Il ruolo dei LVS nella sicurezza di prodotti e sistemi ICT

1. Il ruolo dei LVS nella sicurezza di prodotti e sistemi ICT Franco Soresina Responsabile del Laboratorio

2. 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

3. 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

4. 1. Quali informazioni? 8. Il miglioramento continuo 2. La sicurezza dei processi 7.Conformità agli Standard più diffusi 3. La sicurezza di prodotti e sistemi informatici SI 6. La diffusione della cultura della sicurezza 4. La sicurezza fisica 5. La competenza del personale addetto Principi per la sicurezza delle informazioni

5. 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, ….)

6. 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.

7. 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

8. 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

9. 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

10. Valutazione del livello di sicurezza di un sistema IT1/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

11. Valutazione del livello di sicurezza di un sistema IT2/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

12. 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)

13. 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

14. 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

15. 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

16. 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.

17. 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

18. 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

19. 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.

20. 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.