IEC 62443-4-1: il ciclo di sviluppo sicuro per i prodotti industriali

Che cos'è IEC 62443-4-1?

IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements, è stata pubblicata a gennaio 2018. Secondo il proprio campo di applicazione, la norma specifica i requisiti di processo per lo sviluppo sicuro dei prodotti utilizzati nei sistemi di automazione e controllo industriale. Il ciclo di vita che definisce copre la definizione dei requisiti di sicurezza, la progettazione sicura, l'implementazione sicura, la verifica e la validazione, la gestione dei difetti, la gestione delle patch e il fine vita del prodotto.

Si applica a chi sviluppa e mantiene un prodotto: il fornitore che realizza controllori, dispositivi embedded, apparati di rete, software host o applicazioni. Non si applica all'integratore né all'utente del prodotto, che hanno le proprie parti della serie. ISA pubblica la serie come ISA/IEC 62443.

La norma descrive requisiti di processo, policy e procedure, piuttosto che funzionalità tecniche di sicurezza. I requisiti tecnici per i componenti si trovano in IEC 62443-4-2.

Le otto pratiche di IEC 62443-4-1

I requisiti sono raggruppati in otto pratiche, ciascuna con una breve sigla che fa da prefisso agli ID dei suoi requisiti. La ISA Global Cybersecurity Alliance elenca 47 requisiti in totale:

Pratica	Requisiti	Che cosa copre
1. Gestione della sicurezza (SM)	Da SM-1 a SM-13	Pianificare e gestire il processo di sicurezza: responsabilità, competenze, sicurezza dell'ambiente di sviluppo, chiavi private, componenti forniti esternamente e di terze parti, verifica del processo, miglioramento continuo
2. Specifica dei requisiti di sicurezza (SR)	Da SR-1 a SR-5	Contesto di sicurezza del prodotto, modello delle minacce, requisiti di sicurezza del prodotto e loro revisione
3. Sicurezza fin dalla progettazione (SD)	Da SD-1 a SD-4	Principi di progettazione sicura, progettazione con difesa in profondità, revisione del progetto, best practice di progettazione
4. Implementazione sicura (SI)	Da SI-1 a SI-2	Revisione dell'implementazione della sicurezza e standard di codifica sicura
5. Test di verifica e validazione della sicurezza (SVV)	Da SVV-1 a SVV-5	Test dei requisiti, test di mitigazione delle minacce, test delle vulnerabilità, penetration test, indipendenza dei tester
6. Gestione dei problemi legati alla sicurezza (DM)	Da DM-1 a DM-6	Ricevere, esaminare, valutare, affrontare e divulgare i problemi di sicurezza nel prodotto
7. Gestione degli aggiornamenti di sicurezza (SUM)	Da SUM-1 a SUM-5	Qualificare, documentare e consegnare gli aggiornamenti di sicurezza, nei tempi previsti
8. Linee guida di sicurezza (SG)	Da SG-1 a SG-7	Documentazione per l'utente su difesa in profondità, hardening, funzionamento sicuro, gestione degli account e smaltimento

Pratica 6: gestione dei problemi legati alla sicurezza (DM)

DM è la pratica che un PSIRT riconosce come propria. Secondo ISAGCA, i suoi processi servono a gestire i problemi di sicurezza di un prodotto configurato secondo la sua strategia di difesa in profondità. I suoi sei requisiti seguono un problema dalla segnalazione alla chiusura:

• DM-1: ricezione delle notifiche di problemi legati alla sicurezza
• DM-2: esame dei problemi legati alla sicurezza
• DM-3: valutazione dei problemi legati alla sicurezza
• DM-4: trattamento dei problemi legati alla sicurezza
• DM-5: divulgazione dei problemi legati alla sicurezza
• DM-6: revisione periodica della pratica di gestione dei difetti di sicurezza

In parole semplici: ricevere le segnalazioni, controllarle, valutarle, risolverle, informare gli utenti e rivedere il processo stesso.

Questa sequenza è il ciclo di vita della gestione delle vulnerabilità con un altro nome, e DM-1 e DM-5 sono i punti in cui entra in gioco la divulgazione coordinata delle vulnerabilità. La divulgazione può essere pubblicata come advisory CSAF, con una dichiarazione VEX per le versioni non interessate.

Pratica 7: gestione degli aggiornamenti di sicurezza (SUM)

