Incident response coordinates approaches to manage cyber incidents and fallout to limit the consequences. Incident response frameworks guide the direction and definition of response preparedness, planning and execution by outlining and detailing its elements, steps and stages.
Why an incident response framework is critical
Data breaches exposed more than three billion identity records in 2017, according to a 2018 identity breach report, "Identities in the Wild: The Tsunami of Breached Identities Continues" from 4iQ, a leading identity threat intelligence company. That figure constitutes a 64% increase in breached identity records when compared to data from the previous year, according to the 4iQ website. Breaches are continuing to mount, so exposure must be reined in.
When attackers hit their target, consumers run for cover, and state and federal agencies investigate, file and win legal claims in the millions of dollars. Black hats compromise tens of millions of credit cards, leading to hundreds of millions of dollars in costs. Breaches can cost C-level executives their jobs. Settlements require companies to institute additional security measures and undergo greater scrutiny. After a breach, years of negative press are almost guaranteed and damage control is critical.
These costs are driving organizations to adopt real-time incident response techniques that limit damage and reduce recovery time and costs. Generally, the better the incident response process is, the better the outcome will be.
This article is part of
However, there are many ways to fail at incident response, which can add to the losses. KPMG published the report "10 common cyber incident response mistakes" for federal agencies. To avoid such mistakes, organizations should look to credible incident response frameworks. Organizations can then use the frameworks to refine an incident response plan, avoid response missteps and cap the casualties of the next breach.
Incident response framework vs. incident response plan
A framework provides a conceptual structure. An incident response framework provides a structure to support incident response operations. A framework typically provides guidance on what needs to be done, but not on how it is done. A framework is also loose and flexible enough to allow elements to be added or removed as necessary to satisfy a particular organization or constituency.
A plan is a detailed set of steps that is intended to achieve some goal. A plan may also call out the resources required and the roles and responsibilities that must be supported and carried out to achieve its goals.
An incident response plan has a goal delivering effective incident response. An incident response plan details the processes needed to deal with computer security incidents, the resources required, and the communication and escalation paths required for plan operation.
Working together, the framework suggests logical elements that should be included in a plan. A plan includes those elements as well as elements of mission, services, people, process, technology and facilities.
With these distinctions in mind, it helps to understand three of the most standard incident response frameworks to determine the best approach for your organization.
The NIST incident response framework
The National Institute of Standards and Technology (NIST) is part of the U.S. Department of Commerce. The NIST mission is:
To promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.
With respect to cybersecurity, NIST is responsible for developing information security standards and guidelines, including minimum standards for federal information systems. The NIST "Computer Security Incident Handling Guide" includes an incident response framework in the form of an incident response lifecycle.
The four stages of the NIST incident response lifecycle are preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Here's a look at each one in more detail.
The quality of incident response largely depends on incident response preparation. In this preparation phase of the lifecycle, all the components needed to respond effectively to a computer security incident are identified, created or acquired.
Preparation includes the following:
- establishing an incident management capability, process and plan;
- creating incident response policies and procedures;
- acquiring and training incident response staff;
- acquiring incident handling tools and training;
- building an incident tracking system;
- creating incident reporting policies and processes; and,
- determining incident detection policies, processes, tools and procedures.
Phase 2: Detection and analysis
While the capability to detect incidents is set up as part of the preparation phase, incident detection starts the incident response process. Incidents cannot be responded to until detection occurs.
Detection focuses primarily on discovering indicators of compromise. Network and system users notice many incident indicators, so it is critical to have an incident reporting policy and procedure. Essentially, users need to know about the kinds of activities or indicators that they should note and they should have an easy reporting process.
The other major incident detection method is using various monitoring systems, which include the following:
- intrusion detection/prevention systems
- network traffic analysis systems
- security event information management systems
Incident analysis begins with taking the incident indicators from the detection phase and validating that an incident has actually occurred. Incident analysts are responsible for investigating ambiguous, incomplete, contradictory or erroneous indicators. Given this difficult task, NIST recommends building a team of highly skilled and experienced staff to make determinations of what happened.
Phase 3: Containment, eradication and recovery
Containment follows the detection and validation of a security incident. The goals of containment are simple:
- Stop the problem from getting worse (i.e., limit the damage).
- Regain control of systems and network.
NIST recommends creating containment strategies in advance according to factors such as major incident types, email, network and malware to facilitate decision-making.
Eradication is the elimination of the components of an incident such as removing malware, eliminating malicious user accounts and identifying vulnerabilities that were exploited as part of the security incident.
Recovery is the restoration of systems to normal operation following a security incident. Recovery tasks include restoring files from backups, reinstalling application software from known good media, mitigating vulnerabilities identified in the eradication phase and changing passwords.
Phase 4: Post-incident activity
Post-incident activity centers on lessons learned to accomplish two things: Improve the incident response capability and prevent the incident from recurring. The types of questions asked during the post-incident phase include the following:
- What happened, exactly? (Build an incident timeline to determine this.)
- What worked well? What didn't work as well?
- Which procedures failed or failed to scale to respond to the incident?
- Which staff roles worked and were performed appropriately?
- Were any mistakes made that impeded recovery?
- What staff actions could be improved?
- Which policies and procedures could be improved?
- How could this incident have been avoided?
The ISO incident response framework
The International Organization for Standardization, or ISO, is an independent non-governmental international standards organization. ISO develops voluntary international standards that support innovation and provide solutions to global challenges.
The ISO representative in the United States is the American National Standards Institute (ANSI) which, like NIST, has a mission to enhance U.S. competitiveness. However, ISO also may advocate for international standards to become U.S. national standards.
As of this writing, the latest ISO report on management is "ISO/IEC 27035-1:2016 Information technology -- Security techniques -- Information security incident management -- Part 1: Principles of incident management." This international standard for incident response handling is current and includes cyberattacks.
ISO/IEC 27035 is a multi-part standard. Part 1, mentioned above, introduces incident management principles. Part 2 of the standard, ISO/IEC 27035-2, focuses on incident management preparation and planning.
Briefly, the ISO standard details how individuals should "detect, report and assess information security incidents; respond to information security incidents ... report information security vulnerabilities ... learn from information security incidents and vulnerabilities, institute preventive controls, and make improvements to the overall approach to information security incident management."
ISO/IEC 27035-1:2016 outlines the principles underlying information security incident management, which is broken into five areas:
- Planning and preparation:
- Establish an information security incident management policy.
- Create an incident response team.
- Detection and reporting:
- Set up the processes, procedures and technology required to detect and report the incident.
- Assessment and decision:
- Set up processes and procedures.
- Establish incident descriptions and criteria.
- Response to incidents:
- Establish controls to prevent, respond and recover from incidents.
- Lessons learned:
- Learn from security incidents and improve overall computer security incident management.
NIST and ISO 27035-1 are very similar in approach and overlap each other significantly. There is an important, but subtle difference, however. The NIST "Computer Security Incident Handling Guide" focuses on incident handling, which deals with the prevention, detection and responding to incidents. ISO 27035-1 focuses on incident management, which is integrated broadly into other business management and risk reduction functions outside of the incident response organization.
ISACA incident response framework
Formerly known as the Information Systems Audit and Control Association, ISACA is now known by its acronym only. ISACA is engaged in "development, adoption and use of globally accepted, industry-leading knowledge and practices for information systems."
Likewise, ISACA offers its Incident Management and Response framework, which includes several resources and footnotes. The incident management lifecycle phases include the following:
- Planning and preparation
- Detection, triage and investigation
- defining events vs. incidents and notification process;
- detecting and validating incidents;
- prioritizing and rating incidents;
- implementing intrusion detection systems, intrusion prevention systems and security information events monitoring;
- using antimalware and vulnerability management systems;
- conducting and participating in global incident awareness; and
- conducting log and audit analysis.
- Containment, analysis, tracking and recovery
- executing containment strategy for various incidents;
- performing forensic analysis according to evidence-handling processes;
- executing recovery procedures in line with the enterprise business continuity plans and disaster recovery plans; and
- determining the source of the incident.
- Post-incident assessment
- conducting a postmortem;
- reporting on incident management-related metrics; and
- providing feedback of lessons learned.
- Incident closure
- analyzing postmortem; and
- creating and submitting management reports.
Other frameworks for guiding incidence response
Additional cross-industry incident response frameworks are available, such as those from the SANS Institute, the Institute of Electrical and Electronics Engineers, the Internet Engineering Task Force and the European Union Agency for Network and Information Security. These frameworks can provide guidance and updates. You should familiarize yourself and your incident response plan team with these frameworks.
It is important to contact standards and member organizations in the industry about their frameworks and to ask your vendors for guidance on their hardware, software, services and the different applications you use. Most vendors have frameworks to handle security incidents in their environments.
How to build and customize an incident response plan
Start by assimilating incident response frameworks from recognized standards organizations such as NIST, ISO and ISACA.
The incident response frameworks from NIST, ISO and ISACA are more similar than they are different. All incident management and response frameworks have a common lineage that can be traced back to the original computer emergency response team, CERT/CC and its five-part framework of the following:
- Establishment of an incident management function
- Development of core processes and tools
- Risk assessment
- Prevention process and technology
- Operational exercises for incident management
- Training and guidance
- Vulnerability management
- Network and systems monitoring
- Threat and situational awareness
- Incident reporting
- Incident analysis
- Incident response
- Program and project management
- Security administration
So which framework should you choose? Should you choose one framework in its entirety or should you choose part of one and combine it with parts of another framework in a kind of incident response a la carte?
When considering whether to adopt a framework as is or build your own, here are some things to think about:
What compliance obligations do you have that may affect your choice? Do you have obligations under the Federal Information Systems Management Act (FISMA)? Maybe you are a U.S. Federal government supplier and you must supply FISMA-complaint services. If so, you would go with NIST guidance because NIST has the statutory responsibility under FISMA to develop information security standards and guidelines.
Perhaps you do business outside of the U.S., in Europe or the Middle East. In that case, you should look at ISO 27035-1 because the ISO 27000 family of security standards are almost universally adopted in these regions. Or you might choose to go with the ISO 27000 family of standards to integrate security more easily into other business functions.
Other than these considerations, there is not much to recommend one computer security incident response framework over any other. Remember, a framework provides some structure that underlays and supports incident response operations. The incident response operational plan that you build on the framework, not the framework itself, is what is your organization is going to use to protect itself and guide its incident management activities.
8 ways to fail at incident response
- Fail to get executive sponsorship or involve stakeholders.
- Fail to create a computer security incident response team (CSIRT) and an incident management process documented in an incident response plan.
- Fail to create baselines for network traffic and application use.
- Fail to obtain the needed resources: Budget, people, training, facilities, etc.
- Fail to identify incident response constituency and their needs.
- Fail to identify critical assets that need to be protected.
- Fail to identify the threat environment that endangers critical assets.
- Fail to perform risk assessments.