Azure: Gebruikersrisicobeleid Configureren Via Identiteitsbescherming

Accounts worden gecompromitteerd via verschillende aanvalsvectoren waaronder dumps van inloggegevens waarbij grote hoeveelheden inloggegevens worden gelekt bij datalekken, phishing-aanvallen waarbij gebruikers worden misleid om hun inloggegevens in te voeren op valse websites, keylogger-malware die toetsaanslagen vastleggen, en het hergebruik van wachtwoorden over meerdere websites. Microsoft heeft toegang tot miljarden gelekte inloggegevens die worden verzameld van ondergrondse forums en het donkere web. Identiteitsbescherming correleert gebruikers in uw tenant met bekende gelekte inloggegevens en markeert gecompromitteerde accounts automatisch. De gebruikersrisicodetectie identificeert ook afwijkend gedrag zoals ongebruikelijke PowerShell-activiteit, malware-gerelateerde activiteit en verdachte authenticatiepatronen. Zonder gebruikersrisicobeleid blijven gecompromitteerde accounts onbeperkt actief totdat handmatige detectie plaatsvindt, wat aanvallers voldoende tijd geeft voor gegevenslekken en laterale beweging binnen de omgeving.

Implementatie

Deze controle configureert het gebruikersrisicobeleid waarbij gebruikers met een hoog risiconiveau worden gedwongen om hun wachtwoord veilig te wijzigen via MFA-verificatie voordat zij toegang krijgen. Azure AD Identiteitsbescherming berekent de gebruikersrisicoscore op basis van gedetecteerde gelekte inloggegevens, malware-infecties en afwijkende activiteiten. Gebruikers met een hoog risico worden automatisch gedwongen om hun wachtwoord te wijzigen voordat zij toegang krijgen tot hun account. Voor extreem hoge risiconiveaus kan ook worden gekozen voor blokkering in plaats van wachtwoordwijziging. Het beleid draait continu en biedt geautomatiseerde respons op beveiligingsincidenten zonder handmatige interventie.

Vereisten

Voor de implementatie van het gebruikersrisicobeleid in Azure AD Identiteitsbescherming zijn verschillende technische en organisatorische vereisten van essentieel belang. Deze vereisten zorgen ervoor dat het beleid effectief kan functioneren en dat gebruikers op een veilige en gebruiksvriendelijke manier kunnen reageren op risicodetecties. De primaire technische vereiste is een Azure AD Premium P2 licentie voor alle gebruikers die onder het gebruikersrisicobeleid vallen. Deze licentie is absoluut noodzakelijk omdat Identiteitsbescherming en de geavanceerde risicodetectie functionaliteiten exclusief beschikbaar zijn binnen de Premium P2 licentie. Zonder deze licentie kunnen gebruikersrisicobeleidsregels niet worden geconfigureerd of toegepast. Organisaties moeten daarom eerst een licentie-inventarisatie uitvoeren om te bepalen welke gebruikers Premium P2 licenties hebben en welke gebruikers mogelijk aanvullende licenties nodig hebben. Een tweede kritieke vereiste is dat alle gebruikers geregistreerd moeten zijn voor meervoudige authenticatie. Deze registratie is essentieel omdat het gebruikersrisicobeleid gebruikers verplicht om hun wachtwoord veilig te wijzigen via meervoudige authenticatie wanneer zij als hoog risico worden geïdentificeerd. Zonder meervoudige authenticatie-registratie kunnen gebruikers niet voldoen aan de vereiste voor wachtwoordwijziging en blijven zij geblokkeerd. Organisaties moeten daarom een registratiecampagne voor meervoudige authenticatie uitvoeren voordat het gebruikersrisicobeleid wordt geactiveerd, waarbij alle gebruikers worden begeleid bij het registreren van hun authenticatiemethoden zoals de Microsoft Authenticator-app, SMS of telefonische verificatie. Daarnaast moet zelfservice wachtwoordherstel zijn ingeschakeld voor de tenant. Zelfservice wachtwoordherstel stelt gebruikers in staat om hun eigen wachtwoord te wijzigen zonder tussenkomst van de IT-afdeling, wat cruciaal is wanneer het gebruikersrisicobeleid een wachtwoordwijziging afdwingt. Zonder zelfservice wachtwoordherstel zouden gebruikers die als hoog risico worden geïdentificeerd contact moeten opnemen met de helpdesk voor wachtwoordwijziging, wat de responssnelheid vertraagt en de beveiligingsdoelstellingen ondermijnt. Zelfservice wachtwoordherstel moet worden geconfigureerd met geschikte verificatiemethoden die overeenkomen met de meervoudige authenticatie-registratie van gebruikers. Organisatorisch is het van groot belang dat gebruikers proactief worden geïnformeerd over het gebruikersrisicobeleid en wat zij kunnen verwachten wanneer zij als hoog risico worden geïdentificeerd. Gebruikerscommunicatie moet duidelijke instructies bevatten over het proces van wachtwoordwijziging, welke verificatiemethoden zij kunnen gebruiken, en waar zij hulp kunnen krijgen als zij problemen ondervinden. Deze communicatie moet plaatsvinden voordat het beleid wordt geactiveerd, zodat gebruikers voorbereid zijn en niet verrast worden door onverwachte toegangsbeperkingen. Daarnaast moeten gebruikers worden geïnformeerd over de redenen waarom het beleid bestaat en hoe het hen beschermt tegen accountovername. Ten slotte moet er een incidentresponsproces worden opgezet voor het afhandelen van gebruikers met een hoog risico. Dit proces moet duidelijke stappen bevatten voor het onderzoeken van risicodetecties, het bepalen of een account daadwerkelijk is gecompromitteerd, en het nemen van passende maatregelen zoals geforceerde wachtwoordwijziging, accountblokkering of aanvullende verificatie. Beveiligingsanalisten moeten worden getraind in het gebruik van het Identiteitsbescherming overzicht en het interpreteren van verschillende risicodetectietypen zoals gelekte inloggegevens, malware-infecties en afwijkend gedrag.

