Chapter 8: Incident Response - Quiz¶

Correct Answer: B) Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity

Explanation:

NIST SP 800-61 Incident Response Lifecycle:

Phase 1: Preparation - Build IR team, define roles - Deploy tools (SIEM, EDR, forensics) - Create runbooks and playbooks - Train staff

Phase 2: Detection & Analysis - Identify incidents from alerts - Triage and validate - Determine scope and severity - Initial investigation

Phase 3: Containment, Eradication & Recovery - Containment: Limit damage and prevent spread - Eradication: Remove attacker presence - Recovery: Restore systems to normal operations

Phase 4: Post-Incident Activity - Lessons learned meeting - Update runbooks and detections - Report to stakeholders - Continuous improvement

Cyclical Nature: Post-incident lessons feed back into Preparation

Reference: Chapter 8, Section 8.1 - NIST IR Lifecycle

Correct Answer: B) Short-term provides immediate isolation, long-term allows continued operations while preparing for eradication

Explanation:

Short-Term Containment: - Goal: Immediate threat mitigation - Timeframe: Minutes to hours - Methods: Network isolation, account disabling, process termination - Trade-off: May disrupt business operations - Example: Isolate ransomware-infected host from network (prevents spread but host is offline)

Long-Term Containment: - Goal: Maintain business operations while preparing for eradication - Timeframe: Hours to days - Methods:Segmentation, monitoring, access restrictions - Trade-off: Balances security and availability - Example: Segment compromised web server, allow read-only access while building clean replacement

Scenario: Ransomware on File Server

Short-Term Containment (Immediate):

Action: Disconnect file server from network
Impact: No file access for users
Purpose: Prevent ransomware spread to other systems

Long-Term Containment (Next 24-48 hours):

Action: Restore from backup to isolated segment, allow read-only access
Impact: Users can access files (read-only) while IT rebuilds production server
Purpose: Maintain business continuity during recovery

Reference: Chapter 8, Section 8.2 - Containment Strategies

Correct Answer: B) To completely remove the attacker's presence, including malware, backdoors, and compromised credentials

Explanation:

Eradication Phase: - Goal: Eliminate threat actor presence and ensure they cannot return via existing foothold - Timing: After containment, before recovery - Critical: Incomplete eradication allows attacker to regain access

Eradication Actions:

1. Remove Malware: - Delete malicious files - Clean registry keys/scheduled tasks - Remove persistence mechanisms

2. Eliminate Backdoors: - Remove web shells - Close unauthorized remote access tools - Patch exploited vulnerabilities

3. Revoke Compromised Credentials: - Reset passwords for compromised accounts - Rotate service account credentials - Revoke/reissue certificates and API keys

4. Rebuild Compromised Systems: - Reimage infected hosts (preferred over cleaning) - Restore from known-good backups

5. Patch Vulnerabilities: - Apply security updates that closed exploit vector - Harden configurations

Example: Web Server Compromise

Eradication Checklist:
✓ Remove web shell (backdoor.php)
✓ Patch CVE-2024-12345 (initial access vector)
✓ Reset database credentials (dumped by attacker)
✓ Rebuild web server from clean image
✓ Restore website files from backup
✓ Verify no persistence mechanisms remain

Verification: Use forensics to confirm no attacker artifacts remain

Reference: Chapter 8, Section 8.3 - Eradication

Correct Answer: B) Verify that all threats are eradicated and systems are secure before returning to production

Explanation:

Recovery Phase Best Practices:

Step 1: Validate Eradication

Before restoration, confirm:
✓ Malware removed (EDR scans clean)
✓ Backdoors eliminated (web shell scan negative)
✓ Vulnerabilities patched (vulnerability scan shows compliant)
✓ Credentials rotated (no compromised accounts remain)

Step 2: Test in Isolated Environment

- Restore to staging/test environment
- Monitor for 24-48 hours
- Verify no attacker activity
- Confirm business functionality

Step 3: Phased Restoration

- Restore non-critical systems first
- Monitor for issues
- Gradually restore critical systems
- Maintain enhanced monitoring for 7-30 days

Step 4: Verification

Post-recovery checklist:
✓ All services operational
✓ No security alerts
✓ Users can access systems
✓ Data integrity confirmed

Risk of Premature Restoration: - Attacker maintains persistence → re-compromise - Malware spreads from backup → reinfection - Unpatched vulnerability → immediate re-exploitation

Example: Ransomware Recovery

