Legalities Over the Cloud and Who Owns your Data

When trying to figure out who has rights to your data there are three things to consider: you, the cloud provider, and the region your data is held in. A lot of the issues become issues because of the varying laws; where your data is held might be in different country than the country you uploaded from. So, even after you figure out what your agreement is with a Cloud provider they can be subject to the particular laws of another country; fore instance America has a set of laws known as the Patriot Act which grants the US government access under certain conditions. So even after you figure out who owns the data, and what that means, you might not have control over who is accessing the data.

When you decide on a Cloud provider there are a number of things that you want to look at. One of them being the terms of service that will, most likely, define how a provider views your data, and what they can do with it. The terms of service will be restricted by your regions governing principles. Fore-instance in England they have the ‘Copyright and Rights in Databases Regulations 1997’ to help clear up some of the vagaries of this new technological development. The law defines two types of data one that is protected by copyright law, and ones that aren’t but are still regulated in their way. The existence of the law is a step in the right direction towards clarifying ownership of the information that is being stored in the Cloud.

Although to confuse this issue even further is the fact that some of your information may be stored in your own database but you are using a Cloud service to handle it from time to time. Or your Cloud provider is servicing out to another Cloud provider; so they may host your information in a storage unit that isn’t their own. Each of these situations has unique problems and each part of this chain of concerns depends on user agreements and the particular governing bodies. So there is no single solution to answer the question of who owns your data, and as this issue becomes generally understood hopefully we will see some best practices winning out. Although I wouldn’t necessarily say there is no way to find out. There are some things that can be done to better understand what is happening. Unfortunately one of those things is reading over all your relevant user agreements, and as one source claims it would take roughly 250 working hours to read all the user/privacy agreements most of us come across in one year. So you have to balance your need to know with your time, but be warned the details are important.

Understanding governing rules of where your data is being held or processed is not insignificant either. Each region is going to have its own governing rules about what happens when data is processed and the processing of the data may influence who owns the data now that it has been changed. So each step and movement of your data becomes an important issue to consider when deciding on a Cloud provider.

Who owns your data, then? It depends on the governing laws and user agreement made between you and the Cloud provider. It also depends upon the governing laws of where your data is being held, in addition to the agreements that your cloud provider may be making with their cloud provider. The Cloud has so much under the umbrella of Cloud services, that often one type of Cloud provider will outsource to another type of Cloud provider.

Cloud Security Concerns for Any Customer to Consider

For a Cloud customer there are primarily three questions you have to ask yourself:
– what cloud service I want;
– what security vulnerabilities does that cloud service have;
– and what can I do once I have chosen to limit those vulnerabilities.

A lot of vulnerabilities arise from a lack of knowledge. The Cloud service provider will connect their available network to you by way of a UI or API interface. So being informed will help you as a customer know how best to control your operation, and prevent loss or release of data.

A number of concerns arise when trying to secure your operations. Amongst the concerns one has to consider is what are you sharing on the Cloud service, how secure is the connection to the Cloud provider, and who has access to your operations and information. These questions can form the basis of an investigation into preventing future data failures from happening.

The most basic things you can do to prevent your information from being hacked is to use encrypted data; anything that goes over a network should be encrypted. Encryption is the lock on your information. Another important strategy is to use passwords, especially for any administrative duties, and change those passwords periodically. The problem is that in house employees will not want to memorize changing passwords, and passwords shouldn’t be in the cloud system itself. So a difficult balancing act becomes necessary and in order to juggle between protecting access to your Cloud data, and ease of use.

Another thing you can do to secure your system is to back everything up. In case of malicious or accidental removal, you will have that data stored elsewhere, and you most likely want to encrypt those backups for protection. Hackers can have a variety of reasons for attacking your Cloud provider or personal system, and some of those reasons involve removing your data from the web. So it is vital to create back-ups of important data.

Make use of the security updates your Cloud provider releases immediately; these security patches repair known flaws. If your provider has provided a patch, this means anyone who knows of the patch knows of the flaw in the system, and most likely some people knew of this flaw before you did. The key to good security is to be one-step ahead of everyone else, people trying to access your information are most likely going to go after the lowest hanging fruit.

According to the CSA, another important security concern to consider is the threat of malicious insiders. A malicious insider is someone who now has, or once had access, and now wishes to use that access in a way you don’t want. A malicious insider could be an ex-employee. One way to remedy circumstances is to have a fast turn over rate for security access when new employees are hired and old employees leave. You want to change access over from old employees to new ones immediately. Other measures you can take is to routinely track access to sensitive information. While I deplore over reaching efforts to snoop on employs, there is a balance that can be achieved by tracking access to particularly sensitive information and encryption keys or passwords.

The use of a Cloud service is fraught with new and old perils. While it is in many respects more secure handling your information yourself, its attractiveness as a target for an attack makes it vulnerable. So taking steps to ensure that you are able to limit security loopholes and working with your cloud provider is a good way to help ensure the security of sensitive information and data.

The Cloud Operators and Their Security Concerns

As a data operator of a Cloud service you will have many security concerns. Any new technology comes with a host of new threats to your business model, in particular the business of maintaining privacy in the digital world has become difficult. According to the CSA publication The treacherous 12, there are over 12 security threats to consider. Their article focuses on the 12 most pressing issues they have chosen, of which several of them are of particular concern. According to wikipedia the CSA puts Insecure interfaces and API’s at almost a third of the ‘cloud security outages’, and data loss and leakage make up to a quarter, with hardware failure being the third most troublesome issue.

Without going into great technical detail there are a variety of ways that an insecure API can result in loss or release of sensitive data. To simplify the situation it is about access, a multitude of individuals who now have controlled access. Every door though provides a weakness that walls do not have. Your API is a door into the server room, and a host of people all have their own doors. While most people only have access to their own portion of the server, the server can have bugs not known that give access to other parts of the room. Not to mention the fact that often a Cloud customer may give access to third parties to use the data on the Cloud.

Data loss can occur in a number of significant ways outside of malicious intentions. It is important to maintain backups in case of disaster. Any kind of disaster that destroys the actual hardware of the Cloud service is a possibility to keep in mind; though a client encrypting their information and forgetting the encryption code is a far more likely concern. It does not rest solely on the Cloud provider to prevent loss of information. While malicious intent does compromise most of the loss of data that could have been prevented, it is much more difficult to maintain good practices of protection against an intelligent intruder, over lets say the Customer forgetting their encryption key.

The Mitigation of data leakages involves many types of habits that a good Cloud provider must follow. There are a few types of applications that the Cloud provider can set up to mitigate data leaks from shared networks. It is important to keep in mind that the hardware a client is using could be used by a number of other customers. And this creates security vulnerabilities in the system itself that, even without malicious intent, can lead to outsiders having access to the clients data. Any program is going to have bugs, bugs are essentially problems in the code that wasn’t vetted for. This is going to happen with any program. The amount of code it takes to write a sophisticated program means that there are vulnerabilities that haven’t been thought through, or even discovered yet.

Vulnerabilities lie in loose links, and with so many links in the encryption process it becomes difficult to cover all your bases. It isn’t impossible, the important thing is to stay ahead of the curve. You want to be more secure than your neighbour to prevent vulnerabilities. But the facts are that the code itself is often hundreds of lines long, and to know every vulnerability in a chain that large becomes difficult, luckily finding cracks in the chain is also difficult for the hacker. But above and beyond the programming errors, which can be solved with frequent patches, is the human vulnerabilities and hardware failure.