V Conference on Application Security and Modern Technologies In collaborazione con Venezia, Università Ca Foscari 6 Ottobre 2017 1
Matteo Meucci OWASP Nuovi standard per la sicurezza applicativa 2
<AGENDA> 1. How OWASP can help Companies on software security 1.1 Devs, Architects 1.2 Auditors, Testers 1.2 CISO, Management 2. Focus on SAMM and GDPR </AGENDA> 3
Who Am I? Informatics Engineer (since 2001) Research: OWASP contributor (since 2002) OWASP-Italy Chair (since 2005) OWASP Testing Guide Lead (since 2006) Work: 16+ years on Information Security focusing on Software Security CEO @ Minded Security The Software Security Company (since 2007) 4
1. How OWASP can help on software security 5
www.owasp.org The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit also registered in Europe as a worldwide charitable organization focused on improving the security of software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is welcomed to participate in OWASP and all of our materials are available under free and open software licenses. 6
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). 7
Equifax Incident September 2017 Impacting approximately 143 million consumers Reason: Using library with known vulnerabilities (Apache Struts 2 vulnerability CVE-2017-5638) 8 Timo Pagel
Detection of Components with Known Vulnerabilities Through 2020, 99% of vulnerabilities exploited will continue to be ones known by security and IT professionals for at least one year. Gartner, 2016 Source: Gartner s Top 10 Security Predictions 2016 9 Timo Pagel
Do you see there? Can you see a Secure Software? 10
DEVELOPERS, ARCHITECTS I would like to build secure software 11
OWASP TOP10 2017 (?) A1-Injection A2-Broken Authentication and Session Management A3-Cross-Site Scripting (XSS) A4-Broken Access Control A5-Security Misconfiguration A6-Sensitive Data Exposure A7-Insufficient Attack Protection A8-Cross-Site Request Forgery (CSRF) A9-Using Components with Known vulnerabilities A10-Underprotected APIs Top 2013 is available in italian language 12
TOP10 PROACTIVE CONTROLS 1. Verify for Security Early and Often 2. Parameterize Queries 3. Encode Data 4. Validate All Inputs 5. Implement Identity and Authentication Controls 6. Implement Appropriate Access Controls 7. Protect Data 8. Implement Logging and Intrusion Detection 9. Leverage Security Frameworks and Libraries 10. Error and Exception Handling Project leaders: Jim.Manico@owasp.org Jim.Bird@owasp.org Katy.Anton@owasp.org 13
OWASP CHEAT SHEETS Authentication Cheat Sheet Clickjacking Defense Cheat Sheet Cross-Site Request Forgery Prevention Cheat Sheet DOM based XSS Prevention Cheat Sheet HTML5 Security Cheat Sheet Input Validation Cheat Sheet Query Parameterization Cheat Sheet Session Management Cheat Sheet SAML Security Cheat Sheet Transport Layer Protection Cheat Sheet Unvalidated Redirects and Forwards Cheat Sheet XSS (Cross Site Scripting) Prevention Cheat Sheet 14
AUDITORS, TESTERS I would like to find all the bugs in this software 15
CODE REVIEW GUIDE Most comprehensive open source secure code review guide on the web Years of development effort Version 2 Numerous contributors Project Leader and Editor eoin.keary@owasp.org www.owasp.org/index.php/code_review_guide 16
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); } 17
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 matteo.meucci@owasp.org, andrew.muller@owasp.org www.owasp.org/index.php/testing_guide 18
TESTING GUIDE http://127.0.0.1:8080/jforum-new/jforum.page?action =finduser&module=pm&username=%22%3e%3cscr ipt%3ealert%28123%29%3c/script%3e%3c%22 19
CISO, Management I would like to implement a Roadmap for Software Security 20
Secure SDLC SDLC phases 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 21
SDLC Stakeholders Source: Official (ISC)2 Guide to CSSLP (2012) 22
Roles and responsabilities Define Design Develop Risk Assessment Secure Design Design Review Business Analyst AppSec Specialist Security Manager Security Manager Application Owner Secure Requirements Business Analyst Security Manager Secure Architecture Software Architect Security Manager Threat Modeling Secure Development Business Analyst Software Architect, AppSec Specialist Deploy Software Acceptance Security Manager App Owner Secure Installation Developer System Engineer SCR and WAPT Hardening AppSec Specialist Maintain Web Intrusion Monitoring AppSec Specialist Sec Manager Change Management App Owner Develper System Engineer Fixing Developer 23
OWASP for CISO Use the OWASP Software Contract Annex to regulate your outsourcer contracts Use the CISO Guide for Management s Awareness Use the OWASP TopTen Proactive Controls, the Building Guide and Cheat sheets to write more secure software Use the OWASP Secure Code Review to review the code Use the OWASP Testing Guide to review to test your application 24
OWASP FOR CISO (2) 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 Use the OWASP SAMM to assess your maturity and to build an Application Security Program to manage the SDLC The OWASP Application Security Verification Standard (ASVS) Project provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development. 25
Software Contract Annex 26
Software Contract Annex: the model 1. Security Requirements Client Development 5. Acceptance Secure Software Development Contract 4. Assurance 2. Libraries and frameworks 3. Security Review Secure Software Development Contract 27
OWASP Application Security Verification Standard (ASVS) 28
ASVS 29
ASVS Authentication Verification Requirements 30
OWASP Software Assurance Maturity Model (SAMM) 31
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 32
OWASP SAMM: objectives The SAMM s goals are: Define and measure security-related activities throughout an organization 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 33
OWASP SAMM: 4 Business functions Define Governance Software development management activities and organisation-wide business processes Design Develop Construction Goal definition and software creation processes Deploy Verification Checking, evaluation and testing of software development artifacts Maintain Deployment Software release management and normal operational management 34
OWASP SAMM: 12 Security Practices 35
Step 1: conduct the assessment 36
Step 2: evaluate the assessment 37
Step 3: create the scorecard 38
Step 4: create the roadmap For each Security Practice write down the Activities to implement Evaluate the benefits and the efforts for the organization necessary to improve each Security Practice. 39
Step 4: create the roadmap 40
CASE-STUDY: HOW COMPANIES ARE APPROACHING THE GOVERNANCE OF SOFTWARE SECURITY 41
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 14 assessments from 2012 to 2016 42
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 14 assessments from 2012 to 2016 43
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 14 assessments from 2012 to 2016 44
What Italian Companies are doing today (4) Area: Deployment Vulnerability Management Activities Create information security response team(s) for the application security, Establish consistent incident response process, Conduct root cause analysis for application security incidents. Develop Hardening procedures for all your technologies, Implement a fixing process Environment Hardening to be sure to patch all the issues identified during the security assessment. Request support for fixing all the vulnerabilities identified during the Secure Operational Enablement Code Review and Penetration Testing activities. Participants 20% 60% 40% Source: Minded Security Results of 14 assessments from 2012 to 2016 45
And finally the GDPR... 46
GDPR The General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) is a regulation by which the European Parliament, intend to strengthen and unify data protection for all individuals within the European Union (EU). It also addresses the export of personal data outside the EU. The GDPR aims primarily to give control back to citizens and residents over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU. 47
GDPR: impact on Application Security Article Art. 4: Expansion of definition of personal data Activities The GDPR s definition of the personal data that must be protected is more detailed and broad than previous regulations. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information or a computer IP address. The GDPR includes a requirement to implement data protection by design and by default. This requirement involves creating applications from scratch with security and data protection in mind. Art. 25: Security For applications, security by design incorporates activities like threat by Design modeling, secure design, training developers on secure coding best practices, and ensuring that developers are not only coding securely, but also identifying and remediating security-related defects in their code (fixing) 48
GDPR: impact on Application Security (2) Article Activities Article 28 states that, in choosing a data processor(outside vendor), the controller shall select a processor providing sufficient guarantees to implement appropriate technical and organisational measures and Art. 28: procedures in such a way that the processing will meet the requirements Third-party of this Regulation and ensure the protection of the rights of the data vendor security subject. For application security, this means you can t assume the security of third-party software. You need sufficient guarantees that these externally sourced applications comply with the EU GDPR. Art. 33: Notification of a Under the EU GDPR, breach notification will become mandatory in all personal data member states where a data breach is likely to result in a risk for the breach to the rights and freedoms of individuals. This must be done within 72 hours of first having become aware of the breach. Data processors will also supervisory be required to notify their customers without undue delay after first authority becoming aware of a data breach. 49
SDLC and GDPR Art. 4: Expansion of definition of personal data Define Design Develop 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 Deploy Maintain Hardening Fixing 50
SDLC and GDPR Art. 25: Security by Design Define Design Develop 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 Deploy Maintain Hardening Fixing 51
SDLC and GDPR Art. 28: Third-party vendor security Define Design Develop 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 Deploy Maintain Hardening Fixing 52
SDLC and GDPR Art. 33: Notification of a personal data breach to the supervisory authority Define Design Develop 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 Deploy Maintain Hardening Fixing 53
SDLC and GDPR: advantages GDPR and SDLC re-inforce each other (ab)use GDPR to start SDLC (business case) Improve SDLC by including GDPR activities SDLC deliverables with GDPR demonstrate compliance Thanks to: Embedding GDPR into the SDLC. Sebastien Deleersnyder, Siebe De Roovere 54
th OWASP Day: 20 October Cagliari 55
Thanks! MATTEO.MEUCCI@owasp.org https://twitter.com/matteo_meucci www.owasp.org 23/09/2016 56