LSA Bescherming Ingeschakeld (credential Guard)

Het Local Security Authority-proces vormt het hart van de Windows-beveiligingsarchitectuur en is verantwoordelijk voor het beheer en de opslag van alle authenticatiegegevens op een Windows-systeem. Dit kritieke proces slaat verschillende soorten referenties op in het geheugen, waaronder leesbare wachtwoorden bij oudere Windows-versies, NTLM-hashes die worden gebruikt voor netwerkauthenticatie, Kerberos-tickets die toegang verlenen tot netwerkbronnen, en in de cache opgeslagen domeinreferenties die worden gebruikt voor offline authenticatie. Deze centrale opslag van gevoelige referenties maakt het LSA-proces tot een primair doelwit voor aanvallers die proberen toegang te krijgen tot netwerkbronnen zonder geldige inloggegevens te hebben. De aanvalsvector is duidelijk gedefinieerd: aanvallers die beheerdersrechten hebben verkregen, gebruiken gespecialiseerde tools zoals Mimikatz en ProcDump om het LSA-geheugen te dumpen, alle opgeslagen referenties te extraheren, en vervolgens laterale beweging uit te voeren door gebruik te maken van pass-the-hash-aanvallen waarbij gestolen referenties worden gebruikt om toegang te krijgen tot andere systemen in het netwerk. LSA-bescherming, ook wel bekend als RunAsPPL, beperkt dit kritieke risico aanzienlijk door het LSA-proces uit te voeren als een beschermd proces met Protected Process Light-status. Deze beschermde status betekent dat de Windows-kernel code signing-verificatie afdwingt, waardoor alleen vertrouwde en ondertekende code kan worden uitgevoerd binnen het LSA-proces. Niet-ondertekende code kan niet worden geïnjecteerd in het LSA-proces, wat betekent dat tools voor diefstal van inloggegevens zoals Mimikatz volledig falen omdat ze geen toegang hebben tot het beschermde geheugen waar de referenties zijn opgeslagen. De praktische impact van LSA-bescherming is enorm en kan het verschil betekenen tussen een beperkte inbreuk en een volledige compromittering van de organisatie. Vóór de implementatie van LSA-bescherming volgt een typisch aanvalsscenario een voorspelbaar patroon: een aanvaller compromitteert één beheerdersaccount, gebruikt Mimikatz om alle gecachte referenties uit het geheugen te dumpen, voert laterale beweging uit naar domeincontrollers en andere kritieke systemen, wat resulteert in volledige compromittering van het domein en mogelijk de volledige organisatie. Na de implementatie van LSA-bescherming verandert dit scenario drastisch: wanneer een aanvaller een beheerdersaccount compromitteert, faalt Mimikatz volledig bij het proberen toegang te krijgen tot het LSA-geheugen, laterale beweging wordt effectief geblokkeerd omdat er geen referenties kunnen worden gestolen, en de inbreuk blijft beperkt tot het oorspronkelijke gecompromitteerde systeem. Dit is bijzonder kritiek voor ransomwarepreventie, omdat moderne ransomwaregroepen volledig afhankelijk zijn van diefstal van inloggegevens voor laterale beweging door het netwerk. Zonder de mogelijkheid om referenties te stelen, kunnen deze groepen niet effectief door het netwerk bewegen om hun ransomware te verspreiden, waardoor LSA-bescherming een essentiële verdedigingslaag vormt in de strijd tegen ransomware-aanvallen.

Implementatie

LSA-bescherming wordt geactiveerd door een specifieke registerwaarde in te stellen die het Windows-besturingssysteem instrueert om het Local Security Authority-proces uit te voeren als een beschermd proces. De configuratie wordt uitgevoerd via het Windows-register door de waarde RunAsPPL in het pad HKLM:\SYSTEM\CurrentControlSet\Control\Lsa in te stellen op 1 als een DWORD-waarde. Deze registerwijziging is relatief eenvoudig uit te voeren, maar vereist beheerdersrechten en een herstart van het systeem om effectief te worden, omdat het LSA-proces alleen als beschermd proces kan worden gestart tijdens het opstartproces van Windows. Een modern alternatief voor basis LSA-bescherming is Windows Defender Credential Guard, dat een geavanceerdere vorm van bescherming biedt door gebruik te maken van hardwaregebaseerde isolatie via virtualisatie. Credential Guard biedt superieure bescherming door referenties volledig te isoleren van het besturingssysteem in een virtuele omgeving, maar heeft strengere hardwarevereisten. De basisvereisten voor LSA-bescherming omvatten Windows Enterprise-editie, omdat de Pro-versies van Windows deze beveiligingsfunctie niet ondersteunen. Daarnaast is UEFI-firmware met Secure Boot ingeschakeld vereist, omdat de beveiligingsfunctie afhankelijk is van deze hardwarebeveiligingsfuncties. Voor Credential Guard is bovendien TPM 2.0 vereist, wat Trusted Platform Module 2.0 betekent, een hardwarecomponent die cryptografische functies biedt. Verificatie van een succesvolle implementatie wordt uitgevoerd door het gebeurtenislogboek te controleren, specifiek gebeurtenis-ID 12 in het Microsoft-Windows-Wininit/Operational-logboek, wat bevestigt dat het LSA-proces is gestart als een beschermd proces en dat de beveiligingsfunctie actief is.

Vereisten

LSA-bescherming vereist specifieke hardware- en softwareconfiguraties om effectief te functioneren. Deze vereisten zijn essentieel omdat de beveiligingsfunctie afhankelijk is van diepgaande integratie met de Windows-kernel en hardwarebeveiligingsfuncties. Organisaties moeten zorgvuldig controleren of hun omgeving voldoet aan alle vereisten voordat ze LSA-bescherming implementeren.

Het besturingssysteem moet Windows 10 Enterprise of Windows 11 Enterprise zijn, of Windows Server 2016 of nieuwer. De Pro-versies van Windows ondersteunen LSA-bescherming niet, wat betekent dat organisaties die Windows 10 Pro of Windows 11 Pro gebruiken, moeten upgraden naar de Enterprise-editie. Deze beperking bestaat omdat LSA-bescherming gebruikmaakt van geavanceerde beveiligingsfuncties die alleen beschikbaar zijn in de Enterprise-editie. Voor Windows Server-omgevingen is versie 2016 of nieuwer vereist, waarbij versie 2019 en 2022 de voorkeur hebben vanwege verbeterde ondersteuning en prestaties.

De firmware moet UEFI zijn met Secure Boot ingeschakeld. Legacy BIOS-systemen worden niet ondersteund omdat LSA-bescherming afhankelijk is van UEFI-beveiligingsfuncties. Secure Boot zorgt ervoor dat alleen vertrouwde code wordt uitgevoerd tijdens het opstartproces, wat essentieel is voor de integriteit van het LSA-proces. Organisaties moeten controleren of hun hardware UEFI ondersteunt en Secure Boot correct is geconfigureerd in de firmware-instellingen. Sommige oudere systemen kunnen mogelijk niet upgraden naar UEFI, wat betekent dat deze systemen LSA-bescherming niet kunnen gebruiken.

Voor de Credential Guard-variant, die een hardwaregebaseerde isolatie biedt, is TPM 2.0 vereist. Trusted Platform Module 2.0 biedt hardwarematige cryptografische functies die nodig zijn voor de isolatie van referenties. Organisaties moeten verifiëren dat hun systemen TPM 2.0 hebben en dat deze correct is ingeschakeld in de BIOS- of UEFI-instellingen. TPM 1.2 wordt niet ondersteund voor Credential Guard, hoewel de basis LSA-bescherming (RunAsPPL) zonder TPM kan functioneren, zij het met minder isolatie.

Antiviruscompatibiliteit is een kritieke overweging. Sommige antivirusproducten zijn niet compatibel met LSA-bescherming omdat ze proberen het LSA-proces te monitoren of te injecteren, wat in strijd is met de beschermde processtatus. Organisaties moeten contact opnemen met hun antivirusleverancier om te verifiëren dat hun product volledig compatibel is met LSA-bescherming. Microsoft Defender Antivirus is volledig compatibel, evenals de meeste moderne enterprise-antivirusoplossingen. Echter, oudere of minder bekende antivirusproducten kunnen problemen veroorzaken.

Testen in een pilotomgeving is essentieel vanwege potentiële compatibiliteitsproblemen. Organisaties moeten LSA-bescherming eerst implementeren op een beperkt aantal testsystemen om te verifiëren dat alle applicaties en services correct blijven functioneren. Sommige legacy-applicaties of custom software kunnen problemen ondervinden wanneer LSA-bescherming is ingeschakeld, vooral als deze applicaties proberen toegang te krijgen tot LSA-functies. Een gefaseerde implementatie met grondige tests tussen elke fase is de aanbevolen aanpak.

