Mention the term multifactor authentication (MFA), to a typical system or application administrator, and you will encounter a wide range of responses, from a look of complete confusion to those sporting a barely contained, albeit outright scowl.
Such individuals routinely log into dozens or even hundreds of computer and network systems daily to perform their administrative tasks. The use of MFA requires them to complete additional steps in the authentication process, which can often be perceived as unnecessarily time consuming and redundant. The use of MFA, however, provides an additional layer of defense against brute force password attacks, and adds additional protections to help thwart concerted social engineering attempts and other types of cybersecurity attacks.
In February 2017, the Payment Card Industry Security Standards Council (PCI SSC) issued an information supplement on multi-factor authentication. MFA is an access control method where access is only granted after a user is able to successfully present separate pieces of evidence to an authentication mechanism. This additional authentication criteria are often described as:
- Knowledge - something you know. This could be a password or a passphrase.
- Possession - something you have. This includes a smart card, hardware token or software token.
- Inherence - something you are. This could be a fingerprint, digitally scanned retina image, or some other type of biometric attribute.
The specific items from these bullet points are only a limited set of examples. If you use at least two of them, you will meet the PCI MFA requirements.
The difference between MFA and two-factor authentication (2FA) is that 2FA uses two of the above. With MFA, any two of the three items noted above can be used.
Everything old is new again
MFA has been around for a long time. The now ubiquitous SecurID tokens first appeared almost 20 years ago.
It’s now 2017 and the combination of username and password is simply not enough to secure an email account, let alone administrative access to the PCI cardholder data environment (CDE). You don’t have to be a PCI QSA or even a CISSP to know that the practice of only using passwords as the first line of defense is woefully insufficient.
President Barack Obama wrote in The Wall Street Journal last year that the US Government is doing more to help empower Americans to protect themselves online. An awareness campaign was in place to raise awareness of cyberthreats and encourage more Americans to move beyond only using passwords for authentication.
This is why in their update to PCI DSS v3.2, the PCI Security Standards Council (SSC) added a sub-requirement to requirement 8.3. This new requirement mandates that MFA be used for all non-console access into the CDE for personnel with administrative access.
PCI DSS v3.2 came out in April 2016 and this requirement is a best practice until January 31, 2018, after which it becomes a requirement. The PCI SSC gave firms almost 2 years to put MFA into place. But given the amount of time it takes to design, implement and fully test a MFA solution; if you haven’t got MFA working now, expect to have your staff burn the midnight oil in the coming months to get it correctly implemented.
The username/password combination is akin to putting all of one’s authentication eggs in a single basket. The goal of MFA is to add an additional layer of defending privileged account access. Note that MFA is not a panacea. Poorly implemented MFA, or users that don’t protect or may even share their tokens will obviate any added benefit. But with that, MFA is one of the most effective methods to reduce the attack surface area and increase the security of the CDE.
So why is MFA suddenly on the PCI SSC radar? Our friend Jeff Hall, AKA The PCI Guru, writes that what the PCI DSS is trying to prevent with the requirement for MFA, is spear phishing attacks against system administrators, that were the root cause of the Target, Home Depot and other breaches. When people with administrative privileges are breached -it is game over. Administrative accounts are traditionally fully privileged and provide access to operating system and application features that are never meant to be accessible to the average user. The requirement to implement MFA should help prevent that from happening.
Hall also notes that while the PCI SSC explicitly calls out system administrators, it’s not just administrators that you need to worry about. Anyone that has access to bulk cardholder data inside the CDE should also be using MFA to gain access.
Doing MFA the PCI way
MFA is now the successor to what used to be referred to in the previous versions of the PCI DSS as two-factor authentication.
The new PCI DSS requirements for the implementation of MFA is as follows:
8.3.1 - Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
It’s important to note that 8.3 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. Our previous piece Network Segmentation and PCI Compliance details that in depth.
8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.
This requirement applies to all personnel; including general users, administrators, and vendors (for support or maintenance) with remote access to the network, and especially where that remote access could lead to access to the CDE.
If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the CDE, MFA for remote access to that network would not be required. However, MFA is required for any remote access to networks with access to the CDE, and is recommended as a best practice for all remote access to the entity’s networks.
In prior iterations of the PCI DSS, additional authentication factors were only required when remotely accessing systems within the CDE, now however, even local administrative access is now also required to do so
Internal CDE access is remote access according to 8.3
Suppose you are in a New York office and use Microsoft Terminal Services Remote Desktop Protocol (RDP) to the access the CDE in your Los Angeles office, using the internal corporate network. Most people would think such an approach would not need MFA. But according to PCI 8.3, it does.
Just because the traffic is on the internal network, 8.3 mandates that anytime you are accessing the CDE from any place besides your local console, you must use MFA.
What that means is that even if you use RDP, a jump box, or the like, and even though it is all considered to be internal network access with not even a single packet going out onto a public network, MFA is still, to the chagrin of many, required for PCI DSS compliance.
MFA growing pains
One area of particular pain with respect to implementing MFA involves administrative access to mid-range and mainframe systems. Traditionally such access has been facilitated via interactive terminal sessions, and in some such environments dozens or even hundreds of system administrators and/or developers require privileged access per day.
This new PCI DSS requirement now implies that all such access must leverage the use of MFA. Terminal emulation software applications have not traditionally supported the use of digital certificates, hardware and/or software tokens, or other MFA attributes. Implementing MFA in such environments will incur (often substantial) additional costs to existing access schemes, and administrative overhead associated with the management, distribution, revocation, and end-of-life of the multi-factor attributes. For example, digital certificates are typically issued with an annual or multi-annual expiration date. There will be a need for someone to facilitate those additional administrative provisions to ensure uninterrupted system access.
Putting MFA into action
The following are some high-level steps to put an MFA plan into place:
- A well-implemented MFA solution is likely very close to meeting PCI DSS requirements for MFA. But with that, work with your QSA (Qualified Security Assessor) and/or ISA (Internal Security Assessor) and have them review it for DSS compliance.
- Create MFA policy, process and procedure documentation that details exactly what solutions are acceptable corporate technology standards for such, but also ensures that MFA resources are properly provisioned and managed.
- Create MFA process flows and ensure you are covering all data flows.
- Consider standardization of MFA solutions to help reduce administrative overhead and personnel training requirements.
- Consider implementing penetration testing to validate truly effective MFA implementations. Many firms have deployed a working MFA solution only to find that a user can still access the CDE before the secondary authentication process takes place.
- Don’t forget about the help desk – MFA requires users and the users may have problems. When that occurs, they’ll call the help desk. To help them, the help desk must be trained on the MFA solution, and how to properly assist with legitimate access problems.
Conclusions
MFA provides additional protections in helping to further secure remote access, administrative and privileged access to critical systems and datasets. It also helps to thwart brute force password attacks and social engineering attempts.
While MFA is currently considered to be a best practice with respect to the PCI DSS, the deadline for its implementation within a CDE is rapidly approaching. Don’t wait until the last minute to start architecting an effective MFA solution. The sooner that MFA can be implemented, the sooner that organizations can start to reap the benefits and extra protections that it affords.
Palo Alto Networks has a number of resources available for secure PCI compliance, including the whitepaper “PCI Use Case: Simplify PCI Compliance With Network Segmentation.”
About the authors
David Mundhenk, CISSP, QSA, PCIP, is Senior Security Consultant with Herjavec Group. He has extensive experience providing a variety of professional security services to business and government entities.
Ben Rothke CISSP, PCI QSA, is Senior Security Consultant with Nettitude and the author of Computer Security: 20 Things Every Employee Should Know.