Common Criteria e ITSEC: le certificazioni di

Transcript

FACOLTÀ DI INGEGNERIA
Corso di laurea in Ingegneria delle Telecomunicazioni
Tesi di laurea di secondo livello
Common Criteria e ITSEC: le
certificazioni di sicurezza
Laureando
Marco Giovinazzi
Matricola: 788957
Relatore
Chiarissimo Professore
Marco Listanti
Relatore Esterno
Dr. Michele Bianco
AIEA – Associazione Italiana Information Systems Auditors
Milano Charter of ISACA - Information Systems Audit and Control Association
Anno accademico 2006-2007
Common Criteria e ITSEC: le certificazioni di sicurezza
A mio padre, per la tenacia che mi ha sempre insegnato ad avere.
A mia madre, per l’amore e la comprensione
che mi ha riservato e trasmesso ogni giorno.
A mio nonno, costante riferimento e maestro di vita,
perché so che questo mio successo sarebbe stato anche il suo.
2
Indice Generale
1.
INTRODUZIONE ............................................................................................................................ 5
2.
CONSIDERAZIONI SULLA SICUREZZA ...................................................................................... 7
3.
LA CERTIFICAZIONE DI SICUREZZA........................................................................................ 11
4.
3.1.
CERTIFICAZIONI CORRENTEMENTE UTILIZZATE ......................................................................... 22
3.2.
PANORAMICA STORICA............................................................................................................ 23
3.3.
ATTUALE QUADRO NORMATIVO ................................................................................................ 25
3.4.
AMBITI DI CERTIFICAZIONE ...................................................................................................... 27
3.5.
VANTAGGI E SVANTAGGI DELLA CERTIFICAZIONE ...................................................................... 30
GLI STANDARD DI VALUTAZIONE PER I SISTEMI/PRODOTTI ICT ....................................... 33
4.1.
4.1.1.
Descrizione dello standard .......................................................................................... 35
4.1.2.
Utilizzo dello standard.................................................................................................. 45
4.1.3.
Vantaggi e svantaggi dello standard ........................................................................... 47
4.2.
6.
ITSEC................................................................................................................................... 52
4.2.1.
Descrizione dello standard .......................................................................................... 53
4.2.2.
Utilizzo dello standard.................................................................................................. 57
4.2.3.
Vantaggi e svantaggi dello standard ........................................................................... 58
4.3.
5.
COMMON CRITERIA ................................................................................................................ 33
GLI STANDARD A CONFRONTO ................................................................................................. 59
LO SCHEMA NAZIONALE........................................................................................................... 62
5.1.
I SOGGETTI COINVOLTI NELLA CERTIFICAZIONE ......................................................................... 63
5.2.
STRUTTURA E DESCRIZIONE DELLO SCHEMA ............................................................................ 65
5.3.
IL PROCESSO DI VALUTAZIONE E CERTIFICAZIONE SECONDO LO SCHEMA ................................... 70
5.4.
MUTUO RICONOSCIMENTO ...................................................................................................... 76
5.5.
LA STRATEGIA ITALIANA PER LA DIFFUSIONE DELLA CERTIFICAZIONE ......................................... 77
IL LABORATORIO DI VALUTAZIONE PER LA SICUREZZA (LVS) .......................................... 81
6.1.
COSA RAPPRESENTA .............................................................................................................. 81
7.
8.
9.
6.2.
LE ATTIVITÀ E LE RESPONSABILITÀ .......................................................................................... 83
6.3.
ORGANIGRAMMA E FIGURE PROFESSIONALI ............................................................................. 88
6.4.
IL RAPPORTO CON LA SOVRASTRUTTURA AZIENDALE ................................................................ 95
PROGETTAZIONE DI UN LABORATORIO DI VALUTAZIONE ................................................. 97
7.1.
IL CONTESTO NORMATIVO ....................................................................................................... 98
7.2.
IMPIANTO DOCUMENTALE E GESTIONE DELLA DOCUMENTAZIONE ............................................. 101
7.3.
LA STRUTTURA FISICA ........................................................................................................... 104
7.4.
LA STRUTTURA IT ................................................................................................................. 109
7.5.
GLI ASPETTI DI SICUREZZA .................................................................................................... 129
IL PROCESSO DI ACCREDITAMENTO.................................................................................... 132
8.1.
LE STRUTTURE COINVOLTE ................................................................................................... 133
8.2.
FASI DEL PROCESSO............................................................................................................. 136
8.3.
VALIDITÀ E MANTENIMENTO DEL CERTIFICATO DI ACCREDITAMENTO ........................................ 140
CONSIDERAZIONI FINALI E CONCLUSIONI........................................................................... 142
INDICE DELLE ILLUSTRAZIONI ....................................................................................................... 146
INDICE DELLE TABELLE .................................................................................................................. 147
BIBLIOGRAFIA................................................................................................................................... 148
4
1. Introduzione
Il presente lavoro ha il duplice scopo di introdurre e descrivere le certificazioni di
sicurezza per prodotti o sistemi operanti nel settore dell'Informazione e della
Comunicazione secondo gli standard Common Criteria e ITSEC, e di fornire un
esempio progettuale di come sia possibile creare una struttura dedicata ad attività di
valutazione secondo quanto stabilito dalla normativa vigente.
Il percorso che verrà seguito per raggiungere questo obiettivo partirà dalla
definizione dei concetti base in materia di sicurezza ICT e di certificazione, seguiti da
una analisi dello stato dell'arte nel contesto degli standard di valutazione ad oggi
disponibili e delle differenti aree di applicazione. L'attenzione verrà quindi spostata
sugli standard Common Criteria e ITSEC, sullo stato della normativa vigente in
materia e sulle attività ad essa collegate. Verrà infine presentato un esempio
progettuale di un Laboratorio di Valutazione secondo le specifiche dettate dallo
Schema Nazionale ed analizzato il processo di accreditamento da questo previsto.
Quanto sarà esposto nel seguito rappresenta il risultato dell'esperienza raccolta
lungo differenti percorsi lavorativi in realtà aziendali distinte operanti in questo
settore, per alcuni versi ancora molto giovane in Italia. In particolare la descrizione
del progetto di un ipotetico Laboratorio di Valutazione della Sicurezza (o LVS) deriva
dalle attività di progettazione, studio, gestione e utilizzo di queste strutture in
molteplici realtà aziendali ad oggi operative, per le quali costituiscono attualmente
parte integrante delle proprie attività di business.
5
Per questo motivo tali aziende non saranno nel seguito descritte o nominate, ma
verranno seguite le stesse linee di progetto che hanno portato alla definizione, alla
messa in opera e al successivo accreditamento dei Laboratori in oggetto.
6
2. Considerazioni sulla sicurezza
Il termine Sicurezza ICT ha assunto, soprattutto negli ultimi anni, una serie di
significati differenti legati principalmente al particolare ambito di riferimento e,
conseguentemente, molteplici definizioni e caratterizzazioni. La natura di questo
fenomeno è sicuramente da ricercarsi nella vastità del settore al quale essa si
riferisce ed alla continua evoluzione tecnologica che porta, spesso, ad una
ridefinizione dei concetti fondamentali ai quali essa è legata.
Se si volesse fornire una definizione univoca di quello che la Sicurezza ICT oggi
rappresenta probabilmente ci si dovrebbe riferire ad una molteplicità di aspetti
tecnici, tecnologici, organizzativi e procedurali volti a proteggere un bene di una
organizzazione o di una azienda (asset, nella terminologia corrente). Nell'ambito
delle Certificazioni per la sicurezza ICT, in accordo a quanto specificato nella serie di
standard ISO 27000, il bene essenziale da salvaguardare è rappresentato
dall'informazione. Per essa devono essere garantite alcune caratteristiche di base,
ovvero:
•
Riservatezza, intesa come la possibilità di fruire dell'informazione stessa solo
da parte di soggetti autorizzati, impedendone l'accesso sia intenzionale che
accidentale per chiunque altro.
•
Integrità, intesa come la protezione dell'informazione da alterazioni non
autorizzate, siano esse intenzionali o accidentali.
•
Disponibilità, intesa come la possibilità di fruire delle informazioni, da parte di
chi ne abbia accesso, ogniqualvolta sia necessario, anche in presenza di
fenomeni ostativi intenzionali o accidentali.
7
Con queste premesse, la definizione del termine Sicurezza nello specifico ambito del
settore dell'informazione è esprimibile come:
“la sicurezza nel settore della tecnologia dell’informazione consiste nella
protezione della riservatezza, integrità, disponibilità delle informazioni
mediante il contrasto delle minacce originate dall’uomo o dall’ambiente, al fine
di impedire, a coloro che non siano stati autorizzati, l’accesso, l’utilizzo, la
divulgazione, la modifica delle informazioni stesse, e di garantirne l’accesso e
l’utilizzo a coloro che siano stati autorizzati”
Sul piano reale, tuttavia, questa definizione si scontra con un numero infinito di
difficoltà oggettive che rendono impossibile garantire con certezza assoluta le
caratteristiche sopra descritte, prime fra tutte quelle legate agli aspetti economici
della realizzazione della sicurezza ICT.
Appare chiara, allora, la necessità di individuare dei compromessi, accettati in modo
consapevole ed esplicito da parte dei soggetti interessati, che tengano conto da una
parte di queste limitazioni e dall'altra dei livelli di garanzia (e di fiducia) che si
vogliono raggiungere circa la sicurezza ICT all'interno di ogni singola realtà aziendale
o organizzativa.
Questi compromessi possono essere individuati solo adottando un processo
organico e strutturato di analisi e realizzazione della sicurezza, accettando che
questa non consiste nella semplice adozione di un prodotto o di regole
8
generalizzabili, ma che come processo la sua implementazione varia a seconda
della realtà a cui si riferisce.
Alla luce di queste considerazioni, implementare la sicurezza ICT vuol dire:
•
Individuare le risorse da proteggere (asset)
•
Individuare le minacce che gravano sulle risorse
•
Individuare le vulnerabilità proprie delle risorse
•
Definire un livello accettabile di rischio
•
Determinare le specifiche di sicurezza
A questo processo, che è stato standardizzato in varie normative internazionali, tra
cui la ISO 27001, si dà generalmente il nome di “Analisi dei rischi”.
Senza scendere ulteriormente nel dettaglio di questi concetti, occorre a questo punto
specificare quale sia il ruolo delle certificazioni di sicurezza nel percorso fin qui
tracciato: la valutazione, e quindi la certificazione, consente di verificare quanto un
processo o un sistema sia capace di rispettare determinati requisiti di sicurezza (o di
assurance, come verrà poi specificato), attraverso l'utilizzo di metodologie
internazionali che definiscono criteri standard per la valutazione di tali requisiti.
Attraverso l'Analisi dei rischi, allora, è possibile definire in quali ambiti di una
specifica Organizzazione potrebbe essere richiesta una certificazione di sicurezza
condotta da una terza parte indipendente, come:
•
certificazione del processo di gestione della sicurezza (ISMS), secondo lo
standard ISO27001;
9
•
certificazione di prodotto o di sistema, secondo lo standard ISO15408;
•
certificazione
di
competenza
del
personale,
secondo
criteri
come
CISSP/SSCP o CISA/CISM.
E' da notare, però, che le sole certificazioni, pur rappresentando un notevole valore
aggiunto, non riescono ad elevare il livello di sicurezza se non sono accompagnate
da una costante sensibilizzazione riguardo le particolari tematiche trattate. In altre
parole, ognuna di queste certificazioni è da considerarsi in questo senso come
condizione necessaria ma non sufficiente. E’ altrettanto importante notare come
l’attenzione agli aspetti di sicurezza, anche quelli dettati dai criteri che verranno
esaminati, deve essere considerata come principio fondamentale sin dalle fasi iniziali
di sviluppo di un qualsiasi sistema, prodotto o processo che voglia definirsi sicuro, e
non solo come rimedio occasionale a problematiche emerse o vulnerabilità.
10
3. La Certificazione di Sicurezza
Il termine “Certificazione di sicurezza” è utilizzato oggi in molteplici contesti e a
seconda di questi assume significati differenti.
Diventa perciò importante per lo scopo del presente lavoro definire univocamente il
termine “certificazione di terza parte” o, più semplicemente, “certificazione”.
Come già espresso nei paragrafi precedenti, uno degli scopi della sicurezza
nell'ambito del settore dell’Informazione e della Comunicazione è quello di garantire
la riservatezza, l'integrità e la disponibilità delle informazioni ai soggetti interessati nei
processi di generazione, modifica e diffusione dell'informazione stessa.
In questo contesto, inoltre, la valutazione di sicurezza può essere definita come
l'attività che in maniera probabilistica consente di rispondere circa le capacità di un
sistema (assurance) di rispettare le specifiche di sicurezza che sono state stabilite in
relazione al suo utilizzo/funzionamento.
Il significato del termine “certificazione”, allora, può essere immediatamente definito:
“la certificazione è il risultato di una attività di valutazione eseguita da una
terza parte indipendente (organismo di certificazione) sulla base di standards
e metodologie riconosciute, e per le quali l'organismo di certificazione è stato
preventivamente accreditato da un ente di accreditamento specifico”
Come si evince dalla frase precedente, il processo di certificazione è un
procedimento complesso, in cui sono coinvolti molteplici soggetti che, sulla base di
11
criteri stabiliti, contribuiscono al raggiungimento dello stesso scopo (la certificazione).
Per questo motivo è utile definire a grandi linee gli elementi che sono direttamente
coinvolti in un generico processo di certificazione. Volendo formare due gruppi, il
primo potrebbe riferirsi al contesto normativo, l'insieme, cioè, degli elementi che
definiscono “le regole” secondo le quali operare, e dei soggetti che devono stabilire e
vigilare sulle regole stesse:
1 Norma di riferimento: individua cosa necessita di certificazione e in che modo.
2 Schema di certificazione: raccoglie e definisce l'insieme delle regole che
devono essere utilizzate durante il processo di applicazione della norma di
riferimento.
3 Gestore dello schema: entità super-partes locale che garantisce la corretta
applicazione dello schema da parte di tutti i soggetti interessati. Ha anche il
compito di negoziare accordi di mutuo riconoscimento con gli analoghi gestori
in altri paesi.
4 Il garante dello schema: entità super-partes (spesso internazionale) che si fa
carico di risolvere le controversie che coinvolgono il gestore dello schema.
Il secondo, invece, potrebbe raccogliere i soggetti che sono direttamente coinvolti nel
processo di valutazione e di certificazione, e cioè:
1 Ente Accreditatore: si occupa dell'accreditamento iniziale dei Certificatori e/o
dei Valutatori (o dei Laboratori di Valutazione) e del controllo periodico degli
stessi. In altre parole conferisce ad un soggetto l'etichetta di Valutatore e
12
supervisiona periodicamente l'attività e il rispetto dei requisiti da parte di
questo.
2 Certificatore: si occupa dell'emissione dei certificati sulla base dei risultati
ottenuti dai valutatori (o dai laboratori di valutazione) accreditati e assicura la
corretta gestione dei certificati emessi.
3 Valutatore: esegue la valutazione di sicurezza; si occupa perciò di redigere la
documentazione, ispezionare, testare l'oggetto della certificazione in modo da
poter fornire al certificatore (in caso di verdetto di valutazione positivo) gli
elementi necessari all'emissione dei certificati. Può essere, a seconda del
contesto, una singola figura o un Laboratorio.
4 Cliente:
costituisce
l'owner
dell'oggetto
della
valutazione/certificazione.
Ingaggia direttamente un valutatore con la volontà di portare a certificazione
un determinato prodotto/processo/sistema/...
5 Oggetto della Valutazione (e della certificazione): un prodotto, un sistema, un
processo che, unitamente alla sua documentazione, è sottoposto al processo
di valutazione secondo i criteri e la metodologia adottati.
6 Fruitore della certificazione: rappresenta l’entità che potrà avvalersi della
certificazione; può essere lo stesso Cliente, un fornitore o l’utente finale.
La figura 1 rappresenta qualitativamente il complesso delle entità descritte nei punti
precedenti.
13
Normativa di
riferimento
Schema di
Gestore dello Schema
Certificazione
Ente
Criteri
Accreditatore
Cliente
Garante dello Schema
Ente
Certificatore
Valutatore
ODV
Valutazione
Certificazione
Certificato
Fruitore della
certificazione
Figura 1: Soggetti coinvolti nel processo di certificazione
14
I rapporti che legano le entità coinvolte nel processo saranno più chiari nel seguito,
quando saranno selettivamente scomposti i flussi che compongono l'intero
procedimento.
Affinché la certificazione abbia un senso (e quindi un valore) essa deve garantire
quattro caratteristiche di base:
1 Imparzialità: l'accreditatore, il certificatore e il valutatore devono essere terza
parte
indipendente
rispetto
al
fornitore/titolare
del
prodotto/sistema/processo/... da certificare. In altre parole, deve essere
possibile dimostrare che essi non abbiano interessi commerciali o finanziari
legati all'esito della certificazione.
2 Oggettività: la valutazione deve essere condotta cercando di motivare (ove
possibile) ogni affermazione con evidenze sperimentali. In altre parole,
bisogna limitare il più possibile le considerazioni soggettive in modo da
rendere la certificazione il più oggettiva possibile.
3 Ripetibilità: la valutazione deve essere condotta in modo da dimostrare che se
effettuata una seconda volta sullo stesso oggetto, con gli stessi requisiti di
sicurezza e dallo stesso valutatore, porterebbe ai medesimi risultati.
4 Riproducibilità: la valutazione deve essere condotta in modo da dimostrare
che se effettuata una seconda volta sullo stesso oggetto, con gli stessi
requisiti di sicurezza ma da un valutatore diverso porterebbe ai medesimi
risultati.
Seppur di portata generale, queste caratteristiche possono aiutare a comprendere
quale sia il vero significato della certificazione, e cioè formalizzare una garanzia,
15
sulla base dell’analisi svolta da valutatori di terza parte indipendente, circa il rispetto
da parte dell’oggetto certificato di determinati requisiti e funzioni di sicurezza, in
modo da poter essere consapevoli di quali siano i fondamenti sui quali riporre la
propria fiducia.
Ne segue, però, che uno schema di certificazione perfetto, e cioè tale da soddisfare
completamente le caratteristiche di cui sopra, è praticamente irrealizzabile. Esistono
alcuni aspetti sui quali la valutazione si può basare solo sul giudizio soggettivo del
valutatore, e non su motivazioni complete e oggettive; in molti casi, inoltre, le prove
che si possono effettuare in fase di valutazione sono parziali rispetto alla portata
della certificazione, e ciò conferisce un grado di incertezza che deve essere
consapevolmente conosciuto.
Come per altri aspetti della sicurezza ICT, la certificazione necessita di compromessi
che devono essere noti e accettati da chiunque si avvalga, in modalità diverse, della
certificazione stessa; la presenza di un certificato conferisce un valore aggiunto tale
da poter offrire garanzie che, seppur di carattere elevato, non possono
rappresentare una certezza assoluta, ma piuttosto una indicazione oggettiva su chi o
su che cosa occorre riporre la propria fiducia.
Ricordando che la certificazione è un processo complesso, è possibile scomporne le
principali componenti in flussi semplici, in modo da chiarire non solo quali siano i
percorsi che caratterizzano la certificazione stessa, ma anche quali siano i ruoli delle
entità in gioco che sono state descritte in testa al presente paragrafo.
Selezione dello Schema
16
Perché uno schema sia valido (e quindi sia valido anche l’operato dei soggetti
coinvolti nello schema) in un determinato ambito, occorre che esso sia
legittimato.
Validità
Normativa
Nazionale
Validità
Normativa
Internazionale
Validità
Oggettiva dagli
utilizzatori
Schema
Figura 2: Selezione di uno schema
La legittimazione di uno schema può avvenire secondo un elevato numero di
modalità. Ad esempio, è possibile che un ente sovranazionale provveda a
validarlo e proporlo, creando un circuito di enti nazionali che possono usufruire
del mutuo riconoscimento del loro operato (quello che succede oggi con i
Common Criteria). E’ anche possibile che lo schema sia studiato, proposto e
legittimato tramite l’emissione di una normativa specifica da un ente di Stato, e
quindi riconosciuto in ambito nazionale, o che semplicemente sia riconosciuto
come valido dalla comunità di utenti che fanno uso (come alcune attuali
metodologie open source di valutazione).
17
E’ chiaro che nei tre casi proposti lo schema ha rilevanza differente: l’esistenza
di una normativa che ne regolamenti l’utilizzo conferisce a questo un potere
differente dal semplice riconoscimento di bontà espresso dagli utenti (anche se è
auspicabile che entrambi gli aspetti siano verificati!).
Accreditamento di un Valutatore (o di un Laboratorio di Valutazione)
La procedura di accreditamento di un soggetto abilitato alla valutazione secondo
un determinato schema varia a seconda dell’ambito, della legittimazione dello
schema stesso e del contesto normativo presente.
Richiesta di
Accreditamento
Il Valutatore (o il
laboratorio) fa
richiesta di
accreditamento
presso l'Ente
Accreditatore.
Presenta allo scopo:
• Documentazione
richiesta dallo
schema
• Documentazione
socetaria
• Certificati, …
Analisi della
Richiesta
L'ente accreditatore
analizza la richiesta.
• Valuta i requisiti del
Valutatore (o del
laboratorio)
• Pianifica delle
verifiche (ispettive
o di conformità)
• Stabilisce
tempistiche
Fase di
Verifica
esegue le verifiche
richieste dallo
schema, come per
esempio:
• di conformità
• organizzative
• di competenza
Certificazione di
Accreditamento
emette il verdetto
basandosi sul
materiale presentato
e raccolto in fase di
verifica.
L'ente certificatore, a
questo punto,
analizza il verdetto e
se il processo ha
esito positivo, emette
il certificato di
accreditamento.
Figura 3: Processo di accreditamento di un Valutatore/Laboratorio
In linea generale, la procedura di accreditamento vede in gioco tre entità distinte,
ovvero Valutatore (o Laboratorio), Ente Accreditatore ed Ente Certificatore. L’iter
ha inizio quando il primo di essi fa specifica richiesta di accreditarsi per operare
18
secondo uno schema. A questa fase seguono quelle di esame e verifica da parte
dell’Ente Accreditatore che deve sincerarsi della reale conformità ai requisiti ed
esprimere un parere di verifica. Nel caso questo fosse positivo, l’Ente
Certificatore emette il Certificato di Accreditamento per i modi e i tempi previsti
dallo schema. Spesso accade che lo schema preveda un passo ulteriore prima
che l’Ente Certificatore emetta il certificato, per ragioni di garanzia e controllo,
identificando una commissione specifica all’attenzione della quale sottoporre i
risultati delle verifiche.
Nel seguito del documento verrà dato un esempio di tale procedura, e cioè nel
caso di accreditamento di un LVS.
Certificazione di un prodotto/processo/sistema
Anche la fase di certificazione assume connotati diversi a seconda dello schema,
dell’ambito e della normativa. Allo stesso modo dell’accreditamento possiamo
definire una serie di fasi generali che sono, seppur con nomi diversi,
generalmente sempre presenti.
19
Definizione degli
obiettivi, dei
requisiti e dell’ODV
Il Cliente, insieme
con il Valutatore (o il
Laboratorio)
definisce:
• gli obiettivi da
raggiungere
• il livello di
assurance da
certificare
• l'oggetto della
valutazione (ODV)
Predisposizione
della
documentazione
Viene predisposto
l'impianto
documentale che la
valutazione richiede.
Possono essere fatti
in questa fase dei
test per verificare
alcuni aspetti di
sicurezza.
Fase di
Valutazione
Il Valutatore (o il
Laboratorio) analizza
la documentazione,
verifica (o ripete) i
test effettuati, ne
richiede (o ne
esegue) di nuovi.
In questo fase può
essere coinvolto
l'ente certificatore in
affiancamento al
Valutatore (o al
Laboratorio)..
Emissione della
Certificazione
L'ente certificatore
analizza la richiesta,
valuta la
documentazione di
valutazione e, in
caso di esito
positivo, emette il
certificato.
Figura 4: Processo di certificazione
Una volta scelta la tipologia di certificazione, definito l’Oggetto di Valutazione e
contattato un soggetto abilitato alla valutazione secondo il relativo schema, viene
predisposto tutto ciò che servirà per eseguire la valutazione, in particolar modo la
documentazione che dovrà essere presentata. La fase di valutazione, in caso
non ci siano particolari problemi, si conclude con l’emissione di un rapporto
all’Ente Certificatore, spesso coinvolto anche nella attività di valutazione, che
emette il relativo certificato.
Mantenimento della certificazione
Per il mantenimento della certificazione, a differenza delle altre fasi, è
necessario fare una distinzione tra certificazioni di prodotto o di processo. Nel
primo caso la certificazione resta legata per un tempo determinato a quel
20
prodotto e decade se ne vengono modificate le caratteristiche. Per mantenere il
certificato deve essere il Cliente a richiederne l’adeguamento, sottoponendo a
nuova valutazione i cambiamenti che ha effettuato sul prodotto.
Emissione del
certificato
aggiornato
Richiesta di
adeguamento del
certificato
Valutazioni sulle
modifiche
effettuate
Figura 5: Mantenimento del certificato per prodotto/sistema
Nel caso della certificazione di processo, invece, è l’Ente Certificatore che,
direttamente o tramite ispettori nominati, effettua delle verifiche ispettive durante
il periodo di validità del certificato atte ad appurare che le condizioni per le quali
questo era stato emesso non siano venute a mancare. In questo caso si
raggiunge il miglioramento continuo attraverso un costante monitoraggio dei
cambiamenti e dell’adeguamento a questi.
21
Verifiche periodiche
dell’Ente
Certificatore
Miglioramento
Continuo
Monitoraggio dei
cambiamenti ed
analisi conformità
Figura 6: Mantenimento del certificato per processo
3.1. Certificazioni correntemente utilizzate
In tabella 1 sono riportate alcune certificazioni attualmente utilizzate in Italia.
Tabella 1:Ambiti di certificazione e criteri adottati
Ambito di applicazione
Criteri Standard/Riferimento
Processo di gestione della sicurezza ICT
ISO27001:2005
Prodotto/sistema ICT per uso civile
Common Criteria (ISO15408) - ITSEC
Competenza del personale
CISA/CISM – CISSP/SSCP (ISC2)
Prodotto/sistema ICT per uso classificato
Common Criteria (ISO15408) - ITSEC
22
Come si vede dalla tabella, gli standard ITSEC e Common Criteria sono utilizzate da
entrambi il settore civile e classificato; le normative che disciplinano e regolamentano
le certificazioni, tuttavia, sono differenti, e così anche i centri abilitati per la
valutazione (Centri di Valutazione, o CeVa, per il classificato, LVS per il civile).
3.2.
Panoramica storica
Lo sviluppo dei moderni criteri di valutazione e certificazione di sicurezza ha origine
nella seconda metà degli anni 80, quando l'allora Department of Defence Computer
Security Centec (ora National Computer Security Center, NCSC) pubblica la
versione definitiva di uno standard annunciato circa 5 anni prima, il Trusted
Computer System Evaluation Criteria, TCSEC. Più conosciuto con il nome di Orange
Book, il documento introduce importanti ed innovativi concetti, che poi saranno
ripresi da quasi tutti i moderni standard (inclusi i CC):
•
Valutazione di terza parte (per TCSEC l'organismo era governativo)
•
Assurance, ovvero la capacità del prodotto di soddisfare determinati criteri
di sicurezza
•
Valutazione probabilistica, non assoluta
Anche se oggi l'Orange Book è stato rimpiazzato dai più recenti Common Criteria,
rimane pietra miliare per tutti i successivi standard mondiali.
Dal 1985 sono stati annunciati e pubblicati molti standard e criteri a livello sia
europeo che mondiale; solo per citarne alcuni di maggior rilevanza:
•
1990/1991 – ITSEC (1.0 - 1.2), sviluppato in ambito europeo da Francia,
Germania, Regno Unito e Olanda.
23
•
1992 – Federal Criteria Project, sviluppato negli USA dal National Institute
for Standard and Technology (NIST) e la National Security Agency (NSA).
•
1993 – Information Technology Security Evaluation Manual, ITSEM,
sviluppato dalla Commissione delle Comunità Europee.
•
1995 – BS7799, sviluppato da una commissione del Regno Unito e poi
adottato globalmente a livello Europeo, è oggi la base del più moderno
ISO27001.
•
1996 – Common Criteria v. 1.0, dal progetto CCEB (1993), primo a
coinvolgere esperti provenienti da USA, Unione Europea e Canada. E'
oggi considerato lo standard “de facto” per la valutazione di prodotto. Le
major revisione che sono state rilasciate negli anni sono la 2.1 (1999) e la
2.2 (2004)., mentre è attesa per il prossimo aprile 2008 la nuova versione
3.0 (3.1).
•
2000 – ISO27001, sviluppato a partire dalla prima parte dello standard
BS7799.
Una timeline dello sviluppo descritto nell'elenco precedente è rappresentata nella
figura 7.
24
1985
1990
TCSEC
ITSEC
(orange book)
1992
Federal Criteria
Project
(v.1.0)
2000
ISO27001
(in parte dalla
BS7799)
1980
1990
2000
2005
2004
Common Criteria
(v.2.2)
1993
ITSEM
1995
BS7799
1996
Common Criteria
1999
Common Criteria
(v.2.0)
(v.1.0)
Figura 7: Timeline dei principali criteri/standard di valutazione
Come sarà esposto nei paragrafi successivi, la rilevanza del progetto CCEM che ha
portato alla nascita dei Common Criteria è altissima: il loro sviluppo ha per la prima
volta coinvolto organismi internazionali appartenenti al vecchio e al nuovo
continente, nell'ottica di armonizzare le metodologie proprietarie di valutazione,
ricercarne di nuove e stabilire il meccanismo di mutuo riconoscimento (cfr. par. 5.4),
punto focale per garantire la validità globale delle certificazioni.
3.3.
Attuale quadro normativo
A regolamentare le certificazioni di sicurezza in Italia è la stessa Presidenza del
Consiglio dei ministri, che fissa, tra le altre, tramite l'emissione di decreti (nel seguito
Decreto della Presidenza del Consiglio dei Ministri, DPCM):
•
lo schema di riferimento;
•
l'ambito di applicazione;
•
gli organismi preposti all'emissione delle certificazioni;
25
•
gli organismi preposti all'accreditamento dei valutatori (o dei laboratori di
valutazione).
Il quadro normativo attuale, quindi, si può facilmente ricostruire seguendo i seguenti
documenti:
•
DPCM 11 aprile 2002 – GU n°131 del 6 giugno 2002, ovvero Schema
Nazionale del 1995 aggiornato nel 2002. Regolamenta le certificazioni
relative al contesto classificato, ovvero inerenti alla sicurezza interna e
esterna dello Stato, di prodotti e sistemi ICT. L'Ente preposto alla
certificazione e all'accreditamento è l'ANS/UCSI, che attualmente ha
accreditato positivamente 3 Centri di Valutazione (CeVa). Lo schema
adotta come criteri di certificazione sia i Common Criteria che ITSEC.
•
DPCM 30 ottobre 2003 – GU n° 98 del 27 aprile 2004, ovvero Schema
Nazionale del 2003. Regolamenta le certificazioni relative al contesto non
classificato, ovvero non inerenti alla sicurezza interna ed esterna dello
stato e in tutti gli altri contesti non inclusi dal DPCM dell'11 aprile 2002, di
prodotti e sistemi ICT. Contestualmente al presente decreto è stato istituito
presso l'ISCOM l'Organismo di Certificazione della sicurezza di sistemi e
prodotti ICT, l'OCSI. Questa struttura si avvale tutt'oggi del supporto della
Fondazione
Ugo
Bordoni
(FUB)
e
rappresenta
l'Ente
preposto
all'accreditamento e alla certificazione. Lo schema adotta come criteri di
certificazione sia Common Criteria che ITSEC, ed ad oggi ha accreditato 6
Laboratori per la Valutazione della Sicurezza.
26
Per le altre certificazioni valgono i seguenti criteri:
•
Per la certificazione di processo di gestione della sicurezza (ISMS) che fa
riferimento alla ISO27001:2005 l’Ente di Accreditamento Nazionale è
SINCERT, riconosciuto con Decreto Ministeriale del Giugno 1995.
•
Per la certificazione del personale in Italia è CEPAS il referente per lo
sviluppo dei criteri di verifica della competenza. In ambito internazionale
alcune certificazioni di rilievo sono sviluppate da ISC2 e da ISACA e
gestite localmente tramite affiliazioni nazionali.
I decreti ed i riferimenti sopra riassunti formano quello che è, ad oggi, il cuore del
quadro normativo nazionale. I primi due hanno particolare rilevanza per il fine di
questo documento, poiché formalizzano l'utilizzo di standard riconosciuti (ITSEC e
CC) per le valutazioni della sicurezza di sistemi e prodotti ICT.
Da questi due decreti appare chiara la volontà di proporre la valutazione di sicurezza
come “volontaria” ad esclusione dei prodotti ICT finalizzati all'utilizzo in contesti
classificati, lasciando la valutazione essere intesa come un “valore aggiunto”, non
come un requisito essenziale.
E' parere personale dell’autore che questa visione delle certificazioni risulti
insufficiente, esistendo contesti non certo classificati che però richiederebbero
l'obbligatorietà della certificazione, e che saranno descritti nel paragrafo successivo.
In ambito Europeo, tuttavia, occorre segnalare che esiste la tendenza ad
3.4. Ambiti di certificazione
27
Come detto nel paragrafo precedente, il quadro normativo attuale italiano si limita a
riconoscere
la
certificazione
di
sicurezza
come
azione
volontaria,
senza
regolamentarne l’obbligatorietà in particolari contesti definibili come “critici” (con la
sola esclusione dell’ambito classificato).
Naturalmente una prima differenziazione si deve fare tra organismi privati e pubblici:
mentre per i primi (anche se con opportune eccezioni) la certificazione di sicurezza
su base volontaria potrebbe essere vettore di business all’interno di un mercato
concorrenziale (e quindi vantaggiosa) al fine di dimostrare l’attenzione che si pone a
tali aspetti, per i secondi il discorso si fa più complicato, non essendoci, a parte il
buon senso dei gestori, motivazioni di questo genere.
Riprendendo quanto espresso [31], che identifica ambiti per i quali sia
“raccomandata” la certificazione di sicurezza, questo paragrafo si limiterà ad
elencarne alcuni, evidenziando il fatto che per alcuni di questi potrebbe essere utile
che la normativa stessa prevedesse una adeguata regolamentazione in materia.
Contesti a massima priorità:
Fanno parte di questa categoria quelli direttamente “attinenti alla tutela
dell’incolumità fisica e della salute dei cittadini”, come organi di mantenimento
dell’ordine pubblico, protezione civile, infrastrutture critiche (servizi di
trasporto, comunicazione, energia, etc…). In questi contesti già lo Stato
regolamenta l’utilizzo di verifiche di terza parte per settori differenti da quello
della sicurezza ICT. Tuttavia, data la crescente dipendenza dalle strutture di
informazione e comunicazione di questi organi, “un malfunzionamento,
accidentale o provocato, di tali sistemi può infatti in molti casi produrre
28
gravissimi danni alle persone, se non addirittura la perdita di numerose vite
umane”.
Contesti ad elevata priorità
Fanno parte di questa classe contesti per i quali un eventuale danno
provocato dal malfunzionamento delle strutture di supporti ICT “pur essendo
solo di tipo economico, può essere comunque molto rilevante sia per il
cittadino sia per lo stato”. Per questi la certificazione non solo porterebbe ad
una maggiore efficienza in termini di sicurezza, ma aiuterebbe a “generare
fiducia nei cittadini circa la fruizione in forma telematica di servizi della PA
normalmente erogati nella forma tradizionale, la quale molto spesso risulta
sensibilmente più onerosa in termini economici per lo stato. In alcuni di questi
casi, quali ad esempio il voto elettronico o i servizi nei quali vengono trattati
dati personali sensibili, oltre al beneficio in termini economici per lo stato si
può peraltro ravvisare anche quello di aver sottoposto a verifica di terza parte
la tutela che gli apparati ICT sono in grado di assicurare al cittadino quando
quest’ultimo li utilizza per esercitare le proprie libertà ed i propri diritti
fondamentali”.
Altri contesti critici
Fanno parte di questa categoria “altre situazioni nelle quali la certificazione,
sia pure con minore forza rispetto ai casi trattati nel precedente paragrafo, può
essere consigliata sono quelle per le quali si possano prevedere danni
considerevoli a seguito di incidenti informatici”. Sono tali ad esempio archivi
29
elettronici contenenti ingenti quantità di dati, soprattutto se personali, per i
quali eventuali alterazioni o cancellazioni (accidentali o intenzionali) possono
produrre, oltre ai danni principali derivati dall’ interruzione del servizio, anche
danni in termine di immagine dello Stato, qualora si dimostrasse che non si
erano predisposte adeguate politiche per la tutela di queste informazioni.
3.5. Vantaggi e svantaggi della certificazione
In assenza di una normativa che regolamenti l'utilizzo delle certificazioni di sicurezza,
è auspicabile che i soggetti responsabili di ambienti critici, come quelli presentati nel
paragrafo precedente, affrontino l'iter della certificazione su base volontaria con lo
scopo di assicurare e comprovare la qualità e la sicurezza stessa di questi.
Ad ogni modo, prima di concludere questo capitolo dedicato alle considerazioni di
carattere generale riguardo le certificazioni di sicurezza, è doveroso prendere in
considerazione quali siano gli aspetti positivi e quelli negativi del certificare un
prodotto, un sistema, un processo, etc…
Questo assume un maggiore senso poiché la certificazione volontaria presuppone
un bilancio tra vantaggi e svantaggi, in cui i primi siano maggiori (come ovvio) dei
secondi.
Bisogna allora prendere in considerazione le motivazioni che potrebbero indurre un
soggetto a muoversi a tal fine; alcune delle possibili sono sommariamente riassunte
nel seguente elenco.
30
•
Valore aggiunto: il soggetto produttore o fornitore di un prodotto/servizio vuole
ottenere una certificazione perchè ritiene che essa possa incrementare le
vendite o per uniformarsi allo standard di mercato offerto dai concorrenti.
•
Dimostrazione a terzi: il soggetto titolare o fruitore di un prodotto/processo
vuole ottenere una certificazione perchè intende garantire a terzi il proprio
impegno nella gestione della sicurezza (o qualità), nell'attuare misure
preventive orientate a limitare l'occorrenza di incidenti o di aver adempiuto
correttamente, in caso di incidente, alle best-practices del caso
•
Dimostrazione
propria:
il soggetto
titolare
o
fruitore
di un proprio
processo/prodotto vuole acquisire la consapevolezza della propria sicurezza
attraverso una certificazione di terze parti.
•
Ingresso
in
mercati
ad
alti
requisiti:
il
produttore/fornitore
del
prodotto/processo vuole entrare in un mercato con stringenti vincoli di
sicurezza, che includano la necessità di avere risorse/processi/prodotti
certificati.
Allo stesso modo esistono delle motivazioni per le quali il processo di certificazione
potrebbe essere difficoltoso da intraprendere, come per esempio:
•
Tempistica: il percorso di valutazione e di certificazione, in genere, richiedono
lunghi tempi di esecuzione, per i quali il soggetto Cliente potrebbe essere
scoraggiato.
•
Costo: l'impiego di risorse qualificate di terze parti richiede, in genere, un
esborso economico non indifferente.
31
•
Mantenimento: il processo di mantenimento (specialmente per le certificazioni
di prodotto) presenta vincoli stringenti che possono portare alla perdita della
certificazione, o può richiedere investimenti continui (sia economici che di
tempo e risorse) per l'aggiornamento della certificazione stessa.
32
4. Gli standard di valutazione per i sistemi/prodotti ICT
Il presente capitolo ha lo scopo di illustrare, in maniera descrittiva, i criteri ad oggi
utilizzati per condurre valutazioni e certificazioni di sicurezza per sistemi e prodotti
concernenti il settore della tecnologia dell'informazione e della comunicazione in
Italia.
In accordo con il paragrafo 3.4 del presente documento, verranno analizzati i criteri
stabiliti dallo “Schema Nazionale per la valutazione e la certificazione della sicurezza
di sistemi e prodotti nel settore della tecnologia dell'informazione”, DPCM del 30
ottobre 2003, e dal precedente DPCM del 11 aprile 2002 (per l'ambito classificato).
In entrambi i decreti viene definito “l’insieme delle procedure e delle regole nazionali
necessarie per la valutazione e certificazione, in conformità ai criteri europei ITSEC o
agli standard internazionali ISO/IEC IS-15408 (Common Criteria), emanati dall’ISO
(Organizzazione internazionale per la standardizzazione)”.
Verrà quindi proposta una descrizione degli standard (Common Criteria e ITSEC),
delle linee guida associate, del processo di certificazione stesso e della sua valenza
in ambito nazionale ed internazionale.
Per completezza occorre sottolineare che nell'attuale concezione comune gli
standard Common Criteria sono considerati i diretti successori di ITSEC; è questo il
motivo per cui verrà data maggiore rilevanza al primo rispetto al secondo, restando
comunque intesa la validità e l'importanza di ITSEC in alcuni contesti specifici.
4.1. Common Criteria
33
Gli standard Common Criteria hanno origine da un progetto internazionale durato
circa 5 anni che coinvolgeva NIST e NSA per gli USA e svariate organizzazioni per la
sicurezza in Canada, Francia, Germania, Olanda e Regno Unito. Per lo sviluppo dei
criteri fu istituito un gruppo di lavoro (anch'esso internazionale) denominato Common
Criteria Editorial Board (CCEB). A titolo puramente cronologico, la versione 1.0 dei
Common Criteria fu completata nel gennaio 1996 e approvata nell'aprile dallo stesso
anno dall'ISO per la distribuzione come “Committee Draft” (CD). Dopo numerose
valutazioni di test, i feedback provenienti dalla comunità di utilizzatori e dall'ISO
stessa furono raccolti dalla Common Criteria Implementation Board (CCIB), diretto
successore del CCEB, e utilizzati per produrre la versione 2.0, che raggiunse lo stato
“Beta” nell'ottobre 1997 e il successivo rilascio formale in versione 2.1 nell'agosto
1999.
Nel seguito di questo paragrafo verranno enunciati i concetti alla base dei Common
Criteria e i suoi scopi principali, mentre si rimanda alla documentazione ufficiale
([5],[6],[7],[8],[15],[16],[17]) per una comprensione più profonda dello standard.
La terminologia che verrà utilizzata nel seguito sarà quella italiana, contenuta nelle
Linee Guida, perché di riferimento nelle principali attività pratiche e perchè entrata
ormai nell’uso comune degli operatori del settore.
E' inoltre opportuno ricordare che le considerazioni qui espresse si riferiscono alla
versione 2.2 e 2.3 (le versioni ufficiali al momento della scrittura di questo testo) dei
Common Criteria e della Common Evaluation Methodology (CEM), che saranno
valide fino al Marzo del 2008. A queste subentrerà la versione 3.1, che introdurrà
numerosi cambiamenti sostanziali, sintetizzati nel capitolo 9 del presente
documento.
34
4.1.1. Descrizione dello standard
Da come è possibile leggere nelle note di premessa alla versione 1.0, lo scopo
principale dello sviluppo dei CC è quello di formare una comune base per la
valutazione delle proprietà di sicurezza di prodotti e sistemi IT, che presenti la giusta
flessibilità per permettere la comparazione dei risultati tra laboratori di analisi
indipendenti. L'intento dei CC è inoltre quello di rimpiazzare i precedenti criteri di
sicurezza attivi in Nord America e Europa, rimanendo comunque utilizzabili in ogni
altra parte del mondo.
Il processo di valutazione è costruito in modo tale da stabilire un “livello di
confidenza” tramite il quale stabilire quanto il prodotto o il sistema valutato rispetti i
requisiti (di sicurezza) propri del determinato livello di “assurance” scelto.
In questo modo il risultato della valutazione può aiutare gli utilizzatori della tecnologia
IT in questione a determinare in che modo e in che misura il prodotto stesso sia
sicuro, nel contesto specificato, e quali dei rischi impliciti nel suo utilizzo possano
essere ritenuti tollerabili.
A tale scopo, come sarà espresso nel seguito, i CC contengono un insieme comune
di requisiti per le funzioni di sicurezza, mappati su dei livelli di assurance fissati in
fase di valutazione.
Essendo l'origine dei CC direttamente riconducibile al TCSEC (Orange Book), la
filosofia che ne è alla base è praticamente la stessa. Per descriverla occorre
introdurre alcune definizioni di base, riportare nelle Linee Guida Provvisorie emanate
dall'OCSI:
35
•
Per “prodotto” si intende “un insieme di elementi software, hardware e/o
firmware che svolge una funzione che può essere utilizzata da molti sistemi”.
•
Per “sistema” si intende “una specifica installazione IT (software, firmware o
hardare), caratterizzata da uno scopo a da un ambiente operativo ben
definiti”.
•
Per ODV (o Target Of Evaluation, TOE) si intende un prodotto o un sistema IT
che,
unitamente
alla
documentazione
destinata
agli
utenti
e
agli
amministratori, è sottoposto al processo di valutazione secondo i criteri.
In questo contesto, valutare la sicurezza di un prodotto o di un sistema richiede in
prima istanza di stabilire :
•
a fronte di cosa il sistema/prodotto debba essere sicuro;
•
il contesto nel quale il sistema/prodotto debba essere sicuro (ed essere
utilizzato);
•
quali siano le verifiche attraverso le quali il sistema/prodotto possa essere
ritenuto sicuro.
I tre punti precedenti compongono tre degli elementi base dei CC, e cioè:
•
obiettivi di sicurezza: le intenzioni di contrastare una minaccia o quelle di
rispettare leggi, regolamenti o politiche di sicurezza preesistenti. Il
conseguimento di un obiettivo di sicurezza avviene tramite l'adozione di
36
misure di sicurezza tecniche (funzioni di sicurezza) e non tecniche (fisiche,
procedurali e relative al personale).
•
ambiente di sicurezza: l'ambiente nel quale il prodotto/sistema dovrà operare,
descritto in base all'utilizzo a cui è destinato, le applicazioni componenti,
l'utenza, le misure di sicurezza non tecniche, i collegamenti verso altri apparati
ICT, le minacce a cui è esposto, gli attaccanti possibili, i metodi di attacco e le
vulnerabilità esposte. Fanno parte dell'ambiente anche le politiche di
sicurezza dell'azienda.
•
requisiti di assurance: una serie di verifiche che devono essere fatte per
accertare se il prodotto/sistema rispetta le specifiche di sicurezza. Aumentano
al crescere del livello di assurance (anche detto livello di valutazione).
Queste definizioni consentono di definire univocamente quale sia lo scopo finale di
una valutazione operata secondo lo standard, e cioè:
“offrire garanzie, che vengono prodotte dal soddisfacimento dei requisiti di
assurance e che risultano crescenti con il livello di valutazione, sulla capacità
del sistema/prodotto (TOE) di soddisfare i propri obiettivi di sicurezza
nell'ambiente di sicurezza per esso ipotizzato”
Le garanzie, quindi, sono strettamente dipendenti dal livello di valutazione
(assurance) che si vuole ottenere, e coprono uno spettro di possibili verifiche che
vanno dall'idoneità delle funzioni di sicurezza a soddisfare gli obiettivi di sicurezza
preposti, all'assenza di errori nel processo di traduzione delle specifiche iniziali nelle
37
funzioni di sicurezza finali, fino all'adeguatezza delle procedure di consegna,
installazione e messa in esercizio, dei manuali di utilizzo e di amministrazione, del
supporto tecnico che lo sviluppatore offre all'utilizzatore. E' importante notare che
l'assenza di errori all'interno delle funzioni di sicurezza finali non viene analizzata
solo ricercando la presenza degli errori stessi tramite analisi della documentazione e
test funzionali, ma anche verificando che la realizzazione abbia previsto l'impiego di
strumenti, metodologie e procedure adeguate per la riduzione della probabilità di
errore.
Le funzioni di sicurezza, poi, vengono descritte in base ai requisiti che devono
soddisfare, denominati requisiti funzionali. Questi requisiti, come quelli di assurance,
devono essere espressi utilizzando un catalogo di componenti fornito dai CC o,
eccezionalmente, definendo componenti ad-hoc e fornendo opportune motivazioni e
prove oggettive della loro validità. Per capire cosa si intende per “catalogo”
nell'accezione dello standard, occorre fare un accenno della loro struttura. Per
quanto riguarda la versione 2.3 questa si compone di tre parti principali:
•
Introduction and general model - rappresenta l'introduzione allo standard. Vi
sono contenuti, tra l'altro, i concetti e i principi generali della valutazione. la
terminologia e le definizioni di base e i costrutti per esprimere gli obiettivi di
sicurezza IT.
•
Security functional requirements
–
contiene
l'insieme
(catalogo) dei
componenti funzionali da utilizzare come matrici per esprimere i requisiti
funzionali del TOE, catalogate per componenti funzionali, famiglie e classi.
•
Security assurance requirements – contiene l'insieme (catalogo) delle
componenti di assurance da utilizzare come matrici per esprimere i requisiti di
38
assurance del TOE, catalogate per componenti, famiglie e classi. Fornisce
inoltre i criteri per la valutazione del Security Target e del Protection Profile.
Ognuna di queste parti è studiata per esser utilizzata in modo distinto da tre tipologie
di utenza, i valutatori (evaluators), gli sviluppatori (developers) e consumatori
(consumers). In riferimento a quanto contenuto nella parte 1 dei CC, nella tabella 2
sono espressi i principali utilizzi che i tre profili di utenza possono fare dello standard.
Tabella 2: Utilizzo dello standard per tipologia di utenza
Consumatori
Sviluppatori
Valutatori
Utilizzo a scopi informativi di
Utilizzo a scopi
Utilizzo a scopi
base e come riferimento per lo
informativi di base,
informativi di base, come
sviluppo di requisiti e per la
Introduction and come riferimento, o
riferimento, o come
formulazione
delle specifiche di
general model come guida per i PPs
guida per i PPs
sicurezza per i TOEs
Parte 1
Utilizzo come guida di
Utilizzo come riferimento
obbligatorio per
riferimento per la
l’espressione dei criteri di
Parte 2
nell’interpretazione delle
redazione delle
valutazione nella
espressioni
relative
ai
requisiti
determinazione
del
Security functional
espressioni dei
funzionali
e
nella
redazione
delle
corretto
soddisfacimento
requirements
specifiche funzionali per i TOEs
da parte del TOE dei
requisiti per le
requisiti funzionali
funzioni di sicurezza
dichiarati.
Parte 3
Securitu
assurance
requirements
obbligatorio per
nell’interpretazione delle
l’espressione dei criteri di
Utilizzo come guida
espressioni relative ai requisiti di
valutazione nella
nel determinare i livelli
assurance e nella
determinazione
di assurance richiesti
determinazione di come i TOEs dell’assurance del TOE e
nella valutazione di TSs
affrontino questi aspetti.
e PPs
A queste si aggiunge un ulteriore documento, denominato “Common Evaluation
Methodology” (CEM) che descrive le minime azioni che devono essere affrontate da
un valutatore per condurre una valutazione secondo lo standard, limitando l'ambito di
analisi da EAL1 a EAL4.
39
Tornando alla definizione di catalogo, quindi, questo è un set di base di componenti
che possono essere utilizzati come matrici standard per descrivere dei particolari
requisiti di assurance o funzionali. Sono inoltre organizzati secondo livelli gerarchici,
a partire dalle classi di alto livello (ad es. “Cryptographic Support”) fino alle
componenti singole (ad es. “Cryptographic Algorithm”).
Per quanto riguarda i livelli di valutazione, i Common Criteria ne definiscono una
scala di sette, ognuno comprendente uno specifico insieme di requisiti di assurance.
Questi livelli sono definiti Evaluations Assurance Levels, o EAL[X] con [X] che va da
uno a sette. Al crescere del livello di valutazione vengono richieste specifiche
realizzative più dettagliate (per esempio, dallo schema di progetto ad alto livello o dal
diagramma delle classi si arriva fino al codice sorgente) e il livello di rigore con il
quale le specifiche vengono descritte aumenta (dalla descrizione informale si passa
a quella formale). Il livello EAL1, il più basso tra i sette, non ha precedenti storici
negli altri criteri di valutazione. La motivazione della sua introduzione si evince da
quanto espresso nelle linee guida provvisorie dell'OCSI (in LGP4), e in particolare:
40
“Il soddisfacimento, da parte di un ODV, dei requisiti contenuti nel pacchetto
EAL1 fornisce un livello di garanzia di base, che tuttavia risulta superiore in
modo significativo rispetto al livello di garanzia offerto da un prodotto o
sistema IT che non sia stato sottoposto alla valutazione. Tale livello di
garanzia risulta adeguato in situazioni operative che richiedono una certa
confidenza nel fatto che il comportamento delle funzioni di sicurezza dell’ODV
sia conforme alle specifiche, e fornisce una conferma, da parte di una terza
parte indipendente e imparziale, che il problema della protezione di
informazioni quali i dati personali è stato affrontato con la dovuta cura”
Un ultimo accenno, al fine di rendere più chiaro il modello di valutazione che lo
standard impone, deve essere fatto per quanto riguarda la specifica documentazione
richiesta in fase di valutazione. A questo proposito, tra i numerosi documenti
necessari, saranno descritti nel seguito il Traguardo di Sicurezza (TS o Security
Target nell’accezione inglese) e il Profilo di Protezione (PP o Protection Profile
nell’accezione inglese), fondamentali per una valutazione e chiarificanti riguardo la
metodologia propria di questo standard. Per entrambi, oltre a quanto espresso dai
Common Criteria, l’OC Italiano (OCSI) ha emesso all’interno delle Linee Guida una
descrizione dettagliata di come questi dovrebbero essere compilati.
Traguardo di sicurezza
Il Traguardo di Sicurezza, obbligatoriamente prodotto e fornito in fase di valutazione,
rappresenta uno dei documenti principali di questa attività. Il suo scopo è quello di
41
costituire una sorta di accordo tra gli sviluppatori, i valutatori e, quando appropriato, i
consumatori sulle proprietà di sicurezza dell’ODV e sullo scopo della valutazione. In
altre parole, il Traguardo di sicurezza esprime quali siano le misure funzionali e di
garanzia della sicurezza offerte dall’ODV per soddisfare i requisiti stabiliti. Il target di
utenza al quale il TS si riferisce, quindi, non è composto solo dai produttori dell’ODV
e dai valutatori, ma anche da chiunque sia coinvolto nella gestione, nella
commercializzazione e nella messa in esercizio di questo.
In linea generale, tra le cose da notare che sono contenute nel TS spiccano le
descrizioni dell'ambiente di sicurezza, degli obiettivi di sicurezza e dei requisiti
funzionali e di assurance, parti essenziali che consentono di fornire una
caratterizzazione dell’ODV.
Scendendo più nel dettaglio, il documento deve essere formato da molte sezioni,
ognuna inerente un diverso ambito ed ognuna con i propri criteri di valutazione.
Nell’elenco seguente verrà proposta questa struttura, specificando nei casi più
rilevanti quale siano le informazioni che la compongono.
1. Introduzione
al
Traguardo
di
Sicurezza:
rappresenta
l'introduzione
del
documento; deve contenere obbligatoriamente:
•
identificazione del Traguardo di Sicurezza;
•
sommario del Traguardo di Sicurezza;
•
conformità ai CC;
•
descrizione dell’ODV intesa come caratterizzazione di questo in linea
generale, sia dal punto di vista fisico (componenti e classi hardware e/o
42
software) sia dal punto di vista logico (caratteristiche IT e funzioni di
sicurezza offerte dal TOE).
2. Ambiente di sicurezza dell’ODV, intesa come descrizione degli aspetti di
sicurezza relativi all'ambiente nel quale l’ODV è progettato per operare,
unitamente alle funzioni che deve svolgere in tale ambiente. Deve contenere
obbligatoriamente:
•
le assunzioni che sono state fatte;
•
le minacce identificate;
•
le politiche di sicurezza dell’organizzazione.
3. Obiettivi di sicurezza, intesi come i modi nei quali vengono affrontate e risolte le
esigenze di sicurezza espresse nella parte precedente. Vengono suddivisi per:
•
obiettivi di sicurezza dell’ODV;
•
obiettivi di sicurezza dell'ambiente.
4. Requisiti di sicurezza IT, descritti quando possibile utilizzando i cataloghi messi a
disposizione dallo standard e riguardanti:
•
i requisiti funzionali dell’ODV;
•
i requisiti di garanzia dell’ODV;
•
i requisiti di sicurezza per l’ambiente IT.
5. Sommario delle specifiche dell’ODV, che racchiude i razionali riguardanti:
•
le funzioni di sicurezza IT fornite dall’ODV;
•
le misure di garanzia adottate per soddisfare rispettivamente i requisiti
funzionali e di garanzia specificati.
43
6. Motivazioni, ovvero le dimostrazioni (logiche e pratiche) che:
•
il TDS specifica un insieme completo di requisiti di sicurezza IT;
•
un ODV conforme al TDS affronta effettivamente le esigenze di sicurezza
identificate;
•
le funzioni di sicurezza IT e le misure di garanzia sono in grado di dare una
risposta ai requisiti di sicurezza dell’ODV.
Opzionalmente questo può anche contenere una dichiarazione di conformità
ad un Profilo di Protezione, con la specifica di ogni aggiunta o modifica degli
obiettivi e dei requisiti in esso specificati.
Per definizione il Traguardo di Sicurezza può essere sviluppato esclusivamente con
riferimento specifico ad un singolo prodotto, non ad una intera classe di questi. A
questo scopo è previsto il Profilo di Protezione, descritto nel seguito.
Profilo di Protezione
Il Profilo di Protezione è un documento, generalmente creato dal Cliente (utente o
comunità di utenti) che identifica i requisiti di sicurezza relativi a uno scopo preciso.
In altre parole, questo documento definisce un insieme di caratteristiche di garanzie
e funzioni che identificano la particolare classe di un singolo prodotto/sistema o di
una famiglia di prodotti/sistemi.
Dal punto di vista del fornitore/produttore dell’ODV l'utilizzo di questo documento può
essere duplice. Da un lato, esso può decidere di implementare e certificare prodotti
che rispettano le specifiche di sicurezza imposte da uno o più PP. Dall'altro il
documento può essere inteso come un template per generare un nuovo PP sulle
44
basi dei requisiti di sicurezza espressi per la classe di prodotti, magari ampliandone
lo spettro.
Dal punto di vista dell'utente, invece, un PP può essere utilizzato come criterio per
selezionare il tipo particolare di prodotto che soddisfa maggiormente la sua
particolare esigenza, sulla base di quanto in esso espresso (requisiti di sicurezza).
Dal punto di vista strutturale un PP è per molti versi analogo ad un TDS, in
particolare per quanto riguarda la descrizione dell’Ambiente di sicurezza dell’ODV,
degli Obiettivi di sicurezza, dei Requisiti di sicurezza IT e le motivazioni legate a
questi aspetti.
Quello che invece non è previsto in un PP riguarda le parti direttamente connesse
con l’ODV (e solo con esso), come il sommario delle specifiche di questo, la
conformità ad un eventuale altro PP e le motivazioni che dimostrano l’adeguatezza
delle funzioni di sicurezza e garanzia che permettono di soddisfare i requisiti di
sicurezza.
I due documenti, inoltre, potrebbero essere utilizzati congiuntamente: un TDS
potrebbe essere dichiarato conforme ad un PP, ereditandone direttamente i requisiti
funzionali e di garanzia. In questi casi è possibile solo fare riferimento al PP e
dettagliare le eventuali differenze con questo.
4.1.2. Utilizzo dello standard
Come si può leggere nel documento introduttivo ai CC del 1998, lo standard è stato
progettato per essere utilizzato in due modi differenti; in particolare:
45
•
come metodo standard per descrivere e razionalizzare i requisiti di sicurezza
(tramite PP e ST) di un prodotto/sistema IT
•
Come una solida base tecnica per valutare le caratteristiche di sicurezza e le
funzioni di sicurezza offerte dal prodotto/sistema IT
Mentre il secondo appare sicuramente più legato al concetto di valutazione espresso
fin d'ora, e quindi più comprensibile, per il primo occorre descrivere un tipico
contesto di utilizzo.
In un tipico scenario di sviluppo di un Profilo di Sicurezza, un gruppo di utenti (o una
comunità nel caso più auspicabile), analizzano quali funzioni e servizi debba offrire il
software o l'hardware, o più genericamente il sistema, che stanno progettando (o
che si dovrà progettare). E' da notare che si potrebbe trattare sia di un singolo
sistema, sia di un gruppo di sistemi preposti a svolgere una determinata funzione.
Verranno allora presi in considerazione tutti i prodotti o i componenti che potranno
essere utilizzati, identificando, per ognuno, le caratteristiche IT richieste. A questo
punto si prenderanno in considerazione l'ambiente nel quale il sistema dovrà
operare, identificandone le relative problematiche di sicurezza e i modi operativi di
utilizzo del prodotto/sistema di riferimento.
Questa attività, che presenta molti punti di contatto con l’Analisi del Rischio, sfocia
nel consolidamento dell'insieme dei requisiti e degli obiettivi di sicurezza sia per il
prodotto/sistema, sia per l'ambiente.
A questo punto gli obiettivi di sicurezza potranno essere tradotti in un set di requisiti
funzionali di sicurezza, standardizzati secondo i criteri della parte 2 dei CC, per poi
46
offrire una matrice di requisiti di garanzia (assurance) espressi come dettato nella
parte 3 dello standard stesso.
Questo processo potrebbe essere seguito non solo da una singola compagnia per
definire le caratteristiche di un sistema che si desidera offrire, o da un ente per
descrivere le caratteristiche del sistema che poi terzi andranno ad implementare, ma
anche da “gruppi” di produttori o fruitori che insieme definiscono una serie di linee
guida ufficiali per regolamentare gli aspetti di sicurezza dei loro sistemi.
Ecco quindi uno dei grandi vantaggi dello standard (che poi sarà meglio ripreso nel
paragrafo successivo): la possibilità di cooperazione nella redazione di un
documento di valenza generale, non riferito al singolo prodotto/sistema ma ad un
intero gruppo di questi.
Vanno evidenziati in questo semplice ed idealizzato processo due aspetti principali. Il
primo, naturalmente, è che si tratta solo di uno dei tanti esempi possibili di una
attività di redazione di un PP. Il secondo, invece, è che sarebbe auspicabile la
valutazione da parte di una terza parte indipendente (laboratorio accreditato) del
documento prodotto, al fine di garantirne non solo la qualità, ma anche la sua
consistenza ed interna coerenza.
4.1.3. Vantaggi e svantaggi dello standard
Nell'ottica di esprimere i possibili punti a favore o a sfavore dell'applicazione dello
standard, occorre notare che le considerazioni che seguono sono spesso di
carattere soggettivo, quindi difficilmente applicabili ad una pluralità di contesti per i
quali le condizioni al contorno (e quindi le considerazioni stesse) potrebbero variare.
47
Essendo, tuttavia, i CC uno standard in continua evoluzione, nato per potersi
adeguare in un contesto internazionale attraverso un certo grado di flessibilità e
numerose procedure di feedback, le versioni successive alla 2.3 (quella considerata
in questo documento) potrebbero prevedere nuove procedure nate proprio per
eliminare difetti riconosciuti dall'intera comunità di valutatori che ne fanno uso. A
questo proposito, in breve sarà rilasciata la versione 3.1 dello standard, che
diventerà ufficiale nell'aprile del 2008 e che introdurrà una serie di novità sostanziali.
Per una descrizione di tali cambiamenti si rimanda al capitolo 9 del presente
documento.
Tornando allo scopo di questo paragrafo, i principali vantaggi legati ad una
certificazione di sicurezza, in particolare condotta secondo lo standard Common
Criteria, potrebbero essere:
•
Valore
aggiunto
riconosciuto
a
livello
internazionale:
certificare
un
prodotto/sistema secondo i CC vuol dire anche poter garantire che il
prodotto/sistema stesso è stato progettato considerando e includendo
funzionalità di sicurezza e requisiti dell'ambiente operativo che siano adeguati
al soddisfacimento degli obiettivi di sicurezza identificati.
•
Valutazione eseguita da una terza parte accreditata: la presenza di laboratori
di valutazione ai quali siano state riconosciute adeguate competenze
specialistiche e che possano agire come terza parte nel processo di
certificazione garantisce l'imparzialità della valutazione e la conformità del
prodotto/sistema al livello di valutazione associato.
•
Prevenzione degli incidenti di sicurezza ICT: valutare un prodotto/sistema
secondo i CC vuol dire sottoporlo ad un processo di analisi che non solo si
48
prefigge di testarne la non vulnerabilità ad attacchi/minacce note, ma anche di
offrire adeguate garanzie che non sia possibile violarne le funzioni di
sicurezza attraverso metodologie o vulnerabilità ancora sconosciute. Queste
garanzie, naturalmente, aumentano con l'aumentare del livello della
valutazione, poiché i valutatori dispongono dell'accesso ad informazioni
relative al prodotto in esame sempre più complete (ad es. il codice sorgente)
e spesso non rese pubbliche. La valutazione di queste, ammesso che il livello
di specializzazione dei valutatori sia adeguato, di certo offre maggiori garanzie
rispetto alle procedure di testing condotte da un team specializzato, come ad
esempio quelle di ethical hacking. Questo aspetto va riconsiderato, tuttavia,
per scenari in cui qualsiasi informazione riguardo il prodotto/sistema sia
disponibile a chiunque, ovvero quelli legati al mondo dell’open source; anche
se la compatibilità tra i Common Criteria e questo tipo di prodotti è fortemente
inficiata da alcuni aspetti chiave dello standard, come la voluminosa
documentazione richiesta o il costo stesso della valutazione, va tenuto
presente che se si scegliesse di certificare un prodotto sviluppato secondo
questi criteri, l'accesso a informazioni riservate perderebbe senso, ma
rimarrebbe comunque valido il concetto che le verifiche effettuate sarebbero
comunque di maggiore garanzia rispetto ad altri tipi di valutazione o alla
completa assenza di una certificazione. Su questo concetto si rimanda alla
lettura del capitolo 9 del presente documento dove saranno sommariamente
presi in considerazione, tra l'altro, i possibili punti di contatto tra queste due
realtà.
•
Possibilità di esprimere in forma standardizzata le funzionalità di sicurezza e i
requisiti di assurance: i vasti cataloghi messi a disposizione dallo standard
49
permettono di esprimere questi concetti in modo standardizzato, conferendo
non solo maggiore visibilità o validità ai concetti stessi, ma consentendo
anche un più agevole confronto e favorendone l'utilizzo e il riconoscimento in
un maggior numero di scenari possibili. A titolo di esempio, i cataloghi
potrebbero essere sfruttati in una ipotetica fase di progettazione della
sicurezza di un sistema/prodotto ICT, o nella scrittura di un capitolato per
l'acquisizione di un insieme di sistemi/prodotti ICT, a prescindere dalla
successiva eventualità che si intraprendano procedure di certificazione su di
esso.
•
Possibilità di utilizzare uno dei Profili di Protezione a valenza generale messi a
disposizione dallo standard, come descritto nel paragrafo precedente.
I principali svantaggi che generalmente vengono riconosciuti allo standard, invece,
sono riassumibili come:
•
Lunghi tempi di valutazione/certificazione: al crescere del livello di valutazione
sia la documentazione prodotta, sia i già numerosi controlli da eseguire
aumentano progressivamente. Per questo motivo i tempi del processo di
valutazione spesso sono misurabili in termini di mesi, ad esclusione dei livelli
più bassi, come EAL1 o EAL2, per i quali invece si può anche parlare in
termini di settimane. Può quindi accadere che al termine della certificazione il
prodotto/sistema sia divenuto obsoleto, o che siano già stati rilasciati
aggiornamenti di sicurezza e/o nuove versioni del prodotto stesso.
•
Quantità rilevante di documentazione richiesta: al crescere del livello di
valutazione, come detto nel punto precedente, la quantità di documentazione
50
da produrre e presentare aumenta notevolmente, e con essa i costi ed i tempi
legati al processo di valutazione.
•
Costo elevato del processo: richiedendo l'utilizzo di risorse specializzate e di
terza parte, il processo di certificazione ha di per sé un costo, non
necessariamente elevato, ma comunque non indifferente. Come per gli altri
fattori, tuttavia, al crescere del livello della certificazione questo valore
aumenta a causa dell'aumentare del tempo necessario e delle risorse
impiegate. Questo aspetto ha fatto si che fino ad ora la certificazione sia stata
prevalentemente utilizzata in contesti legati alla sicurezza nazionale, per i
quali il budget difficilmente è limitato, o nella valutazione di prodotti/sistemi per
i quali l'investimento ha senso in ragione di una prevista notevole diffusione in
ambito nazionale e/o internazionale.
•
Processo di mantenimento della certificazione complesso: lo standard (e lo
Schema che sarà esposto nel capitolo 5 del presente documento) prevede
processi di mantenimento della certificazione a fronte di cambiamenti nella
configurazione, nelle caratteristiche e nelle funzioni di sicurezza del
prodotto/sistema. Questi processi, tuttavia, sono spesso inadeguati per un
contesto mutevole come quello della sicurezza ICT, nel quale è importante
applicare aggiornamenti di sicurezza nel più breve tempo possibile dalla
rilevazione di una vulnerabilità. Un approccio basato sulla rapidità di
“patching” del prodotto/sistema più che sulla sua certificazione potrebbe
rappresentare un vantaggio, ma d’altro canto potrebbe anche peccare non
solo riguardo all'analisi ed alla valutazione delle funzioni di sicurezza del
prodotto/sistema, ma anche degli aggiornamenti per esso distribuiti.
51
L'analisi dei punti espressi nel presente paragrafo è in generale oggetto della
definizione di una strategia che sia condivisa dai soggetti maggiormente implicati
nella certificazione, ovvero l’Ente Certificatore, il Laboratorio di Valutazione ed il
Cliente che richiede la certificazione. Per quanto riguarda l'Italia, l'OCSI ha
provveduto ad esprimere una propria strategia per la diffusione delle certificazioni di
prodotti/sistemi ICT, che sarà esposta nel prossimo.
4.2. ITSEC
Lo standard ITSEC, acronimo di Information Technology Security Evaluation Criteria
è, insieme al TCSEC, uno dei primi standard sviluppati espressamente per la
valutazione (e certificazione) di sistemi e prodotti nell'ambito della tecnologia
dell'informazione e della comunicazione.
Sviluppato in modo congiunto da Francia, Germania, Gran Bretagna e Olanda, è
stato pubblicato in versione definitiva nel giugno del 1991, raccogliendo da subito il
pieno consenso della Commissione della Comunità Europea. Per alcuni versi, ITSEC
si può considerare come la risposta europea all’orange book (TCSEC).
Nel corso degli anni lo standard, già approvato da organismi istituzionali, è stato
largamente impiegato e sperimentato; per questo motivo ITSEC è considerato
tutt'oggi una dei principali criteri attraverso il quale formulare un giudizio in materia di
sicurezza e qualità di un sistema o prodotto informatico.
Ad oggi, come premesso, lo standard ha perso consenso in favore dei più moderni
ed elastici Common Criteria, più adatti ad essere applicati nel moderno settore
52
dell'Information Technology; questo aspetto ne ha di certo ridotto l’utilizzo, ma non
ne ha per nulla intaccato la validità.
4.2.1. Descrizione dello standard
ITSEC è da molti considerato il progenitore dei moderni criteri di valutazione per
prodotti e sistemi IT; in effetti questo standard è stato il primo ad introdurre dei
concetti di base, poi largamente riutilizzati, tra i quali:
•
la considerazione per le misure di sicurezza non solo di carattere tecnico, ma
anche organizzativo, ambientale (intendendo le caratteristiche di sicurezza
dell'ambiente in cui il prodotto/sistema deve operare) e fisico;
•
la possibilità di valutare gli aspetti di sicurezza di prodotti hardware, software o
firmware, indistintamente;
•
l'identificazione univoca del promotore della valutazione (denominato
“sponsor”);
•
l'identificazione di enti preposti alla valutazione, formalmente accreditati per
condurre le attività (nello Schema Nazionale sono i Centri di Valutazione, o
CeVa e i Laboratori per la Valutazione della Sicurezza, o LVS);
•
l'identificazione univoca dell'oggetto della valutazione (TOE, Target Of
Evaluation, o in italiano ODV, Oggetto Della Valutazione);
•
la definizione del Traguardo di Sicurezza, TS (o in madrelingua Security
Target, ST);
•
la presenza di livelli di severità della valutazione flessibili (Assurance Level,
AL).
53
Tra questi riveste un ruolo molto importante il traguardo di sicurezza, soprattutto per
la rilevanza che questo attribuisce non solo allo specifico oggetto della valutazione,
ma anche all'ambiente per cui questo è progettato (si comincia a dare molta
rilevanza alle reti di calcolatori); nei criteri, in sintesi, questo documento è il punto
focale attorno al quale ruota tutto il processo di valutazione.
Per descrivere il processo logico di valutazione in ITSEC, allora, possiamo partire
proprio dal TS. Per definire un Traguardo di Sicurezza secondo lo standard è
necessario:
• definire gli obiettivi di sicurezza, a partire dai requisiti operativi del prodotto/
sistema e dell'ambiente di utilizzo in termini di riservatezza, integrità e
disponibilità;
•
individuare un insieme di minacce a cui il prodotto/sistema può essere
esposto;
•
definire le funzioni di sicurezza che il prodotto/sistema deve prevedere e
offrire;
•
individuare gli altri possibili meccanismi di sicurezza presenti e/o utilizzati dal
prodotto/sistema.
A fronte di questi ragionamenti e di questa “collezione” di informazioni sull’ODV, è
possibile redigere un TS, basandosi sul modello offerto dallo schema stesso, ovvero
componendo un documento composto da quattro parti fondamentali:
•
la politica di sicurezza del sistema (System Security Policy, o SSP) o la
descrizione del prodotto (Product Rationale) in caso di prodotto;
54
•
La specifica delle funzioni di sicurezza (Security Enforcing Functions, o SEF).
•
Il livello minimo dichiarato di robustezza dei meccanismi di sicurezza
(Strength of mechanism)
•
Il livello di valutazione desiderato (Assurance Level, o AL)
Iniziando dalla prima, nella SSP sono raccolte, in caso si tratti di un sistema, le
possibili minacce, gli obiettivi di riduzione delle stesse e l'insieme delle politiche che
devono essere adottate per trattare, proteggere e distribuire le informazioni critiche
per la sicurezza. In caso di prodotto, non essendo preventivamente noto l'ambiente
operativo reale, sono descritte le capacità in termini di sicurezza dell'oggetto e le
caratteristiche specifiche del prodotto stesso, nell'ottica di fornire quanta maggiore
informazione possibile riguardo le funzioni offerte da questo.
La SEF, invece, raccoglie e struttura le funzionalità in termini di sicurezza che il TOE
è capace di fornire, decise (in fase di progetto) dallo sponsor e specificate
puntualmente in fase di valutazione. I criteri suggeriscono, per la loro espressione
formale e per facilitare l'operazione di progetto, di utilizzare otto categorie generiche
fornite nel SEF, ovvero:
1. Identificazione ed autorizzazione (Identification and authentication)
2. Controllo degli accessi (Access Control)
3. Attribuibilità delle azioni (Accountability)
4. Ispezionabilità (Audit)
5. Riuso degli oggetti (Object reuse)
55
6. Accuratezza (Accuracy)
7. Affidabilità del servizio (Reliability of service)
8. Scambio di dati (Data exchange)
In questo modo la valutazione può operare sul duplice fronte dell'efficacia, ovvero
verificare
che
le
funzioni
garantiscano
efficacemente
la
sicurezza
del
sistema/prodotto nei confronti delle minacce previste, e della correttezza, ovvero se
queste siano state realizzate senza commettere errori. Queste due strade parallele
di valutazione consento di prendere in considerazione sia la fase di progettazione
dell’ODV, sia quella di messa in opera, lungo un percorso che esamina le capacità
delle funzioni di resistere ad attacchi diretti contro il sistema, quanto esse siano
idonee a realizzare gli scopi preposti e come (e quanto) siano state descritte nella
documentazione fornita dallo sponsor.
Alla valutazione della correttezza è assegnato il compito di fornire l'Assurance Level
associato all’ODV, secondo una scala che va da E0, ovvero nessuna fiducia, a E7,
ovvero fiducia massima. Per l'individuazione di questo valore si passano al vaglio
una lunga serie di fattori, ad esempio l'analisi della fase di sviluppo (e quindi dei
requisiti), progetto architetturale (Architectural Design), dettagliato (Detailed Design)
e realizzazione (Implementation). E’ prevista anche la conduzione di prove
indipendenti (ai livelli più alti) per confermare ed ampliare con i relativi risultati la
documentazione fornita dallo sponsor.
ITSEC conferisce una notevole importanza alla documentazione, sia essa quella di
risultato delle prove effettuate dallo sponsor, o quella destinata ad accompagnare
56
l’ODV nella sua distribuzione (documentazione utente, di amministrazione, di
installazione, ...).
Come detto la definizione dell’ambiente è considerato molto importante dai criteri,
anche di quello di sviluppo; per questo secondo lo standard bisogna considerare tre
aspetti principali: il controllo di configurazione, i linguaggi di programmazione
utilizzati (e i rispettivi compilatori) e la sicurezza dell'ambiente di sviluppo stesso. Per
questi, a seconda del livello considerato, aumentano i requisiti in termini di dettaglio
(relativo alla documentazione fornita) e di specifiche. A titolo di esempio, dal livello
E3 in poi è necessario non solo definire i linguaggi di programmazione utilizzati, ma
anche i compilatori e le librerie di runtime associate.
4.2.2. Utilizzo dello standard
Per la sua maggiore flessibilità rispetto agli altri standard temporalmente concorrenti
(e soprattutto a TCSEC) e per la sua natura Europea, ITSEC è stato accolto con
largo favore ed utilizzato, soprattutto nel decennio scorso, per la valutazione di
sistemi e prodotti legati principalmente all'ambito militare.
Gli anni di maggior lustro dello standard, inoltre, sono stati anche quelli che hanno
visto la nascita e la rapida evoluzione della firma digitale, e questo ha comportato
che ITSEC sia stato utilizzato spesso per la valutazione di sistemi e prodotti legati a
questa, nonostante il costo (in termini sia economici che di tempo) della valutazione
non fosse assolutamente esiguo.
57
4.2.3. Vantaggi e svantaggi dello standard
Come detto nei paragrafi precedenti, ITSEC introduce numerosi miglioramenti
rispetto a standard precedenti (TCSEC). Possiamo di certo dire che le principali
innovazioni introdotte sono state, in sintesi:
• maggiore flessibilità dei livelli di valutazione;
• alta considerazione per l'ambiente di sviluppo e per quello operativo dell’ODV;
• definizione e caratterizzazione dell’ODV stesso, con l'attenzione alla
differenziazione tra sistema e prodotto ed anche alla tipologia, prevedendo la
possibilità di poter valutare software, hardware o firmware;
• duplice valutazione dal punto di vista dell'efficacia delle funzioni di sicurezza e
della loro correttezza;
• introduzione dei principi di valutazione e delle funzioni di sicurezza per
ambienti “innovativi”, come reti di calcolatori e gruppi di sistemi interconnessi.
Lo standard, tuttavia, sia per la poca evoluzione temporale, sia per l'approccio non
certo orientato alla semplicità, ha dimostrato nel tempo di avere alcuni svantaggi
legati principalmente a:
• poca trasparenza rispetto agli elementi che qualificano la valutazione, che
sono definiti dallo sponsor, e sulle caratteristiche di sicurezza del TOE,
contenute solo nei documenti di valutazione;
• inadeguatezza rispetto a processi di mantenimento della certificazione a
fronte di aggiornamenti o variazioni tecnologiche;
58
• mancanza di coinvolgimento dello sviluppatore nel processo di valutazione;
• alta complessità di realizzazione dell'attività di valutazione e conseguente
costo del processo.
4.3. Gli standard a confronto
Volendo mettere a confronto entrambi gli standard Common Criteria e ITSEC vale la
pena di introdurre come riferimento il loro predecessore, ovvero il famoso (e già più
volte citato) TCSEC, o Orange Book.
Tutte e tre i criteri rappresentano delle metodologie approvate da organismi
istituzionali e accettate dalla comunità internazionale; nel corso del tempo sono tutti
stati utilizzati per certificare un corposo numero di prodotti e sistemi e sono stati (e
sono) riconosciuti come validi criteri di valutazione.
E' possibile, allora, operare due tipi di confronto: uno rispetto alle funzionalità che
con tempo sono state introdotte e migliorate, formando una linea temporale specifica
per questa classe di criteri, ed uno rispetto ai livelli di garanzia che i tre standard
mettono rispettivamente a disposizione.
Per il primo, occorre sicuramente focalizzare l’attenzione su alcuni punti specifici:
1. Maggiore formalizzazione del processo di valutazione: ITSEC e CC
identificano alcuni punti fondamentali della valutazione (TS, ODV, …) che
permettono di conferire da una parte maggiore flessibilità (soprattutto con
l’adozione del PP per i Common Criteria), dall’altro di aumentare la
comprensione e le possibilità di comparazione della documentazione
prodotta.
59
2. Maggiore coinvolgimento degli sviluppatori.
3. Supporto per il mantenimento della certificazione: i Common Criteria
prevedono processi di mantenimento della certificazione a fronte di
cambiamenti operati sulle funzioni di sicurezza (e sui requisiti) del
prodotto/sistema.
4. Aumento dei livelli di garanzia proposti: I Common Criteria, rispetto a TCSEC
e ITSEC ha aumentato il livelli di garanzia, per poter ridurre tempi e costi della
valutazione ed estendere lo spettro di applicabilità della certificazione.
5. Concetto di “evoluzione” dei criteri: i Common Criteria sono soggetti a
revisione continua, allo scopo di aggiornare le caratteristiche dello standard ai
requisiti delle nuove tecnologie, aumentare i cataloghi disponibili per la
definizione di requisiti e funzioni, rendere il processo di valutazione più
aderente alle esigenze degli utilizzatori.
Per il secondo, la tabella 3 riassume i livelli di garanzia offerti dai tre standard.
Tabella 3: Livelli di garanzia offerti da TCSEC, ITSEC e Common Criteria
TCSEC
D
Sicurezza Assente
ITSEC
E0
Garanzia Inadeguata
ISO/IEC 15408 (CC)
EAL0
Garanzia Inadeguata
60
C1
Sicurezza media
discrezionale
C2
Sicurezza media
obbligatoria
B1
Sicurezza medio-alta.
Nessuna modifica dei
permessi di accesso ai
file consentita.
B2
Classificazione del
livello di sicurezza dei
dispositivi hardware
B3
Impiego di hardware
specifico per progettare
risorse importanti
A1
Sicurezza massimacertificata
EAL1
Testato
funzionalmente
EAL2
ODV
strutturalmente
testato
EAL3
ODV
metodicamente
testato e controllato
E1
Descrizione informale
ODV
E2
ODV
E3
dell’ODV e del
progetto, testati con
metodo
EAL4
ODV
metodicamente
testato, progettato e
controllato
E4
ODV testato
metodicamente con
descrizione informale
del progetto
EAL5
ODV progettato e
testato semiinformalmente
E5
Progetto semiformale
con modello formale
delle politiche di
sicurezza
EAL6
Test e verifica del
progetto semiinformale
E6
ODV progettato e
testato formalmente in
accordo con il modello
formale delle politiche
di sicurezza
EAL7
Test e verifica
formale del progetto
61
5. Lo schema Nazionale
Come detto nei capitoli precedenti uno degli aspetti da tenere maggiormente in
considerazione nell’ambito della certificazione di sicurezza è quello relativo al
contesto normativo, ovvero di regolamentazione della certificazione stessa. E’ da
ribadire a tal proposito che la presenza di un solido strato normativo non solo è
qualificante e caratterizzante della certificazione stessa, ma consente anche di
stabilire una strategia propositiva per la sua diffusione.
In questo capitolo verranno presentate e descritte le caratteristiche dello Schema
Nazionale in materia di certificazioni per la sicurezza di prodotti e sistemi operanti nel
settore dell'informazione e della comunicazione, regolamentato dal DPCM del 11
aprile 2002, ovvero Schema Nazionale del 1995 aggiornato nel 2002, e dal DPCM
del 30 ottobre 2003, ovvero Schema Nazionale del 2003.
Nel testo normativo si legge che:
“l’ISCTI è l’Organismo di Certificazione della sicurezza nel settore della
tecnologia dell’informazione, anche ai sensi dell’articolo 10 del decreto
legislativo 23 gennaio 2002, n. 10 e dell’articolo 3, paragrafo 4 della direttiva
1999/93/CE”
Il decreto, quindi, riconosce che l’Istituto Superiore delle Comunicazioni e delle
Tecnologie dell’Informazione (ISCTI) del Ministero delle Comunicazioni possiede i
requisiti di indipendenza, affidabilità e competenza tecnica richiesti dalla decisione
della Commissione europea del 6 novembre 2000 (2000/709/CE) e stabilisce che
questi sia Organismo di Certificazione.
62
In questo ambito l’Organismo di Certificazione della Sicurezza Informatica (OCSI)
istituito dall’ISCTI è sia Organismo Certificatore che Ente Accreditatore, e gestisce
tutte le attività in materia di emissione dei Certificati, di accreditamento, sospensione
e revoca dell’accreditamento dei Laboratori di Valutazione della Sicurezza e della
abilitazione degli Assistenti di Sicurezza.
Lo stesso OCSI ha emesso, per consentire l’applicazione dello Schema Nazionale,
una serie di Linee Guida Provvisorie (LGP), organizzate in documenti distinti ed
attualmente in fase passaggio a Linee Guida Definitive. Tutte le variazioni a questi
documenti sono inoltre rese note tramite la pubblicazione delle Note Informative allo
Schema (NIS).
L’insieme di queste Linee Guida costituisce la definizione e la caratterizzazione delle
attività per le quali un Laboratorio è abilitato, comprensiva delle procedure operative
che devono essere rispettate in questo senso.
Quanto espresso nel presente capitolo è riferito alle attività di certificazione operanti,
come da Schema Nazionale, sia secondo lo standard europeo ITSEC che quello
internazionale Common Criteria, nonostante l'attenzione sia concentrata sul
secondo, considerato come evoluzione del primo e sicuramente
di più recente
attualità.
5.1. I soggetti coinvolti nella certificazione
Come rappresentato nelle linee guida provvisorie, i soggetti coinvolti nella
certificazione sono i seguenti:
63
•
Organismo di certificazione: unico ente accreditato per l’emissione dei
Certificati, per l’accreditamento dei Laboratori e l’abilitazione degli assistenti,
l’OCSI sovrintende a tutte le attività legate al processo di Valutazione e
Certificazione
della
sicurezza
nel
settore
dell’informazione
e
della
comunicazione.
•
Commissione di Garanzia: in Italia la Commissione di Garanzia è presieduta
da un membro prescelto dal Dipartimento per l'Innovazione e le tecnologie
della Presidenza del Consiglio dei Ministri e vede rappresentati al suo interno
il Ministro per l'Innovazione e le Tecnologie, il Ministero delle Comunicazioni, il
Ministero delle Attività Produttive, il Ministero dell'Economia e delle Finanze,
altri ministeri che risultino interessati al funzionamento dello Schema
Nazionale, l'ISCOM, gli LVS, i Fornitori e infine le Associazioni dei
Consumatori. Ha il compito di dirimere ogni tipo di controversia inerente alle
attività svolte all’interno dello Schema Nazionale quando nella controversia sia
coinvolto anche l'Organismo di Certificazione o quando quest'ultimo, pur non
essendo coinvolto, non sia riuscito a dirimerla.
•
Laboratori per la Valutazione della Sicurezza: strutture accreditate dall'OCSI
che effettuano le valutazione dei prodotti/sistemi e dei PP in accordo allo
Schema Nazionale e sotto il diretto controllo dell'OCSI. Per una descrizione
dettagliata di questa realtà si rimanda al capitolo 6 di questo documento.
•
Committenti:
i
soggetti
(in
qualsiasi
forma)
che
commissionano
le
certificazioni.
•
Fornitori: i soggetti intermediari che forniscono gli oggetti della valutazione
(possono essere anche i Committenti stessi).
64
•
Assistenti: persone formate e abilitate dall'OCSI che possano fornire supporto
tecnico al Committente o al Fornitore che ne faccia richiesta.
5.2. Struttura e descrizione dello schema
Lo schema nazionale si compone di una serie di documenti che contengono un
insieme di procedure formali che devono essere osservate dall'Organismo di
Certificazione, dai Laboratori per la Valutazione della Sicurezza e da tutti coloro che
richiedono una certificazione secondo gli standard CC o ITSEC o che sono
responsabili
della
progettazione,
installazione,
realizzazione
e
impiego
di
prodotti/sistemi certificati.
E' importante ricordare che lo schema nazionale trattato in questo documento non si
applica al contesto classificato, quello, cioè, inerente la sicurezza interna o esterna
dello Stato.
Lo Schema Nazionale è descritto per mezzo delle Linee Guida, un insieme di sette
documenti distinti, identificabili come LGP[x], con [x] che va da 1 a 7. Ognuno di essi
tratta nello specifico un determinato tema legato alla certificazione, alcuni dei quali,
come il processo di accreditamento o il percorso di certificazione, saranno trattati in
modo approfondito nel seguito. In linea generale, invece, è possibile riassumere il
contenuto delle linee guida come segue:
LGP1 - Descrizione generale dello Schema nazionale di valutazione e
certificazione della sicurezza
65
La LGP1, dopo aver introdotto il concetto di Schema nazionale, di sicurezza
IT e di accreditamento dei laboratori, affronta una descrizione sintetica del
processo di valutazione, identificando le finalità e i requisiti generali per
raggiungere la certificazione di un sistema/prodotto o di un Profilo di
Protezione. Vengono definiti e descritti i ruoli dei soggetti coinvolti nel
processo di valutazione e certificazione, con particolare enfasi per
l’Organismo di Certificazione, il Laboratorio di Valutazione della Sicurezza, il
Committente, il Fornitore e l’Assistente. Inoltre, vengono delineate le tre fasi
che caratterizzano il processo di valutazione: la preparazione, la conduzione e
la conclusione. Infine, viene delineata la fase di certificazione e si forniscono
delle informazioni per quanto concerne la gestione dei Certificati e il loro
mantenimento.
LGP2 - Accreditamento degli LVS e abilitazione degli Assistenti
La LGP2 definisce le procedure per ottenere e mantenere nel corso del tempo
l’accreditamento di un Laboratorio di Valutazione della Sicurezza informatica
secondo lo Schema nazionale per la valutazione e certificazione della
sicurezza nel settore della tecnologia dell’informazione. Inoltre, vengono
specificati gli ambiti di attività di un Laboratorio di Valutazione della Sicurezza
e descritti i requisiti generali gestionali e di competenza tecnica per i
laboratori. Infine, vengono descritti i requisiti e le procedure per ottenere
l’abilitazione al ruolo di Assistente.
LGP3 - Procedure di valutazione
66
La LGP3 definisce le procedure che devono essere seguite nel corso di un
processo di valutazione condotto all’interno dello Schema. Tale processo è
suddiviso in tre fasi distinte: preparazione, conduzione e conclusione. Le
procedure descritte in questa linea guida sono applicabili alla valutazione della
sicurezza di un sistema/prodotto o di un Profilo di Protezione, così come
definiti in ITSEC o nei Common Criteria, e descrivono le modalità secondo cui
effettuare:
•
le comunicazioni tra un Laboratorio di Valutazione della Sicurezza, un
Committente, un Fornitore e l’Organismo di Certificazione;
•
l’organizzazione e la pianificazione delle attività di una valutazione;
•
la finalità e il contenuto delle diverse tipologie di rapporti prodotti nel
corso della valutazione;
•
il controllo di una valutazione;
•
la pubblicazione dei risultati di una valutazione;
•
la chiusura della valutazione e il processo di certificazione con il rilascio
da parte dell’Organismo di Certificazione del Certificato.
LGP4 – Attività di valutazione secondo i Common Criteria
La LGP4 si prefigge l'obiettivo di definire la terminologia di riferimento in lingua
italiana per descrivere, discutere e analizzare l’insieme minimo di unità di
lavoro in cui possono essere scomposte le azioni di valutazione richieste per
svolgere la valutazione di un Profilo di Protezione e la valutazione di un
sistema/prodotto ai livelli di garanzia EAL1, EAL2, EAL3 e EAL4 secondo i
67
Common Criteria. Tutti i punti relativi alla valutazione di un ODV o di un Profilo
di Protezione contenuti nella LGP4 sono stati sviluppati tenendo conto dello
stato della normativa al gennaio 2004. La LGP4 contiene informazioni utili agli
utenti finali di prodotti/sistemi IT che sono stati sottoposti al processo di
valutazione, al personale direttamente responsabile della valutazione di un
sistema/prodotto o di un Profilo di Protezione, al personale che fornisce
assistenza al Committente di una valutazione, al personale responsabile della
stesura di un Traguardo di Sicurezza o di un Profilo di Protezione, e agli
sviluppatori di prodotti/sistemi IT che sono interessati a richiedere la
valutazione e la certificazione dei loro prodotti/sistemi.
LGP5 - Il Piano di Valutazione: indicazioni generali
La LGP5 fornisce ai Valutatori gli elementi fondamentali per definire, in base
ai criteri di valutazione ITSEC e Common Criteria, un Piano Di Valutazione
(PDV) della Sicurezza di un sistema/prodotto o di un Profilo di Protezione. Il
PDV è il documento che contiene la descrizione di tutte le attività che i
Valutatori debbono eseguire durante la valutazione e le modalità secondo le
quali queste attività risultano organizzate, pianificate, correlate e suddivise
nell'ambito del periodo di valutazione. La necessità di fornire delle istruzioni
per la definizione di un PDV nasce dall'esigenza di soddisfare più requisiti,
quali:
•
armonizzare tutta la documentazione e le procedure di valutazione alla
normativa internazionale e nazionale in vigore;
68
•
rendere omogenei e confrontabili i PDV prodotti da Laboratori per la
Valutazione della Sicurezza diversi;
•
garantire,
mediante
il
rispetto
delle
Linee
Guida,
l'obiettività,
l'imparzialità, la ripetitività e la riproducibilità delle attività di valutazione
indicate in un PDV.
LGP6 – Guida alla scrittura dei Profili di Protezione e dei Traguardi di
Sicurezza
Nella LGP6 sono fornite indicazioni per la scrittura dei Profili di Protezione
(PP) e dei Traguardi di Sicurezza (TDS) secondo le norme fissate dai
Common Criteria. Questa LGP è indirizzata principalmente a coloro che sono
coinvolti nello sviluppo dei PP/TDS. Tuttavia, può anche essere utile ai
Valutatori e ai responsabili della definizione e del controllo della metodologia
per la valutazione dei PP/TDS. Gli utenti finali possono altresì trovare utile
questo documento per comprendere i PP/TDS o per individuare le parti di loro
interesse. Viene dapprima fornita una panoramica sui PP/TDS, che
comprende un indice di riferimento; vengono quindi descritte in dettaglio le
sezioni
del
PP/TDS.
Infine,
sono
riportate
alcune
appendici
che
approfondiscono aspetti di particolare rilievo, tra cui la descrizione di esempi
di minacce, politiche di sicurezza, assunzioni e obiettivi di sicurezza, e
l’identificazione di adeguati componenti funzionali per specificare i requisiti
funzionali di sicurezza.
LGP7 – Glossario e terminologia di riferimento
69
Nella LGP7 sono raccolte tutte le definizioni in uso nello Schema nazionale.
Inoltre, è fornito un elenco di termini di uso comune che assumono un
significato specifico nei Common Criteria.
5.3. Il processo di valutazione e certificazione secondo lo
schema
Il processo di valutazione secondo lo schema nazionale si compone di tre fasi
principali: preparazione, conduzione e conclusione. In coda a queste se ne
aggiungono altre due, quella di certificazione che interessa per lo più l’Organismo
Certificatore (OCSI), e quella di chiusura della Valutazione, che coinvolge
attivamente sia il Laboratorio di Valutazione che l’Organismo Certificatore.
Una possibile schematizzazione grafica di queste fasi è fornita in figura 8.
70
Chiusura
Preparazion
Conduzione
Conclusione
Certificazione
Primo contatto tra
committente e LVS.
Il Committente:
• consegna TDS e/o
PP;
• prepara i materiali
per la valutazione.
Il Laboratorio:
• redige il PDV;
• redice l’elenco dei
materiali;
• invia all’OC la
richiesta formale di
iscrizione della
Valutazione nello
Schema.
Ottenuta l’iscrizione, Il Laboratorio:
il laboratorio passa in • redige il Rapporto
fase di valutazione,
Finale di
seguendo le attività
Valutazione (RFV);
riportate nel PDV e
• invia la
le procedure dello
documentazione
Schema.
all’OC
L’OC:
• analizza la
documentazione;
• emette il Rapporto
di Certificazione.
In caso di RFV e RC
positivi, viene
emesso dall’OC il
Certificato e viene
data formale
comunicazione
all’LVS di chiusura
lavori.
Figura 8: Processo di valutazione e certificazione secondo lo Schema Nazionale
Tutte queste procedure contenute nelle linee guida provvisorie (in particolare LGP3)
si applicano sia per una generica valutazione, sia per:
•
una valutazione concomitante (cioè effettuata durante lo sviluppo di un ODV);
•
una valutazione consecutiva (cioè effettuata dopo lo sviluppo di un ODV);
•
una ri-valutazione di un ODV o di un PP;
•
una riutilizzazione dei risultati di una precedente valutazione di un ODV o di
un PP.
71
Ponendoci nell'ottica di voler sintetizzare l'intero processo tramite i passi
fondamentali che lo compongono, è possibile scomporre le singole fasi in blocchi
indipendenti caratterizzati da un ingresso e da una uscita determinati.
La fase di preparazione, allora, inizia con il contatto tra il Committente ed il
Laboratorio di Valutazione, a cui sottopone il Traguardo di Sicurezza e/o il Profilo di
Protezione da lui elaborati. La redazione di questi documenti deve essere portata a
termine esclusivamente dal Committente, che al limite può avvalersi dell’ausilio di un
Laboratorio accreditato o di Assistenti tra quelli abilitati dall'OCSI e di cui è
disponibile sul sito dell'Organismo di Certificazione un elenco completo e
continuamente aggiornato.
Il Laboratorio, ricevuti i documenti, procede con l’analizzarli entrambi e prepara un
nuovo documento, denominato Piano di Valutazione (o PDV), secondo i criteri dettati
dalle linee guida provvisorie, ed in cui sintetizzerà il piano di attività necessario
all'adempimento dell'attività di valutazione. A corredo di questo documento sarà reso
disponibile un elenco completo e dettagliato dei materiali necessari alla valutazione.
Una volta che il PDV e l'elenco dei materiali sarà stato sottoposto all'OC, ammesso
che non vi siano obiezioni al progetto da parte di questo e che siano disponibili tutti i
materiali per la valutazione, la fase di preparazione si conclude con la richiesta
formale del Laboratorio di iscrizione della valutazione nello Schema, accompagnata
dai nominativi dei Valutatori e dei Responsabili identificati.
72
Materiali per la
Valutazione
Elenco completo
dei materiali
Pianificazione
del processo
Rapporto di
adeguatezza della
valutazione
Preparazione
TD S
Richiesta di
Iscrizione allo
PP
PD V
Figura 9: Diagramma della fase di preparazione della valutazione
La seconda fase, e cioè di conduzione, inizia quando l'OC, valutata la richiesta di
iscrizione allo Schema, notifica il risultato positivo di questa. Effettuati quindi tutti i
controlli di pianificazione del caso, la fase in esame ha inizio formale con la Notifica
di inizio lavori, che il Laboratorio provvede a trasmettere all'OC. Tralasciando il
complesso
sistema
di
redazione
dei
Rapporti
di
Attività,
Metodologia
e
Osservazione, il cui ciclo di vita è dettagliatamente descritto nelle Linee Guida
Provvisorie, la fase di conduzione corrisponde al cuore dell'attività di valutazione: in
essa, cioè, i valutatori eseguono la valutazione secondo lo standard (CC o ITSEC)
ed in base alla pianificazione delle Attività di Valutazione definita nel PDV.
Al termine di ogni attività vengono prodotti rapporti formali registrati dall'OC. In
definitiva, allora, si può schematizzare l'attività di conduzione della Valutazione come
un blocco avente in ingresso il Piano di Valutazione, il TDS e/o il PP e l'elenco
73
completo dei materiali per la valutazione, redatti nella fase precedente, e come
uscita:
•
Rapporti di Osservazione
•
uno o più Rapporti di Attività
•
eventuali Rapporti di Osservazione e NIS
•
eventuale Rapporto delle Metodologie
•
verbali delle Riunioni di Avvio dei Lavori e delle Riunioni di Controllo della
Valutazione.
RO
RA
Elenco completo dei
materiali
Richiesta di Iscrizione
allo Schema
RM
Conduzione
ROS-NIS
PD V
VERBALI
Figura 10: Diagramma della fase di conduzione della valutazione
E' importante, in questo contesto, fare una osservazione: tutto il processo di
conduzione dell'attività di valutazione è strettamente seguito dall'OC, che in pratica
supervisiona l'attività del Laboratorio partecipando spesso alle Riunioni ed
analizzando e validando tutta la documentazione emessa da questo.
74
Ultima delle fasi del processo è quella di conclusione dell'attività di Valutazione, che
riceve in input la documentazione prodotta dal Laboratorio e si conclude con la
redazione e la sottomissione all'OC del Rapporto Finale di Valutazione (RFV).
Questo documento, la cui struttura è dettata, al solito, dalle linee guida, contiene un
adeguato riassunto di tutte le attività di Valutazione svolte dal Laboratorio.
RO
RA
RFV
RM
ROS-NIS
Conclusione
VERBALI
Figura 11: Diagramma della fase di conclusione della valutazione
Tutte le informazioni riservate che vengono trattate nel corso delle tre fasi del
processo devono essere opportunamente protette e visibili solo dal personale
abilitato del Laboratorio e dall'OC. In particolare per l'RFV, questo potrà essere
redatto in due versioni differenti, una contenente le suddette informazioni e destinata
all'OC e l'altra (divulgabile) destinata al Committente.
Al termine del processo di valutazione corrisponde l'avvio di quello di Certificazione,
che vede coinvolto l'OC per l'analisi e la verifica della documentazione (in particolare
l'RFV) ufficiale e il Laboratorio per il supporto all'OC. La fase si conclude con
75
l'emissione del Rapporto di Certificazione e del Certificato stesso da parte di questa
e con la richiesta di chiusura del processo di valutazione da parte del Laboratorio.
RFV
Chiusura
Chiusura formale
del processo di
Valutazione
RC
Certificazione
Certificato
Figura 12: Diagramma delle fasi di chiusura della valutazione ed emissione del certificato
5.4. Mutuo riconoscimento
Uno degli aspetti fondamentali di un processo di Certificazione è la valenza del
certificato in ambito nazionale ed internazionale. Mentre il primo è implicito, nel
senso che una volta emesso il certificato questo potrà essere considerato valido e
mantenuto secondo le opportune procedure all'interno della nazione nel quale la
certificazione è avvenuta, il secondo richiede qualche passaggio in più.
Per estendere la validità di certificati emessi in ambito internazionale nel suo
territorio, è necessario che l’Organismo Certificatore di un determinato paese faccia
parte di un network ufficiale formato da suoi corrispettivi in paesi esteri. Tale network
internazionale è denominato, nell’ambito dei CC, Common Criteria Recognition
76
Arrangement (CCRA); per farne parte, l’OC deve farne richiesta ufficiale e seguire un
processo di iscrizione determinato.
Per emettere certificati che siano ritenuti validi in ambito internazionale, invece, l’OC
deve sottoporsi ad un processo di valutazione (denominato shadow evaluation,
valutazione ombra) effettuato da una commissione formata dagli attuali membri del
CCRA.
Al termine di questa valutazione l'OC (e quindi del paese stesso) entra all'interno del
circuito internazionale di “mutuo riconoscimento”, che conferisce ai suoi certificati la
validità sopra descritta.
Attraverso questo processo di “certificazione del certificatore” è possibile affermare e
garantire che l’OC opera secondo le modalità previste dallo standard Common
Criteria (definite in ambito internazionale), aumentare la disponibilità di prodotti
certificati e, soprattutto, evitare la necessità di duplicare il processo di
valutazione/certificazione per paesi differenti.
Attualmente l'Italia ha sottoscritto il CCRA, riconoscendo, di fatto, i certificati emessi
dagli altri Organismi di Certificazione afferenti al circuito, ed è in attesa di completare
il la fase di valutazione ombra.
Una volta che questo processo sarà portato a termine ogni certificato emesso
dall'OCSI sarà valido su scala internazionale e costituirà un notevole punto di forza
del processo di certificazione stesso nella nostra nazione.
5.5. La strategia italiana per la diffusione della certificazione
77
Come specificato nei paragrafi precedenti, l’attuale quadro normativo identifica la
certificazione di sicurezza per prodotti e sistemi operanti nel settore IT, almeno in
ambito non classificato, come atto volontario. I documenti [31], “Linee guida per la
sicurezza ICT delle pubbliche amministrazioni”, pubblicato dal CNIPA ed il [32],
“Proposte concernenti le strategie in materia di sicurezza informatica e delle
telecomunicazioni per la pubblica amministrazione”, hanno sollevato il problema di
identificare contesti specifici nei quali la certificazione secondo lo Schema Nazionale
ed i criteri ITSEC e CC debba essere intesa più come un requisito che come un
valore aggiunto.
Nello scenario odierno, infatti, la diffusione della certificazione è sbilanciata, dovendo
rispondere molto più a fattori di tipo economico e commerciale che a considerazioni
sui benefici che questa porti in termini di sicurezza e garanzia.
Allo scopo di favorirne la diffusione, allora, l’Organismo di Certificazione ha adottato
una strategia adatta alle esigenze del mercato ed al contesto normativo vigente,
basata su due tipi di considerazioni.
In primo luogo, dall’esperienza maturata nel contesto estero è emerso che per
quanto riguarda la certificazione di prodotto sono principalmente richiesti livelli di
garanzia medio-alti (EAL4 in su), situazione motivata dalle politiche concorrenziali
adottate dai vari vendor internazionali, mentre sono richiesti livelli medio-bassi per la
certificazione di sistemi. Tuttavia, dato il costo elevato del processo, i tempi richiesti
e la contrastante natura evolutiva del settore IT, la diffusione è stata limitata a
prodotti specifici, come quelli di difesa perimetrale o smart cards. La certificazione
dei PP, invece, è stata favorita dalle loro molteplici possibilità di utilizzo, mentre sono
stati rari i casi in cui i Committenti decidessero di aderire alle procedure di
78
mantenimento dei certificati, soprattutto per gli ulteriori oneri economici che queste
comportano e per la poca possibilità che gli Organismi di Certificazione hanno di
vigilare sull’utilizzo di certificati non più validi (sia formalmente che praticamente).
D’altro canto, analizzando la situazione italiana ci si rende conto che potrebbe non
esserci mercato per la certificazione di prodotti a livelli di garanzia medio-alti, proprio
perché il mercato è ricco di aziende medio-piccole che forniscono servizi di
integrazione e che raramente puntano il loro core business sulla ricerca, lo sviluppo
e, quindi, la produzione di tecnologia. Al contrario la certificazione di sistema
potrebbe essere favorita da questi fattori ed appetibile per un vasto numero di realtà
pubbliche o private che vogliano comprovare (anche a fini pubblicitari e commerciali)
di aver provveduto al rafforzamento in termini di sicurezza dei propri sistemi. Questa
considerazione acquista di validità soprattutto se si pensa che ha poco senso
utilizzare prodotti molto sicuri (e certificati con alti livelli di garanzia) in sistemi molto
vulnerabili, cosa che invece accade spesso a causa della scarsa diffusione di cultura
e sensibilizzazione in materia di sicurezza.
Alla luce di questi fattori, allora, l’OCSI ha individuato una strategia che punta
essenzialmente a:
•
promuovere la certificazione ai primi livelli di garanzia, soprattutto per sistemi
ICT;
•
promozione del mantenimento sistematico dei certificati;
•
stimolo della domanda di sistemi certificati, operando soprattutto una
sensibilizzazione in materia degli utilizzatori finali dei servizi;
79
•
diffusione della certificazione di sistema a bassi livelli di garanzia nella
Pubblica Amministrazione, al fine di innescare il meccanismo virtuoso
conosciuto come “government by example”;
•
promozione della certificazione di Profili di Protezione e nella loro utilizzazione
all’interno di capitolati di fornitura di sistemi/prodotti sia in contesti privati che
nella Pubblica Amministrazione;
•
diffusione della certificazione di tipo BS27001 congiuntamente a quella
secondo i Common Criteria, almeno per gli aspetti che entrambe hanno in
comune.
80
6. Il Laboratorio di Valutazione per la Sicurezza (LVS)
Come descritto ampiamente nei paragrafi precedenti, uno degli attori più importanti
nel processo di certificazione di sicurezza è il Laboratorio di Valutazione (LVS). Nel
seguito di questo capitolo verrà descritta in maniera dettagliata questa realtà, con lo
scopo di definire i concetti di base necessari alla successiva fase di progettazione.
6.1. Cosa rappresenta
Il Laboratorio di Valutazione della sicurezza svolge, all'interno del processo di
certificazione, uno dei principali ruoli, mantenendo una posizione di intermediario tra
Ente Certificatore e Committente e svolgendo, tra le altre, attività di valutazione degli
ODV o dei PP. Accreditato formalmente da un ente preposto (in Italia viene
accreditato dallo stesso Ente Certificatore, cioè l'OCSI) e operando sotto il controllo
dell'Ente Certificatore, i requisiti che un LVS deve garantire ai fini dell'accreditamento
e della corretta conduzione dei processi di valutazione che svolge, sono riportati
all'interno delle Linee Guida emesse dall'OCSI, ovvero:
•
capacità
di
garantire
l’imparzialità,
l’indipendenza,
la
riservatezza
e
l’obiettività, che sono alla base del processo di valutazione;
•
disponibilità di locali e mezzi adeguati ad effettuare valutazioni ai fini della
sicurezza nel settore della tecnologia dell’informazione;
•
organizzazione in grado di controllare il rispetto delle misure di sicurezza e
della qualità previste per il processo di valutazione;
81
•
disponibilità di personale sufficiente dotato delle necessarie competenze
tecniche e iscritto nell’elenco dell’organismo di certificazione;
•
conformità ai requisiti specificati nelle norme UNI CEI EN ISO/IEC 17025 e
UNI CEI EN 45011, per quanto applicabili;
•
capacità di mantenere nel tempo i requisiti in virtù dei quali è stato
accreditato.
Particolare attenzione deve essere posta per quelli di riservatezza: operando
direttamente nel processo di valutazione, per il laboratorio transitano tutte le
informazioni relative al sistema/prodotto in esame, che siano riservate, pubbliche o
sensibili. L'importanza di garantire la massima riservatezza su tutte queste
informazioni, quindi, costituisce un ulteriore requisito essenziale per rispondere alle
esigenze del Committente e per operare nel rispetto della legge. A questo scopo il
laboratorio deve prevedere un accordo di non divulgazione dei dati che il
committente può scegliere di sottoscrivere qualora ne facesse richiesta.
Il laboratorio che decide di accreditarsi, inoltre, può essere un organismo pubblico o
una impresa regolarmente registrata secondo le norme vigenti.
Possiamo dire, quindi, che l'LVS rappresenti l'entità centrale del processo di
valutazione ed al suo interno, come vedremo nel seguito del paragrafo, vige
un'organizzazione puntuale sia dal punto di vista della pianificazione del lavoro, sia
da quello dei ruoli operativi, sia dal punto di vista della conduzione delle attività per le
quali è abilitato.
82
6.2. Le attività e le responsabilità
Punto di snodo essenziale nel processo di certificazione e responsabile delle attività
nei confronti del Committente, il Laboratorio offre una serie di servizi che possono
essere essenzialmente riassunti nel modo seguente:
•
Valutazione secondo lo schema nazionale e gli standard Common Criteria e
ITSEC, per il livello a cui è abilitato, di sistemi e prodotti operanti nel settore
dell'Informazione e della comunicazione e comunque non destinati al contesto
classificato.
•
Valutazione secondo lo schema nazionale e gli standard Common Criteria e
ITSEC, per il livello a cui è abilitato, di Profili di Sicurezza destinati ad essere
applicati ed applicabili per uno o una serie di prodotti e sistemi operanti nel
settore dell'Informazione e della comunicazione e comunque non destinati al
contesto classificato.
•
Assistenza al Committente per:
o la stesura della documentazione di sicurezza durante la preparazione
della valutazione;
o la determinazione della valutabilità del TDS, ODV o Profilo di
Protezione;
o le attività connesse con la gestione e il mantenimento dei Certificati.
•
Formazione sulle tematiche della sicurezza nel settore della tecnologia
dell’informazione in generale e, in particolare, sulle tecniche di valutazione.
83
Eccezion fatta per quella di valutazione, per la quale esiste un protocollo di
comunicazione con l'OC stabilito, tutte le altre attività possono essere condotte in
piena libertà dal laboratorio' con l'unica clausola di darne comunicazione preventiva
all'OC.
Di seguito sarà data una breve descrizione delle attività sopra esposte, con
l'esclusione di quella di valutazione, già analizzata in dettaglio nel paragrafo 5.3.
Assistenza per la preparazione della valutazione
A
causa
dell’elevata
complessità
del
processo
di
valutazione,
le
organizzazioni coinvolte spesso hanno la necessità di richiedere l’assistenza
di esperti, che possono appartenere o meno a un LVS. L’assistenza può
essere fornita prima che una valutazione inizi o in parallelo alla valutazione
stessa e può essere data:
•
al Committente di una valutazione;
•
al Fornitore di un ODV;
•
all’OC.
Tipicamente l'attività consiste nel supportare la stesura o la revisione di un
TDS, di un PP o comunque di ogni altra documentazione necessaria per la
valutazione.
L'ambito dell'assistenza durante la valutazione viene direttamente negoziato
tra il Committente e l’Assistente. L’OC lascia i dettagli contrattuali alle due
parti in gioco, senza alcun coinvolgimento. Comunque, quando un LVS
84
fornisce sia l'assistenza sia il servizio di valutazione per un particolare ODV o
PP, è obbligato sia a definire chiaramente l'ambito dell'assistenza, sia a
dimostrare all'OC che l'assistenza fornita non influenza l'indipendenza dei
Valutatori o l'imparzialità della valutazione, assicurando che sia sempre
rispettata la separazione e la distinzione tra le strutture e le persone che
forniscono l’assistenza e quelle che effettuano la valutazione. Nel caso,
inoltre, l’LVS faccia uso di Assistenti esterni nel corso di una valutazione, è
tenuto ad informare l’OC di tutte le assistenze fornite e ricevute in quel
contesto.
Assistenza per la determinazione della valutabilità
La certificazione è un processo che ha un costo non indifferente, soprattutto
quando vengono selezionati livelli di assurance medio-alti (ad es. da EAL4 in
su per i CC), e che comporta un notevole impiego di tempo e risorse
professionali. Un ipotetico Committente, allora, può sottoporre una bozza
documentale o semplicemente l'idea di certificare un prodotto/sistema
all'attenzione di un Laboratorio accreditato, in modo da ottenere una
previsione (sia temporale che economica), o semplicemente maggiori
informazioni sul processo di valutazione e certificazione, in vista della propria
volontà di intraprendere questo percorso. In questo caso il laboratorio offre un
servizio di assistenza a fronte di una ipotetica valutazione, per la quale il
Committente potrà servirsi dello stesso Laboratorio o selezionarne un altro
accreditato. E' anche possibile (seppur improbabile nel contesto italiano) che
l'ipotetico Committente sia anche il produttore di uno specifico “oggetto” legato
85
alla sicurezza IT (ad esempio un firewall); in questo caso egli può rivolgersi al
Laboratorio prima della progettazione formale del proprio prodotto, per
ottenere delle indicazioni su come orientare il processo di sviluppo in modo da
rendere il risultato finale maggiormente adatto ad essere valutato e certificato
e, soprattutto, più sicuro. In questo caso il Laboratorio fornisce un servizio
analogo al caso precedente, ma con il valore aggiunto di operare ad un livello
più profondo essendo coinvolto dalle basi dello sviluppo del futuro sistema o
prodotto che, un giorno, potrebbe anche essere sottoposto a certificazione.
Assistenza per il mantenimento della certificazione
Un Certificato rilasciato nell’ambito dello Schema nazionale di valutazione e
certificazione della sicurezza è valido, come già detto, solo per la versione
dell’ODV valutata e nella configurazione dichiarata. Tuttavia la maggior parte
dei prodotti o sistemi utilizzati nel settore della sicurezza IT sono spesso
soggetti a revisione e modifica, per correggere problemi e vulnerabilità note
(patch di sicurezza) o semplicemente per introdurre nuove funzionalità di
sicurezza (come una nuova release dello stesso prodotto). Per queste ragioni
è stato introdotto lo Schema di Gestione dei Certificati (SGC), ovvero uno
strumento mediante il quale è possibile conservare la validità della
certificazione a fronte di modifiche effettuate su un prodotto o sistema già
certificato. Punto chiave in questo senso è la possibilità, prevista dallo
Schema, di sottoporre a valutazione solo le variazioni effettuate sull’ODV,
evitando la ripetizione di tutte le attività di valutazione svolte nel corso della
certificazione originale, al fine di semplificare e snellire il processo. E’ quindi
86
possibile per il Committente/Fornitore aderire all’SGC ed estendere la validità
della certificazione all'ODV modificato dimostrando, mediante lo svolgimento
di un sottoinsieme minimo di azioni di valutazione, l'idoneità delle modifiche
apportate ai fini del raggiungimento degli obiettivi di sicurezza. L’adesione allo
Schema è su base volontaria e può avvenire in fase di valutazione o
successivamente alla emissione del Certificato. E’ necessario, ove si aderisca
allo Schema, indicare un Responsabile per la Gestione del Certificato (RGC),
facente parte della propria organizzazione o appartenente ad un Laboratorio
di Valutazione, o ancora un Assistente abilitato che si impegni ad attuare le
procedure di Gestione del Certificato. La tipologia di attività che si svolge in
questo caso è del tutto analoga a quella del processo di valutazione, limitata,
naturalmente, dalla minore entità delle verifiche da eseguire.
Formazione
Un Laboratorio rappresenta un insieme di figure professionali (i valutatori)
addestrate ed abilitate dall’Organismo di Certificazione a condurre le attività di
valutazione, sottoposte regolarmente ad una opportuna verifica delle
competenze richieste dalle attività stesse. Oltre a queste, tutto il personale
facente parte del Laboratorio è composto da soggetti che posseggono alte
competenze non solo di prodotti o sistemi, ma soprattutto riguardo le principali
problematiche in materia di sicurezza nel settore ICT. Non capita di rado,
inoltre, che gli stessi soggetti siano in possesso di certificazioni di competenza
del personale, come CISA, CISSP, ITIL o simili. Questo aspetto consente
all'intero Laboratorio di presentarsi come struttura competente ed adatta a
87
fornire servizi di formazione sulle tematiche della sicurezza nel settore della
tecnologia dell’informazione in generale ed, in particolare, sulle tematiche, le
tecniche e le finalità di attività di valutazione.
6.3. Organigramma e figure professionali
Nella sua struttura organizzativa, un laboratorio di Valutazione è sottoposto a dei
vincoli specifici riguardanti la sua strutturazione logica ed operativa. Un esempio di
tale struttura è rappresentato graficamente in figura 13.
Responsabile del
Laboratorio
Valutatori con
profilo
documentale
Valutatori con
profilo
operativo
Responsabile
Qualità
Responsabile
rapporti con
l’OCSI
Figura 13: Esempio di organigramma per un LVS
Le Linee Guida non forniscono una limitazione sul numero di persone che
compongono un Laboratorio, ma ne identificano alcune basilari di cui questo non
può fare a meno, definendo una massa critica necessaria tanto in fase di
accreditamento quanto operativa. In particolare sono definite le figure di:
88
Responsabile del Laboratorio
Responsabile di qualsiasi attività svolta dall'LVS, Il Responsabile del
Laboratorio deve anche provvedere a mantenere i rapporti con l'OC, a
nominare i Valutatori ed il Responsabile per l'LVS in ogni singola valutazione.
Qualora ci fosse una variazione nel personale impiegato nel laboratorio, esso
deve provvedere a dare comunicazione immediata in modo formale all'OC,
come anche a fronte di qualsiasi altra modifica significativa rispetto alle
informazioni fornite in fase di accreditamento. E' d'obbligo designare una
figura sostitutiva del Responsabile, che ne fa le veci qualora non sia
disponibile (ad esempio perché non ancora designato o perché non più in
carica), che deve essere indicato nel relativo manuale di qualità.
Responsabile della Qualità
Il Responsabile Qualità è la persona incaricata di tenere aggiornato e
migliorare continuativamente il Sistema Qualità e la sua applicazione.
Particolarmente sensibilizzato in fase di formazione sull'importanza di seguire
rigorosamente le procedure definite nel rispetto della norma e della
documentazione di accreditamento, ha come obiettivo primario il continuo
miglioramento del Sistema per arrivare al rispetto delle procedure necessarie
per il raggiungimento e mantenimento dell'accreditamento del Laboratorio e
per arrivare a generare servizi di qualità sempre più elevata verso il Cliente
(rispetto dei tempi pianificati e riduzione dei tempi morti, miglioramento delle
comunicazioni tra cliente e Laboratorio, etc.). Come per il Responsabile del
89
Laboratorio, per questa figura è obbligatorio fornire, nel manuale della qualità,
l'indicazione di un sostituto che ne faccia le veci in caso di assenza.
Responsabile dei rapporti con l'OC
Il Responsabile dei rapporti con la Sezione Accreditamento dell’OC è l’unica
persona autorizzata a intrattenere rapporti formali durante la procedura di
accreditamento. Tale figura è inoltre responsabile della gestione dei certificati.
Valutatori con profilo documentale
Il valutatore con profilo orientato alla redazione ed all’analisi della
documentazione è in grado di condurre il processo di valutazione di prodotti e
sistemi informatici ad ogni livello di sicurezza richiesto. Può svolgere in
autonomia qualsiasi tipologia di servizio; può definire nuovi metodi di
valutazione, effettuare campionamenti e pianificazioni di test ed avere la
responsabilità di un servizio o di una Valutazione; può supportare il
Responsabile del Laboratorio nella definizione dell’offerta tecnica per uno
specifico servizio. Il valutatore possiede una adeguata preparazione nel
campo della sicurezza IT, conosce lo Schema Nazionale, i criteri ITSEC e
Common Criteria e le relative metodologie.
Valutatori con profilo operativo
Il valutatore con profilo orientato all’operatività possiede una adeguata
preparazione nel campo della sicurezza IT, conosce lo Schema Nazionale, i
90
criteri ITSEC e Common Criteria e le relative metodologie ed è addetto
all’esecuzione delle prove pratiche sull’ODV, all’analisi e alla gestione
operativa in genere delle attività sperimentali. Il valutatore con profilo orientato
all’operatività è, quindi, in grado di:
•
progettare test indipendenti,
•
verificare la configurazione dell’Oggetto della Valutazione,
•
condurre un’analisi di vulnerabilità,
•
individuare vulnerabilità note,
•
svolgere prove di intrusione.
Tale figura costituisce la vera forza produttiva del Laboratorio e riveste
considerevole importanza per la qualità dei servizi resi, specie nel caso di
processi sperimentali poco routinari e scarsamente automatizzati. Oltre alle
normali conoscenze in materia di IT e di sicurezza IT, quindi, il valutatore
operativo deve anche avere comprovata preparazione tecnica per condurre
attività non usuali riguardo i test che possono essere fatti in fase di
valutazione e prova, come ad esempio:
•
Audit di sicurezza
•
Tracciamento dei requisiti di sicurezza
•
Test di intrusione
•
Analisi di vulnerabilità
•
Revisione del codice sorgente
91
•
Prove sul codice eseguibile
Valgono inoltre le seguenti considerazioni riguardo le figure sopra citate:
•
E' richiesto un numero minimo di tre persone operanti nel laboratorio, con
almeno due valutatori (uno per ogni profilo) in aggiunta al Responsabile
dell'LVS.
•
I Valutatori devono essere indipendenti nello svolgimento delle loro attività. Il
Valutatore è formato, addestrato ed abilitato dall’Organismo di Certificazione a
condurre le attività di valutazione. Qualora uno o più Valutatori di un LVS
diano assistenza ad un Fornitore o Committente per un ODV o parte di esso,
gli stessi non potranno partecipare alla valutazione dello stesso ODV. La
qualifica di Valutatore è valida solo ed esclusivamente all'interno di un LVS.
•
Un Valutatore non può in nessun caso partecipare contemporaneamente allo
sviluppo ed alla valutazione di un ODV o di un PP, oppure fornire al
Committente di una valutazione o al Fornitore di un ODV o PP servizi di
assistenza che potrebbero compromettere l’indipendenza della valutazione.
L’LVS deve conformarsi alle condizioni fissate nell’accreditamento per
garantire che l’assistenza fornita non influenzi la sua indipendenza o
imparzialità in ogni valutazione. L’LVS deve informare l’OC qualora si verifichi
un potenziale conflitto di interessi. In tal caso, l’OC verificherà che tutte le
condizioni poste agli LVS siano rispettate e determinerà se i potenziali conflitti
di interessi possono effettivamente minacciare l’integrità delle valutazioni
condotte all’interno dello Schema.
92
•
In fase di accreditamento e durante le visite ispettive periodiche viene
normalmente verificata la competenza di ogni componente dell’LVS, secondo
quanto previsto nella presente Linea Guida. L’OC si riserva la possibilità di
verificare la competenza tecnica del personale di un LVS anche in tempi
diversi dalle visite ispettive periodiche, ad esempio quando si verifichi una
qualsiasi variazione nella composizione dell'organico dell'LVS rispetto a
quanto dichiarato nel Manuale di Qualità: immissione di nuovo personale,
variazione di compiti e responsabilità anche di personale già in forze all'LVS
stesso, ecc.
•
A livello complessivo, utilizzando i propri valutatori gli LVS devono essere in
grado di effettuare valutazioni e prove che riguardano (almeno) le
realizzazioni dei seguenti servizi di sicurezza:
Riservatezza
Integrità
Disponibilità
Autenticazione
Non ripudio
Sicurezza nei malfunzionamenti
Aggiramento delle funzionalità di sicurezza
Separazione logica dei dati
Controllo d’accesso
Accountability
93
Tolleranza ai malfunzionamenti
Robustezza
Selftest
Protezione fisica (prevenzione e rilevamento del tampering)
Protezione ambientale
Accesso al servizio
Archiviazione di informazioni critiche per la sicurezza
Interfacce
Allarmistica
Audit di sicurezza
Test a risposta nota
Tracciamento dei requisiti di sicurezza
Analisi e revisione formale
Prove funzionali
Test di intrusione
Analisi di vulnerabilità
Revisione del codice sorgente
Prove sul codice eseguibile
Revisione della documentazione
94
6.4. Il rapporto con la sovrastruttura aziendale
Come già detto in questo capitolo, il Laboratorio richiedente l’accreditamento può
essere un organismo pubblico o una impresa regolarmente registrata secondo le
norme vigenti. In generale, un laboratorio può essere parte di una preesistente
struttura aziendale, e costituisce una entità a sé stante con determinate mansioni
(quelle legate all'attività del laboratorio stesso), attività e, soprattutto, una propria
indipendenza economica per garantire i requisiti di indipendenza richiesti. Spesso,
poi, i laboratori fanno parte di aziende operanti nel settore dell'integrazione ICT o
della consulenza ICT e che (come è auspicabile) abbiano già ottenuto certificazioni
di conformità ad altri standard, come l’ISO27001.
In questi casi, allora, è molto importante capire quale siano i rapporti che
intercorrono tra il laboratorio e il resto dell'azienda, non solo dal punto di vista
organizzativo ma anche da quello operativo ed economico. Questa analisi, tuttavia.
può essere condotta solo avendo ben chiaro quale sia il particolare contesto
aziendale, e non può essere completamente generalizzata proprio per via di queste
molteplici possibili condizioni al contorno.
In linea del tutto generale, tuttavia, è possibile enunciare quelli che dovrebbero
essere i requisiti comuni ad ogni realtà di questo tipo (LVS) inserita in una
preesistente struttura aziendale:
•
L'LVS dovrebbe avere un propria ragione sociale ed un’Unità Organizzativa
ben definita e separata nei confronti dell’azienda e dell’esterno, in modo da
garantire il più possibile la caratteristica di indipendenza dalle altre unità di
business aziendali, in virtù delle specifiche attività di valutazione, assistenza,
consulenza e formazione erogate.
95
•
Devono essere previsti ed assegnati specifici ruoli interni di competenza e di
evidenza
formale
nei
confronti
degli
Organismi
di
Accreditamento,
Certificazione e dei Committenti, al fine di rendere il più possibile trasparente
il “modus operandi” proprio del laboratorio.
•
L’LVS, come sarà esposto nel seguito di questo documento, deve dotarsi di
un proprio Sistema Qualità e pertanto i relativi processi di qualità devono
essere distinti (specie in alcune parti ove il trattamento delle informazioni è più
evidente) rispetto alla Organizzazione Aziendale, pur mantenendo la coerenza
con il Sistema di Qualità esistente (nel caso ce ne fosse uno).
•
Tutti gli interventi necessari per l’attivazione del laboratorio, sia di carattere
fisico che logico, devono essere apportati in modo coerente rispetto alle
preesistenti certificazioni aziendali, ma al tempo stesso devono garantire
indipendenza all’LVS, al fine di rispettare le norme contenute negli Schemi
Istituzionali sopraccitati.
96
7. Progettazione di un Laboratorio di Valutazione
Nell'ottica di progettare un Laboratorio di Valutazione secondo lo Schema Nazionale,
che cioè risponda ai requisiti imposti dalla normativa e possa essere accreditato,
bisogna fare alcune considerazioni iniziali riguardanti la natura stessa del
Laboratorio.
In primo luogo il Laboratorio è di per sé una struttura indipendente dalla
sovrastruttura aziendale, ove questa fosse presente, e comunque un organismo con
requisiti e regole specifiche dettati da una serie di normative che vanno anche oltre
quelle imposte dallo Schema.
In secondo luogo il Laboratorio deve poter assicurare in ogni momento e per ogni
attività il rispetto dei requisiti di imparzialità, indipendenza, riservatezza ed obiettività.
Questo comporta non solo una particolare attenzione in fase di progetto a tutti gli
aspetti di carattere pratico non specificati nella normativa, ma anche un costante
controllo dei processi e delle strutture che possa, nel tempo, mantenere e migliorare
la funzionalità e la qualità del Laboratorio stesso.
Occorre inoltre notare che la progettazione di un Laboratorio, per quanto la si voglia
astrarre, rimane una attività il cui risultato deve poter essere applicabile nello
specifico contesto. Questo comporta la necessità di considerare una serie di aspetti
specifici che non possono ritenersi universalmente validi (ad es. diverse topologie di
rete, o la possibilità di disporre di spazi morfologicamente differenti).
Per tutti questi motivi nel seguito di questo paragrafo si cercherà di dare maggiore
oggettività e generalità all'analisi, descrivendo un possibile schema architetturale,
fisico ed organizzativo, ma con l'implicita intesa che questo valga solo come esempio
97
di carattere generale; in un contesto reale, infatti, un LVS potrebbe disporre di
strutture e spazi molto più semplici di quelli che saranno descritti, come anche molto
più estesi e complessi.
Le considerazioni che verranno espresse, inoltre, saranno di carattere sia generale
(essenzialmente legate alla normativa imposta), sia pratico. Le seconde in
particolare sono derivanti dall’esperienza accumulata attraverso la progettazione, la
realizzazione, la gestione e l’utilizzo di alcune di queste realtà in ambito nazionale;
per questo motivo alcuni degli aspetti che nel seguito saranno mostrati sono
considerabili come soluzioni puntuali a problematiche non direttamente contenute
nello Schema e, quindi, legate a contesti specifici; in altre parole, potrebbero essere
adottate allo stesso scopo soluzioni differenti ma altrettanto valide.
7.1. Il contesto normativo
Come enunciato nel paragrafo 5.2 del presente documento, le Linee Guida
descrivono quali siano i prerequisiti che un Laboratorio di Valutazione deve avere al
momento del suo accreditamento e che devono essere rispettate nel suo intero ciclo
di vita. Uno di questi, in particolare, esprime la necessità del Laboratorio di essere
conforme ai requisiti specificati nelle norme UNI CEI EN ISO/IEC 17025 e UNI CEI
EN 45011, per quanto applicabili. L'analisi di queste, tuttavia, non rientra nello scopo
di questo documento, motivo per il quale ne sarà data, nel seguito di questo
paragrafo, una sommaria descrizione, includendo i principali aspetti che coinvolgono
direttamente il contesto specifico dell’LVS.
La UNI CEI EN ISO/IEC 17025 contiene i requisiti che devono essere soddisfatti dai
laboratori di prova e di taratura che intendono dimostrare di attuare un sistema
98
qualità, di essere tecnicamente competenti e di poter produrre risultati validi
tecnicamente; la UNI CEI EN 45011 contiene, invece, i requisiti generali relativi agli
organismi che gestiscono sistemi di certificazione di prodotti.
L’insieme delle due norme racchiude, in linea generale, tutti i requisiti in merito a:
•
gestione di un laboratorio;
•
regole per assicurare la competenza tecnica necessaria ad eseguire le prove;
•
gestione della qualità nel laboratorio.
Aspetto molto importante da notare è che, citando il testo della UNI CEI EN ISO/IEC
17025:
“I laboratori di prova e taratura che operano in conformità a tale norma
internazionale operano anche in conformità con la ISO 9001 o ISO 9002”
Questo legame con le norme della serie ISO 9000 è visibile soprattutto
dall’approccio
comune,
specificato
all’interno
di
queste,
del
concetto
di
miglioramento continuo basato sul paradigma PDCA, ovvero:
•
Plan: stabilire gli obiettivi e i processi necessari per fornire i risultati in accordo
con i requisiti del cliente e con le politiche dell’organizzazione;
•
Do: dare attuazione ai processi;
•
Check: monitorare e misurare i processi e i prodotti a fronte delle politiche,
degli obiettivi e dei requisiti relativi ai prodotti e riportarne i risultati;
99
•
Act: adottare azioni per migliorare in modo continuo le prestazioni dei
processi.
Ponendoci nell’ottica di sintetizzarne il contenuto, è possibile affermare che
soddisfare i requisiti dettati da queste norme vuol dire applicare (e dimostrare di
averlo fatto) una serie di requisiti organizzativi e tecnici, alcuni dei quali (i principali)
saranno espressi di seguito.
Requisiti organizzativi
•
Organizzazione, intesa come definizione dei ruoli e delle responsabilità di
ogni
funzione
del
laboratorio,
ma
anche
quale
struttura
ha
la
rappresentanza legale del laboratorio stesso.
•
Sistema di gestione della qualità: adottare e descrivere una politica per la
qualità, specificando quali siano gli strumenti messi in atto a questo scopo.
•
Regole di gestione documentale: adottare e descrivere la politica di
creazione, gestione, versioning, archiviazione di documenti operativi (ad
es. la politica di assegnazione del nome del file in relazione alla versione
rilasciata) sia in formato cartaceo che elettronico.
•
Regole per il riesame delle richieste, delle offerte e dei contratti.
•
Servizi al cliente e reclami: definire quali siano le procedure per la gestione
delle relazioni con i Clienti.
•
Miglioramento: definire la strategia di riesame, di attuazione delle azioni
correttive e preventive, messe in atto per migliorare il proprio sistema di
gestione (ad es. attività di audit programmate)
100
Requisiti tecnici
•
Competenza del personale
•
Formazione e addestramento del personale
•
Idoneità del luogo di lavoro
•
Definizione dei metodi di prova e taratura
•
Identificazione dei sistemi e degli apparati a supporto
•
Riferibilità delle misure e campionamento
•
Metodi di manipolazione degli oggetti da provare e tarare
•
Presentazione dei risultati ottenuti e assicurazione della qualità di questi
Tutte queste informazioni e le motivazioni di correttezza delle strategie adottate per
rispondere a tali requisiti devono essere contenute nella documentazione del
Sistema Qualità, ed in modo specifico nel Manuale della Qualità che verrà descritto
nel paragrafo successivo.
7.2. Impianto documentale e gestione della documentazione
Come anticipato nei paragrafi precedenti, il Laboratorio deve essere conforme ad
alcune normative ed in modo particolare alla UNI CEI EN ISO/IEC 17025. Questo
comporta la necessità di adottare un proprio, indipendente, Sistema di Gestione
della Qualità.
101
E’ necessario perciò provvedere alla strutturazione ed alla creazione di un impianto
documentale conforme alla norma e che, almeno in linea generale, dovrebbe
contenere la seguente documentazione fondamentale:
Manuale della Qualità
Documento fondamentale, descrive il Sistema di Gestione della Qualità del
Laboratorio. Esso contiene la dichiarazione del Responsabile del Laboratorio
relativa alla Politica per la Qualità, richiama la descrizione della struttura
organizzativa e delle responsabilità, i processi e le procedure operative
adottate per ottemperare ai requisiti delle Norme di riferimento. Ove la
sovrastruttura aziendale avesse un preesistente sistema qualità, quello del
laboratorio può essere reso più snello integrando in modo opportuno dei
riferimenti a questo.
Modelli e Templates
Documentazione
relativa
ai
modelli
economico-finanziari
adottati
dal
Laboratorio e templates standard adottati per omogeneizzare la produzione
documentale e renderla conforme al Sistema di Gestione della Qualità
adottato.
Procedure
L'insieme delle procedure operative messe in atto dal Laboratorio per
ottemperare ai requisiti delle Norme di riferimento; alcuni esempi potrebbero
102
essere le procedure relative alla gestione documentale, quelle relative alla
valutazione o all'assistenza, etc...
Norme vigenti
Copie delle normative vigenti (come LGP, NIS, etc...) e copie della
documentazione di riferimento normalmente utilizzata (come CC[1,2,3], CEM,
etc...) in modo da facilitarne la consultazione da parte dei valutatori.
Istruzioni Operative
L'insieme delle regole di redazione e codifica della documentazione del
Sistema di Gestione della Qualità.
Documentazione di registrazione
Documenti atti a dimostrare l'efficace funzionamento del Sistema di Gestione
della Qualità nonché la conformità ai requisiti ed il conseguimento dei livelli
qualitativi attesi. Prodotte e registrate al momento dell'esecuzione di una
attività e strettamente collegati ad essa, includono l’identità del personale
responsabile per l’esecuzione di ogni prova e per la verifica dei risultati.
Particolarmente importante è anche la definizione delle regole di gestione
documentale del laboratorio; mantenendo la linea descrittiva, potremmo dire che
queste regole devono contenere almeno:
103
•
le direttive sulla codifica documentale adottata, come la struttura essenziale
dei documenti prodotti o le regole di scrittura degli stessi;
•
le direttive sull'accesso alla documentazione;
•
le direttive sul sistema di nomenclatura o classificazione adottato per
l'identificazione univoca dei documenti.
Una volta adottato un sistema di gestione documentale è importante, se si vuole
integrare nel Laboratorio uno o più repository elettronici, accertarsi se questi
rispondano pienamente alle specifiche imposte, soprattutto sotto il profilo della
coerenza della gestione delle utenze (limitando, ad esempio, alcune soggetti
all'accesso a documentazione riservata) e quello degli identificatori stabiliti per
l'archiviazione.
7.3. La struttura fisica
La definizione della struttura fisica di un Laboratorio di Valutazione, intesa come la
progettazione dell'ambiente di lavoro nel suo complesso, è prerogativa essenziale
per l'attività del Laboratorio stesso, nonché requisito per le procedure di
accreditamento.
Un LVS che voglia essere accreditato deve definire le strutture entro le quali i suoi
componenti (i valutatori) svolgeranno l'attività di valutazione, e prevedere come
queste strutture dovranno essere utilizzate e gestite.
Nel presente paragrafo verrà descritto un esempio di come possa essere realizzata
la struttura fisica per un ipotetico Laboratorio di Valutazione; bisogna considerare
104
però che quanto espresso nel seguito deve obbligatoriamente essere calato sulla
particolare morfologia, disponibilità di spazi e obiettivi che il laboratorio si propone di
avere.
Considerando allora sia gli aspetti di carattere normativo, sia quelli di carattere
principalmente pratico ed implementativo, di seguito saranno espresse le
considerazioni alla base della struttura proposta.
• L'ambiente fisico nel quale si sviluppa il laboratorio deve essere conforme a
quanto stabilito dalla UNI CEI EN ISO/IEC 17025, ma anche a quella che è la
vigente normativa in materia di sicurezza sul lavoro. A titolo di esempio,
devono essere previste misure anti incendio nelle aree di lavoro, indicazioni
sulla presenza di personale all'interno di aree ad accesso limitato, misure
preventive del rischio elettrico, indicazioni di primo soccorso, ...
• L'ambiente deve prevedere aree di lavoro separate fisicamente (e
logicamente) che permettano di svolgere attività parallele di valutazione.
Come da normativa, infatti, lo stesso valutatore non può mai partecipare
contemporaneamente allo sviluppo ed alla valutazione di un ODV o di un PP
o fornire al Committente di una valutazione o al Fornitore di un ODV o PP
servizi di assistenza che potrebbero compromettere l’indipendenza della
valutazione. Ciò si riflette nella progettazione del laboratorio in quanto
potrebbe essere utile suddividere le aree di lavoro in modo da permettere a
più valutatori di svolgere attività parallele, per esempio di valutazione e
assistenza.
• Il laboratorio è spesso coinvolto in attività di valutazione per le quali possa
essere espressamente richiesto da parte del committente un accordo di
105
riservatezza esplicito; il Committente, per esempio, potrebbe pretendere che
le informazioni riservate relative al proprio prodotto o sistema debbano essere
maneggiate ed analizzate solo dai valutatori coinvolti, dei quali per altro deve
essere fornito un curriculum vitae ufficiale. Nella progettazione di un ambiente
di valutazione, quindi, potrebbe essere necessario prevedere anche questa
eventualità, destinando spazi diversi ad essere utilizzati in modo esclusivo per
una attività specifica, o decidere particolari procedure che regolamentano la
disponibilità dei suddetti spazi per attività di valutazione contemporanee.
• Per lo stesso motivo del punto precedente deve essere previsto un sistema di
controllo e tracciamento degli accessi nelle aree destinate alla valutazione,
tramite sistemi di identificazione univoca delle persone che di volta in volta
accedono alle strutture riservate, come ad esempio lettori di badge, rilevatori
di impronta biometrica o semplici codici di accesso personali.
• La riservatezza delle informazioni, inoltre, impone che negli spazi temporali
non lavorativi tutta la documentazione riservata possa essere conservata in
modo da evitarne l'accesso a personale non autorizzato. La disponibilità nelle
aree di lavoro di armadi opportunamente protetti potrebbe essere una
soluzione al problema, riservandone l'accesso al personale autorizzato solo
nelle fasi di conduzione dell'attività stessa. E' necessario prevedere
l'eventualità, inoltre, di doversi disfare di documentazione cartacea riservata,
per esplicita richiesta del cliente o dipendentemente dalle politiche del
Laboratorio stesso in materia. Potrebbe essere necessario, quindi, individuare
all'interno delle aree di lavoro una o più postazioni per lo smaltimento della
106
documentazione, eventualmente dotate di appositi apparati per la distruzione
di questa (i così detti “paper shredder”).
• Tra le attività che un Laboratorio può trovarsi a svolgere ci sono anche quelle
relative a test si sicurezza su apparati o sistemi forniti dal Committente. E'
importante, allora, prevedere all'interno delle strutture preposte degli spazi
appositi che consentano l'installazione e la messa in esercizio di ODV sui
quali condurre attività di test.
Seguendo le considerazioni espresse nei punti precedenti, un Laboratorio dovrebbe
in sintesi prevedere un numero di aree appropriate e distinte fisicamente (e
logicamente) ognuna dotata di un sistema di controllo e tracciamento degli accessi e
di spazi riservati nei quali gestire la documentazione delle singole attività.
Un esempio potrebbe essere quello di destinare allo scopo quattro aree distinte, due
delle quali dotate di opportune Postazioni di Lavoro e/o strumenti adeguati a
supporto delle attività operative, dove condurre attività di assistenza e valutazione,
di valutazioni concorrenti e di test; le restanti, invece, potrebbero essere impiegate
l’una per le fornire servizi di carattere generale, dotata ad esempio di telefoni, fax o
stampanti di rete, l’altra come Centro di Elaborazione Dati, Gestione e Controllo,
dove inserire tutti i sistemi di supporto, monitoraggio e gestione del Laboratorio.
107
Area Documentale
Area di Test
Area Utilities
Area di Elaborazione Dati, Gestione e Controllo
Figura 14: Strutturazione per aree di un Laboratorio di Valutazione
Il controllo degli accessi effettuato tramite dispositivi biometrici (come la lettura
dell'impronta digitale) o tramite duplice autenticazione con badge e codice di
sicurezza (PIN) personale potrebbe essere una soluzione per limitare e tracciare gli
accessi e i periodi di permanenza delle singole persone che utilizzano gli spazi. E’
molto importante però utilizzare dispositivi che permettano la centralizzazione delle
utenze, utilizzando, ad esempio, un unico sistema di autenticazione ed archiviazione
dei dati degli accessi; in questo modo si faciliterebbe anche la gestione di questi
apparati e la generazione di report degli accessi, ove ce ne fosse bisogno.
L'ulteriore disponibilità per ogni area di strutture di archiviazione (armadi protetti o
cassette di sicurezza) per il materiale utilizzato nel corso delle attività e specifiche
procedure di utilizzo degli ambienti (che prevedano casi di attività concorrenti)
108
potrebbero consentire al Laboratorio di gestire un volume di lavoro adeguato agli
obiettivi preposti rispettando i vincoli di riservatezza richiesti.
Un Laboratorio, naturalmente, potrebbe prevedere molte più aree di quelle descritte
o anche utilizzarne una sola, divisa temporalmente in attività concorrenti; una
corretta razionalizzazione del problema dovrebbe quindi tenere conto non solo del
numero di valutatori presenti, ma anche dal volume di attività che il Laboratorio
desidera raggiungere e (soprattutto) dalla disponibilità e dall’adeguatezza delle
strutture presenti.
7.4. La struttura IT
Con l'acronimo IT (Information Technology) generalmente si intende la convergenza
di informatica e telematica al fine di creare metodi innovativi per il trattamento, il
trasferimento e l'accesso all'informazione. Riferendoci a questa definizione e con
l'obiettivo di descrivere una ipotetica infrastruttura hardware, software e di
connettività a supporto delle attività di un laboratorio di valutazione, in questo
capitolo saranno analizzate le problematiche relative all'implementazione di questa
struttura tecnologica e ne verrà proposto un esempio pratico. Il livello di dettaglio che
si cercherà di dare sarà maggiore sui servizi piuttosto che sui sistemi; in altre parole
l’attenzione sarà focalizzata nella descrizione di “cosa” un sistema offra e non sulle
sue caratteristiche tecniche.
Per organizzare questo processo in modo ordinato e rispettando la suddivisione
individuata nel paragrafo precedente, dopo aver analizzato gli aspetti comuni
verranno prese in considerazione le singole aree documentali, di test, di
elaborazione, gestione e controllo e di utilities.
109
Struttura generale
La struttura generale del Laboratorio, tenuto conto di quanto detto nei paragrafi
precedenti, deve garantire la connettività tra le strutture presenti, mantenendo una
suddivisione logica delle aree che possa facilitare il processo di definizione di
politiche di sicurezza interne.
110
Figura 15: Struttura di un LVS - definizione delle aree funzionali
111
Potrebbe essere conveniente predisporre gli apparati, i sistemi e la rete stessa per
garantire il funzionamento del Laboratorio anche in presenza di guasti o
malfunzionamenti, ad esempio ridondando gli apparati di connettività, dotando i
sistemi di interfacce secondarie e definendo opportune politiche di gestione che
consentano di conservare l'operatività del Laboratorio in questi casi. Per esigenza di
semplicità, tuttavia, la struttura presentata in questo documento non terrà conto di
queste considerazioni, anche se, in una possibile configurazione operativa, sarebbe
necessario solo un suo semplice adeguamento.
Infrastruttura di connettività e di sicurezza perimetrale
Scopo principale dell’infrastruttura di connettività è quello di garantire che i sistemi
componenti possano, a seconda delle politiche di accesso definite per l’area a cui
appartengono e/o per l’utenza connessa, utilizzare i servizi messi a disposizione dal
Laboratorio, come collegamento internet, applicativi di archiviazione documentale,
etc....
Questo vuol dire che oltre a definire un piano di indirizzamento, magari assegnando
sottoreti private differenti a ciascuna area e facendo svolgere dal Firewall stesso
funzionalità di NAT/SNAT, è necessario implementare politiche di filtraggio del
traffico interno ed esterno al laboratorio, in modo da garantire un elevato livello di
sicurezza e limitare l'accesso a dati riservati ai soli soggetti che posseggono
adeguate autorizzazioni.
Essendo, comunque, il Laboratorio una struttura relativamente piccola, l'inserimento
di apparati dedicati esplicitamente alle funzioni di routing e instradamento del traffico
potrebbe essere non necessario, potendo invece impiegare a questo scopo apparati
112
di tipo firewall che integrino a queste opportune politiche di filtro. Operativamente
questo vuol dire agire al livello 2 e 3 della pila ISO/OSI, ma è anche possibile
arrivare fino al livello applicativo utilizzando sistemi in grado di supportare
funzionalità filtraggio a livello applicativo (ad es. sistemi Stateful Packet Inspection),
inglobando negli stessi moduli funzioni di sicurezza e di connettività.
Questo consente, avendo (al limite) a disposizione tante porte quante sono le aree
da gestire, di creare regole di filtro specifiche non solo dal Laboratorio verso l'esterno
e viceversa, ma anche da area ad area, limitando, ad esempio, la possibilità di
connessione ad un determinato servizio, non solo ad utenti specifici ma anche a
sistemi specifici.
Ognuna delle aree da servire, poi, deve disporre di un numero sufficiente di
interfacce per l'accesso alla rete; questo vuol dire semplicemente avere a
disposizione un singolo switch per area, con un numero di porte adeguato ai sistemi
presenti (in genere non meno di 24). In alternativa è possibile utilizzare switch
compatibili con lo standard IEEE 802.1q, cioè che consentano la definizione di lan
virtuali; questo permette non solo di ridurre il numero di infrastrutture presenti e,
conseguentemente, i costi di acquisizione e manutenzione, ma anche di poter
riassegnare le porte in modo dinamico tra le VLAN a seconda di come la struttura del
laboratorio evolva, soprattutto nei casi in cui il numero di sistemi non sia
eccessivamente elevato.
Una ulteriore considerazione da fare è ancora sulla sicurezza perimetrale: l'adozione
di un firewall, anche supportando protocolli filtraggio fino al livello applicativo,
potrebbe non essere sufficiente a limitare l’esposizione al rischio di attacchi o di
diffusione di virus/worm dall’interno della struttura e viceversa; questo avviene sia
113
che il sistema sia direttamente connesso con la rete pubblica, sia che esista un
ulteriore livello di firewall appartenente, ad esempio, alla struttura aziendale di
appartenenza. Potrebbe essere quindi conveniente installare un ulteriore strato di
filtro che sia in grado di offrire sicurezze maggiori in materia di prevenzione e
controllo delle intrusioni, ovvero un IDS (Intrusion Detection System) o meglio un IPS
(Intrusion Protection System); il supporto di molti di questi prodotti per la modalità
inline (l’apparato in realtà non ha indirizzo IP ed appare come un semplice bridge di
rete) è molto utile sia per semplificare la progettazione globale degli spazi di
indirizzamento (il firewall sarebbe, in questo caso, direttamente connesso alla rete
pubblica), sia per “nascondere” ad un ipotetico attaccante esterno la presenza di
sistemi avanzati di protezione. Tenendo conto che, come detto, un Laboratorio
raramente è una struttura estesa geograficamente, potrebbe essere conveniente
utilizzare un singolo sistema che integri al suo interno anche questo tipo di funzioni,
eventualmente sovradimensionato, allo scopo di ridurre i costi e mantenere
comunque un livello di sicurezza adeguato. Bisogna però tener presente che, anche
se a livello economico questi apparati possono convenire, le prestazioni e le
garanzie offerte da apparati studiati e dedicati a svolgere un singolo servizio di
sicurezza ed integrati opportunamente sono spesso migliori.
Un’ultima nota deve essere fatta relativamente all’ambiente di test: potrebbe
accadere che il Laboratorio sia impegnato in attività di analisi remota dei sistemi (ad
esempio sessioni di Vulnerability Assessment su server remoti). La presenza di
apparati di sicurezza dove dover obbligatoriamente transitare durante questi test
potrebbe inficiarne il risultato, oltre che richiedere opportune configurazioni da
implementare di volta in volta su di questi. Potrebbe essere utile, perciò, predisporre
114
una connessione diretta alla rete pubblica da utilizzare in questi casi e limitarne
l’operatività quando non necessaria.
115
Figura 16: Struttura di un LVS - infrastruttura di connettività e sicurezza perimetrale
116
Area di Elaborazione Dati, Gestione e Controllo
Questa tipologia di area, come descritto precedentemente, nasce con lo scopo di
raggruppare funzioni dedicate all'operatore del Laboratorio (in genere al valutatore)
ma anche di poter fornire un centro di gestione unificata di tutti gli apparati e i sistemi
presenti all'interno della struttura.
Partendo dal primo concetto, alcuni servizi che potrebbero essere presenti nel
laboratorio sono:
•
Repository Documentale: applicativo accessibile dagli operatori, per esempio
tramite protocollo http/https, che consenta di gestire la documentazione
digitale nell'intero suo ciclo di vita interno al Laboratorio. A questo scopo deve
garantire delle politiche di accesso ai dati su base utente, che consentano di
consultare, modificare o rimuovere documenti specifici sulla base dei privilegi
specifici (ad esempio, un valutatore deve poter accedere alla documentazione
relativa alla sua attività in corso, ma non a quella di un altro valutatore!),
magari permettendo la creazione di spazi ad accesso limitato dedicati alle
singole attività. Naturalmente le politiche di gestione documentali devono
essere pienamente conformi a quelle definite nel Sistema di Gestione della
qualità. Potrebbe essere opportuno, inoltre, mettere a disposizione un singolo
repository per area, in modo da memorizzare su supporti separati i dati relativi
a diverse tipologie di attività (ad esempio, uno per la documentazione di
valutazione ed uno per quella di test). Ulteriore funzione che potrebbe essere
utile in un applicativo di questo tipo è il controllo di versione, ovvero consentire
il tracciamento delle operazioni effettuate sui documenti (revisioni) da parte
del singolo utente, mantenendo copie storiche differenti per ciascun dato.
117
Esistono allo scopo applicativi open source estremamente flessibili,
configurabili e che richiedono, tra l’altro, l’impiego di sistemi hardware non
proprietari e senza particolari profili di prestazioni (dei semplici sistemi server
a basso costo potrebbero svolgere egregiamente questo compito).
•
Servizi di Backup centralizzato: sistemi con notevole spazio di archiviazione
che permettano agli operatori di effettuare copie di sicurezza dei loro dati, con
cadenza periodica e/o attivazione manuale, e che consentano la definizione di
politiche di salvataggio differenziale dei dati presenti sui sistemi server. E'
però molto importante che gli archivi presenti su di essi siano opportunamente
protetti ed accessibili solo dalle utenze abilitate (utilizzando ad esempio
sistemi di codifica basati su algoritmi di crittografia forti, come AES-256 per
l’alternativa simmetrica e protocolli di comunicazione come sftp). Dal punto di
vista dell’hardware, sarebbe opportuno prevedere sistemi server dedicati, con
notevole spazio disco, meccanismi di ridondanza dei dati (RAID), interfacce di
comunicazione multiple ed adeguate politiche di sicurezza; in alternativa
esistono sul mercato specifici sistemi di tipo NAS che supportano queste
caratteristiche ed implementano interfacce di gestione semplificate.
•
Servizi di accesso a dati comuni: anche se fisicamente questa funzione
potrebbe risiedere sugli stessi repository documentali, a livello logico è
senz'altro necessario mettere a disposizione dei valutatori spazi ad accesso
globale (magari limitato alla sola lettura) dai quali poter prelevare la
documentazione necessaria alle valutazioni, consultare il manuale della
qualità o scaricare i modelli di documento ufficiali del Laboratorio.
118
Riguardo l’altro aspetto identificato, ovvero le funzioni di gestione e controllo, alcuni
servizi che potrebbero essere presenti nel Laboratorio sono:
•
Monitoraggio, gestione e controllo degli apparati e dei servizi: sistemi
consentano di monitorare e gestire gli apparati e i servizi presenti nel
Laboratorio, fornendo accesso diretto ai parametri di configurazione degli
stessi. Gli stessi sistemi contengono indicatori sul funzionamento globale e
sulle performance della struttura IT. Anche se può sembrare complesso, un
sistema di questo tipo potrebbe facilitare di molto la gestione del Laboratorio,
consentendo, ad esempio, di controllare da remoto gli apparati di limitazione
dell'accesso fisico ai locali o di revisionare i set di regole dei sistemi di
protezione perimetrale senza dover agire su ogni singola console. Inoltre,
grazie al monitoraggio, è possibile definire regole secondo le quali un
eventuale malfunzionamento potrebbe generare un allarme ed essere
opportunamente segnalato, consentendo così di isolare e risolvere in tempi
brevi la problematica.
•
Struttura di directory: l'accesso ai sistemi presenti nel Laboratorio deve
avvenire
secondo
credenziali specifiche
e
politiche prestabilite, che
impediscano, ad esempio, l'accesso a sistemi di controllo ad utenze non
abilitate. L’integrazione di un sistema di alberatura di directory potrebbe
essere utile per centralizzare questi meccanismi di gestione delle utenze e
mantenere un sistema di tracciamento degli accessi ai sistemi. Il protocollo
ldap è senz’altro il principale riferimento per questo tipo di applicazioni;
l’utilizzo di un sistema dedicato compatibile con questo standard (anche open
source) potrebbe, quindi, essere una scelta adeguata.
119
Figura 17: Schema di un LVS - Area di Elaborazione Dati, Gestione e Controllo
120
Aree Documentali
Le aree documentali sono studiate per fornire ai valutatori gli strumenti necessari a
svolgere le attività operative del Laboratorio. A questo scopo devono contenere delle
Postazioni di Lavoro (o PdL), workstation dotate di connettività alla rete del
Laboratorio ed alla rete pubblica (internet) ed alcuni applicativi essenziali, come suite
di Office Automation, browser internet, strumenti per la cifratura e la decifratura dei
dati, strumenti per la gestione delle chiavi crittografiche e dei certificati digitali utente
ed anche strumenti ad-hoc, ove necessari, che consentano l'accesso alle risorse
localizzate nell'area di Elaborazione. Dal punto di vista della sicurezza, i sistemi
devono essere dotati di personal firewall e antivirus locale, e consentire
l’autenticazione degli utenti secondo le politiche definite nel Sistema di Gestione
della Qualità.
121
Figura 18: Schema di un LVS - area Documentale
122
Aree di Test
Le aree di test devono consentire ai valutatori, specialmente a quelli di profilo
operativo, di svolgere qualsiasi attività di prova e misura legate alla valutazione di
prodotti e sistemi. Devono perciò contenere alcune Postazioni di Lavoro con le
stesse funzionalità di quelle descritte per l'area documentale, con l’aggiunta di
mettere a disposizione dei valutatori opportuni applicativi di test ed analisi. Potrebbe
essere opportuno, considerando che molti di questi applicativi sono costruiti sul
paradigma Client-Server, disporre all’interno di queste aree alcuni sistemi Server a
disposizione dei Valutatori. Tra i possibili software che possono essere presi in
considerazione vanno citati quelli dedicati all'analisi delle vulnerabilità, alla
mappatura
di rete e fingerprinting, alla scansione di sistemi interconnessi, alla
conduzione di test di penetrazione dei sistemi, etc.... A livello generale, questi
sistemi devono essere analoghi a quelli utilizzati per attività di ethical hacking,
penetration testing e vulnerability assessment.
Oltre a questo, l'area di test deve consentire l'installazione e la messa in opera di
sistemi o di prodotti in fase di valutazione; a questo scopo potrebbe essere utile
prevedere un numero elevato di porte di comunicazione disponibili (a livello degli
switch interni) ed anche utilizzare sistemi di virtualizzazione software con i quali
predisporre opportune macchine virtuali operanti nel rispetto dei requisiti di sicurezza
dell’ambiente previsto per i test stessi.
123
Figura 19: Schema di un LVS - Area di Test
124
Area Utilities
L'area utilities ha lo scopo di offrire servizi di carattere generale a tutti gli operatori
del Laboratorio di valutazione. A questo scopo potrebbero essere presenti in essa
apparati telefonici o fax, ma anche stampanti di rete accessibili dalle postazioni di
lavoro degli operatori.
125
Figura 20: Schema di un LVS - Area Utilities
126
Nelle figure 15, 16, 17, 18, 19 e 20 sono stati rappresentati graficamente in modo
semplificato i passi individuati nel corso dell’analisi condotta sulla progettazione IT
del Laboratorio.
La figura 21, invece, è stata prodotta aumentando il livello di dettaglio e
considerando, nei limiti di questa analisi, una soluzione più aderente ad una realtà
LVS.
127
Figura 21: Schema di un LVS - risultato finale
128
7.5. Gli aspetti di sicurezza
La
struttura
descritta
nei
paragrafi
precedenti
rappresenta
una
possibile
implementazione delle soluzioni di carattere organizzativo e tecnico individuate lungo
il percorso di analisi e progettazione di un ipotetico Laboratorio di Valutazione della
Sicurezza.
E’ stata enunciata anche l’importanza della presenza nel Laboratorio di un Sistema
di Gestione della Qualità, non solo dal punto di vista di un ipotetico accreditamento,
ma soprattutto per la regolamentazione di tutte le attività operative svolte dal
Laboratorio stesso.
Esistono, tuttavia, alcuni aspetti legati alla sicurezza della Struttura IT ed alla sua
gestione che, seppur non sempre inseriti nel Sistema di Gestione di Qualità, devono
essere presi seriamente in considerazione e completano il quadro descrittivo che
tramite questo lavoro si vuole fornire.
Il primo di questi, e sicuramente anche quello più importante, consiste nella
definizione e nella adozione di specifiche politiche di sicurezza e di accesso. Questo
processo interessa in particolar modo i sistemi posti a difesa del perimetro del
Laboratorio; nello schema proposto sono stati inseriti due livelli distinti di protezione
perimetrale, uno di filtro (firewall) ed uno di analisi (Intrusion Detection/Prevenction).
Per entrambi queste politiche devono essere particolarmente restrittive, in modo da
assicurare un livello di sicurezza elevato e constante, soprattutto in virtù degli
obblighi di riservatezza a cui un Laboratorio è soggetto: l’eventuale presenza di una
esposizione o vulnerabilità sfruttabile consentirebbe l’accesso (nella migliore delle
129
ipotesi) a dati riservati o sensibili. Ove questo avvenisse le perdite non sarebbero
solo quelle causate dalla diffusione del dato stesso, ma soprattutto economiche e di
immagine, e potrebbero portare alla sospensione delle attività del Laboratorio
stesso, oltre che inficiarne la reputazione. Molto importante in questo senso è il
processo di traduzione delle politiche, una volta formalizzate, da teoriche a pratiche
(ad esempio dalla definizione delle limitazioni per ambiente alla scrittura delle regole
di filtraggio da installare sugli apparati), che deve essere condotto in maniera
scrupolosa e deve prevedere una fase di collaudo e verifica completa. Le stesse
considerazioni devono essere fatte, in maniera opportuna, per tutti i sistemi presenti
nel Laboratorio, sia quelli che offrono ai Valutatori un determinato servizio (ad
esempio server documentali), sia quelli attraverso i quali è possibile fruire del
servizio stesso (ad esempio le Postazioni di Lavoro). In altre parole, il processo di
definizione delle politiche di sicurezza IT deve essere ritenuto di importanza
fondamentale e come tale trattato, al fine di agire nel pieno rispetto dei requisiti
imposti e di dimostrare sia all’OC che ad un eventuale Committente l’impegno che si
è dedicato a questo scopo.
Una volta individuate ed attuate queste politiche per tutti i sistemi presenti nel
Laboratorio, la fase successiva, ed anche questa molto importante, è quello di
verifica: i sistemi (ed i servizi) stessi devono essere opportunamente analizzati al fine
di individuare e correggere eventuali vulnerabilità che esporrebbero la struttura ad
una minaccia di sicurezza. Quello che si può fare allora è predisporre delle sessioni
di vulnerability assessment periodiche (ad esempio ad intervalli di 3/6 mesi) sul
complesso delle strutture del Laboratorio, analizzare i risultati ottenuti e correggere le
problematiche individuate attraverso una successiva attività di hardening dei sistemi.
Ogni sessione di Vulnerability Assessment/Hardening deve essere completamente
130
documentata, in modo da poter tenere traccia di ciò che si è rilevato e di come si è
proceduto nel corregerlo.
Ultimo dei principali aspetti da considerare è la necessità di aggiornamento dei
sistemi: i produttori e i fornitori di hardware o software mettono a disposizione, in
genere, patch di sicurezza ogni volta che venga rilevata una vulnerabilità nei loro
prodotti/sistemi.
Bisogna
allora
pianificare,
magari attraverso un piano di
manutenzione inserito del Sistema di Gestione della Qualità, la verifica periodica di
aggiornamenti disponibili, individuando per ogni sistema (o gruppo di sistemi) le
opportune procedure a riguardo.
Nel complesso la congiunzione delle attività sopra descritte con quelle di audit
interno previste dal Sistema di Gestione della Qualità garantisce un livello di
sicurezza adeguato per un LVS, che possa essere mantenuto ed aumentato nel
tempo.
131
8. Il processo di accreditamento
Come anticipato nei paragrafi precedenti, lo Schema Nazionale prevede differenti livelli di
accreditamento dei Laboratori, in ragione dei quali questo è abilitato ad operare valutazioni
secondo i criteri europei ITSEC ed allo standard internazionale Common Criteria [CC1,2,3].
Le tipologie di accreditamento sono riassunte nelle tabelle seguenti:
Tabella 4: Livelli di Accreditamento secondo ITSEC
Tipologie
Portata dell’accreditamento
E1
Azioni del Valutatore previste nella parte “AssuranceEffectiveness” relativa al livello E1 dei criteri ITSEC
E1-E2
Azioni del Valutatore previste nella parte “AssuranceEffectiveness” fino al livello E2 dei criteri ITSEC
E1-E2-E3
E1-E2-E3-E4
E1-E2-E3-E4-E5
E1-E2-E3-E4-E5-E6
Tabella 5: Livelli di accreditamento secondo i Common Criteria
Tipologie
Portata dell’accreditamento
EAL1
Azioni associate alla valutazione delle
componenti di garanzia al livello EAL1 (*)
EAL1-EAL2
132
EAL1-EAL2-EAL3
EAL1-EAL2-EAL3-EAL4
EAL1-EAL2-EAL3-EAL4-EAL5
componenti di garanzia al livello EAL5
EAL1-EAL2-EAL3-EAL4-EAL5EAL6
EAL1-EAL2-EAL3-EAL4-EAL5EAL6-EAL7
Naturalmente al crescere dei livelli di abilitazione crescono le competenze tecniche
che i valutatori del Laboratorio devono possedere; la selezione del livello, quindi,
dipende fortemente dalla competenza dell'LVS e definisce l’insieme delle prove che
l’LVS è autorizzato a svolgere. In casi eccezionali l'OC può consentire
l'accreditamento di Laboratori sulla base di tipologie di accreditamento “ad-hoc”, in
modo da rendere il processo flessibile ed adattabile ad esigenze non ordinarie.
Definiti questi concetti generali, verrà nel seguito di questo paragrafo descritta la
procedura di accreditamento, a partire dalle strutture che essa coinvolge fino al
dettaglio delle fasi previste dall'iter.
8.1. Le strutture coinvolte
Lo Schema Nazionale, come indicato nella LGP2 e nella successiva NIS2, prevede
che nel processo di accreditamento siano coinvolte in modo congiunto l'OC (che
come già detto in Italia è anche Ente Accreditatore) e il Laboratorio richiedente
l'accreditamento. In particolare sono definite le seguenti entità:
133
•
il Laboratorio richiedente l’accreditamento, che deve essere un organismo
(pubblico o privato) regolarmente registrato secondo le norme nazionali. Al
suo interno deve essere definito un responsabile dei rapporti con la Sezione
Accreditamento dell'OC, unica figura autorizzata ad intrattenere rapporti
formali con quest'ultima.
•
la Sezione Accreditamento dei Laboratori dell’Organismo di Certificazione,
ovvero la struttura che gestisce e coordina la procedura di accreditamento
interna all'OC. Figura chiave di questa è il Responsabile della Sezione
Accreditamento, che ha il compito di coordinare tutte le fasi dell'iter, ad
esempio nominando gli ispettori autorizzati ad effettuare le verifiche,
supervisionando il loro operato, convocando la commissione TecnicoConsultiva, etc... A partire dalla documentazione fornita successivamente
alle
visite
ispettive,
Accreditamento,
questi
dovrà
successivamente
redigere
sottoposto
il
Rapporto
Finale
all'attenzione
di
della
Commissione Tecnico-Consultiva.
•
gli Ispettori, che rispondono direttamente al Responsabile della Sezione
Accreditamento e che hanno il compito di effettuare e documentare le
verifiche previste dallo Schema Nazionale. Essi devono, in particolare,
verificare la documentazione di qualità fornita dal Laboratorio, verificare la
competenza tecnica delle figure che questo identifica ed eseguire le visite
ispettive in loco. Il risultato delle loro attività è espresso nel Rapporto Finale
di Visita Ispettiva, che deve essere fornito direttamente al Responsabile della
Sezione Accreditamento.
134
•
la Commissione Tecnico-Consultiva, il cui ruolo è quello di garante del
corretto svolgimento della procedura di accreditamento, secondo quanto
previsto dalle procedure in materia. Nominata dal Ministero delle
Comunicazioni essa è formata da un rappresentante del Dipartimento per
l’Innovazione e le Tecnologie della Presidenza del Consiglio dei Ministri, che
ricopre il ruolo di Presidente della Commissione Tecnico-consultiva, dal
Responsabile della Sezione Accreditamento dell’OC e da un rappresentante
del Ministero dello Sviluppo Economico. Il suo compito è quello di analizzare
la documentazione relativa all'accreditamento del Laboratorio e formulare un
parere attraverso il Rapporto di Certificazione dell'Accreditamento.
•
l’Organismo di Certificazione, sulla base del Rapporto di Certificazione
dell'Accreditamento, emette in caso di successo della procedura il Certificato
di Accreditamento, che abiliterà formalmente il Laboratorio a svolgere le
attività di valutazione.
Il processo di accreditamento, come sarà meglio espresso nel seguito, prevede che
gli ispettori verifichino la competenza tecnica del Laboratorio, in special modo quella
dei valutatori. Lo Schema stabilisce il numero minimo di valutatori di cui un
Laboratorio deve disporre, ovvero uno per ogni profilo (documentale e operativo), ma
non stabilisce il numero massimo. E' importante sottolineare che anche se i profili
devono avere competenza specifica in base a questi profili, è necessario che tutto il
team conosca approfonditamente le problematiche di carattere generale legate ai
processi di valutazione ed ai criteri previsti dalla tipologia di accreditamento. In altre
parole, sia i valutatori tecnici che quelli documentali dovranno avere ben chiari gli
135
standard ITSEC e Common Criteria ed avere una buona conoscenza teorica sia
delle Linee Guida che dei processi che lo Schema prevede per le attività di
assistenza, valutazione e certificazione.
Dal punto di vista della tempistica, invece, lo Schema prevede che siano impiegati
circa 60 giorni lavorativi per l'intera fase di accreditamento, e cioè dal momento
dell'inizio delle attività fino all'emissione del Rapporto finale di Visita Ispettiva. Tale
stima, però, è ottimistica, nel senso che è fatta sotto l'ipotesi che sia la
documentazione fornita dal Laboratorio, sia il risultato delle verifiche di competenza
rispondano ai requisiti imposti dall'OC. Nel caso in cui queste ipotesi vengano a
mancare il processo può durare più del previsto, con la limitazione che superato il
limite dei 180 giorni lavorativi l'Ente si riserva di poter esprimere formalmente parere
negativo. E' importante sottolineare che da questa stima dei tempi viene escluso il
periodo di riesame della documentazione da parte della Commissione TecnicoConsultiva, senza il quale l'Ente Accreditatore non può emettere il certificato, e che
potrebbe anche portare ad una sensibile dilatazione dei tempi.
8.2. Fasi del processo
Il processo di accreditamento si svolge complessivamente in tre fasi, ovvero quella
della richiesta di accreditamento, di istruttoria della richiesta e di rilascio del
certificato di accreditamento. La figura x.xx raccoglie le principali attività legate a
ciascuna di queste fasi.
136
Richiesta di
Accreditamento
Il Laboratorio emette
formale richiesta di
voler intraprendere il
percorso di
accreditamento
L'OC esamina la
richiesta ed emette un
preventivo di spesa
Il Laboratorio
consegna la
documentazione
richiesta per avviare la
fase di verifica
Istruttoria della
richiesta
Vengono effettuate le
verifiche previste dallo
Schema, ovvero:
• verifica dei requisiti
imposti dalla norma
• verifica della
competenza tecnica
del Laboratorio e dei
suoi componenti
Rilascio del
certificato di
accreditamento
Il Responsabile della
Sezione Accreditamento
riceve il Rapporto Finale di
Visita Ispettiva ed emette il
Rapporto Finale di
Accreditamento
La Commissione TecnicoConsultiva esamina il
Rapporto finale di
Accreditamento,
predispone, ove lo ritenesse
opportuno, verifiche
aggiuntive ed emette il suo
parere formale attraverso il
Rapporto di Certificazione
dell'Accreditamento.
In caso di parere positivo
l'OC emette il Certificato di
Accreditamento.
Figura 22: Fasi del processo di Accreditamento secondo lo Schema
Tra tutti i passaggi previsti dallo Schema Nazionale per la procedura di
Accreditamento sono assai rilevanti per lo scopo di questo documento quelli relativi
alle verifiche ispettive, appartenenti alla fase di istruttoria della richiesta.
Durante la fase di richiesta, come espresso dallo schema, il Laboratorio deve
consegnare all'OC una corposa documentazione. Questa deve comprendere, tra
l'altro, il Manuale della qualità del laboratorio redatto secondo le norme [UNI1] e
tenendo in conto le competenze tecniche richieste, corredato dai Curriculum Vitae
dei valutatori che si desidera accreditare.
137
Figura 23: Dettaglio del processo di Accreditamento secondo lo Schema
Il Manuale è di estrema importanza nella fase di verifica dei requisiti: ove questo
fosse non conforme alle specifiche imposte, il Responsabile della Sezione di
Accreditamento potrebbe sospendere la procedura, fissando al limite le modalità e i
tempi per l'adeguamento e/o l'integrazione di questo, o addirittura annullare l'intero
138
processo. E' quindi fondamentale redigere correttamente tale documentazione ed
avere cura di controllare scrupolosamente la sua conformità alle normative vigenti.
Dal punto di vista delle verifiche di competenza, invece, quello che il Laboratorio si
trova ad affrontare in fase di accreditamento è un vero e proprio test, inviatogli dal
Responsabile della Sezione Accreditamento o dal leader degli ispettori da lui
nominati, che deve essere completato nelle tempistiche indicate in esso e può
riguardare, ad esempio, uno o più di questi argomenti:
•
le procedure previste dallo Schema;
•
i criteri ITSEC e/o Common Criteria e le relative metodologie;
•
effettuazione della valutazione, completa o parziale, di un prodotto o di un
sistema IT in accordo con quanto previsto dallo Schema e dai criteri ITSEC o
Common Criteria e dalle relative metodologie;
•
produzione di documentazione atta a costituire materiale di documentazione
per la valutazione di un prodotto o sistema IT;
•
elementi generali di sicurezza IT.
•
Il Laboratorio dovrà completare i test rispettando il vincolo temporale imposto
ed utilizzando esclusivamente le competenze del proprio personale.
Per ragioni di riservatezza non è possibile descrivere in questo documento l'entità
dei test né fare un esempio pratico di come questi sono organizzati. Ci limiteremo a
ricordare che è fondamentale che il Laboratorio, specialmente nelle figure dei
valutatori, sia opportunamente addestrato non solo sul fronte dello Schema e sulle
139
procedure che esso prevede, ma anche sul fronte delle principali problematiche di
carattere tecnico e pratico relative alla sicurezza IT.
La conclusione del processo di accreditamento, se i pareri espressi dal
Responsabile della Sezione Accreditamento e dalla Commissione TecnicoConsultiva sono entrambi positivi, riguarda l'emissione da parte dell'OC del
Certificato di Accreditamento, che abilita il Laboratorio ad effettuare attività di
valutazione secondo lo Schema Nazionale e il livello stabilito.
8.3. Validità e mantenimento del certificato di accreditamento
Una volta ottenuto il Certificato di Accreditamento, come detto, l'LVS sarà abilitato ad
operare nell'ambito dello Schema, secondo la tipologia e la portata del livello di
accreditamento stesso. Questa, come altre informazioni riguardanti il Laboratorio, è
riportata direttamente sul certificato, che ha una validità di tre anni dal momento
della sua emissione.
L'OC, tuttavia, durante questo periodo e generalmente con cadenza annuale,
effettuerà ulteriori visite ispettive finalizzate ad accertare che le condizioni abilitanti
per il Laboratorio non siano venute meno.
Alla scadenza dei tre anni, invece, è possibile rinnovare il certificato sottoponendo ad
ulteriori controlli o visite ispettive il Laboratorio stesso, nelle modalità che l'OC ritiene
opportune a seconda dei casi.
Fondamentale per conservare la validità del Certificato negli anni previsti è la notifica
puntuale di tutti i cambiamenti sia organizzativi che pratici che possono presentarsi
140
lungo questo periodo, nonché una corretta osservanza dello Schema e dei Criteri per
tutte le attività svolte dall'LVS.
Per quanto riguarda la tipologia di accreditamento, inoltre, è possibile in qualsiasi
momento richiederne la variazione, tenendo presente che l'iter a cui si va incontro è
del tutto analogo a quello percorso durante l'accreditamento iniziale. Per conferire
maggiore elasticità al processo, tuttavia, L’Organismo di Certificazione può
estendere temporaneamente il livello dell'accreditamento e la sua portata per un
Laboratorio nel caso in cui si presenti una particolare attività di valutazione che lo
richiede (in gergo augmented level, ovvero “livello di valutazione con aggiunta”).
141
9. Considerazioni finali e conclusioni
Volendo riassumere il percorso svolto nel presente lavoro, nei primi capitoli si è
cercato di dare una visione globale del panorama attuale delle certificazioni di
sicurezza, focalizzata sull’analisi degli attuali standard per la valutazione di prodotto
e sistema internazionali (Common Criteria) ed europei (ITSEC); attraverso la
definizione del contesto normativo vigente in Italia, si è passati a descrivere il
Laboratorio di Valutazione della Sicurezza fino a fornire un esempio progettuale della
sua realizzazione organizzativa, strutturale e funzionale. Continuando a seguire
questo percorso, alcune considerazioni finali devono essere fatte su ognuno di
questi concetti.
In merito agli standard di valutazione, possiamo certamente dire che i Common
Criteria siano, ad oggi, il punto di riferimento per qualsiasi attività che ruoti intorno
alla certificazione di prodotto e sistema, superando l’ormai obsoleto (ma comunque
valido) ITSEC. Il motivo di questa catalizzazione dell’attenzione dei principali attori
internazionali su di essi è senz’altro da ricercarsi nei punti di forza di questi criteri: la
loro flessibilità, soprattutto nei numerosi livelli di garanzia definiti, ha permesso la
loro applicazione in contesti eterogenei, mentre il continuo processo di sviluppo (che
non ha quasi nessun riscontro nel passato) e l’importanza che viene data dagli
sviluppatori al feedback proveniente dalla comunità degli utilizzatori hanno
contribuito ad un processo di miglioramento continuo che tra pochi mesi produrrà
una nuova major revision, la 3.1. Lo sviluppo di questa nuova versione dei criteri è
stato focalizzato sullo snellimento delle attività ridondanti e/o non strettamente
necessarie ai fini della valutazione (soprattutto in riferimento ai livelli di garanzia più
bassi), sulla revisione della terminologia, sull’aggiornamento dei requisiti funzionali e
142
di sicurezza e, soprattutto, sulla ristrutturazione delle attività stesse di valutazione.
Queste modifiche dovrebbero portare alla semplificazione dei processi di
valutazione, alla riduzione (soprattutto per il primi livelli di garanzia) della
documentazione richiesta ed ad un aumento complessivo delle capacità di esprimere
“realmente” quale sia la garanzia offerta dalle funzioni di sicurezza dei sistemi
conformi.
Pur
trovando
i
consensi
della
comunità
degli
utilizzatori
sulle
semplificazioni introdotte e sui nuovi strumenti messi a disposizione dallo standard,
questa ristrutturazione operata nelle componenti fondamentali ha suscitato alcune
critiche; la mancata compatibilità con i criteri attualmente in uso (2.3) e la
conseguente difficoltà di riutilizzo dei risultati ottenuti con questi, porterà a dover
revisionare il lavoro fin ora svolto, in modo particolare per i Profili di Protezione (che
dovranno essere sostanzialmente riscritti per poter essere utilizzati). I cambiamenti
elencati in queste poche righe portano anche ad una ulteriore riflessione: negli ultimi
anni si è assistito ad un progressivo incremento nella produzione e nell’utilizzo dei
sistemi open source, sia in ambito privato che nella Pubblica Amministrazione; fino
ad oggi, tuttavia, la diffusione della certificazione di sicurezza per questi prodotti è
stata pressoché nulla, con la sola esclusione di alcuni sistemi operativi basati su
linux e sviluppati principalmente da realtà consolidate come RedHat o Novell. Il
motivo di questo scarso contatto è sicuramente legato agli aspetti di costo e di
vastità della documentazione richiesta, entrambi in collisione con i principi di
economicità ed agilità del codice libero, nonostante l’applicazione dei criteri di
valutazione potrebbe portare enormi benefici proprio negli aspetti di garanzia che
oggi mancano a questi prodotti, soprattutto se considerati già dalle prime fasi di
sviluppo. La versione 3 dei Common Criteria, proprio in virtù delle migliorie descritte
precedentemente, segna sicuramente un ulteriore scatto nel processo di
143
avvicinamento tra le due realtà, fatto questo molto significativo nonostante il
percorso sia ancora molto lungo.
Per ciò che concerne il quadro normativo vigente in materia di sicurezza
dell’informazione e certificazione, come è stato fatto notare all’interno del paragrafo
3.3, risulta chiaro quanto questo sia frammentario e poco adeguato a proporre la
certificazione stessa come strumento di garanzia necessario (e non facoltativo) per
alcune realtà. In accordo con quanto espresso dal documento “Proposte concernenti
le strategie in materia di sicurezza informatica e delle telecomunicazione per la
Pubblica Amministrazione” redatto dal Comitato tecnico nazionale sulla sicurezza
dell’informazione, esistono dei contesti critici per i quali il tema specifico della
obbligatorietà della certificazione di terza parte dovrebbe essere specificatamente
regolamentato, estendendo opportunamente concetti già espressi dalla normativa
stessa per l’ambito classificato.
Per quanto riguarda il Laboratorio di Valutazione della Sicurezza, è chiaro quanto
questa realtà sia importante nel processo di certificazione e del contributo che
apporta anche solo nella sensibilizzazione riguardo le tematiche di sicurezza
dell’informazione. Al momento della scrittura di questo documento, l’OCSI ha già
accreditato 6 differenti LVS, a testimonianza di quanto il mercato Italiano sia
appetibile per questa tipologia di attività di business e del fatto che nei prossimi anni
il tema della valutazione e certificazione sarà centrale nel già ampio complesso della
sicurezza IT.
La progettazione di un Laboratorio presentata in questo documento è stata condotta
nell’ottica di raggiungere un compromesso tra i requisiti dettati dalla normativa e gli
aspetti di carattere pratico che devono essere gestiti nella quotidiana operatività di
144
questa realtà. Il grado di oggettività nell’analisi che si è cercato di rispettare è stato
adottato col fine di evidenziare quali siano le principali problematiche da affrontare
nella realizzazione pratica di un LVS e fornire un esempio di come queste siano
state risolte in contesti reali ed attualmente operativi. Nell’analisi, in conclusione,
sono stati evidenziati due concetti fondamentali; il primo è sicuramente che per
quanto si voglia generalizzare la progettazione di un Laboratorio di Valutazione,
questa deve necessariamente fare i conti con le caratteristiche fisiche, organizzative
e tecnologiche dell’ambiente nel quale questa realtà si andrà ad insediare. L’insieme
delle soluzioni qui presentate è quindi da mediare con le condizioni al contorno
proprie del contesto reale; gli schemi di progetto esposti, in particolare, contengono
alcune soluzioni che potrebbero essere esagerate per un Laboratorio in fase di
startup, come anche potrebbero essere insufficienti per le esigenze di una realtà già
consolidata ed affermata. Il secondo concetto invece riguarda gli aspetti di sicurezza
da considerare sia nella progettazione che nello svolgimento delle attività del
Laboratorio; dovendo rispondere ad alti requisiti di qualità, riservatezza, imparzialità,
indipendenza e obiettività, il controllo, tanto sui processi quanto sui sistemi
componenti, deve essere costante e programmatico, come anche la revisione
periodica delle procedure e delle politiche di sicurezza.
145
Indice delle illustrazioni
FIGURA 1: SOGGETTI COINVOLTI NEL PROCESSO DI CERTIFICAZIONE.................................... 14
FIGURA 2: SELEZIONE DI UNO SCHEMA.......................................................................................... 17
FIGURA 3: PROCESSO DI ACCREDITAMENTO DI UN VALUTATORE/LABORATORIO ................. 18
FIGURA 4: PROCESSO DI CERTIFICAZIONE.................................................................................... 20
FIGURA 5: MANTENIMENTO DEL CERTIFICATO PER PRODOTTO/SISTEMA............................... 21
FIGURA 6: MANTENIMENTO DEL CERTIFICATO PER PROCESSO................................................ 22
FIGURA 7: TIMELINE DEI PRINCIPALI CRITERI/STANDARD DI VALUTAZIONE ............................ 25
FIGURA 8: PROCESSO DI VALUTAZIONE E CERTIFICAZIONE SECONDO LO SCHEMA
NAZIONALE.................................................................................................................................. 71
FIGURA 9: DIAGRAMMA DELLA FASE DI PREPARAZIONE DELLA VALUTAZIONE....................... 73
FIGURA 10: DIAGRAMMA DELLA FASE DI CONDUZIONE DELLA VALUTAZIONE......................... 74
FIGURA 11: DIAGRAMMA DELLA FASE DI CONCLUSIONE DELLA VALUTAZIONE ...................... 75
FIGURA 12: DIAGRAMMA DELLE FASI DI CHIUSURA DELLA VALUTAZIONE ED EMISSIONE DEL
CERTIFICATO.............................................................................................................................. 76
FIGURA 13: ESEMPIO DI ORGANIGRAMMA PER UN LVS ............................................................... 88
FIGURA 14: STRUTTURAZIONE PER AREE DI UN LABORATORIO DI VALUTAZIONE ............... 108
FIGURA 24: STRUTTURA DI UN LVS - DEFINIZIONE DELLE AREE FUNZIONALI........................ 111
FIGURA 16: STRUTTURA DI UN LVS - INFRASTRUTTURA DI CONNETTIVITÀ E SICUREZZA
PERIMETRALE........................................................................................................................... 116
FIGURA 17: SCHEMA DI UN LVS - AREA DI ELABORAZIONE DATI, GESTIONE E CONTROLLO128
FIGURA 18: SCHEMA DI UN LVS - AREA DOCUMENTALE ............................................................ 123
FIGURA 19: SCHEMA DI UN LVS - AREA DI TEST .......................................................................... 125
FIGURA 20: SCHEMA DI UN LVS - AREA UTILITIES ....................................................................... 127
FIGURA 21: SCHEMA DI UN LVS - RISULTATO FINALE................................................................. 129
FIGURA 22: FASI DEL PROCESSO DI ACCREDITAMENTO SECONDO LO SCHEMA.................. 137
FIGURA 23: DETTAGLIO DEL PROCESSO DI ACCREDITAMENTO SECONDO LO SCHEMA ..... 138
146
Indice delle tabelle
TABELLA 1:AMBITI DI CERTIFICAZIONE E CRITERI ADOTTATI ........................................................... 22
TABELLA 2: UTILIZZO DELLO STANDARD PER TIPOLOGIA DI UTENZA............................................ 39
TABELLA 3: LIVELLI DI GARANZIA OFFERTI DA TCSEC, ITSEC E COMMON CRITERIA................ 60
TABELLA 4: LIVELLI DI ACCREDITAMENTO SECONDO ITSEC........................................................... 132
TABELLA 5: LIVELLI DI ACCREDITAMENTO SECONDO I COMMON CRITERIA .............................. 132
147
Bibliografia
Leggi, decreti, normative
[1] Presidenza del Consiglio dei Ministri/Autorita’ Nazionale per la Sicurezza, “Linea Guida -Procedure
di Valutazione” P.C.M.-A.N.S. / LG – VAL.
[2] Decreto del Ministro per l’Innovazione e le Tecnologie e del ministro delle Comunicazioni 17
febbraio 2005 “Linee guida provvisorie per l’applicazuione dello schema nazionale per la valutazione e
certificazione di sicurezza nel settore della tecnologia dell’Informazione.
[3] D.P.C.M. 11 aprile 2003 – Schema nazionale per la valutazione e la certificazione della sicurezza
delle tecnologie dell’informazione, ai fini della tutela delle informazioni classificate, concernenti la
sicurezza interna ed esterna dello Stato.
[4] D.P.C.M 30 ottobre 2003 – Approvazione dello schema nazionale per la valutazione e la
certificazione della sicurezza nel settore della tecnologia dell’informazione, ai sensi dell’art.10, comma
1, del decreto legislativo n. 10 del 23 gennaio 2002.
Standards
[5] CCMB-2005-08-001, “Common Criteria for Information Technology Security Evaluation, Part 1 –
Introduction and general model”, version 2.3, agosto 2005.
Security functional requirements”, version 2.3, agosto 2005.
Security assurance requirements”, version 2.3, agosto 2005.
[8] CCMB-2005-08-004, “Common Evaluation Methodology for Information Technology Security
Evaluation – Evaluation Methodology”, version 2.3, agosto 2005.
[9] ISO/IEC 2382-8, “Information technology – Vocabulary” – Part 8: Security, 1998
[10] ISO/IEC TR 15446, “Information technology – Security techniques – Guide for the production of
Protection Profiles and Security Targets”, dicembre 2003.
[11] Information Technology Security Evaluation Criteria, version 1.2, giugno 1991.
[12] Information Technology Security Evaluation Manual, version 1.0, settembre 199.
148
[13] ISO/IEC 17799 Information technology – Code of practice for information security management.
[14] ISO/IEC 27001 Information technology – Security techniques – Information security management
systems – Requirements.
[15] ISO/IEC 15408-1:2005 Information technology - Security techniques – Evaluation criteria for IT
security - Part 1: Introduction and general model. Disponibile al sito web: http://webstore.ansi.org/
[16] ISO/IEC 15408-2:2005 Information technology - Security techniques - Evaluation criteria for IT
security - Part 2: Security functional requirements. Disponibile al sito web: http://webstore.ansi.org/
[17] ISO/IEC 15408-3:2005 Information technology - Security techniques - Evaluation criteria for IT
security - Part 3: Security assurance requirements technology - Security techniques - Evaluation
criteria for IT security. Disponibile al sito web http://webstore.ansi.org/
[18] UNI/CEI EN ISO/IEC 17025 Requisiti generali per la competenza dei laboratori di prova e di
taratura, 2000.
Linee Guida e Procedure
[19] OCSI, Procedure dello Schema di Gestione dei Certificati.
[20] OCSI, Linee Guida Provvisorie – Parte 1, “Descrizione Generale dello Schema Nazionale”
Versione 1.0, dicembre 2004. Disponibile al sito web: http://www.ocsi.isticom.it/documenti/LGP1_v1204.pdf
[21] OCSI, Linee Guida Provvisorie – Parte 2, “Accreditamento degli LVS e abilitazione degli
Assistenti” Versione 1.0, dicembre 2004. Disponibile al sito web:
http://www.ocsi.isticom.it/documenti/LGP2_v12-04.pdf
[22] OCSI, Linee Guida Provvisorie – Parte 3, “Procedure di valutazione” Versione 1.0, dicembre 2005.
Disponibile al sito web: http://www.ocsi.isticom.it/documenti/LGP3_v12-04.pdf
[23] OCSI, Linee Guida Provvisorie – Parte 4, “Attività di valutazione secondo i Common Criteria”
Versione 1.0, dicembre 2005. Disponibile al sito web: http://www.ocsi.isticom.it/documenti/LGP4_v1204.pdf
[24] OCSI, Linee Guida Provvisorie – Parte 5, “Guida alla scrittura dei Profili di Protezione e dei
Traguardi di Sicurezza” Versione 1.0, dicembre 2005. Disponibile al sito web:
149
[25] OCSI, Linee Guida Provvisorie – Parte 6, “Guida alla scrittura dei Profili di Protezione e dei
Traguardi di Sicurezza” Versione 1.0, dicembre 2005. Disponibile al sito web:
[26] OCSI, Linee Guida Provvisorie – Parte 7, “Glossario e terminologia di riferimento” Versione 1.0,
dicembre 2005. Disponibile al sito web: http://www.ocsi.isticom.it/documenti/LGP7-v12-04.pdf
[27] OCSI, Nota informativa dello Schema n. 1/06, ottobre 2006. Disponibile al sito web:
http://www.ocsi.isticom.it/documenti/NIS_1_06_v1.pdf
[28] OCSI, Nota informativa dello Schema n. 1/07, marzo 2007. Disponibile al sito web:
http://www.ocsi.isticom.it/documenti/nis_1_07_v1.0.pdf
Miscellanea
[31] CNIPA, “i Quaderni”, n.23 marzo 2006, “Linee Guida per la sicurezza ICT nelle Pubbliche
Amministrazioni. Piano Nazionale della sicurezza delle ICT per la PA. Modello organizzativo nazionale
di sicurezza ICT per la PA”, disponibile all’indirizzo web
http://www.cnipa.gov.it/site/_files/Quaderno%20n%2023.pdf
[32] Comitato tecnico nazionale sulla sicurezza informatica e delle telecomunicazioni nelle pubbliche
amministrazioni, “Proposte concernenti le strategie in materia di sicurezza informatica e delle
telecomunicazioni per la pubblica amministrazione”, marzo 2004.
[32] Franco Guida, “La certificazione ICT in Italia”, atti del convegno La certificazione ICT in Italia, 11
febbraio 2005.
[34] Ing. Pierluigi Bagni, “Standard di valutazione e certificazione della sicurezza IT”, 10 ottobre 2003
150
151

Common Criteria e ITSEC: le certificazioni di

Transcript

Documenti analoghi

PDF995, Job 2 - RETI CIVICHE per la PAL

IRSAF – Anglia Ascentis Esol Via San Martino, 34 82016

27 maggio - Dott. Schirripa

la certificazione - PMI Rome Italy Chapter

31/12/2015 Anno IV n° 19 Novembre-Dicembre 2015

Denominazione ente Punteggio Associazione FOR. EVE. Ascentis

ELETTRIKA S.R.L.

CENTRO DI FORMAZIONE MATRIX

Programma Cisco Networking Academy

BANDO GARA TRINITY 2015