261–270 of 319 posts
Earlier quoted context omitted.
They are legally obligated, especially in California, to disclose part or all of this breach to customers. But that obligation is not immediate. Give it some time.
Do they need to notify those of us not located in California?
Earlier quoted context omitted.
The problem with AWS (and other cloud providers) is that it's nearly impossible to properly configure an environment because of how many different methods there are to gain access to resources. Capital One has been all in on AWS and has dedicated an immense amount of time and money to developing systems for managing their AWS resources (Cloud Custodian for instance) and yet they still couldn't protect their data. Wha…
The whole point of moving to a cloud provider it allow the quick setup and deployment of new projects/products as well as trying to limit your costs. With that sort of open-ended system, unless everyone is always thinking security first and okay with the inevitable slow downs associated with a highly locked down system then you will more than likely always run the risk of this sort of situation.
Earlier quoted context omitted.
I've had AWS support tell me exactly what processes are running on my instance. They do seem to have some visibility beyond metadata.
I'm an Amazon employee here - but my words don't represent the company. Internally we also talk to AWS support. They absolutely don't have much visibility into our accounts at all - much to my frustrations. They only see metadata - even for internal accounts. The only teams that have some access to such information is security team, or when you Grant access explicitly to the other person via standard AWS auth mechani…
Earlier quoted context omitted.
It doesn’t matter. There is never a reason for credentials to be anywhere near your repository. If you’re running locally, you should have your credentials in your home directory (via aws configure). If you are running your code on AWS either on an EC2 instance, lambda, or Docker you should be using the role associated with the execution environment. Every SDK that I have used let’s you use a constructor without a pa…
i know, this was a few years ago, and these types of practices were still being developed out in the greater community (lambda didnt exist yet, dockeer was still nascient etc)
(If anyone needs me, I’m busy feeling old after remembering having this conversation with a new PHP developer in 1998)
> hacked into a cloud-computing company server, federal prosecutors in Seattle said > the cloud-computing company, on whose servers Capital One rented space, wasn’t identified in court papers. Does this feel like it was just an S3 bucket with permissions set incorrectly? I've come across sensitive documents in S3 buckets with a well crafted google search.
Per the complaint, it doesn't sound like the bucket was exposed to the world. Rather, security credentials were "obtained": > Capital One determined that the first command, when executed, obtained security credentials for an account named XXXX-WAF-Role, that in turn, enabled access to certain of Capital One's folders at the Cloud Computing Company. Unsure how one would obtain credentials for an IAM Role, but the abov…
You use your own credentials and issue an API call to do it. If you're using the AWS CLI, it's "aws sts assume-role".
We do something similar with our accounts. You can place a restriction on the role that an MFA token must be used while assuming the role, so this allows you to give out longer-term credentials to your devs/admins that can then be used (with an MFA token) to assume a more privileged role.
The role itself needs to be configured with a trust relationship that allows for this, and many roles are restricted to AWS services (i.e. you are authorizing an AWS service to assume the role--not a specific user). I've never used WAF before though, so I'm not sure if it's typical for the WAF role to have that trust relationship or not.
> No bank account numbers or Social Security numbers were compromised, other than:
Then below that, in non-bold, it basically says "oh, except for these 140,000 social security numbers and 80,000 bank account numbers" - which is the primary reason folks are worried about this!
To me, the first thing you are going to see is "No bank account numbers or Social Security numbers were compromised" in bold letters. Which is completely false and misleading. Technically they are telling the truth, but the way they've done it is clearly meant to be misleading.
On top of that, I'm a Capital One customer myself, and I can't figure out how to find out if I was affected at all!
Earlier quoted context omitted.
If you put data in the cloud, make sure you encrypt with keys only you have even when they promise all sorts of assurances of oversight and process in addition to “we use AES”.
This right here. Take away any outsiders ability to access things. I also feel AWS and the rest should be able to notify you when files untouched en masse for years are being accessed and it should set off alarms like crazy. If not acted upon then its the issue of whoever got those emails.
Earlier quoted context omitted.
They are legally obligated, especially in California, to disclose part or all of this breach to customers. But that obligation is not immediate. Give it some time.
According to the Daily Mail article linked above, they've known since mid-July. They could have issued a statement today if they wanted to. I can understand why they didn't do it earlier, to minimize the number of press cycles with their name attached to this incident. But if this were my credit card company, I would be pretty irked to be finding out about it weeks after the company knew, from the news.
Why am I finding out about this from the news and not an email from Capital One themselves? I wish there was legal liability to inform customers in the event of a data breach.
They are legally obligated, especially in California, to disclose part or all of this breach to customers. But that obligation is not immediate. Give it some time.
Earlier quoted context omitted.
What does this refer to?
Some S3 eng accidentally dropped a big chunk of the servers that were the s3 equivalent of an hdfs nameserver, ie mapping blob name to location info, as part of an unrelated config change. While attempting to recover, the s3 team discovered and/or decided the nameserver needed a full restart. That's when they discovered the info in the nameserver had grown so large since the last full restart years previous that it t…