IEC 62443 | Security Assessment e NIS2 Cybersecurity

La IEC 62443 è una delle famiglie di standard più importanti per la cybersecurity industriale. Nasce per proteggere gli Industrial Automation and Control Systems (IACS): ambienti OT, SCADA, PLC, HMI, DCS, sistemi di supervisione, reti industriali, gateway, componenti embedded e architetture IT/OT. Oggi è diventata ancora più strategica perché aiuta a tradurre in controlli tecnici concreti ciò che normative come il Cyber Resilience Act, la NIS2, il RED Delegated Act / EN 18031 e il Regolamento Macchine 2023/1230 chiedono a livello di prodotto, organizzazione, macchina o supply chain.

Implementare controlli, però, non basta: bisogna verificare se funzionano davvero. ISGroup interviene come partner tecnico-offensivo per verificare con security assessment, penetration test OT, reverse engineering, firmware analysis, vulnerability assessment e security auditing se un sistema, un prodotto o un ambiente industriale regge a scenari di attacco realistici. La serie ISA/IEC 62443 definisce requisiti e processi per implementare e mantenere sicuri i sistemi IACS con un approccio olistico che collega operation technology, information technology, safety e cybersecurity.

A chi serve la IEC 62443

La IEC 62443 non guarda solo alla tecnologia, ma anche ai ruoli, ai processi, al ciclo di vita, ai fornitori, all’integrazione e alla manutenzione. Serve a più categorie di soggetti.

Soggetto	Perché usa IEC 62443
Asset owner / utilizzatore industriale	Per gestire il programma di sicurezza OT e proteggere impianti, linee, reti e sistemi in esercizio
System integrator	Per progettare, integrare e mantenere soluzioni di automazione con requisiti di sicurezza documentabili
Produttore di componenti	Per sviluppare prodotti industriali sicuri: PLC, HMI, gateway, software, firmware, apparati embedded
Fornitore di servizi OT	Per dimostrare processi sicuri in attività di manutenzione, integrazione e supporto
CISO / OT Security Manager	Per collegare rischio industriale, controlli tecnici e verifiche di sicurezza
Responsabile qualità / compliance	Per avere una base tecnica riconosciuta su cui costruire evidenze e audit

La IEC 62443 è particolarmente utile quando l’ambiente non è più isolato: macchine connesse, accessi remoti, telemetria, dashboard cloud, gateway industriali, manutenzione predittiva, edge computing e integrazione IT/OT rendono il rischio cyber parte della continuità operativa e, in alcuni casi, della sicurezza fisica.

Perché la IEC 62443 collega normativa e verifica tecnica

Le normative europee più recenti chiedono sicurezza by design, gestione delle vulnerabilità, misure di risk management, sicurezza della supply chain, protezione dei prodotti digitali e capacità di dimostrare ciò che è stato fatto.

Il Cyber Resilience Act introduce requisiti orizzontali di cybersecurity per prodotti hardware e software con elementi digitali immessi sul mercato UE. La Commissione Europea lo descrive come un framework orizzontale applicabile ai prodotti con elementi digitali, inclusi prodotti finali e componenti immessi separatamente sul mercato.

La NIS2 richiede a soggetti essenziali e importanti di adottare misure di gestione del rischio cyber proporzionate, considerando anche standard europei e internazionali rilevanti e la sicurezza della supply chain, come stabilito dalla Direttiva (UE) 2022/2555.

Il RED Delegated Act ha attivato requisiti di cybersecurity per alcune categorie di radio equipment; la Commissione ha pubblicato in Gazzetta Ufficiale i riferimenti agli standard armonizzati EN 18031 collegati a tali requisiti.

In questo scenario la IEC 62443 fornisce una grammatica tecnica comune — asset, zone, conduit, risk assessment, security level, requisiti di sistema e di componente, secure development lifecycle, processi per asset owner, service provider e product supplier, verifica e validazione dei controlli — che permette di tradurre obblighi generali in controlli verificabili. Le normative definiscono cosa deve essere governato; la IEC 62443 aiuta a capire come farlo; un assessment offensivo verifica se quei controlli resistono davvero.

