Een PLC hoort niet direct aan het internet: de IEC 62443-les uit de Siemens S7-dreiging

DE EXPLOIT IS NIEUW. HET ARCHITECTUURPROBLEEM NIET.

Een PLC zou zichzelf niet rechtstreeks tegen het internet hoeven te verdedigen.

Siemens S7 · blootstelling aan internet · ISA/IEC 62443

Ergens draait op dit moment een S7-1200 die je met een zoekopdracht van een paar woorden kunt vinden. Niet omdat iemand hem heeft gehackt, maar omdat hij gewoon aan staat, met een publiek adres, en omdat er ooit een monteur was die 's avonds vanaf huis wilde kunnen meekijken.

Dat is niet nieuw. Wat wél verandert, is hoe snel iemand daar iets mee kan.

Wat er precies gemeld is

Op 20 augustus 2026 kwamen NSA, CISA, FBI, DOE en EPA met een gezamenlijke waarschuwing over Siemens S7-PLC's. Het gaat om de S7-200, S7-300 en S7-400, de S7-1200 in de uitvoeringen 1211C tot en met 1217C, en de S7-1500 — inclusief de F-varianten, de controllers die veiligheidsfuncties draaien.

Wat er is gezien: aanvallers gebruiken Censys en ZoomEye, dezelfde zoekdiensten die onderzoekers gebruiken, om PLC's te vinden die aan het internet hangen en verouderde software draaien. Vervolgens laten ze AI meeschrijven aan aanvalsscripts, op basis van informatie die gewoon openbaar is. Eén van de beschreven scripts doet zich voor als een legitieme monitoringtool en praat S7comm.

En dan het deel dat in de doorvertelling meestal sneuvelt. De waarschuwing gaat over verkenning en het opbouwen van gereedschap. Er wordt niet vastgesteld dat een specifieke Siemens-kwetsbaarheid met succes is misbruikt, en er wordt geen enkele CVE genoemd. De formulering is voorwaardelijk: áls deze PLC's aan het internet hangen of onvoldoende gesegmenteerd zijn, dán zijn bekende kwetsbaarheden te misbruiken.

Dat verschil is geen muggenzifterij van een securityman. Het bepaalt wat je maandag doet. Bij bevestigde exploitatie ga je jagen op sporen. Hier ga je kijken wat er van buiten bereikbaar is — en dat is een heel ander gesprek, met heel andere mensen.

Twee dingen die steeds door elkaar lopen

Er staan hier twee problemen naast elkaar en ze worden vrijwel altijd op één hoop gegooid.

Het eerste is dat AI de drempel verlaagt. Tijd, kennis en kosten om aanvalstuig te bouwen gaan omlaag. Wat vorig jaar iemand met verstand van zaken en een paar weken kostte, kost nu minder. Dat is echt zo, en tegelijk minder spectaculair dan het klinkt: er wordt hier openbare informatie sneller omgezet in werkende code, niet nieuwe natuurkunde uitgevonden. Wat dat betekent voor de verdediger schreven we eerder op in ons stuk over AI en de aanvaller.

Het tweede is dat een industriële controller vanaf het internet te bereiken is. Dat is geen dreigingsprobleem maar een architectuurprobleem, en het bestond al ruim voordat iemand een taalmodel op exploitcode losliet.

Dat onderscheid tussen architectuur en ontwerp is hier niet gezocht. Architectuur gaat over de vraag welke zones er zijn en wat wat mag bereiken. Ontwerp gaat over hoe je dat realiseert: welk apparaat, welke regel, welke instelling. Je kunt een uitstekend ontwerp hebben — nette regels, goed geconfigureerde firewalls — bovenop een architectuur waarin een controller nog steeds aan de straat ligt. Dan heb je het probleem netjes opgeschreven, niet opgelost.

Dit artikel gaat over het tweede. Niet omdat het eerste onbelangrijk is, maar omdat je aan het tweede iets kunt doen dat blijft werken als het gereedschap van de aanvaller weer verandert. En dat verandert.

De vraag waar het gesprek op draait

Als een aanvaller het IP-adres van deze PLC kent, wat moet hij dan passeren of compromitteren voordat hij ermee kan praten?

Meer is het niet. Pak je belangrijkste controllers, loop die vraag langs en schrijf het antwoord op. Niet in een document — gewoon op een vel papier, met iemand van de operatie erbij.

Als het antwoord “niets” is, dan heb je geen dreigingsprobleem. Dan heb je een architectuurprobleem, en daar helpt geen detectieregel tegen.

Wat je vaak hoort is: “ja, maar er staat een wachtwoord op.” Dat is een slot op een deur die aan de straat ligt. Het kan prima zijn dat dat slot het houdt. Maar je hebt dan wel je hele beveiliging opgehangen aan één ding, op een apparaat dat is ontworpen om betrouwbaar een proces aan te sturen, niet om zich staande te houden tegen het internet.

