Building Security In - A Tale of Two Stories - Laksh Raghavan
Building Security In – A
Tale of Two Stories!
• 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
– 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
PayPal’s Agile Transformation
• 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!
I LOVE DEADLINES. I LIKE THE
WHOOSHING SOUND THEY MAKE AS
THEY FLY BY…
- Douglas Adams
PayPal SPLC - Overview
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.
• Institutionalize risk-based thinking and processes
• Secure by Default – Frameworks, Dev. Tools, etc.
• Put our bots to work
• People – Internal PD security champions to help drive focus and attention on
• 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
An exercise in testing (and trusting) the automated process
• 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
Pre-requisite: Security Controls Auto-enabled to Protect
Developers by Default
• 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
• Developers have go out of their way to turn off security controls
• Secure-by-default in all layers
– Dev. Tools
IT IS A MISTAKE TO THINK YOU
CAN SOLVE ANY MAJOR
PROBLEM JUST WITH POTATOES.
- Douglas Adams
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
Your Favorite Tax
• 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
What were our initial design goals?
• We should go where they are and not make them come back to our tool on a
• Two-way sync with our enterprise ALM tool
• It shouldn’t take more than 15 minutes for any product developer to complete
• Don’t slow them down!
• Comprehensive generic but “actionable” guidance for most technology stacks
• Useful for non-standard apps and acquisitions
What makes a good security story?
• A good security story should be “actionable” bite-sized chunk that can implemented by
• It should have clear usage guidelines for your own security APIs, frameworks, libraries,
• 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
A LEARNING EXPERIENCE IS ONE OF
THOSE THINGS THAT SAYS, “YOU KNOW
THAT THING YOU JUST DID? DON'T DO
- Douglas Adams
Pitfalls, Gotchas, etc.
• 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
How do we measure success?
• 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
• 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…”
In a Nutshell
Legacy SPLC Agile Transformed SPLC
200+ PDF/HTML security standards and
Security Stories customized for the specific
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
Threat Model everything Lightweight Threat Model via self-service tool
Human Threat Model only where needed
I REFUSE TO ANSWER THAT QUESTION ON THE GROUNDS
THAT I DON'T KNOW THE ANSWER!
- Douglas Adams
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
Get my slides immediately
Take the DevSecOps Survey