Le parti della IEC 62443 che contano per ruolo

La serie IEC 62443 è ampia e non tutte le parti si applicano agli stessi soggetti. Conviene leggerla per ruoli.

Parte IEC 62443	A chi interessa	Cosa copre
IEC 62443-2-1	Asset owner / operatori industriali	Programma di sicurezza per IACS in esercizio
IEC 62443-2-4	Service provider / system integrator	Processi di sicurezza per integrazione e manutenzione
IEC 62443-3-2	Asset owner, progettisti, integratori	Risk assessment di sistema, zone, conduit e target Security Level
IEC 62443-3-3	Progettisti, integratori, asset owner	Requisiti tecnici di sicurezza del sistema e Security Level
IEC 62443-4-1	Product supplier / R&D	Secure development lifecycle per prodotti IACS
IEC 62443-4-2	Product supplier / R&D / component vendor	Requisiti tecnici di sicurezza per componenti IACS

IEC 62443-2-1: programma di sicurezza per asset owner

La IEC 62443-2-1:2024 specifica requisiti di policy e procedure per il programma di sicurezza di un asset owner su sistemi IACS in esercizio. La norma riconosce che molti sistemi legacy possono avere cicli di vita superiori a vent’anni e che, quando i sistemi non supportano nativamente alcune capacità tecniche, possono essere necessarie misure compensative. Per un utilizzatore industriale, questa parte è importante perché sposta la sicurezza OT da attività puntuale a programma continuativo.

IEC 62443-2-4: requisiti per service provider

La IEC 62443-2-4:2023 riguarda i requisiti di processo che i fornitori di servizi IACS possono offrire all’asset owner durante integrazione e manutenzione di una Automation Solution. È rilevante per system integrator, manutentori, fornitori OT e aziende che operano su impianti di terzi.

IEC 62443-3-2: risk assessment, zone e conduit

La IEC 62443-3-2:2020 stabilisce requisiti per definire il sistema sotto esame, suddividerlo in zone e conduit, valutare il rischio per ciascuna zona e conduit, stabilire il target Security Level e documentare i requisiti di sicurezza. È una delle parti più importanti per chi deve progettare o rivalutare un ambiente OT.

IEC 62443-3-3: requisiti di sistema e Security Level

La IEC 62443-3-3:2013 fornisce requisiti tecnici di sicurezza per sistemi di controllo, collegati ai sette requisiti fondamentali della IEC 62443, e definisce i Security Level di capacità del sistema. È il riferimento quando si vuole verificare se un sistema OT ha controlli coerenti con il livello di rischio atteso.

IEC 62443-4-1: secure product development lifecycle

La IEC 62443-4-1:2018 specifica requisiti di processo per lo sviluppo sicuro di prodotti usati in sistemi di automazione e controllo industriale, includendo definizione dei requisiti di sicurezza, secure design, secure implementation, verification and validation, defect management, patch management e fine vita del prodotto. È centrale per produttori di PLC, HMI, gateway, software industriale, firmware, componenti embedded e prodotti Industrial IoT.

IEC 62443-4-2: requisiti tecnici per componenti IACS

La IEC 62443-4-2:2019 definisce requisiti tecnici per componenti IACS e li collega ai sette requisiti fondamentali: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events e resource availability. È la parte da considerare quando il focus è il prodotto: gateway, controller, HMI, software, firmware, apparati industriali e componenti connessi.

I sette requisiti fondamentali

La IEC 62443 organizza molti requisiti attorno a sette aree fondamentali, che vanno sempre contestualizzate: un impianto brownfield, una macchina legacy, un gateway nuovo e una piattaforma cloud industriale non hanno lo stesso profilo di rischio.

