Per gentile concessione dell’Istituto Superiore delle Comunicazioni e delle Tecnologie dell’Informazione pubblichiamo un altro paragrafo della nuova linea guida sulle certificazioni di sicurezza i cui contenuto ci sono stati anticipati dall’ ing. Luisa Franchina, Direttore Generale di ISCOM. Si tratta del paragrafo che affronta il tema della certificazione secondo i Common Criteria (CC). In questa prima parte saranno presentate le caratteristiche generale dei CC. Nella seconda parte dell’articolo si analizzeranno vantaggi e svantaggi dell’utilizzo dei CC. Ricordiamo che sono stati già pubblicati sia l'indice completo della linea guida sia il paragrafo relativo alle certificazioni delle competenze del personale.

3.2 Valutazione e Certificazione di sistema/prodotto secondo lo standard ISO 15408 (Common Criteria)

Come detto in precedenza, i processi di valutazione e certificazione in accordo allo standard dei Common Criteria sono gestiti, in Italia, dall’Organismo per la Certificazione della Sicurezza Informatica (OCSI).
Tutte le considerazioni seguenti riguardanti i vari aspetti della certificazione Common Criteria effettuata dall’OCSI derivano da documenti ufficiali prodotti dall’OCSI stesso e disponibili sul suo sito.
Le considerazioni e le informazioni contenute in questo paragrafo fanno riferimento alla versione 2.2 dei CC, che è stata recepita dallo standard ISO15408, e della relativa metodologia CEM (Common Evaluation Metodology).
I CC versione 2.2 sono costituiti da tre parti contenenti, il modello generale, il catalogo dei requisiti funzionali di sicurezza e il catalogo dei requisiti di assurance, rispettivamente. La CEM, invece, è costituita da un solo documento che descrive, appunto, la metodologia di valutazione della sicurezza effettuata in accordo con i CC.
È ormai in fase di edizione finale la versione 3.1 dei CC che conterrà delle variazioni anche sostanziali su alcuni aspetti anche rilevanti. Per le finalità di questa Linea Guida si ritiene opportuno fare comunque riferimento alla versione 2.2 ufficiale al momento e consigliare al lettore una verifica periodica presso il sito dell’OCSI  per gli aggiornamenti.
Tutti i documenti ufficiali dei CC sono riportati nel sito www.commoncriteriaportal.org

3.2.1 Generalità sui Common Criteria

In questo paragrafo ci si limiterà a descrivere l’approccio secondo il quale i CC sono stati sviluppati, mirando principalmente a fornire quegli elementi informativi che consentono una adeguata comprensione delle argomentazioni svolte in questo lavoro.
La filosofia che è alla base dei CC è stata ripresa dai precedenti criteri europei 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.
Nel contesto dei Common Criteria [15], con il termine prodotto si intende un insieme di elementi software, hardware e/o firmware che svolge una funzione che può essere utilizzata da molti sistemi, mentre con il termine sistema si intende una specifica installazione IT (software, firmware o hardware), caratterizzata da uno scopo e da un ambiente operativo ben definiti .
Il Profilo di Protezione (PP) è invece 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 fiducia, definiti secondo i Common Criteria.
Un PP ha la finalità di definire un insieme di requisiti che si è dimostrato efficace per raggiungere gli obiettivi individuati, sia per quanto riguarda le funzioni di sicurezza, sia per quanto riguarda la garanzia. Un PP fornisce agli utenti uno strumento per fare riferimento ad uno specifico insieme di esigenze di sicurezza, e facilita lo svolgimento di future valutazioni di Prodotti o Sistemi che soddisfino tali esigenze .
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:

1. l’idoneità delle funzioni di sicurezza a soddisfare gli obiettivi di sicurezza del sistema/prodotto;
2. 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, ecc.), 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 Traguardo di Sicurezza (Security Target), deve essere obbligatoriamente fornito e rappresenta il documento principale della valutazione. Nel Traguardo di Sicurezza 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 Profilo di Protezione (Protection Profile), che per il resto ha una struttura del tutto simile a quella del Traguardo di Sicurezza.
Il Profilo di Protezione 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 Traguardo di Sicurezza).
Il Profilo di Protezione può essere registrato e anche valutato per verificarne la coerenza interna.

(Fine prima parte)

Note

[15] Le definizioni successive sono tratte dalla LGP7 emanata dall’OCSI sicurezza tecniche (funzioni di sicurezza) e non tecniche (fisiche, procedurali e relative al personale).

IsacaRoma link

ISCOM

• Intervista a Luisa Franchina Direttore Generale dell’Istituto Superiore delle Comunicazioni e della Tecnologia dell’Informazione
• Centro di formazione dei dipendenti della PA nel campo della sicurezza ICT
• ISCOM - L'analisi e la gestione del rischio: principi e metodi
• "Futuro Semplice": una nuova iniziativa di ISCOM
• L’OCSI e la certificazione della sicurezza ICT
• Fattori critici per lo sviluppo delle certificazioni di sicurezza secondo i Common Criteria
• ISCOM: Anteprima sulle nuove linee guida sulla sicurezza e la qualità dei servizi - prima parte e seconda parte

Nuova linea guida sulla “Certificazione della Sicurezza ICT”

• Anteprima della linea guida sulla "Certificazione della Sicurezza ICT": l’indice del volume
• Anteprima della linea guida sulla “Certificazione della Sicurezza ICT”: le certificazioni del personale
• ISCOM – Anteprima della linea guida sulla “Certificazione della Sicurezza ICT”: ISO 15408 Common Criteria – prima parte