Incident Response Phases – Recovery

In a previous post we discussed Incident Response (IR) processes and our preference is one that runs Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned (PICERL). In this post, we are going to be looking a bit more into the Recovery phase of IR.

Incident Response - PICE Recovery L

PICERL – Common incident response process / framework

The incident is going well. First, you found something was wrong. Then you carried out an investigation and found evil. Next, you implemented containment measures. Finally, you eradicated all traces from your network. Now its time to recover.

As you will see, this is the second of the “shorter” posts. This isn’t because it is less important, rather it is just very dependant on your needs.

Recovery

Now we are in the phase where you return to normal, in as much as you can without opening new risks. Your goal is a restoration of services, but equally important is doing so without allowing the attackers back in. As you can guess, this means recovery hinges off your preparation and investigation. Like we’ve said before: if you fail to plan, you’ve planned to fail.

As with the previous phase, what you do here really depends on the situation. This means you can’t plan definitive actions, but it is important to plan goals. Usually, this means ensuring that you align with the business goals. However, there are some things to consider.

  • One step at a time. It is really important to phase the return to normal service. Obviously, if only one machine is affected this might not matter. However, if you are trying to recover an enterprise, plan ahead. Remember, you eat the elephant one bite at a time.
  • Monitor. When you bring systems back, monitor them for a while. Of course you investigated well, so your plan is sound. However, mistakes still happen. Dont bring everything back to discover a mistake.
  • Document. Always with IR it is important to keep notes. This is no exception. Make a note of when each system is recovered. Importantly make notes of what you are monitoring for and what you find.

Generally Good Advice

Remember, the exact steps depend on your needs. They also depend on what the attacker has done. Lastly, they depend on your policies, plans and procedures.

However, having said this, there is some simple advice you should follow:

Step 1: Assess everything you need to recover and prioritise based on business impact. It is important to minimise disruption to the business. Because of this, you might want to recover critical systems first. However, if the risk is high, you might want to recover them last. It is up to you!

Step 2: Develop a recovery plan. This can be a simple list of items. On the other hand it can be a complex project.

Step 3: Recover the first things. First things first! Whatever you’ve picked to go first, bring it back into service. Monitor it. By this, we mean look for all the things. Dont just look for the attack you found. If you can, gather data and threat hunt. Above all else, do not rush this step. If you find evil, trigger an incident.

Step 4: Recover the next thing. When you are happy with the first thing, recover the next. Do the same with monitoring. If you can, threat hunt. If you find evil trigger an incident.

Step 5: Repeat step 4 until you run out of things.

Congratulations. Recovery is complete.

Comments are closed.