Security Audit Loggen Size

De Nederlandse Baseline voor Veilige Cloud vraagt om verifieerbare bewijslast richting auditors, toezichthouders en ketenpartners. Een degelijk geconfigureerde loggrootte ondersteunt dat door langdurige, onveranderde registraties te bewaren. Daarmee kunnen forensische onderzoeken weken later nog steeds herleidbare chronologieën reconstrueren, wat essentieel is voor BIO-paragraaf 16.01 en AVG-verantwoordingsplichten.

Implementatie

De instelling configureert via Microsoft Intune het Windows-register zodat de beveiligingslogboeken minimaal 196608 kilobyte opslag hebben, afgestemd op de capaciteit van moderne SSD’s. Het beleid wordt als apparaatconfiguratieprofiel uitgerold, gecontroleerd via het PowerShell-script security-audit-log-size.ps1 en gekoppeld aan compliance-rapportages, zodat elke afwijking direct zichtbaar is voor het SOC.

Vereisten

Het configureren van een dwingend logbeleid vergt meer dan enkel een technisch vinkje in het Intune-portaal. Vooraf moeten alle betrokken partijen—van de CISO tot de werkplekbeheerder—overeenstemming bereiken over de precieze doelstellingen: hoeveel dagen logdata is minimaal nodig, welke ketenpartners mogen loggegevens inzien en hoe sluiten we aan op bestaande SIEM-oplossingen binnen de rijksoverheid. Deze besluitvorming vereist actuele dreigingsinformatie van het NCSC, inschattingen uit de BIO-risicoanalyse en een helder begrip van de opslagcapaciteit op de endpoints in de verschillende doelgroepen zoals laptops voor mobiele inspecteurs en vaste werkstations binnen datacenters. Naast bestuurlijke afstemming spelen technische vereisten een grote rol. De Intune-beheerder heeft het Microsoft Graph DeviceManagement-modulepakket nodig en moet beschikken over de juiste RBAC-rollen, bij voorkeur Intune Service Administrator, om configuratieprofielen te publiceren en compliancebeleid aan te passen. Werkstationbeheerders dienen Windows 10 22H2 of Windows 11 23H2 als minimale build te hanteren, inclusief de laatste cumulatieve updates, zodat de registerinstelling HKLM\System\CurrentControlSet\Services\Eventlog\Security consistent wordt toegepast. Ook moet gecontroleerd worden of lokale hardening, bijvoorbeeld verouderde SCCM-taken, dezelfde sleutel niet overschrijft. Verder is het noodzakelijk om een representatieve pilotgroep te hebben die het beleid gedurende minimaal twee wijzigingsvensters ontvangt. Binnen deze groep moet het monitoringteam het PowerShell-script security-audit-log-size.ps1 kunnen uitvoeren via lokale debug-instellingen, conform de projectafspraak om scripts eerst lokaal te testen. Hiervoor is PowerShell 7, het Microsoft.Graph PowerShell SDK en toegang tot het tenant service-account nodig. Logging van deze testresultaten wordt centraal gedeeld via het projectsharepoint zodat auditsporen van de pilot beschikbaar blijven. Tot slot moeten ondersteunende processen klaarstaan: het gegevensbeschermingsteam dient vooraf een gegevensregister bij te werken, omdat grotere logboeken potentieel meer persoonsgegevens bevatten. De opslagbeheerders moeten verifiëren dat BitLocker-geëncrypteerde schijven voldoende vrije ruimte houden, zodat een vergrote loggrootte niet tot productiviteitsverlies leidt. Wanneer al deze organisatorische en technische voorwaarden zijn ingevuld, kan het beleid veilig en herhaalbaar uitgerold worden. Ook de medewerkers die loggegevens analyseren hebben specifieke competenties nodig. Plan daarom verplichte trainingssessies waarin SOC-analisten leren hoe ze de grotere logboeken efficiënt doorzoeken, bijvoorbeeld via Kusto Query Language-templates. De lessons learned uit deze trainingen worden gedeeld in de projectwiki, zodat toekomstige teams exact weten welke valkuilen zijn ontdekt. Met deze combinatie van governance, tooling, vaardigheden en documentatie ontstaat een volwassen fundament waarop de verdere implementatie kan steunen. Omdat de maatregel invloed heeft op opslagverbruik en netwerkbelasting, hoort er een financieel kader bij. De CIO-office reserveert budget voor eventuele SSD-uitbreidingen, licentie-uitbreidingen binnen Microsoft Graph en extra Log Analytics-capaciteit. Contractmanagers toetsen bovendien of externe leveranciers, zoals werkplekuitvoerders, contractueel verplicht kunnen worden dezelfde loggrootte-afspraken te volgen. Deze financiële en contractuele voorbereiding voorkomt dat de maatregel strandt op resourcebeperkingen zodra de uitrol daadwerkelijk begint. Tot slot is er een communicatiecomponent: elke directie ontvangt een startpakket met een managementsamenvatting, een planning en een lijst met contactpersonen. Dit pakket wordt besproken in het reguliere securityoverleg zodat leidinggevenden precies weten wat er van hen verwacht wordt en welke escalatiepaden beschikbaar zijn. Door deze stakeholders vanaf dag één te betrekken, blijft het draagvlak hoog en kan de organisatie sneller reageren wanneer aanvullende eisen vanuit bijvoorbeeld de Algemene Rekenkamer opduiken.

