Data security best practices for PCI DSS compliance

The glut of recent data breaches, such as the one at Heartland Payment Systems Inc., leaves some security pros wondering if PCI DSS is doing its job. Is it worth all the effort to become PCI compliant if breaches still seem inevitable? In this expert tip, learn about key data breach-prevention issues that PCI doesn't mandate that can keep your enterprise from embarrassing compromises.

 PCI is not perfect, but the point isn't perfection.
,

Every time a company that is compliant with the Payment Card Industry Data Security Standard (PCI DSS) is breached, the masses form with their torches and pitchforks and declare that PCI doesn't work. This was the case with two recent high-profile data breaches: the March 2008 Hannaford Bros. Co. data breach and January's Heartland Payment Systems Inc. breach.

The problem isn't that PCI doesn't work. The problem is the perception that if a company is PCI compliant, it is secure and will never suffer a data breach. The reality is that PCI, like any other regulation -- be it HIPAA, GLBA, etc. -- merely sets a baseline for what needs to happen in order to handle certain kinds of data securely and to avoid fines, loss of services or license to operate. In the case of PCI, it means that when (yes when, not if) a merchant or other company involved in the payment-processing life cycle faces a security problem, it won't be fined by Visa, Mastercard or one of the other members of the PCI Security Standards Council.

For more information
Is your enterprise virtualizing? Check out this preview of PCI virtualization specifications.

Learn best practices for merging with a company that is not PCI compliant.

PCI is not perfect, but the point isn't perfection. Rather, the idea is to raise the bar to a reasonable level. PCI DSS version 1.2 has corrected several issues from earlier iterations, and the standard will surely continue to evolve as the PCI SSC identifies portions that don't work well or issues that were missed in the past. Case in point: in both the Hannaford and Heartland breaches, the miscreants were using Trojans to pass personally identifiable information (PII) to external servers over the Internet. It would be surprising if the next version of the PCI standard did not mandate some sort of monitoring of outbound data flows for PII.

In the meantime, this kind of monitoring is something that you should be doing at your organization, and it likely goes beyond just deploying a data leak prevention (DLP) product. Given that cybercriminals are increasingly using cryptography, it's also necessary to perform traffic analysis. This is a great strategy because it enables discovery of anomalous traffic quickly without actually looking into the packets. Think of it as an early warning system.

Don't miss need-to-know info!

Security pros can't afford to be the last to know. Sign up for email updates from SearchSecurity.com and you'll never be behind the curve!

Another area to look at improving beyond the requirements of PCI is the use of SNMP. PCI currently mandates changes to the default SNMP community strings. While this is a good idea, it isn't enough. SNMP is an insecure protocol; it is notorious for being unencrypted by default, and it doesn't do any good to turn on encryption everywhere else if management credentials are passing through in the clear. So, if possible, turn it off. If you have to use SNMP, at least use v3, which encrypts the data in transmission. Be sure to use AES instead of DES. Keep in mind though that this method still uses a static key, so while it's an improvement, it is far from perfect. Again, if possible, turn off SNMP.

The third area to improve beyond PCI is backups. A huge number of the CA-1386-related breach disclosures have been due to lost backup tapes and drives as opposed to theft. As a result, I'd recommend that reviews of the security of outside providers be done semi-annually (instead of annually, as PCI dictates) and that these reviews extend not only to the actual storage, but also to media-tracking processes and procedures, including how loss is identified and handled. I also highly recommend regular and random testing of these procedures.

These are just three examples of places that a security program can be improved beyond the requirements of the PCI DSS. I encourage security teams to look at all 12 sections of the standard and find other places to improve, and share those improvements with your peers.

About the author:
As CSO-in-Residence, David Mortman is responsible for Echelon One's research and analysis program. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his team were responsible for Siebel's worldwide IT security infrastructure, both internal and external. He also worked closely with Siebel's product groups and the company's physical security team and led up Siebel's product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds a BS in Chemistry from the University of Chicago.


This was first published in March 2009

Dig deeper on PCI Data Security Standard

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close