Intruder Alert! … Or Is It?
Fred Avolio, Avolio Consulting,
What’s wrong with this
We have network vulnerability scanners we point and
click at our firewalls and web, e-mail, and file servers.
We have system vulnerability scanners we run on the same.
We have intrusion detection products watching the network
traffic, and audit logs looking for everything from the
ill-advised situation to the unthinkable (and perhaps
impossible, according to our risk analysis). Then one day
our beeper beeps, the red lights begin flashing, and the
alarms tell us we have an intruder.
do we wish we had an Incident Response Procedure.
is neither time nor space for a complete Incident
Response discussion here. The purpose of this write-up is
not to give you answers, but rather questions.
What Is an Intrusion, Anyway?
Since I’m providing questions, maybe this should
be the first one: just what is an incident, anyway? You
must define what constitutes an intrusion. Does a port
scan — the equivalent of doorknob rattling or turning —
count as an intrusion? Put that way, you might think,
“Well, I guess not.” However, if I liken it to
someone persistently circling your house and trying all
your doors and windows to see what’s unlocked, does
your reaction differ? The answer probably boils down to
what is normal for your network. If a port scan is
rare, you might count it as an intrusion. Or, you may
find that every few minutes someone on the Internet scans
your ports, and so you may decide to ignore port scans
(after making sure a port scan does not reveal any
vulnerabilities). Maybe you should only decide it is an
intrusion if you plan to do something about it.
Once you’ve answered the first question, many
more follow. Two of the most important questions an
Incident Response Procedure must address: “Whom do I
call?” and “When do I call?” You must come
up with a definitive list, with the help of others. The
call list will probably include senior management, system
and network administrators (members of the IT staff),
help desk staff, members of the legal department,
marketing management, someone in public relations, even
someone handling investor relations. Perhaps the police
or the FBI will make your list. You’ll want to know
when to call one versus the other. Many police precincts
have dedicated an officer to computer crimes. Does your
precinct have one? What is his or her direct number?
Obviously, you will not notify everyone at once. Nor will
you notify everyone in a given department. Determining
the proper order and timing of your calls is critical, as
is operating on a “need to know” basis. Your
future business and stock value may depend on getting all
of this right.
the questions flow faster than packets. Earlier, I
mentioned your legal department. Do they understand
computer crime issues? Can they help you understand the
law in your area? What are the rules of evidence under
which your company operates? What constitutes
“elements of proof” in your legal jurisdiction?
Are your logs admissible in court?
will you do if an attacker calls? Will you shut him down,
string him along, or hire him? Is your company’s
policy to prosecute attackers or to batten down the
hatches and hope he goes away?
everyone has to know the answers to all of these
questions but some people in the company do. At the very
least, everyone in the company should know a better
answer than “Ghostbusters!” to the question,
“Who ya gonna call?”
at the Beginning
The absolute worst time to come up with an
Incident Response Procedure is during an attack. Far
better to think, plan, fail, and rethink during peacetime
than in the heat of battle.
you are done, you must drill — more than once. Do the
procedures work? Were they clear and effective? What was
missing? Whom did you forget to tell? Make it as real as
possible, and analyze what information leaked out and
yeah. Your procedures must include a post mortem. Not
only will a debriefing ask the above questions about the
procedures themselves, but it will also assess the damage
done and decide if there is any way to avoid a similar
incident in the future.
best incident response procedure is one that you never
have to use. The next best is the one that allows you to
thoughtfully, effectively, and safely deal with an