Block, Baseline, or Harden: Defending Siemens S7 PLCs

Open the online connection table on an S7-1500 that sits one careless firewall rule from a business network, and the picture looks calm. A historian polls a clutch of data blocks. An HMI holds a session. An engineering station checked in this morning and went quiet. Every one of them speaks S7comm, reads a few blocks, nudges a setpoint now and then, and logs off. Ordinary plant traffic on an ordinary shift.

Now add one more session that looks exactly like the rest. Same protocol. Same read-a-block, write-a-block cadence. Its process name even says "monitor." But it isn't your historian, and the block it just wrote wasn't a setpoint you asked for.

That session is the plain-language subject of a joint advisory the NSA, CISA, FBI, DOE and EPA published on 19 August 2026. The agencies describe threat actors using AI to write S7 exploitation scripts from public information, then dressing those scripts as legitimate monitoring tools so they slide past a bored analyst. The plumbing is dull and freely available: snap7, an open-source library any integrator might grab for a quick tag reader, and its python-snap7 binding. Point it at an S7 controller that answers from the internet, and it will read and write memory, configuration, and in some cases the ladder logic that runs the process.

Read the advisory's list of the hardest-hit sectors and it's a walk through the process industry: critical manufacturing, energy, water and wastewater, chemical, food and agriculture. If your plant runs an S7 controller on a CIP skid, a pump station, a furnace line, or a bottling hall, you're squarely on that list, and the exposed-controller problem isn't somebody else's.

What makes this hard for a plant has nothing to do with how clever the script is. At the wire, a malicious S7comm write is the same operation your historian and your batch server perform all shift. There's no exotic signature to catch, no malformed packet, no memory-corruption bug to patch away. The attacker's tool asks the controller to do exactly what it was built to do, over the same protocol and often the same library your own integrator uses. So you can't filter for "bad S7comm," because it reads identically to the good kind. You're left choosing a posture.

Three of them, really. Blocking means the session never reaches the CPU from anywhere it has no business being: segment the cell, deny the S7comm port across the boundary, and take the controller off every path that can see the public internet. Baselining means you assume something will get through and you watch, learning which clients normally talk to which blocks, so the stranger writing to a block that's normally read-only stands out. Hardening means the PLC checks credentials before it honors a write, so a script speaking fluent S7comm gets turned away at the door. None of the three is new. What changed is that an adversary can now conjure a convincing monitoring impostor cheaply, and that shifts how much each posture is worth.

Reading is the disguise

A monitoring tool, by its nature, mostly reads. It samples tags, pulls a data block, trends a temperature, and writes almost nothing. So does the reconnaissance phase of an intrusion. An impostor that only reads can sit on an exposed controller for weeks looking identical to a legitimate poller, mapping which data blocks hold what, learning the shape of the logic, reading the diagnostic buffer and the rack's hardware configuration to fingerprint every module by make and firmware, timing the process, and never once doing anything a naive filter would call an attack. The write, when it finally comes, is a single event at the end of a long, boring, entirely normal-looking read history. A defense that only watches for the write is watching the last five seconds of a month-long visit. The disguise isn't the payload. It's the patience.

What actually stops the write

Blocking is the bluntest instrument and, where it applies, the strongest. If the S7comm session physically cannot cross from the IT network or the internet into the cell, the AI-written impostor never gets to introduce itself. The advisory's recommendation to deny that port at the perimeter and pull the controller off any internet-facing path is blunt for a reason: it removes a whole class of remote attempts in one rule. Where a plant genuinely needs to push data outward, a data diode (bytes leave the cell, nothing comes back) preserves the outbound telemetry feed without opening a way back in. But blocking only guards the boundaries you actually control. A foothold already inside the cell (a compromised engineering laptop, a contractor VPN that lands in the OT VLAN, a jump host someone stood up "temporarily" and never removed) sits on the trusted side of your rule and speaks to the PLC unimpeded.

Baselining answers a different question: not "did it cross a line" but "does this belong." A behavioral baseline that knows your historian polls the same handful of blocks every few seconds, and that no legitimate client has ever written to the data block holding recipe parameters at 3am, flags the impostor by its behavior wherever it came from. It keys on things a disguise can't easily fake at scale: which source addresses talk to the CPU, the ratio of reads to writes, the specific blocks and function codes touched, the regularity of the timing. And it sees the foothold that blocking misses. The catch is that baselining detects; it doesn't prevent. By the time the anomalous write lights up, it has already happened. Baselining also only sees the conversations you give it visibility into, through a span port, a tap, or the historian's own record of who touched what.

Hardening refuses the write at the endpoint, whether the attacker is across the world or across the room. So which session does the controller trust? On a CPU that enforces access protection, the answer is "the one with the credential," and the impostor without it gets refused before the block is ever written. The limit is the installed base. Legacy controllers, the S7-300 and S7-400 generation, speak an older S7comm whose classic PUT/GET path was never authenticated, so protection there is optional and thin. The modern S7-1500 line supports real access levels, can require authentication for writes, and lets you switch the legacy PUT/GET path off entirely. Same protocol name, very different ability to say no.

How long until anyone notices

Prevention has no detection clock, which sounds like a clean win until the prevention has a gap. A blocked plant that never watches its own cell traffic learns about the session that slipped through a forgotten rule the way plants usually learn about trouble: from the process misbehaving, a batch off-spec, a pump commanded somewhere it shouldn't go, days later. Blocking's latency is zero where it holds and effectively infinite where it doesn't, and you don't always know which is which.

