It has been no secret that retail merchants and their industry representation have been extremely unhappy with having to comply with Payment Card Industry Data Security Standard (PCI DSS) requirements. Their industry representative presentations at the recent Congressional hearings on the effectiveness of PCI DSS showed that their spokespeople could barely contain their vitriol during testimony. In addition, the National Retail Federation has also recently published an ‘open letter’ to the PCI Security Standards Council regarding their collective discomfort over PCI requirements. A copy of this letter can be found at their own website via the following link:
This blog entry is not intended to make light of the concerns of the retail industry regarding PCI DSS, nor to dismiss their assertion that having to comply with the requirements isn’t pain or duty free. The challenges of complying with PCI DSS are measurable, and for some businesses difficult to address. This is especially true for small-to-medium sized businesses which may lack the expertise, bandwidth or resources to formulate an effective response to meet the requirements. The NRF collective attempts to make overall industry improvements for the better should be applauded, however, after reviewing the highlights of their recommendations it appears that they may have been drafted in haste.
What they have proposed is interesting and deserves some analysis and an objective response. The following is a representative sampling of NRF recommended improvements with respect to the current PCI compliance requirements, and also an interpretive viewpoint on the items noted:
National Retail Federation (NRF): Incorporate a formal review and comment phase on revisions to the PCI DSS by participating membership before they are issued.
Objective Response (OR): This is already taking place. The PCI SSC solicits feedback from certified QSAC’s and their respective QSA’s prior to finalizing version changes. In addition they sponsor “town hall” meetings where merchants and service providers who attend can ask questions, make recommendations, and vent their frustrations.
NRF: Ensure the amount of time from issuance of a revision to the
PCI DSS and the effective date is appropriate for all merchants, including
Level-1 merchants making enterprise-wide changes, based on the revisions that
are being implemented,
OR: This is purely subjective, no matter how much time is allotted there will be a contingent of merchants and others who feel like they need more time. The PCI SSC has to draw a line in the sand somewhere. In addition the PCI SSC has recently provided additional assistance for level 2, 3, and 4 merchants with their new, improved Self Assessment Questionnaires and their recommendations for a “prioritized” approach to achieving compliance.
NRF: Follow, and adopt, the ASC X9 announcement of its plan to develop a new standard to protect cardholder data that may include end to end data encryption.
OR: This is very interesting, and apparently their lone
recommendation toward relieving all the perceived pain and suffering associated
with having to comply with the PCI standard. They actually seriously propose
adopting yet another compliance standard? Especially one that is not even
mature yet? Yessir, and
They also propose adopting the supposed “holy grail” of cardholder data protection which is sometimes called “end-to-end” encryption. Sounds like a great idea in principle, but implementing end-to-end encryption will be a serious challenge for all parties currently involved in payment processing and settlement across the globe. It may actually be a viable prospect for the future and possibly successful over the long term. Initially, however, it will be incredibly expensive to deploy, administer, and maintain on a global scale. One also wonders what it will be like for everyone involved to re-initialize and then maintain all those crypto keys in a secure, PCI compliant fashion.
NRF: Utilize the concepts of key controls and controls rationalization to restructure the more than two hundred detailed requirements of the PCI DSS.
OR: This one too is fairly entertaining since the PCI DSS is already
constructed to accommodate what is known
SOX and SAS70 requirements permit unencumbered business operations to continue even if total compliance with their requirements has not been achieved. Also in some instances the auditor and the entity audited sit down prior to the exercise and “agree” upon the audit criteria to be measured against. "What? You don't want to rotate your encryption keys because you 'feel' like it is too much work? OK then! You don’t have to do it." This approach is not going work for PCI, which is one of the few required security frameworks that actually incorporates some level of enforcement for those who refuse to comply.
NRF: Require credit card companies and their banks to provide merchants with the option of keeping nothing more than the authorization code provided at the time of sale and a truncated receipt, rather than requiring merchants to store credit card information for dispute resolution, putting customers at unnecessary risk.
OR: Where PCI compliance is concerned this is a non-issue. Nothing within the PCI DSS nor the PCI PA-DSS requires the merchant to retain anything post authorization. Even section 3.1 & 3.2 of the PCI DSS clearly states the following:
3.1 Keep cardholder data storage to a minimum. Develop a
data retention and disposal policy. Limit storage amount and retention time to
that which is required for business, legal, and/or regulatory purposes,
3.2 Do not store sensitive authentication data after authorization (even if encrypted).
The PCI DSS doesn’t require having the merchants store any CHI post authorization. Some “issuer-processors” may actually be doing so on behalf of their customers (i.e. – banks, financial institutions, credit unions, etc.) who already own the data they are asking to be collected. In addition any sensitive authentication data being captured by them is usually collected during the pre-authorization process. Since the banking industry already "owns" this data, why shouldn't they be allowed to collect it? The additional audit compliance requirements imposed by the card brands on their issuer-processors accommodate a trusted relationship that allows for this to take place only under extremely special circumstances.
If a merchant does not want to collect CHI information for any reason what-so-ever post authorization they currently can choose not to do so. In reality it is usually the case that merchants have been collecting this type of information for years for their own business intelligence and data mining purposes. They are often unwilling to commit the resources required to re-tool their IT applications and infrastructure to support not storing CHI.
It has been reported in some Internet postings that the PCI DSS offers "minimum general recommendations for security" for systems storing or processing CHI. This is a myth. The PCI DSS is indeed a standard and a framework, not detailed process or procedural recommendations on how to secure PCI systems. This is somewhat akin to the OSI model defining the seven protocol and architecture layers for computing systems and networks, but not detailing “how” they should be configured down the system level. The corresponding PCI DSS Requirements and Security Assessment procedures, however, are exacting in spelling out how to measure PCI DSS compliance within a given environment.
The effects of changing or re-engineering an operational business enterprise to become PCI compliant are usually measurable and often significant. Sometimes dealing with any change to normal business operations especially in tough economic times is very uncomfortable, however, managing change and potential risk to business assets is a simply a major component of doing business safely and securely. Reducing or eliminating the emotional aspects of having to do so helps provide focus and reduces anxieties associated with doing so. It also helps to aid in complex decision making. The PCI DSS and related compliance processes are not perfect, but their adoption has resulted in a significant industry improvement over doing nothing, or adding additional security standards to the mix.