International Merchants with EMV no longer need to have PCI Compliance validated


From Visa Bulletin today: Visa Introduces Technology Innovation Program for Merchants, Visa announces that:

Effective 31 March 2011, Visa will allow qualifying merchants outside of the United States to discontinue their annual Payment Card Industry Data Security Standard (PCI DSS) revalidation assessment.

Note that this doesn’t mean that if you use EMV you are exempt from PCI Compliance (more on this below)

It is nice to see that Visa is rewarding investments in EMV and Card Authenication with a potential of lower PCI compliance costs:

Many merchants have invested time and money in the purchase, deployment and enablement of EMV POS terminals. These merchants have also invested in annual PCI DSS compliance assessments, which may require the use of a Qualified Security Assessor and can be a significant expense. Visa is introducing the Technology Innovation Program to assist merchants in reducing the costs associated with annual PCI DSS validation.

If you are a non-US merchant and perform the following you are a qualified merchant:

1. The merchant must have validated PCI DSS compliance previously or have submitted to Visa (via their acquirer) adefined remediation plan for achieving compliance based on a gap analysis.

2. The merchant must have confirmed that sensitive authentication data (i.e., the full contents of magnetic stripe CVV2 or PIN data) is not stored, as defined in the PCI DSS.

3. At least 75 percent of the merchant’s transaction count must originate from enabled chip-reading device terminals (i.e., contact and/or dual interface contact/contactless terminals).

4. The merchant must not be involved in a breach of cardholder data. A breached merchant may qualify for TIP if it has subsequently validated PCI DSS compliance.

What about US Merchants ?

Visa has this to say about this program in the United States:

Despite industry interest in chip and dynamic data authentication, the program is not currently available in the United States because recent debit card regulation has cast uncertainty in the marketplace. Visa Inc. may consider implementation of TIP in the United States at a later date based on evolving environmental circumstances.

I think this announcement adds a new dynamic in the form of a potential incentive as it relates to EMV adoption in the US. US Merchants may now, in the near future, have an incentive or a discount to consider for EMV implementation (assuming implementation of EMV processing infrastructure) in the form of less annual PCI compliance validation costs in the form of on-site audits to offset implementation of new card acceptor devices and updated payment software to support EMV.

If I use EMV we don’t need to be PCI compliant !!!

This is a fallacy that I fear that will echo. This announcement relates to the validation of compliance, not for on-going compliance to the PCI DSS, as stated by Visa below:

Although Visa may waive the annual validation requirement for qualifying merchants, all merchants are still required to maintain on-going PCI DSS compliance. Acquirers retain full responsibility for merchants’ PCI DSS compliance, as well as responsibility for any fees, fines or penalties, which may be applicable in the event of a data breach.

OLS is PCI Compliant


Just a short note to share that OLS has received word from our QSA via a “PCI Certificate of Validation” Letter for our newly launched hosted payment service offering OLS.Host. Congrats to our Operations, Systems and Security Gurus for all of their hard work on this !

PCI Council : Wireless Security Guides for Payment Cards

There are few news articles today that reference this article. - That talks about the PCI Council “Publishing” a Wireless Security Guide for Payment Cards Update July 17/2009 - The Guide is now listed on the PCI Co Website and direct link is here. From the Article these appears to be the relevant things from the Guidelines:

  • The guidelines requires “a firewall that demarcates the edge of the organization’s CDE - cardholder data environment
  • To combat the problem of the rogue access point, businesses will need to use a wireless analyzer or preventative measures such as a wireless intrusion detection/prevention system (IDS/IDP) regularly
  • The council is advising large organizations to set up automated scanning using a centrally managed wireless IDS/IPS system.
  • The guidelines suggest quarterly scans each year to detect rogue wireless devices that could be connected to the CDE at any location and have an incident-response plan to deal with them.
  • To isolate wireless networks that don’t transmit, store or process cardholder data, a firewall must be used, and it has to perform the functions of filtering packets based on the 802.11 protocol; performing stateful inspection of connections; and monitoring and logging traffic allowed and denied by the firewall according to PCI DSS rule 10. The firewall logs would have to be monitored daily and the firewall rules verified once every six months.
  • The wireless guideline also says “relying on a virtual LAN (VLAN) based on segmentation is not sufficient.”
  • For “in-scope wireless networks,” physical security should apply, with options that include mounting wireless access points high up on a ceiling and disabling the console interface and factory rest options by using a tamper-proof chassis.
  • Change the default settings of the access points in terms of default administrative passwords, encryption settings, reset function. Disable SNMP access to remote access points if possible. Do not advertise organization names in the SSID broadcast.
  • Use of AES encryption is recommended for WLAN networks. Specifically, information flowing through certain network segments, including secure wireless devices that connect to the private WLAN through the access points, must be encrypted.
  • Wireless usage policies should be established for “explicit management approval to use wireless networks in the CDE.” Usage policies require labeling of wireless devices with owner, contact information and purpose.

