Incident Response and Risk Management Go Hand in Hand

Sunday, February 12, 2012

Neira Jones

9f19bdb2d175ba86949c352b0cb85572

I was delighted with the level of interest generated by my last post on incident response so I thought I’d continue on the same theme...

My thanks go yet again to the NIST report previously mentioned as I will explore some aspects of risk management and prioritisation that apply to incident response...

As mentioned in my earlier post, I know of very few organisations that exhibit effective incident response plans. Arguably, this may be due to the fact that there could be millions of possible signs of incidents each day, recorded mainly by logging and computer security software.

We all know that automation will be needed for data analysis and selection of events that should be of interest for human review. But before we reach that stage, how do we go about deciding what the rules are?

What is it that we should be interested in?... Invariably, the lack of thorough planning will lead to the failure of incident response, including the following:

  • The monitoring technology (whatever that may be) has been configured in such a way that too much information is gathered and no one can see the wood from the trees... Generally, this happens when incident response is entirely left to IT departments and can lead to very expensive deployments that give very little business value and end up giving information security bad name... (sorry my IT friends...)
  • The incident escalation process lacks sufficient planning and accountabilities have not been adequately assigned at all levels in the chain
  • Failure to identify all stakeholders in the value chain of incident response and individuals not held accountable for their part in the process, including lack of regular review of the information collected.

We could have any variation of the above, and for those who know me, you will have recognised the always reliable trinity of “people, process and technology”... In my opinion, the first critical step on the journey to effective incident response is establishing clear procedures for prioritizing the handling of incidents.

So let’s examine how we go about doing that...

Whilst it is almost impossible to develop step-by-step instructions for handling every incident, the NIST report defines several incident categories, based on common methods of attack, including: external/removable media, brute force, web-based, email, improper use and loss or theft of equipment.

One could start using these categories, but how do they actually relate to any specific organisation? After all, what is important for a retailer will be different for a bank or an airline...

Risk Assessment and Incident Response Go Hand in Hand...

What will make incident response specific and effective for any given business is directly derived from the results of the risk assessment (in PCI DSS terms, requirement 12.1.2). As part of their information security strategy, businesses will attempt to limit the number of incidents that could occur by selecting and implementing a set of controls based on the results of their risk assessment.

As residual risk is inevitable, effective incident response becomes a crucial part of managing it. As the risk assessment identifies the assets critical to a business (and the applicable threats, vulnerabilities and controls), so should the incident response plan concentrate on critical assets first. So, the best time to start developing your incident response plan is whilst performing your risk assessment...

The NIST report goes on saying that effective incident response should embed continuous improvement best practice by ensuring that the information accumulated from all lessons learned from live incident handling is used to identify systemic security weaknesses in policies and procedures. I couldn’t agree more.

Finally, don’t forget the full report can be found at http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-61-Rev.%202 and comments can be submitted to 800-61rev2-comments@nist.gov until 16th March 2012 with "Comments SP 800-61" in the subject line.

Until next time...

Cross-posted from Neira Jones

Possibly Related Articles:
8040
Enterprise Security
Information Security
NIST PCI DSS Compliance Enterprise Security Risk Management Security Strategies Risk Assessments Disaster Recovery Incident Response Business Continuity Monitoring Resilience Policies and Procedures Neira Jones
Post Rating I Like this!
08a691067e5e108f0ee475f0109ce087
Jim Meyer The NIST SP 800-61, Revision mentioned in this post changed the definition of Impact Assessment for the better and in a way that supports Neira's argument.

NIST suggests measuring the Impact in terms of:

Functional Impact - how many users lost access to how much functionality.

Information Impact - was there a (i) Privacy Breach, (ii) Proprietary Breach, or (iii) Integrity loss; and to what extent?

Recoverability Effort - the level of effort and the resources required to recover.

These Impact Areas should be aligned with en effective Risk Assessment.
1382194177
9f19bdb2d175ba86949c352b0cb85572
Neira Jones Thanks Jim, for taking the time to comment :) You may be interested in some of the more recent posts on my blog http://neirajones.blogspot.co.uk/
1382214076
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.