Sep 17, 2017
Zane Lackey (@zanelackey on Twitter) loves discussing how to make the DevOps, and the DevSecOps (or is it 'SecDevOps'... 'DevOpsSec'?)
So we talk to him about the best places to get the most bang for your buck getting security into your new DevOps environment. What is the best way to do that? Have a listen...
Youtube Channel: https://www.youtube.com/channel/UCZFjAqFb4A60M1TMa0t1KXw
Join our #Slack Channel! Sign up at https://brakesec.signup.team
#iHeartRadio App: https://www.iheart.com/show/263-Brakeing-Down-Securi/
Comments, Questions, Feedback: firstname.lastname@example.org
Support Brakeing Down Security Podcast on #Patreon: https://www.patreon.com/bds_podcast
#Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir
#Stitcher Network: http://www.stitcher.com/s?fid=80546&refid=stpr
#TuneIn Radio App: http://tunein.com/radio/Brakeing-Down-Security-Podcast-p801582/
Security shifts from being a gatekeeper to enabling teams to be secure by default
Require a culture shift
Should that be implemented before the shift to CI/CD, or are we talking ‘indiana jones and the rock in the temple’?
If it’s just dev -> prod, where does security have the chance to find issues (i.e. test and QA belong there)?
We used to have the ability for a lot of security injection points, but no longer
Lowers the number of people we have to harangue to be secure…?
Security success = baked in to DevOps
Shift from a ‘top down’ to ‘bottom up’
Eliminate FPs, and forward on real issues to devs
Concentrate on one or two types of vulnerabilities
Triage vulns from most important to least important
Go for ‘quick wins’, or things that don’t take a lot of time for devs to fix.
Grepping for ‘system(), or execve()’
Primitives (hashing, encryption, file system operations)
How do you stop a build going to production if it’s going out like that?
Do we allow insecurity to go to Production?
Or would it be too late to ‘stop the presses’?
“We’ll fix it in post…”
Instead of the ‘guardrail not speedbump’ you are the driving instructor...
But where does security get in to be able to talk to devs about data flow, documentation of processes?
5 Y’s - Why are you doing that?
Setup things like alerting on git repos, especially for sensitive code
Changing a sensitive bit of code or file may notify people
Will make people think before making changes
Put controls in terms of how they enable velocity
You like you some bug bounties, why?
Learn to find/detect attackers as early in the attack chain
Refine your vuln triage/response
Use bug reports as IR/DFIR...
In SAST, a modern way to decide what to test is start with a small critical vuln, like OS command injection. Find those and get people to fix it. BUT don’t developers or project teams get unhappy [sic] if you keep "moving the goal post" as you add in the next SAST test and the next SAST test. How do you do that and not piss people off?
How do you make development teams self sufficient when it comes to writing a secure application? Security is a road block during a 3 month release schedule….getting "security approval" in a 3 day release cycle is impossible.
But then…what is the job for the security team? If DevOps with security is done right, do you still need a security team, if so what do they do???? Do they write more code???
I don't think your Dev'ops'ing security out of a job...but where does security see itself in 5 years?
Last one if there is time and interest. If Zane Lackey was a _maintainer_ of an open source project, what dev ops sec lessons would he apply to that dev model…to the OpenSource model?
(We've got internal projects managed with the open source model...so im interested in this one)
Even with out any of those questions the topics he covered in his black hat talk are FULL of content to talk about. Heck, even bug bounties are a topic of conversation.
The idea of a feedback loop to dev...where an application under attack in a pen test can do fixes live....how that is possible is loads of content.