FLUXSTORM RELAY: l’evoluzione del SOC di Nais

Da inizio 2026 le regole di detection attive nel SOC Nais sono aumentate del 150%. Ogni settimana ne introduciamo di nuove, perché le tecniche di attacco cambiano in fretta e colpiscono in modo sempre più mirato.

C'è però un effetto che chiunque lavori in un SOC conosce bene. Più regole producono più eventi da valutare, e se ogni evento diventasse una notifica per il cliente, la protezione aggiuntiva si trasformerebbe in rumore. Aumentare la visibilità è necessario, ma da solo non basta, bisogna anche capire quali eventi meritano davvero l'attenzione di chi riceve la segnalazione.

Cosa fa bene un playbook

Per anni la risposta del settore a questo problema è stata l'automazione basata su playbook, che costituisce il cuore delle piattaforme SOAR e il motore del servizio SOC di Nais. Il principio è semplice: a un evento di un certo tipo corrisponde una sequenza di azioni predefinita, che raccoglie informazioni, applica controlli e chiude o inoltra il caso.

È un modello che funziona, e funziona bene. Nel SOC Nais gestiamo oltre 200.000 ticket al mese e buona parte di questo risultato poggia su playbook costruiti con il cliente e affinati su anni di casi reali. Sugli scenari noti e ripetitivi un playbook è rapido e si comporta sempre allo stesso modo, il che lo rende anche facile da verificare.

Dove il playbook si ferma

Il limite emerge quando la risposta giusta dipende da qualcosa che il playbook non può sapere. Un accesso RDP fuori orario può segnalare una compromissione in un'azienda ed essere la normale routine di un fornitore di manutenzione in un'altra. Un traffico insolito verso una nuova destinazione può indicare un'esfiltrazione, oppure il primo giorno di utilizzo di un servizio cloud appena adottato.

In casi come questi i dati tecnici a disposizione del SOC descrivono l'evento con precisione, ma non ne chiariscono il significato, che dipende da come lavora l'organizzazione e dalle eccezioni che ha previsto. Un playbook statico può gestire queste situazioni solo accumulando condizioni ed eccezioni, e ogni aggiunta rende l'insieme più difficile da mantenere. Oltre una certa soglia, ottimizzare diventa un lavoro che cresce più in fretta dei benefici che produce.

C'è poi un secondo limite, meno evidente. Quando un analista chiude un falso positivo, quella decisione di solito resta confinata al singolo ticket, e la volta successiva il playbook si comporterà esattamente come prima perché non ha modo di imparare da ciò che è successo.

Due logiche a confronto

La differenza si vede nel momento in cui arriva un evento che richiede una decisione.

Come Relay cambia il passaggio decisionale

Fluxstorm Relay non sostituisce i playbook. Lavora sopra l'automazione esistente e interviene nel punto preciso in cui serve una decisione che il SOC, da solo, non può prendere con certezza.

Quando un alert ha bisogno del contesto operativo del cliente, la notifica arriva via email con la possibilità di rispondere direttamente. Il referente può confermare che si tratta di un'attività legittima, segnalare un comportamento ricorrente da escludere in modo strutturale oppure chiedere un'escalation se non riconosce ciò che sta accadendo. In quest'ultimo caso il ticket, già in gestione, sale subito alla massima priorità.

Le richieste di tuning non modificano le regole in automatico. Passano dai TAM (Technical Account Manager), che le valutano, le traducono in esclusioni mirate e mantengono il controllo tecnico su ciò che cambia. È proprio questo passaggio a trasformare un singolo riscontro in un miglioramento che vale anche per i casi successivi.

Due precisazioni aiutano a evitare fraintendimenti. Rispondere non è obbligatorio: se il cliente non interviene, il SOC continua a presidiare ogni alert come ha sempre fatto e il livello di protezione non cambia. Inoltre, gli alert critici restano gestiti direttamente dal SOC, con intervento immediato e a qualunque ora, perché Relay riguarda gli eventi in cui il contesto fa la differenza e non quelli in cui bisogna agire subito.

Resta la domanda che ogni responsabile della sicurezza si pone: chi può intervenire sugli alert, e come si ricostruisce poi chi ha deciso cosa? L'accesso alle azioni di Relay è riservato ai referenti autorizzati ed è protetto in ogni passaggio. Ogni risposta resta tracciata nello storico del ticket, così il SOC e il cliente possono verificare in qualunque momento chi ha preso ciascuna decisione e in che momento. Confermare un'attività come legittima chiude il singolo caso ma non tocca le regole di detection, che cambiano solo dopo la validazione del TAM.

Cosa cambia per chi riceve le notifiche

Nel breve periodo l'effetto più visibile è una maggiore trasparenza. Il cliente vede cosa il SOC sta valutando nel suo ambiente e può intervenire senza aprire un ticket o accedere a un portale.

Nel tempo conta di più l'effetto cumulativo. Ogni attività riconosciuta come legittima e ogni pattern escluso con il supporto del TAM riducono le segnalazioni che non richiedono intervento, così le notifiche che restano sono quelle che hanno davvero bisogno di attenzione.

Questa tracciabilità ha anche un valore di compliance. Con NIS2 non basta gestire gli eventi di sicurezza: bisogna poter dimostrare come sono stati valutati e chi ha preso le decisioni. Lo storico delle risposte, insieme alle validazioni dei TAM, documenta perché un evento è stato considerato legittimo o portato in escalation, e diventa un'evidenza utilizzabile anche in fase di audit.

Ogni risposta rende più precisa la notifica successiva

Continueremo ad aggiungere regole di detection, perché è così che il SOC tiene il passo con tecniche di attacco che cambiano ogni settimana. Vogliamo però evitare che ogni nuova regola diventi un'email in più nella casella di chi proteggiamo. Con Relay chiediamo il contributo del cliente solo sugli eventi in cui la sua conoscenza fa la differenza, e ciò che ci dice resta nel sistema anche per i casi successivi.

Dietro questo meccanismo c'è il lavoro dei TAM.