Scarica il testo del quaderno in formato pdf (769.23 KB)

Iquadernidi
A cura di Alberto Mucci
ANCHE L’ITALIA SI DOTA DI
UN ORGANISMO CHE CERTIFICA
LA SICUREZZA INFORMATICA
L
La notizia è positiva e di particolare significato in questa delicata fase di passaggio
e di innovazioni tecnologiche: è stata istituito anche in Italia l’organismo di
certificazione della sicurezza degli apparati ICT (informatica e comunicazione).
Quest’organismo è stato individuato nell’Istituto Superiore delle Comunicazioni
e delle Tecnologie dell’Informazione il quale, insieme alla Fondazione Ugo Bordoni,
opera da anni nel settore della valutazione della sicurezza ICT.
La costituzione dell’organismo colma una lacuna importante nel nostro sistema di
certificazione legato alla sicurezza. In pratica il nuovo organismo permetterà di fare
certificazioni anche fuori dal contesto della sicurezza nazionale (tutela delle informazioni
coperte dal “segreto di Stato”), per il quale esiste fin dal 1995 uno Schema nazionale
di certificazione coordinato dall’Autorità Nazionale per la Sicurezza (ANS).
Le ricadute positive di questa novità meritano attenzione, come documentano gli
interventi che compaiono in questo “Quaderno”. In particolare:
-si creano le condizioni perché le imprese possano incrementare le vendite di
specifici prodotti una volta che questi siano dotati di certificazioni di sicurezza;
-gli utilizzatori di prodotti potranno avere una certificazione con garanzie che
vanno oltre la semplice dichiarazione del fornitore;
- i fornitori privati di servizi potranno sperare di ampliare la propria clientela
dichiarando di avvalersi di sistemi ICT provvisti di certificazione di sicurezza,
soprattutto quando gestiscano dati che richiedono adeguata protezione;
- i responsabili del trattamento di dati rilevanti sotto il profilo della sicurezza
potranno dimostrare di aver curato al meglio la loro protezione qualora abbiano
provveduto a certificare i propri sistemi ICT.
La certificazione attuale, utilizzata nel contesto della sicurezza nazionale, ha costi
elevati e tempi operativi lunghi. Con il nuovo organismo si creano i presupposti per
applicare gli standard di certificazione anche a livelli meno elevati, semplificando
le procedure, ma fornendo nel contempo adeguate garanzie. Si potranno certificare
con maggiore facilità sistemi complessi e verrà reso più agevole il mantenimento nel
tempo della certificazione accordata.
Nel maggio 2003 Telema affrontò il tema della sicurezza con lo sviluppo di Internet.
Ampliamo oggi il ventaglio degli scenari che hanno come centro motore la sicurezza,
con le sue molteplici applicazioni, con le tante sfide legate all’incessante progredire
dell’innovazione.
Supplemento al numero 217 di giugno 2004
di MEDIA DUEMILA

INDICE
La certificazione della sicurezza ICT
La certificazione della sicurezza ICT nella Pubblica Amministrazione
L’analisi dei rischi e le certificazioni di sicurezza ICT
L’Organismo di certificazione della sicurezza di sistemi e prodotti ICT
Il processo di certificazione della sicurezza informatica
ITSEC: i criteri europei per la valutazione della sicurezza informatica
Lo Schema nazionale di certificazione della sicurezza informatica
Lo standard Common Criteria (ISO/IEC IS 15408)
Il Quaderno è stato realizzato dalla Fondazione Ugo Bordoni (Presidente il Prof. Giordano
Bruno Guerri, Direttore Generale il Consigliere Guido Salerno, Direttore delle Ricerche l’Ing.
Mario Frullone). Coordinatore del Quaderno l’ing. Franco Guida. Hanno collaborato: Claudio
Manganelli, CNIPA; Giorgio Tonelli, Isabella Marra, Ambrosetti; Carmelo Basso, Giuseppe
Pierri, Giovanni Desirò, ISCTI; Marco Carbonelli, Fondazione Ugo Bordoni.
Sono usciti:
Un web per tutti. L’accessibilità di Internet ottobre 2002
Wi-Fi. Come – quando – perché novembre 2002
I satelliti nella società multimediale dicembre-gennaio 2003
Telefonia mobile e emissioni elettromagnetiche febbraio 2003
Le reti di telecomunicazioni diventano intelligenti marzo 2003
Mentre viaggi lavori con Internet aprile 2003
Come garantire sicurezza con lo sviluppo di Internet maggio 2003
Le macchine che parlano giugno 2003
Le macchine che capiscono luglio-agosto 2003
Il progresso tecnologico fra brevetti e standard settembre 2003
La rendicontazione? Automatica, ma… ottobre 2003
Le nuove tecnologie fotoniche novembre 2003
Il progetto Galileo sta diventando realtà dicembre-gennaio 2004
Non confondere la biometrica con il “grande fratello febbraio 2004
Dal call center al contact center marzo 2004
La larga banda si diffonde cambia la vita della gente aprile 2004
I campi elettromagnetici non sono più “sconosciuti” maggio 2004
67
68
72
74
78
82
85
89

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
La certificazione
della sicurezza ICT
Adistanza di circa un anno dal primo
Quaderno di Telèma dedicato alla sicurezza
ICT, ho accettato con grande
entusiasmo l’invito rivoltomi dal dott. Guido
Salerno, Direttore Generale della Fondazione
Ugo Bordoni (FUB), e dal dott. Alberto Mucci,
coordinatore dei Quaderni, a curare una seconda
edizione che permettesse di tornare su
un argomento la cui importanza ed attualità
continua a crescere. Chi ha avuto l’opportunità
di leggere il Quaderno di Maggio 2003, ricorderà
forse che ci eravamo già lasciati con
l’intenzione di continuare il discorso intrapreso
ed erano già stati individuati vari temi, tra
quelli su cui la Fondazione è impegnata relativamente
alla sicurezza ICT, da sviluppare in un
successivo Quaderno. Mi è apparso però ben
presto chiaro che, tenendo conto della recentissima
novità costituita dall’istituzione di un
Organismo nazionale di certificazione della sicurezza
dei sistemi ICT, strutturare il presente
Quaderno seguendo le linee tracciate lo scorso
anno non sarebbe stato opportuno. Sebbene
con il rammarico di non poter dare spazio a
colleghi e collaboratori della Fondazione che
avrebbero potuto fornire una panoramica di
notevole interesse sui temi di cui quotidianamente
si occupano, ho quindi scelto di dedicare
interamente il Quaderno alla certificazione
della sicurezza, dato anche il notevole impatto
che la novità cui ho accennato sopra sta avendo
ed avrà sulle attività della Fondazione Bordoni
nell’area della sicurezza ICT.
L’assunzione del ruolo di Organismo di certificazione
da parte dell’Istituto Superiore delle
Comunicazioni e delle Tecnologie dell’Informazione
(ISCTI), infatti, si traduce in un notevole
impegno anche da parte della FUB, data
la tradizionale collaborazione nel campo tecnico
che oramai da svariati decenni lega le due
organizzazioni.
Grazie alla disponibilità manifestata dall’ing.
Manganelli, Componente del Centro Nazionale
Giugno 2004
per l’Informatica nella Pubblica
Amministrazione (CNIPA),
il Quaderno può aprirsi con un
articolo di grande interesse che
riporta le azioni che sono state
svolte e che si intende svolgere
nell’ambito della PA relativamente
alla certificazione della Franco Guida
sicurezza ICT. Tali azioni sono
ascrivibili al Comitato tecnico nazionale per la
sicurezza informatica e delle telecomunicazioni
nelle PA, di cui l’ing. Manganelli è Presidente e
del quale mi onoro di far parte.
Il successivo articolo tratta invece i legami tra
l’analisi dei rischi e la certificazione della sicurezza
ICT ed è stato scritto dal dott. Tonelli (anch’egli
autorevole membro del predetto Comitato)
e dalla dott.ssa Marra di Ambrosetti.
Un ulteriore articolo da parte di un altro
membro del Comitato, il Presidente Carlo Sarzana
di S. Ippolito, eminente figura di riferimento
per quanto riguarda gli aspetti giuridici
relativi alle tecnologie informatiche, non ha
potuto purtroppo essere realizzato in tempo utile
per la pubblicazione, data la novità e la
complessità del tema da affrontare (i riflessi
giuridici della certificazione di sicurezza ICT).
Naturalmente non potevano poi mancare
contributi da parte dell’ISCTI, che svolge evidentemente
il ruolo di protagonista considerato
il tema di questo Quaderno. È quindi presente
innanzitutto un articolo del Direttore
dell’ISCTI, ing. Basso, che con la sua guida autorevole
ha creato le condizioni affinché l’Istituto,
coadiuvato dalla Fondazione Bordoni,
potesse assumere un impegno così importante
e al tempo stesso così gravoso. Tale impegno,
peraltro, va ad aggiungersi ad altri di non minore
rilievo nel settore della sicurezza ICT,
quali ad esempio l’allestimento di un Centro di
formazione per i dipendenti della PA e la gestione
del Centro di Valutazione accreditato
dall’Autorità Nazionale per la Sicurezza.
67

