Come verificare la protezione LSA in Windows 11

Il processo LSASS (Local Security Authority Subsystem Service) è un componente fondamentale di Windows responsabile dell’autenticazione degli utenti, dell’applicazione dei criteri di sicurezza e della generazione dei token di accesso che controllano l’accesso alle risorse di sistema. Poiché LSASS elabora e memorizza dati sensibili relativi alle credenziali (per esempio hash delle password, ticket Kerberos), rappresenta un obiettivo di grande valore per gli aggressori. In caso di compromissione, gli aggressori possono estrarre le credenziali dalla memoria, elevare i privilegi e spostarsi lateralmente tra i sistemi.

La protezione offerta dall’Autorità di sicurezza locale (LSA) è un controllo di sicurezza fondamentale di Windows 11, progettato per ridurre tale rischio. Protegge il processo LSASS eseguendolo come processo protetto e limitando l’accesso esclusivamente a componenti affidabili e firmati. Ciò contribuisce a prevenire accessi non autorizzati alla memoria, iniezione di codice e tecniche più comuni di furto delle credenziali. Tuttavia, per verificare che la protezione LSA sia abilitata, è necessario controllare diversi indicatori di sistema anziché una semplice opzione nell’interfaccia utente.

Continua a leggere per scoprire una procedura pratica che consente agli amministratori e ai fornitori di servizi gestiti (MSP) di verificare la protezione LSA in Windows 11.

Come verificare se la protezione dell’Autorità di sicurezza locale è attiva

È importante verificare la protezione LSA da diversi punti di vista, soprattutto negli ambienti gestiti. I passaggi seguenti ti guideranno attraverso i controlli dell’interfaccia utente, i valori del Registro di sistema, le informazioni contenute nei log eventi, il contesto dei criteri e le funzionalità di sicurezza di supporto, al fine di garantire che LSASS sia in esecuzione come processo protetto.

📌 Prerequisiti:

• Diritti di amministratore locale sull’endpoint
• Accesso per “Sicurezza di Windows”, “Visualizzatore eventi” e una shell con privilegi elevati (per es. PowerShell, Prompt dei comandi)
• Registro formale delle modifiche relative a qualsiasi intervento correttivo

Fase 1: Verifica la sicurezza di Windows

Per prima cosa, verifica lo stato in Sicurezza di Windows per capire come il sistema segnali attualmente la protezione LSA. In questa fase potrai anche verificare se ci sono avvisi o raccomandazioni che richiedono la tua immediata attenzione.

1. Accedi a Impostazioni > Privacy e sicurezza > Sicurezza di Windows > Sicurezza del dispositivo > Dettagli sull’isolamento del core.
2. Individua l’opzione di protezione “Autorità di sicurezza locale” e verifica che sia Attivata.
3. Esamina eventuali raccomandazioni o avvertenze per gli utenti.
4. Se sono necessarie prove a fini di audit o ticketing, cattura uno screenshot.

Fase 2: Conferma tramite il registro di sistema

Successivamente, controlla il Registro di sistema per verificare se la protezione LSA è configurata anche a livello di sistema. Questo ti consentirà di distinguere tra i problemi di visualizzazione dell’interfaccia utente e l’effettivo scopo di protezione.

1. Apri l’Editor del Registro di sistema con diritti di amministratore.
2. Vai su HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Controlla RunAsPPL e assicurati che sia impostato su 1 oppure 2, per abilitare la protezione LSA (con o senza UEFI Lock), in modo che LSASS venga eseguito come processo protetto dopo il riavvio.
4. Controlla RunAsPPLBoot e assicurati che sia impostato su 1 oppure 2, in modo da applicare la protezione LSA in una fase precedente del processo di avvio; inoltre, 2 garantisce un’applicazione più rigorosa, bloccando l’impostazione contro eventuali manomissioni sui sistemi supportati.
5. Utilizza questi valori insieme ai log eventi nel passaggio successivo per verificare il comportamento in fase di esecuzione.

Fase 3: Verifica tramite i log eventi

