PCI DSS 3.2 Changes: What Your Business Needs to Know

Learn what new requirements 3.2 is implementing into the standard. 

As you may know, PCI DSS version 3.2 has been released and version 3.1 will expire on October 31, 2016. All new requirements are best practices until February 1, 2018.

SEE ALSO: PA-DSS 3.2: The What, The Why, and The When

So what do these changes mean for businesses?

Here is a list of the changes PCI DSS 3.2 has made to the standard.

Tweet

Updated migration dates

In December 2015, the migration dates for businesses to move from SSL and early TLS to the latest TLS were moved back from June 2016 to June 2018. The PCI Council wanted to reflect that date change in the latest version of PCI DSS.

Many businesses plan to stick with the old date to avoid dealing with the extra exposure. Having SSL encryption is very risky to security since it has many exploitable vulnerabilities. So even though the deadline has been extended, it’s a good idea to make those changes as soon as possible.

Multi-factor authentication required in and out the CDE (8.3)

Multi-factor authentication is an effective way to secure your CDE and is required by the PCI DSS. To properly configure it, you need to have at least two of three things:

• Something you know (username, password, etc.)
• Something you have (getting a code from your phone)
• Something you are (fingerprints and other biometrics)

SEE ALSO: Two Factor Authentication – Security Beyond Passwords

Before 3.2, multi-factor authentication was only required for remote access to the network. Now, even if your connection is within the CDE, multi-factor authentication is required.

Incorporating designated entities supplemental validation into PCI DSS (Appendix)

PCI DSS 3.2 incorporates some extra validation procedures in the Appendix. In addition to full PCI DSS validation, designated entities determined by Acquirers or Payment Brands should have some additional validation that shows whether a business’s day-to-day practices are reflective of their compliance.

The additional validation procedures are for designated entities to make sure they’re PCI compliant on a day-to-day basis, instead of just an annual basis.

For example, you could look at a list of all the change controls in a merchant’s environment for the past year. These procedures could include anything that shows the day-to-day compliance.

Clarifying masking criteria (3.3)

PCI DSS 3.2 clarifies masking criteria for primary account numbers (PAN) when displayed. Masking hides information from view; this is not the same as encryption. When displaying a credit card number or bank identification number (BIN), you can display, at the most, the first 6 and last 4 numbers. If you go beyond these requirements, you’re not compliant.

Whether or not you should display less PAN numbers could depend on various legal requirements. Another related note worthy item, if your business stores PAN, you’re also required to encrypt and properly secure it.

Change management process (6.4.6)

PCI DSS 3.2 explains you need to have a change management process to make sure all new or changed systems are PCI compliant on completion of a significant change. You should document these updates too.

Here are some examples of requirements that could be impacted:

• Network diagram is updated to reflect changes
• New systems are included in the quarterly vulnerability scanning process
• Systems are protected with required controls
• Systems are configured with proper configuration standards

Service Provider Written Agreement (12.8.2)

PCI DSS 3.2 explains that the responsibility that a service provider has for the security of cardholder data depends on the service and the agreement between the provider and the entity. You need to maintain a list of all PCI requirements your service provider meets and a list of requirements they need to meet.

New penetration testing requirements (11.3.4.1)

In PCI 3.1, service providers were required to have penetration tests done annually. Now, service providers that use segmentation are required to perform penetration tests on segmentation controls every six months.

SEE ALSO: How Much Does a Pentest Cost?

Cryptographic architecture requirements (3.5.1)

Service providers should interview personnel and maintain a documented description of cryptographic architectures, which may include:

• Details of algorithms, protocols, and keys used to protect cardholder data
• Description of key usage for each encryption key
• Inventory of HSMs and other SCS used for key management

This helps companies ensure their algorithms and encryptions aren’t getting breached and/or stolen. By documenting these keys, it helps streamline the process of encryption and prevents or detects potential thefts.

Establish a PCI DSS program (12.4.1)

Executive management of service providers must now establish a PCI DSS compliance program to
protect cardholder data.  The program should include:

• Overall accountability for maintaining PCI DSS compliance
• Defining a charter for a PCI DSS compliance program and communication to executive management

SEE ALSO: How Much Does PCI Compliance Cost?

Quarterly personnel reviews (12.11, 12.11.1)

Service providers must perform quarterly reviews to confirm that personnel are following security policies. Reviews should cover the following processes:

• Daily log reviews
• Firewall rule-set reviews
• Applying configuration standards to new systems
• Responding to security alerts
• Change management processes

You also need to document quarterly review process, such as documenting the results of the review and signing off results by personnel responsible for PCI DSS.

Timely detection and reporting (10.8, 10.8.1)

Service providers must have a formal process to detect and alert to critical security failures. The longer the system is vulnerable, the more time the attackers have to find a way to compromise systems and steal data. Examples of critical security control systems include:

• Firewalls
• FIM
• Anti-virus
• Physical access controls
• Logical access controls

Getting compliant

With these new requirements, it may feel like getting PCI compliant is more difficult than ever. Here are some tips that can make getting compliant easier.

• Scope out your network: your scope is everything in your business environment that handles cardholder data. By reducing your scope, you can reduce the amount of elements that need to be PCI compliant.
• Hire a PCI consultant: PCI QSAs and experts know a lot about helping businesses get compliant as soon as possible.
• Establish data security best practices: by doing basic things like implementing physical security and having firewalls, you can streamline the PCI compliance process.
• Create a PCI compliance team: PCI compliance shouldn’t be a one-man job. Set aside a team that handles the PCI DSS.
• Do regular PCI employee training: your employees need to live and breathe PCI. Train them quarterly if not monthly on PCI requirements and data security.

SEE ALSO: The Importance of the PCI DSS: Why You Should Get Compliant

Remember, the PCI DSS is not your enemy: it’s a standard that helps you protect your company from data breaches. PCI DSS 3.2 helps you add additional security to your business to protect your data from hackers.

Read more about 3.2 from our 2016 SecurityMetrics Guide to PCI DSS Compliance!