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 