Each update of the Payment Card Industry Data Security Standard (PCI DSS) has clarified the standard and established new and evolving requirements for organizations that store, transmit, or process cardholder data to implement in their environments in order to maintain compliance. With the publication of version 3.2 of the standard, organizations should get a jump-start on evaluating the new requirements to identify how the changes are going to affect them. While the deadlines seem far off, some of the new requirements will prove challenging to those with large, distributed environments – especially to the service providers who appear to be targeted a little more than the merchants in this version. So, I’d like to share my thoughts about the major changes in version 3.2 ahead of the looming deadlines.
Don’t Wait to Evaluate New Requirements
All assessments made between now and Oct. 31, 2016, may use version 3.1 or version 3.2. After that time, all assessments will need to be made using version 3.2. New requirements added in version 3.2 will remain best practices until Jan. 31, 2018, to allow organizations “sufficient time” to address implementation, according to the PCI Security Standards Council. Beginning Feb. 1, 2018, version 3.2 will become a requirement for all organizations subject to the standard.
Organizations often choose to focus on the completion of current projects and postpone the evaluation and implementation of the new controls (or technology) until the date they become required for compliance. However, the council chose to address certain control deficiencies, misconfigurations, and vulnerabilities because they have been identified as causes of recent security breaches. Therefore, a real threat looms for the organizations that choose to wait to adopt the new requirements.
Another challenge with waiting to implement is missing the opportunity to fully vet the effects of the requirements on the entire environment. Let’s be honest. Very rarely is the implementation of new controls in an environment as straightforward as buying a tool and implementing it without modifying any other process, system, or control. Plus, when a control is implemented, it needs to be in place for a period of time before it can be evaluated for effective operation. Also, further education often is required for relevant personnel. All of these things take time.
To avoid last minute surprises in the 2018 PCI validation, organizations should have open discussions with their qualified security assessors (QSAs) to verify that the controls they are considering implementing will be sufficient to fulfill the new requirements. If possible, the controls should be implemented prior to Feb. 1, 2018, so organizations can ensure they are functioning as intended. Implementing controls at the last minute could easily lead to compliance validation delays.
More Requirements for Service Providers
Many merchants choose to outsource their payment processing function or support of their payment processing environment to focus on their core expertise, so it is no surprise that most of the new requirements in version 3.2 only apply to service providers.
Service providers are no strangers to changing compliance requirements but should not wait too long to review the new requirements. Implementation of the required technologies and modifications of existing controls will take time as personnel need to be trained. In addition, documented policies and procedures will need to be updated to reflect changes in the environment.
Multifactor Authentication
It might have been surprising to see that one of the “evolving requirements”1 listed in the changes is related to multifactor authentication. While it is true that multifactor authentication has always been required for remote access to the cardholder data environment (CDE), now that requirement is much more specific. All organizations must require system administrators to use multifactor authentication to access the CDE – even from the internal network – after Jan. 31, 2018.
Multifactor authentication requires at least two of the following:
- Something you know (such as a password or passphrase)
- Something you have (such as a smart card)
- Something you are (a biometric verification, such as a fingerprint)
Layering of a single authentication factor (for example, multiple passwords) does not satisfy the requirement and is not considered multifactor authentication despite some misunderstanding about this in the past.
The requirement to always log in to the CDE only applies to personnel with administrative access, and the standard allows for the multifactor authentication to be implemented at the application and/or system level or at the network level. Personnel without administrative privileges can continue to access the applications and/or systems as before.
While an organization may already have the technology to control remote network access, each organization will need to address the emerging requirement by evaluating which strategy will provide the maximum level of protection with minimal cost and impact to its environment.
Governance
The next evolving requirement I want to touch on relates to governance. PCI DSS version 3.2 requires organizations to establish responsibility for their PCI compliance programs. The new requirement targets service providers, but it would be a best practice for merchants as well. Successful PCI compliance programs have already identified those charged with the governance of these programs, but the responsibility for PCI compliance will need to be formalized now. This requires that an individual (or possibly a committee) be held accountable not only for protecting cardholder data, but also for defining the program that the company will execute to ensure compliance.
Internal Control Validation
Those chosen to lead PCI compliance programs at their organizations will have an additional tool at their disposal. Organizations will now be required to perform and document quarterly reviews of their PCI compliance programs to confirm that security policies and operational procedures are being followed. Controls testing that is ongoing over a period of time allows the executive who signs the attestation of compliance to feel confident that the compliance he or she is attesting to is really occurring, eliminating the feeling of blindly signing the statement.
While service providers are no strangers to audits, the extent of testing for the quarterly validation of PCI-specific controls will need to be defined, planned, and integrated into the existing audit cycle. Existing audit or compliance programs may already cover some of the same activities, but PCI DSS requires the review to be completed at least quarterly.
Luckily, the standard allows an organization to define the depth of the review and only requires validation that procedures are being followed and controls are being executed, so organizations will have some flexibility on the design of the quarterly testing.
A Smooth Transition to Version 3.2
It is never too early to start discussing new and evolving requirements with your qualified security assessor. As QSAs and QSA companies prepare to assess PCI compliance programs under version 3.2, they are establishing their expectations about how requirements can be satisfied. A discussion to understand your assessor’s expectations can help ensure that you retain sufficient evidence of controls and technologies implemented and that those will pass the compliance validation without any last-minute surprises.
1 According to the PCI Security Standards Council, an “evolving requirement” is a change made “to ensure that the Standards are up to date with emerging threats and changes in the market.”