GPO: Deny Toegang Tot Deze Computer Van De Network

In vrijwel ieder forensisch onderzoek binnen de Nederlandse (semi-)overheid blijkt laterale beweging de beslissende stap waarmee aanvallers langdurig onzichtbaar blijven. Een aanvaller die de hash van een lokaal beheerdersaccount buitmaakt, hoeft slechts een willekeurig ander systeem te benaderen waarop hetzelfde wachtwoord is ingesteld om privileges te verhogen. Zonder technische remmen kan deze kettingreactie binnen minuten escaleren naar domeinbrede uitval van werkplekken, gedeelde bestanden en zelfs operationele technologie. Het afdwingen van een verbod op netwerklogons voor lokale accounts doorbreekt deze ketting, omdat de gehashte referenties simpelweg niet meer bruikbaar zijn buiten het apparaat waar zij werden verkregen. Daarmee wordt een essentieel risicoreserveringsmechanisme ingericht dat reguliere awarenessmaatregelen en procescontroles simpelweg niet kunnen leveren.

Implementatie

Deze maatregel configureert de gebruikersrechten toewijzing "Deny access to this computer from the network" zodat lokale beheerders, gastaccounts en hoogbevoegde domeingroepen geen SMB-, RDP-, WinRM- of andere netwerklogons meer kunnen starten. De accounts behouden hun mogelijkheid om lokaal beheer uit te voeren waar nodig, maar iedere poging om via het netwerk in te loggen wordt door de kernel geweigerd nog voordat authenticatie kan plaatsvinden. Daardoor stopt de aanvalsketen bij het eerste compromis en wordt de afhankelijkheid van uniforme lokale wachtwoorden sterk verminderd. In combinatie met LAPS en just-in-time administratieve processen ontstaat zo een gelaagde verdedigingslinie die zowel technische als organisatorische eisen vanuit CIS, BIO en ISO 27001 ondersteunt.

Vereisten

1. Een goed beheerd Active Directory-domein of een lokale Group Policy hiërarchie vormt de ruggengraat van deze maatregel. De beheerder moet beschikken over een actueel overzicht van Organizational Units, gekoppelde GPO's en eventuele uitzonderingscollecties voor gedeelde werkstations, ontwikkelomgevingen of OT-apparatuur. Documenteer per OU welke beleidsobjecten al bestaan, welke beveiligingsfilters of WMI-filters actief zijn en hoe de wijziging wordt getest voordat deze breder wordt vrijgegeven. Door vooraf de changekalender, CAB-goedkeuring en terugvalscenario's vast te leggen, voorkomt men dat een vergrendeling van netwerktoegang per ongeluk kritieke beheerprocessen raakt. Het is raadzaam om de beleidsaanpassing eerst in een representatieve test-OU te valideren en audit logging aan te zetten zodat elke wijziging traceerbaar blijft. Leg daarnaast vast welke beheerdersrollen de wijziging mogen uitvoeren en hoe segregatie van taken wordt afgedwongen. Veel organisaties profiteren van een dedicated staging-tenant of een afzonderlijke domeincontroller waarop nieuwe beleidsinstellingen eerst gedurende meerdere logoncycli worden beoordeeld. Door gebruik te maken van versiebeheer op de GPO-backups (bijvoorbeeld via Git) kan elke wijziging achteraf worden herleid en kunnen incomplete reviews onmiddellijk worden teruggedraaid. Deze governance-laag is noodzakelijk om audits van Algemene Rekenkamer of interne auditdiensten moeiteloos te doorstaan.
2. De eindpunten moeten Windows 10 of 11 draaien, bij voorkeur met dezelfde buildversies als de referentieconfiguratie die in het werkplekplatform is beschreven. Controleer of de laatste cumulatieve updates en benodigde beveiligingsrollups zijn geïnstalleerd, omdat inconsistenties in LSA-beleid of credential guard-instellingen onbedoelde blokkades kunnen veroorzaken. Werk samen met het werkplekteam om hardwareprofielen en service-accounts te identificeren die mogelijk alsnog netwerktoegang nodig hebben, bijvoorbeeld voor beheeragents of softwaredistributie. Deze uitzonderingen moeten uitdrukkelijk gedocumenteerd en periodiek herbeoordeeld worden, zodat zij geen sluiproutes vormen. Een geautomatiseerde configuratiecontrole via Intune, MECM of Desired State Configuration is gewenst om naadloze uitrol naar honderden apparaten te borgen. Neem de tijd om afhankelijkheden met virtualisatieplatformen, VDI-oplossingen en speciale beheertools (zoals remote assistenten of legacy distributiesoftware) in kaart te brengen. Documenteer per scenario hoe beheerders toch hun taken uitvoeren, bijvoorbeeld via privileged access workstations of gecontroleerde jump servers. Wanneer er apparatuur is die nog niet kan worden bijgewerkt naar Windows 10 of 11, leg dan vast welke compenserende maatregelen gelden, zoals netwerksegmentatie of aanvullende firewallregels. Deze uitzonderingen worden minimaal elk kwartaal herzien zodat verouderde technologie niet uitgroeit tot een blijvende kwetsbaarheid.
3. De implementatie is pas volledig wanneer het Local Administrator Password Solution (LAPS) beleid organisatiebreed is uitgerold en gecontroleerd. Unieke, automatisch geroteerde wachtwoorden per device zijn een harde randvoorwaarde omdat het blokkeren van netwerklogons anders kan leiden tot lock-outs tijdens noodherstel. Zorg dat helpdeskteams toegang hebben tot de geroteerde referenties via de beveiligde LAPS-portal of Azure AD. Combineer de technische maatregelen met processtappen: definieer hoe tijdelijke lokale accounts worden aangevraagd, hoe audits de naleving van het verbod op netwerklogons verifiëren en hoe incidentrespons-teams escaleren wanneer zij toch een afwijking constateren. Door deze combinatie van tooling, proces en mens sluit de maatregel naadloos aan op de eisen uit de Nederlandse Baseline voor Veilige Cloud. Zorg er ook voor dat het sleutelbeheer rondom LAPS is geborgd: wie heeft leesrechten op de wachtwoorden, hoe worden deze acties gelogd en hoe snel wordt toegang weer ingetrokken na functiewisselingen? Combineer de technische controles met een training voor servicedesk en field engineers zodat zij begrijpen waarom netwerklogons geblokkeerd zijn en welke stappen zij moeten volgen als een legitieme beheeractie toch via het netwerk moet plaatsvinden. Een duidelijke communicatiecampagne met infokaarten, FAQ's en een korte e-learning voorkomt dat medewerkers ongecontroleerde achterdeuren creëren om toch remote beheer uit te voeren.

