White Paper

Disaster Readiness & Recovery Best Practices

March 2013Copyright Cohesive Networks

Disaster Readiness & Recovery Best Practices The National Association of Corporate Directors (NCD) reports a majority of directors are unhappy with both the quality and quantity of information management teams report on corporate cybersecurity and IT risk. Another report of IT professionals found that nearly 34% of organizations lack formal crisis response plans in the event of a data breach or cyber attack.

Now that security breaches are in the headlines and boards are becoming more involved in preventative security, your disaster readiness and recovery plans should not keep you up at night. As a IT professional, you can lead your your organization’s plans for readiness and recovery in the face of security breaches and increasing cloud adoption. Follow these steps to improve disaster readiness for your organization:

First Step: Choose Your Cloud Select a public cloud(s) to meet your scaling, geographic, technology, and vendor diversification needs. Diversification of risk is one of your priorities at this step. Unless your organization is already using public cloud, you will also need to start the public cloud approvals process.

Second Step: Build a Secure Environment You Control Create a controllable and secure virtual network over the on top of your cloud provider's physical network. Later, as you install and launch your virtual application server topologies you can layer on the additional firewalls and rules of a “Security Lattice.” Here your priority should be to harden the firewall rules. Since you are going to be scaling in the event of a disaster, the only way to achieve control is to automate the process, because waiting for sysadmin, security, and network staff to resume work after a disaster is not realistic.

Third Step: Test Scaling and Failure Modes Since step one and two do not compromise security, you can focus many “approvals” on a live test of the topology. You have not deployed any IP or data to the topology, but you have substantially reduced your application's recovery time objective (RTO). If a disaster occurs while your project is at this stage, you can cut red tape to focus on recovery as the top priority.

Fourth Step: Migrate Your Application Repository Now that you finally have approval you can begin deploying copies of the digital assets needed for recovery. At this step you'll encounter a wall of concerns over data skew tolerances. One simple rules should guide all your decisions: choose an attainable recovery point objective (RPO). With a working RPO you will be better prepared to deal with reality because you can't afford the perfect solution - if one even existed.

�2

Disaster Readiness & RecoveryCohesive Networks

March 2013Copyright Cohesive Networks

Fifth Step: Commence Data Synchronization Data replication to the cloud - batch or real-time? Consider costs verses your Recovery Point Objective (RPO) and Recovery Time Objective (RTO). At this stage, moving large data to the cloud can be accomplished by “shipping” tapes to the cloud service provider. As was the case with step 3 red tape and budget issues might drag this step out yet will vaporize the moment an actual disaster happens.

Sixth Step: Define & Deploy the Application Topology Physical and cloud data centers are different, so you will need to define your aspirational topology and adapt it for the cloud. You will be deploying a scaled down version of your production systems that can be “inflated” when the time comes. For this you need automated role based contextualization, and will possibly use automation of your virtual server builds. With the ground work completed you are now ready to install, configure, and boot-up each of the software components of your application architecture. In step four you determined a process for maintaining a repository of software packages, and the associated configuration scripts and metadata. That information can now be used to create vendor and cloud platform specific VMs and bring up a working copy of the application stack.

Seventh Step: Process Live Data There are many ways to segment off a control group of users or transactions allowing some to be processed by the running Disaster Recovery facility. The goal is for the Disaster Readiness facility to be small in scale to minimize operating costs when in stand-by mode. However, it is possible to work with large numbers of servers for short periods of experimentation. Copies of the Disaster Readiness facility can be spun-up for dev/test use - a side benefit.

Eighth Step: Conduct Periodic Disaster Drills At this step the Disaster Recovery facility is fully operational, now your attention can turn to preparedness. IT disaster preparedness comes down to monitoring for any early warnings of a pending disaster, and conducting drills to practice disaster response.

�3

Application Security White PaperCohesive Networks

You have now accomplished Disaster Readiness! You have narrowed your RTO by staging what you need to bring up the application in the cloud providers' facilities. And, you have established a process for moving data to the cloud facility, which means your RPO is a a much more known and fixed down-time risk. The process from here involves the tasks to create a miniaturized clone of the application's server topology. The RTO may be short enough that you can be at, "T minus x and holding," because the window is now acceptable.

March 2013Copyright Cohesive Networks

What Can You Do to Be Prepared? Protect your high priority and at-risk IT resources by implementing a cloud based Disaster Readiness and Recovery strategy to fit your unique needs. Do-it-yourself or use Cohesive Networks' products and services.

Cohesive provides actionable IT contingency solutions for minor to catastrophic IT continuity risk.

The VNS3 Product Family makes it possible to extend your data center into one or more IaaS provider's clouds while retaining complete security and control. You can literally extend your enterprise firewall to enclose, isolate, and control your cloud networks.

For more information email - Sales@Cohesive.net

�4March 2013Copyright Cohesive Networks

Application Security White PaperCohesive Networks