Michele Moss OWASP AppSecDC 2010 Conference November 10, 2010

1. People, Process, and Technology: OWASP Impact on the SwA Processes and Practices Working Group Michele Moss OWASP AppSecDC 2010 Conference November 10, 2010

2. Table Of Contents People Background People, Technology, Process Next Steps Measures Technology

3. What CIOs want https://www.cioexecutivecouncil.com October 11, 2006 Press Release

4. 100 apps written by 100 developers at 100 companies What CIOs Get Why 1 company has a responsible appsec program 1 developer has any security training • 83 apps have serious vulnerabilities • 72 apps have cross site scripting • 40 apps have SQL Injection • 100 apps contain code of unknown origin • 90 apps use un-patched libraries with known flaws • 5 apps have h ad a scan or pentest • 1 app has had a manual security code review • 0 apps provide any visibility into security Adapted from: The Open Web Application Security Project ,Jeff Williams, Aspect Security, SWA Forum Sept 2010 Filename/RPS Number

5. Vocabulary Reserved Words Priorities Perspective SwA Requires Multi-disciplinary Collaboration • Communication • Challenges Project Management System Engineering Information Assurance • Experience • Objectives • Drivers • Risks Software Assurance Software Acquisition Software Engineering Information Systems Security Engineering Test & Evaluation Safety and Security Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html Without a common language we cannot communicate across disciplines

6. Table Of Contents People Background People, Technology, Process Next Steps Measures Technology

7. OPEN SAMM Open Software Assurance Maturity Model (SAMM) http://www.opensamm.org/ Open framework to help organizations formulate and implement a strategy for software security tailored to specific risks http://www.opensamm.org/downloads/SAMM-1.0.pdf

8. Why Customer pressure Reaction to an incident Why Not Compliance drivers don’t exist Focus is on systems and networks Secure software training is not given to developers and architects How Executive leadership commitment Translate ROI to project manager vocabulary (cost, schedule, quality) Start small and build Use coding standards Empower secure development to prevent a product from moving to the next milestone Avoid creating a new language Leverage what is already known Increase automation of menial tasks Implementation Lessons Learned • Who • Secure development SMEs • Developers • What • Measure progress (training, secure code reviews, security change requests) • Internal policy • When • During product development process • During Leadership discussions • As part of development and acquisition reviews • Where • IT Development Organizations • IT Acquisition Organizations • IT Integrator Organizations Courtesy of September 2010 SwA Panel SwA Practices – Getting to Effectiveness in Implementation

9. Stakeholders People Organizations Supplier Executive OSAMM ESAPI Checklists Secure Code Review OWASP Top 10 AntiSammy Acquirer Practitioner WebGoat Developer Guides ASVS Legal Project Secure Coding Practices – Quick Reference Testing Guide

10. SwA Must Translate to Organizational and Mission/ Business Focused Stakeholders TIER 1 Organization (Governance) TIER 2 Mission / Business Process (Information and Information Flows) TIER 3 Information System (Environment of Operation) Source: NIST 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems A Security Life Cycle Approach In a way that is applicable in diverse contexts (Defense, National Security, Finance, Heath care, Aviations, Telecommunications) and is not a source of liability or misunderstanding in acquisition decisions

11. Communication Across Organizational Stakeholders Is Critical to addressing ICT SCRM and SwA Challenges Development Project DP 1 Identify and manage risks due to vulnerabilities throughout the product and system lifecycle DP 2 Establish and maintain assurance support from the project DP 3 Protect project and organizational assets Enterprise Assurance Support ES 1 Establish and maintain organizational culture where assurance is an integral part of achieving the mission ES 2 Establish and maintain the ability to support continued delivery of assurance capabilities ES 3 Monitor and improve enterprise support to IT assets Define Business Goals Development Organization DO 1 Establish the assurance resources to achieve key business objectives DO 2 Establish the environment to sustain the assurance program within the organization Prioritize funds and manage risks Acquisition and Supplier Management AM 1 Select, manage, and use effective suppliers and third party applications based upon their assurance capabilities. Development Engineering DE 1 Establish assurance requirements DE 2 Create IT solutions with integrated business objectives and assurance DE 3 Verify and Validate an implementation for assurance Sustained environment to achieve business goals through technology Enable Resilient Technology The Assurance PRM Is A Holistic Framework that connects CMMI and RMM to facilitate communication https://buildsecurityin.us-cert.gov/swa/proself_assm.html