Een geplande herstart is vereist voor activering. LSA-bescherming wordt alleen geactiveerd tijdens het opstartproces, wat betekent dat systemen moeten worden herstart nadat de registerinstelling is gewijzigd. Organisaties moeten een onderhoudsvenster plannen voor de implementatie om ervoor te zorgen dat alle systemen correct worden herstart en dat de beveiligingsfunctie wordt geactiveerd. Het is belangrijk om gebruikers tijdig te informeren over de geplande herstart om verstoring van de bedrijfsvoering te minimaliseren.

Implementatie

De implementatie van LSA-bescherming via Microsoft Intune biedt een gecentraliseerde en schaalbare aanpak voor organisaties die hun Windows-apparaten beheren via de cloud. Deze methode is bijzonder geschikt voor moderne hybride omgevingen waar apparaten zowel on-premises als op afstand worden beheerd. De implementatie via Intune zorgt voor consistente configuratie op alle doelapparaten en vereenvoudigt het beheer en de monitoring van de beveiligingsinstelling. Deze gecentraliseerde aanpak elimineert de noodzaak voor handmatige configuratie op individuele apparaten en zorgt ervoor dat alle apparaten dezelfde beveiligingsinstellingen hebben, wat essentieel is voor een uniforme beveiligingspostuur binnen de organisatie.

Om te beginnen navigeert de beheerder naar het Microsoft Endpoint Manager-beheercentrum, dat toegankelijk is via de Azure-portal. In het navigatiemenu aan de linkerkant wordt de optie Endpointbeveiliging geselecteerd, wat de centrale hub is voor alle beveiligingsconfiguraties voor Windows-apparaten. Binnen deze sectie wordt vervolgens de categorie Aanvalsoppervlakreductie gekozen, wat de juiste categorie is waarin LSA-bescherming valt. Deze categorie bevat verschillende beveiligingsinstellingen die gericht zijn op het verminderen van het aanvalsoppervlak van Windows-apparaten door specifieke beveiligingsfuncties in te schakelen die voorkomen dat aanvallers gebruikmaken van bekende aanvalsvectoren. Binnen deze categorie kan een nieuw beleid worden gemaakt door op Beleid maken te klikken, wat de wizard start voor het configureren van een nieuw beveiligingsbeleid.

Bij het maken van het beleid moet het platform worden ingesteld op Windows 10 en later, wat betekent dat het beleid van toepassing is op zowel Windows 10 als Windows 11-apparaten. Deze platformselectie zorgt ervoor dat het beleid alleen wordt toegepast op de juiste apparaten en voorkomt configuratiefouten op niet-ondersteunde systemen. Het profieltype moet worden ingesteld op Regels voor aanvalsoppervlakreductie, wat de juiste categorie is voor LSA-bescherming. Deze profieltype-selectie is belangrijk omdat het bepaalt welke configuratie-opties beschikbaar zijn in de wizard. Vervolgens moet de specifieke instelling worden geselecteerd: LSA-bescherming inschakelen (RunAsPPL), die moet worden ingesteld op Ingeschakeld. Deze instelling configureert het register automatisch om LSA-bescherming te activeren op alle doelapparaten door de registerwaarde RunAsPPL in te stellen op 1 in het pad HKLM:\SYSTEM\CurrentControlSet\Control\Lsa.

Na het configureren van de instelling moet het beleid worden toegewezen aan de juiste groepen. Organisaties kunnen het beleid toewijzen aan alle apparaten, specifieke beveiligingsgroepen, of apparaten die voldoen aan bepaalde voorwaarden. Het is aanbevolen om te beginnen met een pilotgroep om te verifiëren dat de implementatie correct verloopt voordat het beleid wordt uitgerold naar alle apparaten. Na toewijzing wordt het beleid automatisch geïmplementeerd op de doelapparaten tijdens de volgende synchronisatiecyclus.

Gebruik PowerShell-script lsa-bescherming-enabled.ps1 (functie Invoke-Remediation) – Schakel LSA-bescherming in via het register (herstart vereist).

