Practical Threat modelling
In Agile Projects
Chris Rutter
choss@outlook.com
Platform Security Engineer
Payments / Retail Banking / Government
https://www.linkedin.com/in/chris-rutter-1b74a8b0
Transformation Agile Project
- New, shiny, market-driven functionality
- Use Agile - Feedback from business each week
- Hire DevOps engineers - All skills in team
- Brand New Cloud IaaS / PaaS - Quick provision and scales up
- Deliver MVPs and iterate - Quick Time to Market
Goal: Deliver an MVP in 12 weeks
Unique Security Challenge
Project Plan
Let's be Agile!
- MVP Features defined
- Create Feature-driven user stories
- Estimate stories
- Undocumented whiteboard designs
- Work for 11 weeks
- 1 week for security sign-off
Project Workflow
Week 10
Week 16
- Security Design Review found high impact architectural issues
- App Penetration Test found severe vulnerabilities
- Secret management does not follow company standards
- Review, fixes and verification are thrown over the wall and take weeks
- Business Executive signs off on risk acceptance
Delivered 4 weeks late
Less Secure
Everyone hates/blames Security
Let's try that again
- Threat modelling with developers at whiteboard stage
- Identify risks and controls early
- Design security into our architectures
- Reduce sign-off time
- Build trust between dev, ops and security
- Educate developers & encourage to take security ownership
Threat Modelling as a collaborative exercise
Our Teams
DevSecOps Engineer / Security SME
- Threat Models every sizeable design
- Works with BAs to negotiate security user stories
- Technical security knowledge resource
- Faster change needs more of these!
- Active feature Software developer
- Part of every architectural design whiteboard
- Point of contact for SME
Security SME
Devsecops / Security Champion
Personal Finance Insights App
Project Epic Backlog
Initial Internal Beta
| Story Name | Story Description | Estimate |
|---|---|---|
| US-001 | User can create account and log in with username and password | 1 week |
| US-002 | User can grant access to bank account using Open Banking / OIDC | 2 weeks |
| US-003 | User bank account information can be retrieved and stored | 1 week |
| US-004 | Mobile app can retrieve and display account information | 1 week |
| US-005 | Bank account transactions for last 3 months can be obtained async | 1 week |
| US-006 | Transactions can be viewed on mobile app | 1 week |
| US-007 | User can view total incomings and outgoings based on transaction type | 1 week |
| US-008 | Transactions can be categorised by purchase type | 2 weeks |
| US-009 | User can view total spending per purchase category for each month | 1 week |
| total | 11 weeks |
Threat Model Triage
Sprint 0 - Project Epic Workshop
| Story Name | Story Description |
|---|---|
| US-001 | User can create account and log in with username and password |
| US-002 | User can grant access to bank account using Open Banking / OIDC |
| US-003 | User bank account information can be retrieved and stored |
| US-004 | Mobile app can retrieve and display account information |
Triage continues for all new user stories
Sprint 1
Whiteboard Designs
- Developers and SME whiteboard designs
| US-001 | User can create account and log in with username and password |
|---|
- Communcation Diagram
- Sequence Diagram
Sprint 1
Threat Model
- DevSecOps/SME document flows
- Perform threat model with IT Security Function
- STRIDE Analysis
- Identify Vulnerabilties and controls
| US-001 | User can create account and log in with username and password |
|---|
Sprint 1
Define Standards
- IT Security confirm or define standards for controls
- IT Security give initial indication of risk
- Identify specific standards for controls
- Early indication of highest security priorities
| US-001 | User can create account and log in with username and password |
|---|
Sprint 1
Create Libraries and Implement Controls
- DevSecOps engineer writes a small re-usable library to perform hashing complying with standards. Implements in user story
- Session storage on mobile app is reviewed with front-end developers so that keychain is used and session protected
All Controls are documented and verified instantly
Sprint 1
Create Security User Stories
Based on controls identified during threat modelling
Given: The authentication service requires a database user and credentials at runtime Then: User permissions will be agreed and defined in code And: Credentials will be generated and provided to app securely
Result
- Security concerns are identified before code is written
- Controls are pre-approved by IT Security
- All reviews and controls are documented in parallel
- Security is implemented with each user story (when possible)
- Security-specific user stories are added to backlog immediately
- IT Security gain valuable project knowledge each week
- IT Security seen as experts rather than blockers