Anomalia rilevata. Pattern di calo coordinato su 8 sensori tensione in zone distinte. Classificazione: possibile evento di sicurezza, severità alta. Compatibile con interferenza esterna. Dettaglio nel report allegato.
AGENTE · SCADA ANOMALY WATCHER
Le anomalie SCADA arrivano prima del guasto o dell'attacco.
SCADA Anomaly Watcher monitora in tempo reale il flusso dei sistemi SCADA delle utility. Identifica pattern compatibili con guasti tecnici in arrivo (deriva di sensore, parametri fuori range previsionali) o con intrusioni di sicurezza (pattern di comunicazione anomali, comandi non attesi). Alert immediato al security team o all'operations.
SCADA Anomaly Watcher al lavoro.
Verifica in corso. Erano previsti test di stress IT oggi pomeriggio?
In parallelo: deriva sensore cabina X negli ultimi 7 giorni — severità media, calibrazione richiesta. Alert al team operations su canale separato.
Confermato: test IT autorizzato, falso positivo. Chiudo con motivazione. Cabina X la gestisce operations.
Perché esiste.
I sistemi SCADA sono il cuore del monitoraggio e controllo delle reti di utility. Il volume dei dati è massivo: migliaia di sensori che inviano misurazioni in tempo reale, comandi verso apparati remoti, log di tutte le operazioni. La capacità umana di monitoraggio continuo è limitata; le anomalie precoci — deriva di un sensore, pattern di comunicazione compatibile con un tentativo di intrusione — passano facilmente inosservate.
Come legge in streaming.
SCADA Anomaly Watcher legge in streaming il flusso SCADA del cliente. Per ciascun flusso confronta con i pattern attesi sulla base delle baseline configurate, identifica anomalie tecniche (deriva di sensore oltre soglia, sequenze compatibili con guasto in arrivo) e anomalie di sicurezza (pattern di comunicazione anomali, comandi non attesi, accessi fuori orario o da indirizzi non riconosciuti).
L'intervento resta al team.
L'alert arriva al team operations (anomalie tecniche) o al security team (anomalie di sicurezza) sul canale di lavoro configurato. La decisione di intervento sui sistemi — isolamento di un'area, blocco di un comando, attivazione del piano di emergenza — resta del team operations o del CISO.
Le funzioni che presidiano la rete e la sicurezza della utility.
Responsabile operations di rete
Recupera la capacità di monitoraggio continuo, impraticabile manualmente sui volumi reali. Le anomalie tecniche arrivano con anticipo rispetto al guasto, lasciando spazio all'intervento preventivo di calibrazione o manutenzione.
SCADA · live 2 anomalie
Sottostazione SE-104 tensione fuori range
Linea LV-22 corrente picco
NIS2 classify material · 24h timer
Alert al CISO · ticket aperto
CISO o responsabile cybersicurezza
Ottiene il monitoraggio continuo dei pattern di sicurezza sui sistemi SCADA. NIS2 categorizza la maggior parte delle utility come operatori di servizi essenziali con vincoli specifici di rilevamento e risposta agli incidenti.
Outage in corso ETA 35'
Zona Nord-Est cluster B
Field team 3 squadre · in transito
SLA cliente reset · 20'
Report ARERA in preparazione · 4h
Responsabile compliance
Ha la traccia ispezionabile delle anomalie identificate, delle decisioni del team e degli esiti per audit NIS2. Ogni alert, ogni classificazione, ogni esito è nel registro, leggibile con un client SQL standard.
Previsione 14 giorni 48 tratti
Tratto MV-Nord alto
Tratto MV-Est medio
Asset > 25 anni 12 sostituzioni
Piano manutenzione settimanale
Due anomalie rilevate simultaneamente, due team allertati in parallelo.
Due anomalie in parallelo.
Per una utility energia con rete di distribuzione regionale, l'agente è integrato con il sistema SCADA tramite adapter dedicato. Alle 14:00 l'agente identifica due anomalie in parallelo. La prima: una sequenza di letture di tensione su otto sensori in zone diverse mostra un calo coordinato compatibile con interferenza esterna. La seconda: le letture di un singolo sensore della cabina X mostrano deriva costante negli ultimi sette giorni.
Canali distinti per security e operations.
L'agente attiva due alert separati con canali distinti. Al security team: classificazione 'possibile evento di sicurezza, severità alta' con sintesi dei sensori coinvolti e serie storiche. Al team operations: classificazione 'calibrazione richiesta, severità media' con storia delle letture del sensore.
Falso positivo chiuso, manutenzione pianificata.
Il security team verifica i log di rete, riconosce un test di stress autorizzato dal team IT come causa del pattern anomalo, chiude l'alert come falso positivo con motivazione. Il team operations pianifica la manutenzione di calibrazione della cabina X. L'evento completo — anomalie, decisioni, esiti — resta nel registro audit per audit NIS2.
Baseline tecniche e di sicurezza dichiarative, versionate dal team operations e CISO.
Le regole di SCADA Anomaly Watcher sono dichiarative. Il team operations e il CISO della utility definiscono in formato leggibile le baseline tecniche dei sensori e dei sistemi, i pattern di sicurezza riconosciuti (basati su NIS2 e framework di settore), le soglie di alert per severità. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente. L'integrazione con i sistemi SCADA della utility si realizza in fase di delivery tramite adapter dedicato (OPC UA, Modbus o equivalente), soggetta a validazione delle policy di sicurezza con il CISO e il team Delivery. I sistemi SCADA sono spesso isolati per ragioni di sicurezza (air gap o segmentazione stretta): il pattern di integrazione conforme alla policy NIS2 si definisce in fase di discovery commerciale.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, prompt-injection, tool-rate-limit
- Canali nativi di notifica
- Slack, Telegram, HTTP OpenAI-compatible
- Integrazione sistema SCADA
- adapter dedicato in fase di delivery (OPC UA, Modbus o equivalente); soggetto a validazione policy sicurezza con CISO utility e team Delivery (air gap o segmentazione stretta possibili)
- Baseline tecniche e di sicurezza
- dichiarative, versionate, scritte dal team operations e CISO
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui pattern storici SCADA
- Registro
- immutabile, interrogabile con client SQL standard (audit NIS2 ispezionabile)
Domande frequenti sull'agente.
No. L'agente identifica anomalie e attiva alert al team del cliente. La decisione di intervento sui sistemi SCADA — isolamento di un'area, blocco di un comando, attivazione del piano di emergenza cybersicurezza — resta del team operations o del CISO della utility secondo le procedure stabilite.
Per le utility con un SOC (Security Operations Center) esterno o interno gestito separatamente, gli alert di sicurezza possono essere instradati al SOC come parte della pipeline di sicurezza esistente. L'integrazione si realizza in fase di delivery con il team Exelab, coordinandosi con il CISO della utility per la conformità NIS2.
Il pattern tipico è 14-22 settimane, più lungo della media per la complessità dell'integrazione SCADA e per la valutazione delle policy di sicurezza. Discovery 3-4 settimane, costruzione baseline con i dati storici del cliente 4-6 settimane, integrazione SCADA con valutazione di sicurezza 5-8 settimane, hand-off al team 2-4 settimane. La durata effettiva si definisce nella discovery dopo la mappatura della topologia di rete e delle policy NIS2 della utility.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come SCADA Anomaly Watcher si configurerebbe sulla rete del cliente. Quale sistema SCADA, quali baseline tecniche, quale perimetro NIS2.