Assets op afstand monitoren of zelfs aansturen. Niet alleen industriële bedrijven met machineparken in hun fabrieken willen daaraan, het is ook interessant voor organisaties met zogenaamde remote assets, zoals windmolenparken, treinen, tunnelinstallaties of boorplatformen.
Daarbij wordt de operationele technologie (ot) waar deze assets gebruik van maken – programmable logic controllers (plc’s), supervisory control and data acquisition (scada) en manufacturing execution system (mes) – gekoppeld aan it en verrijkt met data. Door deze koppeling met it wordt het voor hackers ineens mogelijk binnen te dringen in systemen zonder fysiek op locatie te hoeven zijn. Het is daarom zaak ook de ot te beveiligen tegen cyberdreigingen.
Dat is iets wat tot nu toe nauwelijks gebeurt. Dat is niet vreemd, want it en ot zijn altijd gescheiden werelden geweest. Voor ot was het voldoende om de locatie fysiek te beveiligen met bijvoorbeeld camera’s en een groot hek. Als de operations manager of plant director er al aan denkt om zijn ot ook te beveiligen tegen virtuele gevaren, dan krijgt hij van de it-afdeling of van leveranciers vaak een net iets te makkelijk advies. Want de meeste it’ers zijn zich er niet van bewust dat ot zich anders gedraagt dan it – en dus een andere vorm van beveiliging nodig heeft. Ze zijn zich evenmin bewust van de potentiële schade die een hack in de ot-omgeving kan veroorzaken en denken dat het afdoende is om bijvoorbeeld iot-oplossingen op het gebied van remote monitoring en predictive maintenance te beveiligen met slechts een viercijferig wachtwoord. Wie wat langer in deze wereld rondloopt, komt van alles tegen. Van slecht beveiligde verbindingen tot pc’s die al jaren niet zijn geüpdatet. Noodzakelijk dus om door een andere bril te kijken naar ot in het algemeen en de beveiliging van ot in het bijzonder
Security-by-design voor ot
Je zult ook voor ot een security-by-design-aanpak moeten hanteren. Dat betekent dat je systemen van de grond af aan opnieuw zult moeten opbouwen. Dat lijkt arbeidsintensief, maar het heeft voordelen. Want als it en (de it voor) ot op dezelfde manier functioneren, is het eenvoudiger om koppelingen tussen beide omgevingen aan te brengen. Dat kan ook eenvoudig zonder nieuwe securityrisico’s te introduceren, want beide omgevingen zijn nu immers vanuit een security-by-design-gedachte ontworpen. Je kunt die nieuw ontworpen systemen bovendien makkelijk onderbrengen in de cloud en daarmee profiteren van alle voordelen die de cloud biedt, zoals het ontkoppelen van hardware, software en data, waardoor de wendbaarheid en flexibiliteit van ot toeneemt, zonder dat de beschikbaarheid en betrouwbaarheid afneemt. Je kunt oudere assets toekomstbestendig maken doordat de aansturing vanuit de cloud gebeurt. Dat geeft je de mogelijkheid om verouderde software eenvoudig te laten samenwerken met moderne technologie, denk bijvoorbeeld aan machine learning (ml)-algoritmen. Hierdoor kun je nauwgezetter voorspellen welke assets wanneer onderhoud nodig hebben en zo de uptime verhogen. Daarnaast wordt er bespaard op kosten doordat is in te grijpen voordat defecten ontstaan.
Security-as-code
Het ombouwen van it voor ot-systemen gebeurt via een devops-werkwijze. Net als in de it werken we ook in de ot met containers. Dat betekent dat een bestaande plc wordt gecontaineriseerd en voorzien van de juiste integraties en de juiste mate van security. Waar bij de traditionele manier van software ontwikkelen pas achteraf werd nagedacht over de beveiliging van systemen, wordt bij de devops-manier van werken security vanaf het begin af aan meegenomen in de ontwikkeling van de code. We noemen dit ook wel security-as-code. Het uiteindelijke doel van de software is het uitgangspunt voor de securitymaatregelen die je neemt. Als dat doel is om op afstand een fabrieksband stil te zetten vanwege een probleem, dan hoort het bij het doel dat deze functie ook beveiligd moet worden tegen misbruik van deze mogelijkheid. In de devops-werkwijze let je dus vanaf de eerste fase van de ontwikkeling scherp op eventuele kwetsbaarheden in de ot die je containeriseert en op zaken als access control en policy management. Daardoor is security geen pleister meer die je achteraf op een open wond plakt, maar het is een werkwijze die voorkomt dat er wonden ontstaan.
NIST-raamwerk
Bij het containeriseren van ot biedt het raamwerk van de National Institute of Standards and Technology (NIST) goede handreikingen, beschrijvingen en uitgangspunten voor het beveiligen van de container. De NIST sluit ook goed aan bij de Nederlandse wet- en regelgeving, zoals ISO27001 en branchenormeringen zoals IEC62443, de standaard voor industriële communicatienetwerken.
Overigens, naast het beveiligen van de containers is monitoring uiteraard ook belangrijk. Daarom moet er een operations center zijn dat 24/7 monitort wat er in de omgeving gebeurt. Omdat ot-omgevingen anders in elkaar zitten dan it-omgevingen, worden aanvallen op de ot-omgeving ook op een andere manier gepleegd. Daarom is het belangrijk om een operations center te hebben, met medewerkers die verstand hebben van het ot-landschap en die weten wat er nodig is om monitoring en ketenregie voor ot in te richten.
Wil jouw organisatie assets op afstand gaan monitoren, uitlezen en misschien zelfs aansturen, kijk dan door de hier beschreven bril naar de beveiliging van de omgeving en ga er niet van uit dat een viercijferig password op een iot-device voldoende is.
(Auteur Neal Peters is it-architect bij Conclusion Mission Critical.)
De OT kent inderdaad vaak nog slecht beveiligde verbindingen en software welke al jaren niet gepatched is want veel embedded systemen zijn al enkele jaren End-of-Support maar zullen desondanks niet vervangen worden omdat de machines die ermee aangestuurd worden nog lang niet afgeschreven zijn. En veel oplossingen in het OT domain zijn functioneel nooit ontworpen met het idee van een aansluiting op Internet om zodoende dingen vanop afstand te kunnen doen als we kijken naar de ingebouwde toegangscontroles. Kortom, een leuk verhaal maar ik mis nog vooral de koppeling van rollen, functies en toestemmingen want oude code in een container stoppen is geen oplossing als we kijken naar de uitdaging met OT aangaande User Access Control welke misschien meer op claims gebasseerd moet zijn dan op toegewezen rollen als het gaat om de beveiliging. Oja, de OT kent ook nog zoiets als fysieke wisseling van componenten en het is dan ook handig als een service engineer toegang krijgt want assets die zichzelf monitoren en bij mogelijke problemen zelf de leverancier bellen is niet nieuw.
“Het ombouwen van it voor ot-systemen gebeurt via een devops-werkwijze. Net als in de it werken we ook in de ot met containers. Dat betekent dat een bestaande plc wordt gecontaineriseerd en voorzien van de juiste integraties en de juiste mate van security. ”
He Jack, zet deze eens op je https://dmcommunity.org/challenge/