Remember when PCI DSS version 3.2 was released way back in April 2016? We counted
our blessings that the new requirements truly raised the bar - especially for Service Providers - and gave us a considerable grace period to implement them. And as it goes, 2018 seemed so far away and implementing these changes didn’t seem so urgent. Well fast forward to today and all of a sudden January 31, 2018 doesn’t seem too distant in the future anymore.
We have worked with many entities in the last year who marked the new ‘long runway’ PCI 3.2 requirements as NOT APPLICABLE. Unfortunately, this simply won’t due anymore.
Let’s do a quick run through of the requirements that will kick in within the next couple of months, with some of our thoughts around the implementation efforts of service providers needed to update previous best practices.
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.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
A lock is only as good as the control of the keys involved. This comprehensive inventory will give you greater confidence in your ability to meet existing requirement 3.5.2 which requires you to restrict access to your keys to the fewest number of custodians possible.
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.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
We would advise you to develop and document YOUR own risk based definition of what a “significant change” is in your environment. A good general rule of thumb is that a ‘significant change’ is something that could potentially impact the security posture of the thing that is being changed. This definition will serve you well for this and other requirements, including:
- 6 for your public web applications
- 2 for internal and external network vulnerability scans
- 3.1 and 11.3.2 internal and external penetration tests
- 2 risk assessments
More Info: http://thepciportal.com/2017/01/06/the-significance-of-change/
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
This is the big change for 2018 for merchants and service providers alike. It is also a big step forward for reducing the risk that password authentication alone imposes.
Delving a bit further into this, the classic paradigm for multi-factor authentication systems identifies three factors as the cornerstone of authentication:
- Something you know (e.g. a password)
- Something you have (e.g. an ID badge or a cryptographic key)
- Something you are (e.g. a fingerprint or other biometric data)
Multi-factor authentication refers to the use of more than one of the factors listed above. The strength of authentication systems is largely determined by the number of factors incorporated by the system. Implementations that use two different factors are considered to be stronger than those that use only one factor.
Other types of information, such as location data or device identity, may be used to evaluate the risk in a claimed identity, but they are not considered authentication factors.
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)
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
The good news is, most assessed service providers have been partially meeting this requirement for some time now, who isn’t monitoring their firewalls to ensure uptime these days? The other security control systems listed, however, are probably not being monitored for uptime.
The challenge here is figuring out how to implement this type of monitoring on the other listed systems. Existing health monitoring systems might be brought into scope here but leveraging existing SIEM solutions might be a better idea for security operations teams. As we mature our controls for this requirement I think we will see tighter integration of SIEM solutions with common 3rd party security solutions for up/down status.
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
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
Diagnosing the root cause of and resolution to problems? This sounds like a job for an existing Problem Management process staffed with ITIL trained personnel. And if you aren’t so lucky to have this in your organization, it is time to ramp up. Start with mapping out a flowchart of your desired results and identifying where a process will need to be beefed up or created from scratch.
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.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
This control should be no great hardship for service providers as it is just a doubling of frequency for our controls meeting 11.3.4.a. The real challenge here is the fact that most organizations aren’t sure of their ability to test their segmentation controls at all. That is a topic for a whole other blog post, but suffice to say our QSAs have come up with more than one way to handle this challenge.
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.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Our Take
No problem and about time! This requirement will reinforce your compliance work’s evolution from project to program.
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
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
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
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement
Our Take
A little extra incentive to improve our maturity levels with 12.11! Ad-hoc just won’t do anymore. If this control is a challenge in your organization, you might not be doing your PCI compliance efforts as efficiently as you could be. We think this control is going to help organizations move beyond firefighting to fire prevention.
Since several of these requirements involve significant change, it is best to vet them from a PCI perspective with your QSA or your PCI Trusted Advisor.
To learn more about the PCI 3.2 Requirements, check out our resource center of webcasts, blogs, infographics, and more.
Also feel free to leave a comment below and we’ll respond to you right away!
Submit a Comment