Identiteit en zero trust

In ons vorige blog stelden we al dat zero trust een logische reactie is op de ontwikkelingen in het dreigingslandschap. Dat geldt ook voor het domein van identiteit. Waar vroeger een gebruikersnaam en wachtwoord voldoende leken, is dat inmiddels achterhaald. Waarom? Omdat wachtwoorden voortdurend worden gestolen via malware of phishing van inloggegevens.
Bovendien blijkt de mens slecht in het bedenken en onthouden van sterke wachtwoorden. Hackers weten dit en proberen met veelgebruikte of gelekte wachtwoorden toegang te krijgen.

De verplichting om wachtwoorden regelmatig te wijzigen bleek een doodlopende weg: gebruikers gingen juist zwakkere, voorspelbare wachtwoorden gebruiken en schreven ze op. Ook complexiteitsvereisten hielpen niet echt. Mensen creëren dan wel wachtwoorden die aan de eisen voldoen, maar die toch makkelijk te raden zijn, zoals “Welkom123!”.

Wachtwoorden vormen slechts een beperkte barrière. Logischerwijs moeten we het de aanvaller dus moeilijker maken. Multifactorauthenticatie (MFA) werd de nieuwe norm. Maar ook traditionele MFA-technieken zijn niet meer zo veilig als voorheen. Vooral bij phishingaanvallen biedt klassieke MFA vaak geen bescherming meer, omdat aanvallers deze eenvoudig integreren in hun aanval.

Misschien zakt de moed je nu in de schoenen. Hoe nu verder? Is er licht aan het einde van de tunnel? Ja, dat is er zeker. In een zero trust-aanpak wordt het begrip identiteit opgerekt. Het draait niet alleen om de gebruikersnaam, maar ook om het apparaat waarmee wordt ingelogd en de context, zoals locatie, tijdstip of signalen van verdachte activiteiten.

Stel: een hacker logt in met een correct wachtwoord én een goedgekeurde MFA-aanvraag. Hoe houden we hem dan toch tegen?
Simpel: de hacker heeft geen toegang tot de computer van de gebruiker. Hij logt immers in vanaf een andere locatie en een ander apparaat. Daarom willen we dat niet alleen de gebruiker zich authenticeert, maar ook het apparaat. De authenticatie van het apparaat kan zich onopgemerkt op de achtergrond voltrekken. Alleen als beide authenticatiepogingen slagen, krijgt de gebruiker toegang. Een krachtig en effectief concept.

Dit werkt allemaal prima, behalve als de computer zelf is gehackt – bijvoorbeeld doordat de gebruiker malware heeft geopend. De hacker heeft dan immers wél toegang tot het apparaat van de gebruiker en de aanvaller lift dan mee op de geslaagde authenticatiepogingen van zowel de gebruiker als het apparaat.

Dan komt detectie in beeld. Een hacker gedraagt zich anders dan een gewone gebruiker: hij zoekt koortsachtig naar gevoelige data, probeert systemen te verkennen, downloadt veel gevoelige bestanden en voert ongebruikelijke handelingen uit. Ons detectiesysteem moet dit afwijkende gedrag herkennen en kunnen ingrijpen, bijvoorbeeld door de sessie te beëindigen. Maar het kan ook subtieler, door de gebruiker opnieuw te laten authenticeren of tijdelijk rechten in te perken. Een hacker komt dan in de problemen omdat hij niet altijd de MFA-verificatie kan voltooien. Het meenemen van dit soort verdachte signalen en andere contextgegevens in de afweging om toegang te verlenen of te behouden noemt de NEN 7510 in deel 2 (NEN 7510-2:2024) ‘dynamische toegangsbeveiligingstechnieken’.

Hoewel we wachtwoorden en traditionele MFA deels hebben afgeschreven, zijn ze niet volledig nutteloos. We kunnen wachtwoorden verbeteren door gebruik te maken van wachtwoordzinnen: combinaties van willekeurige woorden en tekens. Bijvoorbeeld: “Welkom123!” is makkelijk te raden, maar ‘WelkomKleineSmurf!!!’ is veel sterker en toch goed te onthouden omdat het ook grappig is. Dit wachtwoord wijzigen we alleen als uit onze detectie blijkt dat het account is gehackt of het wachtwoord is uitgelekt. Op plekken waar een wachtwoordmanager beschikbaar is, kiezen we voor lange en complexe wachtwoorden die niet te kraken, te onthouden of te raden zijn. Ook kunnen we ervoor zorgen dat onze identiteitsoplossing het gebruik van makkelijk te raden of gelekte wachtwoorden blokkeert.

Daarnaast kan MFA worden versterkt. De klassieke authenticatiecode is passé. Tegenwoordig kiezen we, waar mogelijk, voor phishing-resistente MFA. Hierbij wordt ook gecontroleerd op welke pagina wordt ingelogd, zodat een phishingaanval alsnog faalt.

Wat willen we nu precies? Een identiteitsoplossing die naast de gebruiker ook het apparaat meeneemt in de authenticatie. Een systeem dat geïntegreerd is met een detectieoplossing die afwijkend gedrag herkent en daarop reageert. Gebruiksvriendelijke maar sterke wachtwoordzinnen, blokkeren van makkelijk te raden wachtwoorden, monitoring op gelekte wachtwoorden, inzet van wachtwoordmanagers en phishing-resistente MFA.

Zijn we dan klaar? We zijn goed op weg. Maar er is nog één belangrijk punt: de systemen en diensten waarop we inloggen moeten deze dynamische ‘risk based’ identiteitscontroles ondersteunen. Alleen dan kunnen we overal dezelfde risicoafweging maken en indien nodig automatisch ingrijpen. We moeten op alle systemen en diensten waarop wordt ingelogd dezelfde identiteitsoplossing gebruiken die het beleid kan afdwingen.

Makkelijker gezegd dan gedaan, maar gelukkig ondersteunen steeds meer oplossingen standaard het gebruik van een externe identiteitsprovider die al deze functionaliteiten biedt. Doen we dit niet, dan ontstaat er wildgroei aan accounts in allerlei systemen, vaak met zwakke wachtwoorden. Bovendien verliezen we het zicht op wat er allemaal in onze IT-omgeving gebeurt.

En als het dan toch misgaat? Dan willen we dat een aanvaller niet meer kan stelen of vernielen dan strikt noodzakelijk. Daarom hanteren we het least privilege-principe: gebruikers krijgen alleen de rechten die ze écht nodig hebben. En is het nodig dat accounts van leveranciers of systeembeheerders continu openstaan? Nee, we willen dat deze accounts via een gecontroleerd proces worden gebruikt, zodat ze alleen actief zijn op het moment dat het echt nodig is. Met andere woorden: we willen een Privileged Access Management-systeem.

Genoeg haakjes dus om je security-architectuur aan te scherpen. Ook al kun je niet alles in één keer realiseren, we hopen met dit verhaal handvatten te bieden om je beveiliging stap voor stap te verbeteren. Gelukkig helpen moderne cloudoplossingen je hierbij een handje, door veel van deze functionaliteiten standaard aan te bieden.

Is dit verhaal wat overweldigend? Geen probleem. Vraag AI om dit verhaal te vertalen naar een concrete roadmap, afgestemd op jouw eigen situatie en volwassenheid. En vergeet niet om de zero trust-aanbevelingen voor identiteit te implementeren die de NEN 7510 doet in deel 2.