Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security Checkpoints in Agile SDLC

299 views

Published on

Product Engineering teams have started to realize the importance of software security. This has resulted in the trend where teams are taking efforts to include it as part of their software development life cycle; as opposed to treating it as another item in their checklist prior to release. However, the real challenge is in trying to find the balance between agility and quality which is where many team find this an uphill task.

While there is no golden standard when it comes to implementing software security, product teams should focus on bringing about systematic and cultural practices within their teams. This should help them to bring about the required efficiency to enable software security as a market differentiator.

This slide-deck on Software Security Initiative focuses on translating a plan of action into sustainable activities as part of the secure software development life cycle that can be adopted by engineering teams. The slides will delve deep into aspects like identifying and designing security checkpoints in the SDLC alongside concepts such as Threat Modelling in Agile, AppSec Toolchain and Security Regressions.

This was presented as a we45 Webinar on April 12, 2018

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Security Checkpoints in Agile SDLC

  1. 1. ENFORCING SECURITY CHECKPOINTS Rahul Raghavan Co Founder and DevSecOps Proponent, we45
  2. 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. 3. Software Security Initiative “Collection of activities that Measure, Maintain and Improve the state of Software Security”
  4. 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. 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. 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. 7. DevSecOps : Gartner’s Infinite Loop
  8. 8. DevSecOps : The we45 Model
  9. 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. 10. In simplespeak… Design Develop Deploy & Test Release & Monitor Plan Code Build Test Release Deploy Operate Monitor
  11. 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. 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. 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. 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. 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. 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. 17. DEVELOP & DEPLOY “The most secure code in the world is code which is never written” - Colin Percival
  18. 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. 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. 20. AppSec Toolchain Architecture 1 2 3 4 5 6 78 9 10
  21. 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. 22. A sample regression architecture
  23. 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. 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. 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. 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. 27. OPEN HOUSE Questions , Clarifications et all….. rahul@we45.com @rahul_raghav torahulraghavan we45.com/blog

×