Zero Trust: where is the silver bullet?

Zero Trust: where is the silver bullet?

Het Zero Trust model is inmiddels al meer dan tien jaar geleden geïntroduceerd door John Kindervag. De ideeën achter het model zijn zelfs nog ouder. Maar mede door de pandemie is er op dit moment veel aandacht voor. Het Zero Trust model heeft als belangrijkste leitmotiv dat een beveiligingsregime van een IT-omgeving niet kan volstaan met een controle van de toegang tot het netwerk.

Kindervag vergeleek dit traditionele regime met een M&M: een harde schil met een zachte binnenkant. Is een hacker eenmaal binnen in een IT-omgeving, dan kan hij vaak vrijelijk toegang krijgen tot vrijwel alle resources in die IT-omgeving. Voorbeelden te over van hackers, die soms maanden in de IT-omgeving van (niet de kleinste) organisaties hebben kunnen ronddolen en hun illegale activiteiten hebben kunnen uitvoeren.

Het Zero Trust model is gebaseerd op het belangrijke uitgangspunt dat alle toegang tot middelen in de IT-omgeving van de organisatie constant gecontroleerd moet worden. Iedere poging om toegang te krijgen tot een onderdeel van de IT-omgeving is per definitie verdacht. Het Zero Trust model heeft impact op alle onderdelen van een IT-omgeving:

De identiteit van een user-account, een service-account, een IOT device of zelfs een applicatie moet onomstotelijk vastgesteld kunnen worden via authenticatie en zo nodig MFA.
Toegang tot devices (printers, IoT devices…), data en applicaties moet expliciet JIT verleend worden, waarbij rechten op basis van least-priviliged uitgangspunten vastgesteld worden en de toegang zo dicht mogelijk bij de resources of applicaties verleend wordt. Idealiter vanuit de resource of applicatie zelf.
Data moet geclassificeerd zijn en zowel tijdens opslag als transport encrypted zijn.
De infrastructuur, zowel on-premisse als in de cloud, moet uiteraard gehardened zijn en middelen hebben om abnormaal, ongewenst gedrag te detecteren en er op te reageren.
Het netwerk tenslotte moet in voldoende mate gesegmenteerd zijn, intrusions voorkomen en permanent gemonitord en geanalyseerd worden.

Dat betekent nogal wat, want de IT-omgevingen zijn daar traditioneel niet op toegerust. Deze tekortkoming is manifester geworden vanwege de Coronacrisis en het toenemend gebruik van de public cloud. Er wordt op grote schaal thuisgewerkt, soms op basis van BYOD. Iedereen maakt beroepsmatig wel gebruik van meerdere SaaS applicaties en Microsoft 365 is inmiddels volledig ingeburgerd. Applicaties en data die voorheen alleen vanuit de beschermde kantooromgeving van de organisatie bereikbaar waren, worden nu via internet toegankelijk van buitenaf. Kortom een grote uitdaging om alles op basis van de Zero Trust uitgangspunten te kunnen managen.

Halverwege vorig jaar heeft het NIST (National Institute of Standards and Technology) een studie gepubliceerd over Zero Trust Architecture (NIST SP 800-207). Een heel abstract voorstel voor een architectuur ten behoeve van de implementatie van Zero Trust. Het lijkt een beetje op twee gedachten te hinken en twee verschillende benaderingen tegenover te zetten: identity based en network based. Voor een aantal leveranciers van mogelijke oplossingen is dat natuurlijk een mooie gelegenheid om de hen ondersteunende krenten uit de abstracte pap te plukken. Vooral uit de hoek van leveranciers van netwerkoplossingen is de creativiteit groot en worden nieuwe begrippen niet geschuwd: deperimetrization, micro-perimeter solutions, next-generation firewalls die gebruikers toegang ontzeggen, trustzones met applicaties met eenzelfde beveiligingsbehoefte.

