Per indagare su un incidente non serve un SIEM. Servono i log giusti attivi, conservati per almeno sei mesi, protetti da manomissioni e consultabili senza dover accedere a ogni singola macchina.
Le sei categorie qui sotto sono un nostro raggruppamento e non uno standard. Riorganizzano le tre tabelle della introduzione al logging per scopi di sicurezza dell'NCSC e aggiungono il logging applicativo dalle linee guida OWASP, oltre ai dettagli su Microsoft 365 tratti dalla documentazione di Microsoft.
Partire dalle domande
Scelga le fonti di log in base alle domande che le verranno poste nelle prime ore di un incidente. L'NCSC le formula in termini generali: che cosa è successo, qual è l'impatto, che cosa dobbiamo fare ora, la remediation ha funzionato e i nostri controlli di sicurezza funzionano. Nelle sue tabelle queste domande diventano più concrete, per esempio chi ha effettuato un accesso remoto fuori orario, oppure se qualcuno ha cliccato su un determinato link. Se non sa dire a quale domanda risponde un log, quel log viene dopo.
Il set minimo
| Fonte | Domanda a cui risponde | Origine |
|---|---|---|
| Identità e accesso remoto | Chi ha effettuato l'accesso, da dove, a che ora? Ci sono stati tentativi falliti sui servizi esposti a Internet? | Log di Active Directory, LDAP, ADFS, VPN, desktop remoto e VDI |
| Posta | Chi ha ricevuto un messaggio come questo e chi ha cliccato sul link? | Server SMTP, MS Exchange, appliance di scansione della posta, API dei cloud provider |
| Endpoint e server | Questo binario è stato eseguito, questo file esiste, è accaduto qualcosa di anomalo su un host? | Windows EVTX, Syslog, Microsoft Sysmon, agent sugli host |
| Firewall, DNS e proxy | Qualche sistema comunica con un IP o un dominio sospetto? | Log del firewall o netflow, log DNS, log del web proxy |
| Web server e applicazione | Che cosa ha fatto l'utente e con quale esito? | Codice applicativo, web server |
| Asset e modifiche | Quale dispositivo aveva questo IP, che cosa è cambiato, a chi appartiene questo server? | Log di DHCP, router, firewall e switch, un CMDB |
Alcuni dettagli cambiano ciò che occorre raccogliere. Sul firewall, l'NCSC indica che i log acquisiti dovrebbero tenere conto del Network Address Translation, in modo da registrare sia l'IP interno sia quello esterno. I log DNS mostrano il dominio su cui l'utente ha cliccato ma non l'URL completo, quindi vanno considerati un ripiego più debole dove non si dispone di un web proxy.
Gli agent sugli host, compreso il Microsoft Sysmon gratuito, possono produrre informazioni sui processi, eventi di lookup DNS, modifiche al file system e hash dei file. Coprono però solo ciò su cui qualcuno li ha installati e configurati, quindi shadow IT, dispositivi di rete, sistemi operativi non supportati e host in cui un malware ha disattivato l'agent restano al buio.
I log del web server non sono logging applicativo. L'applicazione conosce l'identità dell'utente, i suoi ruoli e l'esito di un'azione, mentre i dispositivi dell'infrastruttura spesso no.
Microsoft 365
Se utilizza Microsoft 365, controlli Microsoft Purview prima di acquistare qualsiasi cosa. Audit (Standard) è abilitato per impostazione predefinita per le organizzazioni con la sottoscrizione adeguata. Resta comunque da assegnare i permessi per consultarlo, nel portale Purview o con il cmdlet Search-UnifiedAuditLog in Exchange Online PowerShell.
Standard conserva i record per 180 giorni. I record generati prima del 17 ottobre 2023 ne conservavano solo 90. Audit (Premium) mantiene per impostazione predefinita per un anno i record di Microsoft Entra ID, Exchange, OneDrive e SharePoint.
Premium fornisce inoltre la proprietà SensitivityLabel sull'attività MailItemsAccessed in Exchange Online. Gli utenti hanno bisogno di una licenza Premium perché il sistema generi quegli eventi, quindi si chiarisca la questione delle licenze prima di un incidente.
Conservazione e protezione
L'NCSC raccomanda un minimo di 6 mesi per i log che rispondono alle domande sugli incidenti. Aggiunge che M-Trends 2018 indicava in 101 giorni il tempo medio di rilevamento, quindi conviene conservarli più a lungo, se il budget lo consente.
I log locali possono non raggiungere questa soglia senza che nessuno se ne accorga. Apra ciascun log e legga la data della voce più vecchia. Se risale a meno di sei mesi fa, il log potrebbe essere troppo piccolo o troppo trafficato per rispettare il suo obiettivo, quindi verifichi anche la dimensione configurata o l'impostazione di retention.
Chi si introduce in un sistema ha tutto l'interesse ad alterare i log, perciò il servizio di logging merita la stessa cura di qualsiasi interfaccia di amministrazione. Si chieda chi può leggere i log, chi può scriverci e se si accorgerebbe di una modifica. OWASP indica misure concrete per i log applicativi:
- Collocare i log su file in una partizione separata dal sistema operativo e dai contenuti generati dagli utenti, con permessi rigorosi su directory e file.
- Tenere i log fuori dalle posizioni accessibili dal web. Se non è evitabile, limitare l'accesso e servirli come testo semplice anziché come HTML.
- Quando si registra su un database, usare un account impiegato solo per scrivere i dati di log, con permessi molto restrittivi.
- Usare un formato di evento standard su un trasporto sicuro, come il formato dei messaggi syslog su TLS.
Centralizzare solo dove conviene
L'NCSC considera il logging centralizzato e quello decentralizzato come una scelta reale. Un archivio centrale evita di dover passare da ogni macchina durante un'indagine e diventa più utile a ogni fonte aggiunta. Lasciare i log dove sono funziona quando sono già consultabili e conservati abbastanza a lungo. I servizi di posta in cloud sono l'esempio dell'NCSC: l'estrazione raramente ne giustifica il costo.
Per un piccolo team, una suddivisione sensata consiste nel centralizzare i log di endpoint, server, firewall e VPN, lasciando dove sono i servizi cloud già ben forniti. Su Windows, Windows Event Forwarding invia in modo sicuro i log dai client a un archivio centrale.
L'NCSC avverte inoltre che un modello decentralizzato può degradarsi lentamente. Assegni a qualcuno il compito ricorrente di verificare che ogni fonte produca ancora log, e annoti chi è.
Da dove iniziare
- Prenda le domande concrete dalle tabelle dell'NCSC, per esempio chi ha effettuato un accesso remoto fuori orario, oppure se qualcuno ha cliccato su questo link. Per ciascuna, indichi il sistema che potrebbe rispondere.
- Per ogni fonte, annoti dove è archiviata, per quanto tempo viene conservata e chi può leggerla o modificarla. Segnali tutto ciò che è sotto i sei mesi.
- Controlli le impostazioni predefinite. Se una fonte registra pochi dettagli, modifichi la configurazione per acquisirne di più. In Microsoft 365, verifichi che Audit sia attivo e assegni i permessi di ricerca.
- Inoltri i log di endpoint, server, firewall e VPN a un unico archivio con accesso in scrittura limitato, usando Windows Event Forwarding o syslog su TLS.
- Esegua un'esercitazione: scelga un indirizzo IP sospetto e l'oggetto di un'email di phishing e cerchi di rispondere alle domande usando solo i log. Corregga per prima la fonte su cui si è bloccato.
- Se non può svolgere l'esercitazione internamente, chieda aiuto a un team di incident response o a un fornitore di servizi di sicurezza gestiti.
