Is compliance with standards achieving the goal of protecting data?

* Compliance: An issue of substance

The prevalence of data theft has led to increased enforcement of compliance with standards to protect data - surely a Good Thing, right? Well, maybe not in the way compliance is sometimes being enforced. Longtime colleague Bob Gezelter contributes his thoughts today on the unreasoning application of security standards. Everything that follows is Bob's work with minor edits.

* * *

In January, Heartland Payment Systems suffered a large-scale security breach that appears to have compromised information relating to 100 million credit-card accounts. Heartland is a large-scale third-party transaction processor. Processors of that size should comply with various security standards, including the Payment Card Industry’s Data Security Standard (PCI DSS). At the time of this writing (end of January) it is too early to find details, but the incident prompts me to ask whether compliance with standards is achieving the goal of protecting data.

Recently, my modest information security consulting firm was required to undergo compliance scanning under provisions of the same PCI DSS. The process had some requirements that were logical and appropriate but also some requirements that were illogical in our context. However, compliance with all of the requirements was mandatory, regardless of how irrelevant.

We deal mostly with corporations, which rarely use credit cards. Our few credit-card transactions are processed using a financial-grade, SSL/TLS-enciphered connection to a major payment processor from a conventional Web browser (e.g., Firefox, Internet Explorer) – just like any normal Web commerce. No electronic copy of credit card-related data is stored on any of our computer systems.

However, since the SSL/TLS-enciphered connection traverses our Internet connection, full compliance is obligatory. The requirements fit several categories:

• Reasonable.

• Not reasonable for our configuration.

• Not compliance-related – idiosyncratic behavior of the programmed script verifying compliance: if the script does not see the precise response expected, non-compliance is reported, even if there is no actual non-compliance.

Several check-off items on the compliance review relate to problems which are deemed “Denial of Service” or “May lead to privilege escalation.” Indeed, this presumption may be so for many Windows and *IX (e.g., Unix, Linux, AIX) systems running popular software packages such as sendmail. However, our Web server does not run one of those systems, nor is our server in the path of PCI data processing. Our server runs HP's OpenVMS. Our Web site is served using the public domain WASD Web server. Indeed, one of the showstopper problems was nothing more than a testing script that presumed Windows/*IX file naming conventions.

Yet, despite several requirements that all transmissions involving PCI data be encrypted, there is no requirement that the encryption be based upon a X.509 certificate issued by a generally recognized Certification Authority

Once data are properly encrypted, they are opaque. If financial-grade SSL/TLS is not sufficiently opaque to block eavesdropping and prevent tampering, then there are serious problems with far more systems than just those involved in PCI processing.

A more likely scenario is that of a bouillabaisse: all the requirements related to security get tossed into the stew. For the requirements that make sense, this does no harm. For those which are not appropriate for a merchant’s configuration, there is a problem. For those hosting their own Web stores with payment processing, these requirements are reasonable. For those who do not fit the obvious model, the checklist can be like ill-fitting clothing: at best uncomfortable, at worst unwearable.

In some ways, this situation is reminiscent of what transpired when college programming instructors tried to standardize grading practices using metrics (see for example the discussion of metrics in Aivosto’s Project Analyzer software). Students were required to comment at least a stated percentage of the lines in their programs. Students quickly learned that even silly, nonsensical comments were accepted toward that benchmark metric. The result was predictable: students put in useless, uninformative comments to comply with the rule, and the instructors were obliged to accept that they had complied with the requirement to comment the stated percentage of their code.

The inappropriate PCI DSS requirements serve the interests of none of the parties involved: neither the consumer, the merchant, the processor, nor the compliance authority.

A more extensive discussion of this problem is online in “Securitization: A Risk to Compliance Integrity.” 

* * *Web site. He is the author of the “Mobile Code” and “E-Commerce and Web Server Safeguards” chapters in the Computer Security Handbook, 5th Edition, edited by Seymour Bosworth, M. E. Kabay and E. Whyne (2009), published by John Wiley & Sons. 

Robert Gezelter, CDP, has 33 years of experience in operating systems, networks and security consulting. He can be reached via his firm’s

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT