CYBERSECURITY INCIDENT RESPONSE

PROGRAM (CIRP)

ACME Business Consulting, Inc.

 TABLE OF CONTENTS
CYBERSECURITY INCIDENT RESPONSE PROGRAM (CIRP) OVERVIEW 5
INTRODUCTION 5
SCOPE & APPLICABILITY 5
ASSUMPTIONS 5
ALIGNMENT WITH LEADING PRACTICES 5
KEY TERMINOLOGY 5
UPDATES 6
CIRP STRUCTURE 7
HIERARCHICAL APPROACH TO INCIDENT RESPONSE 7
CONCEPT OF OPERATIONS (CONOPS) 7
CYBERSECURITY INCIDENT RESPONSE PROGRAM (CIRP) 7
INCIDENT RESPONSE OPERATIONS (IRO) 8
INCIDENT RESPONSE PLANS (IRPS) 9
INCIDENT RESPONSE PHASES 9
PRE-INCIDENT 9
INCIDENT RESPONSE OPERATIONS (IRO) 9
POST-INCIDENT 9
INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) 10
ISIRT STRUCTURE 10
ISIRT STAFFING MODEL 10
ISIRT LEADER 10
ISIRT PARTICIPANTS 11
PHASE 1 – PREPARE 12
INPUTS 12
PREPARATION 12
CONTACT LISTS 12
INCIDENT RESPONSE PLANS (IRPS). 12
TABLETOPS 12
TECHNICAL RESOURCE PLANNING 13
JUMP KIT 13
ASSIGNING UNIQUE INCIDENT NUMBERS 14
DELIVERABLES 14
PHASE 2 – DETECT & ANALYZE 15
INPUTS 15
WORKFLOW – DETECTION & ANALYSIS PROCESS 15
CYBERSECURITY DEPARTMENT (CSD) ACTIVITIES 16
BUSINESS UNIT (BU) ACTIVITIES 16
INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) ACTIVITIES 16
INCIDENT ANALYSIS 16
INCIDENT SOURCE IDENTIFICATION 16
EVIDENCE ANALYSIS 17
ASSESSMENT: INCIDENT CATEGORIZATION 18
ASSESSMENT: INCIDENT SEVERITY 19
ASSESSMENT: INCIDENT PRIORITIZATION 20
UNIQUE CIRCUMSTANCES 20
CRIMINAL ACTIVITY 20
DATA LEAKAGE 21
PAYMENT CARD DATA 21
SENSITIVE PERSONAL INFORMATION 21
DELIVERABLES 22
PHASES 3 – CONTAIN 23
INPUTS 23
WORKFLOW – CONTAINMENT PROCESS 23
INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) 24

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 2 of 75

 INCIDENT RESPONDERS 24
DELIVERABLES 24
PHASES 4 – ERADICATE 25
INPUTS 25
WORKFLOW – ERADICATION PROCESS 25
INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) 25
INCIDENT RESPONDERS 26
DELIVERABLES 26
PHASES 5 – RECOVERY 27
INPUTS 27
WORKFLOW – RECOVERY PROCESS 27
HIGH-LEVEL PROCESS FLOW 27
INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) 27
INCIDENT RESPONDERS 28
DELIVERABLES 28
PHASE 6 – REPORT 29
INPUTS 29
WORKFLOW – REPORTING PROCESS 29
DELIVERABLES 30
AFTER ACTION REVIEW (AAR) 30
ROOT CAUSE ANALYSIS (RCA) 31
RISK REGISTER UPDATE 31
PHASE 7 – REMEDIATE 32
INPUTS 32
WORKFLOW – REMEDIATION PROCESS 32
CYBERSECURITY DEPARTMENT (CSD) 32
INFORMATION RISK MANAGEMENT (IRM) / ENTERPRISE RISK MANAGEMENT (ERM) 32
DELIVERABLES 33
APPENDICES 34
APPENDIX A: INCIDENT RESPONSE ROLES & RESPONSIBILITIES 34
APPENDIX B: KEY STAKEHOLDERS & DESIGNATED INCIDENT RESPONDERS 36
INFORMATION TECHNOLOGY (IT) 36
RETAIL & ECOMMERCE 36
VENDOR XXXX 37
GEOGRAPHIES 37
FORENSIC PROVIDERS 38
APPENDIX C: SCIENTIFIC METHOD OF EVIDENCE ANALYSIS 39
ANALYSIS PROCESS 39
SCIENTIFIC METHOD 39
SCIENTIFIC METHOD – PROCESS EXAMPLE 40
APPENDIX D: REPORTING RESULTS FROM ANALYSIS 41
REPORT CONTENTS 41
PACKAGING THE REPORT 43
APPENDIX E: INDICATORS OF COMPROMISE (IOC) 44
APPENDIX F: SOURCES OF EVIDENCE 47
COMPUTER FRAUD INVESTIGATIONS 47
FINANCIAL FRAUD INVESTIGATIONS 47
PORNOGRAPHY INVESTIGATIONS 48
NETWORK INTRUSION INVESTIGATIONS 48
SOFTWARE PIRACY INVESTIGATIONS 48
WORKPLACE VIOLENCE INVESTIGATIONS 49
NARCOTICS INVESTIGATIONS 49
IDENTITY THEFT INVESTIGATIONS 49
APPENDIX G: EVIDENCE ACQUISITION 51
SECURING THE EVIDENCE 51
DOCUMENTING THE EVIDENCE 53

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 3 of 75

 ACQUIRING THE EVIDENCE 54
APPENDIX H: METRICS 55
APPENDIX I: NOTIFICATION TEMPLATES 56
NOTIFICATION TEMPLATE – ISIRT FORMATION 56
NOTIFICATION TEMPLATE - ONGOING INCIDENT 57
GLOSSARY: ACRONYMS & DEFINITIONS 58
ACRONYMS 58
DEFINITIONS 58
RECORD OF CHANGES 59
ANNEX 1: INCIDENT RESPONSE PLAYBOOK - SCENARIO-BASED INCIDENT RESPONSE PLANS (IRPS) 60
IRP 1-1: CATEGORY 1 (ILLEGAL CONTENT) – CHILD PORNOGRAPHY 60
IRP 2-1: CATEGORY 2 (CRIMINAL CONDUCT) – THEFT / EMBEZZLEMENT 61
IRP 2-2: CATEGORY 2 (CRIMINAL CONDUCT) – EMPLOYEE INSTALLS “SKIMMER” ON POINT OF SALE (POS) DEVICES 62
IRP 3-1: CATEGORY 3 (TECHNOLOGY COMPROMISE) – COMPROMISE OF INTERNET OF THINGS (IOT) TECHNOLOGY 63
IRP 4-1: CATEGORY 4 (BREACH OF SENSITIVE DATA) – STOLEN USB DRIVE WITH SENSITIVE DATA 64
IRP 5-1: CATEGORY 5 (MALWARE) – INFECTED POINT OF SALE (POS) DEVICE 65
IRP 5-2: CATEGORY 5 (MALWARE) – 0-DAY WORM 66
IRP 6-1: CATEGORY 6 (HOST / APPLICATION COMPROMISE) – WEB SERVER COMPROMISE 67
IRP 6-2: CATEGORY 6 (HOST / APPLICATION COMPROMISE) – UNAUTHORIZED WEB SERVER 68
IRP 7-1: CATEGORY 7 (DENIAL OF SERVICE) – DISTRIBUTED DENIAL OF SERVICE (DOS) ATTACK ON CORPORATE WEBSITES 69
IRP 8-1: CATEGORY 8 (LOST / STOLEN ASSET) – UNENCRYPTED LAPTOP STOLEN 70
IRP 9-1: CATEGORY 9 (POOR SECURITY PRACTICE) – ROGUE WIRELESS ACCESS POINT (WAP) ON CORPORATE LAN 71
IRP 9-2: CATEGORY 9 (POOR SECURITY PRACTICE) – UNAUTHORIZED CREDENTIAL SHARING 72
IRP 9-3: CATEGORY 9 (POOR SECURITY PRACTICE) – ACCOUNT COMPROMISE FROM SOCIAL ENGINEERING ATTACK 73
IRP 10-1: CATEGORY 10 (UNKNOWN / OTHER) – CLIENT-REPORTED SECURITY INCIDENT 74
ANNEX 2: DATA LEAKAGE RESPONSE 75
DATA SPILL OVERVIEW 75
AUTHORITATIVE GUIDANCE OF DATA SPILLS 75
KEY PERSONNEL 75

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 4 of 75

CYBERSECURITY INCIDENT RESPONSE PROGRAM (CIRP) OVERVIEW

INTRODUCTION
The Cybersecurity Incident Response Program (CIRP) is used as the guideline for managing cybersecurity alerts and
events. This document provides an overview of ACME’s corporate-wide incident response process.

Having one standardized framework provides a number of benefits, including:

 Increased protection of core business functionality, capabilities, and revenue generating systems;
 Reduced potential impact of non-remediated threats and vulnerabilities;
 Reduced potential impact of incidents to the brand, shareholders, customers, and business partners; and
 Ability to leverage a standardized, documented processes across the enterprise.

SCOPE & APPLICABILITY

The CIRP enables ACME employees to respond to cybersecurity incidents and restore normal operations as quickly as
possible, while minimizing the adverse impact on business operations. This process and methodology ensures that the
best possible levels of service quality and availability are maintained.

The scope of the framework includes all stakeholders in any incident response. The different Business Units (BUs),
service providers, and applicable ACME subsidiaries are contained in the breadth of this document.

ASSUMPTIONS
The following are assumptions related to the CIRP described in this document:
 ACME’s cybersecurity policies and standards are communicated to and are followed by ACME’s users, partners,
and service providers.
 BUs respond to incidents by repeatable, internal processes that support the CIRP for the escalation and
governance of incidents.

ALIGNMENT WITH LEADING PRACTICES

ACME’s methodology used to respond to incidents is based on National Institute of Standards and Technology (NIST)
guidance:
 NIST SP 800-61, Computer Security Incident Handling Guide 1
 NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response 2

KEY TERMINOLOGY
The accepted definitions for cybersecurity terms shall be based on the NIST IR 7298, Glossary of Key Information Security
Terms.3 Highlighted below are key cybersecurity-specific terms that the reader of this document must be familiar with.
Additionally, further cybersecurity-specific definitions can be found in the Glossary.

Asset. Any information system, peripheral hardware, application or data that is used in the course of business activities.

1
NIST 800-61 - http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
2
NIST 800-86 - http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-86.pdf
3
NIST IR 7298 - http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 5 of 75

Event. Any observable occurrence in a system and/or network. Events sometimes provide indication that an incident is
occurring. Examples of events include, but are not limited to:
 Event log entry (e.g., system/security/application);
 Security Incident Event Manager (SIEM) notification;
 Conversation (e.g., in person/email/phone/fax/IM);
 Service desk ticket; and
 Observation by an individual.

Incident. An assessed occurrence that actually or potentially jeopardizes:

 The confidentiality, integrity, or availability of an asset; or
 The data that an asset processes, stores, or transmits.

Examples of incidents include, but are not limited to:

 Lost/stolen asset;
 Malware outbreak; and
 Information security policy violation (e.g., violating acceptable use)

Integrated Security Incident Response Team (ISIRT). An ISIRT is a group of individuals who are organized to develop,
coordinate and execute actions for the containment, eradication, and recovery resulting from cybersecurity incidents.

UPDATES
Updates to the CIRP will be announced to employees via management updates or email announcements. Changes will
be noted in the Record of Changes to highlight the pertinent changes.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 6 of 75

CIRP STRUCTURE

Incidents do not care if responders are or are not prepared to respond. What matters is appropriate leadership that is
capable of directing response operations in an efficient and effective manner.

HIERARCHICAL APPROACH TO INCIDENT RESPONSE

In order to implement an efficient and repeatable incident response methodology, it requires a structure that addresses
the scope from a strategic to a tactical level.

At ACME, there are four (4) hierarchical components that define the concept of incident response across the enterprise:
 Concept of Operations (CONOPS)
 Cybersecurity Incident Response Program (CIRP)
 Incident Response Operations (IRO)
 Incident Response Plan (IRP)

CONCEPT OF OPERATIONS (CONOPS)

ACME's policies and standards associated with incident response establish the strategic approach to incident response.
This high-level corporate guidance forms ACME’s Concept of Operations (CONOPS) for incident response across the
enterprise. This CONOPS helps communicate the quantitative and qualitative expectations to all stakeholders of what
must be employed to achieve the desired objectives.

CYBERSECURITY INCIDENT RESPONSE PROGRAM (CIRP)

ACME’s Cybersecurity Incident Response Program (CIRP) establishes the operational approach to addressing
cybersecurity incidents, so that operations may be conducted in a proactive and sustainable manner.

The CIRP defines how ACME teams will work together to respond to an incident. It leverages ACME’s incident response
capabilities to efficiently and effectively manage all levels of incident response. This allows for differing business units
within ACME to “plug in” to organization-wide processes for responding to cybersecurity events and incidents.

The CIRP is an adaptable framework that:

 Is applicable for use across the enterprise;
 Provides a methodology to categorize incidents, assign severity and impact ratings;
 Assigns roles and responsibilities associated with incident response; and
 Breaks down incident response into manageable phases for escalating incidents and bringing groups together
to respond to incidents.

The CIRP is not:

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 7 of 75

  A detailed Incident Response Plan (IRP) for use by business units or key stakeholders. (reference Annex 1:
Incident Response Playbook for scenario-based incident response)

INCIDENT RESPONSE OPERATIONS (IRO)

The CIRP calls out operational responsibilities for key stakeholders. When a stakeholder is engaged in the incident
response process, those personnel are executing Incident Response Operations (IROs).

With or without vetted IRPs, stakeholders are still responsible for responding to the incidents in a professional manner.
A useful analogy is the childhood game of “hide and seek” where the game begins once the words “ready or not, here I
come” are spoken. Incident response is very similar, since ready or not, the responder has to act. The better prepared
the responder is, the more efficient the IRO will be. This preparation most often comes through documented IRPs and
incident response exercises / training.

In order for incident response activities operate in an efficient and controlled manner at the stakeholder-level, IROs are
expected to leverage Incident Response Plans (IRPs). However, a stakeholder can still conduct IROs without an IRP. The
downside to executing IROs without an IRP is that activities are ad hoc in nature.

IROs are simply areas of responsibility that are assigned to key stakeholders related to cybersecurity incidents:
 Every key stakeholder (e.g., department or team) involved in incident response has an IRO;
 Regardless if a participant is or is not prepared, that key stakeholder must respond in a professional manner to
address the realities of the incident; and
 IROs may overlap and have areas of shared responsibility, so it requires teamwork and leadership involvement
to ensure coordination is performed and tasks are completed.

In the example shown below, an incident may involve dedicated actions by several departments:
 Security Operations Center (SOC);
 Legal;
 Finance;
 Communications; and
 Infrastructure (e.g., firewall and database experts).

Each of these key stakeholders has a unique set of skills and areas of responsibilities. As shown in the diagram, some
areas may overlap, but other areas are specific to their unique job functions at ACME. What makes these department-
level IROs efficient is having well thought out and documented IRPs.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 8 of 75

