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

By Mathias Thurman, Computerworld |  Security

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.


Originally published on Computerworld |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness