Si può valutare una soluzione di sicurezza per la fabbrica senza rischiare fermi: si collega il sistema alle sole fonti autorizzate in lettura e lo si lascia osservare per un periodo concordato, mentre prepara proposte che nessuno esegue. È la logica del periodo di osservazione — in OverZeus si chiama Shadow Mode — e permette di misurare ciò che conta per un investimento: copertura delle fonti, qualità delle segnalazioni, chiarezza delle proposte. Alla fine il consiglio decide su un report, non su una promessa.
Il timore di toccare la produzione è fondato
Chi gestisce uno stabilimento lo sa: la tecnologia operativa (OT) — controllori logici programmabili (PLC), sensori, sistemi di supervisione — non è informatica d'ufficio. La guida del National Institute of Standards and Technology (NIST) SP 800-82 revisione 3, riferimento tecnico volontario, spiega che i sistemi OT interagiscono direttamente con il mondo fisico e mettono in primo piano affidabilità e sicurezza delle persone. Una scansione aggressiva o un intervento automatico, banali su un server, su una linea possono interrompere il processo.
Per questo la prudenza di chi dice «prima di installare qualcosa sulla mia produzione voglio capire» non è un ostacolo alla sicurezza: è il punto di partenza corretto. Una prova seria deve accettare vincoli chiari — niente scansioni intrusive, nessuna modifica automatica, nessuna interruzione — e dimostrare valore dentro quei vincoli, non chiedere di rimuoverli.
Osservare e proporre, senza modificare
Un periodo di osservazione in sola lettura funziona così: si concorda un perimetro — quali reti, quali fonti di dati, quali sistemi — e il sistema riceve accesso alle sole fonti autorizzate, in lettura. Da quel momento raccoglie segnali e contesto, prepara analisi e proposte di intervento, ma non le esegue. La produzione resta invariata per l'intera durata della prova.
In OverZeus questa modalità è affidata a Oracle, l'agente dello Shadow Mode e della prova di valore: osserva nel perimetro collegato, associa a ogni evidenza un possibile intervento e prepara un report che distingue quattro cose — ciò che è stato osservato, le interpretazioni, gli interventi proposti e le condizioni per attivarli. La prova non acquisisce permessi di modifica: passare alla fase operativa è una decisione separata, con moduli, integrazioni e autorizzazioni concordati.
Dove entra la fabbrica, entra Hephaestus, l'agente per IoT (Internet delle cose), OT e dispositivi: porta contesto su macchine e sensori — stato, anomalie, dipendenze operative — e prepara proposte entro confini definiti. Anche in piena attivazione, le funzioni di sicurezza e il controllo di processo restano affidati ai sistemi dell'impianto e ai responsabili tecnici; a maggior ragione durante la prova, in cui non viene toccato nulla.
Tre cose si possono misurare già in sola osservazione:
- Copertura: quali fonti riesce davvero a leggere nel tuo ambiente, e quali restano fuori. La copertura dipende dalle integrazioni possibili sul singolo impianto: meglio saperlo durante la prova che dopo la firma.
- Qualità delle segnalazioni: quante segnalazioni si rivelano utili, quante erano attività legittime da contestualizzare, quante informazioni mancavano per decidere.
- Chiarezza delle proposte: ogni proposta indica cosa farebbe, con quali conseguenze e cosa serve per autorizzarla? Se non è comprensibile durante la prova, non lo sarà durante un incidente.
Un avviso di onestà: il periodo di osservazione non è un audit di sicurezza e non misura come il sistema si comporterebbe durante un incidente reale. Misura il valore potenziale nel tuo contesto, con le fonti che hai potuto collegare.
Esempio illustrativo: quattro settimane sul confezionamento
Esempio illustrativo. Lo scenario seguente è inventato: mostra che tipo di valore si può documentare, senza promettere numeri uguali per tutti.
Un'azienda alimentare con due linee di confezionamento concorda quattro settimane di osservazione. Perimetro: la rete di supervisione delle linee, i registri del firewall perimetrale e l'inventario dei dispositivi autorizzato. Nessun accesso in scrittura, nessuna scansione attiva dei controllori.
Nella prima settimana il sistema rileva che un sensore di pesata smette di trasmettere ogni notte verso le tre, per poi riprendere da solo. Hephaestus mette in relazione il segnale con il ruolo della macchina e con la finestra di sanificazione: la proposta — verificare l'alimentazione del sensore durante il ciclo di pulizia — resta sulla carta, ma la correlazione tra orario del silenzio e orario della sanificazione era sfuggita a tutti. Nella terza settimana compare in rete un portatile non censito: risalirà al manutentore del fornitore, con accesso concordato ma mai registrato; la proposta è formalizzare quel profilo di accesso. A fine prova, un registro mostra una modifica alla configurazione del firewall senza ticket associato: anche questa diventa una proposta — agganciare le modifiche di rete al flusso di approvazione — non un ripristino eseguito.
Il report finale, conservato con le sue evidenze, elenca per ciascun caso: cosa è stato osservato, quale interpretazione è stata data, quale intervento era stato proposto, perché non è stato eseguito. Il valore documentabile non è «tre incidenti sventati»: è la visibilità guadagnata su tre punti ciechi, con i passi concreti per chiuderli e le persone che dovrebbero deciderli.
Criteri per decidere dopo la prova
Per chi approva l'investimento, la domanda finale non è «funziona?» ma «cosa sappiamo ora che prima non sapevamo, e cosa costa mantenerlo?». Una presentazione utile al consiglio porta quattro elementi:
- Il perimetro reale della prova: fonti collegate e fonti rimaste fuori, con il motivo. Evita che il report sembri coprire l'intera azienda quando copriva una linea.
- I casi osservati, raccontati con evidenze: segnale, contesto, proposta, decisione presa all'epoca dai responsabili.
- Le proposte e le loro condizioni: cosa servirebbe per attivarle — integrazioni, autorizzazioni, ruoli — e cosa resterebbe comunque alle persone.
- Il lavoro richiesto al team: quante segnalazioni a settimana, chi le esamina, quanto tempo è servito per gestirle durante la prova.
Alcune domande aiutano a non fermarsi alla superficie: il sistema ha spiegato i propri limiti quando mancava una fonte? Le segnalazioni inutili sono state riconosciute come tali, o rivendicate come successi? Il report distingue ciò che è successo da ciò che sarebbe potuto succedere? Una prova ben condotta non ha paura di queste domande: le usa come criteri.
Se il risultato convince, il passo successivo è definire l'attivazione — perimetro, moduli, autorizzazioni — come progetto separato, con le stesse cautele viste per il monitoraggio passivo in officina e per l'inventario OT senza scansioni. Se non convince, restano comunque i casi documentati: anche questo è un risultato, perché è costato poco e ha lasciato informazioni vere. Per approfondire i criteri di scelta prima ancora della prova, puoi leggere la guida su come scegliere un monitoraggio per la fabbrica e la descrizione degli scenari OverZeus per fabbriche e laboratori.
Descrivi impianti, sensori e vincoli produttivi per definire il perimetro di una demo.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.