Two separate judgments. Score = Likelihood × Impact drives prioritization (the order to remediate). Categorization is a different question — which security property does this finding threaten (Confidentiality, Integrity, Availability) and does it carry a compliance obligation? A finding's category doesn't change based on its score.

Categorization examples. The unauthenticated web server, PHI-in-dev/test, prescription email, and fax machine findings are all Confidentiality/Compliance — each exposes PHI/PII and triggers a HIPAA obligation. Unauthorized software is Integrity/Compliance — it risks unapproved code changing system behavior, not direct data exposure. Malicious emails and improperly configured third-party websites are Confidentiality/Integrity — both are vectors for malicious code or credential theft. The ICMP traffic finding is Confidentiality alone — it exposes network information, not PHI.

Highest priority, #8: the unauthenticated web server (score 25, High) — direct, credential-free exposure of data outranks everything else. Lowest priority, #1: sensitive materials left unattended on a fax machine (score 3, Low).

Priority numbering runs low-to-high with score — priority 1 is the least urgent finding, priority 8 is the most urgent.

Controls aren't one-size-fits-all. The prescription email finding needs both Implement DLP and Implement email encryption — DLP catches the mistake in the future, encryption protects data in transit if it happens again. The malicious email finding needs Implement mail filters and Implement SPF — filtering catches malicious attachments, SPF prevents domain spoofing. Most other findings only need one control. Acceptance and several other listed controls (IAM program, IDS/IPS, MDM, FDE, file integrity monitoring, relocating devices) are intentional distractors — none of the eight findings call for them.

Takeaway. Don't conflate severity with category — a Low-severity finding can still be a Confidentiality/Compliance issue, and a High-severity finding isn't automatically "worse" in category, just more urgent to fix first.

Baseline the normal pattern. dkim's legitimate edits all come from 10.20.30.0/24 — the office range — during business hours, writing pages like team.html and contact.html.

The outlier. At 20:15, dkim's account logs in from 32.111.16.37 — an external IP, well outside the office range, at an unusual hour — and writes index.html, the site's actual homepage. That's the source IP to be concerned about.

Indicator of compromise. The netstat and HTTP logs confirm 32.111.16.37 connected on port 22 and pulled the homepage right after. The write to index.html — the page that visibly changed — is the actual indicator, not the unrelated failed logins from 71.44.19.203 or the 404s from 203.0.44.9 (someone just mistyped a filename).

Corrective actions. Change the password on the dkim account (the credential was used from an unexpected location) and Block external SFTP access (the actual exposure that let it happen). Shutting down the file transfer server or deleting the account are disproportionate — dkim still needs to edit the site from the office; blocking all of 10.20.30.* would lock out the legitimate internal logins too.

Tab 1 is netstat -bo output — the columns (Proto / Local address / Foreign address / State / PID) plus the owning executable in brackets under each connection, and the PID column, is exactly what -bo adds to netstat.

Tab 2 is tasklist output — Image Name / PID / Session Name / Session# / Mem Usage is tasklist's default column layout, and its PIDs line up with the ones shown in tab 1.

The suspicious process. In tab 1, a second instance of cmd.exe holds an ESTABLISHED connection to an external IP on port 22 — command-line access reaching out to the internet is not normal behavior. Tab 2 confirms two separate cmd.exe processes running under different PIDs, one with far more memory usage than a typical command prompt.

Confirming it. Tab 3's current hash for cmd.exe doesn't match tab 4's baseline hash for the same file — every other file's hash is identical between the two tabs. A changed hash means the binary was replaced or modified, confirming cmd.exe is the file responsible for the exfiltration.

CandyManCarl.Local (192.168.1.20) — open ports: 21/ftp, 135/msrpc, 139/netbios-ssn, 445/microsoft-ds. The Windows file-sharing stack (135/139/445) makes this a File Server. FTP 21 is a separate, unencrypted file-transfer protocol running alongside it — disable it.

FarmerLaura.Local (192.168.1.30) — 143/imap and 993/imaps both open, making this a Mail Server. IMAP 143 sends credentials and mail in cleartext; IMAP/S 993 is the encrypted equivalent — disable the insecure one.

SandwichSara.Local (192.168.1.40) — 22/ssh, 53/udp dns, 3306/mysql. MySQL makes this the Database server; SSH is normal admin access. DNS has no business running here — it's a second, unrelated service violating "one primary service per device."

