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.

Building Security In - A Tale of Two Stories - Laksh Raghavan

877 views

Published on

DevOps Connect: DevSecOps Edition at RSAC 2017

Published in: Technology
  • If you want a girl to "chase" you, then you have to use the right "bait". We discovered 4 specific things that FORCE a girl to chase after you and try to win YOU over. copy and visiting... ■■■ http://t.cn/AijLRbnO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Earn a 6-Figure Side-Income Online... Signup for the free training HERE ●●● https://bit.ly/2kS5a5J
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Building Security In - A Tale of Two Stories - Laksh Raghavan

  1. 1. Building Security In – A Tale of Two Stories! Laksh Raghavan PayPal Inc. @laraghavan
  2. 2. Introduction 2 • This presentation is: – A case study on how PayPal’s Secure Product Lifecycle (SLPC) had to adapt to Agile with a focus on security stories – Vendor neutral – Descriptive – For large enterprises grappling with scale/process issues • This presentation is NOT: – Silver Bullet TM – Sales pitch – Prescriptive - if you implement the same, YMMV J
  3. 3. PayPal’s Agile Transformation 3 • Some interesting stats and facts about our Agile Transformation: – Big Bang approach against prevailing wisdom – Went from project driven to product aligned – 400+ scrum teams across the globe – 500+ Change Champions and 165 Transformation team members • Every “industry expert” we consulted told us we couldn’t transform at this scale in our designated timeline but we did it!
  4. 4. I LOVE DEADLINES. I LIKE THE WHOOSHING SOUND THEY MAKE AS THEY FLY BY… - Douglas Adams 4
  5. 5. PayPal SPLC - Overview 5 Objective: Reduce the number of vulnerabilities in our products over time by building repeatable/sustainable proactive security practices embedded within our PLC. Customers demand and deserve better security and privacy in their software. PayPal Secure Product Lifecycle is the process that allows PayPal to develop and test products to help reduce security bugs.
  6. 6. SPLC Transformation 6 – Strategy • Institutionalize risk-based thinking and processes • Secure by Default – Frameworks, Dev. Tools, etc. • Put our bots to work – Execution • People – Internal PD security champions to help drive focus and attention on software security • Process – Integrate seamlessly with our “agile” way of delivering products. • Technology – Secure frameworks, libraries and automated tools that enable PD to ship products rapidly *and* securely
  7. 7. An exercise in testing (and trusting) the automated process 7 • Dynamic/In-Context Security Requirements: Security Stories • Automated security controls in the lifecycle • Secure Frameworks and Security Tools used for all projects & human involvement for critical-risk projects • Threat Model only things that aren’t run-of-the-mill web or mobile apps and/or not built on our standardized secure frameworks
  8. 8. Pre-requisite: Security Controls Auto-enabled to Protect Developers by Default 8 • If we rely on *every* developer in an enterprise doing the right thing from a security perspective *every* time he/she writes code, we are doomed to fail! • Wherever possible, security controls are to be made available automatically and turned ON by default • Developers have go out of their way to turn off security controls • Secure-by-default in all layers – Perimeter – Infrastructure – Framework – Libraries – Dev. Tools – Code/Config
  9. 9. IT IS A MISTAKE TO THINK YOU CAN SOLVE ANY MAJOR PROBLEM JUST WITH POTATOES. - Douglas Adams 9
  10. 10. Security Stories 10 Holy Grail for any software security professional è Make functional and non- functional requirements equal citizens In Agile Speak: Make User Stories and Security Stories equal citizens Before: After: Your Favorite Tax Software!
  11. 11. The approach… 11 • A web-based tool that seamlessly plugs into our Quarterly Release Planning (aka Multi-Sprint Planning) process • A simple survey that does light-weight threat modelling, generates security stories, and places them in the backlog of the scrum team • Tracking and reporting from within our Agile LifeCycle Management (ALM) tool
  12. 12. What were our initial design goals? 12 • We should go where they are and not make them come back to our tool on a daily basis • Two-way sync with our enterprise ALM tool • It shouldn’t take more than 15 minutes for any product developer to complete the survey • Don’t slow them down! • Comprehensive generic but “actionable” guidance for most technology stacks • Useful for non-standard apps and acquisitions
  13. 13. What makes a good security story? 13 • A good security story should be “actionable” bite-sized chunk that can implemented by any developer • It should have clear usage guidelines for your own security APIs, frameworks, libraries, etc. • Where needed, it should provide secure code snippets, reusable secure config examples for your custom frameworks, etc. • It should speak developer lingo and not security lingo! • It should have a well-defined “acceptance criteria” or better yet automate acceptance with security tests (static/dynamic, etc.) in the CI pipeline • Clearly call out every-sprint vs one-time stories • In short, the developers should be able to do it themselves without having to ping the security team for well-established patterns and approved security controls
  14. 14. A LEARNING EXPERIENCE IS ONE OF THOSE THINGS THAT SAYS, “YOU KNOW THAT THING YOU JUST DID? DON'T DO THAT.” - Douglas Adams 1
  15. 15. Pitfalls, Gotchas, etc. 15 • Don’t overload your developers with 100s of security stories • Figure out your own Top 10 (Not OWASP Top 10) and focus on that • Don’t hardcode guidance that could potentially change frequently (e.g. APIs) • Hyperlink instead ;) • Prioritize all security stories – High, Medium, Low • Mandate only High priority stories to be completed initially • Don’t try to boil the ocean - Getting the culture going is more important • Expect security stories to be moved around in your ALM tool (multiple scrum teams could be working on the same app!) • Make sure two-way sync doesn’t break
  16. 16. So, what does it look like? 16
  17. 17. So, what does it look like? 17
  18. 18. How do we measure success? 18 • Wide adoption of the tool across all of our Product Development (PD) organization • Not just adoption but also efficacy – are developers also completing the security stories or are they just sitting in the backlog? • Automated SPLC dashboard that makes these metrics transparent to PD leadership • Early engagement means no or minimal projects hit security roadblocks during launch • A quote from our Android App’s Team Manager: “It is great to know that the pentest didn’t find any blockers and it can be largely attributed to the fact that we are following SPLC…”
  19. 19. In a Nutshell 19 Legacy SPLC Agile Transformed SPLC 200+ PDF/HTML security standards and procedures Security Stories customized for the specific use case/feature Manual gates throughout lifecycle Lifecycle relies on automated controls Human involvement for all projects Let the frameworks and tools do the heavy lifting - human involvement for critical risk projects only Threat Model everything Lightweight Threat Model via self-service tool Human Threat Model only where needed
  20. 20. I REFUSE TO ANSWER THAT QUESTION ON THE GROUNDS THAT I DON'T KNOW THE ANSWER! - Douglas Adams 2 Questions?
  21. 21. WE NO LONGER THINK OF CHAIRS AS TECHNOLOGY; WE JUST THINK OF THEM AS CHAIRS. BUT THERE WAS A TIME WHEN WE HADN'T WORKED OUT HOW MANY LEGS CHAIRS SHOULD HAVE, HOW TALL THEY SHOULD BE, AND THEY WOULD OFTEN 'CRASH' WHEN WE TRIED TO USE THEM. - Douglas Adams 2 Thank you!
  22. 22. Get my slides immediately community@alldaydevops.com
  23. 23. Take the DevSecOps Survey bit.ly/DevSecOps-2017
  24. 24. Our sponsors speak your language… DevOps.

×