SUM riprende da dove DM decide una correzione. I suoi processi, nella sintesi di ISAGCA, assicurano che gli aggiornamenti di sicurezza per hardware, software o firmware del prodotto siano sottoposti a test di regressione e resi disponibili agli utenti in modo tempestivo. I cinque requisiti sono:

• SUM-1: qualifica degli aggiornamenti di sicurezza
• SUM-2: documentazione degli aggiornamenti di sicurezza
• SUM-3: documentazione degli aggiornamenti di sicurezza di componenti dipendenti o del sistema operativo
• SUM-4: consegna degli aggiornamenti di sicurezza
• SUM-5: consegna tempestiva delle patch di sicurezza

SUM-3 è quello che arriva fino alla Sua supply chain: gli aggiornamenti dei componenti e dei sistemi operativi da cui dipende il Suo prodotto. Per un prodotto embedded basato su una distribuzione Linux, possono essere la maggior parte delle patch che distribuisce.

Livelli di maturità

IEC 62443-4-1 non chiede se un processo esiste, ma quanto è maturo. Usa quattro livelli di maturità, basati su CMMI for Development:

Livello	Significato
ML1 Initial	I processi vengono eseguiti in modo ad hoc o non documentato
ML2 Managed	I processi sono documentati e descrivono come l'attività viene svolta e gestita
ML3 Defined (Practiced)	I processi sono documentati, eseguiti e ripetibili
ML4 Improving	I processi vengono migliorati nel tempo con metriche di prestazione ed efficacia

La differenza tra ML2 e ML3 è la pratica. Un processo DM scritto può essere ML2. ML3 significa che il processo è stato eseguito e ripetuto: problemi ricevuti, valutati e chiusi, aggiornamenti consegnati, con le registrazioni che lo dimostrano.

Certificazione

• ISASecure SDLA. Il programma Security Development Lifecycle Assurance certifica il processo del ciclo di vita di un'organizzazione di sviluppo secondo IEC 62443-4-1. Le valutazioni sono svolte da laboratori SDLA autorizzati, accreditati come organismi di valutazione della conformità.
• Organismi di certificazione e IECEE CB Scheme. Organismi di prova e certificazione come Applus+ e TÜV Rheinland valutano i fornitori rispetto a 62443-4-1 e indicano il livello di maturità raggiunto, anche nell'ambito dell'IECEE CB Scheme, applicabile in più di 50 Paesi.

Un certificato 62443-4-1 copre il processo di sviluppo del fornitore, non un singolo prodotto. I prodotti vengono valutati separatamente rispetto a 62443-4-2.

Come si collega 62443-4-1 al resto della serie

• IEC 62443-4-2, requisiti tecnici di sicurezza per i componenti IACS: che cosa deve saper fare il prodotto. 4-1 è il modo in cui lo si costruisce e lo si mantiene.
• IEC 62443-3-3, requisiti di sicurezza di sistema e livelli di sicurezza: i requisiti tecnici equivalenti a livello di sistema.
• IEC 62443-2-4, requisiti del programma di sicurezza per i fornitori di servizi IACS: gli integratori e i fornitori di manutenzione che installano e assistono il Suo prodotto presso il sito dell'asset owner e che dipendono dai Suoi aggiornamenti e dalle Sue linee guida di sicurezza.

Mappare IEC 62443-4-1 sul lavoro del PSIRT

Attività del PSIRT	Dove si colloca in 62443-4-1
Ricezione delle segnalazioni di vulnerabilità	DM-1
Triage e analisi	DM-2, DM-3
Remediation	DM-4, SUM-1
Advisory e divulgazione	DM-5, SUM-2
Patch per componenti di terze parti	SUM-3, con SM-9 e SM-10 sui componenti forniti esternamente e di terze parti
Rilascio della correzione	SUM-4, SUM-5
Metriche e revisione del processo	DM-6, SM-13

Questa mappatura è nostra, in base ai titoli dei requisiti. La norma non cita i PSIRT per nome; lo stesso lavoro è descritto nel PSIRT Services Framework di FIRST e in ISO/IEC 30111.

Le SBOM come evidenza per DM e SUM

I titoli dei requisiti del 2018 non citano le SBOM. Ma molti dei problemi di sicurezza di un prodotto industriale si trovano in componenti che il fornitore non ha scritto: il kernel Linux, OpenSSL, BusyBox, uno stack di protocollo. Rispondere a DM-2 e DM-3 per un nuovo advisory significa sapere quali prodotti e versioni contengono il componente interessato. Documentare gli aggiornamenti SUM-3 significa sapere con quali versioni dei componenti è stata distribuita ogni release. A ML3, queste risposte devono avere delle registrazioni alle spalle.

