PCI Requirement 11.1 calls for a process to test for the presence of wireless access points, and a process to detect and identify all authorized and unauthorized wireless access points on a quarterly basis. It’s not entirely about testing for the presence of wireless access points that you do have; it’s more about testing for unauthorized wireless access points. How is this requirement applicable in an AWS environment? 

Through the AWS Shared Responsibility Model, AWS is responsible for protecting “security of the cloud” which includes the infrastructure of hardware, software, networking, and facilities that run AWS services. But, we want to challenge your thinking for PCI Requirement 11.1. To gain compliance and maintain a secure perimeter, you must consider all the ways that your controls, your personnel, and your technology interact with the AWS environment. Each of these are an opportunity for an insecure process. 

The exploitation of wireless technology within a network is one of the most common paths for malicious users to gain access to the network and CHD. This is due to the ease with which a wireless access point can be attached to a network, the difficulty in detecting their presence, and the increased risk presented by unauthorized wireless devices. Walking through your processes to expose vulnerable access points and areas of the network will support compliance with PCI Requirement 11.1

One of the confusing things about going through a PCI DSS engagement within an AWS environment is trying to understand when requirements apply to the AWS environment and when requirements apply outside of that. PCI Requirement 11.1 is one of those. When it asks you to inspect your wireless access points and to search for any unauthorized wireless access points, a lot of times people will say, “Well, our cardholder data environment is in AWS so we can’t have any wireless access points within that environment, so this doesn’t apply to us.” 

I’d like to challenge your thinking on that and get you to think about systems that connect to your AWS environment. What kind of controls have you put into place that would take out the administrative workstation or the IT person’s laptop or the developers who have access to production and push code to production? What kind of controls have you put into place to segment those systems outside of your cardholder data environment? For a lot of people, they haven’t gone to those lengths to do that, so the physical area of where those workstations and laptops and those people who have those roles who have access to your AWS environment become very important. PCI Requirement 11.1 – about someone putting in place a rogue access point that could potentially provide them access to the network that you’re on – becomes important even if your production environment is housed within AWS. 

Evaluate this and think about your workstation or laptop that you’re utilizing to connect to AWS. If you assumed that that system was compromised, how could your AWS environment be affected? That’s a very important incident scenario to walk through in order to look at the controls that you’ve put into place. If those systems reside on a network that has a rogue access point and a malicious individual is connecting to that network and monitoring your traffic and compromising your box, that can be one of the requirements that you should put into place, is to inspect your wireless access points and search for these rogue access points that could appear on your network. If you have any questions about working through this and establishing the scope of your PCI cardholder data environment, please reach out to us today. We’d be happy to help.