Stop 4 of 9 · Weekly
Vulnerability management
A redacted Nessus export becomes a deduplicated, prioritised remediation plan and a client summary that says what to do without a wall of CVE numbers.
Six hundred rows, thirty decisions
The Nessus export for a twenty-user client runs to hundreds of rows. Most of them are the same three problems seen from different angles: a patch level behind on a group of endpoints, a TLS setting on an appliance, an agent nobody upgraded. The scanner counts findings. The client pays for causes.
This is also the workflow where the redaction rule earns itself. A scan report is dangerous precisely because it pairs a weakness with a place to find it. So the file that reaches a chat is not the report.
The export Hazem actually attaches
| Keep | Drop |
|---|---|
| Plugin identifier and name, severity, CVSS, count | Hostnames, IP and MAC addresses, DNS names |
| Asset role label such as clinical workstation or hypervisor | Serial numbers, asset tags, usernames |
| First seen date, patch or fix text from the plugin | The plugin output block, which quotes live config |
Two columns in a spreadsheet do this: replace the host column with a role label, delete the output column. It takes five minutes and it is the difference between a working file and an incident. The redacted file goes into the chat, not into the client Project files, because next month scan replaces it.
[attach the redacted scan export] Group these findings by root cause, not by row. A root cause is the single change that would close a set of findings at once, such as one missing cumulative update, one firmware level, one disabled protocol. For each cause give me: the cause in one line, how many findings it closes, the highest severity inside it, the asset roles affected and the count, and whether the fix is a patch, a configuration change, a replacement or a vendor action. Sort by findings closed. List anything that does not group under Singletons at the end.
From the causes above, build the remediation plan. One row per cause with: the work, the owner as us, the client or the application vendor, the change window it needs, whether a reboot is involved, the risk of doing it, and the risk of not doing it before the next scan. Split into this month and next month based on severity and window availability. Northgate has no clinical downtime between 07:30 and 18:00, and the practice management application is out of our scope, so anything touching it becomes a vendor line with a chase date.
Write the monthly security note for the Northgate practice manager, who is not technical. Four short paragraphs: what we closed, what is left and who owns it, the one thing that needs a decision from her, and the date of the next scan. No CVE numbers, no CVSS scores, no plugin names. Every number in it must come from the attached data, and if you cannot source a claim, leave it out.
The artefact
The cause list, the remediation plan with owners and windows, and the one-page client note. The plan goes into the ticket system as work, the note goes to the client.