A cura di Alberto Mucci ANCHE L’ITALIA SI DOTA DI · A cura di Alberto Mucci Supplemento al...

I quaderni di A cura di Alberto Mucci

Supplemento al numero 217 di giugno 2004 di MEDIA DUEMILA

La notizia è positiva e di particolare significato in questa delicata fase di passaggioe di innovazioni tecnologiche: è stata istituito anche in Italia l’organismo dicertificazione 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 dicertificazione legato alla sicurezza. In pratica il nuovo organismo permetterà di farecertificazioni anche fuori dal contesto della sicurezza nazionale (tutela delle informazionicoperte dal “segreto di Stato”), per il quale esiste fin dal 1995 uno Schema nazionaledi certificazione coordinato dall’Autorità Nazionale per la Sicurezza (ANS).

Le ricadute positive di questa novità meritano attenzione, come documentano gliinterventi che compaiono in questo “Quaderno”. In particolare:

- si creano le condizioni perché le imprese possano incrementare le vendite dispecifici prodotti una volta che questi siano dotati di certificazioni di sicurezza;

- gli utilizzatori di prodotti potranno avere una certificazione con garanzie chevanno oltre la semplice dichiarazione del fornitore;

- i fornitori privati di servizi potranno sperare di ampliare la propria clienteladichiarando 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 sicurezzapotranno dimostrare di aver curato al meglio la loro protezione qualora abbianoprovveduto a certificare i propri sistemi ICT.

La certificazione attuale, utilizzata nel contesto della sicurezza nazionale, ha costielevati e tempi operativi lunghi. Con il nuovo organismo si creano i presupposti perapplicare gli standard di certificazione anche a livelli meno elevati, semplificandole procedure, ma fornendo nel contempo adeguate garanzie. Si potranno certificarecon maggiore facilità sistemi complessi e verrà reso più agevole il mantenimento neltempo 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 progrediredell’innovazione.

L

ANCHE L’ITALIA SI DOTA DIUN ORGANISMO CHE CERTIFICALA SICUREZZA INFORMATICA

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)

67

68

72

74

78

82

85

89

Sono usciti:

INDICEINDICE

Il Quaderno è stato realizzato dalla Fondazione Ugo Bordoni (Presidente il Prof. GiordanoBruno Guerri, Direttore Generale il Consigliere Guido Salerno, Direttore delle Ricerche l’Ing.Mario Frullone). Coordinatore del Quaderno l’ing. Franco Guida. Hanno collaborato: ClaudioManganelli, CNIPA; Giorgio Tonelli, Isabella Marra, Ambrosetti; Carmelo Basso, GiuseppePierri, Giovanni Desirò, ISCTI; Marco Carbonelli, Fondazione Ugo Bordoni.

Sono usciti:

Un web per tutti. L’accessibilità di Internet ottobre 2002Wi-Fi. Come – quando – perché novembre 2002I satelliti nella società multimediale dicembre-gennaio 2003Telefonia mobile e emissioni elettromagnetiche febbraio 2003Le reti di telecomunicazioni diventano intelligenti marzo 2003Mentre viaggi lavori con Internet aprile 2003 Come garantire sicurezza con lo sviluppo di Internet maggio 2003Le macchine che parlano giugno 2003Le macchine che capiscono luglio-agosto 2003Il progresso tecnologico fra brevetti e standard settembre 2003La rendicontazione? Automatica, ma… ottobre 2003Le nuove tecnologie fotoniche novembre 2003Il progetto Galileo sta diventando realtà dicembre-gennaio 2004Non confondere la biometrica con il “grande fratello febbraio 2004Dal call center al contact center marzo 2004La larga banda si diffonde cambia la vita della gente aprile 2004I campi elettromagnetici non sono più “sconosciuti” maggio 2004

67Giugno 2004

Anche l’Italia si dota di un organismo che certifica la sicurezza informatica

La certificazione della sicurezza ICT

A distanza di circa un anno dal primoQuaderno di Telèma dedicato alla si-curezza ICT, ho accettato con grande

entusiasmo l’invito rivoltomi dal dott. GuidoSalerno, Direttore Generale della FondazioneUgo Bordoni (FUB), e dal dott. Alberto Muc-ci, coordinatore dei Quaderni, a curare una se-conda edizione che permettesse di tornare suun argomento la cui importanza ed attualitàcontinua a crescere. Chi ha avuto l’opportu-nità di leggere il Quaderno di Maggio 2003, ri-corderà forse che ci eravamo già lasciati conl’intenzione di continuare il discorso intrapre-so ed erano già stati individuati vari temi, traquelli su cui la Fondazione è impegnata relati-vamente alla sicurezza ICT, da sviluppare in unsuccessivo Quaderno. Mi è apparso però benpresto chiaro che, tenendo conto della recen-tissima novità costituita dall’istituzione di unOrganismo nazionale di certificazione della si-curezza dei sistemi ICT, strutturare il presenteQuaderno seguendo le linee tracciate lo scorsoanno non sarebbe stato opportuno. Sebbenecon il rammarico di non poter dare spazio acolleghi e collaboratori della Fondazione cheavrebbero potuto fornire una panoramica dinotevole interesse sui temi di cui quotidiana-mente si occupano, ho quindi scelto di dedica-re interamente il Quaderno alla certificazionedella sicurezza, dato anche il notevole impattoche la novità cui ho accennato sopra sta aven-do ed avrà sulle attività della Fondazione Bor-doni nell’area della sicurezza ICT.

L’assunzione del ruolo di Organismo di cer-tificazione da parte dell’Istituto Superiore del-le Comunicazioni e delle Tecnologie dell’Infor-mazione (ISCTI), infatti, si traduce in un note-vole impegno anche da parte della FUB, datala tradizionale collaborazione nel campo tecni-co che oramai da svariati decenni lega le dueorganizzazioni.

Grazie alla disponibilità manifestata dall’ing.Manganelli, Componente del Centro Nazionale

per l’Informatica nella Pubbli-ca Amministrazione (CNIPA),il Quaderno può aprirsi con unarticolo di grande interesse cheriporta le azioni che sono statesvolte e che si intende svolgerenell’ambito della PA relativa-mente alla certificazione dellasicurezza ICT. Tali azioni sonoascrivibili al Comitato tecnico nazionale per lasicurezza informatica e delle telecomunicazioninelle PA, di cui l’ing. Manganelli è Presidente edel quale mi onoro di far parte.

Il successivo articolo tratta invece i legami tral’analisi dei rischi e la certificazione della sicu-rezza ICT ed è stato scritto dal dott. Tonelli (an-ch’egli autorevole membro del predetto Comi-tato) e dalla dott.ssa Marra di Ambrosetti.

Un ulteriore articolo da parte di un altromembro del Comitato, il Presidente Carlo Sar-zana di S. Ippolito, eminente figura di riferi-mento per quanto riguarda gli aspetti giuridicirelativi alle tecnologie informatiche, non hapotuto purtroppo essere realizzato in tempo u-tile per la pubblicazione, data la novità e lacomplessità del tema da affrontare (i riflessigiuridici della certificazione di sicurezza ICT).

Naturalmente non potevano poi mancarecontributi da parte dell’ISCTI, che svolge evi-dentemente il ruolo di protagonista considera-to il tema di questo Quaderno. È quindi pre-sente innanzitutto un articolo del Direttoredell’ISCTI, ing. Basso, che con la sua guida au-torevole ha creato le condizioni affinché l’Isti-tuto, coadiuvato dalla Fondazione Bordoni,potesse assumere un impegno così importantee al tempo stesso così gravoso. Tale impegno,peraltro, va ad aggiungersi ad altri di non mi-nore rilievo nel settore della sicurezza ICT,quali ad esempio l’allestimento di un Centro diformazione per i dipendenti della PA e la ge-stione del Centro di Valutazione accreditatodall’Autorità Nazionale per la Sicurezza.

Franco Guida

Per quanto riguarda quest’ultimo contribu-to, viene in particolare evidenziata la capacitàche questo standard offre di soddisfare una e-sigenza molto sentita ed attuale, quella di for-nire garanzie, senza richiedere tempi e costiparticolarmente rilevanti, circa l’effettivo ag-giornamento del software installato sui sistemiICT. L’importanza di questa esigenza è dimo-strata dai numerosi incidenti informatici chesono stati causati dalla mancata installazionedelle patch che avrebbero consentito di elimi-nare vulnerabilità scoperte nel software.

Franco GuidaFondazione Ugo Bordoni

Membro del Comitato tecnico nazionale sulla sicurezza informatica e delle telecomunicazioni

nelle pubbliche amministrazioni

Coordinatore Area operativa dell’Organismo di Certificazione


I successivi due contributi ISCTI, che de-scrivono il processo di certificazione della si-curezza ICT ed i criteri di valutazione europeiITSEC, sono invece stati sviluppati dall’ing.Pierri, che dirige l’Ufficio ISCTI entro il qualel’Organismo di certificazione è stato costituitoed il dott. Desirò, che coordina l’Area gestio-nale di tale Organismo.

Il Quaderno si chiude infine con due con-tributi FUB, nel primo dei quali l’ing. Carbo-nelli descrive sommariamente la normativa(Linee Guida) che sarà adottata nella fase diavvio dello Schema nazionale e che è stata svi-luppata sotto il suo coordinamento. Il secon-do contributo FUB, da me predisposto, illu-stra invece i principi ispiratori dei CommonCriteria, lo standard mondiale di riferimentoper la certificazione della sicurezza dei siste-mi informatici.

le suddette iniziative hanno dedicato un’at-tenzione particolare, la loro illustrazione nelpresente Quaderno è diventata una sceltapraticamente obbligata.

Sicurezza ICT nella PA: le iniziativegovernative

Nel corso degli anni Novanta sono stati e-manati i primi provvedimenti governativi ri-guardanti la sicurezza ICT, i quali, però, han-no affrontato di volta in volta aspetti specificiin modo frammentario, non essendo statoprecedentemente definito un approccio unita-rio applicabile all’intera PA. Come già accen-nato, quindi, il primo riferimento che è possi-bile citare per descrivere le azioni che il Go-verno ha intrapreso al fine di garantire unagestione organica della sicurezza ICT all’in-

A partire dall’inizio del2002 il tema della si-curezza ICT nella

Pubblica Amministrazione èstato affrontato in modo orga-nico a livello governativo at-traverso una direttiva del Pre-

sidente del Consiglio dei Ministri [1], emana-ta dal Ministro per l’innovazione e le tecnolo-gie d’intesa con il Ministro delle Comunica-zioni, ed un successivo decreto interministe-riale [2] con il quale gli stessi Ministri hannocreato un gruppo di indirizzamento e coordi-namento relativamente alle azioni previstenella direttiva. Una trattazione di queste ini-ziative governative sarebbe stata comunqueopportuna nell’ambito di questo QuadernoTelema. Ove si consideri, poi, che proprio altema della certificazione della sicurezza ICT

I quaderni di68

Claudio Manganelli

La certificazione della sicurezzaICT nella Pubblica

Amministrazione

terno della PA è costituito dalla direttiva “Si-curezza Informatica e delle Telecomunicazio-ni nelle Pubbliche Amministrazioni Statali”[1]. Con tale direttiva, i cui principi ispiratorisono conformi alle normative internazionalimaggiormente accreditate (si consideri, ad e-sempio, lo standard [5]), vengono gettate lebasi per lo sviluppo del programma di azionedel Governo nel campo della sicurezza ICT evengono fornite indicazioni alle pubblicheamministrazioni relativamente alle azioniprioritarie da svolgere nell’immediato. In par-ticolare viene raccomandato:– di eseguire un’autodiagnosi, sulla base del-

l’allegato 1 della direttiva, del livello di ade-guatezza della sicurezza ICT, con particolareriferimento alla dimensione organizzativa o-perativa e conoscitiva della sicurezza;

– di attivare le necessarie iniziative per posi-zionarsi 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 silimiterà ad approfondire gli aspetti riguardantila certificazione. A tal riguardo la direttiva pre-vede che il Dipartimento per l’innovazione e letecnologie della Presidenza del Consiglio deiMinistri ed il Ministero delle comunicazionipromuovano la predisposizione di un program-ma di azione del Governo per la sicurezza ICTarticolato su varie linee, tra le quali:– definire uno schema nazionale di riferimen-

to della sicurezza sviluppando linee guida,direttive, standard, nonché i processi di ac-creditamento e di certificazione;

