Kevin Bocek, VP of security strategy and threat intelligence, Venafi
Kevin Bocek, VP of security strategy and threat intelligence, Venafi

There have been a number 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 organisation.

How the organisation complies with their own information security policies, standards and guidelines must be analysed and the gaps in infrastructure and applications must be identified and prioritised so that risk can be greatly reduced. For any organisation that processes, stores and transmits cardholder data, the Payment Card Industry Data Security Standard (PCI DSS) helps keep cardholder data secure.

In April 2015, PCI DSS version 3.1 was published to address vulnerabilities within the Secure Sockets Layer (SSL) encryption protocol and early versions of Transport Layer Security (TLS) that can put payment data at risk. Basically, SSL is dead. Long live TLS. Commencing as of the 30th June, new projects must not use SSL or early versions of TLS.

After a slew of vulnerabilities, from Heartbleed to POODLE, the PCI Security Standards Council (PCI SSC) determined that all versions of SSL and early versions of TLS could no longer be relied upon to protect cardholder data.

SSL and early TLS could allow attackers to perform man-in-the-middle attacks and read what was thought to be authenticated encrypted communications. As explained in the PCI SSC guide, Migrating from SSL and Early TLS, organisations must identify use of SSL/TLS, determine the version applied and plan a remediation strategy that includes moving to the secure protocols (TLS version 1.1 and higher), encrypting data before transmission or applying additional layers of transmission security that are not vulnerable, such as IPSEC.

This migration must be performed by 30 June 2016 to comply with the PCI DSS version 3.1.

With the increasing number of vulnerabilities and attacks involving SSL/TLS and cryptographic keys and digital certificates, the PCI SSC is also reminding organisations that they need to be ready to respond and remediate quickly. Future scenarios may require much shorter remediation time frames and require not just changes to configurations, but also network-wide replacement of cryptographic keys and digital certificates, much like with Heartbleed.

While businesses may have a variety of reasons for not meeting the PCI DSS compliance requirements pertaining to keys and certificates, it certainly isn't because the dangers have subsided. In fact, they're on the rise.

In a recent Poneman Institute report, 100% of the organisations surveyed said they responded to attacks using keys and certificates within the last two years. In response to the growing threat, the PCI SSC has introduced stringent rules governing the security and management of keys and certificates that must be implemented as part of business-as-usual security processes.

To deliver these business-as-usual security processes for keys and certificates, organisations need automated security. This security should include comprehensive discovery for a complete inventory of keys and certificates in scope of the PCI DSS, daily monitoring of all keys and certificates, establishment of a normal baseline, alerts of any anomalous activity and automatic remediation so that errors, oversights and attacks do not become breaches.

Contributed by Kevin Bocek, VP of security strategy and threat intelligence, Venafi.