Incident Response and Forensics
Incident Response and Forensics
Incident response follows a lifecycle: Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned. Know the order and what belongs in each phase. Containment has short-term (isolate host) and long-term (rebuild, patch) variants.
Forensic fundamentals: order of volatility (CPU/registers → memory → network state → disk → backups/archives), chain of custody, hashing for integrity, write blockers, and documented acquisition. Memory captures often hold the most time-sensitive evidence (credentials, injected code).
Evidence handling: label, hash, log every transfer, store securely. Forensic images should be taken before remediation when feasible; if not feasible, document why.
Traps: jumping to eradication before containment (attacker remains active); wiping a host before imaging (destroys evidence); assuming antivirus logs are sufficient forensic evidence; and confusing lessons learned with recovery (lessons learned is after recovery and feeds preparation).
Rule of thumb: Contain first, preserve evidence second, eradicate third, recover fourth, learn last. If a question offers "immediately reimage the host" as an early step, it is usually wrong because it destroys evidence and may not address the root cause.
Worked example: An analyst finds a compromised server. Correct sequence: isolate it from the network (containment) while preserving volatile memory, acquire a forensic image, then eradicate and rebuild from a known-good baseline, then restore service and conduct lessons learned.
Understanding Network Security and Analysis
Understanding Network Security and Analysis
This domain tests whether you can read network evidence: packets, flows, and protocol behavior.
Concepts: the OSI/TCP-IP model and where controls operate; TCP three-way handshake and flags (SYN, ACK, RST, FIN); ports and protocols (80/443, 22, 53, 445, 3389); NAT; VLANs; DNS resolution flow; and TLS handshake basics (SNI, certificate validation).
Analysis tools and artifacts: packet capture (pcap) analysis, flow records (NetFlow/IPFIX), PCAP vs. flow (full content vs. metadata), and log correlation. Know beaconing (regular intervals, jitter), DNS tunneling (long/high-entropy subdomains, high query volume), ARP spoofing, and port scanning patterns (SYN scan vs. full connect).
Traps: assuming encrypted traffic is invisible (metadata, SNI, JA3, and flow patterns remain); misreading a RST as a successful connection; treating a single failed connection as malicious; and confusing NetFlow (metadata) with full packet capture (content).
Rule of thumb: When traffic is encrypted, pivot to metadata: who talked to whom, when, how often, how much, and to what domain.
Worked example: A host makes DNS queries every 60 seconds to random-looking subdomains of one parent domain, each ~200 bytes. This pattern suggests DNS tunneling/C2 beaconing. The analyst should examine query entropy, volume, and destination reputation, and correlate with endpoint telemetry.
Incident Reporting and Communication
Incident Reporting and Communication
Technical containment is only half of response; communication determines legal exposure, stakeholder trust, and regulatory compliance.
Audiences and channels: executive leadership (impact, risk, decisions needed), technical teams (indicators, actions), legal/compliance (obligations, privilege), regulators (statutory timelines), customers/public (transparency, controlled messaging), and law enforcement (coordination).
Key concepts:
- Escalation paths and severity classification: define who is notified, when, and by what channel.
- Regulatory notification timelines: know that obligations vary by jurisdiction and data type; breach notification windows are frequently tested conceptually (e.g., "notify within X hours/days").
- Communication discipline: single spokesperson, approved templates, no speculation, documented decisions.
- Evidence and privilege: route legal-sensitive communications through counsel.
- Post-incident reporting: timeline, root cause, impact, remediation, lessons learned.
Traps: communicating technical detail to executives instead of business impact; notifying the public before regulators/legal review; assuming no notification is required because data was "encrypted"; and letting multiple spokespeople issue conflicting statements.
Rule of thumb: Match the message to the audience: executives get impact and decisions; technical teams get indicators and actions; regulators get facts and timelines; the public gets a controlled, approved statement.
Worked example: A breach exposes customer PII. Correct sequence: escalate internally, engage legal to assess notification obligations, preserve evidence, prepare an approved external statement, notify regulators within the required window, then communicate to affected customers per the approved plan.