Procescreatie-auditing Registreert Geslaagde Gebeurtenissen

Aanvallers misbruiken vaak living-off-the-land-technieken waarbij legitieme binaries nieuwe processen starten; zonder volledige auditlogs kunnen deze activiteiten niet overtuigend aan een incident worden gekoppeld.

Implementatie

Met Microsoft Intune wordt een auditbeleid uitgerold dat het eventtype voor procescreatie inschakelt, de logging koppelt aan centrale SIEM-oplossingen en beheerders begeleidt bij het testen, monitoren en herstellen van afwijkingen.

Vereisten

Een betrouwbare implementatie van gedetailleerde procescreatie-auditing begint met een beheerplatform dat configuraties stabiel kan uitrollen. Microsoft Intune moet volledig geconfigureerd zijn met tenant-brede device configuration profiles, compliance policies en role-based access control zodat slechts geautoriseerde beheerders wijzigingen kunnen publiceren. Windows 10 en 11 Enterprise of Education edities zijn verplicht, inclusief buildversies die de Advanced Audit Policy Configuration ondersteunen. Apparaten moeten zijn gekoppeld aan Azure AD, gebruikmaken van Microsoft Defender for Endpoint sensoren en beschikken over actuele security intelligence updates, omdat anders de correlatie tussen auditgegevens en detectieregels onbetrouwbaar wordt. Daarnaast moeten endpoints voldoen aan basisvoorwaarden zoals eenduidige tijdsynchronisatie via een betrouwbare NTP-bron, een gestandaardiseerde opslaglocatie voor Windows Event Logs en voldoende schijfruimte om de grotere logvolumes te bufferen. Organisaties moeten een change- en releaseproces hebben waarin auditwijzigingen worden beoordeeld door zowel het securityteam als het compliancebureau, inclusief testresultaten uit een gecontroleerde pilotring. Integraties met Microsoft Sentinel of een ander SIEM-platform horen vooraf te zijn ingericht, met serviceaccounts die leesrechten hebben op de Intune Graph API en op de logcollectors. Zonder deze integraties zou het onmogelijk zijn om de extra auditgegevens tijdig te analyseren en alerts te genereren. Tot slot moeten ondersteunende processen beschikbaar zijn: een knowledgebase waarin incident responders precies kunnen zien welke gebeurtenissen worden gelogd, een data-retentiebeleid dat aansluit bij de BIO en de Archiefwet, en opleidingsmateriaal voor werkplekbeheerders waarin de impact van deze auditinstelling wordt toegelicht. Een escalatiepad naar het Computer Security Incident Response Team moet zijn afgestemd, inclusief contactmomenten met leveranciers voor het geval dat auditlogs moeten worden aangeleverd aan externe toezichthouders. De organisatie moet kunnen aantonen dat het beheer van cryptografische sleutels, back-ups en schijfbescherming op orde is, zodat loggegevens niet onbedoeld worden gewijzigd voordat zij naar een beveiligde opslag zijn verzonden. Voorafgaand aan productie moet er een testomgeving zijn met representatieve workloads, serviceaccounts en legacy-applicaties, omdat sommige industriële applicaties gevoeliger zijn voor audit-overhead. In deze omgeving worden prestatiemetingen uitgevoerd, wordt gecontroleerd of Event ID 4688 daadwerkelijk binnenkomt in de SIEM en wordt gevalideerd dat defensieve tooling zoals Microsoft Defender Attack Surface Reduction niet onverwacht blokkeert. Documenteer de resultaten in het CMDB-record van het auditbeleid en voeg goedkeuringen van de Chief Information Security Officer en de Functionaris Gegevensbescherming toe. Pas wanneer al deze voorwaarden gedocumenteerd en ondertekend zijn, voldoet de organisatie aan de vereisten om procescreatie-auditing op schaal te activeren. Een ander belangrijk vereiste is de beschikbaarheid van ondersteuningstools zoals PowerShell 7, de Microsoft Graph PowerShell SDK en het Windows Event Forwarding framework. Beheerders moeten de modules vooraf installeren in een beheernetwerk zonder internettoegang en de benodigde TLS-inspectie-uitsluitingen configureren zodat verbinding met graph.microsoft.com gegarandeerd blijft. Door deze tooling klaar te zetten kan het team snel scripts uitvoeren, configuratieprofielen exporteren voor audits en, indien nodig, rollback-scenario’s testen. Zonder deze voorbereiding dreigt de organisatie tijd te verliezen tijdens een incident, waardoor de waarde van de auditlogs sterk afneemt.

Implementatie

