24 miljard blootgestelde inloggegevens zijn in handen van aanvallers. Is uw control plane er klaar voor?
Op 15 juni 2026 maakten onderzoekers van Cybernews bekend dat zij een onbeveiligde Elasticsearch-cluster met 8,3 terabyte aan data hadden verwijderd – 24 miljard records met gebruikersnamen en wachtwoorden, verzameld uit 36 verschillende bronnen, voornamelijk bestaande uit Telegram-kanalen waar gestolen inloggegevens circuleren binnen criminele gemeenschappen. Ongeveer 22,6 miljard van deze records kwamen uit “collecties” – samengestelde sets van inloggegevens uit historische datalekken die beveiligingsteams in de meeste organisaties al hebben aangepakt via wachtwoordrotatie of het uitfaseren van systemen. De resterende records kwamen echter uit een geheel andere bron: infostealer-malwarelogs die inloggegevens vastleggen die actief zijn buitgemaakt uit live bedrijfsomgevingen.
Dat onderscheid – historische collecties versus actuele infostealer-output – is het verschil tussen een achtergrondbedreiging en een actief operationeel risico. Infostealers zoals RedLine, Lumma en Vidar verzamelen inloggegevens rechtstreeks van de apparaten waarop medewerkers dagelijks inloggen: browsers, desktopapplicaties, wachtwoordmanagers en bedrijfs-SaaS-portalen. De inloggegevens in deze logs zijn niet afkomstig uit een datalek van vijf jaar geleden. Ze zijn afkomstig van endpoints die momenteel in productie draaien, en de authenticatiegegevens die ze hebben vastgelegd zijn nog steeds geldig totdat ze worden geroteerd.
Voor organisaties die moeten voldoen aan HIPAA-naleving, CMMC 2.0 naleving, FedRAMP-autorisatie of vergelijkbare regelgevende kaders, is de rekensom eenvoudig maar confronterend. Een personeelsbestand van enkele duizenden medewerkers zal, met bijna statistische zekerheid, een deel van zijn inloggegevens terugvinden in een verzameling van 24 miljard records. De vraag die compliance officers en beveiligingsteams moeten stellen is niet of die inloggegevens in de database staan. Het is: wat kan een aanvaller bereiken als hij ze succesvol gebruikt, en beperkt uw huidige architectuur dat risico?
Deze post beantwoordt die vraag direct – hoe infostealer-gedreven blootstelling van inloggegevens werkt, waarom gereguleerde sectoren asymmetrische gevolgen ondervinden, en wat een Kiteworks control plane voor veilige gegevensuitwisseling moet doen wat een perimeterverdediging niet kan.
Belangrijkste inzichten
1. Infostealer-afgeleide records vormen de daadwerkelijke dreiging, niet historische collecties
Het merendeel van de 24 miljard records bestaat uit gerecyclede historische datalekken. De infostealerlogs zijn anders – deze inloggegevens zijn buitgemaakt van live bedrijfsapparaten en kunnen nog steeds geldig zijn, waardoor ze het actiegerichte deel vormen waar aanvallers prioriteit aan geven.
2. Gereguleerde sectoren dragen asymmetrische aansprakelijkheid per succesvolle login
Een enkele succesvolle accountovername die toegang krijgt tot beschermde gezondheidsinformatie, gecontroleerde niet-geclassificeerde informatie of gereguleerde financiële data, activeert verplichte meldingen van datalekken en brengt handhavingsrisico’s met zich mee – ongeacht hoeveel data daadwerkelijk is ingezien.
3. Wachtwoordbeveiliging heeft gefaald op de schaal van 24 miljard records
De aanname dat wachtwoordcontroles bedrijfsdata voldoende beschermen is niet langer houdbaar. Multi-factor authentication, op attributen gebaseerde toegangscontrole en continue audit logging zijn geen optionele lagen – ze zijn het vereiste minimum voor omgevingen die gevoelige data verwerken.
4. De control plane voor veilige gegevensuitwisseling is de laatste betekenisvolle verdediging na diefstal van inloggegevens
Aanvallers die succesvol authenticeren met gestolen inloggegevens richten zich op portals voor bestandsoverdracht, beveiligde e-mailplatforms en samenwerkingsomgevingen waar gevoelige data daadwerkelijk aanwezig is. Een uniforme control plane – één beleidssysteem, één audit log, één beveiligingsstatus over alle kanalen – bepaalt wat ze kunnen bereiken en wat wordt vastgelegd.
5. Credential-stuffing risico hoort thuis in compliance risicoregisters en rapportages op bestuursniveau
De combinatie van de 24 miljard records, actieve infostealer-campagnes en de handhavingspositie binnen zorg, defensie en financiële sector betekent dat accountovername op basis van inloggegevens niet langer een technisch probleem is – het is een governance-prioriteit.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het bewijzen?
Lees nu
De twee populaties binnen die 24 miljard records
Beveiligingsprofessionals die grote verzamelingen inloggegevens afdoen als “oud nieuws” hebben niet helemaal ongelijk – voor het deel dat uit collecties bestaat. Het merendeel van de 24 miljard records die Cybernews identificeerde, is afkomstig uit samengestelde datalekdatasets die al jaren op ondergrondse markten circuleren. Veel van deze inloggegevens zijn al geroteerd. Veel van de systemen waarop ze toegang gaven, bestaan niet meer. Beveiligingsteams die consequent wachtwoordhygiëne toepassen, meldingen van datalekken monitoren en periodieke rotatie afdwingen, hebben waarschijnlijk het grootste deel van dit risico al aangepakt.
De infostealer-afgeleide records vormen echter een fundamenteel ander probleem.
Infostealers zijn een categorie malware die specifiek is ontworpen om authenticatiegegevens van geïnfecteerde apparaten te extraheren. Ze werken door opgeslagen wachtwoorden uit de browser op te halen, sessiecookies te extraheren waarmee authenticatie zonder wachtwoord mogelijk is, toetsaanslagen vast te leggen bij inlogschermen en inloggegevens uit desktop-wachtwoordmanagers te verzamelen. De output – een gestructureerde “log” met gebruikersnamen, wachtwoorden en sessietokens, geordend per site en applicatie – wordt verpakt en verkocht op ondergrondse markten, meestal binnen enkele uren of dagen na de oorspronkelijke infectie.
De implicaties voor bedrijfsomgevingen zijn direct. Een medewerker wiens apparaat is geïnfecteerd met een infostealer heeft feitelijk zijn volledige authenticatieprofiel aan een aanvaller overgedragen. Elke bedrijfsapplicatie die hij gebruikt, elk portal voor bestandsoverdracht waarop hij inlogt, elk beveiligd e-mailplatform waarop hij authenticatie uitvoert – alles staat in de log. De organisatie heeft hier geen zicht op totdat het apparaat van de medewerker een endpoint-detectiealarm activeert of de aanvaller de gestolen inloggegevens probeert te gebruiken.
Wat de FortiBleed-campagne die dezelfde week werd onthuld – waarbij 86.000 bevestigde werkende inloggegevens van FortiGate-apparaten uit 194 landen werden verzameld en gepubliceerd – tot een relevant datapunt maakt, is dat hierbij kunstmatige intelligentie werd ingezet voor doelwitidentificatie en geautomatiseerde password spraying om de set inloggegevens uit te breiden en te valideren. De combinatie van grote verzamelingen inloggegevens en AI-ondersteunde validatie versnelt de omzetting van gestolen inloggegevens naar daadwerkelijk werkende toegang. Organisaties die niet consequent MFA afdwingen over alle bedrijfsapplicaties, opereren zonder adequate controles tegenover deze realiteit.
Waarom gereguleerde sectoren een ander risico lopen
Elke organisatie loopt risico door credential stuffing. Maar organisaties die onder HIPAA, CMMC, FedRAMP, ITAR of vergelijkbare kaders vallen, hebben een kwalitatief ander risicoprofiel omdat de consequentie van een enkele succesvolle authenticatie volledig afhangt van waar het gecompromitteerde account toegang toe heeft – en welke meldingsplichten dat activeert.
Onder HIPAA-naleving activeert ongeautoriseerde toegang tot beschermde gezondheidsinformatie meldingsplicht, ongeacht of de aanvaller daadwerkelijk data heeft geëxfiltreerd. Als de inloggegevens van een medewerker worden gebruikt om in te loggen op een gezondheidsinformatiesysteem en de sessie PHI raadpleegt – zelfs alleen door te bladeren – is dat een meldingsplichtig datalek onder de HIPAA Breach Notification Rule. De betrokken organisatie moet getroffen personen, het Department of Health and Human Services en, bij incidenten met 500 of meer personen, prominente media in de getroffen staten informeren. De kosten van die melding en het daaropvolgende onderzoek kunnen de kosten van elke firewall- of endpointbeveiligingsinvestering met een veelvoud overstijgen.
Onder CMMC 2.0-naleving activeert een gecompromitteerd account dat toegang krijgt tot gecontroleerde niet-geclassificeerde informatie (CUI) meldingsplicht onder DFARS 252.204-7012 binnen 72 uur na ontdekking. Het kan ook een herbeoordeling van de CMMC-certificeringsstatus van de organisatie in gang zetten. Defensie-aannemers die een CUI-datalek ervaren via credential compromise lopen niet alleen het incident response-risico, maar ook het risico hun CMMC-certificering – en daarmee hun mogelijkheid om mee te dingen naar DoD-contracten – te verliezen of te laten schorsen.
FedRAMP-naleving creëert vergelijkbare verplichtingen voor cloud service providers en federale instanties, waarbij elke ongeautoriseerde toegang tot federale data onmiddellijke incidentmelding aan de betreffende instantie en CISA vereist.
Het verschil is duidelijk: een gecompromitteerde inlog bij een consumentgerichte retailer kan leiden tot aansprakelijkheid voor fraude. Dezelfde inlog bij een zorgverlener, defensie-aannemer of federale instantie activeert verplichte overheidsmelding, mogelijke handhavingsmaatregelen en certificeringsgevolgen die veel verder gaan dan de kosten van het incident zelf. Organisaties die scenario’s van accountovername op basis van inloggegevens niet expliciet hebben opgenomen in hun risicobeoordelingen per relevant kader, werken met een onbenoemd gat.
Het draaiboek voor credential stuffing tegen contentplatforms
Begrijpen hoe aanvallers grote databases met inloggegevens inzetten tegen bedrijfscontentplatforms maakt duidelijk waarom de verdedigingsarchitectuur net zo belangrijk is als de authenticatielaag.
Credential stuffing-aanvallen volgen een voorspelbare volgorde. Een aanvaller verkrijgt een set inloggegevens – uit een verzameling zoals Cybernews documenteerde, uit aangekochte infostealerlogs of via gerichte phishing – en begint geautomatiseerd te testen op doelplatforms. Moderne credential stuffing-tools kunnen tienduizenden combinaties per minuut testen op een webapplicatie, waarbij ze IP-adressen en user agents roteren om rate limiting en detectie te omzeilen. Wanneer een combinatie slaagt, registreert de tool de bevestigde toegang en zet deze klaar voor handmatige of geautomatiseerde opvolging.
De vervolgstap is waar contentplatforms het doelwit worden. Een aanvaller met bevestigde toegang tot een bedrijfsaccount zal niet direct alles exfiltreren – dat triggert detectie op basis van hoeveelheid. Ze bootsen normaal gebruikersgedrag na, blijven soms dagen of weken inactief voordat ze op zoek gaan naar waardevolle bestanden. Ze kunnen de toegang gebruiken om naar extra accounts te pivoteren via interne adressenlijsten of communicatieplatforms waar inloggegevens of sessietokens worden gedeeld. Wanneer ze toeslaan, richten ze zich op documenten – contracten, financiële administratie, technische tekeningen, medische dossiers, gereguleerde data – die direct te gelde kunnen worden gemaakt of voor afpersing kunnen worden gebruikt. Dataclassificatiecontroles die gevoelige content labelen en toegang beperken per gevoeligheidsniveau zijn een directe tegenmaatregel tegen dit gedrag.
De Klue supply chain-aanval die in dezelfde nieuwsronde werd onthuld – waarbij aanvallers gecompromitteerde OAuth-tokens gebruikten om toegang te krijgen tot Salesforce-omgevingen van LastPass, HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, Tanium en anderen – volgde exact dit patroon. Het gebruikte authenticatiemechanisme verschilde (OAuth-tokens versus wachtwoorden), maar het doel was hetzelfde: geauthenticeerde toegang tot documentopslag en bedrijfsdata op schaal. De implicaties voor risicobeheer in de toeleveringsketen zijn groot: toegang van derden tot bedrijfsomgevingen creëert blootstellingsroutes voor inloggegevens die interne hygiëneprogramma’s alleen niet kunnen dichten.
Voor organisaties die beveiligde beheerde bestandsoverdracht, beveiligde e-mail, SFTP of samenwerkingsplatforms voor content gebruiken, is de credential stuffing-dreiging direct. Dit zijn precies de applicaties waar gevoelige gereguleerde data zich bevindt, en precies de applicaties waarvan medewerkers’ inloggegevens in browsers zijn opgeslagen en door infostealers worden buitgemaakt.
Waarom de wachtwoordlaag al is verslagen
Het conceptuele probleem met wachtwoordgebaseerde authenticatie als beveiligingsmaatregel is dat het ervan uitgaat dat het wachtwoord geheim blijft. Op de schaal van 24 miljard blootgestelde inloggegevens – met een actief infostealer-ecosysteem dat continu nieuwe verzamelt – is die aanname operationeel niet houdbaar voor grote organisaties.
Wachtwoordrotatiebeleid helpt, maar sluit het gat niet. Als de inloggegevens van een medewerker worden buitgemaakt door een infostealer en de organisatie hanteert een 90-dagenrotatie, is er een venster van 90 dagen waarin een aanvaller die gegevens vrij kan gebruiken. Als rotatie wordt afgedwongen op basis van meldingen van datalekken, zit er meestal een vertraging van dagen tot weken tussen de diefstal en het moment dat de organisatie zich ervan bewust is. Infostealers zijn ontworpen om precies in dat gat te opereren.
Sessietoken-harvesting maakt het probleem nog erger. Moderne infostealers verzamelen niet alleen wachtwoorden, maar ook browsersessiecookies waarmee authenticatie zonder wachtwoord mogelijk is – en waarmee zelfs MFA in sommige configuraties wordt omzeild, aangezien het sessietoken is uitgegeven na een legitieme MFA-gebeurtenis. Sessie hijacking via gestolen cookies is een gedocumenteerde aanvalstechniek waarvoor de aanvaller het wachtwoord van het slachtoffer niet hoeft te kennen.
Dit betekent architectonisch dat de verdediging zo moet zijn ontworpen dat deze werkt, zelfs als credential compromise wordt aangenomen. Dit is de logica achter zero-trust beveiligingsprincipes: in plaats van te vertrouwen dat de authenticatie klopt omdat er een geldig inloggegeven is gepresenteerd, past de architectuur continue validatie, gedragsanalyse en beleidsgestuurde toegangscontrole toe die effectief blijven, zelfs als een inloggegeven is gecompromitteerd.
Identity & Access Management op applicatieniveau – niet alleen aan de netwerkperimeter – bepaalt of een gecompromitteerde inlog leidt tot een datalek of tot een geblokkeerde, gelogde poging. Het verschil tussen een organisatie die een credential stuffing-aanval binnen enkele uren detecteert en een organisatie die het pas maanden later ontdekt, is de diepgang en consistentie van toegangscontroles en monitoring over de control plane voor veilige gegevensuitwisseling. Real-time zichtbaarheid via een CISO-dashboard dat afwijkende toegangspatronen over alle contentkanalen toont, maakt van audit logging een operationeel detectiemiddel in plaats van alleen een forensisch hulpmiddel.
Een verdediging bouwen op de control plane
De regelgevende gevolgen van accountovername op basis van inloggegevens – vooral in zorg, defensie en financiële sector – creëren een specifieke architecturale vereiste: controles moeten worden toegepast op het niveau waar gevoelige data daadwerkelijk beweegt, niet alleen aan de netwerkperimeter of bij de identity provider.
Perimetercontroles zijn waardevol, maar onvoldoende voor dit dreigingsmodel. Een gecompromitteerd inloggegeven authenticatieert per definitie via de perimetercontroles. De aanvaller presenteert een geldig token vanaf een IP-adres dat overeenkomt met de locatie van de gebruiker, op een tijdstip dat past bij normaal gebruik. Detectie op basis van de perimeter kan een gecompromitteerde sessie niet betrouwbaar onderscheiden van een legitieme zonder extra context.
Wat zero-trust architectuur biedt, is precies die extra context. Door op attributen gebaseerde toegangscontrole (ABAC) toe te passen via de control plane, dwingt de architectuur fijnmazige beleidsregels af op basis van datagevoeligheid, gebruikersrol, apparaatcompliancestatus en gedragscontext – niet alleen op het presenteren van een geldig token. Een gebruiker van wie het inloggegeven is gecompromitteerd kan succesvol authenticeren, maar als zijn gedrag vervolgens afwijkt van het normale patroon of als hij data probeert te benaderen buiten zijn rol, voorkomt het ABAC-beleid toegang en genereert het een alert.
Continue audit logging is het bewijscomponent dat deze architectuur compliance-verdedigbaar maakt. Wanneer een toezichthouder of eiser vraagt “wat heeft het gecompromitteerde account wanneer benaderd?”, moet het antwoord een specifiek, tijdgestempeld, onveranderlijk record zijn – geen algemene verklaring dat toegangscontroles aanwezig waren. Organisaties die dat record niet kunnen overleggen, lopen hetzelfde bewijsprobleem waar toezichthouders steeds vaker op wijzen in handhavingszaken – zoals de FTC-actie tegen Illuminate Education: bewustzijn van risico zonder verifieerbare controles is op zichzelf een compliance-fout.
DLP binnen de control plane biedt een laatste containmentlaag: beleidsregels die uitgaande data op gereguleerde typen controleren – PHI, CUI, PII, financiële administratie – en blokkeren, in quarantaine plaatsen of waarschuwen bij verzending buiten goedgekeurde kanalen. Zelfs in een scenario waarin een gecompromitteerd account gevoelige data succesvol benadert, kunnen DLP-beleidsregels exfiltratie voorkomen. Dataminimalisatie op control plane-niveau verkleint de impact verder door accounts alleen toegang te geven tot de data die ze nodig hebben voor hun specifieke rol – niet tot alles waarvoor hun rechten technisch gezien toegang bieden.
Kiteworks fungeert als de control plane voor veilige gegevensuitwisseling – met ABAC-handhaving, end-to-end encryptie, onveranderlijke audit logging en DLP als één governance-laag over elk kanaal waarlangs gevoelige data beweegt: e-mail, bestandsoverdracht, SFTP, MFT, API’s en AI-integraties. Dit is de architectuur waarmee gereguleerde organisaties de vraag kunnen beantwoorden: “Als een inloggegeven wordt gecompromitteerd en een aanvaller succesvol authenticatie uitvoert, waar kunnen ze daadwerkelijk bij, welke controles voorkomen exfiltratie en welk record bestaat er van wat er is gebeurd?”
Wat compliance-teams nu moeten doen
De verzameling van 24 miljard records is een nuttige aanleiding voor een gesprek dat compliance-, juridische en beveiligingsteams sowieso zouden moeten voeren, los van een enkele onthulling.
Ten eerste moet monitoring van blootstelling van inloggegevens worden behandeld als een doorlopende risicobeoordelingsfunctie, niet als een reactieve respons op onthullingen. Commerciële meldingsdiensten voor datalekken kunnen vrijwel real-time waarschuwen wanneer inloggegevens van medewerkers opduiken in bekende verzamelingen. Die informatie moet direct leiden tot wachtwoordrotatie en accountcontrole – niet wachten tot de volgende geplande rotatiecyclus.
Ten tweede moet handhaving van MFA worden geverifieerd voor elke applicatie die toegang heeft tot gereguleerde data, niet alleen bij de primaire identity provider. Veel organisaties hebben sterke MFA aan de netwerkgrens, maar hebben het niet consequent afgedwongen over alle applicaties die medewerkers gebruiken. Portals voor bestandsoverdracht, e-mailplatforms en samenwerkingsomgevingen voor documenten zijn veelvoorkomende gaten.
Ten derde moeten HIPAA-naleving-, CMMC 2.0- en FedRAMP-programma’s expliciete dekking van het credential stuffing-risico opnemen in hun risicobeoordelingen. De standaardvraag bij risicobeoordeling – “wat zijn de bedreigingen voor onze gereguleerde data?” – moet een specifieke analyse bevatten van wat er gebeurt als inloggegevens van medewerkers worden gecompromitteerd, tot welke data die gegevens toegang geven en of de toegangscontroles en audit logging voldoende zijn om het incident te detecteren en in te dammen.
Tot slot moet de logging- en monitoringinfrastructuur in gereguleerde omgevingen worden herzien op de specifieke dreiging van geauthenticeerde maar kwaadaardige sessies. Dit is iets anders dan monitoring op mislukte inlogpogingen. Het vereist gedragsanalyse van geauthenticeerde sessies om toegangspatronen te detecteren die niet overeenkomen met normaal gebruikersgedrag – een mogelijkheid die zich binnen de control plane voor veilige gegevensuitwisseling bevindt, niet aan de netwerkperimeter. Organisaties moeten er ook voor zorgen dat hun incident response-plan expliciet scenario’s van accountovername op basis van inloggegevens dekt, met gedocumenteerde runbooks voor de meldingsplichten per relevant regelgevend kader.
De verzameling van 24 miljard records zal binnen enkele maanden worden overtroffen door een nog grotere. Het infostealer-ecosysteem dat de gevaarlijkste records aan deze collecties toevoegt, vertraagt niet. De juiste reactie is niet paniek om een enkele onthulling – het is het bouwen van een architectuur die credential compromise tot een beheersbaar incident maakt in plaats van een datalek.
Meer weten over hoe Kiteworks het risico van accountovername op basis van inloggegevens in gereguleerde omgevingen aanpakt? Plan vandaag nog een demo op maat.
Veelgestelde vragen
Een credential “collectie” is een samengestelde dataset van gebruikersnaam-wachtwoordcombinaties, verzameld uit diverse historische datalekken – meestal incidenten die maanden of jaren geleden plaatsvonden. De inloggegevens in een collectie kunnen al zijn geroteerd of de systemen waarop ze toegang gaven zijn uitgefaseerd. Infostealerlogs zijn kwalitatief anders: ze zijn het resultaat van malware die actief draait op geïnfecteerde apparaten en in real time inloggegevens vastlegt terwijl ze worden gebruikt. Infostealerlogs bevatten vers buitgemaakte inloggegevens die waarschijnlijk nog geldig zijn. Voor beveiligingsteams die datalekverzamelingen beoordelen, vertegenwoordigt het collectie-deel historische blootstelling, terwijl het infostealer-deel een actief operationeel risico vormt. Zero-trust beveiligingsprincipes zijn specifiek ontworpen voor omgevingen waarin credential-geldigheid niet kan worden aangenomen, en bieden continue validatie die niet alleen op het inloggegeven vertrouwt. Organisaties moeten infostealer-specifieke scenario’s opnemen in hun beheer van beveiligingsrisico’s om detectie- en responsmogelijkheden af te stemmen op de snelheid van deze dreiging.
Credential stuffing is een geautomatiseerde aanvalstechniek waarbij gebruikersnaam-wachtwoordcombinaties uit datalekverzamelingen worden getest op doelwebapplicaties. Moderne credential stuffing-tools wisselen tussen verspreide IP-adressen en variëren hun aanvraagpatronen om rate limiting of IP-blokkades te omzeilen, waardoor detectie op basis van hoeveelheid onbetrouwbaar wordt. De aanval slaagt als een gestolen combinatie nog geldig is op de doelapplicatie – meestal omdat de gebruiker wachtwoorden hergebruikt op meerdere diensten of het wachtwoord sinds het oorspronkelijke datalek niet heeft gewijzigd. Detectie vereist gedragsanalyse van geauthenticeerde sessies, niet alleen monitoring op mislukte inlogpogingen. Logs die elk toegangsmoment met apparaat-, locatie- en gedragscontext vastleggen, zijn essentieel om gecompromitteerde sessies achteraf te identificeren. Door deze logs in een SIEM met gedragsanalyse te verwerken, krijgen beveiligingsteams de real-time alerts die nodig zijn om in te grijpen voordat een credential stuffing-sessie leidt tot data-exfiltratie.
Multi-factor authentication verhoogt de drempel voor credential stuffing-aanvallen aanzienlijk en blokkeert het merendeel van de pogingen die vertrouwen op statische gebruikersnaam-wachtwoordcombinaties. MFA is echter geen absolute verdediging. Moderne infostealers verzamelen browsersessiecookies die zijn uitgegeven na een legitieme MFA-gebeurtenis – waardoor sessie hijacking mogelijk is die de MFA-eis volledig omzeilt. Daarnaast kunnen sommige MFA-implementaties worden omzeild via SIM-swapping, real-time phishing-frameworks of social engineering. MFA-handhaving is een essentiële controle, maar moet worden gezien als één laag binnen een defense-in-depth-architectuur, niet als complete oplossing. ABAC-controles op control plane-niveau blijven effectief, zelfs als authenticatie is gecompromitteerd, door beleidsmatige beperkingen op te leggen aan wat een gecompromitteerde sessie kan bereiken. Door MFA te combineren met gegevensbeheerbeleid dat beperkt welke data een bepaalde rol kan benaderen, wordt de schade van een omzeilde MFA-gebeurtenis beperkt.
De verplichtingen hangen af van welke gereguleerde data het gecompromitteerde account heeft benaderd. Onder HIPAA-naleving geldt dat ongeautoriseerde toegang tot beschermde gezondheidsinformatie (PHI) door een onbevoegde persoon wordt beschouwd als een vermoedelijk datalek, waarvoor melding aan betrokkenen en het Department of Health and Human Services verplicht is, tenzij de organisatie een lage kans op schade kan aantonen via een vierfactoren-risicobeoordeling. Onder CMMC 2.0-naleving activeert ongeautoriseerde toegang tot CUI een 72-uurs incidentmelding aan het DoD onder DFARS 252.204-7012. Onder FedRAMP activeert ongeautoriseerde toegang tot federale data een incidentmelding aan de relevante instantie en CISA. HIPAA-naleving en CMMC 2.0-programma’s moeten accountovername op basis van inloggegevens expliciet adresseren in hun incident response-plannen. Organisaties die onder de GDPR vallen, hebben een vergelijkbare 72-uurs meldingsplicht aan de relevante toezichthouder als het om persoonsgegevens gaat.
De reactie moet worden afgestemd op het risicoprofiel van de blootgestelde inloggegevens. Medewerkers met toegang tot gereguleerde data – PHI, CUI, PII, financiële administratie – moeten met voorrang hun inloggegevens wijzigen en accounts laten controleren zodra meldingsdiensten voor datalekken hun gegevens signaleren. De volgende prioriteit is het afdwingen van MFA over elke applicatie die deze medewerkers gebruiken om gereguleerde content te benaderen, niet alleen bij de primaire identity provider. Op middellange termijn moet worden geverifieerd dat toegangscontroles en monitoring op contentniveau – niet alleen aan de netwerkperimeter – voldoende zijn om gecompromitteerde sessies te detecteren en in te dammen voordat ze leiden tot data-exfiltratie. Voor organisaties die onder HIPAA of CMMC vallen, moet deze verificatie worden gedocumenteerd als onderdeel van het doorlopende risicobeoordelingsproces dat deze kaders vereisen. Een beoordeling van risicobeheer door derden van leveranciers met toegang tot gereguleerde dataomgevingen moet parallel lopen, aangezien infostealer-infecties op endpoints van leveranciers dezelfde blootstelling van inloggegevens veroorzaken als infecties op interne endpoints.
Aanvullende bronnen
- Blog Post Zero Trust Architectuur: Never Trust, Always Verify
- Video Microsoft GCC High: Nadelen die defensie-aannemers richting slimmere voordelen drijven
- Blog Post Hoe u geclassificeerde data beveiligt zodra DSPM deze signaleert
- Blog Post Vertrouwen opbouwen in Generatieve AI met een Zero Trust-aanpak
- Video De definitieve gids voor het veilig opslaan van gevoelige data voor IT-leiders