Continuity StrategiesThe CPMT can choose from several strategies i

Continuity Strategies
The CPMT can choose from several strategies in its CP and BC
planning. The determining factor is usually cost. In general,
there are three types of usage strategies in which the
organization has the right to the exclusive use of a facility and
access is not shared with other organizations:
Hot site
A fully configured computing facility that
includes all services, communications links, and physical plant
operations. Hot sites are used for BC operations.
—A hot site is a fully configured computing
facility that includes all services, communications links, and
physical plant operations. It duplicates computing resources,
peripherals, phone systems, applications, and workstations.
Essentially, this duplicate facility needs only the latest data
backups and the personnel to function. If the organization uses
one of the data services listed in the following sections, a hot
site can be fully functional within minutes. Not surprisingly, it
is the most expensive alternative. Other disadvantages include
the need to provide maintenance for all the systems and
equipment at the hot site, as well as physical and information
security. However, if the organization requires a 24/7 capability
for near real-time recovery, the hot site is the optimal strategy.
Warm site
A facility that provides many of the same
services and options as a hot site, but typically without installed
and configured software applications. Warm sites are used for
BC operations.
—A warm site provides many of the same
services and options as the hot site, but typically software
applications are not included or are not installed and

configured. A warm site frequently includes computing
equipment and peripherals with servers but not client
workstations. Overall, it offers many of the advantages of a hot
site at a lower cost. The disadvantage is that several hours—
perhaps days—are required to make a warm site fully
functional.
Cold site
A facility that provides only rudimentary
services, with no computer hardware or peripherals. Cold sites
are used for BC operations.
—A cold site provides only rudimentary
services and facilities. No computer hardware or peripherals are
provided. All communications services must be installed after
the site is occupied. A cold site is an empty room with standard
heating, air conditioning, and electrical service. Everything else
is an added-cost option. Despite these disadvantages, a cold site
may be better than nothing. Its primary advantage is its low
cost. The most useful feature of this approach is that it ensures
that an organization has floor space should a widespread
disaster strike, but some organizations are prepared to struggle
to lease new space rather than pay maintenance fees on a cold
site.
Likewise, there are three strategies in which an organization can
gain shared use of a facility when needed for contingency
options:
Timeshare
A continuity strategy in which an
organization co-leases facilities with a business partner or sister
organization. A timeshare allows the organization to have a BC
option while reducing its overall costs.
—A timeshare operates like one of the three
sites described above but is leased in conjunction with a

business partner or sister organization. It allows the
organization to provide a DR/BC option while reducing its
overall costs. The primary disadvantage is the possibility that
more than one time-share participant will need the facility
simultaneously. Other disadvantages include the need to stock
the facility with the equipment and data from all organizations
involved, the complexity of negotiating the timeshare with the
sharing organizations, and the possibility that one or more
parties might exit the agreement or sublease their options.
Operating under a timeshare is much like agreeing to co-lease
an apartment with a group of friends. One can only hope that
the organizations remain on amicable terms, as they all could
potentially gain physical access to each other’s data.
Service bureau
A continuity strategy in which an
organization contracts with a service agency to provide a BC
facility for a fee.
—A service bureau is a service agency that
provides a service for a fee. In the case of DR/BC planning, this
service is the provision of physical facilities in the event of a
disaster. Such agencies also frequently provide off-site data
storage for a fee. Contracts with service bureaus can specify
exactly what the organization needs under what circumstances.
A service agreement usually guarantees space when needed; the
service bureau must acquire additional space in the event of a
widespread disaster. In this sense, it resembles the rental car
provision in a car insurance policy. The disadvantage is that
service contracts must be renegotiated periodically and rates
can change. It can also be quite expensive.
Mutual agreement
A continuity strategy in which two
organizations sign a contract to assist the other in a disaster by

providing BC facilities, resources, and services until the
organization in need can recover from the disaster.
—A mutual agreement is a contract between
two organizations in which each party agrees to assist the other
in the event of a disaster. It stipulates that each organization is
obligated to provide the necessary facilities, resources, and
services until the receiving organization is able to recover from
the disaster. This arrangement can be a lot like moving in with
relatives or friends—it does not take long for an organization to
wear out its welcome. Many organizations balk at the idea of
having to fund (even in the short term) duplicate services and
resources. Still, mutual agreements between divisions of the
same parent company, between subordinate and senior
organizations, or between business partners may be a cost-
effective solution when both parties to the agreement have a
mutual interest in the other’s continued operations and both
have similar capabilities and capacities.
In addition to these basic strategies, there are specialized
alternatives, such as a
rolling mobile site
A continuity strategy that involves
contracting with an organization to provide specialized facilities
configured in the payload area of a tractor-trailer.
, configured in the payload area of a
tractor/trailer, or externally stored resources, such as a rental
storage area containing duplicate or older equipment. These
alternatives are similar to the Prepositioning of Material
Configured to Unit Sets (POM-CUS) sites of the Cold War era,
in which caches of materials to be used in the event of an
emergency or war were stored outside normal work areas. An
organization might arrange with a prefabricated building
contractor for immediate, temporary facilities (mobile offices)
on site in the event of a disaster.
Listen

webReader by ReadSpeakerSettingsReadi ng
LanguageAmerican English - Female - SelectedAmerican
English - MaleAustralian EnglishBritish EnglishRead on
HoverEnlarge TextText ModePage MaskDownload mp3Help
Open/close toolbar
Digital Forensics Methodology
In digital forensics, all investigations follow the same basic
methodology:
Identify relevant items of evidentiary value (EM).
Acquire (seize) the evidence without alteration or damage.
Take steps to assure that the evidence is at every stage
verifiably authentic and is unchanged from the time it was
seized.
Analyze the data without risking modification or unauthorized
access.
Report the findings to the proper authority.
This general process is illustrated in Figure 10-12.

