Tech Fridays · Episodio 3
Prepararsi alla certificazione IEC 62443-4-1 non è compilare una checklist. Il percorso reale di un’azienda industriale, raccontato da chi lo ha guidato.
Le certificazioni di cybersecurity sono passate, in pochi anni, da vantaggio competitivo a requisito d’accesso. Con NIS2 e il Cyber Resilience Act, chi sviluppa componenti per l’automazione industriale si trova sempre più spesso a doverlo dimostrare: non a parole, ma con un audit. Tra gli standard di riferimento, IEC 62443-4-1 occupa una posizione particolare. Non certifica il prodotto. Certifica il processo con cui il prodotto viene sviluppato. La domanda a cui risponde non è “questo dispositivo è sicuro oggi?”, ma “questa azienda è organizzata per produrre dispositivi sicuri, in modo ripetibile, nel tempo?”. È una differenza sostanziale. E cambia completamente il modo in cui ci si prepara. Abbiamo accompagnato un’azienda italiana attiva nei sistemi di sicurezza e nella robotica industriale lungo questo percorso. Non possiamo entrare nei dettagli tecnici dei loro sistemi (sono riservati), ma il metodo e le lezioni del percorso meritano di essere raccontati. Soprattutto una.
Il punto di partenza: un gap assessment onesto
Ogni percorso serio comincia con una fotografia dello stato attuale. Non con un piano d’azione, ma con una domanda scomoda: a che punto siamo davvero? Nel caso di questo cliente, il gap assessment iniziale ha misurato una conformità del 76% rispetto ai requisiti del Maturity Level 2 (ML2). Vale la pena chiarire cosa significa. IEC 62443-4-1 non misura la sicurezza con un voto assoluto, ma attraverso livelli di maturità del processo: quanto le pratiche di sicurezza sono documentate, gestite e applicate in modo coerente in tutta l’organizzazione. Un 76% su ML2 è un buon punto di partenza: significa che molte pratiche esistono già, ma non tutte sono formalizzate e ripetibili come lo standard richiede. Da lì abbiamo costruito il piano: cinque fasi su 24 settimane per arrivare a ML2, con una prospettiva ulteriore (stimata tra i 7 e i 18 mesi aggiuntivi) per il salto a ML3, il livello in cui le pratiche non sono solo definite ma applicate in modo sistematico su tutta la linea di sviluppo.
Quando la remediation non è una patch
Qui arriva la parte più istruttiva del percorso. Quella che di solito nei case study non si racconta. Durante il vulnerability assessment sul perimetro esterno abbiamo rilevato 18 vulnerabilità. Alla fine del ciclo di remediation, quante sono state chiuse con una correzione tecnica? Una. Non è un fallimento. È la realtà di qualsiasi ambiente industriale reale, e capirlo è il vero salto di maturità. Le altre 17 vulnerabilità ricadevano in due categorie. Alcune riguardavano asset legacy o in via di dismissione: sistemi su cui investire in una correzione avrebbe avuto poco senso, perché destinati a uscire di scena. Altre riguardavano sistemi troppo critici per il business per essere modificati senza fermare la produzione. E in un contesto industriale fermare la produzione ha un costo che spesso supera quello del rischio che si vuole mitigare. Cosa si fa in questi casi? Non si finge di non aver visto. E non si applica una patch a forza rischiando di rompere un impianto in funzione. Si formalizza un’accettazione del rischio con misure compensative. Per ciascuna vulnerabilità non risolvibile tecnicamente abbiamo introdotto controlli alternativi (monitoraggio rafforzato, restrizioni di accesso) e documentato tutto in un risk register condiviso con il cliente: cosa abbiamo trovato, perché non lo abbiamo corretto, come lo teniamo sotto controllo, chi se ne assume la responsabilità. Non tutte le misure compensative si sono però limitate al monitoraggio. Alcune vulnerabilità avevano un impatto elevato, come casi di authentication bypass o di server-side request forgery (SSRF), e non potevano restare in attesa di una patch completa. Qui la collaborazione stretta con il team del cliente ha fatto la differenza: invece di aspettare una correzione impraticabile nel breve periodo, abbiamo implementato remediation parziali mirate. Regole a livello di proxy e di rete per filtrare le richieste pericolose, insieme a piccoli interventi di codice sui punti più esposti, hanno ridotto concretamente la superficie di rischio senza fermare i sistemi in produzione. Non una soluzione definitiva, ma una mitigazione reale, documentata e condivisa. Questo è ciò che IEC 62443-4-1 premia davvero. Non l’assenza di rischio, che non esiste, ma la capacità di riconoscerlo, decidere consapevolmente e documentare la decisione. Un’azienda che sa esattamente quali rischi si sta tenendo, e perché, è più matura di una che dichiara zero vulnerabilità sperando che sia vero.
A che punto siamo
Va detto con chiarezza, perché l’onestà fa parte del metodo: il percorso è in corso. Il raggiungimento formale del Maturity Level 2 con l’ente accreditato è la milestone verso cui il lavoro è indirizzato, non un risultato che possiamo ancora dare per acquisito. Preferiamo raccontarlo così, a percorso aperto, piuttosto che aspettare un traguardo per costruirci sopra una storia levigata. Perché il valore, per chi legge e sta valutando di intraprendere lo stesso cammino, sta proprio qui: nel metodo, nelle scelte, nei compromessi ragionati. Non nel bollino finale.
Cosa portarsi a casa
Se la tua azienda sviluppa componenti per l’automazione o le infrastrutture industriali, e IEC 62443-4-1 è comparso nei requisiti dei tuoi clienti o nelle tue prossime gare, tre cose valgono più di ogni checklist:
- Parti da un gap assessment vero. Sapere che sei al 76% è più utile che sperare di essere al 100%. La fotografia iniziale definisce tutto il resto.
- Preparati a non risolvere tutto con una patch. In ambiente industriale la maggior parte delle vulnerabilità si gestisce, non si elimina. La maturità sta nel come.
- Documenta le decisioni, non solo le correzioni. Un risk register ben tenuto racconta più della tua sicurezza di mille vulnerabilità chiuse in silenzio. La certificazione, alla fine, è la conseguenza. Il risultato vero è un’organizzazione che sviluppa in modo sicuro perché ha imparato a farlo, non perché doveva superare un esame. È il percorso che accompagniamo, insieme alle aziende, un rischio documentato alla volta. Cybersecurity su misura per ogni azienda.
