Security Manager's Journal: Plans and processes are made to be revised

We security managers are always documenting processes and plans. It's a task without end, because you have to dust off those documents every once in a while and think about how they could be updated. Organizations' needs are always changing, and so is technology, so what was a great plan a couple of years earlier might have some gaping holes now.

Trouble Ticket

The company's incident-response process is badly outdated.Action plan: Use a good model to modernize it, and plan to test it often so it stays up to date.

Such was the case with our incident-response plan. I had reason to review it recently, and it clearly needed modernization.

One thing I have learned over the years is that it's a mistake to start from scratch with these things. When you model a security program against a standard, it is likely to receive less scrutiny in an audit, since it will be in a form that is recognizable and accepted in the industry. That's why I decided to use the incident-response recommendations from the National Institute of Standards and Technology (NIST) as our starting point. Every organization will want to customize its plan for its own needs, but building on a widely used and solid framework is a big help.

With NIST's recommendations as our guide, we broke our incident-response process into four phases: preparation; detection and analysis; containment and eradication; and post-incident analysis.

Preparation is in many ways the most important phase. It includes identifying the members of the crisis action team (CAT). Besides representatives from information security, we wanted the CAT to include Windows and Unix engineers, network engineers, help desk personnel and local law enforcement officials.

Having chosen these people, we obtained full and redundant contact information for all of them, so we could be sure we'd be able to get in touch with them if there were an incident. Then we designated certain conference rooms to serve as "war rooms" and secured a dedicated call-in bridge and an email-enabled distribution list. In this phase we also lined up all the relevant tools we might need to detect or respond to incidents, including packet capturing, malware analysis, event monitoring and forensics tools. Finally, we identified trusted third parties to be on call in case we need expert assistance.

You can never know how a security incident will unfold. With that in mind, in the detection and analysis phase, we didn't try to enumerate every possible scenario. Instead, we listed common events that we see as major concerns. These include malware infestations, phishing attacks, unauthorized access, data loss, denial-of-service attacks and theft. We are also defining which sorts of events should trigger activation of the CAT. For example, a single PC hit by malware is insufficient, but the detection of malware that's quickly propagating could well require a full CAT response. To help us decide when the cavalry is needed, we are creating a matrix to lay out the criteria for escalation.

For the third phase, containment and eradication, we are establishing guidelines on whether an event requires evidence collection, damage assessment and identification of the attackers. We are also preparing checklists to help ensure proper eradication and containment of whatever malicious activity the incident involves. For example, a checklist might address what to do when a Windows server is compromised.

For the post-incident phase, we are describing how to ensure that we have gathered all the information necessary for criminal or administrative action, and we are including recommendations on post-mortems so we can identify what went well and what needs improvement.

Once the incident-response process document is complete, we'll start scheduling training sessions and then regular testing of the plan so we can maintain confidence that we are able to effectively respond to any incident.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

Join in the discussions about security! computerworld.com/blogs/security

Read more about security in Computerworld's Security Topic Center.