Intruder Alert! … Or Is It?

Fred Avolio, Avolio Consulting, Inc., http://www.avolio.com/

What’s wrong with this picture?
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.

Boy, do we wish we had an Incident Response Procedure.

There 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.

Just 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.

Next Steps
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.

Now 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?

What 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?

Not 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?”

Begin 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.

Before 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 when.

Oh, 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.

The 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 intrusion.

Any questions?