Showing posts with label PCI DSS. Show all posts
Showing posts with label PCI DSS. Show all posts

Thursday, February 4, 2010

PCI DSS Releases FAQ about End to End Encryption

While major updates to the PCI Data Security Standard get issues with new versions, such as the one to be published later this year, the PCI Security Standards Council often releases FAQ’s that provide clarification or guidance to merchants and QSA’s. In December, the PCI SSC published an FAQ dealing with the impact of end to end encryption on PCI Scope. While couched in several disclaimers, the highlighted section below says that encrypted data can be considered out of scope if the retailer does not have the means to decrypt the data. This is a huge win for retailers looking to implement end to end encryption technology both to improve the security of cardholder data in their environment as well as reduce their on-going PCI compliance and assessment costs.

As when implementing any new payment architecture or technology, you should consult with your QSA during the evaluation, planning and implementation processes to maximize the benefits you receive when implementing a new payment architecture or technology like end to end encryption.

Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?
The Council will be developing more formal guidance around this topic, leveraging information that is received through the various channels of the DSS lifecycle feedback process. Until further guidance is provided by the Council, the following should be taken into consideration regarding encrypted cardholder data.

Encryption solutions are only as good as the industry-approved algorithms and key management practices used, including security controls surrounding the encryption/decryption keys (“Keys”). If Keys are left unprotected and accessible, anyone can decrypt the data. The DSS has specific encryption key management controls (DSS 3.5 and 3.6), however, other DSS controls such as firewalls, user access controls, vulnerability management, scanning, logging and application security provide additional layers of security to prevent malicious users from gaining privileged access to networks or cardholder data environments that may grant them access to Keys. It is for this reason that encrypted cardholder data is in scope for PCI DSS.

However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entity’s environment, from obtaining access to Keys.

Furthermore, service providers or vendors that provide encryption solutions to merchants who have administrative access and controls to Keys along with the management of termination points for encryption to process transactions, are required to demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices (such as NIST referenced in PCI DSS requirement 3.6), along with full compliance with PCI DSS.

Merchants should ensure their solution providers who provide key management services and/or act as the point of encryption/decryption are in compliance with PCI DSS. Merchants should be aware that encryption solutions most likely do not remove them completely from PCI DSS. Examples of where DSS would still be applicable include usage policies, agreements with service providers that deploy payment solutions, physical protection of payment assets and any legacy data and processes (such as billing, loyalty, marketing databases) within the merchant's environment that may still store, process or transmit clear text cardholder data, as that would remain in scope for PCI DSS.


The full PCI SSC FAQ’s can be found here. Click on the FAQ link in the left navigation bar. This specific FAQ can be found here.

Thursday, January 21, 2010

Independent QSA Technical Assessment of VeriShield Protect

VeriFone has contracted with Coalfire Systems, Inc. a leading IT security consulting firm and PCI QSA to conduct an independent technical assessment of VeriShield Protect. The goal of this assessment is to determine if VeriShield Protect meets and follows industry standards, how a proper implementation of VeriShield Protect can improve the security of a retailer’s cardholder environment and the impact VeriShield Protect can have on reducing PCI scope and compliance costs.

The assessment is complete and a white paper of the findings will be published in February. The assessment by Coalfire included lab testing of the system, evaluation of VeriShield Protect as implemented at a Tier 1 retailer and a review of all planned deployment scenarios.

At NRF, Kennet Westby, Coalfire co-founder and COO, presented the initial findings from their assessment to a breakfast meeting of retail CIO’s and security executives. An executive summary from the forthcoming whitepaper was also released at NRF.

Key points from this executive summary include:

• A properly deployed VeriShield Protect solution can provide significant risk mitigation of data compromise and may be one of the most effective controls available to merchants today.

• There can be very clear and dramatic reduction of PCI compliance scope with a properly deployed VeriShield Protect solution.

