Ciclo di vita del software: strumenti e procedure per migliorarne
Transcript
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