BIO 09.04 ISO A.9.4.3

Azure: Aangepaste Verboden Wachtwoordenlijst Configureren

📅 2025-10-29
•
⏱️ 4 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Een aangepaste verboden wachtwoordenlijst voorkomt dat medewerkers voorspelbare, organisatiegebonden wachtwoorden kiezen en vormt daarmee een robuuste extra laag bovenop het standaardbeleid van Microsoft. Door bedrijfsnamen, productcodes en interne acroniemen actief te blokkeren wordt password spraying een stuk minder kansrijk.

Aanbeveling
VOER EEN ORGANISATIE-SPECIFIEKE BANNED PASSWORD LIST IN
Risico zonder
Medium
Risk Score
5/10
Implementatie
2u (tech: 1u)
Van toepassing op:
✓ Azure

Hoewel Microsoft al miljoenen veelvoorkomende wachtwoorden blokkeert, blijven woorden die uniek zijn voor de organisatie onder de radar van de standaardlijst. Medewerkers gebruiken onbewust toch combinaties zoals Bedrijfsnaam2025, productnamen met seizoenen of interne projectcodes, omdat deze patronen makkelijk te onthouden zijn en toch voldoen aan complexiteitsregels. Aanvallers die LinkedIn-profielen, persberichten of aanbestedingsstukken doorspitten, kunnen deze patronen eenvoudig afleiden en inzetten bij password spraying of credential stuffing. Zeker binnen overheidsorganisaties, waar veel tijdelijke medewerkers en externe leveranciers werken, zijn deze voorspelbare woorden een terugkerende zwakke plek. Door een eigen lijst samen te stellen en centraal af te dwingen wordt dit gat gesloten, voldoet de organisatie aan de aanbevelingen uit NIST 800-63B en kan zij richting bestuurders aantonen dat wachtwoordbeleid daadwerkelijk inspeelt op actuele dreigingen.

PowerShell Modules Vereist
Primary API: Microsoft Graph
Connection: Connect-MgGraph
Required Modules: Microsoft.Graph

Implementatie

De maatregel bestaat uit het samenstellen, configureren en onderhouden van een lijst met maximaal duizend verboden termen in Azure AD Password Protection. Beheerders verzamelen organisatiegebonden woorden in samenwerking met marketing, HR en security, valideren de lijst via het vier-ogen-principe en publiceren deze in de Entra-portal. Daarna wordt de functionaliteit getest met representatieve accounts, uitgerold naar productie en gemonitord via scripts en dashboards. Het beleid geldt voor cloud- als on-premises accounts en kan desgewenst worden uitgebreid naar domeincontrollers via de on-premises agent. Door de lijst minimaal jaarlijks te herzien en nieuwe bedrijfsinitiatieven direct toe te voegen, blijft de bescherming actueel en sluit deze aan op de bredere identity governance-strategie van de organisatie.

Vereisten

Het fundament voor een effectieve aangepaste verboden wachtwoordenlijst begint met de juiste licenties en toegang tot Azure AD Password Protection. Elke tenant moet minimaal over Entra ID P1 beschikken zodat zowel cloud- als hybride accounts gebruik kunnen maken van de intelligente woordenlijsten, de geavanceerde heuristiek voor patroonherkenning en de rapportagemogelijkheden. Zonder dit licentieniveau kunnen beheerders wel lijsten voorbereiden, maar ontbreken de beleidsknoppen om het afdwingen centraal in te schakelen. Controleer daarom vooraf met licensing of procurement of de benodigde P1- of P2-sku's zijn toegekend aan alle administratieve accounts, en leg vast welke budgethouder verantwoordelijkheid draagt voor verlenging. Neem deze stap op in het change record zodat auditors kunnen nagaan dat het beleidskader binnen de financiele governance past.

Naast licenties vraagt een kwalitatief sterke lijst om betrouwbare bronnen voor de woorden die moeten worden geblokkeerd. Security officers moeten samenwerken met marketing, HR, productmanagement en lokale kantoorleiders om een compleet overzicht van bedrijfsnamen, merkvarianten, projectcodenamen en interne afkortingen te verzamelen. Verzamel deze termen nadrukkelijk in hun Nederlandse en Engelstalige schrijfwijzen, inclusief veelvoorkomende spelfouten, zodat password spraying op basis van fonetische gokpogingen ook wordt gedempt. Documenteer hoe elk woord tot de lijst is gekomen, wie de eigenaar is en welke gevoeligheid eraan vastzit. Deze provenance is essentieel om toekomstige herzieningen te structureren en om tijdens audits aan te tonen dat de organisatie doelbewust en risicogestuurd te werk gaat.

