PCI Requirement 8.2 adds an additional layer of security to user IDs by requiring something you know, something you have, or something you are. It states, “In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: something you know (such as a password or passphrase), something you have (such as a token device or smart card), something you are (such as a biometric).”
Understanding proper user-authentication management is easier than you might think. How many times have you entered a PIN after swiping your debit card this week? Your PIN is something you know. Has a website ever texted your phone a one-time password in order to gain access? That one-time password is something you have. Do you use a scan of your fingerprint to unlock your smartphone? Your fingerprint is something you are. The PCI DSS explains, “These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used).”
To verify compliance with PCI Requirement 8.2, an assessor needs to examine the documentation that describes your organization’s authentication methods, then observe that the methods described are consistent with your system.
We started off talking in Requirement 8 about the need for everyone to get their own username and that no one shares their usernames. When we get to PCI Requirement 8.2, it basically says that everyone needs to have something to authenticate with. This can be a password, biometrics, a physical device. It doesn’t really matter what it is that your organization uses for authentication, it matters that everyone has something that they use to authenticate with.
Inactive Sessions
I’m sure you’ve witnessed or heard about situations where someone gets up from their workstation, but their session doesn’t log out. Inevitably, someone else uses their workstation to send an embarrassing or prank email on their behalf. But, what if it wasn’t something funny or embarrassing? What if a malicious user used your workstation and gained access to cardholder data? When users walk away from an open machine that has access to critical system components and/or cardholder data, that machine could be used by others in the user’s absence, resulting in unauthorized account access and/or misuse. This is where PCI Requirement 8.1.8 comes into play.
PCI Requirement 8.1.8 states, “If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.” This applies to your organization’s firewalls, routers, networking gear, and other equipment within your environment. An assessor will examine system configuration settings to verify that you require re-authentication after 15 minutes of inactivity. This doesn’t necessarily mean that the session has been terminated, but that the user will need to re-authenticate in order to access that session.
I’m sure we’ve all heard or seen about situations where somebody gets up from their workstation or laptop and it doesn’t log out. Somebody goes over and sends an email on their behalf about something embarrassing or whatever the case may be. We want to be sure that if you get up and walk away from your PC, that if your session has been idle for more than 15 minutes, that session times out.
From an operating system perspective, typically what we’ll look for is that you have a screensaver enabled. That screensaver needs to come on within 15 minutes. Once again, understand that this is not just about your workstation. If you’re going to be remoting into your firewalls, your routers, your networking gear, and all of the other equipment that you might have within your environment – those sessions are subject to this as well.
From an assessment perspective, we’re looking at how you’ve configured your firewalls, your routers, your servers, your applications, and if those sessions exceed 15 minutes or more, it should be timed out. This doesn’t necessarily mean that your session has been terminated, it just means you’re going to need to re-authenticate back into it in order to re-access that session.
Account Lockout Duration
Once a user account is locked out after six log-in attempts, that account must remain locked. PCI Requirement 8.1.7 states, “Set lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.” Complying with PCI Requirement 8.1.7 can delay and prevent a malicious individual from attempting to continually guess a password. If your organization decides that reactivation must be requested to unlock the user account, this additional security parameter further validates that the legitimate account owner is requesting reactivation.
To verify compliance with PCI Requirement 8.1.7, an assessor will examine a sample of password parameters to ensure your organization has set the lockout duration to a minimum of 30 minutes.
In PCI Requirement 8.1.6, we talked about how to prevent a brute-force attack and that after six log-in attempts, the account becomes locked. When we look at PCI Requirement 8.1.7, it says that these accounts need to remain locked for at least 30 minutes or until an administrator resets the account. One of the things that we’re going to do as an assessor, for both of these requirements, we’re going to look at the mechanisms by which these controls are enforced. Is that a hard-coded setting? We may look at the source code as part of something you’ve developed within the application. We might ask you to actually fat-finger an account six or seven times to lock it. We’re going to look at how the application resets or opens up that account for authenticating to it again. Understand that when an account has been locked out, it needs to remain locked out for no less than 30 minutes or until an administrator resets that account.
Appropriate Account Lockout Mechanisms
PCI Requirement 8.1.6 states, “Limit repeated access attempts by locking out the user ID after no more than six attempts.” Why is PCI Requirement 8.1.6 so important? Appropriate account lockout mechanisms cut off an attacker’s ability to continuously guess the password.
Without the appropriate account lockout mechanisms in place, an attacker could attempt to guess account passwords until they’ve gained access. Take brute-force cracking, for example. This is a trial and error method which continuously tries every combination of a password. If you guess enough times, the password will be found. Protection from attacks like these are critical for your organization.
Within the industry and the hacking community, there’s something called brute-forcing. A brute-force attempt is where somebody attempts to use an application, sometimes you can do it manually, that can brute-force a password. These applications will submit a username and every combination of password that you can imagine, until such time that the password is just guessed. If you guess enough times, the password will be discovered. As part of this, the PCI DSS requires that to prevent the brute-force attack, after an account has had six failed access attempts, this account gets locked.
When we look at this particular requirement, understand that this is not just your authentication store or your authentication library. It’s also an FTP server, it’s a web server, it’s really any place that an individual might authenticate. If the account has been used six times unsuccessfully, the account must be locked.
Managing Third-Party Access
PCI Requirement 8.1.5 focuses on managing third-party access to your system. In situations where you’ve given user IDs to third parties so they can access, support, or maintain system components through remote access, those accounts must be monitored. PCI Requirement 8.1.5 deems that accounts used by third parties should only be enabled during the time period needed, and then disabled when not in use. When they are in use, the accounts must be monitored.
A common scenario we encounter is organizations who allow third parties to have access into their network 24/7 in case they need to provide support to the system. It’s difficult to monitor that activity 24/7, right? This is where PCI Requirement 8.1.5 tries to provide a solution for managing third-party access by requiring that access only be allowed when it’s needed. The PCI DSS explains, “Enabling access only for the time periods needed, and disabling it as soon as it is no longer needed, helps prevent misuse of these connections. Monitoring of vendor access provides assurance that vendors are accessing only the systems necessary and only during approved time frames.”
Failure of managing third-party access leads to the risk of malicious activity. The PCI DSS states, “Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor’s environment or from a malicious individual who finds and uses this always-available external entry point into your network.” Complying with PCI Requirement 8.1.5 equips your organization to have manageable relationships with third parties who access, support, or maintain system components through remote access.
From time to time, there might be situations where your organization needs to work with a third party in order to help manage your environment. In that situation where you have given them access into your environment and you’ve created an account for them, when these individuals are coming in from remote, we need to manage these accounts. It’s different if you have somebody that’s a third party that resides in your facility, like someone who’s providing some type of staffing authentication versus a vendor that comes in once a month. In these situations, you still need to manage these accounts.
When we look specifically at this requirement, it says that we need to monitor these accounts at all times, so we need to be monitoring these activities. We need to enable these accounts only when they’re going to be in use. If you as an organization have somebody that’s supporting your environment and you say, “Jeff, we leave these accounts on 24 hours a day because we never know when they’re going to need to get into to support these environments.” I realize that might be a struggle for you to monitor these activities. But in those types of situations, you need to find a way to disable these accounts and re-enable them only when they’re necessary, so that these individuals only have access to these environments as well.
I’m going to call out PCI Requirement 8.1.3 here (we’re not going to talk about it fully), but if these individuals that are coming into your environment by authenticating from remote to support your environment, or these third parties that are coming into your environment, or specifically if they are coming into your environment for administrative purposes or coming into your cardholder data environment at all, there is a factor that they use two-factor authentication. There might be some ways that you can maintain control or physical access over that two-factor authentication by providing that for authentication when they need it. Work with your assessor on methods and means for meeting this obligation. Effectively, if an account is not needed at the immediate period of time, that account needs to be disabled.
Just as an interesting point of conversation, I’ve had a lot of opportunities to work with card brands (Visa, Mastercard, JCB, Discover) and I always ask them, “What are the things that permit the bad guys from getting into the environment from a hacker’s perspective?” They said that the number one cause of individuals getting hacked is allowing accounts like these to be left open and the passwords somehow getting compromised. If I can provide you any bit of guidance or recommendation, make sure that this particular control is managed appropriately.
