Incident Response Plan for {{COMPANY_NAME}}

Author: {{AUTHOR_NAME}}, {{AUTHOR_EMAIL}}

Revision {{REVISION_NUMBER}}, Released {{RELEASE_DATE}}

This incident response plan is based on the concise, directive, specific, flexible, and free plan available on Counteractive Security's Github and discussed at www.counteractive.net

It was last reviewed on {{REVIEW_DATE}}. It was last tested on {{TEST_DATE}}.

TODO: Customize this plan template for your organization using instructions at https://github.com/counteractive/incident-response-plan-template. For incident response services, or help customizing, implementing, or testing your plan, contact us at contact@counteractive.net or at (888) 925-5765.

Assess

Stay calm and professional.
Gather pertinent information, e.g., alarms, events, data, assumptions, intuitions (observe).
Consider impact categories, below (orient), and determine if there is a possible incident (decide):
Initiate a response if there is an incident (act). If in doubt, initiate a response. The incident commander and response team can adjust upon investigation and review.

Assess Functional Impact

What is the direct or likely impact on your mission? (e.g., business operations, employees, customers, users)

Mission/business degradation or failure: incident!
None: assess information impact.

Assess Information Impact

What is the direct or likely impact on your information/data, particularly anything sensitive? (e.g., PII, proprietary, financial, or healthcare data)

Information accessed, taken, changed, or deleted: incident!
None: handle via non-incident channels (e.g., support ticket).

Every team member is empowered to start this process. If you see something, say something.

TODO: Customize categories/severities as necessary. This simple example (incident vs. no incident) is based on impact categories in NIST SP 800-61r2.

Initiate Response

Name the Incident

Create an simple two-word phrase to refer to the incident---a codename---to use for the incident file and channel(s). TODO: Customize incident naming procedure.

Assemble the Response Team

Page the on-duty/on-call Incident Commander. TODO: Add Incident Commander call list or procedure
Do not discuss the incident outside the response team unless cleared by the Incident Commander
Launch and/or join the response chat at {{RESPONSE_CHAT}}. TODO: Add response chat launch procedure.
Launch and/or join the response call at {{RESPONSE_PHONE}} and/or {{RESPONSE_VTC}}. TODO: Add response call launch procedure.
Prefer voice call, chat, and secure file exchange over any other methods.
Do not use primary email if possible. If email is necessary, use sparingly or use {{ALTERNATE_EMAIL}}. Encrypt emails when any participant is outside the {{ORGANIZATION_DOMAIN}} domain. TODO: Add alternative email details and procedure, e.g., on-demand Office 365 or GSuite
Do not use SMS/text to communicate about the incident, unless to tell someone to move to a more secure channel.
Invite on-duty/on-call responders to the response call and response chat.
- Invite the security team. TODO: Add security team contact list or procedure.
- Invite a SME for affected teams and systems. TODO: Add team SME contact list or procedure.
- Invite executive stakeholders and legal counsel at earliest opportunity, but prioritize operational responders. TODO: Add executive stakeholder contact list or procedure.
OPTIONAL: Establish an in-person collaboration room ("war room") for complex or severe incidents. TODO: Add collaboration room procedure.

Reference: Response Team Structure

Command Team
Liaison Team
- Internal Liaison
- External Liaison
Operations Team
- Subject Matter Experts (SMEs) for Systems
- SMEs for Teams/Business Units
- SMEs for Executive Functions (e.g., Legal, HR, Finance)

TODO: Modify role structure as necessary.

Reference: Response Team Contact Information

Response Team Role	Contact Information
Incident Commander pager	{{INCIDENT_COMMANDER_PAGER_NUMBER}}
Incident Commander pager url	{{INCIDENT_COMMANDER_PAGER_URL}}
Incident Commander roster	{{INCIDENT_COMMANDER_ROSTER}}
Security team roster	{{SECURITY_TEAM_ROSTER}}
Team SME roster	{{TEAM_SME_ROSTER}}
Executive roster	{{EXECUTIVE_ROSTER}}

TODO: Customize response team contact information. Include contact procedures in rosters, which can be static or dynamic.

Establish Battle Rhythm

Conduct Initial Response Call

Conduct initial call using the initial response call structure
Follow instructions from the Incident Commander. If the on-duty/on-call Incident Commander does not join the call within {{INCIDENT_COMMANDER_RESPONSE_SLA}} and you are a trained incident commander, take command of the call.
Follow the instructions for your role.
Follow the call and chat, and comment as appropriate. If you are not a SME, filter input through the SME for your team if possible.
Keep the call and chat active throughout the incident for event-driven communication.
Schedule updates every {{UPDATE_FREQUENCY}} on the active bridge.

