Risk Analysis

As part of the planning process, the security architect will need to perform a risk analysis or assessment to determine the threats to which the organization is vulnerable and where mitigating investments should be applied to attempt to reduce the impact of a threat. To do this, security architects need to determine the risks faced by the organization. This includes risk from natural hazards, industry risks, and environmental risks.

The security architect needs to look at natural hazard risks based on the location of the organization; industry risks based on the organization’s type of business or mission; crime risks based on the geographic location(s) of the organization; human-made hazards such as transportation accidents based on proximity to highways, train lines, airports, etc.; proximity risks based on other industries near where the organization is located such as chemical plants, and natural gas storage facilities; and then recommend mitigating strategies to protect the business where appropriate. Once the risk analysis is completed, the security architect will need to document the findings. A sample risk model from the US National Institute of Standards and Technology (NIST) is below:³

Documentation of the risk analysis is a critical success factor with regards to risk mitigation. If the risk analysis is not clearly presented to the business, allowing for key decision makers to understand the risks that are likely to occur, and those that are not very likely to occur, then risk mitigation cannot take place. The output of the risk analysis will require the security architect to create a matrix to represent the risks found, and the likelihood of their occurrence. A sample risk analysis matrix can be seen in Figure 5.1.

The security architect will also need to create a description of the rankings used in the risk analysis matrix to help explain what each rating will mean. An example of a risk level explanation can be seen in Table 5.1

In addition, the security architect will also want to document any specific terms that are used to describe state or activity within the risk analysis being presented to the business. For instance, in the risk level explanation for the risk analysis matrix presented in Table 5.1, the terms Confidentiality, Integrity, and Availability are used with regard to “ loss “, but are not clearly defined for the reader. In order to ensure that there is no confusion on the part of anyone who would be examining the risk analysis documentation, the security architect would also want to provide a definition table of terms for the reader, as shown in Table 5.2

Finally, the security architect will also need to provide a risk level definition along with all other items already discussed in order to ensure that the business is able to clearly understand the magnitude of the risks being discussed, and the necessary level of response required to mitigate the risk, if it is deemed appropriate to do so. Table 5.3 illustrates what the risk level definition would look like.

There are many samples of risk analysis templates available for download through the World Wide Web. A quick search using Google will turn up hundreds of options for the security architect to access and examine as a starting point to creating their own. Microsoft, NIST, the Virginia Information Technologies Agency (VITA), the United Nations, the US Army Core of Engineers, and the governments of Australia, Japan, Germany, France, and the United Kingdom all have sample templates available to be downloaded.⁵

In addition to sample templates, there are a number of Frameworks and Relevant Standards that the security architect should become familiar with. While most of these are focused on Corporate Governance and financial controls, the security architect will still play a part in supporting these frameworks, and will have to build and maintain systems in accordance with their guidance if the industrial verticals that the architect works in are required to use them. These include the following:

1. The Criteria of Control (CoCo), a control framework issued by the Canadian Institute of Chartered Accountants (CICA) in 1995⁶.

2. KonTrag, (Gesetz zur Kontrolle und Transparenz im Unternehmensbereich - German Act on Control and Transparency in Business), which is a framework that promotes corporate governance in both the public and private sectors⁷.

3. Committee of Sponsoring Organizations (COSO) Enterprise Risk Management (ERM) Framework:2004, which consists of eight components designed to help organizations formally organize ERM responsibilities and activities, providing a comprehensive roadmap for establishing the critical processes needed for effective risk management⁸.

4. ISO 31000:2009, Risk Management – Principles and Guidelines, which provides principles, framework and a process for managing risk⁹.

5. ISO/IEC 31010:2009, Risk Management – Risk Assessment Techniques, which provides guidance on selection and application of systematic techniques for risk assessment¹⁰.

6. ISO Guide 73, Risk management – vocabulary, which provides basic vocabulary to develop common understanding on risk management concepts and terms among organizations and functions, and across different applications and types.¹¹