Implementatie

Gebruik PowerShell-script deny-access-from-network.ps1 (functie Invoke-Implementation) – Invoke-Implementation is opgebouwd als een gecontroleerde runbook-ervaring waarin technische checks, governance-maatregelen en auditlogging elkaar versterken. De functie start met een validatie van de beheercontext: draait het script op een Privileged Access Workstation, is de operator aangemeld met een tijdgebonden rol en is er een change- of incidentnummer meegegeven? Pas als aan al deze randvoorwaarden is voldaan, wordt de volgende stap vrijgegeven. Vervolgens leest het script de gewenste doel-OU's, pilotgroepen en eventuele uitzonderingslijsten uit een versleuteld JSON-configuratiebestand zodat de uitrol exact dezelfde scope hanteert als door het hardeningsboard is goedgekeurd. De functie voert een health check uit op Active Directory-replicatie, controleert of SYSVOL recent is gesynchroniseerd en vergelijkt bestaand GPO-beleid met de gewenste instelling. Afwijkingen worden duidelijk gerapporteerd zodat beheerders bewust besluiten kunnen nemen in plaats van blind instellingen te overschrijven. Zodra de omgeving gezond is bevonden, genereert het script een nieuwe GPO of maakt het een beheerderstoegankelijke versie van het bestaande object. Alle aanpassingen worden voorzien van een RBAC-label en digitaal ondertekende logboeken die automatisch in een beveiligde SharePoint-bibliotheek of Azure Storage-account worden opgeslagen. Daarna vult het script de instelling "Deny access to this computer from the network" met de vooraf gedefinieerde SID's, valideert het dat het built-in Administrator-account niet is hernoemd en voegt het – afhankelijk van de gekozen rol – domeingroepen toe zoals Domain Admins, Enterprise Admins of tiering-specifieke managementgroepen. Elke wijziging wordt direct gecontroleerd door de policy-export opnieuw uit te lezen en te vergelijken met de gewenste JSON, zodat configuratiedrift onmogelijk onopgemerkt blijft. In de laatste fase koppelt de functie de GPO gefaseerd aan OU's: eerst pilot, daarna productie. Daarbij wordt automatisch een rapportage gegenereerd die gpresult-exports, Resultant Set of Policy-snapshots en relevante Event Viewer-logs bundelt. Het rapport bevat tevens een risicoanalyse waarin de status van LAPS, Intune compliance en Defender for Endpoint onboardingsinformatie is opgenomen. Wie het script draait, ontvangt bovendien een beknopte samenvatting via Teams of e-mail met de belangrijkste acties, de gebruikte parameter-set en een verwijzing naar het logbestand. Daarmee wordt de volledige implementatie van begin tot eind reproduceerbaar, traceerbaar en passend bij de eisen van de Nederlandse Baseline voor Veilige Cloud. Na succesvolle uitvoering schrijft het script automatisch een samenvatting weg naar zowel het centrale change management systeem als het beveiligingsdossier zodat auditors kunnen aantonen dat er vier-ogencontrole heeft plaatsgevonden. Optioneel kan een parameter worden meegegeven waarmee het script eerst een "what-if" analyse draait: daarbij wordt de GPO wel samengesteld, maar nog niet gelinkt, zodat ontwerpers het resultaat kunnen inspecteren. De logging sluit aan op het standaardformaat voor operationele beveiligingsmaatregelen binnen de Nederlandse Baseline voor Veilige Cloud, inclusief verwijzing naar het specifieke control-ID..

