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

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

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

4. 3 100 apps written by 100 developers at 100 companies What CIOs Get  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  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 Why  1 company has a responsible appsec program  1 developer has any security training  1 company has a responsible appsec program  1 developer has any security training Filename/RPS Number Adapted from: The Open Web Application Security Project,Jeff Williams, Aspect Security, SWA Forum Sept 2010 We Trust We Blame We Hide

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

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

7. 6 OPEN SAMM –Open Software Assurance Maturity Model (SAMM)  http://www.opensamm.org/ 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. 7 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  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 Courtesy of September 2010 SwA Panel SwA Practices – Getting to Effectiveness in Implementation

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

10. 9 SwA Must Translate to Organizational and Mission/ Business Focused Stakeholders 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 TIER 3 Information System (Environment of Operation) TIER 2 Mission / Business Process (Information and Information Flows) TIER 1 Organization (Governance)

11. 10 Communication Across Organizational Stakeholders Is Critical to addressing ICT SCRM and SwA Challenges The Assurance PRM Is A Holistic Framework that connects CMMI and RMM to facilitate communication https://buildsecurityin.us-cert.gov/swa/proself_assm.html 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 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 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 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 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 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 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 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 Acquisition and Supplier Management AM 1 Select, manage, and use effective suppliers and third party applications based upon their assurance capabilities. Acquisition and Supplier Management AM 1 Select, manage, and use effective suppliers and third party applications based upon their assurance capabilities. Enable Resilient Technology Define Business Goals Sustained environment to achieve business goals through technology Prioritize funds and manage risks

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

13. 12 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. 13 Understand Assurance-Related Process Capability Expectations Look to Standards for Assurance Process Detail Understand Your Business Requirements for Assurance Build or Refine and Execute Your Assurance Processes Measure Your Results Process Improvement Lifecycle - A Process for Achieving Assurance Adapted from: Paul Croll, Computer Sciences Corporation, August 2007

15. 14 The Solution Requires A Balance Of Benchmarks  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

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

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

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

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

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

21. 20 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. 21 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. 22 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. 23 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. 24 Back-up

26. 25 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