Een kritiek aspect van de implementatie is dat apparaten moeten worden herstart om LSA-bescherming te activeren. De registerwijziging wordt weliswaar direct toegepast, maar het LSA-proces wordt alleen als beschermd proces gestart tijdens het opstartproces. Organisaties moeten daarom een geplande herstart coördineren voor alle doelapparaten. Dit kan worden gedaan via Intune door een herstart te forceren, of door gebruikers te informeren dat ze hun apparaten moeten herstarten binnen een bepaald tijdsbestek. Het is belangrijk om gebruikers tijdig te informeren om verstoring van de bedrijfsvoering te minimaliseren.

Verificatie van de implementatie is essentieel om te bevestigen dat LSA-bescherming correct is geactiveerd en effectief bescherming biedt tegen aanvallen. De primaire verificatiemethode is via het Windows-gebeurtenislogboek, dat een betrouwbare bron is voor het controleren van de status van systeembeveiligingsfuncties. Beheerders moeten het Gebeurtenislogboek openen, wat toegankelijk is via de Windows-beheerhulpprogramma's of door eventvwr.msc uit te voeren in het dialoogvenster Uitvoeren. Vervolgens moet worden genavigeerd naar Toepassings- en servicelogboeken, wat een uitgebreide verzameling van gespecialiseerde logboeken bevat die door verschillende Windows-componenten worden gegenereerd. Binnen deze sectie moet Microsoft-Windows-Wininit worden geselecteerd, wat het logboek is dat informatie bevat over het Windows-initialisatieproces. Het Operationele logboek binnen deze categorie moet worden geopend, wat de gedetailleerde gebeurtenissen bevat die tijdens het opstartproces worden gegenereerd. In dit logboek moet worden gezocht naar gebeurtenis-ID 12, die een kritieke indicator is dat LSASS.exe is gestart als een beschermd proces. Deze gebeurtenis bevat gedetailleerde informatie over de Protected Process Light-status en bevestigt definitief dat LSA-bescherming actief is en correct functioneert. De aanwezigheid van deze gebeurtenis na elke herstart is een sterke indicator dat de beveiligingsfunctie correct is geconfigureerd en operationeel is.

Een aanvullende verificatiemethode is het testen met Mimikatz of vergelijkbare tools voor diefstal van inloggegevens. Wanneer LSA-bescherming correct is geactiveerd, zullen deze tools falen met een toegang geweigerd-foutmelding wanneer ze proberen het LSA-proces te benaderen of geheugen te dumpen. Deze test moet alleen worden uitgevoerd in een gecontroleerde testomgeving door bevoegde beveiligingsprofessionals. Het succesvol blokkeren van Mimikatz is een sterke indicator dat LSA-bescherming effectief werkt.

Na de implementatie moeten organisaties een monitoringproces opzetten om te verifiëren dat LSA-bescherming actief blijft op alle apparaten. Dit kan worden geautomatiseerd via Intune-compliancebeleid of door regelmatige controles uit te voeren via PowerShell-scripts. Het is ook belangrijk om te monitoren op eventuele compatibiliteitsproblemen of applicatiefouten die kunnen optreden na de implementatie, zodat deze snel kunnen worden opgelost.

Monitoring

Gebruik PowerShell-script lsa-protection-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Continue monitoring van LSA-bescherming is essentieel om te verifiëren dat de beveiligingsfunctie actief blijft en effectief bescherming biedt tegen aanvallen. Monitoring moet worden geïmplementeerd als onderdeel van een bredere beveiligingsmonitoringstrategie en moet zowel technische verificatie als beveiligingsdetectie omvatten. Organisaties moeten regelmatig controleren of LSA-bescherming correct is geconfigureerd en actief is op alle doelapparaten.

De primaire monitoringmethode is het controleren van de registerwaarde RunAsPPL in het pad HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. Deze waarde moet ingesteld zijn op 1 (DWORD) om LSA-bescherming te activeren. Monitoring kan worden geautomatiseerd via PowerShell-scripts die regelmatig de registerwaarde controleren op alle beheerde apparaten. Intune biedt ook de mogelijkheid om compliancebeleid te configureren dat automatisch controleert of de registerwaarde correct is ingesteld en nietieve meldingen genereert wanneer afwijkingen worden gedetecteerd.

