Vulnerability Management Program
Home lab project — isolated environment, self-authorized scope
This project documents a Nessus Essentials vulnerability assessment performed in a private VirtualBox lab. The published scope is intentionally limited to the work supported by the repository: a Basic Network Scan against Windows 10, Ubuntu Server 22.04, and pfSense targets from a Kali Linux 2024.1 scanner.
Scope
The assessment was limited to systems I owned and controlled inside an isolated lab network. The objective was to practice defining scope, maintaining an asset inventory, configuring a scan, reviewing results, and planning remediation without scanning public or unauthorized systems.
Asset Inventory
- Windows 10 VM — workstation target
- Ubuntu Server 22.04 — Linux server target
- pfSense — firewall and gateway target
- Kali Linux 2024.1 — Nessus scanner host
Scan Method
I used Nessus Essentials with a Basic Network Scan and custom configuration against the defined lab targets. The repository does not currently document authenticated credentials or a CIS compliance audit, so this page does not describe the scan as credentialed or compliance-based.
Findings
The repository contains a draft findings summary, but the published severity totals, plugin identifiers, CVSS values, and specific vulnerability mappings cannot be validated from an original .nessus export currently available in the repository. I have therefore omitted those numbers and individual claims here until they can be checked directly against scan evidence.
Prioritization
The intended review process considers scanner severity, affected service, network exposure, asset role, exploitability, and remediation effort. This is the prioritization method for the lab—not a claim that a completed enterprise risk-scoring program or production SLA process was implemented.
Remediation
The repository includes remediation-planning material for patching, reducing exposed services, and hardening configurations. Those items are presented as a plan pending validation against a fresh scan export, not as evidence that every listed vulnerability was confirmed or fixed.
Verification
A completed post-remediation rescan is not currently documented. Verification remains a next step: export the original scan results, validate each finding and identifier, apply selected remediations, rerun the same scan, and compare before-and-after evidence.
Lessons Learned
The strongest lesson was that scanner output must be treated as evidence to validate, not a finished report. Accurate plugin mapping, severity, affected asset, and scan type matter more than a polished finding count. Keeping the public write-up aligned with the underlying evidence makes the project easier to defend in an interview and creates a clearer path for the next scan iteration.