BS-CIS & BS-IT Capstone - Disaster Recovery Database

Running head: DISASTER RECOVERY DATABASE 1

WESTERN GOVERNORS UNIVERSITY

Submittal Cover Sheet

Date: 4/10/2012

Student Name:

Student ID Number:

Student Degree Program: Information Security

Student Email:

Four Digit Assessment/Project Code: CAPU

Mentor Name:

For Revisions Only Indicate Previous Grader:

Submissions received with an altered, incomplete or

missing cover sheet will be returned for resubmission.

Submit to:Western Governors University

Attn.: Assessment Delivery Department 4001 South 700 East, Suite 700

Salt Lake City, Utah 84107-2533

[email protected]

mailto:[email protected]

DISASTER RECOVERY DATABASE 2

Capstone Project Cover Sheet

Capstone Project Title: Disaster Recovery Database

Student Name:

Degree Program: Information Security

Mentor Name:

Signature Block

Student’s Signature

Mentor’s Signature


Table of Contents

Capstone Report Summary 4

Goals and Objectives 10

Project Timeline 13

Project Development 15

References 17

Appendix 1: Competency Matrix 18

Appendix 2: Project Plan and Timelines 19

Appendix 3: ER Diagram 20


Capstone Report Summary

In light of the many disasters that we have seen in recent years, more and more companies have

realized that they need to update their disaster recovery capabilities; however, with the economy still in

turmoil many of them are not willing to spend thousands of dollars for a proper disaster management

information system. This project answers this dilemma by providing a lightweight/portable disaster

recovery database that is relatively easy to create, and easy to access from many locations in the event

of a catastrophe.

The disaster recovery database I created is extremely useful for UT-Health, the institution where I work.

It is able to hold enough information to enable this or any institution to restore its IT operations as

quickly as possible and allows patients, students and customers everywhere to receive professional and

timely service thanks to this quick recovery.

UT-Health does not have any sort of disaster management information system, but they do have a

Disaster Recovery Analyst on staff who, on a yearly basis, performs a business impact analysis of the

company’s mission critical systems. He believes that this disaster recovery database will certainly

expedite his workflow and just like other Disaster Recovery Analysts, he did not have thousands of

dollars to spend on an expensive system.

The database that I designed for UT Health is small and easily replicated to other locations via scripts, it

is also backed up to the cloud with a solution called “Carbonite.” All of this redundancy makes the

database accessible in case of a disaster without the expense of dedicated servers running costly

clustering hardware and software.

This disaster recovery database has the capability to quickly display application details and inventory

information by searching for either the server name or the application name as well as showing all the

assigned systems for a specific contact. One drawback of regular inventory databases is that they


usually provide hardware information, limited information about application dependencies and no

information or relation to their emergency contacts. This database on the other hand, is able to run a

variety of reports such as a criticality lists so that institutions can rebuild the most critical systems first in

the event of an outage, and an emergency contacts list so that they can notify all the necessary

personnel in a timely manner.

Disaster recovery is an essential component of the Information Security CIA Triad (Confidentiality,

Integrity, and Availability); however, it is often overlooked and underfunded as companies spend most

of their time implementing other security solutions such as antivirus, firewalls and intrusion prevention

systems to deal with day to day threats. It will be just a matter of time before the next catastrophe hits

and this database is a great tool to leverage any institution's Disaster Recovery Plan.

This database is not just available at all times; it is easy to update, and it contains the most relevant

information needed to bring the company’s mission critical systems back to life. As we know, the speed

with which an institution can recover depends on its ability to find the right information quickly and on

its capability to maintain that information available under all circumstances. When a disaster strikes,

the chaos that ensues complicates even the best-kept disaster recovery plans; information and people

that were easily accessible at the office become difficult to locate.

To meet the objectives set for this project I originally as asked one of our system administrators to price

out a dedicated system that could meet our high availability requirements and the system he

recommended came out as follows:

Servers - 2 x HP ProLiant DL360 G7 - Xeon E5606 2.13 GHz

Hard Drives – 4 x HP Dual Port Enterprise - hard drive - 146 GB - SAS-2

