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.
Related
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.
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.
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.
Has anyone seen details or a White paper on azure security and the positives and negatives compared to your own hosting?
Securing Microsoft's Cloud Infrastructure
Security Mental Model for Azure
Cloud Security Frame
Outlook for Azure – scattered clouds but generally sunny
Security Considerations for Client and Cloud Applications
abmv has a full set of links.
Just wanted to add one point: The azure platform is highly automated, so there are very few manuall operations, at least compared with the hosting companies I have seen. This reduces the chance of security problems due to human error, forgetting a configuration setting for example.
Azure security whitepapers are available at the Azure Trust Center: http://azure.microsoft.com/en-us/support/trust-center/security/
This is also a helpful document for Security Best Practices for Azure Solutions: http://download.microsoft.com/download/7/8/A/78AB795A-8A5B-48B0-9422-FDDEEE8F70C1/SecurityBestPracticesForWindowsAzureSolutionsFeb2014.docx
In practice, many customers choose to mix several compute types in their cloud environment, as certain models may apply better to different tasks; multiple cloud services, virtual machines, and Web Sites can all work in conjunction. The pros and cons of each should be weighed when making architectural decisions.
There is great potential and promise for the cloud, but those looking to adopt cloud computing are understandably nervous and excited about the business prospects. Customers are excited about reducing capital costs, divesting themselves of infrastructure management, and taking advantage of the agility delivered by on-demand provisioning of cloud-based assets. However, IT architects are also concerned about the risks of cloud computing if the environment and applications are not properly secured, and also the loss of direct control over the environment for which they will still be held responsible. Thus, any cloud platform must mitigate risk to customers as much as possible, but it is also incumbent on the subscriber to work within the cloud platform to implement best practices as they would for on-premises solutions.
Moving to a cloud platform is ultimately a question of trust vs. control. With the Infrastructure-as-a-Service (IaaS) model, the customer places trust in the cloud provider for managing and maintaining hardware. The cloud provider secures the network, but the customer must secure the host and the applications. However, for Platform-as-a-Service (PaaS), the customer gives further control of the host, the network, and runtime components. Thus, the cloud vendor would be responsible for ensuring that the host and runtime are properly secured from threats. In both cases, the customer would be responsible for securing applications and data (e.g., authentication, authorization, configuration management, cryptography, exception management, input validation, session management, communication, audit and logging).
Software as a Service (SaaS) presents one further level of abstraction. In this case, the cloud provider manages all levels of the stack all the way up to the application. Customers provide configuration information and sometimes high level code, but that is the end of their responsibility.
Generally, traditional threats will continue to exist in the cloud, such as cross-site scripting (XSS) or code injection attacks, Denial-of-Service (DOS) attacks, or credential guessing attacks. Some old threats are mitigated, since patching may be automated (for Platform-as-a-Service, or PaaS, only), and cloud resiliency improves failover across a service. Some threats are expanded, such as those concerning data privacy (location and segregation) and privileged access. New threats are introduced, such as new privilege escalation attacks (VM to host, or VM to VM), jail-breaking the VM boundary or hyper-jacking (a rootkit attack on the host or VM). Microsoft has taken extraordinary measures to protect Azure against those classes of threats.
Worth also checking into the Azure Security Information Site - we'll be adding a lot more dev-centric security content there in this calendar year https://aka.ms/AzureSecInfo