Daarnaast moeten technische randvoorwaarden op orde zijn. Zorg dat beheerders over een geisoleerde werkplek met Just-in-Time-toegang beschikken zodat configuraties niet via standaard bureaubladaccounts worden gewijzigd. Bevestig via Azure Monitor of er voldoende diagnostische logs worden opgeslagen in een Log Analytics workspace; deze data is noodzakelijk om later te controleren of de banned list correct wordt toegepast en of gebruikers foutmeldingen ontvangen. Leg in Azure Key Vault of in een beveiligde SharePoint-site vast welke versie van de lijst actief is, wie de laatste wijzigingen heeft goedgekeurd en op welke datum de productieconfiguratie is bijgewerkt. Daarmee ontstaat een gecontroleerde keten waarin security en compliance teams altijd kunnen terugvinden welke woorden in omloop zijn.

Tot slot horen er duidelijke communicatieafspraken bij de vereisten. Stel een adoptieplan op waarin wordt beschreven hoe servicedeskmedewerkers gebruikers te woord staan wanneer een wachtwoord wordt afgewezen. Voorzie change-communicatie van voorbeeldteksten zodat eindgebruikers begrijpen waarom de organisatie streng optreedt tegen voorspelbare wachtwoorden en hoe zij een sterk alternatief kunnen bedenken. Combineer dit met korte instructievideos of Microsoft Learn-modules in het Nederlands. De kwaliteit van de banned list valt of staat met de bereidheid van gebruikers om passende wachtwoorden te kiezen; goede communicatie en begeleidende materialen zijn daarom net zo belangrijk als de technische configuratie.

Een laatste vereiste is het borgen van privacy en gegevensminimalisatie. Omdat sommige termen persoonsgegevens kunnen bevatten, zoals achternamen van directieleden of interne projectnamen die herleidbaar zijn tot een gevoelig dossier, moet vooraf een Data Protection Impact Assessment worden uitgevoerd. Betrek de Functionaris Gegevensbescherming om vast te stellen hoe deze woorden worden opgeslagen, wie toegang heeft en hoe lang de ruwe inventaris bewaard blijft. Versleutel het bronbestand en pas rolgebaseerde toegangscontrole toe zodat alleen de aangewezen security officers wijzigingen mogen doorvoeren. Hierdoor blijft de organisatie conform AVG Artikel 32 werken terwijl zij toch scherp optreedt tegen voorspelbare wachtwoorden.

monitoring

Gebruik PowerShell-script custom-banned-password-list.ps1 (functie Invoke-Monitoring) – Controleren.

