Analisi di log aziendali, firewall, VPN e sistemi cloud

Introduzione

I log sono registrazioni prodotte da sistemi operativi, apparati di rete, applicazioni, servizi cloud, dispositivi di sicurezza e piattaforme aziendali.

Possono documentare:

• un accesso riuscito o fallito;
• la creazione di un account;
• l’assegnazione di un privilegio;
• l’apertura di una connessione VPN;
• il passaggio di traffico attraverso un firewall;
• l’avvio di un processo;
• la consultazione di un file;
• la modifica di una configurazione;
• la revoca di una sessione;
• il download di dati;
• la creazione di una regola email;
• un’azione eseguita tramite API;
• la cancellazione di un registro;
• l’attività di risposta a un incidente.

Il NIST considera la gestione dei log un processo organizzativo che comprende generazione, trasmissione, conservazione, accesso, analisi e dismissione delle registrazioni. Le linee guida sull’incident response pubblicate nel 2025 collocano rilevazione, risposta e recupero all’interno della più ampia gestione del rischio informatico.

In un’indagine aziendale a Roma, la domanda iniziale può sembrare semplice:

La risposta richiede spesso la correlazione di molte fonti:

evento di autenticazione
        ↓
account
        ↓
indirizzo IP
        ↓
assegnazione DHCP
        ↓
sessione VPN
        ↓
dispositivo
        ↓
processo o applicazione
        ↓
azione eseguita
        ↓
persona fisica

Ogni passaggio deve essere dimostrato separatamente.

Un indirizzo IP interno non identifica automaticamente un computer.

Un computer non identifica automaticamente una persona.

Una connessione firewall consentita non dimostra che l’utente abbia letto un documento.

Un evento di login non prova tutte le attività compiute durante la sessione.

L’assenza di un evento non dimostra necessariamente che l’azione non sia avvenuta: il log potrebbe non essere stato abilitato, potrebbe essere scaduto, sovrascritto, esportato in modo incompleto o registrato in un’altra fonte.

La corretta analisi deve quindi distinguere:

1. evento reale;
2. evento registrato;
3. evento esportato;
4. evento interpretato;
5. correlazione;
6. attribuzione;
7. limite.

Sintesi operativa

1. formalizzare incarico, autorizzazioni e perimetro;
2. identificare le fonti di log rilevanti;
3. verificare immediatamente i tempi di conservazione;
4. acquisire prima i dati più volatili o prossimi alla scadenza;
5. documentare account e privilegi usati per l’esportazione;
6. conservare il formato nativo oltre agli output CSV o JSON;
7. calcolare l’hash di ogni file acquisito;
8. registrare data, ora, fuso e fonte temporale;
9. verificare sincronizzazione e scarto degli orologi;
10. distinguere log originari, copie, viste SIEM e report derivati;
11. documentare filtri, query, limiti e numero di risultati;
12. preservare configurazioni di logging e retention;
13. analizzare Windows, Linux, firewall, VPN, DNS e DHCP;
14. acquisire gli audit log dei sistemi cloud;
15. correlare account, IP, asset, sessioni, processi e azioni;
16. verificare NAT, proxy, VPN, carrier e infrastrutture condivise;
17. cercare lacune, cancellazioni e variazioni di configurazione;
18. costruire una timeline normalizzata in UTC;
19. separare fatti, deduzioni e dichiarazioni;
20. formulare conclusioni proporzionate ai dati disponibili.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• sui sistemi dell’organizzazione committente;
• su infrastrutture amministrate legittimamente;
• con autorizzazione del titolare;
• nell’ambito di attività difensive o peritali;
• secondo le politiche aziendali;
• nel rispetto dei rapporti di lavoro;
• nel rispetto della protezione dei dati personali;
• senza eludere controlli di accesso.

Non è lecito:

• accedere a tenant, router o firewall di terzi;
• utilizzare credenziali non autorizzate;
• interrogare account di dipendenti oltre il perimetro dell’incarico;
• disattivare sistemi di sicurezza senza autorizzazione;
• modificare o cancellare log;
• installare agenti occulti;
• intercettare comunicazioni;
• ampliare indiscriminatamente la raccolta;
• utilizzare token o sessioni sottratte;
• acquisire dati personali non pertinenti.

L’attività tecnica deve essere coordinata, secondo il caso, con:

• direzione;
• responsabile IT;
• responsabile sicurezza;
• DPO;
• ufficio legale;
• risorse umane;
• amministratore di sistema;
• responsabile del trattamento;
• fornitore cloud;
• assicuratore cyber;
• autorità competente.

Il NIST SP 800-86 raccomanda che le tecniche forensi siano applicate dopo aver valutato con management e consulenti legali le norme, i regolamenti e gli obblighi applicabili al caso concreto.

2. Che cos’è un log

Un log è una registrazione di uno o più eventi prodotti da un sistema.

Può contenere:

- timestamp;
- hostname;
- indirizzo IP;
- account;
- identificativo sessione;
- processo;
- applicazione;
- azione;
- esito;
- oggetto interessato;
- protocollo;
- porta;
- quantità di dati;
- codice errore;
- identificativo del dispositivo;
- correlazione;
- informazioni aggiuntive.

2.1 Log testuale

Esempio:

2026-07-13T08:42:11+02:00 vpn-gw01
user=rossi.m
src_ip=203.0.113.24
assigned_ip=10.20.14.57
result=success
session_id=845102

2.2 Log strutturato

Può essere memorizzato in:

• JSON;
• XML;
• CSV;
• EVTX;
• database;
• formato binario;
• journal systemd;
• storage proprietario;
• bucket cloud.

2.3 Log locale

È conservato sul sistema che lo produce.

Vantaggio:

• dettaglio nativo.

Rischi:

• sovrascrittura;
• distruzione del dispositivo;
• manipolazione da parte di un amministratore;
• perdita durante un attacco.

2.4 Log centralizzato

È inviato a:

• syslog server;
• SIEM;
• data lake;
• collector;
• servizio cloud;
• storage immutabile.

Può aumentare:

• disponibilità;
• correlazione;
• conservazione;
• separazione dal sistema compromesso.

Non garantisce automaticamente:

• completezza;
• corretta configurazione;
• assenza di ritardi;
• interpretazione corretta;
• integrità end-to-end.

3. Evento, log, alert, incidente e prova

Questi termini non sono sinonimi.

Esempio:

Evento:
un utente inserisce una password errata.

Log:
Windows registra Event ID 4625.

Alert:
il SIEM rileva 50 errori in cinque minuti.

Ipotesi:
tentativo di password spraying.

Incidente:
un account viene successivamente compromesso.

Evidenza:
file EVTX acquisito, sottoposto a hash e correlato
con VPN, Entra ID e firewall.

Un alert può essere:

• vero positivo;
• falso positivo;
• duplicato;
• incompleto;
• basato su una regola errata;
• privo di contesto.

La relazione non deve trattare l’alert come prova autosufficiente.

4. Che cosa può dimostrare un log

Un log può documentare che, secondo la fonte:

• un account ha autenticato;
• un indirizzo IP ha stabilito una connessione;
• un processo è stato avviato;
• una regola è stata modificata;
• un file è stato condiviso;
• un privilegio è stato assegnato;
• un evento è stato bloccato;
• una sessione è terminata;
• una risorsa è stata eliminata;
• un dato è stato scaricato;
• un’API è stata invocata.

Può inoltre contribuire a:

• delimitare un intervallo temporale;
• ricostruire una sequenza;
• confermare una dichiarazione;
• smentire una ricostruzione;
• individuare un account;
• correlare una rete;
• identificare un’infrastruttura;
• documentare un’anomalia;
• verificare un controllo di sicurezza.

5. Che cosa non può dimostrare automaticamente

Un log non dimostra necessariamente:

• chi si trovasse davanti al computer;
• chi conoscesse la password;
• chi avesse materialmente il telefono;
• la finalità dell’azione;
• la liceità dell’accesso;
• la completezza delle attività;
• l’assenza di altri eventi;
• la verità di un campo inserito dal client;
• la precisione geografica dell’IP;
• l’autenticità assoluta del sistema produttore;
• che il record non sia stato modificato prima dell’acquisizione.

6. Le principali domande dell’azienda

Un’azienda romana può chiedere:

• chi ha effettuato un accesso fuori orario;
• quale computer ha scaricato determinati file;
• se un ex dipendente abbia usato la VPN;
• quando sia iniziato un attacco ransomware;
• se un account amministrativo sia stato abusato;
• quali dati siano stati consultati;
• se una regola del firewall sia stata modificata;
• da dove provenga un tentativo di accesso;
• se un IP appartenga a un dipendente;
• chi abbia creato un account cloud;
• se un file sia stato condiviso all’esterno;
• quanto tempo sia durata la compromissione;
• se i log siano stati cancellati;
• perché il SIEM non abbia generato un alert;
• quali dati siano ancora disponibili.

La risposta corretta richiede la definizione di:

- periodo;
- sistemi;
- account;
- sedi;
- reti;
- fusi orari;
- azioni;
- fonti;
- retention;
- quesito tecnico.

7. Mappa generale delle fonti

7.1 Identità e autenticazione

• Active Directory;
• Microsoft Entra ID;
• LDAP;
• RADIUS;
• SSO;
• MFA;
• Identity Provider;
• PAM;
• account applicativi.

7.2 Endpoint

• Windows Event Log;
• Sysmon;
• PowerShell;
• EDR/XDR;
• antivirus;
• Linux journald;
• auditd;
• macOS Unified Log;
• applicazioni locali.

7.3 Rete

• firewall;
• router;
• switch;
• VPN;
• DHCP;
• DNS;
• proxy;
• secure web gateway;
• IDS/IPS;
• wireless controller;
• NAC;
• NetFlow/IPFIX;
• packet capture.

7.4 Posta e collaborazione