Memory – 4GB

Network – ES1000 Gigabit Ethernet

Operating System – Windows Server 2008 SP2 64 bit


OS Client Access Licenses of Windows Server 2008

Database Software – Microsoft SQL Server 2008

The two servers would have been configured with redundant hardware such as power supplies and

network interface cards and one would be located at our main datacenter while the other one stayed at

our co-location. In addition, Microsoft SQL server would have been configured as a geo-cluster to

provide disaster recovery and high availability capabilities, all at a cost of over $10,000. The deployment

of this system was going to require the assistance of a database administrator for the initial setup, as

well as for any updates that were needed in the future. This did not include the cost of maintenance,

monitoring, backups and cooling. In the end, this solution consumed many resources and it wasted

overall capacity as the disaster recovery database is small.

Another possibility for UT Health was to create the database on a shared database server to save

money; however, after looking carefully at this implementation we realized it would not be feasible.

First of all the institution does not have a shared database geo-cluster that we could use for this project,

the only database of this kind was the large Electronic Medical Record database and our current policy

dictates that those databases cannot be shared with other systems as they contain confidential patient

information. Second, even if they had a geo-cluster available they would still need a programmer to

create a separate front end to easily interact with the database, and a Database Administrator to make

changes to the system.

For my third option I reviewed the Sustainable Planner application which is offered by a company called

Virtual Corporation. The system does document management for over 300 document types, everything

from Policy Insurance to Risk Assessments and runs on a Windows Server with IIS and SQL Server or

Oracle Database Systems. Sustainable Planner or SP can import data from multiple sources including

SQL ODBC connections and Excel spreadsheets and it can do limited integration with email and

emergency notification systems. (Sustainable Planner, 2012).


Sustainable Planner was built to help Business Owners build and maintain their own plans, and it

supports all disciplines of business continuity management not just disaster recovery as one can see on

the main portal below:

(Sustainable Planner, 2012).

SP has a large Library of immediately usable templates and once all the data has been entered using the

forms provided users can click on “Generate Report” and the system automatically generates a PDF

document. Below is a sample of a recovery plan automatically generated:



SP even presents the institution with a Maturity Model which makes it easier for the Disaster Recovery

Analyst to show results to management and request additional involvement.



Built on ASP .NET’s two-tiered architecture, Sustainable Planner’s document structure can be changed if

there are organizational changes or acquisitions, in addition, SP can use LDAP as an authentication

mechanism and it has its own built in help-system. (Sustainable Planner, 2012).

System owners can maintain their own documentation at any time and do not have to wait for the

analyst to enter all the data for them. In addition, their portal saves information on the screen every

fifteen minutes so that they do not lose information, below is a screenshot of what the system owner’s

portal looks like.


SP is a powerful system that would benefit companies of many sizes; however, with a cost of $29,900 for

up to 20 users, and a yearly maintenance fee of 15% of the cost, it is priced out of many companies’

reach. The reality is that most companies would rather spend that money on making their systems

redundant and creating high availability solutions than on a Document Management System. While

some corporations flush with cash can benefit tremendously from products such as SP, we believe that


colleges, small business and other government entities with limited funds are better off served by the

free solution that I created.

Our final option and chosen solution was Microsoft Access. This small, robust, yet easy to use database

does not require the assistance of a Database Administrator for configuration or updates. The initial size

of an Access database is about two megabytes, and since most of our data is text based and the number

of systems is relatively limited we do not see it become much larger than a couple of megabytes. The

small size allows us to easily replicate the database to our disaster recovery co-location with a script or

other free solutions and allows us to install Carbonite on the Disaster Recovery Analyst’s workstation to

keep an additional copy in the cloud. In this way, the database will be in three locations, a network share

that is backed up every night, our co-location and the cloud.

Since much of the functionality in Microsoft Access is wizard driven, it will be easy for the Disaster

Recovery Analyst and future administrators to make updates to the Database as they deem necessary.

Goals and Objectives

Recovery strategies are based upon priorities, timing and impact on the organization, so the first thing

