Incidenti e indicatori: creazione, stati e MITRE ATT&CK

L’evento è un fatto tecnico, l’incidente è un caso di lavoro: ha un proprietario, uno stato, una storia e una pagina dove tutto converge. Gli indicatori sono i valori atomici — IP, URL, dominio — che quel caso porta con sé.

Tre modi di far nascere un incidente

Il primo è manuale: Create New apre un pannello vuoto con nome, categoria, severità, stato, endpoint interessato e assegnatario. Il secondo parte dall’evento: nell’Event Monitor il tasto destro offre Create New Incident e apre lo stesso pannello già compilato, a partire dall’endpoint. Vale un vincolo da ricordare: un incidente si alza da alert generati per un solo endpoint.

Il terzo è automatico ed è quello che scala. Nell’event handler, basic o correlation, esiste l’opzione Automatically Create Incident. Quando è attiva, al primo alert nasce un incidente il cui nome combina il nome dell’handler e il soggetto dell’evento. Gli alert successivi con lo stesso soggetto non creano nuovi casi: si attaccano a quello esistente. Un caso nuovo nasce solo se il soggetto cambia oppure se quello vecchio è passato in stato Closed. È il comportamento che vuoi per non annegare, ma anche la trappola: se chiudi troppo presto, il rumore successivo riapre un caso identico. La colonna Incident Reporter distingue l’origine: un incidente automatico mostra un identificativo seguito da Auto-Raised, oppure il nome del playbook o dell’handler che lo ha generato.

Stati, campi immutabili e chi può toccare cosa

Lo stato segue cinque valori: New, Analysis, Response, Closed: Remediated e Closed: False Positive. La distinzione fra i due stati di chiusura non è cosmetica: misura quanto ti costano i falsi positivi. La severità è su tre livelli; la categoria sceglie fra Unauthorized Access, Denial of Service, Malicious Code, Improper Usage, Scans/Probes/Attempted Access e Uncategorized.

Tre campi non si modificano dopo la creazione: numero dell’incidente, data e ora di creazione, endpoint interessato. Se hai sbagliato endpoint devi rifare il caso. Tutto il resto lo traccia il widget Audit History: chi ha cambiato cosa e quando.

Il controllo di accesso è controintuitivo. Per un analista non si crea un profilo con permessi pieni: si imposta Incidents & Events su Read-Only e si portano a Read-Write solo le voci operative — Create & Update Incidents, Triage Event, Execute Playbook, Run Report. Triage Event consente di acknowledge, commentare, vedere i log e agganciare eventi agli incidenti. Così l’analista lavora senza poter riscrivere gli handler.

La pagina di analisi è la console operativa

Doppio clic su un incidente e sei nell’Incident Analysis: widget riposizionabili e salvabili per sommario, endpoint e utente colpiti, asset, timeline, eventi, commenti, audit history, playbook eseguiti, indicatori e report, più i tre di contesto endpoint — Processes, Software e Vulnerabilities — leggibili per snapshot temporali.

Dalla toolbar agisci senza cambiare pagina: Enrich sugli indicatori, Execute Playbook per un playbook con trigger On_Demand, Quarantine per isolare l’endpoint scegliendo endpoint e connettore, Run Report, Export in HTML o PDF. Su Run Report c’è un limite che sorprende: solo i report con Auto Cache ed Extended Log Filtering abilitati possono partire da un incidente. Se il report che ti serve non compare, il problema è nelle sue impostazioni, non nell’incidente. Dal widget Events salti a View Logs o apri Log View già filtrata.

Indicatori ed enrichment

Gli indicatori sono di tre tipi — IP, URL e dominio — e arrivano da più strade: creati a mano, generati da un event handler (fino a cinque per handler), o attaccati da un playbook tramite i connettori FortiGuard e FortiMail. La colonna Source distingue l’amministratore dall’auto-created.

L’enrichment li arricchisce con intelligence esterna: FortiGuard fornisce confidenza, tag IOC e categorie; VirusTotal la reputazione — Malicious, Suspicious, Harmless o Undetected. Tre cose da sapere. FortiGuard è integrato e pronto, mentre VirusTotal pretende una API key nel suo connettore, che va anche abilitato. L’enrichment gira attraverso un playbook predefinito, abilitato di default e in sola lettura. E il pannello non salva da solo: finché non premi Save Enrichment l’indicatore non viene processato. Se il pulsante Enrich è spento, quasi sempre gli indicatori sono indirizzi privati, che non sono indicatori validi.

Il rescan IOC, che richiede licenza IOC, rilegge invece i log storici con le definizioni più recenti — per default DNS, web filter e traffico sugli ultimi 14 giorni. I log rianalizzati ricevono il tag Ioc_Rescan, e solo gli handler che includono quel tag nelle regole produrranno alert dal rescan.

MITRE ATT&CK: due matrici, due letture

Le matrici sono ATT&CK e ATT&CK ICS, quest’ultima piena solo con il servizio OT Security: colonne le tattiche, riquadri le tecniche. La distinzione sta fra le due schede. Attack risponde a «cosa è successo»: eventi e incidenti associati a ciascuna tecnica, con conteggi cliccabili per scendere all’Event Monitor o alla lista incidenti già filtrati. Coverage risponde a «cosa saprei vedere»: gli handler associati a ogni tecnica, con il loro stato Enabled o Disabled.

Quel legame non è automatico. È il campo MITRE Tech ID dell’handler — e quello dell’incidente, quando lo compili a mano — a popolare le matrici. Un handler può coprire più tecniche e sotto-tecniche. Un riquadro senza icone significa che nessun handler copre quella tecnica: è una lacuna di rilevamento, non un’assenza di attacchi. E dopo aver aggiornato la copertura di un handler devi ricaricare la matrice per vederlo.