Zo verifieert u Local Security Authority Protection in Windows 11

Het proces LSASS (Local Security Authority Subsystem Service) is een kerncomponent van Windows die verantwoordelijk is voor gebruikersauthenticatie, het handhaven van beveiligingsbeleid en het genereren van toegangstokens die de toegang tot systeembronnen regelen. Omdat LSASS gevoelig referentiemateriaal verwerkt en opslaat (bijvoorbeeld wachtwoord-hashes en Kerberos-tickets), is het een waardevol doelwit voor aanvallers. Bij een compromittering kunnen aanvallers referenties uit het geheugen halen, rechten verhogen en zich lateraal door systemen bewegen.

Local Security Authority Protection (LSA-beveiliging) is een cruciale beveiligingsmaatregel in Windows 11 om dat risico te verkleinen. De functie beschermt het LSASS-proces door het als beveiligd proces uit te voeren en de toegang te beperken tot vertrouwde, ondertekende componenten. Zo voorkomt u ongeautoriseerde geheugentoegang, code-injectie en veelvoorkomende technieken voor referentiediefstal. Om te controleren of LSA-beveiliging actief is, moet u echter meerdere systeemindicatoren nakijken in plaats van één schakelaar in de gebruikersinterface.

Lees verder voor een praktische workflow waarmee beheerders en managed service providers (MSP’s) de LSA-beveiliging in Windows 11 kunnen verifiëren.

Zo controleert u of Local Security Authority Protection aanstaat

Het is belangrijk om de LSA-beveiliging vanuit meerdere invalshoeken te valideren, zeker in beheerde omgevingen. De volgende stappen leiden u langs controles in de UI, registerwaarden, bewijs uit gebeurtenissenlogboeken, beleidscontext en ondersteunende beveiligingsfuncties zodat u zeker weet dat LSASS als beveiligd proces draait.

📌 Vereisten:

• Lokale beheerdersrechten op het endpoint
• Toegang tot Windows-beveiliging, Logboeken en een shell met verhoogde rechten (bijvoorbeeld PowerShell of de opdrachtprompt)
• Een formele wijzigingsregistratie voor elke herstelactie

Stap 1: Windows-beveiliging controleren

Controleer eerst de status in Windows-beveiliging om te zien hoe het systeem de LSA-beveiliging op dit moment rapporteert. In deze stap ziet u ook of er waarschuwingen of aanbevelingen zijn die directe aandacht vragen.

1. Ga naar Instellingen > Privacy en beveiliging > Windows-beveiliging > Apparaatbeveiliging > Details over kernisolatie.
2. Zoek de schakelaar Local Security Authority-beveiliging en controleer of deze op Aan staat.
3. Bekijk de aanbevelingen of waarschuwingen die aan de gebruiker worden getoond.
4. Maak een screenshot als er bewijs nodig is voor een audit of voor het ticketsysteem.

Stap 2: Bevestigen via het register

Controleer vervolgens het register om te weten of de LSA-beveiliging ook op systeemniveau is geconfigureerd. Zo kunt u onderscheid maken tussen weergaveproblemen in de UI en de werkelijke bedoeling van de beveiliging.

1. Open de Register-editor met beheerdersrechten.
2. Ga naar HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Bekijk RunAsPPL en controleer of deze op 1 of 2 staat. Daarmee is LSA-beveiliging ingeschakeld (met of zonder UEFI-lock) en draait LSASS na een reboot als beveiligd proces.
4. Bekijk RunAsPPLBoot en controleer of deze op 1 of 2 staat. Daarmee wordt LSA-beveiliging eerder in het bootproces afgedwongen, waarbij 2 strenger is omdat de instelling op ondersteunde systemen wordt vergrendeld tegen manipulatie.
5. Gebruik deze waarden samen met de gebeurtenissenlogboeken uit de volgende stap om het gedrag tijdens runtime te bevestigen.

Stap 3: Valideren met gebeurtenissenlogboeken

