Domain 4: Incident Management

Incident Management Readiness

Incident management programs should be seen as a subset of the risk management

process; focused on reducing impact of risk & returning system(s) to acceptable
operational capacity ASAP.

Incident Management - ability to manage an incident when it occurs start to finish

Incident Response - ability to address an incident that has occured

Goals of both Incident Management & Incident Response:

• Identify/detect incidents quickly

• Diagnose incidents accurately
• Minimize impact
• Restore functionality/availability
• Identify Root Cause
• Improve to prevent recurrence
• Document & report

Incident handling & incident management lifecycle: (what does it involve)

Detection & reporting

Triage
Analysis
Incident Response

Phases of Incident Response - For incident response to be effective, organizations

anticipate that incidents will occur and develop incident response plans, test
those plans, and train personnel.

The following are the phases of incident response (5):

• Planning / Preperation

• Detection | Triage | Investigation

• Containment | Analysis | Tracking | Recovery

• Post-Incident assessment

• Incident closure

Planning/Preparation - involves the development of written response plans,

guidelines, and procedures that are followed when an incident occurs. These
procedures are created once the organization’s practices, processes, and
technologies are well understood. This helps to ensure that incident response
procedures align with security policy, business operations, the technologies in
use, and practices in place regarding its architecture, development, management,
and operations. The plans, guidelines, and procedures should identify and include
key external partners.

Detection | Triage | Investigation - represents the time when an organization is

initially aware that a security incident is taking place or has taken place.

Define | Detect | Prioritize incidents, events & notification processes

Implement detection & monitoring capabilities

Often a period of time elapses between the start of the actual incident and the
moment that the organization is aware of it. This period of time is known as DWELL
TIME.

The ability to detect an intrusion or incident requires a capability known as EVENT

VISIBILITY.

Typically, event visibility is achieved through the use of event log collection and
analysis tools (typically, a security information and event management system),
together with other tools the detect activities in networks and in servers and
endpoints.

Containment | Analysis | Tracking | Recovery -

Containment - incident responders perform or direct actions that halt the

progress or advancement of an incident.

Analysis - response team members analyze available data in order to

understand the cause, scope, and impact of the incident. This may involve the use
of forensic analysis tools that are used to understand activities on individual
systems.

Tracking - determine source(s) of the incident

Recovery - recover systems or components to their pre-incident state.

Post-Incident assessment - incident responders and other personnel meet to discuss

the incident: its cause, impact, and the organization’s response.

Incident closure - reports submitted to stakeholders

*** DO NOT OVERLOOK OR FORGET IMPORTANCE OF Retention of Evidence - A chain of
custody may be required to ensure the integrity of evidence. Several standards are
available that guide organizations toward a structured and organized incident
response, including NIST SP 800-61 R2, “Computer Security Incident Handling Guide.”

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Things to remember from prior domains:

1. Organizational Maturity impacts the ability to execute successfully

2. Right people + Right Tools + Adequate planning and resources = SUCCESS

3. Outsourcing is an option to fill skill gaps based on gap assessments

4. Security incident response plans should contain information about specific roles
and responsibilities to ensure that a security incident is handled properly.

Security incident response, business continuity planning, and disaster recovery

planning are often considered separate disciplines, but they share a common
objective: the best possible continuity of business operations during and after a
threat event.

Security incident response, business continuity, and disaster recovery all require
advance planning so that the organization will have discussed, documented, and
outlined the responses required for various types of incidents in advance of their
occurrence.

(REMEMBER that risk assessments are the foundation of planning for all three
disciplines, as it is necessary to discover relevant risks and to establish
priorities during response.)

NOTE: Planning for security incident response, business continuity, and disaster
recovery leads to the improvement of systems and processes.

What is an incident? - an event that has a negative outcome vis-a-vis C I A against

one or more assets

What is a computer security incident? - an event that has a negative outcome vis-a-
vis C I A against one or more assets as the result of a deliberate attack or
intentional malicious action on the part of one or more users

Security incident - an event where the confidentiality, integrity, or availability

of information (or an information system) has been or is in danger of being
compromised.

A security incident can also be thought of as any event that represents a violation
of an organization’s security policy.

NOTE: A vulnerability that is discovered in an organization is not an

incident.
The Intrusion Kill Chain - a model that depicts a typical computer intrusion. The
phases are as follows:

