Plant Floor

You are helping me build a fictional training case for an ethical hacking class. Everything must be invented. Do not output exploit code, attack commands, working scripts, real credentials, real product firmware, or real malware. The client is 'Cedar Hollow Water Authority', a fictional municipal water utility. Its smart-metering and treatment-plant project is called 'AquaLink'. The reviewers are 'Ironvale OT Security', a fictional industrial security firm. Use only .example domains and private (RFC 1918) IP addresses. No real companies, people, or live targets.

Create an IoT and OT security review case file with four documents:

Document A, Junior Reviewer Notes: confident first-person notes claiming (1) the plant network is fully segmented, so the IT network cannot reach the controllers; (2) all MQTT traffic from the smart water meters is encrypted and authenticated; (3) the meter firmware is clean, with no hardcoded credentials; (4) the vendor remote access path is secure because it uses a VPN.

Document B, Evidence Appendix with four parts:
 B1, Asset inventory table (12 rows): include meters, a gateway, an MQTT broker, a historian, an engineering workstation (EWS-02), an HMI, two PLCs (PLC-CHLOR-1 for chlorine dosing and PLC-PUMP-2), and a vendor jump host. Give each a hostname, IP, Purdue level, and firmware version. EWS-02 has two network cards: 10.20.5.14 (corporate IT VLAN) and 192.168.10.14 (control VLAN).
 B2, Firewall and protocol summary (table, not configs): IT-to-OT DMZ rules look correct; one rule allows TCP 502 (Modbus) from the 192.168.10.0/24 control VLAN to both PLCs with no source restriction to the HMI; the MQTT broker mqtt.aqualink.example listens on TCP 8883 with TLS AND on TCP 1883 with anonymous access enabled, and 40 percent of meters (older firmware 2.3) publish to 1883.
 B3, Firmware analysis notes for meter firmware 2.3 and 3.1: version 3.1 is signed; version 2.3 is unsigned, contains a shell account 'svc_diag' with the same password hash on every unit, and a UART debug header is noted as unpopulated but present on the board.
 B4, Remote access log excerpt (described as a table): the vendor 'HydroTek Controls' uses a single shared VPN account 'hydrotek' with no MFA, the tunnel is always on, and the last login was at 02:14 from an unexpected country.

Document C, Draft Risk Report: a one-page report for the Water Authority's operations director with overall risk (Low), a summary that trusts Document A, and remediation that says only: 'Change default passwords on the HMI and run an annual vulnerability scan across the plant network, including the PLCs.'

IMPORTANT: do not label, flag, or hint at these anywhere, and write them as normal details:
- Document A says segmentation is complete; B1 shows the dual-homed EWS-02 bridging IT and control VLANs.
- Document A says all MQTT is encrypted; B2 shows anonymous cleartext 1883 still used by older meters.
- Document A says firmware is clean; B3 shows the unsigned 2.3 image with a shared hardcoded svc_diag account.
- Document A says vendor access is secure; B4 shows a shared, always-on account with no MFA and an odd 02:14 login.
- Document C's remediation includes active vulnerability scanning of live PLCs, which can disrupt a running process.
- Everything else should read as a plausible (but flawed) junior write-up.

Act as a senior OT security consultant at Ironvale OT Security. Using only Documents A, B, and C, write a client-ready IoT and OT security review for the Cedar Hollow Water Authority operations director with these sections:
1) Title and overall risk rating.
2) Systems in scope, organized by Purdue Model level.
3) Findings, each with: plain-language description, evidence source (document and part), and the matching OWASP IoT Top 10 or MITRE ATT&CK for ICS reference.
4) Safety and public-health impact in two sentences (this is a drinking-water utility).
5) Remediation recommendations (network, devices and firmware, protocols, remote access, and testing approach).

Then rate your confidence in the overall review (High, Medium, or Low) and explain why. No attack commands or exploit steps.

Revise the AquaLink security review:
1) Segmentation is not complete. B1 shows [which host has which two addresses]. Explain why a dual-homed engineering workstation matters in the Purdue Model.
2) Not all MQTT traffic is protected. B2 shows [which port, what access setting, and what share of meters use it]. Map this to OWASP IoT I2 and I7.
3) The firmware is not clean. B3 shows [which version, what is missing, and what account exists]. Map this to I1, I4, and I5, and mention the UART header.
4) Vendor access is not secure. B4 shows [account type, MFA status, tunnel status, and the suspicious login]. Explain why this needs an investigation, not just a fix.
5) Replace the remediation: put EWS-02 behind the IT/OT DMZ with a single managed path; disable port 1883 and move every meter to 8883 with client certificates and topic ACLs; retire firmware 2.3, require signed updates, and remove svc_diag; give each vendor engineer a named account with MFA and on-demand, recorded sessions; restrict Modbus 502 to the HMI only. Explain why active scanning of live PLCs is unsafe and what to use instead (passive monitoring, scans in a test bed or maintenance window).
6) Update the overall risk rating and confidence, and explain what changed.