The Capital One Breach And What We Should Really Be Talking About

Voiced by Amazon Polly

I’m not going to try and write anything regarding the attack vector, Erick Johnson did that well here:

I’m not going to give an executive overview, Krebs did that well here:

I really just want to bring up something I haven’t heard enough people talking about, detection. There has been lots of conversation around many different perspectives: Is Amazon to blame, Is Capital One to blame, who wrote the application, who was in charge of security. But to me, no one is really talking about the right thing.

This breach could have happened to anyone.

It could have happened to any web app regardless of where it was hosted, AWS, GCP, Azure, On prem.

Some have said, but AWS’ metadata service was unprotected. Maybe so.

Some have said better code should have been written. Maybe so.

Some have said, someone in security wasn’t doing their job. Maybe so.

It’s great to do a root cause analysis, but not for the reasons I keep seeing. It doesn’t add any value to any of us to do any analysis in order to find blame. The only thing we need to be worried about is defining the TTP. Using those TTPs to understand the method of attack and whether or not we can detect it and if we have any missing controls. Then to implement them.

Bottom Line

Today it is an SSRF attack, tomorrow it is something else. We need to be able to detect “not normal,” and quickly. We need to stop relying on tools and understand what a real attacker is going to do. Joe Vest explains this well here.

Prevention is whack a mole. We can’t stop everything. (I’m not saying we shouldn’t do this) Turning on tools and checking boxes isn’t what an attacker worries about.

So let’s stop asking if we should reconsider this cloud thing and maybe ask “Can we detect this?” On prem or in the cloud.

Vulnerable Web App that led to code execution on a production web facing server -> Non normal use of a service on a public facing system originating from outside the network->export of a large number of records to an external destination.

Then we started architecting with that threat in mind.


For AWS, here are a couple resources that may be helpful (and not new):

 The Assumed Breach Model – A Practical Approach Part 3

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.