Are your customers ready for 31 January 2018?

Are your customers ready for 31 January 2018?
By Natasja Bolton, Senior Acquirer Support QSA

In my last article, I discussed whether two-step authentication was ever acceptable to meet PCI DSS’s requirements for multi-factor authentication. In that article, we also noted that PCI DSS requirement 8.3.1 is currently a best practice which becomes a requirement after 31st January 2018.

 

It seems timely therefore to remind everyone that PCI DSS Requirement 8.3.1 is not the only best practice due to become a requirement from February next year.  As we discussed in our PCI DSS v3.2 – What’s changed article, a number of new requirements were introduced with PCI DSS v3.2. The PCI Council gave everyone 21 months to plan for and implement those requirements:

 

Reqt No. 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 Cardholder data Environment (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

The new requirements applicable to all entities

New Requirement 6.4.6 has been introduced to make sure that PCI DSS requirements are applied or updated whenever the business makes significant changes to in-scope networks and systems.  This means that, whenever new systems/networks are introduced or existing systems/networks modified, businesses 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..  Businesses 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.

 

Requirement 6.4.6 appears in three of the SAQs: the partially outsourced ecommerce SAQ (A-EP), in the payment application systems connected to the Internet SAQ (C) and in SAQ D, so will not impact on the vast majority of your small business customers assessing their compliance against one of the other, smaller SAQs.

 

As we discussed in our previous article, requirement 8.3.1 has been included in the PCI DSS 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.  Businesses 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).  Non-console administrative access is where administrators are able to access the business’ systems over a network. It is called non-console administrative access when the administrator is not physically present at the system’s console using a direct, physical connection to access the system.

 

Requirement 8.3.1 features in more SAQs than 6.4.6: appearing in the standalone IP-based terminal SAQ (B-IP) and the virtual terminal SAQ (C-VT), as well as in SAQs A-EP, C and D.  This multi-factor authentication requirement was included in the SAQs B-IP and C-VT with the release of revision 1.1 of the v3.2 SAQs to align with the intent of the existing requirement 2.3 (which requires strong encryption for all methods of non-console administrative access).

 

It is therefore likely that from February next year, many of your customers will need to implement multi-factor authentication for their non-console administrative access.  Although many small business may be able to avoid this requirement if they do not make use of any methods of non-console administrative access to manage and administer their in-scope systems.

 

Our PCI DSS v3.2 revision 1.1 SAQs Factsheet provides an illustrated example of an SAQ B-IP eligible merchant who makes use of non-console administrative access, showing where they would need not only strongly encrypted methods for administrative access but also multi-factor authentication of the administrative users.

 

It’s important that the upcoming deadline is communicated to your customers soon. If your organisation is planning an outreach campaign then we can help. Sysnet provide a full range of inbound and outbound contact services.

 

The new requirements applicable only to service providers

There are six new requirements that apply only to service providers. These new requirements are discussed in more detail here.

 

Although you may not be tracking the compliance of your customers who are also service providers, consider raising your merchant customers’ awareness of these new requirements, so they know to check for fulfilment of those requirements in any evidence of compliance they may receive from their service providers.  Bear in mind also that these new requirements may be applicable to you too – as they may need to be implemented for services you offer and deliver to your customers (such as your Payment Gateway services).

Our Cyber Risk security professionals are industry leading experts in security and can assist your organisation as well as your business partners and customers when it comes to planning, and assessing service provider compliance

 

Timings for compliance

The deadline for implementing and achieving compliance with these new requirements is the end of January next year.  Even if one of your customers had completed their assessment just before the ‘best practice’ requirements deadline date (marking those requirements as ‘Not applicable because they are best practice’) that does not mean they can wait the twelve months until their next compliance assessment to implement the new requirements applicable to them.

 

In their Attestation of Compliance, businesses have agreed that they ‘must maintain PCI DSS compliance, as applicable to my environment, at all times’.  This means, that businesses must implement the requirements ahead of the 31st January 2018 deadline, even if they will not be formally assessed for compliance until many months after the deadline has passed.

 

The PCI SSC gives an example of this for service provider PCI DSS requirement 11.3.4.1, in one of their FAQs. This requirement obliges service providers using segmentation to undertake testing of their segmentation controls at least every six months. The service provider’s processes must ensure that segmentation penetration testing is undertaken within six months of 1st February 2018. When the service provider’s annual assessment is due, they must be able to provide penetration test results that confirm the segmentation testing was performed to the schedule required by the PCI DSS.

 

For example, if a service provider’s annual assessment took place in October 2018, the assessing QSA would expect to see that:

  • Their methodology and processes for penetration testing had been updated, prior to 31st January 2018, to include the requirement for testing of their segmentation controls at least every six months;
  • Segmentation penetration testing had been performed at least once since February 2018, or more frequently if re-validation of PCI DSS scope was required due to changes.