Autore: Candido FabioProf.: Bistarelli Stefano

Cos’è?

La valutazione è un processo in cui le prove di (assurance)affidabilità sono raccolte e analizzate secondo i criteri di funzionalità e di garanzia.

Essa si può definire come un modo per determinare l’affidabilità e il buon funzionamento del sistema. I criteri utilizzati dipendono dagli obiettivi della valutazione e dalla tecnica di valutazione usata.

Trusted Computer System Evaluation Criteria (TCSEC), è stato il primo grande metodo di valutazione formale usato, e i conseguenti miglioramenti delle metodologie sono costruite su di essa nel corso del tempo. Questo capitolo esplora diverse metodologie di valutazione usate nel passato e nel presente, sottolineando le differenze tra loro e gli insegnamenti tratti da ogni metodologia.

Obiettivi delle valutazioni formali

La sicurezza perfetta è l’obiettivo finale (irrealizzabile) per i sistemi informatici.

Aumento della complessità quindi più difficile validare un sistema da analizzare.

Un sistema affidabile è un sistema che ha dimostrato di soddisfare i requisiti di sicurezza a specifiche condizioni. La fiducia si basa su prove di garanzia. Sebbene un sistema fidato non può garantire la sicurezza perfetta, esso fornisce le basi di fiducia nel sistema con lo scopo della valutazione. Le tecniche di valutazione formale della sicurezza sono state create per facilitare lo sviluppo di sistemi affidabili.

In genere, un metodo di valutazione prevede le seguenti caratteristiche: Una serie di requisiti di sicurezza che definisce le funzionalità per il sistema o il prodotto. Una serie di requisiti di (assurance) garanzia che delineano i passi per stabilire che il sistema o il

prodotto soddisfa le sue esigenze funzionali. Di solito richiedono prove di affidabilità.

Una metodo per determinare che il prodotto o il sistema soddisfa i requisiti funzionali sulla base di analisi delle prove di garanzia.

un metro di valutazione dei risultati (chiamato livello di fiducia), che indica come l’affidabilità del prodotto o sistema è rispetto ai requisiti funzionali di sicurezza.

Un metodo di valutazione formale, è una tecnica utilizzata per fornire misure di fiducia in base a specifiche esigenze di sicurezza e prove di affidabilità.

Diversi standard di valutazione: Trusted Computer System Evaluation Criteria (TCSEC) Information Technology Securety Evaluation Criteria (ITSEC). Il Common Criteria (CC) ha preso il posto di questi standards come una metodo di valutazione

standard.

Decidere la valutazione

La decisione di valutare un sistema formalmente deve prendere in considerazione i numerosi compromessi tra sicurezza e costo, tra time to market e numero di funzionalità.

Valutatori (a pagamento)= personale qualificato di esperti per sviluppare la documentazione di sicurezza e di garanzia della prova. L'interazione con il valutatore per la formazione, chiarimenti, o correzioni prese e lo sviluppo del personale potrebbero influenzare lo sviluppo e programmi di consegna. La valutazione di sicurezza non può dimostrare che un sistema è invulnerabile agli attacchi. La maggior parte dei sistemi di oggi deve operare in ambienti ostili, e i sistemi devono fornire loro protezione da attacchi e da errori involontari. Oggi, sistemi senza una sicurezza non sono più accettabili.

La valutazione prevede una verifica indipendente da parte di esperti e una misura di affidabilità, che può essere utilizzata per confrontare i prodotti. La verifica indipendente da parte di esperti dell'efficacia dei meccanismi di sicurezza e della correttezza della loro implementazione e delle operazioni è preziosa nella ricerca di vulnerabilità e di difetti in un prodotto o in un sistema.

Un prodotto valutato che è esaminato da esperti di sicurezza, che non hanno progettato o implementato il prodotto possono essere un nuovo punto di vista per l'analisi. È meno probabile che contenga grandi difetti. L'analisi di un sistema inizia con una valutazione di requisiti. I requisiti devono essere coerenti, completi, tecnicamente validi, e sufficientemente capaci di contrastare le minacce al sistema. Valutare in che modo le caratteristiche di sicurezza soddisfano i requisiti è un'altra parte della valutazione.

