Il processo di sviluppo sicuro. Kimera Via Bistolfi, Milano

Transcript

1 Il processo di sviluppo sicuro Kimera Via Bistolfi, Milano Kimera Via Bistolfi, Milano

2 Argomenti: Perchè farlo Il processo di sviluppo sicuro Obiettivi del progetto L architettura target La road map Approccio basato sul maturity model Allegati / argomenti

3 Più del 70% delle vulnerabilità rilevate sono a livello applicativo e non più a livello di rete (Fonte Gartner) Attualmente circa il 7-8% del budget IT è indirizzato da attività di IT Security di tipo correttivo (Fonte Gartner) le azioni preventive riducono i costi sostenuti (1 ora di interventi preventivi può corrispondere a 3/10 ore di interventi correttivi nelle fasi di sviluppo ed aumentare fino a 50/200 volte se già in produzione Fonte IS Control 4, 2008) Aumento delle minacce a seguito dello spostamento delle applicazioni verso modelli web oriented, standard di riferimento come PCI DSS (sicurezza transanzioni con carte di credito), requisiti di sicurezza imposti dai clienti e adeguamento alle normative saranno sempre più vincolanti nello sviluppo applicativo La sicurezza applicativa può e deve diventare un parametro a livello decisionale nell acquisto/fornitura di SW dati i vincoli normativi (Privacy) sempre più pressanti / PERCHè FARLO

4 Si migliora l affidabilità del software indipendentemente da problemi di security L approccio metodologico presentato è graduale e funzionale alle necessità di time to market dell azienda, con un impatto graduale ma omogeneo in tutte le fasi di sviluppo / PERCHè FARLO

5 Il processo di sviluppo tradizionale delle web application deve integrarsi con opportuni controlli e attività indirizzate dalla security: / IL PROCESSO DI SVILUPPO

6 Indirizzare il processo di sviluppo verso un modello orientato alla sicurezza nella pratica non è semplice e presenta molte problematiche. Threat Analysis Security Test Risk Analysis alto livello Security Requirements Code Review/VA Hardening/controlli periodici / IL PROCESSO DI SVILUPPO

7 Inspirandoci al SAMM (Software Assurance Maturity Model OWASP Project) sono state identificate 5 macro-aree, declinate in servizi deputati a singole attività e integrati fra loro Tre o più servizi di sicurezza per ciascuna area rappresentano degli specifici silos per il miglioramento all interno dell organizzazione Da prevedere anche aspetti trasversali (governance, tools, formazione ) / ARCHITETTURA TARGET

8 Il raggiungimento di un architettura target, richiede un cambiamento che deve essere affrontato in modo progressivo e misurabile. Le considerazioni che portano verso un approccio maturity model si basano sui seguenti punti: Il cambiamento in un organizzazione è sempre un momento difficile e complesso e con molti ostacoli Lo sviluppo sicuro di software è il risultato di molteplici attività Persone, processi, strumenti, time-to-market, qualità Non esistono formule magiche e/o metodologie calabili dall alto immediatamente funzionanti La sensibilità aziendale verso la security e il livello di accettazione del rischio indirizzano diversamente l approccio alla produzione di software sicuro Un approccio basato sulla qualità non può essere costruito in poco tempo Un organizzazione non può cambiare il suo modus operandi in qualche settimana. E necessario un approccio a fasi, identificando priorità e livelli da raggiungere / ARCHITETTURA TARGET

9 Il raggiungimento dell architettura target è basato su una fase di analisi, design e una fase operativa che porteranno al raggiungimento del risultato finale. Fase 2 - Design Fase 3 - Operativa Fase 1 Analisi / ROAD MAP

10 Il primo step consiste nell analisi della situazione attuale identificando per le singole funzioni il reale posizionamento, tale attività può essere svolta creando apposite check-list di controllo e intervistando le persone coivolte. Mappatura organizzazione attuale Mappatura rispetto alle 5 discipline Mappatura tools, policy, linee guida, procedure.... Risk Analysis Requisiti di sicurezza Baseline Linee Guida/Procedure operative.. 0 Modello Minacce Analisi As - is... Design SW by Security Security Library.. Design Architecture by Security / FASE 1 VA Code Review

