Learn Ethical Hacking (#86) - Critical Infrastructure Security - Hospitals, Power Grids, Water

avatar

Learn Ethical Hacking (#86) - Critical Infrastructure Security - Hospitals, Power Grids, Water

leh-banner.jpg

What will I learn

  • Why critical infrastructure is different -- when a cyber attack can cause physical harm or death;
  • Operational Technology (OT) vs Information Technology (IT) -- the convergence that creates new risks;
  • Healthcare security -- medical device vulnerabilities, DICOM/HL7 protocols, and ransomware in hospitals;
  • Energy grid security -- SCADA systems, smart grid attacks, and the Ukraine power grid incidents;
  • Water treatment security -- the Oldsmar incident and the fragility of municipal infrastructure;
  • Transportation security -- aviation, rail, maritime, and autonomous vehicle attack surfaces;
  • ICS/SCADA protocols -- Modbus, DNP3, OPC UA, and why most have no authentication;
  • Defense: the Purdue Model, ICS-specific monitoring, safety instrumented systems, and air gaps that actually work.

Requirements

  • A working modern computer running macOS, Windows or Ubuntu;
  • Understanding of IoT and embedded security from Episode 57;
  • Understanding of network architecture from Episode 73;
  • The ambition to learn ethical hacking and security research.

Difficulty

  • Advanced

Curriculum (of the Learn Ethical Hacking Series):

Learn Ethical Hacking (#86) - Critical Infrastructure Security - Hospitals, Power Grids, Water

Solutions to Episode 85 Exercises

Exercise 1: Lab evaluation against "What Still Works" (abbreviated).

Control                  | Implemented? | Gap
Phishing-resistant MFA   | NO           | No FIDO2 keys in lab. Impact: HIGH.
Zero Trust Architecture  | PARTIAL      | Tailscale for some apps, VPN for rest.
Network Segmentation     | YES          | VLANs deployed (ep73 exercise).
Least Privilege          | PARTIAL      | AD tiering done, IAM not scoped.
Process Controls         | NO           | No code word / callback procedures.
Behavioral Analytics     | PARTIAL      | Wazuh UEBA basic, no advanced UEBA.
Logging / Monitoring     | YES          | SIEM + Sysmon + CloudTrail active.

Top 3 implemented: FIDO2 MFA (simulated with YubiKey), process
controls (code word for lab "financial" transactions), least
privilege IAM (scoped PassRole to specific roles).

Re-test: ep83 attack chain broke at Phase 2 (MFA blocked VPN
login with stolen password). ep84 broke at Phase 3 (scoped
PassRole prevented admin role assumption).

The re-test results are the most telling part. In episode 83, the attack chain succeeded in 12.5 hours -- from zero knowledge to domain admin -- because not a single defensive control stopped it. After implementing just three of the seven controls from the "What Still Works" list, the SAME attack chain breaks at Phase 2 for the on-premise scenario and Phase 3 for the cloud scenario. That is a dramatic improvement from a relatively small investment. The FIDO2 MFA alone killed the credential spray path entirely (no password, however strong, matters if the attacker also needs a hardware key they do not have). The scoped PassRole prevented the IAM privilege escalation that was the linchpin of the cloud breach in episode 84. Three controls. Two kill chains broken. This is why prioritization matters more than comprehensiveness -- deploy the controls that break the MOST attack paths first, then fill in the gaps.

Exercise 2: Deepfake-resistant communication protocol (abbreviated).

Code word: rotated monthly, distributed in-person at team meetings.
Current word known only to authorized signers + CISO.

Callback: ANY financial request -> hang up -> call back on
  number from internal directory (never the number provided).

Multi-channel matrix:
  Request via email -> verify via phone (known number)
  Request via phone -> verify via Slack DM (verify user online status)
  Request via video -> verify via phone + code word

Escalation: >$50K requires two signers. >$250K requires in-person.
If employee falls for deepfake: immediate account freeze, IR
activation, review all transactions from last 48 hours.

The multi-channel matrix is the centerpiece of this protocol and the part that most organizations get wrong. The principle is simple: never confirm a request through the same channel it arrived on. But the implementation requires thinking about which channels the attacker is LIKELY to control simultaneously. An attacker who has compromised someone's email probably does NOT have access to their phone or Slack. An attacker who can deepfake a video call probably cannot ALSO deepfake a phone call on a different number while maintaining the first call. By forcing verification across independant channels, you exploit the attacker's inability to maintain multiple impersonations simultaneously. The $50K/$250K escalation thresholds are somewhat arbitrary -- the actual numbers should reflect your organization's risk appetite and transaction volume. The 48-hour review window after a successful deepfake is critical because the attacker may have initiated multiple transactions, not just the one that was discovered.

Exercise 3: Honeypot deployment (abbreviated).

Deployed:
  1. Canary token in PDF on company website "contact" page
     Result: 3 accesses in 7 days, all from known web crawlers
  2. honeypot.mydomain.com (returns fake login page)
     Result: 12 access attempts, 8 from scanning tools (Shodan, Censys),
     4 from unknown IPs (potential targeted recon)
  3. Decoy .env on test GitHub repo with canary AWS key
     Result: 2 attempts to use the key within 4 hours of commit
     (automated credential scanners monitoring GitHub commits)

Learning: GitHub credential scanning is FAST. Leaked credentials
are attempted within hours. Real attackers are scanning continuously.

The GitHub credential scanning result is the one that should make you sit up. Four hours from commit to attempted use. That is not a human browsing repositories -- that is automated scanning infrastructure that monitors the GitHub firehose of public commits in near-real-time, extracts anything that looks like a credential (regex patterns for AWS keys, API tokens, database connection strings), and immediately attempts to use them. Tools like truffleHog and GitLeaks do this from the defender's side, but the attackers have their own equivalents running 24/7 against the entire public GitHub corpus. The implication for real operations is clear: if a developer accidentally commits a real credential to a public repo (and this happens constantly -- episode 45 covered supply chain attacks where leaked credentials were the initial access vector), the window to rotate that credential before it is exploited is measured in HOURS, not days. Your incident response playbook for leaked credentials needs to assume the credential is already compromised the moment it hits a public repository.

Episode 85 closed the loop on AI-powered attacks and defenses. We built an AI defense stack that prioritizes behavioral detection over signature matching, deployed FIDO2 MFA as the single most impactful control against AI-enhanced phishing, and established process controls (code words, multi-channel verification) that defeat deepfakes regardless of how convincing the AI becomes. At the end of that episode, I made a deliberate statement: the defenses we have built throughout this series apply doubly in environments where the consequences of failure are measured not in dollars but in human lives.

Today we enter those environments. Here we go.

When Hacking Kills

Everything in this series until now has been about data -- stealing it, protecting it, detecting when it moves. Critical infrastructure changes the equation entirely. When you hack a hospital, patients may die. When you hack a power grid, cities go dark. When you hack a water treatment plant, people drink poison. The CIA triad that we learned in the earliest episodes (Confidentiality, Integrity, Availability) gets inverted: in critical infrastructure, Availability comes first, because downtime is not an inconvenience -- it is a safety hazard.

This is not hypothetical. In 2020, a ransomware attack on Dusseldorf University Hospital in Germany forced the emergency department to close, diverting ambulances to hospitals farther away. A patient requiring urgent care was rerouted to a hospital 30 km away and died during transport. In 2021, an attacker accessed the Oldsmar water treatment plant in Florida and attempted to increase sodium hydroxide (lye) levels to 100x the safe amount -- a concentration that would have poisoned the water supply for 15,000 residents. An alert operator watching the SCADA screen saw the mouse cursor moving on its own and reversed the change in time.

I argue that critical infrastructure security is where everything we have covered in 85 episodes converges into its most consequential form. The same attack techniques apply (phishing for initial access, lateral movement through flat networks, exploiting unpatched systems), but the IMPACT is fundamentally different. A data breach costs money. A hospital ransomware attack costs lives. The technical skills are the same. The stakes are not.

IT vs OT -- Two Worlds Colliding

Information Technology (IT):
  Priority: Confidentiality > Integrity > Availability (CIA)
  Lifecycle: 3-5 years (servers, software)
  Patching: monthly (Patch Tuesday)
  Downtime: tolerable (maintenance windows)
  Environment: air-conditioned data centers
  Protocols: TCP/IP, HTTP, SMB, SQL

Operational Technology (OT):
  Priority: Availability > Integrity > Confidentiality (AIC)
  Lifecycle: 15-30 YEARS (PLCs, RTUs, SCADA)
  Patching: rarely or never (fear of breaking processes)
  Downtime: UNACCEPTABLE (24/7 operations)
  Environment: factory floors, substations, treatment plants
  Protocols: Modbus, DNP3, BACnet, PROFINET

The collision: IT and OT networks were historically separate.
The "air gap" protected OT from IT threats. Then someone
connected the SCADA system to the corporate network for
remote monitoring. Then someone connected the corporate
network to the internet. The air gap died, and IT threats
reached OT systems that were never designed to resist them.

The lifecycle difference is the one that creates the most security debt. When an IT server reaches end-of-life after 5 years, you retire it and deploy a replacement with a current operating system and current patches. When a PLC (Programmable Logic Controller) controlling a chemical process reaches year 15 of its expected 30-year lifespan, you do NOT replace it -- because replacing it means shutting down the process, potentially for days, while the new PLC is installed, configured, tested, and validated. And the FDA (for pharmaceutical processes) or NRC (for nuclear) may require recertification of the entire process after a control system change. So the PLC keeps running. On firmware from 2009. With vulnerabilities that will never be patched. Connected (because someone in management wanted remote dashboards) to a network that is also connected to the internet.

Having said that, the convergence of IT and OT is not entirely the result of carelessness. There are legitimate business reasons for connecting OT systems to IT networks: remote monitoring reduces the need for on-site operators, predictive maintenance based on sensor data reduces downtime, and centralized management of distributed sites (a utility company might have hundreds of substations) is operationally necessary. The problem is not the convergence itself -- it is that the convergence happened WITHOUT the security controls that the new threat model demands. You connected a 1979 protocol (Modbus, no authentication, no encryption) to a network that is reachable from the internet, and then wondered why someone accessed your SCADA system from a coffee shop in another country ;-)

Healthcare Security

The healthcare attack surface:

Medical devices:
  - MRI machines running Windows 7 (cannot be patched -- FDA approved
    configuration must not be modified)
  - Infusion pumps with network connectivity (dose can be modified remotely)
  - Pacemakers with Bluetooth (CVE-2017-12712: remote cardiac reprogramming)
  - DICOM servers (medical imaging) often exposed with no authentication

Protocols:
  - HL7 (Health Level Seven): hospital system integration protocol.
    Typically unencrypted, unauthenticated plaintext over TCP port 2575.
    Contains: patient names, diagnoses, medications, lab results.
    An attacker on the hospital network can read EVERY patient record
    by connecting to the HL7 interface.

  - DICOM (Digital Imaging): medical image transfer protocol.
    Port 104, often unauthenticated.
    Shodan query: "DICOM" -- thousands of exposed PACS servers globally.

Ransomware in healthcare:
  WannaCry (2017): 80+ NHS organizations hit. Surgeries cancelled.
  UHS (2020): 400 hospitals hit by Ryuk. Manual operations for weeks.
  Irish HSE (2021): entire national health service encrypted. Cost: $600M+.

Why healthcare is targeted: maximum pressure to pay.
  Hospitals cannot wait months for recovery. Patients need care NOW.
  Ransomware operators know this and charge accordingly.

The MRI on Windows 7 example is the one that makes IT professionals lose sleep. The machine cost $2-3 million. It was FDA-approved as a complete system, including the operating system. If the hospital updates the OS, the FDA approval is potentially invalidated, meaning the hospital cannot legally use the machine for patient care until it is recertified -- a process that takes months and costs hundreds of thousands of dollars. So the hospital has a choice: run an unpatched, unsupported operating system on a device that is connected to the hospital network (because it needs to send images to the PACS server for radiologists to review), or take a $3 million machine offline for months. No hospital administrator makes the second choice. And so Windows 7 MRI machines sit on hospital networks in 2026, reachable by any attacker who gets past the perimeter (which, as we demonstrated in episodes 83-84, is often trivial).

The HL7 protocol situation is equally horrifying from a security perspective. HL7 v2 (the most widely deployed version) transmits patient data -- names, social security numbers, diagnoses, medications, lab results -- in plaintext over TCP. No authentication, no encryption, no access control at the protocol level. If you can reach port 2575 on the hospital's integration engine (and most hospital networks are flat, so internal access means access to everything), you can read every patient record that flows through the system. Episode 55 covered GDPR and data protection -- healthcare data is the most sensitive category under both GDPR (Article 9, "special categories") and HIPAA, and it is being transmitted across hospital networks in cleartext using a protocol designed in the 1980s.

Energy Grid Security

The grid attack surface:

Generation: power plants (nuclear, gas, coal, renewable)
  PLCs control: turbine speed, cooling systems, fuel flow
  Protocols: Modbus TCP, OPC UA, IEC 61850

Transmission: high-voltage lines, substations
  RTUs (Remote Terminal Units) control: circuit breakers, transformers
  Protocols: DNP3, IEC 60870-5-104

Distribution: local transformers, smart meters
  Smart grid: bidirectional communication with millions of meters
  Protocols: DLMS/COSEM, ZigBee (smart home integration)

Real attacks:
  Ukraine 2015: Russian attackers (Sandworm) compromised 3 power
  distribution companies. Used BlackEnergy malware to access SCADA.
  Opened circuit breakers remotely. 230,000 customers lost power.
  Duration: 1-6 hours. First confirmed cyber attack on a power grid.

  Ukraine 2016: Industroyer/CrashOverride malware. Purpose-built
  to attack electrical grid protocols (IEC 61850, IEC 60870-5-104).
  Automated attack -- no human operator needed after deployment.
  Temporarily blacked out part of Kyiv.

  These attacks demonstrated: nation-states CAN and WILL use
  cyber weapons to attack civilian infrastructure during conflict.

The progression from Ukraine 2015 to Ukraine 2016 is what should alarm every infrastructure security professional. The 2015 attack required human operators at every step: attackers logged into SCADA workstations via stolen VPN credentials (familiar from episode 83), navigated the HMI (Human-Machine Interface) software manually, and opened circuit breakers one by one. It was a cyber attack that looked like a human sitting at the control desk. The 2016 attack was fundamentally different: Industroyer (also called CrashOverride) was purpose-built malware that understood electrical grid protocols natively. It could speak IEC 61850 and IEC 60870-5-104 -- the actual communication protocols used by substations -- and it could operate circuit breakers autonomously, without a human operator guiding it. The jump from "human using cyber tools to manipulate infrastructure" to "autonomous malware that understands infrastucture protocols" is the same jump we discussed in episode 85 regarding AI-powered attacks: the attack becomes faster, more scalable, and less dependent on individual attacker skill.

The smart grid expansion adds millions of potential entry points. Every smart meter is a network-connected device (episode 57 covered IoT security) that communicates with the utility's infrastructure. Compromising a single meter is low-impact. Compromising the meter management system that controls millions of meters simultaneously -- that is a grid-level attack. The ZigBee protocol used for smart home integration has known vulnerabilities (episode 68 covered wireless exploitation), and a compromised smart home hub could potentially be used as a pivot point into the utility's metering infrastructure if the network boundaries are not properly enforced.

Water Treatment Security

# The Oldsmar incident (February 2021):

# Attacker accessed the water treatment SCADA system via TeamViewer
# (remote desktop software installed on an operator workstation)
# Changed sodium hydroxide (NaOH) setpoint from 100 ppm to 11,100 ppm
# (100x increase -- lethal concentrations)

# An operator watching the screen SAW the mouse moving on its own
# and the setpoint changing. Immediately reversed the change.

# What went wrong:
# - TeamViewer on a SCADA workstation (remote access to OT!)
# - Shared password among operators
# - No network segmentation between IT and OT
# - No alerting on setpoint changes outside normal range
# - Windows 7 on the SCADA workstation (out of support)

# What saved them: a human operator watching the screen.
# Without that operator, the poison would have entered the water supply.

The Oldsmar incident is a masterclass in how NOT to secure critical infrastructure, and every single failure maps directly to concepts we covered earlier in this series. TeamViewer on a SCADA workstation -- this is remote access to OT without any of the controls from episode 81 (zero trust architecture). No MFA, no conditional access, no jump server. Just a shared password that multiple operators knew. No network segmentation -- the SCADA workstation was on the same network as the corporate IT systems, meaning any compromise of the IT network (the credential spray from episode 83, for example) would also reach the SCADA system. No setpoint alerting -- the control system had no configured alert for "sodium hydroxide level changed by 10,000%", which is the OT equivalent of not having a SIEM rule for iam:CreateUser with AdministratorAccess (episode 84).

The most chilling detail is what saved Oldsmar: a single human operator who happened to be watching the screen at that exact moment. If that operator had been on break, if they had been looking at a different terminal, if the attack had happened at 3 AM when staffing was minimal -- 15,000 people would have had lye in their drinking water. The defense against a cyber attack on critical infrastructure came down to one person's eyeballs at the right time. That is not a security control. That is luck.

ICS Protocols -- No Authentication by Design

Modbus (most common ICS protocol):
  Created: 1979. Designed for serial communication between PLCs.
  Authentication: NONE. Anyone who can reach port 502 can read/write.
  Encryption: NONE. All data in plaintext.

  # Read 10 holding registers from a PLC (no auth required)
  modbus-cli read 192.168.1.100 0 10

  # WRITE to a PLC register (no auth required!)
  modbus-cli write 192.168.1.100 0 12345
  # You just changed a physical process parameter.
  # This could open a valve, change a temperature setpoint,
  # or disable a safety system.

DNP3 (Distributed Network Protocol):
  Used in: power grid, water treatment
  Authentication: optional (Secure Authentication v5), rarely enabled
  Designed for: reliable SCADA communication over unreliable links

BACnet (Building Automation and Control):
  Used in: HVAC, lighting, access control in buildings
  Authentication: added in 2018 (BACnet/SC), most installations
  predate this and have no authentication

OPC UA (Open Platform Communications Unified Architecture):
  The modern replacement. HAS authentication and encryption.
  But adoption is slow -- legacy Modbus and DNP3 installations
  will exist for decades.

I want to be absolutely clear about the Modbus situation because it is difficult to overstate how bad it is. Any device that can send TCP packets to port 502 can read from and write to any register on a Modbus PLC. There is no username, no password, no token, no certificate, no handshake, no challenge-response. You connect, you send a Modbus function code (0x03 to read, 0x06 to write), and the PLC obeys. This is not a vulnerabilty in the implementation -- it is how the protocol was designed in 1979. It was designed for serial connections between devices in the same physical cabinet, where physical access control (a locked cabinet door) was the security mechanism. Nobody in 1979 imagined that these PLCs would one day be reachable over TCP/IP from the internet.

The fact that OPC UA exists (with proper authentication and encryption) and is being adopted by new installations does not solve the problem for existing infrastructure. The water treatment plant built in 1995 has Modbus PLCs that will run until 2025 or 2035. The power substation built in 2000 has DNP3 RTUs with a 25-year lifecycle. These devices cannot be upgraded to OPC UA -- they do not have the processing power, the memory, or the firmware update mechanisms. They will be replaced when they physically fail, and until then, the ONLY security mechanism is network isolation: making sure that nothing except the authorized SCADA server can reach port 502 or port 20000 on these devices. Network segmentation (episode 73) is not a nice-to-have in ICS environments -- it is literally the only security control that works for protocols with no authentication.

The Purdue Model -- ICS Network Architecture

Level 5: Enterprise network (email, web, ERP)
         |
    [FIREWALL + DMZ]
         |
Level 4: IT/OT boundary (data historian, business intelligence)
         |
    [INDUSTRIAL FIREWALL]
         |
Level 3: Operations management (SCADA server, HMI)
         |
    [NETWORK SEGREGATION]
         |
Level 2: Control systems (PLCs, RTUs, DCS)
         |
Level 1: Intelligent devices (sensors, actuators, drives)
         |
Level 0: Physical process (valves, motors, pumps, generators)

Rules:
  - Traffic flows DOWN the levels (commands) and UP (data)
  - Level 5 should NEVER directly reach Level 2 or below
  - The DMZ at Level 3.5 provides monitored data access
  - Each boundary has: firewall, IDS, logging
  - Remote access: ONLY through a jump server in the DMZ

Reality: most organizations have flat IT/OT networks.
  The SCADA server is on the same VLAN as the receptionist's PC.
  The PLC is reachable from the guest WiFi.
  The Purdue Model is aspirational for many organizations.

The Purdue Model is to ICS security what the zero trust architecture (episode 81) is to enterprise security: the reference model that everyone agrees is correct and almost nobody implements fully. The core principle is defense in depth through network segmentation -- each level is isolated from the others, with firewalls and monitoring at every boundary. An attacker who compromises the enterprise network (Level 5) would need to break through TWO firewall boundaries (the enterprise DMZ and the industrial DMZ) before reaching the SCADA server at Level 3, and ANOTHER boundary before reaching the PLCs at Level 2. Each boundary is a detection opportunity and a containment point.

The "Reality" note at the bottom is not an exaggeration. A 2023 SANS ICS/OT survey found that over 40% of ICS environments had direct connectivity between their enterprise network and the OT control network -- no DMZ, no industrial firewall, no segmentation. The SCADA server that controls physical processes shares a network with the receptionist's PC, the marketing team's laptops, and the guest WiFi access point. In that configuration, the credential spray from episode 83 (which got us onto the corporate network) would also give us direct access to the PLCs that control physical processes. That is the scenario that results in people getting hurt.

Monitoring ICS Networks

Traditional IT security monitoring (the SIEM rules from episode 74, the behavioral analytics from episode 75) does not understand ICS protocols. A SIEM that sees a TCP connection to port 502 does not know whether the Modbus command being sent is "read temperature sensor" (normal) or "write maximum value to chemical dosing pump" (catastrophic). ICS-specific monitoring tools fill this gap:

#!/usr/bin/env python3
"""modbus_baseline_monitor.py -- detect anomalous register changes"""
from datetime import datetime

class ModbusBaselineMonitor:
    def __init__(self):
        self.baselines = {}
        self.alerts = []

    def set_baseline(self, register_addr, normal_min, normal_max, desc):
        """Define normal operating range for a register."""
        self.baselines[register_addr] = {
            'min': normal_min, 'max': normal_max,
            'desc': desc, 'last_value': None,
        }

    def check_value(self, register_addr, value, source_ip):
        """Check a register value against baseline. Alert on anomaly."""
        baseline = self.baselines.get(register_addr)
        if not baseline:
            return None

        alert = None
        if value < baseline['min'] or value > baseline['max']:
            alert = {
                'type': 'out_of_range',
                'register': hex(register_addr),
                'desc': baseline['desc'],
                'value': value,
                'range': f"{baseline['min']}-{baseline['max']}",
                'source_ip': source_ip,
                'time': datetime.utcnow().isoformat(),
                'severity': 'critical',
            }

        if baseline['last_value'] is not None:
            change = abs(value - baseline['last_value'])
            max_change = (baseline['max'] - baseline['min']) * 0.2
            if change > max_change:
                alert = {
                    'type': 'rapid_change',
                    'register': hex(register_addr),
                    'desc': baseline['desc'],
                    'previous': baseline['last_value'],
                    'current': value,
                    'change_pct': round(
                        change / (baseline['max'] - baseline['min']) * 100, 1
                    ),
                    'source_ip': source_ip,
                    'time': datetime.utcnow().isoformat(),
                    'severity': 'high',
                }

        baseline['last_value'] = value
        if alert:
            self.alerts.append(alert)
        return alert

# Water treatment plant monitoring example
monitor = ModbusBaselineMonitor()
monitor.set_baseline(0x0010, 80, 120, 'NaOH concentration (ppm)')
monitor.set_baseline(0x0011, 6.5, 8.5, 'pH level')
monitor.set_baseline(0x0012, 0, 500, 'turbidity (NTU)')
monitor.set_baseline(0x0020, 50, 95, 'chlorine residual (ppm)')

The key concept here is baselining. Unlike IT systems where "normal" is difficult to define (users access different resources at different times), OT systems are remarkably predictable. A water treatment plant's NaOH concentration should always be between 80 and 120 ppm. The pH should always be between 6.5 and 8.5. A change of more than 20% in a single measurement cycle is physically unusual and should trigger an alert. The Oldsmar attacker changed NaOH from 100 to 11,100 ppm -- a 11,000% increase. A baseline monitor with the ranges defined above would have fired a critical alert within one measurement cycle. The operator would not have needed to be watching the screen at that exact moment -- the monitoring system would have paged them.

Commercial ICS monitoring platforms (Dragos, Claroty, Nozomi Networks) do this at scale across thousands of devices and dozens of protocols. They maintain protocol-specific parsers that understand Modbus function codes, DNP3 object groups, and BACnet property identifiers, and they can alert on specific dangerous operations: "someone just sent a Modbus write command to the chemical dosing PLC from an IP address that has never communicated with that PLC before." That level of protocol-aware monitoring is what the Oldsmar plant was missing and what the Purdue Model's monitoring requirements demand.

Defense: Securing Critical Infrastructure

1. Segment IT and OT networks (Purdue Model)
   No direct communication between enterprise and control systems.
   All data exchange through a monitored DMZ.

2. Remove internet access from OT systems
   SCADA workstations do not need email or web browsing.
   Any internet-connected OT system is a target.

3. Eliminate remote access tools on OT workstations
   No TeamViewer, no RDP, no AnyDesk on SCADA systems.
   Remote access ONLY through hardened jump servers with MFA.

4. Monitor OT protocols
   ICS-specific IDS: Claroty, Nozomi Networks, Dragos
   These understand Modbus, DNP3, and BACnet and alert on
   anomalous commands (e.g., setpoint change outside normal range).

5. Safety Instrumented Systems (SIS)
   Independent hardware safety systems that prevent catastrophic
   outcomes regardless of what the control system does.
   SIS should be: physically separate, not network-connected,
   and capable of shutting down the process safely.

6. Patch management for OT (carefully)
   OT patching is different: test patches in a staging environment
   that mirrors production EXACTLY before deploying.
   Some OT systems cannot be patched at all -- compensating
   controls (network isolation, monitoring) are the only option.

7. Incident response planning for OT
   IT incident: restore from backup, rebuild server.
   OT incident: physically dangerous. May require manual override,
   plant shutdown, evacuation. Practice these procedures.

Item 5 -- Safety Instrumented Systems -- is the defense that is unique to critical infrastructure and has no equivalent in IT security. An SIS is a completely independent hardware system that monitors process variables (temperature, pressure, flow rate, chemical concentration) and can shut down the process safely if any variable exceeds safe limits. The critical word is independent: the SIS must be physically separate from the SCADA system, must not be network-connected, and must be able to function even if the entire SCADA system is compromised. If the SCADA system is the brain of the industrial process, the SIS is the circuit breaker that trips regardless of what the brain decides.

In the Oldsmar scenario, a properly configured SIS would have prevented the attack from having any physical impact. The NaOH dosing system would have a hardware interlock that physically cannot dose above a certain concentration, regardless of what the SCADA setpoint says. The attacker could change the setpoint to 11,100 ppm in the software, but the hardware would refuse to open the valve past the safety limit. This is the same principle as the hardware safety limits mentioned in episode 79 (securing AI systems in production): no software control -- including AI, including SCADA, including an attacker with full system access -- should be trusted as the sole safety mechanism for a process that can cause physical harm.

The AI Slop Connection

AI is increasingly embedded in critical infrastructure operations. AI optimizes power grid load balancing, adjusts water treatment chemical levels based on sensor data, manages traffic flow in smart cities, and controls industrial processes in manufacturing plants. Each AI integration creates a new attack surface that combines the AI vulnerabilities from episode 58 with the physical consequences of critical infrastructure compromise.

An AI that manages a chemical dosing system can be manipulated by poisoning its sensor inputs -- feeding it incorrect readings so it compensates by overdosing chemicals. This is an adversarial attack (episode 58) with physical consequences. The AI "sees" that the pH is too high (because the sensor is feeding it false data) and increases the acid dosing to compensate. The actual pH drops to dangerous levels. The AI is doing exactly what it was trained to do -- responding to sensor inputs -- but the inputs are lies, and the output is poison.

The most dangerous pattern: developers connecting AI models to OT systems without understanding the safety implications. An AI that controls a physical process MUST have hardware safety limits (an SIS) that the AI cannot override. No software control -- including AI -- should be the sole safety mechanism. The organizations that deploy AI-optimized chemical dosing or AI-managed power distribution without independent hardware safety systems are building systems where an adversarial attack on the AI model translates directly into physical harm. The AI slop epidemic from episode 6 is bad enough when it produces insecure web applications. When it produces insecure critical infrastructure, the consequences are measured in casualties, not dollars.

The security landscape for critical infrastructure is evolving rapidly. Quantum computing threatens the cryptographic foundations that protect SCADA communications (the few that ARE encrypted). Nation-state actors are stockpiling zero-days for ICS protocols. AI-powered attack tools can now scan for and exploit Modbus devices at scale. The defenders of critical infrastructure need to understand not just today's threats but the trajectory of tomorrow's -- and build the safety systems and network architectures that will still protect physical processes when the threat landscape shifts again.

Exercises

Exercise 1: Research the Ukraine 2015 power grid attack (BlackEnergy/Sandworm). Document: (a) the initial access vector (spearphishing), (b) the lateral movement from IT to OT network, (c) how the attackers opened circuit breakers remotely, (d) how the UPS firmware was modified to prevent remote recovery, (e) what defenses would have prevented each phase. Save to ~/lab-notes/ukraine-grid-analysis.md.

Exercise 2: Set up a simulated ICS environment using GRFICSv2 (https://github.com/Fortiphyd/GRFICSv2) or a Modbus simulator. Practice: (a) reading PLC registers, (b) writing to PLC registers (in the simulator only!), (c) monitoring Modbus traffic with Wireshark. Document what an attacker could do with unrestricted Modbus access.

Exercise 3: Design a network architecture for a fictional water treatment plant following the Purdue Model. Include: (a) 5 levels with specific systems at each, (b) firewall rules between levels, (c) DMZ for remote monitoring, (d) ICS-specific IDS placement, (e) the Safety Instrumented System that prevents dangerous chemical levels regardless of SCADA state. Draw the diagram and specify what each boundary prevents.

Thanks for your time!

@scipio

stem stemsocial steemstem security programming
0
0
0.000
0 comments