Getting Ready For 8.3.1

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


9 Responses to “Getting Ready For 8.3.1”

  1. 1 Mitch
    July 24, 2017 at 3:38 PM

    What is anybody doing for MFA for Windows UNC and PSExec connections?

    • July 29, 2017 at 8:04 AM

      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.

  2. 3 GingaNinja
    June 19, 2017 at 1:44 PM

    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.

    • June 22, 2017 at 11:50 AM

      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.

  3. 5 Yoshi
    March 15, 2017 at 7:26 PM

    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.

    • March 17, 2017 at 10:57 AM

      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.

  4. 7 Cintolo, Tammy
    January 16, 2017 at 1:44 PM

    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?

    • January 25, 2017 at 6:06 AM

      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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


January 2017
« Dec   Feb »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,862 other followers

%d bloggers like this: