Human error is often the weakest link in a security system, and the same is true for AWS environments. Your personnel pose a physical security threat to the data in your cloud. Think of all the ways that an employee, user, or vendor interacts with the data in your cloud – someone has to put data in the cloud, someone manages it, and someone accesses it. Each of these touchpoints is an opportunity for an insecure physical process.

Your responsibility, when it comes to PCI Requirement 9, is to consider the physical aspect of your processes as they relate to CHD in AWS. You might find that personnel doesn’t follow the policies and procedures correctly or find a device that was thought to be out of scope that’s actually in scope. Additionally, you must obtain and review AWS’ PCI Attestation of Compliance (AoC) at least annually. AWS’ PCI AoC and AWS PCI DSS Responsibility Summary are available to customers through AWS Artifact. Reviewing this PCI AoC and performing your own scoping assessment will ensure that you have an appropriate scope for your CHD environment in AWS. 

I want to recommend to you, today, that you evaluate the physical security requirements in the PCI DSS as it relates to how you interact with your AWS environment. A lot of times, people put this to the side and they only consider the risk to the AWS environment and they don’t think about the risk that they face in the processes, the employee actions, and the systems that are utilized to connect to the AWS environment. 

I’ll give you a few examples. When we conduct our physical security walkthroughs with our clients, sometimes we stumble upon things that make the scope larger than the applications or resources that are housed within AWS. For example, during one visit, we were talking to the developers of an organization. We looked over on a shelf and we saw a laptop connected to network attached storage. We asked, “What is that laptop over there?” They said, “Oh, that’s the backup of our production code. We take a snapshot of the code every night and we place it on that device and that’s where it resides, in case of emergency.” Well, that became very important to the scope and now physical security requirements had to be considered for protecting that area. Another example is when we had worked in a remote sense with a client in order to review how they access their AWS environment. We observed them connecting with multi-factor authentication across VPN in order to access their AWS account. They had established bastion hosts in order to take their offices and employee homes out of scope for the physical security requirements. But, when we were onsite and we were observing their processes, we found employees who were connecting to the AWS environment over SSH without multi-factor authentication. Now, all of a sudden, that laptop that employee was using was in scope. It was part of the cardholder data environment and everything else that was connected to that laptop became in scope. Now that physical environment where people were connecting to that AWS environment, because it was bypassing some of the other controls that they had set up, it made physical security a lot more important. These are things to consider. 

Don’t ignore these risks because if you look at some of the recent news and data breaches, you’ll find that attackers did have access to the development environment. They did have access to the build pipeline. Physical security about who can access what and who can get to critical systems within your organization can be very, very important and should not be neglected when you’re looking at physical security requirements in the PCI DSS.