Baselining is the only posture whose entire job is the clock. A tight baseline with alerting wired to someone who answers can surface the first anomalous write in seconds to a few minutes. A loose one, buried under its own false alarms, might as well not exist. Detection speed is a property of the tuning and the staffing, not the technology, which is why a model bolted on and ignored is worse than honest about its latency: it reads as covered while seeing nothing.

Hardening prevents in real time on the controllers that can do it. The refused write never lands, so for the traffic it covers, latency is the best of the three. Yet it says nothing about an action taken with a stolen-but-valid credential, or about the legacy CPU down the line that can't enforce anything. Fast where it works. Silent where it can't.

The alarms you'll actually get, and the monitoring you might break

Every posture has a failure mode that shows up in the control room, and they aren't the same failure. Blocking's is operational. Draw the segmentation too tight and you sever the legitimate historian, the OEE dashboard, and the remote-support session the vendor needs during a trip, all of which ride the very S7comm you just denied. People route around pain, so the over-blocked plant sprouts exceptions, and the exceptions become the path. A rule that gets quietly undone by the people it inconveniences protects nothing.

The false positives actually live in baselining. Every legitimate-but-first-time event looks like an anomaly the first time it happens: a new engineering session before a planned change, a firmware update, the commissioning of a new client. A model with no clean learning window cries wolf until nobody listens; a model tuned toward silence to keep the peace sails right past the impostor it was bought to catch. So do you set it to catch everything and drown, or to stay quiet and miss? That tension is permanent. The behavioral baseline that an edge analytics platform trained on a plant's own telemetry builds is only ever as good as the window it learned from and the feedback it gets when it's wrong. Feed it a clean baseline and answer its alerts, and it earns its place. Ignore it, and it becomes expensive wallpaper.

Hardening's false alarms wear coveralls. Turn on access protection on a running line without first inventorying every client that legitimately writes, and the "attack" you block on Tuesday morning is your own historian that always used PUT/GET, or the third-party gateway that assumed an open controller. Unlike a noisy model, a refused legitimate write can stall a process, not just annoy an analyst. Hardening trips you when you skip the homework.

Who owns it on a Tuesday

Cost lives less in the purchase than in the keeping. Firewall rules and segmentation are cheap to buy and expensive to govern: they drift, someone adds a temporary allow for a vendor and forgets it, and the map on the wall stops matching the switch. Cheap if disciplined, quietly porous if not.

A baseline needs care and feeding. It wants retraining as the plant changes, thresholds tuned as seasons and campaigns shift what counts as normal, and a human who answers the 2am alert and tells it whether it was right. That's genuine labor, and pretending otherwise is how monitoring becomes theater. The upside: the work is ordinary operations work, the same discipline that keeps any alarm rationalization honest.

Hardening is the heavy retrofit up front and the light bill afterward. On a legacy fleet you may not be able to require authentication at all without a controller migration you can't schedule this year. On modern CPUs you can, but you take on credential management and an engineering workflow that now has locks in it. High one-time cost, low running cost, and a long tail of "who has the key" that never quite closes. There's also an ownership seam here that has nothing to do with technology: blocking usually belongs to whoever runs the network, hardening to controls engineering, baselining to whoever watches the alarms. A plant that never decides which of those three teams owns which posture ends up with all three half-done.

Which fits your plant

Start with the least clever thing that removes the most risk. If any S7 controller answers from the internet, or your cell network is flat enough that the business VLAN can reach it, blocking isn't a choice to weigh. It's the first afternoon's work. The advisory is right to be blunt about the port, because no baseline or credential scheme earns its keep while the front door stands open.

Once the boundary holds, the split is about your installed base. A plant standardized on modern S7-1500 controllers has already paid for access protection and legacy-path lockdown, so hardening is the natural next layer. Turn on what you bought. A plant running an older fleet it can't re-flash this year has no hardening to turn on, so its second layer has to be eyes: passive baselining that watches the traffic it can neither block nor authenticate. And any plant that needs to see inside the cell, not just guard its edge, needs baselining regardless of controller vintage.

Your sector shapes which gap bites first. Water and wastewater runs remote assets by nature: a lift station or a chlorination skid on an S7-1200 reached over a cellular router is exposed almost by design, so blocking and tighter remote access come first. A dairy or a brewery tends to gather its S7-1500 controllers in one plant network behind a single boundary, which makes hardening the practical lever. A metals line built around a decade-old furnace controller may have no authentication to enable at all, and there baselining is the only watch you can mount.

Most real sites will run all three, sequenced by what's cheapest and most reversible first. Block, because it's a rule you can write today and undo tomorrow. Harden, because it's structural and worth the retrofit where the hardware allows. Baseline, as the standing eye that assumes the other two have gaps, since they do. Not every plant can do all three at once, and the ones that try usually do none of them well. Pick the order your site can actually sustain past the week of the audit.

Go back to that connection table. The impostor session is still sitting in the log, still politely calling itself "monitor," still speaking the same S7comm as everything around it. All three postures aim at that one line: to make it impossible, to make it refused, or to make it loud. Choose the one your plant can keep true after the temporary rules start creeping back. That's the whole game.

Notes

This is a defense comparison, not a configuration guide. The specific access-protection steps, PUT/GET settings, and firmware baselines differ by controller family and firmware revision, and the manufacturer's own product documentation is the authority for your exact models. None of the three postures is sufficient alone, and they aren't mutually exclusive. The segmentation and monitoring practice described here tracks the zones-and-conduits thinking in IEC 62443 and NIST's OT security guidance, both of which predate this advisory and are worth reading against your own cell. The joint advisory is the primary source for the threat activity, and the place to start.