Paul Traill, Senior Information Security Consultant
The current version of the Payment Card Industry Data Security Standard (PCI DSS) has been in place since April 2016. However, there are a number of requirements within this version 3.2 that up until this year have not been mandatory.
Instead the PCI Security Standards Council (SSC) had marked these particular points as ‘best practice’ to allow organisations time and space to implement them.
There is a danger however that these ‘best practice’ requirements may have been over looked by some companies so that when they come to do their 2018 attestation of compliance, they may suddenly be faced with significant areas of non-compliance. As you will see below, this especially applies to service providers (but Merchants shouldn’t rest on their laurels either).
Let’s discuss these ‘best practice’ points in turn and highlight what needs to be in place from end January 2018, to maintain compliance.
Requirement 3.5.1: Maintain a documented description of the cryptographic architecture.
This is an additional requirement for service providers (SPs) only. It mandates that SPs must document in detail key aspects of their cryptographic implementation, including algorithms, protocols, and keys in use. Interestingly, other than some fleeting references in guidance columns, this is the only place in the whole of the standard that uses the term ‘architecture’ directly as a requirement.
Requirement 6.4.6: Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems, and documentation updated.
This a now a mandatory requirement for both SPs and Merchants. It requires that organisations must have an additional process in place to carry out a ‘PCI DSS-relevant review’ of changes and ensure that the cardholder data environment (CDE) is kept up to date. For example, maybe an asset inventory needs to be updated; or a network diagram amended; or a new system needs to be included in the vulnerability scanning schedule.
Requirement 8.3.1: Incorporate multi-factor authentication (MFA) for all non-console systems admin access into the CDE.
For both SPs and merchants, this potentially represents a significant change in working methods for system administrators. All admin access which is not in front of an actual console must use an MFA option when accessing the CDE, either at the network or system / application level (not both). This is to reduce the risk of powerful admin level access being compromised due to just a password being sniffed either on an internal or external network.
Requirement 10.8 and 10.8.1: Implement a process for the timely detection, response and reporting of failures of critical security control systems.
This is another set of requirements just for SPs. It means that an additional safe-guard measure must be in place to alert if a control such as an IDS/IPS, firewall, anti-virus, or access control mechanism stops working correctly. So, for example, its not just a requirement to have an IDS/IPS in place, but SPs must also check that the solution is doing its job properly and actually detecting intrusion attempts. The new alerting and response process must be documented.
Requirement 184.108.40.206: Penetration testing to be carried out on at least a 6-monthly basis, if segmentation is used.
Yet another uplift for SPs. Where segmentation controls are used to limit the scope of compliance, the organisation must validate that these controls are working effectively at least every six months and after any changes to segmentation methods.
Requirement 12.4.1: Executive management must establish responsibility for the PCI DSS compliance program.
Again, one for SPs. The organisation must define a charter which describes how the compliance program is organised, and that top management have assigned overall accountability and applicable roles.
Requirement 12.11 and 12.11.1: Perform reviews at least quarterly to confirm personnel are following security policies and procedures.
This is now a mandatory requirement for both SPs and merchants A process for confirming that other critical procedures such as change management, firewall policy reviews, log reviews and so on, are actually taking place effectively. Documentation, for example a completed checklist, clearly showing the results and sign-off, needs to be included.
Requirement A2.2: Migration projects to move from SSL / early TLS to be completed.
For all entities, the risk mitigation and migration plan for moving to secure TLS protocols must be completed no later than end June 2018.
How PGI can help your organisation
So, this year is a significant one in terms of ratcheting up compliance levels; and with the likely announcement of an updated version 3.3 of the standard, all entities should play close attention to ongoing PCI DSS requirements.
PGI can provide assistance to your company’s PCI DSS compliance needs. This can either be as a QSA to assess your levels of compliance, or as expert security practitioners to put in place new documentation or processes tailored to your organisation. Contact us to discuss your requirements: firstname.lastname@example.org or +44 (0) 845 600 4403