Identity based attacks zijn de aanvalsvorm waar geen enkele alarmbel voor afgaat. Het NCSC vat het probleem in een zin samen: steeds vaker komt het voor dat hackers niet inbreken maar juist inloggen met legitieme inloggegevens. Er is dan geen exploit, geen malware en geen afwijkend netwerkverkeer. Er is een geslaagde login, precies zoals duizenden andere die dag. Toch behandelen de meeste Nederlandse organisaties identiteitsbeheer nog als een beheertaak en detectie als securitywerk, terwijl deze aanvalsvorm juist op de naad tussen die twee leeft.
Wat de cijfers wel en niet zeggen
Het Data Breach Investigations Report 2026 van Verizon laat een verschuiving zien die vaak verkeerd wordt gelezen. Wereldwijd is misbruik van inloggegevens gezakt naar 13 procent van de inbraken, waarmee het exploitatie van kwetsbaarheden als belangrijkste toegangsweg heeft moeten laten voorgaan. In de EMEA-regio ligt dat cijfer echter op 25 procent, bijna het dubbele van het wereldgemiddelde.
Dat regionale verschil is voor wie identity based attacks serieus neemt de relevante uitkomst. Identity based attacks zijn hier verhoudingsgewijs een groter probleem dan de wereldwijde krantenkoppen suggereren, en de daling in het mondiale cijfer betekent niet dat er minder wordt aangevallen, maar dat andere vectoren harder groeien.
Het rapport legt ook een pijnlijke blootstelling bloot bij ketenpartners: van de onderzochte derde partijen had slechts 23 procent ontbrekende of onjuist ingestelde meervoudige authenticatie op clouddiensten volledig verholpen. Bij zwakke wachtwoorden en verkeerd ingestelde rechten duurde het bijna acht maanden voordat de helft van de bevindingen was opgelost. Dat zijn geen detectieproblemen maar beheerproblemen, en ze bepalen wel of je detectieteam iets te doen krijgt.
Waarom je SOC dit niet alleen kan oplossen
Bij identity based attacks heeft een SOC-analist die naar een geslaagde login kijkt drie vragen: is dit de juiste persoon, hoort deze persoon hier te komen, en is dit normaal voor deze persoon. Voor geen van die drie vragen zit het antwoord in het securityplatform. Ze zitten in de identiteitsinfrastructuur: in de autorisatiematrix, in de rollenstructuur, in de historie van wie welke rechten wanneer heeft gekregen.
Zonder die context is een alert op een ongebruikelijke login niet te beoordelen. Een inlog vanuit Duitsland om half zeven ’s ochtends is verdacht of volstrekt normaal, afhankelijk van of deze medewerker een grensregio-rol heeft. Bij identity based attacks bepaalt de kwaliteit van je identiteitsbeheer dus rechtstreeks hoe bruikbaar je detectie is. Dat is dezelfde afhankelijkheid die we beschreven bij SIEM-investeringen zonder getrainde analisten: het platform levert pas rendement als de omliggende structuur klopt.
Het NCSC benoemt de gebreken die dit veroorzaken expliciet: onvoldoende controle op gebruikersrechten leidt tot te ruime toegang, structurele privilege-accumulatie en onbeheerde accounts. Privilege-accumulatie is daarbij het meest onderschatte: een medewerker die in twaalf jaar vier functies had en bij elke wissel rechten kreeg zonder dat de oude werden ingetrokken, is een aantrekkelijker doelwit dan de systeembeheerder zelf. Hoe je zulke structurele tekortkomingen in kaart brengt, past binnen de aanpak uit ons artikel over het cybersecurity maturity model.
Het vaardighedenprofiel van een IAM-engineer
Hier zit de kern van het probleem dat identity based attacks in Nederlandse organisaties zo effectief maakt. IAM wordt bijna altijd bemenst vanuit systeembeheer, en de vaardigheden die daar zitten zijn niet dezelfde als de vaardigheden die identity based attacks tegenhouden. Een goede beheerder zorgt dat mensen kunnen werken. Een IAM-engineer zorgt dat mensen precies genoeg kunnen werken en geen stap meer, wat een fundamenteel ander uitgangspunt is.
Concreet vragen identity based attacks om vier competenties die zelden in een beheerdersprofiel zitten. Het ontwerpen van een rollenstructuur die de organisatie volgt in plaats van de historie, inclusief periodieke herbeoordeling van rechten. Het beoordelen van authenticatiemethoden op weerbaarheid tegen specifieke aanvalstechnieken. Het inrichten van logging op identiteitsgebeurtenissen zodat detectie er iets mee kan. En het denken vanuit misbruik: welke route legt een aanvaller af vanaf dit account.
Die laatste vaardigheid is aanvalsdenken, en die leer je niet uit een beheerhandleiding. Het is dezelfde manier van kijken die centraal staat in de opleiding Penetration testing, waar deelnemers leren redeneren zoals een aanvaller dat doet. Een IAM-engineer die een keer zelf een pad van gewoon gebruikersaccount naar domeinbeheerder heeft gelopen, ontwerpt rechten anders dan iemand die dat alleen theoretisch kent.
Authenticatie is een risicokeuze, geen aanvinkvakje
Veel organisaties beschouwen hun weerbaarheid tegen identity based attacks als afgerond zodra meervoudige authenticatie aanstaat. Het NCSC is daar duidelijk over: niet alle vormen zijn gelijkwaardig. Authenticatie via sms of e-mail met een eenmalige code is de minst veilige vorm omdat die gelegenheid biedt tot phishing en man-in-the-middle-aanvallen, waarbij de aanvaller ook de code van de tweede stap onderschept.
Het advies dat daaruit volgt tegen identity based attacks is genuanceerder dan een generiek beleid. Deel accounts in op impact, en beveilig ze naar rato: beheerdersaccounts vragen om phishingbestendige authenticatie volgens de FIDO2-standaard, gastaccounts niet. Bij FIDO2 verlaat de privesleutel het geregistreerde apparaat niet en zijn inloggegevens uniek per systeem, waardoor onderschepping onbruikbaar wordt.
Deze afweging maken vraagt om iemand die zowel de techniek als het bedrijfsproces begrijpt. Kies je te zwaar, dan zoeken gebruikers omwegen en daalt de effectiviteit van de maatregel, precies zoals het NCSC waarschuwt over gebruikersgemak. Kies je te licht op de accounts die ertoe doen, dan is de maatregel cosmetisch. Identity based attacks vinden feilloos de accounts waar die afweging verkeerd is uitgevallen.
Hoe IAM en SOC praktisch samenwerken
Samenwerking tegen identity based attacks betekent niet dat beide teams elkaars werk gaan doen. Het betekent dat drie dingen zijn belegd voordat er iets misgaat. Ten eerste levert IAM de context die detectie nodig heeft: een actueel overzicht van rollen, van accounts met verhoogde rechten en van uitzonderingen op het standaardbeleid. Zonder dat overzicht is elk identiteitsalert een onderzoek vanaf nul.
Ten tweede spreekt het securityteam af welke gebeurtenissen die op identity based attacks wijzen automatisch een melding opleveren: een nieuw aangemaakt beheerdersaccount, een wijziging in doorstuurregels, een verleende OAuth-toestemming, een login vanaf een onbekend apparaat bij een high-impact account. Dat zijn geen exotische indicatoren, maar ze worden zelden gemonitord omdat niemand zich eigenaar voelt.
Ten derde is er een afspraak over wat er gebeurt na een bevestigde compromittering. Wachtwoord resetten is niet genoeg wanneer een aanvaller al een sessietoken, een applicatietoestemming of een tweede factor heeft geregistreerd. Dat vraagt om een uitgewerkte procedure die beide teams kennen, in dezelfde geest als de aanpak uit ons artikel over threat hunting binnen het bestaande team. Wie de identiteitsketen ook richting leveranciers wil doortrekken, vindt de aanpak in ons stuk over supply chain security.
Opleiden in plaats van werven
De arbeidsmarkt voor engineers die identity based attacks kunnen tegenhouden is krap en de functietitel is in Nederland nog niet uitgekristalliseerd, waardoor vacatures vaak een onmogelijke combinatie van eisen bevatten. In ons artikel over een cybersecurity vacature schrijven staat waarom dat kandidaten kost, en in de verborgen kosten van een onbezette vacature wat het uitstel financieel betekent. Voor de meeste organisaties is intern opleiden dan ook de snellere route.
Het startpunt voor het opbouwen van weerbaarheid tegen identity based attacks ligt gunstig. De mensen die je nodig hebt zitten al in je organisatie: beheerders die de omgeving door en door kennen en alleen de securitylaag missen. De opleiding Cyber Security Specialist is precies voor die overstap gebouwd en brengt een IT-medewerker in vijftien weken naar een inzetbaar securityniveau, inclusief de netwerk- en systeemfundamenten waarop identiteitsbeheer rust. Wie de detectiekant wil versterken, komt uit bij de opleiding SOC T1 + T2 Analyst voor triage van identiteitsalerts, of bij de opleiding SOC T3 Analyst voor zelfstandig onderzoek naar de reikwijdte van een compromittering.
Loopt een zaak uit op bewijsvoering, bijvoorbeeld omdat een account maandenlang misbruikt bleek, dan telt de kwaliteit van het onderzoek; de opleiding Cyber Forensics Expert richt zich op sporen die later standhouden. En omdat identiteitswerk een logische opstap is naar bredere engineeringrollen, sluit dit aan op het pad dat we beschreven in van SOC-analist naar security engineer.
Denk daarbij in leerpaden en niet in losse cursussen. Identity based attacks vragen om mensen die zowel ontwerp als detectie beheersen, en die combinatie bouw je op over meerdere stappen. Welke rollen je daarvoor nodig hebt en in welke volgorde, werkten we uit in je eerste securityteam samenstellen en in ons artikel over carrierepaden als retentie-instrument. Dat perspectief is ook wat mensen bindt: een beheerder die ziet dat er een route is naar een specialistische rol, vertrekt minder snel.
Certificaten alleen dekken deze combinatie zelden af, zoals we eerder betoogden in certificering versus ervaring. Wat telt is of iemand een rollenstructuur kan ontwerpen die over drie jaar nog klopt, en dat toets je in de praktijk. Dezelfde redenering als in information security structureel verbeteren: structurele capaciteit boven losse maatregelen.
Hoe je zo’n leerpad opbouwt vanuit je huidige bezetting, van open klas tot in-company traject op je eigen identiteitsomgeving, staat op de pagina voor werkgevers. Het volledige niveauoverzicht vind je bij alle opleidingen. Wil je bespreken welk pad past bij de volwassenheid van jouw identiteitsbeheer? Bekijk de eerstvolgende startdata of plan een kennismaking.