Reference: Initial Response Call Structure

INCIDENT COMMANDER (IC): My name is [NAME], I am the Incident Commander. I have designated [NAME] as Deputy, and [NAME] as Scribe. Who is on the call?
SCRIBE: [Takes attendance]
IC: [If missing key personnel] Deputy, please page [MISSING PERSONNEL].
IC: [Asks questions to understand situation, symptoms, scope, vector, impact, and timeline from the incident reporter, applicable SMEs for systems and business units]
SMEs: [Brief answers to IC's questions]
IC:[If this is an incident]:
- At this time, the incident summary is as follows: [reiterates summary]. The Investigation team will be led by [NAME], the Remediation team will be led by [NAME], and the Communication team will be led by [NAME]. They will coordinate team membership and report to me. SMEs, please report to your appropriate team leader.
- What investigation, remediation, or communication steps have already been taken? [this should be a short list, but needs to come out now]
- This call and chat will remain up and available until incident closure, please use it for all incident related communications. Provide real-time status updates in the chat, if possible. Are there any questions or remaining inputs? [answers questions]
- Team leaders, please proceed with your planned actions. We will reconvene at [UPDATE_TIME] to discuss the status. Thank you.
IC: [If this is not an incident]: At this time, these facts do not rise to the level of an incident. I will coordinate directly with the incident reporter for follow-on actions. Thank you for your time.

Reference: Call Etiquette

Join both the call and chat.
Keep background noise to a minimum.
Keep your microphone muted until you have something to say.
Identify yourself when you join the call; State your name and role (e.g., "I am the SME for team x").
Speak up and speak clearly.
Be direct and factual.
Keep conversations/discussions short and to the point.
Bring any concerns to the Incident Commander (IC) on the call.
Respect time constraints given by the Incident Commander.
Use clear terminology, and avoid acronyms or abbreviations. Clarity and accuracy is more important than brevity.

Conduct Response Update

Conduct scheduled updates using the update call structure every {{UPDATE_FREQUENCY}} on the active bridge. TODO: Customize update frequency and scripts; recommend no more than twice daily.
Adjust frequency as necessary.
Coordinate independent updates (e.g., executive, legal) as required, but as infrequently as practicable.

Reference: Response Update Call Structure

INCIDENT COMMANDER (IC): Since our last scheduled update, the incident summary is as follows:
- [Impact]
- [Vector]
- [Summary update]
- [Timeline update]
IC: Investigation team, please provide a brief update
- INVESTIGATION LEAD: [Investigative activities or "nothing to report"]
- What is your recommended investigations plan?
- What investigation actions need tasking or approval? [listen, gain consensus, task/approve]
IC: Remediation team, please provide a brief update
- REMEDIATION LEAD: [Remediation activities or "nothing to report"]
- What is your recommended remediation strategy? Strong objections? [listen, gain consensus, task/approve]
- What remediation actions need tasking or approval?
IC: Communication team, please provide a brief update:
- COMMUNICATIONS LEAD: [Communication activities or "nothing to report"]
- What is your recommended communication strategy? Strong objections? [listen, gain consensus, task/approve]
- What communication actions need tasking or approval?
IC: This call and chat will remain up and available until incident closure, please use it for all incident related communications. Provide real-time status updates in the chat, if possible. Are there any questions or remaining inputs? [answers questions]
IC: Team leaders, please proceed. We will reconvene in [{{UPDATE_TIME}}] to discuss the status. Thank you.

Monitor Scope

Monitor the scope of the response to ensure it does not exceed the Incident Commander's span of control.
If an incident gets sufficiently complex, and there are sufficient responders, consider spinning off sub-teams.

Create Sub-Teams

In preparation for complex incidents, three sub-teams are pre-defined: Investigation, Remediation, and Communication, generally responsible for those response functions. TODO: Customize sub-team structure if necessary.
Create a call bridge and chat for each sub-team.
The Incident Commander will designate team leaders, who report to the IC, and team members, who report to their team leader. Team leaders do not have to be trained as incident commanders, however some leadership experience is preferable.
The Incident Commander may adjust the purpose or name of the sub-teams as necessary.
If you wish to switch teams, ask your current team leader. Do not ask the Incident Commander, or the leader of the other team(s). Use the chain of command.

Split Incident

If an incident turns out to be two or more distinct incidents:

Establish a new incident file.
Track and coordinate investigation, remediation, and communication in the appropriate file.
Consider establishing sub-teams for each incident.
Maintain one top-level Incident Commander, to coordinate low-density, high-demand assets and maintain unity of command.

Investigate

Investigate, remediate, and communicate in parallel, using separate teams, if possible. The Incident Commander will coordinate these activities. Notify the Incident Commander if there are steps the team should consider.

Create Incident File

Create a new incident file at {{INCIDENT_FILE_LOCATION}} using the incident name. Use this file for secure storage of documentation, evidence, artifacts, etc.
- Provision secure digital storage.
- Provision secure file exchange.
- Obtain physical storage.
- Share the incident file location on the call and chat.
- TODO: Customize and automate file location and procedure
Document the functional and information impact, if known (see Assess). TODO: Customize impact categories, if necessary.
Document the vector, if known (e.g., web, email, removable media). TODO: Customize vector list, if necessary.
Document the incident summary: a brief overview of the vector, impact, investigation, and remediation situation, if known.
Document the incident timeline, including attacker activity and responder activity. TODO: Add timelines of varying details, as necessary.
Document investigation, remediation, and communication steps. Document activities independently so they can be combined and reused, if possible.
Track significant information such as:
- Evidence, with time of collection, source, chain of custody, etc.
- Affected systems, with how and when system was identified, and summary of effect (e.g., has malware, data accessed).
- Files of interest, such as malware or data files, with system and metadata.
- Accessed and taken data, with filenames, metadata, and time of suspected exposure.
- Significant attacker activity, such as logins and malware execution, with time of the event.
- Network-based indicators of compromise (IOCs), such as IP addresses and domains.
- Host-based IOCs, such as filenames, hashes, and registry keys.
- Compromised accounts, with scope of access and time of compromise.

TODO: Customize incident documentation procedure, including spreadsheets, databases, forms, systems, and templates, if necessary.

Collect Initial Leads

Interview incident reporter(s).
Collect initial supporting data (e.g., alarms, events, data, assumptions, intuitions) in the incident file.
Interview SME(s) with domain or system expertise, to understand technical detail, context, and risk.
Interview SME(s) in affected business unit, to understand mission/business impact, context, and risk.
Ensure leads are relevant, detailed, and actionable.

Reference: Response Resource List

Resource	Location
Critical information list	{{CRITICAL_INFO_LIST_LOCATION}}
Critical asset list	{{CRITICAL_ASSET_LIST_LOCATION}}
Asset management database	{{ASSET_MGMT_DB_LOCATION}}
Network map	{{NETWORK_MAP_LOCATION}}
SIEM console	{{SIEM_CONSOLE_LOCATION}}
Log aggregator	{{LOG_AGGREGATOR_CONSOLE}}

TODO: Complete critical information and asset lists ("crown jewels"). This is incredibly important to effective response.

TODO: Customize response resource list

Update Investigative Plan and Incident File

Review and refine incident impact.
Review and refine incident vector.
Review and refine incident summary.
Review and refine incident timeline with facts and inferences.
Create hypotheses: what may have happened, and with what confidence.
Identify and prioritize key questions (information gaps) to support or discredit hypotheses.
- Use the MITRE ATT&CK matrix or similar framework to develop questions.
  - ATT&CK for Enterprise, including links to Windows, Mac, and Linux specifics.
  - ATT&CK Mobile Profile for mobile devices.
- Use interrogative words as inspiration:
  - When?: first compromise, first data loss, access to x data, access to y system, etc.
  - What?: impact, vector, root cause, motivation, tools/exploits used, accounts/systems compromised, data targeted/lost, infrastructure, IOCs, etc.
  - Where?: attacker location, affected business units, infrastructure, etc.
  - How?: compromise (exploit), persistence, access, exfiltration, lateral movement, etc.
  - Why?: targeted, timing, access x data, access y system, etc.
  - Who?: attacker, affected users, affected customers, etc.
Identify and prioritize witness devices and strategies to answer key questions.
- Consult network diagrams, asset management systems, and SME expertise
- Check the Response Resource List)
Refer to incident playbooks for key questions, witness devices, and strategies for investigating common or highly damaging threats.

