Forrester Senior Analyst Rick Holland identifies the keys to an effective incident response program.
This article, available through TechTarget, is a good tool for communicating with your executive team.
The article references an interesting point. According to the Forrester Forrsights Security Survey, after a breach has occurred, 25% of organizations increase spending on breach prevention technologies, while 23% increase spending on the incident response program itself.
Know your capabilities and constraints. Avoid overestimating your abilities. An outside perspective may provide clarity.
Technology spending outweighs investments in incident response programs, but technology does not equal a solution.
Time-to-detect, time-to-contain, and time-to-re-mediate are good results-oriented metrics. Think of others. Consider trending and its implications.
Larger organizations have larger challenges addressing incident response. Consider a contingency team as well as internal and external specialists.
Incident response teams should not work in isolation. Involve your vendors and suppliers.
Align security programs, including incident response, with the business value chain. Connecting the response plan to an enterprise risk assessment is key.
To avoid micro-management, establish rules of engagement that identify the need for approval balanced against the need to act.
This article provides a good set of principles to apply as you build or enhance your incident response program.
Let us help you with a response plan review that applies and expands on the ideas presented by Forrester.
Revision 1 provided a complex measure for incident impact assessment that might provide insight in hindsight, but one that was not practical, applicable, or useful in the midst of an incident response. The new measures, suggested in the table above, are really quite useful, applicable, and discernible. There are 3 important impact areas with associated metrics:
This measures loss of system functionality. NONE – No loss of functionality. LOW – no loss of functionality, but loss of efficiency. MEDIUM – Critical services lost to a subset of users. HIGH – Critical services lost to all users.
Here NIST stops short of measuring impact – so the above diagram is not colored for this Impact Area except in the case of NONE – no information was exfiltrated, modified, or deleted. An impact measure is needed for each of the three information impact areas. PRIVACY BREACH – personally identifiable information was compromised. PROPRIETARY BREACH – unclassified proprietary data was compromised. INTEGRITY LOSS – sensitive or proprietary information was changed or deleted. A level of impact measure is needed in each of these areas. The loss of a single document or individual’s data is low, but what defines medium or high?
This is an interesting and useful metric: Is the data/system recoverable? If so, what is the level of recovery effort? NOT RECOVERABLE – the data or system cannot be recovered. REGULAR – time-to-recover is predicable with existing resources. SUPPLEMENTED – time-to-recover is predictable, but with additional resources. EXTENDED – time-to-recover is unpredictable and additional resources including outside help are needed.
This new approach agrees with the Coordinated Response Impact Assessment in the Response Management Framework. The table below shows the 5 possible impact areas with associated impact metrics.
Coordinated Response can help you review and improve your Incident Response Plan.