Incident Response Process Phase 3 – Containment

First Steps

When moving into the containment phase an incident has already been declared. It is now time to categorise the incident and relay this to the customer/management. The categorisation or characterisation of the incident can be broken down into 4 parts.

  • What type of attack is it?
    • External compromise/Internal compromise/Malware etc
  • What systems are effected?
    • Business critical assets will need to be dealt with?
  • Who can be told?
    • Media/employees/Directors/Law Enforcement
  • What does the attacker want?
    • A little more difficult to answer, will need a “we suspect” statement

Once you have an answer to all four you have begun to shade in the outline set up from phase 2.

Keeping Quiet

At this stage it is important not to tip-off the attacker that you are there. The last thing you need is a game of whack-a-mole with the attacker during phase 4. If you have a pretty good idea of what the attacker is after you have a better chance of containing the attack.

For example, if the attacker is collecting a group of files into a zip file in a specific location you may be able to configure security devices, such as an IPS, to detect and block any zip files leaving the environment. This would not tip-off the attacker as they are collecting the files and haven’t extracted it yet. But would also alert you if they attempted to exfiltrate the data.

This whole phase relies on the skill of your team, if your team is poorly trained or poorly prepared the attacker may notice the team’s presence and do a ‘smash and grab’.

It is also possible the attacker is long gone, but this assumption should not be made early.

Initial Containment

The attacker is already in the network, that is why you are here. The goal now is to limit the attackers movement, to stop them gaining further access. Try changing the DNS name of a server, if the attacker is still attacking it then you know they are using IP addresses over DNS names, this means a backup system can be created clean to allow the company to continue while the attacker is still on the system which is no longer live.

There are many other options to limit the attacker, the trick is to make it look like normal network maintenance or failures. Can the attacker be put into an ‘infected VLAN’ while the business continues to operate outside of that. Can filters be set up on networking devices to limit the capabilities.

If you know the attacker has access to emails consider sending mis-information; for example an email from the CIO to the CEO saying “all critical IP information has been moved onto the secure sever, as you need to access if for the meeting later here are the details <honeypot details>”

Forensication

Now is the time to be taking forensic images of the worst hit machines. Try to find patient zero, that is the first infected machine, as this will have the most useful machine. It may not be possible to take an image of every machine, so triage tools such as Crowdstrikes Crowd Response tool will be invaluable at determining which machines are important.

Plan

At this point you should already have a pretty good idea about what measures could have prevented this. Start writing those down for the end report. I have previously mentioned how important note taking is, this is another part of the same idea. You don’t just need to document what you did, but also what you thought (obviously professional thoughts only!!).

Blame

As I pointed out in my photo blame game post, the attacker is the one to blame. Sure the network should have been better protected, but pointing that out right now will not help anyone and simply raise barriers at a point when you need co-operation. Save those comments for the report so they may be written in a constructive way, reviewed by a peer and authorised by you management.

Final thoughts

  • Make sure you have written consent before taking any systems offline which may affect the productivity of the customer
  • Work with ISP’s where relevant
  • Make sure your staff know which incidents do not require you to consult the customer before contacting the authorities (illegal pornography is usually the top of that list)
  • Make sure your IR team have practiced with their tools enough to be competent when the time comes…… grow up 🙂

Other than that, keep calm, don’t panic and write everything down.

This entry was posted in Containment, Incident Response and tagged , , , . Bookmark the permalink.

Leave a comment