• Microsoft 365;
• Exchange;
• Google Workspace;
• email gateway;
• antispam;
• Teams;
• SharePoint;
• OneDrive;
• Google Drive;
• Slack;
• piattaforme SaaS.

7.5 Cloud

• Azure;
• AWS;
• Google Cloud;
• Oracle Cloud;
• servizi di backup;
• storage;
• container;
• Kubernetes;
• serverless;
• API gateway.

7.6 Sicurezza e amministrazione

• SIEM;
• SOAR;
• EDR;
• vulnerability management;
• IAM;
• PAM;
• DLP;
• MDM;
• ticketing;
• change management;
• backup console.

7.7 Fonti organizzative

• inventario;
• assegnazione dispositivi;
• turni;
• badge;
• ruoli;
• ordini di servizio;
• ticket;
• procedure;
• cessazioni;
• contratti;
• elenco amministratori.

8. Inquadramento privacy e organizzativo

8.1 Sicurezza del trattamento

L’articolo 32 del GDPR richiede misure tecniche e organizzative adeguate al rischio, tenendo conto dello stato dell’arte, dei costi, del contesto e della natura dei dati. I log possono contribuire a prevenire, rilevare e ricostruire accessi non autorizzati, ma la loro raccolta deve rispettare finalità, proporzionalità e protezione degli interessati.

8.2 Amministratori di sistema

Il provvedimento del Garante sugli amministratori di sistema richiede che gli accessi logici degli amministratori siano registrati con caratteristiche di completezza, inalterabilità e verificabilità dell’integrità. Le registrazioni devono contenere riferimenti temporali e descrizione dell’evento e devono essere conservate per un periodo non inferiore a sei mesi.

Tale prescrizione:

• riguarda gli accessi degli amministratori nel relativo ambito;
• non costituisce una regola universale di sei mesi per ogni log;
• non impone, per quella sola disposizione, la registrazione di ogni comando;
• non sostituisce l’analisi del rischio;
• non esclude conservazioni più lunghe quando giustificate.

Le FAQ del Garante chiariscono che l’access log comprende accesso, tentativo di accesso e disconnessione nell’ambito delle sessioni interattive, mentre il provvedimento non richiede in modo generalizzato la registrazione di ogni comando eseguito dall’amministratore.

8.3 NIS2

Il decreto legislativo n. 138/2024 ha recepito in Italia la direttiva NIS2. Gli obblighi non riguardano indistintamente ogni impresa, ma i soggetti che rientrano nel relativo perimetro. (Gazzetta Ufficiale)

Il regolamento di esecuzione UE 2024/2690, applicabile alle categorie interessate, richiede procedure di monitoraggio e logging, individuazione degli asset da registrare, revisione dei log e sincronizzazione delle fonti temporali. Tra gli eventi pertinenti sono indicati accessi, autenticazioni, privilegi, modifiche di configurazione e traffico di rete rilevante.

8.4 Lavoratori

L’acquisizione di log riferibili a dipendenti deve essere valutata considerando:

• informativa;
• finalità;
• policy aziendale;
• necessità;
• proporzionalità;
• minimizzazione;
• conservazione;
• controlli a distanza;
• ruolo sindacale;
• segreto professionale;
• dati particolari.

Il perito non deve estendere la raccolta oltre quanto necessario per il quesito.

9. Definire il perimetro

Prima di acquisire occorre stabilire:

- quali sistemi;
- quali utenti;
- quali sedi;
- quali tenant;
- quale periodo;
- quali eventi;
- quali applicazioni;
- quali reti;
- quali dispositivi;
- quali ruoli amministrativi;
- quali fornitori;
- quali dati personali.

Esempio:

È troppo ampio:

10. Questionario iniziale

10.1 Organizzazione

1. Quante sedi sono presenti?
2. Quali reti e domini sono utilizzati?
3. Esiste un inventario aggiornato?
4. Chi amministra i sistemi?
5. Sono presenti fornitori esterni?
6. Esiste un SIEM?
7. Esiste un SOC?
8. Quali cloud provider sono utilizzati?
9. Quali fusi orari sono configurati?
10. Quali politiche di retention esistono?

10.2 Incidente

1. Quando è stato rilevato?
2. Quale evento ha generato l’allarme?
3. Quali account sono coinvolti?
4. Quali dispositivi?
5. Quali IP?
6. Quali dati?
7. Sono state eseguite modifiche?
8. È ancora in corso?
9. Sono stati cancellati log?
10. Sono state attivate misure di contenimento?

10.3 Logging

[ ] Windows Security;
[ ] Sysmon;
[ ] PowerShell;
[ ] Linux journal;
[ ] auditd;
[ ] firewall;
[ ] VPN;
[ ] DNS;
[ ] DHCP;
[ ] proxy;
[ ] EDR;
[ ] Entra ID;
[ ] Microsoft Purview;
[ ] Google Workspace;
[ ] AWS CloudTrail;
[ ] Azure Monitor;
[ ] Google Cloud Logging;
[ ] applicazioni.

10.4 Modifiche già eseguite

Chiedere se l’azienda ha:

• disattivato account;
• revocato sessioni;
• riavviato server;
• aggiornato sistemi;
• eliminato regole;
• ripristinato backup;
• formattato endpoint;
• modificato retention;
• cancellato file;
• esportato dati;
• applicato filtri SIEM;
• avviato script.

11. Formulare il quesito tecnico

Quesito improprio:

Quesiti tecnici più corretti:

- verificare gli accessi associati all’account;
- ricostruire le sessioni VPN;
- identificare gli indirizzi assegnati;
- correlare gli eventi con il dispositivo aziendale;
- verificare accessi a file o servizi cloud;
- documentare download e condivisioni;
- individuare modifiche ai privilegi;
- verificare cancellazioni o interruzioni del logging;
- ricostruire una timeline;
- descrivere i limiti dell’attribuzione personale.

12. Protocollo dei primi trenta minuti

1. identificare i sistemi a rischio di sovrascrittura;
2. documentare ora locale e UTC;
3. verificare retention e capacità residua;
4. acquisire le configurazioni di logging;
5. preservare i log cloud prossimi alla scadenza;
6. esportare i record dal SIEM senza modificare le query salvate;
7. acquisire firewall, VPN, DNS e DHCP;
8. acquisire gli eventi degli identity provider;
9. bloccare la rotazione, solo se autorizzato e tecnicamente sicuro;
10. creare copie di lavoro;
11. calcolare SHA-256;
12. registrare l’account usato per l’esportazione;
13. annotare ogni azione;
14. evitare riavvii non necessari;
15. coordinare l’eventuale contenimento.

La preservazione non deve impedire il contenimento di un incidente attivo.

13. Cartella del caso

CASO_RM_2026_020/
├── 00_incarico/
├── 01_verbali/
├── 02_inventario/
├── 03_configurazioni_logging/
├── 04_windows_evtx/
├── 05_sysmon/
├── 06_linux_journal/
├── 07_firewall/
├── 08_vpn_radius/
├── 09_dns_dhcp/
├── 10_proxy_web/
├── 11_edr_xdr/
├── 12_active_directory/
├── 13_entra_m365/
├── 14_google_workspace/
├── 15_azure/
├── 16_aws/
├── 17_google_cloud/
├── 18_siem/
├── 19_hash/
├── 20_query/
├── 21_normalizzati/
├── 22_timeline/
├── 23_matrici/
├── 24_report/
└── 25_relazione/

Conservare separatamente:

• file originali;
• export nativi;
• output normalizzati;
• query;
• report;
• screenshot.

14. Registro delle fonti

Per ogni fonte registrare anche:

• timezone;
• precisione;
• retention;
• filtri;
• numero record;
• eventuali errori;
• lacune note;
• versione del sistema.

15. Catena di custodia

La catena di custodia deve comprendere:

- identificativo;
- origine;
- amministratore;
- data e ora;
- metodo;
- comando;
- privilegi;
- destinazione;
- formato;
- dimensione;
- hash;
- trasferimenti;
- copie;
- accessi;
- anomalie.

16. Acquisire il formato nativo

Non conservare soltanto:

• screenshot;
• dashboard;
• grafico;
• PDF;
• tabella copiata;
• risultato filtrato.

Acquisire, quando disponibile:

- EVTX;
- JSON;
- XML;
- syslog originale;
- journal;
- CSV raw;
- file compresso;
- archivio vendor;
- digest;
- firma;
- configurazione.

La dashboard è una vista.

Il file nativo conserva più campi e può consentire:

• nuove query;
• verifica del parser;
• confronto;
• riproducibilità;
• analisi di record non inizialmente considerati.

17. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\Security.evtx"

Linux

sha256sum -- Security.evtx

macOS

shasum -a 256 -- Security.evtx

Manifesto di una directory

find originali -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > manifest_sha256.txt

Registrare:

Nome:
Dimensione:
SHA-256:
Fonte:
Data acquisizione:
Operatore:

L’hash non dimostra che il log fosse completo o corretto prima dell’acquisizione.

18. Il problema del tempo

La correlazione dipende dalla qualità temporale.

Possibili rappresentazioni:

2026-07-13 08:14:12
2026-07-13T08:14:12+02:00
2026-07-13T06:14:12Z
Jul 13 08:14:12
1752387252
2026-07-13 08:14:12.462913

18.1 Elementi da registrare

- valore originale;
- fuso;
- offset;
- precisione;
- fonte;
- formato;
- eventuale conversione;
- scarto noto;
- sincronizzazione.

18.2 UTC

Per la timeline è utile normalizzare in UTC, ma il valore originale deve rimanere disponibile.

Esempio:

Valore originale:
2026-07-13T08:14:12+02:00

Valore normalizzato:
2026-07-13T06:14:12Z

18.3 Ora legale

A Roma, nel periodo estivo, l’offset ordinario può essere UTC+02:00; nel periodo invernale UTC+01:00.

Non applicare l’offset sulla base della sola intuizione: verificare data, sistema, configurazione e regole temporali.

19. NTP e sincronizzazione

