Disaster Recovery & Business

Continuity

Systems Security 1
Learning Objectives
Upon completion of this lesson the student should be able
to:
 Describe what contingency planning is and how
incident response planning, disaster recovery
planning, and business continuity plans are related to
contingency planning.
 Discuss the elements that comprise a business
impact analysis and the information that is collected
for the attack profile.
 Recognize the components of an incident response
plan.

Systems Security 2
Learning Objectives
Upon completion of this lesson the student should be able to:
 Explain the steps involved in incident reaction and
incident recovery.
 Define the disaster recovery plan and its parts.
 Define the business continuity plan and its parts.
 Discuss the reasons for and against involving law
enforcement officials in incident responses and when
may be required.

Systems Security 3
Continuity Strategy
 Managers must provide strategic planning
to assure continuous information systems
availability ready to use when an attack
occurs
 Plans for events of this type are referred to
in a number of ways:
 Business Continuity Plans (BCPs)
 Disaster Recovery Plans (DRPs)
 Incident Response Plans (IRPs)
 Contingency Plans
Systems Security 4
Continuity Strategy
 Large organizations may have many types of
plans, small organizations may have one
simple plan, but most have inadequate
planning

Systems Security 5
Contingency Planning
 Contingency is a possible event.

 Contingency planning is a systematic

approach to identifying what can go wrong
in a situation.

 Components of Contingency Planning (CP):

 Incident Response Planning (IRP)
 Disaster Recovery Planning (DRP)
 Business Continuity Planning (BCP)
Systems Security 6
Contingency Planning
 The primary functions of these three planning
components:
 IRP focuses on immediate response, but if the attack
escalates or is disastrous the process changes to
disaster recovery and BCP
 DRP typically focuses on restoring systems after
disasters occur, and as such is closely associated with
BCP
 BCP occurs concurrently with DRP when the damage
is major or long term, requiring more than simple
restoration of information and information resources

Systems Security 7
Contingency Planning Team
 Before any planning can begin, a team has
to plan the effort and prepare the resulting
documents
 Champion - A high-level manager to
support, promote, and endorse the findings
of the project

Systems Security 8
Contingency Planning Team
 Project Manager - Leads the project and
makes sure a sound project planning process is
used, a complete and useful project plan is
developed, and project resources are prudently
managed

 Team Members - Should be the managers or

their representatives from the various
communities of interest: Business, IT, and
Information Security
Systems Security 9
Contingency Planning Hierarchy

Contingency
Planning

Incident Disaster Business

Response Recovery Continuity

FIGURE 7-2 Contingency Planning Hierarchy

Systems Security 10
Contingency Planning
Timeline

Incident Response (IRP)

Disaster Recovery Planning (DRP)
Business Continuity (BCP)

Attack Post Attack Post Attack

(hours) (days)

FIGURE 7-3 Contingency Planning Timeline

Systems Security 11
Figure 1: Contingency Planning Figure 2: Contingency Planning
Hierarchy Timeline

BCP
Post
Attack
 DRP (days)
Post Attack
(hours)
IRP
Attack
Major Steps in Contingency Planning

Business impact Incident Disaster Business

analysis (BIA) response recovery continuity
planning planning planning

Identification of Incident Plan for Establish

threats and attacks planning disaster Continuity
recovery strategy
Business unit analysis
Incident
detection
Scenarios of Crisis Plan for
successful attacks Management continuity of
Incident operations
Assessment of reaction
potential damages

Incident Recovery Continuity

Classification of operations management
subordinate plans recovery

FIGURE 7-4 Systems Security Major Steps in Contingency Planning

13
Business Impact Analysis
 Begin with Business Impact Analysis (BIA)
if the attack succeeds, what do we do then?
 The CP team conducts the BIA in the
following stages:
1. Threat attack identification
2. Business unit analysis
3. Attack success scenarios
4. Potential damage assessment
5. Subordinate plan classification

Systems Security 14
Threat Attack Identification & Prioritization
 Update threat list with latest developments and add
the attack profile
 The attack profile is the detailed description of
activities during an attack
 Must be developed for every serious threat the
organization faces
 Used to determine the extent of damage that could
result to a business unit if the attack were
successful

Systems Security 15
Table 7-1 – Attack Profile
Date of Analysis
Attack name & description
Threat & probable threat agent
Known or possible vulnerabilities
Likely precursor activities or indicators
Likely attack activities or indicators of attack in
progress
Information assets or risk from this attack
Damage or loss to information assets likely from
this attack
Other assets at risk from this attack
TABLE 7-1
Damage or loss to other assets likely from this
Systems Security 16
attack Attack Profile
Business Unit Analysis
 The second major task within the BIA is the