La valutazione dei programmi necessita di particolari tipi di attività amministrative, dell'utente, dell'installazione, e di altre documentazioni di sistema, informazioni che gli amministratori e manutentori devono fornire per configurare e gestire correttamente il sistema, in modo che i meccanismi di sicurezza funzionino come previsto. La misura della fiducia associato a un prodotto valutato aiuta a trovare la combinazione ottimale di fiducia nel prodotto e nell’ambiente per soddisfare le esigenze di sicurezza.

Prospettiva storica dei metodi di valutazione

Le istituzioni militari e governative sono state le prime conducenti di ricerca in materia di sicurezza del computer.

Essi hanno anche guidato la creazione di un processo di valutazione della sicurezza.

I metodi di valutazione furono usati per lo sviluppo di software sicuri di proprietà del governo e istituzioni militari; metodi utilizzati internamente per prendere decisioni sulla loro sicurezza.

Con la rapida espansione del tecnologia, governo e istituzioni militari hanno voluto usare prodotti commerciali piuttosto che svilupparli da se. Questo ha spinto lo sviluppo di metodologie per affrontare la sicurezza e l’affidabilità di prodotti commerciali. I metodi di valutazione prevedono: requisiti funzionali, di garanzia, e livelli di fiducia in vari formati. Alcuni elenchi di requisiti sono utilizzati per costruire categorie affidabili. Altri solo per la descrizione di una categoria di fiducia.

TCSEC: 1983-1999

Trusted Computer System Evaluation Criteria (TCSEC) (Orange Book) sviluppato dal governo degli Stati Uniti fu il primo grande metodo di valutazione della sicurezza informatica. Esso presenta una serie di criteri per valutare la sicurezza dei prodotti per computer commerciali. Il TCSEC definisce i criteri per sei diverse classi di valutazione individuati dalla loro scala di gradimento con C1, C2, B1, B2, B3, e A1. Ogni classe contiene sia i requisiti funzionali che quelli di garanzia; sono cumulativi e aumentano in tutte le classi di valutazione. Le classi sono suddivise in tre diverse "parti" di minore importanza in singole classi di valutazione. Una quarta parte, D, è stata prevista per prodotti sui quali è stata tentata una valutazione, ma non è riuscita a soddisfare tutti i requisiti di qualsiasi delle sei classi. Il fornitore può scegliere il livello di fiducia da perseguire selezionando una classe di valutazione, ma non può farlo per i requisiti funzionali o di garanzia che devono essere soddisfatti.

Il Trusted Computing Base (TCB) è una generalizzazione del meccanismo di validazione di riferimento (RVM). Il TCB non è tenuto a soddisfare i requisiti RVM per tutte le classi. Nel TCSEC, il TCB non deve soddisfare il RVM fino classe B3.

Un prodotto valutato è un rated product.  

I requisiti funzionali del TCSEC Controllo di accesso discrezionale (DAC). Generano diritti di accesso, granularità(filtro del) di

controllo, e elenchi di controllo di accesso. Riutilizzo dell’oggetto affronta la minaccia di un utente malintenzionato di raccogliere informazioni

da oggetti riutilizzabili come una memoria o un disco di memoria. Affronta poi la revoca dei diritti di accesso da un vecchio proprietario quando l’oggetto riutilizzato viene rilasciato e l'incapacità di un nuovo utente di leggere i contenuti precedenti di questo oggetto riutilizzato.

Controllo di accesso obbligatorio (MAC), non richiesto fino alla classe B1. Descrivono una gerarchia delle etichette(labels). Le etichette apposte a soggetti corrispondono alle autorizzazioni che hanno e che sono state approvate da autorizzazioni di sicurezza. Le etichette apposte agli oggetti riflettono le esigenze di protezione per gli oggetti. Per esempio, un file classificato come "segreto" deve essere protetto a questo livello limitando l'accesso ai soggetti che hanno l’autorizzazione.

Etichetta, non richiesto fino alla classe B1, abilita l'applicazione richiedendo dei controlli di accesso. Sia i soggetti che gli oggetti sono etichettati. Altri requisiti danno un‘esatta rappresentazione delle classificazioni e autorizzazioni, esportando delle informazioni etichettate, e etichettando l’output leggibile agli umani e i dispositivi.

