Software Security Governance

Software Security Governance Matteo Meucci, Minded Security 17 Maggio 2013

Agenda del seminario Introduzione alla Software Security Le maggiori problematiche della gestione del software Comuni approcci non strutturati alla gestione della sicurezza applicativa Software Security Governance Processi necessari da creare per la Software Security La gestione dello sviluppo in outsourcing La creazione di un Application Security Program Le iniziative OWASP per il supporto alla Software Security Linee Guida e strumenti open source

Presentazioni Research OWASP-Italy Chair OWASP Testing Guide Lead OWASP SAMM Contributor Work CEO @ Minded Security Application Security Consulting 12+ years on Information Security focusing on Application Security, CISSP, CISA 3

Software Security Governance Introduzione alla sicurezza del software Software Security Governance Processi necessari da creare per la Software Security Introduzione alla Web App Sec La gestione dello sviluppo in outsourcing La creazione di un Application Security Program Le iniziative OWASP per il supporto alla Software Security

Software sicuro o insicuro?

Ingredienti del software sicuro? Software Facts Expected Number of Users 15 Typical Roles per Instance 4 Modules 155 Modules from Libraries 120 Ingredienti: Sun Java 1.5 runtime, Sun J2EE 1.2.2, Jakarta log4j 1.5, Jakarta Commons 2.1, Jakarta Struts 2.0, Harold XOM 1.1rc4, Hunter JDOMv1 % Vulnerability* Cross Site Scripting 22 65% Reflected 12 Stored 10 SQL Injection 2 Buffer Overflow 5 Total Security Mechanisms 3 Modularity.035 Cyclomatic Complexity 323 Encryption 3 95% Authentication 15 Access Control 3 Input Validation 233 Logging 33 * % Vulnerability values are based on typical use scenarios for this product. Your Vulnerability Values may be higher or lower depending on your software security needs: Usage Intranet Internet Cross Site Scripting Less Than 10 5 Reflected Less Than 10 5 Stored Less Than 10 5 SQL Injection Less Than 20 2 Buffer Overflow Less Than 20 2 Security Mechanisms 10 14 Encryption 3 15

La verifica di sicurezza del software public class HelloWorld extends HttpServlet { public void doget( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { response.setcontenttype("text/html"); PrintWriter out = response.getwriter(); out.println("<html><head>"); out.println("<title>hello World</TITLE>"); out.println("</head><body>"); out.println("hello, " + }?

Principi di software security Le vulnerabilità di sicurezza nel processo di sviluppo software sono attese. Il controllo dei difetti di sicurezza del software deve essere considerato parte del processo di sviluppo del software. La gestione delle vulnerabilità è il punto più importante del processo di software security.

Esempio di approccio non strutturato: Ministero dell Informatica

Attori coivolti Ministero Informatica: acquista il software Azienda di sviluppo: realizza il sw Utente: usa il software

Conferenza stampa per il lancio del portale Da oggi è possibile usufruire di un nuovo servizio sul portale di Ministero Informatica Fantastico!! Complimenti!!

Il giorno dopo...

Accesso al portale... Mario Verdi 12/12/1970 m.verdi@azienda.it Mario Rossi- 10/09/1982 mariorossi@azienda.it Paolo Rossi 09/02/1960 p_rossi@azienda.it

Accesso al portale... Oh oh...ho trovato un problemino...

Qualche giorno dopo...

Le reazioni... Ohh..ma come è stato possibile? E colpa degli sviluppatori! Non saprei...ma è impossibile!? Abbiamo seguito tutte le vostre direttive Tutte le persone coinvolte nel ciclo di vita di sviluppo del sw devono essere orientate alla sicurezza del software Se voi non chiedete software sicuro nessuno ve lo realizzerà

Perchè è potuto succedere? Sono stati i richiesti requisiti di sicurezza al software acquistato? Sono state effetuate verifiche di sicurezza per il software? Sono state verificate le librerie o software di terze parti utilizzato? Sono state effettuate verifiche di sicurezza per l infrastruttura su cui gira la applicazione?

Comuni Assunzioni non corrette I test risolvono tutti i problemi di sicurezza applicativa Software proprietario => software sicuro Software open source => software sicuro Se qualcuno non ha fatto una review del codice molto probabilmente vi porterete in esercizio vulnerabilità del framework Il client è una sorgente dati sicura => invia dati attesi All input is Evil! (M. Howard) Implementare significhi sviluppare da zero Utilizzate librerie di sicurezza verificate e condivise

Un approccio più strutturato Facciamo eseguire sulle applicazioni più critiche un penetration test applicativo entro l anno dalla messa in esercizio Facciamo eseguire sulle applicazioni più critiche un penetration test applicativo appena è in esercizio Facciamo eseguire sulle applicazioni più critiche un penetration test applicativo in pre-esercizio NON BASTA! Questo di norma è l ultimo passo che si effettua all interno del processo di sviluppo del software E il recheck? Passo fondamentale per la consapevolezza e gestione delle vulnerabilità

La Governance La Governance della Software Security: OWASP SAMM per Maturity Assessment Awareness e formazione specializzata Adozione di Policy, Standard e Best Practice Creazione di Processi Assegnazione di Ruoli e Responsabilità Punti chiave per l efficenza della Governance (fixing, conoscenza)

Il ciclo di vita del software Il Ciclo di Vita del Software (Sofware Development Life Cycle, SDLC) comprende le seguenti fasi : Define: fase di definizione delle specifiche e requisiti progettuali Design: fase di progettazione che individua i requisiti generali e la struttura per il software e stabilisce le migliori pratiche di progettazione. Develop: fase di sviluppo del software Deploy: messa in esercizio del software Maintain: la gestione del cambiamento delle versioni del software

Secure SDLC Fasi SDLC Define Design Develop Deploy Maintain Secure Software processes Secure Software Requirements Secure Software Design Secure Software Implementation Secure Software Testing & Acceptance Secure Software Deployment & Maintenance

Secure SDLC Costi relativi per il fixing del codice nelle varie fasi dell SDLC Source: Official (ISC)2 Guide to CSSLP (2011)

I step: Awareness Tutte le figure coinvolte nel processo di SDLC devono seguire seminari di alto livello e corsi specializzati per ciascuna figura. Top Management Business Analyst Business unit head QA Manager IT Manager Security Manager Application Security Specialist Applications owner Developer Project Manager

II Step: Policy,Standard e Best Practice L organizzazione deve adottare Policy, Standard e best practice di Software Security I. Define Definire una metodologia di risk assement e classificazione del software Redigere un modello per effettuare il Secure Requirements Redigere un modello per Secure Architecture con lista tecnologie e framework adottati II. Design Redigere un modello per effettuare il Secure Design Redigere un modello per effetuare il Threat Modeling

II Step: Policy,Standard e Best Practice III. Develop Redigere Secure Coding Guidelines (a seconda dei linguaggi). Preferibile se viene adottato un uso condiviso di API (Es: ESAPI) Adottare il proprio modello per i test di sicurezza SCR e WAPT (automatici/manuali, interni/esterni) Adottare un sistema di ticketing per il fixing delle vulnerabilità IV. Deploy Redigere il documento di Software Acceptance Redigere documenti di secure deploy e hardening V. Mantain Adottare un modello di monitoring delle intrusioni web

III step: creazione dei processi Define Design Develop Deploy Maintain Risk Assessment Secure Design Design Review Software Acceptance Web Intrusion Monitoring Secure Requirements Threat Modeling Secure Development Secure Installation Change Management Secure Architecture Secure Code SCR and WAPT Hardening Fixing 28

IV step: assegnazione ruoli e responsabilità Define Design Develop Deploy Maintain Risk Assessment Secure Design Design Review Software Acceptance Web Intrusion Monitoring Security Manager Application Owner Business Analyst AppSec Specialist Security Manager Security Manager App Owner AppSec Specialist Sec Manager Secure Requirements Threat Modeling Secure Development Secure Installation Change Management Business Analyst Security Manager Secure Architecture Software Architect Security Manager Business Analyst Software Architect, AppSec Specialist Developer SCR and WAPT AppSec Specialist Sistemista Hardening Sistemista App Owner Develper Fixing Developer 29

Verifica della sicurezza In-house vs terza parte? Adozione di tool vs analisi manuale? Code Review vs Application Testing?

Verifica della sicurezza: in-house Vantaggi: Portare cultura in azienda Creare competenze Svantaggi Spese per tools, sviluppo metodologie Molto difficile arrivare ad una accuratezza elevata, serve molto tempo per formare il personale Serve personale dedicato

Verifica della sicurezza: terza parte Vantaggi: Utilizzo di personale specializzato su queste attività con competenze tecniche allo stato dell arte Risultati più approfonditi Svantaggi Poco scalabile su centinaia di applicazioni Quando si applica: Su applicazioni critiche

Code Review vs Application Testing Secure Code Review: l attività di secure Code Review consiste nell analisi di sicurezza del codice sorgente dell applicativo linea per linea: viene anche chiamato test di tipo white box, per sottolineare il fatto che chi esegue la verifica ha a disposizione la conoscenza completa dell applicativo (insieme dei sorgenti). Web Application Penetration Testing (WAPT): l attività di Web Application Penetration Testing consiste nell effettuare una simulazione reale di un attacco informatico all applicativo in oggetto al fine di valutarne l effettivo livello di sicurezza. Tale test, viene chiamato di tipo black box in quanto in questa circostanza chi compie l analisi non ha a disposizione nessuna conoscenza sul software, e vuole garantire che non siano presenti problematiche di sicurezza prima del deploy in esercizio.

Obiettivi Vantaggi Svantaggi Secure Code Review Fornire i dettagli completi (componente X dell applicazione alla riga Y) delle vulnerabilità di sicurezza dell applicazione. Adatto per ottenere risultati di elevata qualità per applicazioni critiche. È indicata nel caso in cui si desideri fare una formazione mirata sulla sicurezza applicativa per il team di sviluppo, in quanto in classe si possono discutere le reali problematiche evidenziate dai test. Un Secure Code Review comporta un maggiore effort per l analisi e quindi rappresenta un maggiore dispendio di tempo e quindi di costo. Application Testing Fornire un quadro generale della debolezza dei controlli di sicurezza implementati dall applicazione. Tale attività in generale comporta dei costi minori in quanto impiega meno tempo rispetto ad un Secure Code Review che prevede l analisi dettagliata di tutte le linee di codice dell applicativo. Non sempre è possibile coprire tutte le possibili vulnerabilità in quanto non si ha una conoscenza completa dei dettagli implementativi. In generale l attività di remediation è meno immediata.

Tools vs. Manual Testing (2) Trovare vulnerabilità nel Trovare vulnerabilità nelle Codice Sorgente La combinazione delle 4 applicazioni sviluppate (White Box Testing) tecniche produce I risultati (Black Box Testing) migliori Manual Code Review Manual Penetration Testing Automated Static Code Analysis Automated Vulnerabilty Scanning 35

Tools At Best 45% MITRE found that all application security tool vendors claims put together cover only 45% of the known vulnerability types (over 600 in CWE) They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true) 36

White box testing tools Problema principale di non riuscire a contestualizzare il codice analizzato 11: }elseif( isset($_request['usr']) and isset($_request['pwd']) ){ 12: $usr=mysql_real_escape_string($_request['usr']); 13: $pwd=$_request['pwd']; 14: $wherea = " WHERE (A.username='$usr' and A.password='".md5($pwd)."' )"; 15: }elseif( $_REQUEST[ ID1'] ){ 16: $wherea = " WHERE A.ID1 = $ID1'"; 17: }else{ 18: errortable( 'Impossibile effettuare il login', 0); } 37

Automazione dei test Se si vuole implementare un nuovo processo di verifica della sicurezza del software utilizzando i tool è bene tenere presente i seguenti punti critici: Gestione della configuzione del tool prima della scansione Gestione dei risultati ottenuti e corretto fixing delle problematiche È necessario pensare alll'integrazione di strumenti di revisione del codice e penetration testing nel processo di sviluppo dell azienda (bug ticketing) Un aspetto molto importante è quello di eliminare nel più breve tempo possibile i falsi positivi.

Gestione dei tool Le fasi di gestione dei tool possono essere riassunte come di seguito 1. Startup: attività iniziale in cui le applicazioni vengono analizzate per capire i modelli, gli schemi e le caratteristiche particolari per ulteriori personalizzazioni. 2. Regole personalizzate: la creazione di un set di regole personalizzate per rendere lo strumento migliore montaggio nella logica dell'applicazione. 3. Scansione: questa fase consiste nell eseguire lo strumento configurato per l'applicazione da testare. 4. Convalida di scansione: l'attività per l'identificazione e la rimozione di falsi positivi. 5. Ticketing system: questa fase si occupa di inserire le nuove vulnerabilità nel sistema di ticketing, e di controllare lo stato dei numeri precedenti. 6. Correzione dei bug: i programmatori dovrebbero essere sostenuti durante l'attività di bug fixing, per essere sicuri di aver capito il problema per il raggiungimento di una migliore efficacia.

Gestione dei tool

Organizzazione del processo 1. Startup: realizzato da Application Security specialist. Tale figura deve conoscere bene il prodotto, il software da analizzare e tutte le problematiche 2. Regole personalizzate: nel caso di scrittura di regole è necessario l apporto di un Application Security specialist al fine di realizzare la migliore regola di scansione. 3. Scansione: l Application Security specialist eseguirà la scansione sul software oppure ogni singolo sviluppatore sul proprio pezzo di codice. 4. Convalida di scansione: la persona che esegue la scansione dovrà analizzare il report dei tool ed effettuare una verifica puntuale delle vulnerabilità indivuate. Questa fase è molto dispendiosa in termini di tempo in quanto di norma i tool forniscono centinaia se non migliaia risultati di cui parecchi sono falsi positivi. Chi esegue la scansione deve assicurarsi di consegnare il report agli sviluppatori che contenga il numero minore di falsi positivi per evitare una perdita di tempo in fase di fixing.

Organizzazione del processo 5. Ticketing system: per gestire tutti i nuovi bug di sicurezza individuati è necessario utilizzare un sistema di gestione dei ticket che comunichi al team di sviluppo la problematica e definisca un tempo limite per il fixing. 6. Correzione dei bug: i programmatori del progetto in oggetto devono essere formati per capire la vulnerabilità che è stata loro comunicata e per implementare la migliore remediation possibile. Molto spesso questo aspetto è il più trascurato e l applicazione risulta esposta a gravi problemi di sicurezza perchè non si è stati in grado di gestire il processo di fixing (banalmente nessuno ha implementato il fixing) oppure perchè si è implementata una soluzione non corretta che permette l esecuzione della vulnerabilità nonostante sul sistema di ticketing si sia ufficialmente chiuso il ticket. Per evitare questo problema risulta fondamentale che la Security aziendale monitorizzi questo processo, si accerti della presa in carico del bug fixing e faccia eseguire un altra scansione per verificare che il bug sia stato correttamente sanato.

Figure coinvolte nel processo Application Security specialist: figura dedicata alla gestione del prodotto e alla comunicazione delle effettive vulnerabilità enucleate ai team di sviluppo. La carica può essere assegnata a un membro qualificato di un gruppo indipendente centralizzato interno all'organizzazione, particolarmente adatto a revisioni di questo tipo, oppure a un esperto esterno all'organizzazione. Tale ruolo deve essere necessariamente dedicato solo a questo compito. Application Security Manager: figura che coordina le attività di scansione, assegna i tak di fixing e verifica che siano stati opportunamente chiusi tutti i ticket di sicurezza. Per quanto concerne il processo di fixing è necessario individuare individuare all interno di ciascun team lo sviluppatore che possiede le competenze necessarie per la sicurezza applicativa al fine di assicurarsi una corretta comprensione della problematica e implementazione del fix.

Metodologia e processi per lo sviluppo sicuro FASE DI SVILUPPO DEL SOFTWARE Team di sviluppo I release Remediation Fase di verifica durante lo sviluppo del software Secure Code Review Team I Code Review Code Review - Recheck FASE DI SECURE CODE REVIEW FASE DI PRE-ESERCIZIO Team di sviluppo Applicazione running Remediation Fase di verifica durante la messa in pre-esercizio Web Application Testing Team I Web Application Penetration Testing WAPT - Recheck FASE DI WEB APPLICATION TESTING

Domande Quale elemento è il più importante per una corretta ed efficiente gestione della sicurezza nel ciclo di vita del software (SDLC)? Utilizzo di tool allo stato dell arte per effettuare Secure Code Review e Penetration Testing applicativo su ogni applicazione da sviluppare Awareness e corsi di formazione specialistici su Software Security per ciascuna figura coinvolta nel SDLC Concentrarsi solo sullo sviluppo sicuro del codice

Le maggiori criticità nel modello in outsourcing Outsourcing dello sviluppo: fiducia cieca nel sw acquistato Verifica di sicurezza solo dell applicazione running (WAPT), non Design e Code Review Uso di framework insicuri (Liferay, Ibatis, ecc.) Aggiunta di componenti da terze parti senza fare review (javascript, banner, ecc.) Outsourcing dell infrastruttura: fiducia cieca nella gestione non ci sono contratti di gestione delle problematiche di sicurezza, degli incidenti e delle modalità di deploy. 47

Sviluppo in Outsourcing OUTSOURCER (Sviluppo) Azienda (Committente) Development Team Code Review Team Application Testing Team Contratto di sviluppo Contratto di sviluppo

Cosa cambia nel modello in outsourcing? Define Design Develop Deploy Maintain Risk Assessment Secure Design Design Review Software Acceptance Web Intrusion Monitoring Security Manager Application Owner Business Analyst AppSec Specialist Security Manager Security Manager App Owner AppSec Specialist Sec Manager Secure Requirements Threat Modeling Secure Development Secure Installation Change Management Business Analyst Security Manager Secure Architecture Software Architect Security Manager Business Analyst Software Architect, AppSec Specialist Developer SCR and WAPT AppSec Specialist Sistemista Hardening Sistemista App Owner Develper Fixing Developer A carico del committente A carico dell outsourcer 49

Collaudo software sviluppato in Outsourcing Source: OWASP Secure Software Development Contract Annex Capability Maturity Model v1.1 ISO/IEC 27006:2007 (Information technology Security techniques Requirements for bodies providing audit and certification of information security management systems )

Filosofia del documento (a) Le decisioni sulla sicurezza saranno basate sui rischi. Le decisioni saranno effettuate congiuntamente da cliente e sviluppo (b) Le attività di sicurezza saranno bilanciate. Distribuite in modo uniforme nell'intero ciclo di vita dello sviluppo software. (c) L Attività di sicurezza sarà integrata. Tutte le attività e la documentazione saranno integrate nel ciclo di vita del software per gli sviluppatori e non tenuto separato dal resto del progetto. (d) Le vulnerabilità sono attese. Tutto il software presenta dei bug. Si cercherà di identificare le vulnerabilità più presto possibile nel ciclo di vita del sw. (e) Le vulnerabilità saranno condivise. Tutte le informazioni relative alla sicurezza saranno condivise tra il Cliente e Sviluppo immediatamente e completamente.

Principi fondamentali Prima di acquisire il software da un outsourcer è importante verificare che soddisfi i requisiti di: Compliance, Qualità, Funzionalità e Sicurezza I requisiti di sicurezza devono essere validati e i controlli di sicurezza verificati internamente o da una terza parte tramite security testing (V&V). Il software non deve essere rilasciato fino a che non sia stato certificato e accreditato che il rischio residuo è al livello appropriato (C&A).

Modello di Software Acceptance 1. Security Requirements Sviluppo Cliente 5. Acceptance 2. Librerie e framework Secure Software Development Contract 4. Assurance 3. Security Review Secure Software Development Contract

(1) Security Requirements area Validation and Encoding. Authentication and Session Management. Access Control. Error Handling. Logging. Connections to External Systems. Encryption. Availability Secure Configuration. Specific Vulnerabilities. OWASP Top Ten Most Critical Web Application Vulnerabilities.

(1) Esempio di security Requirements ID Requisito Descrizio ne Data Validation-003 UTILIZZARE I PREPARED STATEMENT L applicazione è soggetta a vulnerabilità di SQL Injection quando usa l input fornito dall utente senza validarlo per fare delle query sul database (ad esempio la ricerca dell utente in fase di login oppure quando si usa una funzione di ricerca fornita dall applicazione). È necessario fare uso solo di Prepared Statement evitando l uso di concatenazioni di stringhe. LìuUtilizzo di concatenazione di stringhe per costruire la query da ingresso arbitrario non renderà il PreparedStatement sicuro. Per esempio: PreparedStatement = "SELECT * FROM utenti WHERE Nome = '" + username + "',"; Se un attaccante inserisce: 'O '1' = '1 Nel campo nome utente, il PreparedStatement sarà vulnerabile a SQL injection, dal momento che tale query verrà eseguita sul database come SELECT * FROM utenti WHERE Nome ='' OR '1 '= '1'; Quindi, se si utilizza invece: PreparedStatement = "SELECT * FROM utenti WHERE nome =?"; preparedstatement.setstring (1, username);...

(1) Esempio di checklist

(2) Librerie, framework e prodotti Disclosure. Lo sviluppo deve indicare tutti i software di terze parti usati nel software, incluse tutte le librerie, strutture, componenti, e altri prodotti, siacommerciale, gratuito, opensource o closed-source (si può decidere in fase di design quali librerie e framework debba utilizzare l outsourcer). Evaluation. Lo sviluppo dovrà fare ogni ragionevole sforzo per assicurare che il software di terze parti soddisfi tutti i termini di questo accordo ed è sicuro come il codice personalizzato sviluppato nell'ambito dell accordo.

(3) Security Review Right to Review. Il cliente ha il diritto di rivedere il codice a proprie spese in ogni momento fino a 60 giorni dalla consegna. Lo sviluppo si impegna a fornire un supporto ragionevole del team di revisione, fornendo il codice sorgente e l'accesso ad ambienti di test. Review Coverage. Il Security Review comprende tutti gli aspetti del software fornito, incluso il codice personalizzato,componenti, prodotti e configurazione del sistema. Scope of Review. Come minimo, la revisione riguarda tutti i requisiti di sicurezza e le vulnerabilità comuni. La revisione può includere una combinazione di scansione di vulnerabilità, PT, l'analisi statica del codice sorgente e il code Review di esperti. Issues Discovered. I problemi di sicurezza scoperti verranno segnalati e devono essere fixati prima di procedere ai prossimi passi.

(3) Security Review In questa fase viene effettuato il processo di Validate & Verify secondo il modello CMMI v.1.1 da parte del Cliente: Validate Si verifica che il software si comporti secondo il disegn e i requisiti stabiliti. Si validano i security requirements concordati (checklist). Verify dei controlli implementati al fine di evitare possibili vulnerabilità Secure Code Review Penetration Testing

(4) Assurance (a) Certification Package. Lo sviluppo fornirà un "pacchetto di certificazione" costituito dalla documentazione relativa alla protezione creata durante il processo di sviluppo. Il pacchetto dovrebbe stabilire che i requisiti di sicurezza, progettazione, implementazione e risultati di test siano stati compilati. (b) Autocertificazione. Lo sviluppo certifica che il software soddisfi i requisiti di sicurezza, tutte le attività di sicurezza sono stati effettuate, e tutti i problemi legati alla sicurezza sono stati documentati e risolti. (c) Nessun codice dannoso. Lo sviluppo garantisce che il software non deve contenere alcun codice dannoso, come virus, worm, backdoor, malware.

(5) Acceptance Considerazioni generali Criteri di completezza Tutti i requisiti funzionali e di sicurezza sono stati completati come da contratto? Change Management Esiste un processo per gestire le richieste di cambiamento? Accettazione del rischio ed exception policy Il rischio residuo di acceptance e le eccezioni alle policy sono entro i limiti stabiliti? Documentazione del software Tutta la documentazione è disponibile?

(5) Acceptance In questa fase si esegue il processo di Certification & Accreditation (C&A) secondo il CMM v1.1 Il software non può essere considerato accettato fino a quando il pacchetto di certificazione è completo e tutte le questioni relative alla sicurezza sono state risolte: Documentazione completa. Fixing e Retest effettuati oppure valutazione che il rischio residuo è al livello appropriato.

(5) Risk Acceptance Come viene gestito il rischio residuo dipende da fattori quali tempo e risorse Tempo e risorse insufficienti per mitigare il rischio trasferire (assicurazione) o evitare il rischio (dismettere il servizio)

Security issue management and acceptance 1. Security Requirements Sviluppo Committente 5. Acceptance 2. Librerie e framework Secure Software Development Contract 4. Assurance 3. Security Review Secure Software Development Contract

OWASP SAMM e BSIMM BSIMM: Lo scopo del BSIMM è quello di documentare le attività comuni a tutte le più importanti attività di software security. Modello descrittivo: a posteriori il modello riflette una fetta crescente di realtà. OWASP SAMM: I modelli precedenti sono buoni per gli esperti da utilizzare come una guida, ma difficile per le aziende da utilizzare per migliorare i propri obiettivi. Modello prescrittivo: mostra un percorso comune da seguire.

OWASP SAMM: obiettivi L obiettivo è identificare le practice di sicurezza adottate dall azienda per quanto riguarda il ciclo di vita dello sviluppo software, valutarne la maturità e costruire una roadmap al fine di raggiungere un livello di maturità che sia allineato agli obiettivi aziendali preposti.

SAMM: 4 Funzioni di business critiche Governance Construction Verification Deployment Software development management activities and organisation-wide business processes Goal definition and software creation processes Checking, evaluation and testing of software development artifacts Software release management and normal operational management Il modello prevede 4 attività di base legate ad ogni azienda che sviluppa o acquista software Rappresentano nomi generici delle funzioni ma dovrebbero essere compresi dagli sviluppatori e manager all interno dell azienda 68 68

Ciascuna area ha 3 Security Practices Governance Construction Verification Deployment Security & Metrics Threat Assessment Design Review Vulnerability Management Policy & Compliance Security Requirements Code Review Environment Hardening Education & Guidance Secure Architecture Security Testing Operational Enablement 69 69

Governance Governance Security & Metrics Policy & Compliance Education & Guidance "Strategy and Metrics": per capire se sono stati pensati Application Security program in azienda e come vengono gestiti. "Policy e Compliance" per capire se sono in uso policy per lo sviluppo del software e come vengono affrontate le problematiche di compliance. "Education e Guidance" per quanto riguarda l'awareness e i percorsi di formazione presenti in azienda. 7 0

Construction Construction Threat Assessment Security Requirements "Threat Assessment": come l'azienda affronta le possibili minacce a cui potrà essere sottoposta l'applicazione da sviluppare. "Security Requirements": quali sono i requisiti di sicurezza per lo sviluppo del sw in azienda. "Secure Architecture": quali sono i requisiti di sicurezza architetturali in uso. Secure Architecture 7 1

Verification Verification Design Review Code Review Security Testing "Design Review": capire se i team di progetto documentano i rischi per la sicurezza e come viene fatto il review di tali progetti. "Code Review": esiste un processo di Code Review sul sw sviluppato? come viene eseguito? "Security Testing": come vengono eseguiti i penetration test applicativi? Quali risultati sono raggiunti? 7 2

Deployment Deployment Vulnerability Management Environment Hardening Operational Enablement "Vulnerability Management": si focalizza l'attenzione su come vengono gestite le problematiche di sicurezza delle applicazioni e come vengono gestiti gli incidenti di sicurezza. "Environment Hardening": si vuole capire come viene gestita la sicurezza dell'ambiente su cui girano le applicazioni. "Operational Enablement": come viene gestita la configurazione del sw e le condizioni di errore.

Per ogni security practice Sono definiti 3 obiettivi per ogni practice che definiscono come questa può essere migliorata nel tempo Ciò stabilisce una nozione del livello al quale un organizzazione adempie ad una data Practice I 3 livelli per una practice in generale corrispondono a: (0: Inizio implicito con la Practice non completata) 1: Iniziale comprensione e la disposizione ad hoc della Practice 2: Migliore efficienza e / o efficacia della pratica 3: Padronanza completa della pratica

Applicare il modello

Procedura di assessment Condurre un assessment Creare uno score card Costruire un programma di assurance Metriche Road map Implementare gli obiettivi e condurre nuovamente un assessment

Ad esempio: BF Governance, SP Education Governance Security & Metrics Policy & Compliance Education & Guidance Obiettivi Attività EG1 EG2 EG3 Offrire allo staff di sviluppo l accesso alle risorse di sviluppo sicuro A. Condurre Training tecnici su Security Awareness Educare tutto il personale nel SDLC in base al proprio ruolo nello sviluppo sicuro A. Condurre training specifici in base al ruolo Training sulla sicurezza mandatori e completi. Personale certificato A. Creare un supporto formale per la application security B. Costruire e mantenere linee guida tecniche B. Utilizzare i trainer per migliorare i team di progetto B. Stabilire esami in base ai ruoli aziendali 77 77

Assessment Education & Guidance La maggior parte degli sviluppatori ha avuto una formazione circa la sicurezza del Software? Assertion: La formazione sulla sicurezza applicativa è fornita a tutti gli sviluppatori. La formazione copre argomenti come le vulnerabilità comuni e le raccomandazioni delle best Assertion: practice per eliminarle. Assertion: La formazione è condotta almeno annualmente ma anche on demand secondo le necessità. I team di progetto hanno accesso alle best practice e alle guide per lo sviluppo sicuro? Le risorse riguardanti le practice di sviluppo sicuro sono state assemblate e rese disponibili Assertion: agli sviluppatori. Il management informa i gruppi di sviluppo che loro devono usare le risorse per lo sviluppo Assertion: sicuro. Assertion: Una checklist basata sulle risorse per lo sviluppo sicuro è stata creata per assicurarsi che le linee guida siano rispettate durante lo sviluppo.

Risultato dell assessment Education & Guidance La maggior parte degli sviluppatori non ha avuto una formazione di alto livello circa la sicurezza. È in corso un piano di formazione solo per un numero ristretto di sviluppatori. Esiste un piano di formazione generica sulla sicurezza mediante e-learning. Le best practice e le guide per lo sviluppo sicuro non sono accessibili a tutti i team di progetto e non sono al momento condivise e concluse, anche se da poco tempo sarebbero disponibili su sistema documentale condiviso da tutti gli sviluppatori. Non è stata al momento fornita una formazione specifica in base al ruolo nel processo di sviluppo. I manager in generale non conosco le problematiche di sicurezza del software, non sono a conoscenza dei maggiori rischi a cui sono esposte le applicazioni e quali possono essere gli impatti di un possibile sfruttamento delle vulnerabiltà. I responsabili applicativi sono in grado di coinvolgere esperti in sicurezza da usare nei progetti. Viene coinvolto il gruppo di Information Security Support ed esterni su questioni specifiche. L'orientamento della sicurezza non è controllato in maniera centralizzata e costantemente distribuita a tutta l'azienda. Vi è documentazione per piattaforme.net e java ma non è chiaro se riguardino gli aspetti di sicurezza o meno. In azienda non c'è mai stata una verifica per assicurare una minima conoscenza delle practice di sviluppo sicuro.

Software Security Maturity Level

Executive Summary Non sono presenti al momento attività di Threat Assessement, Design Analysis e Secure Code Review (sebbene sia presente un processo Quality Assurance Review). L'aspetto della sicurezza per quanto concerne l'acquisizione di software esterno risulta al momento sottovalutato: nei contratti stipulati non vengono stabiliti specifici requisiti di sicurezza e non viene effettuata una verifica di sicurezza del software prima dell acquisizione. Anche laddove sono stati eseguiti penetration test si osserva che non è stato al momento implementato un processo di fixing delle problematiche che accerti che le vulnerabilità enucleate nei test siano opportunamente corrette secondo tempi e responsabilità prestabiliti. Al momento sono trascurati gli aspetti di gestione della sicurezza delle applicazioni in esercizio ed è necessario definire un processo di gestione degli incidenti anche per i servizi applicativi oltre che la parte di rete e di host.

Azioni consigliate

Roadmap

Magic Quadrant Beneficio-Effort delle azioni consigliate

Maturità dello sviluppo sicuro di software Sulla base dei processi di sicurezza implementati e alle linee guida adottate, è possibile pensare a 3 differenti livelli di maturità dello sviluppo di software delle aziende. I Fase - Corsi generali sulla sicurezza applicativa - Check veloce su tutta l infrastruttura applicativa II Fase - Linee Guida - Checklist - Percorsi mirati di formazione - WAPT continui con recheck III Fase - Linee Guida - Checklist per fornitori - Percorsi mirati continuativi - Secure Code Review e WAPT continui con recheck periodici - Knowledge base su Application Security

Quali livelli di maturità hanno le aziende italiane? Secondo l esperienza di Minded Security su 30 aziende valutate, il grafico seguente mostra il posizionamento delle aziende italiane in base al loro core business. 2 PA 5 Government 5 Finance/Energy 9 SW Development 2 Telco 7 Banking PA I Fase Finance/Energy Government - Corsi generali sulla sicurezza applicativa - Check veloce su tutta l infrastruttura applicativa II Fase SW Development - Linee Guida - Checklist - Percorsi mirati di formazione - WAPT continui con recheck Banking Telco III Fase - Linee Guida - Checklist per fornitori - Percorsi mirati continuativi - Secure Code Review e WAPT continui con recheck periodici - Knowledge base su Application Security

Il progetto Open Web Application Security Project (OWASP) è una organizzazione Open Source dedicata alla creazione e alla diffusione di una cultura per quanto riguarda la sicurezza delle applicazioni web Progetto free, come il materiale disponibile sul portale www.owasp.org Migliaia di membri, +100 capitoli locali e altri partecipanti ai progetti. Milioni di hit su www.owasp.org al mese Defense Information Systems Agency (DISA), US Federal Trade Commission (FTC), VISA, Mastercard, American Express e molte aziende in Italia hanno adottato la documentazione OWASP nei loro standard e linee guida 88

OWASP è un gruppo di professionisti 6,381 Articoli 427 presentazioni 200 aggiornamenti/giorno 271 mailing lists 180 blog monitorati Progetti: alfa beta release 89

Linee Guida OWASP Gratuite e open source Libri a basso costo Centinaia di esperti coinvolti Coprono tutti gli aspetti di sicurezza applicativa 90

Principali progetti OWASP BOOKS Owasp top10 OWASP ASVS Building guide Code review guide Testing guide TOOLS WebGoat,WebScarab ESAPI SQLMap SQL Ninja SWF Intruder O2 Orizon Code Crawler 91

OWASP Building Guide Al fine di comprendere ed eliminare le cause della insicurezza nel software,owasp ha sviluppato la guida per lo sviluppo delle applicazioni web sicure pensata per: Sviluppatori per implementare i meccanismi di sicurezza ed evitare le vulnerabilità; Project manager che la utilizzano per identificare le attività da svolgere (threat modeling, code review, development); Team di sicurezza che la usano per apprendere le tematiche di application security e l approccio per la messa in sicurezza;

OWASP Code Review Guide Descrive la metodologia OWASP per testare il codice di un applicazione (white box testing, conoscendo il codice sorgente)

OWASP Testing Guide Descrive la metodologia OWASP per testare la sicurezza di un applicativo web SANS Top 20 2007 NIST Technical Guide to Information Security Testing (Draft) Gary McGraw (CTO Cigital) says: In my opinion it is the strongest piece of Intellectual Property in the OWASP portfolio

OWASP ESAPI: il problema Jasypt Java Pattern Commons Validator Cryptix Struts xml-dsig JCE Reform Spring xml-enc ACEGI HDIV Write Custom Code Java URL Encoder Log4j JAAS BouncyCastle Anti-XSS Java Logging Stinger Many More Standard Control

Immaginate un Enterprise Security API ESAPI con tutti i controlli di sicurezza necessari e che sia: Standardizzato Centralizzato Integrato High Quality Intuitivo Testato Che risolva i problemi dei controlli mancanti o bypassabili

Authenticator User AccessController AccessReferenceMap Validator Encoder HTTPUtilities Encryptor EncryptedProperties Randomizer Exception Handling Logger IntrusionDetector SecurityConfiguration Enterprise Security API Custom Enterprise Web Application Enterprise Security API Existing Enterprise Security Services/Libraries 97

Esempio di Encoding no corretto

Encoding: individuate il codice vulnerabile

Encoding: come fixare

Encoding: dimostrazione della corretta implementazione

Domanda: In generale quanto tempo è necessario per fixare 10 gravi vulnerabilità indivuate da un test eseguito sulla nostra applicazione? Difficile da stimare, comunque si parla di N mesi uomo almeno Il costo è sempre talmente elevato che è più conveniente lasciarle in produzione Dipende dal team di sviluppo: in 3 settimane lavorando bene si potrebbero eliminare dalla produzione

Linee guida e tool OWASP nel modello SAMM Governance Construction Verification Deployment 103 103

Domande? Site: http://www.mindedsecurity.com Blog: http://blog.mindedsecurity.com DOMinator: https://dominator.mindedsecurity.com Mail: matteo.meucci@mindedsecurity.com Grazie!