Data Stored in Electronic Form

Backup strategies for data used to restore technology are varied and are driven by the RTO and the RPO needed to support the business requirements. Some organizations tier data based on its importance to the business and frequency of use. The more time-sensitive data is replicated off-site either synchronously or asynchronously to ensure its availability and its currency. Other data is backed up to tape and sent off-site once or a day or more frequently if required.

If the data needed to rebuild the technology environment is stored somewhere else besides the alternate site, then the time it takes to pack and transport that data must be included in the RTO. Factors such as how the data is stored, how far away it is, and how it will be delivered to the recovery facility will determine how much the recovery time could be increased. Delivery of off-site data to the recovery facility could delay the recovery by hours or even days. To reduce the recovery time, the data that will be used to recover any mission critical systems and applications should be stored in the recovery site whenever possible.

It is vital that the data that is stored off-site include not only the application data but also the application source code, hardware and software images for the servers and end user desktops, utility software, license keys, etc. Application data alone will not be sufficient to rebuild an application.

Remote Replication and Off-Site Journaling

Remote replication involves moving data over a network to secondary storage devices in another location. It can be an expensive solution to implement, but it will meet the needs of an application RPO that is immediate or near immediate. It can be done either synchronously or asynchronously.

Synchronous replication is when the data is written to the production environment disk and to the remote disk at the same time. Until both “writes” occur, the next process cannot begin. There are distance limitations on performing synchronous remote replication as well as network bandwidth requirements that can be extremely demanding. Synchronous replication has the potential to impact production, but is the best solution when time to recovery and data loss matter. This type of replication is commonly deployed in dual data center environments where applications are load-balanced between the two or more sites but can be used for other strategies when the currency of the data, not the actual time of the recovery is key.

Asynchronous replication occurs when the data is written to the production environment and then is queued to write to the backup environment at scheduled intervals depending on the RPO for the data. This can occur several times a day, several times an hour, or several times a minute, depending again on the need for data currency³⁵.

Asynchronous data replication’s advantage is that it does not impact production performance as it takes place offline from the production environment and provides long-distance, remote data replication while still providing disaster recovery data protection.

Remote replication does not eliminate the need for point-in-time copies of the data. If data in the production environment becomes corrupt, the replicated data will also be corrupt. A point-in-time copy of the data is still required for restoration from this type of event³⁶.

Backup Strategies

Most companies, no matter what strategy they employ for storing data off-site, start by performing full backups of all their data followed by periodic incremental backups. Incremental backups take copies of only the files that are new or have changed since the last full or incremental backup was taken, and then set the archive bit to “0.” The other common option is to take a differential backup. Differential backups copy only the files that are new or have changed since the last full backup and do not change the archive bit value.

If an organization wants the backup and recovery strategy to be as simple as possible, then they should only use full backups. They take more time and hard drive space to perform, but they are the most efficient in recovery. If that option is not viable, a differential backup can be restored in just two steps. The full backup of the data is restored first, then the differential backup on top of it. Remember, the differential backs up every piece of data in file that has changed since the last full backup was taken.

An incremental backup takes the most time to restore because the system must lay down the full backup first and then every incremental backup taken since the last full backup. If daily incremental backups are performed, along with only monthly full backups, and recovery is attempted on the 26th day of the month, the organization will have to perform the full backup restore first and then 26 incremental backups must be laid on top in the same order that they were taken in. This example illustrates how the backup method chosen could have a significant impact on the recovery timeline.

There are several other backup methods that the security architect should consider when planning for data integrity, confidentiality, and availability within the context of a recovery strategy.

Synthetic Full Backup

A synthetic full backup is a variation of an incremental backup. Like any other incremental backup, the actual backup process involves taking a full backup, followed by a series of incremental backups. But synthetic backups take things one step further.

What makes a synthetic backup different from an incremental backup is that the backup server actually produces full backups. It does this by combining the existing full backup with the data from the incremental backups. The end result is a full backup that is indistinguishable from a full backup that has been created in the traditional way.

The primary advantage to synthetic full backups is greatly reduced restore times. Restoring a synthetic full backup does not require the backup operator to restore multiple tape or disk sets as an incremental backup does. Synthetic full backups provide all of the advantages of a true full backup, but offer the decreased backup times and decreased bandwidth usage of an incremental backup.

Incremental-Forever Backup

Incremental-forever backups are often used by disk-to-disk-to-tape backup systems. The basic idea is that like an incremental backup, the incremental-forever backup begins by taking a full backup of the data set. After that point, only incremental backups are taken.

What makes an incremental-forever backup different from a normal incremental backup is the availability of data. Restoring an incremental backup requires the tape or disk set containing the full backup, and every subsequent backup set in order up to the point in time that you want to restore to. While this is also true for an incremental-forever backup, the backup server typically stores all of the backup sets on either a large disk array or in a tape library. It automates the restoration process so that you do not have to figure out which tape sets need to be restored. In essence, the process of restoring the incremental data becomes completely transparent and mimics the process of restoring a full backup.

Mirror Backup

A mirror backup is a straight copy of the selected folders and files at a given instant in time. That is, the destination becomes a “mirror” of the source. Any mirror operation after the first will only copy new and modified files, making the operation faster. And deleted files will be removed from the set as well. Some key disadvantages to be aware of with Mirror Backups are that they consume more space than other backup types will, they are not able to be password protected to ensure confidentiality of the data they contain, and they are not capable of tracking different versions of the files that they contain.

Disk Imaging

This type of backup is often described as a “bare metal backup” because it backs up physical disks at the volume level. In other words, a true disk image is an exact copy of an entire physical disk or disk partition.

In its simplest form a disk imaging program creates a bit identical copy of a drive which is made by dumping raw data byte by byte, sector by sector from the source disk into an image file. Disk imaging programs have the ability to interpret the data being copied and remove or compress the empty blocks on a disk which leads to much smaller image files. The majority of programs also create compressed image formats that can be mounted and explored making it possible to retrieve individual files. In addition, the creation of successive incremental or differential backups is often supported, which further reduces the demands on storage. Other techniques have been developed that allow file-level operations such as file type filtering, the ability to exclude non-essential files from the image, such as pagefile.sys, and the ability to image a drive or partition while it is currently in use.

Advantages of Image Backup Systems include allowing for rapid full system restores with the operating system across similar or different hardware platforms. Speed and simplicity is unsurpassed when working with large numbers of files. Many modern image formats can be mounted and used like any other drive making accessing backed up files very user friendly.

File Synchronization

File Synchronization is a specialized adaptation of file based backup technologies. The primary design of synchronization programs are to replicate or mirror working files in two or more locations, allowing for both sets of files to be available and used in real time. The main difference between file synchronization and backup solutions is that a backup will copy files in one direction, while synchronization copies files (or changes) in two directions. With backups there is a “source” and a “destination.” With synchronization there are two sources. For example, when a group of files are set to be synchronized between two systems, files which are changed on either system will be reflected on the other.

Synchronization that replicates changes in both locations is called two-way synchronization. Synchronization that only replicates the changes from one location to the second is called one-way synchronization. One-way synchronization differs from traditional backups when the propagation of deletions or renames is performed, because backups do not generally delete files, and a renamed file is usually copied again.

One-way synchronization can be used as a way to both backup and synchronize computers. A one-way synchronization may be made to a portable hard drive. The hard drive may then be used as a source to sync with another computer and new files will be transferred from the portable drive to the pc. New files on the second pc may also be backed up to the portable drive and then can be transferred to the first pc. Thus both computers will remain in sync, and the data on the drive will remain as a backup of both systems. Similar setups are often used by online storage services which may be seen as being both an online backup as well as an online synchronization solution.

