Thread by @cglyer

One of most undervalued aspects of incident response is incident documentation

In my experience as a consultant step 1 is interviewing client & reviewing whatever scattered notes 🔖📝they have about an incident & organizing it in a logical manner b/c most orgs do this poorly 🙈

Challenge is analysts (due to crisis) move fast to respond quickly & most orgs don’t experience impactful breaches often

This leads to scattered knowledge/understanding & each analyst documenting things in their own way that is efficient for them but not overall investigation

In my experience - here are the most important things to track (a spreadsheet is my preferred tool)

One table for each of the following:
-Timeline of forensic artifacts
-Systems
-Indicators (I prefer separate table for host and network)
-Compromised accounts

Key timeline elements:
-Timestamp (UTC time in ISO 8601 format 2020-07-20T13:27:36Z)
-Forensic artifact description (e.g MFT Created)
-System
-Summary (normalized field w/most important data)
-User account
-Hash
-Attribution
-Comment

Gives chronological view of entire incident

Key elements to track for systems (note: most likely table to be customized per incident)
-Hostname
-IP
-OS
-Date added
-System status
-Investigative lead
-Multiple fields to track forensic acquisition status & date, analyst assigned, analysis status, remediation status/date

When tracking system status - what we settled on @Mandiant was the following:
-Infected (actor deployed malware that would enable them to regain access [backdoor, webshell...etc])
-Accessed
-Compromised (superset of infected & accessed systems)
-TBD (needs further analysis)

I think you’re better off being more conservative w/system status. TBD systems move to FP or Accessed/Infected. Accessed systems only move to Infected

Only put system in category when solid evidence

Example: netflow data of actor IP connecting to system isn’t “proof” of access

Note regarding system status - a threat actor running malware/tools on a system (say it a password dumper) doesn’t make it infected. It would have been accessed until you find evidence enabling access (e.g backdoor, sticky keys exploit, webshell).

Key elements to track for indicators:
-Indicator description (File name, IP address...etc)
-Indicator detail
-System identified on (at least one - doesn’t have to be all)
-Attribution
-Relations (for IPs track hashes and vice versa & filenames track hashes)
-Date added
-Comment

In general you’ll see a pattern emerge that enables you to figure out when you learned something, what it’s attributed to & make connections between each of the independent tables for all of your incident data & enable quick/automated generation of key incident metrics

Speaking of key incident metrics here are some important ones I usually track (sometimes per threat actor):
-earliest evidence of compromise
-most recent evidence of activity
-# compomised systems (with breakdown of infected vs. accessed)
-# of systems requiring analysis

Is this a lot of work to maintain - you bet

You’re role as an investigative lead is like a point guard in basketball. You run offense but rest of team does bulk of the scoring. You need complete mastery of technical details - but you aren’t the one generating the findings