Talk given by Chris Rutter Avoiding The Security Brick An exploration of some common scenarios when security teams and processes seriously impact product delivery and result in questionable security benefits, and some battle-proven techniques on how to work more effectively with security while delivering at pace Chris Rutter. A Security Engineer / Transformation specialist who cut his teeth writing Java in Agile environments, then moved into Security Architecture and now helps teams secure their systems by making security technical rather than a tick box.

1. Avoiding The
Security Brick
Chris Rutter

2. Practical Patterns And Techniques for Applying Security in
Agile / Devops SDLCs
Avoid Throwing Being Hit By Security Bricks
Workshop Format - Discussions every 10 mins
Talk Aims

3. Java Developer > Security Champion >
Security Architect > DevSecOps Consultant
Payments, Banking & Government Transformations
Platform Security Tech Lead with EE at HMRC
crutter@equalexperts.com
Chris Rutter

5. My Path to DevSecOps

6. Modern Product Delivery

7. “ Carry out a comprehensive security review / pen test 2 weeks
before release date and allow 1 week for remediation”
Brick #1

9. Common Issues
● Superficial review & pen test
● Little scope for security to influence design
● No time to deal with findings
● Pressurised risk acceptance
● Impossible to release quickly
Release Management

10. Security Triage Every User Story

11. Pen Test
New public-facing microservice
Change to authentication mechanism
Increase in level of data sensitivity
New management tool or cloud service
Review / Threat Model
New non-public microservice
Change to application architecture
Code behind feature switch
New APIs for existing data sensitivity
Peer Review / Champion Self-Sign
Cosmetic changes
Business logic changes
Bug Fixes / Refactoring
Pre Agree Review Criteria

12. Encryption / Hashing algorithms
User authentication
User Login / Lockout mechanisms
DOS attack detection
Sensitive keys on client devices
Service - Service authentication
Secure database design
Cheaper to Discover Early

13. Labels and Comments to Track and Evidence

14. JQL Reports or JIRA API to Enforce

15. Result
● Security has excellent domain knowledge
● Scrum masters enforce reviews as Definition Of Done
● Faster Release Cycles (up to hourly if required)
● Ability to influence designs early
● Everything reportable, automatable and shareable
Security Release Management

16. Discussion

17. “ Before you go live you must ship your logs off to security
operations in a special format (which will take you weeks to
onboard)”
Brick #2

19. Common Issues
● Large gap between devs and security operations
● Provides a false (and often untested) sense of security
● Slow communication and incident response
● Centralised and difficult to onboard or improve
Security Operations

20. Strategy
● Empower teams to implement and own alerting
● Constantly improve with each new threat model
● Focus on improving alert response process
● Use notification subscription model to allow flexibility
● Test using Chaos Day
Security Operations

21. You Build it, You Secure It
14:54:32,878 WARN [EVT-001] User account locked out
17:32:11,878 WARN [EVT-002] Username does not exist
14:54:32,878 WARN [EVT-003] CSRF Token Invalid
14:54:32,878 WARN [EVT-004] Admin endpoint Usage Detected
14:54:32,878 WARN [EVT-005] JWT Signature Validation Failed
14:54:32,878 WARN [EVT-006] Card CVV Number Incorrect

22. Rapid Implementation & Response

23. Slack For Alerts
● Dynamic, interactive workgroup receive notifications
● Link to cloud hosted runbook with incident response instructions
● Each investigation results in a JIRA ticket
● Security just poke people if required

24. Slack For Rapid Collaboration

25. Result
● All alerts continually evolving through threat modelling
● Teams take ownership of alerts
● Quick to set up and script using Sensu / Github etc.
● Very cheap compared to commercial IDS / SIEM tools
Embedded Operations

26. Discussion

27. “Before you can release, scan your 6 microservices for
vulnerable dependencies and either fix, suppress or
acknowledge all findings”
Brick #3

29. Common Issues
● Time-consuming CVE research duplicated (or skipped)
● Most findings are not used in a vulnerable way
● Difficult to manage vulnerabilities with most tools
● Sometimes difficult / impractical to upgrade
Dependency Checking

30. 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
Share Pre-Investigated Issues

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

32. Put The Brick Down
● Security reviews and collaboration small but often
● Effective communication using modern tools
● Shift security ownership up the pipeline
● Focus on technical and process improvement rather
than managing and firefighting

33. Questions?