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.
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.
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.
- 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.
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. Identify the specific data you need to encrypt or you need to avoid moving into the cloud because of compliance issues.
- 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.
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.
- 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.
Now you should locate your Data in Transit across the network channels both internal and external. You should:
- File Servers
- Email Systems
- Backup Media
Decide how to handle Sensitive Data. There are several options you might take to handle this data.
- Assess the data trajectory
- Assess how data is being transferred between the different elements of the network
- 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.