Le fasi di un incidente e il loro ciclo di vita

La fase di un incidente è il modo in cui FortiSOAR risponde alla domanda «a che punto siamo della risposta». È diversa dallo stato: lo stato dice se il record è aperto o chiuso, la fase dice in quale momento del ciclo di risposta ti trovi. Chi arriva da altri prodotti dà per scontato che le fasi siano una funzione di piattaforma. In FortiSOAR non lo sono, ed è il tipo di dettaglio che senza credito parziale ti costa la domanda intera.

Il modulo Incidents non è nella piattaforma

Dalla release 7.2.0 i moduli di incident response — Alerts, Incidents, Indicators e War Rooms — sono stati rimossi dalla piattaforma FortiSOAR e spostati nel SOAR Framework Solution Pack. È la solution pack fondazionale: crea moduli, dashboard, ruoli e widget necessari a un SOC. Sulle installazioni nuove dalla 7.2.0 viene installata di default; su un sistema aggiornato può comparire il link Update Available sulla card della SP, nella scheda Manage del Content Hub.

Le conseguenze sono tre. Senza SOAR Framework SP non esiste il modulo Incidents, quindi non esiste alcun campo Fase. I valori concreti delle fasi non sono una costante di prodotto: arrivano dalla solution pack e sono modificabili. E la stessa architettura vale per ogni contenuto che aggiungerai dopo, incluso il framework MITRE.

Un incidente, nella definizione FortiSOAR, raccoglie le informazioni scoperte durante un’indagine di incident response e nasce dal sospetto o dalla conferma di una violazione, informatica o fisica. Il record traccia dati come i tempi di contenimento e di ripristino. Accanto alla fase lavorano i Task: possono essere generati automaticamente in base al tipo di incidente e restano collegati al record per tutto il ciclo di vita, dando una vista operativa che va oltre la sola fase.

Come un incidente entra nel ciclo e come avanza

Il flusso standard parte dagli Alert. Il pulsante Escalate, presente di default sul modulo Alerts, è un manual trigger che lancia il playbook di escalation: crea un nuovo incidente in base agli input forniti, collega l’alert al nuovo incidente e il nuovo incidente all’alert, e mette Yes nella colonna Escalated della riga dell’alert.

Attenzione a un default che sembra innocuo: nella maschera di escalation la severity dell’incidente è preimpostata a Medium, e anche il motivo ha un testo predefinito. L’incidente non eredita la severity dell’alert critico da cui nasce: se lasci il campo com’è, lo hai appena declassato.

Da lì l’incidente si muove con le azioni di modulo: Change Status, Change Severity, Change Queue, Reassign, Execute per i playbook manuali, e Resolve per la chiusura. Resolve apre una finestra in cui il motivo di chiusura è obbligatorio, finisce nel campo Closure Notes e porta lo stato del record a Closed. Nella scheda Correlations colleghi e scolleghi record e puoi cambiare stato, severity e lead direttamente dalla griglia dei correlati. Una regola di sicurezza da ricordare: i permessi sui record correlati derivano dal record padre, quindi vedi in sola lettura un incidente collegato a cui altrimenti non avresti accesso.

La fase è una picklist, e le picklist hanno regole proprie

Governare le fasi significa governare una picklist, e il Picklist Editor si comporta diversamente dal Module Editor: le modifiche sono immediatamente attive al salvataggio, perché nomi e valori delle picklist sono record nel database. Non c’è nessun Publish che ti protegge da un errore.

Gli item di picklist sono identificati da un UUID, e questo è a tuo favore: se rinomini una fase, tutti i record che la usano continuano a puntare allo stesso UUID e mostrano il nuovo nome. Rinominare è sicuro, cancellare no.

Il pezzo davvero operativo è la visibilità condizionata. Nel Module Editor, su un campo picklist, la casella Configure Picklist Item Visibility apre cinque stati per ogni item: Visible, Disabled, Hidden, Conditionally Visible, Conditionally Enabled. È così che impedisci a un analista di saltare all’ultima fase: rendi l’item Conditionally Enabled e scrivi la condizione. Occhio alla differenza fra Hidden e Disabled: un item Hidden non compare in creazione o modifica, ma resta ricercabile. E non impostare mai Visibility su Hidden per un campo Required by condition.

Due dettagli minori che fanno danni: i caratteri speciali non sono ammessi nei nomi degli item, e nei playbook i confronti sulle picklist si fanno per IRI, mentre il filtro picklist dalla 7.2.0 pretende la corrispondenza esatta di maiuscole e minuscole sul valore. Il valore di partenza di una nuova fase si imposta come Default Value del campo, nel Module Editor.

MITRE ATT&CK: dove sta davvero

Anche il framework MITRE ATT&CK è contenuto, non piattaforma: si installa dal Content Hub come solution pack MITRE ATTACK Enrichment Framework, che porta la knowledge base del framework dentro il prodotto. Perché il Content Hub funzioni, questo host deve essere raggiungibile dall’istanza, altrimenti la pagina resta bianca.

repo.fortisoar.fortinet.com

Due comportamenti da sapere. Se una tua solution pack personalizzata dichiara una dipendenza dal MITRE Framework, quella SP viene installata automaticamente se manca. Se invece esporti una SP del repository e la importi su un altro sistema, lì diventa una SP locale personalizzata e smette di ricevere aggiornamenti: non spostare il MITRE per esportazione. Infine, tieni distinti i due assi: la fase dice a che punto è la tua risposta, la mappatura ATT&CK dice cosa sta facendo l’avversario.