INCIDENT RESPONSE PLANS (IRPS)
At the department and/or team level, IRPs establish the tactical-level approach towards incident response. IRPs are:
 Meant to be tested and validated on a recurring basis to ensure applicability; and
 “Playbooks” that incident responders follow to ensure proper procedures are adhered to.

Incident responders should use IRPs to handle their response steps. An IRP is the tool that allows an IRO to have a
repeatable structure, since IRPs can be tested to validate the effectiveness of the process(es):
 Without an IRP, IROs operate in an ad-hoc manner;
 IRPs provide repeatable, testable processes to conduct IRO responsibilities;
 IRPs should cover all reasonably-expected incident response scenarios;
 IRPs should be flexible enough to adapt to incidents, but be granular enough to guide an incident responder;
and
 IRPs are a way to proactively answer certain incident responder questions:
o What are the roles & responsibilities within my group?
o What do I do when an incident happens?
o Who do I contact?
o When do I contact others?
o How do I capture documentation?

INCIDENT RESPONSE PHASES

The CIRP addresses the high-level workflow from event collection, to incident declaration, to incident closure. The
process flow framework, illustrated below, outlines the incident response phases:

PRE-INCIDENT
 Phase 1: Prepare

INCIDENT RESPONSE OPERATIONS (IRO)

 Phase 2: Detect & Analyze
 Phase 3: Contain
 Phase 4: Eradicate
 Phase 5: Recovery

POST-INCIDENT
 Phase 6: Report
 Phase 7: Remediate

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 9 of 75

INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT)

The Integrated Security Incident Response Team (ISIRT) is responsible for providing response services, developing an
action plan, and determining the type of leadership escalation that is necessary for an incident. The ISIRT relies on the
expertise and judgment of its team members for investigating escalated incidents and taking action to ensure that the
damage caused by the incident is minimized.

At ACME, ISIRT members are pulled from other job functions on an as-needed basis. During this period of being tasked
to the ISIRT, performing the necessary incident response functions becomes high-priority and should be balanced
appropriately with an employee’s normal responsibilities.

ISIRT STRUCTURE
ACME’s ISIRT structure is based on a centralized incident response model, where a single incident response team handles
incidents across ACME. This model is effective for large organizations with minimal geographic diversity in terms of
computing resources. The structure of the ISIRT is extremely fluid and may consist of employees from any Business Unit
(BU).

References for how the ISIRT is formed and managed include:

 Handbook for Computer Security Incident Response Teams (ISIRTs)4
 Computer Security Incident Response Team (ISIRT) Frequently Asked Questions (FAQ)5
 State of the Practice of Computer Security Incident Response Teams6

Initial meetings of the ISIRT consist of necessary ACME employees and must limit the amount of non-employee
interaction (e.g., contractors or service providers). This approach is designed to reduce confidentiality concerns for
ACME. Once the initial ISIRT formation meetings have taken place and an ISIRT action plan has been established, ACME
can begin to bring in other employees or contractors, if necessary. Employees are expected to perform most of the
incident response work, but some technical support may be outsourced by a third-party security vendor (e.g., Vendor 1
& Vendor 2). The services most often performed by vendors are computer forensics, advanced incident analysis, incident
eradication, and vulnerability mitigation.

The potential impact of the incident should identify the key stakeholders that will comprise the ISIRT. The greater the
potential impact, the higher the point of escalation necessary to resolve the incident. The ISIRT oversees technical
resolution and has technical experts as team members, but a large focus is making sure the appropriate members of
business are aware of the incident, and any actions they need to take in order to reach a resolution.

ISIRT STAFFING MODEL

The ISIRT is intended to be staffed with seasoned professionals and led by an experienced business leader. Appendix A:
Incident Roles and Responsibilities provides definitions and responsibilities for incident response personnel.

ISIRT LEADER
The ISIRT leader is expected to be a member of Cybersecurity Department (CSD) who can ensure the team is effectively
resolving the incident with the appropriate action plan and incident resolution. This individual is expected to work in
tandem with the Business Incident Responders (BIRs) for in-depth knowledge about the BU and the Technical Incident
Responders (TIRs) for additional technical subject matter expertise.

The ISIRT leader’s first and most important task is conducting an informal risk assessment and reviewing it with the BIRs
and TIRs. Once the outcome of the risk assessment is finalized, the potential impact level can be used as a guide for

4
http://www.cert.org/archive/pdf/CSIRT-handbook.pdf
5
http://www.cert.org/CSIRTs/CSIRT_faq.html
6
http://www.cert.org/archive/pdf/03tr001.pdf

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 10 of 75

PHASE 2 – DETECT & ANALYZE

The second phase is “Detect & Analyze” and these activities focus on identifying the type, severity and escalation of the
cybersecurity incident.

INPUTS
During the preparation phase, specific documentation enables the efficient execution of the follow-on phases of the
CIRP process. This documentation includes:
 High Value Assets (HVA) list;
 High Value Data (HVD) map;
 Assigned incident response roles & responsibilities;
 Established contact lists; and
 Incident Response Plans (IRP).

WORKFLOW – DETECTION & ANALYSIS PROCESS

Before an incident can be analyzed and prioritized, the event in question must first be identified and an alert generated
to notify the appropriate individuals.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 15 of 75

CYBERSECURITY DEPARTMENT (CSD) ACTIVITIES
CSD personnel are the key element in the initial assessment of events and determining what additional actions are
required, if any. The general concept of CSD operations in this phase include:
 Automated Alert Notification Process. CSD will serve as intake and also receives automatic notification of
incoming incidents. Once notified, it is their responsibility to escalate the incident appropriately.
 Incident Response Operations-CSD (IRO-CSD). Upon receiving the incident alert, CSD personnel will follow their
own internal processes to validate and prioritize the potential incident. This may include reaching out to other
teams to gather background information.

BUSINESS UNIT (BU) ACTIVITIES

The Business Unit (BU) is the business function or department within ACME that was affected by the cybersecurity
incident. The BU operations in this phase include:
 Provide Details and Triage. The BU often has the greatest subject matter expertise of the cybersecurity incident
and, because of this, will need to work with CSD to provide the details. The BU may also have a refined and
mature process for handling cybersecurity incidents. If this is the case, the BU will provide an extremely active
role in technical triage for the cybersecurity incident.
 Validate Risk Assessment and ISIRT Formation. The decision to create the ISIRT is ultimately done by CSD, but
consensus from the BU is highly encouraged and enables effective incident response.

INTEGRATED SECURITY INCIDENT RESPONSE TEAM (ISIRT) ACTIVITIES

The general concept of ISIRT operations in this phase include:
 ISIRT Formed. Based on the type of incident and the involved parties, CSD and the BPL will identify the
appropriate incident responders to participate in the ISIRT. Each member of the ISIRT is contacted and the team
is established.
 Incident Response Operations (IRO) – ISIRT. Once the ISIRT is formed, the ISIRT Leader will direct work. At this
point, Phase 2 ends and Phase 3 begins.

INCIDENT ANALYSIS
Determining whether a particular event is actually an incident is a matter of judgment, based on available facts. The
incident responders should work quickly to analyze and validate event activities. When an incident responder believes
that an incident has occurred, the incident responder should rapidly perform an initial analysis to determine:
 The incident’s scope, such as which networks, systems, or applications are affected;
 Who or what originated the incident; and
 How the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being
exploited).

INCIDENT SOURCE IDENTIFICATION

Incident precursors and indications can come from both technical and human sources. The event source is simply the
origin of the event. This can be either a human or technical source:
 System User. A user can identify a situation and report that issue to the Service Desk. This submission may be
over the phone or via email.
 System-Generated Alert. Systems logging to the log aggregator (e.g., Security Incident Even Manager (SIEM))
will forward specific events without human interaction.
 Business Unit Personnel. Employees from a business unit can contact CSD directly about incidents.
 CSD Personnel. CSD may observe an alert or behavior that requires additional investigation. CSD personnel
would be responsible for either opening a ticket with Service Desk or manually generating an incident ticket.
 ACME Leadership. Organization leadership may become aware of an event or incident that requires additional
investigation. These organizational leaders are responsible for either opening a ticket with Service Desk or
directly contacting CSD to open an investigation into the potential incident.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 16 of 75

EVIDENCE ANALYSIS
Evidence analysis is a process in which evidence related to an incident is analyzed to learn more about it. While some
evidence may provide all the information an incident responder might need with a surface examination, often, the
evidence needs to be explored more deeply:
 The analysis process must be conducted by an incident responder who is experienced in proper techniques used
to analyze and handle evidence, in order to ensure that evidence is not compromised during the analysis
process.
 Incident responders should assume that an incident is occurring until they have determined that it is not. When
in doubt, incident responders should assume the worst until additional analysis indicates otherwise.
 The initial analysis should provide enough information for CSD to prioritize subsequent activities, such as
containment of the incident and deeper analysis of the effects of the incident.

Evidence-based technical analysis is the process used by ACME to apply the scientific method. Appendix C: Scientific
Method of Evidence Analysis covers the application of the scientific method in the incident response analysis process.
An incident responder must consult with CSD leadership if there is any uncertainty on how to properly analyze or handle
evidence.

Evaluation criteria may be strictly quantitative, qualitative, or it may include a blended approach to determine
prioritization.

QUANTITATIVE CRITERIA
Quantitative criteria focus on measurable aspects of an incident, including but not limited to:
 Amount of data affected;
 Type of data affected;
 Number of users affected;
 Number of times the problem has occurred;
 Impact on business operations;
 Financial;
 Customers; and
 Media.

QUALITATIVE CRITERIA
Qualitative criteria focus on immeasurable aspects of an incident, including but not limited to:
 Type of incident;
 Type of system affected;
 Sensitivity/criticality of the data affected;
 Types of users affected;
 Impact on business reputation or legal liability; and
 Public awareness / exposure of incident.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 17 of 75

ASSESSMENT: INCIDENT CATEGORIZATION
The Cybersecurity Incident Response Program (CIRP) addresses ten (10) categories of cybersecurity incidents. Each
category has the potential to escalate and requires different handling procedures. CSD is responsible for categorizing
the incident into one of the following categories:

# Threat Category Category Description

