As announced in December 2015, the PCI Security Standards Council released version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS) on April 28, 2016. This version update was necessary because of the PCI Council’s decision last December to “dial back” on the sunset dates for the replacement of all versions of SSL and “early versions” of TLS for companies subject to PCI compliance. Troy Leach, the PCI Council’s Chief Technology Officer, also stated in a blog announcing the revised dates for replacing SSL/early TLS that another major reason for publishing this version update now is because “the industry recognizes PCI DSS as a mature standard now, which doesn’t require as significant updates as we have seen in the past. Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard.”
The industry recognizes PCI DSS as a mature standard now
This assertion clearly marks the end of the three year cycle formerly followed by the PCI Council on reviewing and updating the DSS, and hopefully means that the standard will be more responsive both to changes in the threat landscape and to the evolution of payment acceptance methods.
The PCI Council also published a companion document entitled Summary of Changes from PCI DSS Version 3.1 to 3.2which provides a description of changes based on three categories:
- Clarification: Clarifies intent of requirement. Ensures that concise wording in thefefe standard portrays the desired intent of requirements.
- Additional guidance: Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
- Evolving requirement: Changes to ensure that the standards are up to date with emerging threats and changes in the market.
The “clarification” and “additional guidance” changes are attempts to make the DSS flow logically, articulate the intent of each requirement, and quite often to make sure that the overarching intent or reach of the requirement is explicitly obvious.
The “evolving requirement” changes are where you will find the “new” requirements, some of which are effective immediately upon release of the standard while the majority of them are considered “best practices” until a certain acceptance period has elapsed.
Key effective dates
For convenience, here is a list of key effective dates found in PCI DSS v3.2:
- April 28, 2016 – PCI DSS Version 3.2 released
- June 30, 2016 – Sunset date for all service providers to migrate to secure versions of TLS in their service offerings
- October 31, 2016 – PCI DSS Version 3.1 expires, making PCI DSS Version 3.2 fully in force
- January 31, 2018 – Sunset date for all new requirements to be treated as best practices instead of requirements
- June 30, 2018 – Sunset date for all merchants to migrate to secure versions of TLS in their PCI related operations (certain exceptions for POS systems apply)
What’s changed? What’s new?
Changes in PCI DSS version 3.2 may be grouped into several categories, including details about the dates for replacing SSL/early TLS, properly handling third party relationships including new service provider requirements, and an emphasis on meeting PCI DSS requirements on an ongoing or “business as usual” basis.
SSL/early TLS
The rules and testing procedures surrounding the removal of SSL/early TLS ... are a little complicated
The first change observed is that all of the rules and testing procedures surrounding the removal of SSL/early TLS have been consolidated into a single location, now found in Appendix A2. Don’t let that fool you though, because the rules are a little complicated – complicated enough, in fact, that I’m currently working on a follow-on blog that will explain some important nuances around the SSL and early TLS rules in more detail.
New service provider requirements
Surprisingly, the most significant changes directly impact service providers
Surprisingly, the most significant changes directly impact service providers and not merchants. There are nine new requirements found in v3.2 and seven of them are explicitly “for service providers only.” This is most likely the result of the “changing threat landscape,” or more simply because many of the recent major payment industry breaches involved some level of compromise or exploitation of third parties/service providers. Merchants have some increased or clarified responsibilities for managing their third party relationships compared to v3.0/v3.1 but there is now much more explicit responsibility put on the service providers themselves.
PCI and “business as usual”
PCI DSS should be implemented into business-as-usual (BAU) activities
A more subtle but still significant change in v3.2 is an increased emphasis on the necessity of doing what the PCI DSS requires on an ongoing and continuous basis. The best practice goal that “PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy” means that all companies should be treating the standard as a framework for their information cybersecurity programs and not merely treating it as a burdensome, annual check box audit. The emphasis on BAU activities is found in all three types of changes from clarification that merchants not only maintain a list of third party service providers but also list exactly what they do, to requiring more stringent remote access controls (particularly the use of multi-factor authentication by more parties), and in such new requirements as this one:
12.11Additional requirement for service providers only: 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
This is a new set of quarterly reviews required for service providers (who must also maintain documented evidence of these reviews) and will be required to be performed in addition to all of the other activities required by the PCI DSS.
What is a service provider?
Given the emphasis on the third party/service provider relationship and the new requirements specifically written to service providers it might be a good idea to clarify what constitutes a service provider according to the PCI DSS rules.
The PCI Glossary Version 3.2 provides an expanded definition of a service provider as follows:
Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data.
The definition actually continues by providing some examples of companies that should be included and the special circumstances where a company may not be considered a service provider.
The Glossary also provides a definition of what is a merchant which includes this statement:
Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers.
What does this all mean? It means that there are numerous types of companies that could fall into the category of being a service provider.
There are numerous types of companies that could fall into the category of being a service provider
Historically, service providers were recognized as the companies that operate “in-line” with the payment authorization and settlement path. Service providers are responsible for reporting their compliance status to the major payment card brands, and Visa and MasterCard actually maintain global listings of all the validated compliant service providers registered to do business with them.
The broad nature of the definition of service provider, and the changing IT landscape that revolves more and more around outsourcing has meant that there are lots of companies that perform services for merchants that weren’t “on the radar screen” for the service providers. In recognition of this, Visa recently launched a new program where these other service providers can be recognized and tracked. The program is called the Merchant Servicer Self-Identification Program (MSSIP). This program is intended for those companies that fall outside of the direct payment path (but all are subject to PCI compliance based on the definition of service provider!).
There is also a new category of third party which the PCI DSS calls “designated entities” and the supplemental validation requirements are now included in v3.2 in Appendix A3.
Designated entities are defined as “entities designated by a payment brand(s) or acquirer as requiring additional validation of existing PCI DSS requirements.”
Appendix A3 provides further detail:
Examples of entities that this Appendix could apply to include:
- Those storing, processing, and/or transmitting large volumes of cardholder data,
- Those providing aggregation points for cardholder data, or
- Those that have suffered significant or repeated breaches of cardholder data.
These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis through validation of business-as-usual (BAU) processes, and increased validation and scoping consideration.
The mandate is clear for all – follow the PCI DSS continuously, be able to prove it with documented evidence – and this means service providers too!
Are you a merchant or a service provider?
All companies exist because they are selling goods or services, so at one level all companies are merchants. If you are a merchant, you need to understand that every company or third party that helps you conduct business is a likely candidate for being a service provider. Also, if your company sells a service, you are probably a service provider. If your company sells to other companies (and not directly to consumers), you are probably a service provider. If your company is primarily a supplier of hardware and/or software and you provide support for the hardware/software you sell, you are probably a service provider.
How does Tenable help?
Tenable can help you track your PCI “business as usual” security activities to demonstrate ongoing adherence to PCI DSS. Tenable SecurityCenter Continuous View™ (SecurityCenter CV™) can be used to meet or augment over two-thirds of the technical controls found in PCI DSS v3.2, while it identifies vulnerabilities, reduces risk, and ensures compliance.
SecurityCenter CV can be used to meet or augment over two-thirds of the technical controls in PCI DSS v3.2
SecurityCenter CV™ provides pervasive visibility across your network including your cardholder data environment; identifying vulnerabilities, misconfigurations, and malware, and providing critical context using data from sources such as network traffic, virtual systems, mobile device management, patch management, host activity and monitoring, as well as external sources of threat intelligence and known malicious indicators to feed an intelligent monitoring system. SecurityCenter CV provides the critical visibility needed to assure that responses to failures in security controls are executed in a timely and decisive manner.
This is a broad summary of highlights from the PCI DSS 3.2. Tenable also plans to provide a more thorough analysis of the key changes and themes of PCI DSS v3.2 in future blogs, so stay tuned.