We recently had a discussion with a financial services company which had several concerns about moving to the cloud. But surprisingly, these concerns did not come from the technical staff, but rather their business leaders. "I just don't trust it" was the statement from one of their executives. So, this article is for all those business executives that are being pitched a move to the cloud, but feel uneasy about it.
"I don't like the idea of giving somebody else our data"
I've struggled over the years to describe data's nature in a way that is understandable. Data has properties that we can't easily attribute to other areas. For example, you can make a perfect copy of your data almost instantly. Additionally, you can move data from one place to another in a way that can't be replicated with most physical objects. However, data must live somewhere. Traditionally, we've written checks to Dell, IBM, & HP for their server hardware, and Oracle for the privilege of using their database software to house and organize the data. These are the blade servers would get trucked in and set up inside your data center.
Let's talk about that data center for a moment. This is usually a leased building full of servers housing your organizations software and data which keep your company's processes moving. Normally there is also a secondary building somewhere else in the nation which backs up and provides disaster recovery capabilities. The fact that the building might be leased by your company isn't what makes the data "yours". What makes the data yours is that it all lives under the same secure firewall. Remember, data can be copied instantly and moved very easily, so its physical location is not what makes the data yours. It's all about the firewalls and encryption. You may then ask,
"What about the people working at the data center?"
On the business side of the house, we often lump the IT Data Center into one big mass of people. But intuitively, we know there are critical roles which break down the workload of managing the data center. For example, the management of security and the management of server up-time are two very different roles. The person managing security is in charge of ensuring that the data is yours, and stays yours. Whereas the person managing the servers and their up-time is focused on reliability and availability of data by ensuring their hardware is highly available and backed up by other hardware.
Well it turns out that when you move to the cloud you're still going to need a person managing security to ensure that the data is "yours." (ie. encrypted in motion and at rest etc.) In my opinion, this person should be someone employed by your organization so they have skin in the game. The role that the cloud is offloading is the server up-time role. Now I'm not saying that people managing servers don't have to be focused on security. There are entire protocols for ensuring that physical safety of the servers themselves. To the extent that your organization follows those protocols I highly doubt you are as physically secure as Amazon, Google, or Microsoft's data centers. Additionally, as long as your data is encrypted at rest, it would be quite difficult to physically steal a hard drive and do anything useful with it. This is the case both with an internally owned data center or any other.
"I think that the cloud vendors just have a giant target on their backs"
At first glance, I would agree with this sentiment. If I was a hacker, I would be looking for large targets. So why haven't swaths of Amazon customers been hacked? Individual hacks do occur, yes, but why hasn't there been a hack that impacts all the customers at once? This gets back to the nature of data ownership being tied to who manages the security and not physical location. Since the security is managed by each company separately there isn't one place to hack. However, this is only half of the equation. Because the cloud enables servers to be dynamically allocated, companies can achieve an even smaller physical presence which is harder for hackers to find.
This requires a little bit explanation... There are 2 ways of adopting the cloud:
- Treat it like a rented data center: This is the traditional "lift and shift" approach of taking what you have in the data center and replacing it with a cloud vendor. If you're treating your cloud vendor like a rented data center, then you're probably not going to save much money by moving to the cloud. You'll mostly enjoy the operational benefit of not having to manage the physical allocation of servers. (which is no small thing) However, outside of that, the experience is very similar to owning your own data center, and that includes from a security perspective. So, the "target on your back" is the same as the one you had in your data centers. (with the exception of very tight physical security provided by Amazon, Microsoft, and Google) So if you're incompetent in managing firewall/encryption security in your data center, you'll probably be no better off in the cloud.
- Refactor your applications to leverage the cloud's capacity to use compute resources on demand: Imagine this. Let's say you have a call center application that retrieves customer records of people calling. In the cloud you could kick off that application as a service. This means that the allocation of hardware and compute resources are only used when the agent receives a call. Not only does your cloud footprint become tiny, but your application is much harder to hack. This is because there is no persistent application that's "always on" like you would have in a traditional data center. From a hacker's perspective this is incredibly annoying, as it's much easier to hack a persistent server with a consistent location than a service with no dedicated hardware. So, when an application is refactored the tables are turned on who has the "target on their back". Indeed, the one with the giant target on their back are the organizations with consistent application servers and a giant firewall to penetrate.
So, on your road to cloud adoption there needs to be a two-pronged strategy. One is the traditional "lift and shift." This gets the data to the cloud, provides parody to the data centers capabilities and brings a host of efficiencies. However, the second prong of refactoring needs to be planned on the coat tails of the lift and shift effort. This is how you will not only obtain parody to the "target on the back" concern, but actually make your organization a smaller target.
If you fear it, try a small project
I'm personally a big fan of learning by tinkering. Moving to the cloud doesn't have to be a mandate from the ivory tower. There are plenty of applications which are already well suited and have tremendously capable services in the cloud. Once such area is Data Warehousing and Business Intelligence. These two categories have solutions that are more capable than their on-premise counterparts and are cheaper to deploy. Additionally, they leverage the clouds capacity to elastically allocate hardware. If you would like help in identifying a project you can take to the cloud, I recommend you reach out to Intricity and talk with a specialist.
