Making PCI Requirement 8.3 Bulletproof and Simple

Multi-factor authentication (MFA) has become an essential building block of security policy and practice, and likewise has taken on an increasingly important role in regulatory standards such as the PCI-DSS. Specifically, PCI Requirement 8.3 calls out how MFA should be used to secure both the cardholder data environment (CDE) as well as any networks connected to the CDE. And while protecting your most valuable assets with MFA makes good intuitive sense, the details can get a little tricky if you don’t have a flexible way of enforcing policy in your networks. Fortunately, Preempt’s security platform makes it easy to extend MFA to any asset based on almost context you choose. So let’s take a quick look at what PCI requires, and how you can turn a deceptively tricky requirement into a simple, automated process that you never have to think about.

The Basics

First, it is important to understand how the PCI standard defines MFA. PCI defines authentication factors as:

Sponsorships Available

Sponsorships Available

Sponsorships Available

• Something you know (e.g. password)
• Something you have (e.g. device, smart card)
• Something you are (e.g. fingerprint, biometric)

To qualify as MFA, a solution must incorporate at least two of these three types of authentication factors. For example, it is not enough to simply require two passwords.

Next, the two or more factors of authentication must have an independence of mechanism. This means that you can’t use the same device for both factors, such as receiving a 1-time passcode on the same device that you use to enter your password. This makes sense because if the device is compromised by an attacker, it would be trivial to steal the secondary factor of authentication and defeat the purpose of the MFA. However, as long as the MFA solution meets these basic requirements, the PCI standard allows organizations to use virtually any MFA solution or strategy they choose.

Administrative Access to the CDE

Now that we know what constitutes MFA, let’s review what the standard requires. Section 8.3.1 requires MFA to be used for all non-console administrative access into the CDE. In this sense, “non-console” refers to any network-based connection. So unless the administrator is physically connected to system, 8.3.1 will apply.

So there are two things we need to address – how to selectively target administrators, and how to apply the policy to the CDE and its systems. Preempt makes this easy by automatically identifying all of your administrators based on analyzing actual traffic. This can also reveal the presence of stealthy admins who have admin-level privileges but don’t reside in the official Admins groups within Active Directory. Additionally, 8.3.1 does not apply to automated or system accounts, and Preempt makes it easy to specify the policy human administrators only.

Next, we need to target the CDE itself. This can be done at the network level (assuming the CDE is segmented) or individually to specific assets and resources. Preempt can be helpful in both cases, especially given that it provides one of the only ways to extend MFA to virtually any network resource. This can include extending MFA to servers, workstations, legacy applications and a variety of other resources that are typically difficult or impossible to cover with MFA. Also, we need to ensure that policy is enforced regardless of the type of access.

MFA to the Network

Section 8.3.2 introduces broader requirements that apply to all users making remote access to the enterprise network. This applies to both users and administrators, as well as any 3rd parties. Additionally, it applies to the larger enterprise network, not just the CDE. So ,anyone who remotely connects to the network (which is connected to the CDE) will need to complete an MFA challenge before accessing the network. And once again, this makes sense as patient attackers will often attempt to infiltrate the larger enterprise network before targeting the CDE.

Once again, Preempt makes this policy simple, actionable, and auditable. Preempt actions and policies can be triggered based on any context such as the user’s location, network type, device, risk score, behavior, and more. In this case, a simple Preempt policy specifying MFA as an action for any remote connection into the network is all it takes. This will apply to a variety of connection methods such as remote desktop, VPN connections, and more.

And these are just the beginning of how Preempt policies can simplify compliance while making the network more secure. The overriding trait is being able to apply appropriate controls based on your unique context and situational risk. And by being able to apply MFA situationally and to any network asset, it can make it easy to tackle any corner cases that would hard to address with a vanilla MFA deployment. If you would like to learn more about the Preempt Platform and how it can help meet your regulatory requirements, please contact us at [email protected].