NTPv4 è definito dalla RFC 5905 e le best practice operative sono raccolte nella RFC 8633. Una sorgente temporale stabile e documentata è essenziale per correlare eventi prodotti da sistemi differenti.

19.1 Windows

w32tm /query /status
w32tm /query /configuration
w32tm /query /peers

19.2 Linux con systemd

timedatectl status
timedatectl timesync-status

19.3 Chrony

chronyc tracking
chronyc sources -v

19.4 Registrare

- sorgente temporale;
- stato sincronizzazione;
- ultimo aggiornamento;
- offset;
- stratum;
- leap status;
- server;
- eventuali errori.

19.5 Clock drift

Un server può avere uno scarto di:

• pochi millisecondi;
• alcuni secondi;
• minuti;
• ore;
• fuso intero.

Non “correggere” silenziosamente la timeline.

20. Formati e parser

I log possono essere:

• delimitati;
• multilinea;
• strutturati;
• semi-strutturati;
• binari;
• compressi;
• firmati;
• accompagnati da indice.

20.1 Syslog

La RFC 5424 definisce un formato strutturato per il trasporto dei messaggi syslog, separando il contenuto dal protocollo di trasporto e consentendo estensioni specifiche del produttore. Non definisce invece un formato universale di conservazione su disco.

20.2 Campi tipici

PRI
VERSION
TIMESTAMP
HOSTNAME
APP-NAME
PROCID
MSGID
STRUCTURED-DATA
MSG

20.3 Attenzione al parser

Un SIEM può:

• rinominare campi;
• perdere valori;
• interpretare male il fuso;
• troncare messaggi;
• aggregare eventi;
• duplicare record;
• normalizzare in modo errato.

Conservare:

• raw event;
• parser;
• versione;
• mapping;
• campo normalizzato;
• eventuale errore.

21. Integrità e immutabilità

21.1 Misure tecniche

• account di sola lettura;
• separazione dei ruoli;
• storage append-only;
• WORM;
• object lock;
• firma;
• hash concatenati;
• controllo accessi;
• replica;
• segregazione di rete;
• audit sul repository.

21.2 Syslog firmato

La RFC 5848 descrive un meccanismo per aggiungere autenticazione dell’origine, integrità, resistenza al replay, sequenziamento e rilevazione di messaggi mancanti ai flussi syslog.

21.3 CloudTrail

AWS CloudTrail può produrre file digest firmati contenenti gli hash dei file di log, consentendo di verificarne l’integrità quando la funzione è abilitata. (AWS)

21.4 Limite

Un repository dichiarato “immutabile” deve essere verificato rispetto a:

• configurazione;
• privilegi;
• periodo di retention;
• possibilità di cancellazione;
• chiavi;
• policy;
• account root;
• versioning.

22. Retention

La retention non deve essere scelta applicando una durata unica a ogni fonte.

Deve considerare:

• rischio;
• finalità;
• normativa;
• contratti;
• capacità;
• costi;
• investigabilità;
• privacy;
• frequenza degli incidenti;
• tempi di rilevazione.

22.1 Matrice orientativa

22.2 Non confondere disponibilità e retention

Un prodotto può:

• generare il log;
• mostrarlo in console;
• consentirne l’export;
• conservarlo per un periodo differente;
• limitarlo in base alla licenza.

La verifica deve avvenire all’inizio dell’incarico.

23. Inventario delle fonti

Creare una tabella:

Questa mappa aiuta a individuare:

• fonti mancanti;
• retention insufficiente;
• duplicazioni;
• fusi incompatibili;
• responsabilità;
• dipendenze dai fornitori.

24. Windows Event Log

Windows registra eventi in canali come:

- Security;
- System;
- Application;
- Setup;
- ForwardedEvents;
- Microsoft-Windows-Sysmon/Operational;
- Microsoft-Windows-PowerShell/Operational;
- TerminalServices;
- Defender;
- TaskScheduler;
- WMI-Activity;
- DNS Server;
- DHCP Server.

24.1 Acquisizione del file EVTX

wevtutil epl Security `
  "D:\CASO\04_windows_evtx\Security.evtx" `
  /ow:true

wevtutil epl System `
  "D:\CASO\04_windows_evtx\System.evtx" `
  /ow:true

wevtutil epl `
  "Microsoft-Windows-Sysmon/Operational" `
  "D:\CASO\05_sysmon\Sysmon-Operational.evtx" `
  /ow:true

Documentare:

• prompt;
• utenza;
• host;
• privilegi;
• data;
• destinazione;
• errori;
• hash.

24.2 Configurazione del canale

wevtutil gl Security

Registrare:

• dimensione massima;
• modalità di retention;
• auto-backup;
• stato;
• percorso.

25. Eventi Windows principali

Microsoft documenta che l’evento 4625 rappresenta un tentativo di accesso fallito e distingue tipologie come accesso interattivo, rete, servizio e Remote Desktop. L’evento 4688 viene generato alla creazione di un nuovo processo, mentre l’evento 1102 indica la cancellazione del registro di audit.

26. Tipologie di logon Windows

Non concludere:

Può derivare da:

• accesso a share;
• servizio;
• scanner;
• applicazione;
• processo automatico;
• autenticazione remota.

27. Query Windows in sola lettura

27.1 Accessi riusciti e falliti

$start = Get-Date "2026-07-01T00:00:00"
$end   = Get-Date "2026-07-11T00:00:00"

Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4624,4625
    StartTime = $start
    EndTime   = $end
} |
Select-Object TimeCreated, Id, MachineName, Message |
Export-Csv ".\accessi.csv" `
  -NoTypeInformation `
  -Encoding UTF8

27.2 Analisi da EVTX acquisito

Get-WinEvent -Path ".\Security.evtx" |
Where-Object { $_.Id -in 4624,4625,4672,4688,1102 } |
Select-Object TimeCreated, Id, MachineName, RecordId, Message |
Export-Csv ".\Security-selezione.csv" `
  -NoTypeInformation `
  -Encoding UTF8

Conservare sempre l’EVTX originale.

28. Windows Event Forwarding

Windows Event Forwarding consente di inoltrare eventi selezionati dai computer sorgente a un Windows Event Collector.

Può essere utilizzato per:

• centralizzare;
• ridurre il rischio di perdita locale;
• raccogliere eventi di sicurezza;
• alimentare SIEM e SOC.

Microsoft distingue set di eventi completi, comuni, minimi o personalizzati: una selezione ridotta può contenere eventi utili alla rilevazione ma non mantenere una traccia di audit completa. (Microsoft)

28.1 Verificare

- subscription;
- source computers;
- collector;
- query XPath;
- intervallo;
- stato;
- backlog;
- ForwardedEvents;
- perdita di connettività;
- account.

28.2 Limite

L’assenza di un evento nel collector può derivare da:

• evento non selezionato;
• client offline;
• subscription errata;
• errore di inoltro;
• record sovrascritto;
• ritardo;
• filtro.

29. Sysmon

Sysmon può registrare eventi ad alto valore investigativo, tra cui:

• creazione processi;
• connessioni di rete;
• creazione file;
• modifiche al registro;
• caricamento driver;
• query DNS;
• creazione pipe;
• accessi a processi.

Microsoft documenta, tra gli altri:

• Event ID 1: creazione processo;
• Event ID 3: connessione di rete;
• Event ID 11: creazione file;
• Event ID 22: query DNS.

Sysmon registra i timestamp in UTC e utilizza identificativi come ProcessGUID per correlare processi anche quando i PID vengono riutilizzati. (Microsoft Sysmon)

29.1 Verificare la configurazione

sysmon64.exe -c

29.2 Limiti

La qualità dipende da:

• configurazione;
• esclusioni;
• versione;
• data di installazione;
• canale;
• capacità;
• centralizzazione.

L’assenza di Event ID 3 non dimostra assenza di rete se il logging delle connessioni non era abilitato.

30. PowerShell

PowerShell può registrare:

• avvio motore;
• moduli;
• script block;
• trascrizioni;
• comandi;
• errori.

L’Event ID 4104 è associato allo Script Block Logging quando la funzione è configurata. (Microsoft)

30.1 Acquisizione

wevtutil epl `
  "Microsoft-Windows-PowerShell/Operational" `
  ".\PowerShell-Operational.evtx" `
  /ow:true

30.2 Query

Get-WinEvent -Path ".\PowerShell-Operational.evtx" |
Where-Object { $_.Id -eq 4104 } |
Select-Object TimeCreated, RecordId, Message |
Export-Csv ".\PowerShell-4104.csv" `
  -NoTypeInformation `
  -Encoding UTF8

30.3 Dati sensibili

I log PowerShell possono contenere:

• password;
• token;
• stringhe di connessione;
• dati personali;
• percorsi;
• nomi clienti.

Devono essere protetti e minimizzati negli allegati.

31. Active Directory

Fonti principali:

• controller di dominio;
• Security Log;
• Kerberos;
• NTLM;
• Directory Service;
• DNS;
• replica;
• Group Policy;
• account;
• gruppi;
• deleghe.

31.1 Eventi da correlare

- creazione account;
- disabilitazione;
- password reset;
- aggiunta a gruppo;
- ticket Kerberos;
- logon;
- lockout;
- replica;
- modifica GPO;
- modifiche privilegiate.

31.2 Domande

• quale DC ha autenticato;
• quale account;
• quale workstation;
• quale IP;
• quale Logon ID;
• quale ticket;
• quale gruppo;
• quale amministratore.

31.3 Account condivisi

Un account generico impedisce spesso l’attribuzione personale.

32. Linux e systemd journal

systemd-journald raccoglie e conserva eventi strutturati provenienti da kernel, servizi, processi e syslog. journalctl consente di consultarli. (systemd)

32.1 Acquisizione temporale

journalctl \
  --utc \
  --since "2026-07-01 00:00:00" \
  --until "2026-07-11 00:00:00" \
  --output short-iso-precise \
  --no-pager \
  > journal-utc.txt

