This is our final post in a series (What is Pci Compliance Part I  and Part II) on PCI Compliance for Level 3 and Level 4 credit card processing merchants, where we discuss the requirements put forth in Pci Dss version 3.2 by the Payment Card Industry Data Security Council in April 2016.  We’ll touch on the significant changes for merchants in this version of the security standards, multi-factor authentication, and migration from SSL to TLS 1.2 as the only currently acceptable protocol for secure communications on the internet for sensitive data.

Expansion of PCI DSS requirement 8.3

Multi-factor authentication (or MFA) is a “critical control” for securing the cardholder data environment (or CDE).  The CDE is defined as the computer system or network that stores, processes, or transmits sensitive cardholder data. 

MFA includes three basic types of authentication (proof of identity) –

• Something you have: A physical object, such as a smart card or USB drive with a token
• Something you know: A password or PIN
• Something you are: A biometric, such as a retina scan or fingerprint

You encounter multi-factor authentication any time you use an ATM. It requires something you have (your bank card) and something you know (your PIN).

For years, PCI DSS have required MFA for users accessing the cardholder data environment remotely or over untrusted, public networks (i.e. the internet, Wi-Fi).  PCI DSS Version 3.2 now calls for MFA implementation for everyone and anyone with non-console administrative access to the CDE, even from within the organizations trusted network. This includes any administrator, employee and/or third-party vendors who have access to the CDE and could compromise security – purposely or unwittingly.  MFA guarantees secure access control for staff with authorized access and, just as importantly, a way to monitor and trace all access.

Hackers are naturally focused on gaining administrative access to the CDE because of the potential financial gain.  A 2016 Verizon Data Breach Investigation Report shows that in many breaches, hackers took advantage of single-factor authentication entry points.

Studies show that being a small business may actually increase your chance of a cyberattack.  In fact, a 2014 Symantec Intelligence Report shows that “companies with fewer than 250 employees are the victim of 39% of all cyberattacks”.  Here’s another sobering statistic – “60% of small firms that are victims of a hack go out of business within 6 months of the attack”. 

Currently, MFA is listed only as best practice, but it will be a requirement by February 1, 2018.  Implementation of MFA can be complex, which is why the council has allotted time between best practices and requirements.  Expert David Strom has written some useful articles for TechTarget including Multifactor authentication examples and business case scenarios and Multifactor authentication purchasing considerations: What you need to know. Additionally, SearchSecurity developed a Buyer’s Guide to lighten the research load just a little, providing a good starting point for merchants.

Migration from earlier versions of SSL and early TLS to TLS 1.2

Requirements 2.2.3, 2.3 and 4.1 and all references to “strong” cryptography

SSL, short for Secure Sockets Layer, is the security standard technology for encrypting information between a web browser and server and has been for decades.  SSL.com provides an excellent brief overview of SSL and its role in internet security in their FAQ section here.  Unfortunately, there are a number of security vulnerabilities now identified within early versions of SSL technology that cannot be fixed.  The current best practice within PCI DSS version 3.2 is the use of TLS 1.2, a modern improvement on SSL. The deadline for migration to this newer protocol is July 1, 2018.

Merchants need to purchase an SSL certificate to be installed on their website to implement this technology from a certified authority, or CA.  A CA is a recognized entity that provides these electronic certificates that verify identity on the Internet.  In simplest terms, SSL certificates purchased from a CA represent a level of vetting of the company on the internet, and prove to the customer that their online transaction on the company’s website is secure. There are three basic certificate levels including –

• Domain Validation (DV) – the CA confirms the company’s right to use the domain name and that’s all.  Installation of this certificate on a website activates encryption and allows use of https:// (instead of http://) in the site’s URL. Most web browsers will confirm the validity of the certification with a padlock symbol in the URL bar.
• Organization Validation (OV) – the CA vets domain rights and probes a little deeper into who the company is.  This certificate activates the same protocols and visual cues in the browser bar as the DV certificate.
• Extended Validation (EV) – the highest level of certificate available today, with a more in-depth look at where and who the company is.  An EV activates the encryption protocol and places the company name in the browser bar, which will now be green.  This certificate provides unsurpassed credibility of the website. As an example, most major financial institutions have this level of certificate.

These certificates are meant to give your customer the confidence required in these days and times of online transactions – that your website is secure and you are who you say you are.   It’s worth noting  that the certificates are still referred to as SSL even though the cryptography being used is TLS 1.2.  Each browser provides a way to view the certificate details on any website, and each browser has a list of acceptable CAs.  Here for example, is the list for Mozilla/Firefox.  Symantec, another well-known CA, is in the news today as Google apparently is downgrading the company’s certificates for a failure in the validation process for thousands of websites.

The PCI Security Council provides a good supplement for businesses to get started on this protocol migration away from early SSL to the more secure TLS 1.2 encryption protocol. 

I know this all sounds pretty painful, but the PCI DSS requirements were developed to protect not just sensitive data, but you, the merchant.  Emma Sutcliffe, the Director of Data Security Standards, spells it out succinctly in this short, informative article, PCI DSS 3.2: Making the Move to MFA, written for DARKReading -  

“PCI DSS 3.2 aims to help organizations focus attention on critical controls; make improvements that will help mitigate current points of attack, and evaluate opportunities for devaluing (tokenization) card data.”

What should you expect from your payment processor or merchant account provider?  A strong base knowledge of PCI Compliance and direct access to a provider they recommend or partner with.  For example, XBS Global and Priority Payments XBS partners with ControlScan (note their name in green in the browser bar), a security expert in both the Payment Card and Medical Industry (HIPAA).  PCI Compliance is a complex industry unto itself.  Your payment processor may not have all the answers, but they should definitely be partnered with someone who does.

Go to www.pcisecuritystandards.org for complete clarification, questions, resources, and tips regarding these explicit requirements for secure credit card processing.