Some key advantages of file synchronization systems are that files synchronized to online sources can often be easily accessed from any computer or mobile device such as a smart phone or tablet, and some programs combine real-time synchronization with a versioning system that allows for easy collaboration between individuals working on the same file, as well as usually providing for difference comparisons and merging capabilities.

Managed Backup Services

A remote, online, or managed backup service, commonly referred to as a “cloud backup” solution, is a service that provides users with a system for the backup and storage of computer files. Online backup providers are companies that provide this type of service to end users (or clients). Such backup services are considered a form of cloud computing. Online backup systems are built around a client software program that runs on a schedule, typically once a day, and usually at night while computers are not in use. This program collects, compresses, encrypts, and transfers the data to the remote backup service provider’s servers or off-site hardware.

These solutions are service-based, meaning that in order to provide for the assurance, guarantee, or validation that what was backed up is recoverable whenever it is required, data stored in the service provider’s cloud must undergo regular integrity validation to ensure its recoverability. Cloud services need to provide for granularity when it comes to Recovery Time Objectives (RTO’s), as one size does not fit all either for the customers or the applications within a customer’s environment. The customer should never have to manage the back end storage repositories in order to back up and recover data, this should be the responsibility of the service provider. Cloud backup needs to be an active process where data is collected from systems that store the original copy. This means that cloud backup will not require data to be copied into a specific appliance from where data is collected before being transmitted to and stored in the service provider’s data center(s).

Cloud backup solutions offer ubiquitous access, meaning that they utilize standard networking protocols, primarily, but not exclusively IP based, to transfer data between the customer and the service provider over secured connections. Vaults or repositories need to be always available to restore data to any location connected to the service provider’s cloud via private or public networks, as needed during a Disaster Recovery event or test.

Scalability and elasticity enable flexible allocation of storage capacity to customers without limit. Storage is allocated on demand and also de-allocated when customers delete backup sets as they age. The service provider can then release and reallocate that same capacity to a different customer in an automated fashion.

Metering by use allows the security architect to align the value of data with the cost of protecting it. It is procured on a per-gigabyte per month basis. Prices tend to vary based on the age of data, type of data (email, databases, files etc.), volume, number of backup copies and RTOs.

Data mobility/portability prevents service provider lock-in and allows customers to move their data from one service provider to another, or entirely back into a dedicated Private Cloud or a Hybrid Cloud, as needed. Security in the cloud is a critical factor for the security architect to consider. One customer can never have access to another’s data. Additionally, even service providers must not be able to access their customer’s data without the customer’s permission. The security architect needs to ensure that security issues are addressed up front with the vendor in order to make sure that all risks and threats are identified and documented to the fullest extent possible.

Some advantages of managed backup services over traditional backup methods are that they are storing the backups of system data in a different location from the original data. Traditional backup requires manually taking the backup media offsite. Remote backup does not require user intervention. The user does not have to change tapes, label CDs or perform other manual steps to ensure the success of the backup. Remote backup services can be set up to work continuously, backing up files as they are changed.

Some disadvantages of managed backup services over traditional backup methods are that depending on the available network bandwidth, the restoration of data can be slow. It is possible that a remote backup service provider could go out of business or be purchased, which may affect the accessibility of one’s data or the cost to continue using the service. While the data is encrypted during transit through the cloud, it is impossible for the customer to know exactly where their data is transiting, and what country, or countries, it may pass through between the customer’s network and the service provider’s end point for data storage. As a result, the confidentiality and integrity of the customer’s data could be compromised without their knowledge. Further, privacy laws and data regulatory requirements differ by country, and depending on those laws, the customers data could potentially be exposed to regulatory compliance requirements that the customer is not prepared to comply with for a variety of reasons. The security architect must take these issues into account as they examine the various managed backup services available as part of their BCP/DRP architecture.

