LAB-SEC-201 — OpenVAS / Greenbone Vulnerability Management
Purpose
Use Greenbone Vulnerability Management to build a bounded network vulnerability assessment, interpret scan quality and convert raw vulnerability-test results into remediation-ready findings.
Authorised scope
Target only 10.77.0.20 and 10.77.0.50 during the assigned window. Maximum concurrent scan tasks: 2. Denial-of-service checks, default-credential checks and destructive tests remain disabled.
Download:
Learning objectives
- distinguish assets, targets, port lists, scan configurations, tasks and reports;
- explain how feed freshness affects result quality;
- configure a scan that respects timing and traffic limits;
- separate scanner confidence from confirmed exploitability;
- prioritise findings using severity, exposure, asset role and compensating controls.
Task 1 — Readiness and provenance
Record:
- Greenbone/OpenVAS version;
- vulnerability-test feed status and timestamp;
- scanner time and timezone;
- source interface and scanner address;
- permitted targets and exclusions;
- scan profile and port list.
Do not begin until the feed is available and the target list exactly matches the scope fixture.
Task 2 — Build the target and task
Create a target named northstar-bounded-target containing:
10.77.0.20
10.77.0.50
Use a TCP port list appropriate to the known lab services. Create a task named northstar-bounded-scan. Set concurrency to a conservative value and schedule only inside the authorised time window.
Checkpoint: A broad default target is a governance failure even when the scanner itself is correctly installed.
Task 3 — Execute and monitor
During execution, capture:
- start and completion timestamps;
- host availability results;
- scan interruptions or timeouts;
- number of vulnerability tests completed;
- any excluded or unreachable services;
- scanner resource pressure.
Stop the task if it resolves outside the lab subnet or creates abnormal load.
Task 4 — Triage the report
For the two synthetic findings in the evidence pack, complete:
| Field | Required analysis |
|---|---|
| Finding | Exact scanner title and identifier |
| Asset | Host, service and business role |
| Severity | Scanner score and vector where available |
| Confidence | High, medium or low with justification |
| Evidence | Detection method, service response and raw output |
| Validation | Second tool or manual verification step |
| Impact | Plausible effect in the Northstar scenario |
| Remediation | Specific configuration, upgrade or isolation action |
| Retest | Observable secure state after remediation |
Task 5 — Correlate with Nmap
Use the Nmap section of the synthetic evidence pack or complete LAB-SEC-202. Confirm whether the service inventory supports the OpenVAS findings. Record discrepancies such as:
- service found by one tool only;
- version mismatch;
- closed or filtered port during one scan;
- generic product-family detection without a precise version;
- vulnerability test based on banner inference rather than behaviour.
Deliverables
- exported Greenbone report;
- scan configuration screenshot or settings export;
- finding-validation matrix;
- remediation priority list;
- one-paragraph limitations statement.
Knowledge check
1. Why is a high severity score not sufficient proof of exploitability?
The scanner may infer risk from a service signature, version or configuration. Exploitability also depends on exact build, exposure, authentication, compensating controls and runtime behaviour.
2. What should be checked before trusting a vulnerability report?
Feed freshness, target accuracy, service reachability, detection evidence, scanner errors and independent validation.
3. Why retain the raw report after remediation?
It provides traceability for the original evidence, remediation decision and later retest comparison.