Il ruolo dei LVS nella
sicurezza di prodotti e
sistemi ICT
Franco Soresina
Responsabile del Laboratorio
Concetto di sicurezza aziendale
“Studio, sviluppo e attuazione delle strategie, delle
politiche e dei piani operativi volti a prevenire,
fronteggiare e superare eventi in prevalenza di natura
dolosa e/o colposa che possano danneggiare le risorse
materiali, immateriali, organizzative ed umane di cui
l’azienda dispone o di cui necessita per garantirsi
un’adeguata capacità concorrenziale nel breve, nel
medio e nel lungo termine.”
Definizione di security aziendale tratta dalla norma UNI 10459, punto 3.1
2
Principali componenti





Sicurezza delle attività, dei processi,
dell’organizzazione
Sicurezza dei prodotti e dei sistemi informatici
Sicurezza fisica
Competenza del personale addetto alla sicurezza
Diffusione della cultura della sicurezza


Informazione
Formazione
3
Principi per la sicurezza delle informazioni
1. Quali
informazioni?
8. Il miglioramento
continuo
7. Conformità agli
Standard più
diffusi
2. La sicurezza dei
processi
SI
6. La diffusione
della cultura della
Roma, 22sicurezza
maggio 2006
3. La sicurezza di
prodotti e sistemi
informatici
4. La sicurezza
fisica
5. La competenza
del personale
addetto
Riferimenti a Standard

Sicurezza organizzativa: ISO/IEC 27001
 Sicurezza prodotti e sistemi informatici: ISO/IEC
15408
 Sicurezza fisica: omologazioni, conformità,
certificazioni di impianto
 Competenza del personale: certificazioni relative al
personale (CISA, CISSP, CISM, ….)
5
Standard ISO/IEC 15408 (Common Criteria)
I Common Crieria sono uno strumento per definire i
requisiti di sicurezza di prodotti (HW e SW) e sistemi
ICT. Essi forniscono:
 una metodica con cui valutare la consistenza, la
congruenza, la completezza di requisiti di sicurezza
messi a punto per specifici sistemi informatici o per
classi di sistemi;
 i criteri d’esplicitazione dei processi di accertamento
con cui si acclara la sicurezza di sistemi informatici
approntati a fronte di specifiche note a priori.
6
Common Criteria
Con i CC risulta possibile approntare due differenti classi
di documenti:
 Protection Profile (PP) con cui esprimere la sicurezza
attesa da un prodotto/sistema (tipicamente ancora da
approntare) finalizzato all’erogazione di un servizio ICT
 Security Target (ST) con cui asserire la sicurezza
offerta da un prodotto/sistema (tipicamente già
disponibile) per l’erogazione di un servizio
7
Atto costitutivo degli LVS
Lo “Schema Nazionale per la valutazione e certificazione della
sicurezza di sistemi e prodotti nel settore della tecnologia
dell'informazione”
 ha istituito l’Organismo di Certificazione della Sicurezza
informatica (OCSI) come unico Ente autorizzato a Certificare
prodotti e sistemi IT
 ha definito i requisiti organizzativi e di competenza per
accreditare i Laboratori di Valutazione della Sicurezza, abilitati
ad accompagnare i processi di Certificazione
 ha creato le figure professionali di Valutatore e di Assistente,
abilitate ad operare in un Laboratorio
Oggi in Italia abbiamo 6 Laboratori accreditati all’OCSI
8
Principali attività di un LVS
Possiamo distinguere due tipologie di attività:

Attività legate al processo di Certificazione, guidate e
controllate dall’OCSI

Attività legate alla valutazione dei livelli di sicurezza di
prodotti informatici e di sistemi ICT nell’ambiente di
utilizzo, non soggette alla guida ed al controllo
dell’OCSI
9
Valutazione del livello di sicurezza di un
sistema IT
1/2
Il processo di valutazione del livello di sicurezza di un
sistema IT, nell’ambiente di utilizzo, prevede le seguenti
fasi:
 Rilevazione e descrizione delle componenti del
sistema: vengono rilevate tutte le componenti hardware
e software del sistema preso in esame, lo schema
architetturale, i collegamenti, le interrelazioni fra le
componenti, i flussi di utilizzo
 Definizione dei requisiti di sicurezza: unitamente ai
Responsabili del Committente vengono definiti i requisiti
di sicurezza che il sistema deve soddisfare
10
Valutazione del livello di sicurezza di un
sistema IT
2/2

Identificazione delle componenti del sistema
interessate ai requisiti di sicurezza: devono essere
identificate le componenti hw e sw del sistema
impattate dai requisiti di sicurezza che si vogliono
applicare, con l’evidenza delle interrelazioni ed
integrazione delle stesse componenti (in pratica si
delimita un sottosistema funzionale)
 Risk management: vengono identificate le funzioni di
