Azure: Sign-in Risk Policy Configureren Via Identity Protection

Traditionele statische beveiligingsbeleidsregels die meervoudige authenticatie voor iedereen verplichten, missen belangrijke contextuele informatie. Een aanmelding vanaf het thuis-IP-adres van een medewerker tijdens kantooruren vormt bijvoorbeeld een laag risico, terwijl een aanmelding vanuit Rusland tien minuten later uiterst verdacht is. Sign-in risicodetectie maakt gebruik van machine learning en Microsoft-bedreigingsinformatie om onmogelijke reispatronen te identificeren, zoals een aanmelding vanuit Nederland gevolgd door een aanmelding vanuit China binnen één uur. Het systeem detecteert ook anonieme IP-adressen zoals TOR-netwerken en VPN-diensten, onbekende locaties, IP-adressen die gekoppeld zijn aan malware, en pogingen tot wachtwoordspray-aanvallen. Op risico gebaseerde beleidsregels reageren dynamisch: laag risico wordt toegestaan, middel risico vereist meervoudige authenticatie, en hoog risico wordt geblokkeerd met een verplichte wachtwoordwijziging.

Implementatie

Deze controle configureert het sign-in risicobeleid waarbij het risiconiveau wordt ingesteld op Medium of High, en de toegang wordt geregeld via meervoudige authenticatie voor medium risico of blokkering voor hoog risico. Azure AD Identiteitsbescherming analyseert elke aanmelding in realtime en berekent een risicoscore op basis van IP-reputatie, locatiegegevens zoals bekende versus onbekende locaties, reispatronen die onmogelijk zijn, apparaatinformatie en bedreigingsinformatie. Aanmeldingen met medium of hoog risico activeren het beleid: de gebruiker moet meervoudige authenticatie doorlopen indien mogelijk, of wordt geblokkeerd bij hoog risico.

Vereisten

Voor de implementatie van het sign-in risicobeleid zijn verschillende technische en organisatorische vereisten noodzakelijk. Deze vereisten vormen de basis voor een effectieve bescherming tegen gecompromitteerde accounts en verdachte aanmeldpogingen. De belangrijkste technische vereiste is een Azure AD Premium P2 licentie, die onmisbaar is voor de functionaliteit van Identiteitsbescherming. Zonder deze licentie is het niet mogelijk om sign-in risicobeleid te configureren of gebruik te maken van de geavanceerde machine learning-algoritmen die verdachte aanmeldpogingen detecteren. Organisaties die momenteel Azure AD Premium P1 of de gratis versie gebruiken, moeten eerst upgraden naar Premium P2 voordat zij deze controle kunnen implementeren.

Naast de licentievereiste is het essentieel dat alle gebruikers geregistreerd zijn voor meervoudige authenticatiemethoden. Het sign-in risicobeleid werkt namelijk door middel van meervoudige authenticatie af te dwingen bij verdachte aanmeldpogingen. Als gebruikers niet beschikken over geregistreerde MFA-methoden, kunnen zij worden geblokkeerd bij medium of hoog risico, wat kan leiden tot productiviteitsverlies en ondersteuningsvragen. Organisaties moeten daarom eerst een uitgebreide MFA-registratiecampagne uitvoeren waarbij alle gebruikers ten minste twee authenticatiemethoden registreren, zoals de Microsoft Authenticator-app, SMS-verificatie, of hardwaretokens. Voor Nederlandse overheidsorganisaties is het bovendien belangrijk om te voldoen aan de BIO-richtlijnen voor sterke authenticatie, wat betekent dat SMS-verificatie als secundaire methode wordt afgeraden en de voorkeur uitgaat naar app-gebaseerde of hardware-gebaseerde authenticatie.

De configuratie van het sign-in risicobeleid zelf vereist specifieke technische kennis en toegangsrechten. Beheerders moeten beschikken over de rol van Beveiligingsbeheerder of Globale beheerder in Azure AD om het beleid te kunnen configureren. Daarnaast is het belangrijk om voorafgaand aan de implementatie een duidelijk beeld te hebben van de organisatorische context, zoals welke gebruikersgroepen moeten worden beschermd, welke uitzonderingen nodig zijn voor break-glass accounts, en wat de gewenste balans is tussen beveiliging en gebruiksvriendelijkheid. Organisaties moeten ook rekening houden met gebruikers die regelmatig reizen of werken vanaf verschillende locaties, omdat deze gebruikers mogelijk vaker worden geconfronteerd met medium risico-aanmeldingen.