analysis and prioritization of business
functions within the organization
 Identify the functional areas of the
organization and prioritize them as to which
are most vital
 Focus on a prioritized list of the various
functions the organization performs

Systems Security 17
Attack Success Scenario Development
 Next create a series of scenarios depicting the
impact a successful attack from each threat could
have on each prioritized functional area with:
 details on the method of attack
 the indicators of attack
 the broad consequences
 Attack success scenarios details are added to the
attack profile including:
 Best case
 Worst case
 Most likely alternate outcomes

Systems Security 18
Potential Damage Assessment

 From the attack success scenarios

developed, the BIA planning team must
estimate the cost of the best, worst, and
most likely cases
 Costs include actions of the response
team
 This final result is referred to as an attack
scenario end case

Systems Security 19
Subordinate Plan Classification
 Once potential damage has been
assessed, a subordinate plan must be
developed or identified
 Subordinate plans will take into account
the identification of, reaction to, and
recovery from each attack scenario

Systems Security 20
Subordinate Plan Classification
 An attack scenario end case is categorized
as disastrous or not
 The qualifying difference is whether or not an
organization is able to take effective action
during the event to combat the effect of the
attack

Systems Security 21
Incident Response Policy
 Of all the security policies within an organization, an
Incident Response Policy is one of the most important.
 The Incident response policy generally answer the
questions:
 Who will determine an actual security incident has occurred?
 Who will be notified when an incident occurs?
 How are individuals /departments notified?
 Who will be responsible for responding to the incident?
 What is the appropriate response?
 An Incident Response Policy involves several departments
and depending on the severity of the incident, may involve
the media.
Incident Response Planning

 Incident response planning covers the

identification of, classification of, and
response to an incident
 An incident is an attack against an
information asset that poses a clear threat
to the confidentiality, integrity, or availability
of information resources

Systems Security 23
Incident Response Planning
 Attacks are only classified as incidents if they have
the following characteristics:
 Are directed against information assets
 Have a realistic chance of success
 Could threaten the confidentiality, integrity, or availability of
information resources
 IR is more reactive, than proactive, with the
exception of the planning that must occur to prepare
the IR teams to be ready to react to an incident

Systems Security 24
Incident Planning
 The pre-defined responses enable the
organization to react quickly and effectively
to the detected incident
 This assumes two things:
 first, the organization has an IR team
 second, the organization can detect the incident
 The IR team consists of those individuals
needed to handle the systems as incident
takes place

Systems Security 25
Incident Planning
 The military process of planned team responses can
be used in an incident response
 The planners should develop a set of documents
that guide the actions of each involved individual
reacting to and recovering from the incident
 These plans must be properly organized and stored

Systems Security 26
Incident Response Plan
 Format and Content
 The plan must be organized to support quick and
easy access to the information needed
 Storage
 The plan should be protected as sensitive
information
 On the other hand, the organization needs this
information readily available

Systems Security 27
Incident Response Plan
 Testing
 An untested plan is not a useful plan. The levels
of testing strategies can vary:
 Checklist
 Structured walk-through
 Simulation
 Parallel
 Full-interruption

Systems Security 28
Incident Detection
 The most common occurrence is a
complaint about technology support, often
delivered to the help desk
 Possible detections:
 intrusion detection systems, both host-based
and network-based
 virus detection software
 systems administrators
 end users

Systems Security 29
Incident Detection

 Only through careful training can the

organization hope to quickly identify and
classify an incident
 Once an attack is properly identified, the
organization can respond

Systems Security 30
Incident Indicators
Possible indicators of Definite indicators of
incidents: incidents:
 Presence of unfamiliar files  Use of dormant accounts
 Unknown programs or  Changes to logs
processes  Presence of hacker tools
 Unusual consumption of  Notifications by partner or
computing resources peer
 Unusual system crashes  Notification by hacker
Probable indicators of Predefined situations
incidents: that signal an
 Activities at unexpected
times
automatic incident:
 Loss of availability
 Presence of new accounts  Loss of integrity
 Reported attacks  Loss of confidentiality
 Notification from IDS  Violation of policy
Systems Security  Violation of law 31
Incident or Disaster
 When Does an Incident Become a
Disaster?
 the organization is unable to mitigate the impact
of an incident during the incident
 the level of damage or destruction is so severe
the organization is unable to quickly recover
 It is up to the organization to decide which
incidents are to be classified as disasters and
thus receive the appropriate level of response

Systems Security 32
Incident Reaction
 Incident reaction consists of actions that guide
the organization to stop the incident, mitigate
the impact of the incident, and provide
information for the recovery from the incident
 In reacting to the incident there are a number of
