Log di sicurezza: cosa registrare per ricostruire un cyberattacco

Quando un cyberattacco colpisce il server di un’azienda, la prima domanda raramente è soltanto se qualcosa sia andato storto. I team devono stabilire cosa è successo, quando è iniziato, quali account e sistemi sono stati coinvolti, a quali dati si è avuto accesso e se l’attaccante dispone ancora di accesso.

Le risposte dipendono dai log di sicurezza. Un log non è automaticamente una prova utile solo perché esiste. Un registro incompleto, un timestamp errato o un log che può essere modificato dallo stesso amministratore che ha causato l’evento possono lasciare agli investigatori un elenco di sospetti invece di una cronologia difendibile.

Una buona attività di logging supporta la risposta agli incidenti, le verifiche legali e normative, l’apprendimento operativo e le decisioni di ripristino. Aiuta inoltre un’azienda a distinguere tra un sistema di produzione compromesso e un punto di ripristino considerato affidabile.

Inizia dagli eventi che rivelano il percorso dell’attaccante

Il set di eventi corretto varia in base al sistema operativo, all’applicazione e all’infrastruttura, ma l’obiettivo rimane lo stesso: registrare le azioni che mostrano l’accesso iniziale, l’escalation dei privilegi, il movimento laterale, la persistenza, l’accesso ai dati e i tentativi di nascondere o distruggere le prove.

Eventi di autenticazione e identità

Registra gli accessi riusciti e quelli falliti su server, servizi di directory, VPN, console cloud, strumenti di amministrazione remota e applicazioni importanti. I dettagli utili includono l’account utilizzato, il metodo di autenticazione, l’indirizzo di origine, il sistema di destinazione, il risultato e, quando disponibile, il motivo del fallimento.

Non limitarti agli utenti umani. Gli account di servizio, le identità delle attività pianificate, le chiavi API, i certificati macchina e le identità delle applicazioni possono essere utilizzati in modo illecito con la stessa efficacia degli account nominativi. Devono essere conservati anche i cambi di password, gli eventi di autenticazione multifattore, l’emissione dei token, la creazione e la chiusura delle sessioni e i blocchi degli account.

Modifiche ai privilegi e agli account

Le modifiche ai privilegi spesso segnano il momento in cui un’intrusione diventa concretamente più pericolosa. Registra le aggiunte ai ruoli di amministratore, root, amministratore di dominio, proprietario del database e amministratore cloud. Registra le modifiche ai file sudoers, all’appartenenza ai gruppi, alle autorizzazioni delegate, alle policy di accesso e ai diritti degli account di servizio.

La creazione, l’eliminazione, la disabilitazione e la riabilitazione degli account devono essere visibili, inclusa l’identità che ha eseguito l’azione. Lo stesso vale per le modifiche alle credenziali API, alle chiavi SSH, ai token di accesso, ai certificati e alle impostazioni di reimpostazione delle password. Un attaccante può creare un nuovo account invece di continuare a usare quello sfruttato per l’accesso iniziale.

Esecuzione dei processi e persistenza

I log di esecuzione dei processi possono mostrare come un attaccante sia passato da un accesso valido a un’attività dannosa. Quando possibile, acquisisci il nome dell’eseguibile, la riga di comando completa, il processo padre, l’identità dell’utente o del servizio, l’ID del processo, l’orario di avvio e l’host. La creazione di file, l’uso degli interpreti di script, le attività pianificate, i cron job, i servizi, gli elementi di avvio, le chiavi Run del registro e i comandi di gestione remota possono rivelare i meccanismi di persistenza.

I dettagli della riga di comando sono importanti. Un record che indica che è stato eseguito powershell.exe è meno utile di uno che mostra lo script, i parametri, il processo padre e la destinazione contattata. Il logging deve essere bilanciato con la privacy e la gestione dei segreti: le righe di comando possono contenere password, token o dati personali, quindi il loro accesso richiede controlli adeguati.

Attività di configurazione, firewall, VPN e DNS

Le modifiche alla configurazione possono spiegare sia come sia entrato un attaccante, sia perché i normali controlli abbiano smesso di funzionare. Registra le modifiche alle impostazioni di sicurezza del sistema operativo, alla protezione degli endpoint, alle regole del firewall, alle impostazioni di accesso remoto, alle policy delle directory, al routing, alle impostazioni proxy e ai gruppi di sicurezza della rete.

