PCI DSS 3.2: What Your Business Needs To Know

August 30, 2016

Herjavec Group Contributors: David Mundhenk and Alex Spanovic, Security Consulting Services

The Payment Card Industry Data Security Standard (PCI DSS) is a worldwide standard, published and maintained by the PCI Security Standards Council (SSC). It is endorsed and enforced by all major credit card brands & their approved acquirers, and is intended to protect cardholder data wherever it is processed, stored or transmitted. The PCI DSS version 3.2 was published in April 2016, and superseded version 3.1.

PCI DSS 3.2 is mandatory for all compliance assessments with a report date after October 31, 2016.

PCI DSS Evolving Requirements Summary

The PCI DSS version 3.2 introduces 47 clarifications, 3 additional guidance points, and 8 evolving requirements. Of all the evolving requirements, one is effective immediately, and seven are currently considered as non-mandatory ‘best practices’ until February 1, 2018 when they effectively become mandatory requirements.

The following is a brief overview of the most significant PCI DSS requirements changes as well as a brief description of Herjavec Group’s recommendations to ensure compliance at the enterprise level.

Changes Effective Immediately

There has been a change to the wording of requirement 3.3, to provide greater detail around user access and visibility needs relating to the Primary Account Number (PAN) or Credit Card Number, as follows:

  • Requirement 3.3 - Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.

In the previous version of the standard (3.1), requirement 3.3 finished with the text, “can see the full PAN.

Action Required:  Examine written policies and procedures for masking the PAN to verify that:

  • The roles that have a legitimate business need to access more than the first six and last four digits of the PAN are identified and documented
  • The PAN is masked when displayed such that only personnel with legitimate business needs can see more than the first six/last four digits of the PAN
  • All roles not specifically authorized to see the full PAN must only see masked PANs

Effective after January 31, 2018

The Evolving Requirements, which become effective on February 1, 2018, include two for all organizations, and five for service providers only.

Requirements for all organizations:

  • Requirement 6.4.6 - Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable

This control should come naturally to organizations, in order to maintain operational compliance at all times. The documented clarity of the compliance validation, after a significant change on the affected systems for all applicable requirements, facilitates consistency in controlling the PCI scope and maintaining compliance.

Action Required: When your team completes a significant change, examine change records, interview personnel, and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change.

  • Requirement 8.3 - Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication, and its sub-requirements 3.1 and 8.3.2.

This is expanded and restructured requirement (former 8.3 … two-factor authentication … [only] for remote network access), now requires organizations to, 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

Prior iterations of the PCI DSS specifically referenced “2-factor” authentication; authentication credentials representing something the user “knows” (such as a password, passphrase, or PIN) and something the user “has” (digital certificate, software token, one-time password, etc.). PCI DSS 3.2 now references “multi-factor” authentication which includes 2-factor authentication methods, but could also include additional authentication credential factors for enhanced security if needed.

Action Required: Examine network and/or system configurations, as applicable, to verify multi-factor authentication is required for all non-console administrative access into the cardholder data environment (CDE.)

Requirements for service providers only:

These requirements are mandatory for service providers but Herjavec Group recommends they also be regarded as best practices for merchant organizations.

  • Requirement 3.5.1; - Maintain a documented description of the cryptographic architecture that includes:
    • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
    • Description of the key usage for each key
    • Inventory of any HSMs and other SCDs used for key management.

When documented, this degree of clarity enables the organization to keep pace with evolving threats to their cryptographic infrastructure. Insights driven may result in the implementation of strong cryptographic algorithms, cryptographic keys, cryptographic key administrative processes, and well-controlled infrastructure.

Action Required:  Interview responsible personnel and review documentation to verify that a document exists to describe the cryptographic architecture, including:

  • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
  • Description of the key usage for each key
  • Inventory of any HSMs and other SCDs used for key management

Requirement 10.8;  - Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: Firewalls; Intrusion Detection/Intrusion Prevention System (IDS/IPS); File Integrity Monitoring (FIM); Antivirus-malware prevention, Physical access controls, Logical access controls, Audit logging mechanisms;  Segmentation controls (if used), and its sub-requirement to, 10.8.1 …Respond to failures of any critical security controls in a timely manner …

