Recently I posted about how important it was the security to be involved in the development of benchmarks and processes in order to connect to the business. Big fancy acronyms like CIS and ITIL were tossed about like Halloween candy.
Is this your incident response?
This week I am going to extend the conversation into an element of security that must be part of any process discussion: Incident Management.
Incident Management is particularly interesting in the light of the recent attacks on Vmware, Symantec and a host of other high profile companies and internet properties. It all boils down to a fairly straight forward question?when an incident occurs, how does your security team respond. What is the process that is followed?
Documentation, of course, is the key. An outline, flow chart, recipe, whatever you want to call it, having a series of steps that security follows in response to an incident enables the staff to react quickly.
Traditionally incident management is thought of as purely a security exercise. After all?that is what we get hired for. When the intrusion detection alarm goes off, everyone drops what they are doing and runs to the nearest keyboard. The business doesn?t care unless they stop making money. Therein lies the rub?There is an interesting conflict between business and security that often has the two disconnected.
I queried the audience at a SecureWorld Seattle conference I made a presentation at, asking how many of the members felt they were constantly in conflict with the business side of their organizations? It was largely a rhetorical question as the expected answer and the one I received was all of them? This disconnect creates a vacuum that prevents the security teams and the business owners from properly responding to an incident.
Incident response cannot act in a vacuum. If security had its way the process might be: Step 1. Unplug the power cord. Step 2. Congratulate themselves on how secure the server is now.
If the business owners had their way incident response would be: Step 1. Don?t do a thing to keep me from making money. Step 2. If I stop making money?blame security.
How then does this conflict resolve itself? Incident Management, like security must be connected to the business and to do so both parties must be brought to the table and a higher level approach taken.
A three dimensional view of each asset and its risks must be part of any response. How important is this asset? How long can we afford for this asset to be down if at all? What other assets depend on this one?
Once this view of an asset is defined along with all of your other fragile artifacts the IT Ninja can develop their incident management processes around them. Each step of the process must reflect the core business role of any asset in question. High risk, high dependency assets are treated differently than low risk, low dependency assets.
High risk assets must have a low mean time to respond while low risk assets can have larger time windows. The result is that our new process might consist of: Step 1. Determine if the asset is high risk. Step 2. Notify business owner of incident.? Step 3. Determine if incident is ongoing and so on.
Notice how the business owner of the asset has been injected into the process. Just like the security team wants to be invited to the table in the change management process, bringing the various business stakeholders to the development and implementation of the incident management process brings things full circle.
Naturally incident management must be integrated into your other controls such as change management, and release management so that security has the visibility and tools to determine all of the facts around the current system state versus the baseline system state of the environment. System state intelligence gives the security team a launch point for the incident management process.
Security is now connected to the business and the business is connected to security. Both of them working together to keep the pirates at bay while avoiding the cross-purpose internecine rivalries that are so common in organizations today.
Image credit: Joe Belanger
This post was written by?
Chris Orr has contributed 32 posts to The State of Security.
Chris Orr is a Senior Field Systems Engineer for Tripwire, Inc. Having worked for Tripwire for 12 years, he is SANS, ITIL and CISA certified. Currently based in Lake Stevens, WA he covers the Northwest territory and Western Canada for the company.
London 2012 Slalom Canoe Alex Morgan Misty May Treanor Lolo Jones Aly Raisman Marvin Hamlisch Megan Rossee
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.