By Natasja Bolton, Acquirer Support Manager
On the 28th April 2016, the PCI SSC published the latest version of the PCI Data Security Standard: the PCI DSS v3.2. We previously wrote about the changes that council had planned for v3.2, in this follow-up article we examine the changes that have been included in the final publication and what these changes mean for your organisation and your customers.
For a more concise and easy to reference summary of the new standard, please read our accompanying article; a quick guide to PCI DSS v3.2, so that you are prepared to support your clients with their questions.
A new standard?
This new release is not a completely new standard; rather it is another iterative change to the standard, much like 2015’s PCI DSS v3.1 release. As with PCI DSS v3.1, this new version of the PCI DSS builds on the previous major release by including only clarifications, additional guidance to improve understanding and provide further information to the reader and updates to existing requirements.
Although new requirements are included in 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, in particular, to ensure that service providers are fulfilling their responsibilities in providing services to other organisations.
What are the dates we need to work to?
The PCI SSC has allowed a six month period from publication of v3.2 to allow organisations in the middle of their compliance program or assessment to complete their activities against v3.1.
PCI DSS v3.2
Effective from:
Now
PCI DSS v3.1
Retired from:
October 31, 2016
Any compliance assessment after October 31, 2016 must be against PCI DSS v3.2; although in the recent PCI SSC Assessor session it was noted that a 90 day grace period is allowed for submission of in-flight assessments that complete after v3.1 is retired.
PCI DSS v3.2 is valid for assessments from the date of its publication and all key compliance documents have been released to undertake v3.2 compliance assessments; these include the Self-Assessment Questionnaires (SAQs) and the ROC Reporting Template (the Report on Compliance template used for on-site assessments).
So what is new?
The introduction of new requirements
There are nine entirely new requirements included in PCI DSS v3.2; however of those seven are applicable only to Service Providers.
All of these new requirements are best practice recommendations on publication of v3.2; organisations have until January 31, 2018 to implement the new requirements.
V3.2 Reqt #
Requirement
New Requirements: Applicable to All Entities
Requirement 6: Develop and maintain secure systems and applications
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.
Requirement 8: Identify and authenticate access to system components
8.3.1
Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
New Requirements: Applicable to Service Providers Only
Requirement 3: Protect stored cardholder data
3.5.1
Maintain 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
· Description of the key usage for each key
· Inventory of any HSMs and other SCDs used for key management
Requirement 10: Track and monitor all access to network resources and cardholder data
10.8*
Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
· Firewalls
· IDS/IPS
· File Integrity Monitoring
· Anti-virus
· Physical access controls
· Logical access controls
· Audit logging mechanisms
· Segmentation controls (if used)
10.8.1*
Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:
· Restoring security functions
· Identifying and documenting the duration (date and time start to end) of the security failure
· Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause
· Identifying and addressing any security issues that arose during the failure
· Performing a risk assessment to determine whether further actions are required as a result of the security failure
· Implementing controls to prevent cause of failure from reoccurring
· Resuming monitoring of security controls
Requirement 11: Regularly test security systems and processes.
11.3.4.1*
If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
Requirement 12: Maintain a policy that addresses information security for all personnel
12.4.1*
Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
· Overall accountability for maintaining PCI DSS compliance
· Defining a charter for a PCI DSS compliance program and communication to executive management
12.11*
Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:
· Daily log reviews
· Firewall rule-set reviews
· Applying configuration standards to new systems
· Responding to security alerts
· Change management processes
12.11.1*
Maintain documentation of quarterly review process to include:
· Documenting results of the reviews
· Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program
Many of the new requirements (marked *) have been adopted or adapted from the Designated Entity Supplemental Validation that was released in June 2015. The Designated Entities Supplemental Validation includes additional testing procedures intended to provide greater assurance that PCI DSS controls are implementation and maintained, and on a continuous basis through validation of business-as-usual (BAU) processes, and increased validation and scoping consideration. Their inclusion in v3.2 is an indication of the additional security benefit these requirements provide in ensuring that security controls are in place and effective.
The new requirements applicable to all
New Requirement 6.4.6 has been included to make sure that PCI DSS requirements are applied or updated whenever the organisation makes significant changes to in-scope networks and systems. This means that, whenever new systems/networks are introduced or existing systems/networks modified, organisations need to make sure that secure configuration standards are applied, change detection or anti-virus software is installed, audits logs are enabled and retained, etc.. Organisations must also ensure that the supporting documentation and procedures are created/updated. For example, they must create or update their system configuration standards, revise their network and card flow diagrams, or make sure that new systems are included in their scanning and penetration testing procedures.
The use of two-factor (now called multi-factor) authentication has been extended with the introduction of Requirement 8.3.1. This requirement 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. Organisations must now ensure that personnel seeking non-console administrative access to the CDE provide at least two different forms of authentication: multi-factor authentication (MFA). For organisations with a ‘flat’ network, MFA may be used when administrative users logon to the network or onto a specific system on that network. For organisations with a segmented CDE, MFA must be used when administrative users logon to the CDE (or CDE system/application) from outside of the CDE. Multi-factor authentication gives organisations have a much greater level of assurance in the identity of the logged on administrative user, as it is much less likely that an attacker will be able to compromise both authenticating factors.
The new requirements applicable only to service providers
Requirement 3.5.1 is intended to make sure of the ongoing protection of encrypted cardholder data. Service providers must document their cryptographic architecture in order to demonstrate their understanding of their solution, to enable updates to the solution as threats change and as the definition of ‘strong cryptography’ develops and to detect unauthorised changes to the solution, including lost or misplaced cryptographic keys or devices (e.g. hardware security modules or other secure cryptographic devices).
With Requirement 10.8 service providers must be able to detect, report and alert on the failure of critical security control systems. A critical security control system failure could include the complete cessation of a system’s security function (e.g. firewall no longer enforcing access control rules, audit logs not being created) or loss of system effectiveness (e.g. anti-virus or IDS/IPS systems fail to update so are not able to detect new threats). By having proactive processes in place service providers minimise the time available for attackers to exploit a failure and thereby breach the CDE or cardholder data (whether their own or the CDE/cardholder data of their customers).
Many merchant card data breaches can be traced back to third party security control failures. Requirement 10.8 is supported by Requirement 10.8.1 which requires service providers to take quick and effective action whenever a critical security control system fails. These requirements seek to ensure that service providers truly understand the implications of their responsibilities to their customers. Service providers must taking swift and decisive action to detect and respond to failures of the critical security control systems merchants are relying on to protect their CDE and their customers’ cardholder data, including identifying and acting on lessons learnt to prevent recurrence.
Segmentation penetration testing – validating the effectiveness of the segmentation methods/controls used to separate in-scope from out-of-scope systems – was introduced with PCI DSS v3.0. In v3.2, new Requirement 11.3.4.1 requires service providers to perform testing of their segmentation methods/controls as frequently as possible (at least every six months) in order to confirm the validity of their PCI DSS scope. This requirement is very much aligned to Requirement 6.4.6. As businesses, operations, networks and systems change, service providers need to make sure they fully understand their PCI DSS scope and implement all relevant PCI DSS requirements to that validated scope.
Requirement 12.4.1 is about ensuring that executive level management (i.e. C-level, board of directors, or equivalent) has visibility of the service provider’s PCI DSS compliance program and its organisation. Not only to ensure that the organisation’s leaders understand their PCI DSS responsibility but also to make sure that accountability for maintaining the service provider’s PCI DSS compliance has been assigned.
The last of the service provider requirements are intended to provide greater assurance that PCI DSS controls are maintained and in operation on a continuous basis (i.e. embedded in the organisation’s business-as-usual (BAU) processes). To meet Requirements 12.11 and 12.11.1 service providers must undertake, record and sign-off regular reviews checking that personnel are adhering to established security policies and operational procedures as expected and in line with the PCI DSS requirements. The review coverage is intended to ensure that service providers are preventing and detecting unauthorised changes, monitoring for and responding to suspicious activity, and maintaining secure networks and systems.
Changes for organisations that use SSL or early TLS – a new Appendix
The SSL/early TLS migration deadline dates have not changed with the publication of PCI DSS v3.2. In line with the PCI SSC bulletin issued in December 2015, organisations must no longer use SSL or early TLS as a security control after June 30, 2018, although they are expected to work towards upgrading as soon as possible. Service Providers are still expected to complete their migration by June 30, 2016.
In PCI DSS v3.1, each of requirements 2.2.3, 2.3 and 4.1 included testing procedures to ensure that POS POI terminals were not susceptible to known SSL/early TLS vulnerabilities and, if SSL and/or early TLS was in use, to ensure that the entity had a Risk Mitigation and Migration Plan in place.
In v3.2, all testing procedures relating to SSL/early TLS have been moved to a separate Appendix A2. For each of requirements 2.2.3, 2.3 and 4.1, if the organisation is using SSL/early TLS they must fulfil the additional PCI DSS Requirements set out in Appendix A2. The requirements in Appendix A2 are:
Reqt #
Applicability
Action Required
A2.1
Organisations whose POS POI terminals (and the SSL/TLS termination points to which they connect) use SSL and/or early TLS
Organisation must have documentation confirming that the POS POI devices are not susceptible to any known exploits for SSL/early TLS.
OR:
Organisation must fulfil requirement A2.2
A2.2
Organisations with existing implementations (other than as allowed in A2.1) that use SSL and/or early TLS
Organisation must have a formal Risk Mitigation and Migration Plan in place. The Plan must describe:
· How and where SSL/early TLS is used;
· Results of risk-assessment and risk-reduction controls in place;
· Processes to monitor for new SSL/early TLS vulnerabilities;
· Change control processes to ensure no new implementations of SSL/early TLS;
· The migration project plan
The target migration completion date must be no later than June 30, 2018.
A2.3
Service Providers Only
The service provider must provide a secure service offering by June 30, 2016.
Prior to June 30, 2016, the service provider must:
· EITHER: Offer a secure protocol option for their service offering;
· OR: Have Risk Mitigation and Migration Plan that includes a target date for provision of a secure protocol option no later than June 30, 2016.
Inclusion of Designated Entities Supplemental Validation
Organisations identified as Designated Entities are required to complete Supplemental Validation. Designated Entity status is determined by the Acquirer or Payment Brand. There are no set criteria for this designation but examples may include: organisations that store, process and/or transmit large volumes of cardholder data; those that provide aggregation points for cardholder data; or, organisations that have been subject to significant or repeated breaches of cardholder data.
The Designated Entity Supplemental Validation has now been incorporated into the PCI DSS as an additional Appendix (A3); there are no changes to the validation requirements themselves. The additional testing procedures for Designated Entities include:
Implementation of a PCI DSS compliance program
Further documentation and validation of PCI DSS scope (quarterly)
Incorporation of PCI DSS into BAU activities
Control and management of logical access into the CDE
Method to identify and respond to suspicious events
When undergoing an on-site assessment a Designated Entity must include testing of the requirements in Appendix A3. The Designated Entity must also ensure that the additional, and still separate, ‘Supplemental Attestation of Compliance – Designated Entities’ (S-AOC), is completed and submitted with their validation documentation.
V3.2 introduces further flexibility
As was seen previously with PCI DSS v3.0 and v3.1, changes have been made to the PCI DSS to introduce flexible options that still allow for fulfilment of the intent of a Requirement.
PCI DSS v3.1
PCI DSS v3.2
1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)
1.3.5 Permit only “established” connections into the network.
Instead of explicitly requiring the use of stateful inspection (dynamic packet filtering) v3.2 now specifies the intent of the requirement that organisations must meet: ‘verify that the firewall permits only established connections into the internal network and denies any inbound connections not associated with a previously established session’.
It is expected that by dropping the ‘stateful inspection’ terminology this requirement will be better understood by organisations, particularly smaller businesses reliant on broadband routers supplied by their ISP – the manufacturers of those firewall/routers may or may not call this functionality ‘stateful inspection’. Organisations need to check that their firewall or router keeps a record of established connections, e.g. of permitted outbound connections to the Internet. The firewall or router must use not only its rulebase but also its record of established connections to determine whether to permit or deny a connection. For example, inbound traffic may be permitted because it is a new connection that matches a firewall rule or because it is a valid response to an already established outbound connection.
PCI DSS v3.1
PCI DSS v3.2
1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE.
1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network.
Requirement 1.4 has been expanded to allow for fulfilment of the intent of the requirement through the use of a specific technology (personal firewall software) or through use of technology that provides the equivalent level of protection. This software/functionality must be in place and active on mobile devices when they are without the protection of the organisation’s corporate network, for example when connected to the employee’s home broadband or to a public WiFi hotspot.
PCI DSS v3.1 compliant organisations may need to extend their personal firewall software (or equivalent) deployment as a result of the updates to this Requirement. They may only have protection in place for their laptops but the updated requirement applies to any mobile device not just personal computing devices. Organisations allowing use of tablets and smartphones, as well as laptops, on the company network, which may also be used to connect to the Internet when away from the office or outside of the organisation, will need to ensure all of those mobile devices are protected with personal firewall software (or equivalent).
PCI DSS v3.1
PCI DSS v3.2
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.
The PAN masking on display requirement has added flexibility for situations where an organisation has legitimate business needs to grant specific user roles access to more than the first six and last four digits of the PAN, but not necessarily the full PAN.
The requirement adheres to ‘least privilege’ and ‘need to know’ principles to ensure that if business operations/need can be met by granting access to less than the first six and last four digits this should be what is implemented. For example:
Role
PAN Display
Contact Centre role
No PAN
Contact Centre team lead role, with a legitimate business need, e.g. to process refunds
Last four digits only
Customer Service role, with a legitimate business need, e.g. to respond to retrieval requests and chargebacks
First six and last four digits only
Supervisory Customer Service role, with a legitimate business reason to view the full PAN.
Full PAN
Clarifications of intent and implementation
The PCI DSS v3.2 includes many other updates, clarifications and additional guidance to assist both assessors and organisations subject to the PCI DSS to better understand and achieve compliance with the standard.
All of these updates are included in the Summary of Changes from PCI DSS Version 3.1 to 3.2. Those of particular interest are highlighted below:
Requirement 1.3.3 (Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment) has been removed in its entirety as it has been recognised that its intent is met through other requirements in 1.2 and 1.3.
For organisations using disk encryption to render stored cardholder data unreadable, Requirement 3.4.1 has been updated to confirm that this requirement applies in addition to all other PCI DSS encryption and key-management requirements (i.e. Requirements 3.5 and 3.6).
Many references to the inclusion of payment applications in testing procedures have been added throughout the PCI DSS, including an update to the explanation of the relationship between PCI DSS and PA-DSS. To ensure that organisations don’t just assume that a PA-DSS payment applications meets the PCI DSS requirements, testing of payments applications has been explicitly called out in many requirements. For example in Requirement 2.1 (change vendor defaults), Requirement 3.4.d (Render PAN unreadable anywhere it is stored: examine payment application logs), and in the guidance for Requirement 6.2 (install critical patches within one month). These updates are intended to ensure that PA-DSS validated payment applications are properly configured and securely implemented in line with PCI DSS requirements.
The PCI SSC has expanded the scope of Requirement 6.4.5 (Change Control Procedures). In PCI DSS v3.1, change control procedures were required for ‘the implementation of security patches and software modifications’; this statement has been dropped. The accompanying guidance confirms that the intent is for change control procedures to apply to all system changes, including hardware or software updates and installation of security patches.
Another requirement with an apparently expanded scope is Requirement 8.1.5, although in actual fact it is a clarification of intent. Organisations are now required to manage the IDs used by any third party to support, manage or maintain their system components via remote access (whether vendor, POS solution provider or IT support provider).
Lastly, and as mentioned earlier, all references to ‘two-factor authentication’ have become ‘multi-factor authentication’ (Requirement 8.3). This change ensures consistency across all PCI standards and guidance, such as the Tokenization Product Security Guidelines and PCI Token Service Provider Requirements. It is hoped this change will provide greater clarity as ‘two-factor authentication’ is known to have been mis-interpreted as permitting the use of the same factor twice.
The post PCI DSS v3.2 – What’s changed appeared first on Sysnetgs.com.