Implementatie

Gebruik PowerShell-script user-risk-policy-azure.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van het gebruikersrisicobeleid vormt een kritieke stap in het versterken van de beveiligingspostuur van een organisatie. Het proces begint met toegang tot de Azure AD-beheerportal, waar beheerders navigeren naar de sectie Beveiliging en vervolgens naar Identiteitsbescherming. Binnen Identiteitsbescherming bevindt zich de configuratieoptie voor het gebruikersrisicobeleid, waar alle instellingen kunnen worden aangepast om te voldoen aan de specifieke beveiligingsvereisten van de organisatie. Bij het configureren van het beleid moet eerst worden bepaald welke gebruikers onder het beleid vallen. De aanbeveling is om het beleid toe te passen op alle gebruikers in de tenant, zodat geen enkele gebruiker wordt uitgesloten van risicodetectie en automatische respons. Deze aanpak zorgt voor consistente beveiliging door de gehele organisatie heen en voorkomt dat bepaalde gebruikersgroepen kwetsbaar blijven voor accountovername. Door universele toepassing van het beleid wordt een gelijkwaardig beveiligingsniveau gegarandeerd voor alle gebruikers, ongeacht hun rol of functie binnen de organisatie. Dit is met name belangrijk omdat aanvallers vaak zoeken naar zwakke schakels in de beveiligingsketen, en het uitsluiten van gebruikersgroepen zou dergelijke zwakke punten kunnen creëren. Het risiconiveau dat moet worden geselecteerd is Hoog, wat betekent dat alleen gebruikers met een hoog berekend risico worden getroffen door het beleid. Azure AD Identiteitsbescherming berekent continu risicoscores voor alle gebruikers op basis van verschillende signalen zoals gelekte inloggegevens, malware-infecties, afwijkend gedrag en verdachte authenticatiepatronen. Het risicobepalingsproces maakt gebruik van geavanceerde machine learning algoritmen die patronen herkennen in gebruikersgedrag en deze correleren met bekende aanvalsmethoden. Door alleen gebruikers met een hoog risico te targeten, wordt voorkomen dat gebruikers met lage of gemiddelde risicoscores onnodig worden gehinderd in hun dagelijkse werkzaamheden, terwijl tegelijkertijd gecompromitteerde accounts snel worden gedetecteerd en aangepakt voordat aanvallers significante schade kunnen aanrichten. De toegangsactie die moet worden geconfigureerd is Wachtwoordwijziging vereisen, wat betekent dat gebruikers met een hoog risico verplicht zijn om hun wachtwoord te wijzigen via meervoudige authenticatie-verificatie voordat zij toegang krijgen tot hun account. Deze aanpak is effectiever dan accountblokkering omdat het gebruikers in staat stelt om zelf hun account te beveiligen zonder tussenkomst van de IT-afdeling, wat de responssnelheid verhoogt en de belasting op de helpdesk vermindert. Tegelijkertijd zorgt deze aanpak ervoor dat gecompromitteerde wachtwoorden onmiddellijk worden vervangen door nieuwe, veilige wachtwoorden die voldoen aan de organisatorische wachtwoordbeleidsregels. De wachtwoordwijziging vindt plaats binnen een beveiligde omgeving waarbij gebruikers worden begeleid bij het kiezen van een sterk, uniek wachtwoord dat niet eerder is gebruikt en dat voldoet aan alle complexiteitsvereisten. Het beleid moet worden afgedwongen door de schakelaar voor beleidsafdwinging in te schakelen. Zonder deze instelling wordt het beleid alleen in de evaluatiemodus uitgevoerd en worden geen daadwerkelijke acties ondernomen wanneer gebruikers als hoog risico worden geïdentificeerd. De evaluatiemodus is nuttig voor testdoeleinden en voor organisaties die willen begrijpen welke impact het beleid zou hebben voordat het daadwerkelijk wordt geactiveerd. Tijdens de evaluatieperiode kunnen beheerders analyseren hoeveel gebruikers zouden worden getroffen, welke soorten risicodetecties het meest voorkomen, en of de gekozen instellingen geschikt zijn voor de organisatie. Voor productieomgevingen moet het beleid echter altijd worden afgedwongen om daadwerkelijke beveiligingsbescherming te bieden en om te voldoen aan nalevingsvereisten van frameworks zoals CIS Azure Benchmark en BIO. Na activatie van het beleid is continue bewaking essentieel via het Identiteitsbescherming overzicht. Dit overzicht toont alle gebruikers die momenteel als hoog risico worden geïdentificeerd, samen met details over de specifieke risicodetecties die hebben geleid tot deze classificatie. Het overzicht biedt verschillende weergaven en filters waarmee beheerders kunnen analyseren welke soorten risico's het meest voorkomen, welke gebruikersgroepen het meest worden getroffen, en of er trends zichtbaar zijn die wijzen op gerichte aanvallen of systematische beveiligingsproblemen. Beheerders moeten dit overzicht regelmatig controleren, bij voorkeur dagelijks, om trends te identificeren zoals een toename van gelekte inloggegevens binnen een bepaalde gebruikersgroep, nieuwe malware-infecties die zich verspreiden door de organisatie, of afwijkend gedrag dat wijst op geavanceerde aanhoudende bedreigingen. Wanneer gebruikers als hoog risico worden geïdentificeerd, moeten beveiligingsanalisten een grondig onderzoek uitvoeren naar de risicodetecties. Dit onderzoek omvat het bekijken van de bron van gelekte inloggegevens om te bepalen of het gaat om een recent datalek of een oude lek die pas nu is ontdekt, het analyseren van malware-indicatoren om te begrijpen welk type malware is gedetecteerd en welke schadelijke activiteiten deze mogelijk heeft uitgevoerd, en het evalueren van afwijkend gedrag om te bepalen of dit legitieme activiteit is of daadwerkelijk verdacht. Het onderzoek moet ook omvatten het controleren van aanmeldgeschiedenis om te zien of er ongebruikelijke aanmeldpogingen zijn geweest, het analyseren van apparaat- en locatie-informatie om te bepalen of aanmeldingen plaatsvinden vanaf bekende en vertrouwde apparaten en locaties, en het evalueren van de timing en frequentie van activiteiten om te identificeren of er patronen zijn die wijzen op geautomatiseerde aanvallen of accountovername. Op basis van dit onderzoek kunnen analisten beslissen of aanvullende acties nodig zijn, zoals accountblokkering voor extreem hoge risiconiveaus, aanvullende verificatie voor twijfelgevallen, of het initiëren van een volledig incidentresponsproces voor bevestigde compromitteringen. Voor bevestigde gecompromitteerde accounts moet een geforceerde wachtwoordwijziging worden uitgevoerd, zelfs als het gebruikersrisicobeleid dit al automatisch heeft gedaan. Dit zorgt ervoor dat het nieuwe wachtwoord voldoet aan alle organisatorische wachtwoordbeleidsregels en dat gebruikers worden begeleid bij het kiezen van een sterk, uniek wachtwoord dat niet eerder is gebruikt en dat voldoet aan alle complexiteitsvereisten. Daarnaast moeten gebruikers worden geïnformeerd over wat er is gebeurd, welke risicodetecties hebben geleid tot de identificatie van hun account als hoog risico, en welke stappen zij kunnen nemen om hun account verder te beveiligen. Deze stappen omvatten het controleren van recente activiteit om te verifiëren dat alle aanmeldingen legitiem waren, het inschakelen van aanvullende beveiligingsfuncties zoals app-wachtwoorden voor specifieke toepassingen, het controleren van verbonden apparaten en het verwijderen van onbekende of verdachte apparaten, en het overwegen van het gebruik van beveiligingssleutels of andere geavanceerde authenticatiemethoden voor extra bescherming. Organisaties moeten ook overwegen om voor extreem hoge risiconiveaus te kiezen voor accountblokkering in plaats van alleen wachtwoordwijziging. Dit is met name relevant wanneer er sterke indicatoren zijn van actieve accountovername, zoals gelijktijdige aanmeldpogingen vanaf meerdere locaties die geografisch ver uit elkaar liggen, bekende aanvalspatronen die wijzen op geavanceerde aanhoudende bedreigingen, of combinaties van verschillende risicodetecties die samen een zeer hoog risiconiveau vormen. Accountblokkering geeft beveiligingsteams de tijd om een grondig onderzoek uit te voeren voordat toegang wordt hersteld, wat cruciaal kan zijn voor het voorkomen van verdere schade zoals gegevenslekken, laterale beweging binnen de omgeving, of het installeren van achterdeurtjes voor toekomstige toegang. Tijdens de blokkering kunnen analisten alle activiteiten van het account analyseren, contact opnemen met de gebruiker om te verifiëren of de activiteiten legitiem waren, en ervoor zorgen dat alle beveiligingsmaatregelen opnieuw worden geconfigureerd voordat toegang wordt hersteld.