Ze gaan voorbij aan een belangrijke eigenschap die alle netwerkoplossingen ontberen: het herkennen van identiteiten van gebruikers, applicaties en veelal ook devices. Daarbij komt dat de dynamiek en de granulariteit van autorisatiestructuren beide meestal erg groot zijn. Menig RBAC initiatief is al gesneuveld op deze obstakels. Als een verandering in de autorisatiestructuur een verandering in de netwerkinrichting tot gevolg kan hebben en als door micro-segmentering het netwerk kan versnipperen, dan kon het middel beheersmatig wel eens erger zijn dan de kwaal. Daarnaast bieden de netwerk leveranciers geen oplossing voor hetgeen zich niet on-premisse afspeelt: het device van de gebruiker, de public cloud resources of de SaaS applicatie.

Gelukkig zijn er voor het administreren en beheren van identiteiten prima werkende oplossingen in gebruik: bijvoorbeeld Kerberos of Active Directory, de Microsoft implementatie ervan. Daarmee kunnen ook gefedereerde rechten voor cloud resources beheerd worden. Sterker nog, door gebruik te maken van Microsoft’s IRM wordt de autorisatie min of meer onderdeel van de resource zelf. Het werkt zelfs voor een beperkt aantal distributies van Linux. Naast het administreren en beheren van de identiteiten, hebben de werkende oplossingen ook een buitengewoon robuust authenticatieproces. Door daar gebruik van te maken wordt Single Sign On, ook in een Zero Trust model, vanzelfsprekend. Maar ja, die werkende oplossingen missen weer een heleboel eigenschappen die ook nodig zijn om het Zero Trust model succesvol te implementeren. Zo ontbreken vooral de mogelijkheden rond het detecteren en onmiddellijk reageren op inbraakpogingen, zoals deep packet inspections, TLS/SSL encrypted traffic inspections, website filtering, intrusion prevention. Daar hebben we toch weer netwerkspecialisten voor nodig en next generation firewalls (NGFW). Wellicht moet de NGFW in sommige gevallen ook weten welke user of resource een bepaald type verkeer genereerd. In zo’n geval moet de NGFW op een veilige manier toegang hebben tot informatie van de identiteitsbeheerder. Dat betekent dat het controleren van meerdere OSI-lagen steeds noodzakelijker wordt om de hackers voor te kunnen blijven. Maar wat in het NIST model node wordt gemist, is de rol van de applicatie of het device. Als de autorisatie intrinsiek in de applicatie of het device ingebouwd is en er gebruik gemaakt kan worden van de authenticatie kwaliteiten van de identiteitsbeheerder, dan is er geen apart micro-perimeter of NGFW denial nodig om al of niet toegang te verlenen tot een applicatie of een device.

Het is dus duidelijk dat de oplossing voor de implementatie van het Zero Trust model uit verschillende componenten zal bestaan. Het gaat om segmentatie, NGFW, intrusion prevention, monitoring en analyse, maar ook om eenduidige authenticatie, MFA, ingebouwde autorisaties, ATP oplossingen op de devices.

Kortom: alle componten in de gehele keten van IT dienstverlening zullen hun steen moeten bijdragen. Waarbij een centrale rol  weggelegd is voor de identiteitsbeheerder. Op één centraal punt wordt het bestaan van de identiteit geadministreerd en de controle op validiteit gedaan. Dan kan er werkelijk sprake zijn van SSO. Maar de netwerkcontroles blijven. En ook de cloud-beheerders en applicatie- en device-ontwikkelaars zullen een duit in het zakje moeten doen. De gestandaardiseerde protocollen (SAML, OAuth) zijn beschikbaar en werken ook echt. Het lijkt erop dat er nog veel samenwerking nodig is om het Zero Trust model te implementeren en dat iedere leverancier die zegt dé oplossing te hebben, aan een gebrekkig inzicht in het Zero Trust model leidt. Er is nog veel werk aan de winkel en de silver bullet is (zoals wel vaker) ver te zoeken.

[contact-form-7 404 "Niet gevonden"]