32.2 Output JSON

journalctl \
  --utc \
  --since "2026-07-01 00:00:00" \
  --until "2026-07-11 00:00:00" \
  --output json \
  --no-pager \
  > journal.json

32.3 Servizio specifico

journalctl \
  --unit ssh.service \
  --utc \
  --since "2026-07-01" \
  --no-pager \
  > ssh-journal.txt

32.4 Verifica journal

journalctl --verify

L’esito deve essere conservato, senza assumere che una verifica positiva dimostri l’intera storia del sistema.

33. Log Linux tradizionali

Possibili file:

/var/log/auth.log
/var/log/secure
/var/log/syslog
/var/log/messages
/var/log/audit/audit.log
/var/log/kern.log
/var/log/nginx/
/var/log/apache2/
/var/log/cron
/var/log/wtmp
/var/log/btmp

33.1 Accessi

last -Faiw > last.txt
lastb -Faiw > lastb.txt

33.2 Ricerche su file ruotati

zgrep -h "Failed password" \
  /var/log/auth.log* \
  > ssh-failed-passwords.txt

33.3 Sudo

zgrep -h "sudo" \
  /var/log/auth.log* \
  > sudo-events.txt

33.4 Attenzione

last e lastb dipendono da:

• wtmp;
• btmp;
• rotazione;
• integrità;
• configurazione.

Non sono una fonte universale o infallibile.

34. Auditd

Linux Audit può registrare:

• autenticazioni;
• system call;
• accessi a file;
• modifiche;
• esecuzione;
• privilegi;
• cambi di identità;
• modifiche alla configurazione.

34.1 Query temporale

ausearch \
  --start 07/01/2026 00:00:00 \
  --end   07/11/2026 00:00:00 \
  --interpret \
  > audit-periodo.txt

34.2 Eventi per account

ausearch \
  -ua utente \
  --start 07/01/2026 \
  --interpret \
  > audit-utente.txt

34.3 Limite

L’assenza di un evento può dipendere da:

• regola non configurata;
• backlog;
• perdita;
• servizio arrestato;
• rotazione;
• esclusione;
• architettura non supportata.

Acquisire anche:

/etc/audit/auditd.conf
/etc/audit/rules.d/
/etc/audit/audit.rules

35. DNS

I log DNS possono documentare:

• query;
• client;
• nome richiesto;
• tipo record;
• risposta;
• errori;
• modifiche alle zone;
• aggiornamenti dinamici;
• attività amministrative.

35.1 Utilità

• individuare domini malevoli;
• correlare malware;
• ricostruire navigazione tecnica;
• identificare un client interno;
• verificare esfiltrazione DNS;
• collegare una sessione a un dominio.

35.2 Limiti

Una query DNS non dimostra:

• che la connessione sia stata completata;
• che l’utente abbia visto la pagina;
• che il client abbia scaricato il contenuto;
• che la persona conoscesse la richiesta.

Può essere generata da:

• browser;
• prefetch;
• antivirus;
• servizio;
• applicazione;
• aggiornamento;
• malware.

35.3 Windows DNS

I log analitici dettagliati possono richiedere una specifica abilitazione e, su server ad alto volume, incidere sulle prestazioni. La configurazione deve essere valutata prima dell’incidente, non improvvisata durante una compromissione senza analisi dell’impatto. (Microsoft)

35.4 BIND

Il query logging di BIND può fornire informazioni complete sulle richieste in ingresso, ma può generare volume elevato e impatto prestazionale. (BIND 9)

36. DHCP

Il DHCP collega temporalmente:

MAC address
        ↓
IP interno
        ↓
lease start
        ↓
lease end
        ↓
hostname o client identifier

36.1 Dati importanti

• timestamp;
• IP;
• MAC;
• hostname;
• client ID;
• scope;
• server;
• tipo evento;
• durata lease.

36.2 Correlazione

Per attribuire un IP interno alle ore 10:15:

1. verificare il lease valido alle 10:15;
2. verificare il MAC;
3. verificare l’inventario;
4. verificare switch o wireless;
5. verificare l’utente;
6. verificare eventuali lease statici;
7. verificare duplicazioni;
8. verificare fuso e scarto.

36.3 Windows DHCP

Windows conserva eventi DHCP nei canali dedicati e nei file di audit; la configurazione e i percorsi devono essere documentati per la versione in uso. (Microsoft)

36.4 Limiti

Un MAC address può essere:

• virtuale;
• randomizzato;
• clonato;
• associato a dock;
• appartenente a un telefono;
• registrato attraverso relay DHCP.

37. Firewall

I log del firewall possono includere:

- timestamp;
- source IP;
- destination IP;
- source port;
- destination port;
- protocol;
- zone;
- rule;
- policy ID;
- action;
- application;
- NAT;
- session ID;
- byte;
- packet;
- duration;
- session end reason;
- interface;
- user.

Le implementazioni differiscono tra produttori. Palo Alto, Fortinet, Cisco e altri apparati utilizzano campi e logiche differenti per apertura, chiusura, NAT e classificazione applicativa. (Palo Alto Networks)

37.1 Consentito non significa riuscito

Un record allow può significare soltanto che il firewall ha consentito il traffico.

Non dimostra:

• autenticazione applicativa;
• completamento della sessione;
• lettura di dati;
• successo dell’azione;
• identità dell’utente.

37.2 Bloccato non significa attacco

Un deny può derivare da:

• scansione;
• configurazione errata;
• applicazione;
• traffico legittimo;
• servizio dismesso;
• errore DNS;
• tentativo malevolo.

38. Log di inizio e fine sessione

Alcuni firewall registrano:

• session start;
• session end;
• entrambi;
• solo eventi selezionati.

Un log di fine sessione può contenere dati non disponibili all’inizio:

• byte;
• durata;
• applicazione identificata;
• motivo di chiusura;
• NAT definitivo.

Palo Alto documenta che i traffic log sono normalmente prodotti alla fine della sessione e possono essere configurati anche all’inizio. (Palo Alto Networks)

Se la sessione non termina correttamente, il record finale potrebbe:

• mancare;
• essere ritardato;
• contenere valori parziali.

39. NAT

Il NAT modifica indirizzi e porte.

Esempio:

Host interno:
10.10.20.54:51422

Firewall pubblico:
198.51.100.8:60315

Destinazione:
203.0.113.90:443

Per correlare un log esterno all’host interno occorrono:

• timestamp preciso;
• IP pubblico;
• porta pubblica;
• protocollo;
• tabella NAT;
• sessione firewall;
• IP interno;
• porta interna.

Un IP pubblico condiviso senza porta sorgente e orario preciso può essere insufficiente.

40. Proxy e secure web gateway

Possono registrare:

• utente;
• IP client;
• URL;
• dominio;
• metodo HTTP;
• categoria;
• user agent;
• quantità dati;
• esito;
• certificato;
• file;
• hash;
• sandbox verdict.

40.1 Utilità

• phishing;
• download malware;
• esfiltrazione;
• servizi cloud;
• siti di file sharing;
• applicazioni web.

40.2 Limiti

Un proxy può:

• decifrare TLS;
• non decifrarlo;
• registrare soltanto dominio;
• associare l’utente mediante agent;
• attribuire traffico a un account condiviso;
• utilizzare cache.

Una richiesta URL non dimostra necessariamente che il contenuto sia stato letto dalla persona.

41. VPN

I log VPN possono contenere:

- account;
- IP sorgente;
- IP assegnato;
- metodo MFA;
- gateway;
- profilo;
- client;
- sistema operativo;
- session start;
- session end;
- durata;
- byte;
- reason;
- certificate;
- device ID.

41.1 Correlazione minima

1. login VPN;
2. autenticazione RADIUS o IdP;
3. IP assegnato;
4. sessione firewall;
5. destinazione interna;
6. account applicativo;
7. dispositivo.

41.2 Connessione VPN non significa attività specifica

Dimostra, nei limiti della fonte, che:

• l’account ha stabilito una sessione;
• da un IP sorgente;
• attraverso un gateway;
• per un intervallo.

Non dimostra automaticamente:

• chi controllasse il dispositivo;
• quale file sia stato letto;
• quale applicazione sia stata usata;
• che tutto il traffico passasse nella VPN.

41.3 Split tunneling

Con split tunneling:

• solo parte del traffico passa nel tunnel;
• il traffico Internet può uscire localmente;
• le fonti aziendali non vedono necessariamente ogni connessione.

42. RADIUS e NPS

RADIUS può centralizzare:

• autenticazione;
• autorizzazione;
• accounting;
• accesso VPN;
• Wi-Fi;
• apparati di rete.

Microsoft Network Policy Server può registrare richieste, accettazioni, rifiuti e accounting per VPN e accessi di rete. (documentazione Microsoft)

42.1 Eventi da verificare

- Access-Request;
- Access-Accept;
- Access-Reject;
- Accounting-Start;
- Interim-Update;
- Accounting-Stop;
- NAS-IP-Address;
- Calling-Station-ID;
- Framed-IP-Address;
- session ID.

42.2 NPS Windows

Eventi come 6273 e 6274 possono documentare rifiuti o tentativi scartati, secondo la configurazione di audit. (documentazione Microsoft)

42.3 Limite

Un Access-Accept documenta l’accettazione dell’autenticazione, non l’uso successivo di ogni risorsa.

43. Wireless e NAC

Fonti:

• controller Wi-Fi;
• access point;
• RADIUS;
• DHCP;
• NAC;
• switch;
• MDM.

Dati:

- SSID;
- account;
- MAC;
- AP;
- radio;
- segnale;
- VLAN;
- IP;
- roaming;
- sessione;
- autenticazione.

La presenza presso un access point può essere compatibile con una certa area, ma non costituisce una geolocalizzazione precisa della persona.

44. NetFlow e IPFIX

Possono descrivere flussi attraverso:

• indirizzi;
• porte;
• protocollo;
• byte;
• pacchetti;
• durata;
• interfacce.

Non contengono normalmente il payload.

Sono utili per:

• movimenti laterali;
• esfiltrazione;
• scansioni;
• beaconing;
• volume;
• destinazioni.

Limiti:

• campionamento;
• aggregazione;
• timeout;
• NAT;
• assenza contenuto;
• clock drift.

45. IDS e IPS

Un IDS genera alert.

Un IPS può bloccare o modificare il traffico.

Acquisire:

- signature;
- severity;
- source;
- destination;
- timestamp;
- payload disponibile;
- action;
- sensor;
- rule version;
- packet capture;
- confidence.

Un alert di “malware” può essere:

• vero;
• falso;
• duplicato;
• generato da un test;
• riferito a un file non eseguito;
• riferito a traffico cifrato classificato indirettamente.

46. EDR e XDR

Possibili dati:

• processi;
• parent-child;
• command line;
• hash;
• rete;
• file;
• registry;
• utente;
• alert;
• isolamento;
• quarantena;
• timeline;
• response actions.

46.1 Acquisire

- raw event;
- detection;
- incident;
- device timeline;
- query;
- policy;
- versione agent;
- stato sensore;
- azioni del SOC;
- retention.

46.2 Differenza tra evento e detection

Un processo può essere registrato senza alert.

Un alert può aggregare centinaia di eventi.

Conservare entrambi.

46.3 Azioni del SOC

ENISA raccomanda di documentare le attività di incident response, compresi tempi di rilevazione, contenimento, eradicazione, recupero, indicatori, causa e azioni eseguite.

47. Email gateway

Può documentare:

• mittente;
• destinatario;
• IP;
• dominio;
• Message-ID;
• verdict;
• URL;
• allegato;
• hash;
• quarantena;
• consegna;
• riscrittura link;
• sandbox.

È complementare all’analisi forense di email e header.

Un gateway può indicare delivered, ma il messaggio potrebbe:

• essere stato spostato;
• non essere stato letto;
• essere stato eliminato;
• essere stato bloccato da un controllo successivo.

48. SIEM

Il SIEM raccoglie, normalizza e correla fonti differenti.

Può contenere:

• raw logs;
• campi normalizzati;
• regole;
• alert;
• incident;
• watchlist;
• query;
• casi;
• note;
• automazioni.

48.1 Acquisire

- query;
- intervallo;
- timezone;
- numero risultati;
- raw event;
- campi;
- parser;
- regola;
- versione;
- esportazione;
- limiti;
- screenshot.

48.2 Dashboard e prove

Una dashboard è utile per orientarsi, ma non basta.

Conservare:

• dati sottostanti;
• query;
• filtri;
• esportazione;
• hash.

48.3 Regole modificate

Acquisire:

• versione attuale;
• cronologia;
• autore;
• data modifica;
• soglia;
• esclusioni;
• stato;
• azioni automatiche.

49. Query KQL: tentativi di accesso Windows

Esempio orientativo in ambiente autorizzato:

SecurityEvent
| where TimeGenerated between (
    datetime(2026-07-01T00:00:00Z) ..
    datetime(2026-07-11T00:00:00Z)
)
| where EventID == 4625
| summarize
    Tentativi = count(),
    AccountDistinti = dcount(Account)
    by IpAddress, bin(TimeGenerated, 5m)
| order by Tentativi desc

Il risultato può evidenziare:

• password spraying;
• password errata memorizzata;
• servizio configurato male;
• scanner;
• attacco.

Non concludere senza contesto.

50. Query KQL: RDP

SecurityEvent
| where EventID == 4624
| where LogonType == 10
| project
    TimeGenerated,
    Computer,
    Account,
    IpAddress,
    LogonType,
    Activity
| order by TimeGenerated asc

Correlare con:

• VPN;
• firewall;
• TerminalServices;
• session disconnect/reconnect;
• endpoint;
• account.

51. Query KQL: accessi Entra falliti

SigninLogs
| where TimeGenerated between (
    datetime(2026-07-01T00:00:00Z) ..
    datetime(2026-07-11T00:00:00Z)
)
| where ResultType != "0"
| summarize
    Tentativi = count(),
    Utenti = dcount(UserPrincipalName)
    by IPAddress, bin(TimeGenerated, 5m)
| order by Tentativi desc

Documentare:

• tabella;
• workspace;
• retention;
• filtro;
• export;
• versione della query.

52. Normalizzazione dei dati

Campi consigliati:

event_time_original
event_time_utc
ingest_time
source_type
source_host
user
src_ip
src_port
dst_ip
dst_port
protocol
action
result
session_id
process_id
process_guid
object
raw_event
evidence_id

52.1 Non sostituire il raw

Il dato normalizzato deve puntare al record originario.

52.2 Separare i tempi

event time:
quando la fonte dichiara che l’evento è avvenuto;

ingest time:
quando il collector ha ricevuto il record;

processing time:
quando il SIEM lo ha elaborato;

export time:
quando è stato acquisito.

Ritardi significativi possono alterare l’ordine apparente.

53. Deduplicazione

Duplicati possibili:

• stesso evento inviato a due collector;
• replay;
• ridondanza;
• agent e syslog;
• export sovrapposti;
• query ripetute.

Non eliminare fisicamente i duplicati dagli originali.

Creare un dataset derivato indicando il criterio:

chiave deduplicazione =
source_host
+ event_id
+ record_id
+ timestamp
+ hash raw_event

54. Correlazione degli eventi

54.1 Chiavi utili

• username;
• SID;
• UPN;
• email;
• IP;
• porta;
• hostname;
• MAC;
• device ID;
• session ID;
• correlation ID;
• process GUID;
• Message-ID;
• file hash;
• object ID;
• request ID;
• transaction ID.

54.2 Gerarchia di correlazione

corrispondenza esatta:
stesso session ID;

corrispondenza forte:
account + IP + intervallo;

corrispondenza moderata:
hostname + utente + orario;

corrispondenza debole:
stessa città o stesso modello dispositivo.

La relazione deve indicare la forza del collegamento.

55. Microsoft Entra ID

Fonti:

• sign-in logs;
• audit logs;
• provisioning logs;
• risky sign-ins;
• Identity Protection;
• service principal;
• managed identity;
• Microsoft Graph activity.

55.1 Campi importanti

createdDateTime
userPrincipalName
userId
appDisplayName
resourceDisplayName
ipAddress
location
clientAppUsed
deviceDetail
authenticationDetails
conditionalAccessStatus
status
correlationId
riskLevel
riskState

55.2 Retention

Alla data di aggiornamento del capitolo, Microsoft indica per Entra ID una retention nativa differente in base a report e licenza: per audit e sign-in, sette giorni nel piano Free e trenta giorni nei piani P1/P2. I log possono essere conservati più a lungo mediante Azure Monitor e storage. Le variazioni di licenza non recuperano retroattivamente i dati già scaduti. (Microsoft)

Questa informazione deve essere verificata al momento dell’incarico.

56. Microsoft 365 e Purview Audit

Può documentare attività in:

• Exchange;
• SharePoint;
• OneDrive;
• Teams;
• Entra;
• Power BI;
• applicazioni Microsoft 365.

56.1 Acquisire

- ricerca;
- utenti;
- workload;
- operazioni;
- intervallo;
- export CSV;
- AuditData;
- numero risultati;
- licenza;
- retention;
- ruoli.

56.2 Limiti di export

Microsoft indica limiti per singola esportazione: 50.000 record per Audit Standard e 1.000.000 per Audit Premium. Se il risultato supera il limite, il CSV può essere incompleto; occorre segmentare intervalli e filtri. (Microsoft)

56.3 Retention

Audit Premium consente politiche fino a dieci anni con le licenze richieste. Le durate predefinite dipendono da workload, utente e licenza; Audit Standard conserva normalmente 180 giorni per i record generati secondo l’attuale regime. (Microsoft)

56.4 Regola operativa

Non scrivere:

Scrivere:

57. Google Workspace

Fonti:

• login audit;
• admin audit;
• Drive audit;
• OAuth;
• token;
• Gmail;
• mobile;
• SAML;
• gruppi;
• regole;
• alert center.

57.1 Reports API

Google indica un periodo massimo di 180 giorni per i report delle attività di audit ottenibili mediante Reports API.

57.2 Drive

Il report Drive può documentare creazione, modifica, condivisione e gestione dei file per un periodo massimo di 180 giorni, secondo disponibilità e licenza. (Google)

57.3 Audit and investigation tool

L’interfaccia consente ricerche con filtri e download fino a 100.000 righe per singola esportazione. Le funzioni avanzate dipendono dall’edizione. (Google)

57.4 Attenzione

Alcuni eventi:

• non sono registrati;
• dipendono dal servizio;
• dipendono dalla licenza;
• possono essere aggregati;
• possono riferirsi a API;
• possono avere retention differente.

58. AWS CloudTrail

CloudTrail registra attività eseguite mediante:

• console;
• CLI;
• SDK;
• API;
• servizi AWS.

58.1 Event history

AWS rende automaticamente disponibile una cronologia immutabile degli ultimi novanta giorni di eventi di gestione per singola Regione. La vista non comprende automaticamente data events, Insights o network activity events. Per una conservazione continuativa più ampia occorre configurare trail o event data store. (AWS)

58.2 Acquisizione CLI

aws cloudtrail lookup-events \
  --start-time "2026-07-01T00:00:00Z" \
  --end-time   "2026-07-11T00:00:00Z" \
  > cloudtrail-events.json

58.3 Verificare

- account;
- Regione;
- organization trail;
- management events;
- data events;
- Insights;
- S3;
- CloudTrail Lake;
- integrity validation;
- retention;
- encryption;
- access.

58.4 Campi

eventTime
eventSource
eventName
awsRegion
sourceIPAddress
userAgent
userIdentity
requestParameters
responseElements
resources
requestID
eventID