sicurezza già implementate, vengono effettuate
verifiche di vulnerabilità e viene definito il piano di
trattamento dei rischi
 Piano di mantenimento: si definiscono le attività atte
a mantenere il livello di sicurezza richiesto e
raggiunto, specificando le modalità di esecuzione e
gli intervalli di tempo entro cui devono essere svolte
11
Prodotto della valutazione
Il prodotto dell’attività di valutazione è un documento
consistente e di alto valore, che può costituire la base di un
Manuale, che verrà successivamente implementato con
tutte le azioni inerenti la sicurezza:
 installazione di nuovi prodotti
 installazione di patch o di nuovi release
 risultati dei test di vulnerabilità effettuati periodicamente
 cambiamenti nell’ambiente di utilizzo
 cambiamenti dei requisiti di sicurezza
 risultati di attività di valutazione di mantenimento (si
consiglia verifiche semestrali o annuali)
12
Processo di Certificazione
Il processo di Certificazione si innesta sulle attività di valutazione
sopra descritte, con un primo passo consistente in un esame di
certificabilità, svolto in congiunzione con l’OCSI, basato
sull’identificazione dell’ODV, sui requisiti di sicurezza e sul livello di
attestazione richiesto (EALx). Superato questo passo le attività
principali consistono nella:
 Stesura del Security Target, ovvero la definizione delle funzioni di
sicurezza utilizzando il linguaggio dei Common Criteria (in
alternativa l’analoga attività prevista da ITSEC)
 Effettuazione delle opportune attività di valutazione
 Raccolta, catalogazione e verifica della documentazione per la
Certificazione
 Assistenza alla Certificazione
13
Valore aggiunto di un Laboratorio
L’accreditamento del Laboratorio, necessario ed
indispensabile per il processo di Certificazione,
garantisce ai Committenti, anche per l’effettuazione di
attività indipendenti di valutazione, competenza ed
autorevolezza verificata ed attestata, oltre alla capacità
di garantire l’imparzialità, l’indipendenza, la riservatezza
e l’obiettività, come base del processo di valutazione
14
La sicurezza del software
L’utilizzo di un modello di gestione della sicurezza nel
Ciclo di Sviluppo del Software permette di:
 Istituire un programma di sensibilizzazione
 Effettuare verifiche applicative
 Comprendere i requisiti di sicurezza
 Implementare pratiche di programmazione sicura
 Costruire procedure di risoluzione di vulnerabilità
 Definire delle metriche e monitorarle
 Definire linee guida di sicurezza operativa
15
Applicazione del modello





Analisi: analisi dei requisiti di sicurezza, analisi dei rischi,
identificazione delle minacce, analisi delle probabilità di impatto
delle minacce, casi di abuso e UML per la sicurezza del
software, linee guida sull'usabilità del software, analisi
tradizionale nel SDLC;
Progettazione: analisi dei rischi, UML per la sicurezza del
software, linee guida sull'usabilità del software, progettazione
tradizionale nel SDLC;
Sviluppo: programmazione sicura del codice, test di sicurezza
basati sull'analisi dei rischi, analisi statica del codice, sviluppo
tradizionale nel SDLC;
Test: analisi dei rischi, penetration test (approccio blackbox o
code review), mitigazione dei rischi, test tradizionali nel SDLC;
Manutenzione: analisi dei rischi, penetration test, manutenzione
tradizionale nel SDLC.
16
In sintesi …
L'introduzione di un modello di gestione della sicurezza
nel processo di sviluppo del software:
 Migliora la robustezza e la qualità del software
 Minimizza i costi di gestione a lungo termine
 Aumenta la consapevolezza di tutti gli attori coinvolti
17
Altre attività del Laboratorio Technis
Il Laboratorio può aiutare il Committente nella scrittura di
Capitolati di Gara, integrando le specifiche funzionali
oggetto di fornitura, con le specifiche di sicurezza che si
ritengono necessarie. Questo è particolarmente
importante quando l’oggetto del capitolato è la
produzione di software, per il quale sovente si tralascia
di indicare le funzioni di impiegabilità: esercibilità,
mantenibilità, affidabilità, robustezza, ecc.
Il Laboratorio può inoltre effettuare collaudi sulle funzioni
sopra citate
18
Altre attività: partnership
Il Laboratorio Technis può essere un partner importante
per altri fornitori, in quanto porta un contributo di forte
competenza, supportato dalla credibilità derivante
dall’accreditamento e dall’utilizzo di uno standard
(Common Criteria) riconosciuto a livello internazionale
ed ampiamente utilizzato dai maggiori produttori
mondiali.
19
Altre attività: Formazione
Il Laboratorio Technis può effettuare corsi di formazione
specialistici per mettere in grado personale sia
dell’utente sia del fornitore, di scrivere Protection Profile
e Security Target, secondo il linguaggio dei Common
Criteria.
20