Board Risk Acceptance for an Unpatchable HMI
A midstream pipeline operator runs 38 HMI stations on Windows 10 LTSC 2019. The OEM states the HMI stack is validated only at its current patch level and will not support further patching for 14 months. A CVSS 9.8 vulnerability in the HMI web server is remotely exploitable if an attacker reaches the HMI network. The control network has a firewall but no IDS; vendor remote access uses a VPN with shared credentials. The board's risk appetite says no risk acceptance above $5M expected loss without board approval. The risk team calculates annualized loss expectancy of $3.2M, but a worst-case event could reach $40M plus regulatory penalty. The insurer's renewal questionnaire asks whether all critical vulnerabilities are remediated within 30 days. The audit committee requests a memo. The CISO proposes to 'accept the risk' and move on. The regulator has adopted IEC 62443-3-3 as guidance, not a mandatory rule.
1. Is the CISO's proposed risk acceptance valid? Who must approve it, and on what basis?
Read the worked answer
No. The CISO can recommend acceptance, but cannot 'accept and move on' alone.
Authority: the risk owner is the pipeline operations executive who owns the affected process, not the CISO. The board's $5M threshold is stated as expected loss. The $3.2M ALE is below that threshold, so board approval is not automatically triggered by the ALE number. However, the worst-case $40M, regulatory penalty, and insurer implications make this a board-visible risk. I would escalate it anyway, with a clear note that the threshold is being interpreted, not ignored.
Validity: acceptance must be time-bound and conditional. 'Move on' is not acceptance; it is avoidance of documentation. The memo should state the vulnerability, affected assets, exploit precondition, existing controls, planned controls, residual risk, acceptance period, review date, and triggers that reopen the decision - for example, public exploit code, a vendor patch, or an attempted intrusion.
The insurer question cannot be answered 'yes.' The correct answer is an exception with compensating controls and evidence.
2. What treatment plan and documentation would you put in the audit committee memo?
Read the worked answer
The memo should be short, evidence-based, and explicit about residual risk.
Treatment plan:
- Segment the 38 HMIs into an OT zone with a conduit firewall; allow only required HMI-to-controller and HMI-to-historian traffic.
- Add IDS/OT monitoring on the conduit and alert on exploit attempts against the HMI web service.
- Replace shared VPN credentials with individual accounts and MFA; log and escort vendor sessions.
- Apply application allowlisting and disable unnecessary HMI web services where the OEM permits.
- Restrict HMI internet access and remove local admin rights.
- Require a vendor support statement and a patch-validation date.
Documentation: risk register entry with owner, ALE, worst-case, controls, residual risk, acceptance expiry (90 days), and review triggers. Attach the firewall rule export, IDS alert test, MFA enrollment evidence, and vendor letter.
Decision requested: approve a 90-day conditional risk acceptance, not a 14-month blanket acceptance. The board is approving a monitored exception, not denying the vulnerability.
3. How do you answer the insurer and the regulator without misrepresenting the patch status?
Read the worked answer
Answer truthfully and specifically. Misrepresenting patch status is both an insurance and a governance failure.
To the insurer: state that the vulnerability is not remediated because the OEM will not support a patch for 14 months. Describe the compensating controls - segmentation, IDS, MFA, vendor access control, allowlisting - and provide the exception document and review date. Do not answer 'yes' to a question that asks whether all critical vulnerabilities are remediated in 30 days. If the questionnaire has no exception field, attach a narrative and ask for written acknowledgment.
To the regulator: if IEC 62443-3-3 is guidance, provide a gap assessment showing where the current architecture does not meet the guidance, the compensating controls in place, and the remediation timeline. Do not claim compliance. Do not call the vulnerability 'accepted' without showing the risk owner and conditions.
Internal: brief legal and internal audit before submission. The goal is a defensible record that the organization knew, acted, and time-boxed the exception - not a clean questionnaire.