Requisito fondamentale	Significato pratico	Esempi di verifica tecnica
Identification and Authentication Control	Identificare e autenticare utenti, processi e dispositivi	Test credenziali, account condivisi, MFA, autenticazione API
Use Control	Limitare azioni e privilegi in base al ruolo	Test autorizzazioni, privilege escalation, RBAC
System Integrity	Proteggere sistema, software, firmware e configurazioni da alterazioni	Firmware analysis, secure boot, update signing, integrity check
Data Confidentiality	Proteggere dati sensibili in transito e a riposo	Test cifratura, data exposure, secrets management
Restricted Data Flow	Limitare e controllare i flussi tra zone	Segmentation review, firewall test, zone/conduit validation
Timely Response to Events	Rilevare e rispondere a eventi di sicurezza	Logging review, alerting, test rilevabilità scenari d’attacco
Resource Availability	Mantenere disponibilità e resilienza dei sistemi	Test DoS controllati, hardening, backup/recovery review

Security Level: come usarli correttamente

Il Security Level (SL) serve a collegare il rischio atteso alle capacità di sicurezza richieste. Non è un voto generico e non va usato come bollino commerciale.

Livello	Interpretazione pratica
SL 1	Protezione contro violazioni casuali o accidentali
SL 2	Protezione contro attaccanti con mezzi semplici e risorse limitate
SL 3	Protezione contro attaccanti intenzionali con competenze e risorse moderate
SL 4	Protezione contro attaccanti sofisticati, con risorse elevate e motivazione specifica

Il Security Level non si sceglie arbitrariamente: si definisce attraverso analisi del rischio, criticità dell’ambiente, impatti su safety e produzione, esposizione, minacce realistiche e capacità tecniche implementabili. La IEC 62443-3-2 collega la definizione del sistema sotto esame, la segmentazione in zone e conduit, il risk assessment e la definizione del target Security Level per ciascuna zona e conduit.

L’errore da evitare è puntare a “SL 3 ovunque”: in molti ambienti OT sarebbe costoso, complesso o irrealistico. L’approccio corretto è risk-based e considera quali asset proteggere, quali minacce considerare, quale impatto avrebbe una compromissione, quali controlli sono sostenibili, quali misure compensative servono sui legacy e quali verifiche tecniche dimostrano che il livello target è raggiungibile.

Zone e conduit: il modello di segmentazione OT

Il modello zones and conduits è uno degli elementi più utili della IEC 62443. Una zona raggruppa asset con requisiti di sicurezza simili; un conduit rappresenta il canale di comunicazione tra zone.

Zona	Asset tipici	Rischio principale
Enterprise IT	ERP, posta, utenti office, servizi IT	Phishing, malware, lateral movement
DMZ industriale	Jump server, historian, proxy, update repository	Ponte tra IT e OT
Supervisione OT	SCADA, HMI, engineering workstation	Accesso non autorizzato a sistemi di controllo
Controllo	PLC, RTU, DCS, controller	Manipolazione comandi e parametri
Safety	Safety PLC, sistemi di protezione	Impatto su safety e disponibilità
Accesso remoto	VPN, router industriali, account vendor	Compromissione fornitori e manutenzione remota

Questa logica è fondamentale perché molti incidenti non avvengono per una singola vulnerabilità critica, ma per una catena: credenziale debole, accesso remoto esposto, rete piatta, HMI raggiungibile, privilegi eccessivi, logging insufficiente. Validare zone e conduit significa verificare se le zone sono davvero separate, se i conduit sono controllati, se le regole firewall sono coerenti con i flussi necessari, se un account IT può raggiungere asset OT, se un fornitore può muoversi lateralmente e se l’accesso remoto è temporaneo, tracciato e con privilegi minimi. Un assessment offensivo è particolarmente utile qui perché non si limita a leggere il diagramma di rete, ma verifica se la segmentazione funziona davvero.

Come la IEC 62443 aiuta a leggere CRA, NIS2 e RED

La IEC 62443 non sostituisce le normative e non rende automaticamente conformi a CRA, NIS2, RED o Regolamento Macchine. Fornisce però un linguaggio tecnico per trasformare obblighi generali in controlli verificabili.

Norma	Cosa chiede	Come aiuta IEC 62443	Cosa può verificare ISGroup
CRA	Prodotti con elementi digitali sicuri by design, gestione vulnerabilità, update sicuri	4-1 per secure development, 4-2 per requisiti tecnici di componenti	Firmware analysis, code review, hardware/software test, vulnerability assessment
NIS2	Misure di gestione del rischio cyber, supply chain, efficacia dei controlli	2-1 per programma asset owner, 3-2/3-3 per controlli OT	OT security assessment, segmentation review, penetration test OT
RED / EN 18031	Cybersecurity per radio equipment in scope, protezione rete/dati/frode	4-2 per requisiti tecnici di componenti e prodotto	Testing su dispositivi wireless, firmware, API, update, superfici radio
Regolamento Macchine	Protezione contro corruzione software/dati e rischi su macchine connesse	3-2/3-3 per architettura e sistema; 4-1/4-2 per componenti	Assessment su macchine connesse, accessi remoti, gateway, protocolli

Implementare non basta: la validazione tecnica

Molte organizzazioni si fermano alla fase documentale: policy, diagrammi, matrice dei controlli, risk assessment, elenco asset, procedure. Sono elementi necessari, ma non sufficienti.

Una rete OT può risultare segmentata in diagramma ma essere attraversabile tramite una regola firewall troppo ampia. Un prodotto può dichiarare autenticazione robusta ma esporre API con controlli di autorizzazione deboli. Un firmware può prevedere aggiornamenti sicuri ma accettare pacchetti non firmati o vulnerabili a rollback. Un accesso remoto può essere protetto da VPN ma usare account condivisi o privilegi eccessivi.

Per rispondere alla domanda concreta — i controlli implementati reggono a un attacco realistico? — servono attività tecniche come penetration test OT, vulnerability assessment controllato, review della segmentazione IT/OT, test su accessi remoti, firewall rule review, attack path analysis, firmware security assessment, reverse engineering, source code review, protocol security testing, API security testing, hardening review e re-test post-remediation.

Dalla norma al controllo: mappa di validazione

Area IEC 62443	Controllo tecnico	Come validarlo
Identificazione e autenticazione	Account nominali, MFA, gestione credenziali	Test login, password policy, bypass, account condivisi
Controllo uso	Ruoli, privilegi, least privilege	Test escalation, accessi non autorizzati, abuso privilegi
Integrità di sistema	Secure boot, update firmati, hardening	Firmware analysis, update tampering, reverse engineering
Riservatezza dei dati	Cifratura, segregazione dati, secrets protection	Traffic analysis, test esposizione dati, verifica storage
Flusso dati limitato	Segmentazione, firewall, DMZ OT	Segmentation test, path validation, firewall rule review
Risposta agli eventi	Log, alert, monitoraggio	Simulazione controllata di scenari e verifica rilevabilità
Disponibilità delle risorse	Resilienza, backup, recovery	Review backup, test ripristino, valutazioni controllate di disponibilità
Gestione vulnerabilità	Patch, tracking, remediation	Vulnerability assessment, re-test, remediation validation
Sviluppo sicuro	SDLC, code review, test di sicurezza	Source code review, SAST/DAST assistito, manual review
Sicurezza fornitori	Accessi fornitori, manutenzione, contratti tecnici	Remote access review, vendor access assessment

Ambienti legacy e brownfield

La IEC 62443 è utile negli ambienti industriali anche perché riconosce la realtà degli impianti: non tutto è nuovo, aggiornabile o progettato per essere sicuro. Molti ambienti OT includono PLC legacy, HMI obsolete, sistemi operativi non più supportati, applicazioni proprietarie, fornitori storici, segmentazioni nate per esigenze produttive e protocolli non cifrati.

La IEC 62443-2-1:2024 riconosce che molti sistemi legacy possono non avere capacità tecniche native per soddisfare alcune esigenze e che misure compensative possono far parte delle policy e procedure dell’asset owner. In OT non sempre si può “patchare e basta”: a volte la mitigazione corretta è segmentare, isolare, limitare accessi, introdurre jump server, rafforzare il logging, creare allowlist, eliminare percorsi non necessari, ridurre privilegi, monitorare il traffico o spostare funzioni esposte in DMZ. Anche le misure compensative, però, vanno validate: una mitigazione non testata resta un’ipotesi.

