La conformità alla Legge sulla ciberresilienza (Cyber Resilience Act – CRA) dell’Unione Europea si sta rivelando una delle sfide tecniche e organizzative più difficili che i produttori che commercializzano dispositivi integrati in Europa devono attualmente affrontare e risolvere. La legge è entrata in vigore il 10 dicembre 2024 e molti degli obblighi per gli OEM saranno applicati solo tre anni dopo, a partire dall’11 dicembre 2027.
Un elemento cruciale dello sforzo di conformità al CRA di un OEM è la capacità di aggiornare il software di un dispositivo per proteggerlo dalle nuove minacce informatiche e, in particolare, rispondere alle notifiche ufficiali sulle vulnerabilità ed esposizioni comuni (CVE). Mentre i componenti hardware di un sistema conforme agli standard di sicurezza, ovvero dispositivi quali un HSM (Hardware Security Module) o un TPM (Trusted Platform Module), sono oggi ben compresi dagli OEM, il processo di gestione della protezione di sicurezza del software embedded e della distribuzione degli aggiornamenti software ai dispositivi sul campo è nuovo e sconosciuto a molti.
È comprensibile che il tema dell’aggiornamento software susciti una certa trepidazione: si tratta di una funzione per molti versi complessa e difficile da gestire. Infatti, questo è un ambito in cui Foundries.io fornisce tecnologia e supporto ai produttori di dispositivi embedded da molti anni. Riteniamo che non vi sia motivo per cui un OEM debba preoccuparsi dei requisiti di aggiornamento software imposti dalla CRA. Tuttavia, l’implementazione della legislazione ha dimostrato che, sebbene gran parte del processo possa essere semplificato e automatizzato, il settore deve ancora colmare la lacuna nell’offerta di alcuni importanti strumenti e servizi che alleggerirebbero notevolmente l’onere della conformità alla CRA.
Come la CRA richiede che vengano gestiti gli aggiornamenti software
Secondo l’UE, lo scopo della legge CRA è “tutelare i consumatori e le imprese che acquistano prodotti software o hardware con una componente digitale”. La CRA affronta il problema dell’inadeguato livello di sicurezza informatica di molti prodotti e della mancanza di tempestivi aggiornamenti di sicurezza per prodotti e software (vedere Figura 1). La legge si propone di raggiungere questi obiettivi imponendo nuovi obblighi ai produttori e ai rivenditori di un prodotto. In particolare, la legge “obbliga i fabbricanti a prendere sul serio la sicurezza durante l’intero ciclo di vita di un prodotto”.
Fig. 1: un dispositivo IoT connesso, come un campanello smart, è vulnerabile agli attacchi informatici; la CRA richiede al fabbricante di essere in grado di fornire e implementare rapidamente le correzioni necessarie. (Credito immagine: Amin sotto licenza Creative Commons 4.0.)
Sono finiti i giorni in cui un produttore di dispositivi elettronici poteva semplicemente spedire un prodotto dalla sua fabbrica e dimenticarsi della sua esistenza: l’obbligo di proteggere il dispositivo dalle minacce di attacchi informatici persiste ora molto tempo dopo che il dispositivo è stato spedito all’utente finale.
La legge codifica questo continuo obbligo di offrire la necessaria sicurezza in vari modi; i più importanti sono:
- Risolvere le vulnerabilità identificate negli avvisi CVE applicabili dopo la spedizione
- Mantenere una distinta base del software (SBOM) obbligatoria per ogni unità di produzione, per consentire un monitoraggio efficace del CVE
- Risolvere le vulnerabilità “senza alcun indugio”
- Testare e rivedere regolarmente la sicurezza del prodotto
- Implementare una politica per la divulgazione delle vulnerabilità
- Distribuire in modo sicuro e tempestivo le correzioni/gli aggiornamenti all’utente finale, senza costi aggiuntivi.
Pertanto, l’OEM ha ora il dovere di creare un registro, o SBOM, di tutti i componenti software di ogni unità di produzione spedita dalla fabbrica, di gestire e aggiornare lo SBOM per tenere conto delle modifiche alla base del codice di un dispositivo derivanti da aggiornamenti e patch, di sapere quando una parte della base del codice del dispositivo sia esposta a una vulnerabilità nota e di correggere rapidamente la vulnerabilità e distribuire gratuitamente la correzione agli utenti (vedere Figura 2).
Fig. 2: i produttori di smartphone distribuiscono regolarmente aggiornamenti software via wireless. Ora anche i produttori di dispositivi embedded devono seguire il loro esempio.
Il valore dell’infrastruttura di manutenzione a supporto degli aggiornamenti a vita
La base del codice degli attuali dispositivi embedded connessi, in particolare quelli basati sul sistema operativo Linux®, è ampia e complessa: spesso è composta da centinaia o migliaia di componenti separati di terze parti commerciali e open source, nonché da software proprietario. È quasi sempre impraticabile compilare manualmente un inventario di questi componenti: è necessario un sistema per automatizzare la generazione di SBOM durante lo sviluppo, in produzione e dopo la spedizione di ogni variante del prodotto.
La complessità si estende alle funzioni di sicurezza quali l’avvio protetto, l’autenticazione e la protezione crittografica dei dati e degli aggiornamenti software. I registri delle chiavi segrete, univoci per ogni unità di produzione, devono essere archiviati e gestiti in modo sicuro. La gestione dell’infrastruttura a chiave pubblica (PKI) è un elemento essenziale dell’approccio di un OEM alla conformità CRA.
Inoltre, gli OEM necessitano di un sistema per la gestione dei dispositivi sul campo, il quale offre una base per la distribuzione e l’implementazione dei pacchetti di aggiornamento corretti per ogni singola unità. Un sistema di gestione dei dispositivi efficace offre un inventario incentrato sulla sicurezza di tutte le unità inviate ai clienti (ad eccezione di quelle dismesse), ciascuna contrassegnata da un ID di sicurezza univoco. Ciò può aiutare a proteggere i dispositivi dal rischio di attacchi informatici tramite l’introduzione di unità spoof nella flotta di dispositivi, ad esempio per cercare di ottenere l’accesso a codici o segreti critici.
Queste funzioni richiedono un approccio sistematico alla registrazione, all’archiviazione e alla gestione dei dati unità per unità e end-to-end – dallo sviluppo alla produzione fino alla manutenzione post-spedizione. Poiché tutte queste funzioni sono alla base della conformità alla CRA, l’introduzione di questa normativa europea ha spinto gli OEM a valutare l’implementazione di un framework DevOps formale, il tipo di sistema di cui la piattaforma FoundriesFactory™ di Foundries.io è un esempio (vedere Figura 3).
Una piattaforma di questo tipo dovrebbe fornire un gruppo di utility e di strumenti integrati per i seguenti aspetti:
- Gestione PKI
- Generazione e manutenzione di SBOM
- Gestione della flotta
- Un flusso CI/CD per supportare lo sviluppo e la distribuzione rapidi di correzioni e patch
- Sviluppo, consegna e implementazione di aggiornamenti supportati da potenti funzionalità di sicurezza
Con l’istituzione di un framework di questo tipo all’avvio dello sviluppo di un nuovo prodotto e utilizzandolo come base per la gestione del ciclo di vita, gli OEM possono automatizzare, ottimizzare e semplificare i processi di sicurezza e gestione dei dispositivi che altrimenti sarebbero estremamente complessi, time-consuming e soggetti a errori umani.
Fig. 3: la piattaforma FoundriesFactory integra risorse open source esterne per offrire funzioni di sviluppo, sicurezza e operative
I pezzi mancanti del puzzle della conformità
Un framework DevOps collaudato potrebbe essere necessario per tutti gli OEM, fatta eccezione per quelli più piccoli, per gestire il programma di conformità CRA, ma questo non è sufficiente. Sono necessari altri strumenti e sistemi, ma purtroppo, per alcuni degli elementi cruciali del programma di conformità, non sono ancora disponibili efficaci soluzioni open source. Due lacune sono particolarmente evidenti:
- Nel monitoraggio dell’esposizione a CVE
- Nella documentazione e verifica delle azioni di conformità
Gli attuali strumenti di verifica CVE tendono a essere rudimentali: generano un numero eccessivo di risultati positivi. Questo perché abbinano direttamente il nome e la descrizione di un pacchetto software identificato in un avviso CVE con il nome e la descrizione del software nello SBOM di un dispositivo. Ma questo non equivale a identificare una vulnerabilità specifica. In genere, un avviso CVE si applica a una o più sezioni specifiche del codice di base di un prodotto software; il resto del codice di base non è a rischio.
Pertanto, se un dispositivo incorporato utilizza solo una parte del prodotto per implementare una funzione specifica e non contiene la parte vulnerabile della base del codice, non sarà necessario creare e distribuire una correzione. Ma un controllore CVE rudimentale contrassegnerà comunque il dispositivo come vulnerabile se utilizza una qualsiasi parte di un pacchetto software indicato in una nota CVE.
Ciò evidenzia la necessità di strumenti più sofisticati, in grado di analizzare il codice sorgente di un dispositivo e individuare corrispondenze con il codice vulnerabile identificato in un avviso CVE. La nuova disponibilità di modelli avanzati di intelligenza artificiale porta tuttavia a essere ottimisti, in quanto possono fornire la base per la creazione di tali strumenti nel prossimo futuro.
La seconda lacuna evidenziata nel gruppo di strumenti per la conformità è la mancanza di un sistema di supporto alla rendicontazione e all’audit. In caso di inadempienza, la CRA impone forti sanzioni finanziarie, proporzionali alle dimensioni dell’azienda produttrice. Questo aspetto dovrebbe motivare fortemente gli OEM a dimostrare in che modo abbiano rispettato i termini della legge, con riferimento a ogni singola unità produttiva nel campo.
Proprio come l’utility SBOM in software come la piattaforma FoundriesFactory automatizza la generazione di un elenco di componenti software unità per unità, un efficace strumento di reporting di conformità dovrà prevedere un registro delle exposure segnalate e delle correzioni applicate, unità per unità.
Ci si augura che questi strumenti in grado di colmare entrambe le lacune emergano dalla comunità open source e siano adottati in modo sufficientemente diffuso da diventare standardizzati. Laddove esistano soluzioni open source standard, il settore non deve crearne di nuove e questo è un grande vantaggio in quanto consente anche di condividere esperienze e conoscenze comuni.
Il “circolo virtuoso” della standardizzazione open source è il motivo per cui la piattaforma FoundriesFactory, ad esempio, ha adottato The Update Framework (TUF) come strumento per la distribuzione e l’implementazione di aggiornamenti software incentrati sulla sicurezza. Per lo stesso motivo, molti altri elementi della piattaforma FoundriesFactory hanno una base open source.
Aggiornamento software: un processo, non un pacchetto
Sotto la pressione della necessità di conformarsi al CRA, gli OEM devono ora fare i conti con le difficoltà legate all’aggiornamento del software. Hanno compreso che gli aggiornamenti software sono un elemento cruciale del loro impegno nei confronti della conformità, ma anche che l’aggiornamento software non è solo una questione di pacchetto di aggiornamento: un intero sistema di monitoraggio dei dispositivi, sicurezza, gestione della flotta di dispositivi e funzioni di distribuzione del software deve supportare la capacità di rispondere rapidamente a una nuova vulnerabilità o exposure.
Molti OEM trarranno vantaggio dalla creazione di una propria infrastruttura di aggiornamento su un framework DevOps collaudato, che fornirà una base solida e automatizzata per identificare e gestire le unità di produzione sul campo in modo sicuro, consentendo loro di offrire il pacchetto di aggiornamento giusto al dispositivo giusto al momento giusto.
Di George Grey VP Technology,
Qualcomm Technologies International, Ltd., membro del team di Foundries.io