• Reconnaissance - intruder researches and identifies targets and learns still more
about the selected target in order to choose a method of attack.

• Weaponization - intruder creates or obtains malware that will be used to

compromise a target system.

• Delivery - intruder creates a means by which the attack will be delivered to the
target system.

• Exploitation - malware exploits a weakness identified in the target system during

reconnaissance.

• Installation - malware installs itself on the target system.

• Command and control - malware communicates back to an outside server owned or

controlled by the intruder so that the intruder may begin his or her actions on the
attack objective.

• Actions on objective - intruder proceeds with the attack plan, which may consist
of stealing data, damaging or destroying data, or disrupting the operations of one
or more systems.

=============

Incident Response Plan

Must be supported by Policies | Standards | Procedures that are well documented -->
ONE SIZE FITS ONE !!!

Information Security Manager plays a pivotal role in Incident response & needs to
have a good understanding of BCDR processess to be effective & must act as a bridge
to connect/link resources from other departments/areas of the organization as
needed as part of response. (value delivery)

Incident Response methodologies:

CMU SEI Defining Incident Management Processes:

Prepare - getting resources in order and deciding on a plan

Protect - proactive activities to improve posture and mitigate risk(s)
Detect - vigilance wins the day (proactive + reactive)
Triage - sorting, categorizing, correlating, prioritizing & assigning
Respond - technical, management & legal actions taken to address the
incident

Information Security Managers MUST develop an understanding of the current state of

operations and defenses, and then assess where gaps may be and address them

What are the elements that make up an Incident Response Plan (6)?

IRP's should be aligned with and based on a 6 phase approach to Incident Response:

Prepare
Identify
Contain
Eradicate
Recover
Lesson Learned

*** Remember the importance of the following in relation to the plan:

Gap Analysis to seek areas of improvement

Know before you Need
Training
Communication

Common issues to be aware of

Lack of Senior Management support

Misalignment vis-a-vis organizational goals/objectives
Team turnover
Lack of clear defintions and documentation
Complexity

=============

Business Impact Analysis (BIA)

Business Impact Analysis (BIA) - Used to determine what impact a disruptive event
would have on an organization.

Goals:

1. Determine Criticality
2. Estimate Maximum Downtime
3. Evaluate Internal and External Resource Requirements

Process Steps:

1. Gather requirements/information
2. Vulnerability assessment
3. Risk Analysis
Quantitative - ALE = SLE * ARO
Qualitative
4. Communicate findings - Audience relevancy
Criticality Analysis (CA) - ONLY once all of the BIA information has been collected
and charted, can the criticality analysis (CA) be performed.

The criticality analysis is a study of each system and process, a consideration of

the impact on the organization if it is incapacitated, the likelihood of
incapacitation, and the estimated cost of mitigating the risk or impact of
incapacitation.

(it’s a special type of a risk analysis that focuses on key processes and systems)

The criticality analysis needs to include, or reference, a threat analysis. A

threat analysis is a risk analysis that identifies every threat that has a
reasonable probability of occurrence, plus one or more mitigating controls or
compensating controls, and new probabilities of occurrence with those
mitigating/compensating controls in place.

NOTE: BIA --> CA ... NOT THE OTHER WAY AROUND !!!

NOTE: Make sure that any answers you select facilitate the BIA and then the CA
before moving on toward objectives and strategies.

============

Spotlight on BIA Derived Objectives

Determining Downtime:

Maximum Allowable Downtime (MAD) / Maximum Tolerable Downtime (MTD) / Acceptable

Interruption Window (AIW)

Maximum Tolerable Outage (MTO)

Recovery Time Objective (RTO)

Recovery Point Objective (RPO)

Service Delivery Objective (SDO)

Recovery Capacity Objective (RCapO)

Recovery Consistency Objective (RCO)

PAY ATTENTION --> Senior management should be involved in ANY/ALL discussions

related to recovery system specifications in terms of capacity, integrity, or
functionality.

Maximum Tolerable Downtime (MTD) - A (theoretical) period of time, measured from

the onset of a disaster, after which the organization’s survival is at risk.
Establishing MTD for each critical process is an important step that aids in the
establishment of key recovery targets.

Maximum Tolerable Outage (MTO) - A measure of the maximum time that an organization
can tolerate operating in recovery (or alternate processing) mode.

This metric comes into play in situations where systems and processes in recovery
mode operate at a lower level of throughput, consistency, or integrity. MTO drives
the need to reestablish normal production operations within a specific period of
time.

Recovery Time Objective (RTO) - "The time that it takes to recover data and
applications" ---> A LITTLE TOO SIMPLE !!!

How about ... "The targeted duration of time within which a business process must
be restored after a disruption in order to avoid unacceptable consequences
associated with a break in business continuity"

Your RTO should be defined on a per application basis in order to prioritize the
recovery of certain applications, in advance of others, depending on their level of
criticality.

ALSO, KEEP IN MIND THAT ... RTO does not mean that the system (or process) has been
recovered to 100 percent of its former capacity. In an emergency situation,
management may determine that a DR server in another city with, say, 50 percent of
the capacity of the original server is adequate. An organization can establish two
RTO targets, one for partial capacity and one for full capacity.

Recovery Point Objective (RPO) - The point in time you can recover to in the event
of a disaster.

If you have an RPO of 4 hours on your critical applications then this means you
would lose 4 hours of data, as 4 hours ago is the last point in time to which you
can recover.

(The value of a system’s RPO is usually a direct result of the frequency of data
backup or replication)

Service Delivery Objective (SDO) - Level of services supported during recovery;

must be related to business objectives

Recovery Capacity Objective (RCapO) - The processing or storage capacity of an

alternate process or system, as compared to the primary process or system.

RCapO is generally expressed as a percentage.

Management may agree that a recovery site with reduced processing capacity is an
acceptable trade-off, given the relatively low likelihood that a failover to a
recovery site would occur.
Recovery Consistency Objective (RCO) - The consistency and integrity of processing
in a recovery system, as compared to the primary processing system.

RCO is calculated as:

1−(number of inconsistent objects) / (number of objects)

Once these objectives are known, the disaster recovery (DR) team can begin to build
system recovery capabilities and procedures that will help the organization to
economically realize these targets.

===============

Business Continuity Plan (BCP)

ISACA defines Business Continuity as "preventing, mitgating & recovering from

disruption."

International Consortium for Organizational Resilience defines Business Continuity

as "a management process that identifies potential threats to an organization and
the impact(s) to business operations if those threats are realized."

Business continuity planning is undertaken to reduce risks related to the onset of

disasters and other disruptive events. BCP activities identify risks and mitigate
those risks through changes or enhancements in technology or business processes so
that the impact of disasters is reduced and the time to recovery is lessened.

The primary objective of BCP is to improve the chances that the organization will
survive a dsiruption without incurring costly or even fatal damage to its most
critical activities.

BCP vs DRP ? - BCP tends to be more strategic in nature and focus DRP tends to be
more tactical. Regardless, the most important priority is ALWAYS people !!

Restoration vs. Recovery:

a. Recovery - bringing operations back to a working state

b. Restoration - bringing a facility back to a working state

The Business Continuity Planning Process - Plan first, act later.

The business continuity planning process is a life-cycle process, a set of

activities that result in the ongoing preparedness for disaster that continually
adapts to changing business conditions and that continually improves. The following
are the elements of the BCP process life cycle:
• Assign ownership of the program
• Develop BCP policy
• Conduct business impact analysis
• Perform criticality analysis
• Establish recovery targets
• Define KRIs and KPIs
• Develop recovery and continuity strategies and plans
• Test recovery and continuity plans and procedures
• Test integration of BCP and DR plans
• Train personnel
• Maintain strategies, plans, and procedures through periodic reviews and updates

BCP Policy - BCP should be an integral part of the IT control framework, not lie
outside of it.

BCP policy should include or cite specific controls that ensure that key activities
in the BCP life cycle are performed appropriately.

BCP policy should also define the scope of the BCP strategy. This means that the
specific business processes (or departments or divisions within an organization)
that are included in the BCP effort must be defined.

What are the considerations for continuity and recovery plans?

EVERY LITTLE THING !!!

Components of a Business Continuity Plan - The complete set of business continuity

plan documents should include the following:

• Supporting project documents - including the project charter, project plan,

statement of scope, and statement of support from executives

• Analysis documents - These include the following:

• Business impact analysis

• Threat assessment and risk assessment
• Criticality analysis
• Documents defining recovery targets such as recovery time objective,
recovery point objective, recovery capacity objective, and recovery consistency
objective