The RTO for a business process or for an application will determine the recovery strategy for the process or application. The more time that can elapse before the recovery needs to occur, the more recovery options are available. The more time sensitive an application or function is, the fewer options the security architect will have in selecting a recovery strategy. Also, the plan will be more detailed and require more testing and training to successfully implement.

Cost–Benefit Analysis

Each of the foregoing strategies can be considered for the business and technology recovery. Those that are recommended need to have a Cost–Benefit Analysis (CBA) performed to determine if the costs of the strategy being recommended fits within the amount of risk or business loss the business is trying to avoid. The company would not spend $1,000,000 a year on a recovery strategy to protect $100,000 of profit. Every business does not need a dual data center recovery strategy. The strategy selected must fit the business need. The following image from NIST helps visualize this tradeoff:³⁷

The cost of implementing the recovery strategy recommended needs to include the initial costs associated with building out the strategy as well as ongoing costs to maintain the recovery solution, and where applicable, the cost of periodic testing of the solution to ensure it remains viable.

Implementing Recovery Strategies

Once the strategy has been agreed to and funded, the next step is to implement the various strategies approved. This may involve negotiating with vendors to provide recovery services for business or technology, doing site surveys of existing sites to determine excess capacity, wiring conference rooms or cafeterias to support business functions, buying recovery technology, installing remote replication software, installing networks for voice and data recovery, assigning alternate site seats to the various business areas, and the like.

The implementation phase is a project unto itself, perhaps multiple projects, depending on the complexity of the environment and the recovery strategies selected.

Documenting the Plan

Once recovery strategies have been developed and implemented for each area, the next step is to document the plan itself. The plan includes plan activation procedures, the recovery strategies to be used, how recovery efforts will be managed, how human resource issues will be handled, how recovery costs will be documented and paid for, how recovery communications to internal and external stakeholders will be handled, and detailed action plans for each team and each team member. The plan then needs to be distributed to everyone who has a role.

The documentation for recovery of the technology environment needs to be detailed enough that a person with a similar skill set who has never executed the procedures before could use them to perform the recovery. Documentation tends to be a task that no one really likes to do; however, there is no guarantee that the people who perform this function in the production environment or the person who restored the infrastructure and application at the last test is going to be available at the time of the disaster. In addition, disasters tend to be chaotic times where many things are happening at once. Without the proper documentation, a practiced recovery strategy can fall apart and add to the chaos. Restoring an application can be challenging and restoring an entire data center just destroyed by a tornado can be overwhelming, if not impossible, without good documentation.

The documentation needs to be stored at the recovery facility, and every time the recovery is tested, the documentation should be used by the recovery participants and updated as needed. Once the level of confidence in the documentation is high, the security architect should have someone who has never performed the procedure attempt it with an expert looking over their shoulder. It may slightly delay the recovery time at that particular test, but once complete, confidence in the documentation will be strong.

The Human Factor

One common factor left out of many plans is human resource issues. Disasters are human events, and it is important that the plan document the responsibility of the firm to the employees participating in the recovery. Companies need to recognize that to respond to the company’s needs in a disaster situation, it must also recognize the hardships placed on the families of its response teams. To be able to give the best to the company at the time when it is needed most, employees need to have a level of comfort that their family members are safe and the employee’s absence during the recovery effort will not place undue hardship on them.

Logistics

The plan needs to document the logistics of the recovery, not just the technical documentation for recovery of the hardware and applications. The plan needs to contain answers to the following questions:

1. How the disaster will be declared and who has the authority to declare it?

2. How recovery team members will be contacted and who will contact them?

3. How recovery team members are to travel to the alternate site, and who will make any required reservations and pay for those costs?

4. Where documentation is stored and how to get it?

5. How off-site backups will be retrieved, who will do it, and how long it will take?

6. What are the address, phone number, and directions to the alternate site?

7. How necessary supplies will be provided and how more can be requested?

8. What is the command center location and phone number?

9. How problems will be reported and managed?

Plan Maintenance Strategies

As with any documentation, version control is important, particularly with detailed technical procedures. The use of version control numbers on the plan helps to ensure that everyone is using the current version of the plan documentation. The plan needs to be published to everyone who has a role and also needs to be stored in a secure off-site location that not only survives the disaster but is accessible immediately following it.

It is important that the plan be kept up to date as the business and technology environments of your company continue to change and adapt. Tying plan updates to your change management process is critical to keeping pace with significant changes in technology. The BCP must be reviewed and updated at least annually, and more often if significant business changes occur. Plan updates also frequently occur following tests of the plan, if issues or action items from the test require plan documentation changes.

Once the plan has been completed and the recovery strategies are fully implemented, it is important to test all parts of the plan to validate that it would work in a real event. The purpose of testing is to validate the readiness to recover from a real event. If we knew that it all worked, we would not need to test it in the first place. Test to find out what does not work, so that it can be fixed before it happens for real. No test is a failure as long as it provides opportunities to better the recovery process, so that if it happened for real, the organization is more likely to recover.

The first rule of conducting tests of the recovery plans is that no matter what type of test you are conducting, it is important to protect the production environment.

There are many different types of exercises that the security architect can conduct. Some will take minutes, and others hours or days. The amount of exercise planning needed is entirely dependent on the type of exercise, length of the exercise, and the scope of the exercise planned to be conducted. The most common types of exercises for technology recovery are walkthrough exercises, simulated or actual exercises, and compact exercises.

In a walkthrough or tabletop exercise, the team that would need to execute the plan holds a meeting to review the plan. When the organization has a new plan, the best type of tabletop exercise to do is a walkthrough of the actual plan document with everyone who has a role in the plan. Even the planning team is unlikely to read the entire document, and walking through the plan helps to ensure that everyone knows the whole story and everyone’s role. Walking through the plan with the team will help identify gaps in the plan so that they can be addressed.

Once the security architect has conducted that type of walkthrough, the scenario-based tabletop exercises can begin. In these exercises, the security architect will gather the team in a meeting and pretend that something has happened, and the team members are supposed to respond as if it is a real event. The security architect could pretend that there is a power outage, and, based on what is backed up by alternate power sources such as generators and what is not, the team would discuss how the technology or business would be impacted and how they would exercise the portions of the plan to address that scenario.

Tabletop exercises are used to validate the plan within an actual scenario without having to actually execute the recovery procedures. The security architect will “talk through” with the team what they would do; they will not actually do it. These types of exercises are especially helpful in working through the decision processes that will have to be tackled by the leadership team when faced with an event and by other teams to talk through recovery options based on the scenario being presented for the exercise.

A simulated or actual exercise tests the actual recovery in the alternate site. The difference between a simulated and an actual exercise is that a simulated exercise operates completely independently of the production environment, whereas in an actual exercise the production environment is “moved” to the alternate site as is done with a dual data center strategy.

The purpose of this type of exercise is to validate alternate site readiness. The security architect should run this exercise as closely as possible to how it would happen if it were happening for real. Clearly, because exercises are planned events, the security architect will have an opportunity to reduce the actual timeline by pre-staging certain things that they could not do if this were an unplanned event, such as pulling backup tapes from off-site storage and having it delivered to the alternate site for use on the day of the exercise. What the security architect should not do as part of the planning is plan for success. Remember, the reason to test is to find out what does not work so that it can be fixed before it happens for real.

The final exercise is a compact exercise. This is where the security architect will begin with a call to the recovery team, assuming a scenario, and have them respond as if this were a real event and continue right through an actual exercise in the alternate site. These are sometimes done as surprise exercises, with very few people knowing in advance when they are going to happen.

After every exercise the security architect conducts, the exercise results need to be published and action items developed to address the issues uncovered by the exercise. Action items should be tracked until they have been resolved and, where appropriate, the plan updated. It is very unfortunate when an organization faces the same issue in subsequent tests simply because someone did not update the plan.

I. Information Gathering

Step One - Organize the Project:

   Identify and convene planning team and sub-teams as appropriate.

   At the business and/or business unit level set:

   Scope - the area covered by the disaster recovery plan, and objectives - what is being worked toward and the course of action that the business intends to follow.

   Assumptions - what is being taken for granted or accepted as true without proof.

   Set project timetable.

   Draft project plan, including assignment of task responsibilities.

   Obtain senior management approval of scope, assumptions and project plan.

Forms that may be useful in organizing Step One:

1. A Project Plan template.

Step Two – Conduct Business Impact Analysis (BIA)

This step would normally be performed by the security architect in conjunction with business unit managers. In order to complete the business impact analysis, perform the following steps:

   Identify functions, processes and systems.

   Interview information systems support personnel.

   Interview business unit personnel.

   Analyze results to determine critical systems, applications and business processes.

   Prepare impact analysis of interruption on critical systems.

Forms that may be useful in organizing Step Two:

1. A Business Impact Analysis template.

2. A Critical System Ranking form.

Step Three – Conduct Risk Assessment:

The planning team will want to consult with technical and security personnel as appropriate to complete this step. The risk assessment will assist in determining the probability of a critical system becoming severely disrupted and documenting the acceptability of these risks to the business.

For each critical system, application and process as identified in Step 2 using the Critical System Ranking form:

   Review physical security.

   Review backup systems.

   Review data security.

   Review policies on personnel termination and transfer.

   Identify systems supporting mission critical functions.

   Identify vulnerabilities.

   Assess probability of system failure or disruption.

   Prepare risk and security analysis.

Forms that may be useful in organizing Step Three:

1. Security Documentation template.

2. Vulnerability Assessment template.

Step Four - Develop Strategic Outline for Recovery:

Assemble groups as Appropriate for:

   Hardware and operating systems.

   Communications.

   Applications.

   Facilities.

* Any / all other critical functions and business processes as identified in the Business Impact Analysis.

For each system/process above quantify the following processing requirements:

   Light, normal and heavy processing days.

   Transaction volumes.

   Dollar volume (if any)

   Estimated processing time.

   Allowable delay (days, hours, minutes, etc.)

Detail all the steps in the workflow for each critical business function (e.g., for payroll processing each step that must be complete and the order in which to complete them.):

   Identify systems and applications.

   Component name and technical id (if any)

   Type (online, batch process, script)

   Frequency.

   Run time.

   Allowable delay (days, hours, minutes, etc.)

   Identify vital records (e.g., procedures, Intellectual Property, etc.)

   Name and description.

   Type (e.g., backup, original, master, history, etc.)

   Where they are stored.

   Source of item or record.

Can the record be easily replaced from another source (e.g., reference materials):

   Backup type(s)

   Backup generation frequency.

   Number of backup generations available onsite.

   Number of backup generations available off-site.

   Location of backups.

   Media type.

   Retention period.

   Rotation cycle.

Who is Authorized to Retrieve the Backups?

Identify what would be the minimum requirements/replacement needs to perform the critical function if a severe disruption occurred.

   Type (e.g. server hardware, software, etc.)

   Item name and description.

   Quantity required.

   Location of inventory, alternative, or offsite storage.

   Vendor/supplier.

1. Identify if alternate methods of processing either exist or could be developed, quantifying where possible, impact on processing (Include manual processes.)

2. Identify person(s) who supports the system or application.

3. Identify primary person to contact if system or application cannot function as normal.

4. Identify secondary person to contact if system or application cannot function as normal.

5. Identify all vendors associated with the system or application.

6. Document business unit strategy during recovery (conceptually how will the business unit function?)

7. Quantify resources required for recovery, by time frame (e.g., 1 pc per day, 3 people per hour, etc.)

Develop and document recovery strategy, including:

   Priorities for recovering system/function components.

   Recovery schedule.

Forms that may be useful in organizing Step Four:

1. A Group Assignments spreadsheet.