Voor effectieve monitoring en rapportage is toegang tot het Identiteitsbescherming-dashboard vereist. Dit dashboard biedt inzicht in alle risicovolle aanmeldingen, de berekende risicoscores, en de genomen acties. Beveiligingsteams moeten regelmatig dit dashboard raadplegen om trends te identificeren, valse positieven te herkennen, en gecompromitteerde accounts tijdig te detecteren. Het dashboard toont ook statistieken over het aantal geblokkeerde aanmeldingen, het aantal succesvolle MFA-uitdagingen, en patronen in risicovolle activiteiten. Deze informatie is waardevol voor het optimaliseren van het beleid en het verbeteren van de algehele beveiligingspostuur.

Ten slotte vereist de implementatie van sign-in risicobeleid een goed gedefinieerd incidentresponsproces voor hoog-risico aanmeldingen. Wanneer een aanmelding wordt geclassificeerd als hoog risico en wordt geblokkeerd, moet het beveiligingsteam in staat zijn om snel te bepalen of dit een valse positief is of een daadwerkelijk gecompromitteerd account. Het proces moet duidelijke stappen bevatten voor het onderzoeken van hoog-risico aanmeldingen, het verifiëren van de identiteit van de gebruiker, het resetten van wachtwoorden indien nodig, en het documenteren van incidenten voor auditdoeleinden. Voor Nederlandse overheidsorganisaties is dit proces ook relevant voor naleving van de BIO-richtlijnen en de meldplicht datalekken, omdat gecompromitteerde accounts kunnen leiden tot ongeautoriseerde toegang tot persoonsgegevens.

Implementatie

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

De implementatie van het sign-in risicobeleid begint met navigeren naar de Azure AD-portal en het openen van de Identiteitsbescherming-sectie. Beheerders moeten eerst inloggen op de Azure-portal met een account dat beschikt over de rol van Beveiligingsbeheerder of Globale beheerder. Vervolgens navigeren zij naar Azure Active Directory, selecteren de sectie Beveiliging, en openen Identiteitsbescherming. Binnen Identiteitsbescherming is het sign-in risicobeleid te vinden onder de categorie Beleidsregels. Het is belangrijk om te begrijpen dat er twee soorten risicobeleidsregels bestaan: sign-in risicobeleid, dat zich richt op individuele aanmeldpogingen, en gebruikersrisicobeleid, dat zich richt op gecompromitteerde accounts. Voor deze controle is het sign-in risicobeleid relevant.

Bij het configureren van het beleid moeten beheerders eerst bepalen welke gebruikers onder het beleid vallen. De aanbeveling is om alle gebruikers te selecteren, met uitzondering van break-glass accounts. Break-glass accounts zijn noodaccounts die worden gebruikt in noodsituaties wanneer normale beheerdersaccounts niet beschikbaar zijn. Deze accounts moeten worden uitgesloten van het sign-in risicobeleid om te voorkomen dat zij worden geblokkeerd tijdens kritieke situaties. Het is echter belangrijk om deze accounts op een andere manier te beveiligen, bijvoorbeeld door middel van zeer sterke wachtwoorden en beperkte toegang. Voor Nederlandse overheidsorganisaties is het raadzaam om break-glass accounts te documenteren en regelmatig te controleren op ongeautoriseerd gebruik.

Het volgende belangrijke configuratieonderdeel is de selectie van het risiconiveau. Het beleid kan worden ingesteld om te reageren op aanmeldingen met medium risico, hoog risico, of beide. De aanbeveling is om beide risiconiveaus te selecteren voor maximale beveiliging. Aanmeldingen met medium risico worden geconfronteerd met een verplichte meervoudige authenticatie-uitdaging, terwijl aanmeldingen met hoog risico direct worden geblokkeerd. Deze aanpak biedt een goede balans tussen beveiliging en gebruiksvriendelijkheid, omdat gebruikers met medium risico nog steeds toegang kunnen krijgen na succesvolle MFA-verificatie, terwijl hoog-risico aanmeldingen die zeer waarschijnlijk gecompromitteerd zijn, direct worden gestopt.

