Answerbook (Case Study Omega)

Answerbook (Case Study Omega)

Using the Omega Case Study, complete the BIA template for their SAP system. Note, the BIA template is appendix B of the NIST SP 800-34 rev 1 document. Provide a one to two page analysis summarizing the results to the executive management team of Omega. The summary should highlight the priority of business functions, along with the potential for loss in the event of a disaster or sustained outage.

This sample template is designed to assist the user in performing a Business Impact Analysis (BIA) on an information system. The template is meant only as a basic guide and may not apply equally to all systems. The user may modify this template or the general BIA approach as required to best accommodate the specific system. In this template, words in italics are for guidance only and should be deleted from the final version. Regular (non-italic) text is intended to remain.

1. Overview

This Business Impact Analysis (BIA) is developed as part of the contingency planning process for the {system name}{system acronym}. It was prepared on {insert BIA completion date}.

  1.1                             Purpose

The purpose of the BIA is to identify and prioritize system components by correlating them to the business process(es) the system supports, and by using this information to characterize the impact on the process(es) if the system were unavailable.

The BIA is composed of the following three steps:

1. Determine business processes and recovery criticality. Business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum that an organization can tolerate while still maintaining the mission.
2. Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume business processes and related interdependencies as quickly as Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
3. Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can more clearly be linked to critical business processes and Priority levels can be established for sequencing recovery activities and resources.

This document is used to build the {system name} ISCP and is included as a key component of the ISCP. It also may be used to support the development of other contingency plans associated with the system, including, but not limited to, the Disaster Recovery Plan (DRP) or Incident Response Plan (IRP).

2. System Description

Provide a general description of system architecture and functionality.

Indicate the operating environment, physical location, general location of users, and partnerships with external organizations/systems. Include information regarding any other technical considerations that are important for recovery purposes, such as backup procedures. Provide a diagram of the architecture, including inputs and outputs and telecommunications connections.

 

3. BIA Data Collection

Data collection can be accomplished through individual/group interviews, workshops, email, questionnaires, or any combination of these.

  3.1              Determine Process and System Criticality

Step one of the BIA process – Working with input from users, managers, business process owners, and other internal or external points of contact (POC), identify the specific business processes that depend on or support the information system.

Business Process	Description
Pay vendor invoice	Process of obligating funds, issuing check or electronic payment and acknowledging receipt

 

 

If criticality of business processes has not been determined outside of the BIA, the following subsections will help to determine criticality of business processes that depend on or support the information system.

3.1.1 Identify Outage Impacts and Estimated Downtime

This section identifies and characterizes the types of impacts that a system disruption is likely to create in addition to those identified by the FIPS level, as well as the estimated downtime that the organization can tolerate for a given process. Impact categories should be created and values assigned to these categories in order to measure the level or type of impact a disruption may cause. An example is provided. The

template should be updated to reflect what is appropriate for the organization.

Outage Impacts

Impact categories and values should be created in order to characterize levels of severity to the organization that would result for that particular impact category if the business process could not be performed. These impact categories and values are samples and should be updated to reflect what is appropriate for the organization.

 

 

 

 

The following impact categories represent important areas for consideration in the event of a disruption or impact.Impact category: {insert category name} Impact values for assessing category impact: ·            Severe = {insert value} ·            Moderate = {insert value} ·            Minimal = {insert value}
	Example impact category = Cost·            Severe – temp staffing, overtime, fees are greater than $1 million ·            Moderate – fines, penalties, liabilities potential $550k ·            Minimal – new contracts, supplies $75k

 

The table below summarizes the impact on each business process if {system name} were unavailable, based on the following criteria:

Business Process	Impact Category
	{insert}	{insert}	{insert}	{insert}	Impact
Pay vendor invoice

 

Estimated Downtime

Working directly with business process owners, departmental staff, managers, and other stakeholders, estimate the downtime factors for consideration as a result of a disruptive event.

• Maximum Tolerable Downtime (MTD). The MTD represents the total amount of time leaders/managers are willing to accept for a business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and
• Recovery Time Objective (RTO). RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.
• Recovery Point Objective (RPO). The RPO represents the point in time, prior to a disruption or system outage, to which business process data must be recovered (given the most recent backup copy of the data) after an outage.

 

 

The table below identifies the MTD, RTO, and RPO (as applicable) for the organizational business processes that rely on {system name}. Values for MTDs and RPOs are expected to be specific time frames, identified in hourly increments (i.e., 8 hours, 36 hours, 97 hours, etc.).

 

Business Process	MTD	RTO	RPO
Pay vendor invoice	72 hours	48 hours	12 hours (last backup)

 

Include a description of the drivers for the MTD, RTO, and RPOs listed in the table above (e.g., mandate, workload, performance measure, etc.).

Include a description of any alternate means (secondary processing or manual work-around) for recovering the business process(es) that rely on the application. If none exist, so state.

3.2       Identify Resource Requirements

The following table identifies the resources that compose {system name} including hardware, software, and other resources such as data files.

 

System Resource/Component	Platform/OS/Version (as applicable)	Description
Web Server 1	Optiplex GX280	Web Site Host

 

It is assumed that all identified resources support the business processes identified in Section 3.1 unless otherwise stated.

 

3.3       Identify Recovery Priorities for System Resources

The table below lists the order of recovery for {system name} resources. The table also identifies the expected time for recovering the resource following a “worst case” (complete rebuild/repair or replacement) disruption.

■ Recovery Time Objective (RTO) – RTO defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the MTD. Determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.

 

Priority	System Resource/Component	Recovery Time Objective
Web Server 1	Optiplex GX280	24 hours to rebuild or replace

 

