Filter by Category

30 Days to PCI DSS 3.2: Identifying This Version's Changes

pci dss 3.2 changes

Chances are, you’ve already heard about PCI DSS 3.2. The update to the Data Security Standard was introduced in April 2016, and it’s been considered best practice in the industry since the retirement of 3.1 in October 2016. However, 3.2 is not currently “enforceable” during audits. In fact, there are many organizations who still operate under PCI DSS 3.1 requirements—and many more who aren’t compliant at all.

Those aligned with PCI DSS 3.1 are considered fully PCI compliant, but only for the next 30 days. For those who aren’t aware: the deadline for 3.2 compliance, rendering its changes mandatory for all affected organizations, is January 31, 2018.

Where do you stand with PCI compliance? If your company follows version 3.1 or isn’t compliant with all PCI DSS requirements that relate to it, now is the time to ensure you’ll be 100% PCI DSS 3.2 compliant when February 1 arrives.

Several 3.2 requirements will be enforceable next month. Most are mandatory for everyone. To help you identify the changes in this version and determine whether they apply to you, we’ve listed them below.

Further PCI DSS Reading: The PCI Security Standards Council Document Library

Multi-Factor Authentication

Previously, two-factor authentication was only required for remote access to cardholder environments (CDEs). This changes in PCI DSS 3.2. Multi-factor authentication is now mandatory for all non-console administrative access to CDEs, even if the individual is not remote.

Who is affected: Everyone

Which requirement? 8.3, 8.3.1, 8.3.2

Why the change? The PCI Security Standards Council switched their two-factor authentication requirement to multi-factor authentication, allowing organizations to use more than two methods of authentication (if they wish). Furthermore, with version 3.2, they declared it unacceptable to use single-factor authentication to login to non-console accessed CDEs. This includes any CDE access that happens inside trusted networks.

What doesn’t requirement 8.3 include? As PCI Security Standards Council CTO Troy Leach explains, “[The multi-factor authentication requirement] will not impact machine authentication where one system is communicating with another as it is intended for personal authentication, nor will it impact administrators accessing directly from the console.”

PAN Storage

As of this new version, only the first six and last four digits of a primary account number (PAN) can be displayed. The rest must be masked. If employees need to see more than these 10 approved digits, organizations must list who has access and document the reasons behind it.

Requirement 1.1 stipulates that organizations should have a diagram of their card data flows. If you don’t already have one, we suggest doing so now so you know where card information comes into and goes out of your company at all times. This will help determine where unmasked PANs could be stored.

Who is affected: Everyone

Which requirement? 3.3

Why the change? Masking has always been required; this update to PAN storage simply clarifies that any display of PANs greater than the first six/last four digits requires a legitimate business need. It’s a measured attempted to make sure cardholder data is properly encrypted and handled in the event of a data breach.

For more rules surrounding how organizations should protect cardholder data, see PCI DSS requirements 3.1 - 3.6.

New Processes for Service Providers

PCI DSS 3.2 includes five new requirements (and sub-requirements) for service providers. These changes instruct providers to detect and notify customers of failing critical security control systems, maintain documentation on cryptographic architecture, perform quarterly reviews for security personnel, and more.

Who is affected: Service providers and third-party vendors

Which requirements? 3.5.1, 10.8, 10.8.1, 11.3.4.1, 12.4, 12.11, 12.11.1

Why the changes? The PCI Security Standards Council identified a need for better accountability among service providers and third-party vendors in the industry. These new processes were implemented to keep providers and third-party vendors focused on the security of their customers’ card data.

Security Controls for CDE Changes

If an organization makes a change in their cardholder data environment, PCI DSS 3.2 requires them to set up proper security controls immediately following the change. Any PCI DSS requirements that are impacted by the new environment must be re-verified to ensure continued compliance with all PCI DSS standards.

Who is affected: Everyone

Which requirement? 6.4.6

Why the change? A 2015 PCI compliance report from Verizon found that only 29 percent of companies are still compliant a year after validation. Version 3.2 hopes to improve this percentage by ensuring that organizations are checking their changes to the CDE and remaining consistent with updated security controls.

These changes, Troy Leach added in an interview on PCI DSS 3.2, “also ensure organizations view security as an organic process that evolves with the company as an ongoing effort and not a yearly assessment to correct behavior.”

SSL and Early TLS Migration

There are still a few months until the SSL and early TLS migration deadline, but we highly recommend planning for it now (if you haven’t already). A change like this can take time, and there are many considerations to explore.

PCI DSS 3.2 states that all PCI-compliant organizations have until June 30, 2018 to migrate from SSL and early TLS protocols to TLS 1.1 or higher. For those considering a move to TLS 1.1, this is acceptable; however, PCI Security Standards Council does suggest implementing a later version of TLS, like TLS 1.2, even though it’s not the minimum required. In some cases, TLS 1.1 is no longer considered a strong choice against current protocol vulnerabilities.

Who is affected: Everyone

Which requirement? Appendix A2

Why the change? SSL and early TLS protocols have been around for over a decade. Because of the lengthening gap between when they were created and revised and now, and with technology constantly developing to keep up with modern-day needs and vulnerabilities, migrating to TLS 1.1 or greater helps lessen the risks that come with using older protocols.

According to the PCI Security Standards Council and NIST, “there are no fixes or patches that can adequately repair SSL or early TLS. Therefore, it is critically important that organizations upgrade to a secure alternative as soon as possible and disable any fallback to both SSL and early TLS.” The sooner you can migrate, even weeks or months before the deadline, the better equipped your business will be to handle any sudden problems.

Need more information on what’s coming?

Dive deeper into PCI DSS 3.2 and uncover how it might affect organizations like yours.

Get the White Paper

 

Comments (0)


Add a Comment

Allowed tags: <b><i><br>