❌ Bad: Restore encrypted files from backup immediately
✅ Good:
  1. Build new clean server
  2. Patch vulnerabilities
  3. Restore data to new server
  4. Scan restored data for malware
  5. Test in isolated network
  6. Monitor for 48 hours
  7. Return to production with enhanced monitoring

Reference: Chapter 8, Section 8.4 - Recovery

Correct Answer: B) Registers/Cache → RAM → Disk → Remote logs

Explanation:

Order of Volatility (Most to Least Volatile):

1. Registers, Cache, Routing Tables (Seconds) - CPU registers - Processor cache - Network routing tables - ARP cache

2. RAM (Memory) - (Minutes to Hours) - Running processes - Network connections - Decrypted data - Lost on reboot!

3. Temporary Filesystems (Hours to Days) - Swap/pagefile - Temporary directories

4. Disk Storage (Persistent) - Filesystem data - Event logs - Registry (Windows)

5. Remote Logs (Persistent) - SIEM logs - Network flow data - Cloud logs

6. Backups/Archives (Most Persistent) - Offline backups - Tape archives

Collection Priority:

1. FIRST: Capture RAM (memory dump)
   - Use tools: FTK Imager, DumpIt, Lime
   - Rationale: Lost forever on reboot

2. SECOND: Capture network traffic
   - Running tcpdump/Wireshark

3. THIRD: Disk imaging
   - Use tools: dd, FTK Imager, EnCase

4. FOURTH: Collect remote logs
   - Export from SIEM

Critical Rule: Collect volatile evidence first, as it disappears rapidly

Reference: Chapter 8, Section 8.5 - Forensics & Evidence Collection

Correct Answer: B) To document who handled evidence, when, and why, ensuring integrity and admissibility in legal proceedings

Explanation:

Chain of Custody: - Purpose: Prove evidence has not been tampered with - Required For: Legal proceedings, regulatory compliance, internal audits - Documentation: Who, what, when, where, why for every evidence transfer

Chain of Custody Components:

1. Initial Collection:

- Date/Time: 2026-02-15 14:30 UTC
- Collected By: Jane Doe, Senior IR Analyst
- Evidence: Memory dump from WKS-042
- Tool: FTK Imager v4.5
- Hash: SHA256: abc123def456...
- Storage: Forensic workstation, evidence locker #7

2. Transfer/Access Log:

| Date       | Time  | Action       | Person      | Purpose          | Hash Verified |
|------------|-------|--------------|-------------|------------------|---------------|
| 2026-02-15 | 14:30 | Collected    | Jane Doe    | Incident IR-2024 | N/A           |
| 2026-02-15 | 15:00 | Transferred  | John Smith  | Analysis         | ✓ Match       |
| 2026-02-16 | 09:00 | Accessed     | Jane Doe    | Report writing   | ✓ Match       |
| 2026-02-20 | 10:00 | Transferred  | Legal team  | Investigation    | ✓ Match       |

3. Hash Verification: - Calculate cryptographic hash (SHA256) at collection - Verify hash before each access/transfer - If hash changes → evidence compromised

Legal Implications: - Broken chain → evidence inadmissible in court - Gaps in documentation → defense can claim tampering - Proper chain → evidence integrity proven

Best Practices: - Store evidence in secured, access-controlled location - Use write-blockers when accessing storage media - Document everything in evidence log

Reference: Chapter 8, Section 8.6 - Chain of Custody

Correct Answer: B) To identify what worked, what didn't, and how to improve processes and detections

Explanation:

Lessons Learned Meeting: - Timing: Within 1-2 weeks post-incident (while details are fresh) - Attendees: IR team, SOC analysts, IT, management, relevant stakeholders - Duration: 60-90 minutes - Tone: Blameless, focus on process improvement

Meeting Agenda:

1. Incident Summary (5 min): - What happened? - Timeline overview - Impact assessment

2. What Went Well (15 min): - Effective detections - Good communication - Successful containment actions - Example: "EDR detected malware within 5 minutes of execution"

3. What Didn't Go Well (20 min): - Detection gaps - Communication failures - Process bottlenecks - Example: "Lacked runbook for this attack type, wasted 30 min researching response"

4. Root Cause Analysis (15 min): - How did attacker gain access? - Why did initial defenses fail? - What enabled lateral movement?

5. Action Items (20 min): - Create/update detection rules - Patch vulnerabilities - Update runbooks - Train staff - Assign owners and deadlines

6. Metrics & Reporting (10 min): - MTTD, MTTA, MTTR - Lessons for executive report

