Security Incident Recovery Checklist

We are approaching the end of our series of blogs that touch on some important items that your organization should consider for each of the phases of the incident response process, including identification, eradication, and containment. This week we touch on the recovery process following an incident, once everything has been contained and eradicated. This part of the process is critical when it comes to actually getting operations back to normal and ensuring everything for the business is functioning properly. It is very much a part of the overall incident response process. Let’s look at some key considerations that should be part of your organization’s security incident recovery checklist.

Do Backups Exist?

The first and most important question of the recovery process is whether or not you even have backups available for the affected systems that need to be restored. This should be fairly common sense, but it’s one you want to know the answer to well before an actual security incident. In particular, making sure you have management buy-in for what system backups you have available and what the recovery time/data loss for those systems will be in the event of an incident is extremely important. This should all be laid out and approved as part of a Business Continuity Plan (BCP).

How Do You Recover From Said Backups?

So you’ve got backups available, that’s a great first step. But now you actually have to deploy and recover those backups, which depending on their medium, may be more or less complicated. If you’ve ever had to restore a database from tape backups, for example, that’s probably a process that still gives you nightmares to this day. On the other hand, for VM snapshots that you have available, it may be as simple as a few button clicks to roll back to a known-good image. Whatever the case may be, for each of your different recovery methods you want to have a documented process in place before you need it. This process should have sufficient detail such that anyone can follow it to recover the affected systems and all of these documented processes should be tested on a regular basis (e.g. annually or semi-annually) to ensure they actually work as intended. Any tweaks or changes that are necessary should be worked long before an emergency situation where you are trying to recover on a tight timeline.

When And In What Order Will You Recover?

This kind of goes along with the previous items, but as part of your BCP you should have criticalities/priorities assigned to certain business processes and the systems/applications that support those processes. Using those priorities that have been established, your incident response team and IT teams should be able to devise a plan for recovery that supports those business recovery objectives. This plan should account for which systems need to be done first, how fast these systems can be recovered, etc. such that realistic expectations can be set for the recovery process.

What is the Plan for Increased Monitoring?

Even though you hope to completely recover from every event and do things right the first time, security incidents can be sneaky. In all cases, you should implement some kind of plan to conduct increased monitoring on all recently recovered systems for some period of time (e.g. 30 days). This increased monitoring should help you verify that the original incident was indeed successfully remediated, the recovered systems are functioning as expected, and there are no remnants of an infection or persistent access still in your environment.

Overall, the recovery process should be fairly straight forward and these items related to a security incident recovery checklist should assist you. Maybe more so than any of the other phases, the recovery process requires planning, testing, and evaluation before you need to enact it. Proper preparation can help immensely in making sure the recovery process goes smoothly, and hopefully, this security incident recovery checklist will support you in that endeavor.