Een privé mobiel beheernetwerk werd het aanvalspad naar een Poolse energiecentrale

Een privéverbinding. Een industriële controller met standaardcredentials. Dagen aan rustige verkenning. Daarna toegang tot Siemens PLC's en een stilstaande stoomturbine.

Het onderzoek van CERT Polska naar de aanval op een Poolse warmtekrachtcentrale is de moeite waard, en niet vanwege een spectaculaire kwetsbaarheid. Die was er niet. Het aanvalspad bestond uit connectiviteit, vertrouwen en een reeks op zichzelf redelijke keuzes.

Private betekent niet automatisch vertrouwd.

Technisch ging het om een private cellular APN: een afgeschermd mobiel datanetwerk voor communicatie met remote industriële apparatuur. Dat verdient een duidelijke kanttekening, want de berichtgeving nodigde uit tot een kortere conclusie: het onderzoek wijst niet naar 5G of naar mobiele techniek op zich. Het gaat over de beveiligingsarchitectuur rond private connectiviteit — precies waar IEC 62443 voor bedoeld is.

Wat er gebeurde

Op 29 december 2025 werd een centrale aangevallen die warmte levert aan zo'n 50.000 inwoners. Een stoomturbine en de proceswaterinstallatie werden stilgelegd, waardoor de warmtekrachtproductie tijdelijk stopte. Het herstel begon terwijl de aanvallers nog in het netwerk zaten. Klanten verloren uiteindelijk geen warmte en geen elektriciteit.

De verstoring telt. De nuttigere vraag voor verdedigers is hoe een aanvaller die ergens anders begon uiteindelijk bij de industriële besturing uitkwam.

Dat antwoord begint buiten de centrale.

Van een windpark naar andermans OT

CERT Polska voerde het pad terug op een gecompromitteerde omgeving bij een windpark. Van daaruit bereikte de aanvaller een mobiele router op een private APN van de distributienetbeheerder. Die APN bestond om een goede reden: eigen connectiviteit naar remote operationele apparatuur.

Het probleem was dat apparaten binnen dat private netwerk elkaar konden bereiken. Een compromis op de ene locatie werd daarmee een route naar systemen op een andere.

De aanvaller gebruikte dat bereik om rond te kijken: managementinterfaces, remote-accessdiensten en industriële protocollen als S7 en Modbus. Zo kwam een WAGO PFC200-controller in beeld met een via de APN bereikbare webmanagementinterface en een beheeraccount dat nog op standaardcredentials stond. Die controller werd het tussenstation naar de OT-omgeving van de centrale.

Op dat punt is het geen incidentbericht meer maar een architectuurles.

De echte kwetsbaarheid was impliciet vertrouwen

Het is verleidelijk om één oorzaak aan te wijzen: standaardcredentials, een bereikbare managementinterface, te dunne segmentatie, een te ruim ingerichte privéverbinding. Geen daarvan verklaart het incident alleen. Het risico ontstond doordat verschillende zwaktes achter elkaar konden worden gebruikt.

Een privéverbinding bestond voor een legitieme operationele functie. Maar zodra een aanvaller één aangesloten omgeving had, droeg diezelfde verbinding hem richting de andere.

De vraag is dus niet "is dit netwerk private?" maar "wat kan een gecompromitteerd systeem via deze verbinding bereiken?" Dat is een wezenlijk ander vraagstuk. Een privéverbinding beschrijft hoe systemen communiceren. Vertrouwen moet je nog steeds ontwerpen, begrenzen en controleren.

Waarom dit op de managementagenda hoort

OT-security zakt snel af naar firewalls, PLC's, patches en protocollen. Management hoort een niveau daarboven te zitten, want een organisatie kan technisch veel geregeld hebben en tegelijk leunen op aannames die nooit zijn getoetst:

• dat een privénetwerk per definitie vertrouwd is;
• dat een leverancier toegang alleen gebruikt waarvoor die bedoeld is;
• dat een compromis op een remote locatie een andere locatie niet kan raken;
• dat een industriële controller alleen zijn primaire procesfunctie uitvoert;
• dat een aanvaller meteen zichtbaar is zodra hij binnen is.

Als één vertrouwde verbinding, leverancier of remote locatie morgen wordt gecompromitteerd, blijft onze kritieke OT-omgeving dan beschermd? Dat is geen puur technische vraag. Dat gaat over operationele continuïteit.

Zeven praktische lessen voor OT-omgevingen

1. Behandel private connectiviteit als een eigen trust boundary

Een private APN, MPLS-verbinding, leverancierstunnel of remote-accesslijn hoeft niet onveilig te zijn. Ze hoort alleen niet het vertrouwensniveau te erven van de OT-zone waarmee ze praat. Leg vast wie de verbinding beheert, welke systemen eraan hangen, of deelnemers elkaar kunnen bereiken, welke communicatie echt nodig is, en wat er gebeurt als één deelnemer wordt gecompromitteerd.

2. Segmenteer op functie en risico

Een systeem dat operationele data uitwisselt heeft geen brede toegang nodig tot PLC's, SCADA, engineeringstations en managementinterfaces. Segmentatie moet voorkomen dat één gecompromitteerde verbinding een compleet procesnetwerk blootlegt. Dat is het IEC 62443-denken rond zones en conduits: groepeer systemen naar securitybehoefte en beheers het verkeer daartussen bewust.

3. Sta alleen communicatie toe die de operatie nodig heeft