Integrated Solutions For Retailers - PCI DSS: What Do You Know, Where Do You Stand?

The Integrated Solutions For Retailers Magazine has an articled titled PCI DSS: What Do You Know, Where Do You Stand?

For a couple of months spanning the first and second quarters of this year, Integrated Solutions For Retailers surveyed its subscribers — hundreds of retailers from many segments, ranging the gamut from small and regional chains to tier-one enterprises — on their perceptions of the PCI DSS (Payment Card Industry Data Security Standard). The survey results surprised us. Respondents exuded nearly equal parts confidence, confusion, dismay, and ignorance. Some gloated. Some swore.

Some very interesting comments here, some of my favorites:

  • From a regional grocer: “We’ve devoted no effort. PCI certification is an impossible-to-hit, moving target.”
  • Only 23.9% of retailers surveyed indicated that they’re “very familiar” with the PCI DSS.
  • 59.6% say fear of a breach is their motivation for achieving compliance.

Read it here.

One Lesson from the heartland that we should all learn from and 'get' by now.

Photo by davethelimey

Ellen Richey, Chief Enterprise Risk Officer for Visa, Inc said the following at the Visa Global Security Summit

“As we’ve all read, the company had validated PCI compliance. But it was the lack of ongoing vigilance in maintaining compliance that left the company vulnerable to attack. Based on our findings following the compromise, Visa has taken the necessary step of removing Heartland from its online list of PCI DSS compliant service providers.”

I remember someone asking me when news of this breach first hit the news – “But weren’t they PCI compliant ?” “How could they have been breached, weren’t they secure” ?

I’ve discussed this here before here (PCI Compliant Control Breakdown) and here (Compliance != Security - the Titanic illustration).

I really think the the Heartland Breach is the linchpin event to people of these three important concepts:

  1. PCI is a baseline of minimum controls that need to be implemented to generally reasonably protect data across the broad spectrum.
  2. Security goes “above and beyond” the minimum required for compliance and should use a risk based approach specific to your business and operating environment.
  3. Maintaining compliance must be a ongoing process, it is not a once a year thing.

Case in Point: - a sales professional that I work with, attended the Prepaid Expo USA recently and shared this from his notes on one of the sessions on Prepaid Card Processing:

PCI is NOT enough. It is an ongoing process and we are all playing the “catch up game” much like the anti-virus world.

Please don't display my CVC2 number on your order confirmation page

I ordered a set of tickets for an event this summer from a website and was surprised to see my clear text CVC2 (CVC2 is for Mastercard, CVV2 is for VISA).

3-16-2009 8-25-45 AM

