Hello all! I was recently tasked with performing an IR Policy uplift at my organization, and wanted to share an anonymized version of it here! 90% of the formatting survived, so feel free to use (or critique) it if you’d like!
It’s mostly based on NIST 800-61, with some of the SANS incident lifecycle and Verizon VERIS categorizations thrown in, and should be useful for medium-low maturity organizations such as my own.
Throughout the document “VVVV” was used to redact the company name, you should be able to find\replace with your own company name if needed. Otherwise, if you have questions ask away!
**VVVV Information Security Incident Response Policy**
**1.** **Incident Response Policy Overview**
This document formally defines the goals and expectations that VVVV personnel will execute upon while responding to threats to the organization.
This Policy draws heavily from the industry best-practice NIST framework, as defined in [NIST SP-800-61 Rev. 2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) written and published by the U.S. Department of Commerce.
Topics covered in this policy include:
· Defining the terms: *Incident*, *Impact*, and *Severity*
· Incident Response lifecycle, Incident categorization
· Escalation process and relevant stakeholder roles
· Communication requirements, frequency
· Incident Response policy maintenance
Ultimately, the objective of the Incident Response program is to respond quickly and effectively to threats which have the potential to disrupt Confidentiality, Availability, Integrity, and Non-repudiation of business-related activities.
**2.** **Common Language and Definitions**
Event – Any observable occurrence in a system or network
Alert – An event which has been flagged by a security control, either automatically or manually, to be reviewed by the information security team
Incident – An investigation of an alert that contains notes, observations, and actions taken by an incident responder
Types – Security Incidents are categorized in the following ways:
Malware – evidence of malicious code execution
Environmental – infrastructure issues such as power, cooling, weather
Physical – asset is physically stolen, damaged, or handled incorrectly
Error – Config errors, such as unpatched vulnerabilities, poor practices
Misuse – Evidence of intentional or unintentional asset misuse
Social – situations involving phishing, or other deceptive attacks
Hacking – active, advanced attacks, or 3rd party breach requiring action
Severity – A measure of the functional and informational impact of an incident, as well as the effort required to recover from a successful attack.
Critical – Requires formal execution of the Incident Response Plan, potentially engaging 3rd parties such as Incident Response, Legal, or Insurance retainers
· Functional: The widespread inability of the organization to provide any critical services to users
· Information: Confirmed data exfiltration of either proprietary or personally identifiable information.
· Recoverability: Recovery from the incident is not possible
High – Escalated threat with confirmed impact, requires stakeholder communication
· Functional: The organization has lost the ability to provide a critical service to a subset of users
· Information: Suspected data exfiltration of either proprietary or personally identifiable information
· Recoverability: Time to recovery is unpredictable, additional resources and outside help are needed
Medium – Potential for future impact, or confirmed but very limited impact
· Functional: The organization can still provide all critical services, but at reduced efficiency
· Information: Potential data exfiltration of non-critical information
· Recoverability: Time to recovery is predictable with normal effort
Low – No impact, events that may result in future higher severity incidents
· Functional: No effect on the organization’s ability to provide all services to all users
· Information: Zero data exfiltration
· Recoverability: Time to recovery is known and trivial to execute
Major and Minor Incident Classification
*Major* *–* Incidents with a severity of *Critical* or *High* are classified as *Major* Incidents. These Incidents usually require significant investigative and analysis work from CSIRT. Major Incidents typically involve multiple teams, regular communications to leadership and the business, and require post-incident analysis of the handling of the Incident to identify process gaps or recommendations to prevent similar Incidents in the future.
*Minor* *–* Incidents with a severity of *Low* or *Medium* are classified as *Minor* incidents. These Incidents are usually well understood and have pre-defined procedures for successful handling. Communications and escalations stay within the Information Security team. Minor incidents are limited to little-to-no impact to everyday operations.
Incident Lifecycle– These 6 distinct phases describe the current status of an Incident
Preparation – The act of defining an Incident Response process before an incident occurs. Communication templates, authorized actions, stakeholder contact information, runbooks and procedures, are defined and agreed upon.
Identification – The collection and documentation of data for an ongoing Incident, such as the collection of logs, assets, or indicators of compromise
Containment – Taking action to prevent further damage from occurring as a result of an Incident.
Eradication – Taking action to remove or eliminate malicious artifacts that were identified during an Incident.
Recovery – Taking action to restore impacted assets back into normal operation safely.
Lessons Learned – Post-incident review defining gaps in existing controls, recommendations for changes to existing controls, or general process failures.
**3.** **Computer Security Incident Response Team (CSIRT) Stakeholder Roles**
This section defines the relevant roles that are required for a mature Incident Response program to succeed. These range from roles involved with the actual processing and handling of an Incident, to leadership roles involved with decision making and communications.
These roles are summarized below, see Detailed CSIRT Role Definitions for information about specific role responsibilities, how and when they are assigned, and detailed interactions.
📷 *Figure 1- Example of role interactions for a Major Incident*
The *Coordination team* members are responsible for ensuring appropriate procedural steps are taken throughout the response activities. This includes tracking observables, ensuring all detections are thoroughly investigated, and managing communications outside the response team.
· Incident Commander – Directs tasks, assigns roles, may handle communications, responsible for completion of post-incident activity, overall owner of an Incident
· Incident Communications Coordinator *–* dedicated to handling notifications and all communications with IT, Extended CSIRT, and other stakeholders.
· Evidence Curator – Collects, stores and documents evidence.
The *Response team* is responsible for performing investigative steps and actually implementing, containment, eradication, and recovery procedures. The Response team includes Security Analysts, Operational subject matter experts, and other IT staff.
· Analyst – Performs threat impact analysis, examines digital forensics data.
· Technical Responder – Completes tasks and activities during Incident Response
· Working Group Coordinator – Special role for some IR events which provides a bridge between Coordinator and Responder teams. This role is only assigned if an Incident has a high degree of complexity, and reports to the Incident Commander.
The *Response team* must have privileged (Read\Write\Execute) access to all VVVV assets in the event that they need to interact with systems during an investigation. Usage of this access must be highly auditable, and utilize accounts created specifically for this purpose (separate from responder’s everyday accounts)
The *Response team* must also have the authority to *Contain* an incident to prevent further damage to the organization, even if it causes impact to critical service availability. Containment situations which will cause known impact must follow the “Critical asset containment approval” process.
Incident Responders must maintain adequate training so that they remain qualified to perform their duties. Specialized training should occur annually, and include topics such as Cybersecurity best practices, enterprise incident response, threat hunting, vulnerability detection, digital forensics, relevant tool certifications, and cover common terminology.
The *Extended CSIRT* consists of various members of the business who have a vested interest in maintaining normal operations for the organization but are not directly involved with the processing of an Incident. This includes C-Suite, Business owners, HR, Legal, Insurance and Incident Response retainers. Members of the Extended CSIRT are defined in the Extended CSIRT matrix
The responsibilities of the Extended CSIRT typically involve decision making regarding 3rd party involvement, such as activating retainers, notifying law enforcement, breach disclosures, and adherence to regulatory and privacy requirements.
**4.** **Security Incident Communication Plan**
In the event that a *Major* Incident is declared, appropriate communication mechanisms are defined below to allow information to be delivered to relevant stakeholders.
*Email systems* – To be used for both regular and ad-hoc incident updates to CSIRT
*Phone systems* – Suitable for incident coordination, specific knowledge sharing
*In-person* – A secure space, such as a “War room” must exist to allow incident specific knowledge to be shared confidentially.
*ServiceNow* – Instructions assigned to the Response team to aid in the containment and recovery during an Incident
*Website* – Notice of outage, both internally and externally facing must be prepared
*Out-of-band communications* –
Can be used to notify the Incident Response team, of new\ongoing Incidents and allow coordination to set up in-band communications.
**Milestone Communication** – Upon the declaration of a *Major* Incident, Regular pre-formatted emails to CSIRT will be delivered which provide current incident status and recovery ETAs
*Format requirements*: Milestone communications must use a specific format, and be sent to (CSIRT email distribution group), flagged ‘important’. See Milestone Communication format procedure for specifics.
*Schedule*: Milestone communications must be sent every 1 hour (critical) 4 hour (high) until the incident is resolved
**Ad-Hoc Communication** –
Ad-Hoc communications are typically reserved for on-demand updates to CSIRT, Incidents which do not require an hourly update schedule, or as supplemental updates to be delivered to specific stakeholders between Milestone communications. Because of this dynamic nature, Ad-Hoc communications do not have a strict formatting requirement and tend to contain more granular detail for the Incident.
**Verbal Communication** –
In-Person communication should be restricted to a ‘need-to-know’ basis and should be shared with the minimum number of people necessary to work the Incident. The level of discretion is determined by the Incident Commander.
All Information Security incidents have the potential for VVVV employees to testify in a court of law, a fact that should be understood by all parties whenever handling particularly sensitive data, as defined in the VVVV information classification standards
War room – An effective method of ensuring that only those necessary to work an Incident is to secure a physical space with guaranteed availability, with the ability to privately display sensitive information to those involved in an Incident.
Primary Incident handler – Upon identification of an Incident, an *Incident Commander* must be chosen. All new information relevant to the incident must originate from, or involve, the *Incident Commander*. Doing so reduces the risk of undue speculation and can prevent uninformed decisions and double work.
Phone – When an Incident is identified, the CSIRT must have the option to discuss the situation with any stakeholder as necessary. The contact information for all stakeholders is defined in the CSIRT Communications Matrix
Teleconferencing Bridge – A dedicated teleconferencing line must be available for use, with the ability to add\remove participants as necessary to run the Incident.
Out-of-Band Communications – The CSIRT must have non-VVVV methods of contacting each other if all VVVV assets are deemed unsafe. Ex. Personal Cell\email
VVVV must prepare, in advance, a service interruption webpage to use if an Incident with impact occurs which affects the availability of critical services. The language of this email must be reviewed and approved by the corporate communications and legal teams. The CIO must decide when this service interruption webpage is enabled.
Some incidents require action from the broader IT response team. These IT resources utilize ServiceNow to track, prioritize, and document requests until they are resolved. Information shared via ServiceNow *must* be non-confidential, as the tool does not limit access to view tickets for those who have general access to the system.
**5.** **Incident Response Plan Maintenance**
This incident response plan must receive regular updates from CSIRT to remain effective. These updates should originate from the availability of new technologies, lessons learned from Incident Response, and tabletop exercises.
Frequency: CSIRT must meet at least once annually to review the IR plan.
Method: All changes to the Incident Response plan need to be documented and approved via the ITIL Change process.
IR Tabletop: CSIRT must perform an annual tabletop exercise to remain familiar with the Incident Response Plan and identify any deficiencies that need to be addressed. The IR tabletop scenario should be chosen by the *Information Security Manager* and be shared with as few people as possible to perform the simulation.
Throughout the Incident, CSIRT is to exercise their authority to procure the designated War Room, contact relevant support personnel, and test other various escalation and recovery procedures.
CSIRT Organization Change: Should an organization change which modifies the CSIRT stakeholders occur, the updated information should be immediately updated in the CSIRT Contact List.xlsx
Annual Lessons Learned Review: The Incident Response team must complete an annual meeting to review the *lessons learned* phase of all Major Incidents, to determine if the IR plan should be modified to better handle similar incidents in the future. Examples of changes which might originate from this review include:
· Security Policy changes
· Security awareness program changes
· Software reconfiguration (configuration error remediations)
· Deployment of missing security controls
· Reconfiguration of existing security controls
If anyone has questions, I’d be happy to answer!