Ever been here? You don’t want to be!
Your IT team has just advised, your company has been the victim of a ransomware attack.
On Day 0, they were confident they had backups and could fully restore. By Day 3, they discovered a configuration error in their backup system, rendering most of their backups largely unusable, as well as leaving the task of re-imaging hundreds of workstations, one by one. Imagine you had to be the bearer of bad news that the backups were only marginally effective; that is one of the hardest conversations to have with management, particularly if you had previously assured them otherwise.
If you have data within your business, that if it was inaccessible for a period of time would send you broke – then you need to ensure that your backup and disaster recovery processes are well documented and tested. Test regularly, and don’t just rely on the internal backup test that your software provides.
Research consistently shows that the loss of IT functions in a disaster leads to business failure. For instance, a full 93 percent of companies which lose their computer systems for 10 days or more because of disaster file for bankruptcy within 12 months of the event.
So what does Disaster Recover (DR) actually involve?
A DR plan and testing system specify the steps an organisation must take to recover systems that will meet the company’s technology needs after a disaster. Don’t confuse this with the Business Continuity Plan (BCP)
BCP is what spells out what a business must do to make sure that its products and services remain available to customers. A BCP is made up of a business impact analysis, risk assessment, and an overall business continuity strategy.
While the frequency of testing will depend on your business and its DR readiness, we strongly advise doing a full test at least once per year.
For critical applications, set RPO and RTO (recovery time objectives and recovery point objectives), which are measurable on a scale. The purposes of these benchmarks are to make sure you’re reaching your business objectives while also detailing the processes accounting for success. Management needs to be able to calculate potential loss, and account for this potential loss, so they can measure risk. By measuring the loss expectancy and risk levels, you can then budget for changes to the business in terms of reducing this risk.
Testing your Disaster Recovery Plan can be done in a number of ways. The Disaster Recovery Tests (DRTs) depending on the criticality of the system, how many times it is done a year, and the impact on the business of the test.
Five types of DRTs are used to test disaster recovery solutions
Paper test: In a paper test, members of the DR team read and annotate recovery plan documents such as DR policies, procedures, timelines, benchmarks, and checklists. A hard copy of documents should be stored in a secure offline environment and a digital copy in the cloud.
Walk through test: A walk through test is a group walk through of the DRP to pinpoint any issues that need to be addressed and any modifications that should be made to the disaster recovery environment.
Simulation: In a procedure somewhat along the lines of a fire drill, teams practice the DRP in real life to make sure that it’s sufficient for IT disaster recovery.
Parallel test: In a parallel test, failover recovery systems are tested to make sure that, in case of disaster, they can perform real business transactions supporting key processes and applications. Meanwhile, primary systems continue to run the full production workload.
Cutover test: A cutover test goes further to test failover recovery systems built to take over the full production workload in case of disaster. Primary systems are disconnected during the test.
How do I create a Business Continuity Plan (BCP)?
A business continuity plan outlines procedures and instructions an organisation must follow in the face of disaster, whether fire, flood or cyberattack.
The focus of BCP is totally on the business continuation and it ensures that all services that the business provides or critical functions that the business performs are still carried out in the wake of the disaster.
The scope of the project must be defined and agreed upon before developing a BCP. There are seven milestones involved:
- Develop a contingency planning policy statement.
- Conduct a business impact analysis (BIA).
- Identify preventive control.
- Develop strategies for recovery.
- Develop an IT contingency plan.
- Plan testing, training, and exercises.
- Maintenance planning.
Upper-level management support is very important in BCP planning and implementation. C-level management must agree to the plan set forth and must also support the plan’s action items.
BCP planning and/or implementation can sometimes be outsourced to another organisation, thus transferring the risk. And this is a common way of transferring some of the risks. By engaging a Qualified Security Accessor or Senior Security Consultant from Vectra that understands your business, you can ensure it is done correctly, and the correct steps are followed.
NIST SP 800-34 defines this process.
Key takeaways are: Verify your backups, including your ability to restore them; have a gold image for building systems before you need it; identify resources, including contract and funding requirements needed to rebuild at scale. It is not a matter of if it will happen, it is when – and to what extent!