Gebeurtenislogboekmonitoring is een kritieke component van de monitoringstrategie. Gebeurtenis-ID 12 in het Microsoft-Windows-Wininit/Operational-logboek bevestigt dat LSASS.exe is gestart als een beschermd proces. Deze gebeurtenis moet worden gegenereerd bij elke herstart van het systeem wanneer LSA-bescherming actief is. Organisaties moeten een SIEM-systeem of logaggregatieoplossing configureren om deze gebeurtenissen te verzamelen en te analyseren. Het ontbreken van gebeurtenis-ID 12 na een herstart kan wijzen op een probleem met de LSA-beschermingconfiguratie of een poging tot uitschakeling van de beveiliging.

Microsoft Defender voor Endpoint biedt geavanceerde monitoringmogelijkheden voor aanvallen gericht op diefstal van inloggegevens. Wanneer LSA-bescherming actief is, zullen pogingen om Mimikatz of vergelijkbare tools te gebruiken worden gedetecteerd en gegenereerd als waarschuwingen in de Defender voor Endpoint-console. Deze waarschuwingen geven aan dat een aanvaller heeft geprobeerd toegang te krijgen tot het LSA-proces, wat een indicator kan zijn van een actieve aanval. Organisaties moeten deze waarschuwingen configureren voor automatische escalatie naar het security operations center (SOC) voor onmiddellijke respons.

Naast technische monitoring moeten organisaties ook procesmatige controles uitvoeren. Regelmatige audits moeten worden uitgevoerd om te verifiëren dat LSA-bescherming is geïmplementeerd op alle vereiste apparaten en dat er geen uitzonderingen zijn gemaakt zonder goede rechtvaardiging. Deze audits moeten worden gedocumenteerd en gerapporteerd aan het management als onderdeel van de algemene beveiligingsrapportage. Compliance-rapportage moet ook LSA-beschermingstatus opnemen als onderdeel van de beveiligingspostuur van de organisatie.

Monitoring moet ook aandacht besteden aan prestatie-impact en compatibiliteitsproblemen. Hoewel LSA-bescherming over het algemeen minimale prestatie-impact heeft, moeten organisaties monitoren op eventuele prestatieproblemen of applicatiefouten die kunnen optreden. Eventuele problemen moeten worden onderzocht en opgelost, waarbij wordt overwogen of het probleem wordt veroorzaakt door LSA-bescherming of door andere factoren. Documentatie van eventuele problemen en oplossingen helpt bij toekomstige implementaties en troubleshooting.

Automatisering van monitoring is essentieel voor schaalbaarheid en consistentie. PowerShell-scripts kunnen worden geconfigureerd om regelmatig te draaien en rapporten te genereren over de status van LSA-bescherming op alle apparaten. Deze scripts kunnen worden geïntegreerd met monitoringtools zoals Microsoft System Center Operations Manager (SCOM) of Azure Monitor voor geavanceerde dashboards en waarschuwingen. Automatische waarschuwingen moeten worden geconfigureerd voor scenario's zoals het uitschakelen van LSA-bescherming, het ontbreken van gebeurtenis-ID 12 na een herstart, of detectie van aanvallen gericht op diefstal van inloggegevens. Deze geautomatiseerde aanpak zorgt ervoor dat beveiligingsproblemen snel worden geïdentificeerd en aangepakt, wat essentieel is voor het handhaven van een sterke beveiligingspostuur in grote omgevingen met honderden of duizenden apparaten.

Compliance en Auditing

LSA-bescherming is een essentiële beveiligingscontrole die vereist is voor naleving van verschillende cybersecurity-standaarden en regelgeving. Nederlandse overheidsorganisaties moeten voldoen aan meerdere compliance-frameworks, en LSA-bescherming draagt bij aan de naleving van verschillende van deze vereisten. Het is belangrijk om te begrijpen hoe LSA-bescherming past binnen elk compliance-framework en welke specifieke controles worden afgedekt.

De CIS Windows Benchmark, een internationaal erkende beveiligingsstandaard, vereist expliciet dat LSA-bescherming is ingeschakeld. Deze benchmark wordt veel gebruikt door organisaties wereldwijd als basis voor hun Windows-beveiligingsconfiguratie. De CIS Benchmark classificeert LSA-bescherming als een Level 1 controle, wat betekent dat het wordt aanbevolen voor alle omgevingen, inclusief die met beperkte beveiligingsvereisten. Nederlandse organisaties die de CIS Benchmark volgen, moeten LSA-bescherming implementeren om volledige compliance te bereiken. Audits tegen de CIS Benchmark zullen controleren of de registerwaarde RunAsPPL correct is ingesteld en of gebeurtenislogboeken bevestigen dat LSA-bescherming actief is.

De Baseline Informatiebeveiliging Overheid (BIO) norm 12.02 vereist bescherming tegen malware en exploits. Diefstal van inloggegevens via tools zoals Mimikatz wordt beschouwd als een malware-aanvalsvector omdat het gebruikmaakt van kwaadaardige software om beveiligingscontroles te omzeilen. LSA-bescherming biedt directe bescherming tegen deze aanvalsvector door te voorkomen dat tools voor diefstal van inloggegevens toegang krijgen tot het LSA-proces. Voor Nederlandse overheidsorganisaties is naleving van de BIO-normen verplicht, en LSA-bescherming is een effectieve manier om te voldoen aan de vereisten van norm 12.02. Tijdens BIO-audits moeten organisaties kunnen aantonen dat LSA-bescherming is geïmplementeerd en actief is op alle relevante systemen.

ISO 27001 controle A.8.7 vereist bescherming tegen malware door middel van detectie, preventie en herstelmaatregelen. LSA-bescherming valt onder preventiemaatregelen omdat het voorkomt dat kwaadaardige tools toegang krijgen tot gevoelige referenties in het geheugen. Organisaties die gecertificeerd zijn voor ISO 27001 of streven naar certificering moeten kunnen aantonen dat ze passende maatregelen hebben genomen om malware-aanvallen te voorkomen. LSA-bescherming is een concrete technische controle die bijdraagt aan de naleving van deze ISO 27001-vereiste. Tijdens ISO 27001-audits moeten organisaties documentatie kunnen overleggen die aantoont dat LSA-bescherming is geïmplementeerd, gemonitord en onderhouden.

De NIS2-richtlijn, die van toepassing is op essentiële en belangrijke entiteiten in de Europese Unie, vereist in artikel 21 dat organisaties passende cybersecurity-maatregelen implementeren. LSA-bescherming is een essentiële technische beveiligingsmaatregel die bijdraagt aan de algehele cybersecurity-postuur van een organisatie. Nederlandse organisaties die onder de NIS2-richtlijn vallen, moeten kunnen aantonen dat ze passende maatregelen hebben genomen om hun systemen te beschermen tegen cyberaanvallen. LSA-bescherming is een concrete maatregel die helpt bij het voorkomen van laterale beweging door aanvallers, wat een kritieke beveiligingscontrole is. NIS2-compliance vereist ook dat organisaties regelmatig hun beveiligingsmaatregelen evalueren en bijwerken, wat betekent dat LSA-bescherming moet worden gemonitord en onderhouden.

Voor auditdoeleinden moeten organisaties documentatie bijhouden die aantoont dat LSA-bescherming is geïmplementeerd en actief is. Deze documentatie moet omvatten: configuratie-instellingen, implementatiedata, verificatieresultaten, monitoringrapporten en eventuele incidenten of problemen. Auditbewijs moet kunnen worden overlegd tijdens externe audits en moet regelmatig worden bijgewerkt om de huidige status te reflecteren. Organisaties moeten ook procedures hebben voor het reageren op auditvragen over LSA-bescherming en moeten kunnen uitleggen hoe deze controle bijdraagt aan de algehele beveiligingspostuur.

Naast de specifieke compliance-frameworks is LSA-bescherming ook relevant voor algemene beveiligingsbest practices en risicobeheer. Organisaties moeten LSA-bescherming opnemen in hun risicoanalyses en beveiligingsassessments. De implementatie van LSA-bescherming moet worden gedocumenteerd in beveiligingsbeleid en procedures, en medewerkers moeten worden getraind over het belang van deze beveiligingscontrole. Regelmatige compliance-controles moeten verifiëren dat LSA-bescherming actief blijft en dat er geen ongerechtvaardigde uitzonderingen zijn gemaakt.

Remediatie

Gebruik PowerShell-script lsa-protection-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring of compliance-controles aangeven dat LSA-bescherming niet actief is op een apparaat, moet onmiddellijk remediatie worden uitgevoerd. Remediatie omvat het herstellen van de juiste configuratie om ervoor te zorgen dat LSA-bescherming opnieuw wordt geactiveerd. Het is belangrijk om te begrijpen waarom LSA-bescherming is uitgeschakeld voordat remediatie wordt uitgevoerd, omdat dit kan wijzen op een beveiligingsincident of een configuratiefout.

