Is Microsoft Azure PCI DSS Compliant? Lessons in due diligence….

I've been busy assessing a Microsoft Azure environment as of late, for PCI DSS purposes. So. I go here to download their AoC:

https://azure.microsoft.com/en-gb/support/trust-center/compliance/pci-dss/

The date of the AoC is December 31, 2014, and a number of requirements have been “Not Tested”, identified as “N/A” and Compensating Controls have been applied. I guess that's fair enough – a QSA shouldn't really question another QSA's work, but the use of Compensating Controls is a concern.

Presumably a company like Microsoft isn't met with the typical business or technological limitations that perhaps a bank using a 40 year old LINK network is, so alarm bells start ringing. Just why can't a company like Microsoft apply all PCI DSS controls to the letter? A state of the art hosting platform shouldn't have ANY technological limitations that mean certain PCI DSS controls do not apply?

The more concerning element, which is why I've written this post, is that the AoC attests the following services as being PCI DSS Compliant (as of 31 December 2014):

Azure Core Services, Platform Services, Directory Services, Data Processing, Infrastructure, Operations

Great. So I go to the Azure website, and then find I can't actually BUY any of these services by name. The website implies to me that services are constantly under review, subject to changes, improvements, additions and removals. But I can't buy a service called “Azure Core Services”. Therein the problem, and here's what I've found out.

What are Azure Core Services?

The Online Services Terms define Azure Core Services as (dated November 2015, taken from http://www.microsoftvolumelicensing.com):

I can't find “Platform Services, Directory Services, Data Processing, Infrastructure, Operations” as mentioned in the AoC anywhere. Nor can I find the Azure App Service in the list above, which surely has to be the most popular Azure offering.

So going by what can be purchased, referenced here – https://azure.microsoft.com/en-gb/pricing, it appears that large chunks of Azure have NOT been validated according to the Azure AoC.

I'm also directed to the Microsoft Azure Trust Center – https://azure.microsoft.com/en-gb/support/trust-center/compliance/pci-dss/. It mentions “in-scope services”, which in my mind tells me there are also “out-of-scope services”, and directs me here – https://azure.microsoft.com/en-gb/support/trust-center/services/. This shows a list of services that are PCI DSS level 1 (whatever that means – as we all know, PCI controls are all the same regardless of level.).

What services appear to be missing?

So going by the Microsoft website, and what it says are PCI DSS level 1 services, compared to what you can actually go and buy, the following services are missing completely. They are not mentioned in the AoC, or the Trust Center:

Data + Storage

• Everything!

Identity & Access Management

• Azure Active Directory B2C
• Azure Active Directory Domain Services

Of course, the website isn't something to go by – we can only rely on the AoC, but where the AoC is so broad and lists start not matching up, it makes due diligence a nightmare. There is no clear baseline from which to start. Some Azure Core Services (eg Biztalk) are explicitly excluded from the Trust Center as being PCI DSS Level 1. So straight away, we have little faith in “Azure Core Services” as mentioned in the AoC as being 100% inclusive, compliant and validated, as the website shows sub-services missing. We are several months on from the date of the RoC, maybe things have changed. I don't know.

Is Azure PCI DSS Compliant?

At the moment, I would not feel comfortable hosting cardholder data on Azure, period. Not only is there a lack of validation documentation concerning their services, the AoC also marks audit log file integrity (10.5.5) as N/A or Not Tested. The response against 10.5.5 is:

10.5.5 All logs are forwarded to a centralized logging server. The logging storage solution does not allow users to change any logging entries.

Not allowing users to change logging entries is one thing. Maintaining log file integrity is a completely different thing. If there is failure here for a QSA and/or Microsoft to misunderstand a simple PCI DSS control like this, what else is wrong? Have the compensating controls been understood correctly?

So. Is Microsoft Azure PCI DSS Compliant? Some of it might be, some of it definitely isn't (according to the data above), and to date I haven't been able to find any formal documentation that assures me, a seasoned Qualified Security Assessor, that any of the services you can buy from Azure have been correctly validated.

If you decide to host your CDE or parts of it in Azure, do so at your own risk. I'm advising clients to host elsewhere at present, and would warmly welcome Microsoft's formal response on this matter. There's a box to do this below…

Lessons learned

My advice if you're looking to procure a 3rd party service to host, secure, or connect to a CDE?

1. Download, read, and understand the Third Party Security Assurance Guidance document on the www.pcissc.org website.
2. Don't believe anything you read in marketing material or websites. In this case, Microsoft's terms and conditions of website usage imply that all web content is delivered “as is” and exempt themselves from any loss or liability in case of technological errors and omissions. In short, it offers no assurance whatsoever. Same goes for AWS, Google or anyone else.
3. Don't believe anything sales or support will tell you. This isn't assurance.
4. You can only rely on what's in the AoC, or RoC. These are solid, independent, unwavering milestones of assurance. Websites can change, an AoC cannot.
5. Only accept an Attestation of Compliance that explicitly refers to the services you've purchased.
6. If in any doubt, either go elsewhere, or ask your QSA to go and audit the services you've bought.

The worst thing you can do is go ahead and buy cloud services, and try and fix this sort of thing later. You get what you pay for, and buying a cost-effective service with little proof of any security due diligence going on will also expose you to data breach costs if cardholder data goes missing from these systems. Do think about “what if”. So if you experience a data breach, just how soon would it take a provider to respond? How quickly can they close off firewall ports, remove malware and update IPS/IDS rules? How soon can they send you the log files and a forensic image of the compromised system…?

If still in doubt, get in touch. I founded the PCI SSC's Third Party Security Assurance SIG back in 2013, which input directly into PCI DSS v3.0/3.1 and created the TPSA guidance you can now download from the PCI DSS website, and do this sort of thing day in and day out.