De angstaanjagende waarheid over vertrouwen: waarom "geverifieerd" zijn niet betekent dat je veilig bent

Laten we het hebben over iets waar beveiligingsspecialisten wakker van liggen. Het is niet de hacker met een hoodie die je in films ziet. Het is niet een geavanceerde zero-day exploit. Het is iets veel simpelers en oneindig veel gevaarlijker: de aanname dat het verifiëren van de identiteit gelijkstaat aan het verifiëren van de authenticiteit.

Ik kwam onlangs een fascinerende (en lichtelijk angstaanjagende) casus tegen, en ik kan er maar niet aan denken stoppen. Een bedrijf — laten we ze een typisch middelgroot bedrijf noemen — maakte niet één, niet twee, maar DRIE afzonderlijke beveiligingsincidenten door in vier maanden tijd. En hier komt de crux: bij geen van deze incidenten ging het om het binnendringen in netwerken of het uitbuiten van softwarefouten. Bij elke keer werd de aanvaller simpelweg iemand die het bedrijf al vertrouwde.

Dat is... eigenlijk best wel verontrustend als je erover nadenkt.

Het wachtwoord was perfect. De persoon niet.

Dit is het probleem met traditionele beveiliging: we behandelen authenticatie als een probleem van slot en sleutel. Krijg het juiste wachtwoord, slaag voor de MFA-check, en boem — je bent binnen. Maar wat als het slot precies werkt zoals ontworpen, en de persoon die erdoorheen loopt gewoon... niet is wie hij beweert te zijn?

De gevallen waar ik naar verwijs, lieten drie verschillende varianten van exact dit probleem zien. Ten eerste was er een CFO die een telefoontje kreeg van "IT-support" over verdachte activiteiten op zijn account. Het naamdisplay toonde een intern nummer. De beller kende de MFA-provider van het bedrijf. Ze wisten dat de CFO op reis was (omdat hij erover postte op sociale media, want dat doet hij natuurlijk — wij doen het allemaal). Ze hadden zelfs informatie uit oude datalekken rondzweven op het dark web.

Alles wat ze nodig hadden, was dat hij een verificatiecode hardop voorlas. En dat deed hij.

Binnen twintien minuten gebruikte iemand zijn e-mail om dringende betalingen aan te vragen. De enige reden dat er geen geld werd verplaatst? Een scherpe specialist crediteuren die het gevoel had dat de aanvraag "niet klopte" en hem rechtstreeks belde. Dat menselijke instinct heeft de dag gered.

Vertrouw, maar verifieer (behalve wanneer je dat niet doet)

Wat me het meeste opvalt aan deze incidenten is niet de geavanceerdheid van de aanvallen — het is hoe saai ze eruit zouden zien voor de meeste beveiligingssystemen. De inloggegevens klopten. De authenticatie was geslaagd. De sessies waren geldig.

Maar ergens onderweg zijn we vergeten dat verificatie niet alleen gaat over het afvinken van vakjes. Het gaat erom te bevestigen dat de mens aan de andere kant daadwerkelijk is wie hij zegt te zijn — en dat hij een legitieme reden heeft om te doen wat hij doet.

Het tweede incident betrof een medewerker in remote dienstverband die volkomen legitiem leek. Een geweldig cv. Geloofwaardige referenties. Een solide portfolio. Maar hier komt het: niets van dat alles is moeilijk te stelen. De persoon bleek de identiteit te gebruiken van een echte ingenieur, met volledig verzonnen referenties, en werkte vanuit het buitenland met bedrijfslaptops die naar een huurappartement waren gestuurd.

De enige reden dat dit werd opgemerkt? Iemand merkte op dat de laptop het meest actief was tijdens de nachtelijke uren. Dat was het. Geen geavanceerde detectie. Gewoon iemand die aandacht had voor iets dat een beetje vreemd leek.

Het sessieprobleem waar niemand over praat

En dan is er het derde incident, wat volgens mij de meest over het hoofd geziene dreiging is in moderne beveiliging. Het account van een executive werd benaderd vanuit Roemenië. Zij sliep op dat moment in Ohio.

Haar wachtwoord was niet gecompromitteerd. Haar MFA was niet omzeild. In plaats daarvan had malware op een gedeelde thuiscomputer haar browser-sessiecookies geoogst. De aanvaller liep zo de digitale voordeur binnen, verschijnend als een volkomen legitieme, geauthenticeerde gebruiker.

Dit is het duistere geheim van sessie-gebaseerde authenticatie: als je eenmaal binnen bent, blijf je vaak ook binnen. Sessietokens kunnen uren of zelfs dagen geldig blijven. En in tegenstelling tot wachtwoorden zijn ze niet iets wat gebruikers gemakkelijk kunnen beschermen of wijzigen.

Wat is dus de werkelijke les?

Ik denk niet dat de les hier is "wees paranoïder" (hoewel een beetje gezonde paranoia eerlijk gezegd nooit kwaad kan). Ik denk dat het echte inzicht ligt in de kloof tussen identiteitsverificatie en vertrouwensbevestiging.

De meeste organisaties zijn inmiddels erg goed geworden in het eerste deel. We verifiëren inloggegevens, we dwingen MFA af, we vinken vakjes af. Maar het tweede deel — het continu bevestigen dat iemand nog steeds geautoriseerd is en zich passend gedraagt — dat is waar we tekortschieten.

De gevallen die ik bespreek, hadden allemaal iets anders gemeen: ze werden opgemerkt door mensen of door op mensen ontworpen systemen die zochten naar gedragsafwijkingen, niet alleen naar authenticatiefouten. Een collega die een ongebruikelijke aanvraag in twijfel trok. Een analist die vreemde werkpatronen opmerkte. Een geautomatiseerd systeem dat "onmogelijke reizen" signaleerde.

Technische controles zijn noodzakelijk. Maar ze zijn niet voldoende. De echte beveiligingsversterker is het bouwen van een cultuur waarin mensen zich gemachtigd voelen om dingen te bevragen die niet kloppen — zelfs wanneer de inloggegevens kloppen.

Want hier is de ongemakkelijke waarheid: in het huidige dreigingslandschap is het grootste beveiligingsrisico misschien niet de aanvaller buiten je muren. Het is de volkomen legitiem lijkende identiteit die al binnen is.

Blijf waakzaam, vrienden.

Tags: ['identity-security', 'social-engineering', 'business-security', 'remote-work-security', 'authentication']