I CONCETTI DI BASE

Nel limitato spazio disponibile non sarebbe possibile riportare una descrizione anche sommaria delle varie parti che compongono i Common Criteria (denominati CC nel seguito per brevità). Quand'anche ci si provasse, peraltro, si sarebbe obbligati ad introdurre un gran numero definizioni che non potrebbero essere diffusamente illustrate, correndo così il rischio di produrre una sintesi poco chiara nella quale gli elementi veramente importanti che sono alla base di questi criteri potrebbero risultare poco evidenti. In questo paragrafo ci si limiterà quindi a descrivere l'approccio secondo il quale i CC sono stati sviluppati, mirando principalmente a fornire quegli elementi informativi che consentono una adeguata comprensione del successivo paragrafo dedicato ad una descrizione dei vantaggi e degli svantaggi di questi criteri.

La filosofia che è alla base dei CC è stata ripresa dai precedenti criteri europci ITSEC (Information Technology Security Evaluation Criteria) che per primi l'hanno introdotta. In base a tale filosofia non ha senso verificare se un sistema/prodotto è sicuro se non si specifica:

• "sicuro" per fare cosa (obiettivi di sicurezza)

• "sicuro" in quale contesto (ambiente di sicurezza)

• "sicuro" a fronte di quali verifiche (requisiti di assurance).

Tra parentesi sono stati indicati alcuni termini che sono utilizzati nell'ambito dei CC e che consentono di esprimere nel seguente modo lo scopo di una valutazione secondo tali criteri: offrire garanzie, che vengono prodotte dal soddisfacimento dei requisiti di assurance e che risultano crescenti con il livello di valutazione, sulla capacità del sistema/prodotto di soddisfare i propri obiettivi di sicurezza nell'ambiente di sicurezza per esso ipotizzato.

Un obiettivo di sicurezza viene definito, secondo i CC, come l'intenzione di contrastare una minaccia o quella di rispettare leggi, regolamenti o politiche di sicurezza preesistenti. Il conseguimento degli obiettivi avviene attraverso l'adozione di misure di sicurezza tecniche (funzioni di sicurezza) e non tecniche (fisiche, procedurali e relative al personale).

L'ambiente di sicurezza viene descritto in termini di:

- uso ipotizzato del sistema/prodotto (applicazioni, utenti, informazioni trattate ed altri beni con specifica del relativo valore)

- ambiente di utilizzo (misure di sicurezza non tecniche, collegamento con altri apparati ICT)

- minacce da contrastare, specificando caratteristiche dell'attaccante (conoscenze, risorse disponibili e motivazione), metodi di attacco (citando, tra l'altro, lo sfruttamento di eventuali vulnerabilità note del sistema/prodotto ICT), beni colpiti

- politiche di sicurezza dell'Organizzazione.

Le verifiche previste durante il processo di valutazione mirano ad accertare che siano stati soddisfatti, da parte del sistema/prodotto, del suo sviluppatore e del valutatore, opportuni requisiti di assurance che diventano sempre più severi al crescere del livello di valutazione. I CC definiscono una scala di 7 livelli di valutazione (EAL1, EAL2, .... EAL7) o livelli di assurance, precisando, per ogni livello di tale scala uno specifico insieme di requisiti di assurance. Il livello EAL1, cui corrisponde il livello di sicurezza più basso, non ha corrispondenti nei precedenti criteri di valutazione.

Le verifiche, eseguite in base ai requisiti di assurance del livello di valutazione considerato, hanno lo scopo di fornire garanzie circa:

- l'idoneità delle funzioni di sicurezza a soddisfare gli obiettivi di sicurezza del sistema/prodotto;

- l'assenza di errori nel processo che dalle specifiche iniziali di sicurezza (ambiente e obiettivi di sicurezza) porta alla pratica realizzazione delle funzioni di sicurezza (errori di interpretazione delle specifiche tecniche, errori di programmazione, ecc);

- l'adeguatezza delle procedure di sicurezza previste per la consegna e per l'installazione del sistema/prodotto (per evitare che il sistema/prodotto che perviene all'utente finale possa differire, magari anche di poco, da quello sottoposto a valutazione/certificazione), la chiarezza dei manuali d'uso e d'amministrazione (questi ultimi potrebbero infatti indurre gli utilizzatori a comportamenti che introducono vulnerabilità nell'utilizzo di un prodotto/sistema dotato di funzioni di sicurezza del tutto idonee e realizzate senza errori), il supporto che lo sviluppatore si impegna a fornire a chi usa il sistema o prodotto per rimediare ad eventuali vulnerabilità emerse dopo la valutazione

Con riferimento al punto 2) può essere interessante precisare che le garanzie circa l'assenza di errori nel processo di realizzazione delle funzioni di sicurezza non vengono ottenute solamente ricercando direttamente gli errori stessi (analizzando la documentazione presentata dal richiedente della valutazione e sottoponendo il sistema/prodotto a test funzionali e ad attacchi), bensì anche verificando che nel processo di realizzazione sia stato previsto l'impiego di strumenti, metodologie e procedure finalizzati alla riduzione della probabilità di errori.

Al crescere del livello di valutazione:

- vengono richieste specifiche realizzative più dettagliate (ad esempio progetto ad alto livello, progetto a basso livello, codice sorgente)

- il livello di rigore con il quale le specifiche devono essere descritte aumenta (descrizione informale, semiformale, formale).

Il rigore della valutazione, così come nei criteri ITSEC, non viene individuato solo dal livello di valutazione bensì anche da un altro parametro. Infatti per le funzioni che devono essere realizzate con meccanismi probabilistici o di permutazione (password, funzioni hash, etc.), i CC richiedono (a partire da EAL2) che venga specificato un livello minimo di robustezza (SOF - Strength Of Functionality) su una scala a tre valori (basic, medium, high).

Le funzioni di sicurezza del sistema/prodotto vengono descritte in base ai requisiti cui devono soddisfare. Tali requisiti, denominati requisiti funzionali, così come i già citati requisiti di assurance, devono essere espressi (a meno di possibili eccezioni che occorre comunque giustificare) utilizzando un catalogo di componenti fornito nei CC. Più precisamente il catalogo delle componenti funzionali costituisce la parte 2 dei CC, mentre quello delle componenti di assurance la parte 3. I cataloghi sono strutturati su più livelli gerarchici in modo da raccogliere componenti di tipo omogeneo. A titolo di esempio, per quanto riguarda le componenti funzionali, al livello gerarchico più elevato è previsto un raggruppamento secondo le unidici classi di seguito specificate: Audit, Communication, Cryptographic Support, User Data Protection, Identification and Authentication, Security management, Privacy, Protection of the TOE Security Function, Resource Utilization, TOE Access, Trusted Path/Channels (l'acronimo TOE ricorrente in alcuni nomi di classi funzionali indica il sistema/prodotto ICT da valutare).

Tra i numerosi documenti che il richiedente della valutazione deve/può consegnare ai valutatori, unitamente al sistema/prodotto ICT da valutare, due meritano un particolare cenno. Il primo, denominato Security Target, deve essere obbligatoriamente fornito e rappresenta il documento principale della valutazione. Nel Securuty Target devono essere descritti l'ambiente di sicurezza, gli obiettivi di sicurezza, i requisiti funzionali e di assurance (e quindi il livello di valutazione), la robustezza minima delle funzioni di sicurezza ed una prima descrizione ad alto livello delle funzioni di sicurezza. Quest'ultima sezione non è invece contenuta nel secondo documento, il Protection Profile, che per il resto ha una struttura del tutto simile a quella del Security Target. Il Protection Profile può essere opzionalmente sviluppato con riferimento ad un'intera classe di prodotti (per la quale si lascia la libertà di realizzare le funzioni di sicurezza in un qualsiasi modo che soddisfi i requisiti funzionali) piuttosto che con riferimento ad uno specifico sistema/prodotto ICT (come è il caso, invece, del Security Target). Il Protection Profile, che può essere registrato e anche valutato per verificarne la coerenza interna.

I PRO E I CONTRO

In questo paragrafo verranno descritti i principali vantaggi e svantaggi derivanti dall'applicazione dei CC. In realtà, come apparirà più chiaro nel seguito, gran parte di essi possono essere considerati comuni a tutte le raccolte di criteri di valutazione fin qui sviluppate. Per quanto riguarda i vantaggi si possono citare:

- la verifica, eseguita da una terza parte per la quale viene riconosciuto il possesso di conoscenze specialistiche, che le funzionalità di sicurezza del sistema/prodotto ICT, affiancate alle contromisure non tecniche previste, siano adeguate al soddisfacimento degli obiettivi di sicurezza;

- lo svolgimento di un'azione di contrasto preventivo degli incidenti di sicurezza ICT;

- le maggiori garanzie che i CC offrono rispetto ad altri strumenti di contrasto di tipo preventivo;

- la disponibilità di vasti cataloghi relativamente alle funzionalità di sicurezza ICT e ai requisiti di assurance adottabili;

- la possibilità di esprimere in forma standardizzata requisiti di sicurezza per sistemi e prodotti ICT.

Detto questo riguardo ai vantaggi che l'applicazione dei CC può portare, vediamo ora quelli che possono essere considerati gli svantaggi. Tra questi possiamo citare:

- i lunghi tempi di esecuzione del processo di valutazione/certificazione;

- il costo elevato del processo;

- la perdita della certificazione non appena ci si discosta anche lievemente dalla configurazione certificata.

È opportuno tuttavia precisare subito che i primi due svantaggi si riferiscono alle modalità d'impiego tipiche dei criteri nel contesto della sicurezza nazionale, ossia quando viene previsto un livello di valutazione non inferiore a EAL3. In tali casi, infatti, lo svantaggio citato al punto a) deriva dall'obbligo per chi richiede la valutazione di predisporre una notevole mole di documentazione e dal tempo necessario ai valutatori per analizzare tale documentazione ed eseguire tutte le numerose e complesse azioni che i criteri pongono a loro carico. Conseguenza di questo stato di cose è che non di rado quando il processo termina è già disponibile una nuova versione del sistema/prodotto ICT. Inoltre possono nascere difficoltà relativamente all'utilizzazione di prodotti certificati nelle architetture hw/sw più recenti.

Per quanto riguarda il punto b) si può dire che il costo elevato risulta una diretta conseguenza, oltre che dei lunghi tempi di esecuzione, anche delle risorse non trascurabili dal punto di vista sia qualitativo sia quantitativo che durante l'esecuzione del processo è necessario impegnare.

