Account Lockout Drempel Na 10 Mislukte Pogingen

Zonder account lockout kunnen aanvallers onbeperkt wachtwoorden proberen tot ze het juiste wachtwoord vinden. Brute force aanvallen proberen systematisch alle mogelijke wachtwoordcombinaties of gebruiken woordenboekaanvallen met veelvoorkomende wachtwoorden. Een lockoutdrempel beperkt het aantal pogingen en maakt brute force-aanvallen onpraktisch. De waarde van 10 pogingen biedt een redelijke balans tussen beveiliging en bruikbaarheid: veilig genoeg om brute force-aanvallen te voorkomen (10 pogingen is te weinig om systematisch wachtwoorden te raden), maar tolerant genoeg voor legitieme gebruikers die hun wachtwoord vergeten (een typfout 2-3 keer is nog steeds toegang). Een te strenge drempel (bijvoorbeeld 3) leidt tot overmatige lockouts en overbelasting van de helpdesk. Een te soepele drempel (bijvoorbeeld 50) biedt onvoldoende bescherming. 10 pogingen is het optimale punt dat door CIS en Microsoft wordt aanbevolen.

Implementatie

Deze controle configureert het Windows-beveiligingsbeleid 'Account lockout threshold' via Intune en stelt deze in op 10 mislukte inlogpogingen. Na 10 opeenvolgende mislukte inlogpogingen wordt het account automatisch geblokkeerd. De lockout wordt geconfigureerd met: LockoutBadCount is 10 (drempel), LockoutDuration is 30 minuten (hoe lang het account geblokkeerd blijft), ResetLockoutCount is 30 minuten (teller reset na succesvolle inlog). Deze waarden worden geconfigureerd via secedit in het lokale beveiligingsbeleid en gelden voor lokale Windows-accounts. Azure AD-accounts hebben afzonderlijke lockoutbeleidsregels via Azure AD Smart Lockout (automatisch ingeschakeld).

Vereisten

Voor het implementeren van account lockoutdrempel zijn verschillende technische en organisatorische voorwaarden vereist die essentieel zijn voor een succesvolle implementatie en effectieve beveiliging. Deze vereisten omvatten zowel infrastructuurcomponenten als operationele processen die nodig zijn om account lockout correct te configureren, te monitoren en te beheren.

De primaire technische vereiste is een actief Microsoft Intune-abonnement met de juiste licenties voor device management. Intune is het centrale platform waarmee account lockoutbeleidsregels worden geconfigureerd en gedistribueerd naar alle Windows-apparaten binnen de organisatie. Zonder een geldig Intune-abonnement kunnen organisaties geen centraal beheerde account lockoutbeleidsregels implementeren en zijn ze afhankelijk van lokale configuratie per apparaat, wat beheerbaarheid en consistentie aanzienlijk vermindert.

Alle Windows 10- en Windows 11-apparaten moeten zijn ingeschreven in Microsoft Intune om de account lockoutbeleidsregels te ontvangen. Apparaten die niet zijn ingeschreven, ontvangen de beleidsregels niet en blijven kwetsbaar voor brute force-aanvallen. Organisaties moeten een inventarisatie uitvoeren van alle Windows-apparaten en verifiëren dat deze correct zijn ingeschreven voordat account lockout wordt geïmplementeerd. Apparaten die via Azure AD zijn gekoppeld, ontvangen automatisch Intune-beleidsregels, terwijl hybride of on-premises apparaten mogelijk aanvullende configuratie vereisen.

Helpdeskprocedures voor het ontgrendelen van accounts zijn essentieel omdat gebruikers regelmatig hun wachtwoord vergeten of typefouten maken die tot account lockout leiden. Organisaties moeten duidelijke procedures ontwikkelen die specificeren hoe gebruikers hun account kunnen ontgrendelen. Dit kan via zelfbediening waarbij gebruikers na een bepaalde wachtperiode automatisch weer toegang krijgen, of via helpdeskondersteuning waarbij helpdeskmedewerkers accounts handmatig kunnen ontgrendelen. De procedures moeten specificeren welke informatie gebruikers moeten verstrekken om hun identiteit te verifiëren, welke autorisatieniveaus nodig zijn voor helpdeskmedewerkers om accounts te ontgrendelen, en hoe lang het duurt voordat een account automatisch wordt ontgrendeld.