12. Enterprise Leadership and Resilient Technology Prioritize funds and manage risks COO CEO Business Functions Business Processes CFO Define Business Goals Organization Mission tech Development Organization protect sustain CIO Assets in Production Service Sustained environment to achieve business goals through technology Service Mission Service Mission Enterprise Assurance Support tech facilities people info CTO Adapted from: Source: November 2009 SwA Forum-Evolution in SwA Processes Panel – David White, SEI Enable Resilient Technology Development Project Development Engineering

13. A Resilient Technology Best Practices Cross Walk You have been asked to ensure that the OWASP Top Ten (an assurance coding Standard) are not in the Code You can look at the OSAMM for guidance on how to do it https://buildsecurityin.us-cert.gov/swa/proself_assm.html

14. Process Improvement Lifecycle - A Process for Achieving Assurance Measure Your Results Understand Your Business Requirements for Assurance Build or Refine and Execute Your Assurance Processes Understand Assurance-Related Process Capability Expectations Look to Standards for Assurance Process Detail Adapted from: Paul Croll, Computer Sciences Corporation, August 2007

15. The chicken…. (a.k.a. Process Focused Assessment ) Management Systems (ISO 9001, ISO 27001, ISO 2000) Capability Maturity Models (CMMI, RMM, SSE-CMM ) Lifecycle Processes (ISO/IEEE 15288, ISO/IEEE 12207) COBIT, ITIL, MS SDL, OSAMM, BSIMM The egg … (a.k.a Product Focused Assessments) SCAP - NIST-SCAP ISO/OMG W3C – KDM, BPMN, RIF, XMI, RDF OWASP Top 10 SANS TOP 25 Secure Code Check Lists Static Code Analysis Pen Test Results The Solution Requires A Balance Of Benchmarks

16. SwA, SCRM, AndContinuousImprovement Contribute To Operational Resilience MAEC Are we being attacked? OVAL SCAP Compliance Incident Management and Control Apply Lessons Learned CAPEC CVSS, CAPEC MAEC, KDM How do we prevent this next time? Resilience Requirements Management Monitoring Enterprise Focus Who is attacking and what do they want? BPMN Applied to Measurement and Analysis Vulnerability Analysis and Resolution Are we at risk? Controls Applied to Asset Management Adapted from September 2010 SwA Forum, CERT RMM for Assurance , Lisa Young, SEI

17. Table Of Contents People Background People, Technology, Process Next Steps Measures Technology

18. ICT SCRM And SwA Are Complex Multi-Disciplinary Challenges Systems Engineering Information Security ICT Supply Chain Security Risk Management Project Management Application Security Software Assurance (SwA) System Engineering IT Resiliency Information Assurance Supply Chain & Logistics Software Assurance Software Acquisition Software Engineering Information Systems Security Engineering Test & Evaluation Safety and Security Source: https://buildsecurityin.us-cert.gov/swa/procresrc.html Source: September 28, 2010 SwA Forum, Standards Landscape and ICT SCRM Study Period Update, Nadya Bartol, Booz Allen Hamilton Filename/RPS Number

19. SCRM Stakeholders US (CNCI) has vital interest in the global supply chain. Other Users CIP SCRM STANDARDIZATION Enabled by Information Sharing SCRM “commercially acceptable global standard(s)” must be derived from Commercial Industry Best Practices. Commercial Industry DoD DHS & IA SCRM Standardization Requires Public-Private Collaborative Effort Courtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization

20. Standards Development Organizations Landscape: an SCRM Perspective Courtesy of Don Davidson, OSD TMSN ,Chief of Outreach and Standardization

