A Guide to PCI DSS 3.2 Compliance: A Dos and Don’ts Checklist

A Guide to PCI DSS 3.2 Compliance: A Dos and Don’ts Checklist

Before you begin, download the PCI Compliance Checklist PDF and follow along!

Table of Contents

Overview

PCI DSS compliance is a requirement for any business that stores, processes, or transmits cardholder data. It can be tough to dig through the hundreds of pages and sub-requirements provided by the Security Standards Council (SSC). Add some version updates, and we have quite a behemoth to tackle.

As a famous galactic guide once said, “Don’t Panic!”

This guide and corresponding checklist will help you down the path to PCI DSS 3.2 compliance. Learn what changes have come with the 3.2 update, how to approach PCI’s 12 compliance requirements, and the Dos and Don’ts to keep in mind during the process.

PCI DSS 3.2 Evolving Requirements – High Level Review

PCI DSS 3.2 has a multitude of changes and clarifications with the recent update. Let’s discuss them from a bird’s eye view.

New Compliance Deadlines – Get Your Calendars Out

November 1, 2016

PCI DSS 3.1 will be retired as the standard on November 1st. All assessments from this date forward will be based on 3.2.

February 1, 2018

Numerous evolving requirements have been outlined in 3.2 (read further below). The additional requirements will be considered best practice until February 1, 2018 when they become compliance requirements.

July 1, 2018

Right now, SSL and TLS versions 1.0 and earlier are no longer protected security protocols. Implementing updated protocols is considered best practice until July 1, 2018 when it becomes a requirement.

Note* – PCI DSS 3.1 had previously set a deadline of June 30, 2016, but 3.2 has extended it.

DO:

  • Migrate to an updated version TLS security protocol as soon as possible.

DON’T:

  • Wait until the July 1, 2018 deadline to make the adjustment. Though keeping SSL/early TLS for 2016-2017 does not indicate non-compliance, PCI Security Standards Council has determined these protocols are no longer secure. Why risk a breach?

Multi-factor Authentication for Everybody (8.3)

PCI DSS 3.2 has changed the two-factor authentication requirement to multi-factor, clarifying that you’re not limited to only two. Additionally, this requirement no longer applies to just employees working remotely, but anyone with non-console admin access to the cardholder data environment (CDE), regardless of location.

You must pick a minimum of 2 of these authentication methods to be compliant:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a fingerprint or retinal scan

Primary Account Number (PAN) Masking and Visibility (3.3)

PCI DSS 3.2 clarifies that primary account numbers must be masked when displayed, meaning they can only show a maximum of the first 6 and last 4 digits. A list must also be created with the roles and reasons for any employees who must see more digits than the masked PAN allows.

DO:

  • Check to ensure stricter requirements don’t supersede the PAN masking limit above (e.g., card brands that limit PAN masking for point-of-sale receipts).

DON’T:

  • Display the maximum number of first and last digits (6 & 4) if it’s not a business necessity.
    • Solution: Determine the minimum PAN digits your organization needs to function and mask the rest.

Stricter Reporting for Service Providers

PCI DSS 3.2 introduced a number of new requirements for service providers and has also included the Designated Entities Supplemental Validation (DESV) in its appendix. Here’s the catch – payment brands will designate when a service provider is required to fulfill the additional DESV validation.

First things first – what should all service providers do?

DO:

  • Interview personnel to confirm cryptographic architecture is documented and security controls detect critical system failures and alert those data owners. (3.5.1, 10.8)
  • Create a change management process that documents changes to the system as well as their impact to PCI DSS requirements. (6.4.6)
  • Repair security control failures in a timely manner, documenting the failure duration, the cause, risk assessment results, and the new controls preventing future failures. (10.8.1)
  • (If you use segmentation) Perform penetration testing on segmentation controls after every significant change, or at least every 6 months. (11.3.4.1)
  • Perform quarterly reviews (at a minimum) to confirm personnel are following security policies and procedures. (12.11)

*Note: PCI DSS 3.2 has outlined that personnel must be reviewed on daily log reviews, firewall rule-set reviews, application of config standards to new systems, security alert responses, and conformity to change management processes.

  • Document quarterly review results including signatures from the personnel responsible for the PCI DSS compliance program. (12.11.1)
  • Ensure your executive management establishes responsibility for the protection of cardholder data and PCI DSS 3.2 compliance, including a written acknowledgement of responsibility for all service providers. (12.4.1, 12.8.2)

