Blog

September 13, 2017

PCI DSS 3.2 – Important January 31, 2018 Deadline & Clarifications

pci compliance

Technical changes to PCI Compliance are coming in the near future.  This document is intended to be shared with your network administrators, software providers or hardware vendors.  While it is very technical, experienced network managers will understand the terms used to keep your client’s data safe.  In most cases, your software provider will make sure that you adhere to PCI Compliance standards.  However, if you don’t use a commercial software application, this information will be needed by your administrator.  Chosen Payments is always available to assist you with PCI Compliance but it is up to you as a merchant to remain in compliance at all times.

Overview

In April 2016, Version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS) was released. This new version of the standard contains a number of new requirements which come into full force as of February 1, 2018. Here is an overview of 3.2 broken down into four categories.

#1 – The clarification of requirements for Version 3.2 reports

#2 – The new requirements for merchants

#3 – The end of SSL

This information is provided by the PCI Security Standards Council.

#1 – Clarification (Applicable for all 3.2 reports)

1.1.6.a: Identify the firewall and router configuration standards document(s) reviewed to verify the document(s) contain a list of all services protocols, and ports necessary, including a business justification and approval for each.

These approvals should be granted by someone other than a person who is responsible for managing the configuration. For example, this might include a Security Officer or other role who is responsible for overseeing the PCI DSS process internally, or by someone outside of the standard team of people who are responsible for performing the day to day management of network devices.

6.5: Address common coding vulnerabilities in software-development processes as follows:

  • Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.
  • Develop applications based on secure coding guidelines.

The requirement for developer training is not new. However, in Version 3.2, it was clarified that this training must take place for all developers at least annually. We also recommend that testers attend this training as well to ensure that they are adequately equipped to test for basic security vulnerabilities.

11.3.4.c: Verify that the [segmentation penetration test] was performed by a qualified internal resource or qualified external third party, and if applicable, the organizational independence of the tester exists (not required to be a QSA or ASV).

The requirement for segmentation testing is not new. However, in Version 3.2, a clarification was made that brings the requirement for how segmentation penetration testing into line with the requirements for internal and external penetration testing. The person performing the segmentation testing must be either a qualified internal resource or external third party, and there must be sufficient organizational independence (e.g. the penetration testing should not be done by individuals who are responsible for the day to day management of the systems or who report directly to staff who are responsible for these teams).

12.3.3: Verify that the usage policies define:

  • A list of all critical devices, and
  • A list of personnel authorized to use the devices

The wording of this requirement has been adjusted to ensure that it is clear that the usage policies must include both a list of the critical devices in the environment and a list of the personnel authorized to use the devices. This needs to be documented and cannot be considered “self-documenting” as part of a system such as Active Directory or LDAP.

2 – New Requirements for Merchants (as of February 1, 2018)

There are several new requirements that come into force for both merchants and merchant service providers.

6.4.6: Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

To ensure that this requirement is met, we recommend that a clear definition of what constitutes a “significant change” be defined within the processes so that it is possible for staff to identify when this level of review is required. While the PCI Council does not provide a definitive definition of what constitutes a significant change, guidance from Requirement 11.2 suggests this includes (but is not limited to):

  • New system component installations
  • Changes in network topology
  • Firewall rule modifications
  • Product upgrades
  • Operating system upgrades
  • Sub-networks being added to the environment
  • New web servers

Once significant changes have been defined, we recommend developing a set of templates for reviewing the relevant PCI DSS requirements to ensure that both (1) the relevant requirements have been put in place prior to the system going live, and (2) sufficient testing has been done to meet the requirements for PCI DSS (e.g. penetration testing, vulnerability scanning, etc.) Incorporating this into the change control process is one option.

8.3.1: Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

The PCI Security Standards Council recently published a guidance document on what constitutes multi-factor authentication (see: https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf).

In this document they provide a number of examples of what does and does not constitute multi-factor authentication and where multi-factor can be placed in the environment. We also recommend reviewing the PCI Security Standards Council’s guidance on Segmentation and Scoping (see:

https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf) as the way that multi-factor is implemented may be influenced by how you have decided to segment the environment.

3 – SSL / TLS Requirements (July 1, 2018)

After June 30, 2016, all service providers must offer a secure protocol (e.g. TLS 1.2) as an option.

After June 30, 2018, all merchants and service providers must only use a secure protocol for the transmission of cardholder data (e.g. TLS 1.2) and all insecure versions (e.g. SSL and early TLS) must be disabled.

Prior to June 30, 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Given the impending deadline for disabling SSL and Early TLS, we recommend that reviewing the current need for these protocols is done on a more frequent basis to determine if it is possible to disable them prior to the deadline.

 

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInBuffer this page
Share this

Comments are closed here.

Recent Posts