Gebeurtenissenlogboeken geven gezaghebbende bevestiging of LSASS daadwerkelijk als beveiligd proces is gestart en laten zien welke plug-ins niet konden worden geladen onder de beveiligingsvereisten.

1. Open Logboeken.
2. Blader naar Logboeken van toepassingen en services > Microsoft > Windows > CodeIntegrity > Operational.
3. Zoek naar Code Integrity-gebeurtenissen (bijvoorbeeld event-ID 3065 of 3089) die aangeven dat LSASS als beveiligd proces is gestart en die LSA-plug-ins markeren die zijn geblokkeerd of niet konden worden geladen.
4. Volg de auditrichtlijnen van Microsoft voor verdere analyse.

Stap 4: Verifiëren met PowerShell en beleidscontext

Daarnaast helpen PowerShell en beleidsvalidatie om te bevestigen dat LSA-beveiliging is ingeschakeld en door beheertools wordt afgedwongen, zodat de instelling OS-updates overleeft en niet door eindgebruikers kan worden gewijzigd.

1. Gebruik een PowerShell-sessie met verhoogde rechten om de LSA-gerelateerde registerwaarden te bevestigen en de geconfigureerde status te verifiëren met deze opdracht:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL","RunAsPPLBoot" -ErrorAction SilentlyContinue

2. Controleer of Groepsbeleid of MDM de LSA-beveiliging afdwingt, zodat deze updates overleeft en lokale UI-instellingen overschrijft.

Stap 5: LSASS en Credential Guard tegen elkaar afzetten

Valideer ook hoe LSA-beveiliging samenwerkt met Credential Guard, want beide functies steunen op beveiligd LSASS-gedrag en op virtualisatiegebaseerde beveiliging. Het zijn echter losse verhardingsfuncties, dus door hun onderlinge afstemming te bevestigen voorkomt u configuratiefouten die de isolatie kunnen verzwakken of onverwachte waarschuwingen kunnen veroorzaken.

1. Bevestig dat Credential Guard is ingeschakeld.
2. Bevestig dat LSASS als beveiligd proces draait door de registerwaarden van RunAsPPL en de beveiligde opstartgebeurtenissen uit de vorige stappen te valideren.
3. Controleer de controlelogboeken van Code Integrity en LSA op fouten die duiden op geblokkeerde componenten of conflicten tussen Credential Guard en LSA-beveiliging.
4. Noteer elk verschil tussen de verwachte en de werkelijke status zodat dit vóór verdere validatie kan worden verholpen.

Stap 6: Bewijs vastleggen voor de audit

Verzamel altijd duidelijk en verifieerbaar bewijs zodat u bevindingen later kunt nakijken en problemen veel eenvoudiger kunt oplossen.

1. Maak screenshots van de status van de LSA-beveiliging in Windows-beveiliging.
2. Exporteer de relevante registersleutels uit HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Noteer de event-ID’s die de beveiligde start van LSASS bevestigen of plug-inproblemen aanwijzen.
4. Noteer de apparaatnaam, de Windows-build en het geldende beleidsbereik en sla het bewijs op in uw RMM of ticketsysteem.

Stap 7: Inconsistente statussen verhelpen

Kom tot slot in actie wanneer de signalen over LSA-beveiliging in de UI, het register en de gebeurtenissenlogboeken niet overeenkomen. Pak die inconsistenties aan zodat het device daadwerkelijk beschermd is en de gerapporteerde status klopt.

• Pas het betreffende beleid opnieuw toe als de UI aangeeft dat LSA-beveiliging uitstaat terwijl register- en beleidswaarden aangeven dat deze aanstaat.
• Reboot het device en herhaal dit zo nodig totdat Windows-beveiliging, de registerwaarden en de Code Integrity-gebeurtenissen consistent laten zien dat LSASS als beveiligd proces start.
• Onderzoek waarschuwingsstatussen of meldingen over niet-ondertekende LSA-pakketten in Windows-beveiliging.
• Gebruik uw bestaande oplossings- of herstelartikel om niet-conforme plug-ins of stuurprogramma’s te verhelpen.
• Valideer de configuratie na het herstel opnieuw om te bevestigen dat de status in alle bronnen consistent is.