Doorlopende monitoring van de aangepaste verboden wachtwoordenlijst steunt op drie sporen: technische signalen, menselijke review en compliance-rapportage. Gebruik het script om elke nacht te bevestigen dat de configuratie in Entra ID ongewijzigd actief is, dat de replicatie richting on-premises domain controllers nog loopt en dat de versie van de lijst overeenkomt met het bronbestand in de beveiligde documentbibliotheek. Het script logt de hash van de actieve lijst en vergelijkt deze met de referentieversie zodat wijzigingspogingen of foutieve uploads onmiddellijk aan het licht komen. Laat de uitvoer automatisch naar een Log Analytics workspace en een Teams-kanaal van het SOC sturen, zodat afwijkingen niet in een mailbox blijven liggen. Het rapport vormt vervolgens de basis voor het dagelijkse stand-upmoment van het securityteam, waarin zij besluiten of een wijziging legitiem is of moet worden teruggedraaid. Naast de technische controles moet monitoring zich richten op gebruikerservaring en adoptie. Analyseer de Azure AD sign-in logs en zoek gericht naar errorcodes die aangeven dat een wachtwoord is geweigerd vanwege een verboden term. Combineer die data met servicedesk-tickets om te achterhalen of bepaalde afdelingen onevenredig vaak vastlopen, wat kan duiden op een onvolledige communicatiecampagne of een lijst die te agressief is samengesteld. Voeg waar nodig tijdelijke uitzonderingen toe, maar leg deze vast in een change record en stel een einddatum in zodat uitzonderingen niet permanent worden. Rapporteer wekelijks aan de CISO hoeveel blokkeringen hebben plaatsgevonden, hoeveel gebruikers ondersteuning vroegen en welke business units extra begeleiding nodig hebben. Monitoring moet tenslotte ook de effectiviteit van het beleid aantonen richting auditors en het bestuursniveau. Stel een KPI-kader op waarin minimaal drie indicatoren terugkomen: het percentage wachtwoordresets dat in eerste instantie wordt geweigerd vanwege de banned list, de tijd die nodig is om een gevonden inconsistentie op te lossen en de mate waarin nieuwe termen worden toegevoegd binnen de afgesproken reviewcyclus. Documenteer deze KPI's in het ISMS en koppel ze aan de BIO 09.04 control objective. Gebruik Microsoft Sentinel of een Power BI-dashboard om de trend over de afgelopen kwartalen te visualiseren, zodat bestuurders zien dat de maatregel daadwerkelijk bijdraagt aan het verlagen van het risico op password spraying en credential stuffing. Combineer kwantitatieve cijfers met kwalitatieve duiding: noteer welke campagnes zijn gestart, welke lessons learned uit penetratietesten voortkwamen en hoe de organisatie de lijst continu aanscherpt. Een volwassen monitoringproces laat zo duidelijk zien dat securitymaatregelen niet alleen technisch zijn ingeregeld maar ook bestuurlijk worden geborgd. Plan bovendien een halfjaarlijkse onafhankelijke review waarin Internal Audit of een externe assessor steekproeven uitvoert op de logging, het versiebeheer en de communicatie naar gebruikers. Laat hen valideren of de lijst nog steeds is afgestemd op actuele dreigingsinformatie, of alle wijzigingen tweevoudig zijn geautoriseerd en of het proces rond incidentrespons goed aansluit op andere identity governance-workflows. Leg de uitkomsten vast in het auditdossier, formuleer concrete verbetermaatregelen en koppel deze aan eigenaars met een duidelijke deadline. Door monitoring te verrijken met externe toetsing blijft het programma volwassen, transparant en aantoonbaar effectief voor zowel toezichthouders als het bestuur. Zo ontstaat een kwaliteitslus die continu bewijst dat wachtwoordbescherming geen eenmalig project is maar een geborgd proces.

Implementatie

Gebruik PowerShell-script custom-banned-password-list.ps1 (functie Invoke-Implementation) – Implementeren.

  1. Begin met een voorbereidingsworkshop waarin security, identity-beheer en vertegenwoordigers uit de business alle relevante termen verzamelen. Gebruik brainstorming, exports uit HR-systemen en marketingmateriaal om varianten van bedrijfsnaam, merk, productlijn, projecten en locaties op te sommen. Vertaal deze vervolgens naar een uniform CSV-formaat waarin kolommen zijn opgenomen voor de originele term, varianten, eigenaar en classificatie (publiek, intern of vertrouwelijk). Laat twee functionarissen de lijst valideren om fouten te voorkomen. Zodra er consensus is, sla het bestand versleuteld op in een SharePoint-bibliotheek met versiebeheer en beschrijf de placeholders voor toekomstige aanvullingen. Deze fase eindigt met een formele go/no-go waarin de CISO bevestigt dat de lijst klaar is voor configuratie en dat eventuele privacybezwaren zijn afgedekt. Leg deze afspraken vast in het ISMS zodat opvolging gegarandeerd is.
  2. Open daarna de Entra-beheerportal en navigeer naar Security > Authentication methods > Password protection. Controleer eerst de bestaande instellingen voor standaard banned passwords en zorg dat de modus niet op alleen-auditeren staat. Activeer vervolgens de optie voor aangepaste verboden wachtwoorden en plak de goedgekeurde lijst, maximaal duizend termen. Gebruik consistente scheidingstekens en controleer binnen de interface of Azure automatisch dubbele waarden verwijdert. Sla de configuratie nog niet op maar laat een tweede beheerder meelezen via een gedeeld scherm om te bevestigen dat er geen typefouten of ongewenste woorden zijn toegevoegd. Leg dit reviewmoment vast in het change ticket inclusief namen, tijdstempel en eventuele opmerkingen, zodat de auditor later kan herleiden wie welke stap heeft uitgevoerd. Deze peer review is verplicht voordat je op Save klikt, zodat het vier-ogen-principe aantoonbaar wordt gevolgd.
  3. Na publicatie moet de configuratie worden getest in een gecontroleerde omgeving. Start met een set testaccounts in een aparte groep en voer zowel succesvolle als verwachte mislukte wachtwoordwijzigingen uit. Registreer het gedrag van de portal, de foutmeldingen in Microsoft Authenticator en de gebeurtenissen in de Azure AD audit logs. Besteed speciale aandacht aan varianten: probeer bijvoorbeeld een bedrijfsnaam met cijfers, seizoensaanduidingen en speciale tekens om te bevestigen dat fuzzy matching correct werkt. Documenteer alle uitkomsten in een testverslag en voeg screenshots toe voor het auditdossier. Wanneer een test onverwachte resultaten oplevert, pas dan de lijst aan en herhaal de cyclus tot alle scenario's zijn gedekt.
  4. Sluit de implementatie af met een gecontroleerde uitrol. Informeer alle gebruikers minimaal drie dagen vooraf via e-mail, intranet en Teams zodat zij begrijpen waarom de wijziging plaatsvindt en waar zij hulp kunnen krijgen. Plan het daadwerkelijke inschakelmoment buiten kantooruren en zorg dat servicedesk en identity specialisten stand-by zijn. Nadat de instelling live staat, monitor je gedurende de eerste week elk uur de sign-in logs en servicedeskmeldingen om te bevestigen dat het beleid geen kritieke processen blokkeert. Communiceer dagelijks een korte statusupdate naar het crisisteam en koppel aan het eind van de week een lessons-learned terug naar de hele organisatie. Pas indien nodig de lijst bij op basis van nieuwe inzichten en archiveer de definitieve versie inclusief goedkeuringsmail in het ISMS. Rond de implementatie formeel af met een CAB-evaluatie waarin wordt bevestigd dat het risico is verlaagd, de documentatie volledig is bijgewerkt en er een eigenaar is aangewezen voor de periodieke herziening.

