Outline

Cold Open
You wake up to news on a Monday that your company was breached. You check your emails and find teams at work were busy without you.
In an email thread legal forwarded to you the night prior, you can see everyone making decisions, arguing, taking bold actions, and the Ops person decided to make a statement to the press.
Your security team also seem to be unaware of the matter and just recieved emails themselves.
Reading the statement, you find it is filled with inaccuracies and gives way more information than should have been released.
Now the CEO is calling you wanting an update for the Board and your audit department are fielding questions from third parties that need your attention.

Nothing went to plan...... because you didn't have a plan

Let's make one now.

Introduction
WHOAMI details Redacted for double blind purposes.

Why Have a CIRP?

You may have one and dont know it!

Where to start?
People Process Tech

Start with Requirements.
ISO, NIST, COBIT, etc
Roles: Who NEEDS to be involved?
Executives, Legal, Communications, Operations, IT, etc
These folks also might be aware of specific requirements for their areas of the business.
Legal requirements
Contractual obligations around response time, reporting incidents to customers, third parties, regulators, etc
Evidence Collection (more on that in a bit)

People
Define your Roles and Responsibilities.

Usually at least 2 types of teams need to be assembled for incidents.
SOC/CIRT
Tier 1-3, Sec Management, IR Analysts, etc
Steerco/ExecCo
EVPs, CEO, Chief Legal, etc
Sometimes SOC and CIRT are separated and only activate ExecCo for certain incidents. Depends on your severity matrix.

Have Key contacts identified
Tech SMEs
Database team, App Team, Domain Admin/Arch, IAM, Privacy, Cloud, Network, etc

LOB
Logistics, OT/Scada, Product, Manufacturing, Sales, etc

Business Support
HR, Finance, Legal, Facilities, etc

Process
Need to make sure your CIRP makes it clear HOW to identify, classify, handle, escalate, and resolve and incident.
How does someone report an incident?
How do you catorgize and assign severity to an incident?
How many severities do you need?
Some have 2 severities all the way to 5.
Generally I see 3 severities.
Severity 1
Severity 2
Severity 3

How do you define Breach, Compromise, Event, Alert, Incident?
Talk to Legal/Contracts. There already may be a definition you adhere to for customers or regulations. Adopt those. Always try to adopt a common language where possible to ensure everyone understands.

Phases of an Incident
There are many models you can adopt to break out activities into phases.

I like to use the following.
Identify - how incidents become known either through SIEM, alerts, third party notifications, employee reports, etc
Triage - how reports, alerts are examined to validate they are an incident requiring further action (root out false +)
Escalate - how incidents get classified above the lowest severity and who gets notified and when and when a bridge is assembled
Contain - Actions to take to mitigate and incident to the point where an attacker is stopped from futher encroachment into the environmet.
Eradicate - Actions to take to fully remove the attacker from the environment
Recover - Actions to take to bring services and technologies back online, restore data, etc
Postmortem/Lessons Learned - Summary of the incident and results, timeline of events, what went well, what needs to improve, and action list to make those improvements.

Technology
How will you document or track incidents? Excel? SNOW? Jira?

How will you store evidence, reports, maintain access?
Sharepoint? Box? Specific product? Safe?

Forensics
Do you have an inhouse capabilities?
Anyone certified? Can anyone stand as an expert witness if prosecution was needed? Should you have those capabilities?
Do you have an external partner?
IR firms usually provide many if not all services you need in this arena.
Do you need tools ready to use by you or a third party?
EDR, EnCase, Network Taps, Laptops for forensic investigation, write blockers, etc

Out of Band Comms
Somtimes you cannot trust your IM, Email or other corporate communications methods due to an incident. You will need to think about how you will build trust around communications that aren't from your corporate environment.
Signal
End to end encrypted, widely able to be installed, well maintained.
Understand that your phone MAY be subpoenable as the comms only exist on the endpoints of a signal chat. So this may not be ideal, but may work in a pinch.

Google Tenant (or microsoft if you're a google shop).
Getting completely out of your standard builds can provide security as Google will have different challenges for an attacker to try and pivot to rather than using the same environment.
Have email addresses provisioned for the folks in your Roles and Responsibilities.
Ensure voice and video meetings are possible
TEST THIS ANNUALLY to make sure you can get into it and everything still works.

There's also products/services geared specifically to IR command center style experiences.
Regardless
How will you distribute access when the time comes? Where is the documentation stored?
Maybe don't put this part in the CIRP so as not to give a roadmap to the attacker.

Wrap up
Here's a checklist/template
there are loads more out there to help you build the right flow for you

Don't get into the weeds on tech or process (screen caps, commands, etc)
This needs to be something even an executive can read quickly and know what to do.
Stay high level. 20-25 pages maximum!

Focus on requirements and clarity

Start talking and Writing!
Takes about 6 months to get a CIRP drafted revised and approved depending on org.
Test it IMMEDIATELY
have you ever done a Tabletop exercise?

Q/A and other business before the court