Figure 10-12.
Digital Forensics Process
To support the selection and implementation of a methodology,
the organization may wish to seek legal advice or consult with
local or state law enforcement. Other publications that should
become part of the organization team’s library include:
“Electronic Crime Scene Investigation: A Guide for First
Responders, 2nd edition”
(https://www.ncjrs.gov/pdffiles1/nij/219941.pdf)
“First Responders Guide to Computer Forensics”
(http://resources.sei.cmu.edu/library/asset-
view.cfm?assetID=7251)
“Searching and Seizing Computers and Obtaining Electronic
Evidence in Criminal Investigations”
(www.justice.gov/criminal/cybercrime/docs/ssmanual2009.pdf)
For a list of these and other computer forensics responder
guides, visit the CERT Web site at www.cert.org/incident-
management/csirt-development/resources-collecting-
evidence.cfm or the National Institute of Justice Web site at
www.nij.gov.
Identify Relevant Items
A crucial aspect of any digital forensics investigation is
identifying the potential EM and its probable location and then
documenting that information in the search warrant or
authorization document. Unless investigators have an idea of
what to look for (such as evidence that the accused has been
selling intellectual property related to future product offerings,
or has been viewing objectionable or illegal content), they may
never find it in the vast array of possible locations an individual
user may have access to—such as flash drives, external storage

drives, and Internet services.
Acquire the Evidence
The principal responsibility of the response team is to acquire
the information without altering it. Computers modify data
constantly. Normal system file changes may be difficult to
explain to a layperson (e.g., a jury member with little or no
technical knowledge). A normal system consequence of the
search for EM could be portrayed by a defense attorney as
affecting the authenticity or integrity of the EM, which could
lead a jury to suspect that the EM was planted or is otherwise
suspect. The biggest challenge is to show that the person under
investigation is the one who stored, used, and maintained the
EM, or who conducted the unauthorized activity.
Other Potential Evidence
Not all EM is on a suspect’s computer hard drive. A technically
savvy attacker is more likely to store incriminating evidence on
other digital media, such as removable drives, CDs, DVDs,
flash drives, memory chips or sticks, or on other computers
accessed across the organization’s networks or via the Internet.
EM located outside the organization is particularly problematic,
as the organization cannot legally search systems they don’t
own. However, the simple act of viewing EM on a system leaves
clues about the location of the source material, and a skilled
investigator can at least provide some assistance to law
enforcement when conducting a preliminary investigation. Log
files are another source of information about the access and
location of EM, as well as about what happened when.
Some evidence isn’t electronic or digital in nature. Many
suspects have been further incriminated when the passwords to
their digital media were discovered in the margins of user
manuals, in calendars and day planners, and even on notes
attached to their systems.
EM Handling

Once the evidence is acquired, both the copy image and the
original drive should be handled so as to avoid legal challenges
based on authenticity and preservation of integrity. If the
organization or law enforcement cannot demonstrate that no one
had physical access to the evidence, they cannot provide strong
assurances that it has not been altered. Once the evidence is in
the possession of investigators, they must track its movement,
storage, and access until the resolution of the event or case.
This is typically accomplished by means of chain of evidence
(also known as chain of custody) procedures. Chain of evidence
is defined as the detailed documentation of the collection,
storage, transfer, and ownership of collected evidence from
crime scene through its presentation in court. The evidence is
then tracked wherever it is located. When the evidence changes
hands or is stored, the documentation is updated. Not all
evidence-handling requirements are met through the chain of
custody process. Digital media must be stored in an
environment designed for that purpose, one that can be secured
to prevent unauthorized access. Individual items should be
stored in electrostatic discharge (ESD) protective containers or
bags, marked as sensitive to ESD and magnetic fields, and so
forth.
Authenticate the Recovered Evidence
A copy or image of the digital media containing the EM is
typically transferred to the laboratory for the next stage of
authentication. The team must be able to demonstrate that any
analyzed copy or image is a true and accurate replica of the
source EM. This is accomplished by the use of cryptographic
hash tools. As you will learn in Chapter 12, the hash tool takes
a variable-length file and creates a single numerical value,
usually represented in hexadecimal notation, rather like a digital
fingerprint.
Analyze the Data
The most complex part of an investigation is the analysis of the

copy or image for potential EM. The first component of the
analysis phase is indexing. During indexing, many investigatory
tools create an index of all text found on the drive, allowing the
investigator to quickly and easily search for a specific type of
file.
Report the Findings
As investigators examine the analyzed copies or images and
identify potential EM, they can tag it and add it to their case
files. Once they have found a suitable amount of information,
they can summarize their findings as well as their investigatory
procedures in a report and submit it to the appropriate authority.
This authority could be law enforcement or management. The
suitable amount of EM is a flexible determination made by the
investigator. In certain cases, such as child pornography, one
file is sufficient to warrant turning the entire investigation over
to law enforcement. On the other hand, a dismissal on the
grounds of the unauthorized sale of intellectual property may
require a substantial amount of information to support the
organization’s assertion. Reporting methods and formats vary
from organization to organization and should be specified in the
digital forensics policy. The general guideline for the report is
that it should be sufficiently detailed to allow a similarly
trained person to repeat the analysis and achieve similar results.
Listen
webReader by ReadSpeakerSettingsReading

Open/close toolbar
Disaster Classification
A DR plan can classify disasters in a number of ways. The most
common method of
disaster classification
The process of examining an adverse event or
incident and determining whether it constitutes an actual
disaster.
is to evaluate the amount of damage caused by an
incident. Many disasters begin as incidents, and only when they
reach a specified threshold are they escalated from incident to
disaster. A denial-of-service attack that affects a single system
for a short time may be an incident, but when it escalates to
affect an entire organization for a much longer period of time, it
may be reclassified as a disaster. Who makes this classification?
It is most commonly done by a senior IT or InfoSec manager
working closely with the CSIRT and DR team leads. When the
CSIRT reports that an incident or collection of incidents has
begun to exceed their capability to respond, they may request
that the incident(s) be reclassified as a disaster in order for the
organization to better handle the expected damage or loss.
These types of disasters are commo nly referred to as
slow-onset disasters

Disasters that occur over time and gradually
degrade the capacity of an organization to withstand their
effects. Examples include droughts, famines, environmental
degradation, desertification, deforestation, and pest infestation.
, as they occur over time and gradually degrade the
capacity of an organization to withstand their effects. Hazards
that cause these disaster conditions typically include natural
causes such as droughts, famines, environmental degradation,
desertification, deforestation, and pest infestation and man-
made causes such as malware, hackers, disgruntled employees,
and service provider issues.
Usually, disasters that strike quickly are instantly classified as
disasters. These disasters are commonly referred to as
rapid-onset disasters
Disasters that occur suddenly, with little warning,
taking people’s lives and destroying the means of production.
Examples include earthquakes, floods, storm winds, tornadoes,
and mud flows.
, as they occur suddenly with little warning, taking
people’s lives and destroying the means of production. Rapid-
onset disasters may be caused by natural effects like
earthquakes, floods, storm winds, tornadoes, and mud flows, or
by man-made effects like massively distributed denial-of-
service attacks or acts of terrorism, including cyberterrorism or
hacktivism and acts of war. Interestingly, fire is an example of
an incident that can either escalate to disaster or begin as one
(in the event of an explosion, for example). Fire can be
categorized as a natural disaster when caused by a lightning
strike or as man-made.
Table 10-3 presents a list of natural disasters, their
effects, and recommendations for mitigation.
Table 10-3.
Natural Disasters and Their Effects on
Information SystemsNatural DisasterEffects and

MitigationFireDamages the building housing the computing
equipment that constitutes all or part of the information system.
Also encompasses smoke damage from the fire and water
damage from sprinkler systems or firefighters. Can usually be
mitigated with fire casualty insurance or business interruption
insurance.FloodCan cause direct damage to all or part of the
information system or to the building that houses all or part of
the information system. May also disrupt operations by
interrupting access to the buildings that house all or part of the
information system. Can sometimes be mitigated with flood
insurance or business interruption insurance.EarthquakeCan
cause direct damage to all or part of the information system or,
more often, to the building that houses it. May also disrupt
operations by interrupting access to the buildings that house all
or part of the information system. Can sometimes be mitigated
with specific casualty insurance or business interruption
insurance but is usually a specific and separate
policy.LightningCan directly damage all or part of the
information system or its power distribution components. Can
also cause fires or other damage to the building that houses all
or part of the information system. May also disrupt operations
by interrupting access to the buildings that house all or part of
the information system as well as the routine delivery of
electrical power. Can usually be mitigated with multipurpose
casualty insurance or business interruption insurance.Landslide
or mudslideCan damage all or part of the information system or,
more likely, the building that houses it. May also disrupt
operations by interrupting access to the buildings that house all
or part of the information system as well as the routine delivery
of electrical power. Can sometimes be mitigated with casualty
insurance or business interruption insurance.Tornado or severe
windstormCan directly damage all or part of the information
system or, more likely, the building that houses it. May also
disrupt operations by interrupting access to the buildings that
house all or part of the information system as well as the
routine delivery of electrical power. Can sometimes be

mitigated with casualty insurance or business interruption
insurance.Hurricane or typhoonCan directly damage all or part
of the information system or, more likely, the building that
houses it. Organizations located in coastal or low -lying areas
may experience flooding. May also disrupt operations by
interrupting access to the buildings that house all or part of the
information system as well as the routine delivery of electrical
power. Can sometimes be mitigated with casualty insurance or
business interruption insurance.TsunamiCan directly damage all
or part of the information system or, more likely, the building
that houses it. Organizations located in coastal areas may
experience tsunamis. May also cause disruption to operations by
interrupting access or electrical power to the buildings that
house all or part of the information system. Can sometimes be
mitigated with casualty insurance or business interruption
insurance.Electrostatic discharge (ESD)Can be costly or
dangerous when it ignites flammable mixtures and damages
costly electronic components. Static electricity can draw dust
into clean-room environments or cause products to stick
together. The cost of servicing ESD-damaged electronic devices
and interruptions can range from a few cents to millions of
dollars for critical systems. Loss of production time in
information processing due to the effects of ESD is significant.
While not usually viewed as a threat, ESD can disrupt
information systems and is not usually an insurable loss unless
covered by business interruption insurance. ESD can be
mitigated with special static discharge equipment and by
managing HVAC temperature and humidity levels.Dust
contaminationCan shorten the life of information systems or
cause unplanned downtime. Can usually be mitigated with an
effective HVAC filtration system and simple procedures, such
as efficient housekeeping, placing tacky floor mats at entrances,
and prohibiting the use of paper and cardboard in the data
center.

Listen
Open/close toolbar
Recovering from Incidents
Once the incident has been contained and system control has
been regained, incident recovery can begin. As in the incident
reaction phase, the first task is to inform the appropriate human
resources. Almost simultaneously, the CSIRT must assess the
full extent of the damage so as to determine what must be done
to restore the systems. Each individual involved should begin
recovery operations based on the appropriate incident recovery
section of the IR plan.
The immediate determination of the scope of the breach of
confidentiality, integrity, and availability of information and
information assets is called incident damage assessment.

Incident damage assessment can take days or weeks, depending
on the extent of the damage. The damage can range from minor
(a curious hacker snooping around) to severe (hundreds of
computer systems infected by malware). System logs, intrusion
detection logs, configuration logs, and other documents, as well
as the documentation from the incident response, provide
information on the type, scope, and extent of damage. Using
this information, the CSIRT assesses the current state of the
information and systems and compares it to a known state.
Individuals who document the damage from actual incidents
must be trained to collect and preserve evidence, in case the
incident is part of a crime or results in a civil action.
Once the extent of the damage has been determined, the
recovery process begins. According to noted security consultant
and author Donald Pipkin, this process involves the following
steps:*
Pipkin, D. Information Security: Protecting
the Global Enterprise. Upper Saddle River, NJ: Prentice Hall
PTR, 2000: 285.
Identify the vulnerabilities that allowed the incident to occur
and spread. 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 (if present). Improve detection
and reporting methods or install new monitoring capabilities.
Restore the data from backups. The IR team must understand
the backup strategy used by the organization, restore the data
contained in backups, and then use the appropriate recovery
processes from incremental backups or database journals to
recreate any data that was created or modified since the last

backup.
Restore the services and processes in use. Compromised
services and processes must be examined, cleaned, and then
restored. If services or processes were interrupted in the course
of regaining control of the systems, they need to be brought
back online.
Continuously monitor the system. If an incident happened once,
it could easily happen again. Hackers frequently boast of their
exploits in chat rooms and dare their peers to match their
efforts. If word gets out, others may be tempted to try the same
or different attacks on your systems. It is therefore important to
maintain vigilance during the entire IR process.
Restore the confidence of the members of the organization’s
communities of interest. Management, following the
recommendation from the CSIRT, may want to issue a short
memorandum outlining the incident and assuring all that the
incident was handled and the damage was controlled. If the
incident was minor, say so. If the incident was major or
severely damaged systems or data, reassure users that they can
expect operations to return to normal as soon as possible. The
objective of this communication is to prevent panic or confusion
from causing additional disruption to the operations of the
organization.
Before returning to its routine duties, the CSIRT must conduct
an
after-action review (AAR)
A detailed examination and discussion of the
events that occurred during an incident or disaster, from first
detection to final recovery.
. The AAR is an opportunity for everyone who was
involved in an incident or disaster to sit down and discuss what
happened. In an AAR, a designated person acts as a moderator
and allows everyone to share what happened from their own
perspective while ensuring there is no blame or finger-pointing.
All team members review their actions during the incident and
identify areas where the IR plan worked, did not work, or

should improve. Once completed, the AAR is written up and
shared. All key players review their notes and the AAR and
verify that the IR documentation is accurate and precise. The
AAR allows the team to update the plan and brings the reaction
team’s actions to a close. The AAR can serve as a training case
for future staff.
According to McAfee, there are 10 common mistakes that an
organization’s CSIRTs make in IR:
Failure to appoint a clear chain of command with a specified
individual in charge
Failure to establish a central operations center
Failure to “know your enemy,” as described in Chapters 1 and 6
Failure to develop a comprehensive IR plan with containment
strategies
Failure to record IR activities at all phases, especially help desk
tickets to detect incidents
Failure to document the events as they occur in a timeline
Failure to distinguish incident containment from incident
remediation (as part of reaction)
Failure to secure and monitor networks and network devices
Failure to establish and manage system and network logging
Failure to establish and support effective anti-virus and
antimalware solutions*
McAfee. “Emergency Incident Response:
10 Common Mistakes of Incident Responders.” Accessed
7/12/15 from www.mcafee.com/us/resources/white-
papers/foundstone/wp-10-common-mistakes-incident-
responders.pdf.
NIST SP 800-61, Rev. 2 makes the following recommendations
for handling incidents:

Acquire Tools and Resources That May Be
of Value During Incident Handling—The team will be more
efficient at handling incidents if various tools and resour ces are
already available to them. Examples include contact lists,
encryption software, network diagrams, backup devices, digital
forensic software, and port lists.
Prevent Incidents from Occurring by
Ensuring That Networks, Systems, and Applications Are
Sufficiently Secure—Preventing incidents is beneficial to the
organization and reduces the workload of the incident response
team. Performing periodic risk assessments and reducing the
identified risks to an acceptable level are effective in reducing
the number of incidents. Awareness of security policies and
procedures by users, IT staff, and management is also very
important.
Identify Precursors and Indicators Through
Alerts Generated by Several Types of Security Software—
Intrusion detection and prevention systems, antivirus software,
and file integrity checking software are valuable for detecting
signs of incidents. Each type of software may detect incidents
that the other types cannot, so the use of several types of
computer security software is highly recommended. Third-party
monitoring services can also be helpful.
Establish Mechanisms for Outside Parties
to Report Incidents—Outside parties may want to report
incidents to the organization—for example, they may believe
that one of the organization’s users is attacking them.
Organizations should publish a phone number and e-mail
address that outside parties can use to report such incidents.
Require a Baseline Level of Logging and
Auditing on All Systems, and a Higher Baseline Level on All

Critical Systems—Logs from operating systems, services, and
applications frequently provide value during incident analysis,
particularly if auditing was enabled. The logs can provide
information such as which accounts were accessed and what
actions were performed.
Profile Networks and Systems—Profiling
measures the characteristics of expected activity levels so that
changes in patterns can be more easily identified. If the
profiling process is automated, deviations from expected
activity levels can be detected and reported to administrators
quickly, leading to faster detection of incidents and operational
issues.
Understand the Normal Behaviors of
Networks, Systems, and Applications—Team members who
understand normal behavior should be able to recognize
abnormal behavior more easily. This knowledge can best be
gained by reviewing log entries and security alerts; the handlers
should become familiar with typical data and can investigate
unusual entries to gain more knowledge.
Create a Log Retention Policy—
Information about an incident may be recorded in several
places. Creating and implementing a log retention policy that
specifies how long log data should be maintained may be
extremely helpful in analysis because older log entries may
show reconnaissance activity or previous instances of similar
attacks.
Perform Event Correlation—Evidence of an
incident may be captured in several logs. Correlating events
among multiple sources can be invaluable in collecting all the
available information for an incident and validating whether the
incident occurred.

Keep All Host Clocks Synchronized—If the
devices that report events have inconsistent clock settings,
event correlation will be more complicated. Clock discrepancies
may also cause problems from an evidentiary standpoint.
Maintain and Use a Knowledge Base of
Information—Handlers need to reference information quickly
during incident analysis; a centralized knowledge base provides
a consistent, maintainable source of information. The
knowledge base should include general information such as data
on precursors and indicators of previous incidents.
Start Recording All Information as Soon as
the Team Suspects That an Incident Has Occurred—Every step
taken, from the time the incident was detected to its final
resolution, should be documented and time-stamped.
Information of this nature can serve as evidence in a court of
law if legal prosecution is pursued. Recording the steps
performed can also lead to a more efficient, systematic, and less
error-prone handling of the problem.
Safeguard Incident Data—This data often
contains sensitive information about vulnerabilities, security
breaches, and users who may have performed inappropriate
actions. The team should ensure that access to incident data is
properly restricted, both logically and physically.
Prioritize Handling of the Incidents Based
on the Relevant Factors—Because of resource limitations,
incidents should not be handled on a first-come, first-served
basis. Instead, organizations should establish written guidelines
that outline how quickly the team must respond to the incident
and what actions should be performed, based on relevant factors
such as the functional and information impact of the incident,
and the likely recoverability from the incident. This saves time
for the incident handlers and provides a justification to

management and system owners for their actions. Organizations
should also establish an escalation process for instances when
the team does not respond to an incident within the designated
time.
Include Provisions for Incident Reporting
in the Organization’s Incident Response Policy—Organizations
should specify which incidents must be reported, when they
must be reported, and to whom. The parties most commonly
notified are the CIO, head of information security, local
information security officer, other incident response teams
within the organization, and system owners.
Establish Strategies and Procedures for
Containing Incidents—It is important to contain incidents
quickly and effectively limit their business impact.
Organizations should define acceptable risks in containing
incidents and develop strategies and procedures accordingly.
Containment strategies should vary based on the type of
incident.
Follow Established Procedures for Evidence
Gathering and Handling—The team should clearly document
how all evidence has been preserved. Evidence should be
accounted for at all times. The team should meet with legal staff
and law enforcement agencies to discuss evidence handling,
then develop procedures based on those discussions.
Capture Volatile Data from Systems as
Evidence—This data includes lists of network connections,
processes, login sessions, open files, network interface
configurations, and the contents of memory. Running carefully
chosen commands from trusted media can collect the necessary
information without damaging the system’s evidence.
Obtain System Snapshots Through Full

Forensic Disk Images, Not File System Backups—Disk images
should be made to sanitized write-protectable or write-once
media. This process is superior to a file system backup for
investigatory and evidentiary purposes. Imaging is also valuable
in that it is much safer to analyze an image than it is to perform
analysis on the original system because the analysis may
inadvertently alter the original.
Hold Lessons-Learned Meetings After
Major Incidents—Lessons-learned meetings are extremely
helpful in improving security measures and the incident
handling process itself.*
Cichonski, P., Millar, T., Grance, T.
and Scarfone, K. “Special Publication 800-61, Rev 2: Computer
Security Incident Handling Guide.” Accessed 7/12/15 from
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8
00-61r2.pdf.
Note that most of these recommendations were covered earlier
in this section. CSIRT members should be very familiar with
these tools and techniques prior to an incident. Trying to use
unfamiliar procedures in the middle of an incident could prove
very costly to the organization and cause more harm than good.
For more information on incident handling, read the Incident
Handlers Handbook, which is available from the SANS reading
room at www.sans.org/reading-
room/whitepapers/incident/incident-handlers-handbook-33901,
or search for other incident handling papers at
www.sans.org/reading-room/whitepapers/incident/.
Organizational Philosophy on Incident and Disaster Handling
Eventually the organization will encounter incidents and

disasters that stem from an intentional attack on its information
assets by an individual or group, as opposed to one from an
unintentional source, such as a service outage, employee
mistake, or natural disaster.
At that point, the organization must choose one of two
philosophies that will affect its approach to IR and DR as well
as subsequent involvement of digital forensics and law
enforcement, as you will learn later in this chapter:
Protect and forget
The organizational CP philosophy that
focuses on the defense of information assets and preventing
reoccurrence rather than the attacker’s identification and
prosecution. Also known as “patch and proceed.”
—This approach, also known as “patch and
proceed,” focuses on the defense of data and the systems that
house, use, and transmit it. An investigation that takes this
approach focuses on the detection and analysis of events to
determine how they happened and to prevent reoccurrence. Once
the current event is over, the questions of who caused it and
why are almost immaterial.
Apprehend and prosecute
The organizational CP philosophy that
focuses on an attacker’s identification and prosecution, the
defense of information assets, and preventing reoccurrence.
Also known as “pursue and prosecute.”
—This approach, also known as “pursue and
prosecute,” focuses on the identification and apprehension of
responsible individuals, with additional attention paid to the
collection and preservation of potential evidentiary material that
might support administrative or criminal prosecution. This
approach requires much more attention to detail to prevent
contamination of evidence that might hinder prosecution.

An organization might find it impossible to retain enough data
to successfully handle even administrative penalties, but it
should certainly adopt the latter approach if it wants to pursue
formal administrative penalties, especially if the employee is
likely to challenge these penalties. The use of digital forensics
to aid in IR and DR when dealing with intentional attacks is
discussed later in this chapter, along with information for when
or if to involve law enforcement agencies.
View Point The Causes of Incidents and Disasters
Karen
Scarfone,
Principal Consultant, Scarfone Cybersecurity
Karen Scarfone, Principal Consultant,
Scarfone Cybersecurity
The term incident has somewhat different meanings in the
contexts of incident response and disaster recovery. People in
the incident response community generally think of an
“incident” as being caused by a malicious attack and a
“disaster” as being caused by natural causes (fire, flood,
earthquake, etc.). Meanwhile, people in the disaster recovery
community tend to use the term incident in a cause-free manner,
with the cause of the incident or disaster generally being
irrelevant and the difference between the two being based solely
on the scope of the event’s impact. An incident is a milder event
and a disaster is a more serious event.
The result of this is that people who are deeply embedded in the

incident response community often think of incident response as
being largely unrelated to disaster recovery, because they think
of a disaster as being caused by a natural disaster, not an attack.
Incident responders also often think of operational problems,
such as major service failures, as being neither incidents nor
disasters. Meanwhile, people who are deeply embedded in the
disaster recovery community see incident response and disaster
recovery as being much more similar and covering a much more
comprehensive range of problems.
So where does the truth lie? Well, it depends on the
organization. Some organizations take a more integrated
approach to business continuity and have their incident
response, disaster recovery, and other business continuity
components closely integrated with one another so that they
work together fairly seamlessly. Other organizations treat these
business continuity components as more discrete elements and
focus on making each element strong rather than establishing
strong commonalities and linkages among the components.
There are pluses and minuses to each of these approaches.
Personally, I find that the most important thing is to avoid turf
wars between the business continuity component teams. There is
nothing more frustrating than delaying the response to an
incident or disaster because people disagree on its cause. The
security folks say it’s an operational problem, the operational
folks say it’s a disaster, and the disaster folks say it’s a security
incident. So, like a hot potato, the event gets passed from team
to team while people argue about its cause. In reality, for some
problems, the cause is not immediatel y apparent.
What’s really important to any organization is that each adverse
event, regardless of the cause, be assessed and prioritized as
quickly as possible. That means that teams need to be willing to
step up and address adverse events whether or not the event is
clearly their responsibility. The impact of the incident is
generally the same, no matter what the cause is. If later
information shows that there’s a particular cause that better fits
a different team, the handling of the event can be transfer red to

the other team. Teams should be prepared to transfer events to
other teams and to receive transferred events from other teams
at any time.
The “CSI Computer Crime and Security Survey, 2010/2011”
describes how organizations have responded to intrusions.
Although the survey is a bit dated (and is no longer conducted)
it still provides a valuable look into how the average
organization prepares for and recovers from attack-based
incidents (intrusions):
62.3 percent—Patched any vulnerable software
49.3 percent—Patched or remediated other vulnerable hardware
or infrastructure
48.6 percent—Installed additional computer security software
44.2 percent—Conducted an internal forensic investigation
42.0 percent—Provided additional security awareness training
to their end users
40.6 percent—Changed their organization’s security policies
32.6 percent—Changed or replaced software or systems
27.5 percent—Reported the intrusion(s) to a law enforcement
agency
26.8 percent—Installed additional computer security hardware
26.1 percent—Reported intrusion(s) to their legal counsel
25.4 percent—Did not report the intrusion(s) to anyone outside
the organization
23.9 percent—Attempted to identify perpetrator using their own
resources
18.1 percent—Reported the intrusion(s) to individuals whose
personal data was breached
15.9 percent—Provided new security services to
users/customers
14.5 percent—Reported the intrusion(s) to business partners or
contractors
13.8 percent—Contracted a third-party forensic investigator
3.6 percent—Reported the intrusion(s) to public media*

“CSI Computer Crime and Security
Survey, 2010/2011.” Computer Security Institute. Accessed
7/12/15 from
http://reports.informationweek.com/abstract/21/7377/Security/re
search-2010-2011-csi-survey.html.
What is shocking is how few organizations notify individuals
that their personal data has been breached. Should it ever be
exposed to the public, those organizations could find themselves
confronted with criminal charges or corporate negligence suits.
Laws like the Sarbanes-Oxley Act of 2002 specifically
implement personal ethical liability requirements for
organizational management. Failure to report loss of personal
data can run directly afoul of these laws.
Listen

Open/close toolbar
Law Enforcement Involvement
When an incident or disaster violates civil or criminal law, it is
the organization’s responsibility to notify the proper authorities.
Selecting the appropriate law enforcement agency depends on
the type of crime committed. The Federal Bureau of
Investigation (FBI), for example, handles computer crimes that
cross state lines and investigates terrorism and cyberterrorism,
which can include attacks against businesses and other
organizations. The U.S. Secret Service examines crimes
involving U.S. currency, counterfeiting, credit cards, and
identity theft. The U.S. Treasury Department has a bank fraud
investigation unit, and the Securities and Exchange Commission
has investigation and fraud control units as well. However, the
heavy caseloads of these agencies mean that they typically
prioritize incidents that affect the national critical infrastructure
or that have significant economic impact. The FBI Web site, for
example, states that it has “built a whole new set of
technological and investigative capabilities and partnerships—
so we’re as comfortable chasing outlaws in cyberspace as we
are down back alleys and across continents.” It then describes
some of these capabilities and partnerships:
A “Cyber Division” at FBI headquarters to address cybercrime
in a coordinated and cohesive manner
Specially trained “cyber squads” at FBI headquarters and in
each of our 56 field offices, staffed with agents and analysts
who protect against and investigate computer intrusions, theft of
intellectual property and personal information, child
pornography and exploitation, and online fraud
New “Cyber Action Teams” that travel around the world on a
moment’s notice to assist in computer intrusion cases and that

gather vital intelligence that helps us identify the cybercrimes
that are most dangerous to our national security and to our
economy
Our 93 “Computer Crimes Task Forces” nationwide that
combine state-of-the-art technology and the resources of our
federal, state, and local counterparts
A growing partnership with other federal agencies, including
the Department of Defense, the Department of Homeland
Security, and others—which share similar concerns and resolve
in combating cyber crime
*
Federal Bureau of Investigation.
“Computer Intrusions.” Accessed 7/13/15 from
www.fbi.gov/about-us/investigate/cyber/computer-intrusions.
Each state, county, and city in the United States has its own law
enforcement agencies. These agencies enforce all local and state
laws, and they handle suspects and security at crime scenes for
state and federal cases. Local law enforcement agencies rarely
have computer crimes task forces, but the investigative
(detective) units are quite capable of processing crime scenes
and handling most common criminal violations, such as physical
theft or trespassing as well as damage to property, and including
the apprehension and processing of suspects in computer-related
crimes.
Involving law enforcement agencies has both advantages and
disadvantages. Such agencies are usually much better equipped
to process evidence than a business. Unless the security forces
in the organization have been trained in processing evidence
and computer forensics, they may do more harm than good when
attempting to extract information that can lead to the legal
conviction of a suspected criminal. Law enforcement agencies

are also prepared to handle the warrants and subpoenas
necessary when documenting a case. They are adept at obtaining
statements from witnesses, affidavits, and other required
documents. For all these reasons, law enforcement personnel
can be a security administrator’s greatest ally in prosecuting a
computer crime. It is therefore important to become familiar
with the appropriate local and state agencies before you have to
make a call to report a suspected crime. Most state and federal
agencies sponsor awareness programs, provide guest speakers at
conferences, and offer programs such as the FBI’s InfraGard
program, which is currently assigned to the Department of
Homeland Security’s Cyber Division. These agents clearly
understand the challenges facing security administrators.
For more information on the InfraGard program, including how
to find a chapter near you, visit their Web site at
www.infragard.net.
The disadvantages of law enforcement involvement include
possible loss of control over the chain of events following an
incident—for example, the collection of information and
evidence and the prosecution of suspects. An organization that
simply wants to reprimand or dismiss an employee should not
involve a law enforcement agency in the resolution of an
incident. Additionally, the organization may not hear about the
case for weeks or even months due to heavy caseloads or
resource shortages. A very real issue for commercial
organizations that involve law enforcement agencies is the
confiscation of vital equipment as evidence. Assets can be
removed, stored, and preserved to prepare the criminal case.
Despite these difficulties, if the organization detects a criminal
act, it has the legal obligation to notify appropriate law
enforcement officials. Failure to do so can subject the
organization and its officers to prosecution as accessories to the
crimes or for impeding the course of an investigation. It is up to
the security administrator to ask questions of law enforcement
agencies and determine when each agency should be involved,
and specifically to determine which crimes will be addressed by

each agency.
Listen
Open/close toolbar
Incident Response Planning
The scenario at the beginning of this chapter depicts an incident
and not a disaster, despite Joel’s declaration otherwise. By now,
it should be clear why a technology manager, like Iris, must
become involved in assessing the damage to two drenched
accounting offices and the break room. Because the incident at
RWW was determined by Iris to have caused minimal damage, a
corresponding IR plan would have been activated if RWW had a
properly developed IR plan. If the fire had spread beyond the

break room, triggered the sprinkler systems throughout the
building, and caused employee injuries, then an IR plan (even if
RWW had one) would not have been adequate to deal with the
situation. Instead, it would be necessary to initiate the DR plan
and the BC plan, both of which are discussed later in this
chapter. When one of the threats that were identified in
Chapters 1 and 2 is made manifest in an actual adverse event,
the adverse event is classified as an InfoSec incident, but only
if it has all of the following characteristics:
It is directed against information assets.
It has a realistic chance of success.
It threatens the confidentiality, integrity, or availability of
information resources and assets.
The prevention of threats and attacks has been intentionally
omitted from this discussion because guarding against such
possibilities is primarily the responsibility of the InfoSec
department, which works with the rest of the organization to
implement sound policy, effective risk controls, and ongoing
training and awareness programs. It is important to understand
that IR is a reactive measure, not a preventive one.
The responsibility for creating an organization’s IR plan usually
falls to the CISO or an IT manager with security
responsibilities. With the aid of other managers and systems
administrators on the CP team, the CISO should select members
from each community of interest to form an independent IR
team, which executes the IR plan. The roles and responsibilities
of the members of the IR team should be clearly documented
and communicated throughout the organization. The IR plan
also includes an alert roster, which lists certain critical agencies
to be contacted during the course of an incident.
Using the multistep CP process discussed in the previous
section as a model, the CP team can create the IR plan.
According to NIST SP 800-61, Rev. 2, the IR plan should
include the following elements:
Mission
Strategies and goals

Senior management approval
Organizational approach to incident response
How the incident response team will communicate with the rest
of the organization and with other organizations
Metrics for measuring incident response capability and its
effectiveness
Roadmap for maturing incident response capability
How the program fits into the overall organization*
Cichonski, P., Millar, T., Grance, T., and
Scarfone, K. “Special Publication 800-61, Rev. 2: Computer
http://nvlpubs.nist.gov/nistpubs/SpecialPublicatio ns/NIST.SP.8
00-61r2.pdf.
During this planning process, the
IR procedures
, commonly referred to as standard operating
procedures (SOPs), take shape. For every incident scenario, the
CP team creates three sets of incident-handling procedures:
During the Incident—The planners develop and
document the procedures that must be performed during the
incident. These procedures are grouped and assigned to
individuals. Systems administrators’ tasks differ from
managerial tasks, so members of the planning committee must
draft a set of function-specific procedures.
After the Incident—Once the procedures for
handling an incident are drafted, the planners develop and
document the procedures that must be performed immediately
after the incident has ceased. Again, separate functional areas
may develop different procedures.

Before the Incident—The planners draft a third
set of procedures, those tasks that must be performed to prepare
for the incident. These procedures include details of the data
backup schedules, disaster recovery preparation, training
schedules, testing plans, copies of service agreements, and BC
plans, if any. At this level, the BC plan could consist of just
additional material on a service bureau that stores data off-site
via electronic vaulting, with an agreement to provide office
space and lease equipment as needed.
Figure 10-7 presents an example of pages from the
IR plan that support each of these phases. Once these sets of
procedures are clearly documented, the IR portion of the IR
plan is assembled and the critical information outlined in these
planning sections is recorded.
Figure 10-7.
Example of IRP Incident-Handling Procedures
Planning for an incident and the responses to it requires a
detailed understanding of the information systems and the
threats they face. The BIA provides the data used to develop the
IR plan. The IRP team seeks to develop a series of predefined
responses that will guide the team and InfoSec staff through the
IR steps. Predefining incident responses enables the
organization to react to a detected incident quickly and
effectively, without confusion or wasted time and effort.
The execution of the IR plan typically falls to the CSIRT. As
noted previously, the CSIRT is a subset of the IR team and is
composed of technical and managerial IT and InfoSec
professionals prepared to diagnose and respond to an incident.

In some organizations, the CSIRT may simply be a loose or
informal association of IT and InfoSec staffers who would be
called up if an attack was detected on the organization’s
information assets. In other, more formal implementations, the
CSIRT is a set of policies, procedures, technologies, people,
and data put in place to prevent, detect, react to, and recover
from an incident that could potentially damage the
organization’s information. At some level, every member of an
organization is a member of the CSIRT, since every action they
take can cause or avert an incident.
The CSIRT should be available for contact by anyone who
discovers or suspects that an incident involving the organization
has occurred. One or more team members, depending on the
magnitude of the incident and availability of personnel, then
handle the incident. The incident handlers analyze the incident
data, determine the impact of the incident, and act appropriately
to limit the damage to the organization and restore normal
services. Although the CSIRT may have only a few members,
the team’s success depends on the participation and cooperation
of individuals throughout the organization.
The CSIRT consists of professionals who are capable of
handling the information systems and functional areas affected
by an incident. For example, imagine a firefighting team
responding to an emergency call. Rather than responding to the
fire as individuals, every member of the team has a specific role
to perform, so that the team acts as a unified body that assesses
the situation, determines the appropriate response, and
coordinates the response. Similarly, each member of the IR
team must know his or her specific role, work in concert with
other team members, and execute the objectives of the IR plan.
Incident response actions can be organized into three basic
phases:
Detection—Recognition that an incident is
under way

Reaction—Responding to the incident in a
predetermined fashion to contain and mitigate its potential
damage
Recovery—Returning all systems and data to
their state before the incident
Table 10-2 shows the incident handling checklist
from NIST SP 800-61, Rev 2.
Table 10-2.
Incident Handling Checklist from NIST SP 800-
61, Rev. 2ActionCompleted
Detection and Analysis
1.
Determine whether an incident has occurred
1.1
Analyze the precursors and indicators
1.2
Look for correlating information
1.3
Perform research (e.g., search engines,
knowledge base)
1.4
As soon as the handler believes an incident
has occurred, begin documenting the investigation and gathering
evidence
2.
Prioritize handling the incident based on
the relevant factors (functional impact, information impact,
recoverability effort, etc.)
3.
Report the incident to the appropriate
internal personnel and external organizations
Containment, Eradication, and Recovery

4.
Acquire, preserve, secure, and document
evidence
5.
Contain the incident
6.
Eradicate the incident
6.1
Identify and mitigate all vulnerabilities that
were exploited
6.2
Remove malware, inappropriate materials,
and other components
6.3
If more affected hosts are discovered (e.g.,
new malware infections), repeat the Detection and Analysis
steps (1.1, 1.2) to identify all other affected hosts, then contain
(5) and eradicate (6) the incident for them
7.
Recover from the incident
7.1
Return affected systems to an operationally
ready state
7.2
Confirm that the affected systems are
functioning normally
7.3
If necessary, implement additional
monitoring to look for future related activity
Post-Incident Activity
8.
Create a follow-up report
9.
Hold a lessons learned meeting (mandatory

for major incidents, optional otherwise)*
While not explicitly noted in the NIST document, most
organizations will document the findings from this activity and
use it to update relevant plans, policies, and procedures.
Source: NIST SP 800-61, Rev. 2.
Data Protection in Preparation for Incidents
An organization has several options for protecting its
information and getting operations up and running quickly after
an incident:
Traditional Data Backups—The organization
can use a combination of on-site and off-site tape-drive or hard-
drive backup methods, in a variety of rotation schemes; because
the backup point is some time in the past, recent data is
potentially lost. Most common data backup schemes involve
random array of independent disks (RAID) or disk-to-disk-to-
tape methods.
Electronic Vaulting—The organization can
employ bulk batch-transfer of data to an off-site facility;
transfer is usually conducted via leased lines or secure Internet
connections. The receiving server archives the data as it is
received. Some DR companies specialize in
electronic vaulting
A backup method that uses bulk batch
transfer of data to an off-site facility; this transfer is usually
conducted via leased lines or secure Internet connections.

Incident response procedures (IR procedures) Detailed, step-by-
step methods of preparing, detecting, reacting to, and
recovering from an incident.
services.
Remote Journaling—The organization can
transfer live transactions to an off-site facility;
remote journaling
The backup of data to an off-site facility in
close to real time based on transactions as they occur.
differs from electronic vaulting in two ways:
(1)
Only transactions are transferred, not archived data; and(2)
the transfer takes place online and in much closer to real time.
While electronic vaulting is akin to a traditional backup, with a
dump of data to the off-site storage, remote journaling involves
online activities on a systems level, much like server fault
tolerance, where data is written to two locations simultaneously.
Database Shadowing—The organization can
store duplicate online transaction data, along with duplicate
databases, at the remote site on a redundant server;
database shadowing
A backup strategy to store duplicate online
transaction data along with duplicate databases at the remote
site on a redundant server. This server combines electronic
vaulting with remote journaling by writing multiple copies of
the database simultaneously to two locations.
combines electronic vaulting with remote
journaling by writing multiple copies of the database
simultaneously to two separate locations.
Industry recommendations for data backups include the “3-2-1
rule,” which encourages maintaining three copies of important

data (the original and two backup copies) on at least two
different media (like hard drives and tape backups), with at
least one copy stored off-site.
Listen
Open/close toolbar
Affidavits and Search Warrants
Many investigations begin with an allegation or an indication of
an incident. Whether via the help desk, the organization’s
sexual harassment reporting channels, or direct report, someone
makes an allegation that another worker is performing actions
explicitly prohibited by the organization or that make another
worker uncomfortable in the workplace. The organization’s

forensics team must then request permission to examine digital
media for potential EM. In law enforcement, the investigating
agent would create an
affidavit
Sworn testimony that certain facts are in the
possession of the investigating officer and that they warrant the
examination of specific items located at a specific place. The
facts, the items, and the place must be specified in this
document.
requesting a
search warrant
Permission to search for evidentiary material at a
specified location and/or to seize items to return to the
investigator’s lab for examination. An affidavit becomes a
search warrant when signed by an approving authority.
. When an approving authority signs the affidavit or
creates a synopsis form based on this document, it becomes a
search warrant and grants permission to search for EM at the
specified location and/or to seize items to return to the
investigator’s lab for examination. In corporate environments,
the names of these documents may change and in many cases
may be verbal in nature, but the process should be the same.
Formal permission is obtained before an investigation occurs.
Listen

Open/close toolbar
Evidentiary Policy and Procedures
In information security, most operations focus on policies—
those documents that provide managerial guidance for ongoing
implementation and operations. In digital forensics, however,
the focus is on procedures. When investigating digital
malfeasance or performing root cause analysis, keep in mind
that the results and methods of the investigation may end up in
criminal or civil court. For example, during a routine systems
update, a technician finds objectionable material on an
employee’s computer. The employee is fired and promptly sues
the organization for wrongful termination, and so the
investigation of that objectionable material will come under
scrutiny by the plaintiff’s attorney, who will attempt to cast
doubt on the ability of the investigator. While technically not
illegal, the presence of the material may have been a clear
violation of policy, thus prompting the dismissal of the
employee, but if an attorney can convince a jury or judge that
someone else could have placed the material on the plaintiff’s
system, then the employee could win the case and potentially a
large financial settlement.
When the scenario involves criminal issues, where an employee
discovers evidence of a crime, the situation changes somewhat.
The investigation, analysis, and report are typically performed

by law enforcement personnel. However, if the defense attorney
can cast reasonable doubt on whether organizational InfoSec
professionals compromised the digital EM, the employee might
win the case.
How do you avoid these legal pitfalls? Strong procedures for
the handling of potential EM can minimize the probability of an
organization’s losing a legal challenge. Organizations should
develop specific procedures, along with guidance (as in policy)
on the use of these procedures. The
EM policy
The policy document that guides the development
and implementation of EM procedures regarding the collection,
handling, and storage of items of potential evidentiary value, as
well as the organization and conduct of EM collection teams.
document should specify:
Who may conduct an investigation
Who may authorize an investigation
What affidavit-related documents are required
What search warrant-related documents are required
What digital media may be seized or taken offline
What methodology should be followed
What methods are required for chain of custody or chain of
evidence
What format the final report should take and to whom it should
it be given
The policy document should be supported by a procedures
manual based on the documents discussed earlier, along with
guidance from law enforcement or consultants. By creating and
using these policies and procedures, an organization can best
protect itself from challenges by employees who have been
subject to unfavorable action (administrati ve or legal) resulting
from an investigation.
Once the policy is in place, the organization can develop EM
procedures to guide the actual collection, handling, processing,
and storage of EM. Note that both the policy and procedures
documents may be developed independently, or may be part of

the organization’s digital forensics document set. Either way, it
is imperative that formalized documents are developed,
reviewed, and approved, so that if the organization’s handling
of EM is challenged, those responsible for handling the
information can assert their compliance with established
policies and procedures. Unless the organization has completely
committed to the protect and forget philosophy, most likely all
EM processing (as in investigation) will be performed by a law
enforcement agency.
Listen
Open/close toolbar
Managing Investigations in the Organization

When—not if—an organization finds itself having to deal with a
suspected policy or law violation, it must appoint an individual
to investigate it. How the internal investigation proceeds will
dictate whether or not the organization has the ability to take
action against the perpetrator if in fact evidence is found that
substantiates the charge. In order to protect the organization and
possibly to assist law enforcement in the conduct of an
investigation, the investigator (whether the CISO, InfoSec
manager, or other appointed individual) must document what
happened and how. The investigation of what happened and how
is called digital forensics.
Digital forensics is based on the field of traditional
forensics
The coherent application of methodical
investigatory techniques to present evidence of crimes in a court
or court-like setting. Forensics allows investigators to
determine what happened by examining the results of an event—
criminal, natural, intentional, or accidental.
. Forensics allows investigators to determine what
happened by examining the results of an event—criminal,
natural, intentional, or accidental. It also allows them to
determine how the event happened by examining activities,
individual actions, physical evidence, and testimony related to
the event. What it may never do is figure out the why.
Digital forensics
Investigations involving the preservation,
identification, extraction, documentation, and interpretation of
computer media for evidentiary and root cause analysis. Like
traditional forensics, digital forensics follows clear, well -
defined methodologies but still tends to be as much art as
science.
involves applying traditional forensics
methodologies to the digital arena, focusing on information
stored in an electronic format on any one of a number of

electronic devices that range from computers to mobile phones
to portable media. Like forensics, it follows clear, well -defined
methodologies but still tends to be as much art as science. This
means the natural curiosity and personal skill of the investigator
play a key role in discovering potential
evidentiary material (EM)
Also known as “items of potential evidentiary
value,” any information that could potentially support the
organization’s legal or policy-based case against a suspect.
, also known as items of potential evidentiary value.
An item does not become evidence until it is formally admitted
to evidence by a judge or other ruling official.
Related to the field of digital forensics is
e-discovery
The identification and preservation of evidentiary
material related to a specific legal action.
. Digital forensics and e-discovery are related in that
digital forensics tools and methods may be deployed to conduct
e-discovery or to extract information identified during e-
discovery; however, e-discovery may simply focus on extensive
e-mail and database searches to identify information related to
specific key terms. Digital forensics used after litigation has
begun falls under the umbrella of e-discovery. Digital forensics
used prior to the initiation of legal proceedings falls under the
umbrella of incident response (IR).
Based on this premise, digital forensics can be used for two key
purposes:
To Investigate Allegations of Digital
Malfeasance—Investigating
digital malfeasance
A crime against or using digital media,
computer technology, or related components; in other words, a
computer is the source of a crime or the object of a crime.
is similar to e-discovery, as they are conducted
after legal proceedings have begun.

To Perform Root Cause Analysis—If an incident
occurs and the organization suspects an attack was successful,
digital forensics can be used to examine the path and
methodology used to gain unauthorized access as well as to
determine how pervasive and successful the attack was.
Performing root cause analysis is directly related to IR. The IR
team will use root cause analysis when examining their
equipment after an incident.
Some investigations can be undertaken by organizational
personnel, while others require immediate involvement of law
enforcement. In general, whenever investigators discover
evidence of the commission of a crime, they should immediately
notify management and recommend contacting law enforcement.
Failure to do so could result in unfavorable action against the
investigator or organization.
Listen

Open/close toolbar
Digital Forensics Team
Most organizations cannot sustain a permanent digital forensics
team. In most organizations, such expertise is so rarely called
upon that it may be better to collect the data and then outsource
the analysis component to a regional expert. The organization
can then maintain an arm’s-length distance from the case and
have additional expertise to call upon in the event the process
ends in court. Even so, there should be people in the InfoSec
group trained to understand and manage the forensics process.
Should a report of suspected misuse from an internal or external
individual arise, this person or group must be familiar with
digital forensics procedures in order to avoid contaminating
potential EM. This expertise can be obtained by sending staff
members to a regional or national InfoSec conference with a
digital forensics track, or to dedicated digital forensics training.
Listen

Open/close toolbar
Final Thoughts on CP
As in all organizational efforts, iteration results in
improvement. A critical component of the NIST-based
methodologies presented in this chapter is continuous process
improvement (CPI). Each time the organization rehearses its
plans, it should learn from the process, improve the plans, and
then rehearse again. Each time an incident or disaster occurs,
the organization should review what went right and what went
wrong. The actual results should be so thoroughly analyzed that
any changes to the plans that could have resulted in an
improved outcome will be implemented into a revised set of
plans. Through ongoing evaluation and improvement, the
organization continues to move forward and continually
improves upon the process so that it can strive for an even
better outcome.
Listen

Open/close toolbar
Testing Contingency Plans
Very few plans are executable as initially written; instead, they
must be tested to identify vulnerabilities, faults, and inefficient
processes. Once problems are identified during the testing
process, improvements can be made, and the resulting plan can
be relied on in times of need. The following strategies can be
used to test contingency plans:
Desk check
The CP testing strategy in which copies of the
appropriate plans are distributed to all individuals who will be
assigned roles during an actual incident or disaster; each
individual reviews the plan and validates its components.
—The simplest kind of validation involves
distributing copies of the appropriate plans to all individuals
who will be assigned roles during an actual incident or disaster.
Each of these individuals performs a desk check by reviewing
the plan and creating a list of correct and incorrect components.
While not a true test, this strategy is a good way to review the

perceived feasibility and effectiveness of the plan and ensure at
least a nominal update of the policies and plans.
Structured walk-through
The CP testing strategy in which all involved
individuals walk through a site and discuss the steps they would
take during an actual CP event. A walk-through can also be
conducted as a conference room talk-through.
—In a structured walk-through, all involved
individuals walk through the steps they would take during an
actual incident or disaster. This exercise can consist of an on-
site walk-through, in which everyone discusses their actions at
each particular location and juncture, or it may be more of a
talk-through
A form of structured walk-through in which
individuals meet in a conference room and discuss a CP plan
rather than walking around the organization.
, in which all involved individuals sit around a
conference table and discuss, in turn, their responsibilities as
the incident unfolds.
Simulation
The CP testing strategy in which the
organization conducts a role-playing exercise as if an actual
incident or disaster had occurred. The CP team is presented with
a scenario in which all members must specify how they would
react and communicate their efforts.
—In a simulation, the organization creates a role-
playing exercise in which the CP team is presented with a
scenario of an actual incident or disaster and expected to react
as if it had occurred. The simulation usually involves
performing the communications that should occur and
specifying the required physical tasks, but it stops short of
performing the actual tasks required, such as installing the

backup data or disconnecting a communications circuit. The
major difference between a walk-through and a simulation is
that in simulations, the discussion is driven by a scenario,
whereas walk-throughs focus on simply discussing the plan in
the absence of any particular incident or disaster. Simulations
tend to be much more structured, with time limits, planned
AARs, and moderators to manage the scenarios.
Full-interruption testing
The CP testing strategy in which all team
members follow each IR/DR/BC procedure, including those for
interruption of service, restoration of data from backups, and
notification of appropriate individuals.
—In full-interruption testing, the individuals
follow each and every IR/DR/BC procedure, including the
interruption of service, restoration of data from backups, and
notification of appropriate individuals. This exercise is often
performed after normal business hours in organizations that
cannot afford to disrupt or simulate the disruption of business
functions. Although full-interruption testing is the most
rigorous testing strategy, it is unfortunately too risky for most
businesses.
At a minimum, organizations should conduct periodic walk-
throughs (or talk-throughs) of each of the CP component plans.
Failure to update these plans as the business and its information
resources change can erode the team’s ability to respond to an
incident, or possibly cause greater damage than the incident
itself. If this sounds like a major training effort, note what the
author Richard Marcinko, a former Navy SEAL, has to say
about motivating a team:*
Marcinko, R., and J. Weisman. Designation
Gold. New York: Pocket Books, 1998.

The more you sweat to train, the less you bleed in combat.
Training and preparation can hurt.
Lead from the front, not the rear.
You don’t have to like it; you just have to do it.
Keep it simple.
Never assume.
You are paid for results, not methods.
One often-neglected aspect of training is cross-training. In a
real incident or disaster, the people assigned to particular roles
are often not available. In some cases, alternate people must
perform the duties of personnel who have been incapacitated by
the disastrous event that triggered the activation of the plan.
The testing process should train people to take over in the event
that a team leader or integral member of the execution team is
unavailable.
Listen

Open/close toolbar
Timing and Sequence of CP Elements
As indicated earlier, the IR plan focuses on immediate response,
but if the incident escalates into a disaster, the IR plan may give
way to the DR plan and BC plan, as illustrated in Figure 10-9.
The DR plan typically focuses on restoring systems after
disasters occur and is therefore closely associated with the BC
plan. The BC plan occurs concurrently with the DR plan when
the damage is major or long term, requiring more than simple
restoration of information and information resources, as
illustrated in Figure 10-10.
Figure 10-9.
Incident Response and Disaster Recovery
Figure 10-10.
Disaster Recovery and Business Continuity
Planning
Some experts argue that the three planning components (IR, DR,
and BC) of CP are so closely linked that they are

indistinguishable. Actually, each has a distinct place, role, and
planning requirement. Furthermore, each component comes into
play at a specific time in the life of an incident. Figure 10-11
illustrates this sequence and shows the overlap that may occur.
How the plans interact and the ways in which they are brought
into action are discussed in the following sections.
Figure 10-11.
Contingency Planning Implementation Timeline
Listen

Open/close toolbar
Crisis Management
Another process that many organizations plan for separately is
crisis management (CM)
An organization’s set of planning and preparation
efforts for dealing with potential human injury, emotional
trauma, or loss of life as a result of a disaster.
, which focuses more on the effects that a disaster has
on people than its effects on information assets. While some
organizations include crisis management as a subset of the DR
plan, the protection of human life and the organization’s image
is such a high priority that it may deserve its own committee,
policy, and plan. Thus, the organization should form a crisis
management planning team (CMPT), which then organizes a
crisis management response team (CMRT). The appropriate
DRRT works closely with the CMRT to assure complete and
timely communication during a disaster. According to Gartner
Research, the crisis management team is responsible for
managing the event from an enterprise perspective and performs
the following roles:
Supporting personnel and their loved ones during the crisis
Keeping the public informed about the event and the actions
being taken to ensure the recovery of personnel and the
enterprise
Communicating with major customers, suppliers, partners,
regulatory agencies, industry organizations, the media, and
other interested parties*
Witty, R. “What is Crisis Management?”
Gartner Online, September 19, 2001. Accessed 7/13/15 from
www.gartner.com/doc/340971.

The CMPT should establish a base of operations or command
center near the site of the disaster as soon as possible. The
CMPT should include individuals from all functional areas of
the organization in order to facilitate communications and
cooperation. The CMPT is charged with three primary
responsibilities:
Verifying Personnel Status—Everyone must be
accounted for, including individuals who are on vacations,
leaves of absence, and business trips.
Activating the Alert Roster—Alert rosters and
general personnel phone lists are used to notify individuals
whose assistance may be needed or simply to tell employees not
to report to work until the disaster is over.
Coordinating with Emergency Services—If
someone is injured or killed during a disaster, the CM response
team will work closely with fire officials, police, medical
response units, and the Red Cross to provide appropriate
services to all affected parties as quickly as possible.
The CMPT should plan an approach for releasing information in
the event of a disaster and should perhaps even have boilerplate
scripts prepared for press releases. Advice from Lanny Davis,
former counselor to President Bill Clinton, is relevant here.
When beset by damaging events, heed the subtitle to Davis’s
memoir: Tell It Early, Tell It All, Tell It Yourself.*
Davis, L. Truth to Tell: Tell It Early, Tell It
All, Tell It Yourself: Notes from My White House Education.
New York: Free Press, May 1999.

As with IR, DR, and BC, if CM is organized and conducted as a
separate entity, it should have a
CM policy
and implementation of CM plans and the formulation and
performance of CM teams.
and a
CM plan
The documented product of crisis management
planning; a plan that shows the organization’s intended efforts
to protect its personnel and respond to safety threats.
. The methodologies for CM policies and
CM planning (CMP)
The actions taken by senior management to develop
and implement the CM policy, plan, and response teams.
can follow the same basic models as DR policies and
plans, but they should include additional content focused on
personnel safety (such as shelter areas), evacuation plans,
contact information for emergency services, and the like.
For more information, including crisis management materials
focused on crises in schools, visit the Department of Defense
Educational Activity site at www.dodea.edu/crisis/.
Listen

Open/close toolbar
Business Continuity Policy
BCP begins with the development of the
BC policy
and implementation of BC plans and the formulation and
performance of BC teams.
, which reflects the organization’s philosophy on
the conduct of BC operations and serves as the guiding
document for the development of BCP. The BC team leader
might receive the BC policy from the CP team or might guide
the BC team in developing one. The BC policy contains the
following key sections:
Purpose—The purpose of the BC program is to
provide the necessary planning and coordination to help
relocate critical business functions should a disaster prohibit
continued operations at the primary site.
Scope—This section identifies the
organizational units and groups of employees to which the
policy applies. This is especially useful in organizations that are
geographically dispersed or that are creating different policies
for different organizational units.

Roles and Responsibilities—This section
identifies the roles and responsibilities of key players in the BC
operation, from executive management down to individual
employees. In some cases, sections may be duplicated from the
organization’s overall CP policy. In smaller organizations, this
redundancy can be eliminated because many of the functions are
performed by the same group of individuals.
Resource Requirements—Organizations can
allocate specific resources to the development of BC plans.
Although this may include directives for individuals, it can be
separated from the roles and responsibilities section for
emphasis and clarity.
Training Requirements—This section specifies
the training requirements for the various employee groups.
Exercise and Testing Schedules—This section
stipulates the frequency of BC plan testing and can include both
the type of exercise or testing and the individuals involved.
Plan Maintenance Schedule—This section
specifies the procedures and frequency of BC plan revi ews and
identifies the personnel who will be involved in the review. It is
not necessary for the entire BC team to be involved; the review
can be combined with a periodic test of the BC (as in a talk-
through) as long as the resulting discussion includes areas for
improvement of the plan.
Special Considerations—In extreme situations,
the DR and BC plans overlap, as described earlier. Thus, this
section provides an overview of the information storage and
retrieval plans of the organization. While the specifics do not
have to be elaborated in this document, at a minimum the plan
should identify where more detailed documentation is kept,

which individuals are responsible, and any other information
needed to implement the strategy.
You may have noticed that this structure is virtually identical to
that of the disaster recovery policy and plans. The processes are
generally the same, with minor differences in implementation.
The identification of critical business functions and the
resources to support them is the cornerstone of the BC plan.
When a disaster strikes, these functions are the first to be
reestablished at the alternate site. The CP team needs to appoint
a group of individuals to evaluate and compare the various
alternatives and to recommend which strategy should be
selected and implemented. The strategy selected usually
involves an off-site facility, which should be inspected,
configured, secured, and tested on a periodic basis. The
selection should be reviewed periodically to determine whether
a better alternative has emerged or whether the organization
needs a different solution.
Many organizations with operations in New York City had their
BC efforts (or lack thereof) tested critically on September 11,
2001. Similarly, organizations on the U.S. Gulf Coast had their
BC plan effectiveness tested during the aftermath of Hurricane
Katrina in 2005.
Listen

Open/close toolbar
Business Continuity
Sometimes, disasters have such a profound effect on the
organization that it cannot continue operations at its primary
site until it fully completes all DR efforts. To deal with such
events, the organization implements its
business continuity (BC)
An organization’s set of efforts to ensure its long-
term viability when a disaster precludes normal operations at
the primary site. The organization temporarily establishes
critical operations at an alternate site until it can resume
operations at the primary site or select and occupy a new
primary site.
strategies.
Business continuity planning (BCP)
and implement the BC policy, plan, and continuity teams.
ensures that critical business functions can continue
if a disaster occurs. Unlike the DR plan, which is usually
managed by the IT community of interest, the
BC plan
The documented product of business continuity

to continue critical functions when operations at the primary
site are not feasible.
is most properly managed by the CEO or COO of an
organization. It is activated and executed concurrently with the
DR plan when the disaster is major or long term and requires
fuller and more complex restoration of information and IT
resources. If a disaster renders the current business location
unusable, there must be a plan to allow the business to continue
to function. While the BC plan reestablishes critical business
functions at an alternate site, the DR plan team focuses on the
reestablishment of the technical infrastruc ture and business
operations at the primary site. Not every business needs such a
plan or such facilities. Some small companies or fiscally sound
organizations may be able simply to cease operations until the
primary facilities are restored. Manufacturing and retail
organizations, however, depend on continued operations for
revenue. Thus, these entities must have a BC plan in place so as
to relocate operations quickly with minimal loss of revenue.
BC is an element of CP, and it is best accomplished using a
repeatable process or methodology. NIST's “Special Publication
800-34, Rev. 1: Contingency Planning Guide for Federal
Information Systems”* includes guidance for planning for
incidents, disasters, and situations calling for BC. The approach
used in that document has been adapted for BC use here.
Swanson, M., P. Bowen, A. Phillips, D. Gallup,
and D. Lynes. “Special Publication 800-34, Rev. 1: Contingency
Planning Guide for Federal Information Systems.” National
Institute of Standards and Technology. Accessed 7/13/15 from
http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-
rev1_errata-Nov11-2010.pdf.
The first step in all contingency efforts is the development of

policy; the next step is planning. In some organizations, these
are considered concurrent operations where development of
policy is a function of planning, while in others policy comes
before planning and is a separate process. In this text, the BC
policy is developed prior to the BC plan; and both are
developed as part of BC planning. The same seven-step
approach that NIST recommends for CP can be adapted to an
eight-step model that can be used to develop and maintain a
viable BC program. Those steps are as follows:
Form the BC Team—As was done with the DR
planning process, the initial assignments to the BC team,
including the team lead, will most likely be performed by the
CPMT; however, additional personnel may need to be assigned
to the team as the specifics of the BC policy and plan are
developed, and their individual roles and responsibilities will
have to be defined and assigned.
Develop the BC Planning Policy Statement—A
formal organizational policy provides the authority and
guidance necessary to develop an effective continuity plan. As
with any enterprise-wide policy process, it is important to begin
with the executive vision.
Review the BIA—Information contained within
the BIA can help identify and prioritize critical organizational
functions and systems for the purposes of business continuity,
making it easier to understand what functions and systems will
need to be reestablished elsewhere in the event of a disaster.
Identify Preventive Controls—Little is done here
exclusively for BC. Most of the steps taken in the CP and DRP
processes will provide the necessary foundation for BCP.
Create Relocation Strategies—Thorough
relocation strategies ensure that critical business functions will

be reestablished quickly and effectively at an alternate location,
following a disruption.
Develop the BC Plan—The BC plan should
contain detailed guidance and procedures for implementing the
BC strategies at the predetermined locations in accordance with
management’s guidance.
Ensure BC Plan Testing, Training, and
Exercises—Testing the plan identifies planning gaps, whereas
training prepares recovery personnel for plan activation; both
activities improve plan effectiveness and overall agency
preparedness.
Ensure BC Plan Maintenance—The plan should
be a living document that is updated regularly to remain current
with system enhancements.
Listen

Open/close toolbar
Responding to the Disaster
When a disaster strikes, actual events can at times overwhelm
even the best of DR plans. To be prepared, the CPMT should
incorporate a degree of flexibility into the plan. If the physical
facilities are intact, the DR team should begin the restoration of
systems and data to work toward full operational capability. If
the organization’s facilities are destroyed, alternative actions
must be taken until new facilities can be acquired. When a
disaster threatens the viability of an organization at the primary
site, the DR process becomes a business continuity process,
which is described next.
Listen

Open/close toolbar
Simple Disaster Recovery Plan
Figure 10-8 shows an example of what may be
found in a simple DR plan. The plan has nine major sections,
each of which is outlined below. Many organizations—
particularly ones with multiple locations and hundreds of
employees—would find this plan too simple. Nevertheless, the
basic structure provides a solid starting point for any
organization.
Name of Company—The first section identifies
the department, division, or institution to which this particular
plan applies. This identification is especially important in
organizations that are large enough to require more than one
plan.
Date of Completion or Update of the Plan and
the Date of the Most Recent Test.
Staff to Be Called in the Event of a Disaster—
This roster should be kept current; it will not help the
organization to have a list of employees who are no longer with
the company. This section should also identify key support
personnel, such as building maintenance supervisors, physical
security directors, legal counsel, and the starting points on the
alert roster. A copy of the alert roster (also known as the
telephone tree) should be attached.

Emergency Services to Be Called (if Needed) in
Event of a Disaster—While dialing 911 will certainly bring
police, fire, and ambulance services, the organization may have
equally pressing needs for emergency teams from the gas,
electric, and water companies. This section should also list
electricians, plumbers, locksmiths, and software and hardware
vendors.
Locations of In-House Emergency Equipment
and Supplies—This section should include maps and floor plans
with directions to all critical in-house emergency materials,
including shut-off switches and valves for gas, electric, and
water. Directions to key supplies, including first aid kits, fire
extinguishers, flashlights, batteries, and a stash of office
supplies, should also be provided. It is a good idea to place a
disaster pack on every floor in an unlocked closet or readily
accessible location. These items should be inventoried and
updated as needed.
Sources of Off-Site Equipment and Supplies—
These items include contact sources for mobile phones,
dehumidifiers, industrial equipment (such as forklifts and
portable generators), and other safety and recovery components.
Salvage Priority List—While the IT director
may have just enough time to grab the last on-site backup
before darting out the door in the event of a fire, additional
materials can most likely be salvaged if recovery efforts permit.
In this event, recovery teams should know what has priority.
This list should specify whether to recover hard copies or if the
effort should be directed toward saving equipment. Similarly, it
specifies whether the organization should focus on archival
records or recent documents. The plan should include the
locations and priorities of all items of value to the organization.
When determining priorities, ask questions such as: Are these

records archived elsewhere (i.e., off-site), or is this the only
copy? Can these records be reproduced if lost, and if so, at what
cost? Is the cost of replacement more or less than the cost of the
value of the materials? It may be useful to create a simple rating
scheme for materials. Data classification labels can be adapted
to include DR information. For example, some records may be
labeled “Salvage at all costs,” “Salvage if time and resources
permit,” or “Do not salvage.”
Disaster Recovery Procedures—This very
important section outlines the specific assignments given to key
personnel, including the DR team, to be performed in the event
of a disaster. If these duties differ by type of disaster, it may be
useful to create multiple scenarios, each listing the duties and
responsibilities of the parties involved. It is equally important
to make sure that all personnel identified in this section have a
copy of the DR plan stored where they can easily access it, and
that they are familiar with their responsibilities.
Follow-up Assessment—The final section
details what is to be accomplished after disaster strikes —
specifically, what documentation is required for recovery
efforts, including mandatory insurance reports, required
photographs, and the AAR format.
Figure 10-8.
Example Disaster Recovery Plan
Listen

Open/close toolbar
Planning to Recover
To plan for disaster, the CPMT engages in scenario
development and impact analysis, along the way categorizing
the level of threat that each potential disaster poses. When
generating a DR scenario, start with the most important asset:
people. Do you have the human resources with the appropriate
organizational knowledge to restore business operations?
Organizations must cross-train their employees to ensure that
operations and a sense of normalcy can be restored. In addition,
the DR plan must be tested regularly so that the DR team can
lead the recovery effort quickly and efficiently. Key elements
that the CPMT must build into the DR plan include the
following:
Clear Delegation of Roles and

Responsibilities—Everyone assigned to the DR team should be
aware of his or her duties during a disaster. Some team members
may be responsible for coordinating with local services, such as
fire, police, and medical personnel. Some may be responsible
for the evacuation of company personnel, if required. Others
may be assigned to simply pack up and leave.
Execution of the Alert Roster and Notification
of Key Personnel—These notifications may extend outside the
organization to include the fire, police, or medical services
mentioned earlier, as well as insurance agencies, disaster teams
such as those of the Red Cross, and management teams.
Clear Establishment of Priorities—During a
disaster response, the first priority is always the preservation of
human life. Data and systems protection is subordinate when the
disaster threatens the lives, health, or welfare of the employees
or members of the community. Only after all employees and
neighbors have been safeguarded can the DR team attend to
protecting other organizational assets.
Procedures for Documentation of the Disaster—
Just as in an incident response, the disaster must be carefully
recorded from the onset. This documentation is used later to
determine how and why the disaster occurred.
Action Steps to Mitigate the Impact of the
Disaster on the Operations of the Organization—The DR plan
should specify the responsibilities of each DR team member,
such as the evacuation of physical assets or making sure that all
systems are securely shut down to prevent further loss of data.
Alternative Implementations for the Various
System Components, Should Primary Versions Be
Unavailable—These components include stand-by equipment,
either purchased, leased, or under contract with a DR service

agency. Developing systems with excess capacity, fault
tolerance, autorecovery, and fail-safe features facilitates a quick
recovery. Something as simple as using Dynamic Host Control
Protocol (DHCP) to assign network addresses instead of using
static addresses can allow systems to regain connectivity
quickly and easily without technical support. Networks should
support dynamic reconfiguration; restoration of network
connectivity should be planned. Data recovery requires
effective backup strategies as well as flexible hardware
configurations. System management should be a top priority.
All solutions should be tightly integrated and developed in a
strategic plan to provide continuity. Piecemeal construction can
result in a disaster after the disaster, as incompatible systems
are unexpectedly thrust together.
As part of DR plan readiness, each employee should have two
types of emergency information card in his or her possession at
all times. The first lists personal emergency information—the
person to notify in case of an emergency (next of kin), medical
conditions, and a form of identification. The second contains a
set of instructions on what to do in the event of an emergency.
This snapshot of the DR plan should contain a contact number
or hotline for calling the organization during an emergency,
emergency services numbers (fire, police, medical), evacuation
and assembly locations (e.g., storm shelters), the name and
number of the DR coordinator, and any other needed
information.
Listen

Open/close toolbar
Disaster Recovery Policy
As noted in step 2 of the preceding list, the DR team, led by the
manager designated as the DR team leader, begins with the
development of the
DR policy
and implementation of DR plans and the formulation and
performance of DR teams.
soon after the team is formed. The policy presents
an overview of the organization’s philosophy on the conduct of
DR operations and serves as the guide for the development of
the DR plan. The DR policy itself may have been created by the
organization’s CP team and handed down to the DR team leader.
Alternatively, the DR team may be assigned the role of
developing the DR policy. In either case, the DR policy
contains the following key elements:
Purpose—The purpose of the DR program is to
provide direction and guidance for all DR operations. In
addition, the program provides for the development and support

of the DR plan. In everyday practice, those responsible for the
program must also work to emphasize the importance of
creating and maintaining effective DR functions. As with any
major enterprise-wide policy effort, it is important for the DR
program to begin with a clear statement of executive vision.
Scope—This section of the policy identifies the
organizational units and groups of employees to which the
policy applies. This clarification is important if the organization
is geographically dispersed or is creating different policies for
different organizational units.
Roles and Responsibilities—This section of the
policy identifies the roles and responsibilities of the key players
in the DR operation. It can include a delineation of the
responsibilities of executive management down to individual
employees. Some sections of the DR policy may be duplicated
from the organization’s overall CP policy. In smaller
organizations, this redundancy can be eliminated, as many of
the functions are performed by the same group.
Resource Requirements—An organization can
allocate specific resources to the development of DR plans here.
While this may include directives for individuals, it can be
separated from the previous section for emphasis and clarity.
Training Requirements—This section defines
and highlights the training requirements for the units within the
organization and the various categories of employees.
Exercise and Testing Schedules—This section
stipulates the testing intervals of the DR plan as well as the type
of testing and the individuals involved.
Plan Maintenance Schedule—This section states
the required review and update intervals of the plan, and

identifies who is involved in the review. It is not necessary for
the entire DR team to be involved, but the review can be
combined with a periodic test of the DR plan as long as the
resulting discussion includes areas for improving the plan.
Special Considerations—This section includes
such items as information storage and maintenance.
Listen
Open/close toolbar
Reacting to Incidents
Once an actual incident has been confirmed and properly
classified, the IR plan moves from the detection phase to the

reaction phase. NIST SP 800-61, Rev. 2 combines the reaction
and recovery phases into their “Containment, Eradication, and
Recovery” phase.*
Cichonski, P., Millar, T., Grance, T., and
Scarfone, K. “Special Publication 800-61, Rev. 2: Computer
00-61r2.pdf.
The steps in IR are designed to stop the incident, mitigate its
effects, and provide information for the recovery from the
incident. In the IR phase, a number of action steps taken by the
CSIRT and others must occur quickly and may take place
concurrently. An effective IR plan prioritizes and documents
these steps to allow for efficient reference in the midst of an
incident. These steps include notification of key personnel,
assignment of tasks, and documentation of the incident.
Notification of Key Personnel
As soon as the CSIRT determines that an incident is in progress,
the right people must be notified in the right order. Most
“reaction” organizations, such as firefighters or the military,
use an
alert roster
A document that contains contact information
for personnel to be notified in the event of an incident or
disaster.
for just such a situation. Organizations can adopt
this approach to ensure that appropriate personnel are notified
in the event of an incident or disaster.
There are two ways to activate an alert roster: sequentially and
hierarchically. A sequential roster requires that a contact person

call each and every person on the roster. A hierarchical roster
requires that the first person call designated people on the
roster, who in turn call other designated people, and so on. Each
approach has both advantages and disadvantages. The
hierarchical system is quicker because more people are calling
at the same time, but the message can become distorted as it is
passed from person to person. The sequential system is more
accurate, but slower because a single contact person has to
contact each recipient and deliver the message. Fortunately,
many automated systems are available to facilitate either
approach.
For more information on selecting an automated notification
system, read the article by Steven Ross on Tech Target’s page
at
http://searchdisasterrecovery.techtarget.com/feature/Selecting-
an-automated-notification-system-for-data-center-disasters.
The alert roster is used to deliver the
alert message
A description of the incident or disaster that
usually contains just enough information so that each person
knows what portion of the IR or DR plan to implement without
slowing down the notification process.
, which tells each team member his or her
expected task and situation. It provides just enough information
so that each responder, CSIRT or otherwise, knows what portion
of the IR plan to implement without impeding the notification
process. It is important to recognize that not everyone is on the
alert roster—only those individuals who must respond to a
specific actual incident. As with any part of the IR plan, the
alert roster must be regularly maintained, tested, and rehearsed
if it is to remain effective.
During this phase, other key personnel not on the alert roster,
such as general management, must be notified of the incident as
well. This notification should occur only after the incident has
been confirmed but before media or other external sources learn
of it. Among those likely to be included in the notification

process are members of the legal, communications, and human
resources departments. In addition, some incidents are disclosed
to the employees in general, as a lesson in security, and some
are not, as a measure of security. Furthermore, other
organizations may need to be notified if it is determined that the
incident is not confined to internal information resources, or if
the incident is part of a larger-scale assault. For example,
during the distributed denial-of-service attack on multiple high-
visibility Web-based vendors in late 1999, many of the target
organizations reached out for help. In general, the IR planners
should determine in advance whom to notify and when, and
should offer guidance about additional notification steps to take
as needed.
Documenting an Incident
As soon as an incident has been confirmed and the notification
process is under way, the team should begin to document it. The
documentation should record the who, what, when, where, why,
and how of each action taken while the incident is occurring.
This documentation serves as a case study after the fact to
determine whether the right actions were taken and if they were
effective. It also proves, should it become necessary, that the
organization did everything possible to prevent the spread of the
incident. Legally, the standards of due care may offer some
protection to the organization should an incident adversely
affect individuals inside and outside the organization, or other
organizations that use the target organization’s systems.
Incident documentation can also be used as a simulation in
future training sessions on future versions of the IR plan.
Incident Containment Strategies
One of the most critical components of IR is stopping the
incident and containing its scope or impact. Incident
containment strategies vary depending on the incident and on
the amount of damage caused. Before an incident can be
stopped or contained, however, the affected areas must be

identified. Now is not the time to conduct a detailed analysis of
the affected areas; those tasks are typically performed after the
fact, in the forensics process. Instead, simple identification of
what information and systems are involved determines the
containment actions to be taken. Incident containment strategies
focus on two tasks: stopping the incident and recovering control
of the affected systems.
The CSIRT can stop the incident and attempt to recover control
by means of several strategies. If the incident originates outside
the organization, the simplest and most straightforward
approach is to disconnect the affected communication circuits.
Of course, if the organization’s lifeblood runs through that
circuit, this step may be too drastic; if the incident does not
threaten critical functional areas, it may be more feasible to
monitor the incident and contain it another way. One approach
used by some organizations is to apply filtering rules
dynamically to limit certain types of network access. For
example, if a threat agent is attacking a network by exploi ting a
vulnerability in the Simple Network Management Protocol
(SNMP), then applying a blocking filter for the commonly used
IP ports for that vulnerability will stop the attack without
compromising other services on the network. Depending on the
nature of the attack and the organization’s technical
capabilities, ad hoc controls can sometimes gain valuable time
to devise a more permanent control strategy. Typical
containment strategies include the following:
Disabling compromised user accounts
Reconfiguring a firewall to block the problem traffic
Temporarily disabling the compromised process or service
Taking down the conduit application or server—for example,
the e-mail server
Disconnecting the affected network or network segment
Stopping (powering down) all computers and network devices
Obviously, the final strategy is used only when all system
control has been lost and the only hope is to preserve the data
stored on the computers so that operations can resume normally

once the incident is resolved. The CSIRT, following the
procedures outlined in the IR plan, determines the length of the
interruption.
Consider the chapter-opening scenario again. What if, instead of
a fire, the event had been a malware attack? And what if the key
incident response personnel had been on sick leave, on vacation,
or otherwise not there? Think how many people in your class or
office are not there on a regular basis. Many businesses involve
travel, with employees going off-site to meetings, seminars,
training, vacations, or to fulfill other diverse requirements. In
addition, “life happens”—employees are sometimes absent due
to illness, injury, routine medical activities, and other
unexpected events. In considering these possibilities, the
importance of preparedness becomes clear. Everyone should
know how to react to an incident, not just the CISO and systems
administrators.
Incident Escalation
An incident may increase in scope or severity to the point that
the IR plan cannot adequately handle it. An important part of
knowing how to handle an incident is knowing at what point to
escalate the incident to a disaster, or to transfer the incident to
an outside authority such as law enforcement or another public
response unit. Each organization will have to determine, during
the BIA, the point at which an incident is deemed a disaster.
These criteria must be included in the IR plan. The organization
must also document when to involve outside responders, as
discussed in other sections. Escalation is one of those things
that, once done, cannot be undone, so it is important to know
when and where it should be used.
Listen

Open/close toolbar
Detecting Incidents
The challenge for every IR team is determining whether an
event is the product of routine systems use or an actual incident.
Incident classification
The process of examining an adverse event or
incident candidate and determining whether it constitutes an
actual incident.
is the process of examining an adverse event that
has the potential to escalate into an incident and determining
whether it constitutes an actual incident. Classifying an incident
is the responsibility of the IR team. Initial reports from end
users, intrusion detection systems, host- and network-based
virus detection software, and systems administrators are all
ways to track and detect adverse events. Careful training in the
reporting of an adverse event allows end users, help desk staff,
and all security personnel to relay vital information to the IR

team. Once an actual incident is properly identified and
classified, members of the IR team can effectively execute the
corresponding procedures from the IR plan. This is the primary
purpose of the first phase of IR:
incident detection
The identification and classification of an adverse
event as an incident, accompanied by the CSIRT’s notification
and the implementation of the IR reaction phase.
.
A number of occurrences signal the presence of an incident.
Unfortunately, these same events can result from an overloaded
network, computer, or server, and some are similar to the
normal operation of these information assets. Other incidents
mimic the actions of a misbehaving computing system, software
package, or other less serious threat. To help make incident
detection more reliable, Donald Pipkin has identified three
categories of incident indicators: possible, probable, and
definite.*
Pipkin, D. Information Security: Protecting
the Global Enterprise. Upper Saddle River, NJ: Prentice Hall
PTR, 2000: 285.
Possible Indicators
The following types of incident candidates are considered
possible indicators of actual incidents:
Presence of Unfamiliar Files—Users might
discover unfamiliar files in their home directories or on their
office computers. Administrators might also find unexplained
files that do not seem to be in a logical location or owned by an
authorized user.

Presence or Execution of Unknown Programs
or Processes—Users or administrators might detect unfamiliar
programs running, or processes executing, on office machines or
network servers.
Unusual Consumption of Computing
Resources—An example of this would be a sudden spike or fall
in consumption of memory or hard disk space. Many computer
operating systems, including Windows, Linux, and UNIX
variants, allow users and administrators to monitor CPU and
memory consumption. Most computers also have the ability to
monitor hard drive space. In addition, servers maintain logs of
file creation and storage.
Unusual System Crashes—Computer systems
can crash. Older operating systems running newer programs are
notorious for locking up or spontaneously rebooting whenever
the operating system is unable to execute a requested process or
service. You are probably familiar with systems error messages
such as “Unrecoverable Application Error,” “General Protection
Fault,” and the infamous Windows “Blue Screen of Death.”
However, if a computer system seems to be crashing, hanging,
rebooting, or freezing more frequently than usual, the cause
could be an incident candidate.
Probable Indicators
The following types of incident candidates are considered
probable indicators of actual incidents:
Activities at Unexpected Times—If traffic
levels on the organization’s network exceed the measured
baseline values, an incident candidate is probably present. If
this activity surge occurs when few members of the organization
are at work, this probability becomes much higher. Similarly, if
systems are accessing drives, such as floppy and CD-ROM

drives, when the end user is not using them, an incident may
also be occurring.
Presence of New Accounts—Periodic review
of user accounts can reveal an account (or accounts) that the
administrator does not remember creating or that is not logged
in the administrator’s journal. Even one unlogged new account
is an incident candidate. An unlogged new account with root or
other special privileges has an even higher probability of being
an actual incident.
Reported Attacks—If users of the system
report a suspected attack, there is a high probability that an
attack has occurred, which constitutes an incident. The
technical sophistication of the person making the report should
be considered.
Notification from IDPS—If the organization
has installed and correctly configured a host or network-based
Intrusion Detection and Prevention System (IDPS), then
notification from the IDPS indicates that an incident might be in
progress. However, IDPSs are difficult to configure optimally,
and even when they are, they tend to issue many false positives
or false alarms. The administrator must then determine whether
the notification is real or the result of a routine operation by a
user or other administrator.
Definite Indicators
The following five types of incident candidates are definite
indicators of an actual incident. That is, they clearly signal that
an incident is in progress or has occurred. In these cases, the
corresponding IR must be activated immediately.
Use of Dormant Accounts—Many network
servers maintain default accounts, and there often exist accounts
from former employees, employees on a leave of absence or

sabbatical without remote access privileges, or dummy accounts
set up to support system testing. If any of these accounts begins
accessing system resources, querying servers, or engaging in
other activities, an incident is certain to have occurred.
Changes to Logs—Smart systems
administrators back up system logs as well as system data. As
part of a routine incident scan, systems administrators can
compare these logs to the online versions to determine whether
they have been modified. If they have and the systems
administrator cannot determine explicitly that an authorized
individual modified them, an incident has occurred.
Presence of Hacker Tools—Network
administrators sometimes use system vulnerability and network
evaluation tools to scan internal computers and networks to
determine what a hacker can see. These tools are also used to
support research into attack profiles. All too often, however,
they are used by employees, contractors, or outsiders with local
network access to hack into systems. To combat this problem,
many organizations explicitly prohibit the use of these tools
without written permission from the CISO, making any
unauthorized installation a policy violation. Most organizations
that engage in penetration-testing operations require that all
tools in this category be confined to specific systems, and that
they not be used on the general network unless active
penetration testing is under way. Finding hacker tools, or even
legal security tools, in places they shouldn’t be is an indicator
an incident has occurred.
Notifications by Partner or Peer—If a
business partner or another connected organization reports an
attack from your computing systems, then an incident has
occurred.
Notification by Hacker—Some hackers enjoy

taunting their victims. If an organization’s Web pages are
defaced, it is an incident. If an organization receives an
extortion request for money in exchange for its customers’
credit card files, an incident is in progress. Note that even if an
actual attack has not occurred—for example, the hacker is just
making an empty threat—the reputational risk is real and should
be treated as such.
Potential Incident Results
The situations described in the following list may simply be
caused by the abnormal performance of a misbehaving IT
system. However, because accidental and intentional incidents
both can lead to the following results, organizations should err
on the side of caution and treat every adverse event as if it
could evolve into an actual incident:
Loss of Availability—Information or
information systems become unavailable.
Loss of Integrity—Users report corrupt data
files, garbage where data should be, or data that just looks
wrong.
Loss of Confidentiality—There is a
notification of a sensitive information leak, or information that
was thought to be protected has been disclosed.
Violation of Policy—There is a violation of
organizational policies addressing information or InfoSec.
Violation of Law or Regulation—The law has
been broken and the organization’s information assets are
involved.
Listen

Open/close toolbar
Disaster Recovery
The next vital part of CP focuses on
disaster recovery (DR)
efforts for detecting, reacting to, and recovering from a disaster.
. The IT community of interest, under the leadership
of the CIO, is often made responsible for disaster recovery
planning, including aspects that are not necessarily technology
based.
Disaster recovery planning (DRP)

and implement the DR policy, plan, and recovery teams.
entails the preparation for and recovery from a
disaster, whether natural or man-made. In some cases, actual
incidents detected by the IR team may escalate to the level of
disaster, and the IR plan may no longer be able to handle the
effective and efficient recovery from the loss. For example, if a
malicious program evades containment actions and infects and
disables many or most of an organization’s systems and its
ability to function, the
disaster recovery plan (DR plan)
The documented product of disaster recovery
in the event of a disaster.
is activated. Sometimes, events are by their nature
immediately classified as disasters, such as an extensive fire,
flood, damaging storm, or earthquake.
As you learned earlier in this chapter, the CP team creates the
DR planning team (DRPT). The DRPT in turn organizes and
prepares the DR response teams (DRRTs) to actually implement
the DR plan in the event of a disaster. In reality, there may be
many different DRRTs, each tasked with a different aspect of
recovery. These teams may have multiple responsibilities in the
recovery of the primary site and the reestablishment of
operations:
Recover information assets that are salvageable from the
primary facility after the disaster.
Purchase or otherwise acquire replacement information assets
from appropriate sources.
Reestablish functional information assets at the primary site if
possible or at a new primary site, if necessary.
Some common DRRTs include:
DR Management Team—Coordinates the on-site
efforts of all other DRRTs.
Communications Team—With representatives

from the Public Relations and Legal departments, provides
feedback to anyone who wants additional information about the
organization’s efforts in recovering from the disaster.
Computer Recovery (Hardware) Team—Works to
recover any physical computing assets that might be usable after
the disaster and acquire replacement assets and set them up for
resumption of operations.
Systems Recovery (OS) Team—Works to recover
operating systems and may contain one or more specialists on
each operating system that the organization employs; may be
combined with the applications recovery team as a “software
recovery team” or with the hardware team as a “systems
recovery team” or “computer recovery team.”
Network Recovery Team—Works to determine
the extent of damage to the network wiring and hardware (hubs,
switches, and routers) as well as to Internet and intranet
connectivity.
Storage Recovery Team—Works with the other
teams to recover storage-related information assets; may be
subsumed into other hardware and software teams.
Applications Recovery Team—Works to recover
critical applications.
Data Management Team—Works on data
restoration and recovery, whether from on-site, off-site, or
online transactional data.
Vendor Contact Team—Works with suppliers and
vendors to replace damaged or destroyed materials, equipment,
or services, as determined by the other teams.

Damage Assessment and Salvage Team—
Specialized individuals who provide initial assessments of the
extent of damage to materials, inventory, equipment, and
systems on-site.
Business Interface Team—Works with the
remainder of the organization to assist in the recovery of
nontechnology functions.
Logistics Team—Responsible for providing any
needed supplies, space, materials, food, services, or facilities at
the primary site; may be combined with the vendor contact
team.
Other Teams as Needed.
Listen

Open/close toolbar
Business Impact Analysis
The
business impact analysis (BIA)
An investigation and assessment of adverse
events that can affect the organization, conducted as a
preliminary phase of the contingency planning process, which
includes a determination of how critical a system or set of
information is to the organization’s core processes and its
recovery priorities.
is the first phase of the CP process. A crucial
component of the initial planning stages, it serves as an
investigation and assessment of the impact that various adverse
events can have on the organization.
One of the fundamental differences between a BIA and the risk
management processes discussed in Chapters 6 and 7 is that risk
management focuses on identifying the threats, vulnerabilities,
and attacks to determine which controls can protect the
information. The BIA assumes that these controls have been
bypassed, have failed, or have otherwise proved ineffective, that
the attack succeeded, and that the adversity that was being
defended against has come to fruition. By assuming the worst
has happened, then assessing how that adversity will impact the
organization, insight is gained regarding how the organization
must respond to the adverse event, minimize the damage,
recover from the effects, and return to normal operations.
The BIA begins with the prioritized list of threats and
vulnerabilities identified in the risk management process
discussed in Chapter 6 and enhances the list by adding the
information needed to respond to the adversity. Obviously, the
organization’s security team does everything in its power to
stop these attacks, but as you have seen, some attacks, such as
natural disasters, deviations from service providers, acts of

human failure or error, and deliberate acts of sabotage and
vandalism, may be unstoppable.
When undertaking the BIA, the organization should consider the
following:
Scope—Carefully consider which parts of the
organization to include in the BIA; determine which business
units to cover, which systems to include, and the nature of the
risk being evaluated.
Plan—The needed data will likely be
voluminous and complex, so work from a careful plan to assure
the proper data is collected to enable a comprehensive analysis.
Getting the correct information to address the needs of decision
makers is important.
Balance—Weigh the information available;
some information may be objective in nature, while other
information may be only available as subjective or anecdotal
references. Facts should be weighted properly against opinions;
however, sometimes the knowledge and experience of key
personnel can be invaluable.
Objective—Identify what the key decision
makers require for making choices in advance. Structure the
BIA to bring them the information they need, organized to
facilitate consideration of those choices.
Follow-Up—Communicate periodically to
insure process owners and decision makers will support the
process and the end result of the BIA.*
Zawada, B., and L. Evans. “Creating a
More Rigorous BIA.” CPM Group, November/December 2002.

Accessed 5/12/05 from
www.contingencyplanning.com/archives/2002/novdec/4.aspx.
According to NIST’s SP 800-34, Rev. 1, the CPMT conducts the
BIA in three stages described in the sections that follow:*
Swanson, M., P. Bowen, A. Phillips, D.
Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1:
Contingency Planning Guide for Federal Information Systems.”
National Institute of Standards and Technology. Accessed
7/11/15 from http://csrc.nist.gov/publications/nistpubs/800-34-
rev1/sp800-34-rev1_errata-Nov11-2010.pdf.
Determine mission/business processes and recovery criticality.
Identify resource requirements.
Identify recovery priorities for system resources.
Determine Mission/Business Processes and Recovery Criticality
The first major BIA task is the analysis and prioritization of
business processes within the organization, based on their
relationship to the organization’s mission. Each business
department, unit, or division must be independently evaluated to
determine how important its functions are to the organization as
a whole. For example, recovery operations would probably
focus on the IT Department and network operation before
turning to the Personnel Department’s hiring activities.
Likewise, recovering a manufacturing company’s assembly line
is more urgent than recovering its maintenance tracking system.
This is not to say that personnel functions and assembly line
maintenance are not important to the business, but unless the
organization’s main revenue-producing operations can be
restored quickly, other functions are irrelevant.

Note that throughout this section, the term mission/business
process is used, as some agencies that adopt this methodology
aren’t businesses and thus don’t have business processes per se.
Don’t let the term confuse you. Whenever you see the term, it’s
essentially describing a
business process
A task performed by an organization or one of
its units in support of the organization’s overall mission.
. NIST prefers this term, although the term
business process is just as accurate.
It is important to collect critical information about each
business unit before beginning the process of prioritizing the
business units. The important thing to remember is to avoid
“turf wars” and instead focus on the selection of those business
functions that must be sustained in order to continue business
operations. While one manager or executive might feel that his
or her function is the most critical to the organization, that
particular function might prove to be less critical in the event of
a major incident or disaster. It is the role of senior management
to arbitrate these inevitable conflicts about priority; after all,
senior management has the perspective to make these types of
trade-off decisions.
A weighted table analysis (WTA), sometimes called a weighted
factor analysis, can be useful in resolving the issue of what
business function is the most critical. The CPMT can use this
tool by first identifying the characteristics of each business
function that matter most to the organization—the criteria. The
team should then allocate relative weights to each of these
criteria. Each of the criteria is assessed on its influence toward
overall importance in the decision-making process. Once the
characteristics to be used as criteria have been identified and
weighted (usually as columns in a worksheet), the various
business functions are listed (usually as rows on the same
worksheet). Each business function (row) is assessed a score for
each of the criteria (column). Once this activity has been
accomplished, the weights can be multiplied against the scores

in each of the criteria, and then the rows are summed to obtain
the overall scored value of the function to the organization. In
the process just described, the higher the value computed for a
given business function, the more important that function is to
the organization.
A BIA questionnaire is an instrument used to collect relevant
business impact information for the required analysis. It is
useful as a tool for identifying and collecting information about
business functions for the analysis just described. It can also be
used to allow functional managers to directly enter information
about the business processes within their area of control, their
impacts on the business, and dependencies that exist for the
functions from specific resources and outside service providers.
NIST Business Process and Recovery Criticality
NIST’s SP 800-34, Rev. 1 recommends that organizations use
categories like low impact, moderate impact, or high impact for
the security objectives of confidentiality, integrity, and
availability (NIST’s Risk Management Framework [RMF] Step
1). Note that large quantities of information are assembled and a
data collection process is essential if all meaningful and useful
information collected in the BIA process is to be made available
for use in the overall CP development process.
When organizations consider recovery criticality, key recovery
measures are usually described in terms of how much of the
asset they must recover within a specified time frame. The
terms most commonly used to describe this value are:
Recovery time objective (RTO)
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.

Recovery point objective (RPO)
The point in time before a disruption or
system outage to which business process data can be recovered
after an outage, given the most recent backup copy of the data.
Maximum tolerable downtime (MTD)
The total amount of time the system owner
or authorizing official is willing to accept for a business process
outage or disruption. The MTD includes all impact
considerations.
Work recovery time (WRT)
The amount of effort (expressed as elapsed
time) needed to make business functions work again after the
technology element is recovered. This recovery time is
identified by the RTO.
The difference between RTO and RPO is illustrated in Figure
10-3. WRT typically involves the addition of nontechnical tasks
required for the organization to make the information asset
usable again for its intended business function. The WRT can be
added to the RTO to determine the realistic amount of elapsed
time required before a business function is back in useful
service, as illustrated in Figure 10-4.

Figure 10-3.
RTO vs. RPO
Source:
http://networksandservers.blogspot.com/2011/02/high-
availability-terminology-ii.html.
Figure 10-4.
RTO, RPO, MTD, and WRT
Source:
http://networksandservers.blogspot.com/2011/02/high-
availability-terminology-ii.html.
Failing to determine MTD, NIST goes on to say, “could leave
contingency planners with imprecise direction on
(1)
selection of an appropriate recovery method, and(2)
the depth of detail that will be required when developing
recovery procedures, including their scope and content.”*

Swanson, M., P. Bowen, A. Phillips,
D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1:
Determining the information system resource’s RTO, NIST
adds, “is important for selecting appropriate technologies that
are best suited for meeting the MTD.”* As for reducing RTO,
that requires mechanisms to shorten the start-up time or
provisions to make data available online at a failover site.
Unlike RTO, NIST adds, “RPO is not considered as part of
MTD. Rather, it is a factor of how much data loss the
mission/business process can tolerate during the recovery
process.”* Reducing RPO requires mechanisms to increase the
synchronicity of data replication between production systems
and the backup implementations for those systems.

Because of the critical need to recover business functionality,
the total time needed to place the business function back in
service must be shorter than the MTD. Planners should
determine the optimal point to recover the information system
to in order to meet BIA-mandated recovery needs while
balancing the cost of system inoperability against the cost of the
resources required for restoring systems. This must be done in
the context of the BIA-identified critical business processes and
can be shown with a simple chart, such as the one in Figure 10-
5.
Figure 10-5.
Cost Balancing
The longer an interruption to system availability remains, the
more impact and cost it will have for the organization and its
operations. When plans require a short RTO, the solutions that
will be required are usually more expensive to design and use.
For example, if a system must be recovered immediately it will
have an RTO of 0. These types of solutions will require fully
redundant alternative processing sites and will therefore have
much higher costs. On the other hand, a longer RTO would
allow a less expensive recovery system. Plotting the cost
balance points will show an optimal point between disruption
and recovery costs. The intersecting point, labeled the cost
balance point in Figure 10-5, will be different for every

organization and system, based on the financial constraints and
operating requirements.*
Information Asset Prioritization
As the CPMT conducts the BIA, it will be assessing priorities
and relative values on mission/business processes. To do so, it
needs to understand the information assets used by those
processes. The presence of high-value information assets may
influence the valuation of a particular business process.
Normally, this task would be performed as part of the risk-
assessment function within the risk management process. The
organization should identify, classify, and prioritize its
information assets, placing classification labels on each
collection or repository of information in order to better
understand its value and to prioritize its protection. If the
organization has not performed this task, the BIA process is the
appropriate time to do so.
Identify Resource Requirements
Once the organization has created a prioritized list of its
mission/business processes, it needs to determine what
resources would be required in order to recover those processes
and the assets associated with them. Some processes are
resource intensive—like IT functions. Supporting customer
data, production data, and other organizational information
requires extensive quantities of information processing, storage,
and transmission (through networking). Other business-

production–oriented processes require complex or expensive
components to operate. For each process (and information asset)
identified in the previous BIA stage, the organization shoul d
identify and describe the relevant resources needed to provide
or support that process. A simplified method for organizing this
information is to put it into a resource/component table, like the
example shown in Table 10-1. Note in the table how one
business process will typically have multiple components, each
of which must be enumerated separately.
Table 10-1.
Example Resource/Components
TableMission/Business ProcessRequired Resource
ComponentsAdditional Resource DetailsDescription and
Estimated CostsProvide customer support (help desk)Trouble
ticket and resolution applicationApplication server w/LINUX
OS, Apache server, and SQL databaseEach help desk technician
requires access to the organization’s trouble ticket and
resolution software application, hosted on a dedicated server.
See current cost recovery statement for valuation.Provide
customer support (help desk)Help desk network segment25
Cat5e network drops, gigabit network hubThe help desk
applications are networked and require a network segment to
access. See current cost recovery statement for
valuation.Provide customer support (help desk)Help desk access
terminals1 laptop/PC per technician, with Web-browsing
softwareThe help desk applications require a Web interface on a
laptop/PC to access. See current cost recovery statement for
valuation.Provide customer billingCustomized accounts
receivable applicationApplication server with Linux OS,
Apache server, and SQL databaseAccounts Receivable requires
access to its customized AR software and customer database to
process customer billing. See current cost recovery statement
for valuation.
Identify System Resource Recovery Priorities

The last stage of the BIA is prioritizing the resources associated
with the mission/business processes, which provides a better
understanding of what must be recovered first, even within the
most critical processes. With the information from previous
steps in hand, the organization can create additional weighted
tables of the resources needed to support the individual
processes. By assigning values to each resource, the
organization will have a custom-designed “to-do” list available
once the recovery phase commences. Whether it is an IR- or
DR-scaled recovery or the implementation of critical process es
in an alternate site during business continuity, these lists will
prove invaluable to those who are tasked to establish (or
reestablish) critical processes quickly.
In addition to the weighted tables described earlier, a simple
valuation and classification scale, such as
Primary/Secondary/Tertiary, or Critical/Very
Important/Important/Routine, can be used to provide a quicker
method of valuating the supporting resources. What is most
important is not to get so bogged down in the process that you
lose sight of the objective (the old “can’t see the forest for the
trees” problem). Teams that spend too much time developing
and completing weighted tables may find a simple classification
scheme more suited for their task. However, in a complex
process with a large number of resources, a more sophisticated
valuation method like the weighted tables may be more
appropriate. One of the jobs of the CPMT, while preparing to
conduct the BIA, is to determine what method of valuating
processes and their supporting resources should be used.
Listen

Open/close toolbar
The Disaster Recovery Process
In general, a disaster has occurred when either of two criteria is
met:
(1)
The organization is unable to contain or control the impact of an
incident, or(2)
the level of damage or destruction from an incident is so severe
that the organization cannot quickly recover from it.
The distinction between an incident and a disaster may be
subtle. The DRPT must document in the DR plan whether an
event is classified as an incident or a disaster. This
determination is critical because it determines which plan is
activated. The key role of the DR plan is to prepare to
reestablish operations at the organization's primary location
after a disaster or to establish operations at a new location if the

primary site is no longer viable.
You learned earlier in this chapter about the CP planning
process recommended by NIST, which uses seven steps. In the
broader context of organizational CP, these steps form the
overall CP process. These steps are adapted and applied here
within the narrower context of the DRP process, resulting in an
eight-step DR process.
Organize the DR Team—The initial
assignments to the DR team, including the team lead, will most
likely be performed by the CPMT; however, additional
personnel may need to be assigned to the team as the specifics
of the DR policy and plan are developed, and their individual
roles and responsibilities defined and assigned.
Develop the DR Planning Policy Statement—A
formal department or agency policy provides the authority and
guidance necessary to develop an effective contingency plan.
Review the BIA—The BIA was prepared to help
identify and prioritize critical information and its host systems.
A review of what was discovered is an important step in the
process.
Identify Preventive Controls—Measures taken
to reduce the effects of business and system disruptions can
increase information availability and reduce contingency life
cycle costs.
Create DR Strategies—Thorough recovery
strategies ensure that the system can be recovered quickly and
effectively following a disruption.
Develop the DR Plan Document—The plan
should contain detailed guidance and procedures for restoring a
damaged system.

Ensure DR Plan Testing, Training, and
Exercises—Testing the plan identifies planning gaps, whereas
training prepares recovery personnel for plan activation; both
activities improve plan effectiveness and overall agency
preparedness.
Ensure DR Plan Maintenance—The plan should
be a living document that is updated regularly to remain current
with system enhancements.
Listen
Open/close toolbar

Fundamentals of Contingency Planning
The overall process of preparing for unexpected adverse events
is called
contingency planning (CP)
The actions taken by senior management to
specify the organization’s efforts and actions if an adverse
event becomes an incident or disaster. This planning includes
incident response, disaster recovery, and business continuity
efforts, as well as preparatory business impact analysis.
. During CP, the IT and InfoSec communities of
interest position their respective organizational units to prepare
for, detect, react to, and recover from events that threaten the
security of information resources and assets, including human,
information, and capital. The main goal of CP is to restore
normal modes of operation with minimal cost and disruption to
normal business activities after an unexpected adverse event—
in other words, to make sure things get back to the way they
were within a reasonable period of time. Ideally, CP should
ensure the continuous availability of information systems to the
organization even in the face of the unexpected.
CP consists of four major components:
Business impact analysis (BIA)
Incident response plan (IR plan)
Disaster recovery plan (DR plan)
Business continuity plan (BC plan)
The BIA is a preparatory activity common to both CP and risk
management, which was covered in Chapters 6 and 7. It helps
the organization determine which business functions and
information systems are the most critical to the success of the
organization. The IR plan focuses on the immediate response to
an incident. Any unexpected adverse event is treated as an
incident, unless and until a response team deems it to be a
disaster. Then the DR plan, which focuses on restoring
operations at the primary site, is invoked. If operations at the
primary site cannot be quickly restored—for example, when the
damage is major or will affect the organization’s functioning

over the long term—the BC plan occurs concurrently with the
DR plan, enabling the business to continue at an alternate site,
until the organization is able to resume operations at its primary
site or select a new primary location.
Depending on the organization’s size and business philosophy,
IT and InfoSec managers can either
(1)
create and develop these four CP components as one unified
plan or(2)
create the four separately in conjunction with a set of
interlocking procedures that enable continuity.
Typically, larger, more complex organizations create and
develop the CP components separately, as the functions of each
component differ in scope, applicability, and design. Smaller
organizations tend to adopt a one-plan method, consisting of a
straightforward set of recovery strategies.
Ideally, the chief information officer (CIO), systems
administrators, the chief information security officer (CISO),
and key IT and business managers should be actively involved
during the creation and development of all CP components, as
well as during the distribution of responsibilities among the
three communities of interest. The elements required to begin
the CP process are: a planning methodology; a policy
environment to enable the planning process; an understanding of
the causes and effects of core precursor activities, known as the
BIA; and access to financial and other resources, as articulated
and outlined by the planning budget. Each of these is explained
in the sections that follow. Once formed, the
contingency planning management team (CPMT)
The group of senior managers and project
members organized to conduct and lead all CP efforts.
begins developing a CP document, for which NIST
recommends using the following steps:

Develop the CP policy statement. A formal policy provides the
authority and guidance necessary to develop an effective
contingency plan.
Conduct the BIA. The BIA helps identify and prioritize
information systems and components critical to supporting the
organization’s mission/business processes. 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 a contingency plan. The contingency plan should
contain detailed guidance and procedures for restoring damaged
organizational facilities unique to each business unit’s 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.*
Swanson, M., P. Bowen, A. Phillips,
D. Gallup, and D. Lynes. “Special Publication 800-34, Rev. 1:

Source: NIST
Even though the NIST methodologies are used extensively in
this chapter, NIST actually treats incident response separately
from contingency planning; the latter is focused on disaster
recovery and business continuity. This chapter attempts to
integrate the approach to contingency planning in NIST SP 800-
34, Rev. 1 with the guide to incident handling in NIST SP 800-
61, Rev. 2.
Effective CP begins with effective policy. Before the CPMT can
fully develop the planning document, the team must receive
guidance from executive management, as described earlier,
through formal CP policy. This policy defines the scope of the
CP operations and establishes managerial intent in regard to
timetables for response to incidents, recovery from disasters,
and reestablishment of operations for continuity. It also
stipulates responsibility for the development and operations of
the CPMT in general and may also provide specifics on the
constituencies of all CP-related teams. It is recommended that
the CP policy contain, at a minimum, the following sections:
An introductory statement of philosophical perspective by
senior management as to the importance of CP to the strategic,
long-term operations of the organizations.
A statement of the scope and purpose of the CP operations,
stipulating the requirement to cover all critical business
functions and activities.
A call for periodic (e.g., yearly) risk assessment and BIA by the
CPMT, to include identification and prioritization of critical
business functions (while the need for such studies is well
understood by the CPMT, the formal inclusion in policy
reinforces that need to the rest of the organization).
A description of the major components of the CP to be designed
by the CPMT, as described earlier.
A call for, and guidance in, the selection of recovery options

and BC strategies.
A requirement to test the various plans on a regular basis (e.g.,
semiannually, annually, or more often as needed).
Identification of key regulations and standards that impact CP
planning and a brief overview of their relevance.
Identification of key individuals responsible for CP operations,
such as establishment of the chief operations officer (COO) as
CPMT lead, the CISO as IR team lead, the manager of business
operations as DR team lead, the manager of information systems
and services as BC team lead, and legal counsel as crisis
management team lead.
An appeal to the individual members of the organizations,
asking for their support and reinforcing their importance as part
of the overall CP process.
Additional administrative information, including the original
date of the document, revision dates, and a schedule for
periodic review and maintenance.
A number of individuals and teams are involved in CP and
contingency operations:
CPMT—This team collects information about
the organization and about the threats it faces, conducts the
BIA, and then coordinates the development of contingency
plans for incident response, disaster recovery, and business
continuity. The CPMT often consists of a coordinating
executive and representatives from major business units and the
managers responsible for each of the other three teams. It
should include the following personnel:
Champion—As with any strategic
function, the CP project must have a high-level manager to
support, promote, and endorse the findings of the project. This
champion could be the COO or (ideally) the CEO/president.
Project Manager—A champion provides
the strategic vision and the linkage to the power structure of the

organization but does not manage the project. A project
manager—possibly a mid-level operations manager or even the
CISO—leads the project, putting in place a sound project
planning process, guiding the development of a complete and
useful project, and prudently managing resources.
Team Members—The team members
should be the managers or their representatives from the various
communities of interest: business, IT, and InfoSec. Business
managers supply details of their activities and insight into those
functions critical to running the business. IT managers supply
information about the at-risk systems used in the development
of the BIA and the IR, DR, and BC plans. InfoSec managers
oversee the security planning and provide information on
threats, vulnerabilities, attacks, and recovery requireme nts. A
representative from the legal affairs or corporate counsel’s
office helps keep all planning steps within legal and contractual
boundaries. A member of the corporate communications
department makes sure the crisis management and
communications plan elements are consistent with the needs of
that group. Supplemental team members also include the
planning teams: the
incident response planning team
The team responsible for designing
and managing the IR plan by specifying the organization’s
preparation, reaction, and recovery from incidents.
,
disaster recovery planning team
and managing the DR plan by specifying the organization’s
preparation, response, and recovery from disasters, including
reestablishment of business operations at the primary site after
the disaster.
, and
business continuity planning team

and managing the BC plan of relocating the organization and
establishing primary operations at an alternate site until the
disaster recovery planning team can recover the primary site or
establish a new location.
. For organizations that decide to
separate crisis management from disaster recovery, there may
also be representatives from the
crisis management planning team
The individuals from various
functional areas of the organization assigned to develop and
implement the CM plan.
.
As indicated earlier, in larger organizations these teams are
distinct entities, with non-overlapping memberships, although
the latter three teams have representatives on the CPMT. In
smaller organizations, the four teams may include overlapping
groups of people, although this is discouraged because the three
planning teams (IR, DR, BC) will most likely include members
of their respective response teams—the individuals who will
actually respond to an incident or disaster. The planning teams
and response teams are distinctly separate groups, but
representatives of the response team will most likely be
included on the planning team for continuity purposes and to
facilitate plan development and the communication of planning
activities to the response units. If the same individuals are on
the DR and BC teams, for example, they may find themselves
with different responsibilities in different locations at the same
time. It is virtually impossible to establish operations at the
alternate site if team members are busy managing the recovery
at the primary site, some distance away. Thus, if the
organization has sufficient personnel, it is advisable to staff the
two groups with separate members.
As illustrated in the opening scenario of this chapter, many
organizations’ contingency plans are woefully inadequate. CP
often fails to receive the high priority necessary for the efficient
and timely recovery of business operations during and after an

unexpected event. The fact that many organizations do not place
an adequate premium on CP does not mean that it is
unimportant, however. Here is how NIST’s Computer Security
Resource Center (CSRC) describes the need for this type of
planning:
These procedures (contingency plans, business interruption
plans, and continuity of operations plans) should be coordinated
with the backup, contingency, and recovery plans of any general
support systems, including networks used by the application.
The contingency plans should ensure that interfacing systems
are identified and contingency/disaster planning coordinated.
*
Swanson, M., J. Hash, and P. Bowen.
“Special Publication 800-18, Rev 1: Guide for Developing
Security Plans for Information Systems.” National Institute of
Standards and Technology (February 2006, p. 31). Accessed
7/12/15 from csrc.nist.gov/publications/nistpubs/800-18-
Rev1/sp800-18-Rev1-final.pdf.
As you learn more about CP, you may notice that it shares
certain characteristics with risk management and the SecSDLC
methodology. Many IT and InfoSec managers are already
familiar with these processes; they can readily adapt their
existing knowledge to the CP process.
Listen

Open/close toolbar
Incident Response Policy
An important early step for the CSIRT is to develop an
IR policy
and implementation of IR plans and the formulation and
performance of IR teams.
. NIST’s “Special Publication 800-61, Rev. 2: The
Computer Security Incident Handling Guide” identifies the
following key components of a typical IR policy:
Statement of management commitment
Purpose and objectives of the policy
Scope of the policy (to whom and what it applies and under
what circumstances)
Definition of InfoSec incidents and related terms
Organizational structure and definition of roles, responsibilities,
and levels of authority; should include the authority of the
incident response team to confiscate or disconnect equipment
and to monitor suspicious activity, and the requirements for

reporting certain types of incidents, the requirements and
guidelines for external communications and information sharing
(e.g., what can be shared with whom, when, and over what
channels), and the handoff and escalation points in the incident
management process
Prioritization or severity ratings of incidents
Performance measures (discussed in Chapter 9)
Reporting and contact forms
*
Cichonski, P., Millar, T. Grance, and K.
Scarfone. “Special Publication 800-61, Rev. 2: Computer
00-61r2.pdf.
IR policy, like all policies, must gain the full support of top
management and be clearly understood by all affected parties. It
is especially important to gain the support of those communities
of interest that will be required to alter business practices or
make changes to their IT infrastructures. For example, if the
CSIRT determines that the only way to stop a massive denial -
of-service attack is to sever the organization’s connection to the
Internet, it should have a signed document locked in an
appropriate filing cabinet preauthorizing such action. This
ensures that the CSIRT is performing authorized actions, and
protects both the CSIRT members and the organization from
misunderstanding and potential liability.
Listen

Open/close toolbar
Getting Started
As mentioned previously, an early task for the CPMT is to form
the IR planning team (IRPT), which will begin work by
developing policy to define the team’s operations, articulate the
organization’s response to various types of incidents, and advise
users how to contribute to the organization’s effective response,
rather than contributing to the problem at hand. The IRPT then
forms the
computer security incident response team
(CSIRT)
An IR team composed of technical IT, managerial
IT, and InfoSec professionals who are prepared to detect, react
to, and recover from an incident. The CSIRT may include
members of the IRPT.
. Some key members of the IRPT may be part of the

CSIRT. You will learn more about the CSIRT’s roles and
composition later in this section. Figure 10-6 illustrates the
NIST incident response life cycle.
Figure 10-6.
NIST Incident Response Life Cycle
Source: NIST Special Publication 800-61, Rev. 2:
The Computer Security Incident Handling Guide.
Listen

Open/close toolbar
Incident Response
Most organizations have experience detecting, reacting to, and
recovering from attacks, employee errors, service outages, and
small-scale natural disasters. While they may not have formally
labeled such efforts, these organizations are performing
incident response (IR)
efforts for detecting, reacting to, and recovering from an
incident.
. IR must be carefully planned and coordinated
because organizations heavily depend on the quick and efficient
containment and resolution of incidents.
Incident response planning (IRP)
and implement the IR policy, plan, and computer security
incident response team.
, therefore, is the preparation for such an effort. Note
that the term incident response could be used either to describe
the entire set of activities or a specific phase in the overall
reaction. However, in an effort to minimize confusion, this text
will use the term IR to describe the overall process, and
reaction rather than response to describe the organization’s
performance after it detects an incident.
In business, unexpected events sometimes happen. When those
events represent the potential for loss, they are referred to as
adverse events
An event with negative consequences that could

threaten the organization’s information assets or operations.
Sometimes referred to as an incident candidate.
or
incident candidates
See adverse event.
. When an adverse event begins to manifest as a real
threat to information, it becomes an
incident
An adverse event that could result in a loss of
information assets, but does not threaten the viability of the
entire organization.
. The
incident response plan (IR plan)
The documented product of incident response
in the event of an incident.
is usually activated when the organization detects an
incident that affects it, regardless of how minor the effect is.
Listen

Open/close toolbar
Contingency Planning Policies
Prior to the development of each of the types of CP documents
outlined in this chapter, the CP team should work to develop the
policy environment that will enable the BIA process and should
provide specific policy guidance toward authorizing the creation
of each of the planning components (IR, DR, and BC). These
policies provide guidance on the structure of the subordinate
teams and the philosophy of the organization, and they assist in
the structuring of the plan.
Each of the CP documents will include a policy similar in
structure to all other policies used by the organization. Just as
the enterprise InfoSec policy defines the InfoSec roles and
responsibilities for the entire enterprise, each of the CP
documents is based on a specific policy that defines the related
roles and responsibilities for that element of the overall CP
environment within the organization.
Listen

Open/close toolbar
Components of Contingency Planning
As noted earlier, CP includes four major compone nts: the BIA
and the IR, DR, and BC plans. Whether an organization adopts
the one-plan method or the multiple-plan method with
interlocking procedures, each of these CP components must be
addressed and developed in its entirety. The following sections
describe each component in detail, including when and how
each should be used. They also explain how to determine which
plan is best suited for the identification, containment, and
resolution of any given unexpected event. Figure 10-1 depicts
the major project modules performed during CP efforts. Figure
10-2 shows the overall stages of the CP process, which are
derived from the NIST IR and CP methodologies presented
earlier.
Figure 10-1.
Contingency Planning Hierarchies

Figure 10-2.
Contingency Planning Life Cycle
Listen
Open/close toolbar

Introduction to Contingency Planning
You were introduced to planning in Chapter 3, when you
learned about planning for the organization in general and for
the information security (InfoSec) program in particular. This
chapter focuses on another type of planning—plans that are
made for unexpected adverse events—when the use of
technology is disrupted and business operations can come to a
standstill. Because technology drives business, planning for an
unexpected adverse event usually involves managers from
general business management as well as the information
technology (IT) and InfoSec communities of interest. They
collectively analyze and assess the entire technological
infrastructure of the organization using the mission statement
and current organizational objectives to drive their planning
activities. But, for a plan to gain the support of all members of
the organization, it must also be sanctioned and actively
supported by the general business community of interest.
The need to have a plan in place that systematically addresses
how to identify, contain, and resolve any possible unexpected
adverse event was identified in the earliest days of IT.
Professional practice in the area of contingency planning
continues to evolve, as reflected in “Special Publication 800-34,
Rev. 1, Contingency Planning Guide for Federal Information
Systems,” issued by the National Institute of Standards and
Technology (NIST). NIST is a non-regulatory federal agency
within the U.S. Department of Commerce that serves to enhance
innovation and competitiveness in the United States by acting as
a clearinghouse for standards related to technology.* The
Computer Security Division of NIST facilitates sharing of
information about practices that can be used to secure
information systems.* NIST advises the following:
“NIST General Information.” National Institute
of Standards and Technology. Accessed 7/11/15 from

www.nist.gov/public_affairs/general_information.cfm.
“Computer Security Division Mission
Statement.” NIST Computer Security Division. Accessed
7/11/15 from http://csrc.nist.gov/mission/index.html.
Because information system resources are essential to an
organization’s success, it is critical that identified services
provided by these systems are able to operate effectively
without excessive interruption. Contingency planning supports
this requirement by establishing thorough plans, procedures,
and technical measures that can enable a system to be recovered
as quickly and effectively as possible following a service
disruption.*
Some organizations—particularly federal agencies for national
security reasons—are charged by law or other mandate to have
such plans and procedures in place at all times.
Organizations of every size and purpose should also prepare for
the unexpected. In general, an organization’s ability to weather
losses caused by an unexpected event depends on proper

planning and execution of such a plan; without a workable plan,
an unexpected event can cause severe damage to an
organization’s information resources and assets from which it
may never recover. The Hartford insurance company estimates
that, on average, over 40 percent of businesses that don’t have a
disaster plan go out of business after a major loss like a fire, a
break-in, or a storm.*
“Disaster Recovery Tips.” The Hartford.
Accessed 7/12/15 from www.thehartford.com/business/disaster -
recovery-guide.
The development of a plan for handling unexpected events
should be a high priority for all managers. The plan should
account for the possibility that key members of the organization
will not be available to assist in the recovery process. In 1991,
as a tragic example, two key executives of the Bruno’s
Supermarket chain, Angelo and Lee Bruno, were killed in a
plane crash. After that point, the company’s steady growth from
its founding during the Great Depression reversed course. In
fact, it declared bankruptcy in 2000. Although the brand still
has a presence in a few southern markets, the business as it
operated before the incident no longer exists.
There is a growing emphasis on the need for comprehensive and
robust planning for adverse circumstances. In the past,
organizations tended to focus on defensive preparations, using
comprehensive threat assessments combined with defense in
depth to harden systems and networks against all possible risks.
More organizations now understand that preparations agai nst
the threat of attack remain an urgent and important activity, but
that defenses will fail as attackers acquire new capabilities and
systems reveal latent flaws. When—not if—defenses are
compromised, prudent security managers have prepared the

organization in order to minimize losses and reduce the time
and effort needed to recover. Sound risk management practices
dictate that organizations must be ready for anything.
Listen
Open/close toolbar
Chapter 10.
Planning for ContingenciesIntroduction
Anything that can go wrong will go wrong.—
Murphy’s law

A week after the strategic planning meeting, Iris was just
finishing a draft of the information security strategic plan.
Satisfied with her progress thus far, she opened her calendar
and began reviewing her schedule, hoping to find a good day
and time to meet with Mike to discuss contingency planning.
During their last luncheon, her friend Charley had warned Iris
not to wait too long before addressing the issue again. She knew
he had a point. It simply was not a good idea to put off
discussing such an important project until the end of the month,
as Mike had suggested during last week’s strategic planning
meeting. Having a plan in place in case of an emergency just
made good business sense, even if it was not perceived as a high
priority by many of her management peers.
Suddenly, the building’s fire alarm went off. Heart pumping,
Iris left her office. With or without a contingency plan, it was
her responsibility to assess this situation as quickly and as
safely as possible. Was this an incident? A disaster? Or was it
simply a false alarm? As she quickly moved down the line of
cubicles, Iris called for everyone who had not yet left the floor
to leave by way of the nearest exit. Then she rushed to the
floor’s fire control panel, which was located in the elevator
lobby. A blinking light showed that one heat-sensitive sprinkler
head had been activated. Iris waited a moment to see whether
any other blinking lights came on. None did, but the existing
light stayed on. It seemed that she was dealing with an isolated
incident, and not a disaster.
Iris headed down the hall to the place shown on the fire panel
where the sprinkler had been triggered. She turned the corner
and saw Harry and Joel from the accounting department in the
break room, which was right next to their offices. Harry was
inspecting what had once been the coffeepot, while Joel held a
fire extinguisher. Both were wet and irritated. The room was
filled with smoke and smelled of scorched coffee. To Iris’s
relief, there was no fire.

“Is everyone all right?” she asked.
“Yeah,” Harry replied, “but our offices are a mess. There’s
water everywhere.”
Joel shook his head in disgust. “What a time for this to happen.
We were just finishing the quarterly reports, too.”
“Never mind that,” Iris said. “The important thing is that you’re
both okay. Do you guys need to make a trip home so you can
get changed?”
Before they could answer, Mike Edwards ran over to join them.
“What happened?” he asked.
Iris shrugged. “It’s a minor incident, Mike, everything’s under
control. The fire department will be here any minute.”
“Incident? Incident?” Joel said in dismay as he pointed at his
desk, where steam rose from his soaked CPU and a pile of
drenched reports littered the floor. “This isn’t an incident. This
is a disaster!”Learning Objectives
Upon completion of this material, you should be able to:Discuss
the need for contingency planningDescribe the major
components of incident response, disaster recovery, and
business continuityDefine the components of crisis management
and business resumptionDiscuss how the organization would
prepare and execute a test of contingency plansExplain how the
organization manages investigations
Listen

Open/close toolbar
Chapter Summary
Planning for unexpected events is usually the responsibility of
managers from both the information technology and the
information security communities of interest.
For a plan to be seen as valid by all members of the
organization, it must be sanctioned and actively supported by
the general business community of interest.
Some organizations are required by law or other mandate to
have contingency planning procedures in place at all times, but
all business organizations should prepare for the unexpected.
Contingency planning (CP) is the process by which the
information technology and information security communities
of interest position their organizations to prepare for, detect,
react to, and recover from events that threaten the security of
information resources and assets, both human and artificial.
CP is made up of four major components: the data collection
and documentation process known as the business impact
analysis (BIA), the incident response (IR) plan, the disaster
recovery (DR) plan, and the business continuity (BC) plan.
Organizations can either create and develop the three planning
elements of the CP process (the IR, DR, and BC plans) as one
unified plan, or they can create the three elements separately in
conjunction with a set of interlocking procedures that enable

continuity.
To ensure continuity during the creation of the CP components,
a seven-step CP process is used:
Develop the contingency planning policy statement.
Conduct the BIA.
Identify preventive controls.
Create contingency strategies.
Develop a contingency plan.
Ensure plan testing, training, and exercises.
Ensure plan maintenance.
Four teams of individuals are involved in contingency planning
and contingency operations: the CP team, the IR team, the DR
team, and the BC team. The IR team ensures the CSIRT is
formed.
The IR plan is a detailed set of processes and procedures that
plan for, detect, and resolve the effects of an unexpected event
on information resources and assets.
For every scenario identified, the CP team creates three sets of
procedures—for before, during, and after the incident—to
detect, contain, and resolve the incident.
Incident classification is the process by which the IR team
examines an incident candidate and determines whether it
constitutes an actual incident.
Three categories of incident indicators are used: possible,
probable, and definite.
When any one of the following happens, an actual incident is in
progress: loss of availability of information, loss of integrity of
information, loss of confidentiality of information, violation of
policy, or violation of law.
DR planning encompasses preparation for handling and
recovering from a disaster, whether natural or man-made.
The DR plan must include crisis management, the action steps
taken during and after a disaster.
BC planning ensures that critical business functions continue if
a catastrophic incident or disaster occurs. BC plans can include
provisions for hot sites, warm sites, cold sites, timeshares,

service bureaus, and mutual agreements.
Because the DR and BC plans are closely related, most
organizations prepare the two at the same time and may
combine them into a single planning document called the
business resumption (BR) plan.
All plans must be tested to identify vulnerabilities, faults, and
inefficient processes. Several testing strategies can be used to
test contingency plans: desk check, structured walk-through,
simulation, and full-interruption.
Digital forensics involves the preservation, identification,
extraction, documentation, and interpretation of computer media
for evidentiary and root cause analysis. E-discovery is the
identification and preservation of evidentiary materials related
to a specific legal action. Digital forensics and e-discovery are
related in that digital forensics tools and methods may be
deployed to conduct e-discovery or to extract information
identified during e-discovery; however, e-discovery may simply
focus on extensive e-mail and database searches to identify
information related to specific key terms.
Most organizations cannot sustain a permanent digital forensics
team. Even so, people in the InfoSec group should be trained to
understand and manage the forensics process.
In digital forensics, all investigations follow the same basic
methodology: identify relevant items of evidentiary value,
acquire (seize) the evidence without alteration or damage, take
steps to assure that the evidence is verifiably authentic at every
stage and is unchanged from the time it was seized, analyze the
data without risking modification or unauthorized access, and
report the findings to the proper authority.
Listen

Open/close toolbar
Mahtnarg Manufacturing Incident Response Plan
Incident Response Plan
This document discusses the steps taken during an incident
response plan. To create the plan, the steps in the following
example should be replaced with contact information and
specific courses of action for your organization.
1) The person who discovers the incident will call the grounds
dispatch office. List possible sources of those who may discover
the incident. The known sources should be provided with a
contact procedure and contact list. Sources requiring contact
information may be:
a) Helpdesk