If an Acquirer or Payment Brand determines a service provider needs additional DESV validation, what does that mean?

The DESV provides greater assurance that service providers are maintaining PCI DSS controls regularly and more effectively. The 5 validation steps outlined in the DESV sound awfully similar to the new service provider requirements: implement a PCI DSS program, control access to the CDE, etc. It’s best to think of the DESV as the “helicopter parent” to PCI DSS’s “free-range parent.” DESV walks you through every step of building a PCI DSS compliance program and will constantly check to ensure the initiatives are maintained consistently, even down to reporting on meeting minutes.

You can access the full DESV on the PCI SSC site.

PCI’s 12 Requirement Program Made Simple

PCI DSS outlines its requirements in 12 broad steps. Sounds easy, right? Flash forward 139 pages of size 10 font when you’re asking yourself, “What did I just read?”

Let’s take a step back and see if we can group these requirements into something more digestible. How about 4 defense tactics broken down by checklist? We recommend you download our free checklist PDF to track your progress.

Defend your cardholder data

The first step is an obvious one. Customer credit card data is what this is all about, so let’s make sure that data itself is secure before working on the perimeter.

Applicable DSS requirements:

DSS Requirement 3 – Protect stored cardholder data

DO:

  • Implement documented data retention and disposal policies to minimize cardholder data you collect and how long it is retained. (3.1)
  • Interview your employees to confirm policies are being maintained and quarterly processes are in place to remove cardholder data outside of your retention policy. (3.1.b)
  • Make sure the stored data and data in-transit is unreadable. (3.4, 4.1)
  • Encrypt card data and protect the encrypted keys. (3.5)
  • Mask your PAN data when it must be viewed (see above) using the fewest digits possible (under the 6 First, 4 Last display maximum). (3.3)
  • Create a cardholder flow diagram for all data flows through your organization. (1.1.3)
  • Use a data discovery tool to find misplaced sensitive data in your environment.

DON’T:

  • Store sensitive authentication data after authorization. (3.2)
    • Exception: Your organization is an issuer and has business justification.
  • Store masked PAN data.
    • Solution: Encrypt it instead.

DSS Requirement 4 – Encrypt transmission of cardholder data across open, public networks

DO:

  • Identify where you send cardholder data and ensure your policies are not violated in the journey and only trusted keys or certificates are used. (4.1)
  • Select a sample of inbound and outbound transmissions and verify cryptography is maintained during transit. (4.1.c)

DON’T:

  • Send PANs by end-user messaging tech like email, SMS, or IM. (4.2)
  • Use new technologies that utilize SSL/early TLS. (version 1.0 or earlier)
  • Migrate cardholder data to systems using SSL/early TLS. (version 1.0 or earlier)

Defend against the external threat

So now your data itself has been defended. It is encrypted, masked when it must be displayed, and travels only through mapped cardholder data flows. Unfortunately, this is not enough to truly protect your cardholder data. Beyond the perimeter of your environment, the world is a scary place, full of malicious hackers and profiteers.

PCI DSS wants to ensure that you build your walls high and strong (I promise we’ll get away from these castle defense metaphors) by strengthening your firewalls and anti-virus measures, changing default security parameters, and maintaining secure systems with a strong change control process.

Applicable DSS Requirements:

DSS Requirement 1 – Install and maintain a firewall configuration to protect cardholder data

DO:

  • Install a firewall at each internet connection (every device) and between any demilitarized zone (DMZ) and internal network zone. (1.1.4, 1.4)
  • Configure your firewalls with a description of groups responsible for network components and business justifications for all services/protocols/ports in the configuration. (1.1.5, 1.1.6)
  • Review firewall and router configuration at least every 6 months and confirm all other, non-config traffic (inbound or outbound) is denied. (1.1.7, 1.2.1)
  • Configure routers to block connections between untrusted parts of the network and cardholder data. (1.2, 1.3)
  • Assign responsibility for someone to check firewall logs daily.

DON’T:

  • Store cardholder data in the DMZ or any untrusted network.
    • Solution: Create a secure internal network zone. (1.3.6)

DSS Requirement 2 – Do not use vendor-supplied defaults for system passwords and other security parameters

DO:

  • Identify a sys admin to be responsible for system components. (2.2.4)
  • Maintain an inventory list of all system components in scope for PCI DSS. (2.4)
  • Document policies to change vendor-supplied default passwords, default wireless settings and remove default accounts before installing a system on your network. (2.1, 2.1.1, 2.5)
  • Document system component config standards that address security weaknesses, limit service/protocol access based on need, and follow hardening standards. (2.2, 2.2.2)

