By Francis Kyereh, Information Security Consultant
Maintaining payment security is required for all entities that store, process or transmit cardholder data. Guidance for maintaining payment security is provided in PCI security standards. These set the technical and operational requirements for organisations accepting or processing payment transactions. The PCI DSS Version 3.2, containing nine new requirements targeted at service providers, was published in April 2016 by the Payment Card Industry (PCI) Security Standards Council.
The new requirements included in PCI DSS v3.2 focused on mitigating current vulnerabilities identified in data breach reports, including those presented by third party service providers, authentication protocols, and outdated encryption. The changes were also intended to help companies maintain and effectively test compliance between annual PCI assessments.
“Best Practices” become Mandatory Controls effective from February 2018
PCI DSS v3.2 became effective from November 01, 2016 after publication on April 28, 2016 and Qualified Security Assessors (QSAs) were mandated to use the PCI DSS v3.2 Report on Compliance (RoC) and Attestation of Compliance (AoC) templates for PCI DSS assessments from November 01, 2016. However, the new requirements introduced with Version 3.2 were to be treated as best practices by QSAs to allow more time for the affected organisations to put in place the necessary controls.
All of the new requirements under PCI DSS 3.2 were “best practices” until January 31, 2018. Organisations are expected to implement these controls by January 31, 2018. Starting on February 1, 2018, the new requirements are effective as requirements that QSAs must ensure are in place. Thus, QSAs and Internal Security Assessors cannot continue marking those controls as not applicable because they are best practices.
Although new requirements were included in PCI DSS v3.2, they are updates within the existing PCI DSS goals and requirements. The new requirements are intended to ensure organisations are addressing emerging threats and to ensure that service providers are fulfilling their responsibilities in providing services to other organisations.
Key PCI DSS Requirements effective from February 2018
There are nine entirely new requirements included in PCI DSS v3.2. However, seven out of the nine new requirements are applicable only to Service providers. Even though the PCI Council gave organisations about twenty months to implement these new requirements, some organisations may have thought they had more time. As a reminder, some of the key changes that become effective from February 1, 2018 are explained below.
There are several new areas of emphasis in PCI DSS v3.2. These include Change management, administrative access to the Cardholder Data Environment (CDE), documentation of cryptographic controls, executive management and board level appraisal of PCI DSS implementation for the organisation. The PCI Security Standards Council released a document known as the Summary of Changes from PCI DSS Version 3.1 to 3.2 in April 2016 which describes in minute details all the changes that were made from version 3.1 to 3.2.
New requirement 6.4.6 on change control processes, now includes verification of PCI DSS requirements impacted by a (significant) change. All relevant controls must be implemented on all new or changed systems. Documentation must be updated as applicable.
By this action, the PCI Council has introduced a validation step into the change management process to ensure device inventories and configuration standards are kept up to date and security controls are applied where needed. Changes are often implemented for system components that may render the component to be non-compliant against certain PCI DSS requirements or make it inaccurate.
For example, consider the introduction of a new network connection to accommodate growing business or addition of business partners. If the network diagram is not changed to reflect this change, it would be an inaccurate representation and may even be non-compliant if the new connections are used to handle cardholder data.
The new requirement 8.3.1 on remote administrative access to the CDE requires that for any non-console administrative access to CDE, personnel with administrative access must use multi-factor authentication. Current requirement 8.3.2 for multi-factor authentication for remote access to CDE for personnel with administrative access still applies.
Requirement 8.3.1 has been included to make sure that users with the ability to make changes to CDE systems, and hence to potentially weaken security controls or introduce vulnerabilities, are more strongly authenticated. The PCI Council has issued an FAQ to clarify the intent of ‘administrative access’ so that organisations can correctly determine the scope of access into the CDE for which multi-factor authentication will be required.
Documented Description of Cryptographic Architecture
PCI DSS Requirement 3.5.1 is an additional requirement that only applies to service providers. It requires that the service provider organisation maintains a documented description of the cryptographic architecture that includes: details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date, a description of the key usage for each key, and an inventory of any hardware security modules (HSMs) and other secure cryptographic devices (SCDs) used for key management.
Tracking and monitoring access to network resources and Cardholder data
For obligations on tracking and monitoring access to network resources and cardholder data, there are new requirements (10.8, 10.8.1) for service providers to detect and report on failures of critical security control systems.
The service provider is required to implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of firewalls, intrusion detection systems/intrusion prevention systems (IDS/IPS), file integrity monitoring (FIM) anti-virus, physical access controls, logical access controls, audit logging mechanisms and segmentation controls.
This requirement was introduced so that service providers can detect and respond to failures of critical security systems in a consistent and timely manner. Security systems play a vital role in prevention and/or detection of unauthorised access in to the CDE and hence it is important to ensure they do not fail or are monitored for failures and remediated. The specific types of failures may vary depending on the function of the device and technology in use.
A service provider is defined by the PCI Council as an entity directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. The PCI Council’s definition also includes companies that provide services that control or could otherwise impact on the security of cardholder data. There are additional requirements for Service providers (including Shared hosting providers). These are
- maintaining documented description of cryptographic architecture as per requirement 3.5.1
- Detect and report on failures of critical security control systems as per requirement 10.8
- Take quick and effective action whenever a critical security control system fails as per requirement 10.8.1
- Perform penetration testing on segmentation controls at least every six months as per requirement 188.8.131.52
- Service provider executive management to establish responsibilities for protection of cardholder data and PCI DSS compliance program as per requirement 12.4.1
- Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures as per requirement 12.11
- Maintain documentation of the quarterly review process, including sign off of results, per requirement 12.11.1.
All the above controls are effective from February 1, 2018 for all service providers including shared hosting providers.
PCI DSS Version 3.2 has Shorter RoC reports
To limit the verbosity of RoC reporting, the PCI Council has allowed assessor responses for 44 of the PCI DSS requirements. In practice, this means that all that is now required is the name of the PCI QSA who is attesting that the requirement is in place, rather than the reporting detail. This QSA ‘signature’ confirms that the control is in place/verified without the assessor needing to write the usual descriptive responses associated with QSA reporting (the assessor will be collating evidence to support their attestation). The assessor ‘signature’ has been deemed stronger than a ‘yes’ or ‘checkmark’ RoC response.
Inclusion of the new requirements in PCI DSS Self-Assessment Questionnaires
As was discussed in our article on the impact of the PCI DSS v3.2 on the Self-Assessment Questionnaires (SAQs), there were significant changes to the SAQs as many existing PCI DSS requirements were added to some of the SAQs, With the release of the revision 1.1 v3.2 SAQs, which became effective on October 01, 2017, the new requirement 6.4.6 is now included in SAQ A-EP, SAQ C and D and the new requirement 8.3.1 in SAQ A-EP, SAQ B-IP, SAQ C, SAQ C-VT and SAQ D. The service provider version of the SAQ D includes all nine of the new requirements.
When PCI Council released Version 3.2 of the PCI DSS in April 2016, organisations were given between 18 months and 24 months to marshal the necessary resources to put in place the required controls. All too soon, the time is here. Expect your QSA to demand evidence for these new controls in the next assessment and validation cycle.
If you are a merchant that requires technical or PCI DSS help, please click here