Monitoring van lockoutgebeurtenissen is cruciaal voor het detecteren van brute force-aanvallen en het identificeren van beveiligingsincidenten. Organisaties moeten een monitoringoplossing implementeren die Windows Security Event Logs analyseert op Event ID 4740, wat aangeeft dat een account is geblokkeerd. De monitoring moet patronen kunnen identificeren zoals herhaalde lockouts van hetzelfde account (wat kan wijzen op een gerichte aanval), gelijktijdige lockouts van meerdere accounts (wat kan wijzen op een wachtwoordspray-aanval), of ongebruikelijke lockoutpatronen die afwijken van normaal gebruikersgedrag. Deze monitoring moet worden geïntegreerd met een Security Information and Event Management (SIEM) systeem zoals Microsoft Sentinel voor geavanceerde detectie en correlatie van beveiligingsgebeurtenissen.

Gebruikerseducatie over account lockout is belangrijk om gebruikers te helpen begrijpen waarom accounts worden geblokkeerd en hoe ze dit kunnen voorkomen. Organisaties moeten gebruikers informeren over het doel van account lockout (bescherming tegen brute force-aanvallen), wat ze moeten doen als hun account wordt geblokkeerd (wachten op automatische ontgrendeling of contact opnemen met de helpdesk), en hoe ze lockouts kunnen voorkomen (zorgvuldig wachtwoord invoeren, gebruik van wachtwoordmanagers). Deze educatie kan worden geleverd via intranetpagina's, e-mailcommunicatie, of tijdens onboarding-sessies voor nieuwe medewerkers.

Alternatieve authenticatiemethoden voor geblokkeerde accounts zijn essentieel om ervoor te zorgen dat beheerders en andere geautoriseerde personen toegang kunnen krijgen tot systemen, zelfs wanneer hun primaire account is geblokkeerd. Organisaties moeten break-glass accounts configureren die alleen worden gebruikt tijdens noodsituaties en die niet onderhevig zijn aan normale lockoutbeleidsregels. Deze accounts moeten worden beveiligd met sterke wachtwoorden en multi-factor authenticatie, en alle gebruik van deze accounts moet worden geaudit. Daarnaast moeten beheerdersaccounts worden geconfigureerd met verhoogde lockoutdrempels of uitzonderingen om te voorkomen dat beheerders worden uitgesloten tijdens kritieke beheeractiviteiten.

Een incidentresponsprocedure voor overmatige lockouts is vereist om snel te kunnen reageren op mogelijke brute force-aanvallen. Deze procedure moet specificeren wanneer lockoutgebeurtenissen als verdacht worden beschouwd (bijvoorbeeld wanneer meerdere accounts tegelijkertijd worden geblokkeerd, of wanneer een account herhaaldelijk wordt geblokkeerd binnen een korte periode), wie moet worden gecontacteerd bij verdachte activiteiten (security team, SOC, of incidentrespons team), welke stappen moeten worden ondernomen om de aanval te mitigeren (blokkeren van IP-adressen, uitschakelen van gecompromitteerde accounts, forceren van wachtwoordresets), en hoe de incidenten moeten worden gedocumenteerd voor forensisch onderzoek en compliance-doeleinden.

Implementatie

Gebruik PowerShell-script account-lockout-threshold.ps1 (functie Invoke-Remediation) – PowerShell script voor lokale configuratie van account lockoutdrempel via secedit.

Account lockout wordt geconfigureerd via Microsoft Intune, wat organisaties in staat stelt om centraal beheerde account lockoutbeleidsregels te implementeren op alle Windows-apparaten binnen de organisatie. Deze centrale aanpak zorgt voor consistentie in beveiligingsconfiguratie en vereenvoudigt het beheer van account lockoutinstellingen. De implementatie kan worden uitgevoerd via de Intune Settings Catalog, die een gebruiksvriendelijke interface biedt voor het configureren van Windows-beveiligingsbeleidsregels zonder dat er complexe scripts of Group Policy Objecten nodig zijn.

