SAP GRC access control and process control are automated tools that manage an internal security…
How long does it take a disaster to destroy IT infrastructure? Seconds, minutes, hours? Try 205 days.
That’s the average amount of time a hacker spends inside a system before detection. And although your disaster recovery provider may plan for hurricanes, fires and floods, they’re probably not ready for a hacker. Here’s why the future of disaster recovery as a service needs to focus more on security threats.
What Disaster Recovery as a Service Providers Do — and Don’t Do
Disaster recovery services focus on getting your system up and running as quickly as possible. Traditionally, backup copies of your data are stored as tapes at a remote site or in a hosted cloud disaster recovery server. There will also be basic infrastructure (cold DR), a complete duplicate system (hot DR) or cloud resources available to be allocated as needed (cloud DR).
In an emergency, you (or your DRaaS provider) will use the most recent backup to get your system up and running again. This can take anywhere from minutes to weeks, depending on your planning, resources and preparation.
The problem is, your whole disaster recovery plan depends on having a clean copy — something you might not have if a hacker has been camping out inside your system for seven months. There could be malware or cyber security vulnerabilities, compromised user accounts and vandalized or missing data. This can turn a couple days of downtime into months of computer forensics — it could even permanently damage your business.
Disaster Recovery Planning
Security needs to be a facet of disaster recovery planning. You’ll need to brainstorm natural and manmade threats, estimate the risk of each based on probability and severity, and come up with a plan to address the most relevant ones.
That requires a business impact analysis. You’ll have to look at each IT system in depth, and calculate all the costs of downtime, from lost productivity to lawsuits. For example, if a financial database breach could result in SOX compliance penalties and increased audit costs, you’ll need to estimate those expenses.
Use these factors to calculate the impact the disaster would have on each system, and set objectives based on the impact. Two of the most important objectives for planning disaster recovery are:
- Recovery Point Objective (RPO) — How many hours of data you can afford to lose.
- Recovery Time Objective (RTO) — How long it takes to get the system back online.
In addition to RTO and RPO, consider the total time from getting the system online until everyone is back to work (Working Recovery Time), and the total time lost in the disaster (Maximum Tolerable Downtime).
Then, you’ll have to select tools to perform each objective. Defending against hackers could include hiring a cyber security services provider, or expanding in-house security.
Next, you’ll have to assemble a team and a disaster recovery plan. You’ll need contact info and roles for everyone, a communication plan to coordinate the DR efforts, and a system recovery plan detailing every step of DR, along with contingencies and expected execution time.
You’ll also need to plan DR testing. Enterprise disaster recovery requires a lot of people to work together in a high stress situation, so testing needs to be regular, thorough and designed for continuous improvement.
The Future of Disaster Recovery as a Service
Complicated, huh? There’s a reason so many companies don’t have adequate disaster recovery plans. It takes experience, commitment and a vast range of skills to anticipate and prepare for all the worst things that could happen to your company.