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 is an incident response framework important?
Data breaches exposed 3.6 billion new and authentic identity records circulating in underground communities in 2018, according to a 2019 identity breach report, “Identities in the Wild: The Long Tail of Small Breaches,” from 4iQ, a leading identity threat intelligence company. That figure constitutes a 71% increase in breached identity records when compared to data from the previous year, according to the 4iQ website. Cybercriminals targeted more small businesses in 2018, which resulted in a 424% increase in new breaches since 2017. Because breaches continue to mount, 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. Hackers with malicious intent 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, the better the outcome will be.
This article is part of
Failing at incident response can happen in many ways, however, 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.
A framework typically provides guidance in what needs to be done but not in how it is done.
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 intended to achieve a 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 the goal of delivering effective incident response. It 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 well-known 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. NIST’s 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 quality of life.
In regard 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.
Phase 1. Preparation
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.
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.
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 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:
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. It includes things like 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 nongovernmental 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, which, like NIST, has a mission to enhance U.S. competitiveness. 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 cyber attacks. A revised edition is under development.
ISO/IEC 27035 is a multipart 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
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 similar in approach and overlap each other significantly. An important but subtle difference, however, is that the NIST “Computer Security Incident Handling Guide” focuses on incident handling, which deals with the prevention, detection and response 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.”
Like NIST and ISO, ISACA offers its own Incident Management and Response framework, which includes several resources and footnotes. The incident management lifecycle phases are the following:
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 post-mortem;
reporting on incident management-related metrics; and
providing feedback of lessons learned.
Incident closure
analyzing post-mortem; and
creating and submitting management reports.
SANS Institute incident response framework
The SANS Institute’s incident response playbook has the following six components:
Preparation. Organizations should review and codify security policy, perform a risk assessment, identify sensitive assets, define the critical security incidents the team should focus on and build a computer security incident response team (CSIRT).
Identification. Organizations should monitor IT systems, detect deviations from normal operations and decide if they represent real security incidents. If an incident is discovered, the team should collect additional evidence, establish its type and severity, and document everything.
Containment. Organizations need to perform short-term containment and then focus on long-term containment, which involves temporary fixes to enable systems to be used in production while rebuilding clean systems.
Eradication. Organizations need to remove malware from all affected systems, identify the root cause of the attack and take action to prevent similar attacks.
Recovery. Organizations should bring affected production systems back online cautiously to prevent more attacks. The team needs to test, verify and monitor affected systems to verify that they are back to normal activity.
Lessons learned. No later than two weeks from the end of the incident, the team should compile all relevant information about the incident and identify lessons that will help with future incident response activity.
SANS offers the following general format for an incident report:
when was the problem first detected and by whom;
the scope of the incident;
how it was contained and eradicated;
work performed during recovery;
areas where the computer incident response teams were effective; and
areas that need improvement.
Other frameworks for guiding incidence response
Additional cross-industry incident response frameworks are available, such as those from the following institutions:
the Institute of Electrical and Electronics Engineers;
the Internet Engineering Task Force; and
the European Union Agency for Cybersecurity.
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 and 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, ISACA and SANS.
The incident response frameworks from NIST, ISO, ISACA and SANS 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, Computer Emergency Response Team Coordination Center and its five-part framework of the following:
Prepare
Protect
risk assessment
prevention process and technology
operational exercises for incident management
training and guidance
vulnerability management
Detect
network and systems monitoring
threat and situational awareness
Respond
incident reporting
incident analysis
incident response
Sustain
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 a la carte incident response?
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 Security Modernization 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 is 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, it’s difficult to recommend one computer security incident response framework over another. The bottom line is that a framework provides a structure that underlays and supports incident response operations. No matter which framework your organization chooses, the incident response operational plan, not the framework itself, is what your organization is going to use to protect itself and guide its incident management activities to discover and contain breaches.