Voor aanmeldingen met medium risico moet de toegangsactie worden ingesteld op het vereisen van meervoudige authenticatie. Dit betekent dat gebruikers die een medium risico-aanmelding proberen, worden gevraagd om een extra verificatiestap uit te voeren, zoals het invoeren van een code uit de Microsoft Authenticator-app of het bevestigen van een pushmelding. Als de gebruiker succesvol de MFA-uitdaging voltooit, krijgt hij of zij toegang tot de applicatie of service. Als de gebruiker de MFA-uitdaging niet kan voltooien, bijvoorbeeld omdat er geen geregistreerde MFA-methode beschikbaar is, wordt de toegang geweigerd. Het is daarom cruciaal dat alle gebruikers voorafgaand aan de implementatie van het beleid ten minste één MFA-methode hebben geregistreerd.

Het afdwingen van het beleid moet worden ingeschakeld door de schakelaar op Aan te zetten. Wanneer het beleid is ingeschakeld, begint Azure AD Identiteitsbescherming onmiddellijk met het analyseren van alle aanmeldingen en het toepassen van het beleid op basis van de berekende risicoscores. Het is belangrijk om te begrijpen dat het systeem enige tijd nodig heeft om een baseline te ontwikkelen van normale gebruikersgedragingen, waardoor de eerste weken na implementatie mogelijk meer valse positieven kunnen optreden. Beheerders moeten daarom geduldig zijn en het beleid niet te snel aanpassen op basis van initiële resultaten.

Na de implementatie is continue monitoring van het Identiteitsbescherming-dashboard essentieel. Het dashboard biedt een overzicht van alle risicovolle aanmeldingen, inclusief details over de berekende risicoscores, de redenen voor de risicoclassificatie, en de genomen acties. Beveiligingsteams moeten dit dashboard dagelijks raadplegen om trends te identificeren en patronen te herkennen. Bijvoorbeeld, als een bepaalde locatie of IP-adres regelmatig medium risico-aanmeldingen veroorzaakt, kan dit wijzen op een probleem met de netwerkinfrastructuur of een daadwerkelijke beveiligingsdreiging. Het dashboard toont ook statistieken over het aantal succesvolle MFA-uitdagingen en het aantal geblokkeerde aanmeldingen, wat waardevolle informatie biedt voor het evalueren van de effectiviteit van het beleid.

Hoog-risico aanmeldingen vereisen onmiddellijke aandacht en onderzoek. Wanneer een aanmelding wordt geclassificeerd als hoog risico en wordt geblokkeerd, moet het beveiligingsteam snel bepalen of dit een valse positief is of een daadwerkelijk gecompromitteerd account. Het onderzoek moet beginnen met het verifiëren van de identiteit van de gebruiker via een alternatief communicatiekanaal, zoals een telefoongesprek of een beveiligd bericht. Als de gebruiker bevestigt dat hij of zij de aanmelding heeft geprobeerd, kan het team de aanmelding markeren als een valse positief en het account deblokkeren. Als de gebruiker ontkent de aanmelding te hebben geprobeerd, moet het team het account onmiddellijk als gecompromitteerd behandelen en de standaard incidentresponsprocedures volgen, inclusief het resetten van wachtwoorden, het controleren van toegangslogboeken, en het documenteren van het incident.

Ten slotte moeten organisaties waarschuwingen configureren om het beveiligingsteam automatisch te informeren over hoog-risico aanmeldingen. Deze waarschuwingen kunnen worden ingesteld via Azure Monitor of via de ingebouwde waarschuwingsfunctionaliteit in Azure AD. Het is aan te raden om waarschuwingen te configureren die worden geactiveerd wanneer een hoog-risico aanmelding wordt gedetecteerd, zodat het beveiligingsteam onmiddellijk kan reageren. Voor grotere organisaties kan het ook nuttig zijn om waarschuwingen te configureren voor ongebruikelijke patronen, zoals een plotselinge toename van medium risico-aanmeldingen vanuit een specifieke locatie, wat kan wijzen op een gecoördineerde aanval of een probleem met de netwerkinfrastructuur.

Compliance en Auditing

