> The cloud-computing company, on whose servers Capital One rented space, wasn’t identified in court papers
I can’t tell whether the company virtual server got hacked or whether the cloud provider was who got breached. Hopefully just the vm
> The cloud-computing company, on whose servers Capital One rented space, wasn’t identified in court papers
I can’t tell whether the company virtual server got hacked or whether the cloud provider was who got breached. Hopefully just the vm
If you think about the attack vectors here, it was most definitely the virtual server that got attacked. If it was the cloud provider (Amazon), there are a lot of safeguards that these banks use to make sure that any data that touches the shared server persistent storage is encrypted. And when I say safeguards, I mean automation to make sure that this sort of scenario shouldn't ever happen.
This is a huge blow for the public cloud and financial services companies, unfortunately.
Edit: Seemingly a WAF firewall issue. I wonder what happened. These rules should be applied automatically for Capital One using Cloud Custodian [0], so a config issue definitely occurred somewhere.
Final edit: A leaked account with access to IAM permissions. Good lord was occam's razor correct here.
If you've somehow left access to a bucket open the odds are that you also have it configured to let anyone with access to the bucket decrypt the files. AWS calls this server side encryption, where S3 automatically encrypts and decrypts files for you. You can also do client side encryption, of course, but it's much more difficult to manage because you have to deal with keys in your application.
Well,SSE-KMS is not difficult to manage if you have sensitive customers data like Capital One does. I use it all the time. You can pretty much audit the buckets and see what is going on.
And if Capital One has used SSE-KMS on the buckets,we might not be talking about this data breach today.Incompetence? Complacency?
There, I gave you more than 10 seconds. Trying keeping up.
the best link for understanding what happened is actually the court case filing not the media reports. https://www.justice.gov/usao-wdwa/press-release/file/1188626...
so this isn't a case of s3 bucket being public/wide open, its a case of a waf iam permissions being overly broad if I'm parsing the filing correctly. Its unclear how the waf product was hacked/bypassed and its credentials obtained.
wrt to custodian in this equation, its not really related afaics, custodian has lots of filters to help determine stuff like is my ec2 or anything with iam role (lambda, etc) overly permissive wrt to permissions (check-permissions filter). it also has the ability to filter individual statements and access on any resource (s3, lambda, etc there are many) with an embedded iam policy on a fine grained basis (allow y accounts but not x accounts) to protect against account level access (cross-account filter). And the ability on ec2 via guard duty alerts to auto remediate (suspend, memory snapshot, yank role, volume snapshot). its used by lots of users/enterprises across the governance, security, cost-optimization domains because its flexible and supports many clouds.