De implementatie begint met het inventariseren van bestaande audit policies per devicegroep en het spiegelen daarvan aan de Microsoft Security Baseline voor Windows 10 en 11. Het securityteam legt vast welke Groepsbeleid-objecten, lokaal ingestelde auditregels en third-party hardening scripts actief zijn, zodat conflicten worden voorkomen. Door deze nulmeting te koppelen aan de CMDB ontstaat een duidelijk beeld van apparaten die via Intune, Configuration Manager of hybride co-management worden aangestuurd. Op basis van die segmentatie worden doelgroepen bepaald, zoals kritieke servers, ontwikkelwerkplekken en endpoints binnen OT-omgevingen. Na de analyse maakt het Intune-team een configuration profile met het instellingen-catalogusobject "Audit Process Creation" en zet de waarde op "Success". Het profiel krijgt een duidelijke naamgeving, versiebeheer en een change reference-nummer zodat herleidbaarheid is geborgd. In de beschrijving wordt expliciet vermeld waarom Event ID 4688 essentieel is voor detectieketens rond privilege escalation en ransomware. Scope Tags beperken de beheerrechten tot het SOC en het endpointbeheerteam, terwijl dynamische Azure AD-groepen zorgen dat alleen ondersteunde Windows SKU’s het beleid ontvangen. Parallel bereidt het automatiseringsteam het script detailed-tracking-audit-process-creation-is-set-to-include-success.ps1 voor. Het script leest de huidige configuratie via de Graph API, vergelijkt die met de gewenste status en schrijft afwijkingen weg naar een beveiligd logboek. Binnen de deployment pipeline wordt het script eerst in een dry-run modus uitgevoerd, waarbij uitsluitend rapportage plaatsvindt. Zodra de validatie slaagt, wordt de remediationmodus ingeschakeld en levert het script een bevestiging inclusief tijdstempel, Intune device-id en resultaatcode. Deze output wordt opgeslagen in Azure Monitor zodat auditors later kunnen aantonen wanneer en op welke manier het beleid is geactiveerd. Vervolgens start een pilotfase met een representatieve groep apparaten. Beheerders volgen een draaiboek waarin onder meer staat hoe kunstmatige workload wordt gegenereerd via Sysinternals PsExec, zodat nieuwe processen bewust worden aangemaakt en gelogd. Het SOC controleert of de gebeurtenissen via Windows Event Forwarding of Defender for Endpoint naar Microsoft Sentinel gaan en of bestaande analytics rules correct triggeren. Eventuele prestatie-impact wordt vastgelegd; wanneer CPU- of IO-overhead hoger dan vijf procent uitvalt, wordt onderzocht of uitzonderingen nodig zijn voor specifieke applicaties. Wanneer de pilot stabiel draait, richten de teams een gefaseerde uitrol in met duidelijke versies en release waves. Iedere wave bevat borgingsactiviteiten zoals het controleren van de Intune report blades, het verzamelen van gebruikersfeedback en het bijwerken van centrale auditdocumentatie. Het change-advisory-board ontvangt een rapportage met risicoanalyse, fallbackplan en verwachte voordelen, waarna definitieve goedkeuring wordt gegeven. Daarna wordt het beleid breed uitgerold en worden scripts opgenomen in de reguliere onderhoudscyclus, inclusief periodieke her-evaluaties.

Gebruik PowerShell-script detailed-tracking-audit-process-creation-is-set-to-include-success.ps1 (functie Invoke-Monitoring) – Monitoren.

Monitoring