Het sign-in risicobeleid draagt bij aan naleving van verschillende belangrijke beveiligingsstandaarden en frameworks die relevant zijn voor Nederlandse overheidsorganisaties. De implementatie van dit beleid is een directe vereiste voor de CIS Azure Benchmark versie 3.0.0, specifiek controle 1.33, die stelt dat sign-in risicobeleid moet zijn ingeschakeld. De CIS Azure Benchmark is een internationaal erkende set van best practices voor cloudbeveiliging en wordt veel gebruikt door organisaties die hun Azure-omgeving willen beveiligen. Controle 1.33 richt zich specifiek op het gebruik van risicogebaseerde authenticatie om gecompromitteerde accounts en verdachte aanmeldpogingen te detecteren en te blokkeren. Organisaties die deze controle niet implementeren, voldoen niet aan de CIS Azure Benchmark en lopen een verhoogd risico op beveiligingsincidenten.

Voor Nederlandse overheidsorganisaties is de Baseline Informatiebeveiliging Overheid, oftewel BIO, van groot belang. Het sign-in risicobeleid draagt direct bij aan BIO-thema 16.01, dat zich richt op incidentdetectie. Dit thema vereist dat organisaties beschikken over mechanismen om beveiligingsincidenten tijdig te detecteren, inclusief gecompromitteerde accounts en verdachte activiteiten. Het sign-in risicobeleid voldoet aan deze vereiste door gebruik te maken van machine learning-algoritmen en bedreigingsinformatie om verdachte aanmeldpogingen te identificeren en automatisch te reageren. Organisaties die dit beleid implementeren, kunnen aantonen dat zij beschikken over geautomatiseerde detectiecapaciteiten die voldoen aan de BIO-richtlijnen. Tijdens BIO-audits kunnen beheerders het Identiteitsbescherming-dashboard gebruiken om te demonstreren dat het systeem actief risicovolle aanmeldingen detecteert en blokkeert.

De ISO 27001:2022 standaard voor informatiebeveiligingsmanagement bevat controle A.8.16, die zich richt op het monitoren van activiteiten en het detecteren van anomalieën. Het sign-in risicobeleid is een concrete implementatie van deze controle, omdat het systeem continu alle aanmeldpogingen monitort en afwijkingen van normaal gedrag detecteert. De controle vereist dat organisaties beschikken over mechanismen om ongebruikelijke activiteiten te identificeren die kunnen wijzen op beveiligingsincidenten. Het sign-in risicobeleid voldoet aan deze vereiste door onmogelijke reispatronen, onbekende locaties, anonieme IP-adressen en andere anomalieën te detecteren. Organisaties die gecertificeerd zijn volgens ISO 27001 of die streven naar certificering, kunnen het sign-in risicobeleid gebruiken als bewijs van naleving van controle A.8.16. Het is belangrijk om de configuratie en werking van het beleid te documenteren in het informatiebeveiligingsmanagementsysteem en regelmatig te evalueren of het beleid effectief blijft.

De NIS2-richtlijn, die van toepassing is op essentiële en belangrijke entiteiten in de Europese Unie, bevat artikel 21 dat zich richt op de detectie van beveiligingsdreigingen. Dit artikel vereist dat organisaties beschikken over systemen en processen om beveiligingsdreigingen tijdig te detecteren en te analyseren. Het sign-in risicobeleid is een belangrijk onderdeel van een uitgebreide detectiestrategie die voldoet aan de NIS2-vereisten. Het beleid maakt gebruik van geavanceerde technologieën zoals machine learning en bedreigingsinformatie om dreigingen te identificeren die traditionele beveiligingsmaatregelen mogelijk missen. Nederlandse organisaties die onder de NIS2-richtlijn vallen, moeten kunnen aantonen dat zij beschikken over effectieve detectiecapaciteiten, en het sign-in risicobeleid kan worden gebruikt als onderdeel van deze demonstratie. Het is belangrijk om te begrijpen dat NIS2 niet alleen technische maatregelen vereist, maar ook organisatorische processen voor het analyseren en reageren op gedetecteerde dreigingen.

Het Zero Trust-beveiligingsmodel, dat steeds belangrijker wordt voor moderne organisaties, is gebaseerd op het principe van risicogebaseerde toegang. Zero Trust gaat uit van het idee dat organisaties nooit automatisch moeten vertrouwen op gebruikers, apparaten of netwerken, maar altijd moeten verifiëren en toegang moeten verlenen op basis van risico-evaluaties. Het sign-in risicobeleid is een concrete implementatie van dit principe, omdat het systeem elke aanmelding evalueert op basis van verschillende risicofactoren en toegang verleent of weigert op basis van het berekende risiconiveau. In plaats van statische regels die altijd meervoudige authenticatie vereisen, past het sign-in risicobeleid dynamisch de beveiligingsvereisten aan op basis van de context van de aanmelding. Dit resulteert in een betere gebruikerservaring voor legitieme gebruikers, terwijl gecompromitteerde accounts en verdachte aanmeldpogingen worden geblokkeerd. Organisaties die een Zero Trust-architectuur implementeren, moeten het sign-in risicobeleid beschouwen als een essentieel onderdeel van hun identiteits- en toegangsbeheerstrategie.

