Practical tips and heroic war stories on how to secure a large, modern, fast software delivery platform. From building a team to building cool stuff, dealing with organisational setups to dealing with security incidents. Zero Buzzwords Guaranteed. Chris Rutter has spent the last few years obsessed with making security, engineering and the business work together. Starting his career as an engineer, he uses a deep understanding of Agile, Devops, and product delivery to solve security problems in a way that enables teams, rather than hitting them with bricks.

1. Platform Security
IRL
Chris Rutter

2. Java Developer > Security Champion >
Security Architect > Security Tech Lead
Payments, Banking & Government Transformations
Lead Security Engineer @ Clearbank
choss@outlook.com
Chris Rutter

3. Tips and techniques learned building security at scale on a
large software platform
General concepts for thinking about modern security
Benefits of approaches such as standardisation and
convention
Talk Aims

4. An integration oriented design approach emphasizing systematic reuse, for
developing complex products based upon platforms and compatible hardware
and software virtual components, intended to reduce development risks,
costs and time to market
+ Reduce security risks
Platform Based Architecture
https://en.wikipedia.org/wiki/Platform-based_design

5. Platform Based Architecture

6. Large Government Department
● 60 Development Pizza teams
● 1700 Total employees
● 1000 microservices
● 6 Platform Teams
● 1 Platform Security Team (4 people)
Lessons & Techniques

7. ● Lead who understands security and tech
● Product owner who understands value and business impact
● Floating engineering resources
Security Team Structure

8. Platform Security Team Mandate
● Build security into platform development workflows
● Improve Access Management on platform
● Improve operational security capability of platform
● Help coordinate Live vulnerabilities and incidents
● Improve app team development security
● Own and push platform-wide security initiatives
Scalable and Valuable Security

9. Vulnerable Dependencies

10. Understand Mitigation Flow

11. Traditional Approach
X 50

12. Traditional Approach
● Investigation of each finding takes approx 30-60 mins
● Buy licences and on-board 50 champions to use tool
● Security team consulting with 50 teams
● Investigation robustness difficult to standardise
● Shifting Left
● Giving ownership to engineers

13. Practical Approach
POC scanning 10 teams

14. Focus on Shared Libs
● Platform Security
○ Scan
○ Investigate
○ Triage
● Platform Applications Team
○ Build updated shared libraries
○ Test
○ Publish new version

15. Jackson Deserialization Vulnerability (CVE 2017-7525):
Introduction: This vulnerability takes advantage of the ability of an attacker to force a server
to deserialize a compromised class which is known to be on a large number of class paths
and inject malicious input which can result in code execution.
Am I Vulnerable?: You are vulnerable if you use polymorphic typing feature anywhere in
your code. This can be configured in a few ways: @JsonTypeInfo, @JsonSubTypes or
mapper.enableDefaultTyping()
How can I remediate?: You must ensure that you globally configure ObjectMapper
disableDefaultTyping() and have no instances of @JsonTypeInfo, @JsonSubTypes
Sensible & Specific Remediation Advice

16. Basic Code Scanning Engine
Vulnerability Search Terms
XXE XMLInputFactory, TransformerFactory,
SchemaFactory, SAXTransformerFactory,
XMLReader
Jackson Deserialization @JsonTypeInfo, @JsonSubTypes,
mapper.enableDefaultTyping()
Logback ServerSocketReceiver

17. Block Releases After Timeframe

18. ● In-depth analysis by security engineer for accurate diagnosis
● Upgrade path can scale out and is easily Enforced
● Small implementation effort, low load on security team, low
cost of scanning tool
● Lots of engineer time saved by centralising investigations
● 80% of value for 20% of the resources
Benefits

19. ● Shift left but only if valuable and manageable
● Ensure shared functionality is centralised, then it can be
scanned less times and investigated more thouroughly
● Understand and test the full remediation flow
● Focus on value over comprehensiveness, how much risk
reduced for effort? Fight this fight with Auditors!
● Implement in value iterations like any other project
General Scanning Tool Concepts

20. ● Granular database users for each application
● Controls around their scope of access and permissions
● Frictionless process to on-board new application
Granular Database Access Management

21. Access Management Requirements
● App is created and requires access to a database cluster
● App permissions must be defined (which DBs, tables etc.)
● Users created in DB and credentials stored securely
● Credentials provided to applications on deployment
● Permissions altered if data model changes
Granular Database Access Management

22. Traditional Approach #1 ● Manual DB & User creation via
ticket
● Manual security review
● Manual storage of creds in
secrets manager
Slow & Tedious
Prone to error
Encourages larger DBs and wider
roles

23. Traditional Approach
● Extremely slow and involved process
● Requires full-time team of DBAs
● Encourages wider roles and larger DBs
● Significant chance of manual error
● Comprehensive review of all permissions
● Defined ownership of database management

24. Traditional Approach #2
https://imgflip.com/i/4gst9e

25. Standardise App Creation

26. Automate App Creation Lifecycle

27. Standardise Deployment Descriptors

28. Cater For Exceptions
● Legacy Apps
● True Snowflakes
● Automatically Applied
● Managed via PR
● Approval group on PR

29. Benefits
● All access by namespace convention
● Fast and automatic provisioning, new app could go to prod instantly
● Security controls built in, free and pre-approved
● Can be used to automate:
○ Scaffolding with application libraries
○ IAM access to Cloud PaaS resources
○ Deployment pipeline creation
○ DockerFile Creation
● Still allows for legacy or non-compliant patterns but makes this harder

30. Concepts
● Automate app creation lifecycle
● Standardise architectural patterns
● Provision apps to be secure by default
● Mechanism built and owned by platform teams
● Codified exceptions for legitimate use cases / legacy

31. Tiger Team Platform Project
● Cross cutting projects can be very slow
● A lot of time spent managing big bang migrations
● Pockets of knowledge

32. Tiger Team
● Architect for design continuity
● Engineers rotating from all necessary platform teams

33. Tiger Project Plan
● Small iterations through to production, cutting down on intra-team
backlog slow down, minimising big bang migrations and flushing out
integration issues

34. Traditional Security Review Approach
● Pen Test or architectural review at end of project
● No security input during development
● Project can not be released in iterations which will massively slow down
project / integration Review / Pen Test

35. Iterative Just-In-Time Approach
Review
/ Re-modelThreat Model
Review
/ Re-model
Finalise Review

36. Iterative Just-In-Time Approach
● Cross-team project to migrate to a new container hosting solution

37. Iterative Threat Model
● Iteration 1
New dummy service in private zone, no internet connection and no database
access
Network controls must be in place to isolate new apps from production.
Access controls in place so new deployer cannot deploy to existing prod
● Iteration 2
Dummy service with vpn-locked down internet access, no database access
VPN Whitelist must be securely implemented
● Iteration 3
Dummy service with vpn-locked down internet access and access to database
holding non-sensitive public data
Database credentials must be protected and no access given to other databases

38. Benefits
● Support much faster delivery of cross-cutting improvement projects
● Security team involved in entire project, understanding domain from the
outset
● System has security built-in from initial design
● Security considered an enabler
● Avoid expensive fixes based on late pen test or security review

39. Conclusions
● Standardisation and convention is the easiest and cheapest way to scale
securely
● Understand what your teams share, and what they truly need to
customise
● Create platform teams with concrete ownership to build and own cross-
cutting functionality (including security)
● Don’t be scared to take the 80%
● Use Cross-functional virtual teams to build faster and more securely
● Use just-in-time threat modelling to support rapid delivery