More than 30 Minnesota water systems were hit in one coordinated cyber attack. Within days, the Five Eyes told critical infrastructure operators to be ready to pull the plug.
Thirty water systems in two days
Over two days in late July, a coordinated cyber attack hit more than 30 community water systems across Minnesota. The treatment plant in Braham went offline. Plymouth lost cellular communications to two water towers and its wastewater lift stations. Maple Plain declared a local state of emergency. Early reporting points to internet-exposed programmable logic controllers (PLCs) as the way in, and investigators are examining links to Iranian affiliated activity. Through it all, the water stayed safe to drink. No boil advisories were issued, and communities like Plymouth kept water moving the old way: manual operations, with people standing at the equipment.
Six agencies, one message
Within days, the Australian Signals Directorate, the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and the national cyber security centres of Canada, the United Kingdom, and New Zealand released joint guidance titled CI Fortify: Advice for Isolating Vital Systems. The premise is blunt. Critical infrastructure operators must be able to cut vital operational technology (OT) off from every other network, deliberately and in good order, and keep critical services running for as long as a crisis lasts.
The problem stretches well beyond one state’s water sector. State-sponsored actors routinely target critical infrastructure to pre-position for disruptive attacks in a crisis or conflict. Cyber criminals target the same operators because downtime is leverage. Isolation blunts both: it contains the incident, protects the service, and buys time to evict the attacker and rebuild safely.
The document lays out a six step path to that capability, and it is worth reading end to end. But the sharpest material hides in the fine print, where the guidance quietly dismantles assumptions that a lot of production networks lean on today. Six stand out.
1. “Our VLANs separate the networks.”
Not according to the Five Eyes. The guidance rates administrative controls like VLANs as “minimally effective” segregation: acceptable as an interim measure on the road to physical or cryptographic isolation, never as the long-term answer. A VLAN is a traffic label enforced by a switch. Whoever controls the switch controls the label.
If VLANs are part of your segmentation today, the bar for hygiene is high:
- Never let VLAN configurations propagate automatically across the network. Configure them by hand, only where needed
- Lock trunk ports to explicitly allowed VLANs, disable trunk negotiation, and park the native VLAN on an unused, shutdown ID
- Manage switching infrastructure only from your most trusted zone, ideally from dedicated privileged access workstations
- Never let internet-facing zones or demilitarized zones (DMZs) share infrastructure with OT
That is a lot of care for a control that still only earns “minimally effective.”
2. “MPLS keeps our traffic private.”
Multiprotocol Label Switching (MPLS) “does not provide assurance of segregation and is not secure by default.” That’s a direct quote. Operators using MPLS to separate networks of different trust levels, such as information technology (IT) and OT, must add cryptographic isolation, with encryption implemented on the router that forms the OT boundary. Privacy you cannot verify is privacy you are assuming.
3. “Our carrier is a trusted partner.”
The guidance tells operators to treat any carrier provided service as “untrusted and potentially hostile.” This isn’t a judgment about your carrier’s intentions. It’s a statement about what you can verify from your side of the demarcation point. In practice, it means shielding customer edge equipment from the provider network, filtering so only explicitly defined peers can reach your devices, and moving provider-facing infrastructure to the front of the vulnerability management queue.
4. “Our OT devices already encrypt, so the link is covered.”
The advisory is unambiguous: do not use encryption built into OT devices. Encryption over untrusted links belongs on a dedicated device with one job. For Layer 2 carrier services, that means link encryption such as Media Access Control security (MACsec). For Layer 3, it means Internet Protocol Security (IPsec) or equivalent, terminated on a trusted device inside the critical network and reachable only from trusted management hosts. Hardened, patched, and never configurable from the untrusted side.
5. “We’re software defined, so segmentation is handled.”
Software-defined networking, software-defined wide area networks, and Secure Access Service Edge platforms manage large networks efficiently. The guidance does not dispute that. It disputes what they prove: these systems provide logical separation and “do not provide assurance that is equivalent to physical separation.” The abstraction layer between policy intent and device configuration is itself software, and software can be exploited. When an orchestration platform enforces your segmentation, that platform becomes a crown jewel. Efficiency is not assurance.
6. “Once we isolate, we’re safe.”
Isolation ends one set of risks and starts another. The guidance names three. Systems fall out of patch. External visibility drops exactly when you want it most. And removable media becomes the main way data moves, at the same moment the stations that scan that media for malware (the sheep dip machines, in operator slang) stop receiving updates. Isolation isn’t a safe room. It’s a mode of operation with its own disciplines, and the time to learn them is before the crisis, not during it.
The two steps most operators will skip
The six-step path itself is methodical: identify vital systems, identify the critical customers that depend on them, classify criticality and trust, map every connection, build real separation and isolation points, and write a graduated isolation plan with trigger criteria wired into your incident response plan.
Two details deserve more attention than they will get. The first is dependency mapping. Active Directory, Domain Name System (DNS) services, time synchronization, backups, and shared hypervisors quietly tie OT to corporate infrastructure, and any one of them can turn a clean disconnect into an outage. The second is testing. Isolating a single system in a drill proves very little, because dependencies live between systems. Test the full isolation, on a schedule, and keep a printed copy of the plan offline, where an intruder who owns your document management system cannot read what you plan to do next.
Where Check Point fits
An isolation plan is only as good as the boundaries that enforce it. Check Point Quantum Rugged gateways enforce segmentation at the OT boundary in environments where heat, dust, and vibration are part of the job description, with threat prevention that understands industrial protocols. Unified policy across IT and OT turns the isolation points the guidance calls for into boundaries you can operate, monitor, and test rather than lines on a diagram.
Enforcement is half the story. The other half is making sure you rarely need it. Check Point’s philosophy is prevention first: stop the attack before it ever forces the isolation decision. At the boundary, that means intrusion prevention that virtually patches legacy controllers that cannot take a vendor patch. Minnesota is the case study here, where investigators pointed to internet exposed controllers – including models carrying vulnerabilities with no fix available. It means real-time threat intelligence from ThreatCloud AI blocking known attack infrastructure before it touches a controller. And it means Zero Trust access, so a vendor connection reaches one device for one maintenance window, not the whole plant floor.
Think of the graduated isolation plan as your parachute: you build it, you test it, you keep it packed. A prevention first architecture is the reason you almost never pull the cord.

Leave A Comment