Voor auditdoeleinden is het belangrijk om regelmatig rapporten te genereren die aantonen dat het sign-in risicobeleid actief is en effectief werkt. Het Identiteitsbescherming-dashboard biedt verschillende rapporten die kunnen worden gebruikt tijdens audits, inclusief overzichten van risicovolle aanmeldingen, statistieken over geblokkeerde aanmeldingen, en details over gecompromitteerde accounts. Organisaties moeten deze rapporten regelmatig archiveren en bewaren volgens hun bewaarbeleid, meestal voor een periode van minimaal zeven jaar voor compliance-doeleinden. Tijdens audits kunnen beheerders ook screenshots maken van de beleidsconfiguratie om aan te tonen dat het beleid correct is ingesteld en actief is. Het is belangrijk om te documenteren welke gebruikersgroepen onder het beleid vallen, welke uitzonderingen zijn gemaakt, en hoe het beveiligingsteam reageert op hoog-risico aanmeldingen.

Bewaking

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

Effectieve bewaking van het sign-in risicobeleid vormt de ruggengraat van een succesvolle identiteitsbeschermingsstrategie. Zonder continue bewaking is het niet mogelijk om te bepalen of het beleid effectief werkt, of er valse positieven optreden, en of er gecompromitteerde accounts zijn die aandacht vereisen. Het Identiteitsbescherming-dashboard in Azure AD biedt beveiligingsteams een centraal punt voor het bewaken van alle risicovolle aanmeldingen, maar het vereist regelmatige aandacht en een gestructureerde aanpak om maximaal rendement te behalen. Beveiligingsteams moeten niet alleen reageren op incidenten, maar ook proactief patronen identificeren die kunnen wijzen op systematische aanvallen of configuratieproblemen.

Het Identiteitsbescherming-dashboard toont verschillende typen informatie die essentieel zijn voor effectieve bewaking. Allereerst worden alle risicovolle aanmeldingen getoond met details over de berekende risicoscores, de redenen voor de risicoclassificatie, en de genomen acties. Elke aanmelding bevat informatie over het tijdstip van de aanmelding, de gebruikersidentiteit, de locatie waarvan de aanmelding plaatsvond, het gebruikte apparaat, en de IP-adres reputatie. Deze gedetailleerde informatie stelt beveiligingsteams in staat om snel te bepalen of een risicovolle aanmelding legitiem is of daadwerkelijk verdacht. Bijvoorbeeld, een medium risico-aanmelding vanaf een onbekende locatie kan normaal zijn als de gebruiker op reis is, maar kan ook wijzen op een gecompromitteerd account als de gebruiker zich op het kantoor bevindt en geen reis heeft gepland.

Het dashboard biedt ook statistieken over het aantal geblokkeerde aanmeldingen, het aantal succesvolle meervoudige authenticatie-uitdagingen, en trends over tijd. Deze statistieken zijn waardevol voor het evalueren van de algehele effectiviteit van het beleid en het identificeren van patronen die aandacht vereisen. Een plotselinge toename van medium risico-aanmeldingen vanuit een specifieke locatie kan bijvoorbeeld wijzen op een gecoördineerde aanval, een probleem met de netwerkinfrastructuur, of een VPN-dienst die door meerdere gebruikers wordt gebruikt. Beveiligingsteams moeten deze statistieken regelmatig analyseren en trends identificeren die kunnen wijzen op beveiligingsdreigingen of configuratieproblemen. Voor Nederlandse overheidsorganisaties is deze bewaking ook relevant voor compliance-doeleinden, omdat het dashboard kan worden gebruikt om aan te tonen dat het systeem actief beveiligingsdreigingen detecteert en blokkeert.

