Because attackers know that vendor-supplied defaults are an easy target, the PCI DSS makes this a focal point by making organizations responsible for changing vendor-supplied defaults. PCI Requirement 2 states, “Do not use vendor-supplied defaults for system passwords and other security parameters.” But if AWS doesn’t even have default accounts or credentials, how does this requirement impact your compliance? To meet PCI Requirement 2 when using AWS, you need to document the fact that you’re using AWS services that create unique accounts and passwords, like AWS IAM, Amazon Cognito, AWS Directory Service, or other authorization mechanisms. 

One of the root causes of a lot of breaches out there is when companies don’t change vendor default accounts. A lot of attackers know that they can exploit those accounts if you’ve left them behind. It’s known what the username is, it’s known what the password is, if you don’t change things like that. Within the AWS environment, one of the very interesting things is that AWS does not have default accounts. In the PCI DSS requirements dealing with this, you have to ensure that you have changed defaults – so within AWS, that’s really not the emphasis of what you’re doing. You will just want to document the fact that you’re using these AWS services that create unique accounts and passwords that are necessary for managing your access into this new environment that you’re setting up. For example, using IAM is a big part of establishing who’s authorized to have access to these systems. Also, when you generate new EC2 instances, you will be given newly created administrator and root-level accounts to the operating system. There are associated keys and those passwords are encrypted within the AWS system. So where you aren’t changing defaults, you need to document how you are provisioning those services, who has access to them, and the fact that you are protecting the access and the credentials to those services within AWS.