Our Thinking

PCI DSS 3.2 Standard Released – Here’s What you Need to Know

Posted by Steve Levinson on Apr 28, 2016 5:03:40 PM

The PCI Standards Council typically releases a major version of the PCI Data Security Standard (DSS) every three years. The 2016 was released today; this new standard “Version 3.2” comes, with some relief, as a minor update to Version 3.0 instead of a major update to Version 4.0!

The PCI Council does a great job of maturing this framework in a way that resonates with the industry and with current threats, and this latest update is no exception. Our team has reviewed and vetted the changes from version 3.1 (released earlier this year) to version 3.2 to understand the implications of the updates (some of the changes will require legwork to address).

Note – most of the significant changes apply to Service Providers only, but still, there are some you should be aware of.

Timing

According to the PCI Council’s March blog post, the 3.2 version of the standard will become effective in October of this year. Similar to the release of the 3.0 standard, the more significant changes will allow for about 14 months of ramp-up time.

What You Need to Know

While there are several clarifications within this version of the DSS, this blog post will outline the significant changes and provide our overall interpretation about what this means to you.

3.5.1 – Service Providers must provide documentation of their cryptographic architecture: This is a new requirement that is considered a best practice until 2/1/2018. Note this does not apply to merchants. Service providers need to be able to present this documentation to their QSA during the PCI assessment. In theory, most Service Providers should already be doing this in practice, so this should most likely be an exercise in documenting how they encrypt cardholder data (CHD).

6.4.6 – Infuse PCI requirements checklist into your change management procedures: This new requirement, best practice until 2/1/2018, applies to ALL assessed entities. In addition to the existing 6.4.x change management controls, you must show evidence that all applicable PCI requirements were verified on all new or changed systems/networks. This will help ensure that your PCI security posture is not weakened during significant changes. You will need to fine-tune your change management processes to not only include this check point, but also to determine WHICH PCI DSS elements may be impacted by the change; be prepared for some front-end legwork here.

8.3.1 – All administrative access will require multi-factor authentication (“MFA”): This new requirement is probably the most significant change, and is a best practice until 2/1/2018. I am a huge fan of this change and blogged about it over a year ago; one of the inherent weaknesses in the PCI DSS is that most successful breaches involved the attackers getting their hands on administrative credentials – I’m glad to see the PCI Council taking this step. By required MFA, this attack vector will be greatly reduced. It will also put the onus on organizations to develop strategies to address this requirement. I strongly recommend creating a strategy to address this requirement immediately as 14 months will pass by very quickly.

10.8 – Service providers must identify any critical security control failures and respond accordingly: This new requirement, a best practice until 2/1/2018, will raise the bar for Service Providers (not merchants) to improve their security event monitoring capabilities, including monitoring the health of these functions.

11.3.4.1 – More frequent segmentation pen testing for Service Providers: This fine-tuned requirement, a best practice until 2/1/2018, increases the periodicity from once a year, or after “significant” changes, to twice a year.

12.4 – Accountability!: This new element, a best practice until 2/1/2018, requires executive management to document PCI accountability, create a charter for a PCI compliance program, and report updates to executive management/board annually. While several organizations are doing this in practice, we’ve not seen it formalized much. Again, I’m a big fan of this.

12.10.2 – Fine tune Incident Response (IR) Plan: Many organizations don’t give their IR plan a good run for its money and usually just perform a light tabletop exercise. This element will require you to ensure that your annual IR test plan includes a thorough review of all sub-elements from requirement 12.10.1. This requirement does not have a lead time, and therefore will be effective when the standard comes effective in October 2016.

12.11 – Service Providers must perform and document quarterly reviews to confirm personnel are following security policies and operational procedures: This requirement is a best practice until 2/1/2018, and means that Service Providers (not merchants) will need to up their game as it pertains to ensuring all personnel are following all applicable policies/procedures. Undoubtedly, this will cause a good uptick of work for program management or internal audit personnel. It will be important to be able to create auditable evidence that help proves that you’re doing this.

There are other minor changes to consider as well. We urge you to become familiar with all of the changes associated with the new standard and to create strategy to address these new and updated requirements. It may make good sense to reach out to your QSA or your PCI Trusted Advisor to determine your ideal path.

If you’d like to learn more, we will be providing a webinar to discuss these changes on May 4th at 10AM CT. You can register at https://attendee.gotowebinar.com/register/5842209228939034114.

Remember, the sooner you fall behind, the more time you have to catch up.

 

Topics: Security

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts