Bouncing Back from Cyber Attack

Written by

If you've been hit by a cyber-attack, the effects can be costly and long-lasting. Most companies take around a week to recover and a further two months before things are back to normal. According to Kaspersky, the average loss to business during breach and recovery is over $860,000 from a single incident.

Having a cyber-attack specific disaster recovery plan in place can really help to mitigate the damage and shorten the recovery time, saving money at each stage. Knowing where to get started is always half the battle with a disaster recovery plan. There are a lot of free templates out there for inspiration, but how do you know which ones are most relevant and provide the right level of detail? 

Using the NIST Cybersecurity Framework as a Reference Point
Fortunately, your disaster recovery plan can map neatly on to the 'Recovery' function of the trusted NIST Cybersecurity Framework. The framework is depicted as a circle on the NIST website and this is a valuable visual reminder that recovering from a cyber-attack is not the end of your work.

As soon as your recovery has completed and you are back in control of your infrastructure, software and data, it is time to update your organizational understanding in light of the recent attack (this is part of the 'identify' function).

The core framework functions are sub-divided into various categories and these can form the basic sections of your disaster recovery plan (although you may prefer a slightly different format). The framework then further divides categories into sub-categories and signposts those resources that can be used to inform your cybersecurity protocols.

If you do decide to follow the flow of the NIST framework, the categories under the 'Recovery' function are 'Recovery Planning' (RC.RP), 'Improvements' (RC.IM) and 'Communications' (RC.CO).

Recovery Planning
Recovery planning needs to happen as soon as a breach is detected, whether that is during an ongoing cyber-attack or afterwards. 

This section needs to include a description of all of your IT systems in a clear to understand format (using figures, flow charts, etc.) with more complex information put in an appendix.

You should also set out a full list of all personnel who need to be involved in the recovery, a description of their roles and duties and updated contact details. Where affected networks span national or global regions, this might include personnel working across various premises.

You should also set out exactly when the plan should be triggered and when management, partners and customers should be alerted. It is important to note at this stage that the upcoming GDPR will set time limits for event notification so this document will need to be integrated into your plan to ensure compliance.

To help assess the scale of the attack and to react appropriately you will need to find out what data has been stolen and how sensitive it is. If different types of data have been accessed, this could be ranked as least important, more important and most important.

Least important data would include details that are easily found in the public domain such as a name and address (although these details may be more sensitive in some cases, for example in the Ashley Madison hack).

Data such as credit card numbers and email addresses are more important, but not as important as social security numbers, credit card security numbers and, in some cases, account passwords.

The personnel involved in the recovery process should have clear step-by-step instructions to follow so that all necessary actions are taken to limit damage and reduce downtime. 

Once the problem is solved, there should be a step-by-step reconstitution procedure in place to help personnel get systems back online quickly and safely. Any additional reference information (insurance documents, standards, tables, processes, etc.) can be included in one or more appendices.

Communications and Implementing Improvements
Communications are a critical part of any disaster recovery plan since restoring services may involve many internal and external parties. You will also need to carefully review the entire incident to extract the maximum amount of learning possible.

The ultimate goal of your review and communications (and of the disaster recovery plan in general) is to reduce your disaster rate in the future. Where human error has been detected (as it almost always is in IT security breaches), specific training needs to be put in place to address the blind spots.

It is not enough to send a memo reminding everyone not to click on unknown email links or to choose strong passwords. The fact that a breach has happened should be taken as evidence that it will happen again unless you make real changes to the way you are training employees.

If data has been irrevocably lost, you may need to reconsider how you currently handle backups. It may be necessary to get a dependable IT consulting firm involved as they can explain the benefits and trade-offs with each backup strategy. Dependable SafeSTORE is just one such option (offered by DCG IT Support, Los Angeles).

Stress testing should also form part of a robust disaster recovery plan. This could include periodic simulated attacks to ensure your new systems and training is working effectively.

Finally, disaster recovery plans should be frequently reviewed, especially when new IT infrastructure (virtual or physical) is added or when new rules and regulations are rolled out (e.g. the upcoming GDPR). Contact details should be checked and updated where necessary. It is a good idea to nominate one or more people to take responsibility for keeping your plan up-to-date.

What’s hot on Infosecurity Magazine?