DFIR: Structured Analysis Process
Root cause analysis (RCA) is a reactive process, meaning it’s performed after the event occurs. But once a root cause analysis is done, it takes the shape of a proactive mechanism since it can predict problems before they occur. You will often get only a strong correlation between cause and effect and not the exact cause. From there, you’ll have to use your experience and professional knowledge to judge whether to investigate further or not.
I hope using this methodology makes the analyzing process, more like Threat Hunting, a repeatable process to confirm or deny the existence of an attacker on a network.1
What happened?
Source Trigger
Endpoints Involved
Points of Interest:
- Systems
- Web Pages
- Rogue Processes
- Account
Metadata
- Blocked or Allowed
- Transfering Protocol
- Timestamp
- Other systems or applications with similar or related events around the same time?
- Abnormalities:3
- Unusual spawner
- Unusual Locations
- Historic Behavior
- Perform background research.
- It it normal that the endpoints involved are talking with each other?
- Other events related to the source?
Structured Answer:
[trigger source] talked with [endpoints involved] using [metadata information], at [occurance]. [Analysis trigger].
How it happened?
Information flow
Which process or system initiated the connection? - Application Function - Server/Service function - Code Injection
Event sequence
Series of events before and after Check for signs of a rootkit (Process tree analyze is very beneficial 4)
Information content
File transfer - Download/Upload Exploit code
Structured Answer:
Why it happened?
(CTI)
What kind of informatino is transfered?
How can/is the information misused?
Structured Answer:
Root cause analysis explains a specific behavior, but a major incident may contain multiple, seperate, and different behaviors or events. To minimize biased experience, try to first analyze each event seperatly and then as an incident. We can oftentimes exclude unrelevant events.