Is cloud security all about emotional marketing?

I still find it interesting that when I mention “hardware security” to someone, my “pitch” is over, done, finished. Like if no-one realized that every cloud needs physical servers to run on. Everything cloud is marketed as “secure”, but are we really in control of our data?

Private Space – virtual LAN in the internet.

When you read any of the surveys about the cloud adoption there will be a section about risks. The chances are that “security” and “risk of implementing changes” will be in top 3. The risk of changes is the main reason why large companies are much more likely to implement new applications in the cloud, but migrate of existing systems rarely happens.

Regarding security – I’m not sure any two people mean the same thing. Also, some say there are two types of people and companies: a) they care as little as they are allowed to, b) they are very particular. Is it really so? Please do comment, I’d like to hear your say!

Cloud v cabinet

The security aspect is a tricky one. There is nothing better than to lock a door and hide the key in your desk. It is simple, but is it really secure? To properly answer this question, one has to look at a great deal more beyond that drawer, but emotionally we simply like the idea of a locked drawer.

Still, when I mention “hardware, cloud security”, it seems to be an ultimate mood killer. What I mean is something you can touch, you know where it is. We just seem to strongly associate “hardware” with a server cabinet not the cloud, i.e., we need to have the key in our drawers somewhere.

I am not sure that cloud security will ever be able create the same level of emotional attachment even if its objective security is better. The difference is in “control” and the limitation of “transitive trust”.

Still, a question about security is the question everyone will ask and cloud service companies had to come up with good answers.

Try our free certificate monitoring tool with spot certificate (HTTPS/TLS/SSL) validator KEYCHEST.NET – it checks validity, completeness of the validation chain, HSTS, or server downtime over last 2 years. Give us thumbs up!

Hardware v Cloud

Good managers and leaders have high emotional intelligence. They are also much more likely to embrace change compared to employees. My point is that if you want to sell a security, it really helps if you create an emotional argument. I believe that’s why blockchain, or quantum encryption companies will be more successful to sell their technology, as they are representing emotionally attractive propositions.

Having a “box” in the cloud is not in the same category even though all that is cloud needs hardware to run on. While some platforms (e.g., OpenStack) are truly elastic, some others only allow you to launch new virtual servers, but each of them is a resource with a limited set of resources.

Is this security good?

The security industry has put a lot of effort into security validations, frameworks, and certifications. Still, most people are not able to tell “snake oil” from well designed security. Security validations are impenetrable to non-experts and expert opinions are not quite statements “under oath”.

Cloud providers have spent years improving their marketing pitches and these don’t have to follow those frameworks. Even better, most cloud applications just need to show they are “compliant” and there is a difference between “compliant” and “validated”.

Here’s an example of a perfectly correct statement:

With <our service>, customers get the benefit of their keys stored in a hardware security appliance without the need to manage the underlying appliance themselves. In <our service>, customers create policies to grant users and applications access, giving them control of who can access the data.

What it doesn’t say is:

When customers need those keys, they will be decrypted in our platform. This means that we will have to disclose customers’ keys to third parties if we obtain a lawful request. We may not be able to tell you that this happened.

 Trusted Path

The above is an inherent property of cloud platforms, i.e., having someone else managing your data or secrets (i.e., keys). As the cloud platform provides an environment for all cloud services, it’s hard to establish a “trusted path” between a cloud storage and your applications. The main purpose of the trusted path is to prevent “man in the middle”. It is a situation, when someone else can listen to or even change data between its origin and destination.

The methods  to prevent “man in the middle” situations is:

  1. out-of-band communication;
  2. dual-channel communication; or
  3. direct physical connection.

All of those methods are fundamentally anti-cloud, as they break the simplicity of getting resources when needed. It is much harder to say you need a resource, when you have to use two different communication channels.

Downsides of public cloud

I absolutely believe that it’s in the cloud providers’ best interests to protect their customers’ data. I also believe that the vast majority of applications can be run in public clouds.

There are, however, four aspects we should always consider:

  1. You can’t promise your customers that you have “sole control” over their data. There is a third-party (the cloud provider) that is supposed to provide the trusted path and customers’ data can be accessed (lawfully or as a result of a cyber attack) through this third-party.
  2. Virtualization is what it says on the tin – you use a computer shared by many different cloud users and while cloud platforms will try to separate your data, there will always be a risk of bad guys defeating this separation.
  3. In terms of security, you get exactly what you’re told, but very little beyond that. I believe you should always use your common sense and ask simple questions. Where is my data at a certain time? How does it get from A to B? Are there any gaps en route?
  4. Cloud providers are unlikely to take any liability for attacks and damage resulting from these attacks.  Cloud providers take responsibility for the security of their platform, but that’s not quite the same as liability for losses and costs.

Published by

Dan Cvrcek

Founder and CEO of Enigma Bridge, engineer, entrepreneur, cryptography SME, security architect, and professor.