PGP Blogs

Compliance – A Necessary Yet Insufficient Test of Security
Tuesday, September 22nd, 2009

Brian Tokuyoshi – Product Marketing Manager

The PCI Data Security Standard brought the issue of data encryption to light for many organizations. It established a baseline for security practices that highlighted some of the things that best-of-class security organizations already knew, such as specifying the types of data that must be protected and how to avoid risky practices that could expose such information to unauthorized access. It was necessary because the card processing industry is extensive and there needed to be guidelines to bring all the participating companies up to spec.

Yet it still appears to be clear that there are lingering misunderstandings about what it sought to achieve. From the viewpoint of the industry, it is easier to understand its purpose, for it gives the credit card industry better assurances to its customers that all the companies handling personal information have met a minimum set of security standards. From the viewpoint of the organization undergoing the PCI audit process, the purpose does not seem to be universally understood.

For example, what about issue of responsibility? Clearly, the intent of PCI DSS was not to take the responsibility of providing security away from its memberships, and that its guidelines were measures of what they considered to be the starting point for a security practice. The auditor’s role is to ensure that member organizations measure up to the specification, but the auditor doesn’t necessarily go beyond the benchmark. That’s how it works from the industry’s viewpoint, but apparently to the audited company, that’s not always so clear.

CardSystems Solutions is a payment processor that experienced a data breach in 2004, even though it had passed a Cardholder Information Security Program audit (a precursor to PCI DSS). CardSystems Solutions is now seeking damages from its auditor. This case is actually more complex than it appears on the surface, with a number of fascinating issues about the business of auditing and compliance. This lawsuit could redraw the lines about the roles of each party (the auditor, the audited company, and the standards authors). It could also mean that auditors may need more liability insurance, which would drive up the cost of compliance even further.

Data breach notification laws, such as California SB1386, is actually a tougher benchmark than PCI DSS by being less specific (as opposed to more specific) about the required tasks. Data breach notification laws do not specify a course of action to meet compliance, but rather prescribe the penalty for the loss of data. It is clear and unambiguous that responsibility to protect data rests solely on the holder of confidential information. It changes the economics so that failure to properly protect consumer data becomes a financial risk to the company, and companies quickly ascertain that they must do whatever is required to keep data safe regardless of the audit “standards”. There is no transference of responsibility, because as possessors of the consumer data, they must keep it protected. There is no auditor to sue or compliance standard to blame.

Whether it is compliance or data breach notification laws, the drive to protect consumer information is a good thing. It will be interesting to see how the CardSystems case pans out, because it will have a number of repercussions throughout the industry. Nevertheless, the fundamentals for data protection remains the same, and getting started on ensuring that information stays encrypted and building on top of a proper long term strategy for data protection is something that’s good for everyone.

Filed under: Perspectives
Tags: CardSystems Solutions, PCI-DSS
Comments: No Comments

PCI DSS is a Game of Catch Up
Friday, May 15th, 2009

Brian Tokuyoshi – Product Marketing Manager

One of the problems of the Payment Card Industry Data Security Standard is that it will never reach a state of completion. That’s because PCI DSS it defines protections against known security risks, and then maps out a list of things that it must do to meet the minimum requirement for an acceptable level of security.

The goals of PCI DSS are noble, for it establishes practices for handling of sensitive data, and thus ensures security experts address the issues that can’t be taken for granted anymore.

The problem, though, is that PCI DSS sets up the requirements in a way that creates checklists of technology to deploy, which prescribes protection against the known threats. You can’t prescribe a solution to a problem you don’t know about and thus PCI DSS will always lag behind new, emerging threats.  The danger is that companies who have achieved compliance to a current flavor of the standard might rest on their laurels and not proactively do something about the new threads.

For example, what would have happened if the first PCI DSS spec came out 10 years ago? It might talk about the requirements for firewalls, because perimeter security was the primary defense against the bad guys at that time Meanwhile, new inside threats such as malware, wireless access points, and sniffer bots still would be able to operate freely while the organization remains confident they were secure due to meeting the state of the specification at that time.

Based on a new article from Wired Magazine, there is a new attack that goes straight after information that was supposed to be guarded by the PCI DSS specification.  The PIN associated with an ATM card must be encrypted, as specified by the PCI DSS specification. The problem, however, stems from the fact that the PIN is decrypted and re-encrypted by various systems. Meanwhile, hackers discovered a way to take the PIN number, using techniques such as tricking the Hardened Security Module (HSM) into revealing the encryption key used to protect the PIN.

The article cites the manufacturer and states that the issue is largely the result of misconfigured HSMs, and states that “lazy administrators” are to blame. The PCI Security Standards Council is currently working on recommendations for HSMs, but clearly there is a window open for criminals right now while attacks are underway.

Compliance isn’t an end game scenario and completing a PCI audit isn’t a guarantee of safety against the bad guys. Compliance is also not safe harbor against data breaches notification obligations.  What’s important is to stay ahead of the game and be proactive about emerging threats, and recognize the limitations of what compliance affords you.  PCI compliance is a good place to start your security policy, but keep in mind that true security requires a higher standard of vigilance and data protection.

Filed under: Perspectives
Tags: HSM, PCI-DSS, Wired Magazine
Comments: No Comments

Compliance Doesn’t Necessarily Mean You’re Safe
Monday, February 2nd, 2009

Kevin Albright – Product Marketing Manager

By now I’m sure you’ve heard about last week’s breach at Heartland Payment Systems. The number of total records compromised has not yet been released, but given California’s SB 1386 we should be hearing some sort of estimate soon. What is known is that Heartland has contacted 150,000 merchants that it processes payments for and it handles roughly 100 million credit card and debit card transactions per month. Given that this breach is suspected of starting in October 2008, the quick and dirty math should give you a rough estimate of how big this breach is…Huge! Already companies have been contacting customers, issuing new cards, and we are all put on alert to watch our credit card and debit card statements in the coming months.

The interesting thing about this breach is that Heartland was PCI compliant, and that the nature of this breach fell within the rules of the PCI-DSS v1.2 published October 2008 (ironically the same month the suspected breach began). Reportedly malicious software found its way into Heartland’s data center and began sniffing traffic off private leased lines carrying transactions between systems. This traffic was unencrypted and an easy target for a simple sniffer program extracting credit card numbers in the plaintext transmissions. The malicious program then sent the gathered credit card information to a collector system (I wonder if they encrypted it?). Visa and MasterCard contacted Heartland last month on reports of numerous fraudulent charges on cards that had been processed by them.

PCI-DSS standard v1.2 requirement 4.1 states “Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.” It also requires encryption when transmitting over wireless networks and when using end-user messaging technologies such as e-mail, chat and IM. However, the standard does not require any form of encryption when transmitting credit card data across private network segments as was the case at Heartland.

Heartland’s website 2008breach.com posted the following statement in its press release on January 23rd ,”For the past year, Carr has been a strong advocate for industry adoption of end-to-end encryption — which protects data at rest as well as data in motion — as an improved and safer standard of payments security.”

Beyond the failed Secure Electronic Transactions, or SET, initiative of the 1990’s that attempted to ensure that the data is secured between merchant and processor when transmitted over ‘insecure networks’, the simple inclusion of encryption in these transactions whether over ‘secure’ or ‘insecure’ networks could have prevented this incident altogether.

Filed under: Perspectives
Tags: breach, Heartland Payment Systems, PCI, PCI-DSS, SB 1386, SET, sniffer, SSL/TLS
Comments: No Comments