Compliance is defined by dictionary.com as "...acting according to certain accepted standards." It can further be described as a particular "state of being." Compliance is possibly the single most evocative word in the payments industry today. Articles are written, presentations offered and seminars scheduled to discuss issues surrounding compliance with the PCI DSS, the Payment Card Industry Data Security Standard. Certainly compliance with laws and regulations is a significant
part of the industry's daily life, and with good reason. Between the PATRIOT Act, Regulation E and PCI DSS, the feeling that every aspect of business in the industry is regulated may seem overwhelming. Compliance, for the most part, helps both companies and consumers. In the case of the PCI DSS however, pursuit of the necessary "state of being" has caused many companies to become myopic in their information security functions. They begin to behave in a manner that Chris Mark of The Aegenis Group describes as "chasing compliance at the expense of security."
It is imperative to understand that the purpose of the PCI DSS is simply to protect cardholder data. As the standards are prescriptive in nature, it is largely understood that many companies will be unable to meet the "black letter law" of every requirement defined therein. Instead, for some requirements, excepting of course requirement 3.2 which prohibits the storage of sensitive authentication data, many companies will need to find methods of meeting the objective of the standard without strictly meeting the exact methodology described in the standard. Having a prescriptive standard can be both a blessing and a curse when trying to protect cardholder data.
Many people ask why the PCI DSS was constructed in such a prescriptive manner. This question is posed to Aegenis on an almost weekly basis.
Mr. Mark, one of the developers of the original standard, states, "The requirements contained within the standard are a reflection of those controls that the card brands feel are necessary to mitigate the risk to data. Unfortunately, there is a large, and growing, population of data compromises from which to draw information about which, controls should be modified, or added."
It is also important to recognize the realities of the population to which the standard will apply. Certainly merchants and service providers with large, complex environments are challenged with the prescriptive nature of the standard. That being said, level 1-3 merchants account for less than 1/20th of a percent of the total population of nearly 6.8 million U.S. merchants. The other 99.95% are level 4 merchants. For this reason, it is important to develop a standard that is prescriptive and can be read like detailed instructions by organizations that likely do not have dedicated information security and risk personnel. Finally, having a prescriptive set of standards provides consistency throughout the industry. As stated previously the requirements are a reflection of the controls the card brands feel are necessary to mitigate the risk to cardholder data. For this reason it is important to ensure consistent application of the controls. A less prescriptive set of requirements would allow for a broad interpretation of controls, which would do little to ensure consistent application.
That is not to say there are not drawbacks to such a prescriptive standard. The requirements provide ample opportunity for an inexperienced Qualified Security Assessor (QSA) to pursue such a literal interpretation of the requirement that the overall objective, protecting cardholder data, is obscured in the process. An example of such a case is Acme Merchant, whose customer data is stored on a mainframe system. With appropriate compensating controls, Acme may not have to encrypt (or otherwise render unreadable as per 3.4 of the PCI DSS) Primary Account Numbers that are resident within the mainframe environment. In fact, encryption on mainframe systems is one of the few areas where acquirers and card brands almost expect compensating controls due to
the complexity and cost associated with encrypting data. However, it is not uncommon to hear of merchants whose Qualified Security Assessor has informed them that they must remove the data from the mainframe, port it to a Linux or even a Windows environment, and then encrypt the data to meet the technical specification of the stated requirement. Not only is the expense associated with such a suggestion onerous, but there are also definite security implications. While the company may now be "compliant," it is debatable as to whether or not that data is any more secure.
Another example that frequently arises is that of encrypted backup media stored offsite. Consider the example of a large merchant that has 10 years of backups stored offsite unencrypted. The data is not accessible from the network and the only risk is associated with physical compromise of the media. It is not uncommon to hear of QSAs, and even acquirers, requiring that merchants remove the media from storage, encrypt the media and then return it to secure storage where it will remain for years to come. Again, while this meets the stated requirements, it is debatable as to whether there has been an appreciable reduction in risk. More importantly from this writerÕs perspective, is that valuable resources have been diverted from other projects that could have had a real and immediate impact to the risk associated with the cardholder data and instead have been directed toward a project that that would likely not have a measurable impact on the security of the data.
It is a reality that in today's business environment resources are constrained. In the current economy companies are cutting budgets, downsizing staff and generally tightening the proverbial belt. For this reason, ensuring that a risk-based approach is employed when considering compensating controls is critical. To ensure that organizations are both achieving compliance and doing so in a secure manner, as opposed to "chasing compliance", there are important points that must be considered. First, QSAs cannot determine whether a company is able to consider compensating controls. Compensating controls may be considered for any requirement (except 3.2) if the company has either 1) a legitimate technological or 2) a documented business constraint. As such, the first step is to determine whether a constraint exists. If one does, then compensating controls may be employed, irrespective of the QSA's position. Second, the goal of the PCI DSS is to protect cardholder data, not to force companies into compliance with an arbitrary standard. If your organization has developed a novel and secure method of protecting cardholder data while not meeting the "letter of the law," it may likely be compliant. Finally, if an organization is not educated on the specifics of the standard, the intent of the requirements and the goal of the PCI DSS, they are going to be at the mercy of their QSA's interpretation and expertise.
Compliance is a fact of life in the industry. However, blind obedience to a standard is not. Understanding the objective of the standard in question and taking steps to meet that standard does the industry at large a greater service than simply "checking the box." Achieving the state of what can be termed "intelligent compliance" requires education - an understanding of the PCI DSS, the industry as a whole and data security.
Synthesizing these domains allows companies to achieve the protection of cardholder data as well as their own business objectives. The evolution of compliance in the payment card industry has come to a point at which the organizations required to comply must empower themselves to navigate their own course, or they will be subject to the interpretations of others not invested in the overall success of the company. 
|