– realizzare la certificazione di sicurezza ICTnella pubblica amministrazione;

– costituire un Comitato nazionale della sicu-rezza ICT per indirizzare, guidare e coordi-nare le varie iniziative connesse con il rag-giungimento degli standard di sicurezza cheverranno definiti.

Per quanto riguarda la prima linea di azione,il decreto [3] ha definito lo Schema nazionaleper la valutazione e certificazione della sicurez-za di sistemi e prodotti nel settore della tecno-logia dell’informazione e sono attualmente in

corso la definizione e la regolamentazione ditutte le attività che si svolgeranno all’internodello Schema. Per quanto riguarda invece laseconda linea, si rimanda al successivo para-grafo per la descrizione delle azioni già intra-prese e da intraprendere ai fini della sua realiz-zazione. Relativamente alla terza linea, infine,si può richiamare il già citato decreto intermi-nisteriale [2] che ha istituito il Comitato Tecni-co Nazionale sulla sicurezza informatica e del-le telecomunicazioni nelle pubbliche ammini-strazioni (nel seguito denominato brevementeComitato). Tale decreto prevede che il Comi-tato sia costituito da cinque membri, due no-minati dal Ministro delle Comunicazioni (tracui il Presidente) e tre dal Ministro per l’inno-vazione e le tecnologie. Le funzioni assegnateal Comitato sono le seguenti:– sviluppare le strategie da seguire ai fini dello

sviluppo del Piano nazionale e del modelloorganizzativo nazionale della sicurezza ICTnella pubblica amministrazione;

– verificare annualmente lo stato di avanza-mento del Piano nazionale (indicando even-tuali azioni correttive) nonché l’attivazione eapplicazione del modello organizzativo;

– formulare “proposte in materia di regola-mentazione della certificazione e valutazionedella sicurezza, nonché ai fini della predi-sposizione di criteri di certificazione e dellelinee guida per la certificazione di sicurezzaICT per la pubblica amministrazione, sullabase delle normative nazionali, comunitariee internazionali di riferimento”;

– elaborare linee guida per la predisposizionedelle intese con il Dipartimento della funzio-ne pubblica in ordine alla formazione dei di-pendenti pubblici in tema di sicurezza ICT.

La terza funzione costituisce evidentementeil contributo del Comitato alla realizzazionedella linea di azione prevista nella direttiva [1]relativamente alla certificazione di sicurezzaICT nella pubblica amministrazione. Ancheper quanto riguarda questa funzione, quindi,ulteriori informazioni possono essere trovatenel successivo paragrafo.

A completamento di questo quadro sinteti-co sulle iniziative governative è infine oppor-


69Giugno 2004

dal questionario di autovalutazione (allegato1 della direttiva [1]) al quale le PA stesse so-no state invitate a rispondere. Più precisa-mente il Comitato potrà raccomandare che,nei casi in cui risultino situazioni di elevatacriticità, in aggiunta alle verifiche interne(ossia eseguite da personale dell’amministra-zione) già previste dall’allegato 2 della diret-tiva [1], vengano eseguite vere e proprie cer-tificazioni di apparati ICT secondo i Com-mon Criteria [7] [8] [9] o i criteri ITSEC[10]. In queste stesse situazioni il Comitatopotrà eventualmente raccomandare l’esecu-zione di certificazioni del processo di gestio-ne della sicurezza ICT in singole Ammini-strazioni o in parti di esse, eseguite secondolo standard BS7799-2 [6]. Queste indicazionipossono considerarsi in linea con quantoprevisto nel documento [11] che presentacome consigliabile l’uso della certificazionedi sicurezza:1) per i sistemi ICT che trattano informazionile quali, sebbene non classificate ai fini della si-curezza nazionale (in caso contrario le certifi-cazioni sono obbligatorie sia in Italia sia inmolti paesi esteri), possono essere consideratecritiche o essenziali per lo svolgimento dellefunzioni primarie dell’Amministrazione,2) per i sistemi ICT da cui dipendono l’opera-tività e/o la manutenzione delle infrastrutturecritiche.

Inoltre nel documento [12] viene affermatoche il governo statunitense si propone di verifi-care la fattibilità economica dell’estensionedell’obbligo di certificazione ai sistemi ICT u-tilizzati da tutte le agenzie federali, anche neicasi in cui non trattino informazioni classifica-te. Il governo statunitense prevede peraltroche, qualora tale estensione possa essere effet-tuata, essa influenzerà molto positivamente ilmercato dei prodotti ICT consentendo di go-dere dei relativi benefici anche al di fuori delcontesto governativo.

Le prossime azioni

Dopo le prime indicazioni che il Comitatoha fornito attraverso il documento [4], potràessere sviluppata, nell’ambito del programma


tuno segnalare che nella riunione del 18 mar-zo 2003 il Comitato dei Ministri per la Societàdell’informazione ha espresso il proprio pare-re favorevole relativamente al finanziamentodi due progetti riguardanti la sicurezza ICTnella PA. Tali progetti, denominati «CERTper la Pubblica Amministrazione» e «Centrodi formazione e sensibilizzazione del persona-le della PA», sono stati sviluppati in una primafase dal Comitato e sono stati poi fatti propri,rispettivamente, dal Centro Nazionale perl’Informatica nella Pubblica Amministrazione(CNIPA) e dall’Istituto Superiore delle Co-municazioni e delle Tecnologie dell’Informa-zione (ISCTI), che ne cureranno l’ulterioresviluppo e la realizzazione.

Le linee guida per la certificazionedi sicurezza ICT nella pubblicaamministrazione

Come già anticipato nel precedente para-grafo, tra gli obiettivi del programma di azionedel Governo per la sicurezza ICT vi è la realiz-zazione della certificazione di sicurezza ICTnella pubblica amministrazione. A tal fine unpassaggio obbligato è stato la creazione, grazieanche all’azione di stimolo esercitata dal Co-mitato, dello Schema nazionale per la valuta-zione e certificazione della sicurezza nel setto-re della tecnologia dell’informazione [3]. Unavolta avviata l’attivazione di un servizio di cer-tificazione della sicurezza di apparati ICT, ilsuccessivo compito di cui il Comitato ha dovu-to farsi carico è stato quello di definire le mo-dalità di utilizzazione di tale servizio all’inter-no della PA.

Le prime indicazioni

Nell’ambito del documento [4], recente-mente prodotto dal Comitato, il problemadella certificazione di sicurezza ICT nella PAè stato affrontato iniziando ad orientare leamministrazioni nelle scelte che a tal riguar-do dovranno effettuare. In particolare si èprevisto che il Comitato stesso assista le PAnelle decisioni relative alla certificazione, av-valendosi anche delle informazioni derivabili

I quaderni di70

di azione del Governo per la sicurezza ICT,una strategia complessiva per ciò che concer-ne la certificazione della sicurezza ICT nellaPA. In particolare potrà essere raccomandatodi servirsi anche dei primi livelli di certifica-zione, i quali, sebbene poco utilizzati nel con-testo della sicurezza nazionale, possono offri-re spesso, nel contesto generale, significativegaranzie di sicurezza, senza richiedere costi etempi particolarmente rilevanti. Inoltre lecertificazioni eseguite a tali livelli hanno ilvantaggio di richiedere un coinvolgimentonullo o limitato di chi ha sviluppato le com-ponenti del sistema ICT e rendono quindi piùagevole la certificazione di interi sistemi, non-ché il mantenimento nel tempo della certifi-cazione stessa. Analogamente a quanto avvie-ne nella pubblica amministrazione statuniten-se, inoltre, lo standard Common Criteria po-trà essere utilizzato anche fuori del contestodi una certificazione prevedendo lo sviluppodi opportuni Profili di Protezione (ProtectionProfile) che esprimano in modo standardizza-to obiettivi, ambiente ipotizzato e requisiti disicurezza per varie tipologie di prodotti ICT.Tali Profili potranno essere utilizzati dalle PAnella stesura di capitolati e sarà possibile, aseconda dell’entità dei rischi, ritenere suffi-ciente un’autodichiarazione del fornitore cir-ca il soddisfacimento dei requisiti di sicurezzaspecificati nei Profili stessi oppure prevedereuna vera e propria certificazione. In quest’ul-timo caso, peraltro, la disponibilità dei Profilirenderà più agevole e veloce la stesura delladocumentazione necessaria per la certifica-zione stessa.

Claudio ManganelliComponente CNIPA

Presidente del Comitato Tecnico Nazionale sulla sicurezza informatica e delle telecomunicazioni


Documenti di riferimento

[1] Direttiva 16 gennaio 2002 del Presidente del Con-siglio dei Ministri “Sicurezza Informatica e delleTelecomunicazioni nelle Pubbliche Amministrazio-ni Statali” (pubblicata sulla G.U. n.69 del 22 mar-zo 2002).

[2] Decreto 24 luglio 2002 del Ministro delle comunica-zioni e del Ministro per l’innovazione e le tecnologie“Istituzione del Comitato Tecnico Nazionale sulla si-curezza informatica e delle telecomunicazioni nellepubbliche amministrazioni”.

[3] Decreto 30 ottobre 2003 del Presidente del Consigliodei Ministri “Approvazione dello Schema nazionaleper la valutazione e certificazione della sicurezza disistemi e prodotti nel settore della tecnologia del-l’informazione” (pubblicato sulla G.U. n.98 del 27 a-prile 2004).

[4] Proposte concernenti le strategie in materia di sicu-rezza informatica e delle telecomunicazioni per lapubblica amministrazione – Documento del Comita-to Tecnico Nazionale sulla sicurezza informatica edelle telecomunicazioni nelle pubbliche amministra-zioni – Marzo 2004.

[5] ISO/IEC IS 17799-1 - Information security manage-ment - Part 1: Code of practice for information secu-rity management.

[6] BS7799-2 - Information security management sy-stems - Specification with guidance for use.

[7] ISO/IEC IS 15408-1 Evaluation Criteria for Infor-mation Technology Security - Part 1: Introductionand general model.

[8] ISO/IEC IS 15408-2 Evaluation Criteria for Infor-mation Technology Security - Part 2: Security func-tional requirements.

[9] ISO/IEC IS 15408-3 Evaluation Criteria for Infor-mation Technology Security - Part 3: Security assu-rance requirements.

[10] Information Technology Security Evaluation Criteria(ITSEC) - SOG-IS (Senior Officials Group Informa-tion Systems Security) – Giugno 1991.

[11] National Security Telecommunications and Informa-tion Systems Security Policy (NSTISSP) No. 11,Subject: National Policy Governing the Acquisitionof Information Assurance (IA) and IA-EnabledInformation Technology (IT) Products – National Se-curity Telecommunications and Information SystemsSecurity Committee (NSTISSC) – Documento gover-nativo USA - Gennaio 2000

[12] The National Strategy to Secure Cyberspace – Docu-mento governativo USA – Febbraio 2003.


71Giugno 2004

L’auto-valutazione dei manager, la dimensio-ne globale della progettazione (strategica, or-ganizzativa e tecnologica), i confini dell’analisie i livelli di approfondimento delle vulnerabi-lità sono infatti aspetti discriminanti che, semal indirizzati, possono compromettere l’effi-cienza ed efficacia di tutto il lavoro.

Una visione unitaria

In un contesto di rapido cambiamento ecomplessità crescente è necessaria una visioneunitaria e strategica delle aree di rischio e unavalutazione della loro criticità in relazione agliimpatti sul business.

Occorre, quindi, un’analisi del rischio preli-minare di alto livello orientata alla valutazionedegli impatti, utilizzando un approccio olisticoin grado di rappresentare le variabili dinami-che nell’ambito dell’Ente inteso come sistemadi entità – relazioni.

Solo a valle di tali considerazioni il perime-tro di certificazione può essere deciso in modosignificativo con un razionale che giustifica isuccessivi investimenti da realizzare.

É sulle aree valutate critiche che, con suc-cessivi livelli di approfondimento, deve esserefocalizzata una analisi del rischio di dettaglio,giungendo fino alle singole componenti tecno-logiche che possono rappresentare fonti di ri-schio e, quindi, individuando le relative con-tromisure.

La certificazione degli apparati ICT si confi-gura, a sua volta, come una possibile contromi-sura in grado di garantire una particolare effi-cacia nella riduzione delle vulnerabilità dei si-stemi, point of failure, che potrebbero essereimpropriamente messe a frutto per effettuareintrusioni dall’esterno.