Simulated This category is used during exercises and approved testing of
Incident internal/external network defenses or responses.
0 Training
(Training &
Exercises)
This category is used for any data that is illegal to have in possession.

1 Illegal Content This includes illegal content such as child pornography or classified
information on unclassified systems.
Illegal Content This category is used for any incident that would be considered criminal
or Activities conduct.
2 Criminal Conduct
This includes embezzlement, corporate espionage, terrorism/national security
threats, fraud, violence or other conduct that would constitute a criminal
felony or misdemeanor charge.
This category is used for any incident that has safety implications from the
compromise of the technology to be used in a manner it was not designed for.
Technology
3 Safety This includes categories of technologies that includes Operational Technology
Compromise
(OT) and Internet of Things (IoT).

This category is used for any incident that has involves the unauthorized
disclosure or compromise of sensitive data.
Breach of This includes sensitive Personally Identifiable Information (PII) and Intellectual
4 Confidentiality
Sensitive Data Property (IP).

This category is used for malware-related incidents.

5 Malware
Any software code intentionally created or introduced into multiple systems
for the distinct purpose of causing hard or loss to the computer system, its
data, or other resources (e.g., spyware, adware, viruses, Trojans, worms, etc.).
This is a known or suspected compromise that is not directly related to
malware.

Nefarious Host /
A successful event of this nature means the attacker has total control over the
6 Activity Application
host or application and access to any and all data stored on it or on systems
Compromise
that trust the compromised host or application.

This may be from a privilege escalation attack.

This is a known or suspected Denial of Service (DoS) attack.
Denial of Service
7 A successful event of this nature means the attacker(s) successfully denied
(DoS)
access to either the entire network, a portion of the network, or to critical
service(s) / website(s).
This category is used to respond to any lost or stolen IT equipment (e.g.,
Lost / Stolen Lost / Stolen
8 laptops, tablets, computers, servers, media, tapes, etc.)
Asset IT Asset

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 18 of 75

PHASES 3 – CONTAIN

The third phase is “Contain” and these activities focus on containing and controlling the identified cybersecurity incident.

INPUTS
The containment phase includes specific inputs from the identification phase that enable the process to move forward.
These inputs include, but are not limited to:
 Incident Details
o Severity;
o Classification; and
o Summary risk assessment.
 Current Incident Status
o Parties involved;
o Scope of the incident;
o Activities currently underway; and
o Planned activities.
 A list of evidence gathered during the incident investigation

WORKFLOW – CONTAINMENT PROCESS

Once an incident is analyzed and prioritized, the incident must be contained.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 23 of 75

APPENDICES
APPENDIX A: INCIDENT RESPONSE ROLES & RESPONSIBILITIES
This table defines roles and responsibilities for cybersecurity-related incident response:
Role Description
An incident responder is a technical point of contact
for acting upon a cybersecurity incident. IRs can also
Incident
be ISIRT team members. There are generally several
Responder
IRs in any incident who represent different
departments.
An Integrated Security Incident Response Team
ISIRT (ISIRT) Member is the representative contact from a
Member specific functional area or department in case a
major cybersecurity incident occurs.
ISIRT The ISIRT Leader is the appointed leader of the ISIRT
Leader for the duration of the incident.
A supervisory role who manages the Cybersecurity
SOC Department (CSD) Security Operations Center (SOC)
Director and is the first layer of management for
cybersecurity incident response.
Initial Point of Contact (POC) for handling
Service Desk
technology-related user escalations.
Information Risk
Global function that conducts risk assessments and
Management
manages risk across the enterprise.
(IRM)
Business Unit Distinct department or business function within
(BU) ACME.
Business Process A supervisory role within a specific Business Unit
Leader (BPL) (BU) who has responsibilities for business processes.
Business A supervisory role within Cybersecurity Department
Technology (CSD) or Information Technology (IT) who has
Leader (BTL) responsibilities to support a specific BU.
Cybersecurity Incident Response Program (CIRP) - Version 2019.1
Responsibilities
The incident responder triages the potential
incident, determines the nature and scope of the
event, and will classify the severity and priority of
the incident. The IR is a resource with responsibility
to assist in all phases of the cybersecurity response
lifecycle.
An ISIRT Member has the responsibility to assist in
the management and resolution of all cybersecurity
incidents. ISIRT Members temporarily report to the
ISIRT Leader for the duration of the incident
response operations.
The ISIRT Leader has the ultimate responsibility for
the management and resolution of all cybersecurity
incidents. Serves as a single voice of command
during an incident. Produces reports and trending
analysis to management based on pre-defined KPIs
and metrics.
ISIRT Support Member. Responsible for the
development and oversight of a comprehensive
cybersecurity operations program.
The Service Desk is responsible for creating a ticket
gathering initial data for potential incidents, and
notifying the CSD SOC.
ISIRT Support Member. Assists the SOC, ISIRT and
business units to develop risk assessments and
appropriate remediation steps.
Varies on the BUs capability to resolve technical
issues. If the incident is not designated Severity 1 by
CSD and they have a mature incident resolution
process, then they will be responsible resolving the
issue. If it is Severity 1, then they will work with IRM
to resolve the issue with potential technical triage
from a third-party provider.
Assigns a Business Incident Responder (BIR) to
represent the BU during incident response
operations. Responsible for creating and maintaining
the BU's Incident Response Plan (IRP).
Assigns a Technology Incident Responder (TIR) to
represent CSD/IT during incident response
operations. Responsible for assisting the BPL with
creating and maintaining the BU's Incident Response
Plan (IRP).
Page 34 of 75
APPENDIX B: KEY STAKEHOLDERS & DESIGNATED INCIDENT RESPONDERS

INFORMATION TECHNOLOGY (IT)

ACME’s IT department covers the following areas of incident response:

END-USER COMPUTING (EUC)

 Scope: Workstations, laptops, mobile devices, minor applications, etc.
 Responsibilities: Subject matter experts for EUC-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

SERVERS
 Scope: Servers
 Responsibilities: Subject matter experts for server-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

MAJOR APPLICATIONS
 Scope: Major Applications (e.g., SAP, SharePoint, etc.)
 Responsibilities: Subject matter experts for major application-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

INFRASTRUCTURE SUPPORT
 Scope: Firewalls, routers, switches, cloud infrastructure, telecommunications, etc.
 Responsibilities: Subject matter experts for infrastructure-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

DATABASE ADMINISTRATORS (DBAS)

 Scope: SQL, MySQL, Oracle
 Responsibilities: Subject matter experts for database-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

RETAIL & ECOMMERCE

ACME Retail & Ecommerce covers the following areas of incident response:

RETAIL (BRICK & MORTAR)

 Scope: ACME “brick & mortar” stores
 Responsibilities: Subject matter experts for retail-related incident response operations.
 Technical Contacts:
o Primary: TBD
o Alternate: TBD

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 36 of 75

APPENDIX D: REPORTING RESULTS FROM ANALYSIS
In an effort to enhance and preserve the professional image of ACME, it is imperative that the reports provided to
clients, business partners, law enforcement or regulators reflect a consistent and professional approach to analysis
and reporting. This includes ensuring attention to detail in proper formatting, word choice, naming conventions, and
overall “look & feel” of the end products ACME delivers. Reports must be peer reviewed, prior to being delivered to
the client.

REPORT CONTENTS
While each investigation is unique, there are core portions of each analysis that should include the following
components:
 Incident Summary;
 Chronology of Events;
 Evidence;
 Media Forensics;
 Analysis; and
 Process Improvements.

INCIDENT SUMMARY
This is a narrative executive summary of the factual events describing:
 WHO is involved?
o SUSPECT: Identify the suspected user
o VICTIM / ACCUSER: Identify the victim or the accusing party
 WHAT happened?
 WHEN did the incident occur?
 WHERE did the incident occur?
 WHY is this incident being investigated? (e.g., what is the accusation?)

CHRONOLOGY OF EVENTS
The chronology of events is a bullet-point narrative that lays out pertinent events in chronological order. The
chronology may include, but is not limited to:
 When was the incident discovered?
 When did evidence gathering occur?
 When was the ISIRT notified?
 When did a meeting take place and who attended?
 When did a phone call occur and with whom?

EVIDENCE
This is a summary list of all the evidence available to the examiner, including but not limited to:
 Local logs;
 Network logs;
 Web history;
 Email history;
 Remote access logs;
 Physical access logs;
 Media images;
 Phone call logs; and
 Handwritten notes.

MEDIA FORENSICS
This is a narrative describing the evidence-based technical analysis methods and findings. This can best be performed
by itemizing the analysis conducted on the available evidence from the previous section.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 41 of 75

ANALYSIS
This is the overall “conclusion” of the report and is the analysis to prove or disprove the primary assumption(s) that
initiated the investigation. This section should be concise and to the point where the accusations are summarily
answered, based on factual analysis.

There are three (3) correct ways to report on the outcome of the analysis:
 The evidence supports the accusation;
 The evidence does not support the accusation; or
 The evidence is inconclusive.

Evidence Supports The Accusation

Evidence supports the accusation(s) when there is clear evidence to support the cause for the investigation. Examples
include:

Example: The analysis of the user’s Internet browsing traffic discovered evidence of browsing activity to
inappropriate sites. The evidence supports HR’s claim of inappropriate use.

Example: The analysis of the user’s email traffic discovered evidence of the user sending restricted emails to
her personal email account. The evidence supports her manager’s claim.

Evidence Does Not Support The Accusation

Evidence does not support the accusation(s) when there is a lack of clear evidence to support the cause for the
investigation. Examples include:

Example: The event logs lack evidence of the user browsing to inappropriate sites. The evidence does not
support HR’s claim of inappropriate use.

Example: The email traffic analyzed does not provide evidence of the user sending restricted emails to her
personal email account. The evidence does not support her manager’s claim.

Evidence Is Inconclusive
Evidence is inconclusive when there is a lack of compelling evidence to support the cause for the investigation.
Evidence should be considered inconclusive if reasonable doubt exists to support the accusation, based solely on the
available evidence. Examples include:

Example: The event logs document Internet browsing traffic to inappropriate sites. However, due to the
nature of the shared account used on the workstation, the evidence is inconclusive to directly link the activity
to the user. The evidence is insufficient to support HR’s claim of inappropriate use and is inconclusive.