GPO-beheerders openen de editor en navigeren naar Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, maar volgen daarbij een uitgebreid scenario dat begint met planning. Beschrijf in het change-record welke OU-structuren geraakt worden, welke applicaties afhankelijk zijn van lokale serviceaccounts en welke fallback-mogelijkheden bestaan wanneer een apparaat zijn netwerkconnectiviteit tijdelijk verliest. Inventariseer vooraf of er nog legacy-systemen draaien die het gebruikersrecht niet ondersteunen en plan zo nodig een aparte mitigatie. Pas nadat deze analyse is vastgelegd, wordt het bestaande werkplekbeleid gedupliceerd en voorzien van een duidelijke versienaam, zodat rollback binnen minuten mogelijk is. De tweede fase bestaat uit configuratie. In de editor wordt het gebruikersrecht "Deny access to this computer from the network" geopend en gevuld met de ingebouwde SID's voor Local account en Guests, aangevuld met het ingebouwde Administrator-account en – voor werkstations – de domeingroepen Domain Admins en Enterprise Admins. Kies in het dialoogvenster "Select Users or Groups" expres voor "Object Types" zodat ook ingebouwde beveiligingsprincipals zichtbaar zijn en valideer dat hernoemde lokale Administrator-accounts via hun SID worden toegevoegd. Voor servers met speciale rollen leg je expliciet vast waarom zij wel of niet onder het beleid vallen en wijs je een einddatum toe aan elke uitzondering. Documenteer tegelijkertijd welke serviceaccounts nog afhankelijk zijn van netwerklogons en start een traject om deze te vervangen door beheerde identiteiten of gMSA's. Na configuratie volgt een intensieve validatie. Voer gpupdate /target:computer /force uit op meerdere pilotapparaten, controleer via Event Viewer (ID 1704 en 1202) dat de instelling succesvol is toegepast en exporteer met secedit /export de lokale policy om na te gaan of de SID's exact overeenkomen met de baseline. Herhaal dit proces voor een server in een beheersegment om zeker te weten dat de instelling daar niet onbedoeld wordt geactiveerd. Gebruik vervolgens PowerShell-scripts die doelbewust een netwerklogon proberen uit te voeren met een lokaal account; de poging moet leiden tot statuscode 0xC000015B in het Security-eventlog. Alle testbevindingen worden opgenomen in het implementatiedossier, inclusief screenshots, datum, gebruikte accounts en het referentienummer van de change. Pas na twee geslaagde regressietesten start de gefaseerde productie-uitrol (bijvoorbeeld 10%, 30%, 60%, 100%), waarbij elk cohort wordt gemonitord door het SOC en het werkplekteam. Tijdens elke fase ontvangt de servicedesk een briefing over mogelijke meldingen en is een terugvalvenster gereserveerd. Zodra alle fasen zijn afgerond, informeert het CISO-office de lijnorganisaties via een nieuwsbericht waarin de impact, de beheerafspraken en de contactpersonen voor escalaties worden gedeeld. Het resultaat is een uitvoerbaar proces dat technische nauwkeurigheid koppelt aan bestuurlijke transparantie.

Compliance