Le certificazioni di sistemi e prodotti ICTsecondo gli standard Common Criteria e IT-SEC rappresentano, quindi, un’opportunità

L’analisi dei rischi e le certificazioni di sicurezza ICT

L a ragion d’essere dellasicurezza delle informa-zioni di un’ impresa è

essenzialmente quella di man-tenere il rischio ad un livelloritenuto accettabile dal mana-gement.Questo assunto apparentemente

banale introduce però due aspetti cruciali delproblema:– il fatto che si tratta di un’opzione strategica delladirezione e non dell’IT;– la necessità di definire il rischio che si inten-

de tollerare.Le riflessioni che seguono vogliono fornire

un contributo concettuale al processo di inter-pretazione della rilevanza organizzativa dellagestione del rischio nei confronti di un approc-cio in atto che si connota storicamente comesostanzialmente tecnologico.

La sicurezza delle informazioni rappresentaun obiettivo di rilevanza strategica che richie-de il coinvolgimento attivo della direzione/ma-nagement nel tempo al fine di gestire dinami-camente il rischio informativo nell’ambito diuna strategia della sicurezza coerente con lastrategia di business e con la struttura organiz-zativa dell’Ente/Azienda.

La certificazione del Sistema di Protezionedelle Informazioni (Information Security Ma-nagement System, ISMS) di per sé non rappre-senta necessariamente l’attestazione del rag-giungimento dell’obiettivo.

La strada della realizzazione di efficaci I-SMS è purtroppo lastricata di insuccessi; inve-stimenti anche rilevanti non hanno general-mente prodotto i risultati attesi a causa di unainsufficiente definizione degli obiettivi, di unaconfusa ed imprecisa individuazione dei realirischi e di una valutazione degli impatti sulleattività praticamente assente nei processi di Ri-sk Assessment.

I quaderni di72

Giorgio Tonelli

L’analisi dei rischi e le certificazionidi sicurezza ICT

per gestire i rischi tecnologici, da valutare inrelazione all’entità dei rischi stessi.

Per orientare la scelta delle contromisure darealizzare, infatti, occorre a monte una visionecomplessiva del rischio e dei possibili impattial fine di evitare spese inutili e non commisura-te ai valori da proteggere.

L’analisi del rischio

L’analisi del rischio non è però confinabilead ambiti puramente tecnologici e non può es-sere indirizzata solo da una visione tecnologicadel tema.

Infatti, sul piano della gestione strategica,assicurare il giusto equilibrio tra il valoredel patrimonio da salvaguardare, i rischi cuirisulta esposto e gli investimenti necessariper proteggerlo è responsabilità di tutta ladirezione.

Il management deve condividere una seriedi principi e regole e diffondere policy e lineeguida a tutta l’Organizzazione, attuando unafunzione di indirizzo, ma anche di governo ecoordinamento del rischio e della sicurezza.

I principi organizzativi guida per il Sistemadi 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 e-manate dalla Asset Corporate Governance di si-curezza possano essere effettivamente rese o-perative, è, infatti, indispensabile integrare lastruttura organizzativa con una rete di respon-sabilità specifiche (ad esempio ownership degliasset) attribuite a Presidi Organizzativi chiara-mente definiti in termini di missione e macroattività.

La sicurezza non può essere garantita da unafunzione (Security management) separata dalleattività operative, disgiunta dalle responsabi-

lità di business e misurata su obiettivi di pro-cesso; deve invece essere assicurata dai ruoli a-ziendali che hanno a disposizione le effettiveleve di responsabilità e di conoscenza dellarealtà dell’Ente/Azienda necessarie per pren-dere decisioni chiave relativamente a tre aspet-ti: il contributo al business dell’asset da pro-teggere, il livello di rischio accettabile e l’inve-stimento che è opportuno sostenere per rag-giungere tale livello.

L’analisi del rischio viene, in questo modo,gestita come parte integrante del processo de-cisionale e viene applicata a tutte le reali sor-genti di valore del business.

Per fare questo, occorre evidentemente at-tivare un presidio diffuso a tutti i livelli dellastruttura, evitando l’eccessiva burocratizza-zione e la proliferazione di ruoli specifici espesso ridondanti. La via è quella di attribui-re a ruoli già esistenti anche precise respon-sabilità di governo (analisi, gestione e moni-toraggio) del rischio attraverso l’attuazionedi una rete di responsabilità (Responsabile,Referente, Attuatore) che raggiunge ogni sin-golo manager.

Un tale modello di funzionamento organiz-zativo costituisce un riferimento fondamenta-le per realizzare concretamente, in linea congli indirizzi strategici dell’Ente/Organizzazio-ne, i processi della gestione del rischio e dellasicurezza.

É nella speranza di contribuire ad aumenta-re la sensibilità degli stakeholders verso la com-ponente organizzativa del rischio e della sicu-rezza che questo articolo è stato scritto.

Giorgio TonelliSenior Partner Ambrosetti

Membro del Comitato tecnico nazionale per la sicurezza informatica e delle

telecomunicazioni nelle pubbliche amministrazioni

Isabella MarraConsultant Ambrosetti


73Giugno 2004

La natura marcatamente tecnica dell’attivitàdegli Organismi di Certificazione della sicurez-za degli apparati ICT ben si adatta alle caratte-ristiche di un’organizzazione come l’ISCTI,nonché della Fondazione Ugo Bordoni che an-che in questo delicato settore collabora con l’I-stituto. In effetti, a differenza di quanto avvie-ne in altri contesti, l’Organismo di certificazio-ne non svolge solo un ruolo iniziale di accredi-tamento dei laboratori che eseguono le verifi-che in accordo a predefiniti standard (nel casoin esame i cosiddetti Laboratori per la Valuta-zione della Sicurezza, indicati nel seguito an-che con l’acronimo LVS), ma opera attivamen-te durante ogni singolo processo di certifica-zione, verificando che le azioni dei laboratoririsultino conformi sia alle regole precisate nel-lo Schema nazionale di riferimento, sia aglistandard, e alle relative metodologie, ricono-sciuti a livello mondiale. Tali standard, deno-minati rispettivamente Common Criteria[ISO1,2,3,CEM1,2] e ITSEC [ITS1,2], costi-tuiscono oramai dei riferimenti stabili e collau-dati per la conduzione di un processo di valu-tazione e certificazione. In particolare, i criteriITSEC costituiscono il riferimento tecnico eu-ropeo sin dal 1991, anche in virtù di una rac-comandazione del 1995 del Consiglio dell’U-nione Europea, mentre i Common Criteria a-dottati dall’ISO nel 1999 rappresentano i crite-ri di riferimento a livello mondiale e sono statiformalmente accettati dall’Unione Europeacon una risoluzione del 2002. L’esigenza direndere gli standard applicabili ad un insiemedi sistemi/prodotti ICT il più ampio possibileha portato a non poter definire in modo com-pleto e particolareggiato tutte le azioni che de-vono essere compiute dagli LVS ed ha resoquindi assolutamente necessario un indirizza-mento tecnico da parte dell’Organismo di cer-tificazione che garantisca una uniforme appli-


I riferimenti normativi

Il DPCM 30 ottobre 2003,pubblicato sulla GazzettaUfficiale n.98 del 27 aprile

2004 e adottato dal Ministro perl’Innovazione e le Tecnologie di concerto con iMinistri delle Comunicazioni, delle AttivitàProduttive e dell’Economia e delle Finanze,definisce lo Schema nazionale per la valutazio-ne e certificazione della sicurezza di sistemi eprodotti nel settore della tecnologia dell’infor-mazione. Tale Schema si affianca a quello crea-to nel 1995 per consentire la certificazione disicurezza di sistemi e prodotti che trattanoinformazioni classificate, ossia rilevanti ai finidella sicurezza nazionale (ad esempio informa-zioni in ambienti militari). Per quanto riguardaquest’ultimo Schema, il ruolo centrale di Or-ganismo di Certificazione è svolto dall’Auto-rità Nazionale per la Sicurezza (ANS). Nel ca-so del nuovo Schema, che sarà utilizzabile inambito commerciale, ossia per la certificazionedi tutti i sistemi e prodotti ICT ai quali non sidebbano applicare le normative relative alla si-curezza nazionale, l’Organismo di Certificazio-ne è invece l’Istituto Superiore delle Comuni-cazioni e delle Tecnologie dell’informazione (I-SCTI), al quale è stata riconosciuta l’esperien-za maturata come Centro di Valutazione(Ce.Va.) autorizzato dall’ANS ad operare nel-l’ambito dello Schema coordinato da tale Au-torità.

Molti altri paesi in Europa e nell’Americadel nord hanno intrapreso iniziative similari, i-stituendo i propri Organismi di Certificazionenazionali e raccogliendo in questi anni unamole considerevole di attività di certificazionein entrambi i settori, sia quello relativo alleinformazioni classificate sia quello commercia-le.

I quaderni di74

Carmelo Basso

L’Organismo di certificazione della sicurezza di sistemi e

prodotti ICT

cazione degli standard all’interno dello Sche-ma nazionale. Tale indirizzamento, peraltro, ènecessario che sia coerente con quelli che ven-gono forniti negli altri paesi dotati di analoghiSchemi nazionali, al fine di estendere ulterior-mente l’uniformità di applicazione degli stan-dard e consentire il mutuo riconoscimento deicertificati su scala internazionale.

Nel seguito vengono descritte le normeprincipali che regolano il funzionamento delloSchema Nazionale in generale e dell’Organi-smo di Certificazione in particolare.

Lo Schema nazionale

All’interno dello Schema nazionale vengonodefinite tutte le procedure e le regole necessa-rie per la valutazione e la certificazione dellasicurezza ICT, in conformità ai criteri europeiITSEC o ai Common Criteria.

Le procedure relative allo Schema naziona-le devono essere osservate dall’Organismo diCertificazione, dai Laboratori per la Valuta-zione della Sicurezza, nonché da tutti coloro(persone fisiche, giuridiche e qualsiasi altroorganismo o associazione) cui competono ledecisioni in ordine alla richiesta, acquisizione,progettazione, realizzazione, installazione edimpiego di sistemi e prodotti nel settore dellatecnologia dell’informazione che necessitanodi una certificazione di sicurezza conforme a-gli standard internazionali specificati prece-dentemente.

L’Organismo di Certificazione determina lalinea di condotta per l’accreditamento dei La-boratori per la Valutazione della Sicurezza.L’accreditamento degli LVS è l’atto con cuil’Organismo di Certificazione riconosce for-malmente l’indipendenza, l’affidabilità e lacompetenza tecnica di un Laboratorio per laValutazione della Sicurezza.

L’utilità primaria della valutazione/certifica-zione della Sicurezza di un sistema/prodotto/PP(Profilo di Protezione) secondo le regole delloSchema è quella di fornire una stima del livellodi sicurezza secondo standard condivisi da tutti isoggetti coinvolti e di garantire che tale stimavenga eseguita da una terza parte indipendenterispetto ai soggetti stessi.

Lo Schema riconosce gli accordi internazio-nali sull’interpretazione delle norme dei sud-detti standard.

Organizzazione e ruoli

I soggetti coinvolti nel processo di valutazio-ne e certificazione della sicurezza all’internodello Schema nazionale sono:� l’Organismo di Certificazione� la Commissione di Garanzia� il Laboratorio per la Valutazione della Sicu-

rezza;� il Committente;� il Fornitore;� l’Assistente.

L’Organismo di Certificazione

L’ISCTI del Ministero delle comunicazioni èl’Organismo di Certificazione della sicurezzanel settore della tecnologia dell’informazione.

L’Organismo di Certificazione sovrintendealle attività operative di valutazione e certifica-zione nell’ambito dello Schema nazionale at-traverso:– la predisposizione di regole tecniche in ma-

teria di certificazione sulla base delle normee direttive nazionali, comunitarie ed interna-zionali di riferimento;

– il coordinamento delle attività nell’ambitodello Schema nazionale in armonia con i cri-teri ed i metodi di valutazione;

– la predisposizione delle Linee Guida per lavalutazione di prodotti, traguardi di sicurez-za, profili di protezione e sistemi, ai fini delfunzionamento dello Schema;

– la divulgazione dei princìpi e delle procedu-re relative allo Schema nazionale;

– l’accreditamento, la sospensione e la revocadell’accreditamento degli LVS;

– la verifica del mantenimento dell’indipen-denza, imparzialità, affidabilità, competenzetecniche e capacità operative da parte degliLVS accreditati;

