Il 31 gennaio la Commissione Europea ha emanato il Regolamento di Esecuzione relativo all’adozione dell’EUCC, lo schema di certificazione europeo basato sui Common Criteria. Si tratta di uno schema per la certificazione di prodotti, sia hardware che software, dal punto di vista della security.
Il tema della certificazione dei prodotti è molto attuale e sentito: la possibilità di avere un’evidenza oggettiva e certificata delle caratteristiche di sicurezza di un prodotto sarebbe molto utile per le aziende, sia per propria tutela che per poter dare evidenza di adeguatezza alle norme sempre più numerose che mettono in capo alle aziende oneri in tema di cybersecurity.
Eppure, la storia delle certificazioni di prodotti di cybersecurity non è una storia di successi. Per capire l’impatto che può avere l’EUCC sul mercato della sicurezza, è utile vedere un po’ di questa storia.
Dall’Orange Book all’EUCC: evoluzione delle certificazioni di cybersecurity
Il primo schema di certificazione di sicurezza per sistemi informatici che abbia avuto una certa notorietà e diffusione, almeno in occidente, è stato il Trusted Computer System Evaluation Criteria (TCSEC) meglio noto come Orange Book, dal colore della copertina del documento principale di riferimento. Pubblicato nel 1983, era destinato alla certificazione dei sistemi informatici (non dei prodotti) ad uso del Dipartimento della Difesa degli Stati Uniti. Quello schema presentava già alcune delle principali caratteristiche che avrebbero accompagnato le certificazioni di sicurezza negli anni successivi.
Con il TCSEC, ad essere certificati erano i singoli sistemi, ovvero le singole installazioni, sulla base di prodotti che potevano essere al più qualificati. Il sistema comprendeva tutto, dall’hardware al software: processori, scheda madre, schede di rete, sistema operativo… tutto era qualificato e poi certificato insieme. Quindi, se per un’installazione era necessario, ad esempio, un diverso modello di scheda di rete, era necessario ricominciare quasi da capo.
Il processo di certificazione era rigoroso e proprio per questo lungo e complesso, caratteristica che si è poi mantenuta nel tempo. Ottenere una certificazione ai livelli più alti era difficile, ma era un requisito perché il sistema potesse essere utilizzato in determinati contesti.
Non mancavano gli aneddoti su sistemi certificati in configurazioni “semplici” per poi essere in realtà utilizzati in configurazioni più realistiche e quindi, di principio, non certificate. Tuttavia, i TCSEC hanno incorporato un concetto che tuttora rimane fondamentale: la distinzione fra funzionalità di sicurezza e assurance (“garanzia”). Per fare un’analogia, potrei avere per un’auto due sistemi frenanti fra cui scegliere: uno che permette di passare da 100 km/h a 0 in 70 m, e uno che permette di farlo in 50 m. Tuttavia, mentre il primo è stato progettato e testato rigorosamente, il secondo ha subito solo qualche verifica superficiale. In molti casi, può essere preferibile un sistema meno “performante” ma con più garanzie di essere affidabile. Per tornare alla cybersecurity, possiamo pensare ad un firewall che effettua analisi meno sofisticate sul traffico, ma su cui sono state fatte verifiche più attente che le regole non possano essere aggirate.
I limiti del TCSEC
I TCSEC presentavano diversi difetti, fra cui la mancanza di separazione fra il livello di funzionalità e quello di assurance nei livelli che definiva, ma il più importante era certamente il fatto di certificare sistemi e non prodotti, cosa che lo rendeva decisamente inadatto per un utilizzo commerciale più generale.
Così, nel 1990, Francia, Germania, Paesi Bassi e Regno Unito pubblicarono gli ITSEC, che dovevano servire come riferimento per il mercato europeo. Oltre a separare il livello di funzionalità da quello di assurance, erano applicabili a prodotti, e non solo a sistemi, rappresentando quindi un notevole passo avanti rispetto ai TCSEC. Altri paesi hanno provato a fare lo stesso, ma nessuno di questi schemi ha mai avuto successo al di fuori di contesti estremamente circoscritti, tipicamente legati al settore della difesa e a poco altro, dove erano un requisito obbligatorio e quindi i fornitori, per forza di cose, dovevano certificare i propri prodotti.
La ragione è molto semplice: un processo di certificazione molto lungo e complesso, e quindi anche costoso, che oltretutto ritardava la disponibilità sul mercato di prodotti certificati. Non aiutava, naturalmente, il fatto che fossero tutti, in qualche modo, schemi “nazionali”.
Analisi dei Common Criteria e il loro ruolo nel mercato attuale
Si arriva quindi al 1994 quando, sulla base degli standard precedenti, vengono pubblicati i Common Criteria, prima da parte dei paesi occidentali più attivi su questi temi, e poi nel 1999 come ISO/IEC 15408 (i Common Criteria) e ISO/IEC 18045 (la metodologia di valutazione).
I Common Criteria sono attualmente il principale riferimento quando si parla di certificazioni di prodotto sui temi di cybersecurity. Accordi di mutuo riconoscimento fanno sì che prodotti certificati in un paese siano accettati come certificati anche in molti altri, tema fondamentale perché un’azienda investa nella certificazione dei propri prodotti.
Lo schema è consolidato, ed ha ormai trent’anni di storia alle spalle. Ci sono autorità di certificazione nazionali e laboratori qualificati. Con queste premesse, ci si aspetterebbe che sia una certificazione ampiamente diffusa e conosciuta. Solo che non lo è.
Problemi e limiti delle certificazioni Common Criteria
Se guardiamo sul sito ufficiale dei Common Criteria, troviamo uno degli elenchi più completi di prodotti certificati[1]. Qui si cominciano a capire i problemi.
Apparentemente, ci sono quasi 2000 prodotti certificati, che già di per sé non sono tanti. Se però prendiamo una categoria a caso, ad esempio quella dei “Boundary protection devices and systems” (firewall e simili), che comprenderebbe circa 40 prodotti, vediamo che in realtà compaiono più versioni dello stesso prodotto. A seconda della categoria e del prodotto, possiamo avere forse anche una decina di versioni diverse, o configurazioni diverse, ciascuna certificata separatamente. In pratica, se togliamo le diverse versioni e configurazioni dello stesso prodotto, arriviamo a poche centinaia di prodotti certificati in tutto.
Non tutti i prodotti e non tutte le versioni di un vendor sono certificate
Da questo elenco possiamo poi ricavare altre informazioni interessanti: la prima è che non tutti i prodotti e non tutte le versioni di un vendor sono certificate. La scelta di seguire un processo così lungo e costoso, porta a ponderare bene l’investimento. Si vede facilmente che in moltissimi casi i prodotti certificati non sono all’ultima versione (che magari potrebbe avere un processo di certificazione in corso, ma non è assolutamente detto).
Non è infrequente che, in contesti dove è richiesto di utilizzare prodotti certificati, ci si debba accontentare di prodotti e versioni che non sono certo il meglio disponibile sul mercato, semplicemente perché sono il meglio certificato.
Il livello di assurance
La seconda informazione interessante è data dal livello di assurance, che si trova nella colonna “Compliance” come EAL e che va da 1 (il più basso) fino a 7 (il più alto). Si vede subito che, seppure molti prodotti siano ad un livello da EAL4 in su (già piuttosto alto), molti altri sono ad un EAL 1 o 2. Vale la pena di chiedersi, in termini di garanzie fornite all’utente finale, quanto una certificazione di quel livello dia effettivamente delle garanzie significative, e quanto non sia invece una risposta a requisiti normativi posti dai pochi mercati verticali in cui queste certificazioni sono effettivamente richieste.
La scarsa percezione del valore dei Common Criteria
Infine, vediamo che la maggior parte dei prodotti certificati si concentra in poche categorie, fra cui i chip per smart card e TPM la fanno da padroni, seguiti dai dispositivi di rete. Sono componenti e dispositivi utilizzati ampiamente in contesti in cui la certificazione è un requisito normativo. Il mercato più generale della cybersecurity non sembra invece aver percepito finora un grande valore nei Common Criteria, o meglio: non ha percepito un valore che giustificasse i costi, i tempi e le complessità di questo processo di certificazione. Non che il problema di certificare un prodotto harware o software dal punto di vista della sicurezza sia in sé sia semplice. Si deve considerare prima di tutto che qualsiasi “semplificazione” nei processi di certificazione, viene generalmente utilizzata per ottenere certificazioni formalmente corrette ma nella sostanza quanto meno impegnative possibile per chi la deve sostenere. Da un punto di vista operativo poi, se verificare l’assenza di vulnerabilità in un prodotto, anche con la collaborazione del vendor, fosse una cosa semplice, i grossi vendor farebbero internamente queste verifiche, quantomeno per risparmiarsi i costi di gestione e di immagine delle patch di sicurezza. Invece, anche prodotti come i sistemi operativi Windows (che compaiono nella lista di quelli certificati) presentano ogni anno diverse vulnerabilità di sicurezza. In effetti, non è stato infrequente che vulnerabilità di un prodotto in versione non certificata venissero riscontrate uguali nel prodotto certificato.
Le sfide persistenti nella certificazione dei prodotti di sicurezza
Cosa aggiunge a tutto questo l’EUCC? Allo stato attuale, apparentemente molto poco. Sia lo schema che il Regolamento di esecuzione sembrano focalizzati principalmente sull’armonizzazione del mercato europeo dei prodotti certificati, armonizzazione sicuramente utile ma che permette principalmente di superare gli accordi di mutuo riconoscimento che già esistevano. Inoltre, fra i tenti temi di assurance affrontati dai Common Criteria, c’è una focalizzazione sulla famiglia “AVA_VAN”, ovvero l’analisi (ricerca) delle vulnerabilità. Entrambi poi sono al momento focalizzati su “smart card e dispositivi simili” e “dispositivi hardware con security boxes”, ambiti in cui, come visto, i Common Criteria sono già ampiamente utilizzati. Per quanto riguarda le altre tipologie di prodotto, è difficile immaginare che un utente provi a richiedere volontariamente una certificazione ai propri fornitori, limitando drammaticamente le proprie opzioni, come anche che qualche vendor si sottoponga volontariamente ad un processo così oneroso per un ipotetico “vantaggio competitivo”. Eppure, sicuramente tanti concordano che avere la possibilità di avere prodotti certificati, che quindi diano garanzie oggettive sulla gestione della sicurezza nello sviluppo e nel ciclo di vita complessivo, sarebbe una bella tranquillità per gli utenti e un ottimo modo per poter dimostrare conformità alle normative.
Esistono alternative? Il problema è difficile in sé, ma prodotti in settori specifici possono essere certificati secondo schemi diversi, come ISA/IEC 62443 per i sistemi di controllo industriali. I Common Criteria sono però certamente quelli applicabili in modo più ampio.
Normative per l’adozione delle certificazioni di sicurezza: una strada in salita
Proprio le normative sembrano essere, tanto per cambiare, l’unica leva che può forzare un’adozione diffusa di una certificazione di prodotto. Norme in fase di emanazione, come l’AI Act, o ancora di più il Cyber Resilience Act, potranno imporre la certificazione dei prodotti o dei servizi a maggior rischio. La strada, però, è tutta in salita: le norme non fanno sparire i tempi, i costi e le complessità attuali. Non promettono bene neanche i problemi recenti, a livello nazionale ed europeo, nella predisposizione di laboratori di verifica che debbano servire un mercato ampio. Il vero impegno per rendere efficaci i Common Criteria al di fuori del mercato ristretto in cui sono stati finora utilizzati, è quindi rendere il processo e i tempi abbordabili anche ad aziende medio-piccole, in modo da non diventare una penalizzazione, invece che un vantaggio, per il mercato europeo.
Note
[1] L’elenco https://en.wikipedia.org/wiki/ITSEC è alimentato da più autorità nazionali, proprio grazie al meccanismo di riconoscimento reciproco e, seppure non perfettamente allineato, comprende una bona percentuale dei prodotti certificati da singole autorità nazionali. Per confronto, il riferimento italiano è l’elenco mantenuto dall’OCSI https://www.ocsi.gov.it/index.php/elenchi-certificazioni/prodotti-certificati.html
