Security Incident Containment Checklist
We’ve written previously about some helpful checklists for small-medium sized businesses about their incident response process in general and for the identification of potential security incidents more specifically. Today, we’re going to continue that train of thought through to the containment process with a security incident containment checklist. The overall process for incident response is generally described as having 6 key phases that include preparation, identification, containment, eradication, recovery, and lessons learned.
Within the containment process, the primary goal is to reduce the impact of a potential security incident by isolating the affected host(s) and preventing spread to other systems on the network. While this may sound simple, there are some key considerations during this part of the response process that can help limit damage while also preserving critical forensic evidence, which is key. In many smaller organizations that don’t have a dedicated incident response team, this will be the most critical part of the response process before you call in an outside party for help in the analysis and eradication process. Mistakes here could impact your network and make further investigation impossible. Let’s look at some of the key parts of the containment process:
1. Steps to Isolate the Incident
One of the first things to do once you’ve identified an incident is determine if it can be isolated. If it’s a single system that is affected, that may be as easy as unplugging the ethernet cable connecting it to your internal network and/or disabling the wireless adapter. But in some cases, disconnecting it from a wireless network may be impossible. Or multiple systems across the network may be affected and the systems infected may be unknown. Or even worse, maybe the victim host is one of your business critical servers that cannot be taken offline for any reason.
Whatever the case may be, you should have some documented steps to determine the potential reach of the incident and then establish some kind of host isolation. These steps should aim to sandbox the system from the rest of the network, but not shut down or reboot the system if at all possible. This will potentially destroy critical forensic evidence. Some endpoint protection solutions and EDR products have sandboxing/isolation capabilities, which could also be used to meet the intent of this part of the process, but those capabilities and processes should be documented and practiced ahead of time. Finally, if systems can’t be easily isolated or are business critical, ensure you get some kind of documented executive-level approval for that while you are working through the rest of the response process. This approval might prove critical in showing that you did your own due diligence while still being required to facilitate core business processes.
2. Determine Indicators of Compromise
In order to determine the scope of isolation or understand if the isolation steps you’ve taken were effective, you may need to identify indicators of compromise (IOCs). This is not always possible and may not be realistic depending on the incident type or your team’s technical capabilities, but IOCs can help look for evidence of spread across the network. If you need to leave this until later in the forensic analysis process or get help from a third-party organization specializing in incident response, that is definitely understandable here. The order of some of these sub-steps during a response process can definitely shift around depending on the particular scenario you are faced with.
3. Are Copies/Images of Affected Host(s) Available?
Another consideration that may or may not be part of your technical repertoire is the ability to make forensic images of infected systems. Once you’ve isolated these systems, copies of virtual machines (e.g. snapshots) or forensic images can be taken to facilitate the investigation process while allowing your team to continue with the recovery process. If you’re not comfortable doing this, however, or if you are considering litigation due to this incident, it’s advisable to just leave the systems isolated and let the experts handle this part though. Maintaining sound imaging processes and a documented chain of custody is critical for prosecution.
4. Are Backups Available for the Affected Host(s)?
Along with containment, you should be considering your next steps here as you isolate and control the spread of a potential incident. Many of these things are happening in parallel in a real incident, so you have to constantly be thinking through your options. These options could change based on what part of your network is affected, what data is at risk on infected hosts, or what backups/recovery options you have available to you. Documenting your recovery options and the data loss/recovery time associated with those options will help inform some potentially tough decisions you’re going to have to make (along with management buy-in) at some point in the later phases of the incident response process.
So in summary, while the main question you need to answer during the containment phase is “Do I have this incident isolated and under control to limit impact to the rest of the network?”, there are some other key considerations. These considerations may not come into play during every security incident, they should be part of your incident response plan. It’s important to think about and plan for these things ahead of time, even if that plan is simply “when to call in an outside organization.”
