1,247 Findings, Three People, Five Days
Northwind Logistics approved a four-hour weekly scanning window for its 512-server PCI zone. Your authenticated scan using a dedicated service account completes with 1,247 findings: 96 rated critical or high and 812 medium. Credential checks fail on 40 hosts - 26 require SMB signing and reject the fallback, and 14 were using a scan account that a mid-window password rotation reset. Of the 96 critical and high results, 61 are the same missing cumulative update on Windows Server 2016 hosts, 22 are 'expired certificate' on an internal CA that rotated its root last month, and 8 are end-of-life Apache Tomcat on three application servers. The blue team also emails you: their IDS raised 'possible exploit attempt' alerts on two hosts, triggered by a scanner plugin that sends a crafted probe. Your report is due in five days, and the previous year's report shipped 1,100 raw findings with no prioritization, which the client described as unusable.
1. Describe how you turn 1,247 findings into a prioritized deliverable the client can act on within five days.
Read the worked answer
The deliverable is a decision document, not a list. Sequence:
1. Deduplicate by root cause, not by plugin ID. The 61 missing-update rows are one patch-debt problem. The 22 expired certs are one CA-rotation problem. The 8 EOL Tomcat instances are one lifecycle problem. That collapses 96 high findings to roughly 15 distinct issues - which is the number the client can actually work with.
2. Reclassify before reporting. Certificates issued from an internal root that was deliberately rotated last month are probably expected; confirm against the new root store and the change record. Reporting them as live findings is exactly how last year's 1,100-item list lost credibility.
3. Score on asset criticality × exposure × exploitability. Internet-facing, in the cardholder data environment, with a public exploit or known exploitation in the wild ranks first - not 'critical' by scanner label.
4. Validate the top ten manually. Scanners produce false positives and false negatives; the report's credibility rests on the first page being right.
5. Close the coverage hole. Re-scan the 40 unassessed hosts with corrected credentials before shipping, or state explicitly what was not assessed.
6. Give them a plan that fits three people. One patch cycle closes 61 findings; a GPO change closes the 26 signing-related failures. Framing fixes by effort-to-impact is the difference between a report that is read and one that is filed.
2. What is the significance of the 40 hosts where authentication failed, and how do you represent them?
Read the worked answer
Authenticated scanning reads the registry, installed package list, and local configuration; unauthenticated scanning sees banners and network behaviour only. The gap is not cosmetic: the scanner cannot see missing patches applied at the OS level, installed-but-not-listening software, local policy weaknesses, or per-host configuration drift. It also invents findings from version strings, so the results are wrong in both directions.
Therefore the 40 hosts are not 'clean.' They are unknown, and reporting them as zero findings understates risk by an amount nobody can quantify. Represent them in three places: an explicit coverage metric on the summary page ('472 of 512 hosts assessed, 92% authenticated coverage'), an appendix listing the 40 with the failure reason, and a finding in its own right about the scanning control - a single scan account with a rotation schedule that can break mid-window is a single point of failure, and 26 hosts rejecting the fallback means the credential policy was never validated against the estate.
Remediation recommendations: a dedicated scan account whose rotation is coordinated with the scanning schedule, GPO exceptions scoped by OU for the signing requirement, and an alert when authenticated coverage falls below a threshold so the gap is noticed in-month rather than at report time. If credentials can be fixed inside the five-day window, re-scan and cut the number; if not, say so plainly rather than letting the client assume silence means safety.
3. You must confirm the highest-severity finding without risking production. What verification method do you choose and what do you refuse to do?
Read the worked answer
Choose the check by what it costs if the answer is wrong.
Acceptable confirmation: an authenticated query of the patch state (Get-HotFix, the WMI QFE list, or the package inventory, depending on platform) showing the update is genuinely absent; a version banner matching the vendor's affected range; the vendor advisory's own detection script; or a read-only probe the vendor documents as non-disruptive. Two independent signals are enough for a report - a scanner hit plus a manual patch-state query is defensible.
Refuse: running a public exploit against production. It can crash the service, corrupt data, or leave the host in a state the client has to rebuild, and 'it worked' does not make it authorized - the SoW's no-DoS clause and general prudence both prohibit it. If the client needs proof of exploitability to fund the fix, ask for a clone, a VM, or a maintenance window and demonstrate there.
Coordinate before you probe. The IDS alert on two hosts is the cost of skipping this step: unexplained 'exploit attempt' alerts burn blue-team time and damage the engagement. Notify the asset owner and the SOC with the source address, target, time, and plugin name, and ask them to suppress or annotate. That email is itself useful evidence - it shows whether their detection fires on a benign crafted probe or only on real exploitation, which becomes a detection-tuning finding alongside the vulnerability.