DON’T:

  • Implement multiple functions to a single server as this can create permission conflicts. (2.2.1)
  • Assume your vendors are maintaining anti-virus scanning.
    • Requirement: It’s your responsibility to confirm vendors are up-to-date and scanning regularly.

DSS Requirement 5 – Protect all systems against malware and regularly update anti-virus software or programs

DO:

  • Regularly update ant-virus software on your commonly affected systems and evaluate whether additional systems are at risk/need anti-virus. (5.1, 5.1.1, 5.1.2)
  • Automate anti-virus scans and maintain anti-virus audit logs for your systems. (5.2)
  • Ensure only admins can alter or disable anti-virus. (5.3)
  • Document procedures for protecting against malware. (5.4)

DON’T:

  • Wait to identify Malware by observing the damage it causes.
    • Solution: Install software that can observe behavioral anomalies and alert the necessary personnel.

DSS Requirement 6 – Develop and maintain secure systems and applications

DO:

  • Establish a process to keep up-to-date with the latest security vulnerabilities and identify the risk level. (6.1)
  • Install all vendor-supplied security patches. (6.2.a)
  • Document the impact, authorizer, functionality testing, and back-out procedures of all change control procedures. (6.4.5)
  • Use strict development processes and secure coding guidelines (outlined in DSS) when developing software in-house. (6.3)

DON’T:

  • Wait longer than 1 month to install vendor-supplied security patches for risk levels identified as critical. (6.2.b)
  • Test in-house software in your production environment, use production data during testing, or leave test accounts/IDs after software release. (6.3.1, 6.4.1, 6.4.3)

Defend against the internal threat

The cardholder data has been secured. The external barrier has been reinforced. Why can’t we pack up and call it a day? Because there is still a risk that the enemy is one of us…

Sometimes the internal breach can be an infiltrator who joined the organization for the sake of exploiting data or a turn-cloak who has maliciously switched teams (you probably shouldn’t have cracked that joke about Bob’s cargo shorts on casual Friday). Just as often, though, it’s the accidental insider who has access to more than they should and unknowingly creates a security vulnerability.

PCI DSS has a number of requirements in place to combat the risk the insider by restricting both virtual and physical access to cardholder data within the organization.

Applicable DSS Requirements:

DSS Requirement 7 – Restrict access to cardholder data by business need to know

DO:

  • Create a list of roles with access to the CDE that includes the definition of each role, their privilege level, and what permissions are required for each role to function. (7.1, 7.3)
  • Create a least-privilege policy for all employees and a default “deny-all” setting on all access control settings. (7.1.2, 7.2.3)
  • Require documented approval by authorizers for any privilege assignments or privilege changes in the CDE. (7.1.4)

DON’T:

  • Give excessive permissions to a role for that “rainy day” when they might require it.
    • Solution: Use a least privilege model where permissions are granted only by business need.
    • Solution: Grant access only for the period of time that it’s needed.

DSS Requirement 8 – Identify and authenticate access to system components

DO:

  • Define and document procedures for user identification and authentication on all system components. (8.1, 8.4)
  • Assign unique IDs to all users, test those privilege controls, and revoke access on inactive/terminated users. (8.1.1, 8.1.2, 8.1.3, 8.1.4)
  • Monitor all accounts used by vendors and other third parties, then disable them when not in use. (8.1.5)
  • Lock out users IDs for 30 minutes after six failed access attempts. (8.1.6, 8.1.7)
  • Follow best practice guidelines outlined in DSS for password setting – including strong password composition, encrypting credentials, verifying ID before reset, and mandatory resets every 90 days. (8.2.1, 8.2.2, 8.2.3, 8.2.4)
  • Incorporate multi-factor authentication for all non-console admin access and remote access to CDE. (8.3)

DON’T:

  • Use the same password for multiple accounts or devices – once one is compromised, they all will be.
  • Use shared user IDs or authentication methods in the CDE. (8.5)

DSS Requirement 9 – Restrict physical access to cardholder data

DO: (if applicable)

  • Document process for physical access to CDE systems and a list of all devices, limiting access to roles that require it and monitoring all with authorization tokens and surveillance. (9.1.1a, 9.1.1b, 9.2, 9.3, 9.9.1)
  • Create visitor authorization and access controls that ensure visitors are identified, documented, and monitored in areas that access the CDE. (9.4)
  • Establish firm controls for physical media moved within the facility, use tracked couriers when moved outside, and ensure destroyed media cannot be reconstructed. (9.5, 9.6, 9.8)
  • Train employees with processes to identify outside vendors requesting physical access and identify/report suspicious behavior. (9.9.2, 9.9.3)

