Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

5/9/2016
07:45 AM
Emma Sutcliffe
Emma Sutcliffe
Commentary
100%
0%

PCI DSS 3.2: Making the Move to MFA

PCI DSS has always required that any untrusted, remote access into the cardholder data environment use multi-factor authentication. Now version 3.2 takes it one step further.

After more than 10 years in existence, the PCI Data Security Standard (PCI DSS) is globally recognized and accepted as a mature industry standard. It’s most recent iteration -- PCI DSS version 3.2 -- focuses on confirming that security controls are in place and operating effectively, and that processes are followed throughout the year and not just during the annual validation. PCI DSS 3.2 aims to help organizations focus attention on critical controls, make improvements that will help mitigate current points of attack, and evaluate opportunities for devaluing card data.

Multi-factor authentication – or MFA -- is one of these critical controls for defending against the myriad of threats to account data. One of the most significant changes in PCI DSS 3.2 is the expansion of PCI DSS Requirement 8.3, which requires the use of multi-factor authentication for administrators accessing the cardholder data environment.

Compromise after compromise show that whatever method a hacker uses to get in to a company’s network, their goal is to find any device on which they can gain administrative rights. Once they have that, they can move throughout the network, gaining administrative rights on more and more machines until they find the cardholder data. The recent 2016 Verizon Data Breach Investigation Report notes that breaches took advantage of static, single-factor authentication, with attackers working even harder to compromise valid credentials to access environments.

Multi-factor authentication (MFA) provides additional assurance that the individual attempting to gain access is who they claim to be.

Going one step further

The PCI DSS has always required that any untrusted, remote access into the cardholder data environment use multi-factor authentication. With version 3.2 we’re taking it one step further to help organizations protect against both internal and external actors. With PCI DSS 3.2, MFA is also required for personnel with non-console administrative access into the cardholder data environment – even where that access originates from within an organization’s trusted network.

Required use of MFA will encourage companies to implement strong access control measures so that authorized individuals with network and computer administrative access can be monitored and traced. Examples of factors include something you know, such as a password or passphrase; something you have, such as a hardware token or smart card; or something you are, such as a biometric.

Organizations have until have until January 31, 2018 to deploy MFA. As of February 1, 2018 it will be a requirement of PCI DSS, not simply a recommended “best practice.”

Making the Move to MFA

It’s critical for organizations to understand that this requirement applies to all non-console administrative access into the cardholder data environment, even from within a company’s own network. The requirement applies to any administrator, third party or internal individuals who have the ability to change systems and other credentials within that network to potentially compromise the security of the environment. For example, depending on the particular operating system and organizational structure, it could apply to functions or titles such as “superuser,” “root,” “administrator,” “admin” “sysadmin” or “supervisor-state.”

This requirement is intended for authentication of personnel – it does not impact machine authentication where one system is communicating with another – nor will it impact administrators accessing directly from the console.

As a first step, organizations should review how they are currently managing authentication into their cardholder data environment, and review the current administrator roles and access methods to identify where changes to authentication may likely be impacted by this new requirement.

MFA can be performed either at the network level or system level. One common approach is to consolidate administration points into the cardholder data environment (CDE), for example via a jump server. Consolidation offers several benefits including fewer (or just one) points to manage the multi-factor authentication and centralized management and monitoring of all administrative access into the CDE.

The incremental revisions in 3.2 provide an opportunity to address a few critical security risks, starting with administrative access into the cardholder data environment, and evaluate approaches for how best to accept payments securely in the future. Where organizations are able to devalue card data with technologies like point-to-point encryption and tokenization, PCI DSS efforts can be more focused, compliance reporting more concentrated and most importantly, areas where cardholder data must still be used can be better monitored and protected.

Related Content:

  1. PCI DSS 3.2: 3 Things You Need to Know
  2. 7 In 10 Businesses Struggle To Sustain PCI Compliance
  3. Silicon & Artificial Intelligence: The Foundation of Next Gen Data Security

As director of data security standards, Emma Sutcliffe oversees a number of PCI security standards, including the PCI DSS and PA-DSS. Ms. Sutcliffe chairs PCI SSC's Technical Working Group (TWG) and the Tokenization Working Group, where she works closely with the payment ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
5/12/2016 | 8:44:32 AM
Re: PCI-DSS
@theb0x: One could argue that, if a situation is handled right, where an organization suffers a very public, humiliating, and costly fall, that organization may well be the most trustworthy in the future because they will become so dedicated to making sure that the problem never happens again.

At least, until a new group of faces lines the C-suite and/or the board...
theb0x
50%
50%
theb0x,
User Rank: Ninja
5/11/2016 | 10:11:57 AM
Re: PCI-DSS
For an Enterprise not to implement MFA into their CDE would be a very poor choice. It's not just the consumers' data at risk here. It's the Enterprise's overall reputation at risk. What consumer in their right mind would want to conduct business with a company that neglects to take every measure and practice possible to protect this sensitive information? In the event of a data breach, after investigation of the incident it will be publically known that the Company somewhere failed to properly protect it. How does such a company regain confidence with their consumers to conduct business with them again? Can they really be trusted when the 'glitch' has been fixed?
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
5/9/2016 | 9:19:36 AM
PCI-DSS
On the one hand, it's kind of sad that we need PCI-DSS to tell us this and -- effectively -- make us do this (PCI-DSS compliance is required by state law in a couple of states).

On the other hand, the arrogance shown by executives (lookin' at you, former TJX CIO from about ten years ago) in declining to implement these standards has harmed consumers and harmed industry.

I'm glad to see that MFA is now required for accessing these particular data.
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3154
PUBLISHED: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
CVE-2019-17190
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
CVE-2014-8161
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
CVE-2014-9481
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
CVE-2015-0241
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...