{"id":1781,"date":"2019-08-18T08:09:07","date_gmt":"2019-08-18T07:09:07","guid":{"rendered":"http:\/\/www.halkynconsulting.co.uk\/a\/?p=1781"},"modified":"2020-08-07T14:05:34","modified_gmt":"2020-08-07T13:05:34","slug":"incident-response-phases-recovery","status":"publish","type":"post","link":"http:\/\/www.halkynconsulting.co.uk\/a\/2019\/08\/incident-response-phases-recovery\/","title":{"rendered":"Incident Response Phases – Recovery"},"content":{"rendered":"

In a previous post<\/a> 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.<\/p>\n

\"Incident
PICERL – Common incident response process \/ framework<\/figcaption><\/figure>\n

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. <\/p>\n

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.<\/p>\n

Recovery<\/h2>\n

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.<\/p>\n

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.<\/p>\n