Beste praktijken in het kort

Hieronder staan enkele beste praktijken die helpen om de LSA-beveiliging consistent te valideren en betrouwbaar af te dwingen. Ze nemen onduidelijkheid weg en versnellen onderzoeken.

Wat is LSA-beveiliging en waarom controleert u die?

LSA-beveiliging is een Windows-beveiligingsfunctie die LSASS als beveiligd proces uitvoert. Daarmee voorkomt u dat niet-vertrouwde code zich in het proces injecteert en worden pogingen geblokkeerd om referenties uit het geheugen te stelen. De functie verhardt een van de gevoeligste onderdelen van het besturingssysteem en vormt de basis van moderne beveiligingsmaatregelen voor referenties, zoals Credential Guard.

Verificatie is cruciaal om:

• Te garanderen dat LSASS niet alleen is geconfigureerd, maar ook echt als beveiligd proces draait.
• Verschillen tussen de UI, het register en de beleidshandhaving op te sporen.
• Te zorgen dat de beveiliging behouden blijft na upgrades of beleidswijzigingen.
• Onbeveiligde of incompatibele LSA-plug-ins te vinden die de beveiliging verzwakken.
• Bewijs te leveren voor audits, compliance-controles en beveiligingsonderzoeken.

Problemen oplossen

Bij het verifiëren van de LSA-beveiliging kunt u enkele veelvoorkomende problemen tegenkomen. Gebruik de volgende stappen zodat het device zijn beveiligingsbeleid correct rapporteert.

LSA staat uit na een upgrade

Controleer of het bedrijfsbeleid nog steeds wordt toegepast en of de waarden van RunAsPPL nog zijn geconfigureerd. Sommige Windows-upgrades zetten beveiligingsinstellingen terug, dus mogelijk is een reboot nodig. Blijft de instelling niet behouden, pas het beleid dan opnieuw toe en controleer het nogmaals.

De schakelaar in de UI ontbreekt of is grijs

Meestal betekent dit dat de instelling door een bedrijfsbeleid wordt bepaald in plaats van lokaal. Controleer de beleidsvolgorde en bevestig dat het register de afgedwongen status weergeeft. Ook niet-ondersteunde of verouderde configuraties kunnen de schakelaar onbeschikbaar maken.

Waarschuwingen dat plug-ins niet beveiligd zijn

Raadpleeg de auditrichtlijnen van Microsoft om te bepalen welke plug-ins of stuurprogramma’s niet beveiligd konden worden geladen. Werk de niet-conforme componenten bij, verwijder ze of vervang ze om het juiste LSA-gedrag te herstellen. Controleer daarna opnieuw de gebeurtenissenlogboeken om te zien of er geen andere plug-ins zijn getroffen.

Analisten halen LSA en LSASS door elkaar

Maak duidelijk dat LSA het subsysteem is dat verantwoordelijk is voor het authenticatiebeleid, terwijl LSASS het proces is dat dat beleid uitvoert. Een korte interne toelichting helpt om terugkerende verwarring te beperken.

LSA-beveiliging valideren voor duurzame beveiliging

Het verifiëren van LSA-beveiliging vraagt om een gestructureerde aanpak waarmee u zeker weet dat LSASS echt als beveiligd proces draait. Door de besproken workflow te volgen, van het valideren van registerwaarden tot het wegwerken van inconsistenties, houden MSP’s en beheerders de omgeving op lange termijn stabiel.

Gerelateerde onderwerpen:

• Credential Guard en LSA-beveiliging inschakelen op clientdevices
• Local Security Authority Protection in- of uitschakelen in Windows 11
• De waarschuwing “LSA-pakket is niet zoals verwacht ondertekend” oplossen in Windows 11
• Alle instellingen van het lokale beveiligingsbeleid terugzetten naar de standaardwaarden in Windows