Leg het expliciet vast — bron → bestemming → protocol → functie. Alles zonder operationele reden hoeft niet bereikbaar te zijn. Dat geldt voor de OT-firewall aan de buitenkant, maar net zo goed voor interne netwerken, private verbindingen en beheerpaden.

4. Scheid beheer van operationeel verkeer

Een device kan een operationele dataverbinding nodig hebben zonder dat de webinterface of SSH-dienst via diezelfde route bereikbaar hoeft te zijn. Beheertoegang verdient een eigen pad, eigen authenticatie en expliciete autorisatie. Dat is wat voorkomt dat een procesverbinding ook een beheerverbinding wordt.

5. Maak hardening onderdeel van commissioning

Standaardcredentials zijn geen hygiënedetail wanneer het apparaat industriële systemen kan bereiken. Wachtwoorden wijzigen, onnodige diensten uitzetten en de uiteindelijke configuratie verifiëren horen in commissioning en acceptatie — niet in een backlog.

6. Detecteer de aanvaller vóór de impact

De verstoring was op 29 december. De aanvaller verkende de omgeving al dagen eerder: CERT Polska zag scans en geslaagde verbindingen met Siemens PLC's ruim voordat er iets werd stilgelegd.

Zouden wij afwijkend gedrag herkennen voordat iemand de toestand van het proces verandert? OT-monitoring moet daarom verder kijken dan malware: naar onverwachte communicatie, nieuwe netwerkpaden, ongebruikelijke beheeractiviteit en vreemd gebruik van volstrekt legitieme industriële protocollen.

7. Test het ecosysteem, niet alleen de centrale

Een assessment dat stopt bij de plant-firewall mist juist de paden die ertoe doen. Private mobiele netwerken, remote locaties, leveranciersverbindingen, telecomafhankelijkheden en gateway-devices horen mee in risicoanalyses, architectuurreviews, pentests, red-teamoefeningen en incidentresponsscenario's. De beveiligingsgrens van een moderne industriële omgeving ligt zelden nog binnen het hek.

Waar had deze aanval kunnen worden gestopt?

De sterkste les is niet dat één maatregel faalde, maar dat meerdere zwaktes konden worden gecombineerd. Vanuit managementperspectief vallen vier vragen op:

1. Wisten we welke externe verbindingen uiteindelijk een route naar kritieke OT-systemen konden geven?
2. Hadden we rekening gehouden met een gecompromitteerde leverancier, remote locatie of vertrouwde verbinding?
3. Waren er genoeg onafhankelijke lagen om verdere beweging te stoppen of tijdig te zien?
4. Konden we het incident isoleren en de operatie veilig herstellen als preventie faalde?

Dat is wat defence in depth in de praktijk betekent: niet vertrouwen op één firewall, één privénetwerk of één product, maar zorgen dat een fout op één plek geen route naar het industriële proces wordt.

Waar IEC 62443 helpt

IEC 62443 is nuttig omdat het industriële cybersecurity als programma behandelt in plaats van als een stapel technische maatregelen: kritieke assets en processen bepalen, risico's beoordelen vanuit operations en safety, zones en gecontroleerde verbindingen ontwerpen, rollen beleggen, leveranciers meenemen, vulnerability- en patchmanagement organiseren, monitoring en incidentrespons inrichten, maatregelen testen en blijven verbeteren.

Dat is het verschil tussen securitymaatregelen hebben en industrieel cyberrisico beheersen.

Vragen over je eigen omgeving

De nuttigste reactie op zo'n incident is geen nieuw checklistje, maar een kortere lijst met lastigere vragen:

• Welke private of extern beheerde verbindingen komen onze OT-omgeving binnen?
• Welke daarvan vertrouwen we zonder de beveiliging zelf te beheersen?
• Kan een compromis op de ene locatie een route naar een andere worden?
• Welke managementinterfaces zijn bereikbaar via verbindingen op afstand?
• Zouden we ongebruikelijke OT-communicatie zien vóór er operationele impact is?
• Kunnen we kritieke processen veilig voortzetten of herstellen als een verbinding of controller wordt gecompromitteerd?

Zijn die vragen lastig te beantwoorden, dan is dat op zichzelf al informatie.

Van incidentanalyse naar invoering

Een incidentanalyse laat zien wat er mis kan gaan. De volgende stap is leren hoe je zulke risico's systematisch voorkomt, beperkt, detecteert en beheerst — zones, verbindingen, toegang, monitoring en governance rond een echte industriële omgeving.

De CyberBusters-takeaway

Deze aanval bewijst niet dat private mobiele netwerken onveilig zijn. Hij laat iets nuttigers zien: een privéverbinding wordt pas een security boundary wanneer je haar ook zo ontwerpt en beheert.

Dat vraagt om segmentatie, hardening, sterke authenticatie, gecontroleerde communicatie, monitoring, logging, testen en herstelvermogen. En vooral om één ontwerpkeuze: een compromis op één plek mag niet automatisch een route naar het kritieke proces worden.

Private connectiviteit maakte hier het pad. Impliciet vertrouwen maakte het breder. De implementatie bepaalt waar een aanval stopt — en daar wordt IEC 62443 van een norm een werkende capability.

Bronnen

• The Hacker News — Hackers breach Polish power plant controls via private cellular network
• CERT Polska — Incident follow-up report: energy sector 2025
• CyberBusters — PECB ISA/IEC 62443 Lead Implementer-opleiding