Chaos Program

In a computer forensics class I’m currently taking, we studied a federal document that goes in to great detail about how to handle computer security incidents. Malicious code, intrusions, denial of service attacks, the whole gamut of computer/network events that can cause an organization trouble. The document, put out by the National Institute of Standards and Technology is called the Computer Security Incident Handling Guide (aka SP800-61) and it is some of the most useful, albeit hideously boring, reading available for IT professionals currently available.

However, useful and wonderful though it is, I have some problems with this publication. There is very little I can point to and say, “This is wrong.” It covers a lot of territory in an organized way. It gives good advice. Yet I find the total effect to be unsatisfying. Sure, any organization that implements all of the recommendations in this document will be well protected and very capable at responding to incidents when they happen. The trouble is that no organization on Earth is ever going to implement ALL of the recommendations. I don’t think there is enough trained manpower or enough time or money in the world to ever achieve the level of protection detailed (I could even say mind-numbingly detailed) herein.

There is discussion of plans, policies and procedures, guidelines and knowledge bases. The document includes checklists and tables, incident categories and even a marvelous equation for rating the severity of an event. It’s all very complete and very thorough and, as I said, all very sound and reasonable.

I just can’t imagine it can possibly work in practice.

Maybe it’s just me, but I think that when your computers have been compromised, the last thing you want is to run to a file cabinet (or open a password protected pdf, or pull out your cheat sheet) and look for the correct checklist or procedure (Wait! Do we want the procedure or the plan at this point? What’s the policy on that?) for figuring out what you have. Or are we in the containment phase now? I hope someone knows because the training budget on that was cut last year before all of our people could take the class. Come to think of it, they cut a bunch of our people, too.

Time and manpower are two of the real world influences that I think damage the implementation of this very idealized (if intense bureaucracy is your ideal) approach to incident handling. In the real world, incident reporting often comes down to, “Hey! The server is acting funny. Andy, what did you do?” (Real life example). And the responder (in this case a hypothetical server jockey/help desk/programmer/janitor named Andy) begins learning about incident handling AT THAT MOMENT.

Yes, this real world system is screwed up. If it could be implemented, SP800-61 would be an improvement over this ad hoc “OMG! What do I do?” system. If it could be partially implemented, it would be an improvement. That’s what got me started thinking. In even a well funded organization, implementation of these recommendations will take a concerted effort over a period of years. This increases the chances of overall failure (to about 99%) while still giving at least some benefit.

That’s what go me thinking. One of my problems with the whole system is the incredible emphasis on up front paperwork. Policies, plans and procedures certainly seem important but they take a lot of time to write and in the real world no one reads them. Or else one or two people read them when they first come out and then argue over what they said (or how they should be interpreted) when it’s time to follow them. This is one of the huge flaws in bureaucracy. In order for it to function, everyone has to be a lawyer. That’s not what you want when some hacker has broken into your systems and is stealing all your customer’s credit card numbers.

Yet, decisions have to be made at some point and planning them up front is important. Can we balance that with the real world?

Tax software offers some potential help for all sorts of paperwork problems, including this one. It would be helpful if there was a tool that could ask some simple questions (Is the file system encrypted? What are the most critical servers? How much monetary damage should there be before you call the lawyers?) and store them for retrieval at the right time. That would be interesting.

• Computer: “Are you experiencing a hacking incident now?”
• Me: “YES!!”
• Computer: “How many servers/workstations are compromised?”
• Me: “How the hell should I know? I just walked in the door and found 30,000 alerts from the Intrusion Detection System in my email!”
• Computer: “If you do not know, click here for guidance on how to run a scan on each system. Would you like to watch a video about liability issues?”
• Me: “NO! I want to kill the SOB!”
• Computer: “I’m afraid I can’t do that, Dave.”

Well, there may be some bugs to work out in this system. The basic idea, though, is to ditch some of the grunt work of generating paperwork that no one will read in favor of something that can answer people’s questions when they come up. This is a massive undertaking. As I type this, I’m thinking about starting a wiki or writing a survey program (or a combination of both) to start the ball rolling on this. The trouble is, like everyone else in the IT world, I doubt I have enough time to sustain the effort. I feel like I should take a stab at it though, simply to prove that I’m not just a complainer. Still, complaining is easier.

Anyway, the planning software idea only addresses part of the problem. Setting up the systems that SP800-61 quite reasonably recommends (IDS and centralized logging, for example) is to my mind much more important than doing the paperwork (Which is probably why I’m not in management). There are lots of those kinds of things that should be tackled too and they can’t be done all at once.

I’m thinking that in this instance an approach similar to agile development would be helpful. Pick a short period of time (say 2 weeks). Pick a task (getting anti-virus software on all the servers, or doing a penetration test of the web server, or centralizing the logging for X number of machines, whatever). do the task. Tell the software it’s done and move on. Yes, I’m (in my head) integrating actual practices into the incident response assistance tool (IRAT – note to self, come up with a better acronym). This way, during an event, the tool can provide guidance on responding, not just on paperwork.

• Me: “I have a report of suspicious activity on the web server”
• Computer: “You have few possible actions: Centralized logging is not enabled. File system integrity checking is not enabled. What have you been doing all this time, moron?”

Keeping the software up to date can be as much of a nuisance as filling out paperwork, of course. So the next step in this plan, (Besides teaching the computer better manners. I always have trouble with that part) is to set it up to allow people to enter data by voice. From their iPhone.

Then we just have to get management to pay for the phones and the voice software and the IRAT software. Maybe paperwork is the better way to go.

Tags: geek stuff, infosec

This entry was posted on Friday, February 5th, 2010 at 8:59 am and is filed under security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.