Identificazione e autenticazione (I & A) specifica che un utente si identifica al sistema e che questo dopo il riconoscimento ne consente l’utilizzo. Questi requisiti filtrano l’autenticazione dei dati (per gruppo, per utente, e così via), proteggendo l’autenticazione dei dati, e associando l’identità con le azioni verificabili.

Trusted path (percorso fidato), non richiesto fino alla classe B2, fornisce un grado di comunicazione garantito tra l'utente e il TCB.

Audit (verifica) indicano l'esistenza di un meccanismo di controllo, nonché di protezione della verifica dati. Questi definiscono cosa i registri devono contenere e quali eventi il meccanismo di controllo deve registrare. Come altrove le esigenze aumentano, la serie di eventi verificabili aumenta, causando l’espansione della verifica dei requisiti mentre ci si muove a classi più elevate.

Architettura del sistema: un meccanismo di validazione di interferenza nella prova, un processo di isolamento, il principio del minimo privilegio, e interfacce utente ben definite.

Assurance: - strumento di gestione che richiede la separazione dei ruoli di amministratore e operatore e sono obbligatori a partire dalla classe B2.

- procedura di recupero garantiscono un sicuro recupero dopo un fallimento (o di altre discontinuità). Solo per la classe A1.

- integrità del sistema della diagnostica dell’hardware per validare l’hardware on-site e firmware del TCB.

I requisiti di garanzia della TCSEC

I requisiti di gestione della configurazione per il TCSEC (da B2 in su). Richiedono l'identificazione di elementi di configurazione, mappature coerenti per tutta la documentazione e il codice, e strumenti per la generazione del TCB.

Il requisito di distribuzione fidata vuole l'integrità della mappatura tra la versione master(originale) e quella on-site, nonché le procedure di accettazione del cliente. Solo classe A1.

I requisiti di architettura del sistema TCSEC prevedono la modularità, minimizzazione della complessità, e di altre tecniche per la tenuta del TCB il più piccolo e semplice possibile. Da classe C1 a classe B3.

I requisiti di specifica e verifica di progetto affrontano un gran numero di esigenze individuali, che variano di molto tra le classi di valutazione. Le classi C1 e C2 non hanno questi requisiti. La classe B1 richiede un modello di politica di sicurezza informale coerente. La classe B2 richiede che il modello sia formale, coerente e che il sistema abbia un alto livello di specifiche descrittive (DTLS). La classe B3 richiede che il DTLS sia coerente con il modello di politica di sicurezza. La classe A1 richiede una specifica formale di primo livello (FTLS), e che questi metodi formali approvati siano utilizzati per dimostrare che il FTLS è coerente con il modello di politica di sicurezza. Mappatura tra il FTLS e il codice sorgente.

I requisiti di testing indicano la coerenza con i diritti, resistenza alla penetrazione, e la correzione di difetti seguita da retesting.

I requisiti di documentazione del prodotto sono divisi in una guida utente con caratteristiche di sicurezza (SFUG) e una guida amministratore chiamata Trusted Facility Manual (TFM). I primi hanno una descrizione dei meccanismi di protezione, il modo in cui interagiscono, e il loro uso. Il TFM, invece, fornisce i requisiti per eseguire il prodotto in sicurezza, compresa la generazione, l’avvio, e altre procedure.

Tutte le classi richiedono questa documentazione, e più il livello della classe aumenta tanto più i requisiti funzionali e di garanzia aumento. Documentazione interna include la progettazione e il test, filosofia di protezione e descrizione delle interfacce. La documentazione del test specifica i piani di test, le procedure, le prove, e risultati dei test. La documentazione del test e della progettazione necessaria, aumenta al crescere delle classi.

Classi di valutazione della TCSEC Classe C1, chiamato protezione discrezionale, ha requisiti funzionali minimi solo per

l'identificazione e l’autenticazione e per controlli di accesso discrezionale. I requisiti di garanzia sono anche minimi, copre solo il test e la documentazione. Questa classe è stato utilizzata solo per un breve periodo, e nessun prodotto è stato valutato in questa classe dopo il 1986.

Classe C2, chiamato protezione di accesso controllato, richiede il riuso di oggetti e verifica(auditing) in aggiunta ai requisiti funzionali della classe C1 e contiene alcuni più severi test di sicurezza. Questo è stata la classe più comunemente utilizzata per i prodotti commerciali.

Classe B1, chiamata protezione della sicurezza etichettata, richiede l'obbligo di controlli di accesso, che possono essere limitati a un determinato insieme di oggetti. L’etichetta sostiene l'implementazione MAC. Test di sicurezza più severi. Un modello informale di politica di sicurezza valido. Molti fornitori di sistema operativo hanno offerto un prodotto di classe B1 in aggiunta ai loro prodotti primari. Purtroppo, però, i prodotti B1 non sempre ricevono gli aggiornamenti in tecnologia che la linea principale ha ricevuto, e che spesso resta obsoleta tecnicamente.

Classe B2, chiamata protezione strutturata, è accettabile per alcune applicazioni di governo. L’obbligo di controllo di accesso è richiesto per tutti gli oggetti. Etichettatura è estesa, e un percorso fidato per il login è introdotto. Classe B2 richiede l'uso del principio del minimo privilegio per limitare l'assegnazione del privilegio agli utenti meno tenuti ad eseguire il compito specifico. Requisiti di assurance comprendono le analisi del canale privato, la gestione della configurazione, una più consistente documentazione, e un modello formale di politica di sicurezza coerente.

Classe B3, chiamati domini di sicurezza, attua un meccanismo di validazione migliore. Aumentano i requisiti di affidabilità del percorso e vincola che il codice sia sviluppato in termini di modularità, semplicità, e uso di tecniche come la stratificazione e il nascondimento dei dati. Ha dei requisiti di garanzia significativi, test più severi, più requisiti sulla DTLS, una guida per l’amministratore, e la documentazione di progetto.

Classe A1, chiamato protezione verificata, differisce dalla B3 nella garanzia. Richiede l’utilizzo di metodi formali nell’analisi del canale privato, di specifiche di progetto, e di verifica. Si richiede inoltre la distribuzione fidata, aumentano sia i requisiti del test che la documentazione di progetto. Una corrispondenza tra il codice e il FTLS è obbligatorio.

Il processo di valutazione della TCSEC

La fase di valutazione è stata suddivisa in analisi di progettazione, analisi del test, e revisione finale.

I risultati ottenuti dal gruppo di valutazione venivano presentati al consiglio di revisione tecnica (TRB), il quale approvata questa parte della valutazione poteva andare alla fase successiva.

1. L’analisi di progetto consisteva di una rigorosa revisione del sistema di progettazione basata sulla documentazione fornita. Perché i valutatori della TCSEC non leggono il codice sorgente, impongono però requisiti severi sulla completezza e la correttezza della documentazione. I valutatori sviluppano la relazione di valutazione iniziale del prodotto (IPAR) per questa fase.

2. Le analisi del test includevano un’approfondito test di copertura, nonché l'esecuzione dei test forniti dal venditore.

3. Il gruppo di valutazione produceva una relazione di valutazione finale (FER) dopo l'approvazione dell’IPAR (relazione di valutazione iniziale del prodotto) e il test di revisione. Una volta che il consiglio di revisione tecnica aveva approvato la relazione di valutazione finale, e il venditore e i valutatori hanno chiuso tutti termini, la categoria veniva assegnata.

The Ratings Maintenance Program (RAMP) mantiene la garanzia per le nuove versioni di un prodotto valutato. Il fornitore ha la responsabilità dell'aggiornamento a sostegno della garanzia del prodotto, delle modifiche e dei miglioramenti. Un consiglio di revisione tecnica esaminava la relazione del venditore e, una volta approvata, il grado di valutazione veniva assegnato alla nuova versione del prodotto. RAMP non accettava tutte le migliorie. Per esempio, cambiamenti strutturali e aggiunta di alcune nuove funzioni potevano richiedere una nuova valutazione.

Impatti

Il TCSEC creò un nuovo approccio per valutare la sicurezza del prodotto. Basato sull’analisi di progettazione, implementazione, documentazione, e delle procedure.

La prima tecnologia di valutazione; ha imposto diverse basi per le metodologie future. I concetti di valutazione delle classi, i requisiti di assurance e di assurance basata su valutazioni sono fondamentali per la valutazione di oggi.

Il TCSEC ha fissato elevati standard tecnici per la valutazione. La tecnica approfondita dalle valutazioni TCSEC viene dalla forza della fondazione dei requisiti e delle classi, dal rigore del processo di valutazione, e dai controlli e bilanci forniti dai revisori all'interno del gruppo di valutazione e dal consiglio di revisione tecnica e da un gruppo di valutazione esterno.

