Waarom het netwerk de laatste verdedigingslinie is geworden voor OT-, IoT- en medische apparatuur
Ergens op uw netwerk draait een apparaat met een besturingssysteem dat end-of-support is gegaan reeds vooraleer sommige van uw collega's afstudeerden. Het kan een echoscopie zijn, een bouwbeheerssysteem, een kaartlezer, een HMI op een productielijn, of een laboratorium analysator die meer kost dan een bedrijfswagen. U weet dat het een risico is. U hebt het aangekaart. En u krijgt steeds te horen, op beleefde toon, dat het niet gepatcht kan worden.
Dit antwoord klopt meestal. De fabrikant heeft de update niet gecertificeerd. De regelgeving geldt voor een specifieke softwarebuild en opnieuw valideren duurt maanden. Het onderhoudscontract vervalt als u de image aanraakt. Het apparaat draait 24/7 in een klinische of productieomgeving waar een herstart geen klik is, maar een weloverwogen planningsaangelegenheid. Of de leverancier die het heeft gemaakt, bestaat gewoonweg niet meer.
Het eerlijke uitgangspunt voor iedereen die vandaag een bedrijfsnetwerk beheert, is dit: een aanzienlijk deel van de apparaten op uw netwerk zal nooit worden gepatcht, zal nooit een endpoint-agent draaien, en zal niet binnen uw geplande maintenance window worden vervangen. Elke beveiligingsmaatregel die van iets anders uitgaat – EDR-dekking, agent gestuurde statuscontroles, geautomatiseerde patch-compliance – heeft een blinde vlek precies in de vorm van uw meest operationeel kritieke apparatuur.
Als het eindapparaat zichzelf niet kan verdedigen, moet het netwerk dat doen.
Waarom het klassieke antwoord niet meer werkt
Het klassieke antwoord was om deze apparaten ergens anders onder te brengen. Een medische VLAN. Een VLAN voor infrastructuur diensten. Een VLAN voor camera's. Een firewall ertussenin, en we kunnen verder.
Deze aanpak werkt, maar niet meer zodra de schaal toeneemt. Drie factoren maken deze aanpak kwetsbaar:
Het aantal apparaten. Segmentatie per categorie was nog beheersbaar met enkele honderden apparaten. Op geconvergeerde campussen gaat het vandaag om duizenden apparaten waarbij er nog voortdurend bijkomen, vaak geplaatst door facilities of klinische techniek, vaak zonder ‘change request’ aan het netwerkteam.
Het statische ACL-probleem. Elke uitzondering – de remote maintenance toegang van de servicepartner, de monitoringserver die alle subnetten moet bereiken, de nieuwe integratie met het patiëntendossier – krijgt een nieuwe ACL toegangsregel. Na enkele jaren kan niemand nog iets veilig verwijderen, dus de regelset groeit alleen maar. De segmentatie bestaat op papier, terwijl de effectieve policy stilaan "grotendeels toestaan" is geworden.
De fysieke locatie stemt niet meer overeen met beleid. Een VLAN is gebonden aan de plaats waar een apparaat is aangesloten. Apparaten verhuizen tussen afdelingen, verdiepingen en gebouwen. Draadloze apparaten verhuizen voortdurend. Een beleid gekoppeld aan een switchpoort of SSID valt uit elkaar op het moment dat de fysieke locatie verandert, en de oplossing blijkt altijd de VLAN verbreden.
Het resultaat is gekend: een netwerk dat in het ontwerpdocument gesegmenteerd is maar in de praktijk ‘flat’ is. En ‘flat’ is precies de toestand die ransomware nodig heeft. De eerste voet aan de grond is zelden het niet-patchbare apparaat, het is een ge-phishte gebruikersaccount.
Het niet-patchbare apparaat maakt het verschil tussen een incident dat één afdeling treft en een incident dat het hele ziekenhuis treft.
Drie mogelijkheden die het resultaat echt veranderen
Weet voortdurend wat er aanwezig is in het netwerk. Niet een jaarlijkse inventarislijst in een spreadsheet. Passieve profilering die apparaten herkent aan hoe zij zich gedragen op het netwerk – DHCP-fingerprints, protocolgebruik, verkeerspatronen, MAC-eigendom – en markeer alles wat onverwacht verschijnt. In vrijwel elke discovery sessie overschrijdt het aantal verbonden apparaten het aantal in de CMDB.
Deze kloof is waar het risico zit.
De omvang van die kloof wordt consequent onderschat. In een gepubliceerde runZero-casestudy van York University, een campus met 54.000 studenten, hebben zij uiteindelijk zicht op 25.000 assets – ongeveer twee en een half keer meer dan zij voorheen konden zien. De uitleg van hun CISO stemt tot nadenken: hun netwerkbeheertools waren goed in het beheren van het netwerk, maar niet in het zien van de apparaten die eraan zijn verbonden.
Dat zijn twee verschillende opties, en de meeste organisaties beschikken slechts over één ervan.
Bepaal waarmee elk apparaat mag communiceren. Een infusiepomp moet drie servers bereiken. Een camera moet de netwerkvideorecorder bereiken. Een deurvergrendeling moet zijn toegangscontrol server bereiken. Geen van hen heeft internet, de fileserver of elkaar nodig. Leg eerst vast wat het werkelijke verkeer is, en schrijf de policy op basis van wat u waarneemt, niet op basis van wat de fabrikantendocumentatie beweert.
De referentiearchitectuur is namelijk bijna altijd ruimer dan werkelijk nodig is.
Concentreer op het aansluitingspunt. Dit is het onderdeel dat het model werkende houdt. De netwerkpolicy moet aan de apparaat identiteit gekoppeld zijn en op de access layer – de netwerkpoort of het AP waarop het zich verbindt – worden toegepast, niet bij een firewall drie hops verder weg.
Op die manier verandert een verplaatsing tussen gebouwen niets, en de laterale beweging tussen twee apparaten op dezelfde switch wordt geblokkeerd in plaats van onzichtbaar te zijn.
Hoe u dit aanpakt zonder de business te verstoren
De reden dat deze projecten vastlopen is angst, en die angst is terecht: niemand wil degene zijn wiens segmentatie netwerkpolicy een procedure heeft onderbroken. Sequencing lost het meeste op.
- Ontdek passief voordat u iets afdwingt. Weken, geen dagen. Niets verandert op het netwerk tijdens deze fase, dus er is geen risico om dit uit te voeren.
- Model policy in monitoringsmodus. Voer de beoogde policy regels uit en registreer wat zou zijn geblokkeerd. Dit beperkt een discussie over risico tot een beoordeling van een rapport en brengt meestal twee of drie gelegitimeerde verkeersstromen aan het licht die niemand heeft gedocumenteerd.
- Begin met een apparaten groep met hoog risico en laag lateraal bereik. Camera's en gebouwdiensten zijn ideale eerste kandidaten: de security winst is echt en de operationele inzet is lager dan voor klinische of productieapparatuur.
- Betrek de apparaat eigenaren vroeg. Klinische technologie, facilities, OT-engineering. Ze weten dingen die het netwerk niet kan vertellen – dat de analysator 's nachts data naar de fabrikant uploadt, dat een leverancier elk kwartaal belt voor kalibratie. Ze hebben ook informeel vetorecht: zodra een policy de schuld krijgt voor een operationeel probleem, wordt het opgeheven, en eenmaal opgeheven komt het zelden terug. De policy dat u zonder hen oplegt, duurt tot het eerste incident. De policy waar u het mee eens bent, overleeft het.
- Breid uit per groep, met een rollback-mogelijkheid per groep. Elke stap moet onafhankelijk omkeerbaar zijn.
Het loont de moeite om vooraf afspraken te maken over de te hanteren maatstaven, want het argument „dan zijn we veiliger” houdt geen stand tijdens begrotingsbesprekingen. Nuttige maatstaven zijn: de tijd die nodig is om een onbekend apparaat op het netwerk te identificeren, het percentage toegangspoorten dat onder een dynamisch beleid valt, en het aantal bestemmingen dat een gecompromitteerd apparaat in elke groep zou kunnen bereiken – de „blast radius” – en het zien van de daling daarvan is het duidelijkste bewijs dat het programma werkt.
De compliance insteek, in het kort
Als u actief bent als een essentiële of belangrijke entiteit in het kader van NIS2, is het moeilijk om op eerlijke wijze te voldoen aan de verplichtingen op het gebied van activabeheer, toegangscontrole en incidentdetectie zonder bovenstaande mogelijkheid. U kunt een incident niet binnen de vereiste termijn melden als het dagen duurt om vast te stellen wat een apparaat het is en wat het heeft bereikt.
Zowel ISO/IEC 27001 als de technische implementatierichtlijnen van ENISA maken deze verwachting vrij expliciet, en de daaruit afgeleide nationale kaders in elke lidstaat zeggen in lokale bewoordingen vrijwel hetzelfde. De meeste organisaties merken dat de segmentatiewerkzaamheden die ze om veiligheidsredenen uitstelden, nu om nalevingsredenen vereist zijn – wat, pragmatisch gezien, vaak de doorslag geeft bij het vrijmaken van het budget.
Waar Damovo aansluit
Wij ontwerpen en beheren campusnetwerken waarin dit model standaard is, en geen latere toevoeging. Apparaat profilering en policy handhaving worden ingebouwd in de accesslaag, op basis van de platformen zoals onder andere Cisco Identity Services Engine, Extreme Networks Fabric en Universal ZTNA Policy, aangevuld met runZero voor agentloze assetdiscovery in IT, OT en IoT. We begeleiden u door de discovery- en monitorfasen als een gestructureerd proces, zodat u eerst uw werkelijke apparaat inventaris en verkeersbaseline ziet voordat u de toegang activeert. Als uw interne team daarvoor onvoldoende capaciteit heeft, kunnen we de policy cyclus ook als managed service uitvoeren.
Wilt u precies weten hoeveel apparaten er daadwerkelijk op uw netwerk aanwezig zijn? Dat is het gesprek waarmee u moet beginnen.