De primaire remediatiestap is het controleren en herstellen van de registerwaarde RunAsPPL in het pad HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. Deze waarde moet worden ingesteld op 1 (DWORD) om LSA-bescherming te activeren. Als de waarde is gewijzigd naar 0 of is verwijderd, moet deze worden hersteld naar 1. PowerShell-scripts kunnen worden gebruikt om deze remediatie automatisch uit te voeren, wat bijzonder nuttig is wanneer meerdere apparaten moeten worden hersteld. Intune biedt ook de mogelijkheid om automatische remediatie te configureren via compliancebeleid, waardoor apparaten automatisch worden hersteld wanneer afwijkingen worden gedetecteerd.

Na het herstellen van de registerwaarde moet het apparaat worden herstart om LSA-bescherming te activeren. Het LSA-proces wordt alleen als beschermd proces gestart tijdens het opstartproces, dus een herstart is essentieel. Organisaties moeten procedures hebben voor het coördineren van herstarts, vooral voor kritieke systemen. In sommige gevallen kan een geplande herstart worden georganiseerd, terwijl in andere gevallen een onmiddellijke herstart vereist kan zijn afhankelijk van het beveiligingsrisico.

Na remediatie moet verificatie worden uitgevoerd om te bevestigen dat LSA-bescherming correct is hersteld. Dit omvat het controleren van de registerwaarde, het verifiëren van gebeurtenis-ID 12 in het gebeurtenislogboek, en indien mogelijk het testen met Mimikatz om te bevestigen dat tools voor diefstal van inloggegevens worden geblokkeerd. Verificatie moet worden gedocumenteerd als onderdeel van het remediatieproces.

Als LSA-bescherming herhaaldelijk wordt uitgeschakeld, moet een diepgaand onderzoek worden uitgevoerd om de onderliggende oorzaak te identificeren. Mogelijke oorzaken zijn: kwaadaardige software die LSA-bescherming probeert uit te schakelen, onjuiste configuratiewijzigingen door beheerders, compatibiliteitsproblemen met software, of een actieve aanval. Het onderzoek moet worden uitgevoerd door beveiligingsprofessionals en kan forensische analyse omvatten om te bepalen hoe en wanneer LSA-bescherming is uitgeschakeld.

Preventieve maatregelen moeten worden geïmplementeerd om te voorkomen dat LSA-bescherming opnieuw wordt uitgeschakeld. Dit kan omvatten: het beperken van beheerdersrechten, het implementeren van wijzigingscontrole voor registerinstellingen, het configureren van waarschuwingen voor wijzigingen aan LSA-configuratie, en het regelmatig monitoren van de status van LSA-bescherming. Organisaties moeten ook procedures hebben voor het goedkeuren van uitzonderingen wanneer LSA-bescherming tijdelijk moet worden uitgeschakeld voor troubleshooting of compatibiliteitstests.

Documentatie van remediatie-acties is essentieel voor compliance en auditdoeleinden. Alle remediatie-acties moeten worden gedocumenteerd met details over wanneer de actie is uitgevoerd, wie de actie heeft uitgevoerd, waarom remediatie nodig was, en wat de resultaten waren. Deze documentatie helpt bij het identificeren van patronen of terugkerende problemen en kan worden gebruikt tijdens audits om aan te tonen dat de organisatie proactief omgaat met beveiligingsproblemen.

Compliance & Frameworks

• CIS M365: Control Windows Security (L1) - LSA bescherming ingeschakeld
• BIO: 12.02.01 - Malware en exploit bescherming
• ISO 27001:2022: A.8.7 - Bescherming tegen malware
• NIS2: Artikel - Cybersecurity risicobeheer

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 LSA-bescherming (RunAsPPL) in om diefstal van inloggegevens via Mimikatz- en pass-the-hash-aanvallen te voorkomen. Vereist Windows Enterprise, Secure Boot en een herstart. Voldoet aan CIS, BIO 12.02 en NIS2. Implementatie: 8-12 uur inclusief testen en gefaseerde uitrol. KRITIEKE beveiligingscontrole.

• Implementatietijd: 12 uur
• FTE required: 0.1 FTE