One of the key metrics Computer Incident Response Teams (CIRTs) often measure is time to containment. This is often seen as a way to guage the performance of the team as it tracks how long it takes to contain a compromised or infected computer from the time of reporting or detection. This number varies widely accross the companies and many simply do not have the capability or desire to record this information. I think this metric often indicates how well the CIRT team knows their environment and the maturity of their processes. So I highly recommend it be a key performance indicator in your CIRT program.
Today however I would like to specifically talk about an appropriate goal for this metric in relation to compromise by advanced external threats. So I will be excluding non-targeted malware and insider scenarios. I believe on one end of the spectrum you have teams that like to contain as soon as possible to limit any possible impact, whereas on the opposite end you have teams that like to wait a long time (weeks/months, usually contracted responders) to fully scope an incident prior to making any major containment efforts. And before we proceed further containment can mean many things, however I will define it here as isolation or removal of the compromised computer from the network. That being said, why would you choose either of those extreme options? One strategy is to quickly deny the adversary any asset before they can conduct further operations inside your network. The big pitfall being here, that you don't have enough time to figure out exactly how they compromised the system and what other systems they control in such a short time span. Whereas, waiting longer allows you to fully scope out the extent of the breach where the hope is that the investigation doesn't alert the intruders that the defenders are on to them. This routinely fails as advanced intruders, know to mix up their backdoor tools and maintain several entry and exit points. To me rather then being time focused, I prefer a process flow that scopes the incident for you.
Questions like the following are key to this flow:
What method was used to compromise the system?
How long have they been active in the environment and are they still active?
Which system was ground zero for the intrusion?
What accounts have been compromised and can they be reset in a timely manner?
What ingress and egress points are the intruders using?
What systems have been touched by the intruders?
What command and control (C2) method are the intruders using and can you decipher it?
Have you seen this group in your environment before?
Have you documented the indicators of compromise (IOCs)?
Do you have the ability to scan your environment for these IOCs?
Do you have the capability to take the system offline without a disasterous business outage?
Has the scope of the breach and/or data loss been determined?
Has senior security leadership been briefed on the incident?
Is data exfiltration actively occurring?
These are just some intial questions you need to add into your containment decision process flow. I can tell you that being on either end of the spectrum is not sucessful in large companies where you don't have good system inventory and a full internet gateway registry. It's possible to do either if you have full mastery of your computing infrastructure, but this is a rarity. I think based on your capabilities and the questions above you can create a plan that gets the system contained as quick as possible with out tipping off the intruder and/or allowing them to continue to develop their foothold on your network.
Stay secure my friends.
Today however I would like to specifically talk about an appropriate goal for this metric in relation to compromise by advanced external threats. So I will be excluding non-targeted malware and insider scenarios. I believe on one end of the spectrum you have teams that like to contain as soon as possible to limit any possible impact, whereas on the opposite end you have teams that like to wait a long time (weeks/months, usually contracted responders) to fully scope an incident prior to making any major containment efforts. And before we proceed further containment can mean many things, however I will define it here as isolation or removal of the compromised computer from the network. That being said, why would you choose either of those extreme options? One strategy is to quickly deny the adversary any asset before they can conduct further operations inside your network. The big pitfall being here, that you don't have enough time to figure out exactly how they compromised the system and what other systems they control in such a short time span. Whereas, waiting longer allows you to fully scope out the extent of the breach where the hope is that the investigation doesn't alert the intruders that the defenders are on to them. This routinely fails as advanced intruders, know to mix up their backdoor tools and maintain several entry and exit points. To me rather then being time focused, I prefer a process flow that scopes the incident for you.
Questions like the following are key to this flow:
What method was used to compromise the system?
How long have they been active in the environment and are they still active?
Which system was ground zero for the intrusion?
What accounts have been compromised and can they be reset in a timely manner?
What ingress and egress points are the intruders using?
What systems have been touched by the intruders?
What command and control (C2) method are the intruders using and can you decipher it?
Have you seen this group in your environment before?
Have you documented the indicators of compromise (IOCs)?
Do you have the ability to scan your environment for these IOCs?
Do you have the capability to take the system offline without a disasterous business outage?
Has the scope of the breach and/or data loss been determined?
Has senior security leadership been briefed on the incident?
Is data exfiltration actively occurring?
These are just some intial questions you need to add into your containment decision process flow. I can tell you that being on either end of the spectrum is not sucessful in large companies where you don't have good system inventory and a full internet gateway registry. It's possible to do either if you have full mastery of your computing infrastructure, but this is a rarity. I think based on your capabilities and the questions above you can create a plan that gets the system contained as quick as possible with out tipping off the intruder and/or allowing them to continue to develop their foothold on your network.
Stay secure my friends.
Comments
Post a Comment