La certificazione della sicurezza ICT nella Pubblica Amministrazione
I successivi due contributi ISCTI, che descrivono
il processo di certificazione della sicurezza
ICT ed i criteri di valutazione europei
ITSEC, sono invece stati sviluppati dall’ing.
Pierri, che dirige l’Ufficio ISCTI entro il quale
l’Organismo di certificazione è stato costituito
ed il dott. Desirò, che coordina l’Area gestionale
di tale Organismo.
Il Quaderno si chiude infine con due contributi
FUB, nel primo dei quali l’ing. Carbonelli
descrive sommariamente la normativa
(Linee Guida) che sarà adottata nella fase di
avvio dello Schema nazionale e che è stata sviluppata
sotto il suo coordinamento. Il secondo
contributo FUB, da me predisposto, illustra
invece i principi ispiratori dei Common
Criteria, lo standard mondiale di riferimento
per la certificazione della sicurezza dei sistemi
informatici.
Apartire dall’inizio del
2002 il tema della sicurezza
ICT nella
Pubblica Amministrazione è
stato affrontato in modo orga-
Claudio Manganelli
nico a livello governativo attraverso
una direttiva del Presidente
del Consiglio dei Ministri [1], emanata
dal Ministro per l’innovazione e le tecnologie
d’intesa con il Ministro delle Comunicazioni,
ed un successivo decreto interministeriale
[2] con il quale gli stessi Ministri hanno
creato un gruppo di indirizzamento e coordinamento
relativamente alle azioni previste
nella direttiva. Una trattazione di queste iniziative
governative sarebbe stata comunque
opportuna nell’ambito di questo Quaderno
Telema. Ove si consideri, poi, che proprio al
tema della certificazione della sicurezza ICT
68
Per quanto riguarda quest’ultimo contributo,
viene in particolare evidenziata la capacità
che questo standard offre di soddisfare una esigenza
molto sentita ed attuale, quella di fornire
garanzie, senza richiedere tempi e costi
particolarmente rilevanti, circa l’effettivo aggiornamento
del software installato sui sistemi
ICT. L’importanza di questa esigenza è dimostrata
dai numerosi incidenti informatici che
sono stati causati dalla mancata installazione
delle patch che avrebbero consentito di eliminare
vulnerabilità scoperte nel software.
Franco Guida
Fondazione Ugo Bordoni
Membro del Comitato tecnico nazionale sulla
sicurezza informatica e delle telecomunicazioni
nelle pubbliche amministrazioni
Coordinatore Area operativa dell’Organismo
di Certificazione
La certificazione della sicurezza
ICT nella Pubblica
Amministrazione
le suddette iniziative hanno dedicato un’attenzione
particolare, la loro illustrazione nel
presente Quaderno è diventata una scelta
praticamente obbligata.
Sicurezza ICT nella PA: le iniziative
governative
Nel corso degli anni Novanta sono stati emanati
i primi provvedimenti governativi riguardanti
la sicurezza ICT, i quali, però, hanno
affrontato di volta in volta aspetti specifici
in modo frammentario, non essendo stato
precedentemente definito un approccio unitario
applicabile all’intera PA. Come già accennato,
quindi, il primo riferimento che è possibile
citare per descrivere le azioni che il Governo
ha intrapreso al fine di garantire una
gestione organica della sicurezza ICT all’in-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
terno della PA è costituito dalla direttiva “Sicurezza
Informatica e delle Telecomunicazioni
nelle Pubbliche Amministrazioni Statali”
[1]. Con tale direttiva, i cui principi ispiratori
sono conformi alle normative internazionali
maggiormente accreditate (si consideri, ad esempio,
lo standard [5]), vengono gettate le
basi per lo sviluppo del programma di azione
del Governo nel campo della sicurezza ICT e
vengono fornite indicazioni alle pubbliche
amministrazioni relativamente alle azioni
prioritarie da svolgere nell’immediato. In particolare
viene raccomandato:
– di eseguire un’autodiagnosi, sulla base dell’allegato
1 della direttiva, del livello di adeguatezza
della sicurezza ICT, con particolare
riferimento alla dimensione organizzativa operativa
e conoscitiva della sicurezza;
– di attivare le necessarie iniziative per posizionarsi
su una “base minima di sicurezza”,
definita nell’allegato 2 della direttiva.
Una descrizione dettagliata della direttiva [1]
non è possibile per motivi di spazio, per cui ci si
limiterà ad approfondire gli aspetti riguardanti
la certificazione. A tal riguardo la direttiva prevede
che il Dipartimento per l’innovazione e le
tecnologie della Presidenza del Consiglio dei
Ministri ed il Ministero delle comunicazioni
promuovano la predisposizione di un programma
di azione del Governo per la sicurezza ICT
articolato su varie linee, tra le quali:
– definire uno schema nazionale di riferimento
della sicurezza sviluppando linee guida,
direttive, standard, nonché i processi di accreditamento
e di certificazione;
– realizzare la certificazione di sicurezza ICT
nella pubblica amministrazione;
– costituire un Comitato nazionale della sicurezza
ICT per indirizzare, guidare e coordinare
le varie iniziative connesse con il raggiungimento
degli standard di sicurezza che
verranno definiti.
Per quanto riguarda la prima linea di azione,
il decreto [3] ha definito lo Schema nazionale
per la valutazione e certificazione della sicurezza
di sistemi e prodotti nel settore della tecnologia
dell’informazione e sono attualmente in
Giugno 2004
corso la definizione e la regolamentazione di
tutte le attività che si svolgeranno all’interno
dello Schema. Per quanto riguarda invece la
seconda linea, si rimanda al successivo paragrafo
per la descrizione delle azioni già intraprese
e da intraprendere ai fini della sua realizzazione.
Relativamente alla terza linea, infine,
si può richiamare il già citato decreto interministeriale
[2] che ha istituito il Comitato Tecnico
Nazionale sulla sicurezza informatica e delle
telecomunicazioni nelle pubbliche amministrazioni
(nel seguito denominato brevemente
Comitato). Tale decreto prevede che il Comitato
sia costituito da cinque membri, due nominati
dal Ministro delle Comunicazioni (tra
cui il Presidente) e tre dal Ministro per l’innovazione
e le tecnologie. Le funzioni assegnate
al Comitato sono le seguenti:
– sviluppare le strategie da seguire ai fini dello
sviluppo del Piano nazionale e del modello
organizzativo nazionale della sicurezza ICT
nella pubblica amministrazione;
– verificare annualmente lo stato di avanzamento
del Piano nazionale (indicando eventuali
azioni correttive) nonché l’attivazione e
applicazione del modello organizzativo;
–formulare “proposte in materia di regolamentazione
della certificazione e valutazione
della sicurezza, nonché ai fini della predisposizione
di criteri di certificazione e delle
linee guida per la certificazione di sicurezza
ICT per la pubblica amministrazione, sulla
base delle normative nazionali, comunitarie
e internazionali di riferimento”;
–elaborare linee guida per la predisposizione
delle intese con il Dipartimento della funzione
pubblica in ordine alla formazione dei dipendenti
pubblici in tema di sicurezza ICT.
La terza funzione costituisce evidentemente
il contributo del Comitato alla realizzazione
della linea di azione prevista nella direttiva [1]
relativamente alla certificazione di sicurezza
ICT nella pubblica amministrazione. Anche
per quanto riguarda questa funzione, quindi,
ulteriori informazioni possono essere trovate
nel successivo paragrafo.
A completamento di questo quadro sintetico
sulle iniziative governative è infine oppor-
69

70
La certificazione della sicurezza ICT nella Pubblica Amministrazione
tuno segnalare che nella riunione del 18 marzo
2003 il Comitato dei Ministri per la Società
dell’informazione ha espresso il proprio parere
favorevole relativamente al finanziamento
di due progetti riguardanti la sicurezza ICT
nella PA. Tali progetti, denominati «CERT
per la Pubblica Amministrazione» e «Centro
di formazione e sensibilizzazione del personale
della PA», sono stati sviluppati in una prima
fase dal Comitato e sono stati poi fatti propri,
rispettivamente, dal Centro Nazionale per
l’Informatica nella Pubblica Amministrazione
(CNIPA) e dall’Istituto Superiore delle Comunicazioni
e delle Tecnologie dell’Informazione
(ISCTI), che ne cureranno l’ulteriore
sviluppo e la realizzazione.
Le linee guida per la certificazione
di sicurezza ICT nella pubblica
amministrazione
Come già anticipato nel precedente paragrafo,
tra gli obiettivi del programma di azione
del Governo per la sicurezza ICT vi è la realizzazione
della certificazione di sicurezza ICT
nella pubblica amministrazione. A tal fine un
passaggio obbligato è stato la creazione, grazie
anche all’azione di stimolo esercitata dal Comitato,
dello Schema nazionale per la valutazione
e certificazione della sicurezza nel settore
della tecnologia dell’informazione [3]. Una
volta avviata l’attivazione di un servizio di certificazione
della sicurezza di apparati ICT, il
successivo compito di cui il Comitato ha dovuto
farsi carico è stato quello di definire le modalità
di utilizzazione di tale servizio all’interno
della PA.
Le prime indicazioni
Nell’ambito del documento [4], recentemente
prodotto dal Comitato, il problema
della certificazione di sicurezza ICT nella PA
è stato affrontato iniziando ad orientare le
amministrazioni nelle scelte che a tal riguardo
dovranno effettuare. In particolare si è
previsto che il Comitato stesso assista le PA
nelle decisioni relative alla certificazione, avvalendosi
anche delle informazioni derivabili
dal questionario di autovalutazione (allegato
1 della direttiva [1]) al quale le PA stesse sono
state invitate a rispondere. Più precisamente
il Comitato potrà raccomandare che,
nei casi in cui risultino situazioni di elevata
criticità, in aggiunta alle verifiche interne
(ossia eseguite da personale dell’amministrazione)
già previste dall’allegato 2 della direttiva
[1], vengano eseguite vere e proprie certificazioni
di apparati ICT secondo i Common
Criteria [7] [8] [9] o i criteri ITSEC
[10]. In queste stesse situazioni il Comitato
potrà eventualmente raccomandare l’esecuzione
di certificazioni del processo di gestione
della sicurezza ICT in singole Amministrazioni
o in parti di esse, eseguite secondo
lo standard BS7799-2 [6]. Queste indicazioni
possono considerarsi in linea con quanto
previsto nel documento [11] che presenta
come consigliabile l’uso della certificazione
di sicurezza:
1) per i sistemi ICT che trattano informazioni
le quali, sebbene non classificate ai fini della sicurezza
nazionale (in caso contrario le certificazioni
sono obbligatorie sia in Italia sia in
molti paesi esteri), possono essere considerate
critiche o essenziali per lo svolgimento delle
funzioni primarie dell’Amministrazione,
2) per i sistemi ICT da cui dipendono l’operatività
e/o la manutenzione delle infrastrutture
critiche.
Inoltre nel documento [12] viene affermato
che il governo statunitense si propone di verificare
la fattibilità economica dell’estensione
dell’obbligo di certificazione ai sistemi ICT utilizzati
da tutte le agenzie federali, anche nei
casi in cui non trattino informazioni classificate.
Il governo statunitense prevede peraltro
che, qualora tale estensione possa essere effettuata,
essa influenzerà molto positivamente il
mercato dei prodotti ICT consentendo di godere
dei relativi benefici anche al di fuori del
contesto governativo.
Le prossime azioni
Dopo le prime indicazioni che il Comitato
ha fornito attraverso il documento [4], potrà
essere sviluppata, nell’ambito del programma
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
di azione del Governo per la sicurezza ICT,
una strategia complessiva per ciò che concerne
la certificazione della sicurezza ICT nella
PA. In particolare potrà essere raccomandato
di servirsi anche dei primi livelli di certificazione,
i quali, sebbene poco utilizzati nel contesto
della sicurezza nazionale, possono offrire
spesso, nel contesto generale, significative
garanzie di sicurezza, senza richiedere costi e
tempi particolarmente rilevanti. Inoltre le
certificazioni eseguite a tali livelli hanno il
vantaggio di richiedere un coinvolgimento
nullo o limitato di chi ha sviluppato le componenti
del sistema ICT e rendono quindi più
agevole la certificazione di interi sistemi, nonché
il mantenimento nel tempo della certificazione
stessa. Analogamente a quanto avviene
nella pubblica amministrazione statunitense,
inoltre, lo standard Common Criteria potrà
essere utilizzato anche fuori del contesto
di una certificazione prevedendo lo sviluppo
di opportuni Profili di Protezione (Protection
Profile) che esprimano in modo standardizzato
obiettivi, ambiente ipotizzato e requisiti di
sicurezza per varie tipologie di prodotti ICT.
Tali Profili potranno essere utilizzati dalle PA
nella stesura di capitolati e sarà possibile, a
seconda dell’entità dei rischi, ritenere sufficiente
un’autodichiarazione del fornitore circa
il soddisfacimento dei requisiti di sicurezza
specificati nei Profili stessi oppure prevedere
una vera e propria certificazione. In quest’ultimo
caso, peraltro, la disponibilità dei Profili
renderà più agevole e veloce la stesura della
documentazione necessaria per la certificazione
stessa.
Claudio Manganelli
Componente CNIPA
Presidente del Comitato Tecnico Nazionale
sulla sicurezza informatica e delle telecomunicazioni
nelle pubbliche amministrazioni
Giugno 2004
Documenti di riferimento
[1] Direttiva 16 gennaio 2002 del Presidente del Consiglio
dei Ministri “Sicurezza Informatica e delle
Telecomunicazioni nelle Pubbliche Amministrazioni
Statali” (pubblicata sulla G.U. n.69 del 22 marzo
2002).
[2] Decreto 24 luglio 2002 del Ministro delle comunicazioni
e del Ministro per l’innovazione e le tecnologie
“Istituzione del Comitato Tecnico Nazionale sulla sicurezza
informatica e delle telecomunicazioni nelle
pubbliche amministrazioni”.
[3] Decreto 30 ottobre 2003 del Presidente del Consiglio
dei Ministri “Approvazione dello Schema nazionale
per la valutazione e certificazione della sicurezza di
sistemi e prodotti nel settore della tecnologia dell’informazione”
(pubblicato sulla G.U. n.98 del 27 aprile
2004).
[4] Proposte concernenti le strategie in materia di sicurezza
informatica e delle telecomunicazioni per la
pubblica amministrazione – Documento del Comitato
Tecnico Nazionale sulla sicurezza informatica e
delle telecomunicazioni nelle pubbliche amministrazioni
– Marzo 2004.
[5] ISO/IEC IS 17799-1 - Information security management
- Part 1: Code of practice for information security
management.
[6] BS7799-2 - Information security management systems
- Specification with guidance for use.
[7] ISO/IEC IS 15408-1 Evaluation Criteria for Information
Technology Security - Part 1: Introduction
and general model.
[8] ISO/IEC IS 15408-2 Evaluation Criteria for Information
Technology Security - Part 2: Security functional
requirements.
[9] ISO/IEC IS 15408-3 Evaluation Criteria for Information
Technology Security - Part 3: Security assurance
requirements.
[10] Information Technology Security Evaluation Criteria
(ITSEC) - SOG-IS (Senior Officials Group Information
Systems Security) – Giugno 1991.
[11] National Security Telecommunications and Information
Systems Security Policy (NSTISSP) No. 11,
Subject: National Policy Governing the Acquisition
of Information Assurance (IA) and IA-Enabled
Information Technology (IT) Products – National Security
Telecommunications and Information Systems
Security Committee (NSTISSC) – Documento governativo
USA - Gennaio 2000
[12] The National Strategy to Secure Cyberspace – Documento
governativo USA – Febbraio 2003.
71

