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 4 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.
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 pig 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, as often implemented using red and blue teams, is 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, 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 (networks, applications, data, etc.) using 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, provides input to the plan phase of the cycle.
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 Management (SIM) 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 the 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 are made, they are rarely implemented. The organization is concerned that the rate and severity of incidents seems to be growing faster than it can respond to them.
Do you work on one of these organizations? If so, what can you do to begin looking at security incidents as part of a larger Plan, Resist, Detect and Respond cycle? Perhaps that's a topic for another post. In the mean time, I'd love to hear your thoughts in comments.
Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corporation. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and writes a security blog.
