Building an incident response framework for your enterprise

Why is an incident response framework important?

In 2021 alone, there were nearly 24,000 security incidents, which resulted in more than 5,200 confirmed data breaches, according to the "2022 Data Breach Investigations Report" from Verizon. Because breaches continue to mount, often due to hacking or malware, exposure must be reined in.

When attackers hit their target, consumers flee, and state and federal agencies investigate, file and win legal claims in the millions of dollars. Hackers with malicious intent can 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.

Failing at incident response can happen in many ways, which can add to the losses. To avoid making mistakes during incident response, 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. So, 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 let elements 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 might 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 four of the most well-known incident response frameworks to determine the best approach for your organization.

1. NIST incident response framework

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.

For cybersecurity, NIST is responsible for developing information security standards and guidelines, including minimum standards for federal information systems. The NIST Special Publication (SP) 800-61 Rev. 2 -- 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.

Phase 1: Preparation

The quality of incident response largely depends on incident response preparation. In the 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.

Detection focuses 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. 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:

• firewalls
• intrusion detection/prevention systems (IDS/IPS)
• network traffic analysis systems
• SIEMs

Incident analysis begins with taking the incident indicators from the detection phase and validating that an incident has 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 determine what happened.

Phase 3: Containment, eradication and recovery

Containment follows the detection and validation of a security incident. The goals of containment are as follows:

1. Stop the problem from getting worse -- i.e., limit the damage.
2. 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 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 improve the incident response capability and prevent the incident from reoccurring. The following are some types of questions typically asked during the post-incident phase:

• 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?

2. ISO incident response framework

ISO is an independent, nongovernmental international standards organization. It 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 advocates for international standards to become U.S. national standards.

As of this writing, the latest ISO report on incident management is ISO/IEC 27035-1:2023 Information technology -- Information security incident management -- Part 1: Principles and process.

ISO/IEC 27035 is a multipart standard. Part 1, mentioned above, introduces incident management principles. Part 2, ISO/IEC 27035-2, focuses on incident management preparation and planning.

The ISO standard details how individuals should "detect, report and assess information security incidents and vulnerabilities involved with the incident; respond to information security incidents ... deal with reported information security vulnerabilities ... learn from information security incidents and vulnerabilities involved with the incident, implement and verify preventive controls, and make improvements to the overall approach to information security incident management."

ISO/IEC 27035-1:2023 outlines the principles underlying information security incident management, which is broken out into the following five areas:

1. Planning and preparation
   • Establish an information security incident management policy.
   • Create an incident response team.
2. Detection and reporting
   • Set up the processes, procedures and technology required to detect and report the incident.
3. Assessment and decision
   • Set up processes and procedures.
   • Establish incident descriptions and criteria.
4. Response to incidents
   • Establish controls to prevent, respond and recover from incidents.
5. Lessons learned
   • Learn from security incidents and improve overall computer security incident management.

NIST and ISO/IEC 27035-1 are similar in approach and overlap 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/IEC 27035-1 focuses on incident management, which is integrated broadly into other business management and risk reduction functions outside of the incident response organization.

3. ISACA incident response framework

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 following are its incident management lifecycle phases:

1. Planning and preparation
   • Create policies.
   • Acquire management support.
   • Develop user awareness.
   • Build a response capability.
   • Conduct research and development.
   • Build checklists and acquire necessary tools.
   • Develop a communication plan and awareness training.
2. Detection, triage and investigation
   • Define events vs. incidents and notification process.
   • Detect and validate incidents.
   • Prioritize and rate incidents.
   • Implement IDSes, IPSes and SIEM.
   • Use antimalware and vulnerability management systems.
   • Conduct and participate in global incident awareness.
   • Conduct log and audit analysis.
3. Containment, analysis, tracking and recovery
   • Execute containment strategy for various incidents.
   • Perform forensic analysis according to evidence-handling processes.
   • Execute recovery procedures in line with the enterprise business continuity plans and disaster recovery plans.
   • Determine the source of the incident.
4. Post-incident assessment
   • Conduct a post-mortem.
   • Report on incident management-related metrics.
   • Provide feedback of lessons learned.
5. Incident closure
   • Analyze post-mortem.
   • Create and submit management reports.

4. 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.
• 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. Test, verify and monitor affected systems to ensure 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 parameters for an incident report:

• when was the problem first detected and by whom;
• the scope of the incident;
• how the incident was contained and eradicated;
• work performed during recovery;
• areas where the computer incident response teams were effective; and
• areas that need improvement.

Other incident response frameworks

Additional cross-industry incident response frameworks are available, such as those from the following institutions:

• IEEE
• the Internet Engineering Task Force
• the European Union Agency for Cybersecurity

These frameworks can provide guidance and updates. 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. These frameworks 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:

• Prepare. The first step involves the establishment of an incident management function and development of core processes and tools.
• Protect. This step covers risk assessment, prevention process and technology, operational exercises for incident management, training and guidance, and vulnerability management.
• Detect. The Detect stage focuses on network and systems monitoring and threat and situational awareness
• Respond. Incident reporting, incident analysis and incident response are all functions of the Respond stage.
• Sustain. The final step of the framework includes program and project management, as well as 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 for an a la carte kind of 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 could 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/IEC 27035-1 because the ISO/IEC 27000 family of security standards is almost universally adopted in these regions. Or, you might choose to go with the ISO/IEC 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.