Not a real good design, in my opinion, to display the entered card security code :(

Detecting swapped PIN Pads at the Payment Switch


My colleague Andy Orrock writes an excellent post, “Methodology for watching PIN Pad Switches” which discusses a detective control that we put in place in OLS.Switch to detect when a PIN Pad has been changed at the point of sale, along with real time alerting of the event.

Digital Transaction has an article here, that discuses this type of attack, another summary is here and quoted below:

Investigators say the men would enter supermarkets late at night, distract the cashier and swap a PIN pad with an alternate machine that recorded each customer’s financial data. They could swap the equipment in as little as 12 seconds, prosecutors said.

After a while, the men would return, retrieve the machines and harvest the credit and debit card information. At least six supermarkets in Rhode Island and Massachusetts were targeted, and 238 people lost money.

Another consideration to make, is the physical security of payment terminals and pin pads, such as bolting them down or using locking stands and regular inspections. See Verifones PIN Pad Security Best Practices for more.

PCI Compliant Control Breakdown

I read an interesting analysis (during my morning RSS Grind) on Branden Williams blog - titled “PCI Compliant Companies Don’t Suffer Breaches

There is a big misnomer out there that needs to be cleared up. […] In our investigations of PCI related breaches, we have NEVER concluded that an affected company was compliant at the time of a breach. PCI Assessments are point-in-time and many companies struggle with keeping it going every day.

These leads us to the nuance between PCI compliance and PCI Validation - Mike Dahn does a great job here at this post:

Compliance vs Validation

There is a difference between ‘compliance’ and ‘validation’. Compliance is a state of being, one that must be maintained at all times. Validation is a point-in-time check on that state of compliance. The example I give is auto insurance. In order to comply with state laws I must maintain auto insurance at all times. When I go to register my car I have to show proof of insurance. I am validating my compliance with the law. What if I decide to cancel my insurance because it costs too much? Am I still compliant? No. Now, I still validated, but remember validation is a point-in-time while compliance is measured day by day.

One of the first things that people asked when they heard about the latest cardholder breach, it was “weren’t they PCI complaint” ? If you look on the Visa List - you will note the validation date and QSA that performed the review. It is important the understand the Validation Date - that was the last date of the review - that is a point in time where a QSA considered the organization it reviewed “compliant”.

So how is this possible ?, Well an example that I can think of is brushing your teeth really well before going to the dentist, or how many companies fear auditors and get really busy before and audit because of the things they need to do because the auditors are coming ? Do people continue to brush their teeth with this vigor after the dentist visit ? perhaps they floss for a week or so, but behavior is hard to change and people go back to their normal routine. The focus of many organizations is on passing the audit.

I briefly touched on this point when I blogged my thoughts on the Heartland Breach.

If you ever read through some of the actual audit procedures of PCI - notice what the auditors actually test: some tests are just based on Inquiry or documentation alone, furthermore some tests that do not test the operating effectiveness of some of these controls to a period of time.

The current focus is that on existence of a control and not its effectiveness.

Operating Effectiveness - that is defined as: “How an internal control was applied, the consistency with which it was applied, and by whom.”

Consistency - Should the PCI council consider reviewing the audit procedures and testing procedures to test for consistent controls ? Should PCI audits of large service providers or merchants require multiple visits by the QSA to test for this consistency ? Would it even help ?

Another last thought: Do QSA’s and auditors cheat on 2nd and subsequent year follow-up reviews ? Well, they passed it last year… - does the Report on compliance (ROC) look similar to that of previous years ? Was the control still tested like it was in the first year ? I guess some of this can be addressed (hopefully) in the PCI QSA QA program.

I agree with Branden that if one ever finds the real exploit that occurred at Heartland, it probably can be mapped ( even liberally squeezed ) to a current PCI control and is more then likely the result of a control breakdown and the controls poor operating effectiveness.

Two of my 2009 Predictions came true 2 weeks later


Two week ago I made of few predictions for Payment Systems in 2009 ( you can read that post here) Here are the two that I can cross off and pat myself on the back for.

Gift Cards: You or someone that you know will have a gift card, merchandise credit/refund card for a merchant that is no-longer is business in 2009. Gift givers will take note of this and consider giving cash rather then gift cards in holiday 2009 season.

From the Circuit City website: Circuit City would like to thank all of the customers who have shopped with us over the past 60 years. Unfortunately, we announced on January 16, 2009, that we are going out of business.

Will Circuit City stores continue to accept Circuit City GIFT CARDS?

Yes, customers holding Circuit City gift cards may redeem them at full
value at our stores during the liquidation sales. Once the stores are
closed and the company is out of business, the gift cards will have no

PCI Data Security Breaches: There will be data breaches of cardholder data in 2009. We will see more innovative attacks that replace those that were effective before PCI compliance was a wide spread. Even organizations that are validated “PCI Compliant“ will not be exempt. We will see attacks that adapt and change around current PCI Controls.

I blogged about Heartland Payment Systems here and shared my thoughts on the situation here, Yes this breach was at a PCI Compliant and Validated service provider, and the attack appeared to be one that was sophisticated and adapted around the current PCI Controls.

Heartland Payment Systems Breach - My Thoughts


You should all be aware of the Heartland Payment Systems Breach that happened on Inauguration day - had it been a different day it would be a front page story, perhaps it will be a front page story today? This post is to share my thoughts (that are speculation) based on my experience in payment systems and security rather than to re-hash the Heartland Press Release.

Let the pundits come: I can hear it now, “Was Heartland PCI Compliant ?” (They were/are btw, the QSA was Trustwave and they are listed as a compliant service provide dated April 30th, 2008) If they were PCI compliant how did a breach occur ? It is important to note (again, and again) that Compliance != Security. Compliance is a snapshot in time, PCI is not based on an organization’s own risk assessment of their environment. It is a prescriptive list of general IT Controls to be used as a baseline for “better” security then those organizations that are not compliant with the intent of reducing the risk of breaches. But you can be compliant and not secure, security is a process and constantly striving towards that end (it is like driving to infinity you never get there), is the goal, not compliance itself. I also expect to see merchants use this as an excuse – why are we spending all of this money for PCI complaint when attackers can successfully attack Processors anyway?

Processors and Service Providers are Fort Knox: Processors process for thousands of merchants and handle a large volume of transactions. Processors are in the business of processing card data, they require card numbers to communicate over the payment systems interchange networks as well as to provide settlement, clearing , and authorization files (among others) – The data of these files and message formats have account numbers, track data, cvv2 data (only the authorization messages include the last two) in the clear -but transmission is typically over a private leased line, use file level encryption, or transport level encryption, but there is a place in the “PCI-ZONE” of companies that sends this data in clear across the network - making sniffing the traffic a threat here. Can this be further controlled by further network segmentation and control at processors? I think so (topic of another post). Only the Payment Switch would need to have direct connections to these end-points not the full PCI-Zone.

Blame the QSA: Nobody has blamed the QSA yet, and I don’t know if anyone will, but I’m sure someone will try to; when breaches occur they are going to be asked what they missed ? What does that mean for QSA’s or IT auditors ? How do your work papers look ? Can a independent third party look at your work papers as evidence and come to the same conclusion as you? Did you test to the control or did you test something else ? Did you understand intent of the control ?

Issuing Banks: You don’t get to hear much of the story about the burden on Issuing Banks here. They have the cost of notifying cardholders, postage expense, customer service calls, brand perceptions problems due to confused customers, costs to reissue cards, etc. This includes both credit, debit, payroll, gift and others.

Press Release: Two things that got me about the Press Release, one was its timing, which may or may not be a coincidence, and the second was the focus was on the data that was not compromised, not the data that was. Like why not add: The cardholders’ favorite colors and cereals were also not compromised Account Numbers, Expiration Date and Track Data (Track 1 contains Name, Track 2 doesn’t) were compromised, cloned cards can be made from these “dumps” of magstripe data.

PCI Compliance: Remember that Service Providers and Processors where the very first to be scrutinized under Visa’s CISP and MasterCard’s SDP programs, and later PCI. The truth is that many processors and gateways should have close to 5 years or so of experience with PCI compliance and reviews if they are not a new service provider. Also: If you ever read through some of the actual audit procedures of PCI - notice what the auditors actually test: some tests are just based on Inquiry or documentation alone, furthermore some tests that do not test the operating effectiveness of some of these controls to a period of time.

Cost of the Breach: Anything that you hear is a guess - nobody knows for sure– (Well the card brands and affected issuers probably will) - we know that Heartland does 100 million in volume a month, and can safely assume that data was sniffed for a few months (some reports it as in place as early as May 2008) – we don’t know the unique number of card numbers nor do we know which card numbers are affected. I would guess around $600 million - based on cost of record at ~$6.00 and assuming 100 million unique card numbers were affected.

How did it Happen: Let’s look at the PR:

“ After being alerted by Visa® and MasterCard® of suspicious activity surrounding processed card transactions, Heartland enlisted the help of several forensic auditors to conduct a thorough investigation into the matter. Last week, the investigation uncovered malicious software that compromised data that crossed Heartland’s network.”

There really isn’t enough information here but let’s make an educated guess: We know that malware/software was installed. So we have the threat of physical security/social engineering that would install a piece of software, an OS or Application level attack, or a targeted piece of malware that was installed in the PCI Zone accidentally. Perhaps a combination of some of these. This type of Malware (sniffers) requires administrator system or root level access in order to sniff network traffic in promiscuous mode (in most cases.) There are ways to flood network switches to make them act as a hub to broadcast traffic, and there are also VLAN hopping attacks.

PCI 1.2.1 / 1.3.5

Let’s look at PCI 1.2.1:

“Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment”

and PCI 1.3.5

“Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ”

So the data would need to be collected and re-transmitted to a drop site, the drop site was probably actually multiple drop sites, and I’m guessing a well known outgoing port such as 443/SSL was used with encrypted payloads. These two PCI controls are intended to prevent outbound access from the cardholder environment, did these systems have outbound Internet access ? or if they did was it controlled ? and if it was controlled was it able to pass though the allowed outgoing traffic ?

Anti-Virus / Firewalls / Encryption: These are terms that are used to define ones security, Security is not a product - But let’s look at each of these briefly:

Anti-Virus - The effectiveness of Anti-Virus is poor, if you are familiar with services such as VirusTotal or have read something like this <-- This is why not all malware can be detected by Anti-Virus.

Firewalls - I swear I think people think that firewalls are magic devices – Hollywood and TV Land don’t really help here either. Understand what a firewall does - it works at the network layer and can either allow or block IP Address or ranges and port numbers, that is basically all they do. Granted, Application level firewalls and Web Application Firewalls can inspect the content of the traffic (I’m not talking about these)

Encryption: There are different types of encryption, each protects different things in different ways.So you you say something to the effect of:

“We have industry leading encryption”

Are you talking about File Level Encryption ? Disk Encryption (which only works at data at rest), Transport encryption, encrypted data elements or application level encryption, column level or transparent encryption in a database ? Understand that Encryption is not Encryption is not Encryption. For example using a product to encrypt a disk to store data at rest, does not provide encrypted data elements and transport level encryption. And lastly End-to-End Encryption solutions would not of prevented this either: see my post here: When End-to-End Encryption is really not End-to-End.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now