Who in security doesn't like the idea of making security (and thereby PCI compliance) business as usual, or BAU? The goal of BAU is to enable an entity "to monitor the effectiveness of their security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments." (PCI DSS v3.1, page 13) It's a terrific concept, but it hasn't really taken root yet.
The PCI Council offered some examples of how to implement PCI DSS into BAU activities but they didn't go much further than that in describing what BAU means for an entity subject to PCI DSS compliance. The example suggestions include but are not limited to:
- Monitor security controls for effectiveness.
- Detect and respond to security failures promptly.
- Review proposed CDE changes and follow complete change management practices.
- Review compliance impact and PCI scope after organizational changes.
- Communicate with personnel and review processes to confirm security controls remain in place.
- Review technology at least annually for vendor support and security effectiveness.
On June 5, 2015 the PCI Security Standards Council (PCI SSC) took the idea of treating PCI compliance as BAU a step forward. And it's a huge step. They created a new compliance validation program and published the PCI DSS Designated Entities Supplemental Validation For use with PCI DSS v3.1. This document takes a deep dive into the BAU idea and provides a lot more guidance on how to comply in a BAU manner. It digs into the organizational environment and operational processes of the assessed entity.
This new set of validation steps came about because investigations of data breaches revealed an important fact. That is, that too many entities are not maintaining PCI compliance between their annual assessments. If you read the 2015 Verizon PCI Compliance Report you learn that only 28.6% of assessed entities were still compliant less than a year after their assessment. While that's an improvement from a few years ago it's still disappointingly low. But now, if acquirers or card brands want to focus in on mid-year compliance problems with certain designated entities they have a new tool in their belt to help keep these entities in line.
My first reaction on reading this was Yikes! But there are some important things to stop and understand before succumbing to fear. First and foremost, Designated Entities Supplemental Validation (DESV) applies only to designated entities. That designation can only be assigned by an acquirer or card brand. A QSA can't require it during an assessment, and there is no set of self-assessment qualifications that would require you to follow it. It is an additional validation step required for particular entities. The Council provides some examples of which entities it may apply to, which could 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.
My take on it is that this would apply mainly to Level 1 merchants and service providers. I can't recall if I have met someone from a university that is a Level 1 merchant. Even with aggregation my school is a Level 2. If an acquirer or a card brand gets suspicious that an entity is not trying to make PCI compliance BAU, the entity may receive the DESV designation.
Secondly, the DESV does not create any new PCI requirements. Instead it tells an entity how they can meet the requirements already included in PCI DSS. It provides a path to demonstrate to their acquirer or card brand that they are maintaining compliance and it is not just an annual checkbox exercise. Each of the DESV requirements refers to the section(s) of the PCI DSS that it comes from.
Here is an example:
DE.1.1 Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
DE.1.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
- Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually
Each of these requirements also has a detailed testing procedure (often referencing specific documents) and a guidance column, just like you see in the standard itself. You will see things that you don't see in the standard, but those are often considered implicit in the PCI DSS. For example, in DE 1.1 above it references "a charter for a PCI DSS compliance program." This takes requirement 12 up a notch in terms of having tangible evidence that it is being followed.
The additional validation steps are grouped into five main areas to control. Those are:
- DE.1 Implement a PCI DSS compliance program.
- DE.2 Document and validate PCI DSS scope.
- DE.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.
- DE.4 Control and manage logical access to the cardholder data environment.
- DE.5 Identify and respond to suspicious events.
There are no surprises here. But I am particularly impressed with Area 2, scoping. It has concrete steps to assess and validate the scope of compliance. We all know how slippery scope can be sometimes. Area 2 sheds a lot of light on scoping here. It covers data discovery tools in some detail and also addresses data exfiltration. I particularly like the requirement to not only document the PCI scope, but also to document what is not in scope. That's thorough.
Some of these new DESV requirements are different from the PCI DSS simply because they go above and beyond in terms of frequency or reporting. For example, penetration testing is required at least annually in the PCI DSS. But in DE 2.4 it becomes a semi-annual process for organizations that use segmentation to limit scope.
I think the DESV program should not be a big concern for colleges and universities at this time. But things do change, and it's a rare day when PCI DSS requirements get looser instead of tighter. Take this example from the FAQ:
- Q5: Can I use the DESV even if I’m not a Designated Entity?
- A: Yes. The DESV can be used to complement any entity’s PCI DSS compliance efforts, and all entities are encouraged to follow the DESV as a best practice, even if not required to validate.
I would agree with that. If I had the security resources available to implement DESV now I would do it! However, not many of us in this sector have those kinds of resources. But do take note of the encouragement "to follow the DESV as a best practice." We know that sometimes best practices become requirements later on. Take heed, my friends.
The Designated Entities Supplemental Validation program was released with a good set of supporting documents, including a FAQ sheet, a reporting template, and its own specific Attestation of Compliance. You can read the press release on the PCI Security Standards Council's web site (https://www.pcisecuritystandards.org/pdfs/15_06_05_DESV_Press_Release.pdf) and you will find the related documents in the Council's documents library.
Payment Card Industry (PCI) Data Security Standard
PCI DSS Designated Entities Supplemental Validation
For use with PCI DSS v3.1
References:
Posts
Thank you for this article. Very insightful.
ReplyDelete