Het implementatieproces begint in het Microsoft Intune-beheercentrum, waar beheerders navigeren naar de sectie Devices en vervolgens naar Configuration profiles. Hier selecteren beheerders de optie Create om een nieuw configuratieprofiel aan te maken. Het platform moet worden ingesteld op Windows 10 en later, wat ervoor zorgt dat het beleid wordt toegepast op alle moderne Windows-versies. Het profieltype moet worden ingesteld op Settings catalog, wat toegang geeft tot een uitgebreide catalogus van Windows-beveiligingsinstellingen die kunnen worden geconfigureerd.

Het configuratieprofiel moet een duidelijke en beschrijvende naam krijgen, zoals 'Windows - Account Lockout Policy', zodat beheerders gemakkelijk kunnen identificeren welk beleid account lockout configureert. Deze naamgeving is belangrijk voor het beheer van meerdere configuratieprofielen en voor auditdoeleinden. Na het benoemen van het profiel, moeten beheerders de optie Add settings selecteren om de specifieke account lockoutinstellingen toe te voegen.

In de Settings Catalog moeten beheerders navigeren naar de categorie Local Policies Security Options en vervolgens naar de subcategorie Account Policies. Hier vinden ze de drie gerelateerde account lockoutinstellingen die allemaal moeten worden geconfigureerd voor een correct functionerend account lockoutbeleid. Het is cruciaal dat alle drie deze instellingen worden geconfigureerd, omdat Windows vereist dat ze consistent zijn ingesteld om account lockout correct te laten functioneren.

De eerste instelling die moet worden geconfigureerd is de Account lockout threshold, die moet worden ingesteld op 10 ongeldige inlogpogingen. Deze drempelwaarde bepaalt hoeveel mislukte inlogpogingen zijn toegestaan voordat een account wordt geblokkeerd. De waarde van 10 pogingen biedt een goede balans tussen beveiliging en bruikbaarheid, zoals aanbevolen door CIS en Microsoft. Een lagere waarde zou leiden tot te veel lockouts voor legitieme gebruikers, terwijl een hogere waarde onvoldoende bescherming zou bieden tegen brute force-aanvallen.

De tweede instelling is de Account lockout duration, die moet worden ingesteld op 30 minuten. Deze instelling bepaalt hoe lang een account geblokkeerd blijft nadat de lockoutdrempel is bereikt. Een duur van 30 minuten is voldoende om brute force-aanvallen te stoppen zonder legitieme gebruikers te lang te blokkeren. Het is belangrijk om te begrijpen dat een te lange lockoutduur kan leiden tot denial-of-service-risico's waarbij aanvallers opzettelijk accounts kunnen blokkeren door herhaaldelijk verkeerde wachtwoorden in te voeren. Een te korte duur biedt onvoldoende bescherming omdat aanvallers snel opnieuw kunnen proberen.

De derde instelling is de Reset account lockout counter after, die moet worden ingesteld op 30 minuten. Deze instelling bepaalt na hoeveel tijd de teller van mislukte inlogpogingen wordt gereset. Dit betekent dat als een gebruiker bijvoorbeeld 5 mislukte pogingen heeft gedaan en vervolgens 30 minuten wacht zonder verdere pogingen te doen, de teller wordt gereset en de gebruiker weer 10 pogingen heeft voordat het account wordt geblokkeerd. Deze instelling voorkomt dat gebruikers permanent worden geblokkeerd na een paar typefouten, terwijl het nog steeds bescherming biedt tegen brute force-aanvallen die continu proberen in te loggen.

Na het configureren van alle drie de instellingen, moeten beheerders het configuratieprofiel toewijzen aan alle Windows-apparaten binnen de organisatie. Dit kan worden gedaan door een groep te selecteren die alle Windows-apparaten bevat, of door het profiel toe te wijzen aan alle apparaten. Het is belangrijk om ervoor te zorgen dat het profiel wordt toegepast op alle relevante apparaten om consistentie in beveiligingsconfiguratie te waarborgen.

