Lessons Learned Building Secure and Compliant solutions in Windows Azure

In July I  decided to create a series of 3 posts about this topic. Those 3 posts are be:

In this post I’ll be focusing on the last part, which are the lessons learned.

Quick Concepts

When we think about compliance and security there are two concepts we need to consider and master. Those concepts are Data in Transit and Data at Rest. But what is this all about?

Data at Rest

This refers to inactive data which is stored physically in any digital form (e.g. databases , data warehouses, spreadsheets, archives, tapes, off-site backups, mobile devices etc.). In addition, subsets of data can often be found in log files, application files, configuration files, and many other places.

Basically you can think of this as data which is stored on a place which will be able to be retrieved even in case of a restart.

Data in Transit

This is commonly delineated into two primary categories:

  • Data that is moving across public or “untrusted” networks such as the Internet,
  • Data that is moving within the confines of private networks such as corporate Local Area Networks (LANs)

When working in with compliant solutions you always need to have this two in consideration because those will be the two topics that the compliances will focus on.

Lessons Learned

In order to make sure that the solution is “acceptable” from a Data Privacy & Compliance aspect I normally use the following process, that I would like to share with you.

  1. Perform an assessment on the organizational structure in order to understand all the information of where the business is being conducted, and which laws and compliances apply.
    • This is extremely important because if we work the Betting & Gaming industry we might find that they are located in one place but have their gateways on a different one, like Malta, Gibraltar and so on. By understanding this we will be able to understand exactly which compliances should be followed and which ones we should ignore.
    • The same thing applies for example to the Healthcare industry where you have HIPPA compliance but which is important to understand where the company that builds the product is, as well as doing the same for their customers, since different countries will have different compliance requirements.
  2. Understand which countries both the customer and software vendor is located. This will help understand which rules apply to that specific organization and plan for that.
  3. Identify the specific data you need to encrypt or you need to avoid moving into the cloud because of compliance issues.
    • This is an extremely complex exercise because you can’t say on a high level that all the data can or can’t go to the cloud, you need to dig into the compliance and understand exactly which fields can’t be.
    • For example, in the Healthcare industry you have HIPPA compliance which you have to comply with, but you also have to work with both PII (Personal Identifiable Information) and PHI (Personal Health Information), which can’t be in the Cloud at this stage. So normally you hear people saying immediately that this application cannot move into the cloud. That isn’t actually true. If you go and analyze the PHI and PII details you will see that the health information can be anywhere as long as it is not possible to match to which person that information is related to. If you look at it, this isn’t actually that hard to do. You can anonymize the data and place “Patient A” and the full health history in the cloud, do the necessary processing and then just send the information back to on-premises where you have a small table that correlates “Patient A” with the real patient information so doctors can work with.
  4. After understanding everything that is required in terms of requirements and compliances which are applicable to the solution, you need to look at where your Data at Rest is currently being stored inside your customer data center.
    • Databases
    • File Servers
    • Email Systems
    • Backup Media
    • NAS
  5. Now you should locate your Data in Transit across the network channels both internal and external. You should:
    • Assess the data trajectory
    • Assess how data is being transferred between the different elements of the network
  6. Decide how to handle Sensitive Data. There are several options you might take to handle this data.
    • Eradication
    • Obfuscation/Anonymization
    • Encryption
    • Note: Normally we go more with the Encryption option but anonymization is also really important and in some cases the only way to go. For example look at the PII and PHI. Anonymization would be the way to go there.


If you follow this simple process you will definitely be successful identifying what needs to be handles and how it needs to be handle and make your compliant solutions able to be moved to Windows Azure.

Hope this helps and please share your feedback so I can better target the posts.

Introduction to Windows Azure Compliance

In July I  decided to create a series of 3 posts about this topic. Those 3 posts are be:

In this post I’ll be focusing on the Windows Azure compliance part.
Introduction to Windows Azure Compliance

Compliance is extremely important when moving/building solutions to the cloud for two main reasons. First because it will provide us with with an understanding of the type of infrastructure that is underneath the cloud offering. Secondly because there are several different solutions and companies which require specific compliances in order to be approved for deployment.

In order to achieve this Windows Azure Infrastructure provides the following compliances:


ISO/IEC 27001:2005

Specifies a management system that is intended to bring information security under explicit management control” by Wikipedia. More information here.

This is extremely important because it provides us a clear information about how secure our data will be inside Windows Azure.

SSAE 16/ISAE 3402 SOC 1, 2 and 3

“Enhancement to the current standard for Reporting on Controls at a Service Organization, the SAS70. The changes made to the standard will bring your company, and the rest of the companies in the US, up to date with new international service organization reporting standards, the ISAE 3402 by SSAE-16.com. More information here.

Extremely important to understand that Windows Azure is audited and has to follow strict rules un terms of reporting to make it compliance. This give us a view that everything has a specific process that needs to be followed.


“The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted as part of the American Recovery and Reinvestment Act of 2009, was signed into law on February 17, 2009, to promote the adoption and meaningful use of health information technology.” by hhs.gov. More information here.

By having this HIPPA compliance it means that solutions for the healthcare industry can be delivered in Windows Azure because the underlying infrastructure is already HIPPA compliant. This doesn’t mean that anything we do now is HIPPA compliant, it just means that Windows Azure can be used to deploy the solution, but the solution still needs to comply with the rest of the HIPPA compliance, mainly the software compliance part.

PCI Data Security Standard Certification

Created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually — by an external Qualified Security Assessor (QSA) that creates a Report on Compliance (ROC)[1] for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.[2]” by Wikipedia. More information here.

This doesn’t mean that we can deploy PCI compliant solution in Windows Azure, because this certification is only for the way Windows Azure uses to accept payment, and not for allowing 3rd party applications.

FISMA Certification and Accreditation

Assigns specific responsibilities to federal agencies, the National Institute of Standards and Technology (NIST) and the Office of Management and Budget (OMB) in order to strengthen information system security. In particular, FISMA requires the head of each agency to implement policies and procedures to cost-effectively reduce information technology security risks to an acceptable level.[2]

According to FISMA, the term information security means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide integrity, confidentiality and availability.” by Wikipedia. More information here.

Windows Azure Compliance Roadmap

But Windows Azure has other compliances and so here is the complete roadmap.



What all this means if that Windows Azure is a secure and highly compliant option, which will allow us to leverage the Cloud on several different occasions.

The Windows Azure team has a Trust Center which will give you all the information about Security, Privacy and Compliance.

Hope this clears a bit your view about the compliances behind Windows Azure.