Monitoring van deze instelling begint bij Event ID 4688 dat door Windows Audit Policy wordt vastgelegd telkens wanneer een nieuw proces start. De operationele teams configureren Windows Event Forwarding, Microsoft Defender for Endpoint en eventuele third-party agents zo dat deze gebeurtenis ongewijzigd en met originele tijdstempels wordt doorgestuurd. Door de events te verrijken met device tags, gebruikerscontext en applicatienaam ontstaat een dataset waarmee analisten afwijkingen kunnen herkennen. Speciale aandacht gaat uit naar systemen met lokale serviceaccounts, omdat daar vaak geautomatiseerde taken draaien die grote aantallen processen genereren. Voor deze systemen worden baseline-profielen opgesteld zodat detectieregels alleen afwijken wanneer het volume of de commandline-parameters buiten het normale bereik vallen. In Microsoft Sentinel worden Kusto-query’s ingericht die controleren of iedere beheerde endpoint minimaal één procescreatie-event per dag rapporteert. Blijven gebeurtenissen uit, dan is waarschijnlijk het Intune-profiel verwijderd, de auditlog-service gestopt of is de forwardingketen onderbroken. Deze health-checks worden gekoppeld aan een automation rule die een ticket aanmaakt in het ITSM-systeem en, indien nodig, automatisch het monitoring-script start om de configuratie opnieuw te lezen. Naast beschikbaarheidscontrole worden inhoudelijke detecties gebouwd, bijvoorbeeld een regel die waarschuwt zodra `cmd.exe` vanuit `C:\Windows\Temp` wordt gestart of wanneer een standaardgebruiker `rundll32.exe` uitvoert met opvallende parameters. Het SOC publiceert dashboards met kernindicatoren zoals het aantal unieke processen per device, de verhouding tussen interactieve en serviceprocessen en het aantal alerts dat voortkomt uit commandline-anomalieën. Door deze KPI’s maandelijks te bespreken met het werkplekbeheerteam ontstaat een continue feedbacklus. Indien businessapplicaties bewust nieuwe procesketens introduceren, kan het dashboard worden bijgewerkt met uitzonderingsmarkeringen zodat analisten weten dat bepaalde pieken legitiem zijn. Voor beheer op directieniveau wordt een verkorte rapportage opgesteld waarin trends, kritieke incidenten en nalevingsstatus worden toegelicht. Om de monitoringselfservice te verbeteren, stelt het team een handleiding op waarin staat hoe lokale beheerders de configuratie kunnen controleren via `auditpol.exe /get /category:"Detailed Tracking"`. De handleiding beschrijft ook hoe logmanagers verificatie uitvoeren op de Event Viewer, hoe zij logbestanden veilig exporteren en hoe data integrity wordt aangetoond met behulp van hashing. Door deze werkinstructies beschikbaar te maken via het intranet kunnen audits sneller verlopen en wordt de afhankelijkheid van het centrale team kleiner. Bij afwijkingen wordt altijd een runbook gevolgd waarin detectie, triage, herstelactie en communicatiekanalen zijn vastgelegd. Dit runbook bevat criteria voor het escaleren naar het CSIRT, bijvoorbeeld wanneer processen worden gestart door onbekende binaries of wanneer de logging volledig wegvalt. De runbookstappen worden minimaal elk kwartaal getest tijdens een tabletop-oefening zodat het team zeker weet dat monitoringinformatie bruikbaar is tijdens echte incidenten.

Gebruik PowerShell-script detailed-tracking-audit-process-creation-is-set-to-include-success.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Wanneer monitoring aangeeft dat procescreatie-auditing ontbreekt of afwijkend is ingesteld, start het remediatieproces met een snelle triage. Beheerders controleren eerst of het betrokken apparaat nog actief wordt beheerd door Intune en of er recent wijzigingen zijn aangebracht door een change request of noodpatch. Daarna wordt nagegaan of lokale administrators de auditpolicy hebben overschreven met `auditpol.exe` of via een verouderd GPO. Deze analyse wordt vastgelegd in het incidentticket, inclusief screenshots of loguitvoer, zodat auditors later kunnen reconstrueren wat er is gebeurd. Vervolgens gebruikt het team het script detailed-tracking-audit-process-creation-is-set-to-include-success.ps1 in remediationmodus. Het script valideert de Graph-verbinding, leest het huidige beleid, zet de instelling terug naar "Success" en schrijft het resultaat naar een beveiligde opslag. Bij succes wordt automatisch een notitie toegevoegd aan het ticket met het device-id, de tijdstempel en de identiteit van de uitvoerende beheerder. Als het script een foutmelding teruggeeft, bijvoorbeeld omdat het apparaat offline is, wordt een achtergrondtaak gepland om de actie te herhalen zodra het apparaat weer incheckt. Naast technische herstelacties bevat het plan ook organisatorische stappen. Het change-advisory-board wordt geïnformeerd wanneer de oorzaak terug te voeren is op een ongeautoriseerde wijziging of een mislukte deployment. In zulke gevallen kan aanvullende training nodig zijn voor het betrokken team, of moeten toegangsrechten worden herzien. Indien blijkt dat een endpoint bewust buiten beheer is geplaatst, start het securityteam een asset recovery-proces zodat de compliance-achterstand wordt ingelopen. Voor kritieke omgevingen, zoals systemen die logging leveren voor fraudeonderzoek of justitiële dossiers, is een fallback beschikbaar waarbij tijdelijk Group Policy wordt gebruikt om dezelfde auditinstelling door te drukken. Deze noodmaatregel wordt alleen geactiveerd na akkoord van de CISO en wordt weer verwijderd zodra Intune-beheer is hersteld. Alle stappen worden nauwkeurig gelogd, inclusief hashwaarden van aangepaste scripts, zodat bewijslast richting toezichthouders sluitend is. Na afronding van de remediatie wordt een post-mortem uitgevoerd. Het team beoordeelt of detectieregels voldoende snel aansloegen, of runbooks helder waren en welke preventieve maatregelen kunnen voorkomen dat de afwijking terugkomt. Denk aan het toevoegen van een Intune compliance policy die apparaten markeert als non-compliant wanneer audit logging wordt uitgeschakeld, of aan het inrichten van Azure Automation jobs die dagelijks de config uitlezen. Lessons learned worden gedeeld met het SOC, het endpointbeheerteam en de privacy officer zodat organisatorische kennis actueel blijft.

