81 miljoen Azure CLI-wachtwoordspraypogingen. De aanvallers probeerden multi-factor authenticatie niet te kraken, maar te omzeilen.
Eenentachtig miljoen pogingen tot password spraying. Achtenzeventig gecompromitteerde accounts. Negenendertig getroffen organisaties. Dat zijn de cijfers die Huntress op 1 juli 2026 publiceerde over een actieve campagne gericht op Microsoft Azure-omgevingen – maar het belangrijkste getal is geen van deze. Het belangrijkste getal is nul: het aantal MFA-prompts dat de aanvallers hebben geactiveerd.
Dit was geen campagne die draaide om het kraken van MFA. Het draaide erom deze volledig te omzeilen. De techniek is niet nieuw – beveiligingsonderzoekers hebben eerder ROPC-gebaseerde authenticatie-aanvallen gedocumenteerd – maar de schaal van deze campagne en de specifieke targeting van de Azure CLI maken het tot het duidelijkste recente voorbeeld van wat er gebeurt wanneer legacy authenticatiestromen naast moderne identiteitscontroles in dezelfde bedrijfsomgeving bestaan.
Het onderzoek van Huntress documenteert hoe aanvallers de Resource Owner Password Credentials OAuth 2.0-flow gebruikten om direct te authenticeren bij Azure AD zonder dat er Conditional Access Policies of MFA-vereisten werden geactiveerd. Begrijpen waarom dit werkt, vereist inzicht in wat ROPC is, hoe het verschilt van moderne authenticatiestromen en waarom het nog steeds toegankelijk is in de meeste Azure-tenants, ondanks het feit dat Microsoft het protocol heeft uitgefaseerd.
Belangrijkste inzichten
1. Huntress documenteerde 81 miljoen Azure CLI password spray-pogingen, waarbij 78 accounts werden gecompromitteerd bij 39 organisaties.
De campagne was gericht op een legacy OAuth 2.0-flow genaamd Resource Owner Password Credentials (ROPC), die inloggegevens direct naar Azure AD stuurt en moderne MFA- en Conditional Access Policy-handhaving volledig omzeilt.
2. ROPC is uitgefaseerd door Microsoft, maar blijft breed inzetbaar.
De OAuth 2.0 ROPC-flow is ontworpen voor legacy-systemen die gebruikers niet kunnen omleiden naar een browser voor authenticatie. Microsoft heeft deze uitgefaseerd ten gunste van moderne flows, maar omdat het technisch nog steeds werkt in de meeste Azure-tenants, kunnen aanvallers deze gebruiken om te authenticeren zonder MFA of Conditional Access Policy-controles te activeren.
3. Conditional Access Policy-misconfiguratie is de belangrijkste oorzaak.
Zelfs organisaties die Conditional Access Policies hebben ingezet, hebben vaak dekkingsgaten – specifieke applicaties, gebruikersgroepen of locatiegebaseerde voorwaarden waardoor ROPC-verkeer onbeschermd blijft. De Azure CLI vormt vaak een uitzondering, waardoor ontwikkelaars met ROPC geauthenticeerde inloggegevens toegang kunnen krijgen tot productiebronnen.
4. Het aanvalspatroon maakt misbruik van het authenticatiegat tussen beleidsintentie en technische handhaving.
Organisaties denken dat MFA hun Azure-omgeving beschermt omdat het browsergebaseerde authenticatie beschermt. ROPC-authenticatie verloopt echter via een andere stroom. Dit is geen kwetsbaarheid in MFA zelf – het is een misconfiguratie die een legacy authenticatiepad openlaat naast het moderne pad.
5. De oplossing vereist meer dan alleen goed wachtwoordgebruik.
Het blokkeren van het ROPC-aanvalspad vereist een combinatie van: het blokkeren van legacy authenticatieprotocollen op tenantniveau, het auditen van Conditional Access Policy-dekking op gaten, het roteren van inloggegevens van accounts met Azure CLI-toegang, en het implementeren van Identity and Access Management-controles die ROPC-authenticatiegebeurtenissen als afwijkend markeren.
Je vertrouwt erop dat je organisatie veilig is. Maar kun je het verifiëren?
Lees nu
Wat is ROPC en waarom bestaat het nog?
Het OAuth 2.0-framework biedt diverse authenticatiestromen voor verschillende toepassingen. De moderne standaard voor interactieve gebruikersauthenticatie is de Authorization Code-flow met PKCE – deze stuurt gebruikers naar een identiteitsprovider, verzamelt daar de inloggegevens en retourneert een autorisatiecode naar de applicatie. Deze flow is compatibel met MFA en Conditional Access Policies omdat de authenticatie plaatsvindt bij de identiteitsprovider waar deze controles actief zijn.
ROPC is ontworpen als alternatief voor legacy-applicaties die geen browsergebaseerde omleidingen kunnen uitvoeren. In plaats van gebruikers naar een inlogpagina te sturen, accepteert ROPC inloggegevens direct vanuit de applicatie en stuurt deze als een POST-verzoek naar de identiteitsprovider. De applicatie zelf regelt de uitwisseling van inloggegevens.
Microsoft heeft ROPC uitgefaseerd omdat het architectonisch niet compatibel is met moderne beveiligingscontroles. Inloggegevens lopen via de applicatie in plaats van via de authenticatie-UI van de identiteitsprovider, waardoor MFA-prompts niet in de flow kunnen worden geïnjecteerd. Conditional Access Policies die worden geactiveerd bij aanmeldgebeurtenissen, worden niet uitgevoerd. Tokenuitgifte vindt plaats zonder dat de volledige evaluatie van conditional access bij de identiteitsprovider is afgerond.
Het probleem is dat uitfasering niet betekent dat het is uitgeschakeld. ROPC werkt nog steeds in de meeste Azure-tenants. Microsoft stuurt klanten richting moderne authenticatiestromen, maar ROPC blijft operationeel voor achterwaartse compatibiliteit met legacy-systemen. In de door Huntress gedocumenteerde campagne gebruikten aanvallers ROPC om te authenticeren tegen Azure CLI – een veelgebruikt ontwikkelaarstool met toegang tot Azure-bronnen – omdat Azure CLI ROPC-authenticatie ondersteunt en de meeste organisaties deze niet expliciet hebben geblokkeerd. Een formele risicobeoordeling van authenticatieprotocol-dekking – specifiek in kaart brengen welke legacy-flows nog zijn ingeschakeld binnen welke applicatie-scopes – is het startpunt om dit soort gaten te dichten voordat het tot een datalek leidt.
Hoe werkt de aanval in de praktijk?
De door Huntress gedocumenteerde campagne volgt een herkenbaar patroon: valideren van gebruikersnamen, uitvoeren van credential stuffing of spraying op ROPC-toegankelijke eindpunten, tokens verzamelen van geslaagde authenticaties, deze tokens gebruiken om toegang te krijgen tot Azure-bronnen.
Het Azure CLI-gedeelte is belangrijk vanwege de toegang die CLI doorgaans biedt. Ontwikkelaarsaccounts met Azure CLI-toegang hebben vaak rechten op productieomgevingen, resourcegroepen, opslagaccounts en computerbronnen. De CLI is een beheertool – bedoeld voor brede toegang. Wanneer aanvallers een CLI-inloggegeven via ROPC compromitteren, krijgen ze niet alleen toegang tot e-mail. Ze krijgen mogelijk toegang tot de volledige infrastructuur.
Brute force-aanvallen op traditionele authenticatie-eindpunten zijn luidruchtig. Ze genereren mislukte aanmeldingen die door SIEM-platforms en identity protection-systemen worden gedetecteerd en gemeld. ROPC-gebaseerde password sprays kunnen stiller zijn: ze genereren niet dezelfde browser-sessie authenticatiegebeurtenissen, en veel organisaties loggen ROPC-tokenuitgifte niet met dezelfde nauwkeurigheid als interactieve aanmeldingen.
Het cijfer van 81 miljoen pogingen weerspiegelt de rekencapaciteit die nodig is voor credential spraying op grote schaal – het is een groot aantal, maar de 78 geslaagde compromitteringen (0,000096% succesratio) laten ook zien hoe inloggegevens over veel pogingen worden verspreid voordat er een match is. Het echte dreigingsmodel is niet het ruwe aantal pogingen. Het is dat elke geslaagde ROPC-authenticatie een bearer token oplevert dat toegang geeft tot alles wat het gecompromitteerde account kan bereiken. Eén gecompromitteerd ontwikkelaarsaccount met toegang tot productieopslag, computerbronnen en CI/CD-pijplijnen betekent een datalek én een incident op infrastructuurniveau – de combinatie van intellectueel eigendom in coderepositories en gereguleerde data in cloudopslag betekent dat de meldings- en herstelverplichtingen aanzienlijk kunnen zijn.
Phishing en wachtwoordhergebruik zijn de meest voorkomende bronnen van de in deze spraycampagnes gebruikte inloggegevens. Zodra inloggegevens in breach-databases verschijnen – en dat gebeurt uiteindelijk bijna altijd – worden ze input voor geautomatiseerde spraytools. ROPC-authenticatie op schaal is grotendeels een functie van: (a) hoeveel geldige inloggegevens aanvallers uit eerdere datalekken hebben verkregen, en (b) hoeveel tenant-eindpunten via ROPC toegankelijk zijn zonder CAP-handhaving.
Het Conditional Access Policy-dekkingsprobleem
Conditional Access Policies zijn de primaire defense-in-depth-controle voor Azure AD-omgevingen. Ze stellen organisaties in staat voorwaarden te definiëren waaronder authenticatie slaagt – MFA vereisen, risicovolle aanmeldlocaties blokkeren, toegang beperken tot conforme apparaten. Bij correcte configuratie maken CAP’s password sprays grotendeels ineffectief, omdat zelfs een geldig inloggegeven niet succesvol kan authenticeren zonder aan de beleidsvoorwaarden te voldoen.
Het dekkingsprobleem bij ROPC-aanvallen is niet dat CAP’s niet werken. Het is dat de dekking zelden volledig is. Organisaties zetten CAP’s stapsgewijs in, vaak beginnend bij prioritaire applicaties en gebruikersgroepen, en bouwen in de loop van de tijd uitzonderingen op. De Azure CLI is een veelvoorkomende uitzondering: ontwikkelaars hebben CLI-toegang nodig, CLI-tools draaien vaak in geautomatiseerde pijplijnen die geen MFA-onderbrekingen aankunnen, en het resultaat is een CAP-uitzondering die CLI-authenticatie tot een zwak punt maakt.
Verkeerde configuratie beveiliging in de identiteitslaag is consequent een van de meest effectieve aanvalsvectoren. Eén verkeerd geconfigureerde beleidsuitzondering kan inloggegevens blootstellen aan legacy authenticatiepaden die anders robuuste MFA-handhaving omzeilen. De Huntress-campagne is een direct gevolg van die dynamiek: 78 accounts gecompromitteerd, niet omdat MFA zwak is, maar omdat 78 accounts een CAP-uitzondering hadden of binnen een applicatie-scope vielen die ROPC-authenticatie toestond.
De auditvraag die organisaties moeten stellen is niet “hebben we Conditional Access Policies?”, maar “dekken onze Conditional Access Policies alle authenticatiepaden, inclusief legacy-protocoleindpunten, voor alle gebruikersaccounts?” De meeste organisaties hebben dit niet op protocolniveau geaudit. Het uitbreiden van risicobeheer toeleveringsketen-disciplines naar deze vraag is vooral belangrijk voor organisaties die Azure CLI-toegang hebben verleend aan externe ontwikkelaars, contractors of managed service providers – elk extern inloggegeven met CLI-toegang is een ROPC-exposurepunt dat mogelijk buiten de directe CAP-audit van de hoofdorganisatie valt.
Identity Governance voorbij MFA
Het ROPC-aanvalspatroon onderstreept een structureel punt over identiteitsbeveiliging dat MFA alleen niet oplost. MFA is een controle die werkt op interactieve authenticatiestromen. Legacy authenticatieprotocollen zijn ontworpen om buiten interactieve flows te werken. Ze zijn, per ontwerp, niet compatibel met MFA.
De architectonische oplossing vereist ingrijpen op protocolniveau, niet alleen op het niveau van inloggegevens. Legacy authenticatie blokkeren betekent Azure AD zo configureren dat ROPC-tokenverzoeken volledig worden geweigerd – er kan een CAP worden gemaakt die legacy authenticatie voor alle gebruikers of gescope gebruikersgroepen blokkeert. Dit is de belangrijkste aanbevolen maatregel volgens Microsoft en het Huntress-onderzoek.
Rolgebaseerde toegangscontrole en op attributen gebaseerde toegangscontrole-raamwerken die ontwikkelaarsaccounts beperken tot minimale rechten, verkleinen de impact van een ROPC-compromittering. Een ontwikkelaarsaccount dat alleen mag lezen uit specifieke opslagcontainers en mag deployen naar bepaalde resourcegroepen, is minder rampzalig om te compromitteren dan een account met Contributor-rechten op een volledige subscription. Dataminimalisatie toegepast op de scope van inloggegevens – ontwikkelaarsaccounts voorzien van de minimale Azure-rechten die hun huidige taak vereist, periodiek herzien in plaats van jarenlang op te stapelen bij rolwijzigingen – is de operationele praktijk die least-privilege tot een realiteit maakt tijdens gebruik, niet alleen bij provisioning.
Identity and Access Management-programma’s die ontwikkelaarsaccounts als aparte risicocategorie behandelen – met rotatieschema’s, toegangsbeoordelingen en anomaliedetectie voor ROPC-tokenuitgifte – zijn het antwoord op ondernemingsniveau op dit aanvalspatroon. De meeste IAM-programma’s zijn opgezet rond het beheren van door mensen verstrekte inloggegevens in browsergebaseerde workflows. Inloggegevens van ontwikkelaars die worden gebruikt in CLI-tools en automatiseringspijplijnen vallen vaak buiten die workflows.
Zero trust-architectuur toegepast op cloudidentiteit vereist continue verificatie op het niveau van de authenticatiegebeurtenis, niet alleen op applicatietoegangsniveau. Wanneer een token wordt uitgegeven via ROPC, stellen zero trust-principes dat het token moet worden geëvalueerd op risicosignalen – ongebruikelijke herkomst, patronen van wachtwoordhergebruik, toegangssnelheid – voordat bronnen worden vrijgegeven. Die continue evaluatie is wat CAP-gebaseerde controles bieden, en precies daarom is de CAP-bypass van ROPC zo significant.
Het Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report toonde aan dat identity and access management-gaten nog steeds tot de meest voorkomende oorzaken van datalekken in ondernemingen behoren. De door Huntress gedocumenteerde ROPC-campagne is daar een exact voorbeeld van: geen complexe zero-day, maar een legacy-protocolgat dat de meeste organisaties niet specifiek hebben aangepakt in hun identity governance-programma’s. Organisaties die gevoelige content via een Private Data Network met beleidsafgedwongen toegangscontrole en onveranderlijke audit logs op contentniveau routeren, hebben een extra begrenzing: zelfs een gecompromitteerd Azure-inloggegeven met productie-toegang kan geen content bereiken die door de ABAC-beleidsregels van Kiteworks is beperkt tot specifieke geautoriseerde identiteiten.
Directe herstelmaatregelen
Het onderzoek van Huntress biedt concrete adviezen waar organisaties direct mee aan de slag kunnen. De kernmaatregelen zijn:
Blokkeer legacy authenticatie op tenantniveau. Azure AD Conditional Access Policies kunnen legacy authenticatieprotocollen, waaronder ROPC, voor alle gebruikers blokkeren, of gescope op gebruikersgroepen en applicaties. Microsoft biedt hiervoor een beleidssjabloon. Organisaties die deze stap hebben uitgesteld vanwege afhankelijkheden van legacy-applicaties, moeten deze afhankelijkheden in kaart brengen en een migratiepad opstellen.
Audit Conditional Access Policy-dekking. Breng elk gebruikersaccount en elke applicatie in kaart tegen de CAP-beleidsregels die erop van toepassing zijn. Identificeer gaten – applicaties zonder CAP, gebruikersaccounts die zijn uitgesloten van MFA-vereisten, serviceaccounts met CLI-toegang die conditional access omzeilen. Elk gat is een potentieel ROPC-exposurepunt.
Roteer inloggegevens voor accounts met Azure CLI-toegang. In de Huntress-campagne werden 78 accounts succesvol geauthenticeerd via ROPC voordat de campagne werd ontdekt. Organisaties die blootstelling niet kunnen uitsluiten, moeten de inloggegevens van alle ontwikkelaarsaccounts met CLI- of programmatische Azure-toegang roteren.
Schakel aanmeldlogging voor ROPC-gebeurtenissen in. De aanmeldlogs van Azure AD registreren authenticatiegebeurtenissen, inclusief legacy authenticatie. Het configureren van SIEM-alerts voor ROPC-authenticatiegebeurtenissen biedt vroegtijdige waarschuwing voor toekomstige spraypogingen – en legt de audit log-basis vast die nodig is voor incident response.
Implementeer anomaliedetectie op tokenuitgifte. ROPC-tokenverzoeken die afkomstig zijn van onverwachte IP-reeksen, geografische locaties of op ongebruikelijke tijden zijn detecteerbare signalen. Identity protection-tools die authenticatierisico’s scoren, kunnen ROPC-spraypogingen markeren voordat succesvolle authenticaties zich opstapelen. Het CISO-dashboard biedt security-leiders real-time inzicht in contenttoegangspatronen over alle beheerde kanalen – zodat afwijkende activiteit na een credential-compromittering wordt gesignaleerd voordat het escaleert tot een meldingsplichtig incident.
Meer weten over hoe Kiteworks identity governance, toegangscontrole en cloud security misconfiguratie aanpakt in gereguleerde omgevingen? Plan vandaag nog een demo op maat.
Veelgestelde vragen
De Resource Owner Password Credentials (ROPC)-flow is een legacy OAuth 2.0-authenticatiemechanisme dat gebruikersgegevens direct van een applicatie naar de identiteitsprovider stuurt als een POST-verzoek, waarmee de browsergebaseerde redirect-authenticatie van moderne flows wordt omzeild. Omdat inloggegevens via de applicatie lopen in plaats van via de authenticatie-UI van de identiteitsprovider, kunnen MFA-prompts niet in de flow worden geïnjecteerd en worden Conditional Access Policy-aanmeldbeoordelingen niet uitgevoerd. Microsoft heeft ROPC uitgefaseerd vanwege deze beveiligingsbeperkingen, maar het protocol blijft werken in de meeste Azure-tenants voor achterwaartse compatibiliteit met legacy-applicaties. Huntress documenteerde aanvallers die deze flow gebruikten om in 2026 81 miljoen password spray-pogingen uit te voeren op Azure CLI-eindpunten, waarbij 78 accounts succesvol werden gecompromitteerd zonder dat er één MFA-prompt werd geactiveerd. De verkeerde configuratie beveiliging zit niet in MFA zelf, maar in het blijvend beschikbaar zijn van een authenticatiepad dat deze omzeilt. Organisaties die onderworpen zijn aan nalevingsverplichtingen – HIPAA, CMMC, GDPR, FINRA – moeten ROPC-beschikbaarheid in hun Azure-tenant als een compliance-gat behandelen, omdat ongemonitorde legacy authenticatiepaden de toegangscontroledocumentatie ondermijnen die deze kaders vereisen.
Een Azure CLI password spray-aanval met ROPC verloopt als volgt. Aanvallers verkrijgen of stellen een lijst samen met geldige Azure AD-gebruikersgegevens – meestal uit eerdere breach-databases, phishingcampagnes of resultaten van credential stuffing. Vervolgens dienen ze deze inloggegevens in bij het ROPC-token-eindpunt van Azure AD via Azure CLI-authenticatieverzoeken. Wanneer de gegevens geldig zijn en er geen Conditional Access Policy is die de ROPC-flow voor dat account blokkeert, geeft Azure AD een toegangstoken uit zonder MFA te activeren. De aanvaller gebruikt dat token vervolgens om Azure CLI-commando’s uit te voeren op de Azure-bronnen van het slachtoffer. De aanval is detecteerbaar via SIEM-monitoring van legacy authenticatie-aanmeldingen in Azure AD logs, maar alleen als logging is ingeschakeld en alerts zijn geconfigureerd. Zero trust-architectuur-principes die continue verificatie op tokenuitgifteniveau vereisen – inclusief risicoscores voor legacy authenticatieverzoeken – bieden detectiedekking die MFA alleen niet biedt. Een gedocumenteerd incident response-plan dat expliciet ROPC-compromitteringsscenario’s dekt – inclusief de stappen voor het beoordelen van Azure-activiteitslogs en het roteren van inloggegevens – geeft securityteams een duidelijk pad van detectie naar beheersing.
Een Conditional Access Policy (CAP) in Azure AD definieert voorwaarden waaronder authenticatie slaagt – bijvoorbeeld MFA vereisen vanaf specifieke locaties, risicovolle aanmeldingen blokkeren of toegang beperken tot conforme apparaten. Bij correcte configuratie en scope maken CAP’s password spray-aanvallen grotendeels ineffectief, omdat zelfs geldige inloggegevens niet kunnen authenticeren zonder aan de beleidsvoorwaarden te voldoen. De ROPC-aanval omzeilt CAP’s omdat CAP-handhaving wordt uitgevoerd bij interactieve aanmeldingen; ROPC-tokenverzoeken activeren niet dezelfde aanmeldflow. Daarnaast hebben veel organisaties CAP-uitzonderingen voor ontwikkelaarstools, automatiseringspijplijnen en legacy-applicaties die ROPC-compatibele authenticatie nodig hebben. Deze uitzonderingen creëren de dekkingsgaten die de door Huntress gedocumenteerde campagne heeft uitgebuit. Identity and Access Management-audits die specifiek de dekking van authenticatieprotocollen in kaart brengen – niet alleen applicatiedekking – zijn nodig om deze gaten te identificeren. Toegangscontrole op contentniveau – niet alleen op identiteitsniveau – biedt een tweede handhavingsgrens die effectief blijft, zelfs wanneer een authenticatiegat tokenuitgifte mogelijk maakt.
MFA vereisen in Azure AD betekent dat interactieve authenticatiestromen een MFA-uitdaging activeren voordat tokens worden uitgegeven. Legacy authenticatie blokkeren betekent dat Azure AD tokenverzoeken die legacy authenticatieprotocollen (waaronder ROPC) gebruiken volledig afwijst, ongeacht de geldigheid van de inloggegevens. Dit zijn twee afzonderlijke controles met verschillende effecten. Alleen MFA beschermt niet tegen ROPC-aanvallen omdat ROPC de interactieve authenticatiestroom waar MFA wordt geactiveerd omzeilt. Legacy authenticatie blokkeren stopt ROPC-tokenverzoeken vóór de evaluatie van inloggegevens en voorkomt de aanval op protocolniveau. Microsoft raadt aan legacy authenticatie te blokkeren als basisbeveiligingsconfiguratie, en Azure AD biedt hiervoor een benoemd CAP-sjabloon. Organisaties moeten beide controles implementeren: MFA vereisen voor alle interactieve authenticatie en legacy authenticatieprotocollen blokkeren voor alle gebruikersaccounts en applicaties die zijn gemigreerd naar moderne authenticatiestromen. Rolgebaseerde toegangscontrole die ontwikkelaarsaccounts beperkt tot minimale rechten, beperkt de schade van elk legacy authenticatiegat dat overblijft. Programma’s voor risicobeheer door derden moeten verifiëren dat managed service providers en contractors die in de Azure-omgeving werken, hebben bevestigd dat zij legacy authenticatie in hun eigen beheertools hebben geblokkeerd – een MSP-account met ROPC-toegankelijke CLI-inloggegevens veroorzaakt dezelfde blootstelling als een intern ontwikkelaarsaccount.
Organisaties die vermoeden dat ze doelwit zijn geweest van een Azure CLI ROPC password spray, moeten vijf directe acties ondernemen. Ten eerste: haal Azure AD-aanmeldlogs op en filter op legacy authenticatiegebeurtenissen van de afgelopen 90 dagen – ROPC-tokenverzoeken verschijnen als legacy authenticatie-aanmeldingen. Ten tweede: identificeer accounts die succesvol zijn geauthenticeerd via legacy authenticatie en bekijk hun Azure-activiteitslogs op ongeautoriseerde toegang tot bronnen. Ten derde: roteer de inloggegevens van alle accounts met Azure CLI-toegang, ongeacht of ROPC-authenticatie is bevestigd. Ten vierde: implementeer een Conditional Access Policy die legacy authenticatie voor alle gebruikersaccounts blokkeert, of minimaal voor alle accounts met Azure CLI- of programmatische API-toegang. Ten vijfde: beoordeel en sluit alle CAP-uitzonderingen voor ontwikkelaarstools en automatiseringsserviceaccounts. Het opzetten van een volledige audit log-basis en het configureren van SIEM-alerts voor toekomstige ROPC-authenticatiegebeurtenissen moeten hierop volgen. Het incident response-proces moet bevindingen documenteren voor eventuele regulatory compliance-meldingsverplichtingen die van toepassing zijn. Organisaties die gereguleerde data beheren – PHI, CUI, PII – moeten daarnaast beoordelen of opslagaccounts of dataopslagplaatsen die toegankelijk zijn voor de gecompromitteerde Azure-inloggegevens content bevatten waarvoor een datalekmelding vereist is onder de geldende kaders.
Aanvullende bronnen
- Blog Post
Hoe ontwerp je een veilige bestandsoverdracht-workflow voor externe leveranciers en contractors - Blog Post
Het belang van Vendor Risk Management voor CISO’s - Blog Post
Hoe bescherm je intellectueel eigendom bij samenwerking met externe partijen - Blog Post
Bestrijd bedreigingen met supply chain security & risicobeheer - Blog Post
Partner-datalekken: Je bent slechts zo sterk als je zwakste partner