b) Intrusion detection monitoring personnel
c) A system administrator
d) A firewall administrator
e) A business partner
f) A manager
g) The security department or a security person.
h) An outside source.
List all sources and check off whether they have contact
information and procedures. Usually each source would contact
one 24/7 reachable entity such as a grounds security office.
Those in the IT department may have different contact
procedures than those outside the IT department.
2) If the person discovering the incident is a member of the IT
department or affected department, they will proceed to step 5.
3) If the person discovering the incident is not a member of the
IT department or affected department, they will call the 24/7
reachable grounds security department at 555-5555.
4) The grounds security office will refer to the IT emergency
contact list or effected department contact list and call the
designated numbers in order on the list. The grounds security
office will log:
a) The name of the caller.
b) Time of the call.

c) Contact information about the caller.
d) The nature of the incident.
e) What equipment or persons were involved?
f) Location of equipment or persons involved.
g) How the incident was detected.
h) When the event was first noticed that supported the idea that
the incident occurred.
5) The IT staff member or affected department staff member
who receives the call (or discovered the incident) will refer to
their contact list for both management personnel to be contacted
and incident response members to be contacted. The staff
member will call those designated on the list. The staff member
will contact the incident response manager using both email and
phone messages while being sure other appropriate and backup
personnel and designated managers are contacted. The staff
member will log the information received in the same format as
the grounds security office in the previous step. The staff
member could possibly add the following:
a) Is the equipment affected business critical?
b) What is the severity of the potential impact?
c) Name of system being targeted, along with operating system,
IP address, and location.
d) IP address and any information about the origin of the attack.
6) Contacted members of the response team will meet or discuss
the situation over the telephone and determine a response

