With 23 seconds remaining on the game clock and no time outs, the quarterback managed to drive down to the 15-yard line spiking the ball to stop the clock. The offense put their place kicker in position for a game winning field goal. With little wind, and solid turf at east end of the field, this should be a chip shot. The ball is snapped, it’s up, and just before clearing the left upright, the officials moved the goal post and the ball sailed wide right.
Merchants and service providers, that process credit card payments, must feel like that with each new release of the Payment Card Industry – Data Security Standard (PCI-DSS). Entities processing credit card transactions usually work hard implementing security controls to achieve security and compliance; only to have the goal posts moved, or in this case a new PCI-DSS is released causing them to miss their compliance goals. But before declaring these changes unjust or unfair, let’s dig a little deeper and look at the new requirements, the rationale for incremental PCI-DSS releases and possible benefits.
What can we expect with PCI DSS 3.2?
The goals of introducing 3.2, per PCI SSC, are to protect against old exploits, refine the standards for new exploits, and provide greater clarity and tools to implement effective PCI DSS controls.
|
PCI DSS 3.2 Change Summary [1] |
||
|
# Changes |
Change Type |
Definition |
|
47 |
Clarification |
Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements. |
|
3 |
Additional guidance |
Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic. |
|
8 |
Evolving Requirement |
Changes to ensure that the standards are up to date with emerging threats and changes in the market. |
|
58 |
Total changes |
|
The raw numbers: 47 clarifications, 3 additional guidance, and 8 evolving requirements or 58 total changes may seem daunting, but upon closer review 47 clarifications (some as simple as renumbering the requirements), 3 Additional Guidance (typically better defines a process), and 8 Evolving Requirements (i.e., changes to maintain with emerging threats, such as zero-day exploit Poodle necessitated a review of SSL). This is not to suggest the changes are all trivial.
So why introduce new requirements in DSS 3.2, instead of waiting for the next release cycle? Simply put, the threat landscape is changing and the DSS must keep pace. Are there really benefits? We understate the benefit of better security, but tweaking a PCI Compliance program every year may also be easier to implement and fund, than huge big bang program overhauls. While all applicable requirements will need to be retrofitted into PCI Programs, we will detail a few of the more interesting changes below.
3.2 Change Summary
There are five (5) new sub-requirements for Service Providers. For example, service providers are required to detect and report failed critical security controls; conduct semi-annual penetration tests; formally document the cryptographic architecture; perform quarterly reviews of personnel to confirm adherence to security policies and operational procedures; and declare a PCI Program owner. There is a growing trend, where an entity puts strong security controls in place, only to have a third-party service provider with weak controls be the source of the data breach.
Multi-factor authentication is required for non-console administrative access to the systems handling card data. Two or more access control measures (e.g., something you know such as an IS/passphrase, something you have such as token, something you are such as biometric). A password alone is not sufficient to authenticate users, even if coming from a trusted environment. Recent attacks show hackers seek any device they can obtain administrative rights and use that access to move about the network to find cardholder data.
DSS 3.2 also codifies the June 30, 2018 deadline for weaning entities from for SSL and early versions of TLS. Organization should already be managing this risk, including outlining a remediation strategy for migrating as soon as feasible, but no later than the deadline.
Designated Entities Supplemental Validation (e.g., requirement 3.2) – “The DESV provides additional criteria for demonstrating how PCI DSS controls are being applied continuously to protect payment data from compromise. While specifically designed for entities that may be at greater risk for compromise, all organizations can benefit from using this tool to ensure ongoing compliance and security throughout the year.” [2]
How to prepare
“Companies should adopt the standard as soon as possible to prevent, detect and respond to cyberattacks that can lead to payment data breaches. DSS 3.1 will expire on October 31, 2016. However, all new requirements are best practices until February 1, 2018 to allow organizations an opportunity to prepare to implement these changes.” [3]
What about PCI DSS 4.0?
PCI 3.2 was released in April 2016, becomes effective October 31, 2016, with mandatory compliance no later than February 1, 2018. Between now and October 31, 2016 either 3.1 or 3.2 may be used. PA-DSS will be updated May 2016. DSS is seen as a mature control framework, so it doesn’t require as significant and frequent changes, as in the past. PCI SSC indicated the smaller releases are needed to keeping up with emerging threats and the changing landscape of information security and payment processing. The trend will continue. Publishing smaller releases will reduce the big releases making updating information security and compliance programs more manageable.
Expect the bad threat actors to continue to alter their attack strategy to steal credit card data, after all it’s lucrative. Therefore, expect the DSS to modify its security controls to thwart these new attacks. Companies need to use a risk-based approach, when establishing security budget and allocating its security spend. Building a nimble security program that aligns with PCI DSS (Security Standards Council), will better protect an organization and better prepare for the next time the goal posts get moved – not moved because of the PCI SSC, but the threat actors. Sounds like a winning game plan.
ENDNOTES
[1] Summary of Changes from PCI DSS Version 3.1 to 3.2; April 2016
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_Summary_of_Changes.pdf
[2] PCI Council Publishes PCI DSS Designated Entities Supplement Validation; June 5, 2015
https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf
[3] PCI Data Security Standard 3.2 Overview Webinar; April 2016