Voor effectieve bewaking is het belangrijk om waarschuwingen te configureren die het beveiligingsteam automatisch informeren over kritieke gebeurtenissen. Hoog-risico aanmeldingen die worden geblokkeerd vereisen altijd onmiddellijke aandacht, omdat deze zeer waarschijnlijk gecompromitteerde accounts of ernstige beveiligingsdreigingen vertegenwoordigen. Organisaties moeten waarschuwingen configureren die worden geactiveerd wanneer een hoog-risico aanmelding wordt gedetecteerd, zodat het beveiligingsteam direct kan beginnen met onderzoek. Deze waarschuwingen kunnen worden ingesteld via Azure Monitor, waardoor ze kunnen worden geïntegreerd met bestaande Security Information and Event Management systemen of helpdesksystemen. Voor grotere organisaties kan het ook nuttig zijn om waarschuwingen te configureren voor ongebruikelijke patronen, zoals een plotselinge toename van medium risico-aanmeldingen binnen een korte periode, wat kan wijzen op een gecoördineerde aanval of een probleem met de netwerkinfrastructuur.

Naast realtime bewaking is het belangrijk om regelmatig retrospectieve analyses uit te voeren om trends te identificeren en de effectiviteit van het beleid te evalueren. Het Identiteitsbescherming-dashboard biedt exportfunctionaliteit waarmee beveiligingsteams risicovolle aanmeldingen kunnen exporteren voor gedetailleerde analyses in externe tools. Deze analyses kunnen patronen identificeren die niet direct zichtbaar zijn in het dashboard, zoals seizoensgebonden trends, correlaties tussen verschillende risicofactoren, of lange-termijn ontwikkelingen in aanvalspatronen. Organisaties moeten maandelijks een uitgebreide analyse uitvoeren van alle risicovolle aanmeldingen om te evalueren of het beleid effectief blijft en of er aanpassingen nodig zijn. Deze analyses moeten ook worden gedocumenteerd voor auditdoeleinden, omdat auditors vaak vragen om bewijs dat het beleid regelmatig wordt geëvalueerd en geoptimaliseerd.

Het identificeren en verminderen van valse positieven is een belangrijk aspect van effectieve bewaking. Valse positieven zijn risicovolle aanmeldingen die ten onrechte als verdacht worden geclassificeerd, wat kan leiden tot gebruikersfrustratie en onnodige beveiligingsonderzoeken. Veelvoorkomende oorzaken van valse positieven zijn gebruikers die regelmatig reizen, gebruikers die VPN-diensten gebruiken voor privacy, of netwerkconfiguraties die resulteren in onjuiste locatiedetectie. Beveiligingsteams moeten regelmatig het dashboard raadplegen om valse positieven te identificeren en te analyseren waarom ze optreden. Als bepaalde gebruikers of locaties consistent valse positieven veroorzaken, kan het nodig zijn om uitzonderingen te configureren of het beleid aan te passen om deze legitieme aanmeldingen niet langer als risicovol te classificeren. Het is echter belangrijk om uitzonderingen spaarzaam te gebruiken en alleen wanneer er duidelijke legitieme redenen zijn, omdat te veel uitzonderingen de effectiviteit van het beleid kunnen verminderen.

Voor Nederlandse overheidsorganisaties is bewaking ook relevant voor naleving van de meldplicht datalekken. Als een hoog-risico aanmelding wordt geclassificeerd als een gecompromitteerd account en leidt tot ongeautoriseerde toegang tot persoonsgegevens, kan dit een datalek vormen dat moet worden gemeld aan de Autoriteit Persoonsgegevens. Het Identiteitsbescherming-dashboard en de gerelateerde logboeken vormen belangrijk bewijsmateriaal voor het onderzoeken van potentiële datalekken en het bepalen of melding vereist is. Beveiligingsteams moeten daarom zorgvuldig documenteren hoe zij hoog-risico aanmeldingen onderzoeken, welke conclusies zij trekken, en welke acties zij ondernemen. Deze documentatie is niet alleen waardevol voor compliance-doeleinden, maar ook voor het verbeteren van incidentresponsprocessen en het leren van eerdere incidenten.

Remediatie

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