Penetration test OT: come si struttura

Il penetration test OT non è un penetration test IT trasferito sull’impianto. In ambienti industriali un test offensivo deve rispettare vincoli specifici: continuità operativa, safety, disponibilità, finestre di manutenzione, asset non patchabili, protocolli sensibili, PLC e HMI che possono reagire male a scansioni aggressive. Per questo il test deve essere progettato in modo progressivo.

Assessment documentale e architetturale. Si parte da diagrammi, asset, flussi, accessi, zone, conduit, firewall, VPN, account fornitori, HMI, SCADA, PLC, gateway e cloud industriale.

Threat model. Si identificano scenari di attacco realistici: accesso remoto compromesso, pivot IT/OT, abuso di account vendor, manipolazione di protocolli, modifica parametri, compromissione gateway.

Vulnerability assessment controllato. Si analizzano vulnerabilità note, configurazioni, versioni ed esposizioni, evitando scansioni invasive su asset sensibili.

Test mirati. Si testano percorsi di attacco concordati: autenticazione, autorizzazione, segmentazione, firewall, accessi remoti, servizi, interfacce applicative, protocolli.

Report e remediation. Si produce evidenza tecnica con vulnerabilità, impatto, probabilità, scenari, priorità, contromisure e re-test. Il risultato è utile sia al team tecnico sia alla governance: non “abbiamo una policy IEC 62443”, ma “abbiamo verificato che i controlli chiave funzionano o sappiamo dove correggere”.

IEC 62443 e product security: firmware, software e componenti

Per i produttori di componenti industriali, la IEC 62443 è particolarmente rilevante nelle parti 4-1 e 4-2. La 4-1 riguarda il processo di sviluppo sicuro del prodotto: requisiti di sicurezza, secure design, implementazione sicura, verifica, validazione, defect management, patch management e fine vita. La 4-2 riguarda i requisiti tecnici del componente: autenticazione, controllo uso, integrità, confidenzialità, restricted data flow, risposta agli eventi e disponibilità.

Per un produttore di gateway industriali, HMI, PLC, moduli edge, software OT o dispositivi Industrial IoT, il testing deve includere firmware analysis, reverse engineering, secure boot review, verifica update firmati, test credenziali hardcoded, test interfacce debug, API security testing, mobile app security testing se presente, backend security assessment, test protocolli industriali, source code review e vulnerability management review. Questi test sono coerenti anche con la logica del Cyber Resilience Act, che richiede cybersecurity by design e gestione delle vulnerabilità per prodotti con elementi digitali.

Errori comuni nell’applicare la IEC 62443

Trattarla come pura documentazione. La IEC 62443 richiede processi, ma ha forti implicazioni tecniche. Senza validazione, il rischio resta teorico.

Scegliere Security Level troppo alti senza risk assessment. Un target irrealistico genera costi, complessità e frustrazione. Il Security Level deve derivare dal rischio.

Ignorare il legacy. Molti ambienti OT non possono essere messi “a norma” con patch e update. Servono misure compensative testate.

Confondere segmentazione disegnata e segmentazione reale. Una cosa è avere un diagramma; un’altra è dimostrare che un attaccante non può attraversare zone e conduit.

Trattare i fornitori come eccezioni. Accessi remoti, manutenzione e service provider sono spesso tra i percorsi più rischiosi.

Testare solo l’IT. Un ambiente industriale ha protocolli, vincoli e asset diversi. Serve competenza OT specifica.

Non fare re-test. Senza re-test, la remediation resta una promessa.

Checklist di autovalutazione

Le domande seguenti aiutano a capire se l’approccio è maturo o si è fermato alla fase documentale.