Na de toewijzing moeten beheerders de implementatiestatus monitoren om te verifiëren dat het beleid correct wordt toegepast op alle apparaten. De Intune-beheerconsole biedt rapportagefunctionaliteit die laat zien welke apparaten het beleid hebben ontvangen, welke apparaten het beleid nog niet hebben ontvangen, en of er fouten zijn opgetreden tijdens de implementatie. Beheerders moeten deze rapporten regelmatig controleren en eventuele problemen oplossen, zoals apparaten die niet kunnen worden bereikt of configuratiefouten die voorkomen dat het beleid wordt toegepast.

Het is belangrijk om te begrijpen dat Windows vereist dat alle drie de account lockoutinstellingen consistent zijn geconfigureerd. Als bijvoorbeeld de lockoutdrempel is ingesteld op 10 pogingen, maar de lockoutduur niet is geconfigureerd, zal account lockout niet correct functioneren. Evenzo, als de reset-teller niet is geconfigureerd, kan dit leiden tot onverwachte lockoutgedrag. Daarom moeten beheerders ervoor zorgen dat alle drie de instellingen worden geconfigureerd met consistente waarden die samen een effectief account lockoutbeleid vormen.

Monitoring

Gebruik PowerShell-script account-lockout-threshold.ps1 (functie Invoke-Monitoring) – PowerShell script voor validatie van lockoutdrempelconfiguratie.

Effectieve monitoring van account lockouts is essentieel voor zowel beveiliging als bruikbaarheid. Monitoring stelt organisaties in staat om brute force-aanvallen tijdig te detecteren, gebruikersproblemen te identificeren, en de effectiviteit van account lockoutbeleidsregels te evalueren. Zonder adequate monitoring kunnen organisaties niet bepalen of account lockout correct functioneert, of er aanvallen plaatsvinden, of gebruikers onnodig worden geblokkeerd.

De primaire bron van lockoutgebeurtenissen is het Windows Security Event Log, dat alle account lockoutgebeurtenissen registreert met Event ID 4740. Deze gebeurtenissen bevatten belangrijke informatie zoals de gebruikersnaam van het geblokkeerde account, de computernaam waarop de lockout plaatsvond, de tijdstempel van de lockout, en het IP-adres van waaruit de mislukte inlogpogingen werden gedaan. Organisaties moeten deze logboeken regelmatig analyseren om patronen te identificeren die kunnen wijzen op beveiligingsincidenten of gebruikersproblemen.

Herhaalde lockouts van hetzelfde account binnen een korte periode kunnen wijzen op een gerichte aanval waarbij een aanvaller specifiek probeert toegang te krijgen tot een bepaald account. Dit patroon is bijzonder zorgwekkend wanneer het gaat om beheerdersaccounts of accounts met verhoogde privileges, omdat deze accounts toegang geven tot gevoelige systemen en gegevens. Wanneer dergelijke patronen worden gedetecteerd, moeten beveiligingsteams onmiddellijk worden gealarmeerd via het Security Operations Center (SOC) zodat zij kunnen onderzoeken of er sprake is van een actieve aanval en passende maatregelen kunnen nemen om de aanval te stoppen.

Gelijktijdige lockouts van meerdere accounts kunnen wijzen op een wachtwoordspray-aanval, waarbij een aanvaller een klein aantal veelvoorkomende wachtwoorden probeert op een groot aantal accounts. Deze aanvalstechniek is bijzonder gevaarlijk omdat deze moeilijk te detecteren is wanneer individuele accounts worden bekeken, maar duidelijk zichtbaar wordt wanneer meerdere accounts tegelijkertijd worden geblokkeerd. Wanneer dergelijke patronen worden gedetecteerd, moet dit worden beschouwd als een kritiek beveiligingsincident dat onmiddellijke aandacht vereist. Beveiligingsteams moeten alle betrokken accounts identificeren, de bron van de aanval bepalen (zoals IP-adres of geografische locatie), en passende maatregelen nemen zoals het blokkeren van verdachte IP-adressen of het forceren van wachtwoordresets voor alle betrokken accounts.