2. A Critical System Processing Requirements for Recovery spreadsheet.

Step Five – Review Onsite and Offsite Backup and Recovery Procedures

   Review current records (System Instructions, documented processes, etc.) requiring protection.

   Review current offsite storage facility or arrange for one.

   Review backup and offsite storage policy or create one.

Step Six – Select Alternate Facility:

Alternate Site: A location, other than the normal facility, used to process data and/or conduct critical business functions in the event of a disaster.

Determine Resource Requirements:

   Assess platform uniqueness of business systems (e.g., Apple, Oracle database, AIX, etc.)

   Identify alternative facilities.

   Review cost/benefit.

   Evaluate and make recommendation.

   Seek approval.

   Make selection.

II. Plan Development and Testing

Step Seven – Develop Recovery Plan:

The steps for developing the Recovery Plan are listed below in outline form to demonstrate how a security architect may choose to organize their Disaster Recovery Plan.

Objective:

The objective may have been documented in the Information Gathering Step 1 Plan Organization.

Plan Assumptions:

   All assumptions that impact the plan will need to be listed.

Criteria for Invoking the Plan:

   All criteria that must be met or satisfied in order to all for the invocation of the plan need to be listed.

Document emergency response procedures to occur during and after an emergency (i.e. ensure evacuation of all individuals, call the fire department, after the emergency check the building before allowing individuals to return)

   Document procedures for assessment and declaring a state of emergency.

   Document notification procedures for alerting managers.

   Document notification procedures for alerting vendors.

   Document notification procedures for alerting staff and notifying of alternate work procedures or locations.

Roles Responsibilities and Authority:

   Identify personnel.

   Recovery team description and charge.

   Recovery team staffing.

Transportation schedules for media and teams

Procedures for operating in contingency mode:

   Process descriptions.

   Minimum processing requirements.

   Determine categories for vital records.

   Identify location of vital records.

   Identify forms requirements.

   Document critical forms.

   Establish equipment descriptions.

   Document equipment - in the recovery site.

   Document equipment - in the business.

Software Descriptions:

   Software used in recovery

   Software used in production

Produce logical drawings of communication and data networks in the business.

Produce logical drawings of communication and data networks during recovery.

Vendor List:

   Review vendor restrictions

   Miscellaneous inventory

   Communication needs - production

   Communication needs - in the recovery site

   Resource plan for operating in contingency mode

   Criteria for returning to normal operating mode

   Procedures for returning to normal operating mode

   Procedures for recovering lost or damaged data

Testing and Training:

   Document Testing Dates.

   Complete disaster/disruption scenarios.

   Develop action plans for each scenario.

   Sample Testing Diagram.

Plan Maintenance:

   Document Maintenance Review Schedule (yearly, quarterly, etc.)

   Maintenance Review action plans.

   Maintenance Review recovery teams.

   Maintenance Review team activities.

   Maintenance Review/revise tasks.

   Maintenance Review/revise documentation.

Appendices for Inclusion:

   Inventory and report forms.

   Maintenance forms.

   Hardware lists and serial numbers.

   Software lists and license numbers.

   Contact list for vendors.

   Contact list for staff with home and work numbers.

   Contact list for other interfacing departments or business units.

   Network schematic diagrams.

   Equipment room floor grid diagrams.

   Contract and maintenance agreements.

   Special operating instructions for sensitive equipment.

   Cellular telephone inventory and agreements.

Step Eight - Test the Plan:

   Develop test strategy.

   Develop test plans.

   Conduct tests.

   Modify the plan as necessary.

III. Ongoing Maintenance

Step Nine - Maintain the Plan:

The security architect will be responsible for overseeing this.

   Review changes in the environment, technology, and procedures.

   Develop maintenance triggers and procedures.

   Submit changes for systems development procedures.

   Modify change management procedures.

   Produce plan updates and distribute.

Step Ten – Perform Periodic Audit:

Establish periodic review and update procedures