💼 Management Samenvatting
Deze beveiligingsregel waarborgt de correcte configuratie van auditlogboekregistratie voor beveiligingsgroepbeheer op Windows endpoints, waardoor organisaties succesvolle wijzigingen aan beveiligingsgroepen kunnen monitoren en traceren.
Het monitoren van succesvolle wijzigingen aan beveiligingsgroepen is essentieel voor het detecteren van ongeautoriseerde toegangsverwijdingen, het voldoen aan compliance-eisen en het bieden van volledige traceerbaarheid van beveiligingswijzigingen binnen de organisatie. Zonder deze auditfunctionaliteit kunnen beveiligingsincidenten onopgemerkt blijven en ontbreekt cruciale informatie voor forensisch onderzoek.
Connection:
Connect-MgGraphRequired Modules: Microsoft.Graph.DeviceManagement
Implementatie
Deze configuratie stelt het Windows auditbeleid in om succesvolle gebeurtenissen voor beveiligingsgroepbeheer te loggen via Microsoft Intune apparaatconfiguratiebeleid of compliancebeleid. Dit omvat het registreren van alle succesvolle wijzigingen aan beveiligingsgroepen, inclusief het toevoegen of verwijderen van leden, het wijzigen van groepseigenschappen en het aanmaken of verwijderen van beveiligingsgroepen zelf.
Vereisten
De implementatie van auditlogboekregistratie voor beveiligingsgroepbeheer vereist een grondige voorbereiding waarbij zowel technische als organisatorische aspecten zorgvuldig moeten worden geëvalueerd. Deze voorbereidingsfase is cruciaal omdat een onjuiste implementatie kan leiden tot gaten in de beveiligingsmonitoring en niet-naleving van compliance-vereisten. Organisaties moeten beginnen met een complete inventarisatie van hun huidige infrastructuur en bepalen welke componenten reeds aanwezig zijn en welke nog moeten worden geïmplementeerd of geüpgraded. Microsoft Intune vormt de kern van deze implementatie en dient te functioneren als het centrale mobiele apparaatbeheer en mobiele applicatiebeheer platform, ook wel aangeduid als MDM en MAM. Deze platformfunctie kan worden gerealiseerd via een standalone Microsoft Intune licentie of als onderdeel van Microsoft 365 E3 of E5 licenties, waarbij de E5 licentie de meest uitgebreide beveiligingsfuncties en geavanceerde bedreigingsbescherming mogelijkheden biedt. De keuze tussen deze licentieopties hangt af van de specifieke beveiligingsbehoeften van de organisatie en het beschikbare budget. Organisaties die werken met gevoelige overheidsinformatie zullen doorgaans kiezen voor E5 licenties vanwege de uitgebreide compliance- en beveiligingsfuncties. De organisatie moet beschikken over een actief Microsoft Entra ID tenant, voorheen bekend als Azure Active Directory, met de juiste licenties voor apparaatbeheer. Deze licenties zijn essentieel omdat zonder de juiste licentieconfiguratie de auditbeleid instellingen niet kunnen worden toegepast op de endpoints, wat direct leidt tot niet-naleving van beveiligingsvereisten. Het is belangrijk om te verifiëren dat alle benodigde licenties correct zijn toegewezen en dat er geen licentieconflicten bestaan die de implementatie kunnen blokkeren. Daarnaast is het essentieel dat alle Windows endpoints zijn ingeschreven in Microsoft Intune via een van de moderne apparaatregistratiemethoden. Azure AD Join is de meest directe methode waarbij apparaten direct worden geregistreerd in de cloud directory zonder tussenkomst van on-premises Active Directory. Deze methode is bijzonder geschikt voor moderne cloud-first organisaties die volledig werken met cloudservices. Hybrid Azure AD Join is geschikt voor apparaten die zowel on-premises als in de cloud worden beheerd, wat typisch is voor organisaties die een gefaseerde migratie naar de cloud ondergaan. Voor persoonlijke apparaten die worden gebruikt voor werkdoeleinden, ook wel Bring Your Own Device genoemd, kan registratie plaatsvinden via de Intune Company Portal applicatie, die gebruikers in staat stelt hun persoonlijke apparaten veilig te registreren met behoud van privacy. Elke registratiemethode heeft specifieke voordelen en overwegingen die moeten worden afgewogen op basis van de organisatorische behoeften, beveiligingsvereisten en de huidige IT-infrastructuur. Organisaties moeten een gedetailleerde analyse uitvoeren om te bepalen welke registratiemethode het beste past bij hun specifieke situatie. Voor de configuratie van auditbeleid via Intune is een Intune Administrator rol of een rol met vergelijkbare rechten vereist binnen de Microsoft Entra ID omgeving. Deze rolbevoegdheden zijn noodzakelijk om apparaatconfiguratieprofielen aan te maken, te wijzigen en toe te wijzen aan apparaatgroepen. Het principe van least privilege moet worden toegepast, wat betekent dat alleen personen die daadwerkelijk deze configuraties moeten uitvoeren toegang krijgen tot deze rollen. Organisaties moeten ervoor zorgen dat alleen bevoegde personen toegang hebben tot deze rollen en dat roltoewijzingen regelmatig worden gecontroleerd en gedocumenteerd voor compliance doeleinden. Regelmatige toegangsreviews moeten worden uitgevoerd om te verifiëren dat roltoewijzingen nog steeds gerechtvaardigd zijn en dat voormalige medewerkers geen toegang meer hebben tot gevoelige configuratiefuncties. De Windows endpoints moeten minimaal Windows 10 versie 1809 of Windows 11 uitvoeren om volledige ondersteuning te bieden voor de moderne auditbeleid configuratie via Intune. Deze versievereisten zijn essentieel omdat oudere versies van Windows niet beschikken over de benodigde API's en functies die vereist zijn voor moderne Intune configuratie. Oudere versies van Windows 10 of Windows 7 en 8.1 worden niet ondersteund voor deze moderne configuratiemethode en vereisen alternatieve implementatiebenaderingen zoals Groepsbeleid of lokale beveiligingsbeleid configuratie. Organisaties moeten een complete inventarisatie uitvoeren van alle endpoints om te bepalen welke apparaten voldoen aan de minimale versievereisten en een gedetailleerd migratieplan ontwikkelen voor apparaten die niet voldoen. Dit migratieplan moet tijdlijnen bevatten, resourcevereisten specificeren en risico's identificeren die kunnen ontstaan tijdens de migratie. Organisaties moeten er ook voor zorgen dat de endpoints verbonden zijn met het netwerk en regelmatig communiceren met de Intune service om beleidsupdates te ontvangen. Endpoints die langere tijd offline zijn geweest kunnen belangrijke beleidsupdates hebben gemist, wat kan leiden tot niet-naleving van beveiligingsvereisten en potentiële beveiligingsrisico's. Het is daarom belangrijk om netwerkconnectiviteit te monitoren en ervoor te zorgen dat endpoints regelmatig synchroniseren met de Intune service. Monitoring tools kunnen worden geïmplementeerd om endpoints te identificeren die niet regelmatig synchroniseren en om automatische waarschuwingen te genereren wanneer endpoints te lang offline zijn geweest. Vanuit organisatorisch perspectief is het belangrijk dat er duidelijke procedures zijn voor het beheren van auditlogboeken, inclusief retentiebeleid dat specificeert hoe lang logboeken moeten worden bewaard, toegangscontroles voor beveiligingsanalisten die de logboeken moeten kunnen analyseren, en procedures voor het archiveren en verwijderen van oude logboeken. Het retentiebeleid moet worden afgestemd op compliance vereisten zoals BIO, ISO 27001 en eventuele sector-specifieke regelgeving. Nederlandse overheidsorganisaties moeten bijvoorbeeld rekening houden met de Archiefwet, die specifieke bewaartermijnen voorschrijft voor verschillende soorten informatie. Het beveiligingsoperationeel centrum of de IT beveiligingsafdeling moet beschikken over de juiste tools en expertise om de gegenereerde auditlogboeken te kunnen interpreteren en te gebruiken voor beveiligingsmonitoring en incidentafhandeling doeleinden. Dit omvat training van personeel in het gebruik van SIEM systemen, het interpreteren van Windows Security Event Logs, en het identificeren van verdachte activiteiten die nader onderzoek vereisen. Regelmatige trainingsessies moeten worden georganiseerd om ervoor te zorgen dat beveiligingsanalisten up-to-date blijven met de nieuwste bedreigingen en analysetechnieken. Organisaties moeten ook overwegen om automatische waarschuwingen te implementeren voor kritieke gebeurtenissen zoals wijzigingen aan hoog-privileged groepen, zodat beveiligingsteams direct kunnen reageren op potentiële beveiligingsincidenten. Deze automatische waarschuwingen kunnen worden geconfigureerd in SIEM systemen en moeten worden afgestemd op de specifieke risicoprofielen van de organisatie.
Implementatie
De implementatie van auditlogboekregistratie voor beveiligingsgroepbeheer begint met het aanmaken van een nieuw apparaatconfiguratieprofiel in Microsoft Intune, wat de centrale beheeromgeving is voor alle Windows endpoints binnen de organisatie. Navigeer naar het Intune-beheercentrum, de webgebaseerde beheerconsole die toegankelijk is via de Microsoft 365-beheerportaal, en selecteer Apparaten in het navigatiemenu aan de linkerkant. Vervolgens selecteert u Configuratieprofielen uit het submenu en kiest u voor Profiel maken om een nieuw configuratieprofiel aan te maken. Selecteer het platform Windows 10 en later, wat betekent dat het profiel van toepassing is op alle moderne Windows versies vanaf Windows 10 versie 1809 en hoger, inclusief alle versies van Windows 11. Kies het profieltype Instellingencatalogus, wat de meest uitgebreide mogelijkheden biedt voor het configureren van Windows beveiligingsinstellingen en andere systeemconfiguraties. Dit profieltype is bijzonder geschikt voor complexe configuraties omdat het toegang geeft tot een uitgebreide catalogus van instellingen die kunnen worden geconfigureerd zonder dat er aangepaste OMA-URI waarden hoeven te worden gebruikt. Binnen de instellingencatalogus zoekt u naar de categorie Lokale Beveiligingsbeleidsopties, wat verwijst naar de lokale beveiligingsbeleidsinstellingen die traditioneel werden geconfigureerd via Groepsbeleid. Navigeer vervolgens naar Auditbeleid, wat de subcategorie is die alle auditgerelateerde instellingen bevat. Selecteer de specifieke instelling Audit Beveiligingsgroepbeheer, wat het Windows auditbeleid is dat specifiek is ontworpen voor het loggen van gebeurtenissen gerelateerd aan beveiligingsgroepbeheer. Configureer deze instelling om succesvolle gebeurtenissen te loggen, wat betekent dat alleen succesvolle gebeurtenissen worden vastgelegd in het Windows Security Event Log. Het is belangrijk om te begrijpen dat deze instelling zowel succesvolle als mislukte gebeurtenissen kan loggen, maar voor deze specifieke baseline configuratie focussen we op succesvolle gebeurtenissen om een volledig beeld te krijgen van alle wijzigingen die daadwerkelijk zijn doorgevoerd. Dit is een bewuste keuze omdat succesvolle wijzigingen aan beveiligingsgroepen de meest kritieke gebeurtenissen zijn voor beveiligingsmonitoring, aangezien deze wijzigingen daadwerkelijk impact hebben op toegangsrechten. Mislukte pogingen tot wijziging zijn ook belangrijk maar worden doorgaans gelogd via andere auditbeleid zoals Account Management auditbeleid. Na het configureren van de instelling moet het profiel een duidelijke naam krijgen die de functie beschrijft, bijvoorbeeld Audit Beveiligingsgroepbeheer Succesvolle Gebeurtenissen, en een beschrijving die uitlegt wat het profiel doet en waarom het is geconfigureerd. Het profiel moet vervolgens worden toegewezen aan de relevante apparaatgroepen, wat kan worden gedaan door specifieke beveiligingsgroepen te selecteren of door dynamische apparaatgroepen te gebruiken die automatisch apparaten toevoegen op basis van criteria zoals besturingssysteemversie of apparaattype. Het wordt sterk aanbevolen om te beginnen met een pilotgroep van testapparaten om te verifiëren dat de configuratie correct wordt toegepast en dat de auditlogboeken zoals verwacht worden gegenereerd. Deze pilotfase moet minimaal één week duren om voldoende tijd te hebben om te testen onder verschillende omstandigheden en om te verifiëren dat de logboeken correct worden gegenereerd voor verschillende soorten beveiligingsgroepwijzigingen. Tijdens de pilotfase moeten testwijzigingen worden uitgevoerd aan beveiligingsgroepen, zoals het toevoegen en verwijderen van testgebruikers, om te verifiëren dat de bijbehorende gebeurtenis-ID's correct worden gelogd in het Windows Security Event Log. Na succesvolle verificatie kan het profiel worden uitgerold naar alle productie-endpoints via een gefaseerde implementatiebenadering waarbij eerst een kleine subset van productieapparaten wordt geconfigureerd, gevolgd door een geleidelijke uitbreiding naar alle apparaten. De implementatie via Intune zorgt ervoor dat de configuratie centraal wordt beheerd en automatisch wordt toegepast op alle endpoints, ongeacht hun fysieke locatie, wat bijzonder waardevol is voor organisaties met gedistribueerde werkomgevingen en werknemers op afstand. Dit elimineert de noodzaak voor handmatige configuratie op elk apparaat en zorgt voor consistentie in de beveiligingsconfiguratie door de hele organisatie. Het PowerShell script dat beschikbaar is voor deze baseline kan worden gebruikt om de configuratie te verifiëren en te monitoren of de instelling correct is toegepast op alle endpoints binnen de organisatie. Dit script kan worden uitgevoerd als onderdeel van regelmatige compliance controles en kan worden geautomatiseerd via Taakplanner of Azure Automation om periodiek de configuratiestatus te controleren en rapporten te genereren voor management en auditors.
Gebruik PowerShell-script audit-security-group-management-is-set-to-include-success.ps1 (functie Invoke-Monitoring) – Het monitoring script verifieert of het auditbeleid correct is geconfigureerd op alle endpoints en rapporteert de compliancestatus..
Monitoring
Effectieve monitoring van auditlogboekregistratie voor beveiligingsgroepbeheer vereist een gestructureerde aanpak die zowel technische verificatie als continue analyse van de gegenereerde logboeken omvat, waarbij verschillende lagen van monitoring worden geïmplementeerd om volledige zichtbaarheid te garanderen. Het primaire monitoringdoel is om te verifiëren dat het auditbeleid daadwerkelijk actief is op alle endpoints en dat succesvolle beveiligingsgroepwijzigingen correct worden gelogd in het Windows Security Event Log. Dit vereist niet alleen een eenmalige verificatie na implementatie, maar een continue monitoringstrategie die regelmatig de configuratiestatus controleert en rapporteert over de naleving van de beveiligingsvereisten. Het beschikbare PowerShell monitoring script kan worden uitgevoerd op regelmatige basis, bijvoorbeeld wekelijks of maandelijks afhankelijk van de organisatorische behoeften en compliance vereisten, om de compliancestatus van alle endpoints te controleren. Het script verifieert de lokale Groepsbeleidsobject configuratie door de registerwaarden te lezen die de auditbeleid instellingen bevatten, en rapporteert welke endpoints de instelling correct hebben geconfigureerd en welke mogelijk aandacht vereisen. Het script genereert typisch een rapport in CSV of JSON formaat dat kan worden gebruikt voor compliance rapportage en trendanalyse over tijd. Naast technische verificatie is het essentieel om de gegenereerde auditlogboeken daadwerkelijk te analyseren om te begrijpen wat er gebeurt binnen de organisatie en om potentiële beveiligingsincidenten te detecteren. Windows Security Event Log entries met Gebeurtenis-ID 4732, wat een beveiligingsgroep is gewijzigd, Gebeurtenis-ID 4733 wat een account is toegevoegd aan een beveiligingsgroep, Gebeurtenis-ID 4734 wat een account is verwijderd uit een beveiligingsgroep, Gebeurtenis-ID 4735 wat een beveiligingsgroep is verwijderd, Gebeurtenis-ID 4754 wat een account is toegevoegd aan een universele beveiligingsgroep, Gebeurtenis-ID 4755 wat een account is verwijderd uit een universele beveiligingsgroep, Gebeurtenis-ID 4756 wat een universele beveiligingsgroep is gewijzigd, Gebeurtenis-ID 4757 wat een universele beveiligingsgroep is verwijderd, Gebeurtenis-ID 4764 wat een account is toegevoegd aan een distributiegroep, en Gebeurtenis-ID 4765 wat een account is verwijderd uit een distributiegroep, zijn allemaal relevant voor beveiligingsgroepbeheer. Deze gebeurtenissen bevatten gedetailleerde informatie over het toevoegen of verwijderen van leden uit beveiligingsgroepen, wijzigingen aan groepseigenschappen zoals groepslidmaatschappen en machtigingen, en het aanmaken of verwijderen van groepen zelf. Elke gebeurtenis bevat belangrijke metadata zoals de tijdstempel van de wijziging, de gebruiker of serviceaccount die de wijziging heeft uitgevoerd, de naam van de betrokken groep, en de specifieke wijziging die is doorgevoerd. Organisaties moeten een Security Information and Event Management systeem implementeren, zoals Microsoft Sentinel of een vergelijkbare SIEM oplossing, om deze gebeurtenissen centraal te verzamelen en te analyseren. Een SIEM systeem verzamelt gebeurtenissen van alle endpoints binnen de organisatie en slaat deze op in een gecentraliseerde database, waardoor het mogelijk wordt om gebeurtenissen te correleren, trends te identificeren, en geavanceerde analyses uit te voeren die niet mogelijk zijn wanneer logboeken alleen lokaal op endpoints worden bewaard. Dit maakt het mogelijk om anomalieën te detecteren, zoals ongebruikelijke wijzigingspatronen die kunnen wijzen op gecompromitteerde accounts of insider threats, wijzigingen buiten kantooruren die kunnen wijzen op ongeautoriseerde toegang, of wijzigingen door onbekende serviceaccounts die mogelijk zijn gecompromitteerd. Geavanceerde SIEM systemen kunnen machine learning algoritmes gebruiken om normale activiteitspatronen te leren en automatisch te waarschuwen wanneer afwijkende activiteit wordt gedetecteerd. Het is sterk aanbevolen om automatische waarschuwingen te configureren voor kritieke gebeurtenissen, zoals wijzigingen aan hoog-privileged groepen zoals Domain Admins, Enterprise Admins, Schema Admins, of andere gevoelige beveiligingsgroepen die uitgebreide machtigingen hebben binnen de organisatie. Deze waarschuwingen moeten worden geconfigureerd om onmiddellijk beveiligingsteams te waarschuwen wanneer dergelijke wijzigingen plaatsvinden, zodat snelle respons mogelijk is. Regelmatige review van auditlogboeken door beveiligingsanalisten helpt bij het identificeren van potentiële beveiligingsincidenten en het voldoen aan compliance vereisten voor audittrail documentatie. Deze reviews moeten worden uitgevoerd volgens een vastgesteld schema, bijvoorbeeld wekelijks of maandelijks, en moeten worden gedocumenteerd voor audit doeleinden. De reviews moeten niet alleen focussen op het identificeren van verdachte activiteit, maar ook op het valideren dat de auditlogboekregistratie correct functioneert en dat alle verwachte gebeurtenissen worden gelogd zoals bedoeld.
Gebruik PowerShell-script audit-security-group-management-is-set-to-include-success.ps1 (functie Invoke-Monitoring) – Het monitoring script controleert de configuratie status en genereert compliance rapporten voor alle endpoints..
Remediatie
Wanneer monitoring aangeeft dat endpoints niet voldoen aan de vereiste auditbeleid configuratie, moet er een gestructureerd remediatieproces worden gevolgd dat systematisch de verschillende mogelijke oorzaken onderzoekt en oplost. Dit proces moet worden gedocumenteerd en gevolgd voor alle endpoints die niet voldoen aan de vereisten, om te zorgen voor consistentie en om te leren van eerdere problemen. Het eerste dat moet worden gecontroleerd is of het Intune configuratieprofiel correct is toegewezen aan de betreffende apparaatgroepen en of de endpoints daadwerkelijk zijn ingeschreven in Intune. Dit kan worden geverifieerd door te controleren of de endpoints verschijnen in het Intune-beheercentrum onder de sectie Apparaten, en of ze de status Ingeschreven hebben. Endpoints die niet zijn ingeschreven kunnen het beleid niet ontvangen omdat ze geen verbinding hebben met de Intune service, en moeten worden geregistreerd via de standaard Intune registratieprocedures die geschikt zijn voor het type endpoint en de organisatorische vereisten. Voor endpoints die wel zijn ingeschreven maar het beleid niet correct hebben toegepast, moet worden gecontroleerd of de endpoints recent hebben gecommuniceerd met de Intune service. Dit kan worden geverifieerd door te kijken naar de laatste check-in tijd in het Intune-beheercentrum, wat aangeeft wanneer het endpoint voor het laatst heeft gecommuniceerd met de Intune service. Endpoints die langere tijd offline zijn geweest, bijvoorbeeld vanwege netwerkproblemen, onderhoud, of omdat ze zijn uitgeschakeld, kunnen beleidsupdates hebben gemist die zijn uitgerold terwijl ze offline waren. In dergelijke gevallen moet het endpoint opnieuw worden verbonden met het netwerk en kan een handmatige beleidssynchronisatie worden geactiveerd via het Intune-beheercentrum door de optie Synchroniseren te selecteren voor het specifieke apparaat, of via het PowerShell script dat gebruik maakt van de Microsoft Graph API om een synchronisatieverzoek te sturen naar het endpoint. Het beschikbare remediatie script kan worden gebruikt om het auditbeleid direct te configureren op endpoints die niet via Intune kunnen worden bijgewerkt, bijvoorbeeld vanwege aanhoudende netwerkproblemen, tijdelijke Intune service onderbrekingen, of wanneer een snelle remediatie vereist is voordat de Intune beleidssynchronisatie kan worden voltooid. Het script configureert het lokale Groepsbeleidsobject door de juiste registerwaarden in te stellen die de auditbeleid configuratie bevatten, specifiek door de waarde voor Audit Beveiligingsgroepbeheer in te stellen op Succes in de Windows Beveiligingsbeleidsdatabase. Dit is een directe configuratie die onmiddellijk effect heeft zonder te wachten op Intune beleidssynchronisatie. Na het uitvoeren van het remediatie script moet het endpoint opnieuw worden gestart om ervoor te zorgen dat alle processen de nieuwe configuratie laden, of moet het Groepsbeleid worden geforceerd om te vernieuwen met behulp van de gpupdate /force opdracht die wordt uitgevoerd in een verhoogde PowerShell of Command Prompt sessie. De /force parameter zorgt ervoor dat alle beleidsinstellingen opnieuw worden toegepast, zelfs als er geen wijzigingen zijn gedetecteerd, wat belangrijk is om te zorgen dat de auditbeleid configuratie daadwerkelijk actief wordt. Na remediatie moet de configuratie worden geverifieerd met het monitoring script om te bevestigen dat de instelling correct is toegepast en dat het endpoint nu voldoet aan de vereisten. Deze verificatie moet worden uitgevoerd binnen een redelijke tijd na de remediatie, bijvoorbeeld binnen 24 uur, om te zorgen dat de configuratie daadwerkelijk is toegepast en om eventuele problemen snel te kunnen identificeren. Het is belangrijk om de hoofdoorzaak te identificeren waarom het beleid niet correct was toegepast om toekomstige problemen te voorkomen en om het beheerproces te verbeteren. Mogelijke oorzaken kunnen zijn: conflicterende Groepsbeleidsobjecten die het Intune beleid overschrijven, lokale beveiligingsbeleid overrides die zijn geconfigureerd door lokale beheerders of door andere management tools, problemen met de Intune service connectiviteit die voorkomen dat beleidsregels worden gedownload en toegepast, of incompatibele Windows versies die niet volledig worden ondersteund door de Intune beleidsconfiguratie. Een grondige analyse van de hoofdoorzaak helpt niet alleen bij het oplossen van het huidige probleem, maar ook bij het voorkomen van vergelijkbare problemen in de toekomst door het identificeren van systematische problemen die moeten worden aangepakt op organisatorisch niveau. Documentatie van remediatie acties is essentieel voor audit doeleinden en helpt bij het verbeteren van het beheerproces door een kennisbank op te bouwen van veelvoorkomende problemen en hun oplossingen. Deze documentatie moet worden bijgehouden in een centraal systeem, zoals een ticketing systeem of een kennisbank, en moet regelmatig worden gereviewd om trends te identificeren en het beheerproces continu te verbeteren.
Gebruik PowerShell-script audit-security-group-management-is-set-to-include-success.ps1 (functie Invoke-Remediation) – Het remediatie script herstelt de auditbeleid configuratie op endpoints die niet voldoen aan de vereisten..
Compliance en Audit
De implementatie van auditlogboekregistratie voor beveiligingsgroepbeheer draagt direct bij aan het voldoen aan verschillende compliance frameworks en regelgeving die van toepassing zijn op Nederlandse overheidsorganisaties, wat essentieel is voor het behouden van vertrouwen en het voldoen aan wettelijke verplichtingen. Deze compliance vereisten zijn niet alleen technische checkboxes die moeten worden afgevinkt, maar vormen de basis voor een robuust beveiligingsprogramma dat bescherming biedt tegen bedreigingen en dat vertrouwen geeft aan stakeholders dat de organisatie haar verantwoordelijkheden serieus neemt. De BIO Baseline Informatiebeveiliging Overheid vereist in control 16.01 dat organisaties gebeurtenissen loggen en audittrails onderhouden voor alle kritieke systemen en beveiligingsrelevante gebeurtenissen, waarbij specifiek wordt benadrukt dat deze logs moeten worden gebruikt voor monitoring, detectie van incidenten, en forensisch onderzoek. Het monitoren van beveiligingsgroepwijzigingen valt duidelijk onder deze vereiste, aangezien wijzigingen aan beveiligingsgroepen directe impact hebben op toegangsrechten en daarmee op de beveiliging van informatie. Elke wijziging aan een beveiligingsgroep kan resulteren in het verlenen of intrekken van toegangsrechten tot gevoelige systemen en data, wat betekent dat deze wijzigingen kritiek zijn voor de algehele beveiligingspostuur van de organisatie. Zonder adequate logging van deze wijzigingen kunnen organisaties niet voldoen aan de BIO vereisten en lopen ze het risico op niet-naleving tijdens audits. ISO 27001:2022 controle A.12.4.1 vereist eveneens logging en monitoring van gebeurtenissen, waarbij specifiek wordt benadrukt dat logs moeten worden beveiligd tegen wijziging en moeten worden bewaard voor een geschikte periode die is afgestemd op de risico's en compliance vereisten van de organisatie. Deze controle maakt deel uit van het bredere informatiebeveiligingsmanagementsysteem dat ISO 27001 vereist, en audit logging vormt een essentieel onderdeel van dit systeem. De logs moeten niet alleen worden gegenereerd, maar ook worden beschermd tegen ongeautoriseerde wijziging of verwijdering, wat betekent dat organisaties technische en organisatorische maatregelen moeten implementeren om de integriteit van de logs te waarborgen. De CIS Security Benchmark controle 18.9.19.2 specificeert expliciet dat audit policies moeten worden geconfigureerd om succesvolle beveiligingsgroepbeheer gebeurtenissen te loggen, wat een best practice is die wordt aanbevolen door cybersecurity experts wereldwijd. Deze controle maakt deel uit van de CIS Controls, een set van aanbevolen beveiligingsmaatregelen die zijn ontwikkeld door het Center for Internet Security en die worden beschouwd als industry standard voor cybersecurity best practices. Naast deze technische compliance vereisten is het belangrijk dat organisaties hun interne beleid documenteren met betrekking tot audit logging, waarbij dit beleid moet worden goedgekeurd door management en regelmatig moet worden gereviewd en bijgewerkt om te zorgen dat het actueel blijft en aansluit bij de huidige bedreigingslandschap en organisatorische behoeften. Dit beleid moet specificeren welke gebeurtenissen worden gelogd, hoe lang logs worden bewaard volgens een duidelijk retentiebeleid dat is afgestemd op compliance vereisten en organisatorische behoeften, wie toegang heeft tot de logs en onder welke omstandigheden, en hoe logs worden beveiligd tegen ongeautoriseerde toegang of wijziging door middel van technische controles zoals encryptie, access controls, en integrity monitoring. De documentatie moet ook procedures bevatten voor het analyseren van logs door beveiligingsanalisten, het reageren op verdachte activiteiten die worden gedetecteerd in de logs, en het rapporteren aan management en auditors over de status van audit logging en eventuele incidenten die zijn gedetecteerd. Regelmatige audits moeten worden uitgevoerd om te verifiëren dat de audit logging correct functioneert en dat de gegenereerde logs voldoen aan de kwaliteitseisen voor forensisch onderzoek, waarbij deze audits moeten worden uitgevoerd volgens een vastgesteld schema, bijvoorbeeld jaarlijks of halfjaarlijks, afhankelijk van de risico's en compliance vereisten. Deze audits kunnen intern worden uitgevoerd door de beveiligingsafdeling als onderdeel van het interne audit programma, of extern door onafhankelijke auditors die gespecialiseerd zijn in informatiebeveiliging en compliance. Externe audits bieden vaak meer objectiviteit en kunnen helpen bij het identificeren van blind spots die mogelijk worden gemist tijdens interne audits. De audit evidence die moet worden verzameld omvat configuratie screenshots van de Intune policy die aantonen dat de audit policy correct is geconfigureerd, output van het monitoring script die de compliance status van alle endpoints toont, en voorbeelden van gegenereerde audit log entries die aantonen dat de logging daadwerkelijk functioneert en relevante informatie bevat. Deze documentatie moet worden bewaard voor minimaal de retentieperiode zoals gespecificeerd in het audit beleid, typisch één jaar maar mogelijk langer afhankelijk van specifieke compliance vereisten of wettelijke verplichtingen zoals die kunnen gelden voor bepaalde sectoren of voor bepaalde soorten gegevens. De documentatie moet worden opgeslagen op een veilige locatie die beschermd is tegen verlies, wijziging, of ongeautoriseerde toegang, en moet worden georganiseerd op een manier die het gemakkelijk maakt om specifieke informatie te vinden tijdens audits of incident response activiteiten.
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 auditlogging in voor succesvolle beveiligingsgroepbeheer gebeurtenissen om volledige traceerbaarheid te garanderen en te voldoen aan compliance-vereisten voor logging en monitoring van toegangsrechten wijzigingen.
- Implementatietijd: 2 uur
- FTE required: 0.01 FTE