Two Criticals, One Maintenance Window
A 240-bed regional hospital runs its semi-annual vulnerability scan and gets two findings that both land in the "critical" bucket of the ticketing system. Finding A: CVSS 9.8, unauthenticated remote code execution in an outdated JBoss instance on the patient-scheduling web application. The app is internet-facing but sits behind a WAF with a vendor-supplied virtual patch enabled. Finding B: CVSS 7.2, authenticated command injection in the management console of an infusion-pump fleet controller on the clinical-device VLAN. The vendor has declared the model end-of-life and will not patch it, and the VLAN is flat with 400+ devices on it. Change control allows exactly one six-hour maintenance window this week and requires a tested rollback plan. The CISO asks which one you fix.
1. Decide which finding gets the maintenance window this week. Justify the decision using more than the CVSS scores.
Read the worked answer
Neither score decides this - the deciding question is "which action actually removes risk?"
Build a small comparison instead of ranking by number:
| A (JBoss 9.8) | B (pump controller 7.2) | |
|---|---|---|
| Reachable by attacker? | Yes, internet-facing | Only from inside the device VLAN |
| Precondition | None (pre-auth) | Valid domain credentials |
| Can it ever be fixed? | Yes, patch exists | No - vendor EOL, permanently unpatchable |
| Blast radius if used | Scheduling app + PHI it holds | Clinical devices; patient safety |
| Existing mitigation | WAF virtual patch | None |
The window goes to A, but not because 9.8 > 7.2. It goes to A because A is the only one a six-hour window can fix. Putting B in the window buys nothing: there is no patch to install, so the outcome would be downtime for a clinical system with zero reduction in vulnerability. The correct permanent fix for B is architectural - segmenting the device VLAN and restricting console reachability - which is a project, not a maintenance window.
So the reasoning to give the CISO is: A is remediable now, B is not remediable ever. Remediate what you can fix, mitigate what you cannot, and put B on a project track with a named owner and date.
One caution before the window: do not treat "WAF virtual patch enabled" as proven protection. Test the exploit against a staging copy behind the same rule set, confirm the rule version and that it is in blocking (not detection) mode, and confirm there is no path that bypasses the WAF entirely - a legacy load-balancer VIP, a partner VPN, or a direct-to-origin DNS record.
2. For the finding you did not remediate, propose compensating controls and state what each control actually buys you.
Read the worked answer
Compensating controls do not shrink the vulnerability. They shrink the probability it is reached and the time you have to react. Say that explicitly so nobody records "mitigated" in the risk register.
- Segment the device VLAN / ACL the console to a jump host. Buys the most: removes reachability from the flat 400-device broadcast domain and from any compromised user workstation. This is the control that matters.
- Privileged access workstation + MFA for console admin. Buys a reduction in the value of a stolen credential, which is the only precondition the exploit needs.
- Disable unused services on the console; restrict management to specific admin subnets. Buys a smaller attack surface without touching the firmware.
- IDS signatures / NetFlow baselines for the console protocol and unexpected admin logins. Buys detection - you cannot prevent, so you must know quickly. Alert on admin logins outside the change calendar.
- Formal, signed risk acceptance from clinical leadership with a review date. Buys governance: converts an undocumented exposure into a tracked, owned one.
Rank them: segmentation is the control; the rest are depth. A control set that does not reduce reachability here is decoration.
3. Name the one unknown that could flip your decision, and how you would close it before the change window.
Read the worked answer
The unknown is the authentication bar for Finding B. The 7.2 rests on "requires valid domain credentials" - but that phrase hides a wide range. If any authenticated domain user can hit the console, then a single phished marketing account becomes a path to a medical device, and B's likelihood jumps to roughly A's. In that case the window should be spent isolating the device VLAN instead of patching JBoss, because there is no patch for B and none is coming.
Close it with three concrete checks:
- Read the vendor's authentication documentation and test in a lab: does the console accept a plain domain user, or only a specific admin group?
- Pull the console's own auth logs for 30 days - who actually logs in, from where, with what account type?
- Confirm with the firewall team whether anything outside the device VLAN can currently reach the console port.
A second unknown worth closing: is JBoss genuinely reachable from the internet, or only via the WAF? Check external attack-surface data and try to reach the origin IP directly. If there is a bypass path, the virtual patch is fiction and A's priority rises further.
Either answer changes where you spend six hours, so close both before the change window opens, not during it.