Defend against complacency

We’ve secured our cardholder data itself. The perimeter has been reinforced against external threats. Measures have been put in place to negate the threat of internal breaches. What dangers could be left? Complacency.

Just getting to a state of PCI compliance for your assessment is not enough. PCI DSS 3.2 acknowledges this and has requirements that reinforce monitoring access to all network resources, testing policies regularly, and developing programs that keep personnel involved year-round.

Applicable DSS Requirements:

DSS Requirement 10 – Track and monitor all access to network resources and cardholder data

DO:

  • Implement audit trails for all systems, alerts on suspicious activity, and a response plan for those anomalies. (10.1, 10.2, 10.6.2.b))
  • Track all admin actions, login attempts, account changes, and pauses in the audit trail. (10.2.3, 10.2.4, 10.2.5, 10.2.6)
  • Ensure each audit log captures user ID, event type, date and time, event success or failure, where the event originated from, and what resources are affected. (10.3)
  • Keep all audit logs for at least one year with the last three months available for analysis. (10.7)
  • Prevent audit trail tampering and use software to alert on log changes. (10.5)
  • Create a process that reviews CHD system logs daily, and one that reviews all other system components based on your risk assessment results. (10.6.1, 10.6.2)

DON’T:

  • Give audit log access to anyone without a role justification. (10.5.1)
  • Leave the daily audit trail review to manual methods – this can be a massive time void
  • Store audit logs for external-facing technologies on those machines – they can be compromised. (10.5.4)

DSS Requirement 11 – Regularly test security systems and processes

DO:

  • Document each authorized wireless access points with a business justification. (11.1.1)
  • Implement processes to test and respond to authorized and unauthorized wireless access points on a quarterly basis. (11.1, 11.1.2)
  • Run vulnerability scans internally (with qualified personnel) and externally (with Approved Scanning Vendor) with every quarter and significant network change, correcting and re-scanning all identified vulnerabilities. (11.2)
  • Run penetration tests internally and externally (with qualified personnel or 3rd party) annually, correcting and retesting any exploitable risk found. (11.3)
  • Deploy a change-detection tool that alerts personnel to any unauthorized mod of critical systems and runs file comparisons at least weekly. (11.5)
  • Document a process for responding to change-detection alerts. (11.5.1, 11.6)

DON’T:

  • Stick to the bare-minimum for testing
    • Solution: Run reviews more frequently than the bare minimum – you will respond to threats sooner, before they are exploited.

DSS Requirement 12 – Maintain a policy that addresses info security for all personnel

DO:

  • Publish an annually reviewed security policy that documents all CDE critical devices and services, defines appropriate access (in role, use of that access, and location), and implements a risk assessment process. (12.1, 12.2, 12.3, 12.4)
  • Annually complete security awareness training with all personnel who access the CDE. (12.6)
  • Assign role responsibilities to document procedures, analyze security alerts, administer accounts, and monitor access to all data. (12.5)
  • Maintain documentation of service providers that requires lists of services provided, due-diligence in selection (including risk assessment), acknowledgement from SP accepting CHD responsibility, and a process to monitor the providers PCI DSS compliance. (12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5)
  • Create an annually tested response plan for a system breach that outlines tasks for each role, specific actions for different threats/alerts, how to cover critical systems and data backup, legal requirements for reporting, and notifications of card brands. (12.10)

Looking Ahead

PCI DSS 3.2, ultimately, urges you to make a shift in company culture. PCI compliance shouldn’t be something that is discussed only with an impending assessment, but on a regular basis. Find your sensitive data, restrict and monitor access to it, alert on suspicious behavior, and document everything. The checklist above will not only help you move towards these goals, but will prepare management to deal with new threats and requirements. Click here for a printable version of the PCI Compliance checklist.

 

PCI-blue

 

 

Sources:

http://blog.pcisecuritystandards.org/preparing-for-pci-dss-32

https://www.varonis.com/learn/pci-dss-3-1-it-requirements/

https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss

http://blog.pcisecuritystandards.org/preparing-for-pci-dss-3-2-summary-of-changes

http://info.securitymetrics.com/pci-guide

 

Get the latest security news in your inbox.