Securing Agile Transformations in Big Biz

Chris Rutter

choss@outlook.com

DevSecOps Lead

Java Developer

Payments / Retail Banking

Transformation?

Slow project deliveries
Upfront hardware costs
Legacy apps & platforms
Blood, sweat & tears for uptime
High deployment failure rate

Mid-large Companies with:

Regularly Beaten to market by challenger startups

Transformation Alpha 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

Regulated Environment

Mandatory Security Activities

IT Security Architecture Design Review
Penetration Testing
IAM Standards
Data Storage Standards
Key / Secret Management Review
Risk Acceptance processes

Project Plan

Let's be Agile!

MVP Features defined
Loose whiteboard designs
Create Feature-driven user stories
Estimate stories
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

1 week sprint is a 1 week project
Architectures designed, built and completed in 1 sprint
Once a sprint is complete it's forgotten
Developers under pressure for features
If we get blocked, it's IT Security's fault

Understanding the Problem

We've already solved this before

XP, Agile, DevOps

Developers

Require evidence of reviews and implemented controls
Require in-depth project knowledge to be effective
Mapping security requirements to brand-new tools developers choose because they're cool
Can't trust that identified risks will be fixed or taken seriously

Understanding the Problem

We've already solved this before

XP, Agile, DevOps

IT Security

Security as a Design Technique

Security as Acceptance Criteria

What Tools do We Have?

Engagement!
Threat Modelling
Building standardised libraries & patterns
Automated security acceptance tests
Static / Dynamic code scanning in pipelines
Manual destructive logic testing

Who Does What?

DevSecOps Engineer

Active feature Software developer ~50% of time
Part of every architectural design whiteboard
Threat Models every design, every week with SME and Liason
Builds re-usable libraries ready for next sprint
Pairs with testers to write security Acceptance tests
Works with BA to write user stories
Interprets and maintains automated static scans

Focused on reducing 'compliance lead time'

Sprint 1

SPIKE User story to design mobile app integration with oAuth Provider and store access token on server

Case Study

Given: I am a mobile app user
And: I wish to authorise access to an oAuth2 resource
Then: I can provide grant code to project backend
And: project backend will obtain access token
And: access token will be stored for later use

Monday - Design

DevSecOps Engineer and SME whiteboard design with developers. Use existing expertise to guide proper flow implementation

Tuesday - Threat Model

DevSecOps Engineer and SME document and Threat Model design and identify the following security controls:

Spoofing: Certificates must be pinned in app to prevent MITM intercept of credentials
Information Disclosure: Sensitive Access tokens should be encrypted at rest
Elavation of Privilege: Client ID and Secret for oAuth Authorization server must be provisioned in a secure manner

Wednesday - Confirm Standards

DevSecOps Engineer and SME review threat model with IT Security Liason, discover company standards for each control

Certificate Pinning: Must pin certificates on leaf certificate or on Intermediate CA with host-name verification
Encryption At Rest: Must use AES encryption in GCM mode with a key length of 256 bits
Secret Management: Secrets must be stored encrypted in a location with strong IAM controls and full auditing of access and decryption

Thursday- Write re-usable library

DevSecOps Engineer writes re-usable component for encrypting data at rest which complies with IT security standards

Easy-to-use library: Can be imported to projects without any complicated set-up or dependencies
Example automated tests: Include tests which give the tools for fast automation of security verification tests
Documented: Compliance to standards documented, ready for security review later on in project

Friday - Add Control to Functional User Story

Based on developer design, BA writes smaller stories ready for next sprint.

DevSecOps engineer ensures that security control is part of Acceptance Criteria.

Given: Project backend has received a grant code
Then: Backend can use code to obtain access token
And: Token will be stored for later use
And: Token must be encrypted using agreed library

Friday - Create Security User Stories

Based on controls identified during threat modelling / engagement session, stories are created to implement controls

Given: Mobile App authenticates with oAuth provider
Then: All communications will use certificate pinning
And: Pinning implementation is reviewed by SME

Given: App requires access to secrets
Then: Agreed secret retrieval mechanism is used
And: Secret retrieval is reviewed by SME

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

Securing Agile Transformations in Regulated Big Biz