La ragion d’essere della
sicurezza delle informazioni
di un’impresa è
essenzialmente quella di mantenere
il rischio ad un livello
ritenuto accettabile dal mana-
Giorgio Tonelli gement.
Questo assunto apparentemente
banale introduce però due aspetti cruciali del
problema:
– il fatto che si tratta di un’opzione strategica della
direzione e non dell’IT;
– la necessità di definire il rischio che si intende
tollerare.
Le riflessioni che seguono vogliono fornire
un contributo concettuale al processo di interpretazione
della rilevanza organizzativa della
gestione del rischio nei confronti di un approccio
in atto che si connota storicamente come
sostanzialmente tecnologico.
La sicurezza delle informazioni rappresenta
un obiettivo di rilevanza strategica che richiede
il coinvolgimento attivo della direzione/management
nel tempo al fine di gestire dinamicamente
il rischio informativo nell’ambito di
una strategia della sicurezza coerente con la
strategia di business e con la struttura organizzativa
dell’Ente/Azienda.
La certificazione del Sistema di Protezione
delle Informazioni (Information Security Management
System, ISMS) di per sé non rappresenta
necessariamente l’attestazione del raggiungimento
dell’obiettivo.
La strada della realizzazione di efficaci I-
SMS è purtroppo lastricata di insuccessi; investimenti
anche rilevanti non hanno generalmente
prodotto i risultati attesi a causa di una
insufficiente definizione degli obiettivi, di una
confusa ed imprecisa individuazione dei reali
rischi e di una valutazione degli impatti sulle
attività praticamente assente nei processi di Risk
Assessment.
72
L’analisi dei rischi e le certificazioni di sicurezza ICT
L’analisi dei rischi e le certificazioni
di sicurezza ICT
L’auto-valutazione dei manager, la dimensione
globale della progettazione (strategica, organizzativa
e tecnologica), i confini dell’analisi
e i livelli di approfondimento delle vulnerabilità
sono infatti aspetti discriminanti che, se
mal indirizzati, possono compromettere l’efficienza
ed efficacia di tutto il lavoro.
Una visione unitaria
In un contesto di rapido cambiamento e
complessità crescente è necessaria una visione
unitaria e strategica delle aree di rischio e una
valutazione della loro criticità in relazione agli
impatti sul business.
Occorre, quindi, un’analisi del rischio preliminare
di alto livello orientata alla valutazione
degli impatti, utilizzando un approccio olistico
in grado di rappresentare le variabili dinamiche
nell’ambito dell’Ente inteso come sistema
di entità – relazioni.
Solo a valle di tali considerazioni il perimetro
di certificazione può essere deciso in modo
significativo con un razionale che giustifica i
successivi investimenti da realizzare.
É sulle aree valutate critiche che, con successivi
livelli di approfondimento, deve essere
focalizzata una analisi del rischio di dettaglio,
giungendo fino alle singole componenti tecnologiche
che possono rappresentare fonti di rischio
e, quindi, individuando le relative contromisure.
La certificazione degli apparati ICT si configura,
a sua volta, come una possibile contromisura
in grado di garantire una particolare efficacia
nella riduzione delle vulnerabilità dei sistemi,
point of failure, che potrebbero essere
impropriamente messe a frutto per effettuare
intrusioni dall’esterno.
Le certificazioni di sistemi e prodotti ICT
secondo gli standard Common Criteria e IT-
SEC rappresentano, quindi, un’opportunità
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
per gestire i rischi tecnologici, da valutare in
relazione all’entità dei rischi stessi.
Per orientare la scelta delle contromisure da
realizzare, infatti, occorre a monte una visione
complessiva del rischio e dei possibili impatti
al fine di evitare spese inutili e non commisurate
ai valori da proteggere.
L’analisi del rischio
L’analisi del rischio non è però confinabile
ad ambiti puramente tecnologici e non può essere
indirizzata solo da una visione tecnologica
del tema.
Infatti, sul piano della gestione strategica,
assicurare il giusto equilibrio tra il valore
del patrimonio da salvaguardare, i rischi cui
risulta esposto e gli investimenti necessari
per proteggerlo è responsabilità di tutta la
direzione.
Il management deve condividere una serie
di principi e regole e diffondere policy e linee
guida a tutta l’Organizzazione, attuando una
funzione di indirizzo, ma anche di governo e
coordinamento del rischio e della sicurezza.
I principi organizzativi guida per il Sistema
di Sicurezza sono, in sintesi:
Governance degli Asset o Asset Corporate
Governance
Corretta responsabilizzazione
Realizzazione di un presidio globale.
Per assicurare che le policy e le linee guida emanate
dalla Asset Corporate Governance di sicurezza
possano essere effettivamente rese operative,
è, infatti, indispensabile integrare la
struttura organizzativa con una rete di responsabilità
specifiche (ad esempio ownership degli
asset) attribuite a Presidi Organizzativi chiaramente
definiti in termini di missione e macro
attività.
La sicurezza non può essere garantita da una
funzione (Security management) separata dalle
attività operative, disgiunta dalle responsabi-
Giugno 2004
lità di business e misurata su obiettivi di processo;
deve invece essere assicurata dai ruoli aziendali
che hanno a disposizione le effettive
leve di responsabilità e di conoscenza della
realtà dell’Ente/Azienda necessarie per prendere
decisioni chiave relativamente a tre aspetti:
il contributo al business dell’asset da proteggere,
il livello di rischio accettabile e l’investimento
che è opportuno sostenere per raggiungere
tale livello.
L’analisi del rischio viene, in questo modo,
gestita come parte integrante del processo decisionale
e viene applicata a tutte le reali sorgenti
di valore del business.
Per fare questo, occorre evidentemente attivare
un presidio diffuso a tutti i livelli della
struttura, evitando l’eccessiva burocratizzazione
e la proliferazione di ruoli specifici e
spesso ridondanti. La via è quella di attribuire
a ruoli già esistenti anche precise responsabilità
di governo (analisi, gestione e monitoraggio)
del rischio attraverso l’attuazione
di una rete di responsabilità (Responsabile,
Referente, Attuatore) che raggiunge ogni singolo
manager.
Un tale modello di funzionamento organizzativo
costituisce un riferimento fondamentale
per realizzare concretamente, in linea con
gli indirizzi strategici dell’Ente/Organizzazione,
i processi della gestione del rischio e della
sicurezza.
É nella speranza di contribuire ad aumentare
la sensibilità degli stakeholders verso la componente
organizzativa del rischio e della sicurezza
che questo articolo è stato scritto.
Giorgio Tonelli
Senior Partner Ambrosetti
Membro del Comitato tecnico nazionale
per la sicurezza informatica e delle
telecomunicazioni nelle pubbliche amministrazioni
Isabella Marra
Consultant Ambrosetti
73

L’Organismo di certificazione della sicurezza di sistemi e prodotti ICT
I riferimenti normativi
Il DPCM 30 ottobre 2003,
pubblicato sulla Gazzetta
Carmelo Basso Ufficiale n.98 del 27 aprile
2004 e adottato dal Ministro per
l’Innovazione e le Tecnologie di concerto con i
Ministri delle Comunicazioni, delle Attività
Produttive e dell’Economia e delle Finanze,
definisce lo Schema nazionale per la valutazione
e certificazione della sicurezza di sistemi e
prodotti nel settore della tecnologia dell’informazione.
Tale Schema si affianca a quello creato
nel 1995 per consentire la certificazione di
sicurezza di sistemi e prodotti che trattano
informazioni classificate, ossia rilevanti ai fini
della sicurezza nazionale (ad esempio informazioni
in ambienti militari). Per quanto riguarda
quest’ultimo Schema, il ruolo centrale di Organismo
di Certificazione è svolto dall’Autorità
Nazionale per la Sicurezza (ANS). Nel caso
del nuovo Schema, che sarà utilizzabile in
ambito commerciale, ossia per la certificazione
di tutti i sistemi e prodotti ICT ai quali non si
debbano applicare le normative relative alla sicurezza
nazionale, l’Organismo di Certificazione
è invece l’Istituto Superiore delle Comunicazioni
e delle Tecnologie dell’informazione (I-
SCTI), al quale è stata riconosciuta l’esperienza
maturata come Centro di Valutazione
(Ce.Va.) autorizzato dall’ANS ad operare nell’ambito
dello Schema coordinato da tale Autorità.
Molti altri paesi in Europa e nell’America
del nord hanno intrapreso iniziative similari, istituendo
i propri Organismi di Certificazione
nazionali e raccogliendo in questi anni una
mole considerevole di attività di certificazione
in entrambi i settori, sia quello relativo alle
informazioni classificate sia quello commerciale.
74
L’Organismo di certificazione
della sicurezza di sistemi e
prodotti ICT
La natura marcatamente tecnica dell’attività
degli Organismi di Certificazione della sicurezza
degli apparati ICT ben si adatta alle caratteristiche
di un’organizzazione come l’ISCTI,
nonché della Fondazione Ugo Bordoni che anche
in questo delicato settore collabora con l’Istituto.
In effetti, a differenza di quanto avviene
in altri contesti, l’Organismo di certificazione
non svolge solo un ruolo iniziale di accreditamento
dei laboratori che eseguono le verifiche
in accordo a predefiniti standard (nel caso
in esame i cosiddetti Laboratori per la Valutazione
della Sicurezza, indicati nel seguito anche
con l’acronimo LVS), ma opera attivamente
durante ogni singolo processo di certificazione,
verificando che le azioni dei laboratori
risultino conformi sia alle regole precisate nello
Schema nazionale di riferimento, sia agli
standard, e alle relative metodologie, riconosciuti
a livello mondiale. Tali standard, denominati
rispettivamente Common Criteria
[ISO1,2,3,CEM1,2] e ITSEC [ITS1,2], costituiscono
oramai dei riferimenti stabili e collaudati
per la conduzione di un processo di valutazione
e certificazione. In particolare, i criteri
ITSEC costituiscono il riferimento tecnico europeo
sin dal 1991, anche in virtù di una raccomandazione
del 1995 del Consiglio dell’Unione
Europea, mentre i Common Criteria adottati
dall’ISO nel 1999 rappresentano i criteri
di riferimento a livello mondiale e sono stati
formalmente accettati dall’Unione Europea
con una risoluzione del 2002. L’esigenza di
rendere gli standard applicabili ad un insieme
di sistemi/prodotti ICT il più ampio possibile
ha portato a non poter definire in modo completo
e particolareggiato tutte le azioni che devono
essere compiute dagli LVS ed ha reso
quindi assolutamente necessario un indirizzamento
tecnico da parte dell’Organismo di certificazione
che garantisca una uniforme appli-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
cazione degli standard all’interno dello Schema
nazionale. Tale indirizzamento, peraltro, è
necessario che sia coerente con quelli che vengono
forniti negli altri paesi dotati di analoghi
Schemi nazionali, al fine di estendere ulteriormente
l’uniformità di applicazione degli standard
e consentire il mutuo riconoscimento dei
certificati su scala internazionale.
Nel seguito vengono descritte le norme
principali che regolano il funzionamento dello
Schema Nazionale in generale e dell’Organismo
di Certificazione in particolare.
Lo Schema nazionale
All’interno dello Schema nazionale vengono
definite tutte le procedure e le regole necessarie
per la valutazione e la certificazione della
sicurezza ICT, in conformità ai criteri europei
ITSEC o ai Common Criteria.
Le procedure relative allo Schema nazionale
devono essere osservate dall’Organismo di
Certificazione, dai Laboratori per la Valutazione
della Sicurezza, nonché da tutti coloro
(persone fisiche, giuridiche e qualsiasi altro
organismo o associazione) cui competono le
decisioni in ordine alla richiesta, acquisizione,
progettazione, realizzazione, installazione ed
impiego di sistemi e prodotti nel settore della
tecnologia dell’informazione che necessitano
di una certificazione di sicurezza conforme agli
standard internazionali specificati precedentemente.
L’Organismo di Certificazione determina la
linea di condotta per l’accreditamento dei Laboratori
per la Valutazione della Sicurezza.
L’accreditamento degli LVS è l’atto con cui
l’Organismo di Certificazione riconosce formalmente
l’indipendenza, l’affidabilità e la
competenza tecnica di un Laboratorio per la
Valutazione della Sicurezza.
L’utilità primaria della valutazione/certificazione
della Sicurezza di un sistema/prodotto/PP
(Profilo di Protezione) secondo le regole dello
Schema è quella di fornire una stima del livello
di sicurezza secondo standard condivisi da tutti i
soggetti coinvolti e di garantire che tale stima
venga eseguita da una terza parte indipendente
rispetto ai soggetti stessi.
Giugno 2004
Lo Schema riconosce gli accordi internazionali
sull’interpretazione delle norme dei suddetti
standard.
Organizzazione e ruoli
I soggetti coinvolti nel processo di valutazione
e certificazione della sicurezza all’interno
dello Schema nazionale sono:
l’Organismo di Certificazione
la Commissione di Garanzia
il Laboratorio per la Valutazione della Sicurezza;
il Committente;
il Fornitore;
l’Assistente.
L’Organismo di Certificazione
L’ISCTI del Ministero delle comunicazioni è
l’Organismo di Certificazione della sicurezza
nel settore della tecnologia dell’informazione.
L’Organismo di Certificazione sovrintende
alle attività operative di valutazione e certificazione
nell’ambito dello Schema nazionale attraverso:
– la predisposizione di regole tecniche in materia
di certificazione sulla base delle norme
e direttive nazionali, comunitarie ed internazionali
di riferimento;
– il coordinamento delle attività nell’ambito
dello Schema nazionale in armonia con i criteri
ed i metodi di valutazione;
– la predisposizione delle Linee Guida per la
valutazione di prodotti, traguardi di sicurezza,
profili di protezione e sistemi, ai fini del
funzionamento dello Schema;
– la divulgazione dei princìpi e delle procedure
relative allo Schema nazionale;
– l’accreditamento, la sospensione e la revoca
dell’accreditamento degli LVS;
– la verifica del mantenimento dell’indipendenza,
imparzialità, affidabilità, competenze
tecniche e capacità operative da parte degli
LVS accreditati;
– l’approvazione dei Piani di Valutazione;
– l’ammissione e l’iscrizione delle valutazioni;
– l’approvazione dei Rapporti Finali di Valutazione;
75

