PDF p.304 In progress

Lessons Learned

Open PDF at p.304 11 flashcards

Summary

PDF p.304

The lessons learned process reviews severe security incidents to determine their root cause, whether they were avoidable, and how to prevent them in the future. This involves meetings, root cause analysis, and compiling reports to improve procedures.

In plain words

Supplementary — not from your PDF

After a serious incident, hold a review meeting (including people who weren't involved, for objectivity), find the root cause, and write a lessons learned report (LLR) or after-action report (AAR). Root cause analysis can use the Five Whys, or ask who, why, when, where, how and which controls would have helped. Findings go back into preparation.

Detailed explanation

PDF p.304

Lessons Learned Activity

Meeting: Staff review the incident and responses, including both involved and noninvolved handlers for objective perspectives. Focus on improving procedures rather than assigning blame.
Report Compilation: Analysts compile a lessons learned report (LLR) or after-action report (AAR).

Root Cause Analysis

Purpose: Determine how the incident occurred and identify avoidable factors.
Models
- Five Whys Model: Drill down to root causes by asking successive "Why" questions.
  - Example:
    - Why was our patient safety database found on a dark website? Because a threat actor copied it to USB and walked out with it.
    - Why was the database copied without alert? Because the data loss prevention system was disabled.
    - Why was the system disabled? Because the attacker had privileges.
    - Why were they given privileges? All administrator accounts had them.
    - Why didn't disabling the system generate an alert? Alerts were disabled due to false positives.
  - Root Causes: Improper permission assignments and logging/alerting configuration.
- Alternative Questions: Build a complete picture of the incident.
  - Who was the adversary?
  - Why was the incident perpetrated?
  - When did it occur, when was it detected, and how long did it take to contain and eradicate?
  - Where did it occur (affected systems and network segments)?
  - How did it occur (TTPs used by the adversary)?
  - What security controls could have improved mitigation or response?

Important terms

taken from the text above

Meeting: Staff review the incident and responses, including both involved and noninvolved handlers for objective perspectives. Focus on improving procedures rather than assigning blame.
Report Compilation: Analysts compile a lessons learned report (LLR) or after-action report (AAR).
Five Whys Model: Drill down to root causes by asking successive "Why" questions.
Alternative Questions: Build a complete picture of the incident.

Examples & real-world scenarios

Supplementary — not from your PDF

A Five Whys session tracing a breach to excessive permissions.
An AAR recommending MFA for all remote access.
Updating a playbook after a slow containment.

Scenario

Ask why data was stolen: an attacker used an admin account. Why? It had excessive rights. Why? No access reviews. The root cause is the missing review process, not just the one compromised account.

Common mistakes

Supplementary — not from your PDF

Blaming individuals instead of fixing processes.
Writing the report but never acting on its recommendations.

Practical skills

Supplementary — not from your PDF

Run a Five Whys analysis on an incident.

What I should remember

Key Points PDF p.304

Lessons Learned Activity
- Meeting: Review incident and responses, focus on improvement.
- Report Compilation: Create LLR or AAR.
Root Cause Analysis
- Purpose: Identify how the incident occurred.
- Models
  - Five Whys: Successive "Why" questions.
  - Alternative Questions: Comprehensive incident picture.
Example Questions
- Who: Adversary identity.
- Why: Motives and targeted assets.
- When: Incident timeline.
- Where: Affected systems and segments.
- How: TTPs used.
- What: Better security controls.