Visa allows international Merchants to not demonstrate PCI DSS compliance

On February 11, 2011 Visa announced an interesting program that promotes and demonstrates the fraud deterrence strength of the Europay, MasterCard and Visa (EMV) smartcard standard and are also equipped to accept both contact-based and contactless transactions.  Those organizations that have at least 75% of their transactions originating from smartcard-enabled terminals will not have to demonstrate compliance.  This is perhaps a reflection of Visa weighing the risks and benefits of technology from a risk management point of view.  A win for merchants certainly, as this technology is widely adopted in many parts of the world.

As a reminder, all organizations within the Payment Card Industry must be compliant with the data security standard, but the nuance of demonstration / attestation is based on the channel and volume of each individual card.  This program of Visa does not impact the other Card brands, so international Merchants will still need to consider these within their global compliance and security programs.

An interesting writeup on the article is available at Computerworld here.  The press release is here.

The deployment in the U.S. requires both adoption at the Merchant level, and the consumers too.  It would be interesting to compare the costs of the EMV architecture vs. the compliance costs of organizations.  I also wonder if the net benefit of requiring security controls to be meaningfully applied to sensitive data (in this case PCI) does not raise all the “boats” (read: other sensitive data types), as it is more likely that security safeguards are applied broadly.  Is this demonstrated by 28% reduction in identity thefts in 2010?

See you in San Francisco at RSA 2011,

James DeLuccia

Payment Application Best Practices – Top 10, by Visa

Visa has been phenomenal on providing clarification, tools, guidance, and clarity to secure CHD sensitive data and the payment networks.  Visa released on 8/24/2010 the Visa Best Practices document “Visa Top 10 Best Practices for Payment Application Companies, Version 1.o”.  The PDF is available here and is a concise 5 pages.  While directed towards application providers there are interesting and applicable practices described that all operators should consider.

The Best Practices are broken across several domains that go beyond simple software coding checks, but include:

• Organizational Security (Background Checks, Training, Certifications)
• Mature Software Development (SDLC, upgrade cycles in line with PA-DSS)
• Product Vulnerability Management (App detection tests and Code reviews against common vuln & weaknesses)
• Secure Implementation (Contractual PA-DSS requirements, Enforcement of secure installations)
• Emerging Payment Technologies (Adhere to field encryption, token, and PAN elimination, support future dynamic solutions)

The press release provides a nice breakdown of the document from Visa, and can be found here.  In addition, SANS has launched a training series that aligns with the training aspects highlighted in this Best Practice (note this is Best Practice, not a mandate).  Finally two sections that should be carefully considered by all operators is section 8 and 10.

Section 8 states, “Implement an installer, integrator and reseller training and certification program that enforces adequate data security processes when supporting customers” – loosely meaning that these technologies should deploy out-of-the-box secure/compliant.  This is places the onus on the provider of the technology to address the challenges of security, and appears to set an expectation on the user of such.

Section 10 highlights the need to “Support capability of dynamic data solutions across payment applications”, and suggests that fundamental changes in how the payment transaction environment exists today will flex in the future.  Not a severe interpretation given the velocity of changes in this market, but again the imperative is for these providers to be flexible.

A nice set of practices for a specific challenge.  Thoughts?  Concerns?

James DeLuccia

Do ISO entities need to be PCI DSS Compliant?

Who needs to be compliant with the Payment Card Industry Security Standards Council standards?  Well, the default response is usually – anyone who stores, process, and transmits card holder data.  There is constant discussion on pre-auth / post-auth / banking partners / etc..

A recent question I received was … Do ISO (Independent Sales Organizations) need to be compliant with PCI DSS?

This is a great question because it brings into the forefront the Third Party Providers.  While the classic response – “it depends” applies generically, let me elaborate and provide where it DOES exist.

According to Visa’s website, an ISO for this definition is also more broadly classified as a “Third Party Agent”.  Specifically here are the various functions that can be performed (This is key for eliminating the it depends statement from your situation):

