PCI DSS 3.1: What Are The Changes?

1©2015. JAW Consulting UK Ltd. All Rights Reserved. Classification: Public- External.

©2015. JAW Consulting UK Ltd. All Rights Reserved. Proprietary and Confidential. This document and the contents therein are the sole property of JAW Consulting UK and may not be transmitted or reproduced without JAW Consulting UK’s s express written permission. Classification: Public- External

PCI DSS 3.1: What Are The Changes?

22nd September 2015James Rose – Principal PCI DSS Consultant


Introductions

Jamie RosePrinciple PCI DSS Consultant, JAW Consulting [email protected]

James Walker, Managing Director, JAW Consulting UK

Speakers

• Over 10 years experience with PCI DSS• Worked at VISA Europe for 7 years • Supported publication of the first version of the PCI DSS

Moderators


Agenda

• Why the changes have been introduced within PCI DSS 3.1• The impact of POODLE/BEAST on PCI DSS requirements

• Evolving requirements.• Overview of the clarifications & additional guidance• What you need to do to remain compliant.

• Risk Mitigation and Migration Plan• Strategies to move away from weak cryptography.

• Replace & Enforce• Alternative Migration Options

• Q&A (10 minutes)


Why have the changes been introduced within PCI DSS 3.1?

SSL and TLS (1.0 and 1.1) not considered secure.

National Institute of Standards and Technologies (NIST) identified SSL as not acceptable for protection of data due to weaknesses within protocol.


The Impact of POODLE on PCI DSS Requirements

• SSL removed as an example of strong cryptography in PCI DSS.

• Can no longer be used as a security control after June 30, 2016

• Cannot be used in any new deployments.

• Upgrading to secure version of Transport Layer Security (TLS) is the only way to remediate vulnerabilities, exploited by browser attacks such as POODLE and BEAST.


Evolving requirements

Directly effected requirements with the release of PCI DSS V3.1 is as follows:

Requirement 2.2.3 - Additional security features required for Insecure ProtocolsThe use SSL or early versions of TLS as an additional security feature to protect insecure protocols is prohibitedRequirement 2.3 - Non-console admin access Remote admin access methods cannot use SSL or early versions of TLSRequirement 4.1 - Transmission of cardholder data over public networksYou cannot use SSL or early versions of TLS for the transmission of Cardholder data over public networks Requirement 4.1.1 - Wireless networksSSL or early versions of TLS cannot be used as a security control for authentication or transmission


Additional clarifications and additional guidance

There are number of clarifications and additional guidance in the release notes PCI DSS V3. However, the following are worth mentioning:

Requirement 4.2 Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.).SMS has been added as an example of an end-user messaging technology

Requirement 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.



What you need to do to remain compliant.


What you need to do to remain compliant.

1. Update all relevant documentation to ensure SSL and lower versions of TLS (1.0 and 1.1) are removed as an approved security protocol. 2. Use TLS 1.2 for any new deployments or implementations.

3. Create Migration and Mitigation Plan as you move away from using SSL and lower versions of TLS (1.0 and 1.1).

4. Begin Migration Away from SSL and lower versions of TLS for non-console Admin access and the transmission of cardholder data via Public Networks.



The Risk Mitigation and Migration Plan, explained.


Risk Mitigation and Migration Plan

The following provides guidance and examples of information to be documented in the Risk Mitigation and Migration Plan:

• Define the Scope • Risk Assessment• Proactively Monitor for Vulnerabilities (Insecure Protocols)• Change Control - Ensure No Further Deployments.• Migration Project Plan



Define the Scope:• Type of environment where the protocols are used – e.g. the type of payment channel

and functions for which the protocols are used.• Type of data being transmitted – e.g. elements of payment card account data,

administrative connections etc.• Number and types of systems using and/or supporting the protocols – e.g. POS POI

terminals, payment switches, etc.



Risk Assessment:• Perform a Risk Assessment and record risk reduction controls in place.Evaluate and

document the risk to your environment and implement risk reduction controls to help mitigate the risk until all vulnerable protocols can be removed.

Proactively Monitor for Vulnerabilities:• Describe the processes implemented to monitor for new vulnerabilities associated

with vulnerable protocols. Stay informed about new vulnerabilities. As new vulnerabilities are published, evaluate the risk they pose to the environment and determine if additional risk reduction controls need to be implemented until migration is complete.



Change Control - Ensure No Further Deployment:• Describe the processes implemented to ensure SSL/early TLS is not deployed into

new environments. If you do not currently use/need to support the vulnerable protocols, there is no reason further introduce such protocols into environment.

Migration Project Plan• Planning documentation should include which systems/environments are being

migrated and when, as well as a target date for overall migration completion. The target date for the overall migration must be no later than 30th June 2016.



Strategies to move away from weak cryptography.


Strategies to move away from weak cryptography

Replace & Enforce

• Upgrade to a current, secure version of TLS 1.2 that is implemented securely and configured to not accept fallback to SSL or lower versions of TLS.

• Technical controls to ensure SSL and lower versions of TLS are not used. In windows environments this can be implemented via Active Directory GPOs


Strategies to move away from weak cryptography

Alternative Migration Options

• Encrypt data with strong cryptography before sending over SSL or lower versions of TLS (for example, using field-level or application-level encryption to encrypt data prior to transmission)

• Setting up a strongly-encrypted session first (e.g. IPsec tunnel), then sending data over SSL within the secure tunnel

• Additionally, the use of two-factor authentication may be combined with the controls above to provide authentication assurance.


Q&A – 10 minutes

Summary• Why the changes have been introduced within PCI DSS 3.1

• The impact of POODLE/BEAST on PCI DSS requirements• Evolving requirements.• Overview of the clarifications & additional guidance• What you need to do to remain compliant.

• Risk Mitigation and Migration Plan• Strategies to move away from weak cryptography.

• Replace & Enforce• Alternative Migration Options

Any questions ?


You can also find us here:

www.jawconsulting.co.uk

twitter.com/jawconsultinguk

linkedin.com/company/jaw-consulting-uk-ltd

Thank You

Contact me at:

[email protected]

Technology

PCI DSS 3.1: What Are The Changes?