PCI DSS

You are currently browsing the archive for the PCI DSS category.

Heartland Payment Processor Breach

Another day, another major breach of credit card data. And this one is a doozy. The payment processor Heartland Payments Systems on January 20th that they had suffered a breach and an unknown number of credit card accounts had been compromised. Heartland is the 5th largest payment processor in the world, with over 250,000 customers and handling over 100 million transactions per month. It is likely this breach will result in the compromise of more accounts than the infamous TJX breach of 2006 in which approximately 95 million card accounts were exposed.

It appears this hack was a result of poor endpoint security and a lack of encryption of data in motion. I will start by stating that Heartland was in compliance with the PCI DSS and had been audited in April of 2008. That being said, PCI DSS compliance does not guarantee that data is secure. It is a good starting point, but more can and should be done, to ensure the protection of cardholder data.

Back to the Heartland hack; according to the information I have read so far, it appears that some number of systems in their cardholder data environment became infected with spyware that was able to sniff credit card account information while being transmitted over the network. If this is true, it validates my belief that endpoint security is often times the weakest link in the enterprise security environment. I have no doubt that these systems had anti-virus software installed. However, anti-virus software is only as good as their signature database and most are woefully inadequate at detecting malware, especially custom malware. In environments with high security concerns, it is appropriate to utilize application whitelisting utilities that allow only those applications that are specifically defined to execute. These utilities don’t rely on signtures and significantly reduces the threat of malware.

The other problem in the Heartland environment was the fact that credit card data was being transmitted between them and the card companies in clear text. The reason this was not highlighted as a violation of the PCI DSS is because many payment processors use dedicated leased lines to the payment brands, which is often cited as a compensating control for the use of encryption. Clearly, this is a weak compensating control that allows for unfettered access to information on the network in the event that a workstation or server is compromised. Best practice would dictate that account numbers should be encrypted over the network, which is easily achievable with a variety of methods. Defense in depth is lesson to be learned here.

Finally, it appears that Heartland did not have very strong logging and monitoring controls in place as they did not detect the malware themselves. They were notified by Visa and Mastercard of suspicious activity coming from their network. Once notified, Heartland took nearly two months to disclose the breach. It appears their handling of this incident may be in violation of several state laws. If the scope of the breach is as large as is being reported, Heartland may end up spending $100 million dollars or more to deal with this incident. They are already facing a lawsuit as a result of the incident. This is far more money than it would have cost to secure their endpoints and encrypt data in motion. Look for the PCI DSS to be amended as a result of this incident to address these issues.

My Latest Experience With Credit Card Fraud

creditcard

Well, it has happened again.  One of my credit cards has been used to make unauthorized purchases.  I was contacted about a month ago by my issuing bank to inform me of suspicious purchases at a grocery store and restaurant in Arizona.  I presumed (incorrectly) that because I live in North Carolina and did not make any airline ticket purchases or show a pattern of purchases that would lead them to believe that I was in Arizona, the card issuing bank became suspicious and contacted me.  Once I informed them that I did not make the purchases and that the card was still in my possession, they immediately canceled the account and issued me a new card.  I was impressed with their monitoring system that was able to detect this fraud so quickly.  I discovered later that the bank was not as proactive as I had assumed.

This is not the first time this has happened to me.  A couple of years ago this same card was used to make fraudulent purchases on a web site.  In that case, I notified the bank of the fraudulent transaction after seeing it on my statement.  I never did figure out how my card information was obtained during that incident, but something interesting happened recently that I believe explains how the criminals got a hold of my card data this time.  It also explains how the bank noticed the unauthorized charges so quickly.

A few days ago I received a letter in the mail from a major hotel chain stating that they had suffered a breach and that my credit card information had been stolen. I only stayed at this particular hotel once about two and half years ago and I used this credit card to pay for the room.  According to the letter, a “sophicated hacker” had gained access to the computer systems of one of their franchises and was able to access “customer transaction files at a number of other hotels” to obtain credit and debit card data.  Aha.  Given the timing of the incidents it seems probable that the fraudulent transactions were a result of this breach.

To the hotel’s credit, they did at least have some detective controls in place that discovered the breach and appropriately alerted both the payment card companies as well as affected customers.  This is how my issuing bank detected the fraudulent charges so quickly.  They had a heads up.  However, the hotel was clearly not in compliance with the PCI DSS.  Credit card data is supposed to be encrypted when stored, which would have prevented the hacker from being able to read this sensitive information.  And if it was encrypted, then they did not properly manage the encryption keys, which again, is a violation of the PCI DSS.

One of the most important things for any company that stores sensitive information, such as credit card data, to do is implement controls to delete such data after a certain period of time.  There is no reason to store credit card data for two and half years, especially if there is not a recuring transaction.  By limiting the amount of sensitive data that is stored to the absolute minimum necessary for business purposes, a business can reduce its risk and mitigate the resulting damage in the event of a security breach.  No doubt this hotel chain is spending much more on cleaning up after this incident than it would have had it followed this advice.