11 La fase di design è fondamentale per la buona riuscita dell intero progetto, essa consiste essenzialmente nella progettazione del materiale e dei processi a supporto. Identificazione Ruoli/Responsabilità Pratiche di programmazione sicura e modalità di requisitazione Policy, Linee guida e procedure operative Definizione percorsi formativi Tools e metodologie di riferimento Definizione indicatori (KSI). Design / FASE 2

12 La fase operativa consente di introdurre in modalità graduale tutte le logiche di programmazione sicura e di controllo. E essenziale monitorare e misurare la maturità raggiunta nei vari servizi. Atività formativa Integrazione graduale nel processo integrato di SDLC (ora SSDLC) Introduzione delle pratiche di programmazione sicura/emissione requisiti sicurezza Code review Attività di VA/PT Gestione indicatori KSI e monitoraggio Miglioramento continuo raggiungendo gli obiettivi per ogni servizio Risk Analysis Requisiti di sicurezza Baseline Linee Guida/Procedure operative Modello Minacce Design SW by Secur Operativa.. Security Library.. Design Architecture by Security VA Code Review / FASE 3

13 Come raggiungere l architettura target Kimera Via Bistolfi, Milano info@kimera.it

14 Per ogni disciplina e per ogni servizio appartenente devono essere preparate delle schede in cui vengono dettagliate le attività e gli obiettivi da raggiungere. / LE DISCIPLINE

15 Attività Obiettivi Servizio SW Selection/test dei prodotti Introduzione dell attività nel processo di sviluppo Miglioramento continuo Selezione dei prodotti (commerciali/open Source) Introduzione del VA nel processo di sviluppo Analisi delle problematiche riscontrate Test su progetto pilota Acquisizione dati per la creazione di indicatori (KSI) Creazione di linee guida/formazione in funzione delle problematiche riscontrate / servizio VA

16 Attività Obiettivi Servizio Predisporre materiale (policy/linee guida) per gli sviluppatori ed erogare formazione Formare tutto il personale coinvolto nel processo di sviluppo e definire attività di internal security advisor Condivisione della conoscenza e certificazione del personale Erogare corsi generici sulle tematiche di programmazione sicura Erogare corsi specifici e verticali rispetto alle tecnologie utilizzate nello sviluppo Creazione di portali per la condivisione della conoscenza relativa allo sviluppo sicuro Scrivere e implementare guide tecniche di programmazione sicura Erogare consulenza agli sviluppatori durante le fasi di sviluppo Attività formativa finalizzata ad ottenere certificazioni di sicurezza e utilizzo di tools di VA/PT / servizio FORMAZIONE

17 E consigliabile un approccio omogeneo ma si può anche pensare di raggiungere gli obiettivi per singole discipline. / LE 5 DISCIPLINE

18 Commitment non adeguato Suggerimento: Raccogliere dati (attacchi ricevuti, mancata compliance, gg.uu. per attività di remediation, costi fornitori esterni, ) finalizzati a dimostrare l esposizione al rischio e i costi sostenuti Incompatibilità con il time to market Suggerimento: Non applicare rigidamente il modello, lavorare per priorità Costi aggiuntivi Suggerimento: Quantificare l effort per indirizzare almeno le principali vulnerabilità (e.g. XSS, Sql Injection ) Suggerimento: Quantificare gli interventi correttivi a seguito di audit esterno confrontandoli con quanto sarebbe costato a monte La nostra applicazione è sicura Suggerimento: Attività preventiva di VA/PT/Audit finalizzata a dimostrare l errata percezione del livello di sicurezza e creazione modello delle minacce Cultura aziendale non adeguata Suggerimento: Attività continua di formazione, awareness, bollettini di sicurezza e supporto agli sviluppatori / I PROBLEMI

19 SAMM (Security Assurance Maturity Model) OWASP CLASP Project OWASP OWASP Code Review OWASP OWASP Application Security Verification Standard 2008 OWASP The OWASP Enterprise Security API / BIBLIOGRAFIA

20 / ALLEGATO

21 / ALLEGATO

22 / ALLEGATO

23 Kimera Via Bistolfi, Milano Grazie della Vostra attenzione! Troiani Roberto: roberto.troiani [at] kimera.it