A Warrior's Journey: Building a Global AppSec Program - OWASP Global AppSec 2020
1 like•626 views
The document presents a comprehensive framework for building a scalable global application security program by leveraging established strategies such as OWASP SAMM and BSIMM. It emphasizes the importance of culture, process, and governance in fostering security initiatives, and outlines practical steps for organizations at different maturity levels. Key elements include establishing a centralized security group, promoting security champions, and integrating security into development cycles to achieve continuous security at scale.
A Warrior's Journey: Building a Global AppSec Program - OWASP Global AppSec 2020
- 1. Brian Levine Senior Director, Product & Cloud Security A WARRIOR'S JOURNEY: BUILDING A GLOBAL APPSEC PROGRAM
- 2. A Warrior's Journey: Building a Global AppSec Program "Adapt what is useful, reject what is useless, and add what is specifically your own." -Bruce Lee This talk covers critical foundations for building a scalable Application Security Program. Drawing on warrior-tested strategies and assurance frameworks such as OWASP SAMM and BSIMM, this session gives actionable guidance on building and advancing a global application security program. Whether you are starting a fledgling security journey or managing a mature SSDLC, these foundational elements are core for achieving continuous security at scale. Brian Levine is Senior Director of Product Security for Axway, an enterprise software company, delivering product solutions and cloud services to global Fortune 500 enterprises and government customers.
- 3. About Brian Levine Senior Director Product & Cloud Security Axway Software Former Stuff: • Industrial Engineer, Purdue University • Systems Engineer, EMC & other places • Product Manager Security, Syncplicity
- 5. “Adapt what is useful, reject what is useless, and add what is specifically your own.” – Bruce Lee
- 6. • Foundations for building a scalable global application security program Outline & Agenda • Culture • Process • Governance
- 8. OWASP SAMM – “Secure Software Center of Excellence (SSCE)” BSIMM – “Software Security Group (SSG)” Axway – “Product Security Group (PSG)” Others – “Product Security Office (PSO)” ... Centralized Application Security Group a Rose by any other name...
- 9. OWASP SAMM v2.0 Organization & Culture
- 10. “According to our observations, the first step of a Software Security Initiative (SSI) is to form an SSG.” “without an SSG, success ... is very unlikely.” BSIMM – Software Security Group (SSG) Source: BSIMM11
- 11. GETTING STARTED • Secure Executive Sponsorship • Establish and Publicize the Charter and Scope • Define SSDLC goals & product objectives • Align with PM, Development, and Operations • Internal Evangelism • Selecting security tools, procedures, and driving adoption SOFTWARE SECURITY CENTER OF EXCELLENCE (SSCE) LEVELING UP • Stay Focused on the Customer (R&D) • Publish SSDLC Standards, Procedures, and Best Practices • Identify promising security champions to join the SSCE • External evangelism • DevSecOps automation, enabling self- service & continuous security • Data-driven program management
- 12. • 42% (55/130) of the firms in BSIMM11 study have a security champions program. • 65% of the firms that have been assessed more than once have a security champions program. SECURITY CHAMPIONS OWASP SAMM BSIMM
- 13. BUILDING • Identify individuals with interest/passion for security • 1 champion per development project • Provide formal training, workshops, and sponsorship for conferences, certifications, etc. • Executes SSDLC procedures (and scans) • Triages findings into product backlog • Work with SSG on Threat modeling and secure architecture • Reward and Recognize Publicly SECURITY CHAMPIONS PROGRAM SCALING • Multiple full-time champions per project • SPOCs push the curve identifying improvements, new security tools and procedures • Performs secure architecture design and threat models • Interested SPOCs rotate into the SSG “SPOC” Security Point of Contact
- 14. ANTI-PATTERNS • SPOC is the only member of the team responsible for security. All security tasks and questions assigned to SPOC • SPOC is responsible to prioritize security in the product development cycle (bottom-up) • Adversarial or subordinate relationship to the SSG SECURITY CHAMPIONS PROGRAM - GOTCHAS COURSE CORRECTIONS • All devs are responsible for fixing security defects. SPOC works with devops, build managers, etc. to automate security testing • Execs, Product Managers, Engineering Managers are responsible to prioritize security (top-down). • SSG exists to support R&D success. SSG and SPOC learn from each other to improve in a blameless culture.
- 16. Mandatory Developer Security Training EDUCATION & AWARENESS Structured Training Programs Security Events Recognition & Rewards Advanced, role-specific and platform-specific training, more hands-on Behavioral achievements & certifications •Security Days •Tournaments & Challenges •Capture the flag (CTF) OWASP Security Shepherd •Security Stars Program •Public Praise •SWAG •Brand your AppSec program (T-Shirts) •Hit-up your Vendors (Hoodies, Stickers, etc.)
- 17. PROCESS
- 18. Define Security Gates and Passing Criteria Source: Microsoft Security Development Lifecycle © 2010 Microsoft Corporation.
- 19. BSIMM SM1.4, “defining checks in the process first and enforcing them later is extremely helpful in moving development toward security without major pain. Socializing the conditions and then verifying them once most projects already know how to succeed is a gradual approach that can motivate good behavior without requiring it.” SECURITY GATES (PRO-TIP) Merge security into the existing development cycles. First, identify the gates & collect the results. But don’t enforce them (yet). “Be shapeless, formless, like water. Water can flow or water can crash. Be water.” –Bruce Lee
- 20. Third-party software component analysis • For Initial Security Review (ISR) and Final Security Review (FSR) the project is scanned using approved SCA tool(s). • All results are reviewed by the development team • All critical, high, and medium issues are resolved prior to release. (*with enforcement at FSR) EXAMPLE Security Gate / Security Bar Other Security Bars (gates) to define: • Threat modeling / Secure design review • Static Application Security Test (SAST) • Container Vulnerability Analysis • Attack surface analysis • Dynamic Application Security Test (DAST)
- 21. “I fear not who has practiced 10,000 kicks once, but I fear who has practiced one kick 10,000 times.” – Bruce Lee
- 22. CONTINUOUS SECURITY & DevSecOps • Initial Security Review (ISR) • Security Requirements • Threat Model • Training • Dynamic Analysis (DAST) • Attack Surface Analysis • Red Team Pentest • Container Scanning • Secure Code Review • Static Analysis (SAST) • 3rd-party Component Analysis • Incident/Intrusion Detection • Incident Response • Vulnerability Scanning • Hardening/Config Management • Infra Vulnerability Scanning • Verification • 3rd party pentesting • Access Control • Audits • Change Control • Vulnerability Management • Application Security Bar • Cloud Security Bar • Final Security Review (FSR) • Continuous Security Review (CSR) DEV OPS
- 23. CONTINUOUS SECURITY PIPELINE (example) Defect Management Tracking Attack Surface Analysis Dynamic Analysis (DAST) Threat Modeling Static Application Testing (SAST) Software Composition / 3rd- party (SCA) Container Security Code commit Deploy to Production Deploy to staging Threat & Risk Correlation Runtime Analysis & Monitoring Vulnerability Scanning Security Event Management (SIEM) CIS Compliance Cloud Configuration Monitoring Host Intrusion Detection (HIDS) IAM & Privilege Management Continuous Security Review
- 24. Dev’s want fast build times and immediate feedback • Problem: Some security tests cannot be done on every build • Solution: CI pipeline runs security tests inline in the build (where applicable) and for longer running tests or manual security tasks (e.g., threat model), it fetches the latest results via API. Security in CICD
- 25. Governance
- 26. • Aggregate security metrics to communicate overall risk level. • Share at the executive level to show trends and current security posture. • Share across all of R&D so every team can see how they’re doing relative to the business KPI Metrics & Dashboards
- 27. Released Software (with security) is our goal. Conditional Pass Requires: 1. Mitigation Plan 2. Executive Risk Approval Captured in Ticketing System and enforced by automation and orchestration. SECURITY EXCEPTIONS & RISK APPROVAL
- 28. Summary •Culture •Process •Governance Begin where you are... The warrior’s journey starts with the first step.
- 29. I would greatly appreciate your thoughts, comments, feedback, disagreements, complaints, arguments, etc... Where to find me.... Brian Levine
- 30. • Microsoft Security Development Lifecycle © 2010 Microsoft Corporation. • The Software Assurance Maturity Model (SAMM) was created by Pravir Chandra and is now an Open Web Application Security Project (OWASP) project. SAMM is licensed under the Creative Commons Attribution-Share Alike 4.0 License https://owaspsamm.org/ • BSIMM LICENSE This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license,visit http://creativecommons.org/licenses/by-sa/3.0/legalcode or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. ATTRIBUTIONS Image by Gordon Johnson from Pixabay