Frequente lockouts van een enkele gebruiker kunnen wijzen op een vergeten wachtwoord of gebruikersproblemen in plaats van een beveiligingsincident. In dergelijke gevallen moeten helpdeskmedewerkers contact opnemen met de gebruiker om te helpen bij het resetten van het wachtwoord of om te verifiëren of er andere problemen zijn die de lockouts veroorzaken. Helpdeskmedewerkers moeten worden getraind om onderscheid te maken tussen legitieme gebruikersproblemen en mogelijke beveiligingsincidenten, zodat zij de juiste escalatie kunnen uitvoeren wanneer dat nodig is.

Analyse van lockoutpatronen moet verschillende dimensies omvatten om volledig inzicht te krijgen in de aard van lockoutgebeurtenissen. Tijdstempelanalyse kan onthullen of lockouts plaatsvinden tijdens normale kantooruren (wat kan wijzen op gebruikersproblemen) of buiten kantooruren (wat kan wijzen op aanvallen). Geografische locatieanalyse kan onthullen of lockouts afkomstig zijn van bekende locaties (zoals kantoren) of van onbekende locaties (wat kan wijzen op gecompromitteerde accounts of aanvallen). IP-adresanalyse kan onthullen of lockouts afkomstig zijn van bekende IP-adressen of van verdachte bronnen. Deze analyses helpen beveiligingsteams om onderscheid te maken tussen legitieme gebruikersactiviteiten en mogelijke beveiligingsincidenten.

Integratie met een Security Information and Event Management (SIEM) systeem zoals Microsoft Sentinel is essentieel voor geavanceerde detectie van lockoutpatronen en correlatie met andere beveiligingsgebeurtenissen. SIEM-systemen kunnen complexe queries uitvoeren die lockoutgebeurtenissen analyseren op basis van verschillende criteria, zoals het aantal lockouts per account, het aantal lockouts per tijdseenheid, of het aantal lockouts per IP-adres. Een voorbeeld van een nuttige query is: SecurityEvent | waar EventID == 4740 | summarize count() door Account, Computer. Deze query groepeert lockoutgebeurtenissen per account en computer, waardoor beveiligingsteams gemakkelijk kunnen identificeren welke accounts het meest worden getroffen door lockouts en of er patronen zijn die wijzen op aanvallen.

Helpdeskmetrieken zoals het aantal unlock-verzoeken per week kunnen helpen bij het identificeren van trends en het bepalen van baseline-niveaus voor normale activiteit. Wanneer het aantal unlock-verzoeken significant afwijkt van het baseline-niveau, kan dit wijzen op een aanval of op problemen met account lockoutconfiguratie. Helpdeskmedewerkers moeten deze metrieken regelmatig monitoren en escaleren wanneer er significante afwijkingen worden gedetecteerd. Deze metrieken kunnen ook worden gebruikt om de effectiviteit van gebruikerseducatie te evalueren, omdat een afname van unlock-verzoeken na educatiecampagnes kan wijzen op verbeterde gebruikersbewustzijn.

Remediatie

Gebruik PowerShell-script account-lockout-threshold.ps1 (functie Invoke-Remediation) – Herstellen van account lockoutconfiguratie.

Remediatie van account lockouts omvat zowel het ontgrendelen van accounts voor legitieme gebruikers als het reageren op mogelijke beveiligingsincidenten. Organisaties moeten duidelijke procedures ontwikkelen die specificeren hoe verschillende soorten lockouts moeten worden behandeld, afhankelijk van de context en de omstandigheden. Deze procedures moeten onderscheid maken tussen lockouts veroorzaakt door gebruikersfouten en lockouts die mogelijk wijzen op beveiligingsaanvallen.

Voor individuele lockouts die waarschijnlijk worden veroorzaakt door gebruikersfouten, zoals wanneer een gebruiker zijn wachtwoord verkeerd intypt of zijn wachtwoord is vergeten, zijn er verschillende opties voor het ontgrendelen van het account. De eenvoudigste optie is om te wachten tot de automatische ontgrendeling plaatsvindt na de geconfigureerde lockoutduur, die standaard 30 minuten is. Deze aanpak vereist geen interventie van beheerders of helpdeskmedewerkers en is geschikt voor situaties waarin de gebruiker kan wachten tot het account automatisch wordt ontgrendeld.

