Le condizioni in FortiSOAR non stanno in un posto solo. Prima ancora che un playbook parta c’è un filtro che decide se il record entrerà nel database; poi vengono la condizione sul trigger, quella sul singolo step, quella dentro un ciclo e quella del Decision step. Sapere quale interviene per prima è metà del lavoro.

Pre-processing rule: il cancello prima del database

Le pre-processing rule si configurano in Settings, sezione Application Editor, e scattano prima che un record in arrivo venga scritto nel database. Sostituiscono i playbook di deduplica, imprecisi e pesanti.

Il tipo di regola è Drop oppure Update. Con Drop scegli fra due condizioni: decidere sui soli valori del record in arrivo, oppure confrontarlo con i record esistenti creati negli ultimi N giorni, con N fra 1 e 7 — non di più. Con Update l’unica condizione è il confronto con i record esistenti, e le azioni sono tre: collegare il record in arrivo a quello che ha fatto match, saltare l’esecuzione dei playbook alla creazione, e aggiornare i campi del record in arrivo.

I dettagli che valgono il punto intero:

  • la priorità va da P1, la più alta, a P5; le regole si valutano in ordine di priorità e poi di data di creazione, e alla prima che fa match la valutazione si ferma — le altre non vengono nemmeno guardate;
  • le pre-processing rule non si applicano alle operazioni bulk;
  • nelle condizioni valutate sui record esistenti di una regola Drop gli operatori negativi non sono selezionabili (Not Equals, Does Not Contain, Is Not In List): rischierebbero di scartare troppo;
  • se usi l’operatore Already Exists, il Test Run risponderà sempre “Not Dropped”: la funzione di test non interroga il database;
  • il collegamento funziona solo sui moduli con relazioni molti-a-molti verso sé stessi: alert con alert o incident con incident, mai persona con persona;
  • in MSSP i record replicati non vengono valutati dalle regole Drop, mentre le Update sì: per evitarlo aggiungi la condizione tenant=self su master e tenant;
  • i moduli di sistema come People, Appliances e Agent non compaiono nell’elenco: non puoi definirci regole.

Dalla 7.6.0 esiste già una regola chiamata “Enforcing File Attachments for File Indicators”, che lascia creare indicatori di tipo file solo se un file è davvero allegato.

Dove si scrivono le condizioni

Sul trigger. On Create, On Update e On Delete accettano una logica All of the below are True (AND) oppure Any of the below is True (OR): sono mutuamente esclusive, ma puoi annidare gruppi con Add Conditions Group. Filtrare qui invece che con un Decision step subito dopo conviene: eviti di svegliare il motore per nulla. I tag hanno operatori diversi a seconda del trigger: Contains su On Create e On Delete, mentre On Update offre Contains All, Added e Is Changed. E sui campi cifrati non puoi filtrare, né qui né in Find Records.

Sullo step. Il link Condition nel footer aggiunge la casella When, e la regola è precisa: senza for each il When sta a livello di step ed è la prima cosa valutata, quindi se non è soddisfatta lo step viene saltato; con un for each si applica invece dentro il ciclo, elemento per elemento.

Restano lo step Wait, che attende un tempo fisso oppure il verificarsi di una condizione, e il Decision step.

Decision step: vince la prima condizione vera

Il Decision step valuta condizioni alternative e si ferma alla prima soddisfatta, saltando le altre. Se nessuna lo è si segue il percorso di default, che va definito con Add Default Condition. Ogni ramo punta a uno step scelto in Select A Step to Execute, e puoi scrivere tutta la logica prima ancora di creare gli step di arrivo.

Con Show Advanced scrivi Jinja libero, ed è qui la trappola classica: nell’interfaccia avanzata del Decision step le doppie graffe non servono, la condizione si scrive nuda.

vars.variable == 5
vars.variable != []
"x" in vars.variable

In due casi il condition builder non c’è e il Jinja avanzato è obbligatorio: con il trigger No Trigger, e con un Manual Trigger registrato su più moduli.

for each e do until

Il for each si aggiunge una sola volta per step, prende in ingresso un array di oggetti e itera per la lunghezza dell’array. L’elemento corrente si legge con la parola riservata item.

{{ vars.item.name }}
{{ vars.item.severity.itemValue }}

Le modalità sono tre. Bulk crea tutto in una sola chiamata API ed è il default quando metti Create Record o Update Record dentro un ciclo: è la più efficiente, e per volumi che mandano in timeout si passa ai batch. Sequential manda una richiesta per record, una dopo l’altra, e si ferma al primo errore. Parallel manda richieste separate su thread multipli.

Il do until esegue lo step almeno una volta e ripete finché la condizione non è vera o finché non esaurisce i tentativi: default 3 retry, 5 secondi di attesa. Dentro il ciclo leggi il risultato dello step corrente.

vars.steps.<step_name>.message == 'Success'

Perché il retry abbia senso devi mettere Ignore Error su Yes, altrimenti il primo fallimento ferma il playbook prima del secondo tentativo. E una riga della documentazione da prendere alla lettera: do until non va usato insieme a when né a for_each.