Certified: The GIAC GSOM Audio Course

In this episode, we turn to the moment in an incident where your decisions start changing the environment, not just observing it, and that moment is containment. Containment is the set of actions you take to stop harm from getting worse while you are still learning what happened and how far it reached. New learners often picture containment as simply unplugging a machine or shutting everything down, because that sounds decisive and safe. The problem is that blunt actions can create new damage, like stopping a payroll system, breaking customer access, or wiping evidence you still need to reach the truth. Good containment reduces risk in a targeted way, using what you know right now, while preserving the ability to keep the business running. The skill is learning how to choose actions that are strong enough to interrupt an attacker but careful enough to avoid turning the response into a self-inflicted outage.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Containment sits in the middle of Incident Response (I R) because it connects investigation to recovery through real-world trade-offs. If you delay containment too long, an attacker may keep moving, stealing data, or breaking systems, and your scope can expand faster than your team can keep up. If you contain too aggressively, you can disrupt normal operations, trigger panic, and lose credibility with the people you need to support your decisions. The core idea is proportionality, which means the containment action should match the level of confidence and the level of risk. A proportional action is evidence-driven, so you can explain why you did it, and it is reversible when possible, so you can adjust as you learn more. When you adopt this mindset, containment stops being a dramatic emergency move and becomes a controlled risk management tool. That is how mature teams protect both security and continuity at the same time.

To make good containment choices, you first need to understand what you are trying to contain, because different incident types demand different controls. Some incidents are about stolen identities, where the main risk is that a valid account is being used in an invalid way. Some incidents are about compromised hosts, where the main risk is that a device is running unwanted code or has been altered to allow persistence. Some incidents are about data exposure, where the main risk is that sensitive information is being accessed or moved out. Some incidents are about disruption, where the main risk is that availability is being attacked directly. If you do not classify the risk, you may pick a containment action that targets the wrong thing, like isolating a device when the attacker is actually using a cloud login from somewhere else. Clear classification does not require perfection, but it does require you to connect containment to the most likely harm based on current evidence.

A useful technique is to separate containment objectives into a few simple goals that guide your choices without overwhelming you. One objective is to stop the attacker from continuing the same action, such as repeated logins, lateral movement, or data access. Another objective is to prevent spread, which means reducing the attacker’s ability to reach additional systems or accounts. Another objective is to protect the most critical business functions so the incident does not become a business shutdown. Another objective is to preserve evidence so you can still learn how the incident happened and confirm you actually removed access later. You will not always hit all objectives equally, and that is normal, because trade-offs are built into containment. The key is to know which objective you are prioritizing for this decision and to document why. When your team can state the objective clearly, it becomes easier to select actions that fit the situation instead of acting on fear.

Containment also depends on the difference between short-term containment and long-term containment, which are related but not the same. Short-term containment is what you do immediately to reduce active risk, like limiting access, blocking a path, or increasing monitoring around a suspected entry point. Long-term containment is what you do to stabilize the environment until eradication and recovery are complete, like re-segmenting a network zone, tightening access for a group of users, or placing stricter controls on a sensitive workflow. Beginners sometimes jump straight to long-term containment because it feels more complete, but that can cause unnecessary disruption if you do not yet know what is truly affected. Short-term containment should be fast and measured, designed to buy you time and reduce damage. Long-term containment should be deliberate, designed to hold the line while deeper work continues. Thinking in these phases helps you avoid overreacting early while still acting decisively.

One of the most common containment scenarios involves identity misuse, so it helps to reason through what actions reduce risk without breaking normal work. If you suspect an account is being abused, one option is to disable it, which is strong but can stop a critical employee or service from doing its job. Another option is to force a credential reset, which may be disruptive but can be necessary when you believe credentials are compromised. Another option is to restrict where the account can authenticate from, which can be less disruptive if you understand normal patterns. Another option is to reduce privileges temporarily, which can limit harm while keeping basic access available. You choose among these by asking what evidence you have, how critical the account is, and how quickly the attacker could cause damage if you do nothing. When you aim for targeted restrictions first, you often contain the threat while keeping essential operations alive. The best choice is the one that reduces attacker freedom most while removing the least legitimate capability.

Another common containment scenario involves a suspected compromised host, which creates tension between isolation and continuity. Isolating a device from the network can be highly effective at stopping spread and stopping outbound communication, but it can also disrupt the business function that device supports. A point-of-sale system, a manufacturing controller, or a server that supports customer access might not be something you can simply disconnect without consequences. In those cases, containment can look like narrowing communication paths instead of cutting everything, such as limiting the system to only the network services it truly needs. Containment can also involve increasing visibility around the system to detect further activity while you prepare a safer change window. The key is that you do not treat isolation as the only option, because the business impact varies dramatically by asset. When you choose an action, you should be able to explain what risk it blocks and what business capability it might interrupt. That explanation is how you earn trust during stressful decisions.

Network-based containment choices often sound straightforward, but they can backfire if you do not consider dependencies. Blocking a suspected malicious connection path can stop data theft or command and control activity, but it can also block legitimate integrations, remote access, or business partner connectivity. Segmenting a network area can reduce spread, but it may also break workflows that assume broad connectivity, especially in older environments. Rate limiting or filtering traffic can buy time, but it might also create outages if you misjudge what normal traffic looks like. A beginner-friendly way to avoid harm is to think in terms of least disruption first, such as blocking the most clearly malicious destinations or narrowing access for only the affected system group. You also want to coordinate with operations teams, because they understand what will break and what can be tolerated. Containment is a team decision, not a lone hero action, because the business impact is real and must be managed intentionally.

