Un log diventa un evento perché lo ha deciso un handler, e un evento diventa un incidente perché lo ha deciso un analista o una regola che qualcuno ha configurato. Sapere chi prende quale decisione, e con quali stati, è ciò che l’esame chiama analisi di eventi e incidenti.

Chi genera gli eventi: basic e correlation handler

Gli event handler sono di due tipi. In un basic handler ogni regola sta in OR con le altre: basta che una si verifichi e l’evento nasce. In un correlation handler definisci sia le regole sia gli operatori che le legano in sequenza, e gli operatori disponibili sono AND, AND_NOT, OR, FOLLOWED_BY e NOT_FOLLOWED_BY: è lì che si esprime «prima questo, poi quello, entro tanti minuti».

Esistono handler predefiniti per FortiGate, FortiSandbox, FortiMail e FortiWeb, alcuni disabilitati per default. Non si cancellano e alcuni campi non si modificano: per personalizzarli si clona il predefinito e si lavora sul clone. Due oggetti sono tenuti separati dagli handler per essere riusati: il data selector, che sceglie dispositivi, subnet e filtri, e il notification profile, che decide se e dove mandare la notifica via email, SNMP, syslog o fabric connector.

Tre vincoli da non dimenticare. Gli handler generano eventi solo dagli Analytics log, mai dagli Archive. Con gli ADOM abilitati ogni ADOM ha i propri handler e la propria lista di eventi, quindi davanti a una console vuota la prima domanda è sempre «sono nell’ADOM giusto». E in uno scenario Analyzer-Collector è l’Analyzer a valutarli. Due note: la documentazione 7.6 alterna «Handlers» e «Event Handlers» nel menu Incidents & Events, a volte nella stessa pagina, quindi non fissarti su una delle due forme; e gli alert handler appartengono alla 8.0, in 7.6 si chiamano event handler.

Gli stati dell’evento non descrivono il tuo lavoro

Nell’Event Monitor la colonna Event Status vale Unhandled, Mitigated, Contained o vuoto. È l’handler ad assegnarlo, e in un handler personalizzato puoi imporlo o lasciare scegliere FortiAnalyzer. Nel secondo caso la regola è questa: un log IPS o antivirus con action pass diventa Unhandled, con quarantine diventa Contained, con block o drop diventa Mitigated; botnet e IoC sono considerati Unhandled.

Qui casca chi legge quegli stati come stati di lavorazione. Unhandled non significa «nessuno lo ha ancora guardato»: significa che il traffico è passato. È una proprietà del log, non del turno del SOC. Il tuo avanzamento si registra altrove: prendendo in carico l’evento con l’acknowledge, commentandolo e soprattutto alzando o agganciando un incidente. Puoi anche definire stati personalizzati, che compaiono nella stessa colonna.

Le viste per endpoint e per minaccia sono alimentate dai tag che gli handler applicano, e ognuna richiede handler predefiniti precisi: Compromised Hosts e C&C Call Backs, per esempio, vivono sui default di botnet detection e rilevamento IoC. Una vista ostinatamente vuota di solito è un handler spento.

Alzare un incidente, a mano o da solo

Un incidente si crea in due modi: dal pannello Incidents con Create New, oppure con il tasto destro su un evento in All Events scegliendo Create New Incident, e in questo secondo caso i campi arrivano precompilati e l’endpoint coinvolto non è più modificabile. Un limite da ricordare: un incidente si alza solo da alert generati per un singolo endpoint.

I campi da conoscere sono categoria, tecniche MITRE, severità e stato. Le categorie sono Unauthorized Access, Denial of Service, Malicious Code, Improper Usage, Scans/Probes/Attempted Access e Uncategorized; la severità è High, Medium o Low; gli stati sono New, Analysis, Response, Closed: Remediated e Closed: False Positive. Assegnare l’incidente a un amministratore è un campo come gli altri, ed è ciò che rende leggibile la coda di lavoro.

La creazione può anche essere automatica: un handler con quell’opzione attiva genera un incidente il cui nome unisce il nome dell’handler e il soggetto dell’evento. Eventi successivi con lo stesso soggetto si attaccano allo stesso incidente, mentre un soggetto nuovo, o un incidente già chiuso, ne fanno nascere un altro. Li riconosci dalla colonna Incident Reporter, che riporta Auto-Raised invece di un nome umano. Dalla 7.6.0 gli handler del servizio outbreak nascono con l’opzione già attiva: non stupirti di trovare incidenti che nessuno ha creato.

Analizzare, tracciare e limitare i permessi

La pagina di analisi è un cruscotto per singolo incidente: riepilogo modificabile, timeline, lista degli eventi con View Logs e Search in Log View per tornare ai log grezzi, commenti datati, indicatori, playbook eseguiti, asset ed endpoint coinvolti. Da lì puoi mettere in quarantena l’endpoint tramite connettore, eseguire un playbook e allegare un report, con l’avvertenza che dall’incidente si eseguono solo i report con Auto Cache ed Extended Log Filtering abilitati.

Due cose fanno la differenza. Audit History registra chi ha cambiato cosa: quando qualcuno chiede perché un incidente è stato chiuso, la risposta sta lì. E l’analisi si esporta in HTML o PDF, la tabella in CSV. Nelle impostazioni puoi far notificare creazione, aggiornamento ed eliminazione a un fabric connector, per esempio ServiceNow o MS Teams; gli incidenti in stato draft non generano notifica.

Sul fronte permessi, il profilo giusto per un analista imposta Incidents & Events in sola lettura e concede in scrittura solo il necessario: creazione e aggiornamento degli incidenti, triage degli eventi, esecuzione di playbook e report. Così lavora sui casi senza poter toccare la configurazione degli handler, da cui dipende l’SLA di rilevamento.