Uw OT-leverancier heeft uw wachtwoorden — en u weet het niet

Stel u het volgende voor. Een machineleverancier uit Zuid-Duitsland levert een verpakkingslijn aan uw fabriek in Nederland. Tijdens de commissioning — de inbedrijfstelling — configureert de servicemonteur de PLC's, de HMI's en de SCADA-koppeling. Hij stelt wachtwoorden in. Hij configureert een VPN-verbinding voor remote support. Hij maakt accounts aan op uw netwerk. En vervolgens vliegt hij terug naar Duitsland.

Zes maanden later weet niemand in uw organisatie welke wachtwoorden er zijn ingesteld. Niemand weet welke accounts er bestaan. Niemand weet of die VPN-verbinding nog actief is. Maar de leverancier heeft al die informatie nog — samen met de twintig andere klanten waarvoor hij hetzelfde heeft gedaan, met dezelfde wachtwoorden.

Dit is geen hypothetisch scenario. Dit is de standaardsituatie bij het merendeel van de Nederlandse productiebedrijven die ik audit.

Hoe het probleem ontstaat

Het probleem begint bij de commissioning. Wanneer een nieuwe machine of productielijn wordt geinstalleerd, is er enorme tijdsdruk. De monteur moet de installatie werkend opleveren. De fabriek wil zo snel mogelijk produceren. In die druk worden beveiligingspraktijken als eerste opgeofferd.

De monteur gebruikt standaardwachtwoorden die hij bij elke klant gebruikt. "Admin/admin" op de HMI. "1234" op de PLC. Een gedeeld VPN-account met de naam "service" en een wachtwoord dat al jaren hetzelfde is. Deze credentials worden niet gedocumenteerd, niet overgedragen aan de klant, en niet gewijzigd na oplevering.

Vervolgens komt de remote support-fase. De leverancier heeft een servicecontract dat hem het recht geeft om op afstand in te loggen voor storingshulp en onderhoud. Dat is op zich logisch en vaak noodzakelijk. Maar de manier waarop het wordt geimplementeerd is vrijwel altijd onveilig:

• Gedeelde VPN-accounts: Eén VPN-account dat door alle servicemonteurs van de leverancier wordt gebruikt. Als een monteur vertrekt, wordt het wachtwoord niet gewijzigd.
• Permanente verbindingen: De VPN-tunnel staat altijd open, ook wanneer er geen onderhoud plaatsvindt. Er is geen on-demand activering.
• Geen logging: Er wordt niet bijgehouden wie wanneer heeft ingelogd en wat er is gedaan. Bij een incident kunt u niet achterhalen of de leverancier betrokken was.
• Directe toegang tot het OT-netwerk: De VPN-verbinding eindigt direct in het OT-netwerk, zonder tussenkomst van een jump server, bastion host of ander controlepunt.
• Hardcoded credentials in software: Sommige leveranciers hebben wachtwoorden hardcoded in hun applicatiesoftware of configuratiebestanden. Deze kunnen niet worden gewijzigd zonder de applicatie te breken.

Waarom dit een tijdbom is

Het probleem wordt pas zichtbaar als het misgaat. En dan is het te laat. Enkele scenario's die ik in de praktijk heb gezien of die bij collega-auditors zijn voorgekomen:

Een voormalig servicemonteur van een machineleverancier werd ontslagen. Hij had nog toegang tot de VPN-accounts van meer dan dertig klanten. Gelukkig was hij geen kwaadwillende — maar stel dat hij dat wel was geweest? Of stel dat zijn laptop was gestolen?

Een machineleverancier werd zelf getroffen door ransomware. De aanvallers vonden in de systemen van de leverancier de VPN-credentials van al zijn klanten. Vanuit de leverancier hadden ze directe toegang tot de OT-netwerken van tientallen fabrieken. Het is het supply chain-scenario waar beveiligingsexperts al jaren voor waarschuwen.

Bij een audit van een chemisch bedrijf ontdekten we dat een PLC — die een kritiek veiligheidsproces aanstuurde — nog het fabriekswachtwoord "0000" had. Dit wachtwoord stond in de publiek beschikbare handleiding van de fabrikant. Iedereen met toegang tot het netwerk en een kopie van de handleiding kon het veiligheidssysteem herconfigureren.

Controleer dit bij uw leverancier

Gebruik de volgende checklist om de situatie bij uw eigen leveranciers in kaart te brengen. Loop elk punt door voor elke leverancier die remote of fysieke toegang heeft tot uw OT-omgeving:

