Windows XP HMIs Against an SL-T 2 Target
A power generation site has 18 HMIs running Windows XP SP3 that monitor and control boiler feedwater. The vendor states no patch is available and no upgrade is funded until 2027. The HMIs sit on a flat plant network with business users and the corporate domain. A recent vulnerability scan found MS17-010 on all 18 and default local administrator credentials on 12. The site targets IEC 62443 SL-T 2 for the control zone. Production can tolerate only a four-hour monthly maintenance window. The CISO wants a risk decision documented before the next audit. The plant has a firewall, a SIEM, and spare managed switches, but no application whitelisting product. Operators use the HMIs 24/7 and cannot log out between shifts.
1. How would you determine whether the residual risk is tolerable against SL-T 2? What evidence would you require?
Read the worked answer
Compare SL-A with SL-T 2. The flat network, default local admin, and unpatched MS17-010 mean the zone likely does not achieve SL 2, because a simple attacker could move from business to HMIs. Evidence: firewall rule review, scan results, account audit, and proof that compensating controls work. Use a risk matrix: likelihood high, impact high because boiler feedwater control is involved. Tolerability is not just a scan result; it requires asset owner and CISO review. If residual risk remains above the site's criteria, it is not tolerable without time-bound acceptance and remediation funding.
2. What compensating controls can you implement with the existing firewall, SIEM, and switches, given the four-hour monthly window?
Read the worked answer
With existing tools: segment the 18 HMIs into a control zone; deny all business-to-HMI traffic except approved historian or analytics via a jump host; block SMB 445, RDP 3389, and remote admin from business; change default local admin passwords and use unique accounts; disable SMBv1 where possible; use switch ACLs and port security; collect XP event logs into the SIEM and alert on MS17-010 exploit indicators. Use Software Restriction Policies on XP as a limited whitelist. Apply changes in the four-hour window with a tested rollback. These reduce but do not eliminate risk.
3. What would you document for the risk acceptance, and who should sign it?
Read the worked answer
Document the asset owner, risk description, SL-T, SL-A gap, compensating controls, test evidence, residual likelihood and impact, acceptance period, review date, and conditions such as upgrade funding by 2027. The asset owner, typically the plant manager, and the CISO should sign; a security risk committee may need to accept if the risk is above tolerance. Include a remediation plan and expiry; do not make the acceptance permanent. Keep audit evidence of the firewall rules, account changes, and monitoring.