This is a detailed follow-up to the quick post I wrote the Friday before the Labor Day weekend, based on my read at the time of the PCI SSC’s Special Interest Group paper on “Best practices for maintaining PCI DSS compliance”1 published just the day before.
The best practices guidance is by and large a good one though nothing of what is discussed is necessarily new or ground breaking. The bottom line of what the paper discusses is the reality of what any person or organization with electronic information of some value (and who doesn’t today?) needs to do… which is that there is no substitute for constant and appropriate security vigilance in today’s digital world.
That said, I am not sure this guidance (or anything else PCI SSC has done so far with PCI DSS including the new version 3 taking effect at the end of the year) is going to result in the change we need… the change in how PCI organizations are able to prevent or at least able to detect and contain the damage caused by security breaches in their cardholder data environments (CDEs). After all, we have had more PCI breaches (both in number and scale) over the past year than at any other time since PCI DSS has been in effect.
One is then naturally forced to question why or how does PCI SSC expect a different result if PCI DSS itself hasn’t changed fundamentally over the years. I believe a famous person no less than Albert Einstein had something to say about doing the same thing over and over again and expecting different results
If you have had anything to do with the PCI DSS over the last several years, you are probably very familiar with the criticism it has received from time to time. For the record, I think PCI DSS has been a good thing for the industry and it isn’t too hard to recognize that security in PCI could be much worse without the DSS.
At the same time, it is also not hard to see that PCI DSS hasn’t fundamentally changed in its philosophy and approach since its inception in 2006 while the security threat environment itself has evolved drastically both in its nature and scale over this period.
The objective of this post is to offer some suggestions for how to make PCI DSS more effective and meaningful for the amount of money and overheads that merchants and service providers are having to spend on it year after year.
Suggestion #1 : Call for Requirement Zero
I am glad the best practices guidance1 highlights the need for a risk based PCI DSS program. It is also pertinent to note that risk assessment is included as a milestone 1 item in the Prioritized Approach tool2 though I doubt many organizations use the suggested prioritization.
In my opinion however, you are not emphasizing the need for a risk based program if your risk assessment requirement is buried inconspicuously under requirement #12 of the 12 requirements (12.2 to be specific). If we are to direct merchants and service providers to execute a risk based PCI DSS program, I believe the best way to do it is by making risk assessment the very first thing that they do soon after identifying and finalizing the CDE they want to live with.
As such, I recommend introducing a new Requirement Zero to include the following :
- Identify the current CDE and try to reduce the CDE footprint to the extent possible
- Update the inventory of system components in the CDE (Current requirement 2.4)
- Prepare CDE Network diagram (Current requirement 1.1.2) and CHD flow diagram (Current requirement 1.1.3). I consider this to be a critical step. After all, we can only safeguard something valuable if we know it exists. We also talked about how the HIPAA Security Rule could use this requirement in a different post.
- Conduct a Risk Assessment (Current requirement 12.2)
- The full scope (of all 200+ requirements or controls) may be in scope for compliance assessments (internal or by QSA) only during the first year of the three year PCI DSS update cycle. Remember that organizations may still choose not to implement certain controls based on the results of the risk assessment (see suggestion #2 above)
- For the remaining two years, organizations may be required to perform only a risk assessment and implement appropriate changes in their environment to address the increased risk levels. Risk assessments must be performed appropriately and with the right level of due diligence. The assessment must include (among other things) review of certain key information obtained through firewall reviews (requirement 1.1.7), application security testing (requirement 6. 6), access reviews (requirement 7), vulnerability scans (11.2) and penetration tests (11.3).
Performing a risk assessment right at the beginning will provide the means for organizations to evaluate how far they need to go with implementing each of the 200+ requirements. In many cases, they may have to go well over the letter of certain requirements and truly address the intent and spirit of the requirements in order to reduce the estimated risk to acceptable levels.
Performing the risk assessment will also (hopefully) force organizations to consider the current and evolving threats and mitigate the risks posed by these threats. Without the risk assessment being performed upfront, one will naturally fall into the template security mindset we discussed here. As discussed in the post, template approaches are likely to drive a security program to failure down the road (or at least make it ineffective).
Suggestion #2 : Discontinue all (requirements) or nothing approach
A true risk management program must mean that the organizations should have a choice not to implement a control if they can clearly articulate the risk associated with not implementing it is truly low.
I think PCI DSS has a fundamental contradiction in its philosophy of pushing a all-or-nothing regulation while advocating a risk based approach at the same time. In an ideal world where organizations have limitless resources and time at their disposal, they could perhaps fully meet every one of the 200+ requirements while also addressing the present and evolving risks. As we know however, the real world is far from ideal in that the organizations are almost always faced with constraints all around and certainly with the amount of resources and time available at their disposal.
Making this change (from all or nothing approach) of course will mean a foundational change in PCI DSS’ philosophy of how the whole program is administered by PCI SSC and the card brands. Regardless, this change is too important to be ignored considering the realities of business challenges and the security landscape.
Suggestion #3 : Compensating controls
As anyone that has dealt with PCI DSS knows, documentation of compensating controls is one of the most onerous aspects of PCI DSS, so much so that you are sometimes better off implementing the original control than having to document and justify the “validity” of the compensating control to your QSA. No wonder then, that a book on PCI DSS compliance actually had a whole chapter on the “art of compensating control”.
The need for compensating controls should be based on the risk to the cardholder data and not on not implementing the requirement itself. This should be a no-brainer if PCI SSC really wants PCI DSS to be risk based.
If the risk associated with not implementing a control is low enough, organizations should have a choice of not implementing a compensating control or at least not implementing it to the extent that the DSS currently expects the organization to.
Suggestion #4 : Reducing compliance burden and fatigue
As is well known, PCI DSS requires substantial annual efforts and related expenses. If the assessments involve Qualified Security Assessors (QSAs), the overheads are much higher than self-assessments. Despite such onerous efforts and overheads, even some of the more prominent retailers and well-funded organizations can’t detect their own breaches.
The reality is that most PCI organizations have limited budgets to spend on security let alone on compliance with PCI DSS. Forcing these organizations to divert much of their security funding to repeated annual compliance efforts simply doesn’t make any business or practical sense, especially considering the big question of whether these annual compliance efforts really help improve the ability of organizations to do better against breaches.
I would like to suggest the following changes for reducing compliance burden so that organizations can spend more of their security budgets on initiatives and activities that can truly reduce the risk of breaches:
Suggestion #5 : Redundant (or less relevant) controls
PCI SSC may look at reviewing the value of certain control requirements considering that newer requirements added in subsequent versions could reduce the usefulness or relevance of those controls or perhaps even make them redundant.
For example, PCI DSS v3 requirement around penetration testing has a considerable change compared to the previous version. If the organization were to perform the penetration tests appropriately, there should not be much need for requirement 2.1 especially the rather elaborate testing procedures highlighted in the figure.
There are several other requirements or controls as well that perhaps fall into the same category of being less useful or even redundant.
Such redundant requirements should help make the case for deprecation or consolidation of certain requirements. These requirements also help make the case for moving away from the all or nothing approach or philosophy we discussed under #2.
Suggestion #6 : Reduce Documentation Requirements
PCI DSS in general requires fairly extensive documentation at all levels. We already talked about it when we discussed the topic of compensating controls above.
Documentation is certainly useful and indeed strongly recommended in certain areas especially where it helps with communication and better enforcement of security controls that help in risk reduction.
On the other hand, documentation purely for compliance purposes must be avoidable especially if it doesn’t help improve security safeguards to any appreciable extent.
…………………………………………………
That was perhaps a longer post than some of us are used to, especially on a blog. These are the suggestions that I can readily think of. I’ll be keen to hear any other suggestions you may have yourself or perhaps even comments or critique of my thoughts.
References
1Best Practices for Maintaining PCI DSS Compliance (pdf) by Special Interest Group, PCI Security Standards Council (SSC)
2PCI DSS Prioritized Approach (xls download)
0 Comments