EVALUATING SYSTEMS
Autore: Candido Fabio
Prof.: 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.
2.
3.

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.
Le analisi del test includevano un’approfondito test di copertura, nonché l'esecuzione dei test
forniti dal venditore.
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.
2.
3.
4.
5.
6.
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.
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.
Livello E3 ha requisiti più severi sui dettagli di progettazione ed è anche necessaria una
corrispondenza tra il codice sorgente e i requisiti di sicurezza.
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.
Livello E5 richiede una corrispondenza tra il progetto dettagliato e il codice sorgente, e un’analisi
di vulnerabilità a livello di codice sorgente.
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: 1998
La necessità di avere delle garanzie, sui prodotti e i sistemi usati, che siano in grado di ottenere adeguati obiettivi di
sicurezza è cominciata già dal 1985 con gli "Orange Book" - TCSEC.
Da allora vari governi hanno dato vita ad iniziative focalizzate allo sviluppo di criteri di valutazione della sicurezza,
costruiti sui concetti evidenziati dai TCSEC;

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 fiducia
La 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
C1
C2
No equivalent
E1
E2
EAL1
EAL2
EAL3
B1
E3
EAL4
B2
B3
A1
E4
E5
E6
EAL5
EAL6
EAL7
FINE