Disaster Recovery Planning - Part 2

Last month we initiated a discussion on the implications and definitions of a business based "Disaster". This time around, we will delve a little deeper into the topic and go over some of the methodology associated with the Disaster Recovery Planning process.

Let's get started

One of the often neglected procedures in Disaster Recovery Planning that bears mention is Business Impact Analysis (BIA). A BIA is essential in determining the extent to which individual systems affect business continuity in the event of their loss or destruction. The way this analysis is conducted is to examine the relationships between five key elements in your organization:

1. Assets - the resources the organization wants to protect, including hardware, software, facilities, cash, data, and personnel;
2. Threats - the dangers which can cause harm to the system or generate losses;
3. Vulnerabilities - the opportunities which could allow a threat to materialize;
4. Losses - anything that can be taken away from the system. This includes loss of reliability of data through modification, or destruction, theft of equipment, loss of reputation, delays of service;
5. Safeguards - administrative, physical and technical controls designed to provide protection and reduce vulnerability.*

(* list courtesy Binomial International)

Undertaking a BIA is a fundamental step in preparing for your Disaster Recovery Plan as it determines which business systems are essential to post Disaster business resumption and those which may not be key to continuity.

The next step

Once you have differentiated between what is required vs. less mission critical systems, you must examine the essential ones in more detail. This is accomplished by performing Threat and Risk Assessments (TRA's) on all of your key soft and hard assets. A good TRA will determine your state of vulnerability and provide you with a baseline by which you may judge your progress toward efficient Disaster Recovery and make recommendations for safeguards to assist in prevention.

Once you have determined the scope of the TRA, enlisted the participants in the process (typically a cross section of the affected personnel; including key stakeholders in the systems being examined as well as members of the user community) and determined the security concerns intrinsic to your setting, you must develop a preliminary baseline to define the environment. This baseline is what your progress will be measured against as your environment changes over time.

Asset Identification

The next step involved in the TRA process is the identification of assets particular to the system being scrutinized. This is often a very arduous process, depending on the state of inventory records and materiel management strategies your organization may be employing at the time.

There are many commercial off the shelf (COTS) software packages that may be of great assistance in this endeavor. Prime examples of these would be Microsoft System Management Server (SMS) or Norton Administrator for Networks; both of which employ robust asset collection schemes and reporting facilities which should prove invaluable.

Once these assets have been properly documented, a value must be assigned each of them. You must exercise caution in determining an asset's worth, as the capital cost of an item is often dwarfed by it's acquired value. Take as an example, an accounts receivable database which forms part of the company's accounting system. The cost of the software is, in this case, but a fraction of the true replacement value of the database which will include, among other things: data entry time to restore the file (assuming hard copy is available), possible lost revenue on delinquent accounts, and a myriad of effects on other connected systems. Software assets such as the one detailed above are specially handled by a separate process in a TRA called a "Statement of Sensitivity".

SoS

Statements of Sensitivity (SoS) are concerned with three key aspects of assets in question: Confidentiality- the degree to which disclosure of information found within the concerned system could negatively affect business operations in present or future. Data must be classified according to a scale; the following being utilized by government bodies and several large business concerns:

• UNCLASSIFIED or UNDESIGNATED- basic information
• DESIGNATED- personal information, fairly sensitive business information
• CONFIDENTIAL- disclosure may have damaging potential
• SECRET- compromise will likely have serious repercussions
• TOP SECRET- disclosure is likely to eventuate grave injury
• Integrity- the degree to which the integrity of the data in question affects the company's ability to effectively conduct business. Obviously financial information has an extremely high integrity requirement while the corporate social calendar database would not. Asset integrity requirement studies focus on the impact of both inaccurate and incomplete data.
• Availability- An asset's minimum availability (continuity of service) requirement is determined by TRA practitioner and user community consensus on maximum allowable downtime and documented in the Statement of Sensitivity. Care must be taken to ensure all connected systems are taken into account as they often affect the availability of the core component being studied.

Threat Assessment

As we have seen, there are a variety of threats which the TRA practitioner must determine the likelihood of affecting the system in question. He must then arrange them according to the five classes outlined in last month's article and determine the consequences on business continuance should the threat succeed. Consequences are then documented in terms of impact and exposure. The impact of a successful threat is codified into three categories: exceptionally grave, serious and less serious; while the likelihood of threat materialization is classified low, medium and high. The two factors are combined to determine an exposure rating based on a system such as the following chart:

		IMPACT (INJURY)
		Exceptionally Grave	Serious	Less Serious
LIKELIHOOD	High	9	8	5
	Medium	7	6	3
	Low	4	2	1

Risk Assessment

Risk assessment as defined by the RCMP is "an evaluation of the chance of vulnerabilities being exploited, based on the effectiveness of existing or proposed safeguards". Obviously, once you have defined the threats and threat impacts that face your systems, the next logical step is to determine what existing safeguards may be able to significantly reduce or counter the risk. Risk is then rated similarly to the table above and recommendations are made depending on the state of the system's security posture; defined as follows:

1. Equilibrium: Safeguards are well matched to perceived threats
2. Vulnerable: Safeguards are not sufficient to ward off threats
3. Excessive: Safeguards outweigh perceived threats.

This security posture will also act as a guideline for future IT expenditures; as it will document the history of your organization's commitment to threat aversion.

Finally

Now that you have all the key components, you are ready to start your Disaster Recovery Plan. Bear in mind that a Threat and Risk Assessment is a living document which must be updated as your environment evolves. Implementation of Disaster Recovery Plans based on outdated TRA's can be almost as disastrous as the Disaster event itself! We will go into detail about the final phase next month with an in depth interview with Dr. Jeff Williams, a recognized world leader in the field. Until then... be safe!

Originally published in Monitor Magazine, lanStuff column, October, 1997 by technology columnist, Ray Richards.

• Top
• Navigation
• Accessibility
• Colophon