Compliance en Auditing

  1. BIO 09.04 eist dat overheidsorganisaties sterke toegangsbeveiliging hanteren voor alle vitale systemen. Een aangepaste verboden wachtwoordenlijst ondersteunt dit controlepunt door te bewijzen dat wachtwoordbeleid niet beperkt blijft tot syntactische regels, maar ook semantische risico's adresseert. Documenteer daarom per term uit de lijst welk risico wordt afgedekt en koppel dit aan het betreffende proces of informatiesysteem. Beschrijf in het ISMS hoe de lijst wordt opgesteld, wie wijzigingen autoriseert, welke logging beschikbaar is en hoe incidenten worden geescaleerd. Voeg bewijsstukken toe, zoals exports uit Azure AD waarin de instelling "custom banned passwords" zichtbaar is, change-tickets, testverslagen en trainingsmateriaal voor servicedeskmedewerkers. Tijdens audits kan zo eenvoudig worden aangetoond dat de maatregel is ontworpen, geimplementeerd en wordt onderhouden volgens de Deming-cyclus Plan-Do-Check-Act. Dit helpt om aan te tonen dat de BIO-control niet alleen op papier bestaat, maar verankerd is in processen, tooling en governance. Neem in de jaarlijkse BIO-selfassessment expliciet een vraag op over de status van de lijst en laat proceseigenaren bevestigen dat hun terminologie nog actueel is.

    Voor zowel BIO als ISO is traceerbaarheid cruciaal. Richt daarom een centraal register in waarin elke wijziging aan de lijst wordt voorzien van datum, beschrijving, autoriserende manager en gekoppeld risico. Gebruik een digitaal ondertekeningsproces om goedkeuringen te verzamelen, zodat er geen twijfel bestaat over de geldigheid van de maatregel. Leg in het register ook vast welke opleidingen medewerkers hebben gevolgd over wachtwoordbeleid en bewustwording. Deze documentatie toont aan dat de organisatie niet alleen technische instellingen beheert, maar ook investeert in kennisopbouw, wat een expliciete eis is binnen ISO 27001 Annex A. Wanneer de jaarlijkse externe audit plaatsvindt, kan dit register worden gedeeld om direct inzicht te geven in de volwassenheid van het beleid. Auditors zien daarmee dat de maatregel duurzaam is ingericht en dat afwijkingen snel worden opgevolgd.
  2. ISO 27001 A.9.4.3 benadrukt dat toegangscontroleprocedures moeten garanderen dat wachtwoorden van systemen worden beschermd tegen misbruik. Beschrijf in het Statement of Applicability dat de aangepaste lijst een compenserende maatregel vormt voor het residuele risico op credential stuffing. Leg uit hoe de maatregel samenwerkt met andere controls, zoals multi-factor authenticatie, identiteitsbewaking en privileged access management. Zorg dat interne auditors periodiek toetsen of de lijst daadwerkelijk wordt gebruikt bij alle soorten resets: selfservice, helpdesk en geautomatiseerde workflow. Bewaar logging van afgewezen wachtwoorden minimaal zeven jaar, in lijn met de bewaartermijnen van auditdossiers binnen de Nederlandse overheid. Door deze gegevens beschikbaar te houden kan de organisatie aantonen dat gebruikers zijn gewezen op alternatieve wachtwoorden en dat de maatregel daadwerkelijk effect heeft gehad. Neem tot slot in contractuele afspraken met leveranciers op dat ook hun beheerdersaccounts onder dit beleid vallen, zodat third-party risico's worden ingedamd en de scope van ISO 27001-certificering compleet blijft. Voeg aan leveranciersbeoordelingen een controlevraag toe over de aanwezigheid van een vergelijkbaar beleid om ketenrisico's te beperken.

    Verder dienen organisaties aantoonbaar te maken dat de maatregel aansluit bij AVG-verplichtingen. Wanneer persoonsnamen deel uitmaken van de lijst, moet de DPIA beschrijven waarom dit proportioneel is en welke bewaartermijnen gelden. Het combineren van informatiebeveiliging en privacy in de complianceparagraaf laat zien dat de organisatie integraal naar risico's kijkt, iets wat toezichthouders zoals de Autoriteit Persoonsgegevens nadrukkelijk verwachten. Rapporteer aan de FG hoe vaak persoonsnamen zijn toegevoegd of verwijderd en welke argumenten daaraan ten grondslag lagen. Door deze transparantie ontstaat vertrouwen dat securitymaatregelen geen ongewenste neveneffecten hebben voor de privacy van medewerkers, leveranciers of inwoners. Koppel ten slotte alle bevindingen aan het reguliere risicoregister zodat bestuurders eenvoudig kunnen zien welke mitigerende acties lopen en welke besluiten nog openstaan.