21. ISO/IEC 27036: Information technology – Security techniques –Information Security for Supplier Relationships (proposed title) • Scope: This international standard covers information security in relationships between acquirers and suppliers to provide appropriate information security management for all parties. In particular, it also includes management of information security risks related to these relationships. • The standard will be subdivided into the following parts: • Part 1 – Overview and Concepts • Part 2 – Common Requirements • Part 3 – Guidelines for ICT Supply Chain • Part 4 – Guidelines for Outsourcing • Relevant Documents to be considered • Management Systems: ISO/IEC 27000 family; ISO 28000, Supply Chain Resiliency; ISO/IEC 20000, IT Service Management • Risk Management: ISO 31000, ISO/IEC 27005, and ISO/IEC 16085 • Lifecycle Processes and Practices, software acquisition, and software assurance ISO/IEC/IEEE 15288 (systems), ISO/IEC/IEEE 12207 (software), IEEE 1062 (software acquisition), ISO/IEC15026 (software assurance) • ISO TMB NWIP on Outsourcing Courtesy of Nadya Bartol, Booz Allen Hamilton

22. ISO/IEC 27034 – Guidelines for Application Security • Scope: The scope of this standard is to specify an application security life cycle, incorporating the security activities and controls for use as part of an application life cycle, covering applications developed through internal development, external acquisition, outsourcing/offshoring1, or a hybrid of these approaches. • Purpose and justification: • The standard provides guidance to business and IT managers, developers, auditors, and end-users to ensure that the desired level of security is attained in business applications in line with the requirements of the organization’s Information Security Management Systems (ISMS). • Application security addresses all aspects of security required to determine the information security requirements, and ensure adequate protection of information accessed by an application as well as to prevent unauthorized use of the application and unauthorized actions of an application. • Informational security concerns in business applications are to be addressed in all phases of the application life cycle, as guided by the organization’s risk management principles and the ISMS adopted. • This standard will provide guidance to establishing security goals and includes controls to verify that security target level has been reached. Application Security without any validated controls is a security illusion, and may be more hazardous for the organization. Courtesy of Nadya Bartol, Booz Allen Hamilton

23. ISO/IEC TR 24774:2010, Programming Language Vulnerabilities • Any programming language has vulnerabilities in its design • Sub-optimal coding practices can lead to security or safety failures • TR 24774 describes 71 classes of vulnerabilities in language-independent terms. • The second edition of the TR is now being drafted. It will add annexes that describe how to avoid the vulnerabilities in specific programming languages. • Annexes for C, Fortran, Ada and SPARK have been drafted. • We need experts in other languages, including scripting languages, to draft annexes. • Contact: • Convener: John Benito, benito@bluepilot.com • Secretary: Jim Moore, moorej@mitre.org Courtesy of Jim Moore, MITRE

24. What’s next? • Continued collaboration to: • Reach and enable developers • Reach and enable executives • Develop and promote resources for us by developers and executives • Participation in international standardization efforts • SC7 TAG intersections through your SC7 TAG • CS1/SC27 • IEEE representative to the SC7 TAG • SC22 • Participation through the SwA Working Groups and Forum • Stay Tuned …

25. Back-up

26. https://buildsecurityin.us-cert.gov/swa/proself_assm.html • The DHS SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts into a set of high-level goals and supporting practices (an evolution of the SwA community’s Assurance Process Reference Model) • The goals and practices are mapped to specific industry resources providing additional detail and real world implementation and supporting practices • Assurance Focus for CMMI • Building Security In Maturity Model • Open Software Assurance Maturity Model • CERT® Resilience Management Model • CMMI for Acquisition • CMMI for Development • CMMI for Services • SwA Community’s Assurance Process Reference Model –Initial Mappings • SwA Community’s Assurance Process Reference Model - Self Assessment • SwA Community’s Assurance Process Reference Model – Mapping to Assurance Models • Other valuable resources that are in the process of being mapped include • NIST IR 7622: DRAFT Piloting Supply Chain Risk Management Practices for Federal Information Systems • NDIA System Assurance Guidebook • Microsoft Security Development Lifecycle • SAFECode