– l’approvazione dei Piani di Valutazione;– l’ammissione e l’iscrizione delle valutazioni; – l’approvazione dei Rapporti Finali di Valu-

tazione;


75Giugno 2004

sere riferita, da qualsiasi soggetto coinvoltonello Schema nazionale, all’Organismo di Cer-tificazione. Nel caso in cui nella controversiasia coinvolto anche l’Organismo di Certifica-zione, o quest’ultimo non sia riuscito a diri-merla, la controversia deve essere riferita allaCommissione di Garanzia.

Gli altri soggetti dello Schema nazionale

La Commissione di Garanzia ha il compitodi dirimere ogni tipo di controversia inerentealle attività svolte all’interno dello Schemanazionale quando nella controversia sia coin-volto anche l’Organismo di Certificazione oquando quest’ultimo, pur non essendo coin-volto, non sia riuscito a dirimerla. La Com-missione di Garanzia è presieduta da un rap-presentante del Dipartimento per l’Innova-zione e le Tecnologie della Presidenza delConsiglio dei Ministri.

I Laboratori per la Valutazione della Sicurezzasono accreditati dall’Organismo di Certificazio-ne ed effettuano le valutazioni di sistemi o pro-dotti ICT (denominati anche Oggetti Della Va-lutazione, o più brevemente ODV) o di Profilidi Protezione (documenti che consentono didefinire i requisiti di sicurezza da associare aduna prefissata categoria di prodotti ICT) secon-do lo Schema nazionale e sotto il controllo del-l’Organismo di Certificazione medesimo.

Ai fini dell’accreditamento, l’LVS deve pos-sedere i seguenti requisiti:– capacità di garantire l’imparzialità, l’indi-

pendenza, la riservatezza e l’obiettività, chesono alla base del processo di valutazione;

– disponibilità di locali e mezzi adeguati ad ef-fettuare valutazioni ai fini della sicurezza nelsettore della tecnologia dell’informazione;

– organizzazione in grado di controllare il ri-spetto delle misure di sicurezza e della qua-lità previste per il processo di valutazione;

– disponibilità di personale dotato delle ne-cessarie competenze tecniche;

– conformità ai requisiti specificati nelle nor-me UNI CEI EN ISO/IEC 17025 e UNICEI EN 45011 per quanto applicabili;

– capacità di mantenere nel tempo i requisitiin virtù dei quali è stato accreditato.


– l’emissione dei Rapporti di Certificazionesulla base delle valutazioni eseguite dagliLVS;

– l’emissione e la revoca dei Certificati; – la definizione, l’aggiornamento e la diffusio-

ne, almeno su base semestrale, di una lista diprodotti, sistemi e profili di protezione certi-ficati e in corso di certificazione;

– la predisposizione, la tenuta e l’aggiorna-mento dell’elenco degli LVS accreditati;

– la promozione delle attività per la diffusionedella cultura della sicurezza nel settore dellatecnologia dell’informazione;

– la formazione, abilitazione e addestramentodei Certificatori, personale dipendente del-l’Organismo di Certificazione, nonché deiValutatori, dipendenti degli LVS e Assisten-ti, ai fini dello svolgimento delle attività divalutazione;

– la predisposizione, tenuta e aggiornamentodell’elenco dei Certificatori, Valutatori e As-sistenti.

L’Organismo di Certificazione riferisce se-mestralmente sull’attività al Dipartimento perl’Innovazione e le Tecnologie (DIT) della Pre-sidenza del Consiglio dei Ministri.

Sulla base degli indirizzi stabiliti dal Presi-dente del Consiglio dei Ministri o, per suadelega, dal Ministro per l’Innovazione e leTecnologie e dal Ministro delle Comunica-zioni, l’Organismo di Certificazione cura irapporti con Organismi di Certificazione e-steri congiuntamente con l’Autorità Nazio-nale di Sicurezza, nonché partecipa alle altreattività in ambito internazionale e comunita-rio riguardanti il mutuo riconoscimento deiCertificati.

Inoltre, l’Organismo di Certificazione co-munica agli LVS qualsiasi cambiamento signi-ficativo introdotto nello Schema nazionale chepossa influenzare i termini, le condizioni e ladurata dell’attività di valutazione.

All’interno dell’Organismo di Certificazioneopera il Certificatore che è addestrato e abilita-to dall’Organismo stesso per condurre le atti-vità di certificazione.

Ogni controversia inerente alle attività svol-te all’interno dello Schema nazionale deve es-

I quaderni di76

L’LVS deve garantire la massima riservatezzasu tutte le informazioni acquisite relative al-l’Oggetto della Valutazione. A tal fine il Com-mittente può chiedere la sottoscrizione di undocumento nel quale l’LVS si impegna a man-tenere la riservatezza su informazioni tecnicheacquisite durante le attività di valutazione.

Il Committente è la persona fisica, giuridicao qualsiasi altro organismo che commissiona lavalutazione.

Il Committente può anche rivestire il ruolodi Fornitore.

Il Committente sceglie il Laboratorio di Va-lutazione della Sicurezza e stipula con lo stessoil contratto per la valutazione. Il Committenteè responsabile della fornitura all’LVS del Tra-guardo di Sicurezza, dell’Oggetto della Valuta-zione e di tutto il Materiale per la Valutazionerichiesto nel Piano di Valutazione prodottodall’LVS ed approvato dall’Organismo di Cer-tificazione.

Il Fornitore è la persona fisica, giuridica oqualsiasi altro organismo che fornisce l’ODV oparti componenti dell’ODV. Il Fornitore puòanche rivestire il ruolo di Committente dellavalutazione.

L’Assistente è una persona formata, adde-strata e abilitata dall’Organismo di Certifica-zione per fornire supporto tecnico al Commit-tente o al Fornitore che ne faccia richiesta. Al-l’Assistente può essere richiesta, tra l’altro,un’analisi del Traguardo di Sicurezza o delProfilo di Protezione al fine di accertare, sullabase anche di eventuale ulteriore documenta-zione richiesta al Committente, che lo stesso

costituisca una solida base per la conduzionedel processo di valutazione. A tal fine, l’Assi-stente, in ragione delle informazioni di cui di-spone, verifica l’assenza di elementi che possa-no pregiudicare il buon esito della valutazione.Inoltre, l’Assistente può curare il processo digestione del Certificato che viene attivato se ilCommittente decide di voler mantenere ag-giornato nel tempo il Certificato.

Carmelo BassoDirettore dell’Istituto Superiore delle Comunicazioni

e delle Tecnologie dell’Informazione (ISCTI)

Direttore dell'Organismo di Certificazione

Riferimenti bibliografici[CEM1] Common Evaluation Methodology for Informa-

tion Technology Security Evaluation, Part 1 – In-troduction and general model; version 0.6, CEM-97/017, gennaio 1997

[CEM2] Common Evaluation Methodology for Informa-tion Technology Security Evaluation, Part 2 – E-valuation Methodology, version 1.0, CEM-99/045, ottobre 2003

[ISO1] Common Criteria for Information Technology Secu-rity Evaluation, Part 1 – Introduction and generalmodel, version 2.1, CCIMB-99-031, ottobre 2003

[ISO2] Common Criteria for Information TechnologySecurity Evaluation, Part 2 – Security functionalrequirements, version 2.1, CCIMB-99-032, otto-bre 2003

[ISO3] Common Criteria for Information Technology Secu-rity Evaluation, Part 3 – Security assurance require-ments, version 2.1, CCIMB-99-033, ottobre 2003

[ITS1] Information Technology Security Evaluation Cri-teria, version 1.2, giugno 1991

[ITS2] Information Technology Security Evaluation Ma-nual, version 1.0, settembre 1993


77Giugno 2004

Il Profilo di Protezione (PP) è il documentoche descrive per una certa categoria di ODVed in modo indipendente dalla realizzazione,gli obiettivi di sicurezza, le minacce, l’ambien-te ed i requisiti funzionali e di garanzia, defini-ti secondo i Common Criteria.

Il Piano di Valutazione (PDV) è il documen-to che descrive le attività che saranno svoltedal Laboratorio per la Valutazione della Sicu-rezza (LVS) durante il processo di valutazione,i tempi di esecuzione e le risorse necessarie.

Finalità e requisiti

Il processo di certificazione è finalizzatoall’emissione di un rapporto in cui viene di-chiarato se:– il Profilo di Protezione è completo, con-

gruente e tecnicamente corretto;– il Traguardo di Sicurezza è completo, con-

gruente, tecnicamente corretto ed adatto adessere usato come base per la valutazionedel corrispondente ODV,

– l’Oggetto della Valutazione soddisfa il Traguar-do di Sicurezza al livello di garanzia richiesto.

Il processo di valutazione e certificazione deveseguire i seguenti quattro principi generali:– imparzialità: la valutazione deve essere con-

dotta senza pregiudizi e, in particolare, deveessere possibile dimostrare che l’LVS e i Va-lutatori coinvolti non abbiano interessi com-merciali o finanziari dipendenti dall’esitodella valutazione stessa;

– obiettività: le conclusioni del processo di va-lutazione devono essere motivate da eviden-ze sperimentali ogni qual volta sia possibile,in modo da limitare il più possibile opinionie valutazioni soggettive;

– ripetibilità: la valutazione dello stesso siste-ma/prodotto/PP effettuata con gli stessi re-


Il processo di certificazionedella sicurezza informaticacomprende tutte le attività

che vengono svolte durante lavalutazione e certificazione diun sistema/prodotto o anche,nel caso di utilizzazione dellostandard ISO/IEC IS 15408

(Common Criteria), di particolari documentidenominati Profili di protezione (ProtectionProfile). In particolare, all’interno del pro-cesso di certificazione si individuano il pro-cesso di valutazione, articolato in tre fasi di-stinte, e la fase di certificazione. In questolavoro vengono descritte analiticamente lesuddette fasi allo scopo di fornire tutte leinformazioni fondamentali attinenti allapreparazione conduzione e conclusione diuna valutazione, nonché le azioni che ven-gono attuate nella fase di certificazione, a-zioni che si concludono con l’emissione delRapporto di Certificazione e del relativoCertificato.

Il processo di Certificazione

Definizioni generali

Nel seguito è riportato un elenco essenzialedi definizioni necessarie per la comprensionedei paragrafi successivi.

L’Oggetto della Valutazione (ODV) costi-tuisce il sistema o prodotto sottoposto allavalutazione.

Il Traguardo di Sicurezza (TDS) è il docu-mento che specifica le funzioni di sicurezzache l’Oggetto della Valutazione dovrebbe svol-gere, l’ambiente operativo in cui l’ODV è de-stinato ad operare e il livello di garanzia al qua-le l’ODV viene valutato.

I quaderni di78

Giuseppe Pierri


quisiti di sicurezza e dallo stesso LVS deveportare agli stessi risultati;

– riproducibilità: la valutazione dello stesso si-stema/prodotto effettuata con gli stessi re-quisiti di sicurezza da un diverso LVS deveportare agli stessi risultati.

Gli LVS devono garantire, mediante l’ado-zione di specifiche misure, elevati livelli diconfidenzialità al fine di garantire la riservatez-za di informazioni tecnicamente e commercial-mente rilevanti riguardanti l’ODV e che, sediffuse, potrebbero creare un danno al pro-prietario dell’ODV stesso.

La certificazione stabilisce che la valutazio-ne è stata condotta conformemente ai criterinecessari a verificare il soddisfacimento del li-vello di garanzia, della robustezza dei meccani-smi o delle funzioni di sicurezza dichiarati econseguentemente garantisce i risultati dellavalutazione stessa.

L’Organismo di Certificazione, l’LVS e ilCommittente devono rispettivamente designa-re un responsabile per ogni valutazione.

Il processo di certificazione si suddivide inquattro fasi. Le prime tre fasi identificano ilprocesso di valutazione, l’ultima la fase di cer-tificazione.

Il processo di valutazione è, quindi, articola-to in:� preparazione;� conduzione;� conclusione.

Nella quarta e ultima fase, quella di certifi-cazione, l’Organismo di Certificazione esami-na il Rapporto Finale di Valutazione (RFV) elo utilizza come base per la produzione delRapporto di Certificazione e dell’eventualeCertificato, concludendo con questo atto ilprocesso di certificazione.

Nei paragrafi che seguono ciascuna delle 4fasi identificate viene descritta in dettaglio.

Fase di preparazione

Le attività di preparazione della valutazionesono svolte dall’LVS e dal Committente.

