Shifting Security Left - Securing Systems In The Age of Agile and DevOps

(CSA Chicago Deck)

Transcript

1. Shifting Security Left Securing Systems In The Age of Agile and DevOps
2. whoami TYPICAL DISCLAIMERS: ▪ All opinions are mine, except the bad ones. The bad ones probably came from Twitter. ▪ All examples are hypothetical, especially the bad ones. ▪ Nearly all of this is me showcasing other people's work. ▪ I strive for good attribution. If I missed someone, @ me.
3. Security Failures Configuration
4. Congratulations, you got a seat at the table. Now what? ▪ Secure all the things! ▪ Bend them to my will! ▪ SME all the projects! ▪ Make sure security signs off on EVERYTHING. ▪ Pen testing is the only testing. ▪ Don’t change anything after you build it.
5. In waterfall security models angst, cost, delay and failure are features, not bugs.
6. Technology Project Snarkchart Remediation Work 22 days Jan Mar May Jul Sep Nov 2019 Mar May Project Kickoff Jan 10 Executive Review Mar 7 Go No-go Decision Mar 14 Committed Go Live Date Aug 6 The Date You Crossed Your Fingers and Put It In Production Oct 20 Project Close Re-assigning contract staff to new project Feb 4 Remediation Deadline Data Breach Uncovered Requirements 34 days Prototype 29 days Development 150 days Launch 30 days Security Test 6 days Disagreeing About the Severity of the Findings 5 days Bargaining with Compliance for Longest Possible Remediation Timeframe 33 days
7. All bugs cost money, some more than others
8. Left of What?
9. Does you security team even understand what’s going on? What developers see What security sees
10. The reality of DevOps and agile adoption
11. Improving security in most organizations ▪ Training ▪ Threat Modeling ▪ Requirements Definition ▪ Secure Architectural Patterns ▪ Code Quality Tools ▪ Incident Response
12. Training Need to prioritize other security investments? Have a Training Budget? (Don’t snub YouTube. We know every household skill you learned in the last five years came from a YouTube video.)
13. Teach Lightweight Threat Modeling ▪ Threat modeling exercises help you evaluate your application design for security risks. ▪ Threat modeling frameworks and processes can get complicated fast. ▪ Use just enough to achieve a win, and improve threat modeling over time until it’s a good fit. ▪ Mature DevOps teams may benefit from threat-modeling-as-code - ThreatSpec Resources: ▪ Elevation of Privilege – Microsoft ▪ The Security Cards – U of Washington ▪ ThreatSpec
16. Give Teams Self-Service Requirements ▪ OWASP Security Knowledge Framework ▪ Uses the OWASP Application Security Verification Standard (ASVS) to guide teams through identifying security design requirements. ▪ Slack goSDL (Security Development Lifecycle) ▪ Helps teams perform lightweight risk assessments / technology profiles, and provides checklists of security requirements.
17. Inform Your Self-Service Requirements With Secure Architecture Standards ▪ AWS Well-Architected Framework ▪ AWS Security Pillar ▪ Microsoft Best Practices
18. Help developers discover their bugs Make it seamless… ▪ Auto-provision – give developers birthright access to code quality systems. ▪ Include code quality tooling into templates for repos pipelines. But drive accountability… ▪ Develop easy to understand quality indicators. ▪ Warn/Break builds and deploys for critical security defects and obvious misconfigurations.
19. Code quality tools ▪ Code Linting Tools: SonarLint Fortify Security Assistant ▪ Static Analysis: Codeacy Sonarqube Synopsis Coverity NodeJScan (Requires python, ironically) LGTM ▪ Dynamic Analysis Burp Suite OWASP Zap w3af Arachni Codepulse (Use for coverage monitoring of DAST tools) ▪ Secure Composition Analysis Tools Snyk (free for OSS) OWASP Dependency Track SonaType OSS Index
20. Delivering Golden Images ▪ AWS Golden AMI Pipelines ▪ CIS Benchmark Hardened AMIs ▪ AWS Config Rules ▪ Azure Security and Compliance Center ▪ Container Scanning Clair Anchore
21. Vulnerability Management ▪ Audit your CloudFormation templates – Cloudsploit. ▪ Use APIs to continually poll your cloud accounts for new assets. ▪ Post-build, scan your container registries for vulnerabilities. ▪ Use Amazon inspector to check for vulns and misconfigurations. Use vuln scanner APIs ▪ All modern vuln scanners have an API. ▪ At deploy time, identify the target deployment servers and query their vuln state. ▪ Set your WARN/BREAK states to a level that works for your org.
22. Incident Response ▪ CloudTrail all the things ▪ EC2 Clean Room Forensics ▪ Ensure endpoint tools are baked into golden images. Monitor for unsafe behavior in GuardDuty: ▪ Bad firewall rules ▪ Opening unapproved ports ▪ Clearing logs ▪ Non-IAM user logins
23. Secrets Detection ▪ Git pre-commit hooks ▪ Scanning your repos ▪ Better ways to store keys: HashiCorp Vault AWS Secrets Manager Azure Key Vault ▪ Use your DLP to monitor for API keys.
24. Where do we go from here?
25. Where we’re going
26. Slides: speakerdeck.com/chrismerkel Connect: linkedin.com/in/chrismerkel