I have had some interesting meetings with clients lately regarding PCI DSS requirement 8.3.1 and multi-factor authentication (MFA). Requirement 8.3.1 is a best practice until January 31, 2018, but organizations are trying for once to get a jump on it. As a refresher, the requirement states:
“Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.”
But these calls have little to do with discussing MFA. People seem to have that finally down cold. What is becoming painfully obvious and somewhat disturbing from these calls is the realization that a lot of organizations have no defined cardholder data environment (CDE).
Honestly, we have been discussing scope and definition of the CDE for over a decade now. Yet people still are having problems defining their CDE. It makes you start to wonder what these folks have been doing for the last 10 years that they still do not have a defined CDE.
I refer a lot of these clients to the Guidance offered in the PCI DSS as a start to gaining an understanding. That guidance says:
“This requirement is intended to apply to all personnel with administrative access to the CDE. This requirement applies only to personnel with administrative access and only for non-console access to the CDE; it does not apply to application or system accounts performing automated functions.
If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication either when logging onto the CDE network or when logging onto a system.
If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi-factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE.”
What the Council is preventing with 8.3.1 is all of the successful spear phishing attacks against system administrators that were the ultimate root cause of the Target, Home Depot and other breaches. The reason being is that when people with administrative privileges are breached, it is game over. The requiring of MFA should prevent that from happening.
While the Council explicitly calls out administrators, I also explain to my clients that it is not just administrators that you need to worry about. Anyone that has access to bulk data inside the CDE should also be using MFA to gain access. I have seen people in accounting and customer service roles that can access and decrypt stored CHD that can also be at risk to phishing and similar attacks. So it is a good idea that anyone with access to the CDE and bulk data should also be using MFA. The last thing you want to have happen even if the data remains encrypted is to have entire databases be exfiltrated out of your CDE because not everyone with CDE access is using MFA.
But what is absolutely fascinating and scary is that the struggle on these calls continue to surround defining CDE systems.
The first problem I seem to encounter in these meetings revolves around the difference between systems/devices that process/store/transmit cardholder data (aka Category 1 systems/devices) versus those systems/devices that are connected to those Category 1 systems/devices (aka Category 2 systems/devices). The guidance that I give my clients here is that if a Category 2 system has the ability to effect the security of a Category 1 system (i.e., the Category 2 system/device has inbound access to the CDE system(s)/device(s)), then administrators should also use MFA to access those Category 2 systems/devices.
The second most common problem that comes up is network segmentation. Lately the meetings seem to be more and more involving the lack of network segmentation. In those cases the Council’s Guidance column provides your answer. The Guidance states in the second paragraph that:
“If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication either when logging onto the CDE network or when logging onto a system.”
What? As usual, the Council has totally messed up the wording here so it is no wonder people have questions. What the Council should have said in that second paragraph was:
“If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication when logging onto a CDE system.”
The key point in the second paragraph is that there is NO network segmentation, so there is NO separate CDE network. How an administrator would use MFA to logon to a separate network that does not exist is beyond me. The Council really needs to fix that second paragraph.
In situations where the CDE is not explicitly defined, organizations are going to have to implement MFA on a device by device basis, not on a network segment basis. While this can be done, it is a pain in the “you know what” and another reason for segmenting your network to get an explicit CDE.
The final most common issue that comes up with 8.3.1 regards a separate CDE and how to control access to that separate CDE. The most common way to access a CDE, particularly for administrators, is through separate out of band (OOB) administrative systems (there should always be more than just one for redundancy) also referred to as “jump boxes”.
These OOB will have two network interface cards (NIC) for connecting to the CDE network segment and connecting to a network outside of the CDE. The external facing NIC connects to a firewall to manage and monitor the network segmentation. This is because there are typically (or should be) many, many fewer ports required to be open from the OOB to the firewall than from the OOB into the CDE. Access control to the OOB is typically managed through Active Directory, RADIUS or some other directory system but I have seen it managed on the OOB but I would not recommend that practice.
The OOB also needs to be fully instrumented meaning that every keyboard entry and mouse click is recorded. All of that is sent to a separate logging system so that in the event that an issue occurs, the actions of the users of the OOB can be reviewed and a determination made as to how to correct the issue.
The next most common way organizations are controlling access to the CDE is through a virtual desktop (VDI) type of solution because they already have that technology and want to use it to connect to their CDE. The belief being that this will reduce their scope to only the VDIs that connect to the CDE. But to their chagrin, they quickly find out that it does not reduce scope like they think.
The first question about using VDI regards scope as in, what exactly is in scope if we implement VDI? While the VDI is obviously in scope, I get a lot of questions and arguments regarding what in addition to the VDI is also in scope. The Council’s previous pronouncements regarding virtualization make it clear that the virtualization solution such as Citrix or VMware is definitely in-scope in addition to the VDI.
But also in-scope are the devices that access the OOB/VDI particularly if they can be used to view or enter sensitive authentication data (SAD) or cardholder data (CHD). This is because even with OOB/VDI, these secondary devices still can have the SAD/CHD in their memory that could be accessed by malware. That does not mean that the full PCI DSS requirements need to be applied to these secondary devices nor do they necessarily need to be in a separate network segment. But it does mean that appropriate controls need to be applied to protect these secondary devices from the risks they present to SAD/CHD.
I have a lot of clients that try and get these secondary devices out of scope by using virtual keyboards on the OOB/VDI. The thinking being that if the keyboard is not used then the secondary device cannot be in-scope. However, there is still a mouse being used to drive the virtual keyboard and that still means the secondary device is in-scope. That is because the mouse clicks can be recorded by malware and the data retrieved. The only sure way I have seen secondary devices put out of scope is when an encrypted keypad such as a MagTek DynaPro or IDTECH M100 are used for data entry of SAD/CHD.
The second question I get typical revolves around do the administrators use MFA before or after logging on to the OOB/VDI solution? Either method will meet the requirement, but I would think that implementing MFA as part of the OOB/VDI logon process (i.e., before) is going to be much easier to implement than implementing it afterward when you would have to implement it for each system/device in the CDE.
Hopefully we now all understand 8.3.1
PCI Guru 
I have a question regarding implementation of a jump box to meet 8.3.1. We are looking to implement a jump box in which all users would be required to use MFA before being allowed to connect to the CDE. This solution would require the firewall to be configured to point administration ports such as SSH to the jump box. However we have “Connected to” systems which access the CDE using SSH for system to system purposes, the firewall would need to be configured to allow these systems to bypass the jump box. What controls would you expect on these systems to prevent interactive user access? I would assume if they’re not controlled an intruder could use these machines to bypass the jump box/MFA and this would not meet 8.3.1. Note: These systems are in scope for PCI controls.
Keen to hear your thoughts as I’ve heard different opinions from QSA’s
Usually, the jump box is the endpoint for all SSH and other secure end user connectivity between the CDE and non-CDE. So you would have some other secure connectivity between end users outside the CDE and the jump box such as RDP, SSH, TLS or similar depending on what the jump box is running or how it is implemented (i.e., Citrix, VMware, etc.).
For system-to-system connectivity, you want to configure your firewall rules such that the port(s)/service(s) needed are restricted by explicit, static IP addresses for the endpoints versus IP ranges (i.e., x.x.x.*) or, heaven forbid, ANY. I know that might be a pain, but it’s the only way to ensure you have locked down the CDE.
There are times though such as with Active Directory where an IP range would be used in the firewall rule pointing to explicit domain controllers, but those should be the exception, not the rule.
I have a quick question, from what I’ve read on the PCI scoping guideline and PCI DSS 3.2, and also per reading your post, I understand that CDE is only Category 1 devices (process, store, transmit CHD), then there are Category 2 (connected-to) and then there are out of scope system. with that being said, then REQ 8.3.1 requires MFA to access the CDE (only to access Category 1 devices), am I right?
Some people tend to confuse CDE with “category 2/Connected to” system.
8.3.1 requires ALL users to use MFA for non-console access to devices in the cardholder data environment (CDE).
Where most organizations are getting this wrong is with the remote access MFA requirement. They think that once one MFA is done for remote access, everything is good. That is not true. Once remote access has been obtained, the user accessing the CDE must use MFA again. While you can use the same MFA solution, you need to use different tokens for the remote access and the CDE access.
Not sure how people are confusing CDE with Category 2 unless you are not defining the CDE.
Thanks. I don’t know either how people confuse CDE with Category 2.
I read some of your article and PCI as well regarding this and yes, I agree, one thing is MFA for general remote access and another for administrative access to the CDE. We actually implemented MFA for the CDE using a jump box, the only way to connect to the CDE is connecting to the jump box first using MFA, after that you can administer the servers in the CDE.
Thanks
Another quick question, are the Active Directory considered part of the “CDE”, or are these “security services” ( Active Directory) need to go with Multi Factor authentication to connect to it?
They are NOT necessarily part of the CDE (unless you put an AD server in the CDE), but they are critical to the security of anything in the CDE so they need to have MFA on them. Most organizations put their AD servers in a more secure part of their Category 2 or “Shared Services” zone.
Thanks.
It may make sense to have extra security for the active directory as a best practice. But is it required by PCI? What I understand accordingto the requirement is that acces to the CDE must use MFA, and the pci scoping guide differenciate CDE category 1 from category 2( connect to & security systems), hence Active directory fall under Category 2.
If you prefer to not properly secure one of the keys to securing your network, then that is the risk you assume.
Is there any compensating control for req. 8.3.1.
A client has raised a PO for the vendor and are expected to implement 8.3.1 by the end of Q2 2018.
On what basis that client can be certified before the implementation of 8.3.1.
While the Council says that ANY requirement can have a compensating control, in practice it does not work that way. 8.3.1 falls into this bucket because, when you think about it, there are no set of controls that can compensate for a lack of MFA.
What is anybody doing for MFA for Windows UNC and PSExec connections?
As far as I am aware, there is not much one can do for MFA for these specific services other than dong MFA at the time the user authenticates to a Windows domain. And if you think about it, doing MFA when you authenticate to a domain defeats the purpose of the MFA requirement because if you MFA to the domain, you do not stop the attacks on administrator access to the CDE.
In our organization we allow remote administration of CDE systems from personal devices that are running a Citrix Receiver through a netscaler, thus allowing access to a jump server in our Cat 2 environment. The netscaler also performs 2FA at the time of logon. From the jump server the administrator may log into Cat 1 systems to perform remote administration. It should be noted that a firewall controls access from Cat1 Cat 2.
When developing this solution we used the Open Scoping Toolkit as guidance, which considered the Admin Workstation to be out of scope. The PCI Scope Guidance now considers the Admin Workstation, which in this solution would be our personal devices, to be in scope for PCI and must have all necessary controls in place; does this mean that we would now have to use Corporate Owned Devices as that seems like the only reasonable approach to ensure all PCI Controls are met. Or does the use of Citrix technologies reduce the risk to an acceptable level.
This is going to depend on your QSA and acquiring bank and their willingness to accept your logic. Worst case you have to do a compensating control worksheet to describe why it exceeds the requirements.
So, are you saying that the local device on which the VDI is running is considered a secondary (category 2) device? Couldn’t the argument be made that since PAN is entered into the keyboard (or by mouse click) that this is actually CDE (category 1)? Assuming we make this device a Category 2, is that why it would not need to be segmented? Your comment “That does not mean that the full PCI DSS requirements need to be applied to these secondary devices nor do they necessarily need to be in a separate network segment” has left me wondering. How would this be any different from the SAQ-CVT requirement that the connection be “via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems)”? This statement seems to clearly point to segmentation.
You are correct that it is category 1, but what is the actual risk? Because in the end, you are saying that nothing can be trusted. This is where an organization’s risk assessment and other security practices need to come into play and be considered. That said, segmentation can be in the use of HTTPS or IPSec as the Council has stated that secure communications are a form of segmentation.
Based on the Guidance for PCI DSS Scoping and Network Segmentation, we are struggling to locate the Council recommendation for “outbound” from the CDE to other devices and what the scoping classification is for this.
Your thoughts? Do you know of any links to their recommendations on this?
At the Community Meeting in Vegas last fall, they stated that connected to devices with only outbound connections would not have the same risk as devices that have inbound connections. They left it to the rest of us to determine the risk presented and then determine the necessary controls to minimize those risks.