Professional Documents
Culture Documents
Example Cybersecurity Incident Response Program Cirp PDF
Example Cybersecurity Incident Response Program Cirp PDF
Example Cybersecurity Incident Response Program Cirp PDF
PROGRAM (CIRP)
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.
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.
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
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.
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.
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)
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.
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.
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?
PRE-INCIDENT
Phase 1: Prepare
POST-INCIDENT
Phase 6: Report
Phase 7: Remediate
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).
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 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
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).
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).
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.
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).
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.
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
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
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.
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.
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.
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.
Scenario: Legal notifies CSD leadership of a suspected embezzlement incident. The suspect is a contractor working on
SAP upgrades for the Finance department.
Scenario: A ACME employee installs a skimmer on multiple POS devices throughout North America.