Naleving en Controle

Het gebruikersrisicobeleid in Azure AD Identiteitsbescherming draagt significant bij aan de naleving van verschillende cybersecurity frameworks en regelgeving die van toepassing zijn op Nederlandse overheidsorganisaties. Deze nalevingsaspecten zijn cruciaal voor organisaties die moeten voldoen aan strikte beveiligingsstandaarden en regelgevende vereisten. Binnen het CIS Azure Benchmark v3.0.0 framework adresseert het gebruikersrisicobeleid specifiek controle 1.34, die vereist dat gebruikersrisicobeleidsregels zijn ingeschakeld en geconfigureerd. Deze controle is geclassificeerd als Level 2, wat betekent dat het wordt aanbevolen voor organisaties met verhoogde beveiligingsvereisten. De CIS Benchmark biedt gedetailleerde richtlijnen voor de implementatie van gebruikersrisicobeleidsregels, inclusief aanbevelingen voor risiconiveaus, toegangsacties en bewaking. Organisaties die voldoen aan deze controle demonstreren dat zij proactieve maatregelen hebben genomen om gecompromitteerde accounts te detecteren en te reageren, wat essentieel is voor het behouden van een sterke beveiligingspostuur. Voor Nederlandse overheidsorganisaties is het BIO (Baseline Informatiebeveiliging Overheid) framework van bijzonder belang. Het gebruikersrisicobeleid draagt direct bij aan BIO Thema 16.01, dat zich richt op incidentdetectie. Dit thema vereist dat organisaties mechanismen hebben geïmplementeerd om beveiligingsincidenten tijdig te detecteren, waarbij accountovername wordt beschouwd als een kritiek type beveiligingsincident. Het gebruikersrisicobeleid voldoet aan deze vereiste door automatisch gecompromitteerde accounts te detecteren via gelekte inloggegevens, malware-infecties en afwijkend gedrag, en door onmiddellijke responsacties te ondernemen zoals geforceerde wachtwoordwijziging. Dit zorgt ervoor dat beveiligingsincidenten niet onopgemerkt blijven en dat snelle mitigatie plaatsvindt voordat aanvallers verdere schade kunnen aanrichten. De ISO 27001:2022 standaard bevat verschillende controles die relevant zijn voor het gebruikersrisicobeleid. Controle A.5.24 richt zich op informatiebeveiligingsincidentbeheer en vereist dat organisaties processen hebben geïmplementeerd voor het detecteren, rapporteren en afhandelen van beveiligingsincidenten. Het gebruikersrisicobeleid draagt hieraan bij door geautomatiseerde detectie en respons te bieden voor accountovername-incidenten. Controle A.5.25 betreft de beoordeling en besluitvorming over informatiebeveiligingsgebeurtenissen, waarbij organisaties moeten kunnen bepalen welke gebeurtenissen daadwerkelijke incidenten zijn en welke acties moeten worden ondernomen. Het Identiteitsbescherming overzicht biedt de benodigde informatie voor deze beoordeling, inclusief details over risicodetecties, bronnen van gelekte inloggegevens en indicatoren van malware-infecties. De NIS2-richtlijn, die van toepassing is op essentiële en belangrijke entiteiten binnen de Europese Unie, bevat in Artikel 21 specifieke vereisten voor de detectie van beveiligingsdreigingen. Dit artikel vereist dat organisaties passende technische en organisatorische maatregelen nemen om beveiligingsdreigingen te detecteren, waarbij accountovername wordt beschouwd als een significante dreiging. Het gebruikersrisicobeleid voldoet aan deze vereiste door geautomatiseerde detectie van gecompromitteerde accounts te bieden en door onmiddellijke responsacties te ondernemen om de impact van deze dreigingen te beperken. Nederlandse organisaties die onder de NIS2-richtlijn vallen moeten kunnen aantonen dat zij dergelijke detectie- en responsmechanismen hebben geïmplementeerd, en het gebruikersrisicobeleid biedt hiervoor concrete bewijslast. Binnen de Algemene Verordening Gegevensbescherming (AVG) zijn Artikel 32 en Artikel 33 van bijzonder belang voor het gebruikersrisicobeleid. Artikel 32 vereist dat organisaties passende technische en organisatorische maatregelen nemen om persoonsgegevens te beveiligen, waarbij accountovername een directe bedreiging vormt voor de beveiliging van persoonsgegevens. Het gebruikersrisicobeleid draagt hieraan bij door gecompromitteerde accounts te detecteren en te beveiligen voordat aanvallers toegang kunnen krijgen tot persoonsgegevens. Artikel 33 vereist dat organisaties beveiligingsincidenten die leiden tot een inbreuk op persoonsgegevens melden aan de toezichthoudende autoriteit binnen 72 uur. Het gebruikersrisicobeleid helpt organisaties om dergelijke incidenten tijdig te detecteren, wat essentieel is voor het voldoen aan deze meldplicht. Wanneer een gecompromitteerd account toegang heeft gehad tot persoonsgegevens, moet dit worden beschouwd als een mogelijke inbreuk op persoonsgegevens die mogelijk moet worden gemeld, afhankelijk van de omvang en de aard van de toegang. Voor auditdoeleinden moeten organisaties kunnen aantonen dat het gebruikersrisicobeleid correct is geconfigureerd en actief is. Dit omvat screenshots van de beleidsconfiguratie, rapporten van gebruikers met een hoog risico, details van risicodetecties en logs van afgedwongen wachtwoordwijzigingen. Deze auditbewijzen moeten worden bewaard voor een periode van minimaal zeven jaar, in overeenstemming met algemene bewaarvereisten voor beveiligingslogs en incidentdocumentatie. Regelmatige audits moeten worden uitgevoerd om te verifiëren dat het beleid correct functioneert en dat alle gedetecteerde risico's op passende wijze worden afgehandeld.