Implementatie

Gebruik PowerShell-script security-audit-log-size.ps1 (functie Invoke-Monitoring) – Monitoren.

De implementatie start met het beoordelen van de bestaande configuratie in de tenant. Gebruik Microsoft Graph om huidige Device Configuration-profielen te inventariseren en noteer welke groepen reeds een auditinstelling hebben. Daarna wordt een nieuw Windows 10 en later-catalogusprofiel aangemaakt waarin de instelling "Maximum Security Log Size" wordt vastgelegd op minimaal 196608 KB. In de beschrijving van het profiel staat expliciet dat dit beleid onderdeel vormt van de Nederlandse Baseline voor Veilige Cloud, zodat elke beheerder direct begrijpt dat wijziging alleen via het changeproces mag plaatsvinden. Nadat het profiel gereed is, koppel je het aan dynamische Azure AD-groepen die werkstations bevatten. Gebruik duidelijke naamgevingsconventies zoals CFG-WIN-SecurityLogSize en vermijd overlap met andere profielen door prioriteit en scope tags te controleren. Test vervolgens het aangeleverde PowerShell-script lokaal met debugparameters zodat zichtbaar wordt welke registrywaarden worden gelezen en geschreven. Het script gebruikt Get-MgDeviceManagementScript en schrijft resultaten weg naar het logboek. Controleer met Test-Path en Get-ItemProperty of de sleutel daadwerkelijk de gewenste waarde bevat. Communiceer de wijziging via het verandermanagementproces: licht de service desk in, werk het kennisartikel bij en informeer het SOC dat een toename in loggrootte tijdelijk meer data kan genereren. Tijdens de eerste uitrolfase worden slechts honderd apparaten aangestuurd; zodra de rapportage na achtenveertig uur geen foutmeldingen toont, volgt de uitrol naar alle productieapparaten. Documenteer ieder besluit in het changelog, inclusief datum, verantwoordelijke en referentie naar dit artikel. Zo blijft de audittrail integer en kunnen auditors achteraf eenvoudig vaststellen waarom juist deze waarde gekozen is. Parallel daaraan wordt een fallback-scenario ingericht voor apparaten die tijdelijk offline zijn. Via een compliance-script in Endpoint Analytics wordt de laatste succesvolle synchronisatietijd vastgelegd. Als een apparaat drie cycli mist, ontvangt de eigenaar automatisch een bericht met instructies om verbinding te maken via VPN, zodat het beleid alsnog wordt toegepast. De projectleider houdt een implementatiedashboard bij waarin per organisatieonderdeel zichtbaar is hoeveel systemen compliant zijn, welke nog in behandeling zijn en waar extra ondersteuning nodig is. Zodra de doelwaarde van 98 procent is bereikt, wordt het project formeel overgedragen aan de beheerorganisatie met een gedetailleerd overdrachtsdossier. Een aanvullende succesfactor is geautomatiseerd testen. Iedere wijziging in het script of profiel triggert een pipeline in Azure DevOps die statische code-analyse uitvoert, het script draait tegen een gesimuleerde registry en de resultaten archiveert. Pas na een geslaagde pipeline mag de beheerder de wijziging signeren met zijn PIV-kaart. Daarnaast wordt een rollback-plan uitgewerkt waarin beschreven staat hoe de loggrootte tijdelijk kan worden teruggezet als kritieke applicaties onverwacht problemen ervaren. Dit plan is vooraf goedgekeurd door de change manager en bevat duidelijke communicatiescripts voor eindgebruikers en incidentmanagers. Tot besluit wordt er een eindvalidatie uitgevoerd waarin technische en organisatorische criteria samenkomen. Het projectteam organiseert een go-live review met vertegenwoordigers van security, operations, juridische zaken en communicatie. In deze sessie worden de resultaten van de pilot, de uitkomsten van de DevOps-pipeline en de feedback van eindgebruikers besproken. Pas na expliciete goedkeuring van alle stakeholders wordt het beleid als verplicht bestempeld en verplaatst naar de reguliere beheerstraat. Daarna volgt een nazorgperiode van vier weken waarin het implementatieteam verhoogde monitoring activeert en dagelijks de dashboards bekijkt. Eventuele afwijkingen worden niet alleen hersteld, maar ook geanalyseerd op patronen zodat verbeteringen snel kunnen worden teruggevoerd naar het configuratieprofiel.