A TPA can perform any or all of the functions of an: Independent Sales Organization (ISO), Third Party Servicer (TPS), Encryption Support Organization (ESO) and Merchant Servicer (MS). Each function performed by the TPA must be registered by each Visa client that is utilizing those services. TPA functions that require registration include but are not limited to:

• Merchant or cardholder solicitation activities and / or customer service — these are performed by an ISO
• Prepaid program solicitation activities and / or customer service — these are performed by an ISO
• Loading or injecting encryption keys into ATMs, terminals or PIN pads — these are performed by an ESO
• Loading software into an ATM or terminal — these are performed by an ESO
• Storing, processing or transmitting Visa account numbers — these are performed by either a TPS or a MS
• Deploying and / or servicing ATMs – these are performed by an ISO

Beyond registration requirements, all service providers – need to be compliant, as it is the acquiring banks liability if they are not.

Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are properly registered with Visa. Where applicable they must also ensure that all such entities are compliant with the PCI DSS and PCI PIN. Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa acquirers are responsible for any liability that may occur as a result of non-compliance.

In addition, Visa has provided enhanced clarification in their list of ISOs (published 7/15/2010) that lists registered organizations.  The document states that “entities utilizing this list should perform their own additional due diligence to ensure that the service prover is also compliant with any additional requirements that the entity may have in place.”… “Entities that store, process or transmit cardholder data must be registered with Visa and validate PCI DSS compliance.”

There are certainly relationships that may provide exceptions, but the process above shows that if you store, process, or transmit card holder data – proper security and compliance (and Validation where appropriate) with PCI DSS is necessary.

Thoughts?
James DeLuccia IV

Global Best Practices for Tokenization, Visa

On July 14, 2010 Visa released version 1.0 of their Tokenization best practices document.  This follows up previous publications on data field encryption.  The release is brief, but provides several interesting data points that Merchants, Providers, and Practitioners should consider.

Visa breaks down Token systems into 4 Unique Components:

1. Token Generation
2. Token Mapping
3. Card Data Vault
4. Crytographic key Management

A broad set of best practices are highlighted throughout the rest of the document and well worth a review (Here is the direct link to the PDF).  A few specific items that were interesting:

• The Tokenization system must be segmented and “be subject to a full PCI DSS assessment” – note this does not say QSA audit, but rather implies a confirmatory action by the owner of the system.
• Monitoring suggests a need to “detect malfunctions or anomalies and suspicious activities”, which are far more fraud focused.  In addition there is mention of rate limiting functions, which would be beneficial beyond the token-PAN mapping environment
• The Token must be so designed to “not be computationally feasible” to recover original PAN.  A token may be created using EITHER a “known strong cryptographic algorithm” or a “one-way irreversible function”

This publication is meant to provide high level guidance, and Visa is seeking any comments by August 31, 2010 (send messages to inforisk@visa.com w/ “Best Practices for Tokenization” in the subject).  In previous publications Visa has issued more granular publications following these high level documents, so feedback and comment is important.

Best,

James DeLuccia IV

Visa Europe on Data Field Encryption, PCI DSS

This month (March 2010) Visa Europe released a full guidance document on Data Field Encryption: Device and Key Management Guidance.  This relates directly to “end-to-end” encryption, “point-to-point” encryption or “account data” encryption and the process of securing transaction data in transit and in storage.  This has been a critical focus of the payment card community.  A nice article highlighting the benefits of this guidance document and endorsements by major organizations in Europe can be found here.

Simply put though, the guidance provides 71 pages of excellent specific data on what these technologies should be doing at minimum.  This provides operators and auditors with a tool to compare equally the unique solutions being deployed globally, and a common baseline of control safeguards.

The full guidance document may be downloaded here.  A direct link to the PDF is here.

Please note this is focused on Visa Europe.

Thoughts and concerns with this guidance and / or the technology?

James DeLuccia