Building Security In - A Tale of Two Stories - Laksh Raghavan
- 1. Building Security In – A Tale of Two Stories! Laksh Raghavan PayPal Inc. @laraghavan
- 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. 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. I LOVE DEADLINES. I LIKE THE WHOOSHING SOUND THEY MAKE AS THEY FLY BY… - Douglas Adams 4
- 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. 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. 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. 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. IT IS A MISTAKE TO THINK YOU CAN SOLVE ANY MAJOR PROBLEM JUST WITH POTATOES. - Douglas Adams 9
- 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. 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. 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. 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. 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
- 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. 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. I REFUSE TO ANSWER THAT QUESTION ON THE GROUNDS THAT I DON'T KNOW THE ANSWER! - Douglas Adams 2 Questions?
- 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!