58.5 Limite

Un evento in una Regione non rappresenta necessariamente tutte le attività dell’organizzazione.

59. Azure Activity Log

Azure Activity Log documenta eventi sul piano di controllo, ad esempio:

• creazione risorsa;
• modifica;
• eliminazione;
• ruolo;
• policy;
• operazioni amministrative.

Azure conserva nativamente gli eventi dell’Activity Log per novanta giorni; per una durata maggiore occorre configurarli verso altre destinazioni mediante diagnostic settings. (Microsoft Azure)

59.1 Azure CLI

az monitor activity-log list \
  --start-time "2026-07-01T00:00:00Z" \
  --end-time   "2026-07-11T00:00:00Z" \
  --output json \
  > azure-activity-log.json

59.2 Resource logs

I resource log non vengono raccolti automaticamente per ogni risorsa: è necessario configurare le diagnostic settings. Microsoft precisa inoltre che la pipeline non offre garanzia transazionale assoluta e che piccole perdite temporanee possono verificarsi. (Microsoft)

59.3 Distinguere

Activity Log:
piano di controllo;

Resource Logs:
operazioni interne della specifica risorsa;

Entra Logs:
identità e autenticazione;

Defender:
alert e sicurezza;

Log Analytics:
repository e query.

60. Google Cloud Audit Logs

Google Cloud distingue:

• Admin Activity;
• Data Access;
• System Event;
• Policy Denied.

Admin Activity e System Event sono sempre generati. I Data Access log, eccetto specifiche eccezioni come BigQuery, devono generalmente essere abilitati e possono produrre volume e costi. Le registrazioni di audit sono indicate come immutabili all’interno del servizio. (Google Cloud)

60.1 Retention

Alla data di aggiornamento:

• il bucket _Required conserva determinati audit log per 400 giorni;
• il bucket _Default conserva normalmente i record per 30 giorni;
• la retention personalizzata dei bucket configurabili può essere impostata da 1 a 3.650 giorni. (Google Cloud)

60.2 Query CLI

gcloud logging read \
  'logName:"cloudaudit.googleapis.com"' \
  --freshness=10d \
  --format=json \
  > google-cloud-audit.json

60.3 Verificare

- organization;
- folder;
- project;
- log bucket;
- sink;
- exclusions;
- IAM;
- Data Access;
- service account;
- workload identity;
- Regione;
- retention.

61. Altri SaaS

Per ogni servizio chiedere:

1. quali eventi vengono registrati;
2. quale piano è necessario;
3. quanto dura la retention;
4. quale timezone è usato;
5. esiste un’API;
6. esiste un export raw;
7. l’export è completo;
8. chi può accedervi;
9. quali azioni amministrative vengono tracciate;
10. sono presenti audit sui download.

Esempi:

• CRM;
• gestionale;
• piattaforma HR;
• firma elettronica;
• ticketing;
• videoconferenza;
• file sharing;
• backup;
• contabilità.

La documentazione commerciale non sostituisce la verifica della configurazione reale del tenant.

62. Log delle applicazioni

Un’applicazione aziendale può registrare:

• login;
• transazioni;
• modifiche;
• esportazioni;
• ricerca;
• stampa;
• approvazioni;
• cancellazioni;
• errori.

62.1 Problemi frequenti

• account condivisi;
• log solo applicativi;
• fusi non documentati;
• cancellazione da parte dell’amministratore;
• audit non abilitato;
• nomi display al posto di ID stabili;
• dati derivati dal client;
• assenza di versione.

62.2 Acquisire

- database audit;
- log applicativo;
- configurazione;
- schema;
- versione;
- account;
- ruoli;
- mapping utente;
- manuale vendor;
- retention.

63. Accessi ai database

Fonti:

• authentication log;
• audit DBMS;
• query audit;
• amministrazione;
• backup;
• replica;
• error log.

Domande:

• quale account;
• da quale host;
• quale client;
• quale database;
• quale query;
• quale ruolo;
• quale intervallo;
• quale quantità di dati.

Il provvedimento del Garante sugli amministratori di sistema ricomprende, nel relativo ambito, anche le autenticazioni ai database management system. (provvedimento del Garante)

64. Baseline e comportamento normale

Per riconoscere un’anomalia occorre conoscere il normale funzionamento.

Esempi:

• backup notturni;
• scanner;
• account di servizio;
• amministrazione estera;
• VPN aziendale;
• sincronizzazioni;
• manutenzione;
• batch;
• vulnerability scanner;
• patch management.

64.1 Tabella baseline

Un evento raro non è automaticamente malevolo.

65. Password spraying

Indicatori:

- pochi tentativi per molti account;
- stesso IP;
- intervallo regolare;
- molti 4625;
- successivo 4624;
- autenticazioni cloud;
- geolocalizzazione insolita.

Possibili alternative:

• applicazione con credenziali obsolete;
• password cambiata;
• dispositivo mobile;
• scanner;
• servizio;
• test autorizzato.

66. Brute force

Indicatori:

• molti tentativi sullo stesso account;
• alta frequenza;
• stessa sorgente;
• sequenza temporale;
• successivo accesso riuscito.

Non assumere che l’accesso successivo sia necessariamente conseguenza del brute force.

Verificare:

• password change;
• IP;
• device;
• MFA;
• sessione;
• token;
• login abituale.

67. Privilege escalation

Cercare:

• aggiunta a gruppi amministrativi;
• assegnazione ruolo cloud;
• nuova policy;
• reset MFA;
• service principal;
• delega;
• sudo;
• account root;
• modifica PAM;
• nuova chiave SSH.

Correlare:

chi ha effettuato la modifica
+ da quale sessione
+ quale account è stato privilegiato
+ quali azioni sono seguite

68. Cancellazione e manomissione dei log

Possibili indicatori:

• Event ID 1102;
• arresto servizio;
• cambio retention;
• file eliminati;
• reset collector;
• gap temporale;
• sequenza record interrotta;
• digest mancante;
• agent disinstallato;
• bucket policy modificata;
• audit disabilitato;
• exclusion cloud.

68.1 Non ogni cancellazione è malevola

Può derivare da:

• manutenzione;
• troubleshooting;
• aggiornamento;
• procedura;
• ripristino;
• errore.

68.2 Formula

69. Movimento laterale

Possibili tracce:

• SMB;
• RDP;
• WinRM;
• WMI;
• PsExec;
• SSH;
• autenticazioni Kerberos;
• servizi remoti;
• condivisioni amministrative;
• strumenti di gestione.

Correlare:

host origine
→ account
→ autenticazione
→ host destinazione
→ processo
→ servizio
→ attività successiva

Una connessione su porta 445 non dimostra automaticamente esfiltrazione o movimento laterale.

70. Esfiltrazione di dati

Fonti:

• proxy;
• firewall;
• DLP;
• cloud audit;
• USB;
• email;
• browser;
• EDR;
• file server;
• NetFlow.

Indicatori:

- volume anomalo;
- archivio creato;
- compressione;
- upload;
- file sharing;
- email esterna;
- download cloud;
- accesso massivo;
- orario anomalo.

70.1 Volume non equivale a contenuto

Un log di rete può mostrare 5 GB trasferiti.

Non dimostra automaticamente:

• quali file;
• se fossero dati aziendali;
• se il trasferimento fosse autorizzato;
• se fosse upload o protocol overhead, senza campi adeguati.

Collegare con il Capitolo 22 — Dipendente infedele, sottrazione dati e uso di USB.

71. Precursori ransomware

Possibili segnali:

• phishing;
• login VPN anomalo;
• disabilitazione antivirus;
• uso di strumenti amministrativi;
• enumerazione dominio;
• accesso backup;
• cancellazione shadow copy;
• movimento laterale;
• creazione servizi;
• trasferimento elevato;
• modifica GPO;
• cifratura.

L’analisi completa è trattata nel Capitolo 21 — Incident response forense e ransomware.

72. Impossible travel

Un alert può segnalare accessi da località incompatibili in un breve intervallo.

Possibili cause:

• VPN;
• proxy;
• carrier mobile;
• relay;
• geolocalizzazione errata;
• sessioni parallele;
• attaccante;
• app cloud.

Non concludere:

Meglio:

73. Lacune e assenza dei dati

Un record può mancare perché:

• logging non abilitato;
• retention scaduta;
• file sovrascritto;
• sistema offline;
• rete interrotta;
• collector saturo;
• parser errato;
• filtro;
• esclusione;
• licenza;
• evento non previsto;
• esportazione incompleta;
• azione tramite altro canale.

Indicare sempre:

- fonti esaminate;
- periodo;
- configurazione;
- copertura;
- lacune;
- retention;
- affidabilità.

74. Correlazione con dispositivi fisici

Per collegare un evento a un computer:

1. IP assegnato;
2. DHCP;
3. MAC;
4. switch;
5. inventario;
6. seriale;
7. hostname;
8. EDR device ID;
9. utente;
10. accesso locale.

Il semplice hostname può essere:

• modificato;
• duplicato;
• virtuale;
• ricostruito;
• derivato dal client.

75. Correlazione con una persona

Possibili fonti:

• credenziale individuale;
• MFA;
• badge;
• assegnazione dispositivo;
• accesso fisico;
• turno;
• video lecitamente acquisito;
• dichiarazioni;
• ticket;
• email;
• comportamento successivo.

Nessun elemento deve essere trasformato automaticamente in identità personale.

76. Minimizzazione e oscuramento

Nei dataset possono comparire:

• nomi;
• email;
• indirizzi IP;
• URL;
• documenti;
• query;
• dati sanitari;
• segreti commerciali;
• comunicazioni riservate.

Prevedere:

• dataset completo protetto;
• dataset di lavoro;
• allegato oscurato;
• tabella selettiva;
• pseudonimizzazione;
• controllo degli accessi.

Non oscurare i dati nell’originale.

Produrre una copia derivata documentando le trasformazioni.