Example: While event logs document the user was logged into her workstation and was accessing a web-based
personal email site at the time of the incident, the evidence is inconclusive to support her manager’s claim
that confidential documents were sent via the user’s personal email account to sources outside of ACME.

PROCESS IMPROVEMENTS
Each security incident is an opportunity to test and refine the IROs and IRPs of all the parties involved. The report
should include potential process improvements, as applicable.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 42 of 75

Image G-1: Evidence Bag Example

ACQUIRING THE EVIDENCE

Manufacture-recommended procedures must be followed for using drive duplication or evidence acquisition tools.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 54 of 75

IRP 2-1: CATEGORY 2 (CRIMINAL CONDUCT) – THEFT / EMBEZZLEMENT
Category Description: This category is used for any suspected incident involving theft, embezzlement, violence or other
criminal conduct.

Scenario: Legal notifies CSD leadership of a suspected embezzlement incident. The suspect is a contractor working on
SAP upgrades for the Finance department.

Step 1 - Initial Notification & Information Gathering (Phase 2 - Identify)

 The CSD director will assign an incident responder to work on the incident.
 The assigned incident responder will gather the facts & assumptions from Legal.

Step 2 - Classification & Severity Ranking (Phase 2 - Identify)

CSD will categorize & log the incident as:
 Category: 2 Criminal Conduct (embezzlement)
 Severity: 1 (Potential impact to the brand & revenue)

Step 3 - Initial Triage & Escalation Decisions (Phase 2 - Identify)

 Incident responder will work with SAP security and the Finance department to identify systems and
accounts.
 Incident responder will document the findings and gather initial forensic evidence during this step.

Step 4 - ISIRT Briefing (Phase 2 - Identify)

It is likely CSD will want to form an ISIRT for this incident. The likely parties will be CSD, IRM, Legal, HR, Finance and
various technical support personnel.
 CSD’ assigned incident responder will act as a ISIRT member for the duration of the investigation.

Step 5 - Operational Containment of Threat (Phase 3 - Containment)

CSD will validate all affected user and service accounts are either disabled or have the password changed.

Step 6 - Operational Eradication of Threat (Phase 4 - Eradication)

CSD will monitor the SIEM for evidence of unauthorized account usage.

Step 7 - Operational Recovery of Systems and/or Data (Phase 5 - Recovery)

For any recovered systems, CSD will scan the system for malware and look for unauthorized accounts.

Step 8 - Post-Incident Reporting (Phase 6 - Report)

 The ISIRT leader will consolidate notes for the official write-up of the report.
 ISIRT members will review the official report and provide feedback, as necessary.

Step 9 - Post-Incident Remediation (Phase 7 - Remediate)

N/A - In this scenario, there are no expected remediation steps that would likely be assigned to CSD.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 61 of 75

IRP 2-2: CATEGORY 2 (CRIMINAL CONDUCT) – EMPLOYEE INSTALLS “SKIMMER” ON POINT OF SALE (POS) DEVICES
Category Description: This category is used for any suspected incident involving theft, embezzlement, violence or other
criminal conduct.

Scenario: A ACME employee installs a skimmer on multiple POS devices throughout North America.

Step 1 - Initial Notification & Information Gathering (Phase 2 - Identify)

 CSD will gather the facts & assumptions from Retail operations.
 The CSD SOC director will be immediately brought up to speed on the incident’s facts & assumptions.

Step 2 - Classification & Severity Ranking (Phase 2 - Identify)

CSD will categorize & log the incident as:
 Category: 2 Criminal Conduct (theft of payment card data for identify theft purposes)
 Severity: 1 (Potential impact to the brand & revenue)

Step 3 - Initial Triage & Escalation Decisions (Phase 2 - Identify)

 The CSD director will assign an incident responder to work directly with the ISIRT and possible law
enforcement involvement for the handling of the incident and any evidence gathering.
 CSD will perform a preliminary search of who the user is and his/her Internet usage to try and identify
possible collection points for the skimming operation.

Step 4 - ISIRT Briefing (Phase 2 - Identify)

It is likely CSD will want to form an ISIRT for this incident. The likely parties will be CSD, IRM, Retail operations, Retail
and Legal.
 CSD’ assigned engineer will act as the ISIRT member for the duration of the investigation.

Step 5 - Operational Containment of Threat (Phase 3 - Containment)

N/A - In this scenario, there are no expected containment steps that would likely be assigned to CSD.

Step 6 - Operational Eradication of Threat (Phase 4 - Eradication)

N/A - In this scenario, there are no expected eradication steps that would likely be assigned to CSD.

Step 7 - Operational Recovery of Systems and/or Data (Phase 5 - Recovery)

N/A - In this scenario, there are no expected recovery steps that would likely be assigned to CSD.

Step 8 - Post-Incident Reporting (Phase 6 - Report)

 The ISIRT leader will consolidate notes for the official write-up of the report.
 ISIRT members will review the official report and provide feedback, as necessary.

Step 9 - Post-Incident Remediation (Phase 7 - Remediate)

N/A - In this scenario, there are no expected remediation steps that would likely be assigned to CSD.

Cybersecurity Incident Response Program (CIRP) - Version 2019.1 Page 62 of 75