Tuttavia, il TCSEC era lontano dall'essere perfetto. Il suo campo di applicazione era limitato. Il processo di valutazione era difficile e spesso privo di risorse necessarie. Il TCSEC fissa l’affidabilità e la funzionalità insieme alla valutazione delle classi, cosa che ha turbato alcuni utenti. Infine, le valutazioni del TCSEC erano riconosciuti solo negli USA, e le valutazioni di altri paesi non erano validi negli Stati Uniti.

Limitazioni dell’applicazione

Il TCSEC fù scritto per i sistemi operativi e non si traduceva anche per altri tipi di prodotti o di sistemi. Focalizzato sulla esigenze di sicurezza degli stabilimenti degli Stati Uniti e del governo militare, che ha finanziato lo sviluppo. Tutte le classi di valutazione, salvo C1 e C2 devono avere obbligatoriamente il controllo di accesso, che la maggior parte degli ambienti commerciali non utilizza. Il TCSEC non fornisce Integrità, disponibilità, o altri requisiti critici per applicazioni commerciali.

La National Computer Security Center (NCSC) ha cercato di affrontare questi problemi, fornendo criteri per altri tipi di prodotti. Dopo un tentativo di definire un documento di criteri per le reti, il NCSC scelse di sviluppare la Trusted Network Interpretation (TNI), del TCSEC, pubblicato nel 1987. TNI offriva due approcci: valutazione delle reti e la valutazione delle componenti di rete.

Nella prima parte del TNI, i criteri della TCSEC furono interpretati per le reti, la quale si poteva valutare allo stesso livello della TCSEC.

La seconda parte del TNI offriva una valutazione delle componenti di rete. Un componente di rete può essere progettato per fornire un sottoinsieme di funzioni di sicurezza della rete nel suo complesso. TNI potrebbe fornire una valutazione in base alle specifiche di funzionalità che la componente offre.

Nel 1992, fù rilasciato il Trusted Database Management System Interpretation (TDI) del TCSEC. Nei primi anni del 1990, IBM e Amdahl furono spinti per un Trusted Virtual Machine Monitor Interpretation del TCSEC, ma questo progetto venne abbandonato. Le interpretazioni hanno dovuto affrontare questioni che erano esterne al campo di applicazione del TCSEC, e ognuna aveva limitazioni che restringevano la loro utilità. Non molti valutazioni erano risultate dal TNI o TDI.

Limitazioni di processo

Il metodo do valutazione del TCSEC ha avuto due problemi fondamentali. Il primo è stata la graduale espansione dei requisiti che ha definito le

valutazione delle classi TCSEC. Valutatori hanno riscontrato che era necessario interpretare i criteri da applicare a prodotti specifici. Invece di pubblicare frequenti revisioni della TCSEC per affrontare questi requisiti di interpretazioni, il NCSC scelse di sviluppare un processo per l'approvazione di interpretazioni e di pubblicarli come un informale addendum alla TCSEC. Nel corso del tempo, l'elenco è diventato molto grande e si estendeva il campo di applicazione dei singoli criteri in TCSEC e la sue interpretazioni. I requisiti delle classi divennero l'unione dei requisiti del TCSEC e la serie delle interpretazioni applicabili. Così, un sistema operativo di classe C2 doveva soddisfare più requisiti di un sistema valutato pochi anni prima. Questo dava un ulteriore costo per i prodotti più recenti in corso di valutazione e ha fatto sì che la sicurezza minima di tutti i sistemi operativi della C2 non fosse la stessa.