76
L’Organismo di certificazione della sicurezza di sistemi e prodotti ICT
– l’emissione dei Rapporti di Certificazione
sulla base delle valutazioni eseguite dagli
LVS;
– l’emissione e la revoca dei Certificati;
– la definizione, l’aggiornamento e la diffusione,
almeno su base semestrale, di una lista di
prodotti, sistemi e profili di protezione certificati
e in corso di certificazione;
– la predisposizione, la tenuta e l’aggiornamento
dell’elenco degli LVS accreditati;
– la promozione delle attività per la diffusione
della cultura della sicurezza nel settore della
tecnologia dell’informazione;
– la formazione, abilitazione e addestramento
dei Certificatori, personale dipendente dell’Organismo
di Certificazione, nonché dei
Valutatori, dipendenti degli LVS e Assistenti,
ai fini dello svolgimento delle attività di
valutazione;
–la predisposizione, tenuta e aggiornamento
dell’elenco dei Certificatori, Valutatori e Assistenti.
L’Organismo di Certificazione riferisce semestralmente
sull’attività al Dipartimento per
l’Innovazione e le Tecnologie (DIT) della Presidenza
del Consiglio dei Ministri.
Sulla base degli indirizzi stabiliti dal Presidente
del Consiglio dei Ministri o, per sua
delega, dal Ministro per l’Innovazione e le
Tecnologie e dal Ministro delle Comunicazioni,
l’Organismo di Certificazione cura i
rapporti con Organismi di Certificazione esteri
congiuntamente con l’Autorità Nazionale
di Sicurezza, nonché partecipa alle altre
attività in ambito internazionale e comunitario
riguardanti il mutuo riconoscimento dei
Certificati.
Inoltre, l’Organismo di Certificazione comunica
agli LVS qualsiasi cambiamento significativo
introdotto nello Schema nazionale che
possa influenzare i termini, le condizioni e la
durata dell’attività di valutazione.
All’interno dell’Organismo di Certificazione
opera il Certificatore che è addestrato e abilitato
dall’Organismo stesso per condurre le attività
di certificazione.
Ogni controversia inerente alle attività svolte
all’interno dello Schema nazionale deve es-
sere riferita, da qualsiasi soggetto coinvolto
nello Schema nazionale, all’Organismo di Certificazione.
Nel caso in cui nella controversia
sia coinvolto anche l’Organismo di Certificazione,
o quest’ultimo non sia riuscito a dirimerla,
la controversia deve essere riferita alla
Commissione di Garanzia.
Gli altri soggetti dello Schema nazionale
La Commissione di Garanzia 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. La Commissione
di Garanzia è presieduta da un rappresentante
del Dipartimento per l’Innovazione
e le Tecnologie della Presidenza del
Consiglio dei Ministri.
I Laboratori per la Valutazione della Sicurezza
sono accreditati dall’Organismo di Certificazione
ed effettuano le valutazioni di sistemi o prodotti
ICT (denominati anche Oggetti Della Valutazione,
o più brevemente ODV) o di Profili
di Protezione (documenti che consentono di
definire i requisiti di sicurezza da associare ad
una prefissata categoria di prodotti ICT) secondo
lo Schema nazionale e sotto il controllo dell’Organismo
di Certificazione medesimo.
Ai fini dell’accreditamento, l’LVS deve possedere
i seguenti requisiti:
– 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;
– disponibilità di personale dotato delle necessarie
competenze tecniche;
– 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.
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
L’LVS deve garantire la massima riservatezza
su tutte le informazioni acquisite relative all’Oggetto
della Valutazione. A tal fine il Committente
può chiedere la sottoscrizione di un
documento nel quale l’LVS si impegna a mantenere
la riservatezza su informazioni tecniche
acquisite durante le attività di valutazione.
Il Committente è la persona fisica, giuridica
o qualsiasi altro organismo che commissiona la
valutazione.
Il Committente può anche rivestire il ruolo
di Fornitore.
Il Committente sceglie il Laboratorio di Valutazione
della Sicurezza e stipula con lo stesso
il contratto per la valutazione. Il Committente
è responsabile della fornitura all’LVS del Traguardo
di Sicurezza, dell’Oggetto della Valutazione
e di tutto il Materiale per la Valutazione
richiesto nel Piano di Valutazione prodotto
dall’LVS ed approvato dall’Organismo di Certificazione.
Il Fornitore è la persona fisica, giuridica o
qualsiasi altro organismo che fornisce l’ODV o
parti componenti dell’ODV. Il Fornitore può
anche rivestire il ruolo di Committente della
valutazione.
L’Assistente è una persona formata, addestrata
e abilitata dall’Organismo di Certificazione
per fornire supporto tecnico al Committente
o al Fornitore che ne faccia richiesta. All’Assistente
può essere richiesta, tra l’altro,
un’analisi del Traguardo di Sicurezza o del
Profilo di Protezione al fine di accertare, sulla
base anche di eventuale ulteriore documentazione
richiesta al Committente, che lo stesso
Giugno 2004
costituisca una solida base per la conduzione
del processo di valutazione. A tal fine, l’Assistente,
in ragione delle informazioni di cui dispone,
verifica l’assenza di elementi che possano
pregiudicare il buon esito della valutazione.
Inoltre, l’Assistente può curare il processo di
gestione del Certificato che viene attivato se il
Committente decide di voler mantenere aggiornato
nel tempo il Certificato.
Carmelo Basso
Direttore dell’Istituto Superiore delle Comunicazioni
e delle Tecnologie dell’Informazione (ISCTI)
Direttore dell'Organismo di Certificazione
Riferimenti bibliografici
[CEM1] Common Evaluation Methodology for Information
Technology Security Evaluation, Part 1 – Introduction
and general model; version 0.6, CEM-
97/017, gennaio 1997
[CEM2] Common Evaluation Methodology for Information
Technology Security Evaluation, Part 2 – Evaluation
Methodology, version 1.0, CEM-
99/045, ottobre 2003
[ISO1] Common Criteria for Information Technology Security
Evaluation, Part 1 – Introduction and general
model, version 2.1, CCIMB-99-031, ottobre 2003
[ISO2] Common Criteria for Information Technology
Security Evaluation, Part 2 – Security functional
requirements, version 2.1, CCIMB-99-032, ottobre
2003
[ISO3] Common Criteria for Information Technology Security
Evaluation, Part 3 – Security assurance requirements,
version 2.1, CCIMB-99-033, ottobre 2003
[ITS1] Information Technology Security Evaluation Criteria,
version 1.2, giugno 1991
[ITS2] Information Technology Security Evaluation Manual,
version 1.0, settembre 1993
77