Example Action Items:

1. Create detection rule for T1003.001 (LSASS dumping) - Owner: Detection Engineer - Due: 2 weeks
2. Update phishing response runbook with new procedures - Owner: SOC Manager - Due: 1 week
3. Deploy MFA on admin accounts (prevented by this attack) - Owner: IT - Due: 1 month
4. Conduct tabletop exercise for ransomware - Owner: IR Lead - Due: 3 months

NOT a Blame Session: Focus on systemic improvements, not individual mistakes

Reference: Chapter 8, Section 8.7 - Lessons Learned

Correct Answer: B) Post-mortem focuses on technical root cause, lessons learned focuses on process improvements

Explanation:

Post-Mortem (Technical Deep-Dive): - Focus: Detailed technical analysis - Audience: IR team, security engineers, detection engineers - Content: - Complete attack timeline - Technical TTPs used - Root cause analysis (5 Whys) - Evidence artifacts - Forensic findings

Example Post-Mortem Content:

Incident: Ransomware via phishing

Timeline:
14:05 - User clicks phishing link
14:06 - Malware downloads (SHA256: abc123...)
14:07 - Persistence via scheduled task
14:10 - Credential dumping (T1003.001)
14:25 - Lateral movement to file server
14:30 - Ransomware encryption begins

Root Cause:
1. Email gateway lacked attachment sandboxing
2. User training insufficient (clicked obvious phishing)
3. No MFA on admin accounts (credential theft succeeded)
4. Delayed EDR alert (5 min MTTD too slow)

Lessons Learned (Process Improvement): - Focus: Organizational improvements - Audience: Broader (includes management, IT, business stakeholders) - Content: - What worked well - What didn't work - Action items for improvement - Policy/process updates

Example Lessons Learned Content:

Wins:
- EDR detected malware (though slightly delayed)
- Team contained spread within 30 minutes

Improvements Needed:
- Email sandboxing deployment
- MFA on all admin accounts
- Quarterly phishing simulations
- Update runbook with lessons

Action Items:
- Deploy sandboxing (IT, 2 weeks)
- Enable MFA (IT, 1 month)
- Conduct phishing training (HR, quarterly)

Relationship: Post-mortem informs lessons learned, lessons learned drives action

Reference: Chapter 8, Section 8.8 - Post-Mortem vs Lessons Learned

Correct Answer: B) A simulated incident scenario discussed by the IR team to practice decision-making without live system impact

Explanation:

Tabletop Exercise (TTX): - Format: Discussion-based simulation (no live systems affected) - Participants: IR team, SOC, IT, management, legal, PR - Duration: 2-4 hours - Facilitator: IR lead or external consultant - Goal: Test response plans, identify gaps, build muscle memory

TTX Structure:

1. Scenario Introduction (10 min):

"At 3:00 AM, your EDR alerts on WKS-042: 'Ransomware detected'.
The alert shows encryption activity on a file server.
What do you do?"

2. Facilitated Discussion (90-120 min): - Facilitator: "Who is the first responder?" - SOC Analyst: "Tier 1 analyst on duty" - Facilitator: "What's your first action?" - Analyst: "Isolate WKS-042 from network" - Facilitator: "Good. Who do you notify?" - Analyst: "Tier 2 IR lead and manager" - Facilitator: "IR lead, you're now involved. What do you investigate?" - IR Lead: "Check for lateral movement, identify patient zero..."

3. Inject New Information:

Facilitator: "30 minutes later, you discover 5 more systems encrypted.
The file server backup is also encrypted. What now?"

4. Decision Points: - When to involve law enforcement? - When to notify customers? - Pay ransom or restore from backups? - How to communicate with executives?

5. Debrief (30 min): - What went well? - What gaps were identified? - Action items

Example Scenarios: - Ransomware outbreak - Data breach (PII exfiltration) - Insider threat - Supply chain compromise - DDoS attack

Benefits: - Low risk (no production impact) - Builds team coordination - Identifies runbook gaps - Practice decision-making under pressure

Reference: Chapter 8, Section 8.9 - Tabletop Exercises

Correct Answer: B) When legally required or when incident involves criminal activity requiring investigation

Explanation:

When to Involve Law Enforcement:

1. Legal Requirements: - Data Breach Notification Laws: GDPR, CCPA, state laws may mandate law enforcement notification - Regulated Industries: HIPAA (healthcare), PCI-DSS (payment cards), banking regulations - Example: Breach of 10,000+ customer records → mandatory FBI notification