Remediatie

Gebruik PowerShell-script custom-banned-password-list.ps1 (functie Invoke-Remediation) – Het herstelproces start met het script custom-banned-password-list.ps1, dat een actuele snapshot van de configuratie ophaalt en vergelijkt met de referentielijst in de beveiligde opslag. Bij een afwijking draait het script eerst een read-only run die toont welke termen ontbreken, welke onverwacht aanwezig zijn en welke versie in productie staat. Vervolgens vraagt de workflow een formele goedkeuring aan bij de identity lead en de CISO, omdat het terugzetten van een lijst direct effect heeft op alle gebruikers. Na goedkeuring voert het script de herstelmodus uit: de goedgekeurde lijst wordt opnieuw naar Entra ID gepusht, replicatie naar on-premises agents wordt geforceerd en de logging wordt naar Log Analytics gestuurd. Parallel ontvangt de servicedesk een melding met instructies om gebruikers te informeren over de tijdelijke verstoring. Remediatie stopt echter niet bij technische terugplaatsing. Analyseer waarom de mismatch is ontstaan: was er een mislukte deployment, heeft iemand wijzigingen aangebracht buiten het changeproces of is een automatisering vastgelopen? Documenteer de root cause en leg vast welke aanvullende controles nodig zijn, zoals strengere RBAC, extra alerting of een aangepast reviewritme. Laat bovendien penetratietesters of het redteam controleren of er tijdens de verstoring misbruik is gemaakt van voorspelbare wachtwoorden. Voeg hun bevindingen toe aan het incidentrapport en bepaal of er meldplichten richting toezichthouders of ketenpartners zijn. Een effectieve herstelactie omvat ook communicatie en adoptie. Registreer in het incidentticket welke gebruikersgroepen hinder hebben ondervonden, welke foutmeldingen zij zagen en hoe lang de storing duurde. Stuur daarna een gerichte update naar dezelfde groepen waarin je toelicht dat het beleid opnieuw actief is en welke stappen zij moeten zetten wanneer ze alsnog geblokkeerd worden. Geef servicedeskmedewerkers een kort draaiboek, inclusief voorbeeldteksten en verwijzingen naar bewustwordingsmateriaal, zodat zij vragen consistent beantwoorden. Hiermee laat je zien dat securitymaatregelen niet losstaan van dienstverlening, maar elkaar versterken. Het afsluiten van de remediatie gebeurt pas wanneer drie voorwaarden zijn vervuld: de technische configuratie is hersteld en geverifieerd, de oorzaak is weggenomen en alle stakeholders zijn geinformeerd. Rond af met een CAB-bijeenkomst waarin wordt bevestigd dat alle acties zijn voltooid, dat documentatie (inclusief versiebeheer, DPIA en communicatieplannen) is bijgewerkt en dat een vervolgactie voor lessons learned is gepland. Leg deze uitkomsten vast in het ISMS en koppel ze aan het risicoregister zodat zichtbaar is hoe het resterende risico opnieuw is beoordeeld. Deze aanpak waarborgt dat herstel niet alleen een noodgreep is, maar een gecontroleerd proces dat de betrouwbaarheid van het wachtwoordbeleid versterkt. Tot slot moet elk herstelmoment worden gebruikt om de lijst te verbeteren. Plan een korte evaluatie met business-eigenaren om te bepalen of nieuwe termen moeten worden toegevoegd of juist verwijderd. Actualiseer de testscriptbibliotheek zodat toekomstige regressietests het specifieke scenario afdekken dat tot het incident heeft geleid. Voeg de belangrijkste leerpunten toe aan het security awareness-programma, bijvoorbeeld door tijdens een brown bag sessie uit te leggen hoe voorspelbare wachtwoorden zich ontwikkelen en waarom een banned list voortdurend onderhoud vergt. Zo ontstaat een feedbacklus waarbij elke remediatie het beleid slimmer maakt en de organisatie weerbaarder. Documenteer deze verbeteringen expliciet zodat opvolgers het proces moeiteloos kunnen voortzetten..

