Almost three years after the release of its first draft for comments, the next evolution of the standard —PCI DSS v4.0 —is now available!
I've been under a rock.... What is it?
The PCI Security Standards Council (PCI SSC) is an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover, and JCB) in 2006 September. Visa first recognized that there was a need for standards and a unified approach to prevent credit card fraud and other security vulnerabilities. The other brands agreed, and the PCI SSC was formed as a global payment security forum.
Regardless of version, the Payment Card Industry Data Security Standard (PCI DSS) is a global standard that provides a baseline of technical and operational requirements designed to protect account data. It applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational practices for system components included in or connected to environments with cardholder data.
Is this me?
PCI DSS compliance is mandated by credit card companies to help ensure the security of credit card transactions in the payments industry. Its purpose is to help secure and protect the entire payment ecosystem. These standards apply for merchants, service providers processing credit/debit and payment transactions.
It applies to all those handling cardholder data, whether a start-up or a global enterprise. Businesses must always be compliant, and that compliance must be validated annually. Basically, if you accept or process payment cards, PCI DSS applies to you.
How long do I have?
The PCI SSC officially released PCI DSS v4.0 on 31 March 2022. It is the first major version update since v3.0 was released in 2013 November.
To provide organizations time to understand the changes and implement updates, the current version, v3.2.1, will remain active for two years and retire on 31 March 2024.
Oh, how life has changed!
At the time of the last major update, PCI DSS v3.0, mobile and cloud-based technologies were just beginning to emerge and evolve.
There have been short-term, just-in-time-esque updates issued, but PCI DSS v4.0 is a major version update. If one did nothing more than download and open the PDF, PCI DSS v3.2 may have seemed extensive, with the standard spanning 139 pages —PCI DSS v4.0 is 360 pages! There are also multiple supporting documents and templates, including a Report on Compliance (ROC) Template that is 492 pages.
How is this "compliance" different from all the others?
Payment card industry compliance refers to the technical and operational standards that businesses follow to secure and protect credit card and cardholder data provided by cardholders and transmitted through card processing transactions.
To put it simply though, it isn't different. It is merely a restating of best practices for development and cybersecurity, specifically tailored to the payment card industry. Even with the significant volume of changes between v4.0 and v3.2.1, the content itself is not new. It is further explanation in the context of new terminology and technology as a whole.
For any company or professional that has traditionally approached cybersecurity and/or compliance (PCI DSS or other) in a checklist format, this will not ring true. However, if a company or professional has a good understanding of cybersecurity and has always included the concepts at each stage, there is not much to do when it comes to the new version.
One might ask why the verbosity of v4.0 then. The answer to that is linked to the cybersecurity skills gap across all industries. That deep understanding has been lost, and it is reflected in the number of attacks and the issuance of more guidelines and standards, many of which are redundant. There are aspects that were previously implied, and did not need to be stated, but that is no longer true. In an attempt to both educate professionals and ensure security, these inferences can no longer go unsaid, and are now enumerated in each standard; in this case, that itemization spans 200+ additional pages.
Give it to me straight.
I will assume that you are reading this with a complete understanding of v3.2.1 and just want to know what changed, in plain speak.
While there is a document that details the changes available (Summary of Changes from PCI DSS Version 3.2.1 to 4.0, re-hosted on this site for ease of reference) —36 pages long —I am going to call out "my favorite changes."
Bear in mind that these are not "true changes," in my opinion. They are instead further explanation of the previous version. What is meant by that statement will be explained later. I'll do my very best [probably unsuccessfully] to not include any "I told you so" commentary.
Overarching Changes
PCI DSS Applicability (organizational level)
The first sweeping change is in a detail that many will completely overlook. The PCI DSS Applicability was updated in four ways, but two of them are near and dear for me:
Clarified that some PCI DSS requirements may apply for entities that do not store, process, or transmit primary account number (PAN).
Clarified that terms account data, sensitive authentication data (SAD), cardholder data, and PAN are not interchangeable and are used intentionally in PCI DSS.
A common stumbling block with PCI DSS is both the specificity and generality included, and both are illustrated in these two bullets. Teams have a propensity for interpreting the standard in whichever approach makes their situation easiest, and not from the view of the intent of the standard.
If a company markets itself as e-commerce/financial technology, the standard applies. It doesn't actually matter if it does not specifically handle the PAN. There is payment information and cardholder data involved —"cardholder data," not "card data." It is just that simple.
At the same time, if the standard chose a certain term in a specific guideline, it was for a reason. If it reads that PAN has to be handled in a certain way, that means that is true for PAN. Chances are good that there is a matching description for SAD. You do have to read it.
The text reads as follows:
"PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE. Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account data."
You should note that it does NOT say "PCI DSS requirements apply to environments where..." It specifies "entities," meaning that it is not enough to only address the CDE. The entire entity's cybersecurity posture is involved, i.e., NOT just the CDE. There are nuances, but this is truly an expectation that organizations understand the entire standard and any other applicable regulations.
Even further, it is no longer (nor was it ever, honestly) valid to only read the particular requirement that was thought to apply to a department. The entire standard cross-references itself and the requirements are different respective of an entity's architecture. For example, data handling related to cardholder data is defined, but if the same database contains other types of data, that data may become subject to the cardholder data rules as well... but it might not. It is all subject to the context.
Another note that is highlighted is related to the use of third-party service providers (TPSP). For companies that operate in an e-commerce industry yet have "out-sourced their PCI DSS compliance responsibilities" by utilizing a third-party vendor (like using PayPal's PCI DSS compliant frame option for payment implementations) and thus presumably limiting their own PCI DSS scope, there may be some work to do.
"NOTE: Use of a PCI DSS compliant TPSP does not make a customer PCI DSS compliant, nor does it remove the customer's responsibility for its own PCI DSS compliance. Even if a customer uses a TPSP to meet all account data functions, the customer remains responsible for confirming its own compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). Customers should contact the organizations of interest for any requirements."
My favorite pseudo-quote around this is:
"You can outsource the work but not the responsibility."
PCI DSS Applicability (internal level)
Something that was noted in v3.2.1 in smaller print has been elevated to its own section in v4.0. It reads:
"Note: PCI DSS Requirement 6 fully applies to bespoke and custom software that has not been developed and maintained in accordance with one of PCI SSC's Software Security Framework standards. Entities that use software vendors to develop bespoke or custom software that could impact the security of account data or their CDE are responsible for ensuring those software vendors develop the software according to PCI DSS Requirement 6."
Obviously, this highlights the requirements' applicability to internal, not public-facing applications, regardless of their usage or purpose. This has two main points, in my opinion:
Applications, scripts, batch files of command-line processes, etc., are all subject to SDLC treatment and the ensuing requirements of PCI DSS Requirement 6. This means change management, source control, testing, code review, approvals, versioning, etc. —This also includes "Infrastructure as Code" solutions, which is something that Operations teams will not appreciate (and is a wall that I have frequently run against). Expect questions and protestations about separation of duties and evidence creation, but this is entirely possible as a requirement but does require automating many things that those teams potentially do not have the skills to operationalize.
Equally important, this could open an entirely new concern in relation to an organization's ability to utilize open-source software and also maintain PCI DSS compliance. (This has always been a factor, but it is emphasized now.) According to the note, companies would be responsible for ensuring that the OSS in use was developed according to PCI DSS Requirement 6, which is something that can severely limit what components/packages/libraries can be included for use. It also means that the choices of packages/components/libraries cannot be added or implemented by an individual developer without proper oversight and review. This goes hand-in-hand with the emerging requirement of other cybersecurity mandates for the publication of a Software Bill of Materials (SBOM).
Relationship between PCI DSS and PCI SSC Software Standards
The second of the overarching changes is to point out the relationship between PCI DSS and other standards. The PCI SSC Software Standards (and PA-DSS) are used here, but the takeaway should be that PCI DSS is not a standalone requirement, i.e., it is related and overlaps many other standards.
The PCI SSC publishes not only PCI DSS but also validates payment processors and gateways for reuse. Once assessed, those applications are published, and versioning maintained between the organization and PCI SSC. Again, those standards emphasize best practices and cybersecurity at the different levels involved in payment card processing.
The references here are to the other standards published by the PCI SSC, but the broader vision should not be lost. As I have said before, PCI DSS was never intended as a checklist and cannot be implemented piecemeal. It is a part of a much larger information privacy and cybersecurity landscape.
Scope of PCI DSS Requirements
This one takes a step toward expanding the definition of the cardholder data environment (CDE) to encompass today's world, leaving less space for interpretation of what aspects are the responsibility of a company, including third-party, cloud-hosting, and inherited-type risks.
(PERSONAL NOTE: I would have elaborated further in this section, but that may be reflective of my own experience, aka PTSD. However, there are changes in the sub-topics related to scope that call out several of the aspects that I personally know to be problematic, so it will remain to be seen if that is sufficient.)
The scoping section is modified in a less obvious way that I find interesting. Previously, the statement was:
"The PCI DSS security requirements apply to system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data."
Now, it reads:
"PCI DSS requirements apply to:
The cardholder data environment (CDE), which is comprised of:
System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data, and,
System components that may not store process or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD.
AND
System opponents, people, and process that could impact the security of the CDE."
Did you see what they did there? In v3.2.1, the requirements as stated related to the CDE only, and by transference, the people connected to the CDE. In v4.0, the CDE no longer "owns" the relationships; it's anyone; anyone or anything processing, and anyone or anything that does not process but has access, and anyone or anything that could remotely affect it. (If you are like me, rather than creating work in identifying nuances, you simplify this and just say "everything.")
This has always been the case but is an effort at clarification. This is potentially a reflection of the types of breaches occurring since the last standard.
An example would be segmentation and shared services from v3.2.1, reprinted in Figure 1 below.
The corporate LAN depicted here is shown as out-of-scope, but that asterisk (*) and its description is the differentiator. The single criterium for evaluation is:
"Accounts used to access Shared Services from the corporate LAN do not have any access to the CDE."
In multiple breaches, credentials and identities were stolen and malicious actors were able to use those credentials to elevate privileges and then access the CDE. The Shared Services for directory services were in play and opened the door for the LAN and any other similar system to be in scope.
A similar scoping diagram reprinted from v4.0 is shown in Figure 2 below.
PERSONAL NOTE: What is NOT depicted here is the "people" aspect, but that is for a longer discussion and diagramming exercise. Further, the list of "system components" in v4.0 is exhaustive and deserving of its own post.
Approaches for Implementing and Validating PCI DSS
This is a new section that has somewhat gone unsaid but is now published. With this version, the process of assessing an organization's compliance can now officially take one of two paths.
An assessment can be conducted in the traditional way, validating specific prescriptive components.
It can also be conducted in a new way that allows for the organization to demonstrate full understanding of the intent and provide evidence that their own implemented processes fulfill the end result/goal in a customized way.
Until this version, while a savvy assessor would have allowed a custom approach that demonstrated the controls and understanding (and I have personally utilized that path multiple times), it was not formally declared as a separate approach.
The following diagram is reprinted from v4.0, depicting the validation approaches.
Cardholder data
Anyone who has worked with me EVER knows that I am over-the-moon with this one. The change is listed as:
"Changed 'cardholder data' to 'account data' as needed to align with usage and intent."
However, these are not interchangeable throughout, i.e., you will still see "cardholder data" used. This is because there IS a delineation —for PCI DSS, at least.
Account data is defined as:
Cardholder data
Primary account number (PAN)
Cardholder name
Expiration date
Service code
Sensitive authentication data
Full track data (magnetic-strip data or equivalent on a chip)
Card verification code
PINs/PIN block
Prior to this, many professionals equated "cardholder data" with "card data." That has not ever been a valid stance. In this version, PCI SSC has somewhat acknowledged that interpretation and thus reframed the terminology to be "account data."
As a cautionary note though, while account data is defined this way for PCI DSS, remember the previous comments about PCI DSS not being "alone." It still must be implemented as part of the larger landscape, which includes "information privacy" and the various acts in effect and in committee.
There is significant overlap in these areas, and it is important to know the requirements for each, both in security and retention. While PCI DSS does not specify these, compliance is acknowledged as stated here:
"PCI DSS does not supersede county, state, or local laws."
One should read that to understand that while PCI DSS is defining the handling of account data a certain way, organizations must still adhere to the potentially different rules for data privacy and information governance.
Individual requirements-level changes
Obviously, the individual requirements changed, but as stated above, only in a few terms and additional explanations. One is welcome to compare and contrast each —and I may do that at some point —but for now, if one understood the previous standard completely, they would see minimal changes that mainly serve to validate their previous assertions.
Comments