PCI 1.2 and Anti-virus Software Requirements

Last month the PCI Security Standards Council released version 1.2 of the PCI DSS. There were a number of updates and changes to the standard, most of which I have already written about. I want to revisit Requirement 5 of the PCI DSS which relates to the use of anti-virus software on all systems in the cardholder data environment. Version 1.1 states the following:

Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers) Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.

Version 1.2 changes the requirement as follows:

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Notice that they removed the note defining which types of systems are not typically affected by viruses. I attended a seminar recently by David Wallace, a noted PCI DSS expert and someone who is very involved with the PCI SSC. His explanation was that the council wants remove the “pass” that Unix and Linux systems had for not deploying anti-virus software. There have been a number of viruses released in recent years that affect Unix-based operating systems. Also, there are several vendors that now sell anti-virus products for various flavors of Unix and Linux including Red Hat Linux, Solaris and MacOS. These vendors include Trend Micro, McAfee and ClamAV.

The best way to meet this requirement is to install anti-virus software on any system within scope for which a solution exists. Obviously, systems such as IBM’s I-Series and Mainframes would be excluded. But systems running Solaris or RH Linux should have anti-virus software installed if one exists for the particular version you are running. Furthermore, there really is not a compensating control for this requirement. If anti-virus software exists for the system in question, it must be installed. I cannot think of a compensating control that provides a “similar level of defense” as the original requirement.

PCI DSS 1.2

Last week the Payment Card Industry Security Standards Council (PCI SSC) released the first update to the Data Security Standard (DSS) in more than two years. Version 1.2 of the DSS provides some much needed updates and clarifications to the 1.1 version of the document and is the official document as of October 1, 2008. While the standards council claims not to have introduced any new requirements in this version of the document, some of the changes are significant and represent more than just clarification. During a recent PCI DSS security assessment, I found the following changes to be most noteworthy:

  • Compensating Controls

The PCI DSS version 1.2 has much stricter language with regards to compensating controls. Every compensating control must be reviewed, documented and validated by an assessor annually. Furthermore, for each compensating control the Compensating Control Worksheet must be completed. These changes clearly signal the security council’s intent to make it more difficult for merchants to use compensating controls rather than meeting the requirements of the DSS.

  • WEP Encryption

WEP encryption for wireless networks may no longer be implemented for new networks after March 31, 2009. And wireless networks currently using WEP encryption must migrate to industry best practices (e.g. 802.1x) by June 2010. While these requirements are not terribly difficult to meet, merchants need to be aware of this as they roll out new wireless networks or plan to upgrade current WEP enabled WiFi networks.

  • Anti-Virus Software

Both versions 1.1 and 1.2 of the PCI DSS state that anti-virus software must be deployed on “all
systems commonly affected by malicious software (particularly personal computers and servers).” However, in version 1.2 the security council removed a note stating that viruses typically do not affect Unix-based systems and mainframes. This has led some to interpret the requirement to mean that ALL systems must run anti-virus software. However, I would argue this is not the case. The requirement does state “systems commonly affected my malicious software.” To me this would not include mainframes or i-series systems from IBM for example. One could even argue that Solaris, Apple, and Linux systems are not commonly affected by malicious software. My advice would be to run it wherever possible and practical.

  • Patch Installation

The new version of the standard provides more leeway in the patch installation process. Version 1.1 specifically required that security patches be applied within 1 month of release. The new version allows companies to apply a risk based approach which fits better into most enterprises’ vulnerability management programs and will ultimately lead better overall security. Patches can be applied to more critical systems first and less critical ones can be updated later.

  • Video Cameras

Version 1.1 of the DSS required the use of video cameras to monitor sensitive areas. The new version provides the possibility of using other access control mechanisms to monitor access to sensitive areas. Potentially this could include card keys that would provide a date and time stamp each time someone entered a data center for example. Biometric access control mechanisms could also be employed. Standard keys and keypads would NOT meet this requirement as they do not provide the ability to monitor access to sensitive areas.

  • Service Providers

Version 1.2 of the DSS provides more detailed requirements when dealing with service providers that have access to cardholder data. The merchant must maintain a list of all such service providers, ensure that the service providers are PCI DSS compliant and monitor their compliance, maintain a written contract with the service provider stating that they are responsible for the cardholder data, and establish a process when selecting service providers to perform due diligence. These requirements force merchants to work much more closely with their service providers and be aware of their service providers’ PCI DSS compliance status.

To view the new version of the PCI DSS as well as other related documents, go the official PCI SSC web site at .

Copyright © 2011 InfoSecStuff.com — All Rights Reserved