Wanneer onmiddellijke toegang vereist is, kunnen helpdeskmedewerkers het account handmatig ontgrendelen. Voor Active Directory-accounts kan dit worden gedaan via de opdrachtregel met behulp van de opdracht: net user USERNAME /active:yes /domain. Deze opdracht moet worden uitgevoerd met beheerdersrechten op een domain controller of vanaf een computer met geïnstalleerde Remote Server Administration Tools (RSAT). Helpdeskmedewerkers moeten de identiteit van de gebruiker verifiëren voordat zij een account ontgrendelen om te voorkomen dat aanvallers toegang krijgen tot accounts door zich voor te doen als legitieme gebruikers.

Voor lokale accounts op Windows-apparaten kunnen beheerders het account ontgrendelen via Computer Management. Dit wordt gedaan door te navigeren naar Computer Management, vervolgens naar Local Users and Groups, en dan naar Users. Hier kunnen beheerders het geblokkeerde account selecteren, de eigenschappen openen, en het vinkje verwijderen bij 'Account is locked out' om het account te ontgrendelen. Deze methode is alleen beschikbaar voor lokale accounts en vereist lokale beheerdersrechten op het apparaat.

Wanneer meerdere accounts tegelijkertijd worden geblokkeerd, of wanneer een account herhaaldelijk wordt geblokkeerd binnen een korte periode, moet dit worden beschouwd als een mogelijk beveiligingsincident dat een meer uitgebreide respons vereist. In dergelijke situaties moeten beveiligingsteams onmiddellijk worden gealarmeerd en moeten er stappen worden ondernomen om de mogelijke aanval te mitigeren en te voorkomen dat aanvallers toegang krijgen tot systemen.

De eerste stap bij het reageren op mogelijke aanvallen is het isoleren van getroffen apparaten van het netwerk. Dit voorkomt dat gecompromitteerde apparaten worden gebruikt om verdere aanvallen uit te voeren of om toegang te krijgen tot andere systemen op het netwerk. Apparaten kunnen worden geïsoleerd door ze fysiek los te koppelen van het netwerk, door netwerktoegang te blokkeren via netwerkapparatuur zoals switches of firewalls, of door de netwerkadapter uit te schakelen via Intune of andere beheertools.

De tweede stap is het analyseren van Windows Security Logs om aanvalspatronen te identificeren. Deze analyse moet informatie bevatten over het IP-adres van waaruit de mislukte inlogpogingen werden gedaan, de gebruikersaccounts die het doelwit waren van de aanvallen, en de tijdstempels van de aanvallen om patronen te identificeren. Deze informatie is essentieel voor het begrijpen van de aard van de aanval en voor het nemen van passende maatregelen om de aanval te stoppen.

Na het identificeren van de bron van de aanval, moeten beveiligingsteams stappen ondernemen om de aanvaller te blokkeren. Dit kan worden gedaan door firewallregels te configureren die toegang blokkeren vanaf het IP-adres van de aanvaller, door het IP-adres toe te voegen aan een blacklist, of door het gecompromitteerde account uit te schakelen als er aanwijzingen zijn dat het account is gecompromitteerd. Deze maatregelen helpen voorkomen dat de aanvaller verdere pogingen kan doen om toegang te krijgen tot systemen.

Getroffen accounts moeten worden gedwongen om hun wachtwoord te resetten, omdat er mogelijk sprake is van gelekt wachtwoord of gecompromitteerde credentials. Dit kan worden gedaan via Active Directory Users and Computers voor domain accounts, of via Intune voor cloud accounts. Gebruikers moeten worden geïnformeerd over de noodzaak van een wachtwoordreset en moeten worden geadviseerd om een sterk, uniek wachtwoord te kiezen dat niet eerder is gebruikt. In sommige gevallen kan het ook nodig zijn om multi-factor authenticatie te vereisen voor getroffen accounts om extra beveiliging te bieden.

