Security by Design: la nuova architettura della resilienza industriale

Nel contesto industriale, la Security by Design consiste nell’integrare la sicurezza informatica fin dalle prime fasi di progettazione di un sistema OT, anziché introdurla successivamente come intervento correttivo.

Questo approccio implica che ogni componente, come PLC, SCADA, sensori, reti di campo, venga ideato considerando sin dall’inizio i vettori di rischio cyber, i requisiti di autenticazione, la segmentazione della rete e la tenuta operativa.

Oggi, integrare la Security by Design, non è più un’opzione per una ragione strutturale: la convergenza IT/OT ha esposto sistemi progettati per l’isolamento a minacce importanti per le quali non erano stati dimensionati. Gli attacchi a infrastrutture critiche dimostrano che la compromissione di un sistema OT non produce solo danni economici, ma può avere conseguenze fisiche dirette su persone e ambienti.

In questo contesto, la sicurezza deve essere un requisito di progetto al pari della safety funzionale.

Il riferimento tecnico principale per la difesa stratificata in ambito OT è la norma IEC 62443, che introduce, tra i vari requisiti, il concetto di Zone e Conduit, per il quale ogni porzione dell’impianto deve essere isolata in zone di sicurezza omogenee, collegate tra loro solo attraverso condotti controllati e filtrati.

A livello pratico, i requisiti tecnici da integrare in fase di design possono includere:

• Segmentazione e micro-segmentazione della rete: separare in modo netto rete aziendale (IT), rete OT e reti di campo, con firewall industriali e DMZ dedicate.
• Principio del minimo privilegio: garantire che ogni dispositivo e ogni operatore acceda esclusivamente alle risorse strettamente necessarie alla propria funzione.
• Autenticazione robusta: introdurre, dove tecnicamente possibile, meccanismi di autenticazione a più fattori anche per l’accesso a sistemi SCADA e HMI.
• Secure Remote Access: eliminare i canali di accesso remoto non presidiati, sostituendoli con soluzioni dedicate OT con registrazione delle sessioni.
• Hardening dei dispositivi: disabilitare servizi, porte e protocolli non necessari già in fase di commissioning.
• Resilienza e ridondanza: progettare la continuità operativa come requisito di sicurezza, non come elemento separato.

Framework di riferimento complementari sono il NIST SP 800-82 per i sistemi di controllo industriale. L’approccio più maturo è quello che integra questi framework con la safety funzionale (IEC 61511 / IEC 61508), riconoscendo che cyber security e functional safety devono essere progettate in modo integrato.

La visibilità degli asset è il prerequisito assoluto di qualsiasi strategia di sicurezza.

In ambito OT questo problema è amplificato da decenni di stratificazioni tecnologiche, dove coesistono dispositivi legacy privi di capacità di inventario automatico, sistemi proprietari con protocolli non standard e asset acquisiti attraverso fusioni o subappalti mai censiti correttamente.

La discovery e la classificazione degli asset svolgono un ruolo determinante su più livelli:

• Mappatura della superficie d’attacco reale: consente di identificare tutti i dispositivi connessi, inclusi quelli dimenticati o non documentati, e, di conseguenza, le vulnerabilità effettivamente esposte.
• Baseline comportamentale: permette di stabilire il comportamento atteso di ciascun asset identificato (protocolli usati, frequenza di comunicazione, peer autorizzati) e rilevare anomalie o discostamenti.
• Prioritizzazione del rischio: consente di valutare la criticità di ciascun dispositivo connesso e di concentrare le risorse di protezione sui sistemi il cui malfunzionamento avrebbe impatti sulla safety o sulla continuità operativa.
• Supporto alla compliance normativa: contribuisce a mantenere un inventario aggiornato degli asset, in linea con i requisiti di NIS2 e IEC 62443 per la gestione del rischio.

In fase by design, questo significa pianificare fin dall’inizio strumenti di asset management passivi (che non generano traffico anomalo sulla rete OT) o semi-passivi, integrati nell’architettura e non aggiunti come patch successive.

Nella sicurezza OT, il paradigma tipico dell’IT – applicare una patch, riavviare, verificare – semplicemente non è trasponibile in un impianto che deve operare ininterrottamente per anni o decenni.

Un PLC installato nel 2005, con un sistema operativo embedded non aggiornabile, non rappresenta un’eccezione: in molti settori è la norma.

Le strategie che, secondo me, sono più efficaci per gestire questo trade-off sono:

1. Controlli compensativi al posto del patching: quando un asset non può essere aggiornato, si costruisce attorno a esso uno strato di protezione, ad esempio tramite firewall industriali (IPS/IDS OT compatibili) che filtrano il traffico verso e da quel dispositivo, e attraverso virtual patching che blocca lo sfruttamento della vulnerabilità a livello di rete senza intervenire sul sistema.
2. Gestione strutturata delle vulnerabilità: non tutte le vulnerabilità richiedono un’azione immediata. Un processo di vulnerability management OT deve valutare ogni CVE in funzione dell’effettiva esposizione del dispositivo, della presenza di exploit pubblici e dell’impatto operativo di un eventuale incidente.
3. Finestre di manutenzione pianificate: il patching deve essere integrato nel piano di manutenzione ordinaria. La collaborazione con i responsabili di produzione consente di individuare le finestre utili per l’aggiornamento, ad esempio durante fermate non programmate, senza compromettere la continuità operativa.

