Endpoint Security Baby

The Payment Card Industry (PCI) Security Standards Council (SSC) recently announced the forthcoming release of PCI DSS 3.2.  The release of PCI DSS version 3.2 will supersede the scheduled change for November 2016, and will be the only update to the DSS in 2016.  The of the deadline for the Secure Sockets Layer (SSL)/Early Transport Layer Security (TLS) migration as the impetus for moving forward the updated release date.

Anitian was able to attend a peer to peer session at RSA this year with members of the SSC, during which  they clarified the time-line for the release of  PCI DSS v3.2.

Timeline

Target release date for PCI DSS 3.2:  April 2016 Sunset of PCI DSS 3.1: October 2016.

Organizations can still use the 3.1 standard up until the October date.  After that, the 3.2 version must be used.  Incidentally, we found out that 3.1 assessments must be completed by October 2016. You cannot start them before then and finish them after that date.

Anitian recommends all compliant entities move to the v3.2 standard as soon as it is released to avoid any issues.  Anitian plans to have our audit practice using the 3.2 standard within days of release.

Changes

The PCI SCC considers the DSS a mature standard, and any changes to be incremental in nature.  While Anitian generally agrees with that point of view, there are a few potentially significant changes entities need to understand and prepare for immediately if they’re not already in place (which in our experience is often not the case).    The major issues are discussed in order of impact below:

Change 1. Multi-Factor Improvements

Previously, MFA was only required for remote access to the environment.  Now it will be  required for all administrative access to a CDE system. MFA is an excellent way to reduce the risk of an administrator account being compromised.  However, this will likely require architectural changes if you are not using something like a next-generation firewall (NGFW) with VPN as a segmentation technology to control access to your CDE.

Therefore, Anitian considers this change to have a rather significant impact.  Fortunately, we have anticipated this and advised our clients to implement this technology as far back as version 2.0.  Anitian advises all compliant entities to immediately review your segmentation and ensure that MFA can be rolled out to all administrative access.

The bulletin does not make clear if this will be limited to non-console administrative access or not.  As such, Anitian recommends addressing both scenarios for any improvements.

Change 2. Designated Entities Supplemental Validation

PCI DSS v3.2 will incorporate some of the criteria for service providers. While this will only apply to Service Providers, there a quite a few additional changes that may potentially be extended to all Service providers, including:

Implement a PCI DSS compliance program (DE.1) There are four sub-requirements to DE.1, which deal with top-down PCI DSS compliance program management, including formal definitions of roles and responsibilities, as well as supporting policies and procedures for maintaining PCI DSS compliance and integrating compliance as part of business as usual (BUA) practices. DE.1 basically enforces due-diligence for executive management at PCI DSS compliant service providers. Document and validate PCI DSS scope (DE.2) This is the biggest DE requirement, with 6 sub-requirements. Effectively, DE.2 formalizes how the PCI DSS scope is determined, and more importantly, how it is maintained throughout the year.  Anitian is excited about this requirement, as incorrect scoping is the single biggest problem we encounter when performing assessments for both Merchants and Service Providers.  While PCI DSS v3.0 added explicit requirements for maintaining an inventory of in-scope systems, in practice,organizations tend to only perform this exercise on an annual basis.  This has implications for both compliance risk, and more critically, breach of CHD.  It is not uncommon for Anitian to see changes to an environment made during the year not folded into the assessment scope inventory, resulting in incorrectly scoped maintenance activities such as quarterly vulnerability scans. Validate PCI DSS is incorporated into business-as-usual (BAU) activities (DE.3) The three sub-requirements of DE.3 enhance current requirements concerning IR and vulnerability management, and formalize how BAU activities are preformed and tracked throughout the year in greater detail than previously required.  DE.3 can be seen as the “Target”-style breach mitigation requirement. Control and manage logical access to the cardholder data environment (DE.4) There is only one sub-requirement to DE.4, which is to mandate reviewing “user accounts and access privileges to in-scope system components at least every sixmonths to ensure user accounts and access remain appropriate based on job function, and authorized.” It is the six month frequency that is the enhancement DE.4 makes to PCI DSS requirement 7. Identify and respond to suspicious events (DE.5) This also has only one sub-requirement, which is effectively requiring DE’s formalize how they perform security event alert reviews and correlation as part of IR. Anitian welcomes the strong emphasis on IR throughout all of the DE requirements, as this is traditionally one of the weakest components from a procedural and operational effectiveness perspective that Anitian sees in the field.

Change 3. Clarifying Masking Criteria for Primary Account Numbers (PAN) When Displayed

The bulletin does not provide more insight on what to expect with this change.  Anitian plans to publish a follow up on this issue when the Council provides more information.

However, masking of PANs is addressed in v3.1 by requirement 3.3.  The main provisions are that “the first six and last four digits are the maximum number of digits to be displayed”, and “that only personnel with a legitimate business need can see the full PAN”.  The bulletin implies there will be clarifying guidance on when the PAN must be masked, and / or what constitutes a legitimate business need to view the whole PAN.  Until v3.2 is published, Anitian recommends reviewing all instances where PAN is displayed.  Compliant entities should carefully consider the risk of displaying full PAN based on necessity.  It is our experience that most instances where full PAN is displayed are not critical to job function and expose the organization to unnecessary risk.

Change 4. SSL & TLS Updates

This was the main driver for the update to PCI DSS v3.2, and should not include any new information, only formalize the guidance from the .  The key detail of the bulletin is that the migration date has been extended from June 30, 2016 to June 30, 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher).

Anitian strongly recommends eliminating all instances of SSL and older TLS immediately.  These are openly exploited versions and expose the organization to potentially extreme risk.  If it is impossible to migrate, then you must have documented risk mitigation and migration plan in place for all instances of SSL and insecure TLS.  Also, while the SSC considers TLS v1.1 to be secure, Anitian strongly advocates for only using TLS v1.2, in order to mitigate the and .

Conclusion

As usual, these changes reflect the evolving threat landscape for payment card systems.  Anitian considers all of these are reasonable improvements, and in many cases we have anticipated them.  Stay tuned to the Anitian blog for more insights on the PCI DSS, including the finalized v3.2.