Fortinet chiama il prodotto «Fortinet Security Orchestration Platform»: una piattaforma di security management centralizzata, cifrata e scalabile, hub delle operazioni di sicurezza. Detta così è marketing. Quello che l’esame verifica è più concreto: sapere quale pezzo fa che cosa, e soprattutto dove finisce il perimetro di FortiSOAR e dove comincia quello degli strumenti che gli stanno intorno.

Automazione e orchestrazione non sono sinonimi

L’automazione è la singola azione machine-to-machine: un connettore che interroga una reputazione, che mette un IP in denylist, che manda una mail. L’orchestrazione è la sequenza che tiene insieme quelle azioni rispettando il processo aziendale, compresa la parte umana — le approvazioni e i manual input che compaiono nel pannello Pending Tasks e che fermano il playbook finché qualcuno non risponde.

Il motore dei playbook gira in modo asincrono, come servizio indipendente: celeryd esegue i playbook, celerybeatd li schedula. È una scelta di architettura: lascia l’application engine libero di rispondere agli utenti mentre le automazioni girano.

Il dettaglio che costa il punto: i playbook vengono eseguiti per impostazione predefinita nel contesto della Playbook Appliance (PBA), non dell’utente che li innesca. Se un playbook legge un incident ed estrae indicatori, la PBA deve avere Read su Incidents e Create su Indicators. Un amministratore che lancia quel playbook lo vede fallire lo stesso, perché i permessi che contano sono quelli dell’appliance.

Contro il SIEM: quello che dentro FortiSOAR non c’è

FortiSOAR non raccoglie e non normalizza log grezzi. Non esiste un indice di eventi da interrogare: quello che entra è già un alert, portato dentro dal wizard Data Ingestion tramite un connettore che parla con il SIEM, con la piattaforma di threat intelligence, con la casella di posta. La documentazione lo dice nella definizione stessa del modulo: gli alert sono notifiche «tipicamente generate in un SIEM».

Elasticsearch c’è, ma fa un altro mestiere: indicizza i record (allegati compresi) per la Global Search e alimenta il Recommendation Engine. Non è il datastore degli eventi.

E c’è la sorpresa che chi arriva da altri prodotti sbaglia sistematicamente: dalla release 7.2.0 i moduli di incident response — Alerts, Incidents, Indicators, War Rooms — non fanno parte della piattaforma. Arrivano con la solution pack SOAR Framework, che è installata di default solo sulle installazioni nuove. Senza quella solution pack, FortiSOAR sa orchestrare ma non ha nemmeno il posto dove mettere un alert.

I servizi sotto la GUI

Vale la pena conoscere i nomi, perché l’esame è operativo e i log si leggono per servizio, sotto /var/log/cyops:

postgresql-16              tutti i dati applicativi
elasticsearch + cyops-search   ricerca full-text, record simili, suggerimenti campi
rabbitmq-server            audit, live sync, trasferimento dati in ambiente distribuito
nginx                      interfaccia web
uwsgi                      ospita motore playbook e integrazioni
celeryd / celerybeatd      esecuzione asincrona e scheduling dei playbook
cyops-auth                 autenticazione, licenza, HA
cyops-tomcat               SSO, auditing, websocket
cyops-postman              setup multi-tenant distribuito
cyops-integrations-agent   azioni sugli agent remoti
fsr-workflow               motore delle regole
fsr-api-consumer           installazione del Content Hub

Lo stato si controlla con csadm services --status, che colora di verde i servizi attivi e di rosso quelli fermi. Una novità della 7.6.0 da tenere a mente: le integrazioni girano con l’utente fsr-integrations, non più con nginx. Uno snippet di codice che scriveva su filesystem fuori da /opt/cyops-integrations o /tmp smette di funzionare dopo l’aggiornamento.

Muoversi nell’interfaccia

La barra di sinistra espone Componenti che si aprono su moduli, e mostra soltanto ciò che i tuoi permessi consentono. I metodi di ricerca sono tre e non sono equivalenti: la Global Search in alto usa Elasticsearch, cerca su tutti i record e sugli allegati, rispetta l’autorizzazione dell’utente ed è esportabile in CSV; il Table Filter cerca sul campo nome; il Column Filter agisce sulla singola colonna della griglia.

In alto a destra trovi Settings, Executed Playbook Logs (è da qui che si fa debug delle esecuzioni), Notifications — filtrabili con All, Action Required, @Mentions e Show only Unread — e Pending Tasks, che raccoglie approvazioni e manual input. Al centro in alto c’è l’indicatore dei websocket: verde significa Live UI attiva e griglie che si aggiornano da sole, rosso significa «Live Sync is not active» e aggiornamento manuale.

Due default che sembrano innocui: il tema predefinito è Space, non Light; e la lingua scelta nel profilo sovrascrive quella dell’amministratore, ma senza permesso Read o Usage su Widgets l’interfaccia resta in inglese comunque.

Content Hub

Il Content Hub gestisce tre tipi di contenuto — Connectors, Solution Packs e Widgets — in tre schede: Discover mostra tutto il disponibile, Manage l’installato con le notifiche di aggiornamento, Create ciò su cui stai lavorando e non hai ancora pubblicato. I filtri sono Content Type, Category, Publisher e Tags, e i tag funzionano a corrispondenza esatta.

Perché la pagina si popoli, repo.fortisoar.fortinet.com deve essere raggiungibile dall’istanza: altrimenti la voce di menu apre una pagina bianca. La sincronizzazione avviene al trentesimo minuto di ogni ora e si può forzare da CLI.

Sui permessi si perdono punti facilmente: per installare o caricare contenuto basta il permesso Read sul modulo Security, non Update. Per vedere il Content Hub servono Read su Content Hub e Applications più Create, Read e Update su Solution Packs, e senza Read su Content Hub la voce sparisce proprio dalla navigazione. Infine il ruolo FSR Content Hub è assegnato di default alla Playbook Appliance: se lo togli, devi ridare a mano i permessi equivalenti.