strategy.
a) Is the incident real or perceived?
b) Is the incident still in progress?
c) What data or property is threatened and how critical is it?
d) What is the impact on the business should the attack
succeed? Minimal, serious, or critical?
e) What system or systems are targeted, where are they located
physically and on the network?
f) Is the incident inside the trusted network?
g) Is the response urgent?
h) Can the incident be quickly contained?
i) Will the response alert the attacker and do we care?
j) What type of incident is this? Example: virus, worm,
intrusion, abuse, damage.
7) An incident ticket will be created. The incident will be
categorized into the highest applicable level of one of the
following categories:
a) Category one - A threat to public safety or life.
b) Category two - A threat to sensitive data
c) Category three - A threat to computer systems
d) Category four - A disruption of services

8) Team members will establish and follow one of the following
procedures basing their response on the incident assessment:
a) Worm response procedure
b) Virus response procedure
c) System failure procedure
d) Active intrusion response procedure - Is critical data at risk?
e) Inactive Intrusion response procedure
f) System abuse procedure
g) Property theft response procedure
h) Website denial of service response procedure
i) Database or file denial of service response procedure
j) Spyware response procedure.
The team may create additional procedures which are not
foreseen in this document. If there is no applicable procedure in
place, the team must document what was done and later
establish a procedure for the incident.
9) Team members will use forensic techniques, including
reviewing system logs, looking for gaps in logs, reviewing
intrusion detection logs, and interviewing witnesses and the
incident victim to determine how the incident was caused. Only
authorized personnel should be performing interviews or
examining evidence, and the authorized personnel may vary by
situation and the organization.