Monitoring

Gebruik PowerShell-script user-risk-policy-azure.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve bewaking van het gebruikersrisicobeleid is essentieel om te verifiëren dat het beleid correct functioneert en om trends en patronen in risicodetecties te identificeren. Bewaking moet worden uitgevoerd op verschillende niveaus, van dagelijkse operationele controles tot wekelijkse trendanalyses en maandelijkse nalevingsverificaties. Het Identiteitsbescherming overzicht in Azure AD biedt een centrale locatie voor het bewaken van gebruikersrisico's. Dit overzicht toont real-time informatie over alle gebruikers die momenteel als hoog risico worden geïdentificeerd, inclusief hun risicoscore, de specifieke risicodetecties die hebben geleid tot deze classificatie, en de status van eventuele afgedwongen acties zoals wachtwoordwijzigingen. Beheerders moeten dit overzicht dagelijks controleren om nieuwe risicodetecties tijdig te identificeren en te reageren. Naast het overzicht moeten beheerders regelmatig rapporten genereren over gebruikersrisico's om trends te identificeren. Deze rapporten moeten informatie bevatten over het aantal gebruikers met een hoog risico over een bepaalde periode, de meest voorkomende typen risicodetecties zoals gelekte inloggegevens versus malware-infecties, en de effectiviteit van afgedwongen wachtwoordwijzigingen. Trendanalyses kunnen helpen bij het identificeren van nieuwe bedreigingen, zoals een toename van gelekte inloggegevens binnen een specifieke gebruikersgroep of nieuwe malware-varianten die worden gedetecteerd. Bewaking moet ook worden uitgevoerd op het niveau van individuele risicodetecties. Voor elke gebruiker die als hoog risico wordt geïdentificeerd, moeten beheerders de details van de risicodetectie bekijken, inclusief de bron van gelekte inloggegevens indien van toepassing, de timing van de detectie, en eventuele gerelateerde activiteit zoals aanmeldpogingen vanaf onbekende locaties. Deze informatie is essentieel voor het bepalen of een account daadwerkelijk is gecompromitteerd en welke aanvullende acties nodig zijn. Automatische bewaking kan worden geconfigureerd via Azure Monitor en Log Analytics, waarbij waarschuwingen worden ingesteld voor specifieke gebeurtenissen zoals een gebruiker die als hoog risico wordt geïdentificeerd of een gefaalde wachtwoordwijziging. Deze waarschuwingen kunnen worden geconfigureerd om beveiligingsanalisten direct te informeren wanneer actie vereist is, wat de responssnelheid verbetert en ervoor zorgt dat kritieke risico's niet onopgemerkt blijven. Nalevingsbewaking is ook belangrijk, waarbij regelmatig moet worden gecontroleerd of het gebruikersrisicobeleid nog steeds correct is geconfigureerd en actief is. Dit omvat verificatie dat het beleid is toegepast op alle vereiste gebruikers, dat het risiconiveau correct is ingesteld op Hoog, en dat de toegangsactie is geconfigureerd op Wachtwoordwijziging vereisen. Eventuele wijzigingen in de beleidsconfiguratie moeten worden gedocumenteerd en gerechtvaardigd. Ten slotte moeten beheerders de effectiviteit van het gebruikersrisicobeleid bewaken door te meten hoeveel gecompromitteerde accounts worden gedetecteerd en afgehandeld, hoeveel tijd er verstrijkt tussen detectie en mitigatie, en hoeveel valse positieven worden geïdentificeerd. Deze metingen helpen bij het optimaliseren van de beleidsconfiguratie en het demonstreren van de waarde van het beleid aan belanghebbenden.