The investigative plan is critical to an effective response; it drives all investigative actions. Use critical thinking, creativity, and sound judgment.

Reference: Attacker Tactics to Key Questions Matrix

Attacker Tactic	The way attackers ...	Possible Key Questions
Reconnaissance	... learn about targets	How? Since when? Where? Which systems?
Resource Development	... build infrastructure	Where? Which systems?
Initial Access	... get in	How? Since when? Where? Which systems?
Execution	... run hostile code	What malware? What tools? Where? When?
Persistence	... stick around	How? Since when? Where? Which systems?
Privilege Escalation	... get higher level access	How? Where? What tools?
Defense Evasion	... dodge security	How? Where? Since when?
Credential Access	... get/create accounts	Which accounts? Since when? Why?
Discovery	... learn our network	How? Where? What do they know?
Lateral Movement	... move around	How? When? Which accounts?
Collection	... find and gather data	What data? Why? When? Where?
Command and Control	... control tools and systems	How? Where? Who? Why?
Exfiltration	... take data	What data? How? When? Where?
Impact	... break things	What systems or data? How? When? Where? How bad?

See the MITRE ATT&CK page for more insight and ideas.

Create and Deploy Indicators of Compromise (IOCs)

Emphasize dynamic and behavioral indicators alongside static fingerprints.