1. Inventariseer alle remote access verbindingen Welke leveranciers hebben VPN-toegang tot uw OT-netwerk? Hoeveel actieve verbindingen zijn er? Zijn er verbindingen die altijd open staan? Maak een volledige lijst — u zult verbaasd zijn hoeveel het er zijn.
2. Controleer of credentials persoonlijk en uniek zijn Heeft elke monteur een eigen account, of gebruiken ze een gedeeld "service"-account? Persoonlijke accounts zijn essentieel voor traceerbaarheid. Gedeelde accounts moeten onmiddellijk worden vervangen.
3. Verifieer dat standaardwachtwoorden zijn gewijzigd Controleer alle PLC's, HMI's, switches, routers en andere netwerkapparatuur in uw OT-omgeving op standaardwachtwoorden. Gebruik de publieke handleidingen van de fabrikanten om te zien wat de defaults zijn.
4. Eis MFA op alle remote access Elke remote verbinding naar uw OT-omgeving moet beveiligd zijn met multifactor-authenticatie. Geen uitzonderingen. Als uw leverancier zegt dat MFA "niet kan" met hun systeem, is dat een rode vlag.
5. Implementeer just-in-time toegang Remote access mag alleen actief zijn wanneer het nodig is. De leverancier vraagt toegang aan, u keurt het goed, de sessie wordt geopend voor een beperkte tijd en automatisch gesloten. Geen permanente tunnels.
6. Zorg voor volledige logging en monitoring Elke remote sessie moet worden gelogd: wie, wanneer, hoe lang, welke systemen zijn benaderd. Gebruik bij voorkeur een privileged access management (PAM) oplossing die sessies kan opnemen.
7. Gebruik een jump server of bastion host Laat de leverancier nooit direct in uw OT-netwerk komen. Alle remote access loopt via een beveiligde jump server in een DMZ. Vanaf die jump server kan de leverancier alleen de specifieke systemen bereiken die hij nodig heeft.
8. Neem credential management op in leverancierscontracten Leg contractueel vast dat leveranciers unieke credentials gebruiken, dat wachtwoorden periodiek worden gewijzigd, dat gedeelde accounts niet zijn toegestaan, en dat de leverancier u moet informeren bij beveiligingsincidenten aan hun kant.

De oplossing: credential management voor OT

De technische oplossingen bestaan. Het gaat erom ze ook daadwerkelijk te implementeren in OT-omgevingen, waar de cultuur vaak anders is dan in IT. Dit zijn de kerncomponenten:

Privileged Access Management (PAM): Een PAM-oplossing beheert alle privileged accounts centraal. Wachtwoorden worden automatisch geroteerd. Toegang wordt verleend op basis van goedkeuringsworkflows. Sessies worden opgenomen. Dit is de gouden standaard voor remote access management in OT-omgevingen.

Network segmentatie met jump servers: Plaats een beveiligde jump server tussen het externe netwerk en uw OT-netwerk. Alle remote toegang loopt via deze jump server. Dit geeft u een centraal controlepunt waar u kunt loggen, monitoren en beperken.

MFA overal: Multifactor-authenticatie op alle toegangspunten. Geen uitzonderingen. Moderne MFA-oplossingen werken ook met industriele systemen en VPN-verbindingen. Als uw leverancier zegt dat het niet kan, vraag dan een andere leverancier.

Periodieke credential audits: Plan minimaal halfjaarlijks een audit van alle credentials in uw OT-omgeving. Controleer op standaardwachtwoorden, gedeelde accounts, inactieve accounts en accounts van voormalige medewerkers of leveranciers.

Het gesprek met uw leverancier

Het lastigste deel is vaak niet de techniek, maar het gesprek met de leverancier. Veel OT-leveranciers zijn gewend aan hun manier van werken en zien beveiligingseisen als obstakel. Toch is dit gesprek essentieel.

Begin met het stellen van vragen, niet met het opleggen van eisen. "Hoe beheren jullie de credentials voor remote access bij jullie klanten?" "Wat gebeurt er met accounts wanneer een monteur uit dienst gaat?" "Hoe worden wachtwoorden opgeslagen aan jullie kant?" De antwoorden op deze vragen vertellen u alles wat u moet weten.

Als de antwoorden onbevredigend zijn — en dat zullen ze vaak zijn — dan heeft u een concreet verbeterpunt dat u contractueel kunt vastleggen. Maak het onderdeel van uw servicecontract. Geef de leverancier een redelijke termijn om te voldoen. En als hij niet wil meewerken, overweeg dan een alternatieve leverancier. Uw beveiliging is te belangrijk om afhankelijk te maken van de goede wil van een derde partij.