that I needed to do before designing the new system was to review the company’s disaster recovery

plan and other relevant information. Once that was done, I got a general overview of how the company

manages its disaster recovery information, and I was able to determine what information needed to be

collected, how to organize it, and how to update it to make the disaster recovery database useful.

An important part of conducting this review included setting up several interviews with the Disaster

Recovery Analyst, system owners, and members of the server team and network teams to go over these

aforementioned documents.

After reviewing UT Health’s documentation, we decided the system we came up with should meet the

following goals and objectives:


1. The disaster recovery database needed to contain all the information necessary for the quick

coordination and recovery of the company’s mission critical systems. This goal was attained by

creating a database that centrally manages the following information:

o BIA - The company does a business impact analysis for its most critical systems and assigns

them a criticality level of one to four, with one being the most critical. The BIA used to be

saved to an Excel spreadsheet and printed copies were filed in a cabinet.

o Critical Systems List - A list of the most critical systems was kept on another spreadsheet

which was reviewed and updated every year.

o Contacts - There was a separate contact spreadsheet that was updated every year by

sending emails to the department managers and then it was merged and distributed to all

the managers within the company.

o Inventory - The server team maintained another spreadsheet with inventory information; it

contained hardware and location information, limited information about the application

that the servers support and no information or relation to their emergency contacts.

2. The database needed to be available in the event of a catastrophic disaster. There is nothing

worse than finding out that one cannot recover some systems because backups or recovery

components are lost or unusable; therefore, making sure that the system was available under

almost all possible conditions was one of the highest priorities for this project. To make sure

that the database was available in the worst possible scenarios, we replicated it every night to

our co-location, which is 30 miles away. Also, since the city of Houston is prone to hurricanes

that can affect a 100 mile radius we also made sure that the database was replicated to the

cloud giving it extremely high availability.

3. The Cost of implementing the system had to be less than $1,000. Most companies do not have

the resources to implement all the components needed for an efficient recovery of their


systems, they are over burdened with compliance and security issues and therefore the system

needed to be low cost and easily attainable. The new database met this goal as no additional

software or hardware had to be purchased.

4. The system had to be easy to update and expand for future use. In today’s fast changing world

many systems become obsolete even before they are fully implemented and integrated into a

company’s environment; therefore, this system needed to be easy to upgrade by anyone with

less than three years of IT experience. Microsoft Access’s wizard driven functionality was the

answer as it makes it very easy for even novices to make changes to the database for additional

functionality.

5. The system had to be able to create on-demand reports that are useful for the expedited

recovery of the company’s systems. Once again, the wizard driven interface makes it very easy

to create and update reports as needed. The following reports are included as they were part of

our initial deliverables:

o Emergency Contacts Report – This is used to provide to upper management the contact

numbers for all the personnel necessary in the event of a disaster.

o System Owner Report – This report is used to make sure that the information about the

systems is always up to date; it will be used to contact system owners on a yearly basis

to make sure that any changes or upgrades are represented on the database.

o System Priority Report: This report lists all systems by criticality level and is used to

determine the order in which the systems will be brought up in the event of an outage.

o Disaster Recovery Test History – The database records the time it takes to restore the

different systems during the recovery test and provides a basis for improvement for

future tests.


6. The Database needed to be able to quickly provide system information by looking up either a

server or the application itself, and to display the associated information of a particular contact.

This objective was met as the database interface allows the user to search for systems, contacts

or applications in a very efficient manner, providing quick access to inventory and disaster

recovery information.

Project Timeline

This project consisted of five major phases: project initiation, project planning, design specification,

build-out, and project closing. Most of the phases of the project went according to plan but some took a

little longer to complete.

The first phase was the project initiation, which began on April 1 and consisted of the following two

tasks:

1. Reviewing the project scope: This task only took a couple of hours and was completed on time

without incident.

2. Reviewing the Success criteria: I wanted to make sure that the criteria was broad enough to

make the product useful to any organization and yet focused enough to be achievable in a

month; this step was completed within the time allotted.

The project-planning phase consisted of three tasks and took a little bit longer than expected. The first

