Mentre il Dipartimento della Difesa degli Stati Uniti utilizzava propri criteri per la valutazione della sicurezza dei sistemi e prodotti IT intitolati Trusted Computer System Evaluation Criteria [TCSEC] e, comunemente, nota come Orange Book (Libro arancione), altri paesi europei hanno elaborato propri criteri per la valutazione della sicurezza dei prodotti IT. Nel Regno Unito, a esempio, è il caso del Memorandum Number 3, elaborato a uso del governo, e delle proposte del Dipartimento dell'Industria e Commercio, denominate Green Book (Libro Verde). In Germania, l'Ente per la sicurezza dell'informazione ha pubblicato, nel 1989, una prima versione dei propri criteri; allo stesso tempo, in Francia, sono stati elaborati criteri denominati Livre bleu-blanc-rouge (Libro bianco, rosso e blu).

In seguito la Francia, la Germania, i Paesi Bassi e il Regno Unito hanno riconosciuto la necessità di accostarsi al problema in modo armonizzato e di definire criteri di sicurezza IT comuni in quanto i singoli paesi avevano accumulato una vasta esperienza, su cui sarebbe stato assai vantaggioso fondare gli ulteriori sviluppi; le industrie erano contrarie all'adozione di criteri di sicurezza diversi in ogni paese; i concetti e gli approcci di base adottati dai vari paesi coincidevano, anche per quanto riguarda le varie applicazioni in ambito commerciale, governativo e militare. Uno dei motivi, quindi, dell'elaborazione di questi criteri comuni, che sono stati denominati Information Technology Security Evaluation Criteria (ITSEC), è stato la volontà di costituire una base comune per l'attività di certificazione svolta dagli organismi nazionali, con l'obiettivo finale di consentire il mutuo riconoscimento dei risultati delle valutazioni.

Nel 1991 si è giunti ad una completa definizione dei criteri ITSEC che sono stati nello stesso anno fatti propri dalla Comunità Europea.

Ogni sistema o prodotto IT presenta requisiti specifici, che ne garantiscono la riservatezza, l'integrità e la disponibilità.

Per soddisfare tali requisiti occorre implementare diverse misure tecniche di sicurezza, denominate funzioni di sicurezza riguardanti, a esempio, settori quali il controllo di accesso, l'audit e il recupero da errore. Per ITSEC, l'oggetto della valutazione è il TOE (Target of Evaluation) e lo sponsor è chi richiede la valutazione.

La valutazione viene fatta prendendo a riferimento il security target che è un documento che deve contenere almeno: una System Security Policy (nel caso dei sistemi) o un Product Rationale (nel caso dei prodotti); una specifica delle funzioni di sicurezza (Security Enforcing Functions o SEF) che permettono il conseguimento degli obiettivi individuati; la definizione dei meccanismi di sicurezza richiesti (opzionale); il livello minimo dichiarato di robustezza dei meccanismi (strength of mechanisms); il livello di valutazione desiderato.

Col termine SEF (Security Enforcing Function), si intendono le contromisure raggruppate secondo un certo numero di categorie, dette Generic Headings.

La valutazione si basa sul concetto di garanzia (assurance) offerta dal sistema stesso che si caratterizza per: la correttezza (correctness) nel modo di concretizzare le funzioni di sicurezza e dei relativi meccanismi d'attuazione (mechanisms); la fiducia nella loro efficacia (effectiveness).

Le funzioni di sicurezza sono le contromisure di cui, in sede di redazione degli obiettivi di sicurezza (Security Target), si decide l'adozione e descrivono le contromisure in chiave concettuale con orientamento alla loro funzionalità. Possono essere rappresentate sia da prodotti che da procedure di carattere organizzativo ed operativo. Le singole funzioni di sicurezza vengano raggruppate, in generic headings. ITSEC prospetta otto tipologie di funzioni di sicurezza (generic headings) che comunque possono essere integrate da nuove tipologie, con l'evoluzione delle tecnologie e delle tipologie d'attacco. Le tipologie indicate da ITSEC sono:

Stabiliscono e verificano l'identità che dichiara un utente che intende accedere al sistema informatico. L'identificazione avviene usualmente controllando la corrispondenza tra le informazioni fornite dall'utente e le informazioni associate all'utente e note al sistema di protezione.

Garantiscono che un utente possa espletare le sole operazioni di propria competenza.

A questo gruppo appartengono le funzioni il cui scopo è controllare il flusso delle informazioni fra processi e l'uso delle risorse da parte dei processi stessi.

Registrano gli accessi alle varie risorse del sistema. A questo gruppo appartengono tutte le funzioni che hanno lo scopo di lasciare traccia delle azioni dei suoi utenti, in modo da riconoscere chi ha operato.

Permettono di indagare sugli eventi anomali o sopra determinati livelli che possono rappresentare una minaccia alla sicurezza. A questo gruppo appartengono le funzioni che hanno lo scopo di registrare ed analizzare gli eventi, oppure le funzioni che effettuano analisi statistiche al fine di individuare eventuali attacchi alla sicurezza.

Garantiscono il riutilizzo di spazi di memoria, impedendo che ciò costituisca minaccia alla sicurezza. A questo gruppo appartengono le funzioni il cui scopo è quello di cancellare o inizializzare i supporti in modo che possano essere riutilizzabili