Il processo di certificazione della sicurezza informatica
Il processo di certificazione
della sicurezza informatica
comprende tutte le attività
che vengono svolte durante la
valutazione e certificazione di
un sistema/prodotto o anche,
Giuseppe Pierri nel caso di utilizzazione dello
standard ISO/IEC IS 15408
(Common Criteria), di particolari documenti
denominati Profili di protezione (Protection
Profile). In particolare, all’interno del processo
di certificazione si individuano il processo
di valutazione, articolato in tre fasi distinte,
e la fase di certificazione. In questo
lavoro vengono descritte analiticamente le
suddette fasi allo scopo di fornire tutte le
informazioni fondamentali attinenti alla
preparazione conduzione e conclusione di
una valutazione, nonché le azioni che vengono
attuate nella fase di certificazione, azioni
che si concludono con l’emissione del
Rapporto di Certificazione e del relativo
Certificato.
78
Il processo di Certificazione
Definizioni generali
Il processo di certificazione
della sicurezza informatica
Nel seguito è riportato un elenco essenziale
di definizioni necessarie per la comprensione
dei paragrafi successivi.
L’Oggetto della Valutazione (ODV) costituisce
il sistema o prodotto sottoposto alla
valutazione.
Il Traguardo di Sicurezza (TDS) è il documento
che specifica le funzioni di sicurezza
che l’Oggetto della Valutazione dovrebbe svolgere,
l’ambiente operativo in cui l’ODV è destinato
ad operare e il livello di garanzia al quale
l’ODV viene valutato.
Il Profilo di Protezione (PP) è il documento
che descrive per una certa categoria di ODV
ed in modo indipendente dalla realizzazione,
gli obiettivi di sicurezza, le minacce, l’ambiente
ed i requisiti funzionali e di garanzia, definiti
secondo i Common Criteria.
Il Piano di Valutazione (PDV) è il documento
che descrive le attività che saranno svolte
dal Laboratorio per la Valutazione della Sicurezza
(LVS) durante il processo di valutazione,
i tempi di esecuzione e le risorse necessarie.
Finalità e requisiti
Il processo di certificazione è finalizzato
all’emissione di un rapporto in cui viene dichiarato
se:
– il Profilo di Protezione è completo, congruente
e tecnicamente corretto;
– il Traguardo di Sicurezza è completo, congruente,
tecnicamente corretto ed adatto ad
essere usato come base per la valutazione
del corrispondente ODV,
– l’Oggetto della Valutazione soddisfa il Traguardo
di Sicurezza al livello di garanzia richiesto.
Il processo di valutazione e certificazione deve
seguire i seguenti quattro principi generali:
– imparzialità: la valutazione deve essere condotta
senza pregiudizi e, in particolare, deve
essere possibile dimostrare che l’LVS e i Valutatori
coinvolti non abbiano interessi commerciali
o finanziari dipendenti dall’esito
della valutazione stessa;
– obiettività: le conclusioni del processo di valutazione
devono essere motivate da evidenze
sperimentali ogni qual volta sia possibile,
in modo da limitare il più possibile opinioni
e valutazioni soggettive;
– ripetibilità: la valutazione dello stesso sistema/prodotto/PP
effettuata con gli stessi re-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
quisiti di sicurezza e dallo stesso LVS deve
portare agli stessi risultati;
– riproducibilità: la valutazione dello stesso sistema/prodotto
effettuata con gli stessi requisiti
di sicurezza da un diverso LVS deve
portare agli stessi risultati.
Gli LVS devono garantire, mediante l’adozione
di specifiche misure, elevati livelli di
confidenzialità al fine di garantire la riservatezza
di informazioni tecnicamente e commercialmente
rilevanti riguardanti l’ODV e che, se
diffuse, potrebbero creare un danno al proprietario
dell’ODV stesso.
La certificazione stabilisce che la valutazione
è stata condotta conformemente ai criteri
necessari a verificare il soddisfacimento del livello
di garanzia, della robustezza dei meccanismi
o delle funzioni di sicurezza dichiarati e
conseguentemente garantisce i risultati della
valutazione stessa.
L’Organismo di Certificazione, l’LVS e il
Committente devono rispettivamente designare
un responsabile per ogni valutazione.
Il processo di certificazione si suddivide in
quattro fasi. Le prime tre fasi identificano il
processo di valutazione, l’ultima la fase di certificazione.
Il processo di valutazione è, quindi, articolato
in:
preparazione;
conduzione;
conclusione.
Nella quarta e ultima fase, quella di certificazione,
l’Organismo di Certificazione esamina
il Rapporto Finale di Valutazione (RFV) e
lo utilizza come base per la produzione del
Rapporto di Certificazione e dell’eventuale
Certificato, concludendo con questo atto il
processo di certificazione.
Nei paragrafi che seguono ciascuna delle 4
fasi identificate viene descritta in dettaglio.
Fase di preparazione
Le attività di preparazione della valutazione
sono svolte dall’LVS e dal Committente.
Giugno 2004
Il Committente chiede l’intervento dell’LVS,
specificando il Traguardo di Sicurezza o il Profilo
di Protezione richiesto.
Il Committente potrà ottenere dall’LVS
l’indicazione del costo delle attività di valutazione.
Analoga indicazione potrà essere ottenuta
dall’Organismo di Certificazione per quanto
riguarda l’attività di certificazione.
Si consiglia il Committente affinché:
– tenga conto della necessità di ottenere collaborazione
dal Fornitore per quanto riguarda
le informazioni tecniche e la documentazione
richieste per la valutazione;
– qualora l’ODV contenga componenti già
certificati, si predisponga per reperire i documenti
più rilevanti del processo di certificazione,
in particolare, il Traguardo di Sicurezza
e il Rapporto di Certificazione;
– tenga nella dovuta considerazione i costi per
il mantenimento del Certificato nel tempo,
quando previsto;
–ottenga la disponibilità dei risultati dalla valutazione,
in modo da poterli riutilizzare in
eventuali future attività di valutazione, certificazione
e mantenimento.
L’obiettivo della fase della preparazione è
quello di stimare l’adeguatezza dell’ODV o del
PP per la valutazione, prima dell’inizio della
fase di conduzione.
Questo processo è basato sui seguenti elementi:
–individuazione del TDS;
– determinazione della documentazione necessaria
per sostenere la valutazione;
accordo su un PDV;
– determinazione dello scopo della valutazione
e analisi delle responsabilità per assicurare
che tutte le parti in causa siano consapevoli
dei loro compiti;
– accettazione formale dei requisiti previsti
dallo Schema per la valutazione.
Al Committente è richiesto di fornire il Traguardo
di Sicurezza e gli ulteriori documenti
che è necessario sviluppare ai fini della valutazione/certificazione.
L’LVS esamina il Traguardo
di Sicurezza o il Profilo di Protezione al fi-
79

80
Il processo di certificazione della sicurezza informatica
ne di accertare, sulla base anche di eventuale
ulteriore documentazione richiesta al Committente,
che IL TDS o PP costituisca una solida
base per la conduzione del processo di valutazione;
ove necessario richiede modifiche.
Il Materiale per la Valutazione necessario al Valutatore
per condurre la valutazione comprende:
– gli elementi hardware, firmware o software
che costituiscono l’ODV stesso;
– la documentazione per l’utente dell’ODV;
– la documentazione tecnica di supporto, generata
o durante lo sviluppo dell’ODV o per
sostenere il processo di valutazione.
Per la produzione di tutti i tipi di documentazione
relativi alla valutazione e certificazione
è obbligatorio l’uso della lingua italiana, con
deroghe unicamente concesse a:
– eventuali terminologie in lingua inglese, non
tradotte nel glossario di riferimento dello
Schema, che siano utilizzate nei documenti
originali che descrivono i criteri e le metodologie
– documenti di valutazione e certificazione già
esistenti in lingua inglese.
Il Piano di Valutazione, che è preparato dall’LVS,
specifica il lavoro che deve essere condotto
dall’LVS stesso durante la valutazione.
Tale piano indirizza tutti gli aspetti che riguardano
l’applicazione dei criteri e delle metodologie
per la valutazione dell’ODV, fornendo
inoltre tutte le scadenze temporali connesse
con l’attività di valutazione proposta.
L’LVS chiede formalmente all’Organismo di
Certificazione l’iscrizione della valutazione
nello Schema, fornendo il Piano di Valutazione
predisposto. Contestualmente, il Committente,
in modo diretto o attraverso l’LVS, documenta
l’avvenuto pagamento dell’onere finanziario
legato alle prestazioni dell’Organismo di
Certificazione per l’analisi del PDV.
La valutazione sarà accettata formalmente se
sussistono tutte le seguenti condizioni:
– l’Organismo di Certificazione avrà ritenuto
adeguato che l’ODV o il PP venga valutato e
certificato nell’ambito dello Schema;
– l’Organismo di Certificazione avrà ritenuto
adeguati il Traguardo di Sicurezza e il PDV
presentati;
– il Committente avrà accettato di sostenere
l’onere finanziario legato alle prestazioni
dell’Organismo di Certificazione per le attività
di certificazione.
L’Organismo di Certificazione comunica
formalmente all’LVS l’esito della richiesta di iscrizione
allo Schema, motivando adeguatamente
l’eventuale esito negativo e conferma gli
oneri dovuti all’OC per le fasi successive della
certificazione. Tale comunicazione conclude la
fase di preparazione della valutazione.
Successivamente alla comunicazione dell’esito
della richiesta di iscrizione allo Schema
l’LVS coinvolto notifica formalmente all’Organismo
di Certificazione l’effettivo inizio della
valutazione, attraverso una Notifica di Inizio
Lavori (NIL), dando così inizio alla fase di
conduzione della valutazione.
In caso di esito positivo, si terrà normalmente
una Riunione di Avvio dei Lavori (RAL) in
cui saranno coinvolti l’Organismo di Certificazione,
il Committente, l’LVS e qualsiasi altra
entità interessata, al fine di discutere qualsiasi
aspetto che sia attinente alla valutazione, alla
certificazione e alle specifiche dell’ODV. Tale
riunione sarà convocata dall’OC di sua iniziativa
o su richiesta dell’LVS o del Committente,
prima dell’inizio della effettiva fase di conduzione
della valutazione.
Fase di conduzione
I Valutatori effettuano l’attività di conduzione
della valutazione tecnica seguendo le
modalità dettagliate nel Piano di Valutazione.
Questa attività implica la valutazione imparziale
e dettagliata dell’ODV in accordo con i
criteri di valutazione, al fine di determinare in
che misura l’ODV realizzi il Traguardo di Sicurezza
e di identificare eventuali vulnerabilità
sfruttabili.
Se nel corso del lavoro di valutazione vengono
rilevati incongruenze, errori o vulnerabilità,
devono essere prodotti dei Rapporti di Osservazione
che li descrivano in dettaglio. Al termi-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
ne di ogni attività, l’LVS predispone dei Rapporti
di Attività che riassumono i risultati delle
analisi condotte per la specifica attività.
I risultati del lavoro di valutazione devono
essere documentati in modo continuativo al
procedere della valutazione stessa.
L’Organismo di Certificazione controlla ogni
valutazione, al fine di confermare che esse
siano effettuate in accordo con i criteri, i
metodi e le procedure previste dallo Schema.
Durante la fase di conduzione l’Organismo
di Certificazione è coinvolto nelle seguenti
attività:
– se necessario, partecipa agli incontri sull’avanzamento
della valutazione;
– se necessario, concorda con l’LVS il modo in
cui devono essere applicati i criteri per la valutazione
di uno specifico ODV o PP;
– controlla i rapporti tecnici prodotti dai Valutatori
durante il corso delle valutazioni;
controlla i documenti di valutazione.
LVS e il Committente richiedono l’intervento
dell’Organismo di Certificazione al verificarsi
di problemi per i quali è non è stato
possibile individuare una soluzione o laddove
sia necessaria una interpretazione dei criteri o
delle metodologie. Se non è possibile risolvere
il problema e l’LVS decide che questa circostanza
influisce negativamente sulla valutazione,
l’LVS notifica formalmente il fatto al
Committente.
Fase di conclusione: il Rapporto
Finale di Valutazione
I Valutatori documentano la loro attività all’Organismo
di Certificazione attraverso il
Rapporto Finale di Valutazione, che rappresenta
il documento conclusivo del processo di
valutazione e che raccoglie tutti i Rapporti di
Attività e le considerazioni sulla valutazione
svolta. Le conclusioni documentate nel Rapporto
Finale di Valutazione dimostrano e descrivono
il grado con cui i criteri di valutazione
sono stati soddisfatti.
L’LVS rilascia il Rapporto Finale di Valutazione
al Committente dopo aver verificato che
non contenga informazioni proprietarie.
Giugno 2004
Fase di certificazione
La fase di certificazione ha come obiettivo
l’emissione da parte dell’OC del Rapporto di
Certificazione (RC) e dell’eventuale Certificato.
A tal fine, l’Organismo di Certificazione esamina
il Rapporto Finale di Valutazione e,
qualora riscontri la coerenza con i criteri, la
metodologia ed i requisiti dello Schema, lo approva.
Nel caso in cui vengano individuate
delle anomalie risolvibili, l’Organismo di Certificazione
richiede l’intervento del Laboratorio
di Valutazione della Sicurezza per l’eventuale
perfezionamento del Rapporto Finale di
Valutazione.
Il Rapporto di Certificazione deve:
–dichiarare se la valutazione è stata condotta
secondo i criteri e la metodologia prevista
dallo Schema nazionale;
– dichiarare se il Profilo di Protezione è completo,
congruente e tecnicamente corretto;
– dichiarare se il Traguardo di Sicurezza è
completo, congruente e tecnicamente corretto;
– dichiarare se l’Oggetto della Valutazione
soddisfa il Traguardo di Sicurezza al livello
di garanzia richiesto;
– identificare le eventuali vulnerabilità sfruttabili
ed eventualmente raccomandare delle
contromisure;
–motivare l’eventuale emissione di verdetti in
contrasto con quelli dell’LVS.
Nel caso in cui nell’RFV si evidenzino delle
vulnerabilità sfruttabili, il processo di certificazione
non potrà essere completato con l’emissione
del Certificato.
La versione definitiva del Rapporto di Certificazione
e il Certificato vengono emessi dall’Organismo
di Certificazione.
La certificazione si riferisce solo agli aspetti
di sicurezza sottoposti a valutazione:
questo implica il permanere di una probabilità
non nulla che in un ODV certificato
esistano alcune vulnerabilità sfruttabili non
individuate perché al di fuori degli aspetti
di sicurezza sottoposti a valutazione e certificazione.
81