• The benefit to merchants is the VeriShield Protect solution can reduce the cost of PCI compliance assessment and validation and allow them to invest more of those dollars into risk mitigating controls.

• The VeriShield Protect solution integrates securely with PC based POS or cash registers without exposing card data, encryption keys or authentication data to these platforms.

• The format preserving VeriShield Hidden Encryption provided successful integration with all payment application, POS and back-office servers tested.

• The integration with tested payment applications and POS systems was quick, required very little customization and worked effectively with all post authorization, sales audit and refund transactions tested

• The VeriShield Protect solution meets all VISA Data Field Encryption Best Practices.

• VeriShield Hidden Encryption meets encryption best practices and standards for cryptographic algorithms and key strength. The format preserving methods meet industry standards and VISA best practice guidance.

• The key management processes of the VeriShield Protect solution remove most of the challenges of key management for the merchant that are found in many previous end point encryption solutions

• The VeriFone terminal should be the only point in a merchant environment that captures card data through swipe or keyed entry to achieve the greatest security and PCI compliance scope reduction

• A payment application or POS that is not PABP/PA-DSS validated can be taken out of PCI scope if all payment data is captured through the VeriShield Protect solution and the system is cleansed of all legacy card data.

• A deployment architecture that has all card data captured in a VeriShield Protect TRSM and communicates directly to a PCI compliant processer who manages all decryption services for the merchant provides the greatest security and compliance risk mitigation.

• A merchant should have ownership rights to the decryption keys but not have access or possession of keys to achieve the greatest PCI scope reduction.

• A merchant can remove PCI compliance scope for the majority of their retail environment if all electronic card data is captured in a VeriShield Protect TRSM and no decryption appliances or decryption keys exist in their environment.

• The VSDMS provides effective compliance and security auditing for the merchant and QSA. Store validation sampling of compliance is simplified with this tool set. Compliance reporting overtime is easily evidenced for auditors using the VSDMS.

• The VeriFone VeriShield Protect solution impressed the Coalfire technical assessment team and their QSA auditors. The technology and tools are well architected and effective. The maturing of the solution based on their assessment input, customer feedback and industry best practice was equally impressive. Solution support, technical capabilities and security expertise of both VeriFone and its technology partner have benefited early customers in achieving their security and compliance goals.

This full executive summary can be downloaded here.

Monday, July 27, 2009

Visa's Latest PCI DSS Compliance Numbers

From a session at the MWAA last week.

Level Companies %PCI DSS Compliant
1 362 93%
2 702 88%
3 2,627 57%
4 6m+ low

Wednesday, July 22, 2009

How Dealers Should Deal with PCI Compliance

There were some interesting comments and ideas presented by Bob Goldberg, General Counsel of the RSPA, during the PCI Panel discussion I moderated in Las Vegas last week. After thinking about them, I want to expand on his comments and discuss what dealers should be doing with regards to making their customers PCI compliant.

For perspective, the RSPA (which used to be the IRCDA, then the Systems Dealer Association) membership is dealers. Not ISV’s or POS vendors, but dealers who provide local sales, support and service to millions of primarily level 4 merchants who want POS systems or ECR’s.

All players on the payment industry agree that the Level 4 merchant served by the RSPA members has the least amount of knowledge of PCI requirements. In addition these merchants do not usually have an IT staff, or at least not a large one, and they focus on what they doing best – selling stuff, cooking meals, or entertaining customers. Expecting them to understand the subtleties of liability shift as of July 1, 2010, when they do not even understand what to do for PCI Compliance is ludicrous.

The ultimate security solution for these Level 4 merchants is a solution with which they never have to think about payment card security. The industry needs provide them a secure card processing solution in the normal course of business. The only solution likely to meet those criteria is an end to end encryption solution. The end game is to make sure small merchants never have to think about payment card security.

This is some time away from widespread industry adoption, so I the meantime, dealers must develop alternative plans to protect their businesses and their customers.

