This tip is a part of the SearchCloudSecurity.com learning guide, PCI and cloud computing: Cloud computing compliance...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
When it comes to Payment Card Industry Data Security Standard compliance, not all of the 12 requirements are created equal, at least when it comes to implementation complexity. One requirement that has historically been difficult for organizations to meet is the requirement to keep public-facing Web services protected from emerging threats. And, while this particular requirement has always proven difficult for organizations to address, recent developments in IT --- particularly the increased prevalence of cloud-based services -- have made compliance even more difficult.
PCI requirement 6.6 and the cloud
PCI requirement 6.6 is intended to ensure externally facing Web applications (including Web services) are protected against application-level attacks and -- more importantly -- that they stay protected over time. To ensure this, the requirement specifies that organizations employ one of two controls for public-facing (i.e. Internet accessible) Web applications: perform a periodic (at least annual) technical validation of the application via code review or application testing or, alternatively, deploy a Web application firewall (WAF).
What makes the situation particularly complex for organizations in a cloud context is that just relocating applications to an environment outside the organization’s perimeter (for example, to SaaS providers) without putting some time into rethinking how it impacts this requirement can have some unintended consequences. For example, consider what happens in the case that you have an application that currently intersects your cardholder data environment (CDE) and where you’ve historically addressed PCI requirement 6.6 for that application by deploying a WAF. If you contract with a service provider that offers everything up to and including the application server stack, you may limit your ability to deploy a technology like a WAF in that new hosted context. If you execute your migration plan without re-evaluating how you will address requirement 6.6 in light of your new technology choices, you’re likely to encounter a nasty surprise when that portion of your infrastructure comes up during your yearly assessment audit.
The point is, if you’re an entity that’s regulated under the PCI DSS and going through a cloud migration, it behooves you to take a hard look at the public-facing applications that are currently in your CDE and how you will be addressing PCI requirement 6.6 once you’ve made the cutover.
Complying with PCI requirement 6.6 in the cloud
First of all, it’s important to determine if you will need to investigate other compliance strategies in your particular use case. For example, there are a number of scenarios where 6.6 will not necessarily apply to you, depending on what types of cloud-based services you are looking to deploy. This is particularly true if you are a buying a SaaS service from a provider that specializes in payment processing.
In the case of a cloud service that is governed and certified under the Payment Application Data Security Standard (PA-DSS), your compliance burden will be to ensure you’re using the product in a manner that is consistent with the vendor’s deployment instructions. In that case, your responsibility will not be to undertake the application-specific technical controls outlined in 6.6 (unless, of course, the vendor’s instructions require those controls for the application to be used in a compliant manner.) Why? Because it’s part of what the vendor is required to prove as part of certifying the application (see PA-DSS requirement 5).
Alternatively, if you’re purchasing a straight SaaS solution covered by the scope of the service provider’s PCI DSS review (for example, a Web virtual terminal), your compliance burden won’t include these specific application-level technical controls because it’s covered under the auspices of the vendor’s PCI DSS certification. In that case, you’ll need to keep track of the service provider’s compliance status rather than implement the technical controls themselves (however, note the scoping defined by the PA-DSS: namely, that the product is not relicensed and you’re not customizing the deployment/use).
So, if your cloud transition includes one of those two scenarios, moving to a cloud environment may be beneficial from a compliance standpoint. That being said, those two options aren’t the normative case. The normative case is usually either 1) a non-payment system intersecting the CDE moving to a service provider, or 2) discovery after the fact of a non-payment SaaS application containing cardholder data. Neither of those two situations is ideal from a compliance standpoint; they leave you responsible for ensuring compliance with 6.6, but architecturally not ideally positioned to do so.
Given those set of circumstances, some of the issues should be obvious. First of all, it’s the rare SaaS vendor that is going to let you do code review, annual or otherwise. Second, multi-tenancy is likely to make it unlikely that you’ll be permitted to do active application testing. And third, lack of control over the infrastructure is likely to preclude large footprint WAF filters in front of applications. Should you find yourself in this boat, your options are somewhat limited but not completely eradicated; you can address the situation via a scoping strategy, business process strategy or technology strategy.
From a scoping strategy, one of the most expedient methods would be to remove cardholder data from the equation. You could, for example, alter the use of the application to remove cardholder data from the scope of application processing. From a business process standpoint, you can put pressure on the vendor to certify to the PCI DSS or pressure them to let you conduct application testing, either directly or by an independent, reputable third-party. Lastly, from a technical standpoint, you can look to leverage a WAF, either by pressuring the vendor to install a WAF directly, or by considering a WAF with a lighter footprint, such as the open source OpenWAF. A smaller footprint may allow for installation where a large footprint WAF might not.
Whichever strategy you select, the important part is to do it strategically: If you’re an organization going through a cloud transition and you have a CDE with external-facing websites in it, planning ahead can mean the difference between approaching a potentially sticky situation with options vs. scrambling at the last minute to kludge something together.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.