Definizione del rischio accettabile Il livello di rischio accettabile in ambito OT si definisce attraverso un’analisi che incrocia la probabilità di sfruttamento con la severità dell’impatto, non solo economico, ma anche in termini di safety, ambiente e reputazione. La IEC 62443 fornisce una metodologia strutturata (SL-T) per tale valutazione, mentre il rischio residuo deve essere una decisione consapevole e documentata dal business.

Le normative europee rappresentano sicuramente un’opportunità, a patto di saperle interpretare nel modo corretto.

La Direttiva NIS2 introduce obblighi sostanziali come la gestione del rischio, la notifica degli incidenti e la sicurezza della supply chain che, se implementati concretamente, portano le aziende a dotarsi di capacità che avrebbero dovuto sviluppare già da anni.

Il Cyber Resilience Act è particolarmente rilevante per la progettazione OT perché sposta l’obbligo della sicurezza sui produttori di dispositivi connessi, imponendo il principio by design direttamente nella catena di fornitura.

Il Regolamento Macchine estende i requisiti di sicurezza informatica alle macchine CE, creando finalmente un collegamento esplicito tra safety e security.

Il rischio concreto è quello di un approccio burocratico: compilare documenti, ottenere certificazioni, soddisfare checklist senza che nulla cambi realmente nella sicurezza. Per evitarlo, è necessario:

• Partire dal rischio reale, non dal testo normativo. Chiedersi “cosa succederebbe se questo impianto venisse compromesso?” prima di chiedersi “quale articolo devo soddisfare”.
• Integrare la compliance nel ciclo di vita degli asset, non gestirla come progetto separato con scadenza annuale.
• Misurare l’efficacia dei controlli, non solo la loro presenza: un firewall installato ma mal configurato soddisfa una checklist, ma non riduce il rischio.

Coinvolgere le funzioni nel percorso di compliance, perché solo chi conosce il processo può valutare l’impatto reale di un controllo di sicurezza.

La protezione statica (firewall, segmentazione, hardening) è necessaria ma non sufficiente.

Un attaccante determinato, come dimostrato dagli attacchi più sofisticati agli impianti industriali, è in grado di operare all’interno di un perimetro apparentemente sicuro per settimane o mesi prima di manifestarsi.

Il monitoraggio continuo è la capacità che trasforma una difesa passiva in un sistema capace di rilevare, rispondere e adattarsi.

In un modello by design maturo, il SOC industriale non è un elemento accessorio, ma si traduce operativamente in una serie di componenti e funzionalità integrate nell’architettura fin dalla fase di progettazione:

• Sensori di monitoraggio passivo integrati nell’architettura di rete, in grado di catturare il traffico OT senza interferire con i processi e garantire una visibilità continua.
• Correlazione IT/OT: gli eventi di sicurezza OT devono essere contestualizzati con quelli IT, per identificare le catene di attacco che attraversano i due domini e ricostruire il contesto dell’incidente.
• Playbook di risposta OT-specifici: un SOC generico non può gestire un incidente su un sistema OT con le stesse procedure usate per gli endpoint aziendali; le procedure devono tenere conto delle priorità assolute di continuità operativa e safety.
• Threat Intelligence industriale: la conoscenza delle tattiche, tecniche e procedure degli attori che prendono di mira infrastrutture OT deve alimentare in modo mirato le regole di detection e il miglioramento continuo delle capacità di difesa.

L’Industrial AI e la connettività cloud stanno ridefinendo il perimetro OT in modo sostanziale.

I modelli di manutenzione predittiva, ottimizzazione di processo e Digital Twin richiedono flussi di dati continui verso piattaforme cloud, introducendo vettori di attacco che, fino a pochi anni fa, semplicemente non esistevano.

L’AI applicata ai sistemi di controllo, inoltre, introduce una nuova classe di rischi: la manipolazione dei dati di training, gli attacchi adversariali ai modelli e la dipendenza da inferenze opache per decisioni operative critiche.

In questo scenario, la Security by Design per il 2030 dovrà incorporare, secondo me, alcuni principi emergenti:

• Zero Trust applicato all’OT: nessun dispositivo, nessun utente, nessun flusso dati è considerato fidato per default, anche all’interno del perimetro industriale. Ogni interazione viene autenticata e autorizzata.
• AI Security by Design: i modelli AI industriali devono essere progettati con meccanismi di validazione degli input, monitoraggio del drift comportamentale e capacità di fallback deterministico in caso di anomalia.
• Supply chain security: con la crescente dipendenza da vendor di componenti e software OT, la sicurezza deve estendersi a tutto l’ecosistema, includendo strumenti come la Software Bill of Materials (SBOM e la, verifica dell’integrità del firmware.

Il consiglio principale che darei ad un’azienda che progetta oggi i propri sistemi per il 2030 è uno solo: non separare mai la roadmap tecnologica dalla roadmap di sicurezza.

Ogni decisione architetturale ha implicazioni di sicurezza che, se affrontate in ritardo, comporteranno costi e complessità significativamente maggiori rispetto a quelli per la loro integrazione sin dall’inizio.

La Security by Design non è un costo aggiuntivo: principio che consente di costruire sistemi industriali realmente resilienti, riducendo il debito di sicurezza e aumentando la capacità di adattamento nel tempo.