Are you a SaaS? Do you offer various shared services to merchants and other service providers with access to resources or services being logically controlled or partitioned to keep resources contained and data isolated between cloud customers? If so, Appendix A1 is now for you!
On March 31st, 2022 PCI DSS v4.0 was released. Today’s post is part of series of pieces we are publishing that explore the changes to the PCI standard and provide insight into what the changes will mean for your organization. All of our posts can be found here.
One of the bigger changes to the PCI DSS in version 4.0 for certain types of Service Providers is the change in scope to Appendix A1. In PCI DSS v3.2.1, Appendix A1 was titled “Additional PCI DSS Requirements for Shared Hosting Providers,” and in PCI DSS v4.0 is titled “Additional PCI DSS Requirements for Multi-Tenant Service Providers.”
While the change in wording between “Shared Hosting Providers” and “Multi-Tenant Service Providers” may seem subtle, the increase in scope of Service Providers impacted is significant. Namely, the broader definition of Multi-Tenant Hosting providers will include many Software as a Service (SaaS) providers who otherwise would not fall under the definition of hosting providers.
Let us start the journey by better defining “Multi-Tenant Service Providers,” then take a spin through the various requirements in Appendix A1, detouring especially into the two new requirements in Appendix A1.
Appendix A1 starts by defining Multi-Tenant Service Providers quite simply as Service Providers which “offer various shared services to merchants and other service providers.” It then goes on to provide a variety of examples where customers share computing resources, “with access to these resources or services being logically controlled or partitioned to keep resources contained and data isolated between cloud customers.” A1 further clarifies that data center / co-lo’s are not included.
With the proliferation of SaaS services within the enterprise, the new designation of applicability will apply to a much wider range of service providers than traditional cloud hosting providers.
Now that we understand what kind of Service Providers A1 applies to, let’s look at the actual requirements. Of the seven A1 requirements (A1.1.1-1.4, A.2.1-2.3), three are new (A1.1.1, A1.1.4, A1.2.3), and while the others have not significantly changed, there are some clarifications. A few things to note:
The first new requirement, A1.1.1 requires segmentation both between customer environments, as well as between customer environments and the service provider’s environments (commonly referred to as the control backplane). While the variety of multi-tenant provider types may make this seem a bit abstract, I like to think of it similar to virtual machine (VM) segregation, where the guest VMs are the customer environments, and the service provider environment is the hypervisor.
A1.1.2-1.3 are legacy requirements focusing on customer permissions, ensuring they can only access their environments, data, and resources. Again, think of two separate guest VMs with storage on a SAN. Guest 1 cannot access Guest 2, and vice-versa, and Guest 1 can only access their storage on the SAN, not Guest 2’s, and vice-versa.
A1.1.4 is another new requirement and is an extension of the penetration testing requirement 11.4.6 for segmentation testing. PCI DSS v4.0 Requirement 11.4.6 (was 11.3.4.1 in PCI DSS 3.2.1) requires that all Service Providers perform segmentation testing at least every six months, rather than annually like general network penetration testing. A1.1.4 extends this concept further and requires that testing of the customer segmentation controls be performed every six months (rather than just segmentation testing of the control backplane). Note that while 11.4.6 also requires segmentation testing after a significant change, A1.1.4 does not.
Following our VM analogy, this is like testing for VM Escape attacks, against both the other guests as well as the hypervisor. As A1.1.1-1.3 require segmentation of both the service provider environment and between customer environments including all customer data and other resources, all these controls should be tested. Due to the potential complexity, as well as required isolation of customer data, A1.1.4 makes the notable distinction from the other PCI DSS testing requirements in that it explicitly allows for the creation of test customer environments against which the testing may be performed. While this certainly minimizes potential customer impact, it puts the burden on the Service Provider (and penetration testers) to document how the test environment accurately replicated all aspects of the production environment, not just the production segmentation controls.
A1.2.1-2.3 are all about ensuring Multi-Tenant Service Providers have the audit logs and IR processes in place to not only be able to detect and respond to any potential breaches, but also provide this information to their customers. While this principle is not new to PCI DSS v4.0, requirement A1.2.3 is, and extends the concept to explicitly require providers to not only provide a mechanism for customers to be able to report both suspected vulnerabilities as well as incidents, but also that the provider perform remediation as well.
It is interesting to note that while the Customized Approach Objectives require that “Customers are informed where appropriate” (emphasis mine), the Defined Approach requirements do not explicitly require communication with customers (although presumably a service provider will at least have to communicate remediation to the reporting customer if they wish to retain them as a customer, but that is not nearly the same as reporting vulnerabilities and incidents to all customers).
While the requirements for Multi-Tenant Service Providers in PCI DSS v4.0 are generally the same as previous years, there is a bit more formality on segmentation controls, testing, and vulnerability and incident reporting. The most significant impact is that this whole Appendix is no longer limited to just traditional Shared Hosting Providers, but Multi-Tenant Service Providers of any kind (less co-lo’s), and that means a lot of SaaS providers are going to have to prepare for these immediately.
Furthermore, it is important to note that while the three new requirements in A1 are future dated, the change in applicability from Shared Hosting Providers to Multi-Tenant Service Providers is not and will go into effect immediately with PCI DSS v4.0.
Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.