Gebruik PowerShell-script detailed-tracking-audit-process-creation-is-set-to-include-success.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance en Auditing

Gedetailleerde auditlogs over procescreatie ondersteunen meerdere normen tegelijk: de BIO eist aantoonbare logging van systeemactiviteiten (maatregel 16.01), ISO/IEC 27001 artikel A.12.4 benadrukt het vastleggen van systeemgebeurtenissen en de AVG verlangt dat organisaties incidenten kunnen reconstrueren wanneer persoonsgegevens mogelijk zijn geraakt. Door deze instelling actief te houden kan men precies aantonen welke processen zijn gestart door een gebruiker of systeemaccount, wat essentieel is bij forensisch onderzoek na een ransomware-aanval of ongeautoriseerde data-extractie. Leg in het informatiebeveiligingsbeleid vast waarom deze logcategorie onmisbaar is, hoe lang gegevens bewaard blijven en hoe toegang tot de logs wordt gecontroleerd. Auditors verwachten dat elke configuratiewijziging traceerbaar is. Daarom moeten change-tickets, Intune-versies en scriptuitvoeringen worden geregistreerd in een centrale audit trail die toegankelijk is voor interne en externe auditors. Dit register bevat de naam van het beleid, toegepaste scope tags, implementatiedata en verantwoordelijke eigenaren. Voeg bewijs toe in de vorm van Intune-exporten, SIEM-query’s waaruit blijkt dat Event ID 4688 binnenkomt, en screenshots van monitoringdashboards. Door bewijs vast te leggen tijdens de implementatie kan de organisatie tijdens audits snel reageren zonder ad-hoc data te verzamelen. Voor AVG- en BIO-conformiteit moet ook zijn beschreven hoe persoonsgegevens in auditlogs worden beschermd. Logbestanden horen te worden opgeslagen in een omgeving met rolgebaseerde toegang, versleuteling-at-rest en tamper-evident voorzieningen zoals immutable storage policies. Neem in het verwerkingsregister op welke categorieën persoonsgegevens in Event ID 4688 kunnen voorkomen, bijvoorbeeld gebruikersnamen of padnamen die indirect persoonsgegevens bevatten, en motiveer de noodzakelijkheid op basis van het gerechtvaardigd belang voor informatiebeveiliging. Beschrijf eveneens hoe betrokkenenrechten kunnen worden gefaciliteerd wanneer auditlogs PII bevatten, bijvoorbeeld door middel van geautoriseerde extracties die door het privacyteam worden gevalideerd. Bij externe audits, zoals BIO-toetsingen of DigiD-assessments, moet de organisatie aantonen dat de loggingketen daadwerkelijk werkt. Plan daarom periodieke controles waarbij een onafhankelijk team sample-metingen uitvoert: zij starten processen op een testmachine en volgen of de gebeurtenis binnen een afgesproken tijdsvenster in de SIEM verschijnt. De resultaten worden opgenomen in een controleverslag inclusief tijdstempels, query’s en verwijzingen naar de betreffende Intune-policyversie. Wanneer een steekproef faalt, wordt het remediatieproces geactiveerd en wordt het auditrapport aangevuld met corrigerende maatregelen. Governance-raden, zoals de Informatiebeveiligingsraad of het Security Board, gebruiken deze logging-eisen om volwassenheidsniveaus te bepalen. Zij verwachten dat het eigenaarschap van het auditbeleid is toegewezen aan zowel het SOC (voor detectie) als de lijnorganisatie (voor beheer). Tijdens kwartaalrapportages rapporteert het SOC over KPI’s, incidenten en lessons learned, terwijl de lijnorganisatie uitlegt welke systeemveranderingen de logging kunnen beïnvloeden. Deze gezamenlijke governance zorgt ervoor dat naleving van de Nederlandse Baseline voor Veilige Cloud aantoonbaar en duurzaam blijft.

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

Activeer de auditpolicy voor procescreatie via Intune en borg monitoring zodat elke nieuwe processtart centraal wordt vastgelegd.

• Implementatietijd: 2 uur
• FTE required: 0.01 FTE