Il Committente chiede l’intervento dell’LVS,specificando il Traguardo di Sicurezza o il Pro-filo di Protezione richiesto.

Il Committente potrà ottenere dall’LVSl’indicazione del costo delle attività di valu-tazione.

Analoga indicazione potrà essere ottenutadall’Organismo di Certificazione per quantoriguarda l’attività di certificazione.

Si consiglia il Committente affinché:– tenga conto della necessità di ottenere colla-

borazione dal Fornitore per quanto riguardale informazioni tecniche e la documentazio-ne richieste per la valutazione;

– qualora l’ODV contenga componenti giàcertificati, si predisponga per reperire i do-cumenti più rilevanti del processo di certifi-cazione, in particolare, il Traguardo di Sicu-rezza e il Rapporto di Certificazione;

– tenga nella dovuta considerazione i costi peril mantenimento del Certificato nel tempo,quando previsto;

– ottenga la disponibilità dei risultati dalla va-lutazione, in modo da poterli riutilizzare ineventuali future attività di valutazione, certi-ficazione e mantenimento.

L’obiettivo della fase della preparazione èquello di stimare l’adeguatezza dell’ODV o delPP per la valutazione, prima dell’inizio dellafase di conduzione.

Questo processo è basato sui seguenti ele-menti:– individuazione del TDS;– determinazione della documentazione ne-

cessaria per sostenere la valutazione;accordo su un PDV;

– determinazione dello scopo della valutazio-ne e analisi delle responsabilità per assicura-re che tutte le parti in causa siano consape-voli dei loro compiti;

– accettazione formale dei requisiti previstidallo Schema per la valutazione.

Al Committente è richiesto di fornire il Tra-guardo di Sicurezza e gli ulteriori documentiche è necessario sviluppare ai fini della valuta-zione/certificazione. L’LVS esamina il Traguar-do di Sicurezza o il Profilo di Protezione al fi-


79Giugno 2004

– l’Organismo di Certificazione avrà ritenutoadeguati il Traguardo di Sicurezza e il PDVpresentati;

– il Committente avrà accettato di sostenerel’onere finanziario legato alle prestazionidell’Organismo di Certificazione per le atti-vità di certificazione.

L’Organismo di Certificazione comunicaformalmente all’LVS l’esito della richiesta di i-scrizione allo Schema, motivando adeguata-mente l’eventuale esito negativo e conferma glioneri dovuti all’OC per le fasi successive dellacertificazione. Tale comunicazione conclude lafase di preparazione della valutazione.

Successivamente alla comunicazione dell’e-sito della richiesta di iscrizione allo Schemal’LVS coinvolto notifica formalmente all’Orga-nismo di Certificazione l’effettivo inizio dellavalutazione, attraverso una Notifica di InizioLavori (NIL), dando così inizio alla fase diconduzione della valutazione.

In caso di esito positivo, si terrà normalmen-te una Riunione di Avvio dei Lavori (RAL) incui saranno coinvolti l’Organismo di Certifica-zione, il Committente, l’LVS e qualsiasi altraentità interessata, al fine di discutere qualsiasiaspetto che sia attinente alla valutazione, allacertificazione e alle specifiche dell’ODV. Taleriunione sarà convocata dall’OC di sua iniziati-va o su richiesta dell’LVS o del Committente,prima dell’inizio della effettiva fase di condu-zione della valutazione.

Fase di conduzione

I Valutatori effettuano l’attività di condu-zione della valutazione tecnica seguendo lemodalità dettagliate nel Piano di Valutazione.Questa attività implica la valutazione impar-ziale e dettagliata dell’ODV in accordo con icriteri di valutazione, al fine di determinare inche misura l’ODV realizzi il Traguardo di Si-curezza e di identificare eventuali vulnerabi-lità sfruttabili.

Se nel corso del lavoro di valutazione vengo-no rilevati incongruenze, errori o vulnerabilità,devono essere prodotti dei Rapporti di Osser-vazione che li descrivano in dettaglio. Al termi-


ne di accertare, sulla base anche di eventualeulteriore documentazione richiesta al Commit-tente, che IL TDS o PP costituisca una solidabase per la conduzione del processo di valuta-zione; ove necessario richiede modifiche.

Il Materiale per la Valutazione necessario al Va-lutatore 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, ge-

nerata o durante lo sviluppo dell’ODV o persostenere il processo di valutazione.

Per la produzione di tutti i tipi di documen-tazione relativi alla valutazione e certificazioneè obbligatorio l’uso della lingua italiana, conderoghe unicamente concesse a:– eventuali terminologie in lingua inglese, non

tradotte nel glossario di riferimento delloSchema, che siano utilizzate nei documentioriginali che descrivono i criteri e le meto-dologie

– documenti di valutazione e certificazione giàesistenti in lingua inglese.

Il Piano di Valutazione, che è preparato dal-l’LVS, specifica il lavoro che deve essere con-dotto dall’LVS stesso durante la valutazione.

Tale piano indirizza tutti gli aspetti che ri-guardano l’applicazione dei criteri e delle me-todologie per la valutazione dell’ODV, fornen-do inoltre tutte le scadenze temporali connessecon l’attività di valutazione proposta.

L’LVS chiede formalmente all’Organismo diCertificazione l’iscrizione della valutazionenello Schema, fornendo il Piano di Valutazionepredisposto. Contestualmente, il Committen-te, in modo diretto o attraverso l’LVS, docu-menta l’avvenuto pagamento dell’onere finan-ziario legato alle prestazioni dell’Organismo diCertificazione per l’analisi del PDV.

La valutazione sarà accettata formalmente sesussistono tutte le seguenti condizioni:– l’Organismo di Certificazione avrà ritenuto

adeguato che l’ODV o il PP venga valutato ecertificato nell’ambito dello Schema;

I quaderni di80

ne di ogni attività, l’LVS predispone dei Rap-porti di Attività che riassumono i risultati delleanalisi condotte per la specifica attività.

I risultati del lavoro di valutazione devonoessere documentati in modo continuativo alprocedere della valutazione stessa.

L’Organismo di Certificazione controlla o-gni valutazione, al fine di confermare che es-se siano effettuate in accordo con i criteri, imetodi e le procedure previste dallo Schema.Durante la fase di conduzione l’Organismodi Certificazione è coinvolto nelle seguentiattività:– se necessario, partecipa agli incontri sull’a-

vanzamento della valutazione;– se necessario, concorda con l’LVS il modo in

cui devono essere applicati i criteri per la va-lutazione di uno specifico ODV o PP;

– controlla i rapporti tecnici prodotti dai Va-lutatori durante il corso delle valutazioni;controlla i documenti di valutazione.

LVS e il Committente richiedono l’inter-vento dell’Organismo di Certificazione al ve-rificarsi di problemi per i quali è non è statopossibile individuare una soluzione o laddovesia necessaria una interpretazione dei criteri odelle metodologie. Se non è possibile risolve-re il problema e l’LVS decide che questa cir-costanza influisce negativamente sulla valuta-zione, l’LVS notifica formalmente il fatto alCommittente.

Fase di conclusione: il RapportoFinale di Valutazione

I Valutatori documentano la loro attività al-l’Organismo di Certificazione attraverso ilRapporto Finale di Valutazione, che rappre-senta il documento conclusivo del processo divalutazione e che raccoglie tutti i Rapporti diAttività e le considerazioni sulla valutazionesvolta. Le conclusioni documentate nel Rap-porto Finale di Valutazione dimostrano e de-scrivono il grado con cui i criteri di valutazionesono stati soddisfatti.

L’LVS rilascia il Rapporto Finale di Valuta-zione al Committente dopo aver verificato chenon contenga informazioni proprietarie.

Fase di certificazione

La fase di certificazione ha come obiettivol’emissione da parte dell’OC del Rapporto diCertificazione (RC) e dell’eventuale Certifica-to. A tal fine, l’Organismo di Certificazione e-samina il Rapporto Finale di Valutazione e,qualora riscontri la coerenza con i criteri, lametodologia ed i requisiti dello Schema, lo ap-prova. Nel caso in cui vengano individuatedelle anomalie risolvibili, l’Organismo di Cer-tificazione richiede l’intervento del Laborato-rio di Valutazione della Sicurezza per l’even-tuale perfezionamento del Rapporto Finale diValutazione.

Il Rapporto di Certificazione deve:– dichiarare se la valutazione è stata condotta

secondo i criteri e la metodologia previstadallo Schema nazionale;

– dichiarare se il Profilo di Protezione è com-pleto, congruente e tecnicamente corretto;

– dichiarare se il Traguardo di Sicurezza ècompleto, congruente e tecnicamente cor-retto;

– dichiarare se l’Oggetto della Valutazionesoddisfa il Traguardo di Sicurezza al livellodi garanzia richiesto;

– identificare le eventuali vulnerabilità sfrutta-bili ed eventualmente raccomandare dellecontromisure;

– motivare l’eventuale emissione di verdetti incontrasto con quelli dell’LVS.

Nel caso in cui nell’RFV si evidenzino dellevulnerabilità sfruttabili, il processo di certifica-zione non potrà essere completato con l’emis-sione del Certificato.

La versione definitiva del Rapporto di Certi-ficazione e il Certificato vengono emessi dal-l’Organismo di Certificazione.

La certificazione si riferisce solo agli a-spetti di sicurezza sottoposti a valutazione:questo implica il permanere di una proba-bilità non nulla che in un ODV certificatoesistano alcune vulnerabilità sfruttabili nonindividuate perché al di fuori degli aspettidi sicurezza sottoposti a valutazione e certi-ficazione.


81Giugno 2004

vità di monitoraggio, mantenendo sempre ag-giornata la lista delle vulnerabilità sfruttabili.

Giuseppe PierriDirigente Ufficio Informatica e Telematica

Ministero delle Comunicazioni - Istituto Superiore del-le Comunicazioni e delle Tecnologie dell’Informazione

Presidente del Comitato di Pianificazione e Controllo dell’Organismo di Certificazione


I risultati del processo di valutazione e certifi-cazione sono riferibili a una specifica e determi-nata configurazione dell’Oggetto della Valuta-zione: pertanto la commercializzazione di un si-stema/prodotto certificato è vincolata a tale con-figurazione. Al fine di espletare in modo adegua-to la funzione di controllo della validità dei Cer-tificati nel tempo, l’OC svolge una costante atti-

luppi; le industrie erano contrarie all’adozionedi criteri di sicurezza diversi in ogni paese; iconcetti e gli approcci di base adottati dai varipaesi coincidevano, anche per quanto riguardale varie applicazioni in ambito commerciale,governativo e militare. Uno dei motivi, quindi,dell’elaborazione di questi criteri comuni, chesono stati denominati Information TechnologySecurity Evaluation Criteria (ITSEC), è statola volontà di costituire una base comune perl’attività di certificazione svolta dagli organi-smi nazionali, con l’obiettivo finale di consen-tire il mutuo riconoscimento dei risultati dellevalutazioni.

Nel 1991 si è giunti ad una completa defi-nizione dei criteri ITSEC che sono stati nel-lo stesso anno fatti propri dalla ComunitàEuropea.

Ogni sistema o prodotto IT presenta requi-siti specifici, che ne garantiscono la riservatez-za, l’integrità e la disponibilità.

Per soddisfare tali requisiti occorre imple-mentare diverse misure tecniche di sicurezza,denominate funzioni di sicurezza riguardan-ti, a esempio, settori quali il controllo di ac-cesso, l’audit e il recupero da errore. Per IT-SEC, l’oggetto della valutazione è il TOE(Target of Evaluation) e lo sponsor è chi ri-chiede la valutazione.

Mentre i l Diparti-mento della Difesadegli Stati Uniti u-

tilizzava propri criteri per lavalutazione della sicurezzadei sistemi e prodotti IT inti-tolati Trusted Computer Sy-

stem Evaluation Criteria [TCSEC] e, comu-nemente, nota come Orange Book (Libro a-rancione), altri paesi europei hanno elaboratopropri criteri per la valutazione della sicurez-za dei prodotti IT. Nel Regno Unito, a esem-pio, è il caso del Memorandum Number 3, e-laborato a uso del governo, e delle propostedel Dipartimento dell’Industria e Commer-cio, denominate Green Book (Libro Verde).In Germania, l’Ente per la sicurezza del-l’informazione ha pubblicato, nel 1989, unaprima versione dei propri criteri; allo stessotempo, in Francia, sono stati elaborati criteridenominati Livre bleu-blanc-rouge (Librobianco, rosso e blu).