monitoring

Gebruik PowerShell-script security-audit-log-size.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring van de loggrootte vereist een combinatie van geautomatiseerde controles en situationeel bewustzijn. Het PowerShell-script draait volgens het schema dat binnen Intune Device Health is geconfigureerd en schrijft iedere run naar een centrale Log Analytics workspace. Hierin wordt vastgelegd welk apparaat, welke gebruiker en welke registrywaarde is aangetroffen. Wanneer de waarde afwijkt van de drempel, wordt via Microsoft Sentinel een alert gegenereerd dat automatisch naar het SOC wordt gerouteerd. Deze koppeling zorgt ervoor dat afwijkingen niet langer verborgen blijven in lokale eventlogs. Naast techniek is er procesmatige borging nodig. Het monitoringteam bekijkt wekelijks een rapport waarin compliancepercentages per organisatieonderdeel staan. Indien een bepaalde afdeling, bijvoorbeeld Inspectie Leefomgeving, achterblijft, dan wordt een doelgerichte follow-up gepland met hun lokale beheerder. Tijdens kwartaalreviews worden de trends geanalyseerd op basis van seizoensinvloeden, zoals piekbelasting tijdens fiscale rapportages, zodat men kan anticiperen op een verhoogde logproductie. Om de betrouwbaarheid van monitoring te garanderen, voert het team regelmatig een controle uit op de eigen meetinstrumenten. Dat betekent dat de Log Analytics-retentie wordt afgestemd op de bewaartermijnen van de BIO en dat de service principal die toegang verleent een nieuw certificaat krijgt voordat het oude verloopt. Verder wordt nagegaan of nieuwe Windows-builds veranderingen introduceren in de registry-structuur. Zodra Microsoft een wijziging publiceert, wordt het script aangepast en opnieuw getest met de lokale debuginstellingen, geheel volgens de projectregel dat scripts niet ongetest naar productie gaan. Door monitoring stevig te verankeren in zowel tooling als overlegstructuren, kan het SOC gericht beoordelen of de auditlogboeken voldoende capaciteit hebben om verdachte activiteiten vast te leggen. Het resultaat is een voorspelbare, aantoonbare beheersing van logboekgroottes, essentieel voor forensische continuïteit en voor het vertrouwen van bestuurders die verantwoording afleggen aan toezichthouders. Bovendien worden concrete prestatie-indicatoren afgesproken met het bestuur: het percentage apparaten dat gedurende vier weken onafgebroken compliant blijft, het aantal kritieke alerts per maand en de gemiddelde oplostijd na detectie. Deze KPI’s worden besproken in het Security Governance Overleg en vormen input voor de kwartaalrapportage richting de CIO-Rijk. Door monitoringgegevens ook te koppelen aan capacity-management ontstaat inzicht in de groei van opslaggebruik, waardoor tijdig kan worden opgeschaald voordat logboeken opnieuw risico lopen te worden overschreven. Als sluitstuk worden scenario-oefeningen georganiseerd waarbij het monitoringteam samen met het SOC simuleert dat loggrootten plotseling krimpen, bijvoorbeeld door een foutieve groepspolicy. Tijdens deze tabletop-sessies wordt getest of dashboards, escalatiepaden en communicatieboodschappen daadwerkelijk werken. De lessons learned worden direct vertaald in verbeterde runbooks en waar nodig aanvullende automatisering. Het team besteedt daarnaast aandacht aan kennisborging. Nieuwe analisten lopen een mentorschapstraject waarin zij metingen leren interpreteren, hypotheses formuleren en escalaties onderbouwen richting het crisismanagementteam. Deze investering in mensen zorgt ervoor dat monitoring niet afhankelijk is van enkele specialisten maar breed in de organisatie is verankerd. Tot slot wordt een maandelijkse lessons-learned-sessie georganiseerd waarbij monitoringresultaten naast actuele dreigingsinformatie van het NCSC worden gelegd. Hierdoor kan de organisatie anticiperen op nieuwe aanvalspatronen en tijdig besluiten of de loggrootte-parameters moeten worden verhoogd. De uitkomsten van deze sessies worden vertaald naar concrete optimalisaties in het Intune-profiel, zodat monitoring en implementatie elkaar versterken en de cyclus van continue verbetering sluitend blijft.

