Fattori critici per lo sviluppo delle certificazioni di sicurezza secondo i Common Criteria
Inserito da Redazione il Gio, 2006-06-22 06:28
Certificazioni professionali | Giugno 2006 | ISCOM | Security
0622-CC
Per gentile concessione di ISCOM
ripubblichiamo il presente articolo, già apparso su Divulgazione,
la rivista elettronica di comunicazioni, note, recensioni e notizie di
ISCOM. La versione originale è disponibile in formato pdf
(83 K).
L’articolo è stato scritto da Giovanni Elia, Sandro Mari, Renato Baldelli assistenti abilitati OCSI
Il forte incremento dell'informatizzazione del business, ma soprattutto l'enorme capacità di scambiarsi informazioni, ha fatto nascere nelle aziende e nelle pubbliche amministrazioni l'esigenza di attrezzarsi con strumenti di difesa per preservare l'integrità dei propri sistemi e della propria immagine. Troppo spesso il problema della "sicurezza" viene affrontato quando il danno è già stato fatto. Questo causa lesioni alla propria immagine e maggiori spese nella riorganizzazione delle attività. Per una buona e corretta strategia di sicurezza a protezione di dati ed informazioni, non è sufficiente la sola tecnologia, ma è necessario definire anche una strategia nell'organizzazione. L'introduzione di strumenti di difesa e di gestione diventa quindi un investimento obbligato che offre una forte copertura del rischio, facendolo diminuire in modo considerevole e favorendo la propria tranquillità e la fiducia dei propri clienti/utenti.
La necessità di avere delle garanzie, sui prodotti e i sistemi usati, che siano in grado di ottenere adeguati obiettivi di sicurezza è cominciata già dal 1985 con gli "Orange Book" - TCSEC. Da allora vari governi hanno dato vita ad iniziative focalizzate allo sviluppo di criteri di valutazione della sicurezza, costruiti sui concetti evidenziati dai TCSEC; questo ha portato alla redazione degli ITSEC (1991) in Europa, dei CTCPEC (1993) in Canada e dei Federal Criteria (1993) negli Stati Uniti. Tutti questi standard però non riuscivano a soddisfare l'esigenza di una comune metodologia di valutazione e non fornivano risultati sempre confrontabili. Per ovviare a tale situazione nel 1993 i rappresentanti degli Stati Uniti d'America, Canada, Francia, Germania, Olanda e Regno Unito, in collaborazione con l'ISO (International Organization for Standardization), si sono accordati per lo sviluppo di uno standard internazionale di valutazione della sicurezza in ambito informatico, per facilitare una congruente valutazione di prodotti e sistemi IT. Ciò ha portato nel 1997 al rilascio della versione 1.0 dei Common Criteria (CC) -ISO/IEC 15408. Essi costituiscono pertanto uno strumento per valutare in maniera univoca la sicurezza di un sistema hardware o software e quindi consentono la pianificazione e la realizzazione di soluzioni volte al raggiungimento o al mantenimento di un determinato livello di sicurezza. Inoltre, stanno diventando un’ utile guida per la creazione e lo sviluppo di prodotti e sistemi, anche commerciali, con funzioni di sicurezza IT, fornendo delle garanzie basate su valutazioni (investigazioni attive) dei prodotti e dei sistemi in ambito IT. Di non secondaria importanza è inoltre il fatto che la validità della documentazione e dei risultati ottenuti dalla valutazione possono essere attestati soltanto da valutatori esperti, accrescendo così l'efficacia, la profondità e la severità di giudizio della valutazione stessa. Il recepimento da parte dell'ISO ha fatto si che i Common Criteria siano rapidamente diventati lo standard mondiale per le specifiche di sicurezza e per le valutazioni. Ciò, unitamente al largo riconoscimento dei risultati delle valutazioni, fornisce benefici a tutte le parti, portando ad una più ampia scelta di prodotti valutati, ad una più grande conoscenza dei requisiti da parte dei consumatori e ad un maggior accesso ai mercati da parte degli sviluppatori. Infatti, la certificazione dei risultati delle valutazioni fornisce una solida base per garantire che le misure di sicurezza siano appropriate per contrastare le minacce e che le stesse siano implementate in maniera opportuna; anche se, in ogni caso, è bene ricordare che non esiste una garanzia assoluta di sicurezza, per cui il termine "garanzia" dovrebbe essere sempre visto in relazione al particolare insieme di minacce e ipotesi ambientali che gravano sull'ODV (Oggetto Della Valutazione), come è chiamato nella terminologia dei Common Criteria il sistema o prodotto sottoposto alla valutazione. Un aspetto fondamentale del modello Common Criteria è che esso fornisce una netta separazione di ruoli fra valutatori e certificatori. I certificati, infatti, vengono rilasciati basandosi sui vari schemi nazionali, definiti e gestiti da strutture statali, ciò assicura valutazioni indipendenti, effettuate da Laboratori di Valutazione accreditati dagli organi certificatori. In Italia l'ente di Certificazione/Accreditamento è, per prodotti e sistemi che trattano dati classificati nel contesto della sicurezza interna ed esterna dello Stato, l’ANS/UCSi (Autorità Nazionale per la Sicurezza/Ufficio Centrale per la Sicurezza), da cui attualmente sono accreditati 5 Centri di Valutazione (Ce.Va.), dei quali uno presso l’ISCOM (Istituto Superiore delle Comunicazioni e delle Tecnologie dell'Informazione). In tutti i contesti non coperti dal precedente Schema, l’organismo che si occupa di Certificazione/Accreditamento è l'OCSI (Organismo di Certificazione della Sicurezza Informatica), che è una struttura dell'ISCOM e che è il solo ad avere il potere di accreditare i Laboratori di Valutazione.Questi ultimi lavorano sempre a stretto contatto e sotto la sorveglianza dell'organismo certificatore e sono tenuti a redigere un Piano di Valutazione (PDV), ovvero un documento che descrive le attività che saranno svolte dal Laboratorio per la Valutazione della Sicurezza, durante l'intero processo, tenendo conto dei tempi di esecuzione e delle risorse necessarie. Il compito principale dei Laboratori durante la valutazione è stabilire se, e in che modo, i criteri di valutazione introdotti dai Common Criteria devono essere usati come misure oggettive, per la riduzione dei rischi, quando applicati a funzioni di sicurezza critiche nei sistemi IT.
I Common Criteria sono costituiti da tre parti:
La parte 1 (Introduzione e Modello Generale) definisce i concetti generali e i principi della valutazione della sicurezza IT e presenta un modello generale per la valutazione. Presenta inoltre i costrutti per esprimere gli obiettivi di sicurezza, per selezionare e definire i requisiti di sicurezza e per scrivere le specifiche ad alto livello per i prodotti e i sistemi.
La parte 2 (Requisiti Funzionali di Sicurezza) stabilisce un insieme di componenti funzionali come metodo standard per esprimere i requisiti di sicurezza per i prodotti e sistemi. Tale catalogo è organizzato in classi, famiglie e componenti. I singoli componenti costituiscono i mattoni con i quali costruire una soluzione il cui livello di sicurezza deve essere garantito dal Profilo di Protezione (PP), che è il documento che descrive, per una certa categoria di ODV ed in modo indipendente dalla realizzazione, gli obiettivi di sicurezza, le minacce, l'ambiente ed i requisiti funzionali e di garanzia.
La parte 3 (Requisiti di Garanzia) fornisce un catalogo di un determinato insieme di componenti di garanzia, che può essere usato come metodo standard per esprimere i requisiti di garanzia per prodotti e sistemi IT. Anche questo catalogo è organizzato in classi, famiglie e componenti. Tale parte definisce, inoltre, i criteri di valutazione per i PP e i Traguardi di Sicurezza (TDS), che sono i documenti che specificano le funzioni di sicurezza che l'Oggetto della Valutazione dovrebbe svolgere, l'ambiente operativo in cui l'ODV è destinato ad operare e il livello di garanzia al quale l'ODV viene valutato. Tale catalogo presenta sette livelli di garanzia, chiamati EAL (Evaluation Assurance Level),che sono dei pacchetti predefiniti di componenti di garanzia, usati come scala per la sicurezza di prodotti e sistemi IT. A queste tre parti va aggiunta la metodologia di valutazione dei Common Criteria; ovvero i CEM (Common Criteria Evaluation Methodology). Essi sono un manuale che descrive le azioni che i valutatori devono intraprendere per determinare se i requisiti dei Common Criteria siano stati soddisfatti. In altre parole, descrivono le azioni e le attività che devono essere impiegate da un valutatore per condurre una valutazione; essi sono usati dagli schemi di valutazione nazionali per assicurare un'applicazione congruente dei requisiti dei Common Criteria e costituiscono un importante componente per il mutuo riconoscimento internazionale. Sono divisi in due parti: la prima contiene i principi universali ed un modello generale di valutazione, la seconda fornisce la metodologia dettagliata per le valutazioni dal livello EAL1 a quello EAL4.
Uno degli ostacoli maggiori per lo sviluppo e la diffusione delle certificazioni secondo i Common Criteria è rappresentato dal costo che grava sull'intero processo di certificazione e che incide quindi sui prodotti valutati. La riduzione dei costi della certificazione appare un elemento cruciale. Come fare dunque per tenerli abbastanza bassi da essere ragionevoli, pur ottenendo un prodotto tecnicamente valido? Il punto di partenza è individuare dove essi maggiormente si concentrano nel processo di valutazione. Il costo principale è costituito dalle spese per i consulenti ed i laboratori di valutazione. Riguardo ai primi, è necessario che essi posseggano una formazione tecnica consolidata ed affine con la tecnologia del prodotto da valutare, in modo da ridurre sensibilmente il tempo e l'impegno per la loro formazione specifica sul prodotto. E' d'altronde importante che i valutatori siano presenti sin dalla fase iniziale del processo di sviluppo del prodotto in modo che essi possano cominciare ad apprendere subito le caratteristiche del prodotto stesso. In questo modo, il fornitore ha la possibilità di realizzare un prodotto conforme ai Common Criteria, direttamente durante la sua fase di sviluppo. Questa modalità di procedere risulta congruente con l'orientamento delle grandi aziende di integrare le funzionalità di sicurezza dei prodotti/sistemi già nella fase di progetto: in questo senso la sicurezza diventa una specifica di progetto. L'efficienza in termini di costi del processo di certificazione passa anche attraverso una definizione ragionevole dei requisiti di sicurezza; in questo senso è opportuno effettuare una pre-valutazione per cercare di determinare l'impegno che sarà richiesto per il raggiungimento di un certo EAL. La riduzione di tempi e costi legati alla fase di verifica può essere conseguita automatizzando l'insieme delle prove da eseguire: la minimizzazione del numero dei test manuali, che devono essere riprodotti dal laboratorio, risparmierà tempo durante tale fase della valutazione. Come in un qualunque progetto, il processo di certificazione deve essere condotto con tecniche di project management, allo scopo di gestire le comunicazioni tra i diversi attori coinvolti e, di conseguenza, ridurre i ritardi; ad esempio le comunicazioni tra sviluppatori e valutatori su questioni tecniche riguardanti l'oggetto della valutazione richiedono un tempo, necessario affinché il laboratorio di valutazione acquisisca l'indispensabile conoscenza sul prodotto, che può diventare considerevole. Un altro aspetto da non sottovalutare per velocizzare il processo di certificazione è il grado di comprensione della "filosofia" dei Common Criteria da parte del fornitore/sviluppatore. Quanto più velocemente lo sviluppatore acquisisce familiarità con la metodologia dei Common Criteria, tanto più velocemente le problematiche della valutazione potranno essere risolte. In particolare la comprensione della struttura della documentazione dovrà funzionare da guida per lo sviluppatore.
Sempre in tema di riduzione dei costi un ulteriore elemento da prendere in considerazione è il livello per cui si decide di certificare il prodotto. E' evidente che più basso è il livello di certificazione, minore è il tempo richiesto per l'effettuazione della valutazione e la mole di documentazione che il fornitore deve produrre, quindi minori sono i costi. La domanda è se tutto ciò risulta sufficiente a giustificare la scelta di certificazioni a bassi livelli di garanzia o se questa non abbia ripercussioni negative sulla loro richiesta e diffusione. La risposta a questa domanda introduce un argomento di grande rilievo, che verrà sviluppato successivamente, inerente la possibilità di misurare la sicurezza che si raggiunge con un dato EAL e quindi dare ad un utente la possibilità di comprendere cosa aspettarsi da quel livello di certificazione. Dovrebbe diventare chiaro all'utente che anche un basso livello di garanzia mette al riparo dalle principali vulnerabilità note. Inoltre, l'utente dovrebbe essere sicuramente in grado di apprezzare la differenza che esiste tra un prodotto non certificato ed un altro certificato anche solo al livello EAL1.
Uno degli elementi più critici per lo sviluppo dei Common Criteria è quello di riuscire a misurare l'efficacia dei prodotti valutati a differenti livelli di garanzia in termini di sicurezza; in particolare riuscire a correlare un dato EAL ad un livello di sicurezza riconosciuto dall'utente finale del prodotto. Questa problematica si lega con quella relativa ai pochi dati disponibili per difendere l'efficacia dei Common Criteria e della misurazione oggettiva della sicurezza.
Un altro fattore chiave è quello di riuscire a stabilire delle metriche che permettano di misurare il processo per il raggiungimento di un dato EAL. In particolare, ciò che si dovrebbe misurare è l'efficacia delle attività individuali, sia nel processo di valutazione secondo i Common Criteria, sia nel processo di sviluppo del prodotto. Riguardo al primo aspetto la necessità è quella si sviluppare un metodo per correlare la scoperta delle vulnerabilità con il livello della valutazione e per misurare l'incremento in sicurezza ottenibile conformandosi ai Common Criteria. In ultima analisi bisognereb be riuscire a dimostrare l'esistenza di una proporzionalità tra l'utilizzo di maggiori misure di garanzia e la crescita del livello di sicurezza. Per quanto riguarda la misura ed il miglioramento dell'efficacia dei processi interni di sviluppo del prodotto, questa dovrebbe riguardare la tracciabiltà interna delle falle da cui possono originarsi le vulnerabilità; queste ultime risultano ben visibili dall'esterno, mentre ben più difficile è riuscire a ricondurle ai singoli passi di sviluppo interni del prodotto. E' indubbio comunque che il processo utilizzato dai Common Criteria può costringere i fornitori a modificare il loro ciclo di sviluppo per creare un prodotto finito di qualità migliore. La misurazione dell'impatto dei Common Criteria sulla sicurezza, così come viene percepita dagli utenti, rappresenta quindi uno degli obiettivi principali che i fornitori ed i diversi Schemi Nazionali dovrebbero cercare di perseguire nel settore commerciale. Questo naturalmente è solo uno degli obiettivi, che si accompagna con quello di definire il modo in cui il valore complessivo delle valutazioni Common Criteria possa essere aumentato, per meglio tenere in considerazione i requisiti di sicurezza degli utenti commerciali. E' importante inoltre determinare se l'utenza (sia home che business) sia disposta a pagare un prezzo maggiore per prodotti valutati, qualora essi rispondano meglio alle loro necessità e requisiti. Il problema fondamentale è che le necessità dell'utenza commerciale tendono a differire da quelle della Pubblica Amministrazione. Infatti, la prima ha un interesse maggiore ad acquistare prodotti valutati come sicuri attraverso una qualsiasi forma standard di giudizio o test, non necessariamente quella prevista dai Common Criteria. Un approccio possibile sembra allora quello di introdurre nuovi pacchetti di garanzia, all'interno dei Common Criteria, che vengano incontro ai requisiti dell'utenza commerciale. In realtà, questa è la strada intrapresa con la nuova versione 3.0 dei Common Criteria, ancora in fase di approvazione definitiva. Una particolare considerazione riguarda l'uso specifico dei due documenti fondamentali previsti dai Common Criteria, ovvero il Profilo di Protezione ed il Traguardo di Sicurezza. Un Traguardo di Sicurezza in se stesso, essendo inerente ad un prodotto specifico e costituendo il documento col quale vengono condotte le valutazioni del prodotto, è utile al fornitore esclusivamente per presentare, ai potenziali clienti, una testimonianza indipendente, svolta da terzi, delle affermazioni che egli fa sul suo prodotto. Di contro, il Profilo di Protezione, il quale invece fa riferimento ad una classe di prodotti che devono soddisfare i medesimi requisiti di sicurezza, gioca un ruolo importante nel guidare il futuro corso del mercato della sicurezza.Infatti esso rappresenta un documento anticipatore rispetto al Traguardo di Sicurezza che invece è un'espressione di cosa è già stato implementato. Per cui spingere un venditore verso l'uso di un Profilo di Protezione abbinato ad un Traguardo di Sicurezza, piuttosto che usare il Traguardo di Sicurezza da solo, potrebbe costituire un possibile fattore da perseguire nella strategia di diffusione dei Common Criteria. Sempre in questo contesto appare allora evidente che uno dei maggiori benefici dato dall'intero piano "Common Criteria" diventa quello che, coloro i quali avranno redatto dei Profili di Protezione, saranno i soli in grado di guidare il mercato. Ciò potrà anche essere sfruttato da parte degli utenti per spingere i produttori ad implementare le funzionalità di sicurezza volute, attraverso la scelta di Profili di Protezione che vadano incontro alle loro esigenze. Quale strategia useranno allora gli utenti per ottenere i risultati migliori in questo senso? La comunità degli utenti potrebbe iniziare a produrre Profili di Protezione che richiamino standard a cui tutti i prodotti vanno sostanzialmente incontro, ricevendone in tal modo, come minimo, il beneficio di una valutazione indipendente dei prodotti secondo i profili dettati dai Common Criteria. Nel caso in cui l'utente voglia scrivere un Profilo di Protezione col quale spingere il produttore verso un prodotto con nuove e migliori funzionalità di sicurezza, sarà opportuno che gli standard richiesti non siano troppo onerosi per quest'ultimo; infatti potrebbe non essere in grado di realizzare il prodotto o addirittura scegliere di non provarci nemmeno, ritenendo il costo troppo elevato nei confronti del beneficio percepito. Se non ci sono prodotti che vadano incontro pienamente al Profilo di Protezione, è nell'interes se degli utenti e dei produttori permettere la diffusione e la discussione sui dettagli dei risultati della valutazione. Infatti, dato un prodotto che ha fallito tutti i test e uno che ha fallito, per esempio, un solo test, sempre in riferimento allo stesso Profilo di Protezione, il cliente avrebbe così l'opportunità di scegliere in modo definitivo il prodotto che ha avuto i risultati migliori, anche se entrambi hanno fallito la valutazione globale. Il cliente dovrebbe essere pure a conoscenza dei casi in cui, tra due prodotti valutati, uno superi la valutazione, mentre l'altro la fallisca per un piccolo margine rispetto al primo. In questi casi, infatti, una sostanziale differenza di prezzo o la natura stessa del test che ha avuto esito negativo, potrebbe rendere anche il prodotto che ha fallito la valutazione il miglior acquisto per alcune applicazioni.
Le certificazioni secondo i Common Criteria forniscono un vantaggio aggiuntivo non indifferente rispetto ad altre certificazioni: il riconoscimento internazionale. Esse sono la base per la comparazione dei risultati di valutazioni indipendenti. I Common Criteria sono applicabili alle contromisure di sicurezza ICT implementate in HW, SW e firmware e sono indipendenti dalla tecnologia. Come già evidenziato, essi non sono privi di difetti e necessitano di ulteriori riflessioni e miglioramenti. C'è la necessità di guardare a più efficaci ed efficienti metodologie di valutazione, accettate internazionalmente, nell'ottica di una generale riduzione dei costi. L'aspetto essenziale per lo sviluppo commerciale delle certificazioni Common Criteria passa attraverso l'avvicinamento alle esigenze dell'utenza; in questa direzione è andata, opportunamente, la nuova versione 3.0. Ciononostante, le valutazioni di garanzia Common Criteria non risolvono naturalmente tutti i problemi sulla sicurezza. Esse possono solo assistere la comunità ICT ad avere garanzie che spingano produttori e sviluppatori a trovare soluzioni migliori. Infatti la sicurezza IT è un impegno, sia individuale che dell'organizzazione, costante.
[1] ISO/IEC IS 15408-1 Evaluation Criteria for Information Technology Security - Part 1: Introduction and general model
[2] ISO/IEC IS 15408- 2 Evaluation Criteria for Information Technology Security - Part 2: Security functional requirements
[3] ISO/IEC IS 15408-3 Evaluation Criteria for Information Technology Security - Part 3: Security assurance
[4] CEM1 Common Evaluation Methodology for Information Technology Security Evaluation, Part 1 - Introduction and general model
[5] CEM2 Common Evaluation Methodology for Information Technology Security Evaluation, Part 2 - Evaluation Methodology
[6] Linee Guida Provvisorie dello schema nazionale per la valutazione e certificazione della sicurezza di sistemi e prodotti nel settore della tecnologia dell'informazione http://www.ocsi.gov.it
[7] Il portale dei Common Criteria
[8] Il National Information Assurance Partnership del NIST
Sandro Mari si è laureato nel 2003 in Ingegneria Elettronica presso l’Università degli Studi di Roma “La Sapienza”. Ha collaborato con un’ azienda del settore elettronico ed è stato impegnato nel campo della formazione tecnica superiore. Nell’anno accademico 2004-2005 ha frequentato la Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM; dal settembre del 2005 è stagista presso l’ISCOM e si occupa di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza informatica secondo lo standard Common Criteria, rilasciata dall’ OCSI ( Organismo di Certificazione della Sicurezza Informatica ).
sandromari AT tiscali PUNTO it
Giovanni Elia si è laureato in Ingegneria Elettronica nell’aprile del 2003 presso l’Università di Palermo. Nel 2005 ha conseguito il Diploma della Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM e dal settembre dello stesso anno è impegnato in uno stage presso l’ISCOM, occupandosi di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza secondo lo standard Common Criteria, rilasciata dall’OCSI ( Organismo di Certificazione della Sicurezza Informatica ).
ing.giovannielia AT tiscali PUNTO it
Renato Baldelli si è laureato in Ingegneria Elettronica nel 2004 presso l’Università degli Studi di Roma “La Sapienza”. Nell’anno accadamico 2004/2005 ha frequentato la Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM. Dal settembre del 2005 è stagista presso l’ISCOM, e si occupa di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza informatica secondo lo standard Common Criteria, rilasciata dall’ OCSI (Organismo di Certificazione della Sicurezza Informatica ).
renbal AT libero PUNTO it
L’articolo è stato scritto da Giovanni Elia, Sandro Mari, Renato Baldelli assistenti abilitati OCSI
Sommario
I Common Criteria si avviano a diventare il principale standard internazionale per la certificazione di sicurezza di prodotti e sistemi in ambito ICT. Attualmente essi sono utilizzati in prevalenza per le certificazioni dei prodotti destinati alle Pubbliche Amministrazioni. Questo articolo vuole mettere in evidenza le principali caratteristiche dei Common Criteria, ed individuare alcuni fattori che, andando a ridurre i costi dell'intero processo di certificazione, possono condurre ad una loro maggiore diffusione in ambito commerciale.Abstract
The Common Criteria are becoming the most important international standard for the security certification of the IT products and systems. At present time they are mostly used for the certification of products designed for PA.This article wants to enhance the main Common Criteria characteristics, and to determine some factors that, by reducing costs of the whole certification process, can lead them to a larger diffusion in commercial circles.Il forte incremento dell'informatizzazione del business, ma soprattutto l'enorme capacità di scambiarsi informazioni, ha fatto nascere nelle aziende e nelle pubbliche amministrazioni l'esigenza di attrezzarsi con strumenti di difesa per preservare l'integrità dei propri sistemi e della propria immagine. Troppo spesso il problema della "sicurezza" viene affrontato quando il danno è già stato fatto. Questo causa lesioni alla propria immagine e maggiori spese nella riorganizzazione delle attività. Per una buona e corretta strategia di sicurezza a protezione di dati ed informazioni, non è sufficiente la sola tecnologia, ma è necessario definire anche una strategia nell'organizzazione. L'introduzione di strumenti di difesa e di gestione diventa quindi un investimento obbligato che offre una forte copertura del rischio, facendolo diminuire in modo considerevole e favorendo la propria tranquillità e la fiducia dei propri clienti/utenti.
I Common Criteria
La necessità di avere delle garanzie, sui prodotti e i sistemi usati, che siano in grado di ottenere adeguati obiettivi di sicurezza è cominciata già dal 1985 con gli "Orange Book" - TCSEC. Da allora vari governi hanno dato vita ad iniziative focalizzate allo sviluppo di criteri di valutazione della sicurezza, costruiti sui concetti evidenziati dai TCSEC; questo ha portato alla redazione degli ITSEC (1991) in Europa, dei CTCPEC (1993) in Canada e dei Federal Criteria (1993) negli Stati Uniti. Tutti questi standard però non riuscivano a soddisfare l'esigenza di una comune metodologia di valutazione e non fornivano risultati sempre confrontabili. Per ovviare a tale situazione nel 1993 i rappresentanti degli Stati Uniti d'America, Canada, Francia, Germania, Olanda e Regno Unito, in collaborazione con l'ISO (International Organization for Standardization), si sono accordati per lo sviluppo di uno standard internazionale di valutazione della sicurezza in ambito informatico, per facilitare una congruente valutazione di prodotti e sistemi IT. Ciò ha portato nel 1997 al rilascio della versione 1.0 dei Common Criteria (CC) -ISO/IEC 15408. Essi costituiscono pertanto uno strumento per valutare in maniera univoca la sicurezza di un sistema hardware o software e quindi consentono la pianificazione e la realizzazione di soluzioni volte al raggiungimento o al mantenimento di un determinato livello di sicurezza. Inoltre, stanno diventando un’ utile guida per la creazione e lo sviluppo di prodotti e sistemi, anche commerciali, con funzioni di sicurezza IT, fornendo delle garanzie basate su valutazioni (investigazioni attive) dei prodotti e dei sistemi in ambito IT. Di non secondaria importanza è inoltre il fatto che la validità della documentazione e dei risultati ottenuti dalla valutazione possono essere attestati soltanto da valutatori esperti, accrescendo così l'efficacia, la profondità e la severità di giudizio della valutazione stessa. Il recepimento da parte dell'ISO ha fatto si che i Common Criteria siano rapidamente diventati lo standard mondiale per le specifiche di sicurezza e per le valutazioni. Ciò, unitamente al largo riconoscimento dei risultati delle valutazioni, fornisce benefici a tutte le parti, portando ad una più ampia scelta di prodotti valutati, ad una più grande conoscenza dei requisiti da parte dei consumatori e ad un maggior accesso ai mercati da parte degli sviluppatori. Infatti, la certificazione dei risultati delle valutazioni fornisce una solida base per garantire che le misure di sicurezza siano appropriate per contrastare le minacce e che le stesse siano implementate in maniera opportuna; anche se, in ogni caso, è bene ricordare che non esiste una garanzia assoluta di sicurezza, per cui il termine "garanzia" dovrebbe essere sempre visto in relazione al particolare insieme di minacce e ipotesi ambientali che gravano sull'ODV (Oggetto Della Valutazione), come è chiamato nella terminologia dei Common Criteria il sistema o prodotto sottoposto alla valutazione. Un aspetto fondamentale del modello Common Criteria è che esso fornisce una netta separazione di ruoli fra valutatori e certificatori. I certificati, infatti, vengono rilasciati basandosi sui vari schemi nazionali, definiti e gestiti da strutture statali, ciò assicura valutazioni indipendenti, effettuate da Laboratori di Valutazione accreditati dagli organi certificatori. In Italia l'ente di Certificazione/Accreditamento è, per prodotti e sistemi che trattano dati classificati nel contesto della sicurezza interna ed esterna dello Stato, l’ANS/UCSi (Autorità Nazionale per la Sicurezza/Ufficio Centrale per la Sicurezza), da cui attualmente sono accreditati 5 Centri di Valutazione (Ce.Va.), dei quali uno presso l’ISCOM (Istituto Superiore delle Comunicazioni e delle Tecnologie dell'Informazione). In tutti i contesti non coperti dal precedente Schema, l’organismo che si occupa di Certificazione/Accreditamento è l'OCSI (Organismo di Certificazione della Sicurezza Informatica), che è una struttura dell'ISCOM e che è il solo ad avere il potere di accreditare i Laboratori di Valutazione.Questi ultimi lavorano sempre a stretto contatto e sotto la sorveglianza dell'organismo certificatore e sono tenuti a redigere un Piano di Valutazione (PDV), ovvero un documento che descrive le attività che saranno svolte dal Laboratorio per la Valutazione della Sicurezza, durante l'intero processo, tenendo conto dei tempi di esecuzione e delle risorse necessarie. Il compito principale dei Laboratori durante la valutazione è stabilire se, e in che modo, i criteri di valutazione introdotti dai Common Criteria devono essere usati come misure oggettive, per la riduzione dei rischi, quando applicati a funzioni di sicurezza critiche nei sistemi IT.
Struttura dei Common Criteria
I Common Criteria sono costituiti da tre parti:
La parte 1 (Introduzione e Modello Generale) definisce i concetti generali e i principi della valutazione della sicurezza IT e presenta un modello generale per la valutazione. Presenta inoltre i costrutti per esprimere gli obiettivi di sicurezza, per selezionare e definire i requisiti di sicurezza e per scrivere le specifiche ad alto livello per i prodotti e i sistemi.
La parte 2 (Requisiti Funzionali di Sicurezza) stabilisce un insieme di componenti funzionali come metodo standard per esprimere i requisiti di sicurezza per i prodotti e sistemi. Tale catalogo è organizzato in classi, famiglie e componenti. I singoli componenti costituiscono i mattoni con i quali costruire una soluzione il cui livello di sicurezza deve essere garantito dal Profilo di Protezione (PP), che è il documento che descrive, per una certa categoria di ODV ed in modo indipendente dalla realizzazione, gli obiettivi di sicurezza, le minacce, l'ambiente ed i requisiti funzionali e di garanzia.
La parte 3 (Requisiti di Garanzia) fornisce un catalogo di un determinato insieme di componenti di garanzia, che può essere usato come metodo standard per esprimere i requisiti di garanzia per prodotti e sistemi IT. Anche questo catalogo è organizzato in classi, famiglie e componenti. Tale parte definisce, inoltre, i criteri di valutazione per i PP e i Traguardi di Sicurezza (TDS), che sono i documenti che specificano le funzioni di sicurezza che l'Oggetto della Valutazione dovrebbe svolgere, l'ambiente operativo in cui l'ODV è destinato ad operare e il livello di garanzia al quale l'ODV viene valutato. Tale catalogo presenta sette livelli di garanzia, chiamati EAL (Evaluation Assurance Level),che sono dei pacchetti predefiniti di componenti di garanzia, usati come scala per la sicurezza di prodotti e sistemi IT. A queste tre parti va aggiunta la metodologia di valutazione dei Common Criteria; ovvero i CEM (Common Criteria Evaluation Methodology). Essi sono un manuale che descrive le azioni che i valutatori devono intraprendere per determinare se i requisiti dei Common Criteria siano stati soddisfatti. In altre parole, descrivono le azioni e le attività che devono essere impiegate da un valutatore per condurre una valutazione; essi sono usati dagli schemi di valutazione nazionali per assicurare un'applicazione congruente dei requisiti dei Common Criteria e costituiscono un importante componente per il mutuo riconoscimento internazionale. Sono divisi in due parti: la prima contiene i principi universali ed un modello generale di valutazione, la seconda fornisce la metodologia dettagliata per le valutazioni dal livello EAL1 a quello EAL4.
Sviluppo delle Certificazioni CC
Uno degli ostacoli maggiori per lo sviluppo e la diffusione delle certificazioni secondo i Common Criteria è rappresentato dal costo che grava sull'intero processo di certificazione e che incide quindi sui prodotti valutati. La riduzione dei costi della certificazione appare un elemento cruciale. Come fare dunque per tenerli abbastanza bassi da essere ragionevoli, pur ottenendo un prodotto tecnicamente valido? Il punto di partenza è individuare dove essi maggiormente si concentrano nel processo di valutazione. Il costo principale è costituito dalle spese per i consulenti ed i laboratori di valutazione. Riguardo ai primi, è necessario che essi posseggano una formazione tecnica consolidata ed affine con la tecnologia del prodotto da valutare, in modo da ridurre sensibilmente il tempo e l'impegno per la loro formazione specifica sul prodotto. E' d'altronde importante che i valutatori siano presenti sin dalla fase iniziale del processo di sviluppo del prodotto in modo che essi possano cominciare ad apprendere subito le caratteristiche del prodotto stesso. In questo modo, il fornitore ha la possibilità di realizzare un prodotto conforme ai Common Criteria, direttamente durante la sua fase di sviluppo. Questa modalità di procedere risulta congruente con l'orientamento delle grandi aziende di integrare le funzionalità di sicurezza dei prodotti/sistemi già nella fase di progetto: in questo senso la sicurezza diventa una specifica di progetto. L'efficienza in termini di costi del processo di certificazione passa anche attraverso una definizione ragionevole dei requisiti di sicurezza; in questo senso è opportuno effettuare una pre-valutazione per cercare di determinare l'impegno che sarà richiesto per il raggiungimento di un certo EAL. La riduzione di tempi e costi legati alla fase di verifica può essere conseguita automatizzando l'insieme delle prove da eseguire: la minimizzazione del numero dei test manuali, che devono essere riprodotti dal laboratorio, risparmierà tempo durante tale fase della valutazione. Come in un qualunque progetto, il processo di certificazione deve essere condotto con tecniche di project management, allo scopo di gestire le comunicazioni tra i diversi attori coinvolti e, di conseguenza, ridurre i ritardi; ad esempio le comunicazioni tra sviluppatori e valutatori su questioni tecniche riguardanti l'oggetto della valutazione richiedono un tempo, necessario affinché il laboratorio di valutazione acquisisca l'indispensabile conoscenza sul prodotto, che può diventare considerevole. Un altro aspetto da non sottovalutare per velocizzare il processo di certificazione è il grado di comprensione della "filosofia" dei Common Criteria da parte del fornitore/sviluppatore. Quanto più velocemente lo sviluppatore acquisisce familiarità con la metodologia dei Common Criteria, tanto più velocemente le problematiche della valutazione potranno essere risolte. In particolare la comprensione della struttura della documentazione dovrà funzionare da guida per lo sviluppatore.
Sempre in tema di riduzione dei costi un ulteriore elemento da prendere in considerazione è il livello per cui si decide di certificare il prodotto. E' evidente che più basso è il livello di certificazione, minore è il tempo richiesto per l'effettuazione della valutazione e la mole di documentazione che il fornitore deve produrre, quindi minori sono i costi. La domanda è se tutto ciò risulta sufficiente a giustificare la scelta di certificazioni a bassi livelli di garanzia o se questa non abbia ripercussioni negative sulla loro richiesta e diffusione. La risposta a questa domanda introduce un argomento di grande rilievo, che verrà sviluppato successivamente, inerente la possibilità di misurare la sicurezza che si raggiunge con un dato EAL e quindi dare ad un utente la possibilità di comprendere cosa aspettarsi da quel livello di certificazione. Dovrebbe diventare chiaro all'utente che anche un basso livello di garanzia mette al riparo dalle principali vulnerabilità note. Inoltre, l'utente dovrebbe essere sicuramente in grado di apprezzare la differenza che esiste tra un prodotto non certificato ed un altro certificato anche solo al livello EAL1.
Uno degli elementi più critici per lo sviluppo dei Common Criteria è quello di riuscire a misurare l'efficacia dei prodotti valutati a differenti livelli di garanzia in termini di sicurezza; in particolare riuscire a correlare un dato EAL ad un livello di sicurezza riconosciuto dall'utente finale del prodotto. Questa problematica si lega con quella relativa ai pochi dati disponibili per difendere l'efficacia dei Common Criteria e della misurazione oggettiva della sicurezza.
Un altro fattore chiave è quello di riuscire a stabilire delle metriche che permettano di misurare il processo per il raggiungimento di un dato EAL. In particolare, ciò che si dovrebbe misurare è l'efficacia delle attività individuali, sia nel processo di valutazione secondo i Common Criteria, sia nel processo di sviluppo del prodotto. Riguardo al primo aspetto la necessità è quella si sviluppare un metodo per correlare la scoperta delle vulnerabilità con il livello della valutazione e per misurare l'incremento in sicurezza ottenibile conformandosi ai Common Criteria. In ultima analisi bisognereb be riuscire a dimostrare l'esistenza di una proporzionalità tra l'utilizzo di maggiori misure di garanzia e la crescita del livello di sicurezza. Per quanto riguarda la misura ed il miglioramento dell'efficacia dei processi interni di sviluppo del prodotto, questa dovrebbe riguardare la tracciabiltà interna delle falle da cui possono originarsi le vulnerabilità; queste ultime risultano ben visibili dall'esterno, mentre ben più difficile è riuscire a ricondurle ai singoli passi di sviluppo interni del prodotto. E' indubbio comunque che il processo utilizzato dai Common Criteria può costringere i fornitori a modificare il loro ciclo di sviluppo per creare un prodotto finito di qualità migliore. La misurazione dell'impatto dei Common Criteria sulla sicurezza, così come viene percepita dagli utenti, rappresenta quindi uno degli obiettivi principali che i fornitori ed i diversi Schemi Nazionali dovrebbero cercare di perseguire nel settore commerciale. Questo naturalmente è solo uno degli obiettivi, che si accompagna con quello di definire il modo in cui il valore complessivo delle valutazioni Common Criteria possa essere aumentato, per meglio tenere in considerazione i requisiti di sicurezza degli utenti commerciali. E' importante inoltre determinare se l'utenza (sia home che business) sia disposta a pagare un prezzo maggiore per prodotti valutati, qualora essi rispondano meglio alle loro necessità e requisiti. Il problema fondamentale è che le necessità dell'utenza commerciale tendono a differire da quelle della Pubblica Amministrazione. Infatti, la prima ha un interesse maggiore ad acquistare prodotti valutati come sicuri attraverso una qualsiasi forma standard di giudizio o test, non necessariamente quella prevista dai Common Criteria. Un approccio possibile sembra allora quello di introdurre nuovi pacchetti di garanzia, all'interno dei Common Criteria, che vengano incontro ai requisiti dell'utenza commerciale. In realtà, questa è la strada intrapresa con la nuova versione 3.0 dei Common Criteria, ancora in fase di approvazione definitiva. Una particolare considerazione riguarda l'uso specifico dei due documenti fondamentali previsti dai Common Criteria, ovvero il Profilo di Protezione ed il Traguardo di Sicurezza. Un Traguardo di Sicurezza in se stesso, essendo inerente ad un prodotto specifico e costituendo il documento col quale vengono condotte le valutazioni del prodotto, è utile al fornitore esclusivamente per presentare, ai potenziali clienti, una testimonianza indipendente, svolta da terzi, delle affermazioni che egli fa sul suo prodotto. Di contro, il Profilo di Protezione, il quale invece fa riferimento ad una classe di prodotti che devono soddisfare i medesimi requisiti di sicurezza, gioca un ruolo importante nel guidare il futuro corso del mercato della sicurezza.Infatti esso rappresenta un documento anticipatore rispetto al Traguardo di Sicurezza che invece è un'espressione di cosa è già stato implementato. Per cui spingere un venditore verso l'uso di un Profilo di Protezione abbinato ad un Traguardo di Sicurezza, piuttosto che usare il Traguardo di Sicurezza da solo, potrebbe costituire un possibile fattore da perseguire nella strategia di diffusione dei Common Criteria. Sempre in questo contesto appare allora evidente che uno dei maggiori benefici dato dall'intero piano "Common Criteria" diventa quello che, coloro i quali avranno redatto dei Profili di Protezione, saranno i soli in grado di guidare il mercato. Ciò potrà anche essere sfruttato da parte degli utenti per spingere i produttori ad implementare le funzionalità di sicurezza volute, attraverso la scelta di Profili di Protezione che vadano incontro alle loro esigenze. Quale strategia useranno allora gli utenti per ottenere i risultati migliori in questo senso? La comunità degli utenti potrebbe iniziare a produrre Profili di Protezione che richiamino standard a cui tutti i prodotti vanno sostanzialmente incontro, ricevendone in tal modo, come minimo, il beneficio di una valutazione indipendente dei prodotti secondo i profili dettati dai Common Criteria. Nel caso in cui l'utente voglia scrivere un Profilo di Protezione col quale spingere il produttore verso un prodotto con nuove e migliori funzionalità di sicurezza, sarà opportuno che gli standard richiesti non siano troppo onerosi per quest'ultimo; infatti potrebbe non essere in grado di realizzare il prodotto o addirittura scegliere di non provarci nemmeno, ritenendo il costo troppo elevato nei confronti del beneficio percepito. Se non ci sono prodotti che vadano incontro pienamente al Profilo di Protezione, è nell'interes se degli utenti e dei produttori permettere la diffusione e la discussione sui dettagli dei risultati della valutazione. Infatti, dato un prodotto che ha fallito tutti i test e uno che ha fallito, per esempio, un solo test, sempre in riferimento allo stesso Profilo di Protezione, il cliente avrebbe così l'opportunità di scegliere in modo definitivo il prodotto che ha avuto i risultati migliori, anche se entrambi hanno fallito la valutazione globale. Il cliente dovrebbe essere pure a conoscenza dei casi in cui, tra due prodotti valutati, uno superi la valutazione, mentre l'altro la fallisca per un piccolo margine rispetto al primo. In questi casi, infatti, una sostanziale differenza di prezzo o la natura stessa del test che ha avuto esito negativo, potrebbe rendere anche il prodotto che ha fallito la valutazione il miglior acquisto per alcune applicazioni.
Conclusioni
Le certificazioni secondo i Common Criteria forniscono un vantaggio aggiuntivo non indifferente rispetto ad altre certificazioni: il riconoscimento internazionale. Esse sono la base per la comparazione dei risultati di valutazioni indipendenti. I Common Criteria sono applicabili alle contromisure di sicurezza ICT implementate in HW, SW e firmware e sono indipendenti dalla tecnologia. Come già evidenziato, essi non sono privi di difetti e necessitano di ulteriori riflessioni e miglioramenti. C'è la necessità di guardare a più efficaci ed efficienti metodologie di valutazione, accettate internazionalmente, nell'ottica di una generale riduzione dei costi. L'aspetto essenziale per lo sviluppo commerciale delle certificazioni Common Criteria passa attraverso l'avvicinamento alle esigenze dell'utenza; in questa direzione è andata, opportunamente, la nuova versione 3.0. Ciononostante, le valutazioni di garanzia Common Criteria non risolvono naturalmente tutti i problemi sulla sicurezza. Esse possono solo assistere la comunità ICT ad avere garanzie che spingano produttori e sviluppatori a trovare soluzioni migliori. Infatti la sicurezza IT è un impegno, sia individuale che dell'organizzazione, costante.
Riferimenti Bibliografici
[1] ISO/IEC IS 15408-1 Evaluation Criteria for Information Technology Security - Part 1: Introduction and general model
[2] ISO/IEC IS 15408- 2 Evaluation Criteria for Information Technology Security - Part 2: Security functional requirements
[3] ISO/IEC IS 15408-3 Evaluation Criteria for Information Technology Security - Part 3: Security assurance
[4] CEM1 Common Evaluation Methodology for Information Technology Security Evaluation, Part 1 - Introduction and general model
[5] CEM2 Common Evaluation Methodology for Information Technology Security Evaluation, Part 2 - Evaluation Methodology
[6] Linee Guida Provvisorie dello schema nazionale per la valutazione e certificazione della sicurezza di sistemi e prodotti nel settore della tecnologia dell'informazione http://www.ocsi.gov.it
[7] Il portale dei Common Criteria
[8] Il National Information Assurance Partnership del NIST
Gli autori
Sandro Mari si è laureato nel 2003 in Ingegneria Elettronica presso l’Università degli Studi di Roma “La Sapienza”. Ha collaborato con un’ azienda del settore elettronico ed è stato impegnato nel campo della formazione tecnica superiore. Nell’anno accademico 2004-2005 ha frequentato la Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM; dal settembre del 2005 è stagista presso l’ISCOM e si occupa di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza informatica secondo lo standard Common Criteria, rilasciata dall’ OCSI ( Organismo di Certificazione della Sicurezza Informatica ).
sandromari AT tiscali PUNTO it
Giovanni Elia si è laureato in Ingegneria Elettronica nell’aprile del 2003 presso l’Università di Palermo. Nel 2005 ha conseguito il Diploma della Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM e dal settembre dello stesso anno è impegnato in uno stage presso l’ISCOM, occupandosi di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza secondo lo standard Common Criteria, rilasciata dall’OCSI ( Organismo di Certificazione della Sicurezza Informatica ).
ing.giovannielia AT tiscali PUNTO it
Renato Baldelli si è laureato in Ingegneria Elettronica nel 2004 presso l’Università degli Studi di Roma “La Sapienza”. Nell’anno accadamico 2004/2005 ha frequentato la Scuola Superiore di Specializzazione in Telecomunicazioni dell’ISCOM. Dal settembre del 2005 è stagista presso l’ISCOM, e si occupa di sicurezza informatica. Nell’ambito di tale attività ha conseguito l’abilitazione come assistente per le certificazioni di sicurezza informatica secondo lo standard Common Criteria, rilasciata dall’ OCSI (Organismo di Certificazione della Sicurezza Informatica ).
renbal AT libero PUNTO it
IsacaRoma Newsletter Link
- Le pagine dedicate a ISCOM
- ISCOM - L'analisi e la gestione del rischio: principi e metodi
» email this story | printer friendly version | 2651 reads