actions that must occur quickly including:
 notification of key personnel
 assignment of tasks
 documentation of the incident (what happened, proof,
Reference)

Systems Security 33
Notification of Key Personnel
 Most organizations maintain alert rosters for
emergencies. An alert roster contains contact
information for the individuals to be notified in an
incident
 Two ways to activate an alert roster:
 A sequential roster is activated as a contact person calls
each and every person on the roster
 A hierarchical roster is activated as the first person calls
a few other people on the roster, who in turn call a few
other people, and so on

Systems Security 34
The Alert Message
 The alert message is a scripted description of
the incident, with just enough information so
that everyone knows what part of the IRP to
implement
 Can be prepared rapidly by filling in the
blanks in a template included in the IRP

Systems Security 35
Documenting an Incident
 Documenting the event is important:
 First, it is important to ensure that the event is recorded
for the organization’s records, to know what happened,
and how it happened, and what actions were taken. The
documentation should record the who, what, when,
where, why, and how of the even
 Second, it is important to prove, should it ever be
questioned, that the organization did everything possible
to prevent the spread of the incident
 Finally, the recorded incident can also be used as a
simulation in future training sessions

Systems Security 36
Incident Containment
Strategies
 Before an incident can be contained, the affected
areas of the information and information systems
must be determined
 The organization can stop the incident and
attempt to recover control through a number of
strategies including:
 severing the affected circuits
 disabling accounts
 reconfiguring a firewall

Systems Security 37
Incident Containment
Strategies

 The ultimate containment option, reserved

for only the most drastic of scenarios,
involves a full stop of all computers and
network devices in the organization

Systems Security 38
Incident Recovery
 Once the incident has been contained, and control
of the systems regained, the next stage is
recovery
 The first task is to identify the human resources
needed and launch them into action
 The full extent of the damage must be assessed
 The organization repairs vulnerabilities, addresses
any shortcomings in safeguards, and restores the
data and services of the systems

Systems Security 39
Damage Assessment
 There are several sources of information:
 including system logs
 intrusion detection logs
 configuration logs and documents
 documentation from the incident response
 results of a detailed assessment of systems and data
storage
 Computer evidence must be carefully collected,
documented, and maintained to be acceptable in
formal proceedings
 Individuals assessing damage need special
training
Systems Security 40
Recovery
In the recovery process:
 Identify the vulnerabilities that allowed the
incident to occur and spread and resolve them
 Address the safeguards that failed to stop or
limit the incident, or were missing from the
system in the first place. Install, replace or
upgrade them
 Evaluate monitoring capabilities. Improve their
detection and reporting methods, or simply
install new monitoring capabilities

Systems Security 41
Recovery

In the recovery process:

 Restore the data from backups
 Restore the services and processes in use
 Continuously monitor the system
 Restore the confidence of the members of the
organization’s communities of interest
 Conduct an after-action review

Systems Security 42
Automated Response
 New systems can respond to incidents
autonomously/automatically?
 Trap and trace uses a combination of resources to
detect intrusion then trace back to source
 Trapping may involve honeypots or honeynets
 Entrapment is luring an individual into committing a
crime to get a conviction
 Enticement is legal and ethical, while entrapment
is not

Systems Security 43
Disaster Recovery Planning

 Disaster recovery planning (DRP) is

planning the preparation for and recovery
from a disaster
 The contingency planning team must
decide which actions constitute disasters
and which constitute incidents

Systems Security 44
Disaster Recovery Planning

 When situations are classified as

disasters plans change as to how to
respond - take action to secure the most
valuable assets to preserve value for the
longer term even at the risk of more
disruption
 DRP strives to reestablish operations at
the ‘primary’ site

Systems Security 45
DRP Steps

 There must be a clear establishment of

priorities
 There must be a clear delegation of roles
and responsibilities
 Someone must initiate the alert roster and
notify key personnel

Systems Security 46
DRP Steps

 Someone must be tasked with the

documentation of the disaster
 If and only if it is possible, some attempts
must be made to mitigate the impact of
the disaster on the operations of the
organization

Systems Security 47
Crisis Management

 Crisis management is actions taken during

and after a disaster focusing on the people
involved and addressing the viability of the
business

Systems Security 48
The Crisis Management Team
 The crisis management team is responsible for
managing the event from an enterprise
perspective and covers:
 Supporting personnel and families during the crisis
 Determining impact on normal business operations and,
if necessary, making a disaster declaration
 Keeping the public informed
 Communicating with major customers, suppliers,
partners, regulatory agencies, industry organizations, the
media, and other interested parties

Systems Security 49
Disaster Recovery Planning
 Establish a command center to support
communications
 Includes individuals from all functional areas
of the organization to facilitate
communications and cooperation
 Some key areas of crisis management