In seguito la Francia, la Germania, i PaesiBassi e il Regno Unito hanno riconosciuto lanecessità di accostarsi al problema in modo ar-monizzato e di definire criteri di sicurezza ITcomuni in quanto i singoli paesi avevano accu-mulato una vasta esperienza, su cui sarebbestato assai vantaggioso fondare gli ulteriori svi-

I quaderni di82

ITSEC: i criteri europei per la valutazione della sicurezza

informatica

Giovanni Desirò

La valutazione viene fatta prendendo a ri-ferimento il security target che è un docu-mento che deve contenere almeno: una Sy-stem Security Policy (nel caso dei sistemi) oun Product Rationale (nel caso dei prodotti);una specifica delle funzioni di sicurezza (Se-curity Enforcing Functions o SEF) che per-mettono il conseguimento degli obiettivi in-dividuati; la definizione dei meccanismi di si-curezza richiesti (opzionale); il livello minimodichiarato di robustezza dei meccanismi(strength of mechanisms); il livello di valuta-zione desiderato.

Col termine SEF (Security Enforcing Func-tion), si intendono le contromisure raggruppa-te secondo un certo numero di categorie, detteGeneric Headings.

La valutazione si basa sul concetto di garan-zia (assurance) offerta dal sistema stesso che sicaratterizza per: la correttezza (correctness)nel modo di concretizzare le funzioni di sicu-rezza e dei relativi meccanismi d’attuazione(mechanisms); la fiducia nella loro efficacia(effectiveness).

Le funzioni di sicurezza sono le contromisu-re di cui, in sede di redazione degli obiettivi disicurezza (Security Target), si decide l’adozio-ne e descrivono le contromisure in chiave con-cettuale con orientamento alla loro funziona-lità. Possono essere rappresentate sia da pro-dotti che da procedure di carattere organizza-tivo ed operativo. Le singole funzioni di sicu-rezza vengano raggruppate, in generic hea-dings. ITSEC prospetta otto tipologie di fun-zioni di sicurezza (generic headings) che co-munque possono essere integrate da nuove ti-pologie, con l’evoluzione delle tecnologie edelle tipologie d’attacco.Le tipologie indicateda ITSEC sono:

Identificazione ed Autentificazione (Identifi-cation and Authentication)

Stabiliscono e verificano l’identità che di-chiara un utente che intende accedere al siste-ma informatico. L’identificazione avviene u-sualmente controllando la corrispondenza trale informazioni fornite dall’utente e le infor-mazioni associate all’utente e note al sistema diprotezione.

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 informa-zioni fra processi e l’uso delle risorse da partedei processi stessi.

Autorizzazioni (Accountability)Registrano gli accessi alle varie risorse del si-

stema. A questo gruppo appartengono tutte lefunzioni che hanno lo scopo di lasciare tracciadelle azioni dei suoi utenti, in modo da ricono-scere chi ha operato.

Ispezioni (Audit)Permettono di indagare sugli eventi anomali

o sopra determinati livelli che possono rappre-sentare una minaccia alla sicurezza. A questogruppo appartengono le funzioni che hanno loscopo di registrare ed analizzare gli eventi, op-pure le funzioni che effettuano analisi statisti-che al fine di individuare eventuali attacchi allasicurezza.

Riutilizzo (Object Reuse)Garantiscono il riutilizzo di spazi di memo-

ria, impedendo che ciò costituisca minaccia al-la sicurezza. A questo gruppo appartengono lefunzioni il cui scopo è quello di cancellare o i-nizializzare i supporti in modo che possano es-sere riutilizzabili

Accuratezza (Accuracy)Garantiscono l’integrità del SW e dei dati. A

questo gruppo appartengono le funzioni il cuiscopo è quello di effettuare analisi del SW edei dati per segnalare, identificare e correggereeventuali violazioni

Ripristino del servizio (Reliability of Service)A questo gruppo appartengono le funzioni il

cui scopo è quello di assicurare che le risorse sia-no accessibili ed utilizzabili su richiesta di qua-lunque utente abilitato, entro i tempi prefissati

Scambio di dati (Data Exchange)A questo gruppo appartengono le funzio-

ni il cui scopo è quello di assicurare disponi-


83Giugno 2004

ALTA se può essere superata solo da aggres-sioni caratterizzate da un alto livello di esperien-za, opportunità e risorse, con attacchi portati consuccesso al di sopra della normale praticabilità.

Nel documento ITSEM (Annex 6.C) vengo-no definite le modalità di determinazione delgrado di robustezza del meccanismo basate su:

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

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

esperienza tecnica necessaria (diffusa, pro-fessionale, esperto);

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

I livelli previsti variano da E0 ad E6, secon-do crescenti livelli di fiducia.

La normativa ITSEC prevede la valutazionedell’efficacia e della correttezza del sistema diprotezione.

Al crescere del livello di valutazione deside-rato, lo sponsor deve fornire al valutatore do-cumentazione che attesti un crescente rigore el’introduzione di strumenti formali nelle variefasi costruttive.

Il processo di sviluppo è stato logicamentesuddiviso 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 presentaredocumentazione adeguata al livello di prote-zione desiderato.

Al livello E1, il Security Target deve descri-vere per sommi capi il modo con cui le funzio-ni di sicurezza proposte soddisfano gli obietti-vi di sicurezza e contrastano le minacce.

Al Livello E6, il Security target deve fornireuna dettagliata spiegazione (to explain) delmodo con cui le funzioni di sicurezza soddisfa-


bilità, riservatezza ed integrità ai canali tra-smissivi.

Con il termine Assurance si intende sia la fi-ducia (confidence) nell’efficacia (effectiveness)delle funzioni di sicurezza, sia la fiducia nellaloro correttezza (correctness).

La valutazione dell’efficacia mira a stabilire,tra l’altro, se le funzioni di sicurezza adottatesono idonee agli scopi -specificati nel SecurityTarget- per cui sono state scelte e se i meccani-smi che realizzano tali funzioni sono in gradodi contrastare attacchi diretti.

Quest’ultimo aspetto viene misurato sullabase della cosiddetta “robustezza dei meccani-smi” (strenght of mechanisms) per la quale so-no stati definiti tre livelli: Base, Medio e Alto.

La fiducia nella correttezza viene espressa u-tilizzando una scala a sette livelli (da E0 ad E6)nella quale il livello più basso indica totalemancanza di fiducia.

Il processo di valutazione ai fini di una certi-ficazione del sistema stesso consisterà nellostabilire se esso soddisfa o meno il suo SecurityTarget con il livello di valutazione dichiaratodel committente (ITSEC lo definisce Sponsor)e indicato nel Security Target stesso.

ITSEC definisce la robustezza dei meccani-smi di sicurezza (Strenght of Mechanism -SOM) come la loro capacità di resistere ad unattacco diretto.

Vengono definiti tre possibili gradi di robu-stezza (Base, Medio e Alto) che rappresentanocrescenti livelli di capacità del meccanismo disicurezza di resistere ad un attacco diretto.

Nel rispetto di quanto contenuto in ITSECla robustezza, di un meccanismo di sicurezzacritico può essere definita come:

BASE se al minimo fornisce protezione con-tro eventi sovversivi casuali, benché possa es-sere violata da alcuni aggressori;

MEDIA se al minimo fornisce protezionecontro aggressioni caratterizzate da limitateopportunità o risorse;

I quaderni di84

no gli obiettivi di sicurezza e contrastano le mi-nacce e della congruenza tra la politica di sicu-rezza ed il modello formale di sicurezza realiz-zato dal sistema di protezione.

Il progetto architetturaleAl livello E1, lo sponsor deve fornire una

descrizione informale dell’architettura genera-le del sistema. Al livello E6, la descrizione deveessere di tipo formale e deve includere unadettagliata spiegazione che convinca della con-gruità tra la politica di sicurezza e l’architettu-ra del sistema.

Il progetto dettagliatoAl livello E1, lo sponsor non deve fornire al-