Containment decisions become much easier when you prioritize the most valuable assets and the most dangerous attacker actions. If you suspect an attacker is close to sensitive data or critical systems, you may accept more disruption to prevent irreversible harm. If you suspect the incident is contained to a low-impact area, you can often choose gentler actions while you gather more evidence. This is where simple risk thinking matters, even for beginners, because you are constantly balancing likelihood and impact. Likelihood is how confident you are that the suspicious activity is truly malicious and ongoing. Impact is what happens if you are wrong or if you do nothing, including business downtime, data loss, safety issues, and reputational harm. When likelihood and impact are both high, aggressive containment is justified. When likelihood is low or impact is limited, targeted containment plus monitoring may be the better first move. This framing helps you avoid treating every alert as the same emergency.

Communication is part of containment because business leaders experience containment through consequences, not through technical details. If you take an action that interrupts a service, people will notice, and they will form opinions quickly about whether the response team is helping or harming. That is why you should communicate in terms of what risk is being reduced, what functions might be affected, and what alternatives were considered. Even in a Security Operations Center (S O C), containment choices should be shared with the right stakeholders so they are not surprised by sudden outages or access changes. You also want to set expectations about uncertainty, because containment is often done before you know the full story. The goal is not to overshare sensitive information, but to provide enough context that decisions seem reasoned rather than arbitrary. When communication is clear, the organization is more likely to support continued containment and follow-on remediation. That support matters because containment is rarely a single action, and cooperation drives success.

Evidence preservation should always be part of containment planning, because some containment actions can destroy the very clues you need to finish the investigation. For example, rebooting a system, wiping a device, or forcefully terminating activity can remove traces that help you understand what happened and confirm what to fix later. At the same time, preserving evidence cannot be an excuse for allowing active harm to continue unchecked, so you need balanced sequencing. A good approach is to identify what evidence is most likely to disappear soon and capture that first when it is safe to do so, while planning containment steps that minimize unnecessary changes. You can also design containment actions that limit attacker movement while keeping the system in a stable state for analysis. When you think this way, containment supports truth rather than hiding it. That is important because eradication and recovery will be stronger when you truly understand the entry point and the attacker’s path.

Another concept that helps beginners is reversibility, which means choosing containment actions you can undo once you learn more, whenever that is practical. Disabling a single account can be reversed by re-enabling it once credentials are secured and activity is understood, but shutting down an entire service might trigger a long and painful restart process. Narrowing network access can often be reversed quickly if it breaks something unexpected, but a rushed infrastructure change might be hard to unwind safely. Reversible actions are valuable early in an incident because they let you act quickly without committing to drastic consequences based on incomplete information. That does not mean you avoid strong containment when needed, because sometimes strong action is the only safe choice. It means you prefer actions with controlled blast radius and clear rollback paths when the situation allows it. Reversibility is also a trust builder, because stakeholders feel safer supporting containment when they know the organization can recover from unintended side effects.

Containment decisions should also be evaluated against time pressure, because some incidents move fast and some unfold slowly. If you believe an attacker is actively exfiltrating data or spreading, you may need immediate containment even if it disrupts operations, because waiting increases harm. If the incident appears dormant or historical, you may have more time to gather evidence, coordinate changes, and choose low-disruption controls. Time pressure is not just about urgency, because it is also about coordination, since rushed containment without coordination can cause cascading failures. A simple way to handle time pressure is to pick a short-term containment action that is safe and targeted, then use the time it buys to design a better long-term containment plan. This keeps you from freezing under urgency or overreacting with risky changes. It also aligns with how effective response teams work in practice, which is in steps that reduce risk while maintaining control.

Finally, mature containment choices are grounded in a feedback loop, where you confirm whether the action actually reduced risk and whether it created unexpected business impact. If you restrict an account, you watch to see whether suspicious access attempts stop or shift to a different identity. If you isolate a host or narrow its connectivity, you observe whether related alerts decline and whether critical services remain stable. If you block a network path, you check whether legitimate traffic was affected and whether alternative attacker paths appear. This feedback loop is how containment stays tied to evidence rather than to hopes. It also helps you avoid the false comfort of taking a dramatic action and assuming the problem is solved. Containment is not a finish line, because attackers can adapt and incidents can have multiple footholds. When you continually evaluate, you refine scope, strengthen controls, and prepare for eradication and recovery with clearer understanding.

In closing, executing containment well is about making precise, evidence-driven choices that reduce attacker freedom while preserving the business functions people depend on. When you classify the incident type, set clear containment objectives, and choose actions with limited blast radius and reasonable reversibility, you reduce risk without creating unnecessary outages. When you coordinate with stakeholders, preserve critical evidence, and build a feedback loop that validates whether containment worked, you keep the response grounded in reality rather than in panic. The best containment is not the loudest action, because it is the action that stops harm efficiently while keeping options open for the rest of I R. Over time, these habits turn containment from a scary moment into a controlled step that the organization can trust. That trust matters because the next phases rely on the same balance of security and continuity, and containment sets the tone for everything that follows.