Is compliance with standards achieving the goal of protecting data?

The long view of security strategies for your network.

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.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

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.

M. E. Kabay, PhD, CISSP-ISSMP, specializes in security and operations management consulting services and teaching. He is Chief Technical Officer of Adaptive Cyber Security Instruments, Inc. and Associate Professor of Information Assurance in the School of Business and Management at Norwich University. Visit his Web site for white papers and course materials.