I log eventi possono inoltre fornire una conferma attendibile del fatto che LSASS sia stato effettivamente avviato come processo protetto e rivelare eventuali plug-in che non sono stati caricati a causa dei requisiti di protezione.

1. Apri il Visualizzatore eventi.
2. Vai su Log di applicazioni e servizi > Microsoft > Windows > Integrità del codice > Operativo.
3. Cerca gli eventi relativi all’integrità del codice (per esempio ID evento 3065 o 3089) che indicano che LSASS è stato avviato come processo protetto e segnala eventuali plug-in LSA che sono stati bloccati o che non sono stati caricati correttamente.
4. Per ulteriori analisi, segui le linee guida di Microsoft in materia di audit.

Fase 4: Verifica tramite PowerShell e il contesto dei criteri

Inoltre, la verifica tramite PowerShell e con i criteri possono aiutare ad assicurarsi che la protezione LSA sia abilitata e applicata dagli strumenti di gestione, in modo che l’impostazione rimanga invariata anche dopo gli aggiornamenti del sistema operativo e non possa essere modificata dagli utenti finali.

1. Utilizza una sessione PowerShell con privilegi elevati per verificare i valori del Registro di sistema relativi a LSA e controllare lo stato della configurazione utilizzando questo comando:

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

2. Verifica che i Criteri di gruppo o l’MDM impongano la protezione LSA in modo che rimanga attiva anche dopo gli aggiornamenti e prevalga sulle impostazioni dell’interfaccia utente locale.

Fase 5: Verifica incrociata dello stato di LSASS e Credential Guard

È inoltre opportuno verificare come la protezione LSA interagisca con Credential Guard, poiché entrambe le funzionalità si basano sul comportamento protetto di LSASS e sulla sicurezza basata sulla virtualizzazione. Tuttavia, trattandosi di funzioni di hardening distinte, verificarne la corretta corrispondenza consente di evitare configurazioni errate che potrebbero compromettere l’isolamento o generare avvisi imprevisti.

1. Verifica che Credential Guard sia abilitato.
2. Verifica che LSASS sia in esecuzione come processo protetto controllando i valori del registro di RunAsPPL e gli eventi di avvio protetti identificati nei passaggi precedenti.
3. Verifica i log di integrità dei codici e di audit LSA alla ricerca di errori che indichino componenti bloccati o conflitti tra Credential Guard e la protezione LSA
4. Registra eventuali discrepanze tra la postura prevista e quella effettiva, in modo che possano essere corrette prima di procedere con un’ulteriore verifica.

Fase 6: Documentazione a fini di audit

Per assicurarti di poter riesaminare i risultati in un secondo momento e semplificare notevolmente la risoluzione dei problemi, raccogli sempre prove chiare e verificabili.

1. Acquisisci screenshot dello stato di protezione LSA da Sicurezza di Windows.
2. Esporta le chiavi di registro pertinenti da HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Registra gli ID degli eventi che confermano l’avvio protetto di LSASS o che indicano problemi relativi ai plug-in.
4. Prendi nota del nome del dispositivo, della versione di Windows e dell’ambito di applicazione del criterio, quindi archivia la documentazione nel tuo sistema RMM o nel sistema di gestione dei ticket.

Passo 7: Risolvi le incongruenze relative allo stato

Infine, assicurati di intervenire quando i segnali di protezione LSA non corrispondono tra l’interfaccia utente, il Registro di sistema e i log eventi. Risolvi queste incongruenze per garantire che il dispositivo sia effettivamente protetto e che lo stato segnalato sia accurato.

• Riapplica il criterio pertinente se l’interfaccia utente indica che la protezione LSA è disattivata, ma i valori del Registro di sistema e dei criteri indicano che è attivata.
• Riavvia il dispositivo e, se necessario, ripeti l’operazione finché gli eventi di Sicurezza di Windows, i valori del Registro di sistema e quelli relativi all’integrità del codice non indicano in modo coerente che LSASS viene avviato come processo protetto.
• Analizza gli stati di avviso o i messaggi relativi ai pacchetti LSA non firmati visualizzati in “Sicurezza di Windows”.
• Utilizza l’articolo esistente relativo alla correzione o alla risoluzione del problema per risolvere i problemi relativi a plug-in o driver non conformi.
• Dopo aver risolto il problema, verifica nuovamente la configurazione per assicurarti che lo stato sia coerente in tutte le fonti.

