While major updates to the PCI Data Security Standard get issues with new versions, such as the one to be published later this year, the PCI Security Standards Council often releases FAQ’s that provide clarification or guidance to merchants and QSA’s. In December, the PCI SSC published an FAQ dealing with the impact of end to end encryption on PCI Scope. While couched in several disclaimers, the highlighted section below says that encrypted data can be considered out of scope if the retailer does not have the means to decrypt the data. This is a huge win for retailers looking to implement end to end encryption technology both to improve the security of cardholder data in their environment as well as reduce their on-going PCI compliance and assessment costs.
As when implementing any new payment architecture or technology, you should consult with your QSA during the evaluation, planning and implementation processes to maximize the benefits you receive when implementing a new payment architecture or technology like end to end encryption.
Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?
The Council will be developing more formal guidance around this topic, leveraging information that is received through the various channels of the DSS lifecycle feedback process. Until further guidance is provided by the Council, the following should be taken into consideration regarding encrypted cardholder data.
Encryption solutions are only as good as the industry-approved algorithms and key management practices used, including security controls surrounding the encryption/decryption keys (“Keys”). If Keys are left unprotected and accessible, anyone can decrypt the data. The DSS has specific encryption key management controls (DSS 3.5 and 3.6), however, other DSS controls such as firewalls, user access controls, vulnerability management, scanning, logging and application security provide additional layers of security to prevent malicious users from gaining privileged access to networks or cardholder data environments that may grant them access to Keys. It is for this reason that encrypted cardholder data is in scope for PCI DSS.
However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entity’s environment, from obtaining access to Keys.
Furthermore, service providers or vendors that provide encryption solutions to merchants who have administrative access and controls to Keys along with the management of termination points for encryption to process transactions, are required to demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices (such as NIST referenced in PCI DSS requirement 3.6), along with full compliance with PCI DSS.
Merchants should ensure their solution providers who provide key management services and/or act as the point of encryption/decryption are in compliance with PCI DSS. Merchants should be aware that encryption solutions most likely do not remove them completely from PCI DSS. Examples of where DSS would still be applicable include usage policies, agreements with service providers that deploy payment solutions, physical protection of payment assets and any legacy data and processes (such as billing, loyalty, marketing databases) within the merchant's environment that may still store, process or transmit clear text cardholder data, as that would remain in scope for PCI DSS.
The full PCI SSC FAQ’s can be found here. Click on the FAQ link in the left navigation bar. This specific FAQ can be found here.
Thursday, February 4, 2010
Thursday, January 21, 2010
Independent QSA Technical Assessment of VeriShield Protect
VeriFone has contracted with Coalfire Systems, Inc. a leading IT security consulting firm and PCI QSA to conduct an independent technical assessment of VeriShield Protect. The goal of this assessment is to determine if VeriShield Protect meets and follows industry standards, how a proper implementation of VeriShield Protect can improve the security of a retailer’s cardholder environment and the impact VeriShield Protect can have on reducing PCI scope and compliance costs.
The assessment is complete and a white paper of the findings will be published in February. The assessment by Coalfire included lab testing of the system, evaluation of VeriShield Protect as implemented at a Tier 1 retailer and a review of all planned deployment scenarios.
At NRF, Kennet Westby, Coalfire co-founder and COO, presented the initial findings from their assessment to a breakfast meeting of retail CIO’s and security executives. An executive summary from the forthcoming whitepaper was also released at NRF.
Key points from this executive summary include:
• A properly deployed VeriShield Protect solution can provide significant risk mitigation of data compromise and may be one of the most effective controls available to merchants today.
• There can be very clear and dramatic reduction of PCI compliance scope with a properly deployed VeriShield Protect solution.
• The benefit to merchants is the VeriShield Protect solution can reduce the cost of PCI compliance assessment and validation and allow them to invest more of those dollars into risk mitigating controls.
• The VeriShield Protect solution integrates securely with PC based POS or cash registers without exposing card data, encryption keys or authentication data to these platforms.
• The format preserving VeriShield Hidden Encryption provided successful integration with all payment application, POS and back-office servers tested.
• The integration with tested payment applications and POS systems was quick, required very little customization and worked effectively with all post authorization, sales audit and refund transactions tested
• The VeriShield Protect solution meets all VISA Data Field Encryption Best Practices.
• VeriShield Hidden Encryption meets encryption best practices and standards for cryptographic algorithms and key strength. The format preserving methods meet industry standards and VISA best practice guidance.
• The key management processes of the VeriShield Protect solution remove most of the challenges of key management for the merchant that are found in many previous end point encryption solutions
• The VeriFone terminal should be the only point in a merchant environment that captures card data through swipe or keyed entry to achieve the greatest security and PCI compliance scope reduction
• A payment application or POS that is not PABP/PA-DSS validated can be taken out of PCI scope if all payment data is captured through the VeriShield Protect solution and the system is cleansed of all legacy card data.
• A deployment architecture that has all card data captured in a VeriShield Protect TRSM and communicates directly to a PCI compliant processer who manages all decryption services for the merchant provides the greatest security and compliance risk mitigation.
• A merchant should have ownership rights to the decryption keys but not have access or possession of keys to achieve the greatest PCI scope reduction.
• A merchant can remove PCI compliance scope for the majority of their retail environment if all electronic card data is captured in a VeriShield Protect TRSM and no decryption appliances or decryption keys exist in their environment.
• The VSDMS provides effective compliance and security auditing for the merchant and QSA. Store validation sampling of compliance is simplified with this tool set. Compliance reporting overtime is easily evidenced for auditors using the VSDMS.
• The VeriFone VeriShield Protect solution impressed the Coalfire technical assessment team and their QSA auditors. The technology and tools are well architected and effective. The maturing of the solution based on their assessment input, customer feedback and industry best practice was equally impressive. Solution support, technical capabilities and security expertise of both VeriFone and its technology partner have benefited early customers in achieving their security and compliance goals.
This full executive summary can be downloaded here.
The assessment is complete and a white paper of the findings will be published in February. The assessment by Coalfire included lab testing of the system, evaluation of VeriShield Protect as implemented at a Tier 1 retailer and a review of all planned deployment scenarios.
At NRF, Kennet Westby, Coalfire co-founder and COO, presented the initial findings from their assessment to a breakfast meeting of retail CIO’s and security executives. An executive summary from the forthcoming whitepaper was also released at NRF.
Key points from this executive summary include:
• A properly deployed VeriShield Protect solution can provide significant risk mitigation of data compromise and may be one of the most effective controls available to merchants today.
• There can be very clear and dramatic reduction of PCI compliance scope with a properly deployed VeriShield Protect solution.
• The benefit to merchants is the VeriShield Protect solution can reduce the cost of PCI compliance assessment and validation and allow them to invest more of those dollars into risk mitigating controls.
• The VeriShield Protect solution integrates securely with PC based POS or cash registers without exposing card data, encryption keys or authentication data to these platforms.
• The format preserving VeriShield Hidden Encryption provided successful integration with all payment application, POS and back-office servers tested.
• The integration with tested payment applications and POS systems was quick, required very little customization and worked effectively with all post authorization, sales audit and refund transactions tested
• The VeriShield Protect solution meets all VISA Data Field Encryption Best Practices.
• VeriShield Hidden Encryption meets encryption best practices and standards for cryptographic algorithms and key strength. The format preserving methods meet industry standards and VISA best practice guidance.
• The key management processes of the VeriShield Protect solution remove most of the challenges of key management for the merchant that are found in many previous end point encryption solutions
• The VeriFone terminal should be the only point in a merchant environment that captures card data through swipe or keyed entry to achieve the greatest security and PCI compliance scope reduction
• A payment application or POS that is not PABP/PA-DSS validated can be taken out of PCI scope if all payment data is captured through the VeriShield Protect solution and the system is cleansed of all legacy card data.
• A deployment architecture that has all card data captured in a VeriShield Protect TRSM and communicates directly to a PCI compliant processer who manages all decryption services for the merchant provides the greatest security and compliance risk mitigation.
• A merchant should have ownership rights to the decryption keys but not have access or possession of keys to achieve the greatest PCI scope reduction.
• A merchant can remove PCI compliance scope for the majority of their retail environment if all electronic card data is captured in a VeriShield Protect TRSM and no decryption appliances or decryption keys exist in their environment.
• The VSDMS provides effective compliance and security auditing for the merchant and QSA. Store validation sampling of compliance is simplified with this tool set. Compliance reporting overtime is easily evidenced for auditors using the VSDMS.
• The VeriFone VeriShield Protect solution impressed the Coalfire technical assessment team and their QSA auditors. The technology and tools are well architected and effective. The maturing of the solution based on their assessment input, customer feedback and industry best practice was equally impressive. Solution support, technical capabilities and security expertise of both VeriFone and its technology partner have benefited early customers in achieving their security and compliance goals.
This full executive summary can be downloaded here.
Friday, October 23, 2009
VeriShield Protect Meets Visa Data Encryption Best Practices
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.
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.
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.
Subscribe to:
Posts (Atom)