• Response documents - These are all the documents that describe the required
action of personnel when a disaster strikes, plus documents containing information
required by those same personnel. Examples of these documents include the
following:

• Business recovery (or resumption) plan - describes the activities required

to recover and resume critical business processes and activities.

• Occupant emergency plan (OEP) - describes activities required to safely

care for occupants in a business location during a disaster. This will include both
evacuation procedures and sheltering procedures.

• Emergency communications plan - describes the types of communications

imparted to emergency response personnel, employees in general, customers,
suppliers, regulators, public safety organizations, shareholders, and the public.

• Contact lists - contain names and contact information for emergency

response personnel as well as for critical suppliers, customers, and other parties.

• Disaster recovery plan - describes the activities required to restore

critical IT systems and other critical assets, whether in alternate or primary
locations.

• Continuity of operations plan (COOP) - describes the activities required to

continue critical and strategic business functions at an alternate site.

• Security incident response plan (SIRP) - describes the steps required to

deal with a security incident that could reach disaster-like proportions.

• Test and review documents - This is the entire collection of documents related to
tests of all of the different types of business continuity plans, as well as
reviews and revisions to documents.

Network Services continuity is provided via:

Redundancy
Alternative Routing
Diverse Routing
Long-Haul network diversity
Last-Mile circuit protection
Voice & Telephony recovery

Understand the differences between DAS | NAS | SAN for storage services

Keep in mind that the strategies used to recreate data and ensure availability are
linked to RPO & RTO !!!

RPO strategies:

Database Shadowing (seconds)

Remote Journaling (minutes to hours)
Tape Backup (minutes to days)

RTO strategies:

Clustering (seconds)
Remote Replication (minutes)
Online Restore (hours)
Tape Restore (hours to days)

Know the difference between Fault Tolerance (FT) & High Availability (HA)

FT --> NO downtime
HA --> Variable downtime
Understand that insurance is a way to treat risk through transferance or sharing,
and should be considered as part of the Incident Response Plan.

=================

Disaster Recovery Plan (DRP)

Disaster Recovery Planning (DRP) - undertaken to reduce risks related to the onset
of disasters and other events.

DRP is mainly an IT function to ensure that key IT systems are available to support
critical business processes.

*** REMEMBER ... Disaster recovery planning is closely related to business

continuity planning; specifically, DRP is a subset of BCP!!!

BCP is focused on prevention and mitigation

DRP is focused on restoration

The groundwork for DRP begins in BCP activities such as the business impact
analysis, criticality analysis, establishment of recovery objectives, and testing.
The outputs from these activities are the key inputs to DRP:

• The business impact analysis and criticality analysis help to prioritize which
business processes (and, therefore, which IT systems) are the most important.

• Key recovery targets specify how quickly specific IT applications are to be

recovered. This guides DRP personnel as they develop new IT architectures that make
IT systems compliant with those objectives.

• Testing of DRP plans can be performed in coordination with tests of BCP plans to
more accurately simulate real disasters and disaster response.

Recovery Site Strategies -

Chosen by an organization based on the respective RTOs of the critical processes

where the recovery windows of the RTOs must be less than the Maximum Tolerable
Downtime (MTD).

Redundant Center (mirror site) - employed for applications that cannot accept any
downtime without negatively impacting the organization. The applications are split
between two geographically dispersed data centers and either load balanced between
the two centers or hot swapped between the two centers. The surviving data center
must have enough head room to carry the full production load in either case.
 Advantages of a redundant center:
a. Little or no downtime
b. Ease of maintenance
c. No recovery required

Disadvantages of a redundant center:

a. Most expensive option
b. Requires redundant hardware, networks, staffing
c. Distance limitations

Hot Site - standby ready with all the technology and equipment necessary to run the
applications positioned there. The administrator will be able to effectively
restart an application in a hot site recovery without having to perform any bare
metal recovery of servers. If this is an internal solution, then often the
organization will run non-time sensitive processes there such as development or
test environments, which will be pushed aside for recovery of production when
needed. When employing this strategy, it is important that the two environments be
kept as close to identical as possible to avoid problems with O/S levels, hardware
differences, capacity differences, etc., from preventing or delaying recovery.

If this is an external hot site, the environment must be rebuilt for the recovery.
These are services contracted through a recovery service provider. Again, it is
important that the two environments be kept as close to identical as possible to
avoid problems with O/S levels, hardware differences, capacity differences, etc.,
from preventing or delaying recovery. Unique equipment or software would generally
need to be provided by the organization.