FarmerTed.Local (192.168.1.10) — 22/ssh, 23/telnet. This is the Switch (the LAN's central connection point in the topology). Telnet is unencrypted remote management — disable it in favor of SSH.

LunchTimeMike.Local (10.10.10.25) — sits in the DMZ, satisfying the "protected subnet" guideline for internet-facing systems. 80/http and 443/https make it the Web Server. SSH 22 is a management port exposed on a public-facing DMZ host — a separate service beyond its primary role that shouldn't be reachable from the internet segment.

APPWEB01 (10.50.0.20) — the scan flags cleartext transmission of session data. The diagram shows APPWEB01 sits in the CDE, reachable from the internet through the firewall — this is production traffic, so the finding is a True Positive. Fix: Encrypt Entire Session (force TLS/HTTPS for the whole session, not just login).

APPWEB02 (10.50.0.21) — a session cookie is missing the Secure attribute, meaning it could be sent over plain HTTP if that path ever exists. This is a real configuration gap in the new code — True Positive. Fix: Set Secure Flag on Cookies.

APPWEB03 (10.50.0.22) — the server presents a certificate not issued by a trusted CA. Since this server is internet-facing in the CDE, browsers connecting to it will show trust warnings — a genuine issue, True Positive. Fix: Replace with Certificate from Trusted CA.

Takeaway. "True Positive" means the scanner correctly found a real issue — validity and remediation are two separate judgment calls. A finding can be real (true positive) but still need the right fix chosen from several plausible-looking options.

Listing 1 — Non-credentialed scan, File/Print Server. The findings are a mix of generic banner-grabbed Windows and Samba vulnerabilities. Finding 13852 (Windows Task Scheduler Remote Overflow) is a false positive — it's a client-side/workstation-oriented flaw that a non-credentialed scan mis-flags on this server based on an exposed banner alone. The rest — including 19407, Printer Spooler Service — are true positives on a real File/Print server.

Listing 2 — Credentialed scan, Linux Web Server. The findings reference Ubuntu-specific packages (php5, gnupg) — clear evidence of a credentialed, authenticated scan that could read local package versions. Finding 11890 (Buffer Overrun in Messenger Service, CVE-2016-8035) is a false positive — that CVE applies to a Windows-era service, not this Linux host. 19407 (Windows Printer Spooler) also doesn't run on this asset, but the graded false positive for this listing is 11890.

Listing 3 — Compliance scan, Directory Server. These findings are policy/configuration checks (SAM enumeration, key protection, sharing model) rather than CVE-based vulnerabilities — the signature of a compliance/benchmark scan run against a Directory Server. False-positive evaluation doesn't apply to compliance findings, so no checkboxes are graded here.

Identification. The firewall's alert message names the executable directly: invoice.exe From 81.161.63.253. Cross-referencing the malware domain list confirms 81.161.63.253 is a known-bad IP. The file integrity report shows invoice.exe first appearing (Added) at 1 Dec 2019 14:03:19 — that's when the malware entered the organization.

Kill chain mapping. Each stage gets the control that would have broken the chain at that specific point: Email filtering stops the phishing email before delivery; forcing plain-text email format strips the clickable link so it can't be activated; an IP blocklist stops the connection to the known-bad IP; a firewall file type filter blocks the executable from downloading in the first place; restricted local user permissions stops silent installation; updated antivirus catches the malware at execution; disk-level encryption protects data confidentiality even if the endpoint is compromised further.

Takeaway. A single control rarely stops a phishing-to-ransomware chain — defense works because each stage has an independent control that can break the chain even if an earlier one fails.

Match the CVSS score to a bracket. The Tomcat finding is CVSS 8.1, which falls in the 7.0–9.5 bracket — a 12-day remediation window that applies to PROD and UAT, but not DEV.

Confirm the environment applies. The affected asset, 192.168.80.9, falls within the uat.cascadefreight.io subnet (192.168.80.0/24) — UAT is in scope for this bracket, so this finding must be remediated within 12 days.

Why the other findings don't qualify for 12 days. The sensitive-cookie finding (CVSS 6.5, 192.168.94.12) is in the 4.0–6.9 bracket — DEV is excluded from that bracket entirely, so no SLA clock applies at all. The TLS certificate finding (CVSS 4.5, 192.168.90.20) is PROD but falls in a lower bracket with a 25-day window. The privilege-escalation finding (CVSS 7.8, 192.168.95.14) would qualify for the 12-day bracket by score, but the asset is in DEV — which the 7.0–9.5 bracket doesn't cover.

Technique. The finding is "unsupported software version" — the fix is to patch; upgrade Tomcat to current supported release, not a workaround or compensating control, since a supported version is directly available.