# Intelligence-Driven Incident Response ![rw-book-cover](https://learning.oreilly.com/library/view/intelligence-driven-incident-response/9781491935187/ibis_generated_cover_thumbnail.jpg) ## Metadata - Author: - Full Title: Intelligence-Driven Incident Response - Category: #books ## Highlights ### 4. Find - “Be very, very quiet; we are hunting wabbits.” Elmer J. Fudd ### 3. Basics of Incident Response - Intrusion detection and incident response share many characteristics. Both are abstract. They are both complicated topics, and as a result people have sought to simplify them by abstracting them into cycles or models. These models make understanding the complex interplay between defender and adversary possible and form the basis for planning how to undertake responding to these incidents. Just like intelligence models, they are rarely perfect and can’t always be followed explicitly, but they provide a framework for understanding the attackers’ intrusion and the defenders’ response processes. - The Identification phase is the moment where the defender identifies the presence of an attacker impacting their environment. This can occur though a variety of methods: Identifying the attacker entering the network, such as a server attack or an incoming phishing email Noticing command-and-control traffic from a compromised host Seeing the massive traffic spike when the attacker begins exfiltrating data Getting a visit from a special agent at your local FBI field office And last, but all too often, showing up in an article by Brian Krebs - This phase typically leads to an investigation, identifying even more information about the attack and the attacker, before beginning to respond directly. One of the key goals of threat intelligence is to augment the Identification phase, increasing the accuracy and quantity of methods to identify attackers earlier. - Identification, at least in the incident-response sense, is not simply hearing about an attack that took place or learning about a new attacker. Identification starts when there is direct impact to your users, systems, or resources. For it to be an incident, there has to be impact. On the other hand, if an adversary has capability, intent, and opportunity, that adversary does represent a threat. This isn’t the start of the incident cycle, but the intelligence cycle. Only after the adversary is identified in your environment should an incident begin. - The first two phases of the cycle can be considered primarily passive and are focused on information gathering. The first phase of actual response, meaning that specific actions are being taken in response to a specific attack, is containment. Containment is the initial attempts to mitigate the actions of an attacker, stopping them in the short term while preparing a longer-term response. These shorter-term responses may not make the attack impossible, but they dramatically reduce the ability of the attacker to continue to achieve the objectives. These actions should be taken in a rapid but controlled manner to limit the adversary’s opportunity to respond. - Often responders will go for a scorched-earth approach to eradication. In these cases, responders will take remediations on resources with no indications of compromise; for example, regenerating all VPN certificates after an adversary accessed one VPN server. Scorched-earth approaches are effective at mitigating the unknown unknown situations, where it’s impossible to know 100% what the adversary did, but comes with the compromise that it may require a significant effort to make these changes. - A recovery like this requires removing malware from systems, resetting credentials such as passwords and certificates, patching software, and many other changes set on completely removing the attacker’s presence and limiting that attacker’s ability to return. In this case, the mitigation action, taking the entire network offline (likely to limit the attacker’s ability to make changes during the remediation phase), preceded the remedation actions. This is a common pattern when dealing with persistent adversaries. - Containment and eradication often require drastic action. Recovery is the process of going back to a nonincident state. - As an exercise, this can often be daunting. Many teams resist reviewing lessons learned or conducting after-action reviews. This occurs for a wide variety of reasons, from being concerned about mistakes being highlighted (and thus blamed on the IR team) to simply not having enough time. Whatever the reason, nothing will keep an incident-response team from advancing like skipping lessons learned. The goal of the Lessons Learned phase is to discover how to make the next incident response go faster, smoother, or ideally never happen at all. - In addition, capture these lessons and share them with your leadership and related teams. Although it seems like calling out a team’s flaws, in many cases these reports provide concrete justification for making changes that will improve your incident-response capability. - Another military concept that has made its way into cyber threat intelligence vernacular is the kill chain. In fact, it has become so popular that finding information on the original kill chains is difficult because of the extent of information security use cases and marketing. While this concept was on the fringes for years, a paper by Lockheed Martin researchers Eric M. Hutchins et al. titled "Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains" brought the concept into the information security mainstream with a formalized mapping of the most common intrusion pattern as a formalized kill chain. - Kill chains existed long before the Lockheed Martin Cyber Kill Chain as a group of interrelated steps necessary to achieve a military objective, originally of lethal nature (going back to Vietnam era airstirkes). The current US military version of the kill chain is described in "JP 3-60 Joint Targeting.” The kill chain paper by Lockheed Martin is just one cyber kill chain model for describing computer network operations; there is no “right” kill chain. Depending on the attack, certain aspects may be omitted or combined as necessary. Like all models, it’s simply a method of thinking about intrusions. As a result, we will make our own changes, including adding our own stages (targeting and breaking out persistence, for instance), as we describe the kill chain. This isn’t meant to take away from the great work done by the Hutchins et al. but is meant to enhance it as you build your own model for understanding intrusions.