Riepilogo delle best practice

Di seguito sono riportate alcune best practice volte a garantire che la protezione LSA venga costantemente verificata e applicata in modo affidabile. Ciò dovrebbe ridurre le ambiguità e accelerare le indagini.

Che cos’è la protezione LSA e perché è importante verificarla?

La protezione LSA è una funzionalità di sicurezza di Windows che esegue LSASS come processo protetto, impedendo a codice non attendibile di infiltrarsi al suo interno e bloccando i tentativi di sottrarre le credenziali archiviate in memoria. Rafforza la sicurezza di uno dei componenti più sensibili del sistema operativo ed è fondamentale per i moderni controlli di sicurezza delle credenziali, come Credential Guard.

La verifica è fondamentale per:

• Assicurarsi che LSASS non sia solo configurato, ma che sia pienamente operativo come processo protetto.
• Individuare eventuali discrepanze tra l’interfaccia utente, il Registro di sistema e l’applicazione dei criteri.
• Assicurarsi che la protezione rimanga attiva anche dopo gli aggiornamenti o le modifiche ai criteri.
• Individuare i plug-in LSA non protetti o incompatibili che compromettono la sicurezza.
• Fornire prove a supporto di audit, controlli di conformità e indagini di sicurezza.

Risoluzione dei problemi

Durante la verifica della protezione LSA potresti riscontrare alcuni problemi comuni. Si raccomanda di seguire la procedura di risoluzione dei problemi riportata di seguito per garantire che il dispositivo riporti correttamente il proprio stato di sicurezza.

LSA si disattiva dopo l’aggiornamento

Verifica che il criterio aziendale sia ancora in vigore e che i valori di RunAsPPL rimangano configurati. Alcuni aggiornamenti di Windows reimpostano le impostazioni di sicurezza, pertanto potrebbe essere necessario riavviare il sistema. Se l’impostazione non viene mantenuta, riapplica il criterio e verifica nuovamente.

Il pulsante di attivazione/disattivazione nell’interfaccia utente non è presente o è disattivato

Ciò significa solitamente che l’impostazione è regolata da un criterio aziendale piuttosto che da una configurazione locale. Verifica la precedenza dei criteri e accertati che il registro rifletta lo stato applicato. Anche le configurazioni non supportate o obsolete possono rendere il pulsante di attivazione/disattivazione non disponibile.

Avvisi relativi ai plug-in non protetti

Esamina le linee guida di Microsoft in materia di audit per individuare quali plug-in o driver non siano stati caricati in modalità protetta. Aggiorna, rimuovi o sostituisci i componenti non conformi per ripristinare il corretto funzionamento dell’LSA. In seguito, dovresti anche ricontrollare i log eventi per assicurarti che nessun altro plug-in sia stato interessato dal problema.

Gli analisti confondono LSA e LSASS

Si precisa che LSA è il sottosistema responsabile dei criteri di autenticazione, mentre LSASS è il processo che li implementa. L’aggiunta di una breve nota esplicativa interna dovrebbe contribuire a ridurre i malintesi ricorrenti.

Verifica della protezione LSA per la sicurezza a lungo termine

La verifica della protezione LSA dovrebbe seguire un approccio strutturato per garantire che LSASS sia effettivamente in esecuzione come processo protetto. Seguendo il flusso di lavoro descritto, dalla verifica dei valori del registro alla risoluzione delle incongruenze, gli MSP e gli amministratori possono garantire la stabilità a lungo termine.

Argomenti correlati:

• Come abilitare Credential Guard e la protezione LSA su tutti i dispositivi client
• Come abilitare o disabilitare la protezione dell’autorità di sicurezza locale in Windows 11
• Come risolvere l’avviso “Il pacchetto LSA non è firmato come previsto” in Windows 11
• Come ripristinare le impostazioni predefinite di tutti i criteri di sicurezza locali in Windows