Since last month’s blog where I started to discuss the importance of protecting private keys in payment networks, even more retailers have made the news for credit card data breaches. I also personally received a new debit card because of these high-profile retailer data breaches. This is a cause for concern for both retailers and consumers. When cardholder data is stolen, it costs a lot of money to replace the credit and debit cards and refund the money to the cardholder for purchases they did not make. This cost could be passed along to the consumer via paying more for goods and services due to higher merchant interchange rates. So, protecting the private keys that keep the payment card systems data from being disclosed, modified, or unavailable is very important.
While proper compliance to all of the applicable requirements of the Payment Card Industry Data Security Standard (PCI-DSS) to your cardholder data environment will ultimately help protect your private keys and secure your cardholder data, here I want to cover the requirements specific to managing and securing keys. The first step in this process is to know where the private keys are on the cardholder data network. (PCI-DSS req. 2.4) Organizations can accomplish this by providing an inventory of their private keys and where they are located. Once private key locations are known, the rest of the requirements involved in securing keys can be met.
Requirement 3 of the PCI-DSS addresses securing encryption keys with the intent to protect keys so that the cardholder data is not exposed. These requirements use the words exposed or disclosed. When I see this language, I think of confidentiality—one of the pillars of information security. Confidentiality, through using encryption, keeps data from being exposed or disclosed, when it should not be, and is a form of access control. There are several steps to securing the keys during their lifecycle, including access control, proper approvals, and any policies that have to be applied around key length, signing algorithms, validity period, and trusted third parties, if applicable. Norms must be established, and continuous monitoring and reporting must occur, as well as continuous inventory, so that protecting cardholder data is achieved.
Requirements 3 in the PCI-DSS addresses key security as follows:
Although these requirements are applied to data at rest in requirement 3, QSAs apply these same key management requirements to section 4, data in transit, over open, public networks. SSL is currently the technology of choice to achieve this. As in section 3, keys cannot expire and the server certificate must use strong cryptography, for example, 2048-bit keys, not 1024-bit. Other items of note, are verifying that certificates are issued from a trusted source and the TLS configuration on the server has been done properly to ensure integrity of the secure connection. Run a Venafi Labs vulnerability report to determine if these certificate or TLS configuration vulnerabilities exist in your network.
On cardholder data networks, private keys provide the base of trust and confidentiality, protecting against disclosure of personal account numbers and sensitive authentication data. Using strong cryptography and implementing good people, process, and technology around keys will keep the underlying infrastructure of trust protected in your cardholder data network. Cryptographic keys are the foundation of trust in any system.