Identification and Authentication Policies and Procedures

PCI Requirement 8 focuses on two actions: identify and authenticate. These actions are critical to protecting your system. PCI Requirement 8 states, “Identify and authenticate access to system components.” In these videos, we’ve discussed authentication mechanisms, user IDs, secure passwords, inactive user IDs, cryptography, administrative access, multi-factor authentication, and more. But as we’ve learned with every PCI DSS requirement, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 8.8.

PCI Requirement 8.8 states, “Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.” PCI Requirement 8.8 isn’t saying that your organization only needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be implementing what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, becoming familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are. If PCI Requirement 8.8 is not met, your systems could be left vulnerable.

As with every other requirement we’ve talked about thus far, PCI Requirement 8 has the capstone. You’re going to be maintaining your policies, procedures, and standards. Anyone subject to them needs to be fully educated about the merits of those policies and procedures. Your assessor is going to be looking for those policies and procedures, reading them, and then talking to the staff about how you’ve implemented your policies, procedures in your environment. Understand that policies and procedures need to be in use, not just documented.

Database Access

PCI Requirement 8.7 requires that you restrict all access to any database containing cardholder data and access is restricted as follows:

• All user access to, user queries of, and user actions on databases are through programmatic methods.
• Only database administrators have the ability to directly access or query databases.
• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

PCI Requirement 8.7’s intent is to ensure that only database administrators have the ability to access or query databases. Additionally, user authentication brings accountability to those accessing databases. The PCI DSS further explains, “Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only, rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).”

To verify that you restrict all access to any database containing cardholder data, an assessor will review database and application configuration and control settings.

If you have databases within your environment and these databases are connecting to applications, or applications are connecting to databases to query information, we must ensure that the username and password that the databases use can never be used by individuals. As we talked about before, individuals should have their own usernames and passwords that they use to access your environment.

Specific to PCI Requirement 8.7, only applications can be used in application accounts for accessing these databases. We want to be sure that only database administrators have the ability to run a direct query. We also want to make sure that your databases authenticate users before they’re able to run any type of query.

Lastly, from an assessment perspective, we’re going to look at what accounts are actually being used and how they’re being used. Chances are, your assessors are going to want to dig through your log servers to see when these accounts are being used. We’re also going to look to see if you’ve had any interactive log-in with the types of accounts that are associated with the application.

Once again, the application IDs that are associated with connecting to the database should never be used to authenticate into the database to run queries.

Service Providers with Remote Access to Customer Premises Must Use Unique Authentication Credential for Each Customer

Multiple Customers, Multiple Authentication Credentials

The PCI DSS has several requirements that are specific to service providers, including PCI Requirement 8.5.1, which states, “Service providers with remote access to customer premises must use a unique authentication credential for each customer.” PCI Requirement 8.5.1 prevents the compromise of multiple customers through the use of a single set of authentication credentials; if a malicious individual compromises an account, they could compromise more if only one authentication credential is used.

The PCI DSS also notes, “This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

The PCI DSS has several requirements that are specific to service providers. If your organization is a service provider, you need to use unique authentication credentials for each of your customers. This means that if you have five clients, you use unique authentication credentials for each one. The purpose and intent behind this is if Hacker Joe is able to compromise Account 1, we want to prevent him from compromising Accounts 2, 3, 4, and 5. To limit this type of vulnerability, it’s required that you use unique authentication credentials for each customer.

From an assessment perspective, this entails examining your policies and procedures, and interviewing staff so that we understand that they understand what’s required about using unique authentication credentials.

Do Not Use Group, Shared, or Generic Authentication Methods

PCI Requirement 8.5 cautions, “Do not use group, shared, or generic IDs, passwords, or other authentication methods.” It also outlines the following requirements:

• Generic user IDs are disabled or removed.
• Shared user IDs do not exist for system administration and other critical functions.
• Shared and generic user IDs are not used to administer any system components.

Group, shared, or generic authentication methods cause a loss of accountability for the actions that have taken place within your systems and make it impossible to determine who has taken which actions. You should not use group, shared, or generic authentication methods for administrative purposes or any accounts that have access to sensitive cardholder data.

To verify compliance with PCI Requirement 8.5, a sample of user IDs should be examined to ensure your organization’s configurations are set up so that you do not use group, shared, or generic IDs, passwords, or other authentication methods. Policies and procedures will also be examined, along with staff interviews.

We started out in PCI Requirement 8.1, which says everyone needs their own unique username and password. Now we come down to PCI Requirement 8.5 that is kind of married to that. It says that we shouldn’t be using any group, shared, or generic IDs. You should not use these for administrative purposes or any accounts or service that has access to sensitive cardholder data.

One area where organizations get into trouble is with the use of root. There’s ways you can address this so that we can recreate the accountability that’s lost when more than one individual uses an account. If you have a Linux or Unix mainframe environment, when there is a root account being used, what I would recommend is using sudo to address the accountability aspect of these accounts.

From an assessment perspective, we’ll be interviewing administrative staff and talking about how to manage generic passwords. What do you do when your manager comes to you and says, “Create an account for this group of people.” We’ll also be looking at your authentication store to try and identify if you have generic accounts.

Understand that system accounts are not necessarily the same thing as a generic account. A system account is never used by an individual. These accounts are typically used for applications to run or for systems to operate and perform certain tasks. You should never have your staff logging onto these system accounts.

Understand that in the assessment process, we’re going to be asking for a list of all your authentication directories, we’re going to look at all places where you’re authenticating, all of your applications, and look to make sure you’re not sharing or using generic user accounts.