Garantiscono l'integrità del SW e dei dati. A questo gruppo appartengono le funzioni il cui scopo è quello di effettuare analisi del SW e dei dati per segnalare, identificare e correggere eventuali violazioni

A questo gruppo appartengono le funzioni il cui scopo è quello di assicurare che le risorse siano accessibili ed utilizzabili su richiesta di qualunque utente abilitato, entro i tempi prefissati

A questo gruppo appartengono le funzioni il cui scopo è quello di assicurare disponibilità, riservatezza ed integrità ai canali trasmissivi.

Con il termine Assurance si intende sia la fiducia (confidence) nell'efficacia (effectiveness) delle funzioni di sicurezza, sia la fiducia nella loro correttezza (correctness).

La valutazione dell'efficacia mira a stabilire, tra l'altro, se le funzioni di sicurezza adottate sono idonee agli scopi -specificati nel Security Target- per cui sono state scelte e se i meccanismi che realizzano tali funzioni sono in grado di contrastare attacchi diretti.

Quest'ultimo aspetto viene misurato sulla base della cosiddetta "robustezza dei meccanismi" (strenght of mechanisms) per la quale sono stati definiti tre livelli: Base, Medio e Alto.

La fiducia nella correttezza viene espressa utilizzando una scala a sette livelli (da E0 ad E6) nella quale il livello più basso indica totale mancanza di fiducia.

Il processo di valutazione ai fini di una certificazione del sistema stesso consisterà nello stabilire se esso soddisfa o meno il suo Security Target con il livello di valutazione dichiarato del committente (ITSEC lo definisce Sponsor) e indicato nel Security Target stesso.

ITSEC definisce la robustezza dei meccanismi di sicurezza (Strenght of Mechanism -SOM) come la loro capacità di resistere ad un attacco diretto.

Vengono definiti tre possibili gradi di robustezza (Base, Medio e Alto) che rappresentano crescenti livelli di capacità del meccanismo di sicurezza di resistere ad un attacco diretto.

Nel rispetto di quanto contenuto in ITSEC la robustezza, di un meccanismo di sicurezza critico può essere definita come:

BASE se al minimo fornisce protezione contro eventi sovversivi casuali, benché possa essere violata da alcuni aggressori;

MEDIA se al minimo fornisce protezione contro aggressioni caratterizzate da limitate opportunità o risorse;

ALTA se può essere superata solo da aggressioni caratterizzate da un alto livello di esperienza, opportunità e risorse, con attacchi portati con successo al di sopra della normale praticabilità.

Nel documento ITSEM (Annex 6.C) vengono definite le modalità di determinazione del grado di robustezza del meccanismo basate su:

tempo necessario per violare il meccanismo (minuti, giorni, mesi);

complicità necessaria (senza complici, con un utente, con un responsabile);

esperienza tecnica necessaria (diffusa, professionale, esperto);

tipo di attrezzatura da utilizzare (nessuna, apparecchiatura normale oppure speciale).

I livelli previsti variano da E0 ad E6, secondo crescenti livelli di fiducia.

La normativa ITSEC prevede la valutazione dell'efficacia e della correttezza del sistema di protezione.

Al crescere del livello di valutazione desiderato, lo sponsor deve fornire al valutatore documentazione che attesti un crescente rigore e l'introduzione di strumenti formali nelle varie fasi costruttive.

Il processo di sviluppo è stato logicamente suddiviso in quattro fasi:

Per ciascuna fase lo sponsor deve presentare documentazione adeguata al livello di protezione desiderato.

Al livello E1, il Security Target deve descrivere per sommi capi il modo con cui le funzioni di sicurezza proposte soddisfano gli obiettivi di sicurezza e contrastano le minacce.

Al Livello E6, il Security target deve fornire una dettagliata spiegazione (to explain) del modo con cui le funzioni di sicurezza soddisfano gli obiettivi di sicurezza e contrastano le minacce e della congruenza tra la politica di sicurezza ed il modello formale di sicurezza realizzato dal sistema di protezione.

Al livello E1, lo sponsor deve fornire una descrizione informale dell'architettura generale del sistema. Al livello E6, la descrizione deve essere di tipo formale e deve includere una dettagliata spiegazione che convinca della congruità tra la politica di sicurezza e l'architettura del sistema.

Al livello E1, lo sponsor non deve fornire alcuna informazione, mentre ai livelli successivi la documentazione deve essere costituita da un dettagliato progetto del sistema (il livello di dettaglio deve essere tale da poter essere utilizzato come base per la programmazione e costruzione dello hardware. Più precisamente, al livello E2 è richiesta una descrizione informale, mentre dal livello E4 in avanti, tale descrizione deve essere di tipo semi-formale.

Al livello E1, lo sponsor non è tenuto a fornire alcuna documentazione.

Ai livelli più elevati, lo sponsor deve fornire una raccolta di test usati per verificare la correttezza delle funzioni di sicurezza, e argomentare l'adeguatezza dei test scelti. Inoltre, dal livello E2 in avanti la documentazione fornita deve comprovare, a crescenti livelli di approfondimento, anche la corrispondenza tra il progetto dettagliato e il software e lo hardware che costituiscono il sistema di valutazione.

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