Whether or not to put data into the cloud has been a debate since clouds were first formed. At a recent conference I was asked:
with all the security issues you brought up, why should I go to the cloud, I do not know the administrators, nor can I gain cloud visibility, so why go to the cloud at all? and if so which cloud?
There are a myriad of reasons to go to the cloud, not the least of which is politics or being told to go to the cloud. When the real question is:
which cloud services is my organization already using and how can I gain control over the data being placed into the cloud.
Nearly everyone I know is using a cloud some how, whether that is an App on a tablet or mobile phone, or such tools as Google Mail, Google Docs, Facebook, Dropbox, or Twitter. All of these use the cloud, but are you using them safely? This remains the question until a risk analysis has been done on these and other cloud services. So we really have two issues to discuss, green field cloud deployments and use of existing cloud services.
Which cloud, however, depends upon what your requirements are and what risk you are willing to assume and what risk you want the cloud provider to assume. After you review the clouds capabilities, the discussion ends up being about legal concerns regarding contracts and SLAs. The most important contractual issue is the right to audit, which implies you would have the right to audit the cloud against your compliance and security policies. Unless you can write the contract with the cloud provider (i.e. you are spending lots of money with them) cloud providers may not be willing to alter their agreements to include such language, this is where the CloudAudit.org initiative fits in.
I and others constantly mention that you should encrypt your data before it is entered into the cloud, however, not every cloud allows for such encryption, specifically tools such as twitter, Google+, and Facebook. These tools are by their very nature collaborative tools where the public can see what you write and place into these services. So you cannot easily encrypt these services and still have them useful, but you should be able to reduce the risk when using them. A good Data Loss Prevention (DLP) tool is in order. DLP tools will allow IT organizations to detect data that should not be placed into the cloud or any unauthorized location. DLP tools are a must, for organizations that want to use cloud services, to assert that personal identifiable information (PII) and other highly valued information is not sent to the cloud. Generally, DLP tools sit at the bastions to the internet and act as gateways to filter data and report on what could have leaked out.
Another major concern about going to the cloud is data protection and availability. If the cloud goes down, or closes its doors, is my data lost forever? or can I get it back someway? In this case, it is best to ensure the cloud in question has a proper backup mechanism. Even if it does, you will want to download your data, over an encrypted path, to a local data store.
Security and data protection within the cloud are your responsibility not the cloud providers, you have just offloaded the day to day maintenance of hardware, not the protection and integrity of your data.
So if you go to the cloud, ensure at least the following:
- You have the right to audit
- There is a way to get your data back out in case of failure
- You can extract your data at any time
- If you can encrypt, do so
- If you cannot encrypt, implement DLP to ensure no crucial data does not leak out, such as PII.
Before you can begin you need to first discover which clouds are in use, without your knowledge, by filtering firewall traffic to report on what is being accessed. This way you can determine what cloud services need improved security, data loss prevention, or data protection.
Share this Article:
Latest posts by Edward Haletky (see all)
- Continuous Integration, Deployment, and Testing - July 22, 2016
- Serverless: Business Plan or an Approach to Technology? - July 21, 2016
- Root Cause Analysis Is Not Dead - July 13, 2016