Il secondo problema con il processo di valutazione è stato che le valutazioni prendevano troppo tempo. Tre fattori hanno contribuito a questo problema. Molti fornitori fraintendevano la profondità della valutazione e la richiesta di interazioni con i gruppi di valutazione. Le pratiche della valutazione di gestione causavano incomprensioni e problemi di programmazione. Infine, la motivazione per completare una libera valutazione spesso mancava. In genere, entrambi fornitori e valutatori causavano ritardi nella pianificazione: spesso i fornitori dovevano fare ulteriori commesse di lavoro; i valutatori erano assegnati a più valutazioni, e ciò poteva causare ritardi ai fornitori. Molte delle valutazioni andava così per le lunghe che il prodotto era ormai obsoleto prima dell’assegnazione del rating. Verso la fine del ciclo di vita del TCSEC, i laboratori commerciali approvati dal governo, furono autorizzati a fare valutazioni TCSEC contro pagamento di una tassa. I fornitori dovevano essere preparati per la valutazione, e l’interazione tra valutatori e venditori non era affatto diminuita. Un problema era che i cicli RAMP erano così difficili, che le valutazioni soffrivano di ritardi. Di conseguenza, non venne utilizzato molto il RAMP.

Contributi

Il TCSEC ha previsto un processo di valutazione per la sicurezza dei prodotti in commercio. La sua esistenza ha accresciuto la consapevolezza del settore commerciale di esigenze di sicurezza per computer. Questa consapevolezza sarebbe derivata successivamente, anche senza l'influenza del TCSEC. Nel 1990, nuove varietà di prodotti emergevano, compresi i controllori del virus, firewall, reti private virtuali, implementazioni IPsec, e di moduli crittografici. Il TCSEC rimasta concentrata sui sistemi operativi, le sue interpretazioni erano insufficienti per valutare tutti i tipi di reti o la nuova varietà di prodotti. Il settore commerciale era insoddisfatto dei requisiti funzionali della valutazione di classi. Queste carenze del TCSEC ha stimolato un'ondata di nuovi approcci in materia di valutazione che ha influenzato significativamente la tecnologia della valutazione. Organizzazioni commerciali scrissero i propri criteri. Altri organizzazioni commerciali offrivano un pass di "certificazione" basata su test. Computer Security Act del 1987 ha dato la responsabilità per la National Security Agency (NSA) per la sicurezza dei sistemi di elaborazione classificati e le informazioni pertinenti la sicurezza nazionale. Il National Institute of Standards and Technology (NIST) ha ricevuto una carta per i sistemi di elaborazione di informazioni sensibili e non classificati. Nel 1991, NIST e NSA iniziarono a lavorare su nuovi criteri di valutazione chiamati Criteri Federali (FC). Tutte queste attività scaturirono dall'impatto del TCSEC.

Gli sforzi internazionali e la ITSEC: 1991-2001

Dal 1990, diversi paesi occidentali avevano sviluppato i propri criteri di valutazione della sicurezza.

Canada rilasciò la prima versione del Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) nel 1989. Il CTCPEC faceva affidamento sulla TCSEC, ma inserendo alcune nuove idee con le successive uscite sposando ad esempio la separazione di assurance e funzionalità. Esso offre un elenco di requisiti funzionali in diverse categorie. Introduce il concetto di funzionalità di "profili" basato su una serie di requisiti ben definiti dall’elenco. Affronta anche nuove aree di requisiti funzionali come l'integrità, la disponibilità e la assurance di nuovi settori come l'ambiente di sviluppo.

Alcuni paesi dell'Europa occidentale - in particolare, Francia, Germania, Regno Unito e Paesi Bassi – ebbero anche loro da quel momento dei criteri di valutazione della sicurezza.

La mancanza di reciprocità tra valutazione delle nazioni europee creò un movimento per armonizzare i criteri di questi paesi, l’Information Technology Security Evaluation Criteria (ITSEC), che divenne lo standard europeo dal 1991. L'Unione europea appoggiò ufficialmente il ITSEC raccomandadolo dal Consiglio dell'Unione europea nel 1995. Il ITSEC fù ampiamente utilizzato per un periodo di 10 anni fino alla nascita dei Common Criteria (CC). Il ITSEC affronta con successo alcune delle carenze del TCSEC. Creando però una nuova serie di difetti propri.

Il ITSEC prevede sei livelli di fiducia, chiamati livelli di valutazione, E1, E2, E3, E4, E5 e E6. Un settimo livello, E0, è stato utilizzato per prodotti che non soddisfano altri livelli. Un sistema correttamente valutato dal ITSEC veniva chiamato “prodotto certificato” o “sistema certificato”. ITSEC non ha fornito i criteri funzionali. È necessario il venditore per definire i criteri funzionali di sicurezza in un Security Target (ST). Questo divise funzionalità e assurance in distinte categorie. Avere requisiti funzionali definiti dal fornitore o esternamente ha consentito di valutare qualsiasi tipo di prodotto o sistema.

