Though PCI-DSS 3.2 has made a large number of changes mostly include corrections, below are some of the changes that can have an impact on your current CDE environment architecture or PCI-DSS process(if any).

SSL/TLS upgrade

This is considered to be the main driver for PCI-DSS 3.2 as the vulnerabilities like FREAK, DROWN, etc. have completely exploited the so-called secure communication like SSL. Organization should make sure they migrate from SSL and early versions of TLS to new and more secure version of TLS. Also, organizations should make to tackle vulnerabilities like DROWN they should completely disable SSL 2.0 from the entities within CDE and even outside CDE, which support them. Also, PCI-DSS requires organizations to document fully and update the documentation as the configuration across CDE changes. Configurations like what sort of hashing algorithms they are using, what version of TLS is currently deployed should be well documented. The deadline to implement or migrate away from SSL or an earlier version of TLS has been extended from June 30, 2016, to June 30, 2018, which is kind long timeframe to implement changes. In this time frame organization should constantly update to newer and more secure version of TLS.

Multi-Factor Authentication scope

Earlier PCI-DSS version has already introduced multi-factor authentication, but those requirements stated that MFA was required only for remote access to cardholder environment. With PCI-DSS 3.2 it will be mandatory for all administrative access to CDE even for secure local admin access. This new requirement will have a considerable impact on the existing architecture of CDE. Requirement 8.3 is divided into sub-requirements to accommodate the above change as: 8.3.1: “Addresses multi-factor authentication for all personnel with non-console administrative access to the CDE.“ 8.3.2:” Addresses multi-factor authentication for all personnel with remote access to the CDE.“

Change Analysis Process

There is an addition of new requirement 6.4.6 into PCI-DSS 3.2 which requires the organization to maintain a process which carries out impact analysis after a change in cardholder environment. This new requirement will ingest security as an organic process that keeps on getting updated on a regular basis rather than leave security process as a yearly review assessment.

Reporting on Security Control System Failures

New requirements 10.8 and 10.8.1 have been added which requires service providers to draw out a process to report on security control system failures as soon as possible. This requirement was introduced as a considerable gap has been seen in fixing up these security controls which give the attackers the time frame to exploit the system. This requirement involves regular testing of security controls in CDE environment by the service providers.

Masking criteria of Primary Account Number (PAN)

Though not much information can be deduced from PCI-DSS changes summary sheet for this requirement as the new requirement 3.3 continue to use the first six, last four digits of PAN. If more information regarding PAN needs to be displayed, then a proper business reason/use case needs to be documented for it. The new requirement will also provide flexibility for varying BIN (Bank Identification Number) as stated here.

Designated Entities Supplemental Validation (DESV) criteria Incorporated

PCI DSS 3.2 comes with the DESV criteria’s which were earlier a separate document incorporated within it. These criteria’s will provide additional security validation steps for service providers. This will ensure that security controls are continuously enforced in CDE and will PCI-DSS compliance is an art of overall security strategy rather than being treated as an annual assessment. Full DESV reporting format can be downloaded from here. A brief summary of DESV requirement are as follows: DE.1: Implement a PCI DSS compliance program  DE.2: Document and validate PCI DSS scope DE.3: Validate PCI DSS is incorporated into business-as-usual (BAU) activities DE.4: Control and manage logical access to the cardholder data environment

Penetration Testing every six months

New requirement 11.3.4.1 states that now service providers need to perform penetration testing on CDE every six months whereas earlier this requirement subject to an annual basis. This new frequency of penetration tests will make sure that all the security controls in CDE are updated and properly working. Through this requirement organizations will conduct the test and assess security control and can showcase the CDE is isolated. http://blog.pcisecuritystandards.org/pci-dss-32-is-here https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_Summary_of_Changes.pdf