Tip

Data security best practices for PCI DSS compliance

    Requires Free Membership to View

 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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

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:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.