2. Criminal Activity: - Extortion (ransomware demands) - Financial fraud (wire transfer fraud) - Nation-state attacks (critical infrastructure) - Child exploitation material - Insider threats requiring prosecution

3. Need for Legal Authority: - Attacker infrastructure in foreign jurisdiction (need international cooperation) - Need subpoena power to obtain ISP records - Pursuing criminal charges

Considerations Before Contacting Law Enforcement:

Pros: - Access to threat intelligence - Subpoena power - Criminal prosecution - Decryption keys (FBI may have ransomware decryptors)

Cons: - Investigation may become evidence (loss of control) - Potential public disclosure - Extended timeline (criminal investigations take months/years) - May delay recovery

Decision Framework:

IF (legal requirement OR need prosecution OR need decryption assistance):
    Contact law enforcement
ELSE IF (prefer private handling AND no legal mandate):
    Handle internally, consult legal counsel

Who to Contact: - US: FBI Cyber Division, Secret Service (financial crimes), local field office - EU: National cybercrime units, Europol - Industry ISACs: Financial Services ISAC, Health ISAC

Reference: Chapter 8, Section 8.10 - Law Enforcement Coordination

Correct Answer: A) To make evidence read-only and prevent modifications that could compromise integrity

Explanation:

Write Protection for Forensics: - Purpose: Ensure evidence is not altered during analysis - Mechanism: Hardware or software write-blockers - Legal Requirement: Maintains evidence integrity for court admissibility

Write-Blocker Tools:

1. Hardware Write-Blockers: - Physical device between storage media and forensic workstation - Prevents any write operations to evidence drive - Examples: Tableau, CRU WiebeTech

2. Software Write-Blockers: - OS-level protection - Examples: Windows Registry tweaks, Linux mounting as read-only

Forensic Imaging Process:

Step 1: Attach suspect drive to hardware write-blocker
Step 2: Connect write-blocker to forensic workstation
Step 3: Create bit-for-bit image (dd, FTK Imager, EnCase)
Step 4: Calculate hash of source drive
Step 5: Calculate hash of image file
Step 6: Verify hashes match (proves integrity)
Step 7: Analyze IMAGE, not original drive
Step 8: Store original drive in evidence locker (never access again)

Why This Matters:

Scenario Without Write Protection:

Analyst mounts suspect drive to analyze
↓
Operating system automatically updates "last accessed" timestamps
↓
Evidence is now modified (metadata changed)
↓
Defense attorney: "Evidence has been tampered with!"
↓
Evidence inadmissible in court

Scenario With Write Protection:

Analyst mounts drive via write-blocker
↓
All read operations succeed
↓
OS attempts to update timestamps → BLOCKED
↓
Evidence remains unchanged
↓
Hash verification proves integrity
↓
Evidence admissible in court

Best Practice: NEVER analyze original evidence, always work on verified forensic copy

Reference: Chapter 8, Section 8.5 - Write Protection

Correct Answer: B) The first 60 minutes after detection when rapid response can significantly limit damage

Explanation:

Golden Hour Concept: - Origin: Borrowed from emergency medicine (critical first hour after trauma) - In IR: First 60 minutes after incident detection - Importance: Actions taken in this window drastically impact outcome

Why the Golden Hour Matters:

Ransomware Example:

00:00 - Ransomware detected on 1 system
00:05 - Analyst triages alert
00:10 - Isolates infected system
00:15 - Searches for lateral movement
00:20 - Finds attacker on file server (pre-encryption)
00:25 - Isolates file server
00:30 - Eradicates attacker presence

Result: 2 systems affected, no data loss

VS.

00:00 - Ransomware detected
02:00 - Analyst finally responds (delayed 2 hours)
02:15 - Begins investigation
02:30 - Discovers 50 systems encrypted

Result: 50 systems affected, 2TB data encrypted, $500K recovery cost

Golden Hour Actions:

1. Immediate Triage (0-5 min): - Validate alert is true positive - Assess severity

2. Rapid Containment (5-15 min): - Isolate affected systems - Disable compromised accounts - Block malicious IPs/domains

3. Scope Assessment (15-30 min): - Identify lateral movement - Find patient zero - Map affected assets

4. Escalation & Communication (30-45 min): - Notify IR lead - Brief management - Engage legal/PR if needed

5. Evidence Collection (45-60 min): - Capture memory dumps - Collect volatile evidence - Document timeline

Metrics: - Goal: Containment within Golden Hour - Measurement: Time from detection to containment - Industry Average: ~60 minutes for mature SOCs

