NCCSA study materials
NCCSA study resources

The Unpatchable PACS Host

NCCSA · Put your knowledge to work in context.

All case studies

The Unpatchable PACS Host

A 210-bed regional hospital runs its PACS on a Windows Server 2012 R2 host that is years past end of support. The imaging vendor's contract states the application is certified only on that OS build, and an upgrade is scheduled 14 months out. Nine MRI, CT and ultrasound modalities push studies to the server over DICOM (TCP 104 and 11112) from the same flat VLAN that carries 60 clinical workstations and the radiology reception desk. Last week's authenticated scan returned three critical findings on the server and rated the exposure high specifically because any host on that VLAN can reach the service. Radiology estimates 40,000 dollars per hour of downtime, so an immediate rebuild is off the table, and the vendor will not support a patched build. The CISO has asked for a decision memo: isolate, mitigate in place, or accept, with reasoning the audit committee can follow.

1. Which security principles justify isolating the PACS host rather than insisting on a patch, and what must the isolation actually accomplish?

Read the worked answer

The right frame is not patch versus accept, but reducing reachability to the vulnerable service. Three principles do the work here:

  • Least functionality: the host only needs DICOM inbound from nine known modality addresses and management access from two jump hosts. SMB from workstations, RDP from the reception desk and all internet paths should be denied by default.
  • Defense in depth: host firewall, VLAN ACLs and EDR each reduce the chance of success, but depth is not itself the control. If any host on the flat VLAN can still reach TCP 104, the scan finding remains true no matter how many layers exist.
  • Fail-safe defaults and separation of duties: deny all, then permit explicitly; imaging staff should not administer the host, and vendor access should be brokered and recorded rather than standing.

The isolation has to be verifiable, not asserted: a re-scan from a workstation showing the DICOM port unreachable, plus an alert on any new source address touching it. Residual risk is what remains after that evidence exists, not before.

2. The CIO proposes signing a 14-month risk acceptance for the host. What must be true before that signature is defensible?

Read the worked answer

A defensible acceptance is about residual risk and must be owned by someone with the authority to carry it. Before signature:

  1. Compensating controls are live and tested - segmentation verified by scan, brokered access with MFA, EDR in blocking mode, and a detection rule for DICOM traffic from unexpected sources.
  2. Residual risk is quantified in business terms: 40,000 dollars per hour, patient-safety impact if imaging halts, and exposure under the HIPAA Security Rule risk-analysis and breach-notification duties.
  3. A named risk owner above the CISO, with the audit committee informed rather than surprised.
  4. An expiry no later than the vendor upgrade, a review trigger if the CVE appears in KEV or a public proof-of-concept lands, and a 90-day progress checkpoint.
  5. A contingency plan: what happens on detection, who can authorise taking imaging offline, and how studies are rerouted.

The vendor's refusal to support a patched build does not transfer the hospital's obligation to patients; it only shifts who pays for the risk.

3. The vendor asks for a domain account with local administrator rights on the PACS server for convenience. How do you respond, and why?

Read the worked answer

Refuse as stated, but refuse with a workable alternative so it does not become a schedule fight.

  • Local, not domain: the account should exist only on that server. A vendor compromise of a Domain Admin account becomes a forest compromise, which converts a contained imaging problem into a hospital-wide one.
  • Time-boxed via the PAM appliance: checked out to a named engineer against a specific ticket, for a defined window, with session recording and automatic expiry. Access should not outlive the task.
  • Rotated after each session, with the vendor contractually bound to name its engineers and notify of breaches.
  • Change-controlled: every modification needs a change record, and the imaging team reviews it before the session closes.

The principle is least privilege with accountability - exactly the access needed, exactly as long as needed, and a reconstructable record of what was done. The convenience argument is real but cheap to satisfy: a jump host with session recording is usually faster for the vendor than hunting for credentials.