Business Continuity Management / Disaster Recovery Measures Designed to be Integrated Into Systems' Life Cycle NIST on Monday issued revised guidance that
defines a seven-step contingency planning process that federal agencies and other organizations in fields such as healthcare and banking can use to develop and maintain a viable interim recovery program for their information systems. The National Institute of Standards and Technology designed the seven progressive steps to be integrated into each stage of the system development life cycle. They include: - Develop the contingency planning policy statement. A formal policy provides
the authority and guidance necessary to develop an effective contingency plan.
- Conduct the business impact analysis (BIA). The BIA helps identify and prioritize information systems and components critical to supporting the organization's mission/business functions. A template for developing the BIA is provided to assist the user.
- Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase system availability and reduce
contingency life cycle costs.
- Create contingency strategies. Thorough recovery strategies ensure that the system may be recovered quickly and effectively following a disruption.
- Develop an information system contingency plan. The contingency plan should contain detailed guidance and procedures for restoring a damaged system unique to the system's security impact level and recovery requirements.
- Ensure plan testing, training, and exercises. Testing
validates recovery capabilities, whereas training prepares recovery personnel for plan activation and exercising the plan identifies planning gaps; combined, the activities improve plan effectiveness and overall organization preparedness.
- Ensure plan maintenance. The plan should be a living document that is updated regularly to remain current with system enhancements and organizational changes.
Formally, the revised standard is known as Special Publication
800-34, Revision 1: Contingency Planning Guide for Federal Information Systems. An organization must acknowledge that risk management controls may fail; thus, contingency planning is necessary to help organizations anticipate and react to events that threaten information security. Contingency planning entails the forming of four major components: business impact analysis, incident response plan, disaster recovery plan, and business continuity plan1. The following examples of these four components serve as a very basic
contingency plan responding to an event in which a computer virus is spreading through the network of Organization XYZ imagined for the physical security strategy on the Security Awareness page; the central database server is of particular concern. Business Impact AnalysisThis business impact analysis is outlined in accordance with the
template provided in NIST Special Publication 800-34 Rev. 12. 1. Overview This Business Impact Analysis (BIA) is developed as part of the contingency planning process for the Organization XYZ database server. It was prepared on April 26, 2013. 1.1 Purpose The purpose of the BIA is to identify and prioritize system components by correlating them to the mission/business process(es) the system supports, and 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: - Determine mission/business processes and recovery criticality. Mission/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.
- Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
- Identify recovery priorities for system resources. Based upon the results from the previous activities, system
resources can more clearly be linked to critical mission/business processes. Priority levels can be established for sequencing recovery activities and resources.
This document is used to build the Organization XYZ database server Information System Contingency Plan (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 Cyber Incident Response Plan. 2. System Description The Organization XYZ database server is comprised of Microsoft SQL Server 2012 Enterprise Edition installed and running on Microsoft Windows Server 2012; this platform is housed on a Dell R720 server-class system. The database server is located in the server rack located on the second floor server room. Local administrators connect directly through the local area network; other users connect indirectly through the web
server. Daily snapshot backup operations are conducted every day 3 hours after close of business. 3. Data Collection 3.1 Determine Process and System Criticality Step one of the BIA process - Working with input from users, managers, mission/business process owners, and other internal or external points of contact (POC), identify the specific mission/business processes that depend on or support the information system.
| Mission/Business Process
| Description
| | Query customer record
| Database retrieval of customer information (e.g. address, phone, payment information)
| | Store customer transaction
| Recording of customer purchases and credits
| | Authenticate user name and password
| Stored procedure verifying user credentials
|
3.1 Identify Outage Impacts and Estimated Downtime Outage Impacts The following impact categories represent important areas for consideration in the event of a disruption or impact. Impact category: Cost Impact categories for assessing category impact: - Severe = overtime, lost revenue exceeding $100,000
- Moderate = overtime, lost revenue exceeding $50,000
- Minimal = lost revenue exceeding $10,000
| Mission/Business Process
| Cost/Impact
| | Query customer record
| Minimal
| | Store customer transaction
| Severe
| | Authenticate user name and password
| Moderate
|
Estimated Downtime Working directly with mission/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 mission/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 content.
- 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 mission/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 mission/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
mission/business processes that rely on the Organization XYZ database server.
| Mission/Business Process
| MTD
| RTO
| RPO
| | Query customer record
| 48 hours
| 24 hours
| 8 hours
| | Store customer transaction
| 24 hours
| 12 hours
| 4 hours
| | Authenticate user name and password
| 36 hours
| 24 hours
| 8 hours
|
3.2 Identify Resource Requirements The following table identifies the resources that compose the Organization XYZ database server including hardware, software, and other resources such as data files.
| System Resource/Component
| Platform/OS/Version (as applicable)
| Description
| | Server-class System
| Dell R720
| Rack-mounted system
| | Windows Server
| 2012
| Host operating system
| | Microsoft SQL Server
| 2012 Enterprise Edition
| Database management system
| | Database files
| Latest, or latest snapshot if needed
| Binary files containing data
|
It is assumed that all identified resources support the mission/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 the Organization XYZ database server 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 mission/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
| | Server-class System
| Dell R720
| 24 hours to replace
| | Windows Server
| 2012
| 2 hours to install
| | Microsoft SQL Server
| 2012 Enterprise Edition
| 2 hours to install
| | Database files
| Latest, or latest snapshot if needed
| 2 hours to restore
|
Incident Response PlanThe following incident response plan enumerates actions to be taken under conditions before, during, and after an attack in which a virus is detected on a networked device. Before an Attack Users - Avoid inserting media (i.e. compact discs, flash drives, etc.) for which the source is not trusted.
- Do not open e-mail attachments from untrusted
sources or attachments that have not been scanned with anti-virus software.
- Do not visit disreputable web sites or web sites that have been flagged as untrustworthy by web browser services.
Technology Services - Ensure virus definition databases remain up-to-date; if possible, automate the download an installation of such databases within anti-virus software.
- Configure anti-virus software for real-time scanning of all possible system entry
points (e.g. e-mail, file downloads, boot sector scanning, etc.).
- Update anti-virus software (not to be mistaken for virus definition databases) to the latest revision as it becomes available.
During an Attack Users - If a virus is detected, and prompted to delete or quarantine the infected file, quarantine the file.
- Disconnect the device from the network by either unplugging the network cable or disabling the wireless adapter
(typically a keyboard combination such as 'Fn' key + F2 key.
- If the device exhibits odd behavior, power down the device using the power button or unplugging the power chord if necessary.
- Notify technology services immediately, and do not interact with the device until a representative arrives.
Technology Services - Quarantine the file if the user has not already done so.
- Deactivate the device's network adapter or power down the device if
the user has not already done so.
- Power on the device in an environment isolated from the network and other users; scan all contents of fixed and removable media.
After an Attack Users - Scan all contents of the hard drive with anti-virus scanner.
- Document suspected sources of the infection.
- Submit documentation to technology services.
Technology Services - Review user report and anti-virus
software logs for indication of the source of the infection.
- Submit findings to peers and supervisors.
- Configure network components to block traffic, e-mail, file transmission, and/or others from the source.
Disaster Recovery PlanThis example disaster recovery plan portrays a scenario in which a computer virus has pervaded the Organization XYZ network, all stations are assumed to be infected, and data has been
corrupted. The focus of the plan is placed on the Organization XYZ database server, but it also provides some information on subsequent actions to be taking during the disaster recovery effort, referring to other constituent disaster recovery plan documents. Roles and Responsibilities- Security Incident Response Team (SIRT) Members: Qualify event as a disaster pending approval of CISO or CIO; execute alert roster.
- Chief
Information Security Officer (CISO): Contact CEO; approve qualification of event as disaster; provide other approval as necessary.
- Chief Information Officer (CIO): Contact CEO; approve qualification of event as disaster; provide other approval as necessary.
- Information Technology (IT) Technicians: Format server hard drive; install operating system; install database management system; restore database backup.
- Network Technicians: Isolate systems
from the physical network; establish subnetworks for newly restored systems.
- Customer Service Representatives: Contact customers whose systems may have been infected.
Alert Roster- SIRT Members: Contact CISO and/or CIO for disaster classification approval. Contact IT technicians, network technicians, and customer service representatives.
- Chief Information Security Officer (CISO): Contact Chief Executive
Officer (CEO).
- Chief Information Officer (CIO): Contact CEO.
- Information Technology Technicians: Contact CISO, CIO, IT managers, and network administrators as needed.
- Network Technicians: Contact CISO, CIO, IT managers, and network administrators as needed.
- Customer Service Representatives: Contact customers whose systems may have been infected.
Priorities- Disconnect all stations
from the physical network.
- Deactivate wireless gateways.
- Allocate a new subnetwork for restored systems.
- Restore the database server.
- Connect database to new subnetwork.
- Restore the web server. Refer to Web Server Disaster Recovery Plan (DRP) documentation.
- Connect web server to new subnetwork.
- Restore workstations. Refer to Workstation DRP documentation.
- Connect workstations to new subnetwork.
- Restore mobile devices. Refer
to Mobile Devices DRP documentation.
- Activate wireless gateways on new subnetwork.
- Connect mobile devices to wireless network as necessary.
Disaster DocumentationActions outlined in the following steps are to be monitored by SIRT members; upon completion of each action, SIRT members are to prompt individuals performing respective actions for their signatures on the Database Server DRP Record document. Actions- SIRT members have received approval for disaster classification, and contact IT technicians and network technicians.
- Network technicians disconnect the database server from the physical network.
- IT technicians remove all removable media from the database server.
- IT technicians perform a low-level format of all fixed media.
- IT technicians install the operating system software.
- IT technicians install the database
management system software.
- IT technicians restore database files from on-site backups.
- After all other networked devices have been isolated, network technicians reconnect the database server to the physical network.
- Network technicians configure the database for the new subnetwork.
Business Continuity PlanThe following example of a business continuity plan (BCP) outlines the high-level actions that
occur to move Organization XYZ to the designated warm site. BCP Actions- CEO consults department leads to consider time for recovery and determine need for business contingency.
- CEO announces business contingency is in effect.
- CEO works with local authorities to ensure human safety as needed.
- Network managers and technicians move network operations to warm site.
- IT managers and technicians assess ability to move
existing systems to warm site.
- IT managers and technicians requisition new equipment to be delivered to warm site as needed.
- Network technicians validate warm site's network infrastructure and telecommunications capabilities.
- IT managers and technicians install/restore systems at warm site.
- Network technicians connect systems to warm site network.
- Network technicians update public domain name records.
- Network technicians inform customer service
representatives of changes to telephone numbers, public IP addresses, etc.
- Customer service representatives contact customers with new contact information.
1Whitman, M. E., Mattord, H. J. (2010). Management of information security (3rd ed.). Boston, MA: CENGAGE Learning. 2 Swanson, M., Bowen, P., Phillips, A. W., Gallup, D., & Lynes, D. (2010, May). NIST special publication 800-34 rev. 1: Contingency planning guide for
federal information systems. Retrieved from http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
Which is the first step in the contingency planning process?
NIST's 7-Step Contingency Planning Process. Develop the contingency planning policy statement. ... . Conduct the business impact analysis (BIA). ... . Identify preventive controls. ... . Create contingency strategies. ... . Develop an information system contingency plan. ... . Ensure plan testing, training, and exercises. ... . Ensure plan maintenance.. What are the components of contingency planning?
Contingency planning has three components: an estimate of what is going to happen, a plan based on this estimate of what the response should be; and some actions identified to be best prepared. This chapter helps planners think through what is going to happen, and the likely impact on people's lives and livelihoods.
What are the 5 steps of contingency planning?
The 5 Steps Of Contingency Planning. Program Management. Most organizations start by recruiting a contingency planning team that includes at least one representative from each department and every level of management down to the most entry-level positions. ... . Planning. ... . Implementation. ... . Testing & Exercise. ... . Program Improvement.. What are the four components of contingency planning?
Contingency planning has four basic aspects: business impact analysis, incident response plan, disaster recovery plan, and business continuity plan.
| 