77. Caso pratico 1 — Accesso VPN di un ex dipendente

Scenario

Un’azienda romana rileva un accesso VPN attribuito a un ex dipendente tre giorni dopo la cessazione del rapporto.

Fonti

- VPN gateway;
- RADIUS;
- Active Directory;
- DHCP;
- firewall;
- inventario;
- HR;
- laptop aziendale.

Risultati

• account non disabilitato;
• autenticazione riuscita;
• MFA ancora associata al numero personale;
• IP sorgente appartenente a rete residenziale;
• accesso a due server;
• nessun log applicativo sui file;
• laptop aziendale già restituito.

Conclusione prudente

78. Caso pratico 2 — Falso positivo di geolocalizzazione

Scenario

Un professionista di Roma riceve un alert per accessi da Milano e Roma a distanza di tre minuti.

Risultati

- entrambe le sessioni da rete mobile;
- stesso device ID;
- stesso token;
- IP appartenenti allo stesso carrier;
- localizzazione dei nodi di uscita differente;
- nessuna attività anomala.

Conclusione

79. Caso pratico 3 — Cancellazione del Security Log

Scenario

Un server Windows di un’azienda di Roma presenta Event ID 1102 poco prima della creazione di un account amministrativo.

Risultati

• log cancellato;
• account amministrativo utilizzato;
• ticket di manutenzione assente;
• WEF conserva eventi precedenti;
• Sysmon continua a registrare;
• nuova utenza creata dopo nove minuti.

Conclusione

80. Caso pratico 4 — Log firewall e NAT

Scenario

Un provider comunica che un accesso abusivo proveniva dall’IP pubblico di uno studio professionale romano.

Risultati

- IP condiviso da 47 dispositivi;
- NAT dinamico;
- provider non comunica la porta sorgente;
- orario arrotondato al minuto;
- firewall conserva sessioni soltanto per sette giorni;
- segnalazione ricevuta dopo venti giorni.

Conclusione

81. Caso pratico 5 — Ransomware e gap di logging

Scenario

Un’azienda romana subisce cifratura dei server.

Risultati

• EDR disinstallato su due host;
• collector offline per sei ore;
• firewall disponibile;
• Entra ID disponibile;
• backup console registra accesso privilegiato;
• Windows Security sovrascritto.

Conclusione

82. Caso pratico 6 — Download da Microsoft 365

Scenario

Un’azienda di Roma sospetta che un dipendente abbia scaricato documenti da SharePoint prima delle dimissioni.

Risultati

- Purview Audit;
- eventi di download;
- account individuale;
- dispositivo gestito;
- IP VPN aziendale;
- 620 file;
- export suddiviso in intervalli;
- nessun riscontro sulla destinazione successiva.

Conclusione

83. Caso pratico 7 — Google Workspace e link pubblico

Scenario

Uno studio legale di Roma rileva che una cartella Drive era accessibile tramite link.

Risultati

• condivisione modificata da account interno;
• link accessibile senza autenticazione;
• Drive audit disponibile;
• nessun elenco completo dei visitatori anonimi;
• condivisione rimossa dopo l’acquisizione.

Conclusione

84. Caso pratico 8 — AWS CloudTrail incompleto

Scenario

Una società romana chiede chi abbia letto oggetti in un bucket S3.

Risultati

- Event History disponibile;
- management events presenti;
- data events S3 non configurati;
- access log del bucket assente;
- CloudTrail trail creato dopo l’incidente.

Conclusione

85. Caso pratico 9 — Linux e chiave SSH

Scenario

Un server Linux di un’impresa romana registra accessi SSH notturni.

Risultati

• chiave autorizzata aggiunta;
• accesso root disabilitato;
• login account tecnico;
• sudo successivo;
• auditd non configurato sui file sensibili;
• IP proveniente da VPN aziendale.

Conclusione

86. Caso pratico 10 — Account amministrativo condiviso

Scenario

Tre sistemisti di un’azienda romana utilizzano lo stesso account amministrativo.

Risultati

- account condiviso;
- accesso da jump server;
- MFA condivisa;
- nessun PAM;
- change log incompleto;
- modifica firewall non autorizzata.

Conclusione

87. Errori da evitare

Errore 1 — Conservare soltanto screenshot

Si perdono campi e struttura.

Errore 2 — Esportare solo il risultato filtrato

Potrebbero mancare eventi correlati.

Errore 3 — Non acquisire il formato nativo

Si riduce la riproducibilità.

Errore 4 — Ignorare il fuso orario

La sequenza può risultare errata.

Errore 5 — Normalizzare senza conservare il valore originale

Si perde trasparenza.

Errore 6 — Confondere event time e ingest time

Gli eventi possono apparire fuori ordine.

Errore 7 — Attribuire un account a una persona

Le credenziali possono essere condivise o compromesse.

Errore 8 — Attribuire un IP a un dispositivo senza DHCP

L’assegnazione può essere dinamica.

Errore 9 — Attribuire un IP pubblico senza NAT

Mancano porta e sessione.

Errore 10 — Fidarsi della geolocalizzazione

È una stima.

Errore 11 — Considerare un alert una prova conclusiva

Può essere falso positivo.

Errore 12 — Considerare l’assenza di alert come assenza di incidente

La regola può non coprire l’evento.

Errore 13 — Ignorare la configurazione di logging

Determina ciò che può essere registrato.

Errore 14 — Non verificare la retention

I log possono scadere durante l’indagine.

Errore 15 — Modificare la retention senza documentarla

Si altera il contesto.

Errore 16 — Riavviare sistemi indiscriminatamente

Si perdono dati volatili.

Errore 17 — Usare l’account sospetto per acquisire

Si confondono eventi investigativi e precedenti.

Errore 18 — Non registrare l’account di acquisizione

Le query possono generare nuovi audit.

Errore 19 — Non conservare le query

Il risultato non è riproducibile.

Errore 20 — Ignorare i limiti di esportazione

Il file può essere troncato.

Errore 21 — Considerare un CSV completo per definizione

Può dipendere da filtri o limiti.

Errore 22 — Eliminare duplicati dagli originali

Si altera la fonte.

Errore 23 — Ignorare i parser SIEM

Possono interpretare male i campi.

Errore 24 — Confondere traffico consentito e azione riuscita

Sono livelli differenti.

Errore 25 — Confondere login VPN e accesso ai file

La VPN documenta il tunnel.

Errore 26 — Non acquisire DNS e DHCP

Si perdono collegamenti essenziali.

Errore 27 — Non acquisire le configurazioni

Non si può valutare la copertura.

Errore 28 — Applicare una retention universale

La durata deve essere giustificata.

Errore 29 — Raccogliere dati di tutti i dipendenti senza perimetro

Si viola la minimizzazione.

Errore 30 — Pubblicare IP, account o dati sensibili

Si espongono informazioni riservate.

Errore 31 — Considerare l’account admin come autore certo

Può essere condiviso.

Errore 32 — Ignorare account di servizio

Generano molte attività legittime.

Errore 33 — Interpretare ogni scansione come attacco riuscito

Il tentativo può essere bloccato.

Errore 34 — Ignorare la licenza cloud

Determina disponibilità e retention.

Errore 35 — Presumere che i cloud log siano tutti attivi

Molte fonti richiedono configurazione.

Errore 36 — Non documentare i gap

La relazione diventa fuorviante.

Errore 37 — Confondere raw log e dato normalizzato

Il secondo è derivato.

Errore 38 — Non verificare la sincronizzazione temporale

La correlazione può essere falsa.

Errore 39 — Sovrastimare un singolo IOC

Un IP o hash può avere più spiegazioni.

Errore 40 — Scrivere conclusioni giuridiche

Il perito deve rimanere nell’ambito tecnico.

88. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] committente;
[ ] titolare sistemi;
[ ] account;
[ ] tenant;
[ ] periodo;
[ ] quesito;
[ ] privacy;
[ ] legale;
[ ] limiti.

Fase 2 — Valutazione dell’urgenza

[ ] incidente attivo;
[ ] ransomware;
[ ] account privilegiati;
[ ] esfiltrazione;
[ ] retention prossima alla scadenza;
[ ] log sovrascrivibili;
[ ] fornitori;
[ ] obblighi di notifica.

Fase 3 — Inventario

[ ] endpoint;
[ ] server;
[ ] firewall;
[ ] VPN;
[ ] DNS;
[ ] DHCP;
[ ] cloud;
[ ] SIEM;
[ ] applicazioni;
[ ] fornitori.

Fase 4 — Tempo

[ ] ora locale;
[ ] UTC;
[ ] NTP;
[ ] offset;
[ ] drift;
[ ] precisione;
[ ] timezone per fonte.

Fase 5 — Configurazione

[ ] logging abilitato;
[ ] canali;
[ ] filtri;
[ ] retention;
[ ] rotazione;
[ ] forwarding;
[ ] parser;
[ ] esclusioni;
[ ] licenze.

Fase 6 — Acquisizione

[ ] formato nativo;
[ ] raw event;
[ ] export;
[ ] query;
[ ] screenshot;
[ ] configurazione;
[ ] errori;
[ ] conteggio.

Fase 7 — Conservazione

[ ] originali;
[ ] copie lavoro;
[ ] SHA-256;
[ ] accessi;
[ ] cifratura;
[ ] catena di custodia.

Fase 8 — Normalizzazione

[ ] timestamp originale;
[ ] UTC;
[ ] account;
[ ] IP;
[ ] porte;
[ ] sessione;
[ ] host;
[ ] evento;
[ ] raw reference.

Fase 9 — Correlazione

[ ] identità;
[ ] DHCP;
[ ] NAT;
[ ] VPN;
[ ] firewall;
[ ] endpoint;
[ ] applicazione;
[ ] cloud;
[ ] accessi fisici.

Fase 10 — Analisi

[ ] autenticazioni;
[ ] processi;
[ ] privilegi;
[ ] traffico;
[ ] file;
[ ] condivisioni;
[ ] cancellazioni;
[ ] gap;
[ ] persistenza.

