6 ms·

What guarantees does Amazon sell to AWS clients regarding the security of their data?

scarface74 7y ago
From all reports, it was caused by an internal Capital One employee and was allowed due to misconfiguration on Capital One’s side. AWS preaches the “Shared Security Model” and emphasizes what it is responsible for and what you are responsible for.
ceejayoz 7y ago
They promise not to fuck up their side of things. They make no promises about your side.
syn0byte 7y ago
Lots! Tons and Tons and Tons! S3 is super secure and CAN NOT be hacked when properly configured and used according to our standard! You got hacked? You must have configured it wrong because we already told you it was unhackable; Good luck proving it was our fault not yours.
- eropple 7y ago
  Can you actually substantiate a S3 security problem that wasn't user error? Because I've yet to hear of one.
- deleted 7y ago
  [deleted]
- SmellyGeekBoy 7y ago
  > Good luck proving it was our fault not yours. Seems like it would be incredibly easy to prove that an S3 bucket was misconfigured in such a way that the data was publicly accessible. In fact this has been the case in the recent high-profile cases that I can recall.
  - giggzy2 7y ago
    The S3 bucket was not public. The hacker got ephemeral keys by remotely exploiting the WAF. The WAF had no reason to have privileges to read from S3, that was a mistake. I’m unclear if data in bucket was encrypted at rest but I guess if you get keys to read it’s a moot point.
- buboard 7y ago
  not sure if serious
sneaksalot 7y ago
A lot, they probably set the bucket as world-readable with no encryption, which AWS warns you about, their engineer just ignored the warning
ben509 7y ago
Up front, I worked at AWS on the CloudHSM team, don't work at AWS any more. I am not a lawyer. This is all my opinion from a very brief analysis. The customer agreement[4] states: > 3.1 AWS Security. Without limiting Section 10 or your obligations under Section 4.2, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure. > 10. Disclaimers. THE SERVICE OFFERINGS ARE PROVIDED “AS IS.” It goes on with the usual shouty disclaimers. The service terms[3] state (I'm specifically citing IAM here because it's how you handle a ton of authentication): > 19.3 You are responsible for maintaining the secrecy and security of the User Credentials (other than any key that we expressly permit you to use publicly). You are solely responsible, and we have no liability, for any activities that occur under the User Credentials, regardless of whether such activities are undertaken by you, your employees, agents, subcontractors or customers, or any other third party. My read on it: AWS generally gives you tools to secure your data, and it's largely up to you how you want to do it. The docs state that if you set IAM to allow or deny access to a service to an authenticated entity, then IAM will do that. If you set up a VPC and shut off a port through a security group, it's going to be locked down. AWS has a slew of services, and these things can interact in surprising ways. So reading the permissions, you're often wondering[1], "what permissions do I need" and it's not always clear what a permission grants. To summarize, then, the AWS documentation at a low level gives you some very technical instructions, and at a high level will generally recommend best practices[2]. I will say that IAM is good stuff and works, the issue is the sheer complexity of configuring it all, and a few footguns thrown in for good measure. But AWS should look at adding "security agreements" similar to their Service Level Agreements that guarantee availability. [1]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_permissions-required.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_perm... [2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... [3]: https://aws.amazon.com/service-terms/ https://aws.amazon.com/service-terms/ [4]: https://aws.amazon.com/agreement/ https://aws.amazon.com/agreement/

From all reports, it was caused by an internal Capital One employee and was allowed due to misconfiguration on Capital One’s side. AWS preaches the “Shared Security Model” and emphasizes what it is responsible for and what you are responsible for.

ceejayoz 7y ago

They promise not to fuck up their side of things. They make no promises about your side.

syn0byte 7y ago

Lots! Tons and Tons and Tons! S3 is super secure and CAN NOT be hacked when properly configured and used according to our standard! You got hacked? You must have configured it wrong because we already told you it was unhackable; Good luck proving it was our fault not yours.

eropple 7y ago
Can you actually substantiate a S3 security problem that wasn't user error? Because I've yet to hear of one.
deleted 7y ago
[deleted]
SmellyGeekBoy 7y ago
> Good luck proving it was our fault not yours. Seems like it would be incredibly easy to prove that an S3 bucket was misconfigured in such a way that the data was publicly accessible. In fact this has been the case in the recent high-profile cases that I can recall.
- giggzy2 7y ago
  The S3 bucket was not public. The hacker got ephemeral keys by remotely exploiting the WAF. The WAF had no reason to have privileges to read from S3, that was a mistake. I’m unclear if data in bucket was encrypted at rest but I guess if you get keys to read it’s a moot point.
buboard 7y ago
not sure if serious

sneaksalot 7y ago

A lot, they probably set the bucket as world-readable with no encryption, which AWS warns you about, their engineer just ignored the warning

ben509 7y ago

Up front, I worked at AWS on the CloudHSM team, don't work at AWS any more. I am not a lawyer. This is all my opinion from a very brief analysis. The customer agreement[4] states: > 3.1 AWS Security. Without limiting Section 10 or your obligations under Section 4.2, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure. > 10. Disclaimers. THE SERVICE OFFERINGS ARE PROVIDED “AS IS.” It goes on with the usual shouty disclaimers. The service terms[3] state (I'm specifically citing IAM here because it's how you handle a ton of authentication): > 19.3 You are responsible for maintaining the secrecy and security of the User Credentials (other than any key that we expressly permit you to use publicly). You are solely responsible, and we have no liability, for any activities that occur under the User Credentials, regardless of whether such activities are undertaken by you, your employees, agents, subcontractors or customers, or any other third party. My read on it: AWS generally gives you tools to secure your data, and it's largely up to you how you want to do it. The docs state that if you set IAM to allow or deny access to a service to an authenticated entity, then IAM will do that. If you set up a VPC and shut off a port through a security group, it's going to be locked down. AWS has a slew of services, and these things can interact in surprising ways. So reading the permissions, you're often wondering[1], "what permissions do I need" and it's not always clear what a permission grants. To summarize, then, the AWS documentation at a low level gives you some very technical instructions, and at a high level will generally recommend best practices[2]. I will say that IAM is good stuff and works, the issue is the sheer complexity of configuring it all, and a few footguns thrown in for good measure. But AWS should look at adding "security agreements" similar to their Service Level Agreements that guarantee availability. [1]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_permissions-required.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_perm... [2]: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... [3]: https://aws.amazon.com/service-terms/ https://aws.amazon.com/service-terms/ [4]: https://aws.amazon.com/agreement/ https://aws.amazon.com/agreement/