Vulnerability Assessment, Incident Simulation, and After-Action Documentation

Vulnerability Assessment, Incident Simulation, and After-Action Documentation

This lesson brings together every skill you have built across the program. You will run a real vulnerability scan, respond to two live simulated incidents, and assemble a professional documentation portfolio. This is the kind of work security analysts and junior SOC analysts do every day.

Running a Structured Vulnerability Scan

A vulnerability scanner probes your environment for known weaknesses — missing patches, weak configurations, open ports, and default credentials — and maps its findings to a database of known vulnerabilities. You will use either OpenVAS (Greenbone Community Edition) or Nessus Essentials. Both are free for non-commercial use and produce exportable reports.

Before you launch a scan, confirm you have written authorization to scan your capstone environment. Scanning systems you do not own or have explicit permission to test is illegal under the Computer Fraud and Abuse Act. In a production workplace, this authorization comes from a formal Rules of Engagement document. For this capstone, your instructor's assignment brief serves that role.

After the scan completes, export the raw results. Do not submit the raw export as your findings report — you must interpret the data. Classify every finding using CVSS (Common Vulnerability Scoring System) severity bands published by FIRST.org: Critical (CVSS 9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (0.1–3.9). For every Critical and High finding, write a plain-language risk statement explaining what an attacker could do if they exploited it, and recommend a specific remediation action such as applying a named patch, disabling an unnecessary service, or changing a configuration setting. Medium and Low findings require classification but not individual remediation write-ups unless your instructor specifies otherwise.

Responding to Instructor-Injected Incidents

During a defined two-hour window your instructor will inject two simulated incidents into your running environment:

• Incident 1: A brute-force SSH login attempt that results in one successful authentication.
• Incident 2: A malware beacon to a flagged external IP address.

Your SIEM is your primary detection tool. Watch your dashboards and alerts. When you detect an event, open an incident ticket immediately — do not wait until you understand the full scope. Record the timestamp of your first detection, the alert or log entry that triggered it, the systems involved, and every action you take. Use the incident ticket format from the Incident Response course: Ticket ID, Detection Time, Severity, Summary, Affected Assets, Timeline of Actions, Containment Steps, Evidence References, and Status.

Containment means limiting the damage. For the SSH incident that might mean disabling the compromised account, blocking the source IP at the firewall, and rotating SSH keys. For the beacon incident it might mean isolating the affected host and blocking the destination IP. Your runbook should tell you exactly which steps to take and in what order — follow it, and note any point where reality did not match your plan.

Time discipline matters. Your runbook defines time parameters for containment. Missing those parameters is data for your after-action report, not a reason to falsify your ticket timestamps.

Building the Documentation Portfolio

A complete security posture is only as strong as the documentation that supports it. Professionals who cannot document their work cannot defend it to auditors, managers, or regulators. Your final portfolio must include all seven documents in a single organized PDF:

1. Finalized network diagram

2. Security policy (acceptable use, password, and patch management sections)

3. Risk register updated with residual risk ratings after hardening

4. Incident response runbook

5. Completed incident ticket for Incident 1

6. Completed incident ticket for Incident 2

7. Two-page after-action report (AAR)

The AAR is the most important analytical document you will write. It must identify what worked during the incident response, what failed or was slower than planned, and three concrete process improvements you would implement if this were a real environment. Vague statements like "communication could be better" are not acceptable — name the specific gap and the specific fix.

Accuracy and Professionalism

Every finding, timestamp, and action you document may be read by an employer or an auditor. Write clearly, use consistent terminology, and cite the evidence behind every claim. If a log entry supports your timeline, reference it by log source and timestamp. If a CVSS score drives your severity rating, note the score. Precision in documentation is a professional and, in regulated industries, a legal requirement.

Safety and Ethical Reminders

Cybersecurity tools are dual-use: they can defend or attack. Use your scanner and SIEM only within your authorized capstone environment. Never redirect scans toward external hosts or your school's production network. Handle any credential or key material generated during the lab as sensitive data and delete it after the exercise. These habits are not just classroom rules — they reflect the ethical standards embedded in the ISC2 Code of Ethics and CompTIA's candidate agreement, both of which you agreed to when you registered for your certification exams.