Create IOCs based on initial leads and analysis.
Create IOCs using an open format supported by your tools (e.g., STIX 2.0), if possible. TODO: Customize IOC format as necessary.
Use automation, if possible. TODO: Add IOC deployment/revocation procedure.
Do not deploy unrelated, un-curated "feeds" of IOCs; these can cause confusion and fatigue.
Consider all IOC types:
- Network-based IOCs such as IP or MAC addresses, ports, email addresses, email content or metadata, URLs, domains, or PCAP patterns.
- Host-based IOCs such as paths, file hashes, file content or metadata, registry keys, MUTEXes, autoruns, or user artifacts and permissions.
- Cloud-based IOCs such as log patterns for SaaS or IaaS deployments
- Behavioral IOCs (a.k.a., patterns, TTPs) such as process tree patterns, heuristics, deviation from baseline, and login patterns.
Correlate various IOC types, such as network and host-based indicators on the same systems(s).

Identify Systems of Interest

Validate whether they are relevant.
Categorize the reason(s) they are "of interest": has malware, accessed by compromised account, has sensitive data, etc. Treat these as "tags", there may be more than one category per system.
Prioritize collection, analysis, and remediation based on investigative needs, business impact, etc.

Collect Evidence

Prioritize based on the investigative plan
Collect live response data using {{LIVE_RESPONSE_TOOL}}. TODO: Customize live response tools and procedure.
Collect relevant logs from system(s) (if not part of live response), aggregator(s), SIEM(s), or device console(s). TODO: Customize log collection tools and procedure.
Collect memory image, if necessary and if not part of live response, using {{MEMORY_COLLECTION_TOOL}}. TODO: Customize memory collection tools and procedure.
Collect disk image, if necessary, using {{DISK_IMAGE_TOOL}}. TODO: Customize disk image collection tool and procedure.
Collect and store evidence in accordance with policy, and with proper chain of custody. TODO: Customize evidence collection and chain of custody policy.

Consider collecting the following artifacts as evidence, either in real time (_e.g., via EDR or a SIEM) or on demand:

Example Useful Artifacts

TODO: Customize and prioritize useful artifacts.

Running Processes
Running Services
Executable Hashes
Installed Applications
Local and Domain Users
Listening Ports and Associated Services
Domain Name System (DNS) Resolution Settings and Static Routes
Established and Recent Network Connections
Run Key and other AutoRun Persistence
Scheduled tasks and cron jobs
Artifacts of past execution (e.g., Prefetch and Shimcache)
Event logs
Group policy and WMI artifacts
Anti-virus detections
Binaries in temporary storage locations
Remote access credentials
Network connection telemetry (e.g., netflow, firewall permits)
DNS traffic and activity
Remote access activity including Remote Desktop Protocol (RDP), virtual private network (VPN), SSH, virtual network computing (VNC), and other remote access tools
Uniform Resource Identifier (URI) strings, user agent strings, and proxy enforcement actions
Web traffic (HTTP/HTTPS)

Analyze Evidence

Prioritize based on the investigative plan
Analyze and triage live response data
Analyze memory and disk images (i.e., conduct forensics)
Analyze malware
OPTIONAL: Enrich with research and intelligence
Document new indicators of compromise (IOCs)
Update the case file

Example Useful Indicators

TODO: Customize and prioritize useful indicators.