cuna informazione, mentre ai livelli successivila documentazione deve essere costituita da undettagliato progetto del sistema (il livello didettaglio deve essere tale da poter essere utiliz-zato come base per la programmazione e co-struzione dello hardware. Più precisamente, al

livello E2 è richiesta una descrizione informa-le, mentre dal livello E4 in avanti, tale descri-zione deve essere di tipo semi-formale.

La RealizzazioneAl livello E1, lo sponsor non è tenuto a for-

nire alcuna documentazione.Ai livelli più elevati, lo sponsor deve fornire

una raccolta di test usati per verificare la cor-rettezza delle funzioni di sicurezza, e argomen-tare l’adeguatezza dei test scelti. Inoltre, dal li-vello E2 in avanti la documentazione fornitadeve comprovare, a crescenti livelli di ap-profondimento, anche la corrispondenza tra ilprogetto dettagliato e il software e lo hardwareche 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

L ’istituzione dello Schema Nazionaleper la certificazione della sicurezzadei sistemi e dei prodotti nel settore

della tecnologia dell’informazione (di segui-to denominato “Schema nazionale”), avve-nuta attraverso un DPCM adottato dal Mini-stro per l’Innovazione e le Tecnologie diconcerto con i Ministri delle Comunicazioni,delle Attività Produttive e dell’Economia edelle Finanze, si pone come naturale terminedi un percorso che è stato individuato e se-guito in questi ultimi anni anche da numero-si altri stati nazionali, sia in Europa sia nelresto del mondo.

In questo contesto il decreto:– ravvisa la necessità di indivi-

duare un Organismo di Certifi-cazione e di definire lo Schemanazionale, specificando l’insie-me delle procedure e delle re-gole nazionali necessarie per la valutazione ecertificazione, in conformità ai criteri euro-pei ITSEC (Information Technology Secu-rity Evaluation Criteria) [ITS1] o agli stan-dard internazionali CC (Common Criteria)[ISO1,2,3], emanati dall’ISO;

– definisce, nell’ambito dello Schema naziona-le, la ‘sicurezza nel settore della tecnologia


85Giugno 2004

Marco Carbonelli


sere schematicamente riportati i seguenti puntifondamentali:– la risoluzione del Consiglio dell’Unione

Europea del 6 dicembre 2001 relativa adun approccio comune e ad azioni specifi-che nel settore della sicurezza delle reti edell’informazione;

– la decisione della Commissione Europea del6 novembre 2000 (2000/709/CE) relativa aicriteri minimi di cui devono tener conto gliStati membri all’atto di designare gli organi-smi di cui all’articolo 3, paragrafo 4, delladirettiva 1999/93/CE del Parlamento Euro-peo e del Consiglio, relativa ad un quadrocomunitario per le firme elettroniche;

– il varo delle norme UNI CEI EN ISO/IEC17025 concernenti i requisiti generali per lacompetenza dei laboratori di prova e di tara-tura e UNI CEI EN 45011 concernenti i re-quisiti generali relativi agli organismi che ge-stiscono sistemi di certificazione di prodotti;

– l’esistenza dei criteri ITSEC, dal giugno1991, e ITSEM (Information TechnologySecurity Evaluation Manual) [ITS2], dal set-tembre 1993;

– la raccomandazione del Consiglio dell’Unio-ne Europea (95/144/CE) in data 7 aprile1995, concernente l’applicazione dei criteriper la valutazione della sicurezza della tec-nologia dell’informazione ITSEC;

– l’atto del Comitato di gestione dell’ISO (In-ternational Standard Organization) che defi-nisce come International Standard ISO/IEC15408 i “Common Criteria for InformationTechnology Security Evaluation”.

Risulta chiaro come l’istituzione dell’Orga-nismo di Certificazione italiano fosse, alla lucedelle informazioni dettagliate in precedenza,un atto non più procrastinabile, in considera-zione anche delle importanti ricadute econo-miche che la presenza di tale Organismo potràindurre sul mercato tecnologico, sia interno siaestero, legato ai sistemi e prodotti dotati difunzionalità di sicurezza in ambito informaticoche si utilizzano sia nella pubblica amministra-zione, sia nelle aziende, sia di uso privato.

Il decreto riconosce che l’Istituto Superioredelle Comunicazioni e delle Tecnologie del-


dell’informazione’ come la protezione dellariservatezza, integrità, disponibilità delleinformazioni mediante il contrasto delle mi-nacce originate dall’uomo o dall’ambiente,al fine di impedire, a coloro che non sianostati autorizzati, l’accesso, l’utilizzo, la divul-gazione, la modifica delle informazioni stes-se e di garantirne l’accesso e l’utilizzo a colo-ro che siano stati autorizzati.

Le motivazioni

Molte sono le motivazioni che hanno indot-to all’istituzione dello Schema nazionale in Ita-lia e in vari stati dell’occidente industrializzato:vediamo di analizzare alcune di queste.

L’informazione, nell’attuale società, costitui-sce un bene essenziale e si rende necessario ga-rantirne l’integrità, la disponibilità e la riserva-tezza con misure di sicurezza che costituiscanoparte integrante di un sistema informatico.

Da tempo i produttori offrono sistemi e pro-dotti dotati di funzionalità di sicurezza, per lequali dichiarano caratteristiche e prestazioni alfine di orientare gli utenti nella scelta delle solu-zioni più idonee a soddisfare le proprie esigenze.

In molte applicazioni caratterizzate da un e-levato grado di criticità, le predette dichiarazio-ni potrebbero risultare non sufficienti, renden-do necessaria una loro valutazione e certificazio-ne della sicurezza, condotte da soggetti indipen-denti e qualificati, sulla base di standard ricono-sciuti a livello nazionale ed internazionale.

Le garanzie concernenti l’adeguatezza, laqualità e l’efficacia dei dispositivi di sicurezzadi un sistema informatico possono essere for-nite solo da certificatori e valutatori indipen-denti ed imparziali.

La necessità di favorire, a livello comunitarioe internazionale, la cooperazione tra gli Organi-smi di Certificazione e il mutuo riconoscimentodei certificati di valutazione della sicurezza nelsettore della tecnologia dell’informazione.

I punti fondamentali

Accanto alle motivazioni elencate e a corol-lario normativo e politico della scelta di istitui-re un Organismo di Certificazione possono es-

I quaderni di86

l’informazione (ISCTI) del Ministero delle Co-municazioni possiede i requisiti di indipenden-za, affidabilità e competenza tecnica richiestidalla decisione della Commissione Europeadel 6 novembre 2000 (2000/709/CE) e stabili-sce che:“l’ISCTI è l’Organismo di Certificazione dellasicurezza nel settore della tecnologia dell’infor-mazione, anche ai sensi dell’articolo 10 del de-creto legislativo 23 gennaio 2002, n. 10 e del-l’articolo 3, paragrafo 4 della direttiva1999/93/CE”.

Per consentire l’applicazione dello Schemanazionale l’Organismo di Certificazione hapredisposto le “Linee Guida Provvisorie”(LGP). Sarà compito dell’Organismo di Certi-ficazione predisporre entro 12 mesi dalla pub-blicazione del decreto (avvenuta il 26 aprile2004), le “Linee Guida Definitive”, recanti in-dicazioni dettagliate relative allo svolgimentodelle attività di valutazione e certificazione.

Le Linee Guida Provvisorie

Le Linee Guida Provvisorie sono organizza-te in documenti distinti che individuano le a-ree fondamentali in cui l’Organismo di Certifi-cazione sarà chiamato ad agire e descrivono leazioni che i Valutatori dovranno intraprendereper condurre le attività di valutazione in modocorretto (cioè coerentemente on gli standrd in-ternazionali adottati) ed efficace. Nel seguitosono sinteticamente descritti i contenuti delleLinee Guida Provvisorie.

LGP1 - Descrizione generale dello Schemanazionale di valutazione e certificazione dellasicurezza

La LGP1, dopo aver introdotto il concetto diSchema nazionale, di sicurezza IT e di accredi-tamento dei laboratori, affronta una descrizionesintetica del processo di valutazione, identifi-cando le finalità e i requisiti generali per svolge-re una valutazione e certificazione di un siste-ma/prodotto o Profilo di Protezione (PP).Quindi, vengono definiti e descritti i ruoli deisoggetti coinvolti nel processo di valutazione ecertificazione, con particolare enfasi per l’Orga-

nismo di Certificazione, il Laboratorio per laValutazione delle Sicurezza (LVS), il Commit-tente, il Fornitore e l’Assistente. Inoltre, vengo-no delineate le tre fasi che caratterizzano il pro-cesso di valutazione: la preparazione, la condu-zione e la conclusione. Infine, viene delineata lafase di certificazione e si forniscono delle infor-mazioni per quanto concerne la gestione deiCertificati e il loro mantenimento.

LGP2 - Accreditamento degli LVS e abilitazio-ne degli Assistenti

La LGP2 definisce le procedure per ottene-re e mantenere nel corso del tempo l’accredita-mento di un Laboratorio per la Valutazionedella Sicurezza informatica secondo lo Schemanazionale per la valutazione e certificazionedella sicurezza nel settore della tecnologia del-l’informazione. Inoltre, vengono specificati gliambiti di attività di un LVS e descritti i requisi-ti generali gestionali e di competenza tecnicaper i laboratori. Infine, vengono descritti i re-quisiti e le procedure per ottenere l’abilitazio-ne al ruolo di Assistente.

LGP3 - Procedure di valutazioneLa LGP3 definisce le procedure che devono

essere seguite nel corso di un processo di valu-tazione condotto all’interno dello Schema. Ta-le processo è suddiviso in tre fasi distinte: pre-parazione, conduzione e conclusione. Le pro-cedure descritte in questa linea guida sono ap-plicabili alla valutazione della sicurezza di unsistema/prodotto o di un PP, così come definitiin ITSEC o nei Common Criteria, e descrivo-no le modalità secondo cui effettuare:– le comunicazioni tra un LVS, un Commit-

tente, un Fornitore e l’OC;– l’organizzazione e la pianificazione delle at-

tività di una valutazione;– la finalità e il contenuto delle diverse tipolo-

gie di rapporti prodotti nel corso della valu-tazione;

– il controllo di una valutazione;– la pubblicazione dei risultati di una valu-

tazione;– la chiusura della valutazione e il processo di

certificazione con il rilascio da parte del-l’OC del Certificato.


87Giugno 2004

LGP6 – Guida alla scrittura dei Profili di Prote-zione e dei Traguardi di Sicurezza

Nella LGP6 sono fornite indicazioni per lascrittura dei Profili di Protezione (PP) e deiTraguardi di Sicurezza (TDS) secondo le nor-me fissate dai Common Criteria.

Questa LGP è indirizzata principalmente acoloro che sono coinvolti nello sviluppo deiPP/TDS. Tuttavia, può anche essere utile aiValutatori e ai responsabili della definizione edel controllo della metodologia per la valuta-zione dei PP/TDS. Gli utenti finali possono al-tresì trovare utile questo documento per com-prendere i PP/TDS o per individuare le partidi loro interesse.

Viene dapprima fornita una panoramica suiPP/TDS, che comprende un indice di riferi-mento; vengono quindi descritte in dettaglio lesezioni del PP/TDS.

Infine, sono riportate alcune appendici cheapprofondiscono aspetti di particolare rilievo,tra cui la descrizione di esempi di minacce, po-litiche di sicurezza, assunzioni e obiettivi di si-curezza, e l’identificazione di adeguati compo-nenti funzionali per specificare i requisiti fun-zionali di sicurezza.

LGP7 – Glossario e terminologia di riferimentoNella LGP7 sono raccolte tutte le definizioni

in uso nello Schema nazionale. Inoltre, è fornitoun elenco di termini di uso comune che assumo-no un significato specifico nei Common Criteria.

Concludendo, l’occasione che l’istituzione del-l’Organismo di Certificazione offre al mercatodei sistemi e prodotti informatici e quella di com-piere un considerevole balzo in avanti nell’areadella sicurezza informatica, area che viene sem-pre più diffusamente percepita come un ambitocritico, in cui l’utente ha sempre maggiore neces-sità di dover essere tutelato e di sentirsi realmen-te assicurato sull’uso, senza rischi occulti, delletecnologie e delle applicazioni informatiche.

Marco CarbonelliFondazione Ugo Bordoni

Responsabile sviluppo Linee guida provvisoriedello Schema nazionale


LGP4 – Attività di valutazione secondo i Com-mon Criteria

La LGP4 si prefigge l’obiettivo di definire laterminologia di riferimento in lingua italianaper descrivere, discutere e analizzare le azionirichieste per svolgere la valutazione di un Pro-filo di Protezione e la valutazione di un ODVai livelli di fiducia EAL1, EAL2, EAL3 eEAL4 secondo i Common Criteria.

La LGP4 contiene informazioni utili agliutenti finali di prodotti/sistemi IT che sonostati sottoposti al processo di valutazione, alpersonale direttamente responsabile dellavalutazione di un ODV o di un Profilo diProtezione, al personale che fornisce assi-stenza al Committente di una valutazione, alpersonale responsabile della stesura di unTraguardo di Sicurezza o di un Profilo diProtezione, e agli sviluppatori di prodotti/si-stemi IT che sono interessati a richiedere lavalutazione e la certificazione dei loro pro-dotti/sistemi.

LGP5 - Il Piano di Valutazione: indicazioni ge-nerali

La LGP5 fornisce ai Valutatori gli elementifondamentali per definire, in base ai Criteri divalutazione ITSEC e Common Criteria, unPiano Di Valutazione (PDV) della Sicurezzadi un sistema/prodotto o di un PP. Il PDV è ildocumento che contiene la descrizione di tut-te le attività che i Valutatori debbono esegui-re durante la valutazione e le modalità secon-do le quali queste attività risultano organizza-te, pianificate, correlate e suddivise nell’am-bito del periodo di valutazione.

La necessità di fornire delle istruzioni per ladefinizione di un PDV nasce dall’esigenza disoddisfare più requisiti, quali:– armonizzare tutta la documentazione e le

procedure di valutazione alla normativa in-ternazionale e nazionale in vigore;

– rendere omogenei e confrontabili i PDVprodotti da LVS diversi;

– garantire, mediante il rispetto delle LineeGuida, l’obiettività, l’imparzialità, la ripetiti-vità e la riproducibilità delle attività di valu-tazione indicate in un PDV.

I quaderni di88

I concetti di base

Nel limitato spazio disponibile nonsarebbe possibile riportare unadescrizione anche sommaria delle

varie parti che compongono i Common Cri-teria (denominati CC nel seguito per bre-vità). Quand’anche ci si provasse, peraltro,si sarebbe obbligati ad introdurre un grannumero definizioni che non potrebberoessere diffusamente illustrate, correndocosì il rischio di produrre una sintesi pocochiara nella quale gli elementi veramenteimportanti che sono alla base di questi cri-teri potrebbero risultare poco evidenti. Inquesto paragrafo ci si l imiterà quindi adescrivere l’approccio secondo il quale iCC sono stati sviluppati, mirando princi-palmente a fornire quegli elementi informa-tivi che consentono una adeguata compren-sione del successivo paragrafo dedicato aduna descrizione dei vantaggi e degli svan-taggi di questi criteri.

La filosofia che è alla base dei CC è stataripresa dai precedenti cr i teri europeiITSEC (Information Technology SecurityEvaluation Criteria) che per primi l’hannointrodotta. In base a tale filosofia non hasenso 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 (requi-

siti di assurance).

Tra parentesi sono stati indicati alcuni ter-mini che sono utilizzati nell’ambito dei CC eche consentono di esprimere nel seguentemodo lo scopo di una valutazione secondotali criteri: offrire garanzie, che vengonoprodotte dal soddisfacimento dei requisiti di

assurance e che risultano crescenti con illivello di valutazione, sulla capacità del siste-ma/prodotto di soddisfare i propri obiettividi sicurezza nell’ambiente di sicurezza peresso ipotizzato.

Un obiettivo di sicurezza viene definito,secondo i CC, come l’intenzione di contra-stare una minaccia o quella di rispettare leg-gi, regolamenti o politiche di sicurezza pree-sistenti. Il conseguimento degli obiettiviavviene attraverso l’adozione di misure disicurezza tecniche (funzioni di sicurezza) enon tecniche (fisiche, procedurali e relativeal personale).

L’ambiente di sicurezza viene descritto intermini di:– uso ipotizzato del sistema/prodotto

(applicazioni, utenti, informazioni trattateed altri beni con specifica del relativovalore)

– ambiente di utilizzo (misure di sicurezzanon tecniche, collegamento con altriapparati ICT)

– minacce da contrastare, specificandocaratteristiche dell’attaccante (conoscen-ze, risorse disponibili e motivazione),metodi di attacco (citando, tra l’altro, losfruttamento di eventuali vulnerabilitànote del sistema/prodotto ICT), benicolpiti

– politiche di sicurezza dell’Organizzazione.

Le verifiche previste durante il processodi valutazione mirano ad accertare che sianostati soddisfatti, da parte del sistema/pro-dotto, del suo sviluppatore e del valutatore,opportuni requisiti di assurance che diventa-no sempre più severi al crescere del livellodi valutazione. I CC definiscono una scala di7 livelli di valutazione (EAL1, EAL2, …,EAL7) o livelli di assurance, precisando, per


89Giugno 2004

Lo standard Common Criteria(ISO/IEC IS 15408)

Al crescere del livello di valutazione:– vengono richieste specifiche realizzative

più dettagliate (ad esempio progetto adalto livello, progetto a basso livello, codi-ce sorgente)

– il livello di rigore con il quale le specifichedevono essere descritte aumenta (descri-zione informale, semiformale, formale).

Il rigore della valutazione, così come neicriteri ITSEC, non viene individuato solodal livello di valutazione bensì anche da unaltro parametro. Infatti per le funzioni chedevono essere realizzate con meccanismiprobabilistici o di permutazione (password,funzioni hash, etc.), i CC richiedono (a parti-re da EAL2) che venga specificato un livellominimo di robustezza (SOF - Strength OfFunctionality) su una scala a tre valori (basic,medium, high).

Le funzioni di sicurezza del sistema/pro-dotto vengono descritte in base ai requisiticui devono soddisfare. Tali requisiti, deno-minati requisiti funzionali, così come i giàcitati requisiti di assurance, devono essereespressi (a meno di possibili eccezioni cheoccorre comunque giustificare) utilizzandoun catalogo di componenti fornito nei CC.Più precisamente il catalogo delle compo-nenti funzionali costituisce la parte 2 deiCC , mentre quello delle componenti diassurance la parte 3. I cataloghi sono strut-turati su più livelli gerarchici in modo daraccogliere componenti di tipo omogeneo.A titolo di esempio, per quanto riguarda lecomponenti funzionali, al livello gerarchicopiù elevato è previsto un raggruppamentosecondo le unidici classi di seguito specifi-cate: Audit, Communication, CryptographicSupport, User Data Protection, Identifica-tion and Authentication, Security manage-ment, Privacy, Protection of the TOE Secu-rity Function, Resource Utilization, TOEAccess, Trusted Path/Channels (l’acronimoTOE ricorrente in alcuni nomi di classifunzionali indica il sistema/prodotto ICTda valutare).

Tra i numerosi documenti che il richieden-te della valutazione deve/può consegnare ai


ogni livello di tale scala uno specifico insie-me di requisiti di assurance. Il livello EAL1,cui corrisponde il livello di sicurezza piùbasso, non ha corrispondenti nei precedenticriteri di valutazione.

Le verifiche, eseguite in base ai requisiti diassurance del livello di valutazione considera-to, hanno lo scopo di fornire garanzie circa:– l’idoneità delle funzioni di sicurezza a

soddisfare gli obiettivi di sicurezza delsistema/prodotto;

– l’assenza di errori nel processo che dallespecifiche iniziali di sicurezza (ambiente eobiettivi di sicurezza) porta alla praticarealizzazione delle funzioni di sicurezza(errori di interpretazione delle specifichetecniche, errori di programmazione, ecc);

– l’adeguatezza delle procedure di sicurez-za previste per la consegna e per l’instal-lazione del sistema/prodotto (per evitareche i l s istema/prodotto che pervieneall’utente finale possa differire, magarianche di poco, da quello sottoposto avalutazione/certificazione), la chiarezzadei manuali d’uso e d’amministrazione(questi ultimi potrebbero infatti indurregli uti l izzatori a comportamenti cheintroducono vulnerabilità nell’utilizzo diun prodotto/sistema dotato di funzionidi sicurezza del tutto idonee e realizzatesenza errori), il supporto che lo svilup-patore si impegna a fornire a chi usa ils istema o prodotto per rimediare adeventuali vulnerabilità emerse dopo lavalutazione.

Con riferimento al punto 2) può essereinteressante precisare che le garanzie circal’assenza di errori nel processo di realizza-zione delle funzioni di sicurezza non vengo-no ottenute solamente ricercando diretta-mente gli errori stessi (analizzando la docu-mentazione presentata dal richiedente dellavalutazione e sottoponendo il sistema/pro-dotto a test funzionali e ad attacchi), bensìanche verificando che nel processo di realiz-zazione sia stato previsto l’impiego di stru-menti, metodologie e procedure finalizzatialla riduzione della probabilità di errori.