Se invece vengono utilizzati i primi livelli di valutazione, il che può essere adeguato in molte situazioni di pratico interesse, gli svantaggi descritti ai punti a) e b) tendono a scomparire. Al riguardo si può peraltro ricordare che proprio con i CC è stato aggiunto un livello iniziale di valutazione che non trova corrispondenze nei precedenti criteri di valutazione e che è caratterizzato da tempi e costi alquanto contenuti. Quando tale livello viene utilizzato la collaborazione richiesta al soggetto che ha sviluppato l'oggetto della valutazione è praticamente nulla e risulta quindi possibile valutare e certificare anche componenti di un sistema ICT per le quali risulta molto difficile ottenere informazioni progettuali che consentano la scrittura della documentazione prevista ai livelli di valutazione medi e alti. Ovviamente in tale caso diviene più difficile per i valutatori individuare eventuali vulnerabilità, dato che non dispongono più (o ne dispongono in misura alquanto limitata) di informazioni, normalmente non accessibili fuori dell'ambiente di sviluppo (ad esempio i valutatori possono avere accesso al codice sorgente di un prodotto commerciale), relative alla struttura interna delle funzioni di sicurezza. Tuttavia la certificazione al livello minimo EAL1 già garantisce l'eliminazione (tipicamente mediante l'installazione di apposite patch) di eventuali vulnerabilità dell'oggetto della valutazione che siano già note. Dal livello EAL2 in su, il valutatore tenterà anche di violare l'oggetto della valutazione utilizzando tecniche di attacco diverse da quelle che consentono di sfruttare le vulnerabilità già note.

Riguardo al punto c) è opportuno invece sottolineare che una delle implicazioni più dirette che crea notevoli difficoltà è l'impossibilità di installare le patch senza prevedere una nuova certificazione del sistema/prodotto ICT. Quest'ultima può essere però resa relativamente veloce e non troppo costosa (anche a livelli di valutazione medi ed alti) seguendo le indicazioni relative al mantenimento nel tempo della certificazione (tali indicazioni nella prima versione dei CC erano presenti in un'apposita classe di assurance denominata Maintenance of assurance mentre ora sono disponibili in un documento separato sviluppato ai fini del mutuo riconoscimento internazionale). In taluni casi, peraltro, ossia quando mediante una opportuna analisi si sia potuto stabilire che gli aggiornamenti hw/sw non possono compromettere il buon funzionamento delle parti più critiche del sistema/prodotto ICT, può essere sufficiente una integrazione della documentazione di valutazione, piuttosto che una riesecuzione di attività da parte dei valutatori.

CONCLUSIONI

(Ndr: ripreso da "I quaderni di Telema" della rivista Media Duemila di giugno 2004)