Unusual authentication behavior (e.g., frequency, systems, time of day, remote location)
Non-Standard formatted usernames
Unsigned binaries connecting to the network
Beaconing or significant data transfers
PowerShell command line requests with Base64-encoded commands
Excessive RAR, 7zip, or WinZip activity, especially with suspicious file names
Connections on previously unused ports.
Traffic patterns related to time, frequency, and byte count
Changes to routing tables, such as weighting, static entries, gateways, and peer relationships

Iterate Investigation

Update the investigative plan and repeat until closure.

Remediate

Investigate, remediate, and communicate in parallel, using separate teams, if possible. The Incident Commander will coordinate these activities. Notify the Incident Commander if there are steps the team should consider

Update Remediation Plan

Review the incident file at {{INCIDENT_FILE_LOCATION}} using the incident name
Review applicable playbooks.
Review the Response Resource List).
Consider which attacker tactics are in play in this incident. Use the MITRE ATT&CK list (i.e., Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Execution, Collection, Exfiltration, and Command and Control), or similar framework.
Develop remediations for each tactic in play, as feasible given existing tools and resources. Consider remediations to Protect, Detect, Contain, and Eradicate each attacker behavior.
Prioritize based on timing strategy, impact, and urgency.
Document in incident file.

Use information security (infosec) frameworks as inspiration, but do not use incident remediation as a substitute for an infosec program with an appropriate framework. Use them to supplement one another.

Protect

"How can we stop tactic X from happening again, or reduce risk? How can we improve future protection?"

Use the following as a starting point for protective remediation:

Patch applications.
Patch operating systems.
Update network and host IPS signatures.
Update endpoint protection/EDR/anti-virus signatures.
Reduce locations with critical data.
Reduce administrative or privileged accounts.
Enable multi-factor authentication.
Strengthen password requirements.
Block unused ports and protocols at segment and network boundaries, both inbound and outbound.
Whitelist network connections for critical servers and services.

Detect

"How can we detect this on new systems or in the future? How can we improve future detection and investigation?"

Use the following as a starting point for detective remediation:

Enhance logging and retention for system logs, particularly critical systems.
Enhance logging for applications, including SaaS applications.
Enhance log aggregation.
Update network and host IDS signatures using IOCs.

Contain

"How can we stop this from spreading, or getting more severe? How can we improve future containment?"

Use the following as a starting point for containment remediation:

Implement access lists (ACLs) at network segment boundaries
Implement blocks at the enterprise boundary, at multiple layers of the OSI model.
Disable or remove compromised account access.
Block malicious IP addresses or networks.
Black hole or sinkhole malicious domains.
Update network and host IPS and anti-malware signatures using IOCs.
Remove critical or compromised systems from the network.
Contact providers for assistance (e.g., internet service providers, SaaS vendors)
Whitelist network connections for critical servers and services.
Kill or disable processes or services.
Block or remove access for external vendors and partners, especially privileged access.

Eradicate

"How can we eliminate this from our assets? How can we improve future eradication?"

Use the following as a starting point for eradication remediation:

Rebuild or restore compromised systems and data from known-good state.
Reset account passwords.
Remove hostile accounts or credentials.
Delete or remove specific malware (difficult!).
Implement alternative vendors.
Activate and migrate to alternate locations, services, or servers.

Choose Remediation Timing

Determine the timing strategy---when remediation actions will be taken---by engaging the Incident Commander, the system SMEs and owners, business unit SMEs and owners, and the executive team. Each strategy is appropriate under different circumstances:

Choose immediate remediation when it is more important to immediately stop attacker activities than to continue investigating. For example, ongoing financial loss, or ongoing mission failure, active data loss, or prevention of an imminent significant threat.
Choose delayed remediation when it is important to complete the investigation, or important not to alert the attacker. For example, long-term compromise by an advanced attacker, corporate espionage, or large-scale compromise of an an unknown number of systems.
Choose combined remediation when both immediate and delayed circumstances apply in the same incident. For example, immediate segmentation of a sensitive server or network to meet regulatory requirements while still investigating a long-term compromise.

Execute Remediation

Assess and explain risks of remediation actions to stakeholders. TODO: Customize remediation risk approval procedure, if necessary.
Immediately implement those remediation actions with little or no affect on the attacker (sometimes called "posturing actions"). For example, many of the protection and detection actions above are good candidates.
Schedule and task remediation actions according to the timing strategy.
Execute remediation actions in batches, as events, for maximum effectiveness and minimum risk.
Document execution status and time in the incident file, especially for temporary measures.

Iterate Remediation

Update the remediation plan and repeat until closure.

Communicate