ITSEC: i criteri europei per la valutazione della sicurezza informatica
I risultati del processo di valutazione e certificazione
sono riferibili a una specifica e determinata
configurazione dell’Oggetto della Valutazione:
pertanto la commercializzazione di un sistema/prodotto
certificato è vincolata a tale configurazione.
Al fine di espletare in modo adeguato
la funzione di controllo della validità dei Certificati
nel tempo, l’OC svolge una costante atti-
Mentre il Dipartimento
della Difesa
degli Stati Uniti utilizzava
propri criteri per la
valutazione della sicurezza
Giovanni Desirò
dei sistemi e prodotti IT intitolati
Trusted Computer System
Evaluation Criteria [TCSEC] e, comunemente,
nota come Orange Book (Libro arancione),
altri paesi europei hanno elaborato
propri criteri per la valutazione della sicurezza
dei prodotti IT. Nel Regno Unito, a esempio,
è il caso del Memorandum Number 3, elaborato
a uso del governo, e delle proposte
del Dipartimento dell’Industria e Commercio,
denominate Green Book (Libro Verde).
In Germania, l’Ente per la sicurezza dell’informazione
ha pubblicato, nel 1989, una
prima versione dei propri criteri; allo stesso
tempo, in Francia, sono stati elaborati criteri
denominati Livre bleu-blanc-rouge (Libro
bianco, rosso e blu).
In seguito la Francia, la Germania, i Paesi
Bassi e il Regno Unito hanno riconosciuto la
necessità di accostarsi al problema in modo armonizzato
e di definire criteri di sicurezza IT
comuni in quanto i singoli paesi avevano accumulato
una vasta esperienza, su cui sarebbe
stato assai vantaggioso fondare gli ulteriori svi-
82
vità di monitoraggio, mantenendo sempre aggiornata
la lista delle vulnerabilità sfruttabili.
Giuseppe Pierri
Dirigente Ufficio Informatica e Telematica
Ministero delle Comunicazioni - Istituto Superiore delle
Comunicazioni e delle Tecnologie dell’Informazione
Presidente del Comitato di Pianificazione e
Controllo dell’Organismo di Certificazione
ITSEC: i criteri europei per
la valutazione della sicurezza
informatica
luppi; le industrie erano contrarie all’adozione
di criteri di sicurezza diversi in ogni paese; i
concetti e gli approcci di base adottati dai vari
paesi coincidevano, anche per quanto riguarda
le varie applicazioni in ambito commerciale,
governativo e militare. Uno dei motivi, quindi,
dell’elaborazione di questi criteri comuni, che
sono stati denominati Information Technology
Security Evaluation Criteria (ITSEC), è stato
la volontà di costituire una base comune per
l’attività di certificazione svolta dagli organismi
nazionali, con l’obiettivo finale di consentire
il mutuo riconoscimento dei risultati delle
valutazioni.
Nel 1991 si è giunti ad una completa definizione
dei criteri ITSEC che sono stati nello
stesso anno fatti propri dalla Comunità
Europea.
Ogni sistema o prodotto IT presenta requisiti
specifici, che ne garantiscono la riservatezza,
l’integrità e la disponibilità.
Per soddisfare tali requisiti occorre implementare
diverse misure tecniche di sicurezza,
denominate funzioni di sicurezza riguardanti,
a esempio, settori quali il controllo di accesso,
l’audit e il recupero da errore. Per IT-
SEC, l’oggetto della valutazione è il TOE
(Target of Evaluation) e lo sponsor è chi richiede
la valutazione.
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
La valutazione viene fatta prendendo a riferimento
il security target che è un documento
che deve contenere almeno: una System
Security Policy (nel caso dei sistemi) o
un Product Rationale (nel caso dei prodotti);
una specifica delle funzioni di sicurezza (Security
Enforcing Functions o SEF) che permettono
il conseguimento degli obiettivi individuati;
la definizione dei meccanismi di sicurezza
richiesti (opzionale); il livello minimo
dichiarato di robustezza dei meccanismi
(strength of mechanisms); il livello di valutazione
desiderato.
Col termine SEF (Security Enforcing Function),
si intendono le contromisure raggruppate
secondo un certo numero di categorie, dette
Generic Headings.
La valutazione si basa sul concetto di garanzia
(assurance) offerta dal sistema stesso che si
caratterizza per: la correttezza (correctness)
nel modo di concretizzare le funzioni di sicurezza
e dei relativi meccanismi d’attuazione
(mechanisms); la fiducia nella loro efficacia
(effectiveness).
Le funzioni di sicurezza sono le contromisure
di cui, in sede di redazione degli obiettivi di
sicurezza (Security Target), si decide l’adozione
e descrivono le contromisure in chiave concettuale
con orientamento alla loro funzionalità.
Possono essere rappresentate sia da prodotti
che da procedure di carattere organizzativo
ed operativo. Le singole funzioni di sicurezza
vengano raggruppate, in generic headings.
ITSEC prospetta otto tipologie di funzioni
di sicurezza (generic headings) che comunque
possono essere integrate da nuove tipologie,
con l’evoluzione delle tecnologie e
delle tipologie d’attacco.Le tipologie indicate
da ITSEC sono:
Identificazione ed Autentificazione (Identification
and Authentication)
Stabiliscono e verificano l’identità che dichiara
un utente che intende accedere al sistema
informatico. L’identificazione avviene usualmente
controllando la corrispondenza tra
le informazioni fornite dall’utente e le informazioni
associate all’utente e note al sistema di
protezione.
Giugno 2004
Controllo degli accessi (Access Control)
Garantiscono che un utente possa espletare
le sole operazioni di propria competenza.
A questo gruppo appartengono le funzioni il
cui scopo è controllare il flusso delle informazioni
fra processi e l’uso delle risorse da parte
dei processi stessi.
Autorizzazioni (Accountability)
Registrano gli accessi alle varie risorse del sistema.
A questo gruppo appartengono tutte le
funzioni che hanno lo scopo di lasciare traccia
delle azioni dei suoi utenti, in modo da riconoscere
chi ha operato.
Ispezioni (Audit)
Permettono di indagare sugli eventi anomali
o sopra determinati livelli che possono rappresentare
una minaccia alla sicurezza. A questo
gruppo appartengono le funzioni che hanno lo
scopo di registrare ed analizzare gli eventi, oppure
le funzioni che effettuano analisi statistiche
al fine di individuare eventuali attacchi alla
sicurezza.
Riutilizzo (Object Reuse)
Garantiscono il riutilizzo di spazi di memoria,
impedendo che ciò costituisca minaccia alla
sicurezza. A questo gruppo appartengono le
funzioni il cui scopo è quello di cancellare o inizializzare
i supporti in modo che possano essere
riutilizzabili
Accuratezza (Accuracy)
Garantiscono l’integrità del SW e dei dati. A
questo gruppo appartengono le funzioni il cui
scopo è quello di effettuare analisi del SW e
dei dati per segnalare, identificare e correggere
eventuali violazioni
Ripristino del servizio (Reliability of Service)
A questo gruppo appartengono le funzioni il
cui scopo è quello di assicurare che le risorse siano
accessibili ed utilizzabili su richiesta di qualunque
utente abilitato, entro i tempi prefissati
Scambio di dati (Data Exchange)
A questo gruppo appartengono le funzioni
il cui scopo è quello di assicurare disponi-
83