Beveiligingsincidenten moeten worden geëscaleerd naar het beveiligingsteam voor incidentrespons. Het beveiligingsteam kan een diepgaandere analyse uitvoeren van de aanval, forensisch onderzoek uitvoeren om te bepalen of er daadwerkelijk toegang is verkregen tot systemen, en aanvullende maatregelen nemen om te voorkomen dat vergelijkbare aanvallen in de toekomst plaatsvinden. Alle stappen die worden ondernomen tijdens de incidentrespons moeten worden gedocumenteerd voor compliance-doeleinden en voor het leren van lessen voor toekomstige incidenten.

Na een beveiligingsincident moeten organisaties hun wachtwoordbeleidsregels evalueren en versterken indien er aanwijzingen zijn dat zwakke wachtwoorden hebben bijgedragen aan de aanval. Dit kan het verhogen van de minimale wachtwoordlengte omvatten, het vereisen van complexere wachtwoorden, het implementeren van wachtwoordverbodenlijsten die voorkomen dat gebruikers veelvoorkomende of gecompromitteerde wachtwoorden gebruiken, of het vereisen van regelmatige wachtwoordwijzigingen. Deze maatregelen helpen voorkomen dat toekomstige aanvallen succesvol zijn door het moeilijker te maken voor aanvallers om wachtwoorden te raden of te kraken.

Compliance en Auditing

Account lockoutdrempel is een essentiële beveiligingsmaatregel die bijdraagt aan naleving van verschillende beveiligingsframeworks en regelgevingsvereisten die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. Deze maatregel helpt organisaties te voldoen aan vereisten voor bescherming tegen brute force-aanvallen, authenticatiebeveiliging, en accountbeveiliging zoals gespecificeerd in internationale standaarden en Nederlandse wetgeving. Zonder account lockout kunnen organisaties niet volledig voldoen aan de vereisten van frameworks zoals CIS Benchmark, BIO-baseline, ISO 27001, NIS2, en NIST.

De CIS Benchmark voor Microsoft Intune en Windows bevat specifieke controles voor account lockoutdrempel die vereisen dat organisaties account lockout configureren met een drempelwaarde tussen 5 en 10 mislukte inlogpogingen. Deze controle is geclassificeerd als Level 1, wat betekent dat deze wordt aanbevolen voor alle organisaties. De controle specificeert dat account lockout moet worden geconfigureerd om brute force-aanvallen te voorkomen en dat de drempelwaarde moet worden afgestemd op de beveiligingsvereisten van de organisatie. Voor de meeste organisaties wordt een drempelwaarde van 10 pogingen aanbevolen als een goede balans tussen beveiliging en bruikbaarheid. Het niet implementeren van account lockout resulteert in een mislukte auditbevinding voor deze controle, wat kan leiden tot compliance-problemen bij klanten of partners die CIS-compliance vereisen.

De Baseline Informatiebeveiliging Overheid (BIO) specificeert in Thema 09.04.03 dat organisaties maatregelen moeten implementeren om bescherming te bieden tegen brute force-aanvallen op authenticatie-informatie. Deze maatregel omvat het gebruik van account lockoutmechanismen die accounts automatisch blokkeren na een bepaald aantal mislukte inlogpogingen. Voor Nederlandse overheidsorganisaties is de BIO-baseline verplicht, en het niet voldoen aan deze vereisten kan leiden tot beveiligingsincidenten en compliance-problemen. Account lockoutdrempel van 10 pogingen helpt overheidsorganisaties te voldoen aan BIO-vereisten door effectieve bescherming te bieden tegen brute force-aanvallen op lokale Windows-accounts.

ISO 27001:2022 controle A.5.17 richt zich op authenticatie-informatie en vereist dat organisaties account lockoutmechanismen implementeren om te voorkomen dat aanvallers onbeperkt wachtwoorden kunnen proberen. Deze controle vereist dat organisaties een beleid implementeren dat accounts blokkeert na een bepaald aantal mislukte authenticatiepogingen, en dat dit beleid wordt gehandhaafd en gemonitord. Account lockoutdrempel van 10 pogingen stelt organisaties in staat om te voldoen aan deze vereisten door automatische accountblokkering te implementeren na mislukte inlogpogingen. Organisaties moeten kunnen aantonen dat account lockout correct is geconfigureerd, dat lockoutgebeurtenissen worden gemonitord, en dat er procedures zijn voor het ontgrendelen van accounts wanneer dat nodig is.

