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 a 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
prioritising 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...
Nice blog. NIST incident response enhances the scalability of the framework, allowing interaction with local, state and federal resources using common methods and terminology defined at the federal level.
ReplyDelete