84
ITSEC: i criteri europei per la valutazione della sicurezza informatica
bilità, riservatezza ed integrità ai canali trasmissivi.
Con il termine Assurance si intende sia la fiducia
(confidence) nell’efficacia (effectiveness)
delle funzioni di sicurezza, sia la fiducia nella
loro correttezza (correctness).
La valutazione dell’efficacia mira a stabilire,
tra l’altro, se le funzioni di sicurezza adottate
sono idonee agli scopi -specificati nel Security
Target- per cui sono state scelte e se i meccanismi
che realizzano tali funzioni sono in grado
di contrastare attacchi diretti.
Quest’ultimo aspetto viene misurato sulla
base della cosiddetta “robustezza dei meccanismi”
(strenght of mechanisms) per la quale sono
stati definiti tre livelli: Base, Medio e Alto.
La fiducia nella correttezza viene espressa utilizzando
una scala a sette livelli (da E0 ad E6)
nella quale il livello più basso indica totale
mancanza di fiducia.
Il processo di valutazione ai fini di una certificazione
del sistema stesso consisterà nello
stabilire se esso soddisfa o meno il suo Security
Target con il livello di valutazione dichiarato
del committente (ITSEC lo definisce Sponsor)
e indicato nel Security Target stesso.
ITSEC definisce la robustezza dei meccanismi
di sicurezza (Strenght of Mechanism -
SOM) come la loro capacità di resistere ad un
attacco diretto.
Vengono definiti tre possibili gradi di robustezza
(Base, Medio e Alto) che rappresentano
crescenti livelli di capacità del meccanismo di
sicurezza di resistere ad un attacco diretto.
Nel rispetto di quanto contenuto in ITSEC
la robustezza, di un meccanismo di sicurezza
critico può essere definita come:
BASE se al minimo fornisce protezione contro
eventi sovversivi casuali, benché possa essere
violata da alcuni aggressori;
MEDIA se al minimo fornisce protezione
contro aggressioni caratterizzate da limitate
opportunità o risorse;
ALTA se può essere superata solo da aggressioni
caratterizzate da un alto livello di esperienza,
opportunità e risorse, con attacchi portati con
successo al di sopra della normale praticabilità.
Nel documento ITSEM (Annex 6.C) vengono
definite le modalità di determinazione del
grado di robustezza del meccanismo basate su:
tempo necessario per violare il meccanismo
(minuti, giorni, mesi);
complicità necessaria (senza complici, con
un utente, con un responsabile);
esperienza tecnica necessaria (diffusa, professionale,
esperto);
tipo di attrezzatura da utilizzare (nessuna,
apparecchiatura normale oppure speciale).
I livelli previsti variano da E0 ad E6, secondo
crescenti livelli di fiducia.
La normativa ITSEC prevede la valutazione
dell’efficacia e della correttezza del sistema di
protezione.
Al crescere del livello di valutazione desiderato,
lo sponsor deve fornire al valutatore documentazione
che attesti un crescente rigore e
l’introduzione di strumenti formali nelle varie
fasi costruttive.
Il processo di sviluppo è stato logicamente
suddiviso in quattro fasi:
La Definizione dei requisiti di sicurezza
(Requirements)
Progetto architetturale (Architectural Design)
Il Progetto dettagliato (Detailed Design)
La Realizzazione (Implementation)
Per ciascuna fase lo sponsor deve presentare
documentazione adeguata al livello di protezione
desiderato.
Al livello E1, il Security Target deve descrivere
per sommi capi il modo con cui le funzioni
di sicurezza proposte soddisfano gli obiettivi
di sicurezza e contrastano le minacce.
Al Livello E6, il Security target deve fornire
una dettagliata spiegazione (to explain) del
modo con cui le funzioni di sicurezza soddisfa-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
no gli obiettivi di sicurezza e contrastano le minacce
e della congruenza tra la politica di sicurezza
ed il modello formale di sicurezza realizzato
dal sistema di protezione.
Il progetto architetturale
Al livello E1, lo sponsor deve fornire una
descrizione informale dell’architettura generale
del sistema. Al livello E6, la descrizione deve
essere di tipo formale e deve includere una
dettagliata spiegazione che convinca della congruità
tra la politica di sicurezza e l’architettura
del sistema.
Il progetto dettagliato
Al livello E1, lo sponsor non deve fornire alcuna
informazione, mentre ai livelli successivi
la documentazione deve essere costituita da un
dettagliato progetto del sistema (il livello di
dettaglio deve essere tale da poter essere utilizzato
come base per la programmazione e costruzione
dello hardware. Più precisamente, al
L’istituzione dello Schema Nazionale
per la certificazione della sicurezza
dei sistemi e dei prodotti nel settore
della tecnologia dell’informazione (di seguito
denominato “Schema nazionale”), avvenuta
attraverso un DPCM adottato dal Ministro
per l’Innovazione e le Tecnologie di
concerto con i Ministri delle Comunicazioni,
delle Attività Produttive e dell’Economia e
delle Finanze, si pone come naturale termine
di un percorso che è stato individuato e seguito
in questi ultimi anni anche da numerosi
altri stati nazionali, sia in Europa sia nel
resto del mondo.
livello E2 è richiesta una descrizione informale,
mentre dal livello E4 in avanti, tale descrizione
deve essere di tipo semi-formale.
La Realizzazione
Al livello E1, lo sponsor non è tenuto a fornire
alcuna documentazione.
Ai livelli più elevati, lo sponsor deve fornire
una raccolta di test usati per verificare la correttezza
delle funzioni di sicurezza, e argomentare
l’adeguatezza dei test scelti. Inoltre, dal livello
E2 in avanti la documentazione fornita
deve comprovare, a crescenti livelli di approfondimento,
anche la corrispondenza tra il
progetto dettagliato e il software e lo hardware
che costituiscono il sistema di valutazione.
Giovanni Desirò
Ministero delle Comunicazioni – Istituto Superiore
delle Comunicazioni e delle Tecnologie
dell’Informazione (ISCTI)
Coordinatore Area Gestionale dell’Organismo
di certificazione
Lo Schema nazionale di
certificazione della sicurezza
informatica
Giugno 2004
In questo contesto il decreto:
– ravvisa la necessità di individuare
un Organismo di Certificazione
e di definire lo Schema
nazionale, specificando l’insie- Marco Carbonelli
me delle procedure e delle regole
nazionali necessarie per la valutazione e
certificazione, in conformità ai criteri europei
ITSEC (Information Technology Security
Evaluation Criteria) [ITS1] o agli standard
internazionali CC (Common Criteria)
[ISO1,2,3], emanati dall’ISO;
–definisce, nell’ambito dello Schema nazionale,
la ‘sicurezza nel settore della tecnologia
85

86
Lo Schema nazionale di certificazione della sicurezza informatica
dell’informazione’ come la 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.
Le motivazioni
Molte sono le motivazioni che hanno indotto
all’istituzione dello Schema nazionale in Italia
e in vari stati dell’occidente industrializzato:
vediamo di analizzare alcune di queste.
L’informazione, nell’attuale società, costituisce
un bene essenziale e si rende necessario garantirne
l’integrità, la disponibilità e la riservatezza
con misure di sicurezza che costituiscano
parte integrante di un sistema informatico.
Da tempo i produttori offrono sistemi e prodotti
dotati di funzionalità di sicurezza, per le
quali dichiarano caratteristiche e prestazioni al
fine di orientare gli utenti nella scelta delle soluzioni
più idonee a soddisfare le proprie esigenze.
In molte applicazioni caratterizzate da un elevato
grado di criticità, le predette dichiarazioni
potrebbero risultare non sufficienti, rendendo
necessaria una loro valutazione e certificazione
della sicurezza, condotte da soggetti indipendenti
e qualificati, sulla base di standard riconosciuti
a livello nazionale ed internazionale.
Le garanzie concernenti l’adeguatezza, la
qualità e l’efficacia dei dispositivi di sicurezza
di un sistema informatico possono essere fornite
solo da certificatori e valutatori indipendenti
ed imparziali.
La necessità di favorire, a livello comunitario
e internazionale, la cooperazione tra gli Organismi
di Certificazione e il mutuo riconoscimento
dei certificati di valutazione della sicurezza nel
settore della tecnologia dell’informazione.
I punti fondamentali
Accanto alle motivazioni elencate e a corollario
normativo e politico della scelta di istituire
un Organismo di Certificazione possono es-
sere schematicamente riportati i seguenti punti
fondamentali:
– la risoluzione del Consiglio dell’Unione
Europea del 6 dicembre 2001 relativa ad
un approccio comune e ad azioni specifiche
nel settore della sicurezza delle reti e
dell’informazione;
– la decisione della Commissione Europea del
6 novembre 2000 (2000/709/CE) relativa ai
criteri minimi di cui devono tener conto gli
Stati membri all’atto di designare gli organismi
di cui all’articolo 3, paragrafo 4, della
direttiva 1999/93/CE del Parlamento Europeo
e del Consiglio, relativa ad un quadro
comunitario per le firme elettroniche;
– il varo delle norme UNI CEI EN ISO/IEC
17025 concernenti i requisiti generali per la
competenza dei laboratori di prova e di taratura
e UNI CEI EN 45011 concernenti i requisiti
generali relativi agli organismi che gestiscono
sistemi di certificazione di prodotti;
– l’esistenza dei criteri ITSEC, dal giugno
1991, e ITSEM (Information Technology
Security Evaluation Manual) [ITS2], dal settembre
1993;
– la raccomandazione del Consiglio dell’Unione
Europea (95/144/CE) in data 7 aprile
1995, concernente l’applicazione dei criteri
per la valutazione della sicurezza della tecnologia
dell’informazione ITSEC;
– l’atto del Comitato di gestione dell’ISO (International
Standard Organization) che definisce
come International Standard ISO/IEC
15408 i “Common Criteria for Information
Technology Security Evaluation”.
Risulta chiaro come l’istituzione dell’Organismo
di Certificazione italiano fosse, alla luce
delle informazioni dettagliate in precedenza,
un atto non più procrastinabile, in considerazione
anche delle importanti ricadute economiche
che la presenza di tale Organismo potrà
indurre sul mercato tecnologico, sia interno sia
estero, legato ai sistemi e prodotti dotati di
funzionalità di sicurezza in ambito informatico
che si utilizzano sia nella pubblica amministrazione,
sia nelle aziende, sia di uso privato.
Il decreto riconosce che l’Istituto Superiore
delle Comunicazioni e delle Tecnologie del-
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
l’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:
“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”.
Per consentire l’applicazione dello Schema
nazionale l’Organismo di Certificazione ha
predisposto le “Linee Guida Provvisorie”
(LGP). Sarà compito dell’Organismo di Certificazione
predisporre entro 12 mesi dalla pubblicazione
del decreto (avvenuta il 26 aprile
2004), le “Linee Guida Definitive”, recanti indicazioni
dettagliate relative allo svolgimento
delle attività di valutazione e certificazione.
Le Linee Guida Provvisorie
Le Linee Guida Provvisorie sono organizzate
in documenti distinti che individuano le aree
fondamentali in cui l’Organismo di Certificazione
sarà chiamato ad agire e descrivono le
azioni che i Valutatori dovranno intraprendere
per condurre le attività di valutazione in modo
corretto (cioè coerentemente on gli standrd internazionali
adottati) ed efficace. Nel seguito
sono sinteticamente descritti i contenuti delle
Linee Guida Provvisorie.
LGP1 - Descrizione generale dello Schema
nazionale di valutazione e certificazione della
sicurezza
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 svolgere
una valutazione e certificazione di un sistema/prodotto
o Profilo di Protezione (PP).
Quindi, vengono definiti e descritti i ruoli dei
soggetti coinvolti nel processo di valutazione e
certificazione, con particolare enfasi per l’Orga-
Giugno 2004
nismo di Certificazione, il Laboratorio per la
Valutazione delle Sicurezza (LVS), 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 per la 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 LVS 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
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 PP, così come definiti
in ITSEC o nei Common Criteria, e descrivono
le modalità secondo cui effettuare:
– le comunicazioni tra un LVS, un Committente,
un Fornitore e l’OC;
– 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’OC
del Certificato.
87

88
Lo Schema nazionale di certificazione della sicurezza informatica
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 le azioni
richieste per svolgere la valutazione di un Profilo
di Protezione e la valutazione di un ODV
ai livelli di fiducia EAL1, EAL2, EAL3 e
EAL4 secondo i Common Criteria.
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 ODV 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 PP. 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;
– rendere omogenei e confrontabili i PDV
prodotti da LVS 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
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.
Concludendo, l’occasione che l’istituzione dell’Organismo
di Certificazione offre al mercato
dei sistemi e prodotti informatici e quella di compiere
un considerevole balzo in avanti nell’area
della sicurezza informatica, area che viene sempre
più diffusamente percepita come un ambito
critico, in cui l’utente ha sempre maggiore necessità
di dover essere tutelato e di sentirsi realmente
assicurato sull’uso, senza rischi occulti, delle
tecnologie e delle applicazioni informatiche.
Marco Carbonelli
Fondazione Ugo Bordoni
Responsabile sviluppo Linee guida provvisorie
dello Schema nazionale
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
Lo standard Common Criteria
(ISO/IEC IS 15408)
I concetti di base
Nel limitato spazio disponibile non
sarebbe possibile riportare una
descrizione anche sommaria delle
varie parti che compongono i Common Criteria
(denominati CC nel seguito per brevità).
Quand’anche ci si provasse, peraltro,
si sarebbe obbligati ad introdurre un gran
numero definizioni che non potrebbero
essere diffusamente illustrate, correndo
così il rischio di produrre una sintesi poco
chiara nella quale gli elementi veramente
importanti che sono alla base di questi criteri
potrebbero risultare poco evidenti. In
questo paragrafo ci si limiterà quindi a
descrivere l’approccio secondo il quale i
CC sono stati sviluppati, mirando principalmente
a fornire quegli elementi informativi
che consentono una adeguata comprensione
del successivo paragrafo dedicato ad
una descrizione dei vantaggi e degli svantaggi
di questi criteri.
La filosofia che è alla base dei CC è stata
ripresa dai precedenti criteri europei
ITSEC (Information Technology Security
Evaluation Criteria) che per primi l’hanno
introdotta. In base a tale filosofia non ha
senso verificare se un sistema/prodotto è
sicuro se non si specifica:
“sicuro” per fare cosa (obiettivi di sicurezza)
“sicuro” in quale contesto (ambiente di
sicurezza)
“sicuro” a fronte di quali verifiche (requisiti
di assurance).
Tra parentesi sono stati indicati alcuni termini
che sono utilizzati nell’ambito dei CC e
che consentono di esprimere nel seguente
modo lo scopo di una valutazione secondo
tali criteri: offrire garanzie, che vengono
prodotte dal soddisfacimento dei requisiti di
Giugno 2004
assurance e che risultano crescenti con il
livello di valutazione, sulla capacità del sistema/prodotto
di soddisfare i propri obiettivi
di sicurezza nell’ambiente di sicurezza per
esso ipotizzato.
Un obiettivo di sicurezza viene definito,
secondo i CC, come l’intenzione di contrastare
una minaccia o quella di rispettare leggi,
regolamenti o politiche di sicurezza preesistenti.
Il conseguimento degli obiettivi
avviene attraverso l’adozione di misure di
sicurezza tecniche (funzioni di sicurezza) e
non tecniche (fisiche, procedurali e relative
al personale).
L’ambiente di sicurezza viene descritto in
termini di:
–uso ipotizzato del sistema/prodotto
(applicazioni, utenti, informazioni trattate
ed altri beni con specifica del relativo
valore)
–ambiente di utilizzo (misure di sicurezza
non tecniche, collegamento con altri
apparati ICT)
–minacce da contrastare, specificando
caratteristiche dell’attaccante (conoscenze,
risorse disponibili e motivazione),
metodi di attacco (citando, tra l’altro, lo
sfruttamento di eventuali vulnerabilità
note del sistema/prodotto ICT), beni
colpiti
– politiche di sicurezza dell’Organizzazione.
Le verifiche previste durante il processo
di valutazione mirano ad accertare che siano
stati soddisfatti, da parte del sistema/prodotto,
del suo sviluppatore e del valutatore,
opportuni requisiti di assurance che diventano
sempre più severi al crescere del livello
di valutazione. I CC definiscono una scala di
7 livelli di valutazione (EAL1, EAL2, …,
EAL7) o livelli di assurance, precisando, per
89

90
ogni livello di tale scala uno specifico insieme
di requisiti di assurance. Il livello EAL1,
cui corrisponde il livello di sicurezza più
basso, non ha corrispondenti nei precedenti
criteri di valutazione.
Le verifiche, eseguite in base ai requisiti di
assurance del livello di valutazione considerato,
hanno lo scopo di fornire garanzie circa:
– l’idoneità delle funzioni di sicurezza a
soddisfare gli obiettivi di sicurezza del
sistema/prodotto;
– l’assenza di errori nel processo che dalle
specifiche iniziali di sicurezza (ambiente e
obiettivi di sicurezza) porta alla pratica
realizzazione delle funzioni di sicurezza
(errori di interpretazione delle specifiche
tecniche, errori di programmazione, ecc);
– l’adeguatezza delle procedure di sicurezza
previste per la consegna e per l’installazione
del sistema/prodotto (per evitare
che il sistema/prodotto che perviene
all’utente finale possa differire, magari
anche di poco, da quello sottoposto a
valutazione/certificazione), la chiarezza
dei manuali d’uso e d’amministrazione
(questi ultimi potrebbero infatti indurre
gli utilizzatori a comportamenti che
introducono vulnerabilità nell’utilizzo di
un prodotto/sistema dotato di funzioni
di sicurezza del tutto idonee e realizzate
senza errori), il supporto che lo sviluppatore
si impegna a fornire a chi usa il
sistema o prodotto per rimediare ad
eventuali vulnerabilità emerse dopo la
valutazione.
Con riferimento al punto 2) può essere
interessante precisare che le garanzie circa
l’assenza di errori nel processo di realizzazione
delle funzioni di sicurezza non vengono
ottenute solamente ricercando direttamente
gli errori stessi (analizzando la documentazione
presentata dal richiedente della
valutazione e sottoponendo il sistema/prodotto
a test funzionali e ad attacchi), bensì
anche verificando che nel processo di realizzazione
sia stato previsto l’impiego di strumenti,
metodologie e procedure finalizzati
alla riduzione della probabilità di errori.
Lo standard Common Criteria (ISO/IEC IS 15408)
Al crescere del livello di valutazione:
–vengono richieste specifiche realizzative
più dettagliate (ad esempio progetto ad
alto livello, progetto a basso livello, codice
sorgente)
– il livello di rigore con il quale le specifiche
devono essere descritte aumenta (descrizione
informale, semiformale, formale).
Il rigore della valutazione, così come nei
criteri ITSEC, non viene individuato solo
dal livello di valutazione bensì anche da un
altro parametro. Infatti per le funzioni che
devono essere realizzate con meccanismi
probabilistici o di permutazione (password,
funzioni hash, etc.), i CC richiedono (a partire
da EAL2) che venga specificato un livello
minimo di robustezza (SOF - Strength Of
Functionality) su una scala a tre valori (basic,
medium, high).
Le funzioni di sicurezza del sistema/prodotto
vengono descritte in base ai requisiti
cui devono soddisfare. Tali requisiti, denominati
requisiti funzionali, così come i già
citati requisiti di assurance, devono essere
espressi (a meno di possibili eccezioni che
occorre comunque giustificare) utilizzando
un catalogo di componenti fornito nei CC.
Più precisamente il catalogo delle componenti
funzionali costituisce la parte 2 dei
CC, mentre quello delle componenti di
assurance la parte 3. I cataloghi sono strutturati
su più livelli gerarchici in modo da
raccogliere componenti di tipo omogeneo.
A titolo di esempio, per quanto riguarda le
componenti funzionali, al livello gerarchico
più elevato è previsto un raggruppamento
secondo le unidici classi di seguito specificate:
Audit, Communication, Cryptographic
Support, User Data Protection, Identification
and Authentication, Security management,
Privacy, Protection of the TOE Security
Function, Resource Utilization, TOE
Access, Trusted Path/Channels (l’acronimo
TOE ricorrente in alcuni nomi di classi
funzionali indica il sistema/prodotto ICT
da valutare).
Tra i numerosi documenti che il richiedente
della valutazione deve/può consegnare ai
Iquadernidi

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica
valutatori, unitamente al sistema/prodotto
ICT da valutare, due meritano un particolare
cenno. Il primo, denominato Security Target,
deve essere obbligatoriamente fornito e rappresenta
il documento principale della valutazione.
Nel Securuty Target devono essere
descritti l’ambiente di sicurezza, gli obiettivi
di sicurezza, i requisiti funzionali e di assurance
(e quindi il livello di valutazione), la
robustezza minima delle funzioni di sicurezza
ed una prima descrizione ad alto livello
delle funzioni di sicurezza. Quest’ultima
sezione non è invece contenuta nel secondo
documento, il Protection Profile, che per il
resto ha una struttura del tutto simile a quella
del Security Target. Il Protection Profile
può essere opzionalmente sviluppato con
riferimento ad un’intera classe di prodotti
(per la quale si lascia la libertà di realizzare le
funzioni di sicurezza in un qualsiasi modo
che soddisfi i requisiti funzionali) piuttosto
che con riferimento ad uno specifico sistema/prodotto
ICT (come è il caso, invece, del
Security Target). Il Protection Profile, che può
essere registrato e anche valutato per verificarne
la coerenza interna.
I pro e i contro
In questo paragrafo verranno descritti i
principali vantaggi e svantaggi derivanti dall’applicazione
dei CC. In realtà, come apparirà
più chiaro nel seguito, gran parte di essi
possono essere considerati comuni a tutte le
raccolte di criteri di valutazione fin qui sviluppate.
Per quanto riguarda i vantaggi si
possono citare:
–la verifica, eseguita da una terza parte per
la quale viene riconosciuto il possesso di
conoscenze specialistiche, che le funzionalità
di sicurezza del sistema/prodotto ICT,
affiancate alle contromisure non tecniche
previste, siano adeguate al soddisfacimento
degli obiettivi di sicurezza;
–lo svolgimento di un’azione di contrasto
preventivo degli incidenti di sicurezza ICT;
– le maggiori garanzie che i CC offrono
rispetto ad altri strumenti di contrasto di
tipo preventivo;
Giugno 2004
–la disponibilità di vasti cataloghi relativamente
alle funzionalità di sicurezza ICT e
ai requisiti di assurance adottabili;
–la possibilità di esprimere in forma standardizzata
requisiti di sicurezza per sistemi
e prodotti ICT.
Detto questo riguardo ai vantaggi che l’applicazione
dei CC può portare, vediamo ora
quelli che possono essere considerati gli
svantaggi. Tra questi possiamo citare:
–i lunghi tempi di esecuzione del processo
di valutazione/certificazione;
– il costo elevato del processo;
– la perdita della certificazione non appena
ci si discosta anche lievemente dalla configurazione
certificata.
È opportuno tuttavia precisare subito che
i primi due svantaggi si riferiscono alle
modalità d’impiego tipiche dei criteri nel
contesto della sicurezza nazionale, ossia
quando viene previsto un livello di valutazione
non inferiore a EAL3. In tali casi,
infatti, lo svantaggio citato al punto a) deriva
dall’obbligo per chi richiede la valutazione
di predisporre una notevole mole di
documentazione e dal tempo necessario ai
valutatori per analizzare tale documentazione
ed eseguire tutte le numerose e complesse
azioni che i criteri pongono a loro carico.
Conseguenza di questo stato di cose è che
non di rado quando il processo termina è già
disponibile una nuova versione del sistema/prodotto
ICT. Inoltre possono nascere
difficoltà relativamente all’utilizzazione di
prodotti certificati nelle architetture hw/sw
più recenti.
Per quanto riguarda il punto b) si può
dire che il costo elevato risulta una diretta
conseguenza, oltre che dei lunghi tempi di
esecuzione, anche delle risorse non trascurabili
dal punto di vista sia qualitativo sia
quantitativo che durante l’esecuzione del
processo è necessario impegnare.
Se invece vengono utilizzati i primi livelli
di valutazione, il che può essere adeguato in
molte situazioni di pratico interesse, gli svantaggi
descritti ai punti a) e b) tendono a
91

