Guest blog by EventTracker CEO, A.N. Ananth
for Solution Providers for Retail
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle branded credit cards from major cards such as Visa, and MasterCard, to name a few. Merchants should know that PCI DSS v3.0 went into full effect on January 1, 2015, becoming the sole basis for compliance with the PCI Data Security Standards. However, on April 15, 2015, the PCI Security Standards Council (PCI SSC) announced an update, and the release of PCI DSS v3.1. I’ll answer some common concerns below.
Why so soon with the update?
This reevaluation follows the well-known exploits of vulnerabilities in SSL technology such as Heartbleed, POODLE and FREAK all of which have allowed attackers to collect large volumes of private data. The Heartbleed bug in particular, was a vulnerability based on the way SSL was implemented and it can be patched. Over time, additional vulnerabilities have been uncovered in SSL v3 that are inherent to the nature of the protocol. In short, it’s fundamentally broken and no longer considered a secure way to encrypt sensitive data.
In light of these weaknesses, the PCI Standards are leaving the Secure Sockets Layer (SSL) behind. The updated rules specifically prohibit use of SSL v1, v2, and v3 for transmitting credit card data over open, public networks.
While most of the updates are relatively minor adjustments and clarifications, and will have minimal impact on a merchant’s PCI compliance program efforts, there is one notable shift: Version 3.1 specifically indicates that no version of SSL will meet the PCI Council’s definition of strong cryptography. Major updates to PCI DSS are usually 3 years apart. This time is provided to give retailers (many of whom are national and international in scope), reasonable time to upgrade and comply.
However, the PCI Security Standards Council can, and in this case did, issue updates outside that cycle to react to threats, as needed. So what’s the emergency?
First, let’s discuss SSL and what has happened to it. SSL is the standard security technology for establishing an encrypted link between a web server and a browser. SSL v3.0 was released in 1996 by Netscape. It was succeeded by Transport Layer Security (TLS) 1.0 released in 1999 and updated to v1.2 in 2008. SSL ensured that all data passed between the web server and browsers remain private . Critical for e-commerce, SSL assured that no third party can eavesdrop between your browser and your website as you part with sensitive information like your credit card number.
While weaknesses were identified in SSL 3.0, it was still considered safe for use up until October of 2014, when the POODLE vulnerability came to light. POODLE is a flaw in the SSL 3.0 protocol itself, so it’s not something that can be fixed with a software patch.
POODLE allows a man-in-the-middle, such as a malicious Wi-Fi hotspot or a compromised ISP, to extract data from secure HTTP connections. This in turn could let that attacker do things such as access online banking or e-mail systems. Although SSL was succeeded by Transport Layer Security,(TLS) it’s still widely supported on both servers and clients alike and is still required for compatibility with Internet Explorer 6. SSLv3, unlike TLS 1.0 or newer, omits validation of certain pieces of data that accompany each message. Attackers can use this weakness to decipher an individual byte and time of the encrypted data, and in so doing, extract the plain text of the message byte by byte. That was the fatal flaw for SSL.
What does PCI DSS 3.1 require you to do?
According to the new rules, companies have until June 30, 2016, to update to a more recent version of TLS. Prior to this date, existing implementations using SSL and or early TLS must have a formal risk mitigation and migration plan in place. Effective immediately, all new implementations must not use SSL or early TLS.
How can you check your merchants’ SSL/TLS usage and version? A vulnerability scan from EventTracker Vulnerability Assessment Service (ETVAS) or other scanner, will identify insecure implementations.
SSL/TLS is a widely deployed encryption protocol. The most common use of SSL/TLS is to secure websites (HTTPS), though it is also used to secure email in transit (SMTPS or SMTP with STARTTLS, IMAPS or IMAP with STARTTLS), share files (FTPS) and secure connections to remote databases as well as secure remote network logins (SSL VPN)
What’s the bottom line?
Any business software running SSL 2.0 or 3.0 must be reconfigured or upgraded by June of next year. Most SSL/TLS deployments support both SSL 3.0 and TLS 1.0 in their default configuration. Newer software may support SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In these cases the software simply needs to be reconfigured. Older software may only support SSL 2.0 and SSL 3.0. If this is the case, it is time to upgrade. Welcome to our brave new world, where protocol procedure is flexible enough to provide needed updates in an accelerated fashion when needed.
See more at Solutions Providers for Retail.