Action Required: Examine documented policies and procedures, and interview personnel, to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to:

  • Firewalls
  • IDS/IPS
  • FIM
  • Anti-virus
  • Physical access controls
  • Logical access controls
  • Audit logging mechanisms
  • Segmentation controls (if used)

Failure of a critical security control should result in the generation of an alert along with the appropriate PCI compliant incident response.

Requirement 11.3.4.1; - If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

Action Required:  Examine the results from the most recent penetration test to verify that: 

  • Penetration testing is being performed to verify segmentation controls at least every six months in addition to being performed after any changes to segmentation controls/methods
  • The penetration testing covers all segmentation controls/methods in use
  • The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE

Requirement 12.4.1; - executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include: overall accountability for maintaining PCI DSS compliance; defining a charter for a PCI DSS compliance program and communication to executive management

 Action Required:

  • Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance
  • Examine the company’s PCI DSS charter to verify it outlines the conditions under which the PCI DSS compliance program is organized and communicated to executive management

Requirement 12.11; - Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes: daily log reviews; firewall rule-set reviews; applying configuration standards to new systems; responding to security alerts; change management processes, and its sub-requirement to,

Requirement 12.11.1 -  … Maintain documentation of quarterly review process …

Action Required: Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures. The complete review should include:

  • Daily log reviews
  • Firewall rule-set reviews
  • Applying configuration standards to new systems
  • Responding to security alerts
  • Change management processes
  • Verification that reviews are performed and documented at least quarterly.
  • Verification that sign-off of results is completed by personnel assigned responsibility for the PCI DSS compliance program

Effective after June 30, 2018

The requirements for risk mitigation and migration from SSL and early TLS protocols, to versions of TLS which are considered strong encryption (v1.1 and v1.2, currently), were introduced in PCI DSS 3.1 with a mandatory deadline date for the completion of the migration. Shortly after its release, this date was amended through the PCI SSC’s notifications to the industry and has been communicated again in PCI DSS 3.2 to be June 30, 2018.

In PCI DSS 3.2, Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS provides full specifications of the SSL and Early TLS related requirements, as well as references to SSL/early TLS.

Additional information on this topic can be found here:

As highlighted initially, this summary offers a brief overview of the requirements presented in PCI DSS 3.2.  The goal of these evolving PCI DSS requirements is to ensure improved compliance through risk assessments across your organization.  Please review them carefully and seek support from a third party assessor in order to ensure compliance.

To learn more about PCI DSS 3.2, or to engage Herjavec Group’s Security Consulting Services team, please contact us.

[contact-form-7 id="99" title="Contact Herjavec Group"]


About Herjavec Group

Dynamic IT entrepreneur Robert Herjavec founded Herjavec Group in 2003 to provide cybersecurity products and services to enterprise organizations. Herjavec Group delivers SOC 2 Type 2 certified managed security services supported by state-of-the-art, PCI compliant, Security Operations Centres, operated 24/7/365 by certified security professionals. This expertise is coupled with leadership positions across a wide range of functions including consulting, professional services & incident response. Herjavec Group has offices globally including across Canada, the United States, United Kingdom and Australia. For more information, visit www.herjavecgroup.com.

Stay Informed 

    Follow us on Twitter

    Connect with us on LinkedIn

 

*By selecting one of the communications above, you consent to Herjavec Group
sending commercial electronic messages to you for marketing purposes, including information about the products, services and events selected.


Take the First Step
In Transforming Your Cybersecurity Program

Enterprise security teams are adapting to meet evolving business needs. With 5 global Security Operations Centers, emerging technology partners and a dedicated team of security specialists, Herjavec Group is well-positioned to be your organization’s trusted advisor in cybersecurity. We’ll help you understand your risk exposure, increase your visibility and ROI, and proactively hunt for the latest threats.

Book a Free Consultation

Stay Informed

Follow us on Twitter
Connect with us on LinkedIn