 | Common Criteria for IT Security |
Introduzione ai nuovi standard
di sicurezza
di
Ing. Luigi Baffigo
Premessa
Un po’ di storia
Organizzazione dei Common Criteria (CC)
Modello generale dei Common Criteria
I Concetti chiave dei Common Criteria
Tipologie dei requisiti
Il modello costruttivo
Definizione del Target Of Evaluation (TOE)
Gerarchia delle componenti dei CC
Le Classi funzionali della sicurezza
Le Classi di affidabilità della sicurezza
Livelli di valutazione dell’affidabilità
I Protection Profiles e i Security Targets
Modalità di utilizzo pratico dei CC
Premessa
Tra le finalità di questo nuovo standard di sicurezza informatica (che è previsto sostituisca i vari ITSEC, TCSEC, ecc) gli estensori si sono posti, oltre all’obiettivo istituzionale di fornire regole e direttive per gli sviluppatori e per gli enti di valutazione, anche quello di fornire una guida e una fonte di consultazione per gli utenti degli stessi sistemi informatici.
Ben difficilmente il responsabile della sicurezza o l’amministratore di un sistema informatico, per svolgere la sua attività, avrà la necessità di dover leggere o studiare per intero la documentazione relativa a tali standard, dovrà però averne un’idea generale ed essere in grado di consultarli in particolari circostanze quali l’acquisto e installazione di prodotti di sicurezza, valutazione della situazione di rischio, audit, ecc.
Questo mio elaborato vuole, facendone un’estrema sintesi, ridurre il disagio e le difficoltà di chi per la prima volta si avvicina ai Common Criteria. Le parti in corsivo rappresentano miei personali commenti che derivano dalla pluriennale esperienza in questo settore.
I così detti Common Criteria o in modo più rigoroso secondo la terminologia ISO "IS 15408 — Information technology — Security techniques — Evaluation criteria for IT security", rappresentano il risultato di uno sforzo, iniziato nel lontano 1993, e solo ora concluso, per sviluppare una comune metodologia per la valutazione della sicurezza nel mondo dell’Informatica che fosse applicabile in campo internazionale.
Infatti, gli attuali criteri di valutazione:
- L’americano TCSEC (Trusted Computer Security Evaluation Criteria o Orange Book, del 1985).
- L’europeo ITSEC (Information Techonology Security Evaluation Criteria, del 1991) nato dallo sforzo congiunto della Francia, Germania, Olanda e Regno Unito.
- Il canadese CTCPEC (Canadian Trusted Computer Product Evaluation Criteria, del 1993) che tentava di conciliare i concetti del TCSEC e del ITSEC.
- L’americano FC (Federal Criteria for Information Technology Security, draft del 1993) che tentava a sua volta di conciliare l’approccio Nord Americano con quello Europeo.
non riuscivano più 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, 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 con l’obiettivo di rilasciare dei nuovi criteri che fornissero utili risposte all’esigenza di standardizzazione di un mercato informatico sempre più globale. Tali nuovi criteri dovevano inoltre permettere il reciproco riconoscimento della valutazione dei prodotti di sicurezza.
Nel 1996 era rilasciata la versione 1.0 dei Common Criteria.
Nell’ottobre 1998 si aveva il rilascio della versione 2.0 , (DIS 15408 che, ora con l’approvazione finale dell’ISO è a tutti gli effetti International Standard. Il documento ufficiale dovrebbe aversi entro l’anno in corso.
Nel frattempo a gennaio 1999 è stata rilasciata una versione draft (v 0.6) della Common Evaluation Methodology avente lo scopo di armonizzare le modalità di valutazione da parte degli enti valutatori. Tale metodologia è alla base per il reciproco riconoscimento.
Oltre a ISO, rappresentato dall’WG3/SC27 (gruppo di lavoro internazionale dedicato alla sicurezza informatica), collaborano col progetto i seguenti enti ufficiali nazionali:
- Canada — Communication Security Establishment
- Francia — Service Central de la Sécurité des Systèmes d’Information (SCSSI)
- Germania — Bundesamt für Sicherheit in der Informationstechnik (BSI)
- Olanda — Netherlands National Communications Security Agency
- Regno Unito — Communication-Electronics Security Group (CESG)
- USA — National Institute of Standards and Technology (NIST)
- USA — National Security Agency (NSA)
La CEE ha sponsorizzato il progetto.
Commento: tra i paesi più industrializzati non partecipa il Giappone, l’Australia e, ma non sorprende, l’Italia.
Organizzazione dei Common Criteria (CC)
Il documento attualmente rilasciato (Common Criteria for Information Technology Security Evaluation - Version 2.0 Final), oltre 600 pagine corredate da disegni e tabelle, è suddiviso in 3 parti:
- Parte 1: Introduzione e descrizione del modello generale.
- Parte 2: Descrive i requisiti delle funzioni di sicurezza
- Parte 3: Descrive i requisiti ed i livelli della affidabilità della sicurezza
Nella tabella seguente una semplificata ipotesi di utilizzo dei tre capitoli da parte dei tre possibili utilizzatori: Utenti, Sviluppatori di SW o Sistemi informatici, Enti di valutazione e certificazione, mentre alcuni esempi pratici di utilizzo sono descritti più oltre al termine del documento.
Utenti | Sviluppatori | Certificatori | |
Parte 1 | Fornisce una conoscenza generale. | Fornisce una conoscenza generale per formulare i requisiti e le specifiche di un TOE | Fornisce una conoscenza generale e utile come guida per la struttura dei PP e ST |
Parte 2 | Una guida nel caso si debbono formulare dei requisiti per funzioni di sicurezza | Riferimenti per interpretare i requisiti di sicurezza e definire le specifiche funzionali di un TOE | Formulazione delle dichiarazioni obbligatorie dei criteri di valutazione per valutare se il TOE rispetta le funzioni di sicurezza dichiarate |
Parte 3 | Una guida nel caso si debba determinare o richiedere il livello di affidabilità di sicurezza | Riferimenti per interpretare i requisiti di affidabilità e definire l’approccio di affidabilità di un TOE | Formulazione delle dichiarazioni obbligatorie dei criteri di valutazione per valutare l’affidabilità del TOE, dei PP o ST |
Commento: Il documento, pur usando un linguaggio comprensibile a chi si intende di informatica ed in generale di sicurezza, diventa di difficilissima lettura per il diffusissimo uso di sigle ed abbreviazioni. Non bisogna spaventarsi, tenendo sempre sotto mano il glossario e con una buona dose di pazienza e tanto tempo a disposizione, si può studiare e digerire. In generale mi sento di affermare che è stato fatto un ottimo lavoro, l’impostazione è chiara e precisa e la struttura rigorosamente razionale del modello di riferimento ne facilita la comprensione.
Contemporaneamente sono stati resi disponibili in draft alcuni documenti aggiuntivi (da 50 a 90 pagine l’uno) chiamati Protection Profile o PP che rappresentano i primi tentativi di rendere concreti i principi e le guide contenute nei CC. Attualmente i più interessanti riguardano:
- Application-Level Firewall for Low-Risk environment (v. 2.0)
- Traffic-Filter Firewall for Low-Risk environment (v. 2.0)
- Commercial Security 1 (v. 1.0) — Ambiente semplice con sicurezza a livello base
- Commercial Security 3 (v. 1.0) — Ambiente multi-user con database e necessità di un livello di sicurezza selettivo.
- CS2-OS - commercial off the shelf (COTS) general-purpose operating systems (v. 0.1)
Questi PP sono stati tutti approntati dagli enti governativi USA (NIST, NSA,ecc.)
Altri PP dovrebbero essere resi disponibili dagli altri enti Europei o da società di sviluppo Sw.
Commento: Per questi documenti valgono le stesse considerazioni fatte per i CC. Il linguaggio è lo stesso così come le abbreviazioni. I Protection Profile rappresentano, per i responsabili della sicurezza e gli amministratori di sistemi, la parte più interessante ed utile dei CC. In pratica sono utilizzabili come modelli di riferimento per valutare o costruire un firewall, un sistema di controllo accessi, ecc. con la certezza che il modello stesso è, per quanto riguarda la sicurezza, coerente e completo.
Purtroppo non è possibile comprendere i PP senza avere una buona conoscenza dei Common Criteria almeno nelle sue linee generali.
Completano la documentazione attualmente disponibile un primo rilascio in draft della Common Evaluation Methodology (v. 0.6) (CEM). Trattasi di un documento di oltre 500 pagine articolato in 3 parti:
- Parte 1 : Introduzione e modello generale
- Terminologia e principi di valutazione
- Parte 2 : Metodologia di valutazione
- Protection Profile & Security Target
- Livelli di Affidabilità
- Altri componenti di affidabilità
- Parte 3 : Ampliamento della metodologia
Tale documento va considerato come parte integrante dei CC. Pone l’attenzione sull’attività degli enti che sono preposti alla valutazione della sicurezza dei prodotti/sistemi informatici garantendo che il loro operato sia congruente con i requisiti dei CC stessi.
Si presenta come un tool che dovrebbe garantire la consistenza dell’applicazione dei principi contenuti nei CC in caso di valutazioni ripetute nel tempo e secondo schemi diversi. Ovviamente è uno dei prerequisiti per il principio del reciproco riconoscimento delle valutazioni effettuate da enti diversi.
Commento: Vale ciò che è stato detto per i documenti già elencati. Il CEM dovrebbe interessare quasi esclusivamente gli enti che si propongono come valutatori e certificatori della sicurezza e gli auditor informatici.
Modello generale dei Common Criteria
I Common Criteria contengono essenzialmente i principi tecnici fondamentali — di validità generale, chiari e flessibili - per Tali requisiti sono descritti in modo organico e strutturato per due tipologie di situazioni: Tutti i requisiti di sicurezza (specifiche, descrizione, collegamenti, interdipendenze, ecc.) che si possono comporre nei PP e ST sono contenuti in un Allo stesso tempo i Common Criteria contengono i principi fondamentali per Per ottenere ciò ci si avvale di un
descrivere
valutare
I Concetti chiave dei Common Criteria
- — Requisiti funzionali — fondamentali per definire i comportamenti in materia di sicurezza dei prodotti e sistemi informatici. I requisiti effettivamente implementati diventano così funzioni di sicurezza.
- — Requisiti di affidabilità — fondamentali per stabilire la fiducia che si può riporre nelle funzioni di sicurezza sia in termini di correttezza di implementazione sia in termini di efficacia di soddisfare gli obiettivi propri delle stesse funzioni di sicurezza.
Il modello costruttivo su cui si basano i CC fa riferimento essenzialmente a due oggetti che possono essere oggetto di descrizione e valutazione :
- — I Protection Profile (PP) — un insieme organico di obiettivi e requisiti di sicurezza associabili a categorie di prodotti o sistemi informatici che soddisfano le necessità di sicurezza degli utenti. I PP non devono fare riferimento a specifici prodotti realmente realizzati.
- — Il Security Target (ST) — un insieme organico di requisiti e specifiche di sicurezza associate ad uno specifico prodotto o sistema informatico - a sua volta chiamato Target Of Evaluation (TOE) e che è oggetto di valutazione.
Alcuni esempi per chiarire meglio: Protection Profile per i Firewall, per un sistema tipo utilizzato in ambiente commerciale, per sistemi multi-user basati su sistemi operativi di normale commercio o per un sistema di controllo accessi basato su regole predefinite.
Per esempio Security Target per Oracle v7, per il Firewall XYZ, ecc.
Un ST può includere uno o più Protection Profile già descritti e valutati.
Definizione del Target Of Evaluation (TOE)
Come già intuito è chiamato TOE il prodotto o il sistema informatico che è oggetto di valutazione. Al TOE sono anche associati altri due elementi:
- — La TOE Security Policy (TSP) — cioè l’insieme di regole che governano le modalità con cui i beni (assets) informatici sono gestiti, protetti e distribuiti all’interno del prodotto o sistema che è oggetto di valutazione.
- — Le TOE Security Functions (TSF) — Sono considerate funzioni di sicurezza (TSF) tutte quelle parti del prodotto o sistema informatico oggetto di valutazione dalle quali dipende la garanzia della corretta esecuzione delle Politiche di Sicurezza (TSP).
Gerarchia delle componenti dei CC
I vari componenti dei requisiti e delle funzioni di sicurezza e di affidabilità sono definiti e classificati secondo una precisa gerarchia che prevede: Classi, Famiglie e Componenti.
- Le Classi sono un insieme organico di Famiglie che perseguono uno scopo comune.
- Le Famiglie sono un insieme organico di Componenti che perseguono un obiettivo di sicurezza comune, ma che possono differire nel rigore o nell’intensità.
- Le Componenti sono l’insieme minimo e non divisibile che può essere utilizzato ed inserito nei PP o ST.
Esempio: La classe User Data Protection o la Classe Audit.
Esempio: la famiglia Access Contro Policy raggruppa tutte le componenti che svolgono questa funzione.
Esempio: Access Control.1 raggruppa le funzioni di controllo accessi di livello 1.
Questa impostazione dovrebbe garantire flessibilità pur suggerendo di muoversi all’interno di requisiti predefiniti.
Le Classi funzionali della sicurezza
I CC definiscono 11 classi funzionali per i requisiti di sicurezza e 10 classi per i requisiti di affidabilità.
Le classi funzionali dei requisiti di sicurezza sono:
Classe | Nome |
FAU | Audit |
FCO | Communications |
FCS | Cryptographic Support |
FDP | User Data Protection |
FIA | Identification & Authentication |
FMT | Security Management |
FPR | Privacy |
FPT | Protection of TOE Security Functions |
FRU | Resource Utilization |
FTA | TOE Access |
FTP | Trusted Path/Channels |
Ogni classe è individuata da una sigla di tre lettere che è ripetuta su tutte le famiglie e componenti che appartengono alla stessa classe.
Di seguito una breve descrizione di ogni classe:
FAU — La classe Security Auditing comprende il riconoscimento, la registrazione, la conservazione e l’analisi delle informazioni connesse con le più significative attività che coinvolgono la sicurezza. Le registrazioni così ottenute possono essere esaminate per determinare quali attività di sicurezza sono avvenute e chi le ha attivate.
FCO — Communications — Questa classe è formata da due famiglie col compito di assicurare l’identità delle parti che sono coinvolte nello scambio di dati. Queste famiglie hanno il compito di garantire l’identità di chi origina le informazioni trasmesse (proof of origin) e di garantire la identità di chi riceve le informazioni trasmesse (proof of receipt), assicurano inoltre che chi origina il messaggio non possa negare di averlo spedito ed il ricevente non possa negare di averlo ricevuto.
FCS — Questa classe fornisce le funzionalità crittografiche nel caso ciò sia richiesto, per soddisfare più severi obiettivi di sicurezza. Fanno parte di questa classe molte funzioni tra cui. Identificazione ed autenticazione, non-rigetto, percorsi e canali fidati, separazione dei dati, ecc.
FDP - Quattro sono le famiglie di questa classe che definisce i requisiti di protezione dei dati utente. Tali famiglie indirizzano la protezione dei dati utente all’interno del TOE, durante l’importazione e l’esportazione, nella fase di memorizzazione e ne gestiscono gli attributi di sicurezza.
FIA — Identificazione ed Autenticazione — Le famiglie appartenenti a questa classe indirizzano i requisiti connessi con le funzioni che stabiliscono e verificano l’identità degli utenti. Tale funzione è richiesta per garantire che ogni utente sia associato con un appropriato profilo di sicurezza (attributi di sicurezza — es. identità, gruppo di appartenenza, regole di riferimento, livello di riservatezza, ecc.). Una identificazione non ambigua degli utenti autorizzati ed una corretta associazione dei relativi attributi di sicurezza con quelli dei dati e oggetti informatici è un elemento critico per garantire che le politiche di sicurezza volute siano rispettate.
Le famiglie appartenenti a questa classe permettono di determinare e verificare l’identità degli utenti, determinarne la specifica autorità per interagire con il TOE secondo specifici profili di sicurezza.
FMT — Security Management — Questa classe è preposta a specificare le regole di gestione delle molteplici funzioni di sicurezza presenti nel TOE, inclusi gli attributi di sicurezza ed i dati essenziali al funzionamento delle stesse funzioni. Sono specificate differenti regole di gestione, di interrelazioni tra le funzioni e le aree di competenza.
Questa classe si ripropone molteplici obiettivi:
- Gestione dei dati relativi al funzionamento delle stesse funzioni di sicurezza.
- Gestione degli attributi di sicurezza. Es. liste di accesso, liste delle potenzialità.
- Gestione delle funzioni di sicurezza. Es. selezione delle funzioni attivabili, regole o condizioni di funzionamento.
- Definizione delle regole di sicurezza.
FPR - Questa classe contiene i requisiti per la Privacy, intesa come protezione per ogni utente contro la possibilità che un altro utente possa individuarne l’identità e farne un uso improprio.
Le famiglie a disposizione sono:
Anonimity : garantisce che un utente possa utilizzare una risorsa od un servizio certo che la propria identità non venga rivelata ad altri utenti.
Pseudonymity: come nel caso precedente con in più la possibilità però di rendere conto (accountable) delle attività eseguite.
Unlinkability: garantisce che un utente possa accedere più volte alle risorse ed ai servizi senza che altri utenti possano ricostruire questi passaggi.
Unobservability: garantisce che un utente possa utilizzare una risorsa od un servizio senza che altri utenti possano osservare quale servizio o risorsa egli stia utilizzando.
FPT — Questa classe comprende famiglie di requisiti funzionali che fanno riferimento all’integrità e alla gestione dei meccanismi che compongono le funzioni di sicurezza del TOE e all’integrità dei dati delle stesse funzioni di sicurezza. Le famiglie di questa classe potrebbero apparire come una duplicazione della classe FDP (protezione dei dati utente) ed utilizzare anche gli stessi meccanismi.
Mentre le funzioni incluse nella classe FDP si occupano della sicurezza dei dati utente, le famiglie incluse nella classe FTP si occupano della protezione dei dati che sono essenziali al funzionamento delle stesse funzioni di sicurezza del sistema o prodotto oggetto di valutazione (TSF).
FRU — Questa classe fornisce tre famiglie che supportano la disponibilità delle risorse necessarie per il funzionamento del TOE, quali per esempio le capacità elaborative e/o di memorizzazione.
La famiglia Fault Tolerance fornisce la protezione contro la indisponibilità delle risorse elaborative per effetto di inconvenienti o guasti al TOE stesso.
La famiglia chiamata Priority of Service assicura che le risorse siano allocate alle attività più critiche o importanti e non vengano monopolizzate da attività a bassa priorità.
La famiglia Resource Allocation permette di porre dei limiti all’utilizzo delle risorse per evitare che un utente le monopolizzi.
FTA — Questa classe contiene le famiglie che disciplinano l’accesso allo stesso TOE definendo i requisiti per controllare l’esecuzione delle sessioni utente.
Le famiglie a disposizione sono:
- Inizio delle sessioni
- Limitazioni nelle sessioni multiple concomitanti.
- Limitazioni negli scopi degli attributi di sicurezza utilizzabili.
- Blocco delle sessioni.
- Storia degli accessi
- Simboli (banners) degli accessi.
FTP — Le famiglie comprese in questa classe forniscono i requisiti di sicurezza per un percorso fidato (trusted) di comunicazione tra gli utenti e le stesse funzioni di sicurezza (TSF) e per un canale fidato di comunicazione tra le TSF e gli altri prodotti informatici. Il percorso di comunicazione deve garantire che l’utente sia in comunicazione con le corrette TSF e che le TSF siano in comunicazione col corretto utente.
Nella tabella allegata un sintetico confronto con la classi funzionali definite nei CC e quelle definite nell’ITSEC.
Classi funzionali dei CC | Classi funzionali di ITSEC |
Audit | Audit |
Communications | Accountability Data Exchange |
User Data Protection | Access Control Accuracy Object Reuse |
Privacy | |
Identification and Authentication | Identification and Authentication |
Protection of Trusted Security Functions | |
Resource Utilisation | Reliability of Service |
TOE Access | Access Control |
Trustedd path/Channels | Access control Data Exchange |
Commento: La lista dei requisiti funzionali è molto ampia ed articolata per severità di utilizzo. Ai fini pratici credo che si dimostrerà utilissima in quanto potrà essere impiegata come lista di controllo oltre che per descrivere le caratteristiche di sicurezza volute anche per descrivere un prodotto o sistema esistente. Da notare che sono dettagliatamente elencate tutte le interdipendenze tra le famiglie anche di classi diverse. Il linguaggio utilizzato è sintetico ed essenziale: lo ritengo chiaro e comprensibile.
Le classi di affidabilità della sicurezza
Le classi dei requisiti che concorrono a determinare l’affidabilità della sicurezza sono 10.
Classe | Nome |
ACM | Configuration Management |
ADO | Delivery & Operation |
ADV | Development |
AGD | Guidance Documents |
ALC | Life Circle Support |
ATE | Tests |
AVA | Vulnerability Assessment |
APE | Protection Profile Evaluation |
ASE | Security Target Evaluation |
AMA | Maintenance of Assurance |
Le classi di affidabilità sono anch’esse codificate con una sigla di tre lettere che si ripete sulle famiglie che compongono la classe.
Di seguito una breve descrizione delle classi:
ACM — La gestione della configurazione aiuta a garantire che sia preservata la integrità del TOE richiedendo che esista adeguata disciplina e controllo dei processi di messa a punto e modifica del TOE e dei dati ad esso correlati. Tale disciplina deve prevenire che il TOE venga modificato, che ci siano aggiunte o cancellazioni di sue parti senza la dovuta autorizzazione. Inoltre il TOE deve essere fornito di appropriata documentazione sia per la sua distribuzione sia per la valutazione.
ADO — Questa classe definisce i requisiti per le misure, le procedure e gli standard che si riferiscono alla fasi di spedizione, installazione e di utilizzo sicuro del TOE garantendo che le protezioni di sicurezza offerte non siano compromesse durante le fasi di trasferimento, installazione, start-up e funzionamento.
ADV — Definisce i requisiti per la graduale messa a punto, nella fase di sviluppo, delle funzioni di sicurezza del TOE partendo dalle specifiche generali sino alla effettiva implementazione.
ADG — definisce i requisiti finalizzati alla comprensibilità, copertura e completezza della documentazione operativa fornita dallo sviluppatore. Questa documentazione, che è divisa in due categorie — una per gli utenti ed una per l’amministratore — è uno dei fattori chiave per la sicurezza dell’operatività del TOE.
ALC — definisce i requisiti per l’affidabilità attraverso l’adozione di un ben definito modello di ciclo di vita per tutti i passi dello sviluppo del TOE, inclusa la politica e le procedure per rimediare ai difetti, il corretto uso dei tool, le tecniche e le misure di sicurezza utilizzate per proteggere l’ambiente di sicurezza.
ATE — stabilisce i requisiti per i test che dimostrano come le funzioni di sicurezza soddisfino i requisiti funzionali del TOE. Vi fanno parte test di copertura, di profondità e funzionali, così come modalità di test indipendenti.
AVA — definisce i requisiti diretti alla identificazione dei punti deboli sfruttabili. In particolare quei punti deboli generati nel TOE nelle fasi di costruzione, di utilizzo, di uso improprio o configurazione non corretta.
APE - L’obiettivo della valutazione di un Protection Profile (PP) è di dimostrare che il PP è completo, consistente e tecnicamente corretto. Un PP già valutato può essere utilizzato come base per lo sviluppo di security Target (ST). I PP già valutati possono essere inclusi in appositi registri a disposizione degli utenti.
ASE — L’obiettivo della valutazione di un Security Target (ST) è di dimostrare che il ST è completo, consistente, tecnicamente corretto e pertanto utilizzabile per essere utilizzato come base per la valutazione di un corrispondente TOE.
AMA — fornisce i requisiti che devono essere applicati dopo che un TOE sia stato certificato secondo i Common Criteria. Questi requisiti si ripropongono di garantire che il TOE, dopo la valutazione, continui a soddisfare i propri Security Target malgrado possibili variazioni allo stesso TOE ed all’ambiente in cui è posto. Come cambiamenti vengono considerati la scoperta di nuove minacce o punti deboli e la correzione di errori di codifica.
Livelli di valutazione dell’affidabilità
Livello | Nome | TCSEC | ITSEC |
EAL1 | Functionally Tested | ||
EAL2 | Structurally Tested | C1: Discretionary security protection | E1: Informal architectural design |
EAL3 | Methodically Tested & Checked | C2 — Controlled access protection | E2: E1 + informal detailed design & test documentation |
EAL4 | Methodically Designed, Tested & Reviewed | B1 - Labeled security protection | E3: E2 + Source code or hardware drawing & evidence of testing |
EAL5 | Semiformally Designed & Tested | B2 — Structured protection | E4: E3 + Semiformal architectural design & formal model of security policy |
EAL6 | Semiformally Verified Designed & Tested | B3 — Security domains | E5: E4 + Correspondence between detailed design & source code |
EAL7 | Formally Verified Designed & Tested | A1- Verified design | E6: E5 + Formal description & detailed architectural design |
I livelli di valutazione dei CC sono 7 e vengono definiti con la sigla EAL (Evaluation Assurance Levels). I livelli sono stati definiti in modo da essere (grossolanamente) confrontabili con gli equivalenti livelli dei TCSEC e ITSEC. La tabella riporta questa corrispondenza.
Di seguito una breve descrizione dei livelli di affidabilità:
Il livello EAL1 è applicabile quando è richiesta una certa fiducia nella correttezza delle operazioni, ma le minacce alla sicurezza non appaiono serie. Ciò potrebbe avere senso dove viene richiesta una generica affidabilità della sicurezza per dimostrare che un minimo di attenzione sia stata posta nella protezione dei dati.
EAL1 fornisce una valutazione del TOE così come viene reso disponibile ai clienti, inclusi i risultati di test indipendenti e un esame della documentazione di guida normalmente fornita. Si presuppone che la valutazione EAL1 si possa condurre con successo anche senza il coinvolgimento degli sviluppatori del TOE e con non troppa spesa. Una valutazione a questo livello dovrebbe fornire la prova che TOE funzioni così come descritto nella documentazione e che fornisce sufficiente protezione contro le minacce identificate.
Il livello EAL2 richiede la cooperazione degli sviluppatori del TOE in termini di informazioni sui processi di spedizione e di design e risultati dei test, ma non dovrebbe richiedere agli sviluppatori uno sforzo più ampio di quello richiesto nella normale messa a punto di un buon prodotto. In altri termini non ci dovrebbero essere sensibili aggravi di costo e di tempi.
EAL2 è applicabile in quelle situazioni dove gli sviluppatori o gli utenti richiedono un basso o moderato livello di affidabilità della sicurezza pur in mancanza di una completa documentazione di sviluppo. Tale circostanza si potrebbe avere nel caso di sistemi proprietari o nel caso non sia facile disporre della necessaria documentazione di sviluppo.
Il livello EAL3 permette ad uno sviluppatore coscienzioso di raggiungere il massimo di affidabilità da una appropriata progettazione della sicurezza in fase di design senza comunque alterare in modo sostanziale le esistenti corrette procedure di sviluppo.
EAL3 è applicabile in quelle situazioni dove gli sviluppatori o gli utenti richiedono un moderato livello di affidabilità della di sicurezza senza, per condurre la valutazione, dover effettuare un sostanziale re-engeneering del TOE stesso.
Il livello EAL4 permette ad uno sviluppatore di raggiungere il massimo di affidabilità da una appropriata progettazione della sicurezza basata su un buon processo di sviluppo tra quelli disponibili in commercio che, basato sul rigore, non richieda specialisti con elevati skill o particolari conoscenze in materia di tecnologie di sicurezza.
EAL4 è il livello più alto di affidabilità che probabilmente si potrà economicamente ottenere aggiustando prodotti già esistenti.
Il livello EAL5 permette ad uno sviluppatore di raggiungere il massimo di affidabilità da una appropriata progettazione della sicurezza basata su un rigoroso processo di sviluppo tra quelli disponibili in commercio che preveda un utilizzo moderato di specialisti in tecniche di architettura di sicurezza. Tali TOE saranno probabilmente progettati e sviluppati col preciso intento di raggiungere il livello EAL5. È altamente probabile che per il fatto di dover soddisfare i requisiti di questo livello ci siano dei costi aggiuntivi che non dovrebbero comunque essere consistenti nel caso si utilizzino processi rigorosi di sviluppo senza ricorrere a specializzate tecnologie.
EAL5 è pertanto applicabile in quelle situazioni dove gli sviluppatori o gli utenti richiedano un elevato livello di affidabilità della sicurezza in uno sviluppo pianificato e condotto in modo rigoroso evitando di subire elevati e non ragionevoli costi a seguito dell’utilizzo di tecniche specialistiche di engineering di sicurezza.
Il livello EAL6 permette agli sviluppatori di raggiungere un alto livello di affidabilità con l’utilizzo di specifiche tecnologie di sicurezza in rigorosi ambienti di sviluppo per produrre TOE di prima qualità nel caso si debbano proteggere beni informatici di alto valore contro rischi notevoli.
EAL6 è pertanto applicabile nei casi in cui si debbano sviluppare dei TOE per utilizzi in situazioni ad alto rischio dove il valore dei beni protetti giustifichi notevoli costi addizionali.
I Protection Profiles e i Security Targets
Come già detto il modello costruttivo su cui si basano i CC fa riferimento essenzialmente a due oggetti che possono essere oggetto di descrizione e valutazione :
I Protection Profile (PP) — un insieme organico di obiettivi e requisiti di sicurezza associabili a generiche categorie di prodotti o sistemi informatici che soddisfano le necessità di sicurezza degli utenti.
Il Security Target (ST) — un insieme organico di requisiti e specifiche di sicurezza associate ad uno specifico prodotto o sistema informatico che è oggetto di valutazione.
I contenuti dei PP e ST sono:
Protection Profile | Security Target |
Introduction | Introduction |
TOE description | TOE description |
Security environment | Security environment |
Security objectives | Security objectives |
Security requirements | Security requirements |
TOE summary specification | |
PP claims | |
Rationale | Rationale |
Di seguito una breve descrizione dei vari componenti che costituiscono i contenuti dei PP e ST.
L’introduzione contiene i dati identificativi del PP o ST ed una breve descrizione in forma narrativa.
TOE description — in questa parte è descritto il sistema o il prodotto che è oggetto di valutazione. Tale descrizione è essenziale per capire i requisiti di sicurezza e deve anche definire la tipologia dei prodotti e le caratteristiche informatiche dello stesso TOE. Nel caso si tratti di un PP, non potendo fare riferimento a specifici prodotti, le varie caratteristiche e specifiche sono fornite come ipotesi.
TOE security environment — In questa sezione devono essere descritti gli aspetti di sicurezza relativi all’ambiente nel quale il TOE si presuppone sia usato e la maniera nella quale si intende impiegarlo.
Fa parte di questa sezione un primo capitolo che descrive le ipotesi di base come: le ipotesi di utilizzo, le applicazioni coinvolte, il valore dei beni informatici, le limitazioni d’utilizzo, l’ambiente fisico, caratteristiche del personale e le tipologie di connessione, ecc.
Un altro capitolo descrive le principali minacce a cui è esposto il TOE e dal quale lo si vuole difendere.
L’ultimo capitolo di questa sezione definisce la politica della sicurezza, la relativa organizzazione e le regole che il TOE deve rispettare.
Security objectives — Questa sezione definisce gli obiettivi di sicurezza del TOE e del suo ambiente in modo che siano indirizzati tutti gli aspetti di sicurezza che sono stati identificati e conseguentemente predisposte le risposte alle minacce identificate e coperte tutte le ipotesi di base e le regole previste dalla politica di sicurezza..
Security requirements — Questa sezione definisce in dettaglio i requisiti di sicurezza a cui deve sottostare il TOE ed il suo ambiente. Devono essere definiti sia i prerequisiti funzionali sia quelli di affidabilità fornendo le relative prove che essi soddisfano le necessità previste per soddisfare gli obiettivi di sicurezza del TOE stesso.
Rationale — Questa sezione contiene le prove, che devono essere verificate in fase di valutazione, in modo che si possa essere certi di avere un PP completo e un coerente set di requisiti e che il TOE dispone di un altrettanto completo e coerente set di contromisure.
Le sezioni elencate sono comuni sia ai PP sia ai ST. In aggiunta i ST contengono una sezione di specifiche ed un’altra di richiamo degli eventuali PP che inglobano.
Modalità di utilizzo pratico dei CC
In generale si possono individuare due modalità di utilizzo dei CC.
- Una modalità standardizzata per descrivere i requisiti di sicurezza di un prodotto o sistema.
- Una struttura tecnica corretta per la valutazione delle caratteristiche di sicurezza dei prodotti o sistemi.
Vediamo ora di ipotizzare alcuni scenari differenti di utilizzo.
Descrizione di requisiti di sicurezza
Si ipotizza che un gruppo di utenti (es. una associazione bancaria o assicurativa, un ente responsabile per l’informatica per un gruppo di aziende, ecc.) voglia definire un set di caratteristiche di sicurezza che debbono essere rispettate nei sistemi o in alcuni software utilizzati dagli utenti stessi. Il primo passo sarà quello di costruire un Protection Profile (PP) per definire questi requisiti comuni. Si inizierà con l’identificare il tipo di prodotto o la tipologia di un ipotetico prodotto e le generiche funzioni informatiche necessarie. Successivamente si dovrà considerare l’ambiente nel quale ciò dovrà operare con particolare riferimento all’identificazione dei problemi di sicurezza e alle difficoltà da superare. Tale attività è in sostanza una analisi di rischio e si concretizza in una dichiarazione di esigenze generali e di obiettivi di sicurezza che devono essere rispettati sia dal prodotto sia dall’ambiente.
Utilizzando la Parte 2 dei CC si devono ora trasformare questi obiettivi in un set coerente e omogeneo di definizioni di requisiti funzionali di sicurezza. Tenendo presente il livello di affidabilità di sicurezza che si desidera bisogna ora assegnare il corrispondente EAL utilizzando la Parte 3. Probabilmente si dovranno rivedere i requisiti funzionali che non dovessero essere in linea con il livello (EAL) desiderato.
Da tenere sempre presente in questa fase che il livello di sicurezza (EAL) oltre a determinare il grado di affidabilità influenza direttamente i tempi ed i costi di messa a punto della soluzione progettata.
Una volta che si è soddisfatti del risultato ottenuto l’elaborato può essere preso come base per lo sviluppo delle funzioni di sicurezza del prodotto o sistema ipotizzato.
Il documento ottenuto è essenzialmente un Protection Profile (PP). Sarebbe bene a questo punto farlo verificare da un ente terzo per essere certi che il tutto sia corretto, completo e soprattutto coerente. Eventualmente il PP, una volta verificato e certificato, potrebbe anche essere riposto in un pubblico registro (attualmente in via provvisoria gestito dal NIST USA) e messo a disposizione di chiunque sia interessato.
Commento: È evidente il vantaggio di operare in questo modo. Infatti non solo il documento risultante conterrà norme e regole omogenee e coerenti dal punto di vista della sicurezza, ma soprattutto sarà scritto con un linguaggio univoco e comprensibile che non si presta ad equivoci. Chi si occupa di sicurezza sa quanto sia importante intendersi sul significato delle parole e sui contenuti.
Valutazione della sicurezza di un prodotto
Lo scenario ipotizzato è quello relativo ad un laboratorio di sviluppo SW o HW che voglia verificare le caratteristiche di sicurezza di uno specifico prodotto. Si potrebbe anche ipotizzare che il prodotto in questione faccia riferimento ad un generico PP (es. quello rilasciato dal gruppo di utenti del caso precedente). A questo punto lo sviluppatore potrà costruire il prodotto o sistema facendo riferimento ai requisiti precisati nel PP e a quanto in corrispondenza previsto nelle Parti 2 e 3 dei CC rispettivamente per le funzionalità e affidabilità della sicurezza.
Una volta che il prodotto o sistema sia stato costruito sarà possibile preparare un Security Target (ST) che, se era disponibile un Protection Profile si limiterà a richiamarlo e a dichiarare di averlo rispettato, altrimenti va costruito come previsto dai CC. Dovrà inoltre essere messa a punto la documentazione relativa alle specifiche tecniche di sicurezza ed alle modalità utilizzate per rispettarle.
In ultimo dovrà essere coinvolto un ente accreditato di valutazione e certificazione che verificherà e testerà il tutto.
Tale ente valuterà prima il Security Target per verificare che sia completo e coerente e che effettivamente incorpori gli eventuali Protection Profile che dice di aver rispettato. Successivamente sarà valutato il prodotto per verificare che sia conforme e coerente con quanto dice il Security Target.
Nel caso il prodotto superi tutti i test e controlli il risultato potrà essere inviato ad un ente ufficiale di certificazione per la sua registrazione.
Certificazione dei risultati
Nella Parte 1 dei CC viene descritto il processo di certificazione che deve garantire che tutte le operazioni di valutazione siano state condotte correttamente. L’ente di certificazione è di norma una autorità che garantisce che nell’ambito della sua giurisdizione gli enti di valutazione operino secondo precisi standard di qualità.
Gli enti elencati all’inizio di questo documento sono tutti, nei rispettivi paesi, enti ufficiali governativi di certificazione.
Valutazione di un sistema installato
Un altro modo di utilizzare il processo previsto dai CC è quello di usarli per la valutazione di uno specifico sistema già installato. In tal caso occorre sviluppare un Security Target che descriva l’architettura del sistema, le funzioni e l’ambiente operativo ed in dettaglio le funzioni di sicurezza presenti. Fatto ciò occorre richiedere ad un ente o ad un laboratorio di valutazione di effettuare una valutazione in loco per verificare che ci sia corrispondenza tra il security Target ed il sistema installato. A questo punto il Security Target potrebbe essere eventualmente certificato da un ente ufficiale.
Commento: Credo che i Responsabili dei dati personali ed i Responsabili della sicurezza di Sistemi Informativi importanti e con dati sensibili dovrebbero valutare seriamente l’opportunità di seguire questo modo di utilizzare i CC. Disporre di una descrizione standardizzata della sicurezza del sistema di cui si è responsabili, ed eventualmente di una sua valutazione indipendente, è sicuramente coerente con i dettati dell’art. 15 della legge 675/96.
Milano, giugno 1999
La comunicazione del NIST:
CC just approved as International Standard IS 15408!
(8 June 1999) FLASH!! We have just received news from the ISO CentralSecretariat via the SC27 Secretariat that all three Parts of FDIS 15408(the CC) have received sufficient support from the just-closed NationalBody balloting, so the International Standard 15408 is now a reality. Allthat remains is ISO's usual final formatting and publication, withoutfurther textual modification. This process usually takes a few months, sowe can expect IS 15408-1, -2, and -3 to be published by early Fall. In themeantime, the FDIS text is definitive and can be used.