Security is one of (if not THE) top concern companies and users have with cloud computing. The issue of cloud security, however, is much more complex than simply “is the cloud secure or not”. A cloud-based application can be hosted in a secure environment, with properly encrypted data and everything, and an attacker can still get access to your information through social engineering. On the other hand, you can have the most secure password policies in the world, but if the hosting environment gets hacked, you are still going to lose your data.
Any proper solution that tries to address the cloud security issues that exist today must take into account the three sides of the security issue: technology, processes, and responsibility. Another important factor to take into account is that the details and the importance of each one of these, relative to the others, change according to where in the cloud stack we are. Building secure cloud software is very different from security at the cloud platform level, and from secure infrastructure as well.
The first step is to employ the proper technology to secure applications and data. “Proper technology” varies widely depending on what layer of the cloud we are talking about. For cloud applications, security can be as simple as deploying proper security certificates and encryption. All sensitive information needs to be properly encrypted, so that even if an attacker gains access to your systems, any data that gets stolen will still need to be decrypted to be gotten at. And it’s not enough to simply encrypt passwords: if you know that people commonly employ their birthdays as passwords, encrypt that as well. As much as possible, technology should protect users from themselves without inconveniencing them.
A very interesting solution in this space is Porticor’s Virtual Private Data. It’s basically an encryption layer that sits transparently on top of any cloud data store, performing dynamic data encryption/decryption as data gets accessed. I recommend that anyone interested in securing cloud applications take a look at their solution.
On the lower layers of the cloud stack, security is much the same as it was before the cloud. Cloud platforms need to be secure just as operating systems are secured, avoiding malicious code from taking over other execution sessions or stealing data, and so on. In the infrastructure layer, security is both about maintaining a secure virtualization environment and about physical security. Fortunately, most top-tier cloud infrastructure providers already are very security minded, reducing risks on this side.
All the technology in the world can’t save you if an attacker can call your receptionist and get her to install malware on your corporate network using her network administrator password. This is as true for the cloud as it is for private networks, and while something like this probably wouldn’t happen at a large enterprise, there is a surprisingly large number of small- and medium-size businesses where it just might.
If a company is deploying a Windows cloud server from Rackspace, for instance, it will come with a pretty complex password, automatic updates enabled, firewall-activated, and so on. Many times, though, the first step that people take is to change the password to something easier to remember – usually “password”, or “Pass1234” because a secure password must always include capital letters and numbers – and create an unprotected FTP tunnel to that server, “just to copy a few things”. What started as a reasonably secure server is now a security breach waiting to happen. It’s not enough to have the proper security tools. Companies need to build processes that actually put those tools to use.
Companies also underestimate the power of having proper information security policies communicated to all employees. When everyone in the company is security conscious, proper security comes much easier. The process side of security doesn’t start with technical processes, but with people, so proper and constant communication is fundamental.
So far, the two aspects we explored are pretty standard. While cloud applications need to be much more security conscious than traditional in-house applications, the technology needed to deploy the extra security is pretty standard. The same thing goes for securing cloud servers. The greatest differences between cloud security and traditional security lie in the matter of responsibility.
When a company deploys traditional software, IT knows its responsibilities. The software is inside the data centers it operates and controls, and anything that happens – data being stolen, servers being hacked, and so on – is their responsibility. Since IT has full control over the environment, they are comfortable with taking on the burdens that come with this control.
When things are moved to the cloud, however, IT departments lose control over the environment. It is understandable, then, that they are unwilling to take responsibility for problems that might happen. Having clearly separated responsibilities helps: hosting providers need to ensure the security of the underlying platform (virtualization layer, physical security, and so on). The rest would fall to the customers. But it is not enough. Providers need to offer guarantees in case something happens, and understand where internal IT departments are coming from, to improve relations and reduce their concerns.
These three perspectives need to be taken into account together, or we run the risk of creating an even more complex environment than what already exists. In some ways, the cloud has the potential to make things more secure, by providing incentives or automating the management of common security tasks that many small businesses forget about. On the other hand, the concentration of data in the hands of a few service providers can make for very attractive targets, increasing the responsibility of these companies. No technology, process, or contract can, alone, remove the security concerns over the cloud; and everyone that has concerns about the cloud should look at the whole security package, and not technology or processes alone.