It is finally here: the forward-dated controls that have been in existence since the release of version 3.2 of the PCI Data Security Standard, from April 2016. Hopefully, by now, you have had a chance to review them, but if you haven’t we are going to take a deep dive on each of the new controls and discuss what would be needed to pass your next assessment. Let’s first look at the controls applicable to all entities, both merchants and service providers.

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.

As with the recent push of more “business as usual,” there have been more controls looking to ensure to keep the accuracy of the environment currently within the documentation. This is no different. First off, ensure that your organization defines what a “significant change” means. PCI gives some examples, but in my opinion they are a little dated. For example, they suggest that a new server is a significant change. In the era of auto-scaling and virtualization, this may not be the best example of what constitutes a significant change. This is why it is important to document this trigger for your organization. Keep in mind that this is not the only control that has this trigger as well. If there were no significant changes within the last year, the Report on Compliance will mark the remainder of the requirement and not be applicable. However, it is recommended that you update your change control documentation to ensure that this step is incorporated if and when there is a significant change. If there is a trigger of a significant change, ensure that the changes are tracked and records are kept on the relevant updates. It is recommended to either create a separate change record for this or incorporate them into the existing change tracking system. The QSA will request the change records, documentation, and sample systems to ensure that this was effectively in place.

8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

This requirement has been talked about quite a bit already in the community, though I think it will serve to highlight just a couple of points with the requirement. There are two significant narrowing attributes to this requirement: “access to the CDE” AND “with administrative access.” So, when enforcing this control, we look specifically at whether the system is defined as CDE and whether the user is considered to have administrative access. Also, if you look at the PCI SSC FAQ, they state that this control "... can be implemented at the network level or at system/application level; it does not have to be both.” This means that you can enforce multi-factor authentication at a jump box, as long as all administrative access goes through this channel.

3.5.1 Additional requirement for service providers only: 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

This new requirement essentially just extends the existing documentation requirements around the management and storage of the keys to include some details, including algorithms and keys used for the protection of cardholder information. However, in the normal PCI irritations, they also add that all protocols need to be documented as well, but requirement three is dedicated to only at-rest encryption. Even though a contradiction, there is no hard rule that the requirements have to fit cleanly, so we must also look for this to be documented as well.

10.8 Additional requirement for service providers only: 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

• FIM

• Anti-virus

• Physical access controls

• Logical access controls

• Audit logging mechanisms

• Segmentation controls (if used)

10.8.1 Additional requirement for service providers only: 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

The purpose of this requirement is to identify that a failure has occurred with one of your critical security controls before it comes up in your assessment, where your IDS hasn’t reported anything in six months. PCI gives many examples of what they expect to be covered by this requirement, including firewalls, IDS/IPS, FIM, etc. To implement this control, one common way is with a heartbeat service to monitor appliances, like vulnerability scanners or intrusion detection devices. Also, utilize your SIEM, depending on its capabilities, to ensure that logs are coming in promptly for all systems in scope and even for specific components, like file integrity monitoring logs. Lastly, keep in mind that this does not need an actual alert to be generated. As part of a common process, you could incorporate into the review process that if an issue is discovered, you alert the appropriate individuals to the issue. If there is an issue detection, ensure that the steps of 10.8.1 are documented and retained for evidence during the next assessment. It is recommended that you feed this into your incident response process and record the issue similar as you would a minor/moderate incident.

11.3.4.1 Additional requirement for service providers only: 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.

This requirement ups the existing obligation to perform a penetration test to twice a year, instead of just one. Also notice that it adds the verbiage that you must perform another penetration test if you change the segmentation controls, whether or not you consider it a significant change or not. However, there are probably very few situations that would not trigger the significant change requirement if you are changing the segmentation controls. I would also point out that this does not intend that any changes to the access control lists would require another penetration test. This would be governed by the requirement 1.1.1, where you should have a process in place to review all changes to your routers and firewalls.

12.4.1 Additional requirement for service providers only: 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

This requirement mandates the creation of a PCI Charter; essentially a document outlining the responsibility for the PCI compliance program and the commutation of the status of the program to executive management. The requirement does not specify exactly how often you have to communicate the status, but since this is an annual compliance measurement, there should be at least one example during the testing time period. We recommend that it be a quarterly process and incorporate some of the components from 12.11, which we will cover next.

12.11 Additional requirement for service providers only: 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 Additional requirement for service providers only: 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

Lastly, there is a requirement to check existing requirements. Namely, ensure that some of the reviews are being done as appropriately, processes are being done, and new systems are being applied security configurations consistently. This must be formally documented and signed off by the person or group identified as responsible within the PCI Charter. As always, if you have any questions about the specific requirements and how it applies to your organization, you should reach out to your trusted QSA partner for advice and direction.