I log del firewall devono mostrare le connessioni consentite e negate, gli indirizzi di origine e destinazione, le porte, i protocolli, l’interfaccia o la zona e la regola che ha gestito il traffico. I log VPN devono includere gli orari di connessione e disconnessione, l’indirizzo assegnato, l’account, le informazioni sul dispositivo, il risultato dell’autenticazione e il gateway. Questi record possono collegare un’origine esterna a un’attività che in seguito appare su un server interno.

Le richieste DNS vengono spesso trascurate. Possono rivelare infrastrutture di comando e controllo, destinazioni di staging, domini appena registrati e tentativi di raggiungere servizi di cloud storage o trasferimento dati. Conserva l’host richiedente, il nome interrogato, il tipo di record, la risposta, il resolver e il timestamp. Il DNS da solo non dimostra una compromissione, ma può completare una sequenza che gli altri log mostrano solo parzialmente.

Attività web, dei database e degli amministratori cloud

I log di accesso web devono acquisire l’orario della richiesta, l’indirizzo di origine, l’host, il metodo, il percorso, il codice di stato, la dimensione della risposta, l’utente o l’identificatore di sessione quando appropriato e lo user agent. I reverse proxy e i web application firewall possono aggiungere informazioni sulle richieste bloccate, sulle regole applicate e sugli indirizzi dei client inoltrati. Conserva con attenzione le informazioni sull’origine: gli header del proxy non devono essere considerati affidabili se la catena dei proxy non è sotto controllo.

Per i database, registra gli accessi, gli accessi falliti, le modifiche ai privilegi, le modifiche allo schema, i comandi amministrativi, le query che coinvolgono tabelle sensibili, le esportazioni, i backup, i ripristini e le modifiche alle impostazioni di audit. La registrazione completa delle query può essere costosa o contenere dati sensibili, quindi le organizzazioni dovrebbero definire quali database, azioni e categorie di dati richiedono una raccolta dettagliata.

I piani di controllo cloud richiedono un proprio audit trail. Registra le azioni degli amministratori relative a gestione di identità e accessi, storage, macchine virtuali, gruppi di sicurezza, chiavi, impostazioni di logging, snapshot, percorsi di rete e policy di eliminazione o conservazione. Il log di un workload cloud può mostrare cosa è successo dentro un server, mentre il log degli amministratori del provider mostra chi ha modificato l’ambiente circostante.

Le operazioni di backup sono eventi di sicurezza

I backup non devono essere trattati come un aspetto separato dal logging degli incidenti. Registra l’avvio e la conclusione dei job di backup, i sistemi di origine, i dati selezionati, il risultato, l’identità dell’operatore o del servizio, la destinazione, le modifiche alla conservazione, le richieste di eliminazione, gli errori di cifratura o delle chiavi, le richieste di ripristino e i relativi risultati.

Un attaccante che non può cifrare o sottrarre immediatamente i dati di produzione potrebbe tentare di eliminare i punti di ripristino, ridurre il periodo di conservazione, disabilitare i job o compromettere le credenziali utilizzate per gestire i backup. Queste azioni devono comparire in un audit trail non controllato esclusivamente dall’amministratore della produzione.

I campi che trasformano una voce di log in una prova

Il volume degli eventi non equivale al loro valore investigativo. Ogni evento importante dovrebbe rispondere a un piccolo gruppo di domande: quando è avvenuto, da dove ha avuto origine, cosa aveva come obiettivo, chi o cosa lo ha eseguito, quale azione si è verificata e ha avuto successo?

• Timestamp sincronizzato: usa una fonte temporale coerente e registra il fuso orario o l’offset UTC. Includi un orario preciso dell’evento quando la piattaforma lo supporta, oltre all’orario di raccolta quando i due valori differiscono.
• Origine e destinazione: acquisisci gli indirizzi IP di origine e destinazione, le porte, i nomi host, le interfacce, le zone, gli URL, gli oggetti del database o le risorse cloud, secondo necessità. Registra il contesto NAT o proxy quando influisce sull’attribuzione.
• Identità: identifica l’utente umano, l’account di servizio, il processo, il dispositivo, il certificato, il token o il client API. Un semplice nome visualizzato non è sufficiente se non può essere associato a un’identità univoca.
• Azione: indica cosa è stato tentato: accesso, assegnazione di un ruolo, avvio di un processo, accesso a un file, modifica di una regola, esportazione, eliminazione o ripristino.
• Risultato: distingui tra successo, fallimento, rifiuto, completamento parziale ed errore. Gli eventi falliti possono mostrare attività di sondaggio e tentativi ripetuti; quelli riusciti indicano quale accesso è stato ottenuto.
• Identificatori di correlazione: conserva gli ID delle richieste, delle sessioni, delle tracce, delle transazioni, dei processi e dei job. Questi identificatori consentono agli investigatori di collegare una richiesta proxy a un evento dell’applicazione, a una query del database e a un’azione successiva.
• Dettagli sull’oggetto e sulle modifiche: per le modifiche alla configurazione o agli accessi, registra la risorsa interessata e, quando possibile, i valori precedente e nuovo.

