Le Certificazioni Common Criteria rappresentano un punto di riferimento fondamentale nel panorama della sicurezza informatica. Nate con l’obiettivo di fornire un quadro standardizzato e riconosciuto a livello internazionale per la valutazione della sicurezza dei prodotti IT, queste certificazioni sono diventate un must per le aziende che puntano a garantire la massima protezione ai propri sistemi e dati.
Tuttavia, come in ogni processo complesso e articolato, esistono limiti e sfide da affrontare. L’evoluzione del settore ha portato all’introduzione dei Protection Profile, strumenti progettati per rispondere alle esigenze specifiche di determinati scenari operativi. Ma come si distinguono dai collaborative Protection Profile? E soprattutto, quale sarà il futuro delle Certificazioni Common Criteria in un mondo digitale in costante evoluzione?
Indice degli argomenti
L’origine delle Certificazioni Common Criteria
Gli standard Common Criteria (Standard ISO 15408 — Information technology — Security techniques — Evaluation criteria for IT security), hanno origine da un progetto internazionale iniziato nel 1993 e durato circa 5 anni che coinvolgeva NIST e NSA per gli USA e svariate organizzazioni per la sicurezza in Canada, Francia, Germania, Olanda e Regno Unito. Per lo sviluppo dei criteri fu istituito un gruppo di lavoro (anch’esso internazionale) denominato Common Criteria Editorial Board (CCEB).
L’obiettivo era quello di sviluppare una comune metodologia per la valutazione della sicurezza nel mondo dell’Informatica che fosse applicabile in campo internazionale e superasse i limiti degli standard al momento in vigore (TCSEC, ITSEC, …).
I Common Criteria (CC) sono diventati lo standard di riferimento per le certificazioni di sicurezza dei prodotti ICT grazie a degli accordi internazionali di mutuo riconoscimento delle certificazioni.
Tra questi, il più rilevante è il Common Criteria Recognition Arrangement (CCRA) che vede coinvolti circa 30 Paesi membri di cui 18 sono emittenti ed utilizzatori dei certificati, mentre altri 12 sono solo utilizzatori dei certificati. Il CCRA prevede il mutuo riconoscimento delle certificazioni fino al livello EAL2.
Oltre al CCRA, esiste un altro accordo di mutuo riconoscimento delle certificazioni di sicurezza basate sui CC, il Senior Officials Group Information Systems Security (SOG-IS), che include 17 Paesi membri europei ed prevede il mutuo riconoscimento dei certificati fino al livello EAL4.
Quest’ultimo sarà sostituito dall’EUCC, lo schema europeo di certificazione e prodotti ICT, che ha recepito lo schema SOG-IS.
I CC si sono rilevati un ottimo standard per la certificazione della sicurezza dei prodotti ICT perché permettono una convalida formale della sicurezza di un prodotto e si possono applicare a tutti i prodotti ICT, siano essi hardware o software.
I limiti delle certificazioni CC
Le certificazioni CC presentano però dei limiti legati soprattutto ai tempi e ai costi delle valutazioni di sicurezza che crescono al salire del livello di assurance richiesto.
Inoltre, l’attuale sistema di valutazione dei CC può essere soggetto a interpretazioni da parte del valutatore che esegue la valutazione o dell’Autorità che gestisce lo schema nazionale e questo può portare a non avere delle valutazioni ripetibili e/o oggettive e quindi confrontabili. Tale aspetto è maggiormente rilevante per le valutazioni di livello elevato dove non è previsto il mutuo riconoscimento da parte dei Paesi Membri del CCRA.
Infine, non meno importante, un’altra critica mossa ai CC è il fatto che le tali valutazioni si concentrano principalmente sulle funzionalità descritte nel Security Target fornito dal fornitore del prodotto e verificano se il prodotto ICT oggetto di valutazione fornisce tutte le funzioni specificate appunto nel Security Target.
L’introduzione dei Protection Profile
Questi limiti hanno spinto molti Stati Membri del CCRA a introdurre degli schemi di certificazione della sicurezza personalizzati, sempre basati sui CC, ma che o semplificano tutto il processo di valutazione per renderlo meno lungo e costoso oppure lo rendono maggiormente oggettivo e ripetibile attraverso l’introduzione obbligatoria dei Protection Profile (PP).
Tra questi va evidenziato lo schema di certificazione americano gestito dal National Information Assurance Partnership (NIAP), nato da una partnership tra il National Institute of Standards and Technology (NIST) e la National Security Agency (NSA). Il NIAP opera prevalentemente il Dipartimento delle Difesa americana e certifica i prodotti ICT definiti come Commercial Off The Shelf (COTS) da utilizzare nei sistemi di sicurezza nazionale.
Dagli inizi del 2013, il NIAP non accetta più valutazioni generiche EAL, ma richiede che i prodotti ICT siano valutati rispetto a dei Protection Profile (PP) da questa certificati. Tale approccio rappresenta un vincolo per il mutuo riconoscimento del CCRA in quanto, anche se disponibili dei PP certificati e pubblicati sul CC Portal, non è sempre detto che il PP richiesto dal NIAP sia tra questi. D’altra parte, tutti i produttori di prodotti ICT hanno un elevato interesse ad essere inclusi nella lista gestita dal NIAP per poter avere accesso al mercato americano
Questa situazione ovviamente ha messo in crisi il sistema di mutuo riconoscimento introdotto con il CCRA e, d’altro canto, un’uscita degli Stati Uniti dal CCRA avrebbe penalizzato in maniera significativa il mercato delle certificazioni di sicurezza dei prodotti ICT (la maggior parte dei produttori di tali prodotti sono americani) decretando la fine del CCRA stesso.
Per tale ragione, nel settembre 2012, sotto la spinta del NIAP, il Common Criteria Management Committee (CCMC), Comitato responsabile per la gestione del CCRA, ha predisposto un documento che revisiona l’accordo di mutuo riconoscimento introducendo due concetti innovativi quali gli International Technical Community (iTC) e i collaborative Protection Profile (cPP).
Differenze tra Protection Profile e collaborative Protection Profile
Il Protection Profile (PP) è un documento, generalmente creato da un’organizzazione (es. vendor, comunità di utenti, autorità nazionale,…) che definisce un insieme di requisiti e funzioni di sicurezza per una particolare classe di prodotti/sistemi (es. apparati di rete, sistemi operativi, dispositivi mobili, hardcopy device,…).
Dal punto di vista del produttore del prodotto l’utilizzo di questo documento può essere duplice:
- esso può decidere di implementare e certificare prodotti che rispettano le specifiche di sicurezza imposte da uno o più PP;
- il documento può essere inteso come un template per generare un nuovo PP sulle basi dei requisiti di sicurezza espressi per la classe di prodotti, magari ampliandone lo spettro.
Dal punto di vista dell’utente, invece, un PP può essere utilizzato come criterio per selezionare il tipo particolare di prodotto che soddisfa maggiormente la sua particolare esigenza, sulla base di quanto in esso espresso (requisiti di sicurezza).
Dal punto di vista strutturale un PP è per molti versi analogo ad un Security Target, in particolare per quanto riguarda la descrizione dell’Ambiente di sicurezza, degli Obiettivi di sicurezza, dei Requisiti di sicurezza IT e le motivazioni legate a questi aspetti.
Quello che invece non è previsto in un PP riguarda le parti direttamente connesse con il prodotto oggetto della valutazione, come il sommario delle specifiche di questo, la conformità ad un eventuale altro PP e le motivazioni che dimostrano l’adeguatezza delle funzioni di sicurezza e garanzia che permettono di soddisfare i requisiti di sicurezza.
I due documenti, inoltre, potrebbero essere utilizzati congiuntamente: un Security Target potrebbe essere dichiarato conforme ad un PP, ereditandone direttamente i requisiti funzionali e di garanzia. In questi casi è possibile solo fare riferimento al PP e dettagliare le eventuali differenze con questo.
I PP possono essere certificati in accordo a quanto previsto dallo standard CC e, in tal caso, sono pubblicati sul CC Portal che è il sito ufficiale del CCRA.
Ma quali sono i vantaggi di una valutazione rispetto ad un PP da quella generica CC chiamata EAL?
Le certificazioni rispetto ad un PP offrono degli indubbi vantaggi rispetto ad una generica valutazione CC e superano, se non totalmente, molti dei limiti mostrati in precedenza.
Tra le principali differenze si evidenziano:
- in una valutazione conforme ad un PP, tutti i fornitori dello stesso tipo di prodotto devono aderire agli stessi requisiti di sicurezza, mentre in quelle EAL i fornitori scelgono individualmente quali requisiti di sicurezza rivendicare, causando a volte incoerenze tra prodotti simili;
- i metodi di valutazione utilizzati per le valutazioni PP sono approvati dal CCRA (la maggior parte dei PP sono generalmente a livello EAL1), mentre per le valutazioni EAL il riconoscimento del CCRA è limitato in quanto si arriva al mutuo riconoscimento solo le valutazioni fino a livello EAL2;
- le valutazioni PP usano un approccio oggettivo nei metodi di valutazione perché il PP indica tutti i requisiti funzionali che il prodotto deve soddisfare, mentre nelle valutazioni EAL i requisiti funzionali del prodotto sono scelti in maniera soggettiva dal fornitore;
- i risultati di una valutazione PP sono pertinenti, applicabili e ripetibili in quanto usano lo stesso minacce standard e gli requisiti funzionali di sicurezza raccolti in un PP, mentre per le valutazioni EAL i risultati non sono ripetibili tra i prodotti della stessa categoria sviluppati da fornitori diversi;
- i PP sono sviluppati generalmente da comunità tecniche riconosciute dal CCRA, mentre nelle valutazioni EAL i requisiti sono generici e definiti dai singoli fornitori;
- le minacce che afferiscono al prodotto sono definite generalmente dalle agenzie di sicurezza internazionali, mentre nelle valutazioni EAL le minacce sono identificate dopo che il fornitore ha mappato la funzionalità del prodotto in base ai Common Criteria e possono produrre requisiti diversi e una minore sicurezza
Da quanto scritto si evince chiaramente che l’utilizzo di un PP risolve molti dei limiti dei CC, ma richiede nel contempo che i PP, per poter essere efficaci e garantire il mutuo riconoscimento, devono avere alla base un vasto consenso, soprattutto da parte delle Autorità che gestiscono gli schemi di certificazione nazionali.
Cosa sono i collaborative Protection Profile (cPP)
Un cPP è un Protection Profile per una determinata tecnologia definito da una International Technical Community (iTC) composta da esperti di CC e dell’area tecnologica di riferimento e sponsorizzata da uno o più membri del CCRA. L’intento è quello di risolvere l’eterogeneità dei PP specifici dei governi, definendo al contempo requisiti e metodologie di test migliori attraverso il coinvolgimento degli esperti del settore. Durante lo sviluppo di un cPP, tutti i Paesi membri CCRA sono invitati a rilasciare dichiarazioni di posizione informali che indicano se la nazione intende approvare o meno il cPP. Il processo di sviluppo del cPP è stato definito dal CC Development Board.
Oltre al processo cooperativo, l’altra caratteristica distintiva di un cPP è che di solito non specificano un livello di assurance EAL perché i cPP si concentrano sulla definizione di requisiti funzionali di sicurezza (Security Functional Requirements – SFR) adeguati per un determinato prodotto/tecnologia. In questo caso, la distinzione importante da comprendere è che gli SFR di un cPP descrivono le funzionalità di sicurezza di un prodotto, mentre i Security Assurance Requirements (SAR) definiscono il livello delle attività di valutazione (CC Parte 3) richiesto durante il processo di valutazione.
Come detto prima, i cPP sono sviluppati da International Technical Community (iTC) riconosciute dal CCRA e che includono esperti di CC, esperti della tecnologia di riferimento del cPP, utenti del prodotto, ma soprattutto rappresentanti delle Autorità dei Paesi membri del CCRA. Questi ultimi, assumono un ruolo molto attivo nello sviluppo del cPP proprio nell’ottica di garantire il mutuo riconoscimento delle valutazioni. A titolo esemplificativo, lo sviluppo di un cPP può essere richiesto solo da uno Paese membro del CCRA.
Conclusioni
I Common Criteria si sono rilevati un ottimo standard per la certificazione della sicurezza dei prodotti ICT perché permettono una convalida formale della sicurezza di un prodotto e si possono applicare a tutti i prodotti ICT, siano essi hardware o software. Nel contempo però, hanno rivelato dei limiti dovuti, paradossalmente, alla elevata flessibilità della loro applicazione.
L’approccio basato sull’utilizzo di Protection Profile e di collaborative Protection Profile, supera i limiti mostrati dallo standard e permette di avere delle valutazioni oggettive e ripetibili, pur mantenendo la rigorosità richiesta dallo standard.
Non è un caso quindi che lo schema europeo basato sui CC, l’EUCC, prevede che le valutazioni di prodotti ICT a livello “high” possono essere fatte solo se si applicano i requisiti di un dominio tecnico (simile a un PP) o di un Protection Profile certificato.
Sulla base dell’esperienza del CCRA, è evidente che le certificazioni basate sui PP potranno avere successo solo se i PP saranno sviluppati e certificati con il coinvolgimento di tutti gli attori in gioco e con un ruolo attivo da parte delle Autorità Nazionali che devono garantire il mutuo riconoscimento delle certificazioni. Solo in questo modo sarà possibile sviluppare un mercato di massa di tali certificazioni e aumentare il livello di sicurezza delle infrastrutture ICT dei vari Paesi nel mondo.
