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.
Are User Accounts Actively In Use?
PCI Requirement 8.1.4 calls out the need to remove/disable inactive user accounts within 90 days. Sounds pretty straightforward, right? PCI Requirement 8.1.4 is where a lot of organizations tend to struggle. It’s not about if the user has been terminated or left your organization, it’s about if the account has been actively in use. Extended vacations, sabbaticals, maternity leaves, medical leaves – factors like these play into whether or not an account is actively in use. Even with legitimate reasons for not using an account, your organization still needs to remove/disable inactive user accounts within 90 days. If someone is still employed, still active, but just not using an account, then that individual should have never been given access to the account.
Why are inactive accounts harmful to cardholder data? The PCI DSS explains, “Accounts that are not used regularly are often targets of attack since it is less likely that any changes (such as a changed password) will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data.” PCI Requirement 8.1.4 places further protection on cardholder data.
PCI Requirements 8.1.1 through 8.1.3 play large roles in PCI Requirement 8.1.4 compliance. Your organization must give unique user IDs in order to track which users are performing specific actions. You must manage the addition, deletion, and modification of user IDs and credentials so that you know who receives privileged access. You must promptly revoke access for terminated users. Without any of these controls in place, you cannot identify inactive user accounts, so you cannot remove/disable inactive user accounts within 90 days.
We recommend that you have a relationship between your organization’s HR department and IT department. You must have a process in place so that HR notifies IT of any extended leave of absence so that the IT department can manage this control and remove/disable inactive user accounts within 90 days.
In a previous video, we talked about the need to control the move, add, change of accounts. When we get to PCI Requirement 8.1.4, it says that we either need to remove or disable any inactive account that’s been inactive for longer than 90 days.
This is one requirement that most organizations really struggle with. We find that’s because the requirement is not about if the employee has been terminated, it’s about if the account has not been used. If you’ve given permissions for somebody to use an account to access an environment and they have not used that account within 90 days, we expect for that account to either be disabled or removed.
Where we have struggles here is where we have people that go on an extended vacation, a woman on maternity leave, or a multitude of other things that would cause an account to not be used. One of the things that we would recommend you do, from an organizational perspective, is that you have a hook from your HR department into your IT department. When someone is going to take an extended leave of absence or be gone for an extended period of time, HR notifies the IT department so that they can manage this particular control.
Subsequent to that, there are people that are still employed or active but they’re just not using these accounts. Somehow, we have to measure whether or not these accounts have been used. It gets really difficult if you’re using your own homegrown authentication mechanism. Has this account been used? Sometimes, there’s no way to tell. But at the end of the day, if the account has not been used in the last 90 days, it needs to be disabled or removed.
From an assessment perspective, KirkpatrickPrice has a lot of scripts that they will likely provide you, which will pull a lot of this information to automate the audit process for you. It tells us whether or not you have accounts that haven’t been used in the last 90 days.
Protect Cardholder Data from Terminated Users
We’ve all heard a horror story of a terminated employee or someone that has left the company discovering their account was left open or active, giving them access to your network, and malicious access to cardholder data occurred. PCI Requirement 8.1.3 seeks to keep situations like these from happening. PCI Requirement 8.1.3 states, “Immediately revoke access for any terminated users.” Once an employee has been terminated or left your organization, their user credentials and other authentication methods must be immediately revoked. The purpose of PCI Requirement 8.1.3 is to protect cardholder data from terminated users. Even if a terminated user doesn’t have malicious intent, any unnecessary access to cardholder data puts it at risk. This is why you must immediately revoke access for any terminated users.
To verify compliance with PCI Requirement 8.1.3, an assessor will take a sample of users who have been terminated within a specific period of time and review current user access lists to ensure that terminated users’ IDs have been deactivated or deleted from access lists. This review should be of both local and remote access lists.
I’m sure we’ve all heard a story of terminating an employee, and then that individual’s account was left open for some reason and that ex-employee came back into that environment two weeks later and deleted a bunch of data or did something malicious in your environment. The PCI DSS looks to be respective of that. What they’ve done is created this requirement that says if you have a terminated employee, their account needs to be revoked immediately. You could do this one of two ways. You could simply disable the account, or you can actually delete it – the choice is up to you.
But what we’re going to do from an assessment perspective is we’re going to work with your HR department and get a list of accounts or individuals that have been terminated in the last six months, and then we’re going to look at those accounts within your environment. Organizations are pretty good about the active directory, server, or that main authentication library, but understand that you have other applications within your environment that they may or may not have had access to. So, when we look at this particular control, it’s all accounts, not just main authentication accounts. Be respective of that, try to keep an inventory of what particular accounts individuals have had within your organization, and once those individuals have been terminated, you must immediately delete or revoke access to that account, as required by your policies and procedures.