Remediatie

Gebruik PowerShell-script user-risk-policy-azure.ps1 (functie Invoke-Remediation) – Herstellen.

Remediatie van gebruikers met een hoog risico vereist een gestructureerde aanpak die begint met onderzoek en eindigt met het herstellen van de beveiliging van het account. Het remediatieproces moet worden uitgevoerd door getrainde beveiligingsanalisten die begrijpen hoe verschillende risicodetectietypen moeten worden geïnterpreteerd en welke acties passend zijn voor verschillende scenario's. Wanneer een gebruiker als hoog risico wordt geïdentificeerd, moet eerst een grondig onderzoek worden uitgevoerd naar de risicodetectie. Dit onderzoek begint met het bekijken van de details van de risicodetectie in het Identiteitsbescherming overzicht, waarbij specifieke aandacht wordt besteed aan het type detectie zoals gelekte inloggegevens, malware-infectie of afwijkend gedrag. Voor gelekte inloggegevens moet worden bepaald of het gaat om een recent datalek of een oude lek, en of de gelekte inloggegevens daadwerkelijk overeenkomen met het account van de gebruiker. Voor malware-infecties moeten de specifieke malware-indicatoren worden geanalyseerd om te begrijpen welke type bedreiging is gedetecteerd. Na het onderzoek moet worden bepaald of het account daadwerkelijk is gecompromitteerd of dat het gaat om een valse positief. Dit vereist het evalueren van alle beschikbare informatie, inclusief recente aanmeldactiviteit, locaties van aanmeldpogingen, en eventuele gerelateerde beveiligingswaarschuwingen. Als het account daadwerkelijk is gecompromitteerd, moeten onmiddellijke mitigatiestappen worden ondernomen. De primaire remediatieactie voor gecompromitteerde accounts is geforceerde wachtwoordwijziging, die automatisch wordt afgedwongen door het gebruikersrisicobeleid wanneer gebruikers als hoog risico worden geïdentificeerd. Echter, beveiligingsanalisten moeten verifiëren dat deze wachtwoordwijziging daadwerkelijk heeft plaatsgevonden en dat het nieuwe wachtwoord voldoet aan alle organisatorische wachtwoordbeleidsregels. Als de automatische wachtwoordwijziging is mislukt, moet handmatig een wachtwoordwijziging worden geforceerd. Voor accounts met extreem hoge risiconiveaus of sterke indicatoren van actieve accountovername moet worden overwogen om het account tijdelijk te blokkeren in plaats van alleen wachtwoordwijziging te vereisen. Accountblokkering geeft beveiligingsteams de tijd om een grondig onderzoek uit te voeren en te verifiëren dat alle bedreigingen zijn gemitigeerd voordat toegang wordt hersteld. De blokkering moet worden gecommuniceerd aan de gebruiker, samen met instructies over hoe toegang kan worden hersteld na het voltooien van het onderzoek. Na wachtwoordwijziging of accountblokkering moeten aanvullende verificatiestappen worden uitgevoerd om te verifiëren dat het account volledig is beveiligd. Dit omvat het controleren van recente activiteit om te identificeren of er onbevoegde toegang heeft plaatsgevonden, het controleren van meervoudige authenticatie-registraties om te verifiëren dat geen onbevoegde authenticatiemethoden zijn toegevoegd, en het controleren van toepassingsmachtigingen om te identificeren of aanvallers toegang hebben verkregen tot gevoelige toepassingen. Gebruikers moeten worden geïnformeerd over wat er is gebeurd en welke stappen zij kunnen nemen om hun account verder te beveiligen. Deze communicatie moet duidelijke instructies bevatten over het controleren van recente activiteit, het inschakelen van aanvullende beveiligingsfuncties zoals meervoudige authenticatie, en het melden van verdachte activiteit. Gebruikers moeten ook worden begeleid bij het kiezen van een sterk, uniek wachtwoord dat niet wordt hergebruikt op andere websites. Voor accounts die zijn getroffen door malware-infecties moet ook worden overwogen om aanvullende stappen te ondernemen, zoals het scannen van het apparaat van de gebruiker op malware, het resetten van sessies om ervoor te zorgen dat aanvallers geen actieve sessies hebben, en het controleren van andere accounts die mogelijk zijn gecompromitteerd via hetzelfde apparaat of dezelfde inloggegevens. Ten slotte moeten alle remediatieacties worden gedocumenteerd voor controledoeleinden, inclusief details over de risicodetectie, het onderzoek dat is uitgevoerd, de conclusies die zijn getrokken, en de acties die zijn ondernomen. Deze documentatie is essentieel voor nalevingsverificatie en voor het leren van incidenten om toekomstige remediatieprocessen te verbeteren.

Compliance & Frameworks

• CIS M365: Control 1.34 (L2) - Zorg ervoor dat het gebruikersrisicobeleid is ingeschakeld
• BIO: 16.01 - BIO: beveiligingsincidentdetectie en geautomatiseerde respons
• ISO 27001:2022: A.5.24, A.5.25 - Incidentbeheer en beoordeling
• NIS2: Artikel - Geautomatiseerde detectie van beveiligingsdreigingen

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Gebruikersrisicobeleid: Gebruikers met hoog risico worden verplicht om hun wachtwoord veilig te wijzigen. Geautomatiseerde detectie van gelekte inloggegevens en afwijkingsdetectie. Vereist: Azure AD Premium P2 (Identiteitsbescherming). Activatie: Identiteitsbescherming → Gebruikersrisicobeleid → Hoog risico: Wachtwoordwijziging vereisen. Verplicht voor CIS 1.34, BIO 16.01, AVG. Implementatie: 1-2 uur. Geautomatiseerde respons op accountovername.

• Implementatietijd: 3 uur
• FTE required: 0.02 FTE