Remediatie

Gebruik PowerShell-script security-audit-log-size.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring een afwijking detecteert, treedt het remediatieproces direct in werking. Het Invoke-Remediation-gedeelte van het script controleert of de registrywaarde herschreven kan worden zonder dat het systeem een herstart nodig heeft. In de meeste gevallen wordt de nieuwe waarde onmiddellijk toegepast en registreert het script het resultaat in dezelfde Log Analytics workspace. Lukt dat niet omdat bijvoorbeeld een legacy-GPO de instelling overschrijft, dan opent het systeem automatisch een ticket in het ITSM-platform met alle relevante context zodat een beheerder binnen de afgesproken twee werkdagen kan handelen. Het functionele eigenaarschap blijft bij de CISO-office; zij beoordelen of een afwijking incidenteel of structureel is. Bij structurele problemen, zoals een regionale werklocatie waar laptops buiten Intune om opnieuw worden geïmageerd, wordt een verbeterplan opgesteld. Dat plan bevat een root-causeanalyse, corrigerende maatregelen en aanvullende controles, allemaal afgestemd op de Nederlandse Baseline voor Veilige Cloud. Zo ontstaat een aantoonbare PDCA-cyclus waarin niet alleen de technische fout wordt hersteld, maar ook de achterliggende oorzaak wordt aangepakt. Daarnaast is communicatie met eindgebruikers belangrijk. Wanneer een systeem vanwege remedie-actie meer opslag claimt en daardoor tijdelijk minder schijfruimte vrij heeft, ontvangen gebruikers een bericht waarin het doel en de verwachte impact wordt uitgelegd. Deze transparantie voorkomt onnodige servicedeskverzoeken en vergroot het begrip voor beveiligingsmaatregelen. Indien apparaten onvoldoende vrije ruimte hebben, voert het werkplekteam een cleanup-scenario uit waarbij tijdelijke bestanden worden verwijderd voordat de loggrootte wordt verhoogd. Tot slot wordt iedere remediatie afgesloten met een validatie. Het script draait opnieuw met debug-logging, de resultaten worden gecontroleerd door een tweede beheerder en de auditor ontvangt een kort rapport met tijdstempels en verwijzingen naar de relevante BIO-controls. Pas wanneer alle stappen zijn gevalideerd, wordt het incident gesloten. Zo blijft het remediatieproces transparant, herleidbaar en volledig in lijn met de verwachtingen van Nederlandse toezichthouders. Wanneer meerdere apparaten gelijktijdig afwijken, treedt het Major Incident-proces in werking. Het crisisteam bepaalt dan of aanvullende capaciteitsmaatregelen nodig zijn, bijvoorbeeld het tijdelijk verhogen van de loggrootte boven de standaard of het versneld distribueren van SSD-upgrades. Tijdens de post-incident evaluatie worden metrics zoals Mean Time To Repair en het aantal getroffen gebruikers vastgelegd, zodat toekomstige remediaties sneller en consistenter verlopen. Alle remediaties worden gebundeld in een digitaal dossier dat beschikbaar is voor interne en externe auditors. Hierin staan screenshots, scriptuitvoer, communicatieberichten en besluiten van het crisisteam. Het dossier wordt bewaard volgens de AVG- en Archiefwet-eisen, waardoor het proces ook juridisch houdbaar is wanneer er vragen komen vanuit toezichthouders of parlementaire onderzoeken. Om het proces toekomstbestendig te houden, volgt het beheerteam jaarlijkse bijscholing waarin nieuwe aanvalstechnieken, updates in de BIO en lessons learned uit andere organisaties worden besproken. Deze trainingen monden uit in verbeterde draaiboeken en zorgen ervoor dat remediaties bij een volgende dreigingsgolf nog sneller en zorgvuldiger verlopen. Daarnaast wordt een resourcebuffer ingericht: een poule van getrainde specialisten die bij piekbelasting kan worden opgeschaald zonder langdurige inhuurprocessen. Zo blijft de remediatiecapaciteit stabiel, zelfs wanneer meerdere dreigingen tegelijkertijd spelen. Elke afgeronde case wordt geëvalueerd in het Security Governance Overleg, waardoor het lerend vermogen van de organisatie voortdurend wordt gevoed en remediatieafspraken nooit vrijblijvend zijn.

Compliance en Auditing

