There have been a lot of retailers making headlines for payment system breaches, where millions of credit card numbers have been stolen. After a breach, the retailer has to take a hard look at the people, processes, and technology that are in place in their Information Security organization. How the organization complies with their own Information Security policies, standards, and guidelines must be analyzed and the gaps in infrastructure and applications must be identified and prioritized so that risk can be greatly reduced.
For any organization that processes, stores, and transmits cardholder data, the Payment Card Industry Data Security Standard (PCI-DSS) helps keep cardholder data secure. There are 6 objectives supported by 12 high-level requirements and over 200 detailed requirements. The number of requirements that apply to an entity that is storing, transmitting, or processing cardholder data depends on the number of transactions processed, the cardholder data flow, and if there has been an egregious violation. Egregious violations occur when the following is present on a network: a Primary Account Number (PAN) stored in the clear in a database, a PAN transmitted in the clear over an open public network, or stored sensitive authentication data. This authentication data includes full track data from the magnetic stripe or chip, the 3- or 4-digit code on the front or back of the credit card (CAV2/CVC2/CVV2/CID), or personal identification numbers (PINs/PIN blocks). So even a merchant with low transaction volumes could have all 239 requirements apply if they have not properly scoped or implemented the network and cardholder data handling.
Requirements three and four fall under the objective, Protect Cardholder Data, and define critical protection methods that use cryptography. The cryptography has to be implemented in a secure manner to keep intruders out. “If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.” (PCI-DSS, pg. 34) So there are a lot of requirements, but underlying the security of the entire PCI-DSS is the application of strong cryptography in the right places and the assurance that the private keys are protected. Private keys must stay private. Failure to do so undermines all of the other security controls that are in place.
So how does one protect a private key? The PCI-DSS requirement 3.5.2 goes into detail on this, and I will blog about this next month. For now, I want to highlight the physical security requirements under requirement 9, Restrict Physical Access to Cardholder Data. To do this I want to share my experience in having implemented a Certification Authority (CA). Five tiers of physical security, were implemented to secure the Root CA, which was an offline CA, and four for the online CAs:
I know you’re not all protecting Certification Authority keys, however, the care taken to protect CA keys, should be thought about for the private keys on the payment network. In order to protect private keys there has to be physical and network defense in depth present. I could argue that all 239 PCI-DSS requirements should be in place to protect private keys. But I bet most organizations do not give private encryption keys much thought, and therefore, do not know what private keys are on their network, who put them there, if they have been rotated, if they are accessible by only the key custodians or by any administrator, and if they are exposed to the internet because of zero-day malware or other Trojans that have gone undetected.
There are numerous current attacks on private keys. Yes, I know some are because the X.509 standard was not implemented properly, and this was taken advantage of by intruders and malicious individuals. But in your organization, can you be sure that the wrong people don’t have your private keys, that an intruder has not replaced them, and that you have all the proper controls in place to ensure this?