Deze configuratie ondersteunt gelijktijdig meerdere kaders: CIS Windows Benchmark L1 schrijft voor dat lokale accounts geen netwerklogons mogen starten, de BIO-paragraaf 09.02 benadrukt strikte toegangscontrole binnen overheidsdomeinen, en ISO 27001-controle A.9.2.3 vereist dat rechten minimaal worden toegekend. Door het beleid te formaliseren binnen de Nederlandse Baseline voor Veilige Cloud kan een organisatie aantonen dat zij systematische maatregelen neemt tegen onbevoegde systeemtoegang. Beschrijf in het compliance-dossier hoe de wijziging is goedgekeurd, hoe technische validatie plaatsvond, welke monitoring is ingericht en hoe uitzonderingen worden vastgelegd. Voeg screenshots van de GPO-instelling, exports van Resultant Set of Policy-rapporten en verwijzingen naar LAPS-beheerprocessen toe. Tijdens audits kan vervolgens eenvoudig worden aangetoond dat de maatregel niet alleen is geconfigureerd maar ook bewaakt, omdat logbestanden laten zien dat ongeautoriseerde netwerklogons worden geweigerd. Op die manier raakt de organisatie geen punten kwijt bij BIO- of ENSIA-toetsingen en kan zij richting toezichthouders duidelijk maken dat laterale beweging onder controle staat. Naast deze internationale normen sluit de maatregel aan op de Baseline Informatiebeveiliging Overheid-eisen rondom identiteits- en toegangsbeheer en ondersteunt hij de principes uit het Rijksbrede Zero Trust-beleid. Leg in de compliance-sectie uit hoe de maatregel gekoppeld is aan ENSIA-vragen, welke KPI's worden gemonitord en hoe uitzonderingen via een risicogericht besluitvormingsproces worden afgehandeld. Beschrijf bovendien hoe het driemaandelijkse assurance-proces verloopt: welke steekproeven worden uitgevoerd, welke rapporten worden gedeeld met het CISO-office en hoe bevindingen worden opgevolgd. Door deze informatie te bundelen kan een auditor direct zien dat technische instellingen, organisatorische afspraken en bewijslast elkaar versterken en dat de organisatie aantoonbaar in controle is. Verder kan de organisatie verwijzen naar de eisen uit de NIS2-richtlijn en de daarop gebaseerde Wet beveiliging netwerk- en informatiesystemen, waarin nadrukkelijk wordt gevraagd om maatregelen tegen laterale beweging en credential misuse. Maak inzichtelijk hoe het drieledige verdedigingsmodel (preventie, detectie, respons) binnen dit beleid vorm krijgt en hoe de maatregel aansluit op andere controls, zoals Credential Guard of Conditional Access. Beschrijf eveneens hoe periodieke maturity-assessments, bijvoorbeeld gebaseerd op het CSBN-kader, aantonen dat het beleid niet verslapt. Door deze aanvullingen ontstaat een volledig compliance-narratief waarin toetsers precies zien welke processen de technische instelling borgen. Vergeet tenslotte niet om vast te leggen welke bewaartermijnen gelden voor bewijsstukken. ENSIA vereist dat screenshots, exportbestanden en loguitdraaien minimaal tot de volgende audit beschikbaar blijven, terwijl de BIO in veel gevallen een bewaartermijn van zeven jaar voorschrijft. Maak duidelijk hoe deze archivering is georganiseerd (bijvoorbeeld via een SharePoint-recordscenter of een beveiligd archief in Azure Storage) en wie verantwoordelijk is voor het vrijgeven van gegevens aan toezichthouders. Een compleet compliancehoofdstuk beschrijft daarmee zowel de normatieve eisen als de praktische uitvoering, waardoor de organisatie aantoonbaar voldoet aan de Nederlandse Baseline voor Veilige Cloud. Neem deze documentatie tevens op in de jaarlijkse management review zodat directieteams expliciet bevestigen dat de maatregel actueel blijft en voldoende middelen beschikbaar zijn voor beheer en monitoring. Deze bevestiging wordt inclusief actiepunten vastgelegd in het managementverslag. Auditors waarderen deze transparantie enorm.

Monitoring