two tasks: creating the communications plan and determining the schedule went without a hitch;

however, when it came time to have the project kickoff meeting with upper management there was a

conflict of schedules that set me back two days. The conflict was eventually worked out and I was finally

able to meet with everyone on April 7. I utilized the two days before the meeting to think about the

database design so that time was not wasted.


The next phase was the design specification, which consisted of five tasks. Since we agreed that the

best solution would be use Microsoft Access for our database after the project kickoff meeting, I was

able to cut the time it would take to select the software, security, storage and access requirements

down to one day from four. This put our project back on track and I was able to get final sign-off from

the client on April 8, a full two days before schedule.

Finally, with all my goals and requirements defined I set out to complete phase four, or the actual build-

out of the disaster recovery database. This phase consisted of six tasks and was by far the most time

consuming phase of the project. I started working on the database design on April 9 and on April 10 I

created the following five tables: Contacts, SystemAvailability, Dependencies, Inventory, and

DR_Testing.

After the tables were created and some test data had been entered, I proceeded to create the table

relationships and on April 11 I created the following queries: Critical Systems, Contacts, Extended,

Environments and Systems and Critical Systems Technical Contacts.

I populated the tables with additional sample data and ran several queries to see if they provided the

desired outcome. After several days of changes and tweaks, I finally got results that we established for

our goals and objectives. This phase definitely took extra hours of working late into the night as

different versions of Microsoft Access have evolved and do things in different ways. I had to relearn

some of the things that I already knew how to do; nevertheless, by April 16, I had a fully functional

database that was able to process the company’s data in a meaningful way. I would spend the next four

days completing the last five tasks of the design phase, which were:

1. Configuring the backup solution: This task was met on time as I was able to create a script and

configure Carbonite in one day.


2. Testing and Quality Control: I spent two days performing testing and quality control, making

sure that the queries provided the desirable results, and making sure that the reports looked

presentable.

3. Project review: On April 19, one day behind schedule, I started to review the project to make

sure that all deliverables were accomplished; anything that was missing was completed and I

made sure that everything was working as expected.

4. Train upper management and review requirements, goals and objectives: The last two tasks

were completed on April 20. Upper management was presented with the disaster recovery

database and all capabilities were shown and demonstrated. Management seemed pleased

with the results and had suggestions about the future use of the database, the meeting lasted

two hours.

The last phase was the project closing this is where the final documentation for the project was created.

This involved creating an ER diagram of the database, a training video for new users and the system

documentation. Of all three final tasks, creating the video took the longest; for some reason I had a hard

time capturing the sound of my voice on several computers; I was finally able to create a video on a

laptop with a built in microphone.

The project was completed on time on April 23; however, many extra hours had to be put in to make

that possible. Without a written project plan I would have allowed the project to take a little longer so

the lesson I learned is to be more generous with the time allotment.

Project Development

This project started like many others with high expectations and the belief that it could be easily

accomplished, and while the expectations were met, I found out that it required a lot more work than

originally imagined.


The project went off to a good start, the meetings with the different teams and with upper management

went well and the goals and requirements initially set did not change through the life of the project;

what changed was the amount of research that I had to do regarding Disaster Recovery and the proper

ways to create a Microsoft Access database.

One of the surprises that I encountered while creating the database was that Microsoft Access 2007

does not work like previous version of Access; for example, the new version does not support user-level

security as the 2003 version does. What this means is that you can no longer control database access

with user names and passwords, so as a mitigating control we configured special NTFS permissions on

the network share so that only authorized personnel could access the database.

Another component that took a while to design were the forms used in the database; for the most part

the tables and queries were straight forward to build, but the forms with multiple drop-downs, buttons

and in-line queries took an inordinate amount of testing and re-design.

The final database received very good reviews from the Disaster Recovery Analyst and from upper

management. They were impressed by the range of capabilities that could be achieved by creating a

small database that could rival more expensive solutions.

The Disaster Recovery Database will save all the teams involved a good amount of time as it manages all

their records in a central location and is very easy to use. In the end though, only the proper

maintenance of the database will make sure that the institution can recover its critical systems in a

