Why cloud has not taken off in the enterprises?

Given all the hypes around cloud computing, it is surprising that there is only scant evidence that cloud has taken off in the enterprise. Sure, there is salesforce.com, but I am more referring to the infrastructure cloud, such as Amazon, or even Microsoft Azure and Google App Engine. Why have not it taken off? I have heard various theories, and I also have some of my own. I list them in the following. Please feel free to chime in if I miss anything.

  • I am using it but I do not want you to know. Cloud is different from previous technologies that it is not a top-down adoption (e.g., mandated by the CIO), but rather a bottom-up adoption where engineers are fed up with the CIO and want a way around. I have heard various companies using Amazon extensively, particularly in life sciences and financial sector, where there is a greater demand for more computation power. In one case, I have heard a hedge fund company who rents 3,000 EC2 servers every night to crunch through the numbers. Even though they use cloud, they do not want to generate unnecessary attention to invite questions from upper management and CIOs, because cloud is still not an approved technology and putting any data outside of the firewall is still questionable.
  • Security. Even if the CIO wants to use the cloud, security is always a major hurdle to get around. I have been involved in such a situation. Before using cloud, it has to be officially approved by the cyber security team; however, the cyber security team has every incentive to disapprove it because moving data outside the firewall exposes them to additional risks that they have to be responsible for. In the case I was involved in, the cyber security team came up with a long list of requirements that, in the end, we found that some of their internal applications do not even meet. Needlessly to say that the project I was involved in was not a go, even with a strong push from the project team.
  • Redemptification. CIOs have to cover themselves too. Most cloud vendors’, including Amazon’s, license term disclaims all liabilities should lose or failure happens. This is very different from the traditional hosting model, where the hosting provider claims responsibility in writing. CIOs have to be able to balance the risk. A redemptification clause in the contract is like an insurance policy, and few CIOs want to take the responsibility for something they do not control.
  • Small portion of cost. Infrastructure cost is only a small portion of the IT cost, especially for capital rich companies. I heard from one company that their infrastructure cost is < 20% of the budget, and the bulk of the budget is spent on application development and maintenance. For them, finding a way to reduce application cost is the key. For startups, cloud makes a lot of sense. However, for enterprises, cloud may not be the top priority. To make matters worse, porting applications to the cloud tends to require the application to be re-architected and re-written, causing the application development cost to go even higher.
  • Management. CIOs need to be in control. Having every employee pulling out their credit card to provision for compute resources is not ok. Who is going to control the budget? Who will ensure data is secured properly? Who can reclaim the data when the employee leaves the company? Existing cloud management tools simply do not meet enterprises’ governance requirements.

Knowing the reasons is only half of the battle. At Accenture Labs, we are working on solutions, often in partnership with cloud vendors, to address cloud shortcomings. I am confident that, in a few years, the barrier to adoption in enterprises would be much lower.

Cloud is more secure than your own data center

I have given many Cloud Computing presentations to our clients in the past year. Everyone is interested, but all are concerned that the Cloud is not secure. My answer to them is that the Cloud, at least the Amazon Cloud, is more secure than your own data center. There are two reasons that Amazon Cloud is more secure.

The first reason is that Amazon gives you greater, instant control on your firewall settings. In our current IT infrastructure, we may have one firewall for the whole organization, or one for each division at best, and this firewall is controlled by some central IT guy. There are three problems associated with the current architecture. First of all, the firewall only protects you from people outside of your organization. The firewall is ineffective if the guy in the next cubicle decides to attack you or if his laptop is infected with virus. The second problem is that you do not have visibility into the firewall settings. A port could be left open for the hackers to exploit, but since you do not know, you would not have put in the necessary counter-measures. The third problem is that you could not easily change the security settings when deemed necessary. For example, you found a security hole, and you want to block future exploits. But you have to submit a form to IT to request firewall changes and it takes at least a week to implement the change. Meanwhile, your application remains vulnerable.

In contrast, Amazon gives you as many security groups (their term for their software-based firewall) as you want, and as the application owner, you have direct control on their settings. You can take advantage of security groups to have fine grain security control even at the application component level. For example, let us consider a simple two tier intranet application which has several application servers and one database server. We will create two security groups called “appserver” and “dbserver” respectively. By default, all accesses are off, and you have to explicitly enable permissions for each security group. We will add one rule to the “appserver” security group which says that only people from your IP range (e.g.,  x.y.x.w/24) can access port 80. Then we will add another rule to the “dbserver” security group which says that only those in the “appserver” security group can access. Once you set up the rules, you can fire up the application servers in the “appserver” security group, and then the database server in the “dbserver” security group. Now people from your organization can access your application as your designed, but a hacker has to go through extra hoops to get to your database. First, a hacker has to gain access to a server in your intranet, from there, he can only exploit port 80 to gain access to the application servers. Even if he is successful, he still has to gain access to the database server through the “appserver” group because that is the only one enabled to talk to the “dbserver” group. The chance of hacking open one machine is low already, the probability that one can hack all three open, in sequence, is essentially zero.

The second reason that Amazon is secure is that they have disabled all layer 2 functionalities. These layer 2 functionalities are the key to enable many security exploits. For example, you cannot fake your IP address from an Amazon server. If you send packets with a source IP address that is different from the one you are assigned, the packets are simply dropped by the hypervisor. Also, if you enable “prosmiscuous” mode to snoop traffic on the network, it is simply ineffective. Lastly, if you ARP for any IP address trying to find out who is nearby, you always get back the gateway’s MAC address, so you would not be able to know who is sitting in the same subnet.

Obviously, I am not alone at saying that Cloud is secure. Check out Gnucitizen for example.

Cloud is more secure than your own hard disk

I had several feedbacks from my last post on the Outlook Attachment Remover from my colleagues. The number one response is: “Do not put our client’s data there, even if encrypted, it is against the policy”. In this post, I will discuss why Cloud is secure and what a sensible company policy should be.

When CIO gives us the company laptop, we promise to take full responsibility for it. We are expected to set a strong password so that no one can logon to our machine, and we are expected to lock our screen whenever we are away. When clients send us their confidential data, they expect us to secure it in areas where only we have access to. We do not need client permission to store the data on our hard drive because we have promised to our CIO and our clients that we will guard our laptop and hard drive.

When we request a bucket from Amazon S3, the bucket, by default, is readable/writable by us only. Similar to a password, our access to the bucket is guarded by our Amazon credential, which includes both a 20 alpha-numerical characters of Access Key ID and a 40 alpha-numerical characters of Secret Access Key. We promise to keep the Keys to ourselves and Amazon promises the access right works as designed. So, just like our hard disk, the bucket is ours and ours alone. Why should not we be able to store our and client data there? Why do we need client permission?

As much as we promise, accidents do happen. Our laptop could be infected with virus and Trojan horses, we could lose our laptops, Amazon security could be breached. In the past year alone, I know at least two incidents where our company laptops were stolen. In contrast, I have not heard ANY S3 security breach since they launched their service three years ago. It is a more dramatic contrast than you think because S3 has millions of customers and it hosts 29 billion objects, whereas, our company has much fewer employees and far fewer number of laptops. So, is our hard disk more secure than S3?

Since no one can say their system is 100% secure, we have to put in measures to guard against the rare events. Our company laptop has encryption software installed. When the laptop is lost, we are safe because no one can read the data.

 Now, if I encrypt my email attachments, including client data, and put them in my own S3 bucket that is readable/writable by me only, and hold on to the password to myself, why would I need client permission? Why is it not secure? Why is it against the company’s policy? If anything, based on the past track record, CIO should ban us from storing data on our hard drive instead.