Prefazione
Raccogliere tutti i log necessari per fare auditing su server e workstation Windows è un processo necessario per la gestione di una corretta postura delle nostre infrastrutture e passa da un processo di configurazione mediante le Group Policy (o i criteri di gruppo locali se la macchina non fosse membro di un dominio) andando ad abilitare l’auditing di quanto ci interessa monitorare.
La prima fase consiste nel configurare le Group Policy. Successivamente è indispensabile che tutti i log che verranno prodotti dai server presenti nella nostra infrastruttura vengano convogliati in un SIEM il quale a sua volta ha lo scopo non solo di conservarli, ma anche di analizzarli e correlarli con altri eventi (magari anche da altre fonti) per ricostruire cosa ha ci ha portato davanti ad una certa situazione.
Disclaimer
Queste che propongo sono le mie configurazioni di base che implemento in tutti i sistemi Windows che voglio andare a monitorare: in linea di massima coprono gran parte dello spettro delle attività di security che un SOC dovrebbe monitorare, tuttavia consiglio di usarle come linee guida in base ai vostri ambienti e alle vostre esigenze.
Dimensionamento e retention
In questo primo settaggio andiamo a modificare la dimensione dei file dell’event log e la loro retention, cioè come, quanto e quando questi vengono mantenuti su file system prima che vengano sovrascritti.
La voce “Retention method” indica il metodo con il quale, una volta che il registro ha raggiunto la dimensione massima definita dalla chiave “Dimensionamento e retention dei log locali”, i log più vecchi vengono sovrascritti. Per amor di chiarezza, lo si vede meglio nell’immagine sottostante (img 2, le proprietà del registro “security”).
Vien da se che la voce “Maximum security log size” dovrà essere correttamente dimensionata in base alle vostre esigenze.
Security Options
Questo è un criterio di sicurezza che, se abilitato, consente alle impostazioni della categoria del criterio figlio di sovrascrivere le impostazioni della categoria del criterio padre. Sui sistemi Windows Vista e versioni successive, i criteri di controllo possono essere impostati a livello di sotto categoria. Tuttavia, quando un criterio di controllo viene applicato come parte di un criterio di gruppo, può essere applicato solo a livello di categoria. Pertanto, quando vengono aggiunti nuovi computer ad una rete, i criteri di gruppo della rete sostituiranno i criteri di controllo dei nuovi computer.
Account logon
Queste opzioni servono per generare nel registro degli eventi tutte le segnalazioni circa la convalida delle credenziali inviate per una richiesta di accesso dell’account utente, piuttosto che abilitare il logging del servizio di autenticazione Kerberos il quale determina se vengono generati eventi di controllo per le richieste TGT (ticket-granting ticket) via Kerberos. Lascio qui sotto tutte le documentazioni ufficiali al sito di Microsoft per gli approfondimenti (NB: coniglio caldamente una letta ai link se gestite direttamente voi un SIEM, così da capire come e quali eventi correlare nelle regole).
- Audit credentials validation
- Audit Kerberos authentication services
- Audit Kerberos Service Ticket Operations
Logon e logoff
Sicuramente la policy più semplice, in quanto le chiavi sono parlanti: in pratica l’abilitazione delle chiavi indicate permettono al sistema di registrare tutti gli eventi circa le login effettuate (andate a buon fine o meno), se l’account viene disabilitato e lo stato delle login “speciali” come quelle via RDP o di servizio (qua ho scritto un articolo sulle diverse tipologie di logon su Windows).
System
Policy interessante dal mio punto di vista, motivo per il quale la imposto sempre. Abilitando questa chiave si permette al sistema di scrivere tutti log che determinano se Windows genera eventi di controllo per le modifiche nello stato di sicurezza di un sistema.
Impostare questo audit delle attività di sistema può aiutare a identificare gli errori di configurazione, risolvere i problemi di interruzione del servizio e analizzare le compromissioni che si sono verificate, oltre a rilevare gli attacchi. I log prodotti sono necessari per fornire una traccia di prove nel caso in cui il sistema sia compromesso. La raccolta di questi dati è essenziale per analizzare la sicurezza e rilevare segnali di comportamenti sospetti e imprevisti.
Nella speranza di non vedere mai questi eventi comparire, io la inserirei. 😉
Domain controller
Oltre a tutte le policy impostate fin’ora, per quanto concerne i domain controller, consiglio di aggiungere anche queste due policy relative alla gestione degli account e l’accesso al Directory Services.
Determina se loggare ogni evento di gestione dell’account, per esempio:
- un account utente o un gruppo viene creato, modificato o eliminato
- un account utente viene rinominato, disabilitato o abilitato
- è stata impostata o modificata una password
Anche qua, consiglio caldamente una letta alla documentazione ufficiale dove sono riportati tutti i codici di evento che possono essere messi sotto monitoraggio.
Allego qua un esempio di log raw di facile comprensione.
Il primo log, il 4720, indica che un nuovo utente, quindi un nuovo oggetto, è stato creato. Il “TargetUserName” indica il nome dell’oggetto e il “SubjectUserName” indica quale utente ha creato questo oggetto
Il secondo, il 4723, indica che l’utente descritto nella chiave “SubjectUserName” ha modificato la password dell’utente/oggetto “TargetUserName”.
Di default, questi valori sono impostati su nessun controllo (not configured) nell’oggetto Criteri di gruppo (GPO).
Se si definisce questo criterio è possibile specificare se controllare i successi, gli errori o non controllare affatto il tipo di evento. I controlli riusciti generano un log quando un utente accede correttamente a un oggetto di Active Directory con un SACL specificato. Analogamente, i controlli non riusciti generano una voce di controllo quando un utente tenta senza successo di accedere a un oggetto di Active Directory con un SACL specificato.
SACL
SACL è l’acronimo di System Access Control List, ed è un elenco di controllo degli accessi (ACL) utilizzato da Windows per scopi di controllo della sicurezza. Questi elenchi di controllo di accesso al sistema non devono essere confusi con gli elenchi di controllo di accesso discrezionale (DACL) più familiari utilizzati da Windows 2000 e Windows NT per controllare l’accesso agli oggetti di Active Directory e file system NTFS da parte di utenti e gruppi.
I SACL vengono utilizzati per stabilire criteri di sicurezza a livello di sistema per azioni come la registrazione o il controllo dell’accesso alle risorse, per esempio
- quali entità di sicurezza (utenti, gruppi, computer) devono essere controllate quando si accede all’oggetto
- quali eventi di accesso devono essere controllati per queste entità
- se viene generato un attributo Success o Failure per un evento, a seconda delle autorizzazioni concesse nel DACL per l’oggetto
Conclusioni
Allego un documento dove elenco tutti gli eventi che queste policy abilitano con relativo “id evento” e “descrizione” dell’evento stesso.
EOF