Un playbook di FortiAnalyzer è un grafo: un trigger di partenza e uno o più task collegati. Ogni task parte quando il playbook è scattato e tutti i task che lo precedono sono conclusi; il playbook finisce quando non restano task. Per crearli serve Read-Write su Incidents & Events; per limitarsi a lanciarli basta Execute Playbook.

Un solo trigger, quattro forme

Il trigger è sempre il primo passo e ogni playbook ne ha uno e uno solo. Le forme sono quattro. EVENT_TRIGGER parte quando nasce un evento che corrisponde ai filtri; INCIDENT_TRIGGER quando nasce un incidente. Entrambi accettano filtri in AND o in OR fra le condizioni, e qui c’è la trappola più costosa: se non imposti nessun filtro, il playbook parte su tutti gli eventi o su tutti gli incidenti. Su un ADOM di produzione significa mandare in quarantena mezza rete, quindi il filtro va messo prima di abilitare, non dopo.

ON_SCHEDULE esegue il playbook su una pianificazione — ora di inizio, ora di fine, tipo e frequenza dell’intervallo — ed è la forma giusta per l’igiene ricorrente, tipo aggiornare l’asset and identity database da FortiClient EMS. ON_DEMAND si lancia a mano, dalla lista dei playbook oppure dal pulsante Execute Playbook nella pagina di analisi di un incidente: è il trigger dei playbook di risposta che un analista decide di applicare a un caso specifico. Un playbook con trigger diverso da ON_DEMAND non compare in quell’elenco, ed è il motivo per cui un playbook «non si riesce a lanciare» pur essendo abilitato.

I connettori decidono cosa puoi fare

Un task esegue un’azione, ma l’elenco delle azioni disponibili non è fisso: dipende dai connettori attivi. Local, FortiGuard e VirusTotal ci sono già; gli altri li devi creare. Il connettore locale agisce su FortiAnalyzer stesso: Create Incident, Update Incident, Attach Data to Incident, Run Report, Get Events, oltre alle azioni di enrichment. Gli altri si dividono in due famiglie: i Security Fabric connector (FortiClient EMS, FortiMail, FortiCASB, FortiAuthenticator, FortiWeb, FortiSandbox), che arricchiscono le azioni di risposta, e gli ITSM connector (ServiceNow, Slack, MS Teams e un webhook generico), che portano l’informazione fuori. Il pallino sulla card dice se l’API risponde: verde riuscita, arancione ignota, rossa caduta.

Il connettore FortiOS merita un paragrafo a sé. Compare da solo appena il primo FortiGate è autorizzato nell’ADOM, ma le sue azioni non sono un catalogo Fortinet: sono le automation rule configurate su ciascun FortiGate. Le regole devono usare il trigger Incoming Webhook, devono essere abilitate su FortiOS per comparire fra le azioni, e devono avere nomi univoci — regole omonime su FortiGate diversi vengono considerate la stessa regola e appaiono una volta sola. Quando ci sono più FortiGate, FortiAnalyzer sceglie a chi mandare la chiamata in base al devid, cioè al numero di serie indicato nel task, che puoi scrivere a mano o ricevere da un task precedente. Morale: se l’azione che ti aspetti non compare nel dropdown, il problema è quasi sempre sul FortiGate, non sul FortiAnalyzer.

Variabili: legare l’output di un task all’input del successivo

Un playbook diventa utile quando i task si passano dati. Le variabili sono di due tipi. Le trigger variable pescano dall’evento o dall’incidente che ha fatto partire il playbook, e servono per esempio a filtrare un report sull’IP dell’endpoint colpito. Le output variable prendono il risultato di un task precedente e lo usano come input, per esempio per allegare a un incidente il report generato un passo prima.

${trigger.epip}
${id_2c7_84b_2c5_f47.vulnerabilities}

La prima forma è la trigger variable, la seconda l’output variable: identificativo del task, punto, nome dell’output. Il task ID esiste sempre — viene assegnato automaticamente a ogni task — ma la GUI non lo mostra. Per leggerlo crei un task Attach Data to Incident del connettore locale e apri il dropdown Attachment: selezionando un task precedente ne vedi l’identificativo, e in modalità testo lo copi. È un aggiramento, ma è la strada documentata.

Template, portabilità e diagnosi

Non serve partire da zero. Alla creazione puoi scegliere un template già cablato con trigger e task: Compromised Host Incident e Critical Intrusion Incident creano l’incidente rispettivamente sugli host compromessi rilevati via IoC e sulle intrusioni critiche rilevate da IPS; Quarantine Endpoint by FortiOS isola un endpoint per MAC address o UID FortiClient; la famiglia FortiClient EMS copre scansione antivirus e vulnerabilità, quarantena e revoca, e l’arricchimento di un incidente con processi, software o vulnerabilità.

I playbook si esportano e importano dal menu contestuale, in JSON in chiaro o zippato in base64, scegliendo se includere i connettori. È il modo per portare un playbook da un lab a un ADOM di produzione. Se il nome esiste già, FortiAnalyzer non sovrascrive: rinomina l’importato aggiungendo il timestamp.

La diagnosi vive nel Playbook Monitor, dove ogni esecuzione è un job con ID, orari, utente che l’ha lanciato e stato Running, Success o Failed. L’icona Details apre il dettaglio task per task, con stati Scheduled, Success, Failed e Upstream_failed — quest’ultimo indica un task fallito perché non è riuscito a raggiungere un dispositivo a monte. Attenzione a come si legge il verdetto: un job è marcato Failed anche se un solo task è fallito, quindi le azioni degli altri task possono essere state eseguite davvero. Prima di rilanciare un playbook di risposta, apri sempre il dettaglio e guarda cosa è già andato a buon fine.