This week at OWASP AppSec USA there's a schedule packed with great sessions focusing on devops, shifting left, automation and more. I was lucky enough to get some time from Chris Gates, Sr Security Engineer, Uber and Ken Johnson's, CTO nVisium, busy schedule to ask them a few questions related to their session at AppSec, DevOops: Redux - a defense oriented follow up to their popular talk, DevOops: How I hacked you.
Chris: There has been quite a bit of research into AWS, but Google’s Cloud Platform and Microsoft’s Azure less so. I’d like to find some time to poke at those technologies.
Ken: I enjoy code so for me new languages that are syntactically appealing, practical, and well supported are a major focus. Elixir is very interesting, for example. Outside of code, I've spent my fair share of time in AWS and still feel like there is always more to learn.
Chris: Least privilege, hardening, and having no Incident Response plan. It really is a challenge to balance security with ease and speed of deployment but it must be done.
Ken: The most common security mistake I see is leaving equipment insecurely configured and/or not monitoring it. Another big problem is leaked credentials whether API keys, AWS Access Keys, application secret keys, etc.
Ken: I'd say I'm spilt. Firstly, serverless security by James Wickett is very interesting and there has been a lot of buzz around using AWS's Lambda for this purpose minus the security aspect. Also, I'm very interested in the Scumblr talk because leaked credentials and managing visibility outside the organization is important. Netflix has done a lot to build tools that address many of the problems modern development shops face.
Chris: Occasionally talk at conferences outside your niche. I primarily speak at “security” conferences, but the best reception and feedback I’ve ever received at a conference was at DevOps Days for the original DevOoops talk. It was not my normal crowd but I also wasn't speaking to the choir and that was refreshing. Ken and I were able to see realization (and then OMFG) on the faces of people in the crowd as we presented the ways to break common devops tools. Feedback afterwards reinforced to us that people were using these tools and products in their organizations and were able to immediately take something away from the presentation because we also included some fixes for the issues we presented. Follow on questions from those talks led to the creation of the talk we are giving at AppSec USA.
Ken: Be yourself. Also, rehearse A LOT by first speaking at meetups or local events before doing something bigger like a conference .
Chris: On the purple teaming side of things: We have turned security, even for internal security teams, into an adversarial exercise rather than a teamwork exercise. Many times internal Red and Blue teams who are charged with the same goal, that of protecting the organization, tend to treat each other as adversaries instead of teammates. When Red doesn't share with Blue and Blue doesn't share with Red to improve each other's skills in a positive and cooperative manner, an attacker only needs to be slightly better tech than the company’s Red team and only needs to evade the Blue team’s detection abilities to succeed. The key is to work together to iteratively improve each other.
Chris: The group powering up and configuring whatever the technology is has “a” responsibility for securing the technology. We need to move away from “being too busy” or “not my job” to worry about securing things. In the DevOps world your environment can look drastically different from one day to the next with the pace of development and the ability to deploy sites/microsites in a very quick fashion. If the creators of the sites aren't 1) securely deploying these things and 2) letting someone know they are deploying them, we can never hope to have any reasonable level of security for them.
Secondary responsibility goes to an organization’s security team to make themselves available during all phases of deployment from design/architecture, to deployment, to monitoring. Security should always be a value-add and not a blocker to the organization conducting its business. Everyone in security should read “The Phoenix Project” and give some thought to if their actions resemble those of the security manager in the book.
Ken: The answer really depends on the business. Also, it depends on whether or not you are asking who should be implementing security at a technical level or if you are asking who should be responsible to the business for security. Let's focus on the technical implementation and I'm going to throw something out there. If you are on a security team, and your company is using the tooling associated with DevOps, learn that tooling and get certified where possible (Amazon's certification path, for example). It will help when security is brought into any decision making process with the Ops/Dev teams.
Chris: I have no useful information on timelines. You’d have to check to see what Uber have put out in regards to timing. But I can tell you that every time I drive on I-95 I want autonomous cars to be ready as soon as possible.
Related to the topic is car-to-car communication. We’ve yet to deploy any protocol, that I’m aware of, correctly the first time. There are some pretty serious implications to vulnerabilities in autonomous cars and car-to-car communications. Thankfully many car manufactures are on board with bug bounty programs so I think we can identify and remediate issues pretty quickly.
Ken: We're already seeing some adoption of autonomous driving but I can't see 100% of the US using autonomous vehicles for a long time. More likely, you'll see adoption in cities like SF, Seattle, etc. - first. I think there are a lot of general safety concerns that likely take precedent over software security concerns. That having been said, the automotive industry hasn't exactly shown us (security) that they are excelling at software security, either. So software security is definitely one concern in a larger set of concerns around autonomous vehicles.
Chris: Haydn Johnson (@traversal) and I are speaking at SecTor in October on “Purple Teaming the Cyber Kill Chain” and Chris Nickerson (@indi303) and I are speaking at BruCon on “Building a Successful Internal Adversarial Simulation Team.”
Both talks complement each other with the idea that purple teaming should be more than just getting charged for an extra consultant to tell you how you did in person but instead create a framework for Red and Blue to work together to improve the protection, detection, and response capabilities for an organization.
Ken: LASCON and AppSec California are a must in my opinion. Also, I'm trying to make it out to DevOpsDays Amsterdam. As far as content, Chris and I have spoken a lot about AWS but one area I'd like to see us dive deeper into is disaster recovery techniques for AWS as well as maybe a little more into Azure/Google Cloud. These cloud platforms and DevOps movements in general, have done something really unique for security - they have blended the skillsets of folks like Chris and I who would otherwise fall under traditional roles such as "application security" or "network security".
If securing the tools you use to help enable devops is of interest, don't miss their session coming up on Friday, DevOops:Redux.