The PCI DSS 3.2 compliance standards released today include important requirements that merchants and banks must...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
implement in strong encryption and multifactor authentication, as well as new timetables for those changes.
PCI DSS version 3.1 will expire on Oct. 31, 2016. However, all new requirements will be considered best practices until Feb. 1, 2018, in order to allow organizations to prepare to implement the changes detailed in PCI DSS 3.2.
Now in its 10th year, the PCI Security Standards Council decided its PCI DSS, or Payment Card Industry Data Security Standard, is mature enough to move away from major changes to the current requirements. However, Troy Leach, CTO for the PCI Security Council, noted that the PCI DSS 3.2 does include at least one "big ask" from a business perspective.
"Last year, in April, we published version 3.1. And in that standard, we did something that was pretty significant from an infrastructure perspective, which is we no longer used SSL as an example of good, strong cryptography. We published material recognizing that while it is 20-year-old technology and people should be migrating away from SSL and early versions of TLS, that we recognize that it may be an easy ask for a technology change, but a very difficult business ask in that migration, especially as people are investing in other technologies," Leach told SearchSecurity. "We're encouraging migrating to point-to-point encryption for payments; we're encouraging migration to EMV terminals. There's all these other investments, so the timing of this change was pretty significant."
While merchants and banks now have a longer timeframe in which to improve encryption, PCI DSS 3.2 does include an appendix template for businesses to prove there is a strategy in place for this migration and the work is being done.
Improving documentation and testing
This appendix is not the only change in PCI DSS 3.2 that will require improved documentation and testing for merchants.
New requirements 10.8 and 10.8.1 outline that service providers need to detect and report on failures of critical security control systems.
Leach said "without formal processes to detect and alert to critical security control failures as soon as possible, the window of time grows that allows attackers to identify a way to compromise the systems and steal sensitive data from the cardholder data environment [CDE]."
New requirement 22.214.171.124 states that service providers need to perform penetration testing on segmentation controls every six months.
"In all organizations, if you're saying your cardholder data environment -- for compliance reasons or just good security hygiene -- has a smaller footprint, we highly encourage that, but we ask all organizations to do penetration testing at least annually, and after significant changes, to verify you've actually corralled your cardholder data into a smaller, confined space," Leach said. "For service providers, we've upped that frequency to twice a year, so every six months and after significant changes."
PCI DSS 3.2 also includes new requirements 12.11 and 12.11.1 for service providers to perform quarterly reviews of the personnel to make sure those employees responsible for protecting cardholder data are following the security procedures in place. Leach said this shouldn't be a big ask if businesses are PCI-compliant, but there should be more "demonstration that these procedures and processes are in place throughout the year."
One of the bigger requirements, according to Leach, is new requirement 12.4.1, which aims to establish responsibilities for protecting cardholder data from the executive management of service providers.
"Organizations where executive management [is] involved in strategic development of payment card security will be able to respond to changes and ask appropriate questions to determine the effectiveness of the program and influence strategic priorities," Leach said. "Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization, but the executive visibility is critical for service providers where protecting cardholder data is central to their business."
Troy LeachCTO, PCI Security Standards Council
James Devoy, CSO and global head of risk and assurance for Sysnet Global Solutions, based in Dublin, told SearchSecurity "it seems clear from the adoption of this requirement into the standard that the PCI Council felt that merchants were 'falling out' of compliance after making changes to their environments -- I assume the industry has seen compromises linked to this type of compliance gap -- and so felt the need to spell it out in the DSS."
Lastly, PCI DSS 3.2 requires new documentation surrounding the cryptographic architecture of a business.
"Everyone has moved to and relies on encryption, but it's important to document what you're using, because people change jobs," Leach said. "There's new personnel that comes in, and there just needs to be a well-documented structure to the type of encryption you're using so that you're aware if you're using SHA-1 -- which is becoming an issue in the payment industry -- if you're using SSL or TLS [or] if you're using more deprecated versions of algorithms. All these types of things should be documented so that there can be good forecasting by an organization, so it's not a standards body informing you that a 20-year-old cryptographic algorithm is being end-of-lifed."
PCI DSS 3.2 also includes a significant change in terms of multifactor authentication (MFA). The standard has required MFA for all remote access since version 1.0, but the new change is to require MFA for admin-level access to CDE, even within a local secure network.
Leach said this change was made because, although the majority of connections continue to be remote, breach investigations and conversations that the council had showed security could be better in local networks.
"What we realized is that just because of how distributed payment networks have become, organizations were doing single-factor administrative access in their own networks, and from that single-factor, being able to gain access to the card data environment," Leach said. "It was a trusted network where there were a series of controls that should be in place, but the reality was that there's just not enough administrative oversight in the general network of an organization that this control made sense now."
Rob Sadowski, director of market insight for RSA, based in Bedford, Mass., said, "Identity is the most consequential attack vector, and we see compromised credentials and unauthorized privileged access occurring in almost every payment data compromise."
"Multifactor authentication has long been a best practice for remote and administrative access, so hopefully, this requirement will compel holdouts to action," Sadowski said. "There are now authentication solutions on the market that address long-standing concerns about usability that can help organizations achieve both end-user convenience and security in implementing this essential capability."
Timing and planning
Leach said the aim behind giving organizations an 18 to 20-month window, where the changes are considered best practices before making them requirements, allows them more time to evaluate, make the necessary resource changes and implement changes. PCI DSS changes have "quite a bit of alignment between our standards and the expectations of the industry," Leach said. "We map to several structures, like the NIST Cybersecurity Framework and others where there's very similar intent and purpose."
Ben Jepson, director for the U.K.-based NCC Group, said PCI DSS is a mature standard, and compares well to other information security standards and security controls sets.
"In fact, the Security Standards Council's lifecycle for updating the ecosystem of PCI standards is much more frequent than the likes of ISO 27001 or the ISF Standard of Good Practice," Jepson said. "Furthermore, there is a lot of overlap of the security controls defined within the PCI DSS with these other standards. Historically, the Security Standards Council has been comparably quick to react by providing updates to the PCI DSS and deadlines for depreciating unsecure technologies to mitigate against widespread cardholder data compromises."
Devoy said he believes service providers may have a trickier time with their seven new requirements, and "may well need the full 21 months to implement and meet the new requirements they are subject to."
"Technically, there is nothing new in their specific requirements, but fulfillment of all of them does rely on an organization having achieved a certain level of maturity. The changes are about making sure service providers -- whose secure and compliant services may be relied upon by many hundreds, or even thousands, of other entities -- have fully embedded PCI DSS into their operational activities, that they update their controls and compliance activities as changes are made, and are proactive in their response to failures of critical security controls," Devoy said. "It may take a while to achieve, but this greater emphasis on accountability and validation can only serve to increase security assurance across the industry, reduce the incidence of compromise and decrease fraud."
Minimizing data and securing the environment
Brian NeSmith, CEO and co-founder of Arctic Wolf Networks Inc., based in Sunnyvale, Calif., said the approach of the PCI DSS may not actually improve security.
"The expected new PCI standards fall far short of actually improving the security of cardholder data. History has proven that this rearview-mirror approach to security -- focusing on protecting the assets alone -- does not meaningfully improve security," NeSmith said. "By the time you see it, it's too late; it's already happened. What the industry really needs is to improve its threat detection and response capabilities in order to catch the bad guys before the damage is done."
Leach noted that the real aim of PCI DSS is to minimize the data footprint that could be compromised.
"My biggest focus is not on the PCI requirements, but actually on, 'How do we find ways to devalue data? How do we find ways to minimize that footprint first?'" Leach said. "Because if you have a smaller, more concise area that you need to protect, then any amount of security controls that you apply to that smaller environment are going to be more successful."
Leach said the PCI Council promotes the use of EMV, point-to-point encryption, tokenization and other technologies, "but our focus is, all these things combined is really what we see as our endgame."
"So many times, as security professionals, we get fixated that we just need to throw more security controls, more firewalls [and] make the walls to the castle higher. But the challenge we have is that criminals are building ladders faster and taller than we can build the walls," Leach said. "And so, if we can find ways to disincentivize criminals from trying to steal cardholder data and repurpose it, we really are improving the overall payment security ecosystem."
How is the NIST Cybersecurity Framework being received?