Remediatie van problemen met het sign-in risicobeleid vereist een gestructureerde aanpak die begint met het identificeren van de oorzaak van het probleem en eindigt met het implementeren van de juiste oplossing. Wanneer het beleid niet werkt zoals verwacht, kunnen er verschillende oorzaken zijn, variërend van configuratiefouten tot licentieproblemen tot technische problemen met de Azure AD-omgeving. Het is belangrijk om systematisch te werk te gaan en eerst de meest waarschijnlijke oorzaken te onderzoeken voordat over te gaan op complexere diagnoses. Beheerders moeten beginnen met het controleren van de basisconfiguratie, inclusief of het beleid daadwerkelijk is ingeschakeld, welke gebruikers onder het beleid vallen, en welke risiconiveaus zijn geselecteerd.

De meest voorkomende remediatie-actie is het herstellen van een beleid dat niet is ingeschakeld of dat is uitgeschakeld door een fout of onbedoelde configuratiewijziging. In sommige gevallen kan het beleid automatisch worden uitgeschakeld wanneer er een probleem is met de Azure AD-configuratie of wanneer er onvoldoende licenties beschikbaar zijn. Beheerders moeten daarom regelmatig controleren of het beleid nog steeds actief is door naar de Identiteitsbescherming-sectie te navigeren en te verifiëren dat de schakelaar voor het sign-in risicobeleid op Aan staat. Als het beleid is uitgeschakeld, moet het worden ingeschakeld door de schakelaar te activeren. Het is belangrijk om te begrijpen dat wanneer het beleid wordt ingeschakeld, het systeem enige tijd nodig heeft om opnieuw te beginnen met het analyseren van aanmeldingen, dus beheerders moeten geduldig zijn en niet verwachten dat het beleid onmiddellijk alle aanmeldingen analyseert.

Als het beleid wel is ingeschakeld maar niet werkt zoals verwacht, kan het probleem liggen aan de configuratie van de risiconiveaus of de toegangsacties. Beheerders moeten controleren of de juiste risiconiveaus zijn geselecteerd, of de toegangsacties correct zijn geconfigureerd, en of de gebruikerselectie correct is ingesteld. Het is mogelijk dat het beleid is geconfigureerd om alleen te reageren op hoog risico, terwijl de organisatie ook wil reageren op medium risico. In dat geval moeten beheerders de configuratie bijwerken om ook medium risico te selecteren. Evenzo moeten beheerders controleren of de toegangsactie voor medium risico correct is ingesteld op het vereisen van meervoudige authenticatie, en of de toegangsactie voor hoog risico correct is ingesteld op blokkering.

Een andere veelvoorkomende remediatie-actie is het oplossen van licentieproblemen. Het sign-in risicobeleid vereist Azure AD Premium P2-licenties voor alle gebruikers die onder het beleid vallen. Als gebruikers niet beschikken over Premium P2-licenties, worden hun aanmeldingen niet geanalyseerd door het risicobeleid, wat kan leiden tot een valse indruk dat het beleid niet werkt. Beheerders moeten controleren of alle gebruikers die onder het beleid vallen beschikken over Premium P2-licenties door de licentieportaal in Azure AD te raadplegen. Als gebruikers niet beschikken over de juiste licenties, moeten beheerders licenties toewijzen of de gebruikerselectie bijwerken om alleen gebruikers te selecteren die wel beschikken over Premium P2-licenties. Voor grote organisaties kan het handig zijn om een dynamische groep te maken die alleen gebruikers bevat met Premium P2-licenties en deze groep te gebruiken in de gebruikerselectie van het beleid.

Als gebruikers regelmatig worden geblokkeerd of geconfronteerd met meervoudige authenticatie-uitdagingen die als onterecht worden ervaren, kan het nodig zijn om het beleid aan te passen om valse positieven te verminderen. Dit kan worden gedaan door specifieke gebruikers of groepen uit te sluiten van het beleid, of door de risicodrempels aan te passen. Het is echter belangrijk om uitzonderingen spaarzaam te gebruiken en alleen wanneer er duidelijke legitieme redenen zijn, omdat te veel uitzonderingen de effectiviteit van het beleid kunnen verminderen. Beheerders moeten eerst onderzoeken waarom bepaalde gebruikers consistent valse positieven veroorzaken voordat zij uitzonderingen configureren. Bijvoorbeeld, als een gebruiker regelmatig reist, kan het nodig zijn om die gebruiker uit te sluiten van het beleid, maar alleen na zorgvuldige afweging van de beveiligingsrisico's. Voor Nederlandse overheidsorganisaties is het belangrijk om alle uitzonderingen te documenteren en regelmatig te evalueren of ze nog steeds nodig zijn.

Wanneer het beleid correct is geconfigureerd maar gebruikers nog steeds problemen ondervinden, kan het probleem liggen aan de MFA-registratie van gebruikers. Het sign-in risicobeleid werkt door middel van meervoudige authenticatie af te dwingen bij verdachte aanmeldpogingen, dus als gebruikers niet beschikken over geregistreerde MFA-methoden, kunnen zij worden geblokkeerd bij medium of hoog risico. Beheerders moeten controleren of alle gebruikers ten minste één MFA-methode hebben geregistreerd door de gebruikersportaal te raadplegen of door gebruikers te vragen hun MFA-status te verifiëren. Als gebruikers niet beschikken over geregistreerde MFA-methoden, moeten beheerders een uitgebreide MFA-registratiecampagne uitvoeren waarbij alle gebruikers worden gevraagd om ten minste twee authenticatiemethoden te registreren. Voor Nederlandse overheidsorganisaties is het belangrijk om app-gebaseerde of hardware-gebaseerde authenticatie te prefereren boven SMS-verificatie, in overeenstemming met de BIO-richtlijnen.

Voor hoog-risico aanmeldingen die zijn geblokkeerd, vereist remediatie een duidelijk incidentresponsproces dat begint met het verifiëren van de identiteit van de gebruiker. Als de gebruiker bevestigt dat hij of zij de aanmelding heeft geprobeerd en dat het een legitieme aanmelding was, kan het beveiligingsteam de aanmelding markeren als een valse positief en het account deblokkeren. Dit moet echter alleen worden gedaan na zorgvuldig onderzoek en verificatie van de identiteit van de gebruiker via een alternatief communicatiekanaal. Als de gebruiker ontkent de aanmelding te hebben geprobeerd, moet het beveiligingsteam het account onmiddellijk als gecompromitteerd behandelen en de standaard incidentresponsprocedures volgen. Dit omvat het resetten van wachtwoorden, het controleren van toegangslogboeken om te bepalen of er ongeautoriseerde toegang heeft plaatsgevonden, het deblokkeren van apparaten indien nodig, en het documenteren van het incident voor auditdoeleinden. Voor Nederlandse overheidsorganisaties kan dit ook leiden tot de meldplicht datalekken als er ongeautoriseerde toegang tot persoonsgegevens heeft plaatsgevonden.

Na het oplossen van een probleem is het belangrijk om te documenteren wat het probleem was, welke stappen zijn ondernomen om het op te lossen, en welke wijzigingen zijn gemaakt aan de configuratie. Deze documentatie is waardevol voor toekomstige referentie en voor het voorkomen van vergelijkbare problemen in de toekomst. Beheerders moeten ook regelmatig testen of het beleid nog steeds correct werkt door testaanmeldingen uit te voeren vanaf verschillende locaties en met verschillende risiconiveaus. Deze tests helpen bij het identificeren van configuratieproblemen voordat ze leiden tot beveiligingsincidenten of gebruikersfrustratie. Voor grote organisaties kan het handig zijn om een testaccount te maken dat specifiek wordt gebruikt voor het testen van het sign-in risicobeleid, zodat beheerders kunnen verifiëren dat het beleid correct werkt zonder echte gebruikers te beïnvloeden.

Compliance & Frameworks

• CIS M365: Control 1.33 (L2) - Zorg ervoor dat sign-in risicobeleid is ingeschakeld
• BIO: 16.01 - BIO: beveiligingsincident detectie
• ISO 27001:2022: A.8.16 - Monitoring van activiteiten en anomaliedetectie
• NIS2: Artikel - Anomaliedetectie en bedreigingsinformatie

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

Sign-in risicobeleid: Medium of hoog risico vereist meervoudige authenticatie of blokkering. Op machine learning gebaseerde anomaliedetectie: onmogelijke reispatronen, Tor-netwerken, onbekende locaties, anonieme IP-adressen. Vereist: Azure AD Premium P2 voor Identiteitsbescherming. Activatie: Identiteitsbescherming → Sign-in risicobeleid. Verplicht voor CIS 1.33, BIO 16.01, Zero Trust. Implementatie: 2-3 uur. Realtime detectie van gecompromitteerde accounts.

• Implementatietijd: 4 uur
• FTE required: 0.03 FTE