Advantages of internal or external hot site:

a. Allows recovery to be tested
b. Highly available
c. Site can be operational within hours

Disadvantages of internal or external hot site:

a. Hardware and software compatibility issues in external sites

Warm Site - A facility that is partially configured with some data center support
infrastructure, such as HVAC, computers, etc. It will generally have all the
cooling, cabling, and networks in place to accommodate the recovery but the actual
servers, mainframe, etc., equipment are delivered to the site at time of disaster.
#

Cold Site - a shell or empty data center space with no technology on the floor. All
technology must be purchased or acquired at the time of disaster.

Advantages of warm and cold site:

a. Less expensive
b. Available for longer recoveries

Disadvantages of warm and cold site:

a. Not immediately available
b. Not fully testable without extensive work

Mobile Site - Drive | Drop | Data !!

Service Bureaus - a company that leases computer time via contract. Can be onsite
or remote.

Cloud recovery - IaaS | PaaS | SaaS

DRaaS - Disaster Recovery as a Service

Mutual Assistance Agreements (reciprocal agreements)- You agree to help me and I

agree to help you in a time of need, but not very practical if circumstances get in
the way.

Do not forget about where your data resides !! (databases) ...

a. Electronic Vaulting - database backups are moved to a remote site using a

bulk transfer capability. Remote site can be a dedicated facility or a co-
location/cloud solution.

b. Remote Journaling - quicker version of electronic vaulting, using bulk

transfers of data, but more frequently. Focus is on copying and transferring the
transaction log files instead of the entire database.

Multiple Processing Sites (duplicate sites) - a solution if the organization’s

facilities are geographically distributed. If multiple processing sites are used
for the production environment they should be treated as an organizational
“reciprocal” agreement. This means workloads must be categorized based on
criticality to the organization and each location must be able to process, store
and transmits another’s workload.

================

Incident Classification & Categorization

Understand the need to triage incidents to allow for priortized response and
utilization of resources

Escalation process needs to be clearly defined by the Information Security Manager

in partnership with management

Processess to guide the help/servive desk in identifying what is an incident vs.

what is a request for help need to be estabished and trained on

===================

Incident Management Training Testing & Evaluation

Testing/evaluation of Incident Response Plans should be done regularly (at a

minimum ANNUALLY)

EVERYONE invloved in response activities should be trained (on-going) to ensure

that they understand their role and the responsibilities they own

CHANGE = EVALUATE THE PLAN

Senior Management MUST be committed to the plan for it to succeed !!!

Information Security Manager is responsible for the plan and everything that
supports it and/or that it touches

REMEMBER THE IMPORTANCE OF METRICS (KPI | KRI | KGI) & RESTORATION OBJECTIVES !!!

Test Disaster Recovery Plans (DRP) - Plans must be tested periodically (at a
minimum annually) in order to ensure alignment and relevancy to the organization.

Three testing categories:

1. Paper (test types 1 & 2)

2. Preparedness (test type 3)
3. Full operational (test types 4 & 5)

Five test types:

1. Read-Through / Desk Check / Checklist - copies of the plan are distributed

to the members of the team for review so that basic facts and details can be
validated. This is done on an individual basis.

2. Structured Walk-Through (table-top) - Team members meet and discuss each

plan element and procedure. They step through the plans and have some role
interaction, done within a conference room. They assess effectiveness and
limitations. Deficiencies or areas for improvement are noted for the test report
and post-test review.

3. Simulation (functional tests or war games) - Cost and complexity are

increased, as simulations require planning and coordination. Simulations typically
include a pretend disaster, and all teams exercise their training and judgment and
simulate their actions.

4. Parallel - higher cost and more complex, as it takes advantage of test

time at the actual recovery site. Note that parallel testing does not impact
operations. The benefit of parallel testing is that recovery site processing
results can be compared with the primary site’s processing. Another benefit is that
recovery procedures may be more fully tested and personnel more fully trained. A
parallel test is basically an operations test to show that critical systems can be
run at the alternate site.

5. Full-Interruption / Cutover - the highest cost and most complex test.

Primary operations are shut down and continuity relies solely on recovery procedure
accuracy, completeness, and personnel ability. Full interruption should only be
considered after successful parallel testing and only conducted under steering
committee and senior management authorization.

===================

Incident Management Tools & Techniques

Centralized systems include:

SIEM - Security Information & Event Management

EDR - Endpoint Detection & Response
XDR - Extended Detection & Response
MDR - Managed Detection & Response

Incident Response Team (IRT) models:

Centralized - one team to handle ALL

Distributed - multiple teams based geographically or by specialty
Coordinating - Centralized guides Distributed
Outsourced - hired talent

Roles & responsibilities of IRT personnel.docx

Audits are helpful to review the alignment of the IRP with all current policies,
standards & procedures.

Internal
External

Incident Response may be outsourced if the skills and resources necessary to

execute do not exist within the organization

==================

Evaluation Containment Communication & Recovery

Things to remember from prior domains:

1. Organizational Maturity impacts the ability to execute successfully

2. Right people + Right Tools + Adequate planning and resources = SUCCESS

3. Outsourcing is an option to fill skill gaps based on gap assessments

4. Security incident response plans should contain information about specific roles
and responsibilities to ensure that a security incident is handled properly.

Event vs Incident

The IT Infrastructure Library (ITIL) defines an incident as “any event which is not
part of the standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service. The stated ITIL
objective is to restore normal operations as quickly as possible with the least
possible impact on either the business or the user, at a cost-effective price.”

CONTEXT IS KEY TO SUCCESS

Plan execution should be assigned to a coordinator/facilitator who is

qualified (may not be the ISM)

Testing is CRUCIAL to success of plan when needed

Containment activities will be driven by the nature of the incident

Clear and formally defined lines of communication & notification requirements need
to be established, documented and communicated in advance of an incident

Mission critical communication networks necessary for Incident Response should also
be identified in advance of an incident and prioritized as part of the BIA

Containment vs Eradication

RECOVERY DOES NOT MEAN A RETURN TO BUSINESS AS USUAL

==================

Post-incident Review Practices

Continuous Improvement is key goal of Post-incident Review Practices

Root cause(s) & corrective action(s) should be derived

Documentation is key to lessons learned and Root Cause identification

IRPs should be aligned with ALL regulatory/statutory requirements & should be

positioned to provide legally sound outcomes that are defensible if necessary in
court
Forensic Investigations - required when a security incident has occurred and it is
necessary to gather evidence to determine an incident’s cause and effects.

Because the information gathered in an investigation may later be used in a legal

proceeding, a forensic investigator must follow strict chain of custody procedures
when gathering, studying, and retaining information.

Before a security professional can begin to identify evidence, the larger incident
scene needs to be dealt with. A incident scene is the environment in which
potential evidence may exist. The principles of criminalistics to apply are:

a. Identify the scene

b. Protect the environment
c. Identify evidence and potential sources of evidence
d. Collect evidence
e. Minimize the degree of contamination

Forensic Techniques and Considerations - Computer and network forensics requires

several specialized techniques that ensure the integrity of the entire forensic
investigation and a sound chain of evidence. Some of these techniques are as
follows:

• Data acquisition

• Data extraction (this must be done in a way that proves the source of the
data and that it was not altered during the extraction process)

• Data protection

• Analysis and transformation

Chain of Evidence (Chain of Custody) - documents the evidence lifecycle from

discovery and collection through analysis and storage to reporting and
presentation. EVERY activity and EVERY interaction no matter how small must be
recorded and become part of the chain, or the evidence is tainted and cannot be
used in court. Specific items that must be noted when evidence is collected and
labeled:

a. General description of the evidence

b. Time & date evidence was collected
c. Exact location the evidence was collected from
d. Name of the person collecting the evidence
e. Relevant circumstances surrounding the collection

*** NOTE: The key to an effective and successful forensic investigation is

the establishment of a sound chain of custody. The major considerations that
determine the effectiveness of a forensic investigation are as follows:
• Identification - description of the evidence that was acquired and the tools and
techniques used to acquire it.

• Preservation - description of the tools and techniques used to retain evidence.

This will include detailed records that establish the chain of custody, which may
be presented and tested in legal proceedings.

• Analysis - description of the examination of the evidence gathered, which may

include a reconstruction of events that are a subject of the investigation.

• Presentation - formal document that describes the entire investigation, evidence

gathered, tools used, and findings that express the examiner’s opinion of the
events that occurred (or did not occur).

Evidence collection and handling -

NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response is a

good resource