Un playbook di FortiAnalyzer, da solo, sa fare pochissimo: crea incidenti, allega dati, lancia report, legge lo stato del sistema. Tutto il resto — mettere in quarantena un endpoint, bloccare un mittente, aprire un ticket — lo ottiene chiedendolo a qualcun altro attraverso un connettore. Sapere dove finisce FortiAnalyzer e dove comincia il resto del Security Fabric è metà del lavoro su questo obiettivo. E chiariamolo subito: i playbook di FortiAnalyzer sono nativi del prodotto, i connettori documentati sono di due famiglie, Security Fabric e ITSM.

Dove vivono i connettori e come si leggono

Li trovi sotto Incidents & Events, in Automation, nella scheda Active Connectors: la stessa pagina elenca i connettori e le azioni che possono eseguire nei playbook.

Alcuni esistono già senza che tu faccia niente. Il connettore Local è FortiAnalyzer stesso ed espone le azioni che girano sulla macchina: Create Incident, Update Incident, Attach Data to Incident, Run Report, Get Events, Update Asset and Identity, i tre passi di enrichment e qualche diagnostica come Get Disk Usage o Get CPU Usage. Il connettore FortiGuard si configura da solo quando c’è una licenza valida e offre Lookup Indicator e FGD Enrich. VirusTotal c’è di default, ma resta inerte finché non gli metti la API key.

La prima cosa da guardare quando qualcosa non gira è il pallino di stato: verde è connessione API riuscita, arancione stato sconosciuto, rosso connessione caduta.

Creare un connettore Security Fabric

Da Create New scegli il tipo sotto Security Fabric: FortiClient EMS, FortiMail, FortiCASB, FortiAuthenticator, FortiWeb, FortiSandbox. Il grosso è banale — nome, IP o FQDN, credenziali — ma ogni tipo ha un campo che fa la differenza:

  • FortiClient EMS Cloud non chiede un IP ma un Account ID, vuole EMS 7.0 o successivo e dopo la creazione manda una richiesta di autenticazione che qualcuno deve approvare dentro EMS, in Administration > Fabric Devices. Finché non la approvano il connettore resta rosso.
  • FortiWeb chiede l’ADOM in cui sta il dispositivo; FortiSandbox chiede versione e tipo di istanza, On Premise o Cloud.
  • FortiCASB chiede un token generato in FortiCASB e l’FQDN giusto per la tua area: forticasb.com per i server globali, eu.forticasb.com per quelli europei.

La scheda Actions mostra cosa saprà fare il connettore prima ancora di salvarlo: guardala, perché è lì che scopri se ti serve davvero. Dopo il salvataggio compare in elenco con un toggle.

Effetto collaterale da ricordare: creare certi connettori genera automaticamente un playbook. FortiCASB, per esempio, crea Get Cloud Service Data, che va abilitato se vuoi usare l’event handler predefinito Default-Shadow-IT-Events.

Il connettore FortiOS non decide le proprie azioni

Qui si perdono punti. Il connettore FortiOS compare da solo appena il primo FortiGate viene autorizzato nell’ADOM, ed è disponibile negli ADOM FortiGate e Fabric; i dispositivi successivi appaiono come voci separate dentro lo stesso connettore.

Ma l’elenco delle sue azioni non lo scrive FortiAnalyzer: sono le automation rule configurate su ciascun FortiGate, in Security Fabric > Automation. Le regole sono quattro:

  • la regola deve usare il trigger Incoming Webhook;
  • si configura su ogni FortiGate singolarmente;
  • appare in Active Connectors solo quando è abilitata in FortiOS;
  • deve avere un nome univoco, perché regole omonime vengono mostrate una volta sola: FortiAnalyzer le considera la stessa regola replicata su più dispositivi.

Con più connettori FortiOS, FortiAnalyzer sceglie a quale dispositivo parlare in base al devid, il numero di serie indicato nel task, inserito a mano o fornito da un task precedente. Morale: se l’azione che cerchi non c’è nel menu del task, il problema è sul FortiGate, non su FortiAnalyzer.

Trigger, task e variabili

Un playbook è un trigger più uno o più task. I trigger sono quattro — EVENT_TRIGGER, INCIDENT_TRIGGER, ON_SCHEDULE, ON_DEMAND — e ogni playbook ne ammette uno solo. Sui trigger di evento e incidente i filtri si combinano in All o Any; se non metti filtri, tutti gli eventi fanno partire il playbook, che raramente è quello che vuoi.

Un task parte quando il playbook è stato innescato e tutti i task collegati che lo precedono sono completi. Conviene partire da un template: i predefiniti coprono i casi tipici, dalla quarantena via FortiOS o EMS all’arricchimento di un incidente con la lista dei processi o delle vulnerabilità.

Per passare dati fra task ci sono due tipi di variabile, di output e di trigger:

${<task_id>.<output>}
${id_2c7_84b_2c5_f47.vulnerabilities}
${trigger.<variable>}
${trigger.epip}

I task ID non sono mostrati dentro il task. Il modo documentato per leggerli è un giro strano ma da ricordare: crea un task con l’azione Local Attach Data to Incident, apri il menu Attachment, seleziona il task precedente e passa alla modalità testo per copiare il valore.

Dove i connettori si riusano fuori dai playbook

I connettori non servono solo ai playbook. Nelle impostazioni degli incidenti puoi associare un fabric connector e farti notificare quando un incidente viene creato, aggiornato o eliminato — gli incidenti in stato draft non generano notifica. Nei notification profile, che poi assegni agli event handler, l’alert può uscire attraverso uno o più fabric connector, oppure via email, SNMP trap o syslog.

È lì che i connettori ITSM (ServiceNow, Slack, MS Teams e il webhook generico) danno il meglio; ServiceNow e MS Teams sono usabili anche dentro un playbook.

Ultima cosa, banale ma bloccante: per gestire i playbook serve un profilo amministratore con permesso Read-Write su Incidents & Events.