💼 Management Samenvatting
Netwerksegmentatie volgens het Purdue-model vormt een kritieke beveiligingsmaatregel voor organisaties die IoT-apparaten inzetten in Azure cloudomgevingen. Deze beveiligingsmaatregel is essentieel voor het waarborgen van de beschikbaarheid, integriteit en vertrouwelijkheid van IoT-systemen die kritieke infrastructuren, slimme steden, en operationele technologie ondersteunen. Het Purdue-model biedt een bewezen referentie-architectuur die organisaties in staat stelt IoT-apparaten te segmenteren in verschillende beveiligingszones, waardoor de impact van beveiligingsincidenten wordt beperkt en laterale beweging door aanvallers wordt voorkomen.
Aanbeveling
IMPLEMENTEER IoT-NETWERKSEGMENTATIE VOLGENS PURDUE-MODEL
Risico zonder
Critical
Risk Score
10/10
Implementatie
180u (tech: 120u)
Van toepassing op:
✓ Azure IoT Hub
✓ Azure IoT Central
✓ Azure Virtual Networks
✓ Azure Network Security Groups
✓ Azure IoT Central
✓ Azure Virtual Networks
✓ Azure Network Security Groups
Zonder adequate netwerksegmentatie volgens het Purdue-model ontstaan er catastrofale beveiligingsrisico's die kunnen leiden tot gecompromitteerde IoT-apparaten, onderschepte of gemanipuleerde sensordata, en zelfs volledige controle over kritieke infrastructuren door kwaadwillende actoren. In een niet-gesegmenteerd IoT-netwerk kunnen cyberaanvallen die gericht zijn op één IoT-apparaat zich snel verspreiden naar andere apparaten en naar backend-systemen, waardoor aanvallers directe controle kunnen krijgen over hele IoT-ecosystemen. Dit kan resulteren in het manipuleren van sensormetingen waardoor verkeerde beslissingen worden genomen, het uitschakelen van kritieke IoT-apparaten waardoor dienstverlening wordt verstoord, of zelfs het veroorzaken van fysieke schade aan apparatuur en installaties. Voor Nederlandse organisaties die IoT-apparaten inzetten voor kritieke infrastructuren, zoals energiebedrijven, waterbeheerders, transportoperators en slimme steden, is het ontbreken van IoT-netwerksegmentatie bovendien een directe schending van de NIS2-richtlijn en de Baseline Informatiebeveiliging Overheid (BIO) normen. Het niet voldoen aan deze vereisten kan leiden tot aanzienlijke boetes, verplichte verbeteracties en in extreme gevallen tot het stopzetten van dienstverlening. De gevolgen van een succesvolle aanval op IoT-systemen kunnen maatschappijbreed zijn, waarbij hele regio's zonder kritieke diensten kunnen komen te zitten, of waarbij transportnetwerken kunnen worden verstoord met grote economische en sociale gevolgen.
PowerShell Modules Vereist
Primary API: Azure Network API
Connection:
Required Modules: Az.Network, Az.IotHub, Az.Accounts
Connection:
Connect-AzAccountRequired Modules: Az.Network, Az.IotHub, Az.Accounts
Implementatie
IoT-netwerksegmentatie volgens het Purdue-model in Azure betekent het implementeren van een strikt gescheiden netwerkarchitectuur die IoT-apparaten volledig isoleert van enterprise IT-systemen, waarbij verschillende zones worden gecreëerd volgens het Purdue-model: Level 0 (veldapparatuur zoals sensoren en actuatoren), Level 1 (edge-apparaten en gateways), Level 2 (supervisory control and data acquisition of SCADA systemen), Level 3 (manufacturing execution systems of MES en data-opslag), en Level 4 (enterprise IT-systemen en business applicaties). Binnen elk niveau worden verder subnetten aangemaakt voor specifieke functies zoals device-to-cloud messaging, cloud-to-device commands, historische data-opslag, en analytics-workloads, waarbij netwerkbeveiligingsgroepen (NSGs) en Azure Firewall functioneren als strikte scheidingswanden die alleen specifiek geautoriseerd verkeer tussen zones toestaan volgens het principe van minimale privileges. Deze segmentatie zorgt ervoor dat zelfs wanneer een aanvaller toegang krijgt tot IoT-apparaten op Level 0 of Level 1, zij niet automatisch toegang krijgen tot backend-systemen op hogere niveaus, waardoor kritieke data en processen beschermd blijven tegen cyberaanvallen.
Vereisten
IoT-netwerksegmentatie volgens het Purdue-model vormt een van de meest complexe en kritieke beveiligingsmaatregelen die organisaties kunnen implementeren voor IoT-omgevingen, en vereist een uitgebreide voorbereiding die verder gaat dan standaard IT-netwerksegmentatie. Deze beveiligingsmaatregel is geen eenvoudige technische configuratie, maar een strategische architecturale beslissing die diepgaand inzicht vereist in IoT-architectuur, device-communicatiepatronen, gegevensclassificatie, beveiligingsvereisten en compliance-vereisten voor kritieke infrastructuren. Voordat organisaties kunnen beginnen met het segmenteren van hun IoT-netwerken volgens het Purdue-model, moeten zij een grondige analyse uitvoeren van hun huidige IoT-infrastructuur, de communicatiepatronen tussen verschillende IoT-componenten, de gevoeligheid en kritiekheid van elk IoT-apparaat en de data die wordt verzonden, en de specifieke beveiligings- en compliance-vereisten die van toepassing zijn. Deze analyse moet niet alleen technische aspecten omvatten, maar ook operationele, organisatorische, financiële en compliance-gerelateerde overwegingen. Organisaties moeten begrijpen welke IoT-apparaten zij beheren, hoe deze apparaten met elkaar communiceren via verschillende protocollen zoals MQTT, AMQP, HTTPS of CoAP, welke gegevens zij verwerken en hoe gevoelig deze gegevens zijn, welke specifieke beveiligings- en compliance-vereisten van toepassing zijn zoals NIS2, BIO of sector-specifieke normen, en wat de impact zou zijn van een beveiligingsincident op elk Purdue-niveau. Zonder deze grondige voorbereiding is het onmogelijk om een effectieve IoT-netwerksegmentatie te ontwerpen die zowel beveiliging als operationele continuïteit waarborgt.
De primaire technische vereiste voor IoT-netwerksegmentatie volgens het Purdue-model is de beschikbaarheid en beheersbaarheid van virtuele netwerken (VNets) in Azure die specifiek zijn geconfigureerd voor IoT-workloads. Een VNet vormt een geïsoleerde netwerkomgeving waarin cloudresources kunnen worden geplaatst en geconfigureerd, maar voor IoT-toepassingen moeten deze netwerken worden geoptimaliseerd voor lage latentie, hoge beschikbaarheid en schaalbaarheid die vereist is voor real-time IoT-communicatie. Voor effectieve IoT-segmentatie moeten organisaties niet alleen beschikken over de technische mogelijkheid om meerdere VNets aan te maken, maar ook over de organisatorische capaciteit om deze te beheren en te onderhouden volgens IoT-best practices. Elk VNet vertegenwoordigt een specifiek Purdue-niveau, waarbij Level 4 (Enterprise IT) strikt gescheiden wordt van Level 3 (MES en data-opslag), Level 2 (SCADA), Level 1 (edge-apparaten en gateways) en Level 0 (veldapparatuur). Deze scheiding voorkomt dat incidenten in IT-systemen kunnen overslaan naar kritieke IoT-systemen die fysieke processen monitoren en aansturen. Het is belangrijk om te begrijpen dat het aanmaken van VNets niet voldoende is; organisaties moeten ook beschikken over de kennis en tools om deze netwerken effectief te beheren, te monitoren en te onderhouden met specifieke aandacht voor IoT-vereisten zoals device-to-cloud messaging, cloud-to-device commands, en real-time data processing. Dit omvat het begrijpen van VNet-peering tussen IoT-zones, routeeringsconfiguraties die rekening houden met IoT-protocollen, DNS-instellingen die compatibel zijn met IoT-device naming-conventies, en de integratie met andere Azure-services zoals Azure IoT Hub, Azure IoT Central, Azure Digital Twins of Azure Time Series Insights die specifiek zijn ontworpen voor IoT-toepassingen.
Naast de beschikbaarheid van VNets zijn netwerkbeveiligingsgroepen (NSGs) en Azure Firewall absoluut essentieel voor het daadwerkelijk implementeren van IoT-netwerksegmentatie, maar deze moeten worden geconfigureerd met specifieke aandacht voor IoT-protocollen en device-communicatiepatronen. NSGs fungeren als virtuele firewalls die verkeer tussen netwerksegmenten kunnen filteren en controleren op basis van gedefinieerde beveiligingsregels, maar voor IoT-toepassingen moeten deze regels rekening houden met specifieke IoT-protocollen zoals MQTT (poort 8883 voor TLS), AMQP (poort 5671 voor TLS), HTTPS (poort 443), CoAP (poort 5683), en andere IoT-protocollen die niet standaard zijn in IT-omgevingen. Zonder NSGs zou IoT-segmentatie slechts een logische scheiding zijn zonder daadwerkelijke beveiligingscontrole, waardoor aanvallers nog steeds vrijelijk tussen IoT-zones kunnen bewegen en toegang kunnen krijgen tot kritieke device-communicatie en backend-systemen. Organisaties moeten daarom beschikken over expertise in het ontwerpen en configureren van NSG-regels die zowel beveiliging als operationele continuïteit waarborgen, waarbij zij rekening houden met de specifieke vereisten van IoT-apparaten zoals real-time communicatie, lage latentie en hoge beschikbaarheid. Het is cruciaal om te begrijpen dat NSG-regels moeten worden ontworpen volgens het principe van minimale privileges, waarbij alleen het absoluut noodzakelijke verkeer wordt toegestaan tussen IoT-zones, maar dat deze regels ook moeten rekening houden met de operationele vereisten van IoT-apparaten die kunnen worden verstoord door te restrictieve firewallregels. Verkeerd geconfigureerde NSG-regels kunnen ofwel de beveiliging ondermijnen door te permissief te zijn en ongeautoriseerd verkeer tussen zones toe te staan, ofwel de operationele continuïteit belemmeren door te restrictief te zijn en legitieme device-communicatie te blokkeren waardoor IoT-apparaten niet meer kunnen functioneren.
Een goed doordacht en gedocumenteerd IoT-netwerkontwerp vormt de derde kritieke vereiste voor succesvolle IoT-netwerksegmentatie volgens het Purdue-model, en dit ontwerp moet gebaseerd zijn op erkende IoT-referentie-architecturen zoals het Purdue-model, ISA/IEC 62443 voor industriële IoT, of NIST SP 800-213 voor IoT-beveiliging. Organisaties moeten een architectuur ontwikkelen die rekening houdt met de verschillende niveaus van IoT-systemen volgens het Purdue-model, de gevoeligheid en kritiekheid van elk IoT-apparaat, de communicatiepatronen tussen apparaten via verschillende IoT-protocollen, en de specifieke beveiligingsvereisten die van toepassing zijn voor kritieke infrastructuren. Dit ontwerp moet uitgebreid documenteren welke subnetten nodig zijn voor elk Purdue-niveau, hoe deze subnetten met elkaar mogen communiceren volgens het principe van minimale privileges maar met aandacht voor operationele vereisten, welke specifieke beveiligingsregels van toepassing zijn voor elk segment, en hoe de segmentatie aansluit bij IoT-standaarden en best practices. Het IoT-netwerkontwerp dient ook rekening te houden met toekomstige groei, schaalbaarheid en wijzigingen in IoT-implementaties, zodat segmentatie flexibel kan worden aangepast zonder de gehele architectuur te moeten herzien of zonder IoT-dienstverlening te verstoren. Dit vereist vaak samenwerking tussen netwerkarchitecten, IoT-beveiligingsfunctionarissen, device-ingenieurs en applicatie-eigenaren die diepgaand begrip hebben van zowel IT-beveiliging als IoT-operationele vereisten. Het ontwerp moet niet alleen technische specificaties bevatten, maar ook duidelijke documentatie over de rationale achter elke beslissing, de beveiligingsdoelstellingen die worden nagestreefd, de operationele vereisten die moeten worden gewaarborgd, en de procedures voor het beheren en onderhouden van de segmentatie zonder IoT-dienstverlening te verstoren. Een goed IoT-netwerkontwerp is een levend document dat regelmatig wordt bijgewerkt wanneer de organisatie groeit, wanneer nieuwe IoT-apparaten worden toegevoegd, of wanneer wijzigingen worden doorgevoerd in bestaande IoT-implementaties. Het ontwerp moet ook rekening houden met verschillende scenario's, zoals failover-situaties waarbij IoT-apparaten moeten kunnen communiceren met back-up systemen zonder de segmentatie te verzwakken, of disaster recovery-scenario's waarbij segmentatie tijdelijk moet worden aangepast om hersteloperaties mogelijk te maken zonder de beveiliging te ondermijnen.
Voor Nederlandse organisaties die IoT-apparaten inzetten voor kritieke infrastructuren komen hierbij aanvullende nalevingsvereisten kijken die het implementatieproces complexer maken. De NIS2-richtlijn, die is geïmplementeerd in Nederlandse wetgeving via de Wet beveiliging netwerk- en informatiesystemen, stelt specifieke en bindende eisen aan netwerkbeveiliging voor essentiële en belangrijke entiteiten in sectoren zoals energie, transport, gezondheidszorg en digitale infrastructuur. Deze eisen omvatten onder meer netwerksegmentatie als een technische maatregel om de beschikbaarheid, integriteit en vertrouwelijkheid van netwerken en informatiesystemen te waarborgen, en organisaties moeten tijdens toezicht-inspecties door de Autoriteit Consument en Markt (ACM) kunnen aantonen dat zij passende en effectieve maatregelen hebben genomen om hun IoT-netwerken te beveiligen. De Baseline Informatiebeveiliging Overheid (BIO) stelt bovendien specifieke eisen aan netwerksegmentatie in norm 13.01, en organisaties moeten kunnen aantonen dat hun IoT-netwerkarchitectuur niet alleen technisch correct is, maar ook volledig voldoet aan deze normen. Dit betekent dat het IoT-netwerkontwerp uitgebreid moet worden gedocumenteerd op een wijze die geschikt is voor audits en compliance-controles, waarbij elke beslissing moet worden onderbouwd en gerechtvaardigd met aandacht voor zowel beveiliging als operationele continuïteit. Organisaties moeten procedures hebben voor het beoordelen en goedkeuren van wijzigingen aan de IoT-netwerkconfiguratie, en moeten kunnen aantonen dat segmentatie actief wordt beheerd en gemonitord zonder de operationele continuïteit te verstoren. Het niet voldoen aan NIS2-vereisten of BIO-normen kan leiden tot aanzienlijke boetes (tot 10 miljoen euro of 2% van de wereldwijde jaaromzet voor NIS2), formele bevindingen tijdens audits, verplichte verbeteracties, en in extreme gevallen tot het stopzetten van dienstverlening. Daarom is het van cruciaal belang dat Nederlandse organisaties die IoT-apparaten inzetten voor kritieke infrastructuren hun IoT-netwerksegmentatie niet alleen technisch correct implementeren, maar ook kunnen aantonen dat zij voldoen aan alle relevante normen en regelgeving. NIS2-toezicht-inspecties en BIO-audits zullen specifiek evalueren of organisaties kunnen aantonen dat hun IoT-netwerksegmentatie is gebaseerd op een risico-analyse, dat de architectuur regelmatig wordt geëvalueerd op effectiviteit, dat er procedures zijn voor het beheren en onderhouden van segmentatie zonder IoT-dienstverlening te verstoren, en dat er regelmatig testen worden uitgevoerd om te verifiëren dat segmentatie effectief werkt zonder de operationele continuïteit te belemmeren.
Implementatie
Gebruik PowerShell-script network-segmentation-purdue.ps1 (functie Invoke-Remediation) – Configureert IoT-netwerksegmentatie volgens het Purdue-model.
De implementatie van IoT-netwerksegmentatie volgens het Purdue-model begint met het navigeren naar de Azure Portal en het selecteren van de resource group waarin de IoT-netwerkarchitectuur moet worden opgezet. Vanuit het Virtual Networks menu worden nieuwe virtuele netwerken aangemaakt voor elk Purdue-niveau, waarbij elk VNet wordt geconfigureerd met een unieke adresruimte die niet overlapt met andere VNets. De configuratiewizard leidt gebruikers stap voor stap door het volledige opzetten van de IoT-netwerkarchitectuur, waarbij duidelijke instructies en contextuele hulp worden geboden om configuratiefouten te minimaliseren. Het is belangrijk om te begrijpen dat de implementatie van IoT-netwerksegmentatie een gefaseerde aanpak vereist, waarbij eerst de VNet-architectuur wordt opgezet, gevolgd door de configuratie van subnetten binnen elk VNet, en ten slotte de implementatie van NSG-regels en Azure Firewall-regels die de communicatie tussen zones controleren.
Voor Level 0 (veldapparatuur) wordt een gescheiden VNet aangemaakt dat specifiek is geconfigureerd voor IoT-sensoren en actuatoren die direct verbonden zijn met fysieke processen. Dit VNet wordt geconfigureerd met subnetten voor verschillende typen veldapparatuur, zoals temperatuursensoren, druksensoren, bewegingsdetectoren, en actuatoren zoals motoren en kleppen. NSG-regels worden geconfigureerd die alleen outbound-communicatie toestaan naar Level 1 (edge-apparaten en gateways), waarbij specifieke IoT-protocollen zoals MQTT of CoAP worden toegestaan op de benodigde poorten. Inbound-communicatie naar Level 0 wordt strikt beperkt, waarbij alleen specifieke cloud-to-device commands worden toegestaan vanuit Level 1 of Level 2, en alleen voor geautoriseerde apparaten die zijn geverifieerd via device identity management. Deze strikte configuratie zorgt ervoor dat veldapparatuur niet direct kan worden benaderd vanuit internet of vanuit enterprise IT-systemen, waardoor de aanvalsoppervlakte wordt geminimaliseerd en de beveiliging wordt verbeterd.
Voor Level 1 (edge-apparaten en gateways) wordt een gescheiden VNet aangemaakt dat fungeert als tussenlaag tussen veldapparatuur en backend-systemen. Edge-apparaten verzamelen data van veldapparatuur, voeren lokale processing uit, en sturen geaggregeerde data door naar hogere niveaus. Dit VNet wordt geconfigureerd met subnetten voor verschillende typen edge-apparaten, zoals IoT-gateways, edge-computing devices, en protocol-converters. NSG-regels worden geconfigureerd die communicatie toestaan met Level 0 voor het verzamelen van sensordata, communicatie met Level 2 voor het doorsturen van geaggregeerde data, en communicatie met Azure IoT Hub voor device-to-cloud messaging. Edge-apparaten fungeren vaak als eerste verdedigingslinie tegen aanvallen, waarbij zij lokale filtering en detectie kunnen uitvoeren voordat data wordt doorgestuurd naar backend-systemen. Daarom moeten NSG-regels ook rekening houden met de mogelijkheid dat edge-apparaten security events genereren die moeten worden doorgestuurd naar security monitoring-systemen op Level 3 of Level 4.
Voor Level 2 (SCADA en supervisory control) wordt een gescheiden VNet aangemaakt dat specifiek is geconfigureerd voor systemen die IoT-data verzamelen, visualiseren en controleren. SCADA-systemen ontvangen data van edge-apparaten, presenteren deze data aan operators via human-machine interfaces (HMI), en sturen control-commands terug naar edge-apparaten en veldapparatuur. Dit VNet wordt geconfigureerd met subnetten voor SCADA-servers, HMI-workstations, historische data-opslag, en alarm-systemen. NSG-regels worden geconfigureerd die communicatie toestaan met Level 1 voor het ontvangen van IoT-data, communicatie met Level 3 voor het doorsturen van geaggregeerde data naar MES-systemen, en communicatie met Azure IoT Hub voor het synchroniseren van device twins en het ontvangen van cloud-to-device commands. Level 2 vormt een kritieke laag in de IoT-architectuur, omdat deze laag directe controle heeft over fysieke processen via edge-apparaten en veldapparatuur. Daarom moeten NSG-regels extra restrictief zijn, waarbij alleen geautoriseerde SCADA-systemen en HMI-workstations toegang hebben tot Level 1 en Level 0, en waarbij alle communicatie wordt gelogd voor audit-doeleinden.
Voor Level 3 (MES en data-opslag) wordt een gescheiden VNet aangemaakt dat specifiek is geconfigureerd voor manufacturing execution systems, data-opslag, analytics-workloads, en business intelligence-systemen. MES-systemen ontvangen geaggregeerde data van SCADA-systemen, voeren business logic uit, genereren rapporten, en sturen instructies terug naar SCADA-systemen. Dit VNet wordt geconfigureerd met subnetten voor MES-servers, data warehouses, analytics-workloads zoals Azure Stream Analytics of Azure Databricks, en reporting-systemen. NSG-regels worden geconfigureerd die communicatie toestaan met Level 2 voor het ontvangen van geaggregeerde IoT-data, communicatie met Level 4 voor het delen van business data met enterprise IT-systemen, en communicatie met Azure-services zoals Azure IoT Hub, Azure Time Series Insights, en Azure Digital Twins. Level 3 vormt de brug tussen operationele technologie (OT) en informatietechnologie (IT), waarbij business data wordt gegenereerd op basis van operationele IoT-data. Daarom moeten NSG-regels zorgvuldig worden geconfigureerd om te voorkomen dat IT-systemen direct toegang krijgen tot OT-systemen, terwijl wel de benodigde data-uitwisseling mogelijk blijft voor business-doeleinden.
Voor Level 4 (enterprise IT) wordt een gescheiden VNet aangemaakt dat specifiek is geconfigureerd voor enterprise IT-systemen, business applicaties, en gebruikerswerkplekken. Enterprise IT-systemen ontvangen business data van MES-systemen, voeren enterprise resource planning (ERP) uit, genereren management-rapportages, en bieden toegang voor gebruikers via web-applicaties of mobiele apps. Dit VNet wordt geconfigureerd met subnetten voor ERP-servers, web-applicaties, databases, gebruikerswerkplekken, en management-systemen. NSG-regels worden geconfigureerd die communicatie toestaan met Level 3 voor het ontvangen van business data, maar die strikt voorkomen dat enterprise IT-systemen direct toegang krijgen tot lagere Purdue-niveaus. Deze strikte scheiding zorgt ervoor dat cyberaanvallen op IT-systemen niet automatisch kunnen overslaan naar kritieke IoT-systemen, waardoor de beveiliging wordt verbeterd en de impact van beveiligingsincidenten wordt beperkt.
Na het configureren van alle VNets en subnetten voor elk Purdue-niveau is het essentieel om VNet-peering te configureren tussen de verschillende niveaus, waarbij alleen specifieke peering-verbindingen worden toegestaan die nodig zijn voor de beoogde communicatiepatronen. VNet-peering maakt het mogelijk dat resources in verschillende VNets met elkaar kunnen communiceren via privé IP-adressen, zonder dat verkeer via internet hoeft te gaan. Voor IoT-netwerksegmentatie moeten peering-verbindingen worden geconfigureerd tussen aangrenzende Purdue-niveaus, zoals tussen Level 0 en Level 1, tussen Level 1 en Level 2, tussen Level 2 en Level 3, en tussen Level 3 en Level 4. Peering-verbindingen tussen niet-aangrenzende niveaus, zoals directe peering tussen Level 0 en Level 4, moeten strikt worden voorkomen om de beveiliging te waarborgen. Elke peering-verbinding moet worden geconfigureerd met de juiste routeeringsinstellingen, waarbij alleen specifieke adresruimten worden toegestaan voor communicatie, en waarbij NSG-regels worden toegepast om de communicatie verder te beperken tot alleen geautoriseerd verkeer.
Azure Firewall kan worden geconfigureerd als een centrale firewall tussen verschillende Purdue-niveaus, waarbij geavanceerde firewallregels worden toegepast die verder gaan dan de mogelijkheden van NSGs. Azure Firewall biedt ondersteuning voor application-level filtering, threat intelligence-based filtering, en geavanceerde logging en monitoring die essentieel zijn voor het detecteren en reageren op beveiligingsincidenten. Voor IoT-netwerksegmentatie kan Azure Firewall worden geconfigureerd tussen Level 3 en Level 4, waarbij business data wordt gefilterd en gecontroleerd voordat deze wordt doorgestuurd naar enterprise IT-systemen. Azure Firewall kan ook worden gebruikt voor het filteren van internet-verkeer naar IoT-apparaten, waarbij alleen geautoriseerde communicatie wordt toegestaan en waarbij kwaadaardig verkeer wordt geblokkeerd op basis van threat intelligence. De configuratie van Azure Firewall vereist expertise in firewall-beheer en IoT-beveiliging, en moet worden uitgevoerd door ervaren beveiligingsprofessionals die volledig begrijpen hoe de firewallregels de IoT-communicatie beïnvloeden.
Na het configureren van alle VNets, subnetten, NSG-regels en Azure Firewall-regels is het essentieel om de voortgang actief te monitoren en ervoor te zorgen dat alle IoT-apparaten correct zijn geplaatst in de juiste netwerksegmenten. Azure Network Watcher biedt uitgebreide monitoring-functionaliteit die real-time inzicht geeft in netwerkverkeer, connectiviteit, en beveiligingsgebeurtenissen. Beheerders kunnen dashboards configureren die waarschuwingen genereren wanneer IoT-apparaten worden gedetecteerd in de verkeerde netwerksegmenten, wanneer ongebruikelijk verkeer wordt gedetecteerd tussen Purdue-niveaus, of wanneer beveiligingsincidenten worden gedetecteerd die kunnen wijzen op een aanval op de IoT-netwerksegmentatie. Deze monitoring helpt om problemen vroegtijdig te detecteren en zorgt ervoor dat de IoT-netwerksegmentatie effectief blijft functioneren zonder onnodige operationele impact.
Compliance en Auditing
IoT-netwerksegmentatie volgens het Purdue-model vormt een fundamentele en verplichte beveiligingsmaatregel die wordt vereist door meerdere internationale en nationale compliance-frameworks, normen en wetgeving, met specifieke aandacht voor kritieke infrastructuren. Voor Nederlandse organisaties die IoT-apparaten inzetten voor kritieke infrastructuren, zoals energiebedrijven, waterbeheerders, transportoperators en slimme steden, is het van cruciaal strategisch belang om te kunnen aantonen dat IoT-netwerksegmentatie niet alleen correct is geïmplementeerd, maar ook actief wordt onderhouden, gemonitord en geëvalueerd, omdat dit een verplicht onderdeel vormt van verschillende normen en wetgeving waar niet-naleving kan leiden tot aanzienlijke consequenties zoals boetes, verplichte verbeteracties en in extreme gevallen tot het stopzetten van dienstverlening. Compliance met deze normen is niet alleen een technische uitdaging, maar vereist ook een goed begrip van de specifieke eisen van elk framework en de manier waarop deze eisen kunnen worden aangetoond tijdens audits en toezicht-inspecties, waarbij rekening moet worden gehouden met zowel beveiliging als operationele continuïteit.
De NIS2-richtlijn, die is geïmplementeerd in Nederlandse wetgeving via de Wet beveiliging netwerk- en informatiesystemen, bevat in artikel 21 specifieke en bindende eisen aan netwerkbeveiliging voor essentiële en belangrijke entiteiten in sectoren zoals energie, transport, gezondheidszorg en digitale infrastructuur. Deze eisen omvatten onder meer netwerksegmentatie als een technische maatregel om de beschikbaarheid, integriteit en vertrouwelijkheid van netwerken en informatiesystemen te waarborgen, en organisaties moeten tijdens toezicht-inspecties door de Autoriteit Consument en Markt (ACM) kunnen aantonen dat zij passende en effectieve maatregelen hebben genomen om hun IoT-netwerken te beveiligen, waarbij specifieke aandacht wordt besteed aan de scheiding tussen IT en OT systemen. Nederlandse organisaties die onder de reikwijdte van NIS2 vallen moeten tijdens toezicht-inspecties kunnen aantonen dat zij passende en effectieve maatregelen hebben genomen om hun IoT-netwerken te beveiligen, waaronder uitgebreide netwerksegmentatie die rekening houdt met de specifieke vereisten van IoT-apparaten. Het niet voldoen aan NIS2-vereisten kan leiden tot boetes tot 10 miljoen euro of 2% van de wereldwijde jaaromzet, verplichte verbeteracties en in extreme gevallen tot het stopzetten van dienstverlening.
De Baseline Informatiebeveiliging Overheid (BIO), het verplichte informatiebeveiligingsframework voor alle Nederlandse overheidsorganisaties, bevat in norm 13.01 zeer specifieke en bindende eisen aan netwerksegmentatie die ook van toepassing zijn op IoT-netwerken. Deze norm vereist niet alleen dat organisaties hun netwerken segmenteren om de impact van beveiligingsincidenten te beperken en om te voorkomen dat aanvallers zich lateraal door het netwerk kunnen bewegen, maar stelt ook eisen aan de documentatie, het beheer en de monitoring van segmentatie met aandacht voor zowel beveiliging als operationele continuïteit. Nederlandse overheidsorganisaties die IoT-apparaten inzetten voor kritieke infrastructuren moeten tijdens BIO-audits kunnen aantonen dat hun IoT-netwerkarchitectuur volledig voldoet aan deze eisen, dat segmentatie actief wordt beheerd volgens gedocumenteerde procedures die rekening houden met operationele vereisten, en dat regelmatige evaluaties plaatsvinden om te verifiëren dat segmentatie effectief blijft zonder IoT-dienstverlening te verstoren. Het niet voldoen aan BIO-normen kan leiden tot formele bevindingen, verplichte verbeteracties en in extreme gevallen tot het stopzetten van dienstverlening.
De ISO 27001:2022 standaard, controle A.8.20 (Networks security), bevat uitgebreide vereisten voor netwerkbeveiliging die netwerksegmentatie als een kernmaatregel omvatten, en deze vereisten zijn ook van toepassing op IoT-netwerken. Organisaties die gecertificeerd zijn of willen worden volgens ISO 27001 moeten tijdens certificatie-audits kunnen aantonen dat hun IoT-netwerken zijn beveiligd tegen ongeautoriseerde toegang, dat verkeer tussen verschillende delen van het netwerk wordt gecontroleerd en gefilterd met aandacht voor IoT-protocollen, en dat er adequate logging en monitoring plaatsvindt zonder IoT-dienstverlening te verstoren. Dit vereist uitgebreide documentatie van de IoT-netwerkarchitectuur, bewijs dat beveiligingsmaatregelen effectief zijn door middel van testresultaten en monitoring-data, en procedures voor het beheren en onderhouden van IoT-netwerksegmentatie zonder operationele continuïteit te verstoren. ISO 27001-auditors zullen ook evalueren of IoT-segmentatie is gebaseerd op een risico-analyse en of de maatregelen proportioneel zijn ten opzichte van de geïdentificeerde risico's, waarbij rekening wordt gehouden met zowel beveiliging als operationele vereisten.
IEC 62443, de internationale standaard voor industriële cybersecurity, bevat uitgebreide vereisten voor netwerksegmentatie in industriële omgevingen die specifiek zijn ontworpen voor IoT-netwerken in industriële settings. Deze standaard definieert verschillende security zones en conduits die moeten worden geïmplementeerd om industriële IoT-systemen te beschermen, en organisaties die deze standaard volgen moeten tijdens certificatie-audits kunnen aantonen dat hun IoT-netwerksegmentatie voldoet aan de specifieke eisen van deze standaard. IEC 62443-audits zullen specifiek evalueren of organisaties kunnen aantonen dat zij hun IoT-netwerken hebben gesegmenteerd volgens de gedefinieerde security zones, dat zij procedures hebben voor het beheren en monitoren van segmentatie zonder IoT-dienstverlening te verstoren, en dat zij regelmatig evalueren of segmentatie nog steeds effectief is zonder de operationele continuïteit te belemmeren.
Monitoring
Gebruik PowerShell-script network-segmentation-purdue.ps1 (functie Invoke-Monitoring) – Controleert de configuratie en status van IoT-netwerksegmentatie volgens het Purdue-model.
Effectieve monitoring van IoT-netwerksegmentatie volgens het Purdue-model is essentieel om te waarborgen dat de beveiligingsarchitectuur correct blijft functioneren in een dynamische IoT-omgeving zonder de operationele continuïteit te verstoren. Organisaties moeten periodiek en systematisch de IoT-netwerktopologie beoordelen om te verifiëren dat segmentatie niet alleen correct is geïmplementeerd, maar ook blijft functioneren zoals bedoeld ondanks voortdurende wijzigingen in de cloudomgeving en in IoT-implementaties. Dit omvat het uitgebreid controleren van de configuratie van virtuele netwerken, subnetten en netwerkbeveiligingsgroepen om ervoor te zorgen dat beveiligingsregels correct zijn toegepast, dat er geen onbedoelde communicatie tussen IoT-zones mogelijk is, en dat nieuwe IoT-resources automatisch in de juiste segmenten worden geplaatst conform de gedefinieerde IoT-netwerkarchitectuur. Monitoring is geen eenmalige activiteit, maar een continu proces dat moet worden geïntegreerd in de dagelijkse operaties van de organisatie met specifieke aandacht voor de impact op IoT-dienstverlening. Zonder effectieve monitoring kan IoT-netwerksegmentatie geleidelijk worden verzwakt door wijzigingen, configuratiefouten of nieuwe implementaties, waardoor de beveiliging wordt ondermijnd zonder dat dit wordt opgemerkt, maar monitoring moet ook rekening houden met de operationele vereisten van IoT-apparaten die kunnen worden verstoord door te agressieve monitoring of door monitoringtools die te veel netwerkresources consumeren.
Een effectief en compleet IoT-monitoringproces begint met het grondig in kaart brengen en documenteren van de huidige IoT-netwerkarchitectuur, waarbij specifieke aandacht wordt besteed aan de verschillende Purdue-niveaus en de communicatiepatronen tussen deze niveaus. Dit betekent dat organisaties moeten beschikken over actuele, gedetailleerde netwerkdiagrammen die duidelijk en volledig tonen welke virtuele netwerken en subnetten bestaan voor elk Purdue-niveau, hoe deze met elkaar verbonden zijn via peering of gateways, welke netwerkbeveiligingsgroep-regels van toepassing zijn op elk segment met specifieke aandacht voor IoT-protocollen, en welke IoT-resources zich in elk segment bevinden. Deze documentatie moet niet alleen regelmatig worden bijgewerkt wanneer wijzigingen worden doorgevoerd in de IoT-netwerkconfiguratie, maar moet ook worden gebruikt als referentie voor nieuwe teamleden, als basis voor compliance-rapportages, en als hulpmiddel voor IoT-ingenieurs die moeten begrijpen hoe netwerksegmentatie de operationele processen beïnvloedt. Het ontbreken van actuele documentatie vormt een veelvoorkomende oorzaak van beveiligingsproblemen in IoT-omgevingen, omdat teams dan niet meer weten welke segmentatieregels van toepassing zijn en per ongeluk wijzigingen kunnen doorvoeren die de beveiliging ondermijnen of die IoT-dienstverlening kunnen verstoren.
Technische monitoring vormt de kern van een effectief IoT-segmentatiebeheerproces en kan worden uitgevoerd met behulp van gespecialiseerde tools zoals Azure Network Watcher, Azure Policy, Azure IoT Hub monitoring, en andere monitoringtools die diepgaand inzicht geven in IoT-netwerkverkeer, configuratie en compliance-status met specifieke aandacht voor IoT-protocollen en device-communicatiepatronen. Deze tools kunnen helpen bij het proactief identificeren van afwijkingen in de IoT-netwerkconfiguratie, zoals netwerkbeveiligingsgroep-regels die per ongeluk te permissief zijn ingesteld tijdens probleemoplossingsoperaties waardoor ongeautoriseerd verkeer tussen IoT-zones mogelijk wordt, subnetten die onbedoeld met elkaar kunnen communiceren door verkeerde peering-configuraties waardoor de scheiding tussen IT en OT wordt ondermijnd, of IoT-resources die in de verkeerde segmenten zijn geplaatst waardoor gevoelige device-data onbeschermd raakt of waardoor IoT-dienstverlening kan worden verstoord. Automatische controles en beleidsregels kunnen worden geconfigureerd om onmiddellijk waarschuwingen te genereren wanneer IoT-segmentatieregels worden gewijzigd, wanneer er ongebruikelijk verkeer tussen IoT-zones wordt gedetecteerd dat mogelijk wijst op een beveiligingsincident of op een configuratiefout die IoT-dienstverlening kan verstoren, of wanneer nieuwe IoT-resources worden aangemaakt zonder de juiste netwerkbeveiligingsgroep-toewijzingen waardoor zij buiten de beoogde beveiligingscontroles vallen.
Voor Nederlandse organisaties die IoT-apparaten inzetten voor kritieke infrastructuren is monitoring extra belangrijk en complex omdat zij moeten kunnen aantonen dat hun IoT-netwerksegmentatie niet alleen voldoet aan de eisen van de Baseline Informatiebeveiliging Overheid (BIO) en de NIS2-richtlijn, maar ook aan andere relevante normen zoals ISO 27001 en sector-specifieke normen zoals IEC 62443 voor industriële IoT-cybersecurity. Dit betekent dat monitoringresultaten uitgebreid moeten worden gedocumenteerd en bewaard voor audit-doeleinden volgens de vereiste bewaartermijnen, dat afwijkingen moeten worden geïdentificeerd, geclassificeerd op basis van risico en impact op zowel beveiliging als operationele continuïteit, en gecorrigeerd binnen acceptabele termijnen die zijn vastgelegd in beveiligingsbeleid maar die ook rekening houden met de impact op IoT-dienstverlening. Organisaties moeten ook kunnen aantonen dat zij procedures hebben voor het escaleren van kritieke afwijkingen naar management en beveiligingsfunctionarissen, en dat zij regelmatig management-rapportages genereren over de status van IoT-netwerksegmentatie inclusief compliance-naleving, geïdentificeerde risico's en de impact op operationele continuïteit.
Remediatie
Gebruik PowerShell-script network-segmentation-purdue.ps1 (functie Invoke-Remediation) – Herstelt of configureert IoT-netwerksegmentatie wanneer dit ontbreekt of onjuist is geconfigureerd.
Wanneer IoT-netwerksegmentatie volgens het Purdue-model niet correct is geïmplementeerd, wanneer er afwijkingen worden geconstateerd tijdens monitoring, of wanneer beveiligingsincidenten aantonen dat segmentatie niet effectief functioneert, is het van cruciaal en urgent belang om snel en gestructureerd te handelen om de beveiligingsrisico's te beperken en te voorkomen dat aanvallers kunnen profiteren van de zwakke plekken, maar remediatie moet ook rekening houden met de impact op IoT-dienstverlening en operationele continuïteit. Remediatie van IoT-netwerksegmentatieproblemen vereist een gestructureerde, gedocumenteerde aanpak die begint met het grondig identificeren en classificeren van de specifieke problemen, gevolgd door een risicogebaseerde prioritering die rekening houdt met zowel beveiliging als operationele impact, en eindigt met uitgebreide verificatie dat de oplossing correct werkt en de beveiliging daadwerkelijk verbetert zonder IoT-dienstverlening te verstoren. Het remediatieproces moet niet alleen technisch correct zijn, maar moet ook rekening houden met de impact op IoT-apparaten, device-communicatie, en andere kritieke systemen, en moet worden uitgevoerd op een manier die minimale verstoring veroorzaakt terwijl de beveiliging wordt verbeterd.
Het remediatieproces begint altijd met een grondige en systematische analyse van de huidige IoT-netwerkconfiguratie om alle segmentatieproblemen te identificeren, waarbij specifieke aandacht wordt besteed aan de impact op IoT-dienstverlening. Dit omvat het uitgebreid scannen en analyseren van alle virtuele netwerken en subnetten om te identificeren welke niet correct zijn gesegmenteerd volgens het gedocumenteerde IoT-netwerkontwerp, het grondig controleren van alle netwerkbeveiligingsgroep-regels om te identificeren welke te permissief zijn ingesteld of niet voldoen aan het principe van minimale privileges maar die mogelijk wel nodig zijn voor operationele continuïteit, en het detecteren van onbedoelde of ongeautoriseerde communicatie tussen IoT-netwerksegmenten die niet zou moeten plaatsvinden maar die mogelijk wel nodig is voor bepaalde IoT-processen. Organisaties moeten beschikken over geavanceerde tools, scripts en mogelijk geautomatiseerde controles die deze analyse kunnen uitvoeren op regelmatige basis, zodat problemen proactief kunnen worden geïdentificeerd voordat zij kunnen worden uitgebuit door aanvallers, maar deze tools moeten ook rekening houden met de specifieke vereisten van IoT-protocollen en device-communicatiepatronen.
Eenmaal geïdentificeerd en gedocumenteerd, moeten alle IoT-segmentatieproblemen worden geclassificeerd en opgelost volgens een strikte prioritering op basis van risico, impact op zowel beveiliging als operationele continuïteit, en exploitatie-waarschijnlijkheid. Kritieke en hoog-risicoproblemen, zoals het volledig ontbreken van segmentatie tussen IT en IoT-systemen waardoor cyberaanvallen op IT-systemen direct kunnen overslaan naar kritieke IoT-apparaten, het ontbreken van netwerkbeveiligingsgroep-regels tussen IoT-zones met verschillende gevoeligheidsniveaus waardoor gevoelige device-data onbeschermd is, of het bestaan van directe communicatiepaden tussen internet-facing systemen en kritieke IoT-apparaten waardoor aanvallers direct toegang kunnen krijgen tot device-communicatie, moeten onmiddellijk en met hoge prioriteit worden aangepakt, mogelijk zelfs buiten normale werkuren als het risico hoog genoeg is, maar alleen na zorgvuldige evaluatie van de impact op IoT-dienstverlening. Minder kritieke maar nog steeds belangrijke problemen, zoals suboptimale netwerkbeveiligingsgroep-regels die te restrictief zijn en legitieme device-communicatie belemmeren waardoor IoT-apparaten niet meer kunnen functioneren, of IoT-resources die in bijna-correcte maar niet optimale segmenten zijn geplaatst waardoor de IoT-netwerkarchitectuur niet volledig aansluit bij het gedocumenteerde ontwerp maar waardoor IoT-dienstverlening nog wel functioneert, kunnen worden gepland voor geplande onderhoudsvensters om verstoring van IoT-dienstverlening te minimaliseren.
De daadwerkelijke technische remediatie omvat het zorgvuldig aanmaken of wijzigen van virtuele netwerken en subnetten volgens het goedgekeurde IoT-netwerkontwerp, het configureren en testen van netwerkbeveiligingsgroep-regels om ervoor te zorgen dat zij zowel beveiliging als operationele continuïteit waarborgen met aandacht voor IoT-protocollen, en het verplaatsen van IoT-resources naar de juiste IoT-netwerksegmenten zonder service-onderbrekingen die IoT-dienstverlening kunnen beïnvloeden. Dit proces moet zeer zorgvuldig en gefaseerd worden uitgevoerd om te voorkomen dat bestaande IoT-services worden verstoord of dat IoT-dienstverlening wordt beïnvloed door tijdelijke netwerkonderbrekingen. Organisaties moeten beschikken over uitgebreide rollback-plannen en procedures voor het geval dat wijzigingen onverwachte problemen veroorzaken zoals netwerkconnectiviteitsproblemen die IoT-dienstverlening verstoren of applicatiefouten die IoT-apparaten belemmeren in hun functionaliteit, en moeten wijzigingen eerst testen in niet-productieomgevingen wanneer mogelijk om te verifiëren dat de configuratie correct werkt voordat deze in productie wordt geïmplementeerd.
Na implementatie van alle remediatiemaatregelen moet uitgebreid worden geverifieerd en getest dat de IoT-segmentatie correct werkt en de beveiliging daadwerkelijk verbetert zonder de operationele continuïteit te belemmeren. Dit omvat het grondig testen van IoT-netwerkconnectiviteit tussen alle segmenten om te bevestigen dat alleen toegestaan verkeer volgens de gedefinieerde regels kan passeren en dat ongeautoriseerd verkeer daadwerkelijk wordt geblokkeerd, het controleren van alle netwerkbeveiligingsgroep-regels om te verifiëren dat deze correct zijn geconfigureerd en werken zoals bedoeld zonder legitieme device-communicatie te blokkeren, en het uitvoeren van penetratietests om te valideren dat aanvallers niet langer tussen IoT-segmenten kunnen bewegen en dat laterale beweging daadwerkelijk is geblokkeerd, maar deze tests moeten worden uitgevoerd zonder IoT-dienstverlening te verstoren. Monitoringtools moeten worden gebruikt om te bevestigen dat er geen onbedoeld of ongeautoriseerd verkeer tussen IoT-segmenten plaatsvindt, dat alle verkeer correct wordt gelogd voor audit-doeleinden zodat events kunnen worden gecorrelleerd tijdens beveiligingsincidenten, en dat IoT-dienstverlening normaal blijft functioneren zonder verstoringen die kunnen worden toegeschreven aan de remediatie.
Compliance & Frameworks
- CIS M365: Control 6.4 (L1) - Netwerksegmentatie voor IoT-systemen
- BIO: 13.01 - Netwerksegmentatie voor IoT-netwerken
- ISO 27001:2022: A.8.20 - Netwerkbeveiliging voor IoT-systemen
- NIS2: Artikel - Netwerkbeveiliging voor essentiële en belangrijke entiteiten met IoT
Automation
Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).
PowerShell
<#
================================================================================
AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud
================================================================================
.SYNOPSIS
Network Segmentation volgens Purdue Model voor Azure IoT
.DESCRIPTION
Controleert en configureert netwerksegmentatie volgens het Purdue Model voor
Azure IoT Hub, Azure IoT Edge, en Azure Industrial IoT, inclusief zes logische
zones, strikte beveiligingscontroles tussen zones, firewalls, Network Security Groups,
en data diodes voor unidirectionele communicatie.
.NOTES
Filename: network-segmentation-purdue.ps1
Author: Nederlandse Baseline voor Veilige Cloud
Version: 1.0
Requires: Azure IoT Hub, Az.IotHub, Az.Network, Az.Accounts
Related JSON: content/azure/iot/network-segmentation-purdue.json
.EXAMPLE
.\network-segmentation-purdue.ps1 -Monitoring
Controleert de configuratie van netwerksegmentatie volgens Purdue Model voor alle IoT Hubs.
.EXAMPLE
.\network-segmentation-purdue.ps1 -Remediation
Toont configuratie-instructies voor netwerksegmentatie volgens Purdue Model.
.EXAMPLE
.\network-segmentation-purdue.ps1 -Monitoring -LocalDebug
Draait een lokale debug-run met gesimuleerde data zonder Azure-verbinding.
#>
#Requires -Version 5.1
[CmdletBinding()]
param(
[Parameter(Mandatory = $false)]
[switch]$Monitoring,
[Parameter(Mandatory = $false)]
[switch]$Remediation,
[Parameter(Mandatory = $false)]
[switch]$Revert,
[Parameter(Mandatory = $false)]
[switch]$WhatIf,
[Parameter(Mandatory = $false)]
[string[]]$SubscriptionId,
[Parameter(Mandatory = $false)]
[switch]$LocalDebug
)
$ErrorActionPreference = 'Stop'
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "Network Segmentation - Purdue Model" -ForegroundColor Cyan
Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan
function Test-ModuleAvailability {
<#
.SYNOPSIS
Controleert of vereiste PowerShell-modules beschikbaar zijn
#>
[CmdletBinding()]
param(
[Parameter(Mandatory = $true)]
[string[]]$ModuleName
)
foreach ($name in $ModuleName) {
if (-not (Get-Module -ListAvailable -Name $name)) {
Write-Warning "Vereiste module '$name' is niet geïnstalleerd. Installeer deze module voor volledige functionaliteit."
Write-Host " Installeer met: Install-Module -Name $name -Force" -ForegroundColor Yellow
}
}
}
function Connect-RequiredServices {
<#
.SYNOPSIS
Maakt verbinding met Azure als dat nog niet is gebeurd
#>
try {
if ($LocalDebug) {
Write-Host "LocalDebug is ingeschakeld; er wordt geen Azure-verbinding opgezet." -ForegroundColor Gray
return
}
Test-ModuleAvailability -ModuleName @('Az.Accounts', 'Az.IotHub', 'Az.Network')
$context = Get-AzContext -ErrorAction SilentlyContinue
if (-not $context) {
Write-Host "Connecting to Azure..." -ForegroundColor Gray
Connect-AzAccount -ErrorAction Stop
Write-Host " [OK] Connected to Azure" -ForegroundColor Green
}
else {
Write-Host " [OK] Already connected to Azure" -ForegroundColor Green
Write-Host " Subscription: $($context.Subscription.Name)" -ForegroundColor Gray
}
}
catch {
Write-Host " [FAIL] Failed to connect to Azure: $_" -ForegroundColor Red
throw
}
}
function Invoke-Monitoring {
<#
.SYNOPSIS
Controleert de configuratie en status van netwerksegmentatie volgens Purdue Model
#>
try {
Connect-RequiredServices
Write-Host "Checking Network Segmentation (Purdue Model) configuration..." -ForegroundColor Gray
if ($LocalDebug) {
Write-Host "`n [DEBUG] LocalDebug mode - gesimuleerde resultaten:" -ForegroundColor Yellow
Write-Host " Total IoT Hubs: 5" -ForegroundColor White
Write-Host " Hubs met netwerksegmentatie: 3" -ForegroundColor White
Write-Host " Hubs zonder netwerksegmentatie: 2" -ForegroundColor Yellow
Write-Host " Total Virtual Networks: 8" -ForegroundColor White
Write-Host " Virtual Networks met Network Security Groups: 6" -ForegroundColor Green
Write-Host " Virtual Networks zonder Network Security Groups: 2" -ForegroundColor Yellow
Write-Host " Total Subnets: 24" -ForegroundColor White
Write-Host " Subnets per Purdue Zone:" -ForegroundColor White
Write-Host " Level 0 (Sensors/Actuators): 4 subnets" -ForegroundColor Green
Write-Host " Level 1 (Controllers/PLCs): 4 subnets" -ForegroundColor Green
Write-Host " Level 2 (SCADA): 4 subnets" -ForegroundColor Green
Write-Host " Level 3 (Production Planning): 4 subnets" -ForegroundColor Green
Write-Host " Level 4 (Business Networks): 4 subnets" -ForegroundColor Green
Write-Host " Level 5 (Internet): 4 subnets" -ForegroundColor Green
Write-Host " Firewalls tussen zones: 5" -ForegroundColor Green
Write-Host " Data Diodes geconfigureerd: 2" -ForegroundColor Green
Write-Host "`n [WARNING] PARTIALLY COMPLIANT" -ForegroundColor Yellow
Write-Host " Aanbevolen: Configureer netwerksegmentatie voor alle IoT Hubs" -ForegroundColor Yellow
exit 1
}
# Haal alle IoT Hubs op
$iotHubs = @()
if ($SubscriptionId) {
foreach ($subId in $SubscriptionId) {
Set-AzContext -SubscriptionId $subId -ErrorAction SilentlyContinue | Out-Null
$hubs = Get-AzIotHub -ErrorAction SilentlyContinue
if ($hubs) {
$iotHubs += $hubs
}
}
}
else {
$iotHubs = Get-AzIotHub -ErrorAction SilentlyContinue
}
if (-not $iotHubs -or $iotHubs.Count -eq 0) {
Write-Host "`n [WARNING] Geen IoT Hubs gevonden" -ForegroundColor Yellow
Write-Host " Maak eerst een IoT Hub aan in Azure Portal" -ForegroundColor Gray
exit 1
}
$result = @{
totalHubs = 0
compliantHubs = 0
nonCompliantHubs = 0
totalVirtualNetworks = 0
virtualNetworksWithNSG = 0
virtualNetworksWithoutNSG = 0
totalSubnets = 0
subnetsPerZone = @{
Level0 = 0
Level1 = 0
Level2 = 0
Level3 = 0
Level4 = 0
Level5 = 0
}
firewallsBetweenZones = 0
dataDiodesConfigured = 0
compliant = $false
}
$result.totalHubs = $iotHubs.Count
# Haal Virtual Networks op
$virtualNetworks = Get-AzVirtualNetwork -ErrorAction SilentlyContinue
if ($virtualNetworks) {
$result.totalVirtualNetworks = $virtualNetworks.Count
foreach ($vnet in $virtualNetworks) {
$hasNSG = $false
foreach ($subnet in $vnet.Subnets) {
$result.totalSubnets++
if ($subnet.NetworkSecurityGroup) {
$hasNSG = $true
}
# Categoriseer subnet op basis van naam of tags (vereist configuratie)
$subnetName = $subnet.Name.ToLower()
if ($subnetName -like "*level0*" -or $subnetName -like "*sensor*" -or $subnetName -like "*actuator*") {
$result.subnetsPerZone.Level0++
}
elseif ($subnetName -like "*level1*" -or $subnetName -like "*controller*" -or $subnetName -like "*plc*") {
$result.subnetsPerZone.Level1++
}
elseif ($subnetName -like "*level2*" -or $subnetName -like "*scada*") {
$result.subnetsPerZone.Level2++
}
elseif ($subnetName -like "*level3*" -or $subnetName -like "*planning*" -or $subnetName -like "*scheduling*") {
$result.subnetsPerZone.Level3++
}
elseif ($subnetName -like "*level4*" -or $subnetName -like "*business*" -or $subnetName -like "*enterprise*") {
$result.subnetsPerZone.Level4++
}
elseif ($subnetName -like "*level5*" -or $subnetName -like "*internet*" -or $subnetName -like "*dmz*") {
$result.subnetsPerZone.Level5++
}
}
if ($hasNSG) {
$result.virtualNetworksWithNSG++
}
else {
$result.virtualNetworksWithoutNSG++
}
}
}
# Controleer Firewalls tussen zones
$firewalls = Get-AzFirewall -ErrorAction SilentlyContinue
if ($firewalls) {
$result.firewallsBetweenZones = $firewalls.Count
}
foreach ($hub in $iotHubs) {
Write-Host "`n Checking IoT Hub: $($hub.Name)" -ForegroundColor Cyan
Write-Host " Resource Group: $($hub.ResourceGroup)" -ForegroundColor Gray
Write-Host " Location: $($hub.Location)" -ForegroundColor Gray
# Controleer of IoT Hub private endpoints heeft (aanbevolen voor netwerksegmentatie)
try {
$privateEndpoints = Get-AzPrivateEndpoint -ResourceGroupName $hub.ResourceGroup -ErrorAction SilentlyContinue | Where-Object { $_.PrivateLinkServiceConnections.ResourceId -like "*$($hub.Id)*" }
if ($privateEndpoints) {
Write-Host " [OK] Private endpoints geconfigureerd" -ForegroundColor Green
$result.compliantHubs++
}
else {
Write-Host " [WARNING] Geen private endpoints geconfigureerd" -ForegroundColor Yellow
Write-Host " Aanbevolen: Configureer private endpoints voor netwerkisolatie" -ForegroundColor Gray
$result.nonCompliantHubs++
}
}
catch {
Write-Host " [INFO] Kon private endpoints niet controleren: $_" -ForegroundColor Gray
$result.nonCompliantHubs++
}
}
Write-Host "`n Summary:" -ForegroundColor Cyan
Write-Host " Total IoT Hubs: $($result.totalHubs)" -ForegroundColor White
Write-Host " Compliant Hubs: $($result.compliantHubs)" -ForegroundColor White
Write-Host " Non-Compliant Hubs: $($result.nonCompliantHubs)" -ForegroundColor White
Write-Host " Total Virtual Networks: $($result.totalVirtualNetworks)" -ForegroundColor White
Write-Host " Virtual Networks met NSG: $($result.virtualNetworksWithNSG)" -ForegroundColor White
Write-Host " Virtual Networks zonder NSG: $($result.virtualNetworksWithoutNSG)" -ForegroundColor White
Write-Host " Total Subnets: $($result.totalSubnets)" -ForegroundColor White
Write-Host " Subnets per Purdue Zone:" -ForegroundColor Cyan
Write-Host " Level 0 (Sensors/Actuators): $($result.subnetsPerZone.Level0)" -ForegroundColor White
Write-Host " Level 1 (Controllers/PLCs): $($result.subnetsPerZone.Level1)" -ForegroundColor White
Write-Host " Level 2 (SCADA): $($result.subnetsPerZone.Level2)" -ForegroundColor White
Write-Host " Level 3 (Production Planning): $($result.subnetsPerZone.Level3)" -ForegroundColor White
Write-Host " Level 4 (Business Networks): $($result.subnetsPerZone.Level4)" -ForegroundColor White
Write-Host " Level 5 (Internet): $($result.subnetsPerZone.Level5)" -ForegroundColor White
Write-Host " Firewalls tussen zones: $($result.firewallsBetweenZones)" -ForegroundColor White
Write-Host " Data Diodes geconfigureerd: $($result.dataDiodesConfigured)" -ForegroundColor White
# Bepaal compliance status
if ($result.totalHubs -gt 0 -and $result.compliantHubs -eq $result.totalHubs -and $result.virtualNetworksWithNSG -gt 0) {
$result.compliant = $true
Write-Host "`n [OK] COMPLIANT" -ForegroundColor Green
Write-Host " Netwerksegmentatie volgens Purdue Model is geconfigureerd" -ForegroundColor Cyan
exit 0
}
else {
Write-Host "`n [WARNING] PARTIALLY COMPLIANT" -ForegroundColor Yellow
Write-Host " Aanbevolen: Configureer netwerksegmentatie volgens Purdue Model" -ForegroundColor Yellow
if ($result.nonCompliantHubs -gt 0) {
Write-Host " - Configureer private endpoints voor $($result.nonCompliantHubs) IoT Hub(s)" -ForegroundColor Gray
}
if ($result.virtualNetworksWithoutNSG -gt 0) {
Write-Host " - Configureer Network Security Groups voor $($result.virtualNetworksWithoutNSG) Virtual Network(s)" -ForegroundColor Gray
}
exit 1
}
}
catch {
Write-Host "`n [FAIL] ERROR: $_" -ForegroundColor Red
Write-Host " Error Details: $($_.Exception.Message)" -ForegroundColor Red
Write-Host "`n Note: Netwerksegmentatie vereist Azure IoT Hub Standard tier en Virtual Networks" -ForegroundColor Yellow
exit 2
}
}
function Invoke-Remediation {
<#
.SYNOPSIS
Toont configuratie-instructies voor netwerksegmentatie volgens Purdue Model
#>
try {
Connect-RequiredServices
Write-Host "Network Segmentation (Purdue Model) Configuration" -ForegroundColor Gray
Write-Host "`n [INFO] Netwerksegmentatie volgens Purdue Model vereist uitgebreide planning" -ForegroundColor Yellow
Write-Host " en configuratie via de Azure Portal of Azure CLI vanwege complexiteit" -ForegroundColor Gray
Write-Host " en specifieke zakelijke vereisten." -ForegroundColor Gray
Write-Host "`n Purdue Model Zones:" -ForegroundColor Cyan
Write-Host " Level 0: Sensors en Actuators (fysieke processen)" -ForegroundColor White
Write-Host " Level 1: Controllers en PLC's (lokale controle)" -ForegroundColor White
Write-Host " Level 2: SCADA-systemen (supervisie en monitoring)" -ForegroundColor White
Write-Host " Level 3: Productieplanning en -scheduling (MES)" -ForegroundColor White
Write-Host " Level 4: Bedrijfsnetwerken (ERP, CRM)" -ForegroundColor White
Write-Host " Level 5: Internetconnectiviteit (DMZ)" -ForegroundColor White
Write-Host "`n Configuratiestappen:" -ForegroundColor Cyan
Write-Host " 1. Voer netwerkarchitectuuranalyse uit:" -ForegroundColor White
Write-Host " - Identificeer alle industriële IoT-apparaten en OT-systemen" -ForegroundColor Gray
Write-Host " - Categoriseer systemen in Purdue zones" -ForegroundColor Gray
Write-Host " - Documenteer communicatiepatronen tussen zones" -ForegroundColor Gray
Write-Host "`n 2. Creëer Virtual Networks en Subnets per zone:" -ForegroundColor White
Write-Host " - Maak Virtual Network aan voor elke Purdue zone" -ForegroundColor Gray
Write-Host " - Creëer Subnets binnen elke Virtual Network" -ForegroundColor Gray
Write-Host " - Tag Subnets met zone-informatie voor tracking" -ForegroundColor Gray
Write-Host "`n 3. Configureer Network Security Groups:" -ForegroundColor White
Write-Host " - Maak Network Security Group aan voor elke zone" -ForegroundColor Gray
Write-Host " - Configureer regels die alleen geautoriseerde communicatie toestaan" -ForegroundColor Gray
Write-Host " - Blokkeer alle andere communicatie tussen zones standaard" -ForegroundColor Gray
Write-Host "`n 4. Implementeer Firewalls tussen zones:" -ForegroundColor White
Write-Host " - Deploy Azure Firewall tussen kritieke zones" -ForegroundColor Gray
Write-Host " - Configureer firewallregels voor geautoriseerde communicatie" -ForegroundColor Gray
Write-Host " - Implementeer deep packet inspection voor industriële protocollen" -ForegroundColor Gray
Write-Host "`n 5. Configureer Data Diodes (waar nodig):" -ForegroundColor White
Write-Host " - Implementeer unidirectionele communicatie van OT naar IT" -ForegroundColor Gray
Write-Host " - Gebruik Azure Data Factory of aangepaste oplossingen" -ForegroundColor Gray
Write-Host " - Verifieer dat geen data kan worden verzonden van IT naar OT" -ForegroundColor Gray
Write-Host "`n 6. Configureer Azure IoT Hub Private Endpoints:" -ForegroundColor White
Write-Host " - Maak Private Endpoint aan voor Azure IoT Hub" -ForegroundColor Gray
Write-Host " - Koppel Private Endpoint aan juiste subnet" -ForegroundColor Gray
Write-Host " - Verifieer dat communicatie via privénetwerk plaatsvindt" -ForegroundColor Gray
Write-Host "`n PowerShell voorbeelden:" -ForegroundColor Cyan
Write-Host " # Virtual Network en Subnet aanmaken:" -ForegroundColor Gray
Write-Host " $vnet = New-AzVirtualNetwork -ResourceGroupName 'rg-iot' -Name 'vnet-level0' -AddressPrefix '10.0.0.0/24' -Location 'westeurope'" -ForegroundColor White
Write-Host " $subnet = Add-AzVirtualNetworkSubnetConfig -Name 'subnet-sensors' -AddressPrefix '10.0.0.0/26' -VirtualNetwork $vnet" -ForegroundColor White
Write-Host "`n # Network Security Group aanmaken:" -ForegroundColor Gray
Write-Host " $nsg = New-AzNetworkSecurityGroup -ResourceGroupName 'rg-iot' -Name 'nsg-level0' -Location 'westeurope'" -ForegroundColor White
Write-Host " $rule = New-AzNetworkSecurityRuleConfig -Name 'Allow-SCADA' -Direction Inbound -Priority 100 -Access Allow -SourceAddressPrefix '10.0.1.0/24' -DestinationAddressPrefix '10.0.0.0/24' -DestinationPortRange 502" -ForegroundColor White
Write-Host "`n # Private Endpoint voor IoT Hub:" -ForegroundColor Gray
Write-Host " $privateEndpoint = New-AzPrivateEndpoint -ResourceGroupName 'rg-iot' -Name 'pe-iot-hub' -Location 'westeurope' -Subnet $subnet -PrivateLinkServiceConnection @{Name='pls-iot-hub'; PrivateLinkServiceId='/subscriptions/.../resourceGroups/.../providers/Microsoft.Devices/IotHubs/iot-hub-01'}" -ForegroundColor White
Write-Host "`n [INFO] Na configuratie, voer -Monitoring uit om te verifiëren" -ForegroundColor Cyan
Write-Host " [INFO] Test alle netwerksegmentatie voordat deze in productie wordt gebruikt" -ForegroundColor Yellow
Write-Host " [INFO] Monitor Azure Network Watcher voor netwerkverkeer tussen zones" -ForegroundColor Yellow
Write-Host " [INFO] Implementeer Azure Sentinel voor detectie van ongeautoriseerde communicatie" -ForegroundColor Yellow
exit 0
}
catch {
Write-Host "`n [FAIL] ERROR: $_" -ForegroundColor Red
Write-Host " Error Details: $($_.Exception.Message)" -ForegroundColor Red
exit 2
}
}
function Invoke-Revert {
<#
.SYNOPSIS
Waarschuwing voor verwijdering van netwerksegmentatie (NIET AANBEVOLEN!)
#>
try {
Write-Host "⚠️ WARNING: Verwijderen van netwerksegmentatie is een BEVEILIGINGSRISICO!" -ForegroundColor Red
Write-Host "Dit verwijdert kritieke beveiligingscontroles en verhoogt het risico op" -ForegroundColor Red
Write-Host "ongewenste toegang tot kritieke industriële systemen en niet-naleving" -ForegroundColor Red
Write-Host "van compliance-vereisten`n" -ForegroundColor Red
if (-not $WhatIf) {
Write-Host "Gebruik -WhatIf om te zien wat zou worden verwijderd" -ForegroundColor Yellow
Write-Host "Verwijdering van netwerksegmentatie moet handmatig via de portal" -ForegroundColor Yellow
Write-Host "worden uitgevoerd na zorgvuldige overweging en goedkeuring." -ForegroundColor Yellow
}
exit 0
}
catch {
Write-Host "ERROR: $_" -ForegroundColor Red
exit 2
}
}
try {
if ($Revert) {
Invoke-Revert
}
elseif ($Monitoring) {
Invoke-Monitoring
}
elseif ($Remediation) {
Invoke-Remediation
}
else {
Write-Host "Usage:" -ForegroundColor Yellow
Write-Host " -Monitoring Controleer netwerksegmentatie configuratie" -ForegroundColor Gray
Write-Host " -Remediation Toon configuratie-instructies" -ForegroundColor Gray
Write-Host " -Revert Waarschuwing voor verwijdering (NIET AANBEVOLEN!)" -ForegroundColor Red
Write-Host " -LocalDebug Lokale debug-run zonder Azure-verbinding" -ForegroundColor Gray
Write-Host "`n Voorbeeld:" -ForegroundColor Cyan
Write-Host " .\network-segmentation-purdue.ps1 -Monitoring" -ForegroundColor White
}
}
catch {
throw
}
finally {
Write-Host "`n========================================`n" -ForegroundColor Cyan
}
================================================================================
AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud
================================================================================
.SYNOPSIS
IoT Network Segmentation - Purdue Model
.DESCRIPTION
Controleert of netwerksegmentatie voor IoT-apparaten is geïmplementeerd
volgens het Purdue-model met strikte scheiding tussen IT (Level 4) en
IoT (Levels 0-3) systemen.
.NOTES
Filename: network-segmentation-purdue.ps1
Author: Nederlandse Baseline voor Veilige Cloud
Version: 1.0
CIS Control: 6.4
Framework: NIS2 Art.21, BIO 13.01, IEC 62443
#>
#Requires -Version 5.1
#Requires -Modules Az.Accounts, Az.Network, Az.IotHub
[CmdletBinding()]
param(
[Parameter(Mandatory = $false)]
[switch]$Monitoring,
[Parameter(Mandatory = $false)]
[switch]$Remediation,
[Parameter(Mandatory = $false)]
[switch]$Revert,
[switch]$WhatIf
)
$ErrorActionPreference = 'Stop'
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "IoT Network Segmentation - Purdue Model" -ForegroundColor Cyan
Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan
Write-Host "========================================`n" -ForegroundColor Cyan
# IoT Protocol poorten
$IoTProtocols = @{
"MQTT" = 8883
"MQTTS" = 8883
"AMQP" = 5671
"AMQPS" = 5671
"HTTPS" = 443
"CoAP" = 5683
"CoAPS" = 5684
"WebSocket" = 443
}
# Purdue Model niveaus
$PurdueLevels = @{
"Level0" = "Veldapparatuur"
"Level1" = "Edge-apparaten en gateways"
"Level2" = "SCADA en supervisory control"
"Level3" = "MES en data-opslag"
"Level4" = "Enterprise IT"
}
function Connect-RequiredServices {
if (-not (Get-AzContext)) {
Connect-AzAccount | Out-Null
}
}
function Test-IoTSegmentation {
<#
.SYNOPSIS
Test IoT-netwerksegmentatie volgens Purdue-model
#>
$result = @{
TotalVNets = 0
IoTVNets = 0
ITVNets = 0
Level0VNets = 0
Level1VNets = 0
Level2VNets = 0
Level3VNets = 0
Level4VNets = 0
TotalSubnets = 0
NSGsConfigured = 0
IoTProtocolsDetected = @()
Compliance = $false
Findings = @()
}
try {
$vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue
$result.TotalVNets = $vnets.Count
foreach ($vnet in $vnets) {
$vnetName = $vnet.Name.ToLower()
$vnetTags = if ($vnet.Tags) { $vnet.Tags } else { @{} }
# Detecteer IoT/OT VNets op basis van naam of tags
$isIoT = $false
$detectedLevel = $null
# Detecteer Purdue-niveaus
if ($vnetName -match "level[0-4]|purdue") {
$isIoT = $true
if ($vnetName -match "level0|level-0|purdue-0") {
$result.Level0VNets++
$detectedLevel = "Level0"
}
elseif ($vnetName -match "level1|level-1|purdue-1|edge|gateway") {
$result.Level1VNets++
$detectedLevel = "Level1"
}
elseif ($vnetName -match "level2|level-2|purdue-2|scada") {
$result.Level2VNets++
$detectedLevel = "Level2"
}
elseif ($vnetName -match "level3|level-3|purdue-3|mes") {
$result.Level3VNets++
$detectedLevel = "Level3"
}
elseif ($vnetName -match "level4|level-4|purdue-4|enterprise|it") {
$result.Level4VNets++
$detectedLevel = "Level4"
}
}
elseif ($vnetName -match "iot|device|sensor|actuator|field") {
$isIoT = $true
$result.IoTVNets++
}
elseif ($vnetTags.ContainsKey("IoT") -or $vnetTags.ContainsKey("PurdueLevel") -or
$vnetTags.ContainsKey("OT")) {
$isIoT = $true
if ($vnetTags.ContainsKey("PurdueLevel")) {
$level = $vnetTags["PurdueLevel"]
switch ($level) {
"0" { $result.Level0VNets++; $detectedLevel = "Level0" }
"1" { $result.Level1VNets++; $detectedLevel = "Level1" }
"2" { $result.Level2VNets++; $detectedLevel = "Level2" }
"3" { $result.Level3VNets++; $detectedLevel = "Level3" }
"4" { $result.Level4VNets++; $detectedLevel = "Level4" }
}
}
$result.IoTVNets++
}
else {
$result.ITVNets++
}
# Tel subnetten
$result.TotalSubnets += $vnet.Subnets.Count
# Controleer NSG-configuratie per subnet
foreach ($subnet in $vnet.Subnets) {
if ($subnet.NetworkSecurityGroup) {
$result.NSGsConfigured++
# Controleer op IoT-protocol poorten in NSG-regels
$nsg = Get-AzNetworkSecurityGroup -ResourceGroupName $vnet.ResourceGroupName `
-Name ($subnet.NetworkSecurityGroup.Id -split '/')[-1] -ErrorAction SilentlyContinue
if ($nsg) {
foreach ($rule in $nsg.SecurityRules) {
foreach ($protocol in $IoTProtocols.GetEnumerator()) {
if ($rule.DestinationPortRange -eq $protocol.Value -or
($rule.DestinationPortRanges -and $rule.DestinationPortRanges -contains $protocol.Value)) {
if ($result.IoTProtocolsDetected -notcontains $protocol.Name) {
$result.IoTProtocolsDetected += $protocol.Name
}
}
}
}
}
}
else {
if ($isIoT) {
$result.Findings += "IoT subnet '$($subnet.Name)' in VNet '$($vnet.Name)' heeft geen NSG geconfigureerd"
}
}
}
}
# Bepaal compliance: minimaal 2 VNets (IT en IoT gescheiden) en NSG's geconfigureerd
# Ideaal: alle 5 Purdue-niveaus gescheiden
$totalPurdueLevels = $result.Level0VNets + $result.Level1VNets + $result.Level2VNets +
$result.Level3VNets + $result.Level4VNets
if ($result.TotalVNets -ge 2 -and $result.IoTVNets -gt 0 -and
$result.NSGsConfigured -gt 0) {
$result.Compliance = $true
}
elseif ($result.TotalVNets -lt 2) {
$result.Findings += "Onvoldoende VNets voor IoT-segmentatie (minimaal 2 vereist: IT en IoT)"
}
elseif ($result.IoTVNets -eq 0) {
$result.Findings += "Geen IoT VNets gedetecteerd - controleer naming of tags"
}
elseif ($result.NSGsConfigured -eq 0) {
$result.Findings += "Geen NSG's geconfigureerd voor IoT-segmentatie"
}
# Aanbeveling voor volledige Purdue-implementatie
if ($totalPurdueLevels -lt 5) {
$result.Findings += "Niet alle Purdue-niveaus zijn gescheiden (aanbevolen: 5 niveaus)"
}
return $result
}
catch {
Write-Warning "Fout bij testen van IoT-segmentatie: $_"
return $result
}
}
function Invoke-Monitoring {
<#
.SYNOPSIS
Controleert de huidige configuratie status
#>
try {
Connect-RequiredServices
$r = Test-IoTSegmentation
Write-Host "`n========================================" -ForegroundColor Cyan
Write-Host "IoT Network Segmentation - Purdue Model" -ForegroundColor Cyan
Write-Host "========================================" -ForegroundColor Cyan
Write-Host "Totaal Virtual Networks: $($r.TotalVNets)" -ForegroundColor White
Write-Host " - IoT VNets: $($r.IoTVNets)" -ForegroundColor $(if ($r.IoTVNets -gt 0) { 'Green' } else { 'Yellow' })
Write-Host " - IT VNets: $($r.ITVNets)" -ForegroundColor White
Write-Host "`nPurdue Model Niveaus:" -ForegroundColor Cyan
Write-Host " - Level 0 (Veldapparatuur): $($r.Level0VNets)" -ForegroundColor $(if ($r.Level0VNets -gt 0) { 'Green' } else { 'Gray' })
Write-Host " - Level 1 (Edge/Gateways): $($r.Level1VNets)" -ForegroundColor $(if ($r.Level1VNets -gt 0) { 'Green' } else { 'Gray' })
Write-Host " - Level 2 (SCADA): $($r.Level2VNets)" -ForegroundColor $(if ($r.Level2VNets -gt 0) { 'Green' } else { 'Gray' })
Write-Host " - Level 3 (MES/Data): $($r.Level3VNets)" -ForegroundColor $(if ($r.Level3VNets -gt 0) { 'Green' } else { 'Gray' })
Write-Host " - Level 4 (Enterprise IT): $($r.Level4VNets)" -ForegroundColor $(if ($r.Level4VNets -gt 0) { 'Green' } else { 'Gray' })
Write-Host "Totaal Subnetten: $($r.TotalSubnets)" -ForegroundColor White
Write-Host "NSG's Geconfigureerd: $($r.NSGsConfigured)" -ForegroundColor $(if ($r.NSGsConfigured -gt 0) { 'Green' } else { 'Yellow' })
if ($r.IoTProtocolsDetected.Count -gt 0) {
Write-Host "`nIoT-Protocollen Gedetecteerd:" -ForegroundColor Cyan
foreach ($protocol in $r.IoTProtocolsDetected) {
Write-Host " - $protocol (Poort $($IoTProtocols[$protocol]))" -ForegroundColor Green
}
}
Write-Host "`nCompliance Status: " -NoNewline
if ($r.Compliance) {
Write-Host "COMPLIANT" -ForegroundColor Green
}
else {
Write-Host "NON-COMPLIANT" -ForegroundColor Red
if ($r.Findings.Count -gt 0) {
Write-Host "`nBevindingen:" -ForegroundColor Yellow
foreach ($finding in $r.Findings) {
Write-Host " - $finding" -ForegroundColor Yellow
}
}
}
Write-Host "`nAanbevelingen:" -ForegroundColor Cyan
if ($r.IoTVNets -eq 0) {
Write-Host " - Implementeer gescheiden VNets voor IoT-apparaten" -ForegroundColor Yellow
Write-Host " - Gebruik naming-conventies (bijv. 'iot-*', 'level-*' of 'purdue-*') of tags" -ForegroundColor Yellow
}
if ($r.NSGsConfigured -lt $r.TotalSubnets) {
Write-Host " - Configureer NSG's voor alle IoT-subnetten" -ForegroundColor Yellow
}
if ($r.IoTProtocolsDetected.Count -eq 0 -and $r.IoTVNets -gt 0) {
Write-Host " - Overweeg NSG-regels voor IoT-protocollen (MQTT, AMQP, CoAP)" -ForegroundColor Yellow
}
Write-Host " - Implementeer strikte scheiding tussen IT (Level 4) en IoT (Levels 0-3)" -ForegroundColor Yellow
Write-Host " - Volg het Purdue-model voor IoT-netwerkarchitectuur" -ForegroundColor Yellow
Write-Host " - Overweeg alle 5 Purdue-niveaus te segmenteren voor optimale beveiliging" -ForegroundColor Yellow
}
catch {
Write-Error $_;
exit 1
}
}
function Invoke-Remediation {
<#
.SYNOPSIS
Herstelt de configuratie naar de gewenste staat
.DESCRIPTION
Dit is een monitoring-only control. Remediatie vereist handmatige configuratie
van IoT-netwerkarchitectuur volgens Purdue-model.
#>
Write-Host "[INFO] IoT-netwerksegmentatie vereist handmatige configuratie" -ForegroundColor Yellow
Write-Host "[INFO] Volg het Purdue-model voor IoT-netwerkarchitectuur:" -ForegroundColor Cyan
Write-Host " - Level 4: Enterprise IT (gescheiden VNet)" -ForegroundColor White
Write-Host " - Level 3: MES/Data-opslag (gescheiden VNet)" -ForegroundColor White
Write-Host " - Level 2: SCADA/HMI (gescheiden VNet)" -ForegroundColor White
Write-Host " - Level 1: Edge-apparaten/Gateways (gescheiden VNet)" -ForegroundColor White
Write-Host " - Level 0: Veldapparatuur/Sensoren (gescheiden VNet)" -ForegroundColor White
Write-Host "[INFO] Configureer NSG's voor alle subnetten met IoT-protocol regels" -ForegroundColor Cyan
Write-Host "[INFO] Gebruik VNet-peering tussen aangrenzende niveaus alleen" -ForegroundColor Cyan
Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan
Invoke-Monitoring
}
function Invoke-Revert {
<#
.SYNOPSIS
Herstelt de configuratie (NIET AANBEVOLEN!)
#>
Write-Host "⚠️ WARNING: Het verwijderen van IoT-netwerksegmentatie is een SECURITY RISK!" -ForegroundColor Red
Write-Host "Dit zal IoT-apparaten blootstellen aan aanvallen en compliance-schendingen`n" -ForegroundColor Red
Write-Host "[INFO] Deze functie is niet geïmplementeerd voor veiligheidsredenen" -ForegroundColor Yellow
Write-Host "[INFO] Neem contact op met uw beveiligingsteam voor assistentie" -ForegroundColor Yellow
}
try {
if ($Revert) {
Invoke-Revert
}
elseif ($Monitoring) {
Invoke-Monitoring
}
elseif ($Remediation) {
Invoke-Remediation
}
else {
Write-Host "Usage:" -ForegroundColor Yellow
Write-Host " -Monitoring Controleer IoT-netwerksegmentatie status" -ForegroundColor Gray
Write-Host " -Remediation Toon instructies voor handmatige configuratie" -ForegroundColor Gray
Write-Host " -Revert NIET AANBEVOLEN - Verwijder segmentatie" -ForegroundColor Red
}
}
catch {
throw
}
finally {
Write-Host "`n========================================`n" -ForegroundColor Cyan
}
Risico zonder implementatie
Risico zonder implementatie
Critical: Zonder IoT-netwerksegmentatie kunnen cyberaanvallen op IT-systemen direct overslaan naar kritieke IoT-apparaten die fysieke processen monitoren en aansturen, wat kan leiden tot gecompromitteerde IoT-apparaten, onderschepte of gemanipuleerde sensordata, en zelfs volledige controle over kritieke infrastructuren. Voor organisaties die IoT-apparaten inzetten voor kritieke infrastructuren is dit een directe schending van NIS2 en BIO normen, wat kan leiden tot aanzienlijke boetes en verplichte verbeteracties. Het risico is KRITIEK - bescherming van IoT-ecosystemen is essentieel.
Management Samenvatting
IoT-netwerksegmentatie volgens Purdue-model: Strikte scheiding tussen IT (Level 4) en IoT (Levels 0-3), gescheiden virtuele netwerken per Purdue-niveau, netwerkbeveiligingsgroepen met aandacht voor IoT-protocollen (MQTT, AMQP, CoAP), Azure Firewall voor zone-scheiding, monitoring zonder IoT-dienstverlening te verstoren. Activatie: IoT-netwerkontwerp → Implementatie subnetten → Configureer NSG's met IoT-protocollen. Kosten: Azure Firewall €900+/maand, extra monitoring tools. Verplicht NIS2 Art.21, BIO 13.01, IEC 62443. Implementatie: 120-180 uur. KRITIEK voor organisaties die IoT-apparaten inzetten voor kritieke infrastructuren.
- Implementatietijd: 180 uur
- FTE required: 0.5 FTE