Actionable Followups from the Capital One Breach

Alexandre Sieira has some very interesting and actionable advice from looking at the Capital One Breach in “Learning from the July 2019 Capital One Breach.”

Alex starts by saying “The first thing I want to make clear is that I sympathize with the Capital One security and operations teams at this difficult time. Capital One is a well-known innovator in cloud security, has very competent people dedicated to this and has even developed and high quality open source solutions such as Cloud Custodian that benefit the entire community.” I share that perspective – I’ve spent a lot of time at OWASP, DevSecCon and other events talking with the smart folks at Capital One.

One thing I’ll add to his post is that the advice to “Avoid using * like the plague” is easy to implement with static analysis, by which I mean grep or diff in a commit hook. Similarly, if you want to block the grant of ListBuckets, you can look for that specific string.

Over time, you can evolve to check that the permissions are from a small subset of permissions you agree should be granted. One of the nice things about the agile approach to security is that you can start tomorrow, and then evolve.

At Blackhat next week, Dino Dai Zovi will be talking about how “Every Security Team is a Software Team Now.” Part of that thinking is how can we take advice, like Alex’s, and turn it into code that enforces our goals.

As we learn from breaches, as we share the code we build to address these problems, we’ll see fewer and fewer incidents like these.

Navigation