Gli ID di correlazione sono particolarmente preziosi negli ambienti distribuiti. Un utente può autenticarsi tramite un provider di identità, accedere a una VPN, connettersi a un servizio web, attivare un worker applicativo e causare una query al database. Senza identificatori condivisi o una mappatura affidabile tra i sistemi, la cronologia diventa un esercizio manuale basato su congetture.

Le organizzazioni dovrebbero documentare le fonti degli orologi, lo scostamento previsto e i formati dei timestamp. Una differenza di cinque minuti tra un firewall e un server può bastare per ordinare erroneamente gli eventi durante un attacco breve. I raccoglitori di log devono preservare il timestamp originale invece di sostituirlo silenziosamente con l’orario di arrivo dell’evento.

Definisci un set minimo di eventi e una checklist investigativa

Ogni azienda dovrebbe mantenere una baseline di logging scritta per i propri server e sistemi critici. Come minimo, dovrebbe coprire autenticazione, modifiche ai privilegi e agli account, esecuzione dei processi, modifiche alla configurazione, accesso alla rete, DNS, attività web e dei database, amministrazione cloud e operazioni di backup. La baseline dovrebbe identificare il responsabile del sistema, la fonte di log prevista, il metodo di raccolta, il periodo di conservazione e la persona responsabile della revisione degli eventi gravi. Un riferimento pratico per creare una checklist degli eventi di sicurezza e risposta agli incidenti può aiutare i team a individuare le lacune prima che si verifichi un incidente.

La baseline non è un’attività di configurazione una tantum. Esaminala dopo una modifica software importante, una migrazione, l’introduzione di un nuovo servizio cloud, un’acquisizione o un incidente. Verifica che gli eventi previsti sulla carta siano effettivamente generati, raccolti, ricercabili e conservati per il periodo richiesto.

Centralizza la raccolta senza creare un singolo punto di errore

La raccolta centralizzata rende più rapide le indagini perché gli analisti possono cercare tra server, sistemi di identità, reti e applicazioni utilizzando un’unica cronologia. Riduce inoltre la possibilità che un attaccante che compromette un server possa cancellare ogni traccia della propria attività.

Invia i log a un livello di raccolta dedicato o a una piattaforma SIEM per la gestione degli eventi e delle informazioni di sicurezza. Usa un trasporto sicuro, limita chi può inviare o modificare i record, monitora lo stato dei raccoglitori e genera un avviso quando una fonte importante smette di inviare dati. Un guasto silenzioso del logging può essere grave quanto un avviso mai configurato.

La centralizzazione non deve significare che ogni sistema abbia accesso illimitato a tutti i log. Separa i privilegi di acquisizione, ricerca, amministrazione ed eliminazione. Conserva un registro degli accessi ai log e delle attività di esportazione, soprattutto quando le prove possono essere condivise con un fornitore di analisi forense, un assicuratore, un’autorità di regolamentazione o un’agenzia di polizia.

Conservazione e resistenza alle manomissioni

La conservazione deve riflettere il tempo durante il quale un attaccante potrebbe rimanere inosservato, gli obblighi legali, i requisiti contrattuali e la velocità delle indagini interne. Una conservazione troppo breve può eliminare le prove necessarie per comprendere l’accesso iniziale. Una conservazione eccessiva senza controlli di accesso può aumentare i rischi per la privacy e la sicurezza.

Utilizza, quando appropriato, storage append-only o immutabile, proteggi il servizio di logging con credenziali separate e impedisci agli amministratori della produzione di modificare o eliminare i record storici. Hash, record firmati, storage write-once e copie indipendenti possono rafforzare il rilevamento delle manomissioni. Il controllo esatto deve essere adeguato alla sensibilità dell’ambiente, ma il principio è semplice: chi può compromettere la produzione non dovrebbe poter riscrivere le prove che la riguardano.

