Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

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

Mathias Thurman | May 7, 2013
The company's incident-response plan needs to be updated. That's normal -- no plan is carved in stone.

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.


1  2  Next Page 

Sign up for MIS Asia eNewsletters.