timely manner. Disaster Recovery is a process, not a product, and while this database will make it easier

to manage this process, it is up to the participating teams to make sure that the information on the

database is always up to date.

17

References

Recovery point objective. (2012, March 3). In Wikipedia. Retrieved March 6, 2012,

http://en.wikipedia.org/wiki/Recovery_point_objective

Recovery time objective. (2012, March 2). In Wikipedia. Retrieved March 5, 2012,

http://en.wikipedia.org/wiki/Recovery_time_objective

Sustainable Planner. (2012). Retrieved March 7, 2012 from

http://www.virtual-corp.net/html/sustainable_planner.html

What Is an IT Disaster Recovery Plan? (2009, October). In Search Disaster Recovery. April 10, 2012,

http://searchdisasterrecovery.techtarget.com/feature/IT-disaster-recovery-DR-plan-template-A-free-download-and-guide

http://searchdisasterrecovery.techtarget.com/feature/IT-disaster-recovery-DR-plan-template-A-free-download-and-guide%20

http://searchdisasterrecovery.techtarget.com/feature/IT-disaster-recovery-DR-plan-template-A-free-download-and-guide%20

http://www.virtual-corp.net/html/sustainable_planner.html

http://en.wikipedia.org/wiki/Recovery_time_objective

http://en.wikipedia.org/wiki/Recovery_point_objective

18

Appendix 1: Competency Matrix

Domain/Subdomain Competency Explanation

Database Databases Reviewed and selected appropriate database designs, and identified design solutions that address application needs.

Project Management Upper Division Project Management Skills

Implemented, controlled, and coordinated project according to project plans.

Security Business Continuity and Disaster Recovery

Identified Disaster Recovery needs and implements a Disaster Recovery and inventory Database.

Organizational Behavior and Leadership

Leadership and Professionalism Analyzed the culture within an organization to determine how to work effectively within that organization.

Quantitative Literacy Quantitative Literacy Constructed reasonable quantitative arguments for data analysis, solved problems using a variety of techniques.

Network Systems Administration and Management /Network Fundamentals

Provided analysis of High Availability Solutions and multiple ways of replication of information

Reasoning and Problem Solving

Upper division reasoning and problem solving skills

Analyzed current issues and needs and presented a logical solution to the different problems presented.

Natural Science Upper Division natural Science Skills

Analyzed the components, organization, interactions and process of ecosystems

Principles of Management Upper Division principles of Management Skills

Responded appropriately to diversity of issues in the workplace

Language and Communication

Upper Division Language and Communication Skills

Presented information using effective communication strategies

19

Appendix 2: Project Plan and Timelines

Project InitiationEstimated Duration

Estimated Begin Date

Estimated End Date

Review Project Scope 1 day 3/1/2012 3/1/2012Review Success Criteria 1 day 3/2/2012 3/2/2012Project PlanningDevelop Communication Plan 1 day 3/3/2012 3/3/2012Determine Schedule 1 day 3/4/2012 3/4/2012Project Kickoff Meeting with Upper Management 1 day 3/5/2012 3/5/2012Design SpecificationsSoftware Requirements 1 day 3/6/2012 3/6/2012Security Requirements 1 day 3/7/2012 3/7/2012Storage Requirements 1 day 3/8/2012 3/8/2012Access Requirements 1 day 3/9/2012 3/9/2012Obtain Project Start sign-off from client 1 day 3/10/2012 3/10/2012Build OutDesign Database 5 days 3/11/2012 3/15/2012Configure Backup Solution 1 day 3/16/2012 3/16/2012Testing and Quality Control 1 day 3/17/2012 3/17/2012Project Review 1 day 3/18/2012 3/18/2012Train Upper Management and Staff 1 day 3/19/2012 3/19/2012Review requirements, goals, objectives 1 day 3/20/2012 3/20/2012Project ClosingER Diagram 1 day 3/21/2012 3/21/2012Training Video 1 day 3/22/2012 3/22/2012System Documentation 1 day 3/23/2012 3/23/2012

Appendix 3: ER Diagram

20