“Over the past year, there has been a considerable spike in cyber attacks against the financial services and the online retail industry. There are a number of actions a firm can take in order to prevent or thwart the specific attacks and techniques used by these intruders.”
There are 12 Recommendations here, 11 of those, that in all honestly, should not be new to any one addressing IT Security or PCI Compliance – I can map each of these 11 to a PCI requirement:
- Recommendation 1,2,4,6,8 : maps to PCI 2.2.x “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”
- Recommendation 3: maps to PCI 6.5.x “Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes”
- Recommendation 5: maps to PCI 7.2.x “Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.”
- Recommendation 7: maps to PCI 8.5.13 “Ensure proper user authentication and password management for non-consumer users and administrators on all system components”
- Recommendation 9,10: maps to PCI 1.3.x “Prohibit direct public access between the Internet and any system component in the cardholder data environment.”
- Recommendation 11: maps to PCI 1.2.1 “Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.”
The last one is a little different and or not as common as the items above:
Recommendation 12: Ensure your HSM systems are not responsive to any commands which generate encrypted pin blocks. More specifically, HSMs should not accept commands that allow plain text PINs as an argument and respond with encrypted PIN blocks.
HSMs are normally used to verify Personal Identification Numbers (PINs), generate PINs used with bank accounts and credit cards, generate encrypted Card Verification Values (CVVs), generate keys for Electronic Funds Transfer Point of Sale systems (EFTPOS), and generating and verifying Message Authorization Codes (MACs). These systems, if accessed by an unauthorized intruder, can provide the attacker the ability to discover the appropriate PIN number for a corresponding credit or debit card. Therefore, in an effort to prevent this, HSMs should be configured to disallow “in the clear” PINs as an argument for performing its tasks.
This recommendation discusses configuration options with Hardware Security Modules or HSM’s. There is a attack that allows an attacker to derive how a PIN is encrypted if the HSM Allows for functions that allow a Clear PIN as an input an attacker can send various clear PINs and analyze the output from the HSM.
At one of our acquiring clients we communicate with a Thales 8000 HSM. The functions that we are are for PIN Translations for Debit/EBT Transactions. The functions that we use for this do not involve a clear pin, we receive an encrypted PIN Block from the Point-of-Sale and PIN-Pad that we translate to a different PIN Block under a different encryption key to the Debit/EBT Networks and/or providers.
Looking at the “Thales — Console Reference Manual” – I see this option:
Select clear PINs: Yes or No
This enables the clear PIN support via host commands „NG? and „BA?. Authorised state is
a requirement for these commands to be processed by a host application.
Note: This is a security risk unless precautions are taken at the host.
The Manual states that this is clearly a bad thing:
So for Requirement 12 – Make sure that you are not using any “Clear PIN’s” and any function that allow “Clear PIN’s” as an argument are not enabled.