Fase 11 — Timeline

[ ] evento originale;
[ ] evento normalizzato;
[ ] fonte;
[ ] attendibilità;
[ ] deduzione;
[ ] limite.

Fase 12 — Relazione

[ ] materiale;
[ ] metodo;
[ ] fonti;
[ ] copertura;
[ ] risultati;
[ ] correlazioni;
[ ] limiti;
[ ] conclusioni;
[ ] allegati;
[ ] hash.

89. Checklist finale

Perimetro

[ ] incarico;
[ ] autorizzazione;
[ ] sistemi;
[ ] utenti;
[ ] periodo;
[ ] privacy;
[ ] fornitori.

Acquisizione

[ ] raw;
[ ] formato nativo;
[ ] query;
[ ] configurazione;
[ ] timezone;
[ ] errori;
[ ] conteggio;
[ ] hash.

Rete

[ ] firewall;
[ ] NAT;
[ ] VPN;
[ ] RADIUS;
[ ] DHCP;
[ ] DNS;
[ ] proxy;
[ ] NetFlow.

Endpoint

[ ] Windows;
[ ] Sysmon;
[ ] PowerShell;
[ ] Linux;
[ ] auditd;
[ ] EDR;
[ ] processi;
[ ] account.

Cloud

[ ] Entra;
[ ] Microsoft 365;
[ ] Google Workspace;
[ ] Azure;
[ ] AWS;
[ ] Google Cloud;
[ ] SaaS;
[ ] retention.

Analisi

[ ] normalizzazione;
[ ] deduplicazione;
[ ] correlazione;
[ ] baseline;
[ ] falsi positivi;
[ ] gap;
[ ] attribuzione;
[ ] limiti.

Relazione

[ ] fatti separati dalle deduzioni;
[ ] valori temporali originali;
[ ] conclusioni prudenti;
[ ] dati oscurati;
[ ] allegati verificabili;
[ ] hash degli output.

90. Output minimo dell’accertamento

1. incarico;
2. verbale;
3. inventario delle fonti;
4. registro dei reperti;
5. configurazioni di logging;
6. configurazioni temporali;
7. log Windows EVTX;
8. log Sysmon;
9. log PowerShell;
10. journal Linux;
11. auditd;
12. log firewall;
13. log NAT;
14. log VPN;
15. log RADIUS;
16. log DHCP;
17. log DNS;
18. log proxy;
19. log EDR;
20. export SIEM;
21. query utilizzate;
22. Entra ID;
23. Microsoft Purview;
24. Google Workspace;
25. Azure Activity Log;
26. Azure resource log;
27. AWS CloudTrail;
28. Google Cloud Audit Logs;
29. applicazioni SaaS;
30. manifesti SHA-256;
31. dataset normalizzato;
32. tabella dei gap;
33. timeline;
34. matrice di correlazione;
35. elenco indicatori;
36. relazione tecnica;
37. allegati;
38. hash degli output.

91. Struttura della relazione tecnica

91.1 Incarico

• committente;
• quesito;
• autorizzazione;
• perimetro;
• periodo;
• limiti.

91.2 Architettura

• sistemi;
• reti;
• cloud;
• identità;
• collector;
• SIEM.

91.3 Fonti

• origine;
• formato;
• retention;
• timezone;
• copertura;
• hash.

91.4 Metodo

• acquisizione;
• strumenti;
• versioni;
• query;
• normalizzazione;
• correlazione.

91.5 Risultati

• accessi;
• processi;
• traffico;
• privilegi;
• file;
• cloud;
• cancellazioni;
• gap.

91.6 Timeline

• eventi;
• UTC;
• fonte;
• livello di attendibilità;
• deduzioni.

91.7 Attribuzione

• account;
• sessione;
• IP;
• dispositivo;
• persona;
• alternative;
• limiti.

91.8 Conclusioni

Risposte tecniche proporzionate al quesito.

92. Modelli di frasi tecniche

92.1 Evento registrato

92.2 Accesso riuscito

92.3 Tentativo fallito

92.4 Account

92.5 IP

92.6 NAT

92.7 VPN

92.8 Firewall

92.9 DNS

92.10 Processo

92.11 Cloud audit

92.12 Export incompleto

92.13 Retention scaduta

92.14 Gap

92.15 Cancellazione

92.16 Clock drift

92.17 SIEM

92.18 False positive

92.19 File download

92.20 Assenza di evento

92.21 Attribuzione

92.22 Conclusione generale

93. Immagini e figure suggerite

94. Riferimenti tecnici e normativi esterni

1. NIST SP 800-92 — Guide to Computer Security Log Management.
2. NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations.
3. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response.
4. RFC 5424 — The Syslog Protocol.
5. RFC 5848 — Signed Syslog Messages.
6. RFC 8633 — Network Time Protocol Best Current Practices.
7. Garante per la protezione dei dati personali — Amministratori di sistema e access log.
8. Regolamento UE 2016/679 — Sicurezza del trattamento.
9. Decreto legislativo n. 138/2024 — Recepimento NIS2.
10. Regolamento di esecuzione UE 2024/2690 — Monitoraggio e logging.
11. ENISA — Technical Implementation Guidance on Cybersecurity Risk Management Measures, 2025.
12. Microsoft — Windows security event sets e principali Event ID.
13. Microsoft — Sysmon events e correlazione dei processi.
14. Microsoft — Entra ID log retention.
15. Microsoft — Purview Audit export e retention.
16. Microsoft — Azure Activity Log e resource logs.
17. Google Workspace — Reports API e audit tool.
18. AWS — CloudTrail Event History e log file integrity validation.
19. Google Cloud — Cloud Audit Logs e retention dei bucket.
20. Microsoft — NPS, RADIUS e accounting.

95. Collegamenti interni consigliati

Capitolo precedente

• Truffe online, bonifici fraudolenti e financial cybercrime

Capitolo successivo

• Incident response forense e ransomware

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Dipendente infedele, sottrazione dati e uso di USB
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

96. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/consulente-tecnico-parte-informatico-roma/
/servizi/incident-response-forense/
/contatti/

Anchor text consigliati

analisi forense dei log aziendali a Roma
perizia su firewall e VPN
ricostruzione degli accessi informatici
analisi Windows Event Log
analisi dei log Linux
correlazione DNS e DHCP
verifica delle sessioni VPN
analisi Microsoft Entra ID
perizia Microsoft 365
analisi Google Workspace
verifica AWS CloudTrail
analisi Azure Activity Log
analisi Google Cloud Audit Logs
timeline di un incidente informatico
consulente informatico forense per aziende a Roma

97. Box commerciale finale

Devi ricostruire accessi, connessioni o attività aziendali a Roma?

Lo Studio Quaranta Digital Forensics può supportare aziende, professionisti, studi legali, responsabili IT e consulenti nell’acquisizione e nell’analisi tecnica di:

[ ] Windows Event Log;
[ ] Sysmon;
[ ] PowerShell;
[ ] Linux journal e auditd;
[ ] Active Directory;
[ ] firewall;
[ ] NAT;
[ ] VPN;
[ ] RADIUS;
[ ] DNS;
[ ] DHCP;
[ ] proxy;
[ ] EDR e XDR;
[ ] SIEM;
[ ] Microsoft Entra ID;
[ ] Microsoft 365;
[ ] Google Workspace;
[ ] Azure;
[ ] AWS;
[ ] Google Cloud;
[ ] piattaforme SaaS.

L’attività può comprendere:

• acquisizione forense dei log;
• verifica dell’integrità;
• normalizzazione temporale;
• analisi di account e sessioni;
• correlazione tra IP e dispositivi;
• ricostruzione di accessi VPN;
• analisi di traffico e NAT;
• verifica di ruoli e privilegi;
• ricostruzione di download e condivisioni;
• individuazione di gap;
• timeline dell’incidente;
• supporto al data breach;
• relazione tecnica;
• assistenza al legale e al CTP.

98. Conclusione del capitolo

L’analisi dei log aziendali non consiste nel cercare una singola riga che “dimostri tutto”.

Una corretta attività deve ricostruire una catena:

evento
→ fonte
→ registrazione
→ conservazione
→ esportazione
→ normalizzazione
→ correlazione
→ interpretazione
→ conclusione

Ogni fonte osserva soltanto una parte dell’infrastruttura.

Il firewall vede il traffico.

La VPN vede il tunnel.

Il DHCP associa temporalmente un indirizzo.

L’identity provider registra l’autenticazione.

L’endpoint registra processi e attività locali.

Il cloud registra azioni secondo servizio, licenza e configurazione.

Il SIEM raccoglie e interpreta, ma non sostituisce automaticamente le fonti originarie.

Una relazione tecnicamente corretta deve indicare:

- quali fonti sono state acquisite;
- quali fonti non erano disponibili;
- quale periodo era coperto;
- quale fuso era utilizzato;
- come sono stati verificati gli orologi;
- quali filtri sono stati applicati;
- quali gap sono stati rilevati;
- quali correlazioni sono forti;
- quali restano ipotesi;
- quali limiti impediscono conclusioni ulteriori.

99. Anticipazione del capitolo successivo

Capitolo 21 — Incident response forense e ransomware

Il prossimo capitolo tratterà:

• attivazione del piano di risposta;
• triage dell’incidente;
• isolamento dei sistemi;
• acquisizione della memoria;
• preservazione dei log;
• identificazione del patient zero;
• accesso iniziale;
• movimento laterale;
• persistenza;
• esfiltrazione;
• cifratura;
• note di riscatto;
• indicatori di compromissione;
• analisi EDR e SIEM;
• backup;
• contenimento;
• eradicazione;
• recupero;
• data breach;
• rapporto con autorità, assicurazione e fornitori;
• relazione tecnica e lesson learned.

Continua con il Capitolo 21 — Incident response forense e ransomware →