De NIS2-richtlijn, die in Nederland is geïmplementeerd via de Wet beveiliging netwerk- en informatiesystemen, vereist in Artikel 21 dat essentiële en belangrijke entiteiten passende maatregelen implementeren voor cybersecurity-risicobeheer, inclusief bescherming tegen brute force-aanvallen. Deze vereiste is met name relevant voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg, en financiële dienstverlening. Artikel 21 specificeert dat organisaties moeten kunnen aantonen dat ze maatregelen hebben geïmplementeerd om brute force-aanvallen te voorkomen en te detecteren. Account lockoutdrempel is een essentiële maatregel die helpt organisaties te voldoen aan deze vereisten door automatische accountblokkering te implementeren na mislukte inlogpogingen. Het niet implementeren van account lockout kan resulteren in niet-naleving van NIS2-vereisten, wat kan leiden tot boetes en andere handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM) of andere toezichthouders.

NIST Special Publication 800-63B bevat aanbevelingen voor digitale identiteitsrichtlijnen en specificeert dat organisaties account lockoutmechanismen moeten implementeren om brute force-aanvallen te voorkomen. De publicatie raadt aan dat organisaties een lockoutdrempel configureren die voldoende bescherming biedt tegen brute force-aanvallen zonder legitieme gebruikers onnodig te blokkeren. Een drempelwaarde van 10 pogingen wordt aanbevolen als een goede balans tussen beveiliging en bruikbaarheid. Organisaties die NIST-richtlijnen volgen, moeten account lockout implementeren en kunnen aantonen dat de configuratie voldoet aan NIST-aanbevelingen.

Account lockout is algemeen erkend als een best practice voor het voorkomen van brute force-aanvallen en wordt aanbevolen door beveiligingsexperts, standaardisatieorganisaties, en regelgevingsinstanties wereldwijd. Deze erkenning komt voort uit het feit dat account lockout een effectieve en relatief eenvoudige maatregel is die aanzienlijke beveiligingsvoordelen biedt zonder complexe implementatie of hoge kosten. Organisaties die account lockout implementeren, kunnen aantonen dat ze proactieve maatregelen hebben genomen om hun systemen te beschermen tegen brute force-aanvallen, wat belangrijk is voor compliance-doeleinden en voor het aantonen van due diligence bij beveiligingsincidenten.

Voor auditdoeleinden moeten organisaties kunnen aantonen dat account lockout correct is geconfigureerd en wordt beheerd. Dit omvat het documenteren van de lockoutconfiguratie (drempelwaarde, duur, reset-teller), het bijhouden van lockoutgebeurtenissen via Windows Security Event Logs, het implementeren van monitoring en alerting voor lockoutgebeurtenissen, en het hebben van procedures voor het ontgrendelen van accounts wanneer dat nodig is. Deze documentatie is essentieel voor het succesvol doorstaan van compliance-audits en voor het aantonen van due diligence bij beveiligingsincidenten. Organisaties moeten ook kunnen aantonen dat account lockout regelmatig wordt geëvalueerd en bijgewerkt om ervoor te zorgen dat het effectief blijft tegen nieuwe aanvalstechnieken.

Compliance & Frameworks

• CIS M365: Control Intune-Account-Lockout (L1) - Account lockout threshold moet geconfigureerd zijn (5-10 pogingen)
• BIO: 09.04.03 - BIO Baseline Informatiebeveiliging Overheid - Thema 09: Bescherming tegen brute force aanvallen
• ISO 27001:2022: A.5.17 - Authentication information - Account lockout mechanisms
• NIS2: Artikel - Brute force bescherming via account lockout

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

Configureer account lockout na 10 mislukte inlogpogingen. Lockoutduur: 30 minuten. Voorkomt brute force-aanvallen op lokale Windows-accounts. Monitor lockoutgebeurtenissen voor aanvalsdetectie. Voldoet aan BIO 09.04, ISO 27001 A.5.17, CIS. Implementatie: 1-2 uur inclusief helpdeskprocedures.

• Implementatietijd: 2 uur
• FTE required: 0.02 FTE