Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Matteo Meucci Software Security in practice - Aiea torino - 30-10-2015


Published on

Matteo Meucci did a talk on software security in practice, describing the actual scenario and the roadmap for the enterprise to improve their maturity in the SDLC.

Published in: Technology
  • Be the first to comment

Matteo Meucci Software Security in practice - Aiea torino - 30-10-2015

  1. 1. Software Security in Practice Matteo Meucci CEO Minded Security AIEA Turin – 30-10-2015
  2. 2. Agenda I Part) Introduction to Software Security 1.1 Scenario 1.2 What is the state of the Information Security today? 1.3 The main targets of the cyber attacks II Part) How OWASP can support Enterprises 2.1 Web Application Security: the OWASP Guides today 2.2 How to use the testing guide in your processes III part) A structured approach to software security  3.1 OWASP Guidelines and tools in SDLC 3.2 Outsourcing Governance 3.3 SAMM: the assessment to evaluate your Software Development LifeCycle  3.4 Case-Study: how Companies are approaching the Governance of Software Security
  3. 3. Informatics Engineer (since 2001) Research • OWASP contributor (since 2002) • OWASP-Italy Chair (since 2005) • OWASP Testing Guide Lead (since 2006) Work • 14+ years on Information Security focusing on Software Security • CEO @ Minded Security – The Software Security Company (since 2007) 3 Who am I?
  5. 5. InfoSec scenario: software is the key point Users Cyber criminals Companies Governments Software
  6. 6. Is your Google mail secure? • Yes! • No! • I don’t know
  7. 7. What is Secure Software? It’s secure! Looks at the lock, down on the right! It’s secure! It’s Google! Sure! The news said that is unbreakable!
  8. 8. Software Security Principles • The Vulnerabilities in the software development process are expected. • The control of the security bugs and flaws in the software should be considered as part of the process of software development. • Vulnerability management (fixing process) is the most important step of the process of software security.
  10. 10. 2014 Attacks In 2014, 5 out of 6 companies have been the victim of cyber attacks (+ 40% over 2013, Symantec report 2014) 30.000 websites are hacked every day to distribute malware (SOPHOS - Security Threat Report 2012) 2014 important security breaches (DBIR 2015):
  11. 11. What is the state of the security today? Attackers Are Moving Faster, Defenses Are Not With Heartbleed, attackers moved in to exploit these vulnerabilities much faster than vendors could create and roll out patches. In 2014, it took 204 days, 22 days, and 53 days, for vendors to provide a patch for the top three most exploited zero-day vulnerabilities. Attackers Are Streamlining and Upgrading Their Techniques, While Companies Struggle to Fight Old Tactics Attackers making each attack more selective by infecting legitimate websites, monitoring site visitors and targeting only the companies they wanted to attack. Also Small and Medium sized organizations are under attacks Last year, 60 percent of all targeted attacks struck small- and medium-sized organizations. These organizations often have fewer resources to invest in security, and many are still not adopting basic best practices like blocking executable files and screensaver email attachments.
  13. 13. Target of data breach: what vector attacks are more used today? •Web Applications: access to the DB to stole Credit card or personal user information. Attack vettor: SQL injection, XSS •Crimeware: Five out of every six large companies were targeted with spear-phishing attacks in 2014, a 40 percent increase over the previous year. Attack vector: email, fake sites •Cyber espionage: Governments use cyber espionage to take the control of humans, systems, trade secrets. Attack vector: 0day •DoS: botnet are used to perform distributed attack to sites do deny the services to legitamate users. Attack vector: malware
  14. 14. Attacks to Companies • Companies are attacked on the web applications and on their personnel (email, fake sites, malware, mobile) • The top three industries affected are the same as previous years: Public, Information, and Financial Services. (Verizon) • In 60% of cases, attackers are able to compromise an organization within minutes. (Verizon) • The time of reaction it is really slow today 14
  16. 16. OWASP has ~140 Projects • PROTECT - These are tools and documents that can be used to guard against security-related design and implementation flaws. • DETECT - These are tools and documents that can be used to find security-related design and implementation flaws. • LIFE CYCLE - These are tools and documents that can be used to add security-related activities into the Software Development Life Cycle (SDLC).
  17. 17. Developer Guide • The First OWASP ‘Guide’ • Complements OWASP Top 10 • 310p Book (on wiki too) • Many contributors • Apps and web services • Most platforms • Examples are J2EE, ASP.NET, and PHP • Unfortunately Outdated • Project Leader and Editor  Andrew van der Stock,
  18. 18. Code Review Guide • Most comprehensive open source secure code review guide on the web • Years of development effort • Version 1.1 produced during 2008 • Numerous contributors • Version 2.0 effort launched in 2012 • Project Leader and Editor  Eoin Keary,
  19. 19. Code Review Guide public void findUser() { boolean showResult = false; String username = this.request.getParameter("username"); ... this.context.put("username", username); this.context.put("showResult", showResult); }
  20. 20. Testing Guide • Most comprehensive open source secure testing guide on the web • Years of development effort • Version 4.0 produced in 2014 • Hundred of contributors • Project Leader and Editor • Matteo Meucci, Andrew Muller ,
  21. 21. Testing Guide new/ %22%3E%3Cscript%3Ealert%28123%29%3C/script%3E%3 C%22
  22. 22. The OWASP Testing Guide: Community driven for all the Enterprises
  23. 23. The state of the art of the Web Application Penetration Testing
  24. 24. Fight with the same weapons (knowledge)
  25. 25.  July 14, 2004 "OWASP Web Application Penetration Checklist", V1.0  December 25, 2006 "OWASP Testing Guide", V2.0  December 16, 2008 "OWASP Testing Guide", V3.0  September 17, 2014 "OWASP Testing Guide", V 4.0 Citations: • NIST SP800-115 “Technical Guide to Information Security Testing and Assessment” • Gary McGraw (CTO Cigital) says: “In my opinion it is the strongest piece of Intellectual Property in the OWASP portfolio” – OWASP Podcast by Jim Manico • NSA’s "Guidelines for Implementation of REST“ • Official (ISC)2 Guide to the CSSLP - Page: 70, 365 • Many books, blogs and websites Testing Guide History Note: use the Guide only on your local applications or be sure to have an NDA in place with the owner of the application before test it.
  27. 27. How to use the methodology Web Application Source Code public void findUser() { boolean showResult = false; String username = this.request.getParameter("us ername"); ... this.context.put("username", ESAPI.encoder().encodeForHT MLAttribute(username)); this.context.put("showResult", showResult); } Methodology Report Fixing Methodology Retest Report
  28. 28. Common misunderstanding
  29. 29. Example of unstructured approach: Ministry of Informatics
  30. 30. Actors User: who uses the software Ministry of Informatics: who buys the software Development teams (internal/external): who develops the software
  31. 31. Press conference for the launch of the service Now you can take advantage of a new service on the portal of the Ministry of Informatics Fantastic!! Compliments!!
  32. 32. The day after…
  33. 33. Users access to the portal… John Black – 12/12/1970 – Josh White - 10/09/1982 – Paul Red– 09/02/1960 –
  34. 34. Users access to the portal… Oh oh...I find a problem...
  35. 35. Some days after…
  36. 36. The reactions… it was possible? Fault of the developers! but it is impossible !? We followed all your instructions If you do not ask for security, no one will develop secure software Use the Testing Guide as common framework
  37. 37. An year after…another security breach but it is impossible!? We adopt the OWASP Testing Guide! Web Application Penetration testing is not enough! If you do not design a correct vulnerability fixing process you will not solve the vulnerabilities of your application it was possible? Fault of the developers!
  40. 40. The Importance to use all the OWASP resources into your SDLC If you do not ask for security, no one will develop secure software Use the OWASP Software Contract Annex to regulate your outsourcer contracts If you do not know the application threats, you will develop unsecure software Use the OWASP Top 10 for General Awareness Use the CISO Guide for Management’s Awareness Vulnerabilities in the software development process are expected Use the OWASP Building Guide and ESAPI to write more secure software Use the OWASP Secure Code Review Guide to review the code Use the OWASP Testing Guide to review to test your application
  41. 41. The Importance to use all the OWASP resources into your SDLC The fixing process is the most important step of the process of software security Retest your application after a bug fixing or a new release to be sure that the right implementations are in place How can I manage the Software Security Governance? Use the OWASP SAMM to assess your maturity and to build an Application Security Program to manage the SDLC
  42. 42. 42 OWASP Guidelines in the SAMM model Governance Construction Verification Deployment 42
  44. 44. Secure SDLC Costs relating the fixing in the phases of SDLC Source: Official (ISC)2 Guide to CSSLP (2011)
  45. 45. Source: Official (ISC)2 Guide to CSSLP (2012) SDLC Stakeholders
  46. 46. Secure SDLC Fasi SDLC Secure Software processes Define Secure Software Requirements Design Secure Software Design Develop Secure Software Implementation Deploy Secure Software Testing & Acceptance Maintain Secure Software Deployment & Maintenance
  47. 47. Roles and responsabilities 4 7 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 SCR and WAPT Hardening Fixing Business Analyst Security Manager Business Analyst AppSec Specialist Business Analyst Software Architect, AppSec Specialist Security Manager Application Owner Software Architect Security Manager Security Manager Developer AppSec Specialist Developer Security Manager App Owner Sistemista Sistemista AppSec Specialist Sec Manager App Owner Develper
  48. 48. Development Team Code Review Team Application Testing Team Outsourcing Contratto di sviluppo (Fornitore) (Committente) Contratto di sviluppo
  49. 49. Collaudo software 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 )
  50. 50. 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.
  51. 51. 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).
  52. 52. Modello di Software Acceptance Sviluppo Cliente Secure Software Development Contract 1. Security Requirements 2. Librerie e framework 3. Security Review 4. Assurance 5. Acceptance Secure Software Development Contract
  53. 53. (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.”
  54. 54. (1) Esempio di security Requirements ID Requisito Data Validation-003 – UTILIZZARE I PREPARED STATEMENT Descriz. 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); ....
  55. 55. (1) Esempio di checklist
  56. 56. (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, open-source 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.
  57. 57. (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.
  58. 58. (3) Security Review • In questa fase viene effettuato il processo di Validate & Verify secondo il modello CMMI v.1.1: – 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
  59. 59. (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.
  60. 60. (5) Acceptance • Considerazioni generali •Tutti i requisiti funzionali e di sicurezza sono stati completati come da contratto? Criteri di completezza •Esiste un processo per gestire le richieste di cambiamento? Change Management •Il rischio residuo di acceptance e le eccezioni alle policy sono entro i limiti stabiliti? Accettazione del rischio ed exception policy •Tutta la documentazione è disponibile? Documentazione del software
  61. 61. (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.
  62. 62. Security issue management and acceptance Sviluppo Cliente Secure Software Development Contract 1. Security Requirements 2. Librerie e framework 3. Security Review 4. Assurance 5. Acceptance Secure Software Development Contract
  63. 63. FALSI MITI Comuni reazioni da parte dei fornitori: (1) Non vi preoccupate sviluppiamo utilizzando lo standard OWASP (2) Broken Authentication Session Hijacking, Liferay offre una serie di feature di sicurezza per la gestione dell’autenticazione e anche per altre possibili security issues (3) Cross Site Scripting: JSF ha una serie di feature di sicurezza anti XSS (4) Broken Access Control: garantito dall’applicazione che andremo a sviluppare
  65. 65. SAMM goals • SAMM allows a Company to: – Measure and improve software security best practices – Focus on security risk to make effective use of security resources – Find vulnerabilities earlier in the development process – Design a Roadmap to manage the software security in your projects
  66. 66. OWASP SAMM: objectives The SAMM’s goals are: Evaluate an organization’s existing software security practices Build a balanced software security assurance program in well-defined iterations Demonstrate concrete improvements to a security assurance program Define and measure security-related activities throughout an organization
  67. 67. OWASP SAMM: 4 Business functions Define Design Develop Deploy Maintain 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
  68. 68. OWASP SAMM: 12 Security Practices
  69. 69. Governance • Strategy & Metrics involves the overall strategic direction of the software assurance program and instrumentation of processes and activities to collect metrics about an organization’s security posture. • Policy & Compliance involves setting up a security and compliance control and audit framework throughout an organization to achieve increased assurance in software under construction and in operation. • Education & Guidance involves increasing security knowledge amongst personnel in software development through training and guidance on security topics relevant to individual job functions. 6 9 Governance Strategy & Metrics Policy & Compliance Education & Guidance
  70. 70. Construction • Threat Assessment involves accurately identifying and characterizing potential attacks upon an organization’s software in order to better understand the risks and facilitate risk management. • Security Requirements involves promoting the inclusion of security-related requirements during the software development process in order to specify correct functionality from inception. • Secure Architecture involves bolstering the design process with activities to promote secure-by- default designs and control over technologies and frameworks upon which software is built. 7 0 Construction Threat Assessment Security Requirements Secure Architecture
  71. 71. Verification • Design Review involves inspection of the artifacts created from the design process to ensure provision of adequate security mechanisms and adherence to an organization’s expectations for security. • Code Review involves assessment of an organization’s source code to aid vulnerability discovery and related mitigation activities as well as establish a baseline for secure coding expectations • Security Testing involves testing the organization’s software in its runtime environment in order to both discover vulnerabilities and establish a minimum standard for software releases. 7 1 Verification Design Review Code Review Security Testing
  72. 72. Deployment • Vulnerability Management involves establishing consistent processes for managing internal and external vulnerability reports to limit exposure and gather data to enhance the security assurance program. • Environment Hardening involves implementing controls for the operating environment surrounding an organization’s software to bolster the security posture of applications that have been deployed. • Operational Enablement involves identifying and capturing security-relevant information needed by an operator to properly configure, deploy, and run an organization’s software. Deployment Vulnerability Management Environment Hardening Operational Enablement
  73. 73. 73 SAMM activities 1. Conduct the first assessment 2. Create a score card 3. Create a Software Security Program 1. Metrics 2. Road map 4. Implement the objectives of the roadmap and conduct a new assessment
  74. 74. Step 0: SAMM Startup • Give a presentation of SAMM model and objectives to all the people involved in the assessment in the Company • Collect the name and functions of the people involved in the assessment with the SAMM sponsor (Roles and responsability)
  75. 75. Step 1: conduct the assessment
  76. 76. Step 2: evaluate the assessment
  77. 77. Step 3: create the scorecard
  78. 78. Step 4: create the roadmap • For each Security Practice write down the Activities to implement • Evaluate the benifts and the efforts for the organization necessary to improve each Security Practice.
  79. 79. Step 4: create the roadmap
  80. 80. Step 5: Magic quadrant for the actions
  81. 81. Step 6: scorecard with roadmap
  82. 82. Step 7: write the report
  84. 84. What Italian Companies are doing today Area: Governance Activities Participants Strategy and Metrics Conduct periodic industry wide cost comparisons, collect metrics for historic security spend (% project), past spending. 10% Policy and Compliance Identify and monitor external compliance drivers, build and maintain compliance guidelines. 80% Education and Guidance Training courses for Developers, Analysts, Auditors and Workshop for Management. 55% Source: Minded Security – Results of 12 assessments from 2012 to 2015
  85. 85. What Italian Companies are doing today (2) Area: Construction Activities Participants Secure Architecture Build the document for the Governance of the development outsourcing process. 30% Security Requirements Develop: “Building Secure applications guidelines”. 60% Secure Design Apply the methodology of threat modeling to the projects evaluated with medium to high risk in the definition phase of the project and the specific 10% Source: Minded Security – Results of 12 assessments from 2012 to 2015
  86. 86. What Italian Companies are doing today (3) Area: Verification Activities Participants Design Review Identify software attack surface, Analyze design against known security requirements, Inspect for complete provision of security mechanisms. 20% Code Review Conduct Manual Secure Code Review for critical applications 30% Security Testing Conduct penetration testing on software releases with fixing support. 75% Source: Minded Security – Results of 12 assessments from 2012 to 2015
  87. 87. What Italian Companies are doing today (4) Area: Deployment Activities Participants Vulnerability Management Create information security response team(s) for the application security, Establish consistent incident response process, Conduct root cause analysis for application security incidents. 20% Environment Hardening Develop Hardening procedures for all your technologies, Implement a fixing process to be sure to patch all the issues identified during the security assessment. 60% Operational Enablement Request support for fixing all the vulnerabilities identified during the Secure Code Review and Penetration Testing activities. 40% Source: Minded Security – Results of 12 assessments from 2012 to 2015
  88. 88. Companies Worldwide: BSIMM 6
  89. 89. Key point to implement a Software Security Program (SSP) Carrying out the activities of a SSP without commitment of the Companies is very unlikely • Identify and work with Software Security Group (SSG): The internal group charged with carrying out and facilitating the SSP. • Identify and promote Satellite groups in your Company: a group of interested and engaged developers, architects, software managers, testers, who have a natural affinity for software security. A strong SSG is fundamental to carry on the software security initiative.
  90. 90. Key point to have a mature Software Security Program (SSP) A fast fixing process is the key to have a mature SSP • Satellite architects: should fix flaws asap • Satellite developers: should fix bugs asap • Satellite tester: should test if the remediations are strong enough asap. A strong satellite is the key of a mature software security initiative.
  91. 91. Next steps? Companies will: • Hire Information Security managers. • Hire Talents skill on Application Security in your organizations. • Implement Software Security Governance. • Provide ongoing education and training: guidelines and company policies for protecting sensitive data on personal and corporate devices. • Prepare for the worst: Incident management crises.
  93. 93. REFERENCES • OWASP: • nts_Database_Project • Rapporto CLUSIT 2015 • Enisa European Threat Landscape 2014 • Symantec Internet-security-threat-report-volume-20-2015 • Verizon rp_data-breach-investigation-report-2015 •Ponemon Institure Report 2015 • OWASP SAMM: • BSIMM v6: