There has been much discussion this year about the benefits of end to end encryption protecting cardholder data. Proper end to end encryption solutions will improve the security of cardholder data, remove some retail systems from PCI DSS scope and will reduce both the costs of compliance as well as the cost of PCI DSS assessments. George Peabody of the Mercator Group projects that retailers will save 20% of their ongoing PCI compliance costs and 25% of their annual assessment costs. (1)
Until recently, merchants were left on their own to evaluate end to end encryption solutions to determine if indeed, the solution did properly protect cardholder data. Visa’s recently published Data Encryption Best Practices has finally provided guidance to retailers who are looking to implement end to end encryption.
While some of the best practices are technical and reference technical specifications, they incorporate generally accepted financial industry standards that are widely understood and used within the payments industry today for the protection of debit PINs and debit PIN encryption keys.
There are 14 Data Field Protection Best Practices which are grouped into 5 Data Field Protection Goals. These goals and the associated best practices are as follows:
Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.
1. Cardholder and sensitive authentication data must remain encrypted between the endpoints
2. ANSI or ISO approved strong encryption like TDES or AES must be used
3. The first 6 digits and last 4 digits of the PAN may be left in the clear for routing and receipt printing purposes, but the remaining track data must be encrypted
4. Per existing PCI DSS requirements and definitions, sensitive authentication must not be stored after authorization.
Use robust key management solutions consistent with international and/or regional standards.
5. Keys must be managed per ANSI X9.24/ISO 11568 or equivalent within Secure Cryptographic Devices (SCD) such as a PED Payment Terminals and Host Security Modules ( HSM).
6. Keys and key components must be generated using an approved random or pseudo-random process such as NIST SP 800-22.
7. The key management process must be documented
8. Keys may only be transmitted in a secure manner, for example, the key distribution method described in ANSI X9/TR-34.
9. The keys used for encryption must be unique per device and not used for any other purpose like debit PIN encryption or key exchange.
Use key-lengths and cryptographic algorithms consistent with international and/or regional standards.
10. Encryption keys shall have strength of at least 112 equivalent bit strength. (AES is 128 bytes.)
11. Format Preserving Encryption schemes must be evaluated by at least one independent security evaluation organization and subjected to a cryptographic peer review.
Protect devices used to perform cryptographic operations against physical/logical compromises.
12. Devices used to perform cryptographic operations should undergo independent assessment to ensure that the hardware and software they are using is resilient to attack.
13. Keys must be protected against physical and logical compromise as well as protected from substitution and authenticity shall be ensured.
Use an alternate account or transaction identifier for business processes that requires the primary account number to be utilized after authorization, such as processing of recurring payments, customer loyalty programs or fraud management.
14. If any cardholder data (e.g. the PAN) is needed after authorization, a single-use or multi-use transaction ID or token should be used instead.
These best practices should help retailers properly evaluate end to end encryption solutions.
The VeriShield Protect End to End Encryption solution meets or exceeds all of these requirements.
1. Cardholder data is encrypted as soon as the card is swiped and remains encrypted until it reaches the RBS datacenter.
2. VeriShield Protect uses strong AES encryption
3. The first 6 digits and last 4 digits of the PAN are left in the clear for routing and receipt printing purposes, but all other track data must is encrypted
4. No sensitive authentication is stored after authorization.
5. Keys are managed per ANSI X9.24/ISO 11568 within Secure Cryptographic Devices (SCD) such as a PED Payment Terminals and Host Security Modules ( HSM).
6. Keys and key components are generated using NIST SP 800-22 standards.
7. The key management process is documented
8. Keys are only be transmitted in a secure manner.
9. Keys used for encryption are unique per device and not used for any other purpose.
10. AES key strength is 128 bytes
11. VeriShield Protect has been evaluated by an independent security evaluation organization and subjected to a cryptographic peer review.
12. The VeriFone payment terminals used to perform cryptographic operations are PCI PED approved
13. All keys are protected against physical and logical compromise as well as protected from substitution and the authenticity of keys is proven.
14. After authorization, VeriShield Protect can produce a single-use or multi-use transaction ID or token.
Visa’s publication of Data Field Encryption Best Practices is likely to become the next PCI standard. The history of Visa PED, Visa CISP and Visa PABP all being adopted by the PCI Security Standards Council will likely continue to be followed with this set of best practices. Retailers should feel confident that by adopting VeriShield Protect not only will they better protect their consumers data and reduce their PCI compliance costs, but also that they will be ahead of the game for the next payment industry standard.
(1) “End to End Encryption: The Acquiring Side Responds to Data Loss and PCI Compliance”, George Peabody, Mercator Advisory Group, Inc. June 2009.
Friday, October 23, 2009
Tuesday, October 20, 2009
I read the recent article "Tokenization Vs. End-to-End Encryption: Experts Weigh in" published in Bank Information Security yesterday and felt compelled to send the following letter to the editor to correct the mis-information it contained.
_____________________________________________________________
Linda McGlasson
Managing Editor, Bank Information Security
I read the recent article you published on Tokenization versus End-to-End Encryption and I think there are several errors or misconceptions that should be corrected. Perhaps some of this comes from the bias of the experts you interviewed.
First the entire discussion of tokenization versus end-to-end encryption does not even make sense. This is not an either or solution, nor is it a large versus small company decision. Both tokenization and end-to-end encryption can improve the security of cardholder data and can work well together in many environments.
By definition, tokenization cannot take place at the point of card swipe. Cardholder data must be sent throughput the authorization process to a secure token server before a token could be generated and sent back in the response message. This is the main reason why tokenization cannot stand alone in protecting cardholder data. It will remain unprotected in payment terminals, POS systems and retailer host systems where it may be captured by malware planted by criminals.
However, for long term data storage, tokenization may be the ideal solution for many retailers. We are partnering with several processors and merchants to deploy solutions which protect cardholder data in transit with end-to-end encryption and data at rest with tokenization.
The first important point about end-to-end encryption is that it should take place as soon as the card is swiped and remain protected as it traverses the payment infrastructure until it is decrypted. If that decryption takes place at the merchant’s acquiring processor, then there is no unencrypted cardholder data in the retailer’s environment.
And I will have to disagree with Anton Chuvakin that no one can roll out and end to end encryption solution and have it secure and useable. If the acquirer is involved and the payment terminal manufacturer provides a robust end to end encryption solution then smaller Level 4 merchants can remove cardholder data in the clear from their environment. By following industry encryption and key management standards, such as defined by Visa in their recent Data Field Encryption Best Practices, larger merchants can also implement a secure and useable end-to-end encryption solution.
Kevin Nixon, your independent security consultant needs to learn more about the end-to-end encryption solutions on the market. I suspect he is a QSA and fears that if security technology removes systems from PCI DSS scope he will be out of a job. It has nothing to do with doing security on the cheap, it has all to do with doing the best security. In fact, end-to-end encryption for many retailers will cost more than their annual PCI DSS assessment. Further, he argues such encryption could encrypt a worm and send it along. First, end –to-end encryption, done per Visa Data Field Encryption standards is done in the Tamper Resistant Security Module (TRMS) of the payment device which is protected by many of those layers Kevin talks about. And how could someone write a worm or malware and make it fit in the limited bytes of track data.
Perhaps next time you write an article about end-to-end encryption or tokenization you should consider talking to some of the vendors who are currently helping retailers protect sensitive cardholder data.
Jeff Wakefield
VP & General Manager, Global Security Solutions, VeriFone
_____________________________________________________________
Linda McGlasson
Managing Editor, Bank Information Security
I read the recent article you published on Tokenization versus End-to-End Encryption and I think there are several errors or misconceptions that should be corrected. Perhaps some of this comes from the bias of the experts you interviewed.
First the entire discussion of tokenization versus end-to-end encryption does not even make sense. This is not an either or solution, nor is it a large versus small company decision. Both tokenization and end-to-end encryption can improve the security of cardholder data and can work well together in many environments.
By definition, tokenization cannot take place at the point of card swipe. Cardholder data must be sent throughput the authorization process to a secure token server before a token could be generated and sent back in the response message. This is the main reason why tokenization cannot stand alone in protecting cardholder data. It will remain unprotected in payment terminals, POS systems and retailer host systems where it may be captured by malware planted by criminals.
However, for long term data storage, tokenization may be the ideal solution for many retailers. We are partnering with several processors and merchants to deploy solutions which protect cardholder data in transit with end-to-end encryption and data at rest with tokenization.
The first important point about end-to-end encryption is that it should take place as soon as the card is swiped and remain protected as it traverses the payment infrastructure until it is decrypted. If that decryption takes place at the merchant’s acquiring processor, then there is no unencrypted cardholder data in the retailer’s environment.
And I will have to disagree with Anton Chuvakin that no one can roll out and end to end encryption solution and have it secure and useable. If the acquirer is involved and the payment terminal manufacturer provides a robust end to end encryption solution then smaller Level 4 merchants can remove cardholder data in the clear from their environment. By following industry encryption and key management standards, such as defined by Visa in their recent Data Field Encryption Best Practices, larger merchants can also implement a secure and useable end-to-end encryption solution.
Kevin Nixon, your independent security consultant needs to learn more about the end-to-end encryption solutions on the market. I suspect he is a QSA and fears that if security technology removes systems from PCI DSS scope he will be out of a job. It has nothing to do with doing security on the cheap, it has all to do with doing the best security. In fact, end-to-end encryption for many retailers will cost more than their annual PCI DSS assessment. Further, he argues such encryption could encrypt a worm and send it along. First, end –to-end encryption, done per Visa Data Field Encryption standards is done in the Tamper Resistant Security Module (TRMS) of the payment device which is protected by many of those layers Kevin talks about. And how could someone write a worm or malware and make it fit in the limited bytes of track data.
Perhaps next time you write an article about end-to-end encryption or tokenization you should consider talking to some of the vendors who are currently helping retailers protect sensitive cardholder data.
Jeff Wakefield
VP & General Manager, Global Security Solutions, VeriFone
Friday, September 25, 2009
Is state-of-the-art security going to become a new legal standard?
In another recent case, a US District judge allowed a couple to bring a case against a bank, who alleged that the bank failed to implement state-of-the-art security technology, which resulted in their becoming victims of online bank account of about $26,000. The judge refused to dismiss the case, clearing the way for the court case to take place. The judge stated: “In light of citizens' apparent delay in complying with FFIEC security standards, a reasonable finder of fact could conclude that the bank breached its duty to protect Plaintiffs' account against fraudulent access.”
I'm sure this would apply for failure to implment PCI DSS requirements, but what about not using TDES after 7/1/10, or not implementing end to end encryption after several top retailer implement it?
http://www.securecomputing.net.au/News/156418,us-court-rules-that-bank-failed-to-protect-customer-against-fraud.aspx
I'm sure this would apply for failure to implment PCI DSS requirements, but what about not using TDES after 7/1/10, or not implementing end to end encryption after several top retailer implement it?
http://www.securecomputing.net.au/News/156418,us-court-rules-that-bank-failed-to-protect-customer-against-fraud.aspx
Does a Retailers Requirements to Protect cardholder data go beyond PCI?
Last week the US District Court in Maine threw out most of the claims in the class action lawsuits against Hannaford over their data breach. What they did not throw out was a claim that Hannaford had an implied duty to take reasonable measures to protect consumer data. What this means is in addition to several state laws that require protection of consumer data, retailers may become subject to an implied contract that they must protect the consumer data that they gather in the course of doing business. Other retailers have been assessed penalties for unfair practices in protecting consumer data by the Federal Trade Commission. While actual consumer damages in these breaches have been low because of the issuers card protection, I wonder if this opens the door for easier recovery of costs from merchants by the impacted financial institutions.
Former Congressman Does Not See Federal PCI Legislation Likely
Tom Davis, former US Congressman currently at Deloitte gave the keynote speech at the PCI SSC community meeting this week in Las Vegas. After some very interesting insights about how presidential job approval impacts congressional elections which is what drives much of Congress, he talked about the current climate on the hill for cyber security initiates, including legislation covering PCI. His view was there is benefit in congressional hearings to draw attention to the issue get the industry to look harder at its own initiatives, and such hearings will continue. However, there is no benefit to any congressman in pushing cyber security legislation of any kind until there is some kind of cyber Armageddon. He believes any federal legislation that covers PCI will not occur for the next foreseeable number of years. This is not to be confused with someone filing a piece of legislation. He ended by saying the private sector is way ahead of the government sector on both cyber security policy and implementation.
Wednesday, August 19, 2009
End-to-End Encryption: What’s Next?
While end to end encryption solutions like VeriShield Protect are valuable tools for retailers looking to protect their customers’ cardholder data, even more benefits are on the horizon.
The PCI Security Standards Council has engaged PricewaterhouseCoopers to conduct a study of new payment security technologies on securing cardholder data and achieving PCI DSS compliance.
The study, currently underway, is expected to recommend that if a true, secure end to end encryption scheme is implemented, many of the PCI DSS requirements would be met.
George Peabody of the Mercator Group estimates that retailers will save 80% of their on-going compliance costs and 75% of their PCI DSS audit costs by implementing a true end to end encryption solution like VeriShield Protect. In his analysis, that would translate to between $262,500 and $1,750,000 in annual savings to a retailer.
The PCI Security Standards Council has engaged PricewaterhouseCoopers to conduct a study of new payment security technologies on securing cardholder data and achieving PCI DSS compliance.
The study, currently underway, is expected to recommend that if a true, secure end to end encryption scheme is implemented, many of the PCI DSS requirements would be met.
George Peabody of the Mercator Group estimates that retailers will save 80% of their on-going compliance costs and 75% of their PCI DSS audit costs by implementing a true end to end encryption solution like VeriShield Protect. In his analysis, that would translate to between $262,500 and $1,750,000 in annual savings to a retailer.
VeriShield Protect Offers Benefits Beyond End to End Encryotion of Cardholder Data
In addition to the obvious benefits of encrypting cardholder data throughout a retailer’s enterprise, VeriShield Protect can assist retailers in improving the security of their systems and achieving PCI DSS compliance in many other ways.
While the PCI DSS requirements to not require cardholder data to be encrypted across private networks, retailers are challenged to maintain compliance with PCI DSS, and protection against breaches, 24x7 across their vast geographically disperse networks. Exploiting gaps in compliance or other weaknesses in retailers’ systems, criminals have been able to install Malware on retailers’ systems to capture cardholder data in transit. In the cat and mouse game of data theft and data protection, most retailers realize now that they need to protect cardholder data at all points in their systems, including data in motion during the authorization approval process. To protect cardholder data in transit, retailers often turn to solutions other than end to end encryption, like SSL connections between devices or software-based encryption schemes within their POS systems.
This presents challenges for many retailers however. Retailers with any of the following issues may find it difficult, if not impossible to provide the additional cardholder data protection they desire to properly protect their customers from the impact of a data breach. These challenges include:
· Retailers with older POS platforms
· Retailers who have mixed POS systems across their chain
· Retailers who are planning POS system upgrades in the next year or two
· Retailers who use public broadband networks for store communications
· Retailers with franchisees that make implementation of common systems difficult
The VeriShield Protect end to end encryption solution can overcome all of these challenges with a minimum of effort or disruption to the existing POS and store systems infrastructure.
Older systems with low processing bandwidth often cannot handle the processing overhead required to support encrypting communications between both the payment terminal and POS terminal, and between the POS terminal and the store server or host computer with SSL. In addition, older payment terminals and the DOS-based POS systems that are still installed usually cannot support SSL at all. VeriShield Protect, which does the encryption in the tamper-resistant security module (TRSM) within the payment terminal, overcomes the SSL limitation of older systems. And because VeriShield Protect uses Format Preserving Encryption (FPE), no changes are required to the POS systems in order to implement it.
Another challenge retailers are often faced with is the need to support multiple POS systems across their stores – due to store or chain acquisitions, different POS systems in different brands, or multi-year POS upgrades, often tied to store remodels. The challenge is the potential cost of implementing a data in transit protection scheme multiple times across each platform. Again, the Format Preserving Encryption of
VeriShield Protect solves this problem because it can be implemented across different POS systems without the need to change the POS system software.
In a similar fashion, VeriShield Protect can solve the challenge retailers who plan to upgrade their POS system in a few years face. These retailers are often reluctant to implement changes on their existing POS systems knowing the life of a project like this will be short, and they may prefer to use their resources getting a new POS system ready to deploy. Because VeriShield Protect can be implemented without any required POS changes, it is a great solution for retailers who want to protect their current system today, and then use the same solution for their new POS system in the future.
While most retailers use private networks, many find that using the public broadband infrastructure meets their requirements. PCI DSS requires that cardholder data which traverses public networks must be encrypted. VeriShield Protect with its transaction monitoring capability and its and secure key management functionality is an excellent way to meet this requirement without any impact on POS systems.
Retailers with franchise operators often face the most challenges of all. They may have multiple POS systems used by their operators and different systems they use in corporate stores. It is not uncommon for these retailers to have some operators access their network over a public broadband architecture. And finally, getting all of the franchise operators to implement common POS or store systems at the same time is usually impossible. By implementing a common payment terminal across all corporate and franchise locations that supports VeriShield Protect, retailers with franchise locations can insure that their customers’ cardholder will be protected whether they pay in a corporate or franchise owned store.
VeriShield Protect solution provides a wide range of benefits for all entities in the payment chain.
First, VeriShield Protect allows retailers to cost-effectively address three of the most difficult and expensive PCI DSS requirements.
· Requirement 3: Protect stored cardholder data
· Requirement 4: Encrypt transmission of cardholder data across open, public networks
· Requirement 5: Restrict physical access to data
Among the other key benefits are:
· Cardholder data is never exposed in the clear in the POS Environment
· Real-time monitoring improves encryption compliance and reduces the impact of costly audits, loss-prevention methods, and potential breaches
· There’s little or no impact on current POS systems and payment networks—no degradation of performance, and no changes required for most existing software
· BIN range checking continues to function as is, and nonpayment cards can be processed without encryption, if desired
· Cardholders are not impacted
For more information about VeriShield Protect and End-to-End Encryption, visit our web site www.verifone.com/verishield and download two white papers: “Protecting Cardholder Information: The Elusive Goal” and “Understanding End-to-End Encryption.”
While the PCI DSS requirements to not require cardholder data to be encrypted across private networks, retailers are challenged to maintain compliance with PCI DSS, and protection against breaches, 24x7 across their vast geographically disperse networks. Exploiting gaps in compliance or other weaknesses in retailers’ systems, criminals have been able to install Malware on retailers’ systems to capture cardholder data in transit. In the cat and mouse game of data theft and data protection, most retailers realize now that they need to protect cardholder data at all points in their systems, including data in motion during the authorization approval process. To protect cardholder data in transit, retailers often turn to solutions other than end to end encryption, like SSL connections between devices or software-based encryption schemes within their POS systems.
This presents challenges for many retailers however. Retailers with any of the following issues may find it difficult, if not impossible to provide the additional cardholder data protection they desire to properly protect their customers from the impact of a data breach. These challenges include:
· Retailers with older POS platforms
· Retailers who have mixed POS systems across their chain
· Retailers who are planning POS system upgrades in the next year or two
· Retailers who use public broadband networks for store communications
· Retailers with franchisees that make implementation of common systems difficult
The VeriShield Protect end to end encryption solution can overcome all of these challenges with a minimum of effort or disruption to the existing POS and store systems infrastructure.
Older systems with low processing bandwidth often cannot handle the processing overhead required to support encrypting communications between both the payment terminal and POS terminal, and between the POS terminal and the store server or host computer with SSL. In addition, older payment terminals and the DOS-based POS systems that are still installed usually cannot support SSL at all. VeriShield Protect, which does the encryption in the tamper-resistant security module (TRSM) within the payment terminal, overcomes the SSL limitation of older systems. And because VeriShield Protect uses Format Preserving Encryption (FPE), no changes are required to the POS systems in order to implement it.
Another challenge retailers are often faced with is the need to support multiple POS systems across their stores – due to store or chain acquisitions, different POS systems in different brands, or multi-year POS upgrades, often tied to store remodels. The challenge is the potential cost of implementing a data in transit protection scheme multiple times across each platform. Again, the Format Preserving Encryption of
VeriShield Protect solves this problem because it can be implemented across different POS systems without the need to change the POS system software.
In a similar fashion, VeriShield Protect can solve the challenge retailers who plan to upgrade their POS system in a few years face. These retailers are often reluctant to implement changes on their existing POS systems knowing the life of a project like this will be short, and they may prefer to use their resources getting a new POS system ready to deploy. Because VeriShield Protect can be implemented without any required POS changes, it is a great solution for retailers who want to protect their current system today, and then use the same solution for their new POS system in the future.
While most retailers use private networks, many find that using the public broadband infrastructure meets their requirements. PCI DSS requires that cardholder data which traverses public networks must be encrypted. VeriShield Protect with its transaction monitoring capability and its and secure key management functionality is an excellent way to meet this requirement without any impact on POS systems.
Retailers with franchise operators often face the most challenges of all. They may have multiple POS systems used by their operators and different systems they use in corporate stores. It is not uncommon for these retailers to have some operators access their network over a public broadband architecture. And finally, getting all of the franchise operators to implement common POS or store systems at the same time is usually impossible. By implementing a common payment terminal across all corporate and franchise locations that supports VeriShield Protect, retailers with franchise locations can insure that their customers’ cardholder will be protected whether they pay in a corporate or franchise owned store.
VeriShield Protect solution provides a wide range of benefits for all entities in the payment chain.
First, VeriShield Protect allows retailers to cost-effectively address three of the most difficult and expensive PCI DSS requirements.
· Requirement 3: Protect stored cardholder data
· Requirement 4: Encrypt transmission of cardholder data across open, public networks
· Requirement 5: Restrict physical access to data
Among the other key benefits are:
· Cardholder data is never exposed in the clear in the POS Environment
· Real-time monitoring improves encryption compliance and reduces the impact of costly audits, loss-prevention methods, and potential breaches
· There’s little or no impact on current POS systems and payment networks—no degradation of performance, and no changes required for most existing software
· BIN range checking continues to function as is, and nonpayment cards can be processed without encryption, if desired
· Cardholders are not impacted
For more information about VeriShield Protect and End-to-End Encryption, visit our web site www.verifone.com/verishield and download two white papers: “Protecting Cardholder Information: The Elusive Goal” and “Understanding End-to-End Encryption.”
California Financial Code and PCI Touchscreen Requirements
There has been some confusion in the market about how to meet the California Financial Code requirements and still meet PCI requirements on touch screen terminals. This bulletin is intended to clear that confusion up.
The California Financial Code requires that retailers provide tactile keypads to allow PIN entry for sight impaired individuals. While California is the only state with this law, and the federal regulations at the moment do not require this, several organizations have pushed national retailers to make the same accommodations. These organizations include the American Council for the Blind and the American Federation for the Blind, and in some cases those group’s state organizations. Several retailers have negotiated settlements with these groups after legal action was initiated. The most recent was Target, which settled on May 14th this year. In that case, Target agreed to upgrade every payment device to have a tactile keypad. The California Financial Code requires retailers to have a tactile keypad at every lane, except those retailers with just two lanes, who are allowed to have a tactile keypad in only one of those two lanes.
While the California law does not spell out specifics for the keypad, the associations for the blind, and the Federal Code call out several very specific requirements including the number layout, the raised dot on the 5 key, and the colors and raised symbols on the clear, enter and cancel keys. VeriFone products with keypads such as the MX 800 Series, the PP1000SE and the Vx 810 all meet these requirements.
The PCI Security Standards Council is concerned with the integrity of the payments system, not its accessibility to persons with disabilities. That is why the PCI PED requirements do allow a virtual PIN Pad on touch screen only terminals. While it was not spelled out in the early PCI PED requirements, the more current versions clearly state that overlays of any kind are not allowed on touch screen. This includes both keypad overlays which would provide accessibility to sight impaired individuals as well as protective overlays. The reason for this is the potential for criminals to embed technology within any kind of touch screen overlay that could be used to capture an individual’s PIN number. Whether this is a real or perceived threat, both MasterCard and Visa have confirmed that any kind of overlay on a touch screen device is not PCI compliant.
Retailers wanting to meet both PCI requirements as well as provide access to sight impaired individuals have two choices. First install a product that has a tactile keypad built in like the MX830, MX850, MX860 or MX870, or second, for products with touch screen only keypads, add an attached PIN Pad like the PP1000SE.
The California Financial Code requires that retailers provide tactile keypads to allow PIN entry for sight impaired individuals. While California is the only state with this law, and the federal regulations at the moment do not require this, several organizations have pushed national retailers to make the same accommodations. These organizations include the American Council for the Blind and the American Federation for the Blind, and in some cases those group’s state organizations. Several retailers have negotiated settlements with these groups after legal action was initiated. The most recent was Target, which settled on May 14th this year. In that case, Target agreed to upgrade every payment device to have a tactile keypad. The California Financial Code requires retailers to have a tactile keypad at every lane, except those retailers with just two lanes, who are allowed to have a tactile keypad in only one of those two lanes.
While the California law does not spell out specifics for the keypad, the associations for the blind, and the Federal Code call out several very specific requirements including the number layout, the raised dot on the 5 key, and the colors and raised symbols on the clear, enter and cancel keys. VeriFone products with keypads such as the MX 800 Series, the PP1000SE and the Vx 810 all meet these requirements.
The PCI Security Standards Council is concerned with the integrity of the payments system, not its accessibility to persons with disabilities. That is why the PCI PED requirements do allow a virtual PIN Pad on touch screen only terminals. While it was not spelled out in the early PCI PED requirements, the more current versions clearly state that overlays of any kind are not allowed on touch screen. This includes both keypad overlays which would provide accessibility to sight impaired individuals as well as protective overlays. The reason for this is the potential for criminals to embed technology within any kind of touch screen overlay that could be used to capture an individual’s PIN number. Whether this is a real or perceived threat, both MasterCard and Visa have confirmed that any kind of overlay on a touch screen device is not PCI compliant.
Retailers wanting to meet both PCI requirements as well as provide access to sight impaired individuals have two choices. First install a product that has a tactile keypad built in like the MX830, MX850, MX860 or MX870, or second, for products with touch screen only keypads, add an attached PIN Pad like the PP1000SE.
Thursday, August 13, 2009
Tactile PIN Debit Keypads required in all stores by 1/1/10.
Several years ago, the California Legislature passed Financial Code 13082, which requires all point-of-sale devices that have a touch screen keypad to also offer a tactile keypad to allow visually impaired individuals to enter their PIN securely. As of January 1, 2010 all retailers must comply with this law, which requires all retailers with more than 2 such devices to equip each one with a tactile keypad, and those with 2 lanes or less to equip one such device.
The actual text of the California law follows.
California Financial Code 13082
Sourced at: http://www.leginfo.ca.gov/calaw.html
(a) Whenever a point-of-sale system is changed or modified to include a video touch screen or any other nontactile keypad, the point-of-sale device that would include the video touch screen or nontactile keypad shall also be equipped with a tactually discernible numerical keypad similar to a telephone keypad containing a raised dot with a dot base diameter between 1.5 millimeters and 1.6 millimeters and a height between 0.6 millimeters and 0.9 millimeters on the number 5 key that enables a visually impaired person to enter his or her own personal identification number or any other personal information necessary to process the transaction in a manner which provides the opportunity for the same degree of privacy input and output available to all individuals.
(b) (1) On or before January 1, 2010, any existing point-of-sale system, except as provided in paragraph (2), that includes a video touch screen or any other nontactile keypad shall also be equipped with a tactually discernable keypad as described in subdivision (a).
(2) At locations equipped with two or less point-of-sale machines, only one point-of-sale machine shall be required to be equipped with a tactually discernible keypad on or before January 1, 2010, as described in subdivision (a).
(c) On and after January 1, 2006, a manufacturer or distributor shall be required to offer for availability touch screen or other nontactile point-of-sale devices to be used and sold in this state that are equipped with tactually discernible keypads as described in subdivision (a) that enable a visually impaired person to enter his or her own personal identification number or any other personal information necessary to process a transaction in a manner that ensures personal privacy of the information being entered.
(d) As used in this section, "point-of-sale device" includes any device used by a customer for the purchase of a good or service where a personal identification number (PIN) is required, but does not include the following: (1) An automated teller machine as defined in subdivision (c) of Section 13020. (2) A point-of-sale device that is equipped to, or exclusively services, motor fuel dispensers. (e) This section shall not be construed to preclude or limit any other existing right or remedy as it pertains to point-of-sale devices and accessibility.
The actual text of the California law follows.
California Financial Code 13082
Sourced at: http://www.leginfo.ca.gov/calaw.html
(a) Whenever a point-of-sale system is changed or modified to include a video touch screen or any other nontactile keypad, the point-of-sale device that would include the video touch screen or nontactile keypad shall also be equipped with a tactually discernible numerical keypad similar to a telephone keypad containing a raised dot with a dot base diameter between 1.5 millimeters and 1.6 millimeters and a height between 0.6 millimeters and 0.9 millimeters on the number 5 key that enables a visually impaired person to enter his or her own personal identification number or any other personal information necessary to process the transaction in a manner which provides the opportunity for the same degree of privacy input and output available to all individuals.
(b) (1) On or before January 1, 2010, any existing point-of-sale system, except as provided in paragraph (2), that includes a video touch screen or any other nontactile keypad shall also be equipped with a tactually discernable keypad as described in subdivision (a).
(2) At locations equipped with two or less point-of-sale machines, only one point-of-sale machine shall be required to be equipped with a tactually discernible keypad on or before January 1, 2010, as described in subdivision (a).
(c) On and after January 1, 2006, a manufacturer or distributor shall be required to offer for availability touch screen or other nontactile point-of-sale devices to be used and sold in this state that are equipped with tactually discernible keypads as described in subdivision (a) that enable a visually impaired person to enter his or her own personal identification number or any other personal information necessary to process a transaction in a manner that ensures personal privacy of the information being entered.
(d) As used in this section, "point-of-sale device" includes any device used by a customer for the purchase of a good or service where a personal identification number (PIN) is required, but does not include the following: (1) An automated teller machine as defined in subdivision (c) of Section 13020. (2) A point-of-sale device that is equipped to, or exclusively services, motor fuel dispensers. (e) This section shall not be construed to preclude or limit any other existing right or remedy as it pertains to point-of-sale devices and accessibility.
Wednesday, August 12, 2009
The Evolution of Payment Terminal Standards
Almost since the inception of payment terminals, there has been concern about criminals tampering with these devices to capture card information for fraudulent purposes. In 1997, Visa issued the first security requirements for PIN Entry Devices. Effective January 1, 2008, all newly deployed PIN entry terminals were required to meet this standard. Manufacturers did not have to submit terminals to independent labs for certification against this standard; rather they simply attested that the standard was met. In 2002, Visa enhanced their PED security program with additional security requirements and the requirement that terminals be submitted to a Visa approved lab for approval. In May of 2003, Visa announced that effective January 1, 2004, all newly deployed terminals must meet this standard and as of July 1, 2010, all installed terminals must have met this standard and independently tested by a lab.
In 2004, MasterCard and Visa agreed to develop one set of PIN Entry Device requirements, which became known as PCI PED. As part of this agreement they announced that all newly deployed terminals after January 1, 2008 must meet this requirement.
In 2005, the card associations (American Express, Discover, JCB, MasterCard and Visa) formed the PCI Security Standards Council to standardize payment standards they required retailers to adhere to (The PCI DSS or Data Security Standard). In September 2006, the PCI SSC announced that they would take over the management and development of the PED Standard, and they released the PCI PED 2.0 Requirements in April of 2007. Next in the evolution of Payment Terminal Standards will be the introduction of the PTS (PIN Transaction Security Program) at the PCI SSC community meeting in September 2009.
The following chart illustrates the timeline of the evolution of payment terminal standards.
In 2004, MasterCard and Visa agreed to develop one set of PIN Entry Device requirements, which became known as PCI PED. As part of this agreement they announced that all newly deployed terminals after January 1, 2008 must meet this requirement.
In 2005, the card associations (American Express, Discover, JCB, MasterCard and Visa) formed the PCI Security Standards Council to standardize payment standards they required retailers to adhere to (The PCI DSS or Data Security Standard). In September 2006, the PCI SSC announced that they would take over the management and development of the PED Standard, and they released the PCI PED 2.0 Requirements in April of 2007. Next in the evolution of Payment Terminal Standards will be the introduction of the PTS (PIN Transaction Security Program) at the PCI SSC community meeting in September 2009.
The following chart illustrates the timeline of the evolution of payment terminal standards.
Interesting Skimmer Found in a US retailer
Here is an interesting picture of a skimmer, apparently uncovered by Knoxville area law enforcement. Its the first time I have seen a picture of an the entire top case of a payment terminal being used as a skimming device!
The full article is
Tuesday, August 11, 2009
Wireless Check Deposit via the iPhone
Pretty neat application from USAA which lets customers deposit checks wirelessly by taking a photo of both sides of the check using the iPhone's built-in camera, and then sending an image of a check directly to USAA where it can be verified and deposited.
See the complete story here
Wednesday, July 29, 2009
VeriFone ranked 3rd best peripherals vendor by retailers!
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.
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.
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
Thursday, June 25, 2009
TJX Agrees to Security Pilot Programs and to push End to End Encryption
There were some interesting terms agreed to by TJX in the TJX/State Settlement. First, TJX agrees to participate in pilot programs for new payment security technology, such as chip and pin, if asked to do so by MasterCard or Visa within 2 years of the date of the agreement. After two years, I guess they can say no.
Second, they agreed to take steps within the next 180 days to encourage the development of end to end encryption including seeking the cooperation of their acquiring bank.
The text of these section appears below. A copy of the entire agreement can be found at: http://storefrontbacktalk.com/story/TJX%20Agreement.pdf
The Attorneys General and TJX believe that the security of Cardholder Information collected in connection with retail transactions is an important priority. Protecting Cardholder Information is a dynamic challenge, because as security technologies available to retailers evolve, criminals attempt to develop more sophisticated ways of trying to circumvent such technologies. The Attorneys General and TJX therefore agree that possible improvements within the payment card system could aid the protection of consumers. To further that goal, TJX agrees as follows:
A. Pilot Programs. TJX will notify Visa and MasterCard in the United States and its acquiring bank(s) in the United States, simultaneous with the execution of this Assurance, that TJX desires to participate in pilot programs for testing new security-related payment card technology, such as the chip-and-PIN technology that is used in many other countries. TJX will participate in such program(s), if invited to do so, within two (2) years following the Effective Date of this Assurance, provided that any new security-related payment card technology and the terms and conditions of such participation are considered in good faith by TJX to be feasible and reasonable.
B. New Encryption Technologies. TJX will take steps over the one hundred eighty (180) days following the Effective Date of this Assurance, to encourage the development of new technologies within the Payment Card Industry to encrypt Cardholder Information during some or all of the bank authorization process with a goal of achieving "end-to-end" encryption of Cardholder Information (i.e, from PIN pad to acquiring ban). Such methods may include but are not limited to encouraging the development of new technologies and seeking the cooperation of TJX's acquiring bank(s) in the United States and other appropriate third parties. TJX will provide the Attorneys General, within one hundred eighty (180) days following the Effective Date, with a report specifying its progress in this effort.
Second, they agreed to take steps within the next 180 days to encourage the development of end to end encryption including seeking the cooperation of their acquiring bank.
The text of these section appears below. A copy of the entire agreement can be found at: http://storefrontbacktalk.com/story/TJX%20Agreement.pdf
The Attorneys General and TJX believe that the security of Cardholder Information collected in connection with retail transactions is an important priority. Protecting Cardholder Information is a dynamic challenge, because as security technologies available to retailers evolve, criminals attempt to develop more sophisticated ways of trying to circumvent such technologies. The Attorneys General and TJX therefore agree that possible improvements within the payment card system could aid the protection of consumers. To further that goal, TJX agrees as follows:
A. Pilot Programs. TJX will notify Visa and MasterCard in the United States and its acquiring bank(s) in the United States, simultaneous with the execution of this Assurance, that TJX desires to participate in pilot programs for testing new security-related payment card technology, such as the chip-and-PIN technology that is used in many other countries. TJX will participate in such program(s), if invited to do so, within two (2) years following the Effective Date of this Assurance, provided that any new security-related payment card technology and the terms and conditions of such participation are considered in good faith by TJX to be feasible and reasonable.
B. New Encryption Technologies. TJX will take steps over the one hundred eighty (180) days following the Effective Date of this Assurance, to encourage the development of new technologies within the Payment Card Industry to encrypt Cardholder Information during some or all of the bank authorization process with a goal of achieving "end-to-end" encryption of Cardholder Information (i.e, from PIN pad to acquiring ban). Such methods may include but are not limited to encouraging the development of new technologies and seeking the cooperation of TJX's acquiring bank(s) in the United States and other appropriate third parties. TJX will provide the Attorneys General, within one hundred eighty (180) days following the Effective Date, with a report specifying its progress in this effort.
Wednesday, June 24, 2009
Nevada Data Encryption Law Has Wide Coverage
Nevada recently enacted a new Data Protection law which replaced the previous law that was in effect for less than a year. The new law has some broad-reaching implications. The law applies to any business that has any transactions or employees located in the state, no matter where their headquarters are located and requires those businesses that accept credit cards to “comply with the current version” of the PCI DSS.
The text of the law is as follows:
"If a data collector doing business in this State accepts a
payment card in connection with a sale of goods or services, the
data collector shall comply with the current version of the
Payment Card Industry (PCI) Data Security Standard, as adopted
by the PCI Security Standards Council or its successor
organization, with respect to those transactions, not later than the
date for compliance set forth in the Payment Card Industry (PCI)
Data Security Standard or by the PCI Security Standards Council
or its successor organization."
While the law requires data encryption for personal information transmitted outside of the enterprise, it does not apply for data transmission over a secure, private communication channel for approval or processing of negotiable instruments, electronic fund transfers or similar payment methods.
Data sent over public communication links needs to be encrypted, in a secure approved manner as spelled out in the law.
The previous version of the law defined personal information as unencrypted information consisting of an individual's last name and first name (or first initial), combined with his or her Social Security number, driver's license or identification card number, or financial account number plus password or access code.
The law also states that is a business (data collector in the law's terminology) is compliant with the law, then the business shall not be liable for damages unless there is gross misconduct involved.
The Nevada law is scheduled to go into effect January 1, 2010.
The full text of the law can be found here: https://www.leg.state.nv.us/75th2009/Bills/SB/SB227_EN.pdf
The text of the law is as follows:
"If a data collector doing business in this State accepts a
payment card in connection with a sale of goods or services, the
data collector shall comply with the current version of the
Payment Card Industry (PCI) Data Security Standard, as adopted
by the PCI Security Standards Council or its successor
organization, with respect to those transactions, not later than the
date for compliance set forth in the Payment Card Industry (PCI)
Data Security Standard or by the PCI Security Standards Council
or its successor organization."
While the law requires data encryption for personal information transmitted outside of the enterprise, it does not apply for data transmission over a secure, private communication channel for approval or processing of negotiable instruments, electronic fund transfers or similar payment methods.
Data sent over public communication links needs to be encrypted, in a secure approved manner as spelled out in the law.
The previous version of the law defined personal information as unencrypted information consisting of an individual's last name and first name (or first initial), combined with his or her Social Security number, driver's license or identification card number, or financial account number plus password or access code.
The law also states that is a business (data collector in the law's terminology) is compliant with the law, then the business shall not be liable for damages unless there is gross misconduct involved.
The Nevada law is scheduled to go into effect January 1, 2010.
The full text of the law can be found here: https://www.leg.state.nv.us/75th2009/Bills/SB/SB227_EN.pdf
Friday, June 19, 2009
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
These requirements are included on the MasterCard web site here: http://www.mastercard.com/us/sdp/merchants/merchant_levels.html
Thursday, June 18, 2009
DOJ warns of escalating criminal assault on the payment system
Kimberly Peretti, Senior Counsel, Computer Crime Division, Department of Justice recently spoke at the MasterCard Global Risk Management Conference. Among the highlights of her presentation:
- Criminals are now targeting HSM’s. With this, they could easily decrypt PIN's
- DUKPT has been breached. In one case, criminals stole the data in 2004, but it took them 2 years to crack DUKPT. They were aided by having the full Track 2 data which includes the Pin Verification Value (PVV). Having done this once, they are more sophisticated now and should be able to crack encrypted PINS less time if they try it again.
- The group that is targeting processors is still targeting retailers.
- There has been a huge explosion of breached retail and financial industry networks in the last three years. There are numerous examples of network breaches without card data compromise. Its like exploring for oil but not drilling until the price is right, criminals are doing the same thing.
FBI Cyber Director warns industry of fraud risk
Shaun Henry, Assistant Director, Cyber Division, FBI spoke recently at the MasterCard Global Risk Management Conference. Among the things I found either interesting or scary were:
- Businesses don’t understand the cyber threat today. They can't feel it, touch it or imagine it, so it is hard to worry about is and prepare for it.
- Criminals are breaching systems everyday and waiting for the opportune time to steal the information. Their breaches leave little trace until a compromise occurs. They cover their tracks and wait to harvest cardholder information. Their presence is not removed after scanning, reloading computers, password changes, network reconfiguration, etc.
- Some Malware waits for specific vulnerabilities to appear before acting, for instance, when a patch is found that has not been applied. They go back to a breached system to see if the patch has been applied, and if not they exploit the vulnerability.
- There are three types of groups that are attacking systems today.
1. Individuals and Hacker Groups
2. Terrorist Organizations and Sympathizers
3. Advanced and Developing Cyber States
- Overall, criminal attacks are escalating
1st – Steal data for themselves and convert to cash
2nd – Steal data and sell it to others for exploitation
3rd – Hijack you systems for extortion (T-Mobile?)
- You need to rethink everything, all your assumptions about data security.
How do you know your downloads are safe? How do you know they have not already been infected? How do you know the hallmark card an employee downloaded simply contained malicious software and not malware designed to steal cardholder data? Look for criminal entry and data exodus everywhere - not just where you might expect them. - Adversaries with the interest, ability and intent to get your information can and will breach your system.
Malware emerging as primary data breach weapon
Chris Novak from Verizon provided an update at the MasterCard Global Risk Management Conference in Miami two weeks ago.
Malware is a rising method of attack, and in 25% of the Malware attacks, the software was written specifically for the environment that was attacked.
There are three new emerging kinds of attacks. Ram Scrappers running in memory, packet sniffers capturing data in motion, and malware that resides in unallocated disk space and is hard to locate.
Malware is a rising method of attack, and in 25% of the Malware attacks, the software was written specifically for the environment that was attacked.
There are three new emerging kinds of attacks. Ram Scrappers running in memory, packet sniffers capturing data in motion, and malware that resides in unallocated disk space and is hard to locate.
MasterCard Global Risk Management Conference
I attended the recent MasterCard Global Risk Management Conference in Miami a couple of weeks ago. I will be entering some posts based on some of the things that were covered by the speakers.
The opening speaker was Wendy Murdock, the Chief Franchise Officer for MasterCard. Some of her interesting and main points:
The opening speaker was Wendy Murdock, the Chief Franchise Officer for MasterCard. Some of her interesting and main points:
- 93% of the breached records from 2008 were from financial services firms
- MasterCard processes 21B transactions a year from 24M acceptance points.
- They estimate that cardholder data is stored in over 200,000 locations globally (Wow - lots of places to protect and lots of places for criminals to try to find an open window.)
- She stated that if the industry can not solve the problem, it will force the government to put in place "burdensome regulations."
- Financial institutions need "proper incentives" to insure compliance. (She did not share her thoughts on what they need to be.)
- MasterCard needs better channels for sharing fraud information. (How about the SPVA and the PPISC?)
- The industry must use all tools, whether PCI or targeted encryption solutions to solve the problem. (How about end to end encryption!)
Subscribe to:
Posts (Atom)