PCI DSS 3.1

The Standard That Killed SSL

Branden R. Williams

• Publisher: Syngress
• Year: 2015
• ISBN:
  9780128046494
• Topic: Computer Science
• Subtopic: Artificial Intelligence (AI) & Semantics
• Index: Computer Science

PCI DSS has recently updated its standard to 3.1. While the changes are fairly minor in nature, there are massive implications to companies relying on SSL as a scope reducing tool inside their enterprise. This update book goes through the specific changes to PCI DSS 3.1, and includes new case studies that discuss the specific implications for making the change to 3.1. This concise supplement also includes a detailed explanation of each changed requirement and how it will impact your environment. PCI Compliance, 3.1 Addendum serves as an update to Syngress' comprehensive reference volume PCI Compliance, Fourth Edition.

• Includes all system updates to the new version of PCI DSS 3.1
• Details and describes each update and enhancement
• Includes case studies that illustrate when and where these changes will effect and improve your enterprise

Chapter 1

Introduction

If you are reading this text, you are probably just as shocked as I am that the Council released an addendum to PCI DSS outside of the normal cycle. If you think back, the last time this happened was in July of 2009 when PCI DSS v1.2.1 became public. Version 1.2.1 only had some minor changes in it that were fairly cosmetic in nature. I bet that most of you, even those who have been dealing with PCI DSS for years, probably didn’t even know that there was an addendum to version 1.2.

Keywords

PCI DSS 3.1

If you are reading this text, you are probably just as shocked as I am that the Council released an addendum to PCI DSS outside of the normal cycle. If you think back, the last time this happened was in July of 2009 when PCI DSS v1.2.1 became public. Version 1.2.1 only had some minor changes in it that were fairly cosmetic in nature. I bet that most of you, even those who have been dealing with PCI DSS for years, probably didn’t even know that there was an addendum to version 1.2.

Well, version 3.1 is no tiny update. It’s nothing strictly cosmetic. It’s not a tiny deal. And it’s here to replace version 3.0. This addendum to PCI Compliance, 4th Edition, is meant as a companion piece. I will be taking you through the major changes in PCI DSS 3.1, including some of the fun things you will now be tasked with as you begin your assessments this fall.

For most of you, version 3.0 is still new enough that you may not have even been through your first formal 3.0 assessment. Those of you who are just now beginning to look at 3.0 should just move straight to 3.1. PCI DSS 3.0 was officially retired on June 30, 2015. If there is something in version 3.1 that may jeopardize your compliance timelines, work with your acquiring bank to figure out a pathway forward on either 3.0 or 3.1. There’s really no sense in working hard to remediate gaps against a retired standard (just like you wouldn’t start a PCI DSS 2.0 assessment today). Also, shame on you for waiting so long!

Those who are in the middle of your 3.0 assessment or remediation, talk to your acquiring bank. If you have already started, they may allow you to finish your validation against version 3.0. Even if this is your situation, take a look at the changes in PCI DSS 3.1. If you rely heavily on SSLv3 in your environment, this could be extremely painful. If not, the rest of the changes may be minor enough (for you) to continue forward with PCI DSS 3.1.

Now that we’ve discussed the themes, let’s review the contents. This booklet is organized into the following chapters.

Chapter 1, Introduction. You are reading it. Good job!

Chapter 2, The Death of SSL. What exactly does it mean for you as someone who relies on SSLv3?

Chapter 3, Third Parties. An extended review of the third-party adventure that started with 3.0 and continues with 3.1.

Chapter 4, Technical Testing. More details on what technical changes exist.

Chapter 5, Other Miscellaneous Changes. For those that did not fall into the above categories, quick blurbs on what changed.

Chapter 6, Final Thoughts.

Thanks for letting me take you on this journey. What I hope you get out of this is details around the changes, business-level information that will help you choose the best path, and specific things that are actionable for you today.

Chapter 2

The Death of SSL

Secure Sockets Layer (SSL) is one of the foundational technologies that enabled and allowed commerce to exist in an electronic, decentralized medium. Without it (or something similar), many of us would not have the types of jobs we do today. There are a number of implementations of this historical protocol—one of the most common being the open-sourced implementation published under the OpenSSL name. We’ve been dealing with SSL issues in PCI DSS since version 2.0 where SSL version 2 implementations were no longer allowed due to vulnerabilities in the protocol. I can remember counseling a number of customers through the migration process. The ones that were the hardest to resolve were implementations in embedded systems or those third-party “black box” solutions that end up playing a critical role in a firm’s IT environment.

Keywords

SSL; TLS; PCI DSS 3.1; TLS migration; POODLE

Secure Sockets Layer (SSL) is one of the foundational technologies that enabled and allowed commerce to exist in an electronic, decentralized medium. Without it (or something similar), many of us would not have the types of jobs we do today. There are a number of implementations of this historical protocol—one of the most common being the open-sourced implementation published under the OpenSSL name.We’ve been dealing with SSL issues in PCI DSS since version 2.0 where SSL version 2 implementations were no longer allowed due to vulnerabilities in the protocol. I can remember counseling a number of customers through the migration process. The ones that were the hardest to resolve were implementations in embedded systems or those third-party “black box” solutions that end up playing a critical role in a firm’s IT environment.

Then in 2014, we had two specific vulnerabilities related to SSL that caused a bit of a ruckus through the world. The first was Heartbleed—a gruesomely named vulnerability reported by Neel Mehta from Google’s Security Team. Unfortunately, this vulnerability was present in OpenSSL for a couple of years before its discovery. The vulnerability in the OpenSSL codebase was so severe and omnipresent that it forced the operators of millions of websites to revoke and reissue their SSL certificates after they patched. The bug allowed an attacker to “bleed” arbitrary amounts of data from memory revealing sensitive things like private keys that allow anyone to decrypt the SSL stream. It’s like the magic decoder ring that has the power to reveal the contents of any encrypted stream. The lock in the browser was just a false sense of security.

The second was a series of vulnerabilities that started with the first POODLE attack published in October of 2014. This initial release (plus future iterations that targeted early versions of TLS) is what kicked off the process at the Council to kill SSL and early versions of Transport Layer Security (TLS) in favor of TLS 1.2 (or greater, depending on when you are reading this book). While the debate over the severity of this particular vulnerability rages, it was scored at 4.3 on the CVSS list which means you have to remediate it to remain compliant with PCI DSS.

Following this, the Council removed the three instances of SSL from PCI DSS 3.0 and the genesis for PCI DSS 3.1 was born. Given the CVSS score, it almost seems unnecessary for the Council to rush out PCI DSS 3.1 with sunset dates on SSL. Let’s consider this for a moment.

PCI DSS Requirement 11.2 mandates quarterly scans of your networks. As of last October, any machine that is vulnerable to the POODLE attack is flagged as a vulnerability that needs to be fixed. Remember, any vulnerability with a CVSS score over 4.0 must be fixed in order to obtain a passing or clean scan. Therefore, if you have not solved this issue yet, then you are unable to comply with PCI DSS Requirement 11.2. So while the Council rushed to remove those words from PCI DSS 3.1, they did so (among other reasons) to make sure that these two items were in alignment. Otherwise, you would have someone trying to argue an ASV scan is wrong because the standard clearly supports the use of SSL. The reverse argument applies as well.

The tricky par...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Foreword
• Acknowledgments
• Chapter 1. Introduction
• Chapter 2. The Death of SSL
• Chapter 3. Third Parties
• Chapter 4. Technical Testing
• Chapter 5. Other Miscellaneous Changes
• Chapter 6. Final Thoughts