10) Team members will recommend changes to prevent the
occurrence from happening again or infecting other systems.
11) Upon management approval, the changes will be
implemented.
12) Team members will restore the affected system(s) to the
uninfected state. They may do any or more of the following:
a) Re-install the affected system(s) from scratch and restore
data from backups if necessary. Preserve evidence before doing
this.
b) Make users change passwords if passwords may have been
sniffed.
c) Be sure the system has been hardened by turning off or
uninstalling unused services.
d) Be sure the system is fully patched.
e) Be sure real time virus protection and intrusion detection is
running.
f) Be sure the system is logging the correct events and to the
proper level.
13) Documentation—the following shall be documented:
a) How the incident was discovered.
b) The category of the incident.
c) How the incident occurred, whether through email, firewall,
etc.

d) Where the attack came from, such as IP addresses and other
related information about the attacker.
e) What the response plan was.
f) What was done in response?
g) Whether the response was effective.
14) Evidence Preservation—make copies of logs, email, and
other communication. Keep lists of witnesses. Keep evidence as
long as necessary to complete prosecution and beyond in case of
an appeal.
15) Notify proper external agencies—notify the police and other
appropriate agencies if prosecution of the intruder is possible.
List the agencies and contact numbers here.
16) Assess damage and cost—assess the damage to the
organization and estimate both the damage cost and the cost of
the containment efforts.
17) Review response and update policies—plan and take
preventative steps so the intrusion can't happen again.
a) Consider whether an additional policy could have prevented
the intrusion.
b) Consider whether a procedure or policy was not followed
which allowed the intrusion, and then consider what could be
changed to ensure that the procedure or policy is followed in the
future.
c) Was the incident response appropriate? How could it be
improved?

d) Was every appropriate party informed in a timely manner?
e) Were the incident-response procedures detailed and did they
cover the entire situation? How can they be improved?
f) Have changes been made to prevent a re-infection? Have all
systems been patched, systems locked down, passwords
changed, anti-virus updated, email policies set, etc.?
g) Have changes been made to prevent a new and similar
infection?
h) Should any security policies be updated?
i) What lessons have been learned from this experience?

Continuity StrategiesThe CPMT can choose from several strategies i

More Related Content

Similar to Continuity StrategiesThe CPMT can choose from several strategies i (20)

More from AlleneMcclendon878 (20)

Recently uploaded (20)

Continuity StrategiesThe CPMT can choose from several strategies i