Un Target of evaluation (TOE) (obiettivo di valutazione) è un prodotto o un sistema, con il suo amministratore e documentazione utente associata, oggetto di una valutazione.

Requisiti di assurance dell’ITSEC

Requisiti di assurance dell’ITSEC simili a quelli della TCSEC (differenze terminologiche). Come in TCSEC, sono stati definiti i requisiti di assurance secondo i livelli di valutazione. L’assurance nell’ITSEC era considerata in termini di correttezza ed efficacia. Ci sono sei requisiti di efficacia applicati in modo uniforme a tutti i livelli di valutazione ITSEC.

Idoneità dei requisiti. Questo dà coerenza e copertura agli obiettivi di sicurezza(ST) mostrando come i requisiti di sicurezza e ipotesi ambientali siano sufficienti a contrastare le minacce definite nella ST.

Vincoli dei requisiti. Questa analisi ha esaminato i requisiti di sicurezza e i meccanismi che l’hanno implementato. Devono essere entrambi supportati e devono garantire un sistema di sicurezza efficace e integrato.

L’ITSEC richiede una valutazione delle misure di sicurezza utilizzate durante lo sviluppo e la manutenzione del prodotto o del sistema. Il TCSEC non ha avuto tale requisito.

Dal livello E2, il ITSEC richiede che sia definita una corrispondenza tra tutti i livelli di rappresentazione del TOE.

Il TCSEC richiede solo una mappatura dal primo livello di specifica al codice (solo per le classi di valutazione più alte). Il ITSEC ha i requisiti per compilatori e linguaggi che il TCSEC non ha.

Il ITSEC necessita della presentazione del codice sorgente a diversi livelli e del codice oggetto al più alto livello. Le valutazioni nel TCSEC sono state fatte senza esaminare il codice.

I requisiti dell’ITSEC affrontano questioni per le procedure di consegna e per le procedure di distribuzione approvate, mentre le TCSEC usa esperti in processi di distribuzione. Inoltre, i requisiti di distribuzione iniziano al livello più basso della ITSEC, mentre il TCSEC lo richiede solo al livello più alto.

I requisiti di inizio sicuro e di funzionamento nell’ITSEC sono previsti in più aspetti che nel TCSEC, il quale li prevede solo dopo il recupero di una discontinuità.

L'efficacia dei requisiti richiesti dall’ITSEC ha diverse forme di valutazione della vulnerabilità che la TCSEC non richiede.

Il progetto di analisi della vulnerabilità a livello di progettazione non ha equivalenti nel TCSEC.

Livelli di valutazione dell’ITSEC

I livelli dell’ITSEC sono elencati dal più basso al più alto. Ogni livello include i requisiti del precedente livello. Se un prodotto o un sistema non soddisfa i requisiti di qualsiasi livello, è valutato come livello E0 (che corrispondeva nella TCSEC al livello D).

1. Il Livello E1 richiede un obiettivo di sicurezza (ST) per valutare il prodotto o il sistema; una descrizione informale dell’architettura del prodotto/sistema. Il prodotto/sistema deve essere in grado di dimostrare che il suo ST è soddisfatto.

2. Livello E2 richiede una descrizione informale di progettazione dettagliata del prodotto/sistema del TOE, come pure il controllo di configurazione e di un processo di controllo della distribuzione. Prove di collaudo deve essere fatta.

3. Livello E3 ha requisiti più severi sui dettagli di progettazione ed è anche necessaria una corrispondenza tra il codice sorgente e i requisiti di sicurezza.

4. Livello E4 richiede anche di un modello formale della politica di sicurezza, un più rigoroso approccio strutturato all’architettura e di progettazione dettagliata, e di un’analisi di vulnerabilità a livello di progettazione.

5. Livello E5 richiede una corrispondenza tra il progetto dettagliato e il codice sorgente, e un’analisi di vulnerabilità a livello di codice sorgente.

6. Livello E6 richiede anche un ampio uso di metodi formali. Un'altro requisito è la mappatura parziale del codice eseguibile per il codice sorgente.

Il processo di valutazione ITSEC

