If I were to use separate Windows Server that was PCI-DSS compliant, would I still be compliant if I had a SQL Azure hosting the backend? This is assuming that I'm compliant at the application layer, and that I'm only storing permitted values (like no CVV), etc.
AWS is now PCI DSS 2.0 Level 1 compliant, so the assumptions that Level 1 is not achievable by a cloud vendor is not correct:
http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs/
In addition, Rackspace has also achieved PCI Level 1 compliance:
http://www.rackspace.co.uk/rackspace-home/media-centre/news/article/article/rackspace-enhances-security-with-pci-accreditation/
It is true that Microsoft has not yet achieved PCI compliance for Windows Azure.
It is likely that they are actively working on addressing any limitations in Windows Azure so that they will also be able to provide this service to their customers and remain competitive, but as of today they have not yet achieved PCI compliance.
Microsoft writes in the Azure Faq:
At commercial launch, Windows Azure will not have specific audit or security certifications. You can expect to see us pursue key certifications, such as the ISO27001, in the near future. The Windows Azure Platform and Windows Azure apply the rigorous security practices incorporated in the Security Development Lifecycle (SDL) process. SDL introduces security and privacy early and throughout the development process. The Windows Azure Platform and Windows Azure also benefit from the security capabilities afforded by the Microsoft Global Foundation Services’ (GFS) infrastructure. The GFS assurances are validated by external auditors on a regular basis and include a comprehensive security program that covers the entire delivery stack.
Microsoft makes no claim regarding PCI standards for 3rd party hosting. There are ways to develop cloud based applications to use 3rd party PCI data processers that may keep the cloud application itself out of scope.
http://www.microsoft.com/windowsazure/faq/default.aspx
choose "Licensing and Service Level Agreements" in the drop down
then find the last paragraph "What industry audit and security certifications cover the Windows Azure Platform? Specifically, call out position on SAS70, ISO 27001, and PCI?"
Not sure of PCI-DSS Compliance status in Azure, but I will note that Azure and EC2S3 are not the same animals. Azure is a completely hosted infrastructure which exposes services and endpoints to offer application writers the ability to sit on a fully managed and monitored (including typical security constructs in place for the on-premise Server product) platform, and extend these services to the resident applications.
Considering the amount of time that Microsoft has spent with the PCI folks (from Vista on), I would be highly surprised if a PCI-DSS compliant application didn't maintain it's level of certification when extended to Windows Azure.
Hope this helps. The purpose wasn't to bash EC2S3, it was more to fill in the blamks on Azure.
Mr. Helper :-)
Just an update on this question.
As it stands currently, Windows Azure is indeed PCI DSS Level 1 compliant. See the following Windows Azure Trust Centre article for more information:
Windows Azure Trust Center - Compliance
With PCI DSS it is important to remember that it is not just about storing, it's "store, process, or transmit." If any of this happens in or through the cloud then the cloud becomes part of your cardholder data environment, thus in scope for PCI compliance. Since it's a cloud that you don't control, there would be no way to verify compliance.
No verification, no compliance. Sorry.
Looks like AWS and Rackspace both have achieved some level of compliance (http://aws.amazon.com/security/pci-dss-level-1-compliance-faqs/, http://www.rackspace.co.uk/rackspace-home/media-centre/news/article/article/rackspace-enhances-security-with-pci-accreditation/), but Global Foundation Services (the infrastructure behind Microsoft Windows/SQL Azure, CDN, etc) has not (http://www.globalfoundationservices.com/security/). I would not be surprised to see that GFS achieves some accredication in the near future, however.
Amazon announced PCI DSS Level 1 compliance on Dec 07, 2010. My answer below is now incorrect.
See http://www.mckeay.net/2009/08/14/cannot-achieve-pci-compliance-with-amazon-ec2s3/. Amazon says you can't achieve PCI-DSS level 1 compliance on their infrastructure. The important lines are -
It is possible for you to build a PCI
level 2 compliant app in our AWS cloud
using EC2 and S3, but you cannot
achieve level 1 compliance. If you
have a data breach, you automatically
need to become level 1 compliant which
requires on-site auditing; that is
something we cannot extend to our
customers.
I haven't read Azure's documentation, but I am pretty sure they don't allow on-site auditing. Given that, the same conclusions would apply to Microsoft Azure as well.
Related
Is Microsoft provided few standard device provisioning service in Azure marketplace which can be directly used for device provisioning for any custom device? Or OEM needs to create a device provisioning service for their custom device ,put that in the market place and then use that device provisioning service from market place?
Could someone please clarify? Thanks.
MS has a Auto-provisioning service but is not a full fledged system. But that is to be expected as the market requirements can be vary broad and very much use case specific.
https://learn.microsoft.com/en-us/azure/iot-dps/
In terms of OEM services. OEM's can probably create such services, but again the use case and ownership questions arise.
So the basically the 'basic' tools are there but it is kinda left to you on how you want to deal with the situation. Thinking of integration with CI/CD and the custom software needed to install on each device - Some custom work such a provisioning service is need. At least in our case.
But this can be a nightmare when going to the thousands of devices to manage.
As Van mentioned, Azure does have a device provisioning service that can be used for any custom device, and new features were announced about a month ago.
If there are gaps in the service, please suggest improvements in the UserVoice! As the PM for provisioning service, knowing the gaps means we can start to fill them.
Since Azure Functions host are dynamically added and removed based on the number of incoming events under "Consumption Plan", what is the guarantee that Azure transparently encrypts the data in-transit as well as at-rest on the hosts? Are there any documentations which can share some light on how Azure Functions fulfills HIPAA compliance?
Be careful not to conflate two separate things. The plan type is not relevant to compliance.
Azure Functions are covered for HIPAA apps. You can find the details here: Overview of Microsoft Azure compliance
Note, Azure itself is baseline compliant. But, you yourself can create and deploy an app that breaks compliance, just like you can on-prem. Azure Functions are by nature stateless, but there's little stopping you, the developer, form persisting data in a non-compliant way.
If one is hosting an healthcare application(For me its ASP.NET MVC and going to host it in Azure cloud service) which needs to be HIPAA compliance, then encryption is required in 2 aspects:
data in motion; and
data at rest.
Upon searching various locations one comes to the conclusion that the data at rest is taken care by using TDE (transparent data encryption), and data in motion is taken care by SSL.
So is there no need to use any encryption/decryption logic from my end?
That's a tough question to be honest, and I'm afraid the answer is a little open ended. The certifications that Microsoft have for the Azure platform certifies the fabric and the platform services in your instance as HIPPA compliant.
Any service you build on the Azure platform also needs to meet that compliance so it is your responsibility to ensure that compliance is met. While I can provide you that level of detail you would need to verify your solution with someone who is an expert in HIPPA compliance.
I am creating an azure based application that must be pci compliant. There is an understanding within my company that to meet this compliancy any personally identifiable information (PII) should be stored encrypted.
I have a number of questions.
Is it true that pci compliance means encrypting PII within the data store?
What are my options with this on Azure?
I would like to be storing data in documentdb as this would be the closest match to the format of the data within the application. Most of the data is document based and json. Would this meet the PCI compliance standards?
Does it make a difference if the data store that contains payment and card info is different to that containing the PII?
The question regarding what PCI compliance requires is best directed to your organization's compliance officer. They are the one that will ultimately have to "sign off" on your solution so they control the specifications you're working towards.
As for what your options are, mfanto pointed out the SQL support for the new tiers. There's also Azure Storage which now has encryption extensions. Document DB doesn't have anything yet to my knowledge. And if you're running your own database, Windows VMs have had support for bitlocker drive encryption on data drives for some time now.
While the sample uses local files, it should be noted that Azure Encryption Extensions supports streams as well for all upload/download methods - and nothing is ever written to disk (streams are encrypted/decrypted on the fly).
UploadFromStreamEncrypted(...)
DownloadToStreamEncrypted(...)
https://github.com/stefangordon/azure-encryption-extensions/blob/master/AzureEncryptionExtensionsTests/FunctionalTests.cs#L107
Cosmos DB (formerly DocumentDB) now supports encryption-at-rest. It is enabled by default in every region. There is no impact to cost or performance SLA. Note: The local emulator does not support encryption-at-rest (though the emulator is only for dev/test purposes).
As far as compliance goes, you'll need to talk with a compliance/legal expert for that.
For more info on Cosmos DB encryption-at-rest, see this post.
I am having a hard time understanding Windows Azure service bus and access control concepts. In layman's terms, what are they? What are they used for?
The Service Bus component of Windows Azure is meant to handle the problems arising from services that are living in multiple networks. Basically, a service bus just makes it appear as if your code is running on a single machine, while in reality it could be running anywhere within the Azure datacenters.
Access Control lets you use "federated authentication for your service based on a claim-based RESTful model. (Sorry, copy&Paste from an O'Reilly book about Azure!)
Basically, when you create an Azure site, application or service, it could be running on any of the thousands of systems within the datacenter. And each of those systems has it's own IP address, it's own network, memory, processor and whatever more. To let them collaborate and to appear as a single system, these two services have been created.
If you want to learn more about Azure, this would be a good moment to buy a book! :-)
Azure is quite complex and service buses and access control are a bit more advanced topics.
Service Bus is a solution for the integration between multiple applications whether they are hosted on the same infrastructure or even spread along multiple infrastructure or/and Cloud Computing provider. If you search more in the internet you might find a lot about EAI (Enterprise application integration) here is my blog post about this topic:
http://hhaggan.wordpress.com/2013/03/07/introduction-to-enterprise-application-integration-eai/
and here another that I hope that helps you understand better what is the service bus:
http://hhaggan.wordpress.com/2013/03/09/introducing-service-bus/
in another words, it is a messaging platform that helps you communicate with multiple applications, softwares or services no matter what programming language they are written with or on which os or platform they are hosted on. you will feel its effect specially when you work on connecting multiple nodes together, I don't mean 5 or 6 nodes but 10 and above.
Certainly there are several types of service bus, whether they are based on relayed messaging service or brokered messaging service, each one of them has several uses, its purpose and way of working.
For the Access control, this is so easy, it is a way of authentication and authorization for your application using third parties, It is a claim based identity that you can do the required authentication through the third party database. you wont need to build everything from scratch in your database. this helps a lot during development and I believe that this can help a lot in social media marketing and branding because of the use of facebook, twitter during the authentication.