include:
 Verifying personnel head count
 Checking the alert roster
 Checking emergency information cards
Systems Security 50
DRP Structure

 Similar to the IRP, DRP is organized by

disaster, and provides procedures to
execute during and after a disaster
 Provides details on the roles and
responsibilities for those involved in the
effort, and identifies the personnel and
agencies that must be notified

Systems Security 51
DRP Structure

 Just as the IRP must be tested, so must

the DRP, using the same testing
mechanisms
 Each organization must examine its
scenarios, developed during the initial
contingency planning, to determine how
to respond to the various disasters

Systems Security 52
Business Continuity Planning
 Business continuity planning outlines
reestablishment of critical business
operations during a disaster that impacts
operations
 If a disaster has rendered the business
unusable for continued operations, there
must be a plan to allow the business to
continue to function

Systems Security 53
Continuity Strategies
 There are a number of strategies for planning for
business continuity
 The determining factor in selection between these
options is usually cost
 In general there are three exclusive options:
 hot sites
 warm sites
 cold sites
 And three shared functions:
 Timeshare (leased site in conjunction with a biz part/sis )
 service bureaus (provides services for free: physical
facilities in case of disaster)
 mutual agreements (between agencies)
Systems Security 54
Off-Site Disaster Data Storage
 To get these types of sites up and running quickly, the
organization must have the ability to port data into the new
site’s systems
 These include:
 Electronic vaulting - The bulk batch-transfer of data to an off-
site facility.
 Remote Journaling - The transfer of live transactions to an
off-site facility; only transactions are transferred not archived
data, and the transfer is real-time.
 Database shadowing - Not only processing duplicate real-
time data storage, but also duplicates the databases at the
remote site to multiple servers.

Systems Security 55
Model for IR/DR/BC Plan

 The single document set approach

supports concise planning and encourages
smaller organizations to develop, test, and
use IR/DR plans
 The model presented is based on analyses
of disaster recovery and incident response
plans of dozens of organizations

Systems Security 56
The Planning Document
1. Establish responsibility for managing the
document, typically the security
administrator
2. Appoint a secretary to document the
activities and results of the planning
session(s)
3. Independent incident response and
disaster recovery teams are formed, with a
common planning committee
Systems Security 57
The Planning Document
4. Outline the roles and responsibilities for
each team member
5. Develop the alert roster and lists of
critical agencies
6. Identify and prioritize threats to the
organization’s information and
information systems

Systems Security 58
The Planning Process
There are six steps in the Contingency Planning
process:
1. Identifying the mission- or business-critical functions
2. Identifying the resources that support the critical
functions
3. Anticipating potential contingencies or disasters
4. Selecting contingency planning strategies
5. Implementing the contingency strategies
6. Testing and revising the strategy

Systems Security 59
Completing the Planning
Document

 Finally the IR portion of the plan is

assembled
 Sections detailing the organization’s DRP and
BCP efforts are placed after the incident
response sections
 Multiple copies for each functional area
are created, cataloged, and signed out to
responsible individuals

Systems Security 60
Using the Plan
 During the incident
 After the incident
 Before the incident

Systems Security 61
Law Enforcement Involvement
 When the incident at hand constitutes a violation of law the
organization may determine that involving law enforcement is
necessary
 There are several questions, which must then be answered:
 When should the organization get law enforcement involved?
 What level of law enforcement agency should be involved:
local, state, or federal?
 What will happen when the law enforcement agency is
involved?
 Some of these questions are best answered by the
organization’s legal department

Systems Security 62
Benefits of Law Enforcement Involvement
Involving law enforcement agencies has
advantages:
 Agencies may be much better equipped at
processing evidence than private organizations
 Unless the organization has staff trained in
forensics they may less effective in convicting
suspects

Systems Security 63
Benefits of Law Enforcement Involvement
Involving law enforcement agencies has
advantages:
 Law enforcement agencies are also prepared to
handle the warrants and subpoenas needed
 Law enforcement skilled at obtaining statements
from witnesses, completing affidavits, and other
information collection

Systems Security 64
Drawbacks to Law Enforcement Involvement
Involving law enforcement agencies has
disadvantages:
 On the downside, once a law enforcement
agency takes over a case, the organization
loses complete control over the chain of
events
 The organization may not hear about the case
for weeks or even months

Systems Security 65
Drawbacks to Law Enforcement Involvement
Involving law enforcement agencies has
disadvantages:
 Equipment vital to the organization’s business
may be tagged as evidence, to be removed,
stored, and preserved until it can be examined
for possible support for the criminal case
 However, if the organization detects a criminal
act, it is a legal obligation to involve the
appropriate law enforcement officials

Systems Security 66