Ogni paese partecipante ha la propria metodologia di valutazione sotto l’ITSEC. Tutti seguono delle linee guida simili. Useremo la metodologia certificata dal Regno Unito. Certified, licensed evaluation facilities (CLEFs) effettua valutazioni per contro di una tassa. CLEFs ha una parte di valutazione e una di consulenza.

Poiché le tasse sono state coinvolte, tutte le parti sono state motivate a completare la valutazione in tempi brevi.

1. Valutazione degli obiettivi di sicurezza, sulla base di requisiti di garanzia e di idoneità.

2. I valutatori valutavano il prodotto secondo gli obiettivi di sicurezza (ST).

3. La documentazione necessaria per la ITSEC seguiva una struttura un po’ più rigida di quella del TCSEC, rendendo più facile per i produttori di fornire utili elementi di prova ai valutatori. Quando la documentazione è insufficiente i valutatori della TCSEC leggono il codice per chiarimenti.

4. Schema di certificazione della manutenzione molto semplice. È richiesto un test a sostegno della corretta implementazione del piano.

Non ha una revisione tecnica come quelle del consiglio di revisione tecnica del TCSEC.

Nonostante ci siano requisiti di assurance più significativi in alcuni settori, le valutazioni ITSEC sono state spesso viste tecnicamente inferiori alle valutazioni TCSEC per due motivi.

Il primo è stata la possibile debolezza nello sviluppo di requisiti funzionali. Valutazione del processo stesso poco rigoroso. Un altro limite delle ITSEC è stata la mancanza di

reciprocità di valutazione con il Canada e gli Stati Uniti. Purtroppo, non sempre i fornitori sono esperti qualificati in sicurezza per sviluppare obiettivi di

sicurezza appropriati. Questo ha sollevato la preoccupazione per il fatto che le valutazioni ITSEC non determinano se una richiesta ha senso, ma si limita a verificare che il prodotto le soddisfi. In effetti, la valutazione dell’obiettivo di sicurezza (ST) è stato spesso un lavoro di uno o due individui. Non da un consiglio di esperti (come il TCSEC) che valuta la qualità del lavoro dei valutatori.

Il Common Criteria: 1998La 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; 

TCSEC (1985)

ITSEC  (1991) in Europa

CTCPEC (1993) in Canada

Federal Criteria (1993) negli Stati Uniti.

Esigenza di una metodologia comune Risultati confrontabili

COMMON CRITERIA (CC)

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. CC utilizza i seguenti termini:

La TOE Security Policy (TSP), è un insieme di norme che regolano come l’attività viene gestita, protetta e distribuita all'interno di un prodotto o di un sistema.

La TOE Security Functions (TSF), è un insieme composto di tutto l'hardware, Software, e il firmware del prodotto o del sistema che deve essere invocato per la corretta applicazione della TSP.

Descrizione generale del Metodologia (1) La filosofia che è alla base dei CC è stata ripresa dai precedenti criteri europei ITSEC.

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).

Un obiettivo di sicurezza (ST) 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.

Descrizione generale del Metodologia (2)Le verifiche, eseguite in base ai requisiti di assurance del livello di valutazione considerato, hanno lo scopo di

fornire garanzie circa:

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

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

- l'adeguatezza delle procedure di sicurezza previste per la consegna e per l'installazione del sistema/prodotto ; la chiarezza dei manuali d'uso e 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

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).

Le funzioni di sicurezza del sistema/prodotto vengono descritte in base ai requisiti da soddisfare. Tali requisiti, denominati requisiti funzionali, così come i già citati requisiti di assurance, devono essere espressi utilizzando un catalogo di componenti fornito nei CC (parte 2 dei CC), (mentre componenti di assurance parte 3). I cataloghi sono strutturati su più livelli gerarchici in modo da raccogliere componenti di tipo omogeneo.

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

Corrispondenza dei livelli di fiduciaLa tabella seguente dà una vaga corrispondenza dei livelli di fiducia delle diverse metodologie. La tabella indica che il CC offre un livello che è inferiore a qualsiasi livello precedentemente offerto.

TCSEC ITSEC CC D E0 No equivalent

No equivalent No equivalent EAL1 C1 E1

EAL2 C2 E2 EAL3

B1 E3 EAL4

B2 E4 EAL5 B3 E5 EAL6 A1 E6 EAL7

FINE