I quaderni di90

valutatori, unitamente al sistema/prodottoICT da valutare, due meritano un particolarecenno. Il primo, denominato Security Target,deve essere obbligatoriamente fornito e rap-presenta il documento principale della valu-tazione. Nel Securuty Target devono esseredescritti l’ambiente di sicurezza, gli obiettividi sicurezza, i requisiti funzionali e di assu-rance (e quindi il livello di valutazione), larobustezza minima delle funzioni di sicurez-za ed una prima descrizione ad alto livellodelle funzioni di sicurezza. Quest’ultimasezione non è invece contenuta nel secondodocumento, il Protection Profile, che per ilresto ha una struttura del tutto simile a quel-la del Security Target. Il Protection Profilepuò essere opzionalmente sviluppato conriferimento ad un’intera classe di prodotti(per la quale si lascia la libertà di realizzare lefunzioni di sicurezza in un qualsiasi modoche soddisfi i requisiti funzionali) piuttostoche con riferimento ad uno specifico siste-ma/prodotto ICT (come è il caso, invece, delSecurity Target). Il Protection Profile, che puòessere registrato e anche valutato per verifi-carne la coerenza interna.

I pro e i contro

In questo paragrafo verranno descritti iprincipali vantaggi e svantaggi derivanti dal-l’applicazione dei CC. In realtà, come appa-rirà più chiaro nel seguito, gran parte di essipossono essere considerati comuni a tutte leraccolte di criteri di valutazione fin qui svi-luppate. Per quanto riguarda i vantaggi sipossono citare:– la verifica, eseguita da una terza parte per

la quale viene riconosciuto il possesso diconoscenze specialistiche, che le funziona-lità di sicurezza del sistema/prodotto ICT,affiancate alle contromisure non tecnichepreviste, siano adeguate al soddisfacimen-to degli obiettivi di sicurezza;

– lo svolgimento di un’azione di contrastopreventivo degli incidenti di sicurezza ICT;

– le maggiori garanzie che i CC offronorispetto ad altri strumenti di contrasto ditipo preventivo;

– la disponibilità di vasti cataloghi relativa-mente alle funzionalità di sicurezza ICT eai requisiti di assurance adottabili;

– la possibilità di esprimere in forma stan-dardizzata requisiti di sicurezza per siste-mi e prodotti ICT.

Detto questo riguardo ai vantaggi che l’ap-plicazione dei CC può portare, vediamo oraquelli che possono essere considerati glisvantaggi. 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 confi-gurazione certificata.

È opportuno tuttavia precisare subito chei primi due svantaggi si riferiscono allemodalità d’impiego tipiche dei criteri nelcontesto della sicurezza nazionale, ossiaquando viene previsto un livello di valuta-zione non inferiore a EAL3. In tali casi,infatti, lo svantaggio citato al punto a) deri-va dall’obbligo per chi richiede la valutazio-ne di predisporre una notevole mole didocumentazione e dal tempo necessario aivalutatori per analizzare tale documentazio-ne ed eseguire tutte le numerose e comples-se azioni che i criteri pongono a loro carico.Conseguenza di questo stato di cose è chenon di rado quando il processo termina è giàdisponibile una nuova versione del siste-ma/prodotto ICT. Inoltre possono nasceredifficoltà relativamente all’utilizzazione diprodotti certificati nelle architetture hw/swpiù recenti.

Per quanto riguarda il punto b) si puòdire che il costo elevato risulta una direttaconseguenza, oltre che dei lunghi tempi diesecuzione, anche delle risorse non trascura-bili dal punto di vista sia qualitativo siaquantitativo che durante l’esecuzione delprocesso è necessario impegnare.

Se invece vengono utilizzati i primi livellidi valutazione, il che può essere adeguato inmolte situazioni di pratico interesse, gli svan-taggi descritti ai punti a) e b) tendono a


91Giugno 2004

mentre ora sono disponibili in un documen-to separato sviluppato ai fini del mutuo rico-noscimento internazionale). In taluni casi,peraltro, ossia quando mediante una oppor-tuna analisi si sia potuto stabilire che gliaggiornamenti hw/sw non possono compro-mettere il buon funzionamento delle partipiù critiche del sistema/prodotto ICT, puòessere sufficiente una integrazione delladocumentazione di valutazione, piuttostoche una riesecuzione di attività da parte deivalutatori.

Conclusioni

L’utilizzo dei Common Criteria per lavalutazione e certificazione di sistemi/pro-dotti ICT consente di ottenere garanzie cir-ca il livello di sicurezza di tali sistemi/pro-dotti che possono essere ancor più graduaterispetto a quanto possibile con i precedenticriteri. In particolare l’utilizzo dei primilivelli di valutazione e dei requisiti previsti aifini del mantenimento nel tempo delle certi-ficazioni sembra in grado di soddisfare leesigenze di protezione frequentementeincontrate fuori del contesto della sicurezzanazionale, ossia in situazioni di rischio infor-matico non particolarmente elevato. A talriguardo, ad esempio, saranno eseguibili concosti e tempi limitati certificazioni chegarantiscano da un lato la capacità delle fun-zioni di sicurezza dell’oggetto certificato disoddisfare, nel contesto utilizzativo descritto(ambiente di sicurezza), gli obiettivi di sicu-rezza dichiarati, dall’altro, come risultatominimo, l’eliminazione di tutte le vulnerabi-lità note da cui fosse affetto l’oggetto stesso.

Franco GuidaFondazione Ugo Bordoni

Membro del Comitato tecnico nazionale sulla sicurezza informatica e delle telecomunicazioni


Coordinatore Area Operativa dell’Organismo di Certificazione


scomparire. Al riguardo si può peraltro ricor-dare che proprio con i CC è stato aggiunto unlivello iniziale di valutazione che non trovacorrispondenze nei precedenti criteri di valu-tazione e che è caratterizzato da tempi e costialquanto contenuti. Quando tale livello vieneutilizzato la collaborazione richiesta al sog-getto che ha sviluppato l’oggetto della valuta-zione è praticamente nulla e risulta quindipossibile valutare e certificare anche compo-nenti di un sistema ICT per le quali risultamolto difficile ottenere informazioni proget-tuali che consentano la scrittura della docu-mentazione prevista ai livelli di valutazionemedi e alti. Ovviamente in tale caso divienepiù difficile per i valutatori individuare even-tuali vulnerabilità, dato che non dispongonopiù (o ne dispongono in misura alquantolimitata) di informazioni, normalmente nonaccessibili fuori dell’ambiente di sviluppo (adesempio i valutatori possono avere accesso alcodice sorgente di un prodotto commerciale),relative alla struttura interna delle funzioni disicurezza. Tuttavia la certificazione al livellominimo EAL1 già garantisce l’eliminazione(tipicamente mediante l’installazione di appo-site patch) di eventuali vulnerabilità dell’og-getto della valutazione che siano già note. Dallivello EAL2 in su, il valutatore tenterà anchedi violare l’oggetto della valutazione utiliz-zando tecniche di attacco diverse da quelleche consentono di sfruttare le vulnerabilitàgià note.

Riguardo al punto c) è opportuno invecesottolineare che una delle implicazioni piùdirette che crea notevoli difficoltà è l’impos-sibilità di installare le patch senza prevedereuna nuova certificazione del sistema/prodot-to ICT. Quest’ultima può essere però resarelativamente veloce e non troppo costosa(anche a livelli di valutazione medi ed alti)seguendo le indicazioni relative al manteni-mento nel tempo della certificazione (taliindicazioni nella prima versione dei CC era-no presenti in un’apposita classe di assuran-ce denominata Maintenance of assurance

I quaderni di92

A cura di Alberto Mucci ANCHE L’ITALIA SI DOTA DI · A cura di Alberto Mucci Supplemento al...

Documents

Transcript of A cura di Alberto Mucci ANCHE L’ITALIA SI DOTA DI · A cura di Alberto Mucci Supplemento al...