Ciclo di vita del software: strumenti e procedure per migliorarne

Forum P.A. ’07 – La Sicurezza ICT nella PA
Ciclo di vita del software:
strumenti e procedure per
migliorarne la sicurezza
Roberto Ugolini
[email protected]
ver. 1.0
del 16/05/2007
SDLC
[email protected]
1
Sicurezza: il modello ed i servizi
Assessment del Sistema di Gestione della Sicurezza delle Informazioni
– Gap Analysis – Definizione e Implementazione dell’SGSI
PIANIFICARE
Istituire il SGSI
Indicatori di Sicurezza
Analisi dei Rischi
Piano di Trattamento dei Rischi
Processo di sviluppo sicuro del codice
Certificazione di sicurezza
Integrazione con strumenti crittografici
REALIZZARE
MIGLIORARE
Attuare e
operare il
SGSI
Mantenere e
migliorare il
SGSI
CONTROLLARE
Monitorare e
riesaminare il SGSI
Analisi di Vulnerabilità/Penetration Test – Audit ISO 27001 – Osservatorio Tecnologico
ver. 1.0
del 16/05/2007
SDLC
[email protected]
2
Il processo di sviluppo sicuro del codice
Il processo di sviluppo sicuro del codice (SDLC) è composto da un certo
numero di azioni, alcune delle quali supportate da strumenti tecnologici,
altre da procedure organizzative
Penetration
testing
Il processo di SDLC non può essere pensato come una semplice aggiunta
della sicurezza alla fine dello sviluppo del prodotto, subito prima o dopo
(quanto dopo?) il rilascio
ver. 1.0
del 16/05/2007
SDLC
[email protected]
3
Penetration testing (1/2)
Il Penetration Testing è la metodologia oggigiorno più applicata per quanto
riguarda la verifica della sicurezza del software, in parte anche in quanto ha
l’interessante (… e pericolosa!) caratteristica di poter essere svolta al
termine del ciclo di sviluppo.
Sfortunatamente questo tipo di test però viene svolto da esperti esterni per
una durata limitata di tempo e può identificare solamente le vulnerabilità
evidenti e superficiali.
Inoltre è troppo legato a fattori aleatori, quali la capacità del tester e la
assoluta mancanza di metodologie di test universalmente accreditate.
In generale questo tipo di testing viene di fatto svolto troppo tardi nel ciclo
di sviluppo e non da che risultati superficiali: spesso il risultato
risultato di questi test
è quello di creare una certificazione superficiale del prodotto.
ver. 1.0
del 16/05/2007
SDLC
[email protected]
4
Penetration testing (2/2)
Penetration Testing: manuali o automatizzati?
Possono (e devono) coesistere in un’attività condotta in modo esaustivo
Gli strumenti per Web Application sono ideali nell’identificare vulnerabilità tecniche
L’esperienza e la capacità umane sono invece fondamentali per trovare vulnerabilità
logiche e creare “mis-use case”
Strumenti per penetration testing: open source o commerciali?
E’ necessaria una combinazione equilibrata di personale esperto e formato e strumenti
automatizzati, sia commerciali sia opensource
I tool automatizzati aiutano un security tester ad effettuare in modo più rapido e
maggiormente completo l’assessment di una web application
Il tool richiede la conoscenza dei suoi limiti e di come padroneggiarlo per essere
proficuo
Non sostituiscono l’attività manuale e possono per ciò essere combinati con strumenti
opensource
In questo modo è possibile affrontare vulnerabilità tecniche o logiche, ridurre i falsi
positivi/negativi e gestire l’assessment di applicativi di grosse dimensioni
ver. 1.0
del 16/05/2007
SDLC
[email protected]
5
E quindi?
1
4
2
6
3
5
Il processo di vita del software e le attività di SDLC necessarie (fonte IEEE)
ver. 1.0
del 16/05/2007
SDLC
[email protected]
6
Ma se il software proviene da un fornitore esterno?
Fornitura subordinata alla:
(in fase di trattativa/capitolato)
• accettazione degli standard/linee guida adottati dal committente, che indirizzino
specificamente il problema delle vulnerabilità del software e la progettazione di
software sicuro
• “certificazione” dei profili degli esperti di sicurezza che verranno impiegati per
validare il prodotto ed relativo codice sorgente (esperti interni o possibilmente in
outsourcing)
• “certificazione” dei processi interni ed esterni di gestione del codice
• “certificazione” del processo di sviluppo seguito in particolare con riferimento alla
gestione dei requisiti di sicurezza del codice
• tempistica di risoluzione delle falle di sicurezza
(in fase di rilascio)
Reportistica delle operazioni di testing sul software completo (condotti sia tramite
risorse interne che in outsourcing) e relative contromisure adottate prima del
rilascio finale
ver. 1.0
del 16/05/2007
SDLC
[email protected]
7