Reference: Chapter 8, Section 8.11 - The Golden Hour

Correct Answer: B) Step-by-step procedures, decision trees, contact info, evidence collection, escalation criteria

Explanation:

Incident Response Runbook Components:

1. Incident Identification: - Alert name and SIEM query - Symptoms and indicators - ATT&CK mapping

2. Initial Response (Golden Hour Actions):

Step 1: Validate alert (true/false positive)
Step 2: Assess severity (Low/Medium/High/Critical)
Step 3: If High/Critical → Notify IR lead immediately
Step 4: Document start time and initial findings

3. Triage & Investigation:

- Check for lateral movement
- Identify compromised accounts
- Query threat intelligence
- Determine scope (how many systems affected?)

4. Containment Actions:

Decision Tree:
IF ransomware detected:
  → Isolate infected hosts immediately
  → Disable compromised user accounts
  → Block C2 domains/IPs at firewall

IF data exfiltration:
  → Block destination IPs
  → Snapshot affected databases
  → Preserve evidence

5. Evidence Collection:

- Memory dump: Use FTK Imager
- Disk image: Use dd or EnCase
- Network capture: tcpdump/Wireshark
- Log export: SIEM query [provide template]
- Calculate SHA256 hash for chain of custody

6. Escalation Criteria:

Escalate to IR Lead if:
- Severity: High or Critical
- Scope: > 5 systems affected
- Asset: Critical infrastructure (domain controller, database)
- User: Executive/VIP account
- Uncertainty: Analyst unsure of next steps

7. Contact Information:

- IR Lead: Jane Doe - jane@company.com - 555-0100
- Manager: John Smith - john@company.com - 555-0101
- Legal: legal@company.com - 555-0102
- PR: pr@company.com - 555-0103
- Law Enforcement: FBI Cyber - cyber@fbi.gov - 1-800-CALL-FBI

8. Recovery Steps:

- Eradication checklist
- System rebuild procedures
- Validation testing
- Return to production criteria

9. Lessons Learned Template:

- What worked?
- What didn't?
- Action items

Best Practices: - Keep runbooks updated (review quarterly) - Use checklists for consistency - Include screenshots/examples - Version control (track changes)

Reference: Chapter 8, Section 8.12 - Runbook Design

Correct Answer: B) To coordinate response, make strategic decisions, communicate with stakeholders, allocate resources

Explanation:

Incident Commander (IC) Role: - Authority: Central decision-maker during major incidents - Focus: Strategic coordination, not tactical execution - Duration: Active until incident is contained/resolved

IC Responsibilities:

1. Coordination: - Assemble IR team (analysts, IT, forensics, legal, PR) - Assign roles and responsibilities - Ensure teams don't duplicate efforts

2. Strategic Decision-Making: - Approve high-impact containment (isolate production systems?) - Decide when to involve law enforcement - Determine communication strategy - Prioritize response actions

3. Communication: - Upward: Brief executives, board - Lateral: Coordinate with IT, legal, PR - Downward: Direct IR team - External: Law enforcement, customers (if needed)

4. Resource Allocation: - Deploy additional analysts if needed - Authorize overtime/on-call - Engage third-party forensics if needed - Budget approvals for emergency tools/services

5. Documentation Oversight: - Ensure proper evidence handling - Review incident timeline - Approve post-incident report

Example: Ransomware Incident

Without IC (Chaotic):

- IT starts rebuilding servers
- SOC isolates systems
- Legal wants to preserve evidence
- PR drafts customer notification

Result: IT rebuilds destroy forensic evidence, SOC isolation disrupts recovery, conflicting actions

With IC (Coordinated):

IC: "Before any rebuilding, forensics team captures disk images"
IC: "SOC, identify all affected systems - don't isolate yet"
IC: "IT, prepare rebuild plan but wait for evidence collection"
IC: "Legal, draft notification but don't send until scope confirmed"
IC: "Forensics, you have 4 hours to collect evidence, then IT can rebuild"

Result: Evidence preserved, coordinated recovery, no conflicting actions

IC Decision Framework: - Technical Decisions: Delegated to experts (SOC lead, IT lead) - Strategic Decisions: IC makes final call (isolate production? notify customers?) - Escalation: IC decides when to escalate to CEO/board

Skills Required: - Calm under pressure - Clear communication - Technical understanding (doesn't need to be deepest expert) - Leadership experience

Reference: Chapter 8, Section 8.13 - Incident Commander Role