Recommended
More Related Content
What's hot
What's hot (20)
Similar to Security Checkpoints in Agile SDLC
Similar to Security Checkpoints in Agile SDLC (20)
Recently uploaded
Recently uploaded (20)
Security Checkpoints in Agile SDLC
- 1. ENFORCING SECURITY CHECKPOINTS Rahul Raghavan Co Founder and DevSecOps Proponent, we45
- 2. Agenda Ø Software Security Initiative – A Quick Recap Ø Challenges in Application Security Ø The advent of DevSecOps Ø SDLC Security Checkpoints Ø Application Threat Modeling Ø Application Security Tooling Ø Regressions for Application Security
- 3. Software Security Initiative “Collection of activities that Measure, Maintain and Improve the state of Software Security”
- 4. Phases of an SSI Prepare to Kick Start / Improve your SSI Take Control and Implement your SSI Measure Success of your SSI Identify Continuous Improvements of your SSI PLAN DO CHECK ACT
- 5. In focus today… Application Team Mapping Gather Historic Current State Data Ascertain Compliance Legal Objectives Establish SSI Governance Identify Training Needs Organize Tool-chest Identify Security Checkpoints Toolchain implementation Enhance existing automation Build Internal Capability SIG Collaborations Transcend Beyond Penetration Tests Enforce Security Checkpoints PLAN DO
- 6. The Advent of DevSecOps Ø Security = Continuous Feedback + Improved Automation Ø End of the chain security activities broken down into piece-meal engagements Ø Division of security responsibilities – Dev, Ops, QA, Security Ø Transformation of engineering tools and platform – interfacing capabilities Ø Everyone needs to “get” code
- 7. DevSecOps : Gartner’s Infinite Loop
- 8. DevSecOps : The we45 Model
- 9. Security Checkpoints Ø Logical security turnstiles at every phase of development and deployment Ø Assimilate common security objectives across engineering teams Ø Establish traceability for identified security flaws
- 10. In simplespeak… Design Develop Deploy & Test Release & Monitor Plan Code Build Test Release Deploy Operate Monitor
- 11. SOFTWARE DESIGN “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies” C.A.R Hoare
- 12. Threat Modeling Ø Identify, Enumerate and Prioritize - Security Risks Ø Systematic Breakdown of Attack Vectors and Attack Channels Ø Identifying Most Likely, Relevant Threats to a system Ø To identify controls and measures of risk treatment Ø Create a Security Playbook for the Product Team
- 13. Everything that’s wrong with Threat Modeling today Ø Assumption of frozen requirements => Very Waterfall! Ø Threat Models are not dynamic enough - Out of date with application delivery Ø Current Threat Modeling is not collaborative – Bunch of Security folks at the beginning of a project
- 14. The 1-2-3 of Threat Modeling Abuser Stories Attack Model Test Scenario User Story What can be done to abuse a functionality How to make your abuser story come to life Security checks you can formulate for each attack model
- 15. Threat Modeling :: Test Case Mapping User Story As a user I want to search for my notes using the Search functionality Abuser Story As an attacker, I will try to search for notes of other users so as to disclose potentially sensitive info As an attacker I will try to redirect users to malicious sites to compromise account credentials Attack Model Attacker can perform Man-In- The-Middle attacks Attacker can perform Injection attacks Test Scenarios Check if the application is always on HTTPS, across the application Check for SSL strength Check for HSTS header present in HTTP Headers while connecting to the application Check for SSL vulnerabilities like POODLE, BEAST…
- 16. Security in Design Ø Consolidate security requirements § Compliance mandates § Regulatory obligations Ø Perform architecture design review Ø Perform Threat Modeling Ø Third party threat feeds / historic data Ø Identify relevant SAST, SCA & DAST tool-chest Ø Prioritize training needs Design Checkpoint Abuser Stories linked to User Stories in JIRA/Confluence
- 17. DEVELOP & DEPLOY “The most secure code in the world is code which is never written” - Colin Percival
- 18. Develop Ø Table – Top code walkthroughs Ø SAST IDE Plugins Ø SCA runs as part of code review and build management Ø Peer-review prior to code commit Ø Evangelize use of Secure Coding Guidelines/checklist Ø Liaise security champions Develop Checkpoint SAST and SCA scans on local repo prior to code commit
- 19. AppSec Toolchain Ø Security tools (SAST, SCA and DAST) to work in conjunction with engineering platforms Ø “Force Multiplier Effect” through open source scanner components Ø Automated or scheduled triggers that kick off scan workflows Ø Transform from plain DAST to Parameterized DAST Ø Save critical security bandwidth by minimizing § Vulnerability Triaging § Testing common scenarios § Reconnaissance and Discovery Ø Transform vulnerabilities as “defects” routing them to the common defect pipeline system
- 20. AppSec Toolchain Architecture 1 2 3 4 5 6 78 9 10
- 21. Security Regression Ø Taking security one step closer to Quality Assurance (QA) Ø Leverage functional automation tools and resources to run security iterations with QA iterations Ø Extend and re-use automation scripts / technology to create “Security Regressions” Ø Increase efficiency of DAST scanners Ø Create security ”exploit scripts” for identified vulnerabilities Ø Automate security test case scenarios Ø Scale Security with QA Ø AppSec Toolchain + Security Regression = Savings in Resource Bandwidth
- 22. A sample regression architecture
- 23. Deploy and Test Ø Find bugs Early, Fix bugs Early! Ø Strategies for ‘Found bugs’ and ‘Yet to Find bugs’ Ø Threat Modeling :: Test cases mapping Ø Run Automated Tool Chain (DAST Scanners) Ø Leverage QA functional automation Ø Perform residual / iterative penetration tests Ø Non-Deterministic testing Ø Prioritize vulnerabilities based on impact Deploy & Test Checkpoint Piggyback on existing release gates (include security thresholds)
- 24. PRODUCT RELEASE AND MONITORING “When we launch a product, we’re already working on the next one. And possibly even the next, next one” - Tim Cook
- 25. Release & Monitor Ø Shift Right Strategy – Self Protect or Fail Safe Ø Use of RASP, WAF, Botnet Mitigation, Load Balancers, DDoS Ø Successful and failed attack metadata feedback as actionable intel Ø Integrate security cookbooks with deployment cookbooks (config audits more than testing) Ø Assisted Bug Bounties Release & Monitor Checkpoint Establish feedback mechanisms from Production to Design
- 26. Iteration 2 and forward Ø Consolidate security requirements Ø Compliance mandates Ø Regulation obligations Ø Perform architecture design review Ø Perform Threat Modeling Ø Third party threat feeds/historic data Ø Identify relevant SAST, SCA & DAST tool-chest Ø Prioritize training needs Ø Identify design changes to address security vulnerabilities Ø Update design documents Ø Update coding guidelines Design Checkpoint ➤ Table – top code walkthroughs ➤ SAST IDE Plugins ➤ SCA runs as part of code review and build management ➤ Peer-review prior to code commit ➤ Evangelize use of Secure Coding Guidelines/checklist ➤ Liaise security champions ➤ Code changes to remediate security vulnerabilities Develop Checkpoint Deploy & Test Checkpoint ➤ Find bugs Early, Fix bugs Early! ➤ Strategies for ”Found bugs” and “Yet to find bugs” ➤ Threat Modeling :: Test case mapping ➤ Run Automated Tool Chain (DAST Scanners) ➤ Leverage QA functional automation ➤ Perform residual/iterative penetration tests ➤ Non-deterministic testing ➤ Prioritize vulnerabilities based on impact ➤ Run regressions ➤ Compare scan results from previous iterations ➤ Shift Right Strategy – Self protect of Fail Safe ➤ Use of RASP, WAF Botnet mitigation, Load Balancers, DDoS ➤ Successful and failed attack metadata feedback as actionable intel ➤ Integrate security cookbooks with deployment cookbooks (config audits more than testing) ➤ Assisted Bug Bounties Release & Monitor Checkpoint
- 27. OPEN HOUSE Questions , Clarifications et all….. rahul@we45.com @rahul_raghav torahulraghavan we45.com/blog