asec t10 realizing software security maturity the growing pains and gains

2020-03-01 63浏览

  • 1.#RSAC SESSIONID:ASEC-T10 REALIZING SOFTWARE SECURITYMATURITY:THE GROWING PAINS AND GAINS Mark Stanislav Kelby Ludwig Director of Application Security Duo Security Senior Application Security Engineer Duo Security
  • 2.Maturity Models #RSAC BSIMM SAMM 2
  • 3.BSIMM &SAMM:A Comparison(ish) #RSAC BSIMM Definition In Use Since Latest Release Curated By Model Basis # of Top-Level Groupings # of Activities SAMM Building Security in Maturity Model 2008 8 (September 2017) Synopsys (Security Vendor) Real-world, “in use” industry data 4 — Governance, Intelligence, SSDL Touchpoints, and Deployment 113 across 12 sub-groupings 3 Software Assurance Maturity Model 2009 (1.0) 1.5 (April 2017) OWASP (Community Organization) “Ideal state” via community input 4 — Governance, Construction, Verification, and Operations 77 across 12 sub-groupings
  • 4.Maturity Models #RSAC BSIMM DESCRIPTIVE SAMM PRESCRIPTIVE 4
  • 5.Staffing for Success #RSAC 1.6% 10.9% Percentage of Software Security Group (SSG) Members to Software Engineers in BSIMM8’s Data Set Percentage of Our Application Security Team Members to Our Product Engineering Staff 5
  • 6.ApplicationSecurity:Team Values #RSAC ENGINEERING IS FAMILY Application Security will be adversarial in activity, but never in the relationship with our Engineering team members. What thismeans:What this does notmean:Empathetic and respectful engagement Empower engineers with knowledge Be available, be thoughtful, be patient 6
  • 7.ApplicationSecurity:Team Values #RSAC LOW FRICTION, HIGH VALUE Application Security will look for key points in the SDLC that provide high value, with low friction, to increase security. What thismeans:What this does notmean:Less roadblocks, more roundabouts Be mindful of overhead on Engineers Be creative in building better security 7
  • 8.ApplicationSecurity:Team Values #RSAC BUILD A PAVED ROAD Application Security will build and promote standard capabilities that accelerate engineers with clear support & benefits. What thismeans:What this does notmean:Guardrails so engineers feel confident Help to accelerate innovation & output More time to spend on “hard” problems 8
  • 9.ApplicationSecurity:Team Values #RSAC HOW COULD IT GO RIGHT? Application Security will ensure Engineering is enabled & supported to lead innovation, even for hard security challenges. What thismeans:What this does notmean:We’re enablers, not the team of “No” Our titles contain ‘Engineer’ for a reason Be up for the challenge; no fatalists here 9
  • 10.ApplicationSecurity:Team Values #RSAC NO CODE LEFT BEHIND Application Security is committed to ensuring that no code is forgotten about and that our security testing accounts for it. What thismeans:What this does notmean:Don’t just focus on the new & shiny Understand the full software inventory “Old” code changes in “new” deploys 10
  • 11.Duo Application Security Maturity Model (DASMM) Governance Engineering - Strategy & Metrics - Policy & Compliance - Education & Guidance - Software Requirements - Software Architecture - Threat Assessment 54 Activities 46 Activities Verification - Code Review - Software Testing - Design Review 55 Activities #RSAC Operations - Defect Management - Deployment Composition 35 Activities Leveraging Industry Maturity Models with the Ability to Customize 11
  • 12.DASMM:Tracking Program Maturity #RSAC Coverage Coverage 1 0.5 0.2 0 Priority Definition Priority 1 2 3 4 Consistent coverage and very mature practices Inconsistent coverage and/or partially mature practices Minor coverage and/or weak practices Non-existent coverage and/or immature practices Definition An activity vital to the success of the AppSec program Highly valuable activities that notably increase maturity Supplemental to program goals, but not key to success There is no intention to adopt this activity in the future * SpoilerAlert:Fake Data 12
  • 13.Building a Program #RSAC Standardize Foundational - OWASP SAMM Descriptive - Bugcrowd VRT Functional FIRST PSIRT Framework - Synopsys BSIMM - Microsoft STRIDE OWASP ASVS - Microsoft SDL - Microsoft DREAD ISO 30111 & 29147 13
  • 14.Building a Program #RSAC Strong Collaboration Quality Assurance - Maximize test coverage Product Team - Advise on key trends Compliance - Vendor assessments - Shared technical tooling - Assess early design risk - RFP questionnaires - Triage security bugs - Understand our users - Support audit needs 14
  • 15.Building a Program #RSAC Give Back to the Community Content - Present at conferences Industry Contributions - Influence relevant standards - Author blog posts - Build community events - Respond to the press - Perform security research 15
  • 16.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Training Requirements Design Implementation Verification Release Response 16 Release Response
  • 17.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Engineering-focused “Security Skills & Interest” survey All new Engineering hires fill out this form to influence our program focus Hands-on formal training & guest speakers Tailored courses developed internally and 3rd-party specialized training Informal gamified training Internal CTFs and Elevation of Privilege (EoP) card-game tournaments 17 Response
  • 18.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Response SECURITY DESIGN REVIEWS Evaluates the security architecture of an application's overall composition. Benefits to Engineers Possible Deliverables Early, efficient clarity on secure design Real-time feedback Reduces likelihood of major refactoring later Formalized review artifacts Provides early AppSec team awareness Software security requirements Allows for highly interactive engagement 18
  • 19.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Response THREAT MODELING Reviewing a software design to enumerate threats and contextualize their real risk. Benefits to Engineers Possible Deliverables Thoughtful evaluation of attack surface Data flow diagrams Development of a better “attacker mindset” Threat enumeration details Useful insights for cost/benefit analysis Interactive whiteboarding Allows for more strategic risk mitigation 19
  • 20.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Response CODE AUDITING Point-in-time analysis of how implemented code has met the intent of security engineering principles, standards, and guidelines as defined for the project’s goals. Benefits to Engineers Possible Deliverables Prompt remediation of security anti-patterns Well-documented remediation patches Collaborative review of code in increments Detailed technical writeups of vulnerabilities Focused attention to “security quality” of work Improved security test coverage Bite-sized security education opportunities 20
  • 21.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Response SECURITY ASSESSMENT Comprehensive review of software's total security composition, usually at major lifecycle inflection points (e.g. new release, feature update, major code refactor). Benefits to Engineers Possible Deliverables Holistic review of entire in-scope code base Threat modeling asset updates Analyzes the integrated security properties A comprehensive assessment report New or updated view of threat model artifacts Detailed technical writeups of vulnerabilities Good “gut check” before a major release 21
  • 22.Security Development Lifecycle (SDL) #RSAC Training Requirements Design Implementation Verification Release Product Security Advisory (PSA) process Modeled after ISO/IEC 30111:2013 Coordinated vulnerability disclosure policy Modeled after ISO/IEC 29147:2014 Our contact details are published on our web site, including a GPG key FIRST PSIRT Framework Being finalized after a recent v1.0 RFC period, during which we submitted feedback 22 Response
  • 23.Ad-hocHelp:Easy Mode #RSAC Review small code diffs One-off Slack conversations Issue tracker subscriptions Forwarding us an email thread Walking up to our desk with beer 23
  • 24.AppSec Team “Office Hours” #RSAC 1 hour of weekly time with AppSec Published on engineer calendars Reminders via Slack & in-person Open-ended discussion and Q&A Often results in “next step” outcomes Realizes low-friction, high-value 24
  • 25.Intake Process #RSAC Intake form is submitted by an engineer Timeline and AppSec resources forecasted Details added to the security activity board The Intake Form Will Receive… Which activity was requested and why Overview of the request’s scope Links to all relevant project artifacts Activity timeline and point of contact 25
  • 26.Execution Management and Scheduling #RSAC Similar to an internal consultancy Simple and repeatable process Easy and transparent scheduling Helps answer statusing questions 26
  • 27.1st PartyExecution:Kick-Off Checklist #RSAC Shared responsibility between AppSec and Engineering Ensures… Security activities start on-time Goals & expectations are aligned Clarity on perceived risks AppSec process consistency Acts as a single source of truth for information 27
  • 28.One Report; Many Benefits #RSACPerspective:A formal deliverable sets the tone for a level of quality & completeness of the workContext:Holistic view of key activity propertiesCompliance:Report aggregates necessary information needed for auditors and customers HistoricValue:Easily allows differential analysis of year-over-year results for a given codebaseDebrief:Ensures that all stakeholders have the complete picture of the security activity’s output 28
  • 29.Now, Take Action! #RSAC Next Week… Read through OWASP SAMM & Synopsys BSIMM — choose a framework Perform a comprehensive software inventory to determine what’s in scope Within Three Months… Perform a gap analysis against BSIMM or SAMM of your program Provide an interactive Application Security training to engineers Begin operating across the Security Development Lifecycle (SDL) 29
  • 30.#RSAC THANK YOU! Mark StanislavEmail:'>Email: