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.

Addition, Deletion, and Modification of User IDs

PCI Requirement 8.1.2 states, “Control addition, deletion, and modification of user IDS, credentials, and other identifier objects.” To meet PCI Requirement 8.1.2, there must be a formal program of control and someone within your organization must be responsible for the addition, deletion, and modification of user IDS and other credentials. Think about all of the addition, deletion, and modification that has occurred within your organization in the last year: new hires, terminations, quitting, promotions, or a change in role. You must to ensure that the privileges that an individual has been assigned are the privileges that they actually need, but those privileges do not exceed what is required by their job. Additionally, if an individual is no longer at your organization, that account must be removed.

A test of control for PCI Requirement 8.1.2 is to sample privileged user IDs and general user IDs, review the privileges that they need, and review the privileges that they have been given. This helps assessors ensure that only privileges that are documented with approval have been given to individuals.

Somebody within your organization needs to be formally responsible for managing the addition, deletion, and modification of user accounts within your environment. People are going to be coming into your environment, people are going to be leaving, people are going to be terminated, people are going to be changing roles within your environment, and we want to make sure that the privileges that they’ve been assigned are indeed the privileges that they need. However, we want to make sure that these privileges do not exceed what is required for their job. Or, if the individual is no longer within the company, that those accounts have been formally removed. Specific to PCI Requirement 8.1.2, we’re going to look to make sure that you have a program in place for managing the addition, deletion, and modification of those user accounts.

Furthermore, as part of that addition, and deletion, and modification for PCI Requirement 8.1.2, we’re going to be asking for a list of individuals that have been hired over the last period of time and we’re going to be asking for two types of users: a general, everyday user and individuals who’ve been given some type of privileged account. We’re going to take that user request list (we talked about that back in PCI Requirement 7), and we’re going to look at the permissions for these individuals that have actually been authorized. We’re then going to go look at those systems and make sure that whatever privileges that have been assigned or approved, match those that have been assigned to those individuals.

Never Share User IDs and Passwords

PCI Requirement 8.1 focuses on proper user identification management. If there’s no management of users within your system, you’ve lost accountability for the actions that take place within your systems. It’s hard to determine who has taken which actions if you cannot identify users. The PCI DSS states that having uniquely identified users, instead of using one user ID for several employees, allows organizations to maintain individual responsibility for actions and keep an effective audit trail per employee. This will also help speed up resolution and containment processes when misuse or malicious intent occurs.

We can’t stress enough how important it is to define and implement policies and procedures, but it’s especially important here. Specifically, PCI Requirement 8.1 requires organizations to define and implement policies and procedures to ensure proper user identification management. These policies and procedures should outline the measures defined in the sub-requirements of PCI Requirement 8.1:

• 8.1.1 – Assign all users a unique ID before allowing them to access system components or cardholder data.
• 8.1.2 – Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
• 8.1.3 – Immediately revoke access for any terminated users.
• 8.1.4 – Remove/disable inactive user accounts within 90 days.
• 8.1.5 – Manage IDs used by third parties to access, support, or maintain system components via remote access.
• 8.1.6 – Limit repeated access attempts by locking out the user ID after not more than six attempts.
• 8.1.7 – Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
• 8.1.8 – If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

To verify compliance with PCI Requirement 8.1, an assessor requires your organization to define and implement policies and procedures to ensure proper user identification management. An assessor will review your organization’s policies and procedures to verify that they outline processes to meet PCI Requirements 8.1.1 through 8.1.8. An assessor will also review all of the authentication that you have within your environment to verify that everyone has their own unique username and password and see if there are generic user accounts being used.

In PCI Requirement 8.1, we call out the need for everybody within your environment to have their own unique user ID. You should never share a username. The purpose and the intent behind that is because when you use somebody else’s username and password, we’ve lost accountability for the actions that have taken place. From a logging and forensics perspective, it gets pretty hard to determine who’s done what when we have multiple people using the same account. Specific to this requirement, we look to see that everybody gets their own username and password.

From an assessment perspective, what we’ll typically do is look at all of the authentication that you have within your environment and we’ll look to see that everybody has their own username and password. When looking at your authentication stores, we’re looking to see if there are generic user accounts. There are some situations where it’s hard to get away from this. For example, if you’re in a break/fix environment, you might have to use an administrator account. There are situations where you can assign privileges to individuals within your organization that give them those rights, but where this really gets sticky is when we come across the use of root, and we’ll talk about that later in subsequent requirements.