PCI Requirement 8.3 says, “Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.” For AWS, everything is non-console – so how to you comply with this requirement? Is it still applicable for an AWS environment? Yes, it is. In every use case, the actions are administrative in nature or using virtual technology. This means that you must enable MFA for administrators and all users. 

MFA requires that you utilize two out of three authentication methods, which are: 

To learn more about how AWS IAM supports MFA, visit the AWS documentation on using MFA in AWS. 

Relating an AWS environment to PCI Requirement 8.3 requires us to start with the idea of non-console access. For anything within an AWS environment, it’s going to be non-console access. Immediately accept the fact that multi-factor authentication needs to be enabled for administrators as well as regular users of your AWS environment because, for all intents and purposes, all of your access is either administrative in nature or over some type of remote technology because you’re never going to be at the console in your AWS environment. So, enabling multi-factor authentication is very important. 

You have to require two of the three components for multi-factor. There are three factors: something you know, which is something like a password or passphrase, something you are, which would be a thumbprint scan or retinal scan, and something that you have, which would be some device, some token, that provides you with a code on that physical device to allow you to connect over multi-factor authentication technologies. One side note, something that comes up from time to time, is if I’m logging in from my laptop and I’m entering my password and I’m opening a virtual token or an app, a software application, which is giving me the second item, is that multi-factor? It’s something to think about if one authentication mechanism to gain access to that device that allows you to enter both components is exposed in some way, exploited in some way, then you’re really losing the benefit of that second factor. Think in terms of logging in from a workstation with your username and password and then going to a second device, something that you have, to get your token, ideally a mobile phone or other type of device separate from your laptop. That’s the principle of MFA – to require two of those things in order to access the environment. 

Another thing that I’ll point out when we’re going through these security audits is that we will evaluate where you have multi-factor enabled. You have to think about that for your third parties as well, it’s not just your administrators and your users, but it’s also any third parties who have access. I just reviewed an AWS environment yesterday where all of their vendor accounts that they had created for people to access their AWS environment did not have multi-factor enabled. That’s something that you want to apply across the board because you don’t want someone to do something as simple as losing their username and password, clicking on a phishing link, exposing that password that they have, and that being your last line of defense before someone could log in and access your environment. Think globally and implement MFA to require your users to enter two things, two factors, in order to access your AWS environment.