Gebruik PowerShell-script deny-access-from-network.ps1 (functie Invoke-Monitoring) – De functie invoke-monitoring binnen het script voert een dagelijkse controle uit op een representatieve set werkstations. Eerst wordt via PowerShell Remoting of Intune Management Extension een RSOP-export opgehaald en vergeleken met de verwachte waarde voor SeDenyNetworkLogonRight. Daarna wordt het eventlog Security gefilterd op 4625-fouten waarbij de Status-codes 0xC000015B of 0xC000018C aangeven dat een netwerklogon niet is toegestaan. Deze gebeurtenissen worden verrijkt met apparaatnaam, toegewezen OU, gebruiker en tijdstempel voordat zij naar het centrale SIEM worden verstuurd. Een rapportage in Microsoft Sentinel controleert of er in de afgelopen 24 uur afwijkingen zijn gevonden en genereert automatisch een incident als de policy ontbreekt of als een uitzonderingsaccount buiten de afgesproken onderhoudsperiode toch netwerktoegang kreeg. Hierdoor ontstaat een sluitende control-cyclus waarin detectie, analyse en respons maximaal vijftien minuten vragen en waarin auditors zwart-op-wit bewijs vinden dat de maatregel daadwerkelijk werkt. Documenteer de resultaten per week in het security service register zodat managementtrendanalyses kunnen aantonen dat de maatregel blijvend effect sorteert. Het monitoringproces omvat tevens een benchmark waarbij de resultaten van verschillende OU's naast elkaar worden gelegd zodat afwijkingen in adoptie snel zichtbaar worden. Het SOC publiceert een maandrapport waarin trends, aantal geweigerde netwerklogons en resterende uitzonderingen worden toegelicht. Deze rapportage vormt input voor het overleg met de Chief Information Security Officer en het werkplekplatformteam, zodat besluitvorming over nieuwe vrijstellingen of strengere blokkades op feiten is gebaseerd. Voeg waar mogelijk automatisering toe die bij herhaalde overtredingen direct een service ticket opent, inclusief instructies voor het betrekken van incidentrespons. Zo blijft de maatregel een levend onderdeel van de security operations in plaats van een eenmalige configuratie. Naast de geautomatiseerde controles wordt halfjaarlijks een red-team-achtige validatie uitgevoerd waarbij ethische hackers proberen netwerklogons met lokale accounts af te dwingen. Hun bevindingen worden vergeleken met de SIEM-rapportages om te bevestigen dat alle detecties correct afgaan. De resultaten worden gedeeld met het CIO-beraad zodat ook bestuurlijke stakeholders zicht houden op de effectiviteit van de maatregel. Door deze scherpe monitoring ontstaat een feedback loop die ervoor zorgt dat aanpassingen in het infrastructuurlandschap (bijvoorbeeld de introductie van nieuwe beheertools of cloudgebaseerde werkplekoplossingen) onmiddellijk worden meegenomen in de controlematrix. Als onderdeel van continuous improvement sluit het monitoringteam ook aan op de maandelijkse threat intelligence-briefing van het NCSC. Eventuele nieuwe tactieken waarbij aanvallers proberen netwerkblokkades te omzeilen worden vertaald naar aanvullende detectieregels. Deze updates worden binnen twee werkdagen uitgerold, waarna regressietests bevestigen dat bestaande werklast niet negatief wordt beinvloed. Dankzij deze discipline groeit de control mee met het dreigingsbeeld en blijft het vertrouwen van bestuurders en auditors hoog. Alle meetwaarden worden bovendien opgenomen in het jaarlijkse assurance-rapport voor de interne auditdienst en de Algemene Rekenkamer, zodat externe toezichthouders de effectiviteit objectief kunnen toetsen. Het gehele monitoringsproces wordt ondersteund door een RACI-matrix waarin duidelijk staat wie verantwoordelijk is voor analyses, goedkeuring en escalatie. Deze matrix wordt gedeeld met de SOC-partner en opgenomen in het service level agreement, inclusief heldere responstijden. Daardoor is het voor iedere stakeholder inzichtelijk wanneer opvolging verwacht mag worden en wie eindverantwoordelijk is voor het sluiten van incidenten. Elke wijziging in rolverdeling wordt meteen vertaald naar het SIEM-playbook zodat operators nooit hoeven te gokken wie aan zet is..

Remediatie