Mantieni separati produzione e prove

I log non devono dipendere interamente dall’integrità dei sistemi che monitorano. Se un attaccante ottiene l’accesso amministrativo a un server, i log locali possono essere eliminati, alterati o cifrati. Invia copie al di fuori dell’host e, per i sistemi critici, mantieni un confine amministrativo separato per l’infrastruttura di raccolta e conservazione.

Proteggi la piattaforma di logging stessa con autenticazione multifattore, amministrazione limitata, segmentazione della rete e monitoraggio indipendente. Esegui il backup della sua configurazione e, quando appropriato, dei suoi dati. Se la piattaforma di logging non è disponibile durante un incidente, l’organizzazione può perdere sia la visibilità sia la capacità di dimostrare cosa è stato raccolto.

Come le agenzie possono isolare le prove tra i clienti

I managed service provider, le agenzie IT e i team di sicurezza che supportano diverse aziende hanno bisogno di un ulteriore livello di disciplina. Le prove devono essere separate per cliente, non semplicemente etichettate con un campo che un analista potrebbe filtrare per errore.

Utilizza tenant, aree di storage o domini di accesso distinti per ciascun cliente, con ruoli separati e autorizzazioni basate sul minimo privilegio. Gli identificatori dei clienti devono essere inclusi nei metadati degli eventi, ma non devono essere l’unico controllo che impedisce l’accesso tra clienti. Ricerca, dashboard, esportazioni, avvisi e policy di conservazione devono essere testati per verificare l’isolamento dei tenant.

Conserva un audit trail che indichi quale membro del personale ha avuto accesso alle prove di un determinato cliente e quando. Definisci come conservare le prove durante un’indagine, come trasferirle e quando eliminarle. Se viene utilizzato un raccoglitore condiviso, documenta i controlli tecnici e procedurali che impediscono ai log di un cliente di comparire nell’indagine di un altro.

Le agenzie dovrebbero inoltre concordare in anticipo chi può autorizzare la raccolta, il contenimento, la sospensione degli account, il ripristino e la divulgazione. Durante un attacco, un’autorità poco chiara può ritardare l’azione mentre le prove continuano a scomparire.

Usa i log per ricostruire il ciclo di vita dell’attacco

Un’indagine utile è una cronologia, non una raccolta di eventi allarmanti. Inizia dal primo segnale credibile e verifica ogni fase rispetto a più fonti.

1. Accesso iniziale: cerca autenticazioni riuscite insolite, fallimenti ripetuti seguiti da un successo, servizi esposti, sessioni VPN sospette, richieste web che sfruttano percorsi vulnerabili, nuovi strumenti remoti e accessi cloud imprevisti. Confronta origine, dispositivo, area geografica, orario e metodo di autenticazione con l’attività normale.
2. Esecuzione ed escalation dei privilegi: identifica il primo processo, script, comando o azione applicativa sospetta. Poi segui le modifiche ai privilegi locali, di directory o cloud. Chiediti se l’account disponeva già di diritti eccessivi o se l’attaccante ha creato un nuovo percorso verso l’amministrazione.
3. Movimento laterale: segui i record di autenticazione e di rete dal primo host verso altri server, condivisioni di file, database, hypervisor e sistemi di gestione. Cerca lo stesso account, indirizzo di origine, strumento o processo che compare su più sistemi.
4. Persistenza: cerca nuovi account, job pianificati, servizi, elementi di avvio, chiavi SSH, token API, policy di accesso modificate e impostazioni di gestione remota alterate. La persistenza può essere creata giorni prima del furto o della cifratura dei dati.
5. Accesso ai dati e impatto: correla richieste web, accessi ai database, letture di file, creazione di archivi, esportazioni, attività sul cloud storage e connessioni in uscita insolite. Stabilisci a cosa è stato effettuato l’accesso, non solo cosa era potenzialmente disponibile.
6. Elusione delle difese: verifica la presenza di agenti arrestati, log degli eventi cancellati, policy di audit disabilitate, regole del firewall modificate, snapshot eliminati, pianificazioni dei backup alterate e raccolta dei log fallita. Questi eventi possono indicare sia le intenzioni dell’attaccante sia i limiti delle prove disponibili.

La cronologia deve distinguere i fatti osservati dalle supposizioni. Registra la fonte di ogni conclusione, conserva i log grezzi pertinenti e annota le lacune. Se un server era offline o il logging era disabilitato, dichiaralo chiaramente. Un rapporto d’incidente difendibile è più utile quando riconosce l’incertezza, invece di presentare un orario preciso non supportato.

