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.
By recognizing and avoiding these common mistakes, Kelly Jackson Higgins provides a quick set of best practices backed by interviews with security experts. The article should be in every Response Teams must-read library. A response plan should identify the practices to avoid these mistakes:
Not all attacks start with an Advanced Persistent Threat. Apply an objective lens to the data. Look for a 2 stage attack: (1) Phishing, (2) Command and Control.
The article makes a good point. Monitoring is not just for protection and detection. When a breach or intrusion is discovered, audit records provide clues as to what happened, when, and what may be ex-filtrated. Not monitoring, even insufficient monitoring increases potential impact.
Containment and eradication are important, but determining outcomes – data theft, sabotage, other long-term damage – may be more important.
This was not called out as a 4th mistake, but the article led with an example of a team that was focused on the malware and missed a shift to control of an administrative tool. The admonition to “avoid tunnel vision” applies more broadly than just “focusing on malware”.
The example also identified a good practice. An outside firm reviewed the outcome of the incident and discovered the control shift – the true intent of the attack.
Coordinated Response can help to broaden your view and t0 improve your incident response plan.
An effective risk assessment, regardless of the technique employed, identifies impact areas and potential impact levels. Then, given the probabilities an attack, risk strategies are defined: avoid the risk; mitigate the risk; share the risk; accept remaining risk.
Ultimately, unless you choose to avoid the risk, some residual risk is accepted. Then, when an unlikely incident occurs, an incident response plan is the last line of defense.
The key to an effective impact assessment rests with two key questions:
• What areas of your business are at risk when an incident occurs?
• How do you measure the impact?
These two questions are first asked during the risk assessment – the theoretical question: what if? When an incident occurs, they are asked again, only it is no longer in theory. What areas of your business are affected? To what level?
While most organizations evaluate the financial impact, the majority view reputational impact as the more important. Other areas to measure include operational impact and legal impact. If your organization is regulated, you might measure legal impact, policy impact, and regulatory impact as separate areas.
For each impact area, it is important to provide metrics or descriptions that differentiate the impact level. Low, medium, and high are not enough as impact measures. Without metrics different people assign different meanings to the terms low, medium, and high.
It’s worth stressing that the impact component of the risk assessment can and should be used during the Incident Impact Assessment. The Response Team measures adverse impact to determine the needed response.
With this information the response team makes informed decisions on what resources to apply and what actions to take. Refer to our Response Management Framework for added insight.
Let us help you with a response plan review that considers your information security risk assessment.
Most SIEM vendors from HP and IBM to LogRythm and LogLogics offer tools that support incident response, but in the words of one research organization the response is IT-focused and tightly coupled to the SIEM. The enterprise is not involved. Artifacts are limited to SIEM records. Incidents derived from outside the SIEM – help desk tickets, third party alerts, etc. – are not tracked at all.
There is a need to manage incidents at an enterprise-level. In addition to IT, there is involvement and support from:
SIEM vendors provide no interface supporting these enterprise actors. The researchers suggest connecting with an enterprise process automation platform, for example, Microsoft (TM) SharePoint, a platform that provides:
Coordinated Response embraces the SIEM response capability, but extends it to the Enterprise level.
The guide puts incident handling activities in the context of the above diagram. The table below provides the first level of detail.
|Preparation||Detection & Analysis||Containment, Eradication, & Recovery||Post-Incident Activity|
The above activities represent a useful checklist for evaluating an incident response plan as well as incident handling in action.
Of course, recognize that the response to an incident is fluid, often with unclear boundaries. Containment may start in the early stages of analysis. Prioritization may change and notification may continue throughout the incident. But, the insight provided by the NIST publication goes beyond Federal agencies.
I attended the CSO Perspectives event in Alexandria, Virginia on March 21st. This event was produced by CSO Magazine and CSO Online. Publisher Bob Bragdon was the host and moderator. During the course of the day, there was an extensive discussion of the Federal Government’s role in Cybersecurity.
Over lunch, with Bob and a number of others, I suggested we need a federated approach to cybersecurity.
Consider highway safety for a moment and all the factors that make it safe to drive:
This federated approach to safety and security is needed on the information highway (now there is a dated term). We expect hardware and software manufacturers to build safer products. But, we need to be trained to use them properly and not to turn off safety features or, in some cases, we need to be trained to turn them on. The network service providers and internet service providers need to build safer “highways”. We still need government regulations and enforcement.
How do we protect against malicious drivers? This is a metaphor worth exploring.
In Special Publication 800-53, revision 3 NIST included Incident Response as 1 of 18 families of security controls. For the complete list see the end of this item. Much of the material is useful beyond the Federal government.
First, NIST provides a useful framework for considering Incident Response (IR). Please don’t let the control numbers confuse things. I started with preparation, but NIST considers IR Planning as IR-8.
Incident Response preparation starts with Policies and Procedures and the preparation of an incident response plan. With the plan in hand, train users how to recognize and report incidents, train the response team how to organize and react. For some incidents, actually testing the plan with field exercises may be needed.
Incident response execution includes handling, monitoring, reporting, and possibly additional assistance from specialists. NIST suggests each organization consider these controls and determine when or whether they apply.
In SP800-53, Revision 4 Draft, two additional controls were identified: IR-9 Information Spoilage Response and IR-10 Integrated Information Security Cell. The first addresses the additional needs for damaged or leaked information. The latter describes the organization of a specialized element of the Incident Response Team.
While the Incident Response Plan is just one of 8 controls, it touches all the other controls. NIST declares a good Incident Response Plan:
I heartily agree with NIST’s declaration.
NIST Security Controls
Here is the complete list of security control families identified in SP 800-53 and organized by the three control classes: Technical, Operational, and Managerial.
According to the New York Times, Hackers in China Attacked the Times for Four Months. The Times Incident Response Plan provides examples of best practices as well as lessons learned.
And the most important best practice is to make security improvements based on the postmortem and lessons learned
In the case of the New York Times, the hackers were able to crack the password for every Times employee. Then the hackers used the passwords to gain access to the personal computers of 53 employees. The attack was discovered on October 25. The investigation placed the initial compromise on or around September 13 or 6 weeks earlier.
First, the Times engaged their Internet Service Provider (ISP), AT&T, to watch for unusual activity as part of AT&T’s intrusion detection protocol. The Times received an alert from AT&T that coincided with the publication of a story on the Chinese Prime Minister’s family wealth.
The New York Times briefed the Federal Bureau of Investigation (FBI). The FBI has jurisdiction over cybercrimes in the United States.
At the start of week 9, when the response team, even with AT&T assistance, was unable to eliminate the malicious code, the Times engaged Mandiant, a firm specializing in cybersecurity breaches. This is both a lesson learned and a best practice. Expect to need additional help when a significant incident occurs, but it’s best to engage the specialists when the response plan is first developed.
The response team identified 45 pieces of malware that provided the intruders with an extensive tool set to extract information. Virus protection only identified 1 piece. This is an important lesson. Advanced or enhanced malware may be difficult to detect. Defense in depth requires added security controls. In this case, monitoring provided the alert.
At this point, the response team “allowed hackers to spin a digital web for four months to identify every digital back door the hackers used”. This allowed the Times to (1) fully eradicate the intruders, (2) determine the extent of the intrusion and data extraction, and (3) build improved defenses for the future. Again, this is a best practice – investigation precedes eradication.
I found the work habits of the hackers particularly interesting. They worked a standard day starting at 8 A.M. Beijing time. Occasionally they worked as late as mid-night including November 6, election night.
My focus, my interest, my expertise are in the area of incident response planning and management. Seasoned in business process management & automation, I have helped numerous organizations build business response management solutions. Working with my key advisers – Jim Bothe and John Walsh (see About Us – Leadership) – I began focusing on cybersecurity incident response management.
Most people asked about cybersecurity tools mention antivirus software or firewalls or intrusion detection systems. These important tools help to protect systems and information. But, if these tools fail, if an incident occurs, an organized, coordinated response to the incident is needed.
Other people think about the effort to prepare the security plan and architecture. Preparation starts with a risk assessment, includes the security architecture, but should include an incident response plan. To respond to an incident without a well thought out, well tested, well practiced plan increases the risk, the cost, and the overall impact of the incident.
Some organizations might consider any activity performed by the Computer Security Incident Response Team or CSIRT as incident response, but many CSIRT activities are pro-active. The CSIRT may participate in preparation and protection as part of incident management, not just the narrower incident response. In addition, legal, human resources, security may also participate as extended team members of the CSIRT.
The diagram above is based on one in the publication Defining Incident Management Processes for CSIRTs: A Work in Progress, Carnegie Mellon University / Software Engineering Institute, May, 2004. The publication, Technical Report CMU/SEI-2004-TR-015, is available at http://www.sei.cmu.edu/library/abstracts/reports/04tr015.cfm. The authors provide both insight and useful guidance. Be not fooled by its publication date or the tag line “a work in progress”.