92
scomparire. Al riguardo si può peraltro ricordare
che proprio con i CC è stato aggiunto un
livello iniziale di valutazione che non trova
corrispondenze nei precedenti criteri di valutazione
e che è caratterizzato da tempi e costi
alquanto contenuti. Quando tale livello viene
utilizzato la collaborazione richiesta al soggetto
che ha sviluppato l’oggetto della valutazione
è praticamente nulla e risulta quindi
possibile valutare e certificare anche componenti
di un sistema ICT per le quali risulta
molto difficile ottenere informazioni progettuali
che consentano la scrittura della documentazione
prevista ai livelli di valutazione
medi e alti. Ovviamente in tale caso diviene
più difficile per i valutatori individuare eventuali
vulnerabilità, dato che non dispongono
più (o ne dispongono in misura alquanto
limitata) di informazioni, normalmente non
accessibili fuori dell’ambiente di sviluppo (ad
esempio i valutatori possono avere accesso al
codice sorgente di un prodotto commerciale),
relative alla struttura interna delle funzioni di
sicurezza. Tuttavia la certificazione al livello
minimo EAL1 già garantisce l’eliminazione
(tipicamente mediante l’installazione di apposite
patch) di eventuali vulnerabilità dell’oggetto
della valutazione che siano già note. Dal
livello EAL2 in su, il valutatore tenterà anche
di violare l’oggetto della valutazione utilizzando
tecniche di attacco diverse da quelle
che consentono di sfruttare le vulnerabilità
già note.
Riguardo al punto c) è opportuno invece
sottolineare che una delle implicazioni più
dirette che crea notevoli difficoltà è l’impossibilità
di installare le patch senza prevedere
una nuova certificazione del sistema/prodotto
ICT. Quest’ultima può essere però resa
relativamente veloce e non troppo costosa
(anche a livelli di valutazione medi ed alti)
seguendo le indicazioni relative al mantenimento
nel tempo della certificazione (tali
indicazioni nella prima versione dei CC erano
presenti in un’apposita classe di assurance
denominata Maintenance of assurance
Lo standard Common Criteria (ISO/IEC IS 15408)
mentre ora sono disponibili in un documento
separato sviluppato ai fini del mutuo riconoscimento
internazionale). In taluni casi,
peraltro, ossia quando mediante una opportuna
analisi si sia potuto stabilire che gli
aggiornamenti hw/sw non possono compromettere
il buon funzionamento delle parti
più critiche del sistema/prodotto ICT, può
essere sufficiente una integrazione della
documentazione di valutazione, piuttosto
che una riesecuzione di attività da parte dei
valutatori.
Conclusioni
L’utilizzo dei Common Criteria per la
valutazione e certificazione di sistemi/prodotti
ICT consente di ottenere garanzie circa
il livello di sicurezza di tali sistemi/prodotti
che possono essere ancor più graduate
rispetto a quanto possibile con i precedenti
criteri. In particolare l’utilizzo dei primi
livelli di valutazione e dei requisiti previsti ai
fini del mantenimento nel tempo delle certificazioni
sembra in grado di soddisfare le
esigenze di protezione frequentemente
incontrate fuori del contesto della sicurezza
nazionale, ossia in situazioni di rischio informatico
non particolarmente elevato. A tal
riguardo, ad esempio, saranno eseguibili con
costi e tempi limitati certificazioni che
garantiscano da un lato la capacità delle funzioni
di sicurezza dell’oggetto certificato di
soddisfare, nel contesto utilizzativo descritto
(ambiente di sicurezza), gli obiettivi di sicurezza
dichiarati, dall’altro, come risultato
minimo, l’eliminazione di tutte le vulnerabilità
note da cui fosse affetto l’oggetto stesso.
Franco Guida
Fondazione Ugo Bordoni
Membro del Comitato tecnico nazionale sulla
sicurezza informatica e delle telecomunicazioni
nelle pubbliche amministrazioni
Coordinatore Area Operativa dell’Organismo
di Certificazione
Iquadernidi