Disaster Recovery Planning Basics

Disaster Recovery Planning Basics

2017, Jul 22    

First remember that any information systems can be susceptible to vunlnerabilities.

The information found here is meant to better assist in understanding the purpose, process, and format of information system contingency planning development through practical, real-world guidelines. This guidance document provides background information on interrelationships between information system contingency planning and other types of security and emergency management-related contingency plans, organizational resiliency, and the system development life cycle. This document provides guidance to help personnel evaluate information systems and operations to determine contingency planning requirements and priorities.

If you're interested in jumping ahead, here is a link to NIST 800-34 REV.1 Enjoy!

Disaster Recovery Planning in Information Systems.

The word "disaster" has a particular social connotation that suggests absolute calamity, death, destruction, and mayhem. The vast majority of disaster situations are due to human error and malfunction - rather than a natural catastrophic event. Disaster also doesn't strictly mean property loss or building evacuations. An adverse effect on primary and critical business processes could still occur. Risk analysis helps us determine the effect of disasters on business strategy.

Risk Analysis

** A method, an approach, to evaluate potential loss of IT assets involved in a disaster.

It allows us to identify areas of business process disruption when our assets go off-line. Outcomes from Risk Analysis will become a tool we use to prepare Recovery Strategies and bring the business process back online.

Risk Management

** Systematic application of management policies, procedures, and practices to the tasks of establishing context, identifying, analyzing, evaluating, treating, monitoring, and communicating risk.

Principles of Risk Assessment

** Involves evaluating the most probable threats to an organization.

and analyzing the related vulnerabilities of the organization to these threats.

How is a disaster event defined and quantified?

Approaches to Risk Analysis

  • Qualitative Risk Analysis
  • Quantitative Risk Analysis

Evaluating qualitative and quantitative metrics and the assets.

Qualitative Risk Analysis

Prioritizes the identified project risks using a pre-defined rating scale. Risks are scored based on their probability or likelihood of occurring and the impact on should they occur.

* Qualitative approaches tend to address the emotional response we have to a disaster.

Quantitative Risk Analysis

A further analysis of the highest priority risks. During which a numerical or "quantitative" rating is assigned to develop a probabilistic analysis of the project.

* Quantitative approaches attempt to quantify using financial metrics, the loss to an organization if a disaster were to occur.

Practical Application of Risk Analysis.

  • Quantifies the possible outcomes for the project and assess the probability of achieving specific project objectives.
  • Provides a quantitative approach to making decisions when there is uncertainty.
  • Creates realistic and achievable cost, schedule or scope targets.

Threat Assessment Model (TAM)

A simple method, an analytical framework, of performing Risk Assessment to evaluate technological risk from the perspective of an information asset. An Information Asset could be a piece of equipment, system data, or confidential information. A vulnerability contributes to the risk that an asset may be damaged. The vulnerability would expose a company to loss and generates the necessity for some control of safeguard. This exposure will result in the inherent risk, or the highest possible risk if there are no controls in place.

Threat X Likelihood = Exposure

Questions to ask:

  • What is the likelihood of the threat?
  • How severe would it be if it did occur?
  • Who or what could cause it to happen?

Risk Management can take a back seat to competing priorities for several reasons:

  • It can appear as a distraction - Time spent otherwise working on other projects.
  • It's not free - Too much time and labor necessary.
  • It's not guaranteed - You can't plan for every disaster situation.

So, where's the material financial ROI on risk management?

There is none; it's a sunk cost that does nothing but increases our perceived confidence in our capacity to respond to a disaster. We can always say our information assets are vulnerable, downtime is inevitable, and the loss anticipated. But do we want to experience a little pain now to understand our vulnerability, so that we might best respond to it? Or do we wish to put the pain off until the moment that our vulnerabilities get us compromised?