Un elenco di componenti scritto a mano, o una scansione dell'albero dei sorgenti, diventa rapidamente obsoleto. Una SBOM ottenuta dalla build che ha prodotto la release no, a patto che la build stessa sia registrata.

Il ruolo di CRACI

CRACI non certifica nulla ai sensi di IEC 62443 e non gestisce il Suo processo di sviluppo. Le sue registrazioni possono servire da evidenza per alcune parti di esso: l'inventario dei componenti di ogni release e il monitoraggio delle build distribuite rispetto alle nuove vulnerabilità.

CRACI esegue le build GitHub Actions, comprese le build Yocto, sui propri runner e registra i pacchetti che ogni job ha effettivamente scaricato, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache e le dipendenze che nessun lockfile elenca. Ogni SBOM riporta uno stato di completezza e si esporta in CycloneDX o SPDX. Le SBOM monitorate vengono rivalutate continuamente, la cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile e la vista dell'inventario mostra quali versioni sono distribuite su quali prodotti. Le SBOM dei vendor per i componenti acquistati vengono monitorate insieme alle Sue build. Veda il tracciamento delle vulnerabilità e CRACI per i PSIRT.

IEC 62443-4-1: domande frequenti

Che cos'è IEC 62443-4-1?

IEC 62443-4-1:2018, Secure product development lifecycle requirements, è la parte della serie IEC 62443 che stabilisce i requisiti di processo per i fornitori che sviluppano prodotti utilizzati nei sistemi di automazione e controllo industriale. Copre requisiti di sicurezza, progettazione sicura, implementazione, verifica e validazione, gestione dei difetti, gestione delle patch e fine vita del prodotto.

Quali sono le otto pratiche di IEC 62443-4-1?

Gestione della sicurezza (SM), specifica dei requisiti di sicurezza (SR), sicurezza fin dalla progettazione (SD), implementazione sicura (SI), test di verifica e validazione della sicurezza (SVV), gestione dei problemi legati alla sicurezza (DM), gestione degli aggiornamenti di sicurezza (SUM) e linee guida di sicurezza (SG). Insieme contengono 47 requisiti.

Qual è la differenza tra IEC 62443-4-1 e 62443-4-2?

4-1 riguarda il processo che un fornitore usa per sviluppare e mantenere i prodotti. 4-2 stabilisce i requisiti tecnici di sicurezza per i componenti stessi, come dispositivi embedded, dispositivi di rete, dispositivi host e applicazioni software. In genere un fornitore viene valutato rispetto a 4-1 per il suo processo di sviluppo e rispetto a 4-2 per un prodotto specifico.

Quali pratiche di IEC 62443-4-1 coprono la gestione delle vulnerabilità?

Principalmente la pratica 6, gestione dei problemi legati alla sicurezza (da DM-1 a DM-6), che copre ricezione, esame, valutazione, trattamento e divulgazione dei problemi di sicurezza, e la pratica 7, gestione degli aggiornamenti di sicurezza (da SUM-1 a SUM-5), che copre qualifica, documentazione e consegna puntuale degli aggiornamenti di sicurezza. È il lavoro che svolge un PSIRT.

Quali sono i livelli di maturità di IEC 62443-4-1?

Quattro livelli, basati su CMMI for Development: ML1 Initial (ad hoc o non documentato), ML2 Managed (processi documentati), ML3 Defined o Practiced (documentati, eseguiti e ripetibili) e ML4 Improving (processi migliorati nel tempo con metriche di prestazione).

Come si ottiene la certificazione IEC 62443-4-1?

Tramite un organismo di certificazione accreditato. Il programma SDLA di ISASecure certifica le organizzazioni di sviluppo secondo IEC 62443-4-1 tramite laboratori autorizzati, e organismi di certificazione come TÜV Rheinland e Applus+ rilasciano certificati 62443-4-1 che indicano il livello di maturità raggiunto, anche nell'ambito dell'IECEE CB Scheme.

IEC 62443-4-1 richiede una SBOM?

I titoli dei requisiti del 2018 non citano le SBOM. Diversi requisiti riguardano i componenti forniti esternamente e gli aggiornamenti di componenti dipendenti e sistemi operativi, e un elenco affidabile dei componenti di ogni release è il modo pratico per dimostrare come li gestisce.