While RSPA members generally understand the PCI programs and requirements, their customers most often do not. Focused on running their businesses in a challenging economy, these merchants often eschew these PCI related expenses due to many reasons including, but not limited to, the following reasons: lack of capital, no understanding of the impact of non-compliance, or the belief that a breach will never happen to them.

Where this becomes a real significant issue to a dealer is when their customer is breached. In that case, the dealer is often sued by the merchant for improper installation, or not telling them they need a software upgrade for PA-DSS, or some other reason to deflect blame away from the merchant, or to recoup some of the merchant’s expenses caused by the breach or the remediation after the breach.

So how can a dealer protect themselves when they are between the rocks of merchants who do not want to spend money for PCI compliance and the hard places of the card brands with their mandated PCI Compliance dates. There are several things retail dealers need to do to protect themselves.

First and foremost is education. Dealers need to understand the PCI standards, the compliance dates and the impact of non-compliance on themselves and their customers. They do not need to become experts in the details of each standard, but need to be comfortable talking about what retailers must do by what dates, and what the impact of not meeting the card association deadlines would be on their customers’ businesses.

Second, dealers must understand the PCI status if the products they sell. Do the software applications they re-sell meet current PA-DSS requirements? What is the installation process they need to follow to insure the software is installed properly? Do the payment terminals they sell meet the current requirements? What is the plan for the merchant’s acquirer to meet the upcoming TDES implementation date of July 1, 2010?

Next, dealers need to make sure they inform their customers about any deadlines to their customers based on the products they sell them. If a dealer sells POS applications, then they need to be sure to inform each of their customers when the deadline is for upgrading to the next PA-DSS validated version. If the dealer sells payment terminals or PIN pads they should communicate to their customers the July 1, 2010 dates for removal of non-certified devices and implementation of Triple-DES keys. In addition to just informing their customers about these dates, they need to document these conversations via an email or paper trail. Dealers need this documentation to prove they told their customers about impending compliance date in the event their customer is breached and wants to sue them.

Finally, dealers need to understand the installation requirements of the solutions which they sell. Part of the PA-DSS requirements is the requirement for a software vendor to provide installation instructions to make sure the software is properly installed. Other products that dealers sell and install must also be properly installed and configured such as changing default passwords, blocking unused ports, etc. Each dealer should develop a checklist of each of the proper installation requirements to be completed as their employees install or upgrade systems. At the end of the installation or upgrade, the installer should review the checklist with a customer representative and get them to sign the checklist indicating they installation was done in accordance with accepted PCI standards, and that going forward, it is the responsibility of the customer to maintain the PCI compliance of the system.

The recommendations here should go a long way in protecting a dealer in case one of their customers is breached, and should also position dealers who do this as a business advisor and payment security expert in addition to a retail systems expert. In the long-run, people buy systems from people they trust, and helping dealer customers protect their systems from a breach will benefit the dealers who bring more value to their customers.

Tuesday, July 21, 2009

Who is Minding the Legal Risk around PCI?

David J. Navetta, Esq., CIPP, managing member InfoSecCompliance, LLC published an excellent article the April 2009 issue of the ISSA (International Systems Security Association) Journal titled "Who is Minding the Legal Risk around PCI?"

The article reviews the legal framework for PCI related compliance and lawsuits and should be a must read for anyone responsible for PCI compliance for their company.

A PDF of the article can be found here.

Does the Nevada Information Security Law apply to all retailers?

David Navetta has a good post today about the implications of the Nevada Security of Personal Information Law on the InfoSec Compliance Blog.

He makes the point, as have others, that the law applies to almost any company whether you do business in Nevada or not. If you have but one customer from Nevada, even though your stores are not located there, and you accept credit or debit cards from a Nevada resident, then you are required to meet the PCI Data Security Standard and you are required to send the cardholder data in an encrypted format of it is sent outside of your enterprise.