Waar IEC 62443 hier over gaat

De ISA/IEC 62443-reeks is geen product en geen keurmerk. Het is een manier om industriële cybersecurity als architectuurvraag te behandelen in plaats van als een lijst maatregelen. Vijf begrippen doen hier het meeste werk.

Eerst afbakenen waar je het over hebt

Beveiligingsarchitectuur begint met het System under Consideration: wat hoort er wel en niet bij de omgeving die je beoordeelt. Dat klinkt als papierwerk tot je merkt wat er buiten viel. De mobiele router die de installateur heeft achtergelaten. De cloudportal waarmee de leverancier zijn eigen apparatuur beheert. Het beheerkoppelvlak van de switch, waar niemand eigenaar van is.

Wat buiten de afbakening valt, valt ook buiten je risicoanalyse. En daar zitten precies de verbindingen die je niet zag.

Blootstelling verandert het risico

Een controller die vanaf het internet bereikbaar is heeft een fundamenteel ander aanvalsoppervlak dan dezelfde controller achter een paar gecontroleerde overgangen. Dat hoort terug te komen in je risicoanalyse.

Dat betekent niet dat elke installatie dezelfde maatregelen nodig heeft. Een verpakkingslijn en een installatie met een veiligheidsfunctie horen niet op hetzelfde niveau uit te komen. Maatregelen volgen uit risico — dat is waar 62443-3-2 over gaat.

Zones en conduits, en wat ze niet zijn

Twee misverstanden die in bijna elke tekening terugkomen. Een VLAN is niet automatisch een zone: een VLAN scheidt verkeer, een zone is een groep assets met vergelijkbare beveiligingseisen en een reden waarom ze bij elkaar staan. En een firewallregel is niet automatisch een conduit: een regel zegt wat mág, een conduit is de bewust ontworpen communicatie tussen twee zones.

Voor de directietafel is de vertaling simpel. Een zone is een ruimte waarvan je kunt uitleggen waarom die dingen daar samen staan. Een conduit is een deur waarvan je kunt uitleggen waarom hij er is, wie erdoor mag, en wat er gebeurt als je hem dichtdoet. Kun je dat niet uitleggen, dan heb je geen zone maar een subnet. Hoe je daar wel komt staat in een VLAN is geen segmentatiestrategie.

Alleen wat de operatie nodig heeft

62443 werkt met het idee van beperkte datastromen. In de praktijk: leg per verbinding vast welke bron, welke bestemming, welk protocol, om welke operationele reden, en wat er gebeurt als de verbinding wegvalt.

Die laatste twee zijn de interessante. Een verbinding waarvoor niemand een reden kan noemen en waarvan niemand weet wat er stukgaat als je hem dichtzet, is bijna altijd een verbinding die er ooit voor het gemak bij is gezet. Meestal door iemand die er niet meer werkt.

Toegang op afstand is iets anders dan blootstelling

Hier loopt het gesprek vaak vast, dus expliciet: toegang op afstand is niet hetzelfde als rechtstreeks aan het internet hangen. Een leverancier, OEM of je eigen engineer heeft vaak echt toegang nodig. Dat mag. Het gaat erom via welke architectuur dat loopt.

Afhankelijk van het risico horen daar zaken bij als geauthenticeerde toegang met individuele accounts in plaats van één gedeeld wachtwoord, meerfactorauthenticatie, een VPN of ZTNA waar dat past, een tussenstap zoals een jump host, rechten op basis van rol in plaats van gewoonte, toegang die in tijd begrensd is, een goedkeuringsstap voordat de sessie opengaat, logging van wat er gebeurt, en beperking tot de protocollen die nodig zijn.

Let op: dat is een lijst met gangbare maatregelen, geen lijst die de norm voorschrijft. IEC 62443 eist geen specifiek product en geen specifiek merk. Wat jij nodig hebt volgt uit jouw risicoanalyse, niet uit een verkoopgesprek.

Eén laag is geen architectuur

De reflex na zo'n waarschuwing is een firewallregel. Dat helpt. Maar het is niet het antwoord, en dat is precies waar het bij de meeste incidenten misgaat: er was wel een firewall, en daarachter was het plat.

Defence in depth betekent dat een fout op één plek geen route naar het proces wordt. Architectuur en afbakening. Segmentatie in zones. Gecontroleerde conduits daartussen. Hardening van de controllers zelf. Authenticatie en autorisatie. Monitoring die afwijkend gedrag ziet. Wijzigingsbeheer, zodat je weet wat er is veranderd. Beheerste toegang op afstand. En patchen of mitigeren op basis van risico.

Hoe dat uitpakt als één laag het alleen moet doen, staat in onze analyse van de aanval op een Poolse energiecentrale. Geen zeroday, wel een keten van op zichzelf redelijke keuzes.