Domande da porsi quando si esaminano i log dopo un incidente

Usa domande pratiche per mantenere l’analisi concentrata:

• Qual è il primo evento che non può essere spiegato dalla normale attività aziendale?
• Quale account, servizio, dispositivo o applicazione esposta è stato coinvolto per primo?
• Il primo accesso è riuscito oppure i fallimenti ripetuti hanno rivelato una preparazione precedente alla violazione?
• Quali privilegi sono cambiati dopo l’accesso iniziale?
• Quali processi, script, strumenti o attività pianificate sono comparsi sui sistemi interessati?
• Quali host interni sono stati contattati successivamente dall’account o dall’origine?
• Sono stati letti o esportati file sensibili, tabelle di database, caselle di posta o oggetti di cloud storage?
• L’attaccante ha modificato regole del firewall, impostazioni DNS, logging, policy di identità o operazioni di backup?
• I timestamp di tutti i sistemi rilevanti sono sincronizzati abbastanza da supportare la sequenza?
• Quali log mancano, sono in ritardo, sono archiviati localmente o potrebbero essere stati manomessi?
• Quali account, chiavi, token e sessioni devono essere revocati prima del ripristino?
• Quali sistemi sono stati esaminati a sufficienza per stabilire che il ripristino sia sicuro?

Il contenimento e la conservazione delle prove devono essere bilanciati. Disconnettere un server compromesso può fermare ulteriori danni, ma spegnerlo o cancellarlo può rimuovere prove volatili. Segui una procedura d’incidente concordata e coinvolgi un supporto forense qualificato quando i fatti possono avere conseguenze legali, normative o assicurative.

Il ripristino dipende da una cronologia affidabile

I log possono mostrare quando i sistemi sono stati compromessi, ma non possono ripararli. Il ripristino richiede una copia sicuramente integra dei dati e dello stato del sistema, oltre alla certezza che l’attaccante non abbia alterato il processo di recovery.

Prima di ripristinare, identifica la prima compromissione sospetta e tratta con cautela i punti di ripristino creati successivamente. Esamina i log dei job di backup, l’attività degli amministratori, le modifiche alla conservazione e i test di ripristino. Conferma che le credenziali dei backup non siano state esposte, che i dati di recupero siano completi e che i sistemi ripristinati non si riconnettano immediatamente all’infrastruttura dell’attaccante.

I punti di ripristino integri devono essere conservati abbastanza a lungo da coprire il probabile tempo di permanenza dell’attaccante e il periodo d’indagine. L’immutabilità durante la finestra di conservazione aiuta a impedire che un attaccante riscriva o elimini tali punti dopo aver ottenuto accesso alla produzione. La cifratura protegge i dati in caso di accesso allo storage, mentre la separazione delle chiavi garantisce che il provider dello storage non possa semplicemente decifrare da solo i dati dei clienti.

Per le aziende che proteggono server sotto il proprio controllo, Safenix offre backup off-site cifrati con una chiave che Safenix non possiede, archiviati in Germania e immutabili per tutta la durata della finestra di conservazione. Il servizio è progettato per server aziendali sotto controllo diretto, non per siti ospitati su hosting condiviso.

Dopo un incidente, il ripristino deve essere testato in un ambiente isolato prima del passaggio alla produzione. Convalida applicazioni, account, percorsi di rete, attività pianificate, monitoraggio e controlli di sicurezza, poi ruota le credenziali e conferma che la via d’ingresso originale sia chiusa. Le aziende che stanno valutando come conservare punti di ripristino integri e testare il recovery possono consultare le opzioni di backup off-site dei server Safenix.

Integra il logging nella pianificazione della resilienza

I log di sicurezza sono più preziosi quando vengono progettati prima dell’emergenza. Documenta la baseline degli eventi, sincronizza gli orologi, centralizza la raccolta, limita gli accessi, separa le prove dalla produzione e testa le procedure di conservazione e ripristino.

Il monitoraggio dei server può identificare tempestivamente i comportamenti anomali, mentre gli audit log forniscono i dettagli necessari per ricostruire decisioni e azioni. Insieme a punti di ripristino integri e protetti, offrono a un’azienda le due cose di cui un team di risposta agli incidenti ha più bisogno: una ricostruzione affidabile di ciò che è successo e un modo più sicuro per tornare operativi.