Het waarborgen van compliance begint met duidelijke documentatie. Dit artikel maakt onderdeel uit van de gecontroleerde documentenset binnen het project "Nederlandse Baseline voor Veilige Cloud" en verwijst direct naar BIO 16.01, CIS 18.9.19.2 en ISO 27001 A.12.4.1. Elke beleidswijziging wordt vergezeld van een versiebeheerrecord waarin de wijzigingsdatum, accordering door de CISO en verwijzing naar de change advisory board is vastgelegd. Daarmee kan een auditor eenvoudig vaststellen of de instelling op het juiste moment en met de juiste argumentatie is ingevoerd. Voor AVG-naleving wordt het principe van dataminimalisatie toegepast. Hoewel grotere logboeken meer data bevatten, worden alleen strikt noodzakelijke beveiligingsevenementen opgeslagen. De Functionaris Gegevensbescherming heeft beoordeeld dat de logboeken een gerechtvaardigd belang dienen en heeft de bewaartermijn vastgesteld op één jaar, in lijn met de auditbewijslast die de rijksoverheid doorgaans hanteert. In het gegevensregister is beschreven welke persoonsgegevens mogelijk voorkomen en welke technische en organisatorische maatregelen, zoals versleuteling en toegangsbeheer, daarop van toepassing zijn. Tijdens interne audits controleert de kwaliteitsmanager of het Intune-profiel nog overeenkomt met de beschreven configuratie. Zij raadpleegt het scriptresultaat, bekijkt de Intune-policy en controleert steekproefsgewijs devices via wevtutil el om te verifiëren dat de Security-log daadwerkelijk de vereiste omvang heeft. Bevindingen worden geregistreerd in het auditlogboek en opgevolgd via het verbeterregister. Wanneer een externe auditor, bijvoorbeeld de Algemene Rekenkamer of een ISO-certificerende instantie, aanvullende eisen stelt, worden deze toegevoegd aan de documentatie zonder het JSON-schema aan te passen. Tot slot is er aandacht voor ketenverantwoordelijkheid. Veel gemeenten en uitvoeringsorganisaties delen infrastructuur of leveren loggegevens aan landelijke SOC’s. In de verwerkersovereenkomsten is vastgelegd dat partners dezelfde minimale loggrootte hanteren en dat afwijkingen binnen vierentwintig uur worden gemeld. Hierdoor kunnen organisaties aantonen dat ze niet alleen intern, maar ook in de keten voldoen aan de Nederlandse Baseline voor Veilige Cloud. Deze transparantie versterkt het vertrouwen van bestuurders, auditors en burgers dat beveiligingsincidenten compleet en tijdig onderzocht kunnen worden. De compliance-resultaten worden elk kwartaal opgenomen in de rapportage aan het CIO-beraad, inclusief trends, uitzonderingen en geplande verbeteracties. Door deze rapportage te combineren met het landelijk beveiligingsdashboard ontstaat een integraal overzicht van alle Intune-maatregelen, waardoor bestuurders in één oogopslag zien hoe de auditloggrootte bijdraagt aan bredere risicobeheersing. Omdat veel organisaties naast BIO ook andere kaders hanteren, zoals NEN 7510 voor zorginstellingen of ENSIA voor gemeenten, is er een mappingtabel opgesteld. Deze tabel toont hoe de loggrootte-instelling scoort tegen de eisen van die frameworks, zodat auditteams niet telkens het wiel opnieuw hoeven uit te vinden. De tabel wordt meegeleverd bij elke audit en vormt een tastbaar bewijs dat de Nederlandse Baseline voor Veilige Cloud compatibel blijft met sectorale verplichtingen. Elke ondertekende audit wordt afgesloten met een digitaal certificaat waarin de betrokken managers hun goedkeuring bevestigen via PIV-handtekeningen. Dit certificaat wordt samen met de export van het Intune-profiel opgeslagen in een gescheiden archief en periodiek gecontroleerd op integriteit. Daardoor blijft de bewijskracht behouden, ook wanneer documenten jaren later opnieuw moeten worden overlegd. Deze end-to-end borging wordt ondersteund door automatisering: PowerShell-scripts in de deployment-map genereren bij iedere wijziging automatisch een compliance-samenvatting die aan de auditdossiers wordt toegevoegd. Zo blijven verslaglegging en techniek onafscheidelijk verbonden.

Compliance & Frameworks

• CIS M365: Control 18.9.19.2 (L1) - CIS Security Benchmark aanbevelingen
• BIO: 16.01 - BIO Baseline Informatiebeveiliging Overheid - 16.01 - Gebeurtenissen logging en audittrails
• ISO 27001:2022: A.12.4.1 - ISO 27001:2022 - Gebeurtenissen logging en audittrails

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 in audit logging.

• Implementatietijd: 2 uur
• FTE required: 0.01 FTE