A system resource can be software, data files, servers or other hardware and should be identified individually or as a logical group.

Identify any alternate strategies in place to meet expected recovery time objectives. This includes backup or spare equipment and vendor support contracts.

 

BACKGROUND

Omega Research is a rapidly growing research and consulting firm. They have a single main office located in Reston, VA and three small branch offices located in San Diego, CA, Salem, OR, and Kansas City, MO. Omega is not currently involved in e-commerce or business-to­business relationships.

Two weeks ago, Omega experienced a significant loss of proprietary data (estimated value $550,000.00) that was stored electronically in an Oracle database in their main office in Reston. The data was unrecoverable and backups were not being routinely maintained, so no restoration was possible. Although he has no hard evidence, Omega’s CTO believes that the loss resulted from deliberate deletion of files by a systems administrator from the Kansas City office that had been “let go” several weeks prior to the loss. Needless to say, the CTO has been tasked to “get things under control.”

You have been hired as a consultant to develop a comprehensive plan for improving the company’s recovery posture in order to prevent future outage of Omega’s critical systems and network resources. Your guidance and observations will eventually be used to develop a long-term procedural and policy solution for Omega Research. The CTO has stepped up to the plate and made the commitment to do whatever it takes to address these issues.

 

 

 

Baseline Network Infrastructure

• Omega leverages AT&T Managed Internet Services for each of its office locations.
• Omega owns and manages the border routers for each of their office sites.
• Offices in Reston, San Diego, and Kansas City receive full T-1 service.
• Offices in Salem receive 256k F-T1 circuit service.

 

 

Systems

 

 

Business processes provided by AIX Environment

 

1. Financial
2. Reporting
3. Data Warehouse

 

 

 

LAN

 

 

Vendor	Services	Address	Phone	Contacts
IBM	Tape LibraryTSM Server	522 South RdPoughkeepsie, NY 12601	214 451-7747	Steve Barretta
SunGard	Recovery services for server environment	401 N Broad St. Philadelphia, PA	877 456-3966 215 351-1300	q Don Meltin (Test Coord.) q Jack Fabrianni (Acct. Rep) q Lincoln  Balducci (Resource Coord.)

 

 

BASELINE ARCHITECTURE

Local Area Architecture (Reston Office)

AIX Environment

• Perimeter protection provided by screening router. Configured for dynamic packet filtering using reflexive Access Control Lists (ACL’s).
• Remote access is provided to employees while at home or on travel through PPTP VPN, and, dial-up RAS offered by a Microsoft Windows NT 4.0 Server ®.
• All servers in the Reston office have been centrally located to a data center.
  • The Reston data center supports a 5-keypunch combination lock that is required to have access to the room. That combination is shared with all IT personnel and is infrequently rotated.
  • The data center is controlled for humidity through HVAC purification.
  • The data center is controlled for temperature with isolated HVAC services.
  • The data center is not on a raised floor to control static electricity.
  • The data center does not have a site-wide UPS. Each server and network equipment supports their own mini-UPS.

 

• Internal Omega E-mail is supported by a Microsoft Exchange ® 2000 mail server running on a Microsoft Windows ® 2000 Server. Omega has installed an SMTP mail gateway to support Internet mail exchange.
• Omega is the registered owner of com and maintains a DNS Server at the Reston facility for name resolution supporting Omega users and to allow Internet access to publicly accessible information (web and e-mail).
• Web hosting services are provided on a Microsoft Windows ® 2000 Server running Internet Information Services (IIS).
• 500 directory services are available through Active Directory although their implementation is relatively immature – they are operating in a mixed environment.
• Server and client o/s environments have not been routinely patched.
• Reston office printers are all network connected.
• The IT Department is responsible for management of the networks and networked resources at the Reston facility. They manage more than 170 workstations and 6 servers performing the functions previously described.
• Client machines consist of Microsoft Windows ® 95, 98, NT Workstation 4.0, 2000, and Mac operating systems include OS/8 and OS-X, Panther.
• Productivity applications have not been standardized. Some user communities enjoy Corel OfficeSuite ® while others appreciate Microsoft Office ®. There are various editions of these packages installed on client machines.

 

 

 

 

BASELINE ARCHITECTURE

Local Area Architecture (San Diego Office)

• The San Diego is essentially a mirror of the network architecture provided at the Reston facility.
• Differences:

o San Diego does not host a web server.

o San Diego does not support VPN or RAS connections.

o There are fewer employees working out of the west coast office. The local IT staff consists of one engineer who manages all networks and networked resources within the San Diego office.

o There are less than 50 client machines in San Diego with similar configurations as the main office.

o All servers have been located in a spare office in San Diego.

• There is not a controlled access restriction like in the main center.
• The office is not controlled for temperature, humidity, or static.
• There are no redundant power supplies.

 

BASELINE ARCHITECTURE

Local Area Architecture (Salem Office)

• Salem is a small site with only 30 workstations configured in much the same way as the rest of the company.
• Sale supports a single combined shared file and print server hosted on a Microsoft Windows ® NT 4.0 Server.
• Mail services are obtained through the San Diego office, using mailboxes set up on the San Diego Exchange Server.
• There are no publicly available networked resources at the Salem office.
• Remote access to Salem’s infrastructure is provided to mobile and home employees using VPN client to gateway connectivity.
• Salem has an IT staff of one engineer that manages all networks and networked resources at this site.
• All servers have been located in a spare office in San Diego.
• There is not a controlled access restriction like in the main center.
• The office is not controlled for temperature, humidity, or static.
• There are no redundant power supplies.

Is this the question you were looking for? If so, place your order here to get started!