Security is too hard. It is time for automation!
A presentation at DevOpsDays Bogota in in Bogotá, Bogota, Colombia by Sasha Rosenbaum
Security is too hard. It’s time for automation! Sasha Rosenbaum @DivineOps
Dev Ops Architect Product Manager Microsoft => GitHub @DivineOps
And you?
State of security today
More code = more problems Source: GitHub Data Science team analysis
Insecure code causes breaches Source: 2019 Data Breach Investigations Report, Verizon 53% of breaches are caused by weaknesses in applications
The earlier we remediate, the better! SDLC Stages Develop Build Test Deploy Breach $ Millions $7,600 Remediation Costs Sources: NIST, Polemon Institute $80 Development $240 Build $960 Test/QA Production Breach
Security researchers are outnumbered! Sources: NIST, Polemon Institute
Assume Breach There are two types of companies: those that have been hacked, and those that don’t know they have been hacked
The Two Widest Back Doors • Credential Theft • Exploiting Known Vulnerabilities
Attackers have changed their playbook… 46% How do breaches occur? of compromised systems had no malware on them 100% 67% of victims have upto-date anti-virus signatures of victims were notified by an external entity Source: Mandiant 2014 Threat Report 33% of victims discovered the breach internally MICROSOFT CONFIDENTIAL, NDA 99% Of the exploited vulnerabilities were compromised more than a year after the CVE was published. 23% Of recipients open phishing messages (11% click on attachments) 50% Nearly 50% open emails and click on phishing links within the first hour.
Phishing • Total population of 524 people. • 220 people clicked on signup button. 37 people clicked on both phishing emails • Only 11 people (2%) reported to as probable phish!
Employee awareness training is not very effective in preventing phishing attacks
Email protection
Securing the software supply chain
How much do you rely on open source?
Open source software in the Enterprise New Code 99% of organizations make extensive use of open source Inner Source 90% of new application development leverages open source software. Source: Forrester Wave Software Composition Analysis 2017 Open Source New Application Code
99% Of the exploited vulnerabilities were compromised more than a year after the CVE was published
90% percent of active applications use libraries with a known CVE — 30 percent used a library with a critical CVE. Patching a critical CVE took an average of 34 days. Source: TCell Security Report, 2018
Automatically upgrade vulnerable dependencies
Dependabot increases the resolve rate and speed
Package Management Ø OSS dependencies are scanned for vulnerabilities and kept up to date Ø Builds artifacts are managed Ø Binary artifacts are accessed via a trusted feed and scanned for vulnerability
Securing you Code
Secret scanning
Code scanning
Code scanning can help!
Code scanning is still an aspiration Of applications using static analysis! ~Weekly Source: Veracode SOSS Vol. 10 ~Daily
Code scanning is automated code review!
Code scanning
Automation is not everything
Why Threat Model? A way to identify security issues during design Developers think about how a product works Attackers think about how to abuse a product Shift the mindset Think like an attacker
Threat Model: Pull Request Bypass
War Games
“Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win” — John Lambert (MSTIC)
Security Mindset - Assume Breach Started with war games to the learn attacks and practice response vs. Initially double-blind test Over time, eliminated blue team Our defenders need to be our defenders Shifted left to prevent top risks Credential theft Secret leakage OSS vulnerabilities
Example: Red Team Attack Open File Share Plaintext Test Credentials Dev box with Test Account as Local Admin Dev’s Credentials Mimikatz Credential Dump
Another Source of Leak: Credentials in a File What do plaintext credentials look like? Every team seems to experience this one at the beginning.
Prove it!
Every time someone viewed the dashboard…
Protect Against Lateral Movement Ø Assume layers before yours will be breached Ø Never assume an internal service is unimportant Ø Never assume a service is secure because it is internal
No Standing Permissions Ø No standing access to production Ø JIT ( just in time) tokens only Ø Secure Workstations only Ø Infrastructure refresh
Internal CTFs Capture the Flag events
Thank you! @DivineOps
Thank you! @DivineOps
Software composition reports show that the more code we write, the more security vulnerabilities we introduce - both directly in our code, and in our dependencies. How can we make sure that we reduce the risk of new security vulnerabilities every time we push to production?
In this session, we will learn how to protect your code against common security missteps - before you deploy to the cloud. You’ll come away with a better understanding of what you do earlier in your development to prevent security issues down the line.
for free. You
can too.
Buzz and feedback
Here’s what was said about this presentation on social media.