En de controller zelf

Hardening van een PLC is een ander gesprek dan hardening van een server, want hier gaan beschikbaarheid en veiligheid voor. “Gewoon alles patchen” is geen advies dat je in een fabriek kunt uitvoeren, en iedereen die weleens in een productiehal heeft gestaan weet dat.

Wat je wel kunt: firmware draaien die nog ondersteund wordt. Beveiligingsupdates testen voordat ze de lijn raken en ze inplannen in een onderhoudsvenster. Diensten uitzetten die je niet gebruikt. Beperken wie mag programmeren en vanaf waar. Sterke authenticatie gebruiken waar het apparaat dat aankan. De configuratie beschermen tegen ongeautoriseerde wijziging. Een werkende configuratie als backup bewaren — en één keer testen of je hem ook echt kunt terugzetten. En wijzigingen in de gaten houden, want een onverwachte programmawijziging op een PLC is geen ruis.

Kun je niet patchen, dan is dat een risicobesluit met compenserende maatregelen. Geen actiepunt dat je elk kwartaal doorschuift.

Security levels zijn een doel, geen cijfer op de doos

62443-3-3 beschrijft systeemeisen en hangt daar security levels aan. Het nuttige is dat je per zone een target security level kunt vaststellen op basis van risico, en dat kunt afzetten tegen wat de omgeving vandaag werkelijk kan. Dat verschil is je werklijst.

Wat het niet is: een keurmerk op een apparaat. Een PLC is niet “SL 3”. Het niveau hoort bij een zone en bij de eisen die daar gelden. Als een leverancier je een security level op een productblad laat zien, verkoopt hij je iets anders dan wat de norm bedoelt.

Vijf vragen om vandaag te stellen

1. Zijn er PLC's, HMI's, engineeringkoppelvlakken of OT-gateways rechtstreeks bereikbaar vanaf het internet?
2. Is elke externe verbinding naar OT terug te vinden als een bewust ingerichte, gecontroleerde route?
3. Kunnen we van elk asset uitleggen waarom het in zijn huidige zone zit?
4. Is de communicatie tussen zones beperkt tot wat de operatie echt nodig heeft?
5. Als de inloggegevens of het platform voor toegang op afstand worden gecompromitteerd, wat houdt een aanvaller dan tegen om bij de controllers te komen?

Die laatste levert het beste gesprek op. Hij verplaatst de vraag van “hebben we MFA” naar “wat gebeurt er als die ene laag valt”. En dat is waar je het over wilt hebben.

Vertrouw de tekening niet

Een architectuurplaat beschrijft de bedoeling. Blootstelling gaat over de werkelijkheid, en in industriële omgevingen lopen die twee verder uiteen dan iemand prettig vindt. Er zit vaak vijftien jaar tussen de tekening en de installatie.

Controleer dus wat er echt van buiten bereikbaar is. Je publieke adresruimte. NAT- en portforwardingregels, ook die van jaren terug. Industriële en mobiele routers, inclusief die van een leverancier. Gateways voor toegang op afstand. Verbindingen van integrators. OT-apparatuur die vanuit een cloudportal wordt beheerd. En de beheerkoppelvlakken van je switches, firewalls en gateways, want die worden bijna altijd vergeten.

Aanvallers vallen je Visio-tekening niet aan. Ze vallen aan wat ze kunnen bereiken.

Waar het op neerkomt

AI verandert de snelheid en de toegankelijkheid van aanvalscapaciteit. Goede OT-architectuur verandert wat die capaciteit kan bereiken.

Dat is geen woordspel. Als een controller alleen te bereiken is via een overgang die jij hebt ontworpen, dan maakt het minder uit hoe snel iemand een script in elkaar zet. Hij komt er niet bij zonder eerst iets te passeren dat jij daar bewust hebt neergezet — en dat is precies het soort obstakel dat blijft werken als het gereedschap verandert.

Het doel is niet om een PLC veilig genoeg te maken om het internet te overleven.

Het doel is de architectuur zo te ontwerpen dat dit überhaupt niet nodig is.

Verder dan de checklist

Wil je verder dan de checklist? CyberBusters verzorgt ook de PECB ISA/IEC 62443 Lead Implementer, voor professionals die IEC 62443 moeten vertalen naar praktische keuzes in governance, risico en architectuur.

Bronnen

• The Hacker News — AI-generated exploit scripts target Siemens S7 PLCs, nieuwscontext bij het gezamenlijke advies van NSA, CISA, FBI, DOE en EPA van 20 augustus 2026
• CISA — Cybersecurity Advisories
• Siemens ProductCERT, voor actuele advisories over Siemens-producten
• ISA — ISA/IEC 62443 series of standards
• IEC 62443-3-2 — security risk assessment for system design
• IEC 62443-3-3 — system security requirements and security levels