Compliance & Frameworks

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).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Custom Banned Password List .DESCRIPTION CIS Azure Foundations Benchmark - Control 1.15 Controleert custom banned password list configuratie. .NOTES Filename: custom-banned-password-list.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 CIS Control: 1.15 #> #Requires -Version 5.1 #Requires -Modules Az.Accounts [CmdletBinding()] param([Parameter()][switch]$Monitoring) $ErrorActionPreference = 'Stop' $PolicyName = "Custom Banned Password List" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null } } try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Security > Authentication methods" -ForegroundColor Gray Write-Host " - Password protection" -ForegroundColor Gray Write-Host " - Custom banned password list configured" -ForegroundColor Gray Write-Host " - Organisatie-specifieke termen toegevoegd" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Custom banned passwords" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } # ================================================================================ # Standaard Invoke-* Functions (Auto-generated) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Implementeert de configuratie #> [CmdletBinding()] param() Invoke-Remediation } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratie status #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "⚠️ Manual verification required" -ForegroundColor Yellow Write-Host "Controleer in Entra ID portal:" -ForegroundColor Gray Write-Host " - Azure AD > Security > Authentication methods" -ForegroundColor Gray Write-Host " - Password protection" -ForegroundColor Gray Write-Host " - Custom banned password list configured" -ForegroundColor Gray Write-Host " - Organisatie-specifieke termen toegevoegd" -ForegroundColor Gray } else { Write-Host "`n⚠️ Manual verification: Custom banned passwords" -ForegroundColor Yellow } } catch { Write-Error $_; exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Herstelt de configuratie naar de gewenste staat .DESCRIPTION Dit is een monitoring-only control, remediation delegeert naar monitoring #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoring-only control" -ForegroundColor Yellow Write-Host "[INFO] Running monitoring check..." -ForegroundColor Cyan Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
Medium: Zonder maatregel blijven bedrijfsnaamvarianten, projectcodes en interne acroniemen toegestaan als wachtwoord. Aanvallers die openbare bronnen scannen kunnen deze patronen eenvoudig gebruiken voor password spraying, waardoor accounts van bestuurders, leveranciers en tijdelijke medewerkers snel worden misbruikt en naleving van BIO 09.04 en NIST 800-63B in het gedrang komt.

Management Samenvatting

Voeg maximaal duizend organisatiegebonden termen toe aan Azure AD Password Protection, valideer de lijst via het vier-ogen-principe, test de blokkades met representatieve accounts en monitor dagelijks op afwijkingen. De maatregel kost enkele uren implementatietijd, vereist Entra ID P1 en levert een directe reductie op van succesvolle spraying-aanvallen.