If you’re a merchant, service provider, or anyone else who stores/processes/transmits cardholder information (i.e. anyone with the PCI DSS in scope), you probably don’t need me to tell you that we now have a new version of the DSS — revision 3.2 — that just came out at the end of April.
It’s new, it’s shiny, and it has quite a few folks wondering just what exactly it means to them from a practical point of view.
The good news is that, for this iteration of the standard at least, the impacts to folks in the merchant and service provider community are comparatively minimal relative to some past versions we’ve seen. As promised by the standards council on several occasions, as the standard continues matures, the frequency of new requirements remain low.
That’s not to say though that there aren’t any items that merchants or service providers should know about and plan for. In fact, there are a few items that bear specific discussion. While not all of the new requirements need to be addressed right away, beginning to plan now ensures adequate preparation time since the changes might be larger than they appear on the surface.
With that in mind, let’s take a look at some of the specific areas that merchants and service providers will likely want to be mindful of.
New Authentication Requirements
One of the more impactful changes is the modification to requirement 8.3. This now requires multi-factor authentication to non-console administrative access in the CDE. This is a bigger deal than it might seem on the surface.
First, bear in mind that it’s not exactly a “no brainer” when it comes to the engineering involved. For example, if you’re already using a product such as a privileged identity management solution that has altered the login flow, integration can be complex. Likewise, legacy systems and applications are in scope and some of these as we know can be “resistant” to modification of the logon flow.
Second, consider what specifically this potentially could apply to. Database administration? Virtual host administration? Containers? System or network access? Yes, yes, and yes.
If you don’t believe me, take a look at the definition of “system component” on page 10; i.e., “’System components’ include network devices, servers, computing devices, and applications.” The DSS goes on to specifically list virtual devices, numerous types of system services and software, and a host of other items as examples.
Now, the standard does say in the guidance for 8.3, “Multi-factor authentication is not required at both the system-level and application-level for a particular system component.”
So that does arguably make things simpler. However, this isn’t a “dodge” to allow an organization to bypass the requirement (for example by employing a multi-factor solution nobody uses when actual administration is done through some other channel.) Instead, the implication seems clear that admin activity, regardless of the method used to effect it, requires multi-factor.
Change Control Documentation
Requirement 6.4.6 was added that now requires that PCI relevant documentation be updated upon “significant changes” to the environment. They provide some commentary in the guidance to clarify what they mean by this: “A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process.”
In other words, as part of the change control, you’ll now want to have some evidence that you can explicitly point to (since assessors will now review it per the assessment column) to demonstrate how you’ve addressed the relevant DSS requirements per each change that you make.
Again, this is harder than it sounds. Why? Automation. For many shops, automation is increasing. Under DevOps, multiple code pushes can happen on a daily basis, some of which might constitute a “significant change.”
In this context, there may be change control/validation processes that are already automated and, as part of that automation, don’t already record validation of DSS controls (assuming they do it at all).
Therefore, gathering the required evidence for these changes may require updates to how that automation is done. Likewise, automated modification of network configuration (e.g. software defined networking, backplane communication, migration of containers/VM images) might not, as a matter of course, precipitate updates to existing documentation like the network diagram required by PCI. It might take some legwork to make it so they do.
Service Provider Requirements
The new revision introduces also a host of requirements specific to service providers. Requirement 10.8 requires service providers to detect and report failures in security controls. While this is a good thing (and, come on, arguably ethically questionable if not already being done), it will still require potential effort on the part of some service providers to ensure that failures are both captured and reported when they occur.
Another new requirement for service providers is the requirement (3.5.1) to “Maintain a documented description of the cryptographic architecture…” This includes inventory of HSM’s, details of algorithms/protocols/keys (including expiry), and description of key usage for all keys.
Consider the number of keys in a medium to large size service provider environment: there’s TLS certs (potentially multiple per device), VPN certs, SSH keys, application keys, etc.
Some service providers might know (and be able to produce a document that lists) the expiration dates, usage, length, and location of all those keys. But for quite a few, this will likely require a discovery and cataloguing effort to get to. Specifically, a process to create a master list – and an ongoing operational capability to ensure it stays accurate and up to date over time (i.e. in light of architectural changes, key rotation, etc.)
There are a few other service provider targeting requirements as well that were added. Service providers are also now required to review quarterly that personnel are following security policies and operational procedures (requirement 12.11), that they have defined responsibilities for cardholder data protection and the DSS compliance program (12.4), and that they penetration test segmentation controls every six months (11.3.4.1). None of these are necessarily “rocket science,” but they will likely require some pre-planning to ensure that the organization is ready to move when the time comes.
The Bottom Line
Now, these aren’t by any means the only changes in the new 3.2 revision. There are a host of much-needed clarifications, evolving requirements, additional guidance, and other updates. However, these particular items, because they do contain a few potential “gotchas,” are among the subset that organizations might consider starting the planning for now.
While the new requirements do allow some lead-time (they go into effect February 2018), the lead time is likely well needed. Specifically, to figure out architecturally how to address them, to create an implementation plan for getting to compliance, and for rolling that plan out in time to meet the deadline.
Ed Moyle is Director of Thought Leadership and Research at ISACA. Prior that he was Director of Emerging Business and Technology for ISACA. Before joining ISACA, Ed was a founding partner of the analyst firm Security Curve. In his more than 15 years in information security, Ed has held numerous practitioner and analyst positions including senior manager with CTG’s global security practice, vice president and information security officer for Merrill Lynch Investment Managers, and senior security analyst with Trintech. Ed is co-author of Cryptographic Libraries for Developers and a frequent contributor to the Information Security industry as author, public speaker, and analyst.