La IEC 62443 e la famiglia di standard che la compongono rappresentano il riferimento tecnico principale per la cybersecurity nei sistemi di automazione industriale e controllo (IACS). A differenza di altri framework generici, questa serie e stata progettata specificamente per ambienti OT: tiene conto dei vincoli di disponibilita, dei cicli di vita lunghi, della presenza di componenti legacy, della convivenza tra piu fornitori e della separazione tra chi possiede l'impianto, chi lo integra e chi produce i componenti.
Per chi lavora come system integrator o come OEM, la IEC 62443 non e solo un documento da citare nelle offerte. E uno strumento che definisce responsabilita, requisiti e livelli di maturita in modo strutturato. Conoscerne la logica aiuta a capire cosa il cliente puo chiedere, cosa si deve garantire e dove finisce la propria responsabilita.
Struttura della serie: quattro gruppi, logiche diverse
La serie IEC 62443 e organizzata in quattro gruppi, ciascuno identificato dal secondo numero della sigla. Non tutti i documenti hanno lo stesso peso operativo, e non tutti sono gia pubblicati nella versione definitiva, ma la struttura complessiva e stabile e riconosciuta a livello internazionale.
Parte 1-x: concetti generali e glossario
Il gruppo 1-x fornisce le definizioni di base, i concetti fondamentali e il modello di riferimento. Il documento piu rilevante e la IEC 62443-1-1, che introduce il vocabolario comune, i ruoli, le relazioni tra le parti e il concetto di IACS (Industrial Automation and Control System). La IEC 62443-1-2 contiene un glossario esteso. La IEC 62443-1-3 descrive le metriche di conformita, e la IEC 62443-1-4 tratta il ciclo di vita della sicurezza IACS.
Per un integrator o un OEM, il gruppo 1-x serve soprattutto per allinearsi sul linguaggio. In un progetto con piu attori, usare gli stessi termini non e un dettaglio: evita ambiguita nei capitolati, nelle specifiche e nelle verifiche.
Parte 2-x: policy e procedure dell'asset owner
Il gruppo 2-x si rivolge principalmente a chi possiede e gestisce l'impianto, cioe l'asset owner. La IEC 62443-2-1 definisce i requisiti per un sistema di gestione della sicurezza IACS (CSMS, Cybersecurity Management System). La IEC 62443-2-4, invece, specifica i requisiti di sicurezza per i service provider, cioe per chi fornisce servizi di integrazione, manutenzione e supporto.
La 2-4 e uno dei documenti piu rilevanti per i system integrator. Stabilisce cosa l'asset owner puo pretendere dal fornitore in termini di gestione degli accessi remoti, hardening, gestione delle credenziali, documentazione, patching, backup e procedure operative. Non si tratta di raccomandazioni generiche: sono requisiti strutturati, organizzati per capability e per livello di maturita.
La IEC 62443-2-2 si occupa della valutazione della protezione di un IACS in esercizio (IACS Protection Level Rating), e la IEC 62443-2-3 copre la gestione delle patch in ambiente IACS.
Parte 3-x: requisiti di sistema
Il gruppo 3-x entra nel vivo dell'architettura. La IEC 62443-3-2 definisce il processo di security risk assessment per un sistema IACS, introducendo concetti chiave come zone, conduit e Security Level target (SL-T). La IEC 62443-3-3 specifica i requisiti tecnici di sicurezza a livello di sistema, organizzati in sette Foundational Requirements (FR).
Per un integrator, la 3-2 e il punto di partenza per progettare l'architettura di sicurezza di un impianto. Definisce come suddividere il sistema in zone omogenee dal punto di vista del rischio, come collegare le zone attraverso conduit controllati e come assegnare a ogni zona un target di sicurezza coerente con le conseguenze di un incidente. La 3-3 traduce quei target in requisiti tecnici concreti.
Parte 4-x: requisiti di prodotto e componente
Il gruppo 4-x si rivolge ai product supplier, cioe ai vendor di componenti e software IACS. La IEC 62443-4-1 definisce i requisiti per un ciclo di sviluppo sicuro (Secure Development Lifecycle), e la IEC 62443-4-2 specifica i requisiti tecnici di sicurezza per i singoli componenti, classificati come software application, embedded device, host device o network device.
Per un OEM, questi sono i documenti di riferimento. La 4-1 richiede processi documentati di threat modeling, gestione delle vulnerabilita, test di sicurezza, gestione delle patch e fine supporto. La 4-2 traduce i Foundational Requirements della 3-3 a livello di singolo componente, con requisiti diversi per ogni tipo di dispositivo.
I tre ruoli: asset owner, integration service provider, product supplier
Uno degli aspetti piu utili della IEC 62443 e la distinzione esplicita tra tre ruoli, ciascuno con responsabilita proprie e requisiti dedicati.
Asset owner
L'asset owner e chi possiede e gestisce il sistema IACS. E responsabile della definizione dei requisiti di sicurezza, della gestione del rischio, della governance e del mantenimento della postura di sicurezza nel tempo. In pratica: lo stabilimento, l'end user, l'operatore. L'asset owner definisce il target di sicurezza (SL-T) per ogni zona e conduit, approva le soluzioni proposte dall'integrator, e si assicura che le misure siano mantenute in esercizio.
Non sempre l'asset owner ha le competenze interne per svolgere tutte queste attivita. In molti contesti industriali, parte del lavoro viene delegata a un integratore o a un consulente. Ma la responsabilita finale resta in capo all'asset owner.
Integration service provider (system integrator)
L'integrator progetta, configura, installa e mette in servizio il sistema IACS, o parti di esso. La IEC 62443-2-4 definisce i requisiti che un integrator deve soddisfare: dalla gestione degli account e delle credenziali, alla documentazione dell'architettura, al backup delle configurazioni, all'hardening dei componenti, alla gestione degli accessi remoti durante commissioning e assistenza.
Nella pratica, questo significa che l'integrator non puo limitarsi a "far funzionare" il sistema e poi consegnare. Deve dimostrare che il sistema e stato integrato secondo criteri di sicurezza coerenti con il Security Level richiesto dall'asset owner. Deve produrre documentazione, seguire procedure verificabili, gestire credenziali in modo controllato e garantire che il sistema consegnato sia in uno stato noto e ripristinabile.
Per molti integrator questo rappresenta un cambiamento significativo. Tradizionalmente, il commissioning si concludeva con il collaudo funzionale. Con la 62443, il perimetro si estende alla sicurezza della configurazione, alla tracciabilita delle modifiche e alla consegna di evidenze documentali.
Product supplier (vendor / OEM)
Il product supplier e chi sviluppa e fornisce componenti hardware o software destinati a essere usati in un IACS. La IEC 62443-4-1 richiede un processo di sviluppo che includa threat modeling, gestione delle vulnerabilita, security testing e gestione degli aggiornamenti. La IEC 62443-4-2 specifica i requisiti tecnici che ogni tipo di componente deve soddisfare, in funzione del Security Level dichiarato.
Per un OEM che produce macchine o sottosistemi destinati a essere integrati in impianti piu grandi, la conformita alla 4-1 e alla 4-2 diventa un requisito sempre piu frequente nei capitolati. Non basta che il prodotto "funzioni": deve essere sviluppato con un processo documentato e deve esporre capacita di sicurezza coerenti con i livelli richiesti dal sistema in cui verra inserito.
Security Level: cosa sono e come si usano
La IEC 62443 definisce quattro Security Level (SL), numerati da 1 a 4, che rappresentano il livello di protezione atteso rispetto a categorie crescenti di minaccia. Non sono livelli di "gravita" generica: sono legati al tipo di attaccante e alle risorse che questo puo impiegare.
Il concetto di Security Level si declina in tre forme distinte:
- SL-T (Target): il livello di sicurezza obiettivo, definito dall'asset owner per ogni zona e conduit in base al risk assessment.
- SL-C (Capability): il livello di sicurezza che un componente o un sistema e in grado di supportare, in funzione delle sue caratteristiche tecniche. Questo e cio che il vendor o l'integrator dichiarano.
- SL-A (Achieved): il livello effettivamente raggiunto dopo l'integrazione e la configurazione nel contesto operativo reale.
La relazione tra questi tre livelli e fondamentale. L'asset owner definisce SL-T. L'integrator seleziona componenti con SL-C adeguato e li configura per raggiungere SL-A >= SL-T. Se un componente ha SL-C inferiore al target, servono misure compensative a livello di sistema o di zona.
Nella pratica, la maggior parte degli impianti industriali si colloca tra SL 1 e SL 2. Raggiungere SL 3 richiede investimenti significativi in architettura, processi e competenze. SL 4 e raro al di fuori di infrastrutture critiche governative o militari.
Un asset owner definisce SL-T 2 per la zona di controllo di una linea di produzione. L'integrator seleziona un PLC con SL-C 2 e un HMI con SL-C 1. Per compensare il gap sull'HMI, l'integrator implementa segmentazione aggiuntiva, controllo degli accessi a livello di rete e restrizioni sulle porte di comunicazione. L'SL-A complessivo della zona viene valutato in base a cio che il sistema, nel suo insieme, riesce effettivamente a garantire.
Zone e conduit: il cuore dell'architettura di sicurezza
Il modello zone-conduit e il meccanismo con cui la IEC 62443-3-2 organizza la segmentazione di sicurezza di un sistema IACS. Non e un concetto astratto: e il modo in cui si traduce il risk assessment in architettura di rete e di sistema.
Zone
Una zona e un raggruppamento logico di asset IACS che condividono lo stesso livello di sicurezza richiesto (SL-T). Tutti gli asset all'interno di una zona hanno requisiti di sicurezza omogenei. La zona definisce un confine di protezione: il traffico che entra o esce dalla zona deve attraversare un conduit controllato.
Nella pratica, una zona puo corrispondere a una cella di produzione, a un'area funzionale (es. compressori, utilities, packaging), a un livello dell'architettura (es. livello di campo, livello di controllo, livello supervisione) o a un dominio organizzativo. La scelta dipende dall'analisi del rischio e dalla struttura dell'impianto.
Un errore frequente e creare zone troppo ampie, mettendo nello stesso perimetro asset con requisiti di sicurezza molto diversi. Un altro errore e creare zone troppo granulari, rendendo l'architettura ingestibile. La 3-2 non prescrive un numero fisso di zone: richiede che la suddivisione sia coerente con il rischio e documentata.
Conduit
Un conduit e il canale di comunicazione che collega due zone. Ha un proprio SL-T e deve garantire che il traffico tra le zone sia controllato, filtrato e coerente con le policy di sicurezza. Un conduit puo essere implementato con un firewall, con una DMZ, con un data diode, con regole di routing o con una combinazione di misure, a seconda del livello di sicurezza richiesto.
Il concetto chiave e che nessun flusso di comunicazione tra zone diverse dovrebbe avvenire senza passare per un conduit definito e documentato. Nella realta, molti impianti esistenti hanno flussi non mappati, connessioni dirette tra livelli diversi, switch condivisi tra reti OT e IT, o accessi remoti che bypassano completamente la segmentazione prevista.
Per un integrator, il modello zone-conduit e sia uno strumento di progettazione sia un linguaggio per comunicare con l'asset owner. Quando si presenta un'architettura di rete, ragionare in termini di zone e conduit rende espliciti i confini, i flussi ammessi, le dipendenze e i punti di controllo.
I sette Foundational Requirements
La IEC 62443-3-3 organizza i requisiti tecnici di sistema in sette aree fondamentali, chiamate Foundational Requirements (FR). Ogni FR contiene un insieme di System Requirements (SR) e, per ciascun SR, dei Requirement Enhancement (RE) che si applicano a Security Level crescenti.
Non tutti i FR hanno lo stesso peso in ogni contesto. In un impianto dove la priorita assoluta e la disponibilita, FR 7 e FR 5 sono spesso i primi su cui concentrarsi. In contesti con dati sensibili di processo, FR 4 acquista rilevanza. La scelta delle priorita dipende dal risk assessment e dagli SL-T assegnati.
Per un integrator, i FR della 3-3 sono la mappa dei requisiti tecnici da soddisfare a livello di sistema. Per un OEM, la 4-2 traduce gli stessi FR a livello di componente. La coerenza tra i due livelli e essenziale: un sistema non puo raggiungere SL 2 se i componenti che lo compongono non supportano almeno SL-C 2 per i FR rilevanti, oppure se non vengono implementate misure compensative documentate.
Cosa cambia nella pratica per un system integrator
Per chi integra sistemi IACS, la IEC 62443 introduce cambiamenti concreti su diversi fronti.
Documentazione e consegna
Non basta consegnare uno schema elettrico e un manuale operativo. La 62443-2-4 richiede che l'integrator fornisca documentazione dell'architettura di sicurezza, elenco degli account e delle credenziali, baseline delle configurazioni, procedure di backup e ripristino, e descrizione delle misure di hardening applicate. In molti progetti, questa documentazione non esiste o e frammentaria.
Gestione degli accessi durante il commissioning
Le credenziali usate durante l'installazione e il commissioning devono essere gestite in modo controllato. Account temporanei, password di default non cambiate, accessi remoti lasciati attivi dopo il collaudo: sono tutti punti che la 62443 affronta esplicitamente. L'integrator deve dimostrare che il sistema viene consegnato in uno stato "pulito" dal punto di vista delle credenziali e degli accessi.
Hardening e configurazione di sicurezza
Disattivare servizi non necessari, chiudere porte non utilizzate, configurare i protocolli secondo le raccomandazioni del vendor, limitare i privilegi degli account operativi: queste attivita non sono piu un "nice to have" ma parte integrante della consegna, se il capitolato richiama la 62443.
Responsabilita sul Security Level raggiunto
Se il contratto specifica un SL-T per una zona, l'integrator e responsabile di dimostrare che il sistema integrato raggiunge quell'obiettivo, o di documentare le gap e le misure compensative. Questo richiede competenze che vanno oltre l'automazione tradizionale: segmentazione di rete, gestione delle identita, logging, protezione delle comunicazioni.
Cosa cambia per un OEM
Per chi produce macchine, sottosistemi o componenti destinati a sistemi IACS, le parti 4-1 e 4-2 definiscono un perimetro preciso di responsabilita.
Secure Development Lifecycle (4-1)
La 4-1 richiede che il processo di sviluppo includa threat modeling, gestione delle vulnerabilita, security testing, rilascio di patch e comunicazione degli advisory. Non si tratta di aggiungere un test di sicurezza alla fine dello sviluppo: il concetto e che la sicurezza sia integrata nel processo, dalla fase di specifica alla fine del supporto.
Per un OEM di medie dimensioni, adottare la 4-1 puo richiedere un investimento significativo in processi e competenze. La certificazione secondo la 4-1 e offerta da enti come ISASecure (ISCI) e richiede audit documentali e di processo. Non tutti i vendor la raggiungono, e non tutti i mercati la richiedono allo stesso modo. Ma la tendenza e chiara: i capitolati la citano con frequenza crescente, soprattutto nei settori regolamentati.
Requisiti di componente (4-2)
La 4-2 specifica cosa un componente deve supportare dal punto di vista della sicurezza, in funzione del Security Level dichiarato. Per un embedded device a SL 2, ad esempio, servono identificazione univoca del dispositivo, autenticazione degli utenti, protezione delle credenziali, logging degli eventi di sicurezza, protezione dell'integrita del firmware e capacita di aggiornamento sicuro.
Non tutti i componenti sul mercato soddisfano questi requisiti. In molti casi, PLC, HMI, switch industriali o gateway hanno capacita di sicurezza limitate, soprattutto nelle versioni meno recenti. L'OEM deve conoscere il Security Level che il proprio prodotto puo supportare e dichiararlo in modo trasparente, perche l'integrator e l'asset owner ne dipendono per le scelte progettuali.
Certificazione: ISASecure, IECEE e altri schemi
La conformita alla IEC 62443 puo essere dichiarata dal vendor o dall'integrator, oppure verificata da enti terzi attraverso schemi di certificazione. I principali sono:
- ISASecure (ISCI): programma gestito da ISA che offre certificazioni per componenti (EDSA, SSA), per processi di sviluppo (SDLA, basato sulla 4-1) e per sistemi (SSA). E lo schema piu diffuso a livello internazionale per i prodotti IACS.
- IECEE: lo schema di certificazione IEC, che ha introdotto un programma specifico per la 62443. Prevede la valutazione di conformita tramite laboratori accreditati (CB Scheme).
- TUV, Bureau Veritas e altri enti: diversi organismi offrono servizi di assessment e certificazione basati sulla 62443, con approcci e ambiti variabili.
La certificazione non e obbligatoria per legge nella maggior parte dei contesti, ma sta diventando un requisito di mercato. Alcuni asset owner la richiedono nei capitolati, altri la considerano un criterio preferenziale. Per un OEM, avere la certificazione 4-1 o 4-2 e un vantaggio competitivo concreto. Per un integrator, la capacita di lavorare secondo la 2-4 e di documentare il proprio processo e sempre piu spesso un prerequisito per partecipare a progetti in settori regolamentati.
IEC 62443 e NIS2: punti di contatto
La NIS2 non cita esplicitamente la IEC 62443, ma i requisiti della direttiva in materia di risk management, incident handling, supply chain security, governance e continuita operativa si sovrappongono in larga misura con le aree coperte dalla 62443. Per le organizzazioni industriali che devono adeguarsi alla NIS2, la IEC 62443 rappresenta un framework tecnico coerente per tradurre i requisiti normativi in misure concrete.
In particolare, la 62443 copre aspetti che la NIS2 richiede ma non dettaglia: segmentazione, Security Level, zone e conduit, requisiti per i fornitori, ciclo di sviluppo sicuro, gestione delle patch in ambiente OT. Per un integrator o un OEM che opera nel perimetro NIS2, adottare la 62443 come riferimento tecnico e una scelta prudente e ben supportata.
Limiti e aspetti da considerare
La IEC 62443 e uno strumento potente, ma non e priva di complessita e limiti pratici.
- Costo e accessibilita: i documenti della serie non sono gratuiti. L'acquisto dell'intera serie rappresenta un investimento, e la lettura richiede tempo e competenze specifiche. Non esiste una versione semplificata ufficiale per PMI o per chi si avvicina per la prima volta.
- Stato di pubblicazione: non tutti i documenti della serie sono pubblicati nella versione definitiva. Alcune parti sono in fase di revisione o di sviluppo. E importante verificare quale edizione e in vigore prima di fare riferimento a requisiti specifici.
- Applicabilita a impianti esistenti: la serie e stata pensata per sistemi nuovi o per retrofit significativi. Applicarla a impianti esistenti con decenni di stratificazione, componenti legacy e architetture non documentate richiede compromessi e pragmatismo. Non tutto si puo portare a SL 2 senza interventi strutturali.
- Competenze necessarie: implementare la 62443 richiede competenze che combinano automazione, networking, cybersecurity e gestione dei processi. Queste competenze non sono ancora diffuse in modo uniforme nel settore.
- Gap tra teoria e pratica: il modello zone-conduit presuppone una rete ben segmentata e documentata. In molti impianti reali, la rete e cresciuta nel tempo senza un disegno di sicurezza, con switch condivisi, VLAN non gestite, connessioni dirette tra livelli e accessi remoti non mappati. Prima di applicare la 62443, spesso serve un lavoro significativo di mappatura e bonifica dell'esistente.
Un approccio graduale e realistico
Non serve raggiungere la piena conformita alla 62443 in un colpo solo. Un percorso realistico per un integrator o un OEM puo partire da alcuni passi concreti:
L'obiettivo non e la conformita formale, ma la capacita di dimostrare che il proprio lavoro segue criteri di sicurezza documentati, ripetibili e coerenti con uno standard riconosciuto.
Il nostro punto di vista
La IEC 62443 sta diventando il linguaggio comune della cybersecurity industriale. Non e l'unico standard rilevante, e non risolve tutti i problemi, ma offre una struttura chiara per assegnare responsabilita, definire requisiti e verificare risultati. Per un system integrator, significa ripensare il modo in cui si consegna un impianto. Per un OEM, significa integrare la sicurezza nel processo di sviluppo, non solo nel prodotto finito.
Chi inizia a lavorare con la 62443 oggi si trovera in una posizione migliore domani, quando i capitolati la richiederanno come requisito di base e non come opzione.
Vuoi capire dove si colloca la tua organizzazione rispetto alla IEC 62443?
Contattaci per una valutazione tecnica — analizziamo il tuo ruolo (integrator o OEM), mappiamo le pratiche attuali rispetto ai requisiti della serie e identifichiamo le priorita di adeguamento.