Il sistema sotto esame è stato definito formalmente?
Gli asset IT, OT, cloud, gateway e accessi remoti sono mappati?
L’ambiente è diviso in zone e conduit?
Il target Security Level è definito per zona o sistema?
La segmentazione è stata verificata tecnicamente?
Gli accessi remoti e gli account fornitori sono stati testati?
Autenticazione e autorizzazione su HMI, SCADA, API e servizi sono stati verificati?
Firmware, software o componenti embedded critici sono stati analizzati?
I meccanismi di update e patch sono stati testati?
Esiste un piano di remediation basato su rischio reale?
È stato eseguito un re-test dopo le correzioni?
Esistono evidenze tecniche utilizzabili in audit o valutazioni interne?

Se molte risposte sono negative, il problema non è solo di conformità: è di validazione.

Output di un security assessment in ottica IEC 62443

Output	Utilità
Executive summary	Decisioni di management, budget, priorità
Technical report	Evidenze tecniche per IT, OT, R&D, system integrator
Mappa asset e superfici d’attacco	Base per zone, conduit e risk assessment
Threat model	Scenari realistici di compromissione
Validazione segmentazione	Verifica pratica dei confini tra zone
Vulnerability assessment	Identificazione di vulnerabilità note e configurazioni deboli
Penetration test report	Evidenza di sfruttabilità reale e impatto
Firmware / software findings	Vulnerabilità su componenti e prodotti
Piano di remediation	Priorità e contromisure concrete
Re-test report	Evidenza delle correzioni

Questo tipo di output può essere integrato in percorsi di audit, risk assessment, qualifica fornitore, revisione architetturale, roadmap di remediation o preparazione a requisiti normativi. Non sostituisce una certificazione, ma la rende più solida dal punto di vista tecnico.

Il ruolo di ISGroup

ISGroup supporta aziende industriali, OEM, system integrator e produttori di componenti con attività tecniche allineabili a percorsi IEC 62443, senza sostituire organismi certificatori o consulenti normativi. Le attività includono IEC 62443 oriented security assessment, penetration test OT, vulnerability assessment controllato, verifica zone e conduit, segmentation review, Remote Access Security Review, penetration test su macchine connesse, firmware security assessment, reverse engineering, source code review, API security testing, protocol security testing, hardware/software security testing, remediation plan e re-test post-correzione.

La IEC 62443 aiuta a definire controlli e livelli di sicurezza; ISGroup verifica se quei controlli reggono davvero.

Domande frequenti sulla IEC 62443

La IEC 62443 è obbligatoria?
La IEC 62443 non è una normativa europea direttamente obbligatoria come CRA o NIS2. È una famiglia di standard tecnici che può diventare rilevante come riferimento contrattuale, tecnico, di audit o di settore, soprattutto in ambienti OT, Industrial IoT, automazione e infrastrutture critiche.
Che differenza c’è tra IEC 62443-3-2 e IEC 62443-3-3?
La 3-2 riguarda il security risk assessment per il system design: definizione del sistema sotto esame, zone, conduit, rischi e target Security Level. La 3-3 riguarda i requisiti tecnici di sicurezza del sistema e i Security Level di capacità del sistema.
Che differenza c’è tra IEC 62443-4-1 e IEC 62443-4-2?
La 4-1 riguarda il processo di sviluppo sicuro dei prodotti IACS. La 4-2 riguarda i requisiti tecnici di sicurezza dei componenti IACS, come controller, HMI, gateway, software e dispositivi embedded.
Serve un penetration test per la IEC 62443?
La IEC 62443 non prescrive direttamente un penetration test, ma per validare controlli tecnici, segmentazione, accessi remoti, autenticazione, firmware, protocolli e superfici esposte, penetration test e security assessment producono evidenze concrete e difficilmente sostituibili con sola documentazione.
ISGroup certifica IEC 62443?
No. ISGroup non vende certificazioni IEC 62443 e non sostituisce organismi di certificazione. L’intervento riguarda la verifica tecnica: assessment, penetration test, reverse engineering, firmware analysis, security auditing e validazione dei controlli.

IEC 62443 security assessment per CRA, NIS2 e RED