Lesson 9 of 12 — Vulnerability Management & Incident Response
Finding vulnerabilities before attackers do, triaging and remediating them by risk, and — when attacks succeed — executing a structured incident response, conducting root cause analysis, and preserving forensic evidence that stands up to scrutiny.
Security professionals live in two modes: proactive and reactive. Vulnerability management is the proactive mode — finding weaknesses in your environment before an attacker does, assessing their real-world risk, fixing the highest-priority issues first, and verifying the fix worked. Incident response is the reactive mode — the structured process that kicks in when a security event occurs, requiring disciplined decision-making under pressure to contain damage, eradicate the threat, recover operations, and learn from what happened.
Both disciplines are tested heavily in the Security Operations domain, which carries 28% of the Security+ exam — the single highest-weighted domain. CompTIA tests these topics almost entirely through scenario questions: you will read an incident description and be asked what the next correct IR action is, or you will see a vulnerability scan output and be asked which finding to remediate first. Mastering the frameworks in this lesson — the vulnerability management lifecycle and the PICERL incident response lifecycle — gives you the mental model to answer those questions correctly every time.
Scanning, analysis, remediation, and validation — finding weaknesses before attackers do and closing them systematically.
The lifecycle: scan (discover weaknesses) → analyze (prioritize by risk) → remediate (patch, configure, mitigate) → validate (confirm the fix worked). Credentialed scans see more than non-credentialed. CVSS + asset criticality + exploitability-in-wild drives remediation order.
The PICERL lifecycle — Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned — and the critical decisions at each phase.
IR is not improvised — it follows a documented playbook. Preparation builds the capability before an incident. Identification determines that an incident is real. Containment stops the bleeding. Eradication removes the threat. Recovery restores operations. Lessons Learned prevents recurrence.
Why the attack succeeded — and how to collect, preserve, and analyze evidence that proves it in legal and regulatory proceedings.
RCA distinguishes root causes from symptoms — fixing only the symptom means the same attack succeeds again. Forensics requires: collect volatile evidence first (RAM before disk), maintain chain of custody, use write blockers, create forensic images, and never work on originals.
Scanning, analysis, remediation, and validation — finding weaknesses systematically before attackers do
Vulnerability management is a continuous cycle, not a one-time project. Every organization has vulnerabilities — the goal is not to achieve zero vulnerabilities (impossible) but to identify, prioritize, and eliminate the highest-risk ones faster than attackers can exploit them.
Non-credentialed (unauthenticated): The scanner connects to the target like an attacker would — without login credentials. It can only detect vulnerabilities visible from the network: open ports, service banners, exposed web interfaces, and publicly exploitable conditions.
Credentialed (authenticated): The scanner is provided valid credentials (admin/service account) and logs into each target system. It can read installed software versions, registry keys, configuration files, and applied patches — providing a far more complete and accurate picture of the vulnerability landscape.
Internal scan: Conducted from inside the network — finds vulnerabilities that an insider or already-compromised system could exploit. Represents the attacker's post-initial-access view.
External scan: Conducted from outside the network perimeter — simulates an attacker's view from the internet. Identifies what is exposed to the public and exploitable without prior network access.
Agent-based scan: A lightweight agent installed on each endpoint continuously reports vulnerability status. Provides real-time visibility without needing to schedule scan windows or maintain scan credentials.
CVSS score alone is insufficient for prioritization. A CVSS 10.0 vulnerability on a test server with no sensitive data is less urgent than a CVSS 7.0 on an internet-facing payment system with an active exploit. The correct framework combines multiple factors:
A practical SLA framework for vulnerability remediation:
The direct fix — vendor-supplied code that closes the vulnerability. The gold standard: eliminates the root cause. Requires testing before production deployment to avoid introducing service disruptions.
When a patch is not available (zero-day) or not immediately deployable (requires system downtime), mitigation reduces exploitability without eliminating the vulnerability:
For low-risk vulnerabilities where remediation cost exceeds the potential impact, the organization may formally accept the risk. This requires:
Applying a patch does not guarantee the vulnerability is closed. Patches can fail to install, can be rolled back by other updates, or may not address the specific configuration that made the system vulnerable. Validation is the re-scan that proves the remediation worked.
The vulnerability management lifecycle is a continuous loop — not a linear process. After validation, monitoring for new vulnerabilities in the same asset begins immediately. New CVEs for already-patched software versions can appear within days of the previous patch cycle closing.
The structured lifecycle that transforms chaos into disciplined response: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned
Incident response is not improvised — organizations that improvise under the pressure of an active attack consistently make costly mistakes: destroying evidence by rebooting systems, alerting attackers by changing credentials too early, or declaring recovery before the threat is fully eradicated. The PICERL framework (aligned to NIST SP 800-61) provides the mental model for disciplined IR decision-making.
Everything you do before an incident occurs. Preparation determines whether your organization responds effectively or chaotically. No amount of technical skill during an incident compensates for missing preparation.
Detecting that a security event has occurred, determining whether it constitutes a confirmed incident, and characterizing its scope and severity. This phase is where alerts become incidents — or are triaged as false alarms.
Stopping the attack from spreading further while preserving evidence for investigation. Containment is a two-stage process: short-term (immediate stoppage) and long-term (stable, sustainable containment while eradication is prepared).
Removing the threat — the attacker's tools, malware, persistence mechanisms, and unauthorized accounts — completely and verifiably from the environment. Partial eradication is worse than no eradication (it creates false confidence).
Restoring affected systems and services to normal operations — but only after verifying the threat has been eradicated. Premature recovery that returns systems before the threat is gone restarts the incident cycle.
The most frequently skipped and most valuable phase. Lessons learned directly improves the organization's security posture and prepares for the next incident. Conducted as a structured after-action review within 1–2 weeks of incident closure.
Finding the underlying "why" behind an incident — and collecting evidence that proves what happened
Root cause analysis and digital forensics are closely linked: forensics collects the evidence, and RCA interprets that evidence to find the fundamental failure. Without RCA, organizations fix symptoms and face the same incident again. Without proper forensics, there is no evidence to support RCA — or legal proceedings.
The most common RCA failure is treating the symptom as the root cause. A ransomware infection is a symptom — the root cause is usually one of: unpatched vulnerability, phishing email that bypassed email filtering and security awareness training, or credentials compromised and MFA not enforced.
If you only remove the ransomware (treat the symptom) without identifying and closing the initial access vector, the same attacker — or the next one — will re-enter through the same door within weeks.
A completed RCA produces three categories of outputs:
Each finding maps to a corrective action with an owner, timeline, and success metric. RCA is not about blame — it is about systemic improvement. Organizations with mature incident response programs treat every incident as a learning opportunity, not a failure to hide.
Digital evidence exists on a spectrum from highly volatile (disappears within seconds of power loss) to highly persistent (survives storage for years). The order of collection must match this spectrum — collect the most volatile evidence first.
netstat -ano, arp -a
ps aux, Task Manager export, process tree
Chain of custody is the documented, unbroken record proving that evidence was collected, handled, and stored without tampering. It is the forensic foundation for legal admissibility.
| Evidence Type | What It Contains | Collection Method | Key Forensic Value |
|---|---|---|---|
| RAM Image | Running processes, decrypted files, active network connections, user sessions, registry hive loaded into memory, encryption keys | Volatility, WinPmem, FTK Imager (live acquisition) — must be collected before power off | Fileless malware only exists here; encryption keys for encrypted ransomware may be in RAM |
| Disk Image | All files, deleted files (recoverable from unallocated space), file metadata (timestamps, ownership), partition tables, slack space | Write blocker (hardware) + FTK Imager or dd — creates forensic copy while blocking any writes to the original | Deleted malware artifacts, attacker tools, modified system files, timeline analysis |
| Network Capture (PCAP) | All network traffic packets — full content (if unencrypted) or metadata (source/dest IP, port, timing, payload size) | Wireshark, tcpdump, SPAN port mirror — ideally collected before incident is contained | C2 communication patterns, data exfiltration volume/destination, lateral movement traffic |
| Log Files | System events, authentication attempts, process execution, network connections — from OS, applications, and security tools | Export from SIEM; local logs from /var/log/ (Linux) or Windows Event Viewer; preserve originals |
Authentication timeline, initial access evidence, attacker command execution, lateral movement path |
| Mobile Device | Call logs, messages, photos, app data, location history, browser history, deleted data in flash memory | Cellebrite UFED, Oxygen Forensics — device in airplane mode to prevent remote wipe; Faraday bag to block signals | Insider threat evidence, attacker communication, location alibi verification |
Sort each vulnerability finding into the correct remediation priority tier based on CVSS score, asset criticality, and exploitability
Select a real-world incident and answer questions about the correct IR phase actions, forensic procedures, and RCA findings
cmd.php) in the web root directory that was not present in last week's scan. The web shell was created on a Tuesday at 2:14 AM — six days ago. The e-commerce site has been running normally. No customer-visible outage occurred. The security team has no idea what the attacker did during those six days. The server stores customer session tokens and processes credit card transactions (PCI DSS in scope).Select the best answer for each question, then submit for graded feedback