Incident response is one part of a four-phase security cycle: Plan, Resist, Detect, and Respond. It's easy to over-invest in one phase if we don't pay attention to the way the phases interconnect.

Top-down view of a four-seat rowboat on dark blue water. Three rowers rest with their oars held out flat, while one rower pulls a single oar, so the boat leaves a circular wake.

What is the relation of incident response (IR) to other information security disciplines, such as intrusion detection, penetration testing, application security and network defense? These teams operate as part of an overall incident cycle that ties disparate security specialists together. The cycle consists of four major phases: Plan, Resist, Detect, and Respond. Let’s take a look at the cycle and explore ways in which organizations often fail at navigating it.

The Security Incident Cycle Flow

Speaking at the US Digital Forensic and Incident Response Summit 2010, Richard Bejtlich discussed the topic of CIRT-Level Response to Advanced Persistent Threat. His talk focused on the unique challenges of handling APT incidents that span years, not days. The presentation (PDF) included a slide that outlined the structure of the Computer Incident Response Team (CIRT) group that Richard built at General Electric to support the security incident cycle. I’ll refer to this diagram; however, my interpretation might differ from that of Richard, as I do not recall the specific details he shared with the audience when discussing this slide.

Security Incident Cycle: Plan, Resist, Detect, and Respond

Phases of the Security Incident Cycle

Your ability to navigate the security incident cycle is critical to the success of your data protection efforts. Let’s take a quick look at the phases of the cycle:

  • Plan: We can look at the big picture of the security incident cycle as starting with the plan phase. The organization prepares to defend its IT infrastructure and data by assessing its security posture. This involves understanding what threats it is likely to face and understanding the extent to which its current state is vulnerable to such threats. Penetration testing and red team exercises are very useful at this stage. The planning phase allows the organization to design an effective, practical and relevant information security architecture.
  • Resist: Having planned out its defense tactics and strategies, and deployed the appropriate components of its security architecture, the organization resists attacks. This involves using security technologies — with the right processes in place — to filter unwanted network traffic in both inbound and outbound directions, block exploits and malware infections (to the extent possible), control access to data and cloud services, guard web applications, and so on. Note the use of the term “resist,” in contrast to the dangerously optimistic term “prevent.”
  • Detect: Since it is naive to expect that the organization will be able to resist all intrusion attempts, it puts effort into detecting compromises. This involves having visibility into the state of the environment at all levels of IT infrastructure (endpoints, networks, cloud services, applications, data, etc.) using endpoint, intrusion, and extrusion detection, performing change detection, gathering and reviewing logs, and so on. The data collected in the detect phase is also critical for investigating the scope of the intrusion once malicious activities have been discovered. Many organizations don’t implement this phase properly.
  • Respond: Once a breach has been detected, the organization mobilizes its incident handlers to respond to the intrusion. This process typically involves understanding the incident’s scope, containing the situation, eradicating the attacker’s presence and recovering from the incident. The post-incident activity, in the form of lessons learned and remaining action items, provides input to the plan phase of the cycle. Capture these details in an incident report so the people planning the next round of improvements can act on them.

The Cycle and the NIST Cybersecurity Framework

NIST now also treats incident response as part of the broader security program. NIST used to describe IR as a four-phase life cycle in SP 800-61r2. In the current version, SP 800-61r3, NIST replaced that life cycle with one based on the six functions of its Cybersecurity Framework (CSF) 2.0. These functions span the organization’s entire security program, from governance to recovery:

  • Plan corresponds to Identify, which includes assessing the organization’s assets and risks and improving the program based on lessons learned.
  • Resist corresponds to Protect.
  • Detect corresponds to Detect.
  • Respond corresponds to Respond and Recover.

The sixth function, Govern, applies to all four phases of the cycle. This function includes the organization’s risk management strategy, roles, and policies. For example, executives should decide in advance who can authorize response steps such as taking a business-critical system offline. The incident response coordinator needs to know who these decision-makers are to keep the response moving.

Joshua Wright maps the activities of his incident response model to these CSF functions in his book Dynamic Incident Response. As he puts it, “effective incident response cannot exist as an isolated function.”

Failures Navigating the Security Incident Cycle

Too often, organizations focus on only one phase of the security incident cycle, without recognizing that each phase is part of a larger circle. Let’s look at some of these failures:

  • Pussyfoot Planning: Some organizations spend all their energy crafting the perfect information security strategy. They carefully weigh pros and cons of all approaches, evaluate products, and account for objectives of all constituents. Committees are formed and reorganized. No agreement is reached. Best practice frameworks are consulted and control mappings are created. Without being able to finalize the plans, such organizations cannot proceed with the implementation of a strategy.
  • Resolute Resistance: Some organizations invest most of their time and money in purchasing and deploying top-of-the-line security tools. A Data Loss Prevention (DLP) project is in the works. Employees are sent to product training. Compliance questionnaires are filled out. Yet, there is no clear relationship between the deployed technologies and the risks facing the organization. A vulnerability management program is in place, but the organization struggles to keep up with security patches. No processes exist to detect when resistance mechanisms fail to block attacks.
  • Dramatic Detection: Some organizations deploy numerous intrusion sensors to discover malicious activities. Many intrusion alerts are issued for the attacks that would have been blocked by defensive measures anyway. A Security Information and Event Management (SIEM) project is in the works. The high number of alerts makes the organization feel good about its “visibility” into the environment. Reports are regularly generated to show the number of exploits or viruses detected in a given day, week and month. When confirmed intrusions are detected, no one is quite sure how to deal with them.
  • Ravenous Response: Some companies have experienced incident handlers. They utilize a variety of free and commercial IR and forensics tools. The handlers are always fighting fires and work long hours. Sometimes they have no opportunity to recommend post-incident improvement measures before having to deal with another breach. When the recommendations are made, they are rarely implemented. The organization is concerned that the rate and severity of incidents seem to be growing faster than it can respond to them.

Look for these failures in your own organization, and assign a clear owner to each handoff between phases of the incident cycle.

About the Author

Lenny Zeltser is a cybersecurity executive with deep technical roots, product management experience, and a business mindset. He has built security products and programs from early stage to enterprise scale. He is also a Faculty Fellow at SANS Institute and the creator of REMnux, a popular Linux toolkit for malware analysis. Lenny shares his perspectives on security leadership and technology at zeltser.com.