Gebruik PowerShell-script deny-access-from-network.ps1 (functie Invoke-Remediation) – De herstelprocedure richt zich op situaties waarin het beleid ontbreekt, onjuist is toegepast of doelbewust is verwijderd tijdens incidentrespons. Invoke-remediation vergelijkt de actuele instelling per apparaat met de referentieconfiguratie, zet ontbrekende groepen binnen enkele seconden terug en registreert in hetzelfde logbestand welke accounts zijn toegevoegd of verwijderd. Wanneer de functie constateert dat een apparaat tijdelijk van het netwerk is ontkoppeld, plant het automatisch een herstelpoging binnen twee uur en stuurt het een melding naar het werkplekteam. Op die manier worden uitzonderingen snel opgespoord zonder handmatig zoekwerk. Documenteer na afloop welke root cause is gevonden (bijvoorbeeld een vergeten masterimage of een foutieve golden profile) en laat het change team de bijbehorende procesaanpassing doorvoeren. Combineer deze remediatie met een communicatiepakket voor beheerders zodat zij weten dat lokale accounts uitsluitend via goedgekeurde jump servers netwerktoegang mogen aanvragen. Zo blijft de maatregel toekomstbestendig en sluit hij aan op de lessons learned uit eerdere penetratietesten en ransomware-incidenten. Wanneer een apparaat onbereikbaar blijft of wanneer de afwijking is ontstaan door een bewust besluit (bijvoorbeeld tijdens calamiteitenherstel), zorgt de functie voor een escalatie naar het change team inclusief automatische tijdlijn van de genomen stappen. Er wordt vastgelegd welke verantwoordelijke de uitzondering heeft goedgekeurd en welk vervalmoment geldt. Zodra de noodsituatie voorbij is, wordt het beleid automatisch opnieuw toegepast en wordt de verantwoordelijke gevraagd om schriftelijk te bevestigen dat het systeem weer onder reguliere governance valt. Dit sluit aan bij de eisen van cyberverzekeraars en de lessons learned uit recente ransomware-incidenten waarbij vergeten uitzonderingen vaak de zwakke schakel bleken. Het herstelproces eindigt altijd met een post-incident-evaluatie waarin het CISO-office nagaat of beleidsafspraken moeten worden aangescherpt. Indien blijkt dat uitzonderingen structureel nodig zijn, wordt een standaardwerkprocedure opgesteld met duidelijke einddata en alternatieve controles. Hierdoor blijft de maatregel wendbaar en tegelijkertijd aantoonbaar beheerst. Alle remediatieresultaten worden bovendien gekoppeld aan het centrale risicoregister zodat management kan zien hoe vaak deze control moet ingrijpen en of aanvullende investeringen vereist zijn. Waar nodig wordt het herstel ondersteund door runbooks voor crisisteams, zodat ook buiten kantoortijden helder is hoe de blokkade opnieuw wordt afgedwongen. Deze runbooks bevatten concrete commando's, beslisbomen voor uitzonderingen en referenties naar de verantwoordelijke functies. Door deze professionalisering is remediatie niet afhankelijk van een paar experts maar ingebed in de reguliere dienstverlening. Tijdens kwartaalreviews bespreekt het change board de verzamelde remediatierapporten om patronen te herkennen, bijvoorbeeld terugkerende installatiescripts of golden images die de instelling overschrijven. Op basis daarvan worden verbetermaatregelen geprioriteerd en eigenaarschap toegewezen. Deze regelmatige terugkoppeling maakt het herstelproces steeds efficiënter en borgt dat afwijkingen daadwerkelijk afnemen. Daarnaast worden lessons learned gedeeld binnen het security community of practice, zodat andere teams profiteren van dezelfde inzichten. Het platformteam vertaalt de structurele aanbevelingen naar backlog-items in het werkplekprogramma en koppelt de voortgang maandelijks terug. Op deze manier blijft remediatie een zichtbaar en meetbaar onderdeel van de bredere beveiligingstransformatie. De uitkomsten worden tevens gekoppeld aan ENSIA- en BIO-rapportages, waardoor bestuurders kunnen aantonen dat afwijkingen structureel worden opgelost en niet terugkeren. Het continue karakter van dit herstelprogramma houdt de gehele keten alert en maakt duidelijk dat netwerkblokkades geen vrijblijvende instelling zijn. Iedere betrokken discipline weet daardoor exact welke opvolging verwacht wordt..

Compliance & Frameworks

• CIS M365: Control Windows - Network access (L1) -
• BIO: 09.02.03 -
• ISO 27001:2022: A.9.2.3 -

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

Schakel netwerklogons voor lokale beheerders, gastaccounts en hoogbevoegde domeingroepen uit zodat pass-the-hash niet meer werkt. Controleer vooraf of LAPS overal draait, voer de wijziging via een geautomatiseerd script uit, valideer met RSOP en SIEM-rapportages en leg uitzonderingen vast. Deze inspanning kost gemiddeld vier uur maar verlaagt het risico op laterale beweging substantieel en voldoet aan de Nederlandse Baseline voor Veilige Cloud.

• Implementatietijd: 4 uur
• FTE required: 0.02 FTE