The RIS News 2009 Hardware Leaderboard is out. This is the fourth year of the survey of retailers asking them to review their hardware vendors. Almost 500 retailer reviews were submitted covering 79 suppliers of hardware technology to retailers including POS systems, peripherals and digital signage and networking.
In the peripherals category, VeriFone ranked 3rd overall, 1st in technology innovation and 2nd in product features! In this category, VeriFone trailed only Epson and Dell. Hypercom and Ingenico again this year did not make the top ten.
In the kiosk category, VeriFone also ranked 3rd overall behind IBM and NCR, and ranked 2nd in product quality.
In the overall category of all POS hardware, VeriFone ranked 6th overall, including 3rd in Product Features and 3rd in Technology innovation.
The full study can be downloaded here.
Wednesday, July 29, 2009
Monday, July 27, 2009
Visa - Chip & Pin not coming to US for a long time
The June/July issue of Cards&Payments has an article profiling Ellen Richey,head of global enterprise risk for Visa. Some interesting points from the article.
Q: Is it possible for companies to maintain compliance all the time?
A: Maintaining compliance is basically just disiplined execution. Security needs to be built into the business process so it is part of the everyday work.
Q: You said recently that Visa expects the US to adopt chip technology that is being used elsewhere to make purchases more secure. When do you think that will happen?
A: The fundamental technology will have to be consistent all around the world, and the EMV standard is what needs to be applied to maintain interoperability. But the U.S. is not going to be adopting a chip-and-PIN credit card or debit card any time in the very near future. What we're seeing today in the U.S. is contactless-chip technology rolling out.
Q: What will be the greatest security advance?
A: First, we think the industry ultimately needs to move toward dynamic data. Trying to protect static data within the system is going to be, I hope, less and less of a problem because the data will be less and less vulnerable. Once its stolen, it would be unusable. That would be the ultimate advance. Secondly, what I would like to see is continuously improving collaboration among all stakeholders - better communications and better cooperation to advance security - because we think security is absolutely a shared responsibility, and everybody has a role to play.
Q: Is it possible for companies to maintain compliance all the time?
A: Maintaining compliance is basically just disiplined execution. Security needs to be built into the business process so it is part of the everyday work.
Q: You said recently that Visa expects the US to adopt chip technology that is being used elsewhere to make purchases more secure. When do you think that will happen?
A: The fundamental technology will have to be consistent all around the world, and the EMV standard is what needs to be applied to maintain interoperability. But the U.S. is not going to be adopting a chip-and-PIN credit card or debit card any time in the very near future. What we're seeing today in the U.S. is contactless-chip technology rolling out.
Q: What will be the greatest security advance?
A: First, we think the industry ultimately needs to move toward dynamic data. Trying to protect static data within the system is going to be, I hope, less and less of a problem because the data will be less and less vulnerable. Once its stolen, it would be unusable. That would be the ultimate advance. Secondly, what I would like to see is continuously improving collaboration among all stakeholders - better communications and better cooperation to advance security - because we think security is absolutely a shared responsibility, and everybody has a role to play.
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
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.
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.
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.
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.
Sunday, July 19, 2009
Verizon Business reveals details of Encryption Key Compromises
Verizon Business recently held a webinar titled “Don’t be the next victim on PIN-Based attacks.”
In the webinar, they revealed that there have been several PIN breaches, as well as the details behind the most common attacks against encrypted debit PIN’s. While the method of obtaining the encryption keys may vary, the commonality of these attacks is that they occur when criminal organizations enter a system in the payments infrastructure and are able to take over, or control, the HSM (Host Security Module) that is used for debit key translation between different payment system processors. These attacks can occur against both financial institutions as well as retailers that have installed HSN’s for PIN translation.
The top threats identified in the webinar are:
• PIN Block Translation Attack
• HSM API Brute Force Attack
• Lack of Unique Keys per Device/Zone
• Use of weak keys
The PIN Block Translation attack takes advantage of a weak PIN encryption format included in HSM’s for compatibility reasons. The format, called IBM/Diebold only has 10,000 possible PIN combinations. The standard ANSI x9.8 PIN Block format has 1,000,000,000,000,000,000,000,000,000 combinations. In this attack, criminals first breach the payment system network and then gain control of the HSM. Commands are entered to have the HSM build a table of all keys encrypted in the IM/Diebold format. They then use the PIN translation capability of the HSM to translate all DES or TDES encrypted PINs into the IBM/Diebold format, using the IBM/Diebold encryption key that they also load into the HSM. Then they simply look up the encrypted PIN in the table and they get the unencrypted PIN from the table.
A note – Verizon reports that gaining logical access to the HSM is easier than many people think and also occurs with much more frequency as well.
The HSM API Brute Force attack is similar to the PIN Block Translation Attack, but it does so without taking advantage of the IBM/Diebold format. Like the PIN Block Translation Attack, this also requires logical access to the HSM, gained by criminals after breaching the payment system network. Hackers break the encrypted PINs basically like solving an algebra problem by executing millions of commands to the HSM until they are able to determine the encrypted PIN. These commands are usually requested via batch or script files. This attack does not require a high degree of difficulty, but it does require much more time and processing power.
The Lack of Unique Keys per Device/Zone, is generally an attack that only occurs against retailers, although some ATM networks and gateways have also been breached as they are still using Master Session keys. This attack is usually aided by finding encrypted PIN block information in places like TLOG files and again uses a brute force type of attack against the encrypted PINs.
The fourth common method of attack against encrypted PINs takes advantage of weak DES (single DES) keys. In 1998 in a high-tech lab environment, DES keys were cracked in 56 hours. In 2007, DES keys can be cracked with a server costing less than $10,000 in 6 days.
There is also a Russian criminal gang that offers a fee-based DES cracking service. Ship a POS PED to the gang overnight and they will return the DES keys within 72 hours for $250,000, or you get your money back.
They also presented some best practices to reduce the impact of a PIN encryption key compromise as well as some ways to minimize the impact if a debit encryption key is breached.
• Replace any HSM’s that support the IBM/Diebold format, or upgrade the software so that it no longer supports the IBM/Diebold format.
• Do not use Master Session keys, as a breach of one location’s keys will provide them access to encrypted PIN’s from all devices.
• Review HSM logs and look for high volumes of unusual transactions like PIN translations.
• Review access to the HSM and make sure that only authorized programs are able to send it commands.
• Upgrade to TDES keys as they are much much more difficult to breach than single DES keys.
• Make sure you terminals are securely mounted and terminals in storage and transit are properly protected so they cannot be sent to Russian criminal gangs to have their encryption keys removed.
• As per current PCI requirements, a key should only be used for a single purpose. This limits the impact of a breach if one key is compromised. This is why the PCI PIN security requirements require encryption keys to be used for a single purpose only. (i.e. Debit PIN encryption, terminal authentication, end to end encryption, file signing, etc.)
The webinar was presented by Chris Novak, Managing Principal, Forensics Americas and Matthijs van de Wel, Managing Principal, Forensics EMEA
In the webinar, they revealed that there have been several PIN breaches, as well as the details behind the most common attacks against encrypted debit PIN’s. While the method of obtaining the encryption keys may vary, the commonality of these attacks is that they occur when criminal organizations enter a system in the payments infrastructure and are able to take over, or control, the HSM (Host Security Module) that is used for debit key translation between different payment system processors. These attacks can occur against both financial institutions as well as retailers that have installed HSN’s for PIN translation.
The top threats identified in the webinar are:
• PIN Block Translation Attack
• HSM API Brute Force Attack
• Lack of Unique Keys per Device/Zone
• Use of weak keys
The PIN Block Translation attack takes advantage of a weak PIN encryption format included in HSM’s for compatibility reasons. The format, called IBM/Diebold only has 10,000 possible PIN combinations. The standard ANSI x9.8 PIN Block format has 1,000,000,000,000,000,000,000,000,000 combinations. In this attack, criminals first breach the payment system network and then gain control of the HSM. Commands are entered to have the HSM build a table of all keys encrypted in the IM/Diebold format. They then use the PIN translation capability of the HSM to translate all DES or TDES encrypted PINs into the IBM/Diebold format, using the IBM/Diebold encryption key that they also load into the HSM. Then they simply look up the encrypted PIN in the table and they get the unencrypted PIN from the table.
A note – Verizon reports that gaining logical access to the HSM is easier than many people think and also occurs with much more frequency as well.
The HSM API Brute Force attack is similar to the PIN Block Translation Attack, but it does so without taking advantage of the IBM/Diebold format. Like the PIN Block Translation Attack, this also requires logical access to the HSM, gained by criminals after breaching the payment system network. Hackers break the encrypted PINs basically like solving an algebra problem by executing millions of commands to the HSM until they are able to determine the encrypted PIN. These commands are usually requested via batch or script files. This attack does not require a high degree of difficulty, but it does require much more time and processing power.
The Lack of Unique Keys per Device/Zone, is generally an attack that only occurs against retailers, although some ATM networks and gateways have also been breached as they are still using Master Session keys. This attack is usually aided by finding encrypted PIN block information in places like TLOG files and again uses a brute force type of attack against the encrypted PINs.
The fourth common method of attack against encrypted PINs takes advantage of weak DES (single DES) keys. In 1998 in a high-tech lab environment, DES keys were cracked in 56 hours. In 2007, DES keys can be cracked with a server costing less than $10,000 in 6 days.
There is also a Russian criminal gang that offers a fee-based DES cracking service. Ship a POS PED to the gang overnight and they will return the DES keys within 72 hours for $250,000, or you get your money back.
They also presented some best practices to reduce the impact of a PIN encryption key compromise as well as some ways to minimize the impact if a debit encryption key is breached.
• Replace any HSM’s that support the IBM/Diebold format, or upgrade the software so that it no longer supports the IBM/Diebold format.
• Do not use Master Session keys, as a breach of one location’s keys will provide them access to encrypted PIN’s from all devices.
• Review HSM logs and look for high volumes of unusual transactions like PIN translations.
• Review access to the HSM and make sure that only authorized programs are able to send it commands.
• Upgrade to TDES keys as they are much much more difficult to breach than single DES keys.
• Make sure you terminals are securely mounted and terminals in storage and transit are properly protected so they cannot be sent to Russian criminal gangs to have their encryption keys removed.
• As per current PCI requirements, a key should only be used for a single purpose. This limits the impact of a breach if one key is compromised. This is why the PCI PIN security requirements require encryption keys to be used for a single purpose only. (i.e. Debit PIN encryption, terminal authentication, end to end encryption, file signing, etc.)
The webinar was presented by Chris Novak, Managing Principal, Forensics Americas and Matthijs van de Wel, Managing Principal, Forensics EMEA
Mercator End to End Encryption Report
Mercator Advisory Group recently published “End to End Encryption: The Acquiring Side Responds to Data Loss and PCI Compliance.” The report was written by George Peabody, Principal Analyst for Mercator and was published in June 2009.
Among the finding in the report:
• “PCI, as it is defined today, while necessary, is not sufficient. More robust approaches are required. And that is where card number encryption enters the scene, as another method of removing high value card numbers from merchant, processor and acquirer systems.”
• “Encryption is about making secret data economically and computationally impractical to steal. Having done that, cyber criminals have no ability to profit from what data they do manage to steal after they‘ve broken into the enterprise.”
• Mercator projects that the scope of PCI DSS audits should be reduced by 75% and annual compliance maintenance costs should be reduced by 80% by implementing a proper end to end encryption solution. In their analysis, that translates to between $262,500 and $1,750,000 in annual savings to a retailer.
• George Peabody believes that retailers should be given an interchange break for implementing an end to end encryption solution. “There is precedent for incentive interchange rates based on merchant deployment of fraud and risk controls. E2EE deployment by a merchant qualifies as a fraud and risk control. After all the PCI DSS expenditures made by merchants, under threat of a stick, a handful of basis points for good citizenship would let the Acquiring Team know that its efforts are appreciated. Since they have to play by the Issuing Team‘s rules, it is deserved.”
• “The only way E2EE becomes systemic is if it becomes mandated for all merchants or an interchange incentive is given or E2EE saves enough money and pain to compel merchants.... and upstream through to issuers.”
Among the finding in the report:
• “PCI, as it is defined today, while necessary, is not sufficient. More robust approaches are required. And that is where card number encryption enters the scene, as another method of removing high value card numbers from merchant, processor and acquirer systems.”
• “Encryption is about making secret data economically and computationally impractical to steal. Having done that, cyber criminals have no ability to profit from what data they do manage to steal after they‘ve broken into the enterprise.”
• Mercator projects that the scope of PCI DSS audits should be reduced by 75% and annual compliance maintenance costs should be reduced by 80% by implementing a proper end to end encryption solution. In their analysis, that translates to between $262,500 and $1,750,000 in annual savings to a retailer.
• George Peabody believes that retailers should be given an interchange break for implementing an end to end encryption solution. “There is precedent for incentive interchange rates based on merchant deployment of fraud and risk controls. E2EE deployment by a merchant qualifies as a fraud and risk control. After all the PCI DSS expenditures made by merchants, under threat of a stick, a handful of basis points for good citizenship would let the Acquiring Team know that its efforts are appreciated. Since they have to play by the Issuing Team‘s rules, it is deserved.”
• “The only way E2EE becomes systemic is if it becomes mandated for all merchants or an interchange incentive is given or E2EE saves enough money and pain to compel merchants.... and upstream through to issuers.”
MasterCard Clarifies Remote Key Injection Requirements
A month ago MasterCard issued a bulletin about how and what terminals can be upgraded to TDES keys for debit PIN encryption. The bulletin seemed to indicate that Remote Key Injection would not be allowed as a way to upgrade terminals to TDES keys.
Here is an updated statement from MasterCard:
"Last month, MasterCard issued a Security Bulletin to provide guidance on how point-of-sale terminals could be upgraded from triple-DES capable to triple-DES compliant encryption. In the Security Bulletin, MasterCard provided guidance stating that the most secure option to upgrade the terminals is to follow PCI PIN Security Requirements and have the upgrade performed at a key injection facility. However, our customers and vendors can use Remote Key Injection services to upgrade the terminals if those services meet all aspects of the PCI Pin Security Requirements."
This has also been clarified with an additional statement from MasterCard as follows:
"MasterCard has strict rules relating to Pre-PCI terminals, in order to assist our Acquirers meet the Visa Triple DES mandate we confirmed via the security bulletin that Pre-PCI terminals could provided they were Triple Des capable, (Which all Pre-PCI terminals should be) then they could be upgraded to become triple Des compliant.
Now in order to achieve this, the upgrade must be undertaken as per the PCI PIN Security Requirements ( This is our standard process been around for years nothing new or different). This has nothing to do with requiring the terminals to be PCI POS PED approved as per the latest articles. With regard to remote key injection, then as I have already mentioned, our preference is that vendors use a Key injection facility. However if you offer RKI, then provided you can confirm this will be undertaken as per the PIN Security Requirements then that is permitted.
With regard to PCI approved terminals being upgraded, as these terminals are still approved then these terminals can also be upgraded to TDES Compliant, again provided it is carried out against the PCI PIN Security Requirements, but as this was already allowed and nothing changed, we did not include it in our original bulletin."
The net of all this is that Remote Key Injection can be used, but it must be a process that meets the PCI PIN Security Requirements. These are a comprehensive set of requirements for protecting the integrity of encryption keys.
Here is an updated statement from MasterCard:
"Last month, MasterCard issued a Security Bulletin to provide guidance on how point-of-sale terminals could be upgraded from triple-DES capable to triple-DES compliant encryption. In the Security Bulletin, MasterCard provided guidance stating that the most secure option to upgrade the terminals is to follow PCI PIN Security Requirements and have the upgrade performed at a key injection facility. However, our customers and vendors can use Remote Key Injection services to upgrade the terminals if those services meet all aspects of the PCI Pin Security Requirements."
This has also been clarified with an additional statement from MasterCard as follows:
"MasterCard has strict rules relating to Pre-PCI terminals, in order to assist our Acquirers meet the Visa Triple DES mandate we confirmed via the security bulletin that Pre-PCI terminals could provided they were Triple Des capable, (Which all Pre-PCI terminals should be) then they could be upgraded to become triple Des compliant.
Now in order to achieve this, the upgrade must be undertaken as per the PCI PIN Security Requirements ( This is our standard process been around for years nothing new or different). This has nothing to do with requiring the terminals to be PCI POS PED approved as per the latest articles. With regard to remote key injection, then as I have already mentioned, our preference is that vendors use a Key injection facility. However if you offer RKI, then provided you can confirm this will be undertaken as per the PIN Security Requirements then that is permitted.
With regard to PCI approved terminals being upgraded, as these terminals are still approved then these terminals can also be upgraded to TDES Compliant, again provided it is carried out against the PCI PIN Security Requirements, but as this was already allowed and nothing changed, we did not include it in our original bulletin."
The net of all this is that Remote Key Injection can be used, but it must be a process that meets the PCI PIN Security Requirements. These are a comprehensive set of requirements for protecting the integrity of encryption keys.
Friday, July 17, 2009
VISA 7/1/10 Mandate Clarifications
There has been much confusion over the impact to a retailer who does not meet the Visa July 1, 2010 mandates for payment security.
To review, there are three different mandates from Visa that must be met by US merchants by July 1, 2010. These are:
· All non-certified payment terminals on which PIN debit transactions are conducted must be removed from service. This includes any terminal that is not either VISA PED or PCI PED.
· All debit card PINs must be encrypted in TDES from the payment terminal
· All applications that “store, process, or transmit cardholder information” must be PA-DSS or PABP compliant.
So what is the impact of not conforming to one or more of those mandates?
First, in all cases, if the retailer suffers a data breach and cardholder information is compromised, then all liability passes to the retailer if the breach was in part the result of the retailer not being compliant with these mandates. Various studies put the cost of a cardholder breach in the range of $125 to $225 per compromised record. (Not card records actually used fraudulently, but all cardholder records that were exposed by the breach.) The Ponemon Institute publishes an annual study of the cost of a data breach which is available on their web site.
The costs of a breach that a retailer would be subject to include the following:
·Investigation costs by themselves, the card associations and the banks that issued the compromised cards.
·The costs borne by the issuing banks to re-issue the compromised cards
·The actual costs of fraudulent purchases made on any of the compromised cards
·Fines from VISA which would be assessed against the acquiring bank who would pass them to the retailer’s processor who would pass them to the retailer
·In addition, the retailer would have their own legal, PR, IT, forensics and remediation costs, which of course they would also have to bear even if they were compliant at the time of the breach.
What costs would a retailer face if they are non-compliant with the July 1st, 2010 mandates? These may vary by which of the mandates the retailer is not compliant with.
·Use of non-certified payment terminals after July 1, 2010 (Does not apply to Fuel Dispensers, there are different requirements for that.)
- While Visa has not issued a statement about the enforcement of thus mandate, it is reasonable to expect that they will fine acquiring banks who have merchants using non-compliant terminals. This could start on July 1, 2010, or sometime after that date. VISA has not publically published their enforcement plan for this mandate yet. It would be pure speculation to estimate the size of these fines.
Use of Master Session or Single DES (DUKPT) after July 1, 2010
- Visa has already announced, in their April 2009 TDES update that they will begin fining acquires who have merchants using other then TDES on 8/1/12. It is safe to assume that in most cases those fines will be passed onto the merchants in non-conformance with the mandate.
·Use of non PA-DSS (or un-expired PABP) applications after July 1, 2010.
- Visa has confirmed verbally to me that they plan on fining acquirers as of July 1, 2010 if they have merchants that are not in compliance with this mandate. The amount of this fine is likely to be in the same range as the fines for PCI DSS non-conformance ($5,000 t0 $25,000 per month), although I expect a lower tier fine for Level 4 merchants. I would guess that these would be assessed monthly for as long as the merchant remains non-compliant.
In summary, there are two types of costs and fines a merchant could be subject to if they do not meet Visa’s July 1, 2010 mandates: first non-compliance fines for non-compliance with the mandates, some of which be assessed starting on that date; and breach fines and other breach related costs in the event of a breach that was in part based on the merchant’s non0compliance with these payment security mandates.
To review, there are three different mandates from Visa that must be met by US merchants by July 1, 2010. These are:
· All non-certified payment terminals on which PIN debit transactions are conducted must be removed from service. This includes any terminal that is not either VISA PED or PCI PED.
· All debit card PINs must be encrypted in TDES from the payment terminal
· All applications that “store, process, or transmit cardholder information” must be PA-DSS or PABP compliant.
So what is the impact of not conforming to one or more of those mandates?
First, in all cases, if the retailer suffers a data breach and cardholder information is compromised, then all liability passes to the retailer if the breach was in part the result of the retailer not being compliant with these mandates. Various studies put the cost of a cardholder breach in the range of $125 to $225 per compromised record. (Not card records actually used fraudulently, but all cardholder records that were exposed by the breach.) The Ponemon Institute publishes an annual study of the cost of a data breach which is available on their web site.
The costs of a breach that a retailer would be subject to include the following:
·Investigation costs by themselves, the card associations and the banks that issued the compromised cards.
·The costs borne by the issuing banks to re-issue the compromised cards
·The actual costs of fraudulent purchases made on any of the compromised cards
·Fines from VISA which would be assessed against the acquiring bank who would pass them to the retailer’s processor who would pass them to the retailer
·In addition, the retailer would have their own legal, PR, IT, forensics and remediation costs, which of course they would also have to bear even if they were compliant at the time of the breach.
What costs would a retailer face if they are non-compliant with the July 1st, 2010 mandates? These may vary by which of the mandates the retailer is not compliant with.
·Use of non-certified payment terminals after July 1, 2010 (Does not apply to Fuel Dispensers, there are different requirements for that.)
- While Visa has not issued a statement about the enforcement of thus mandate, it is reasonable to expect that they will fine acquiring banks who have merchants using non-compliant terminals. This could start on July 1, 2010, or sometime after that date. VISA has not publically published their enforcement plan for this mandate yet. It would be pure speculation to estimate the size of these fines.
Use of Master Session or Single DES (DUKPT) after July 1, 2010
- Visa has already announced, in their April 2009 TDES update that they will begin fining acquires who have merchants using other then TDES on 8/1/12. It is safe to assume that in most cases those fines will be passed onto the merchants in non-conformance with the mandate.
·Use of non PA-DSS (or un-expired PABP) applications after July 1, 2010.
- Visa has confirmed verbally to me that they plan on fining acquirers as of July 1, 2010 if they have merchants that are not in compliance with this mandate. The amount of this fine is likely to be in the same range as the fines for PCI DSS non-conformance ($5,000 t0 $25,000 per month), although I expect a lower tier fine for Level 4 merchants. I would guess that these would be assessed monthly for as long as the merchant remains non-compliant.
In summary, there are two types of costs and fines a merchant could be subject to if they do not meet Visa’s July 1, 2010 mandates: first non-compliance fines for non-compliance with the mandates, some of which be assessed starting on that date; and breach fines and other breach related costs in the event of a breach that was in part based on the merchant’s non0compliance with these payment security mandates.
MasterCard Revises Level II SDP Merchant Compliance
MasterCard has changed its requirements for Level II Merchant SDP Program Compliance. SDP, or Site Data Protection is the MasterCard program for cardholder security and is similar to the VISA CISP Program. Currently Level 2 MasterCard merchants can complete a PCI DSS Self-Assessment Questionnaire and submit that to MasterCard as part of their SDP certification process. Level 2 Merchants are defined by MasterCard as merchants doing between 1M and 6M annual MasterCard transactions annually or merchants whose transaction volume makes them a Level 2 merchant for another card brand. By December 31, 2010, all Level 2 MasterCard merchants must complete an onsite assessment conducted by a PCI SSC certified Qualified Security Assessor, and thereafter submit an annual onsite assessment conducted by a PCI SSC certified Qualified Security Assessor. These requirements are included on the MasterCard web site here: http://www.mastercard.com/us/sdp/merchants/merchant_levels.html
Subscribe to:
Posts (Atom)