Security researchers announced this week that they had discovered a significant vulnerability in almost every computer on the planet. This vulnerability – actually two related ones called Meltdown and Spectre – allow a malicious application running on a computer to peek into the memory of another application on the same computer and suck out its contents. This is most devastating in public cloud environments where applications from different customers often end up running on the same physical computer.
Consider for a moment the scope of the risk involved. Enormous numbers of Internet applications now run on public cloud environments. Data present in any one of those could have been stolen. For an enterprise, this means that corporate secrets, financial results, source code, customer lists, embarrassing or incriminating conversations – anything stored in the cloud– might have gotten into the wrong hands. Though no attacks have actually been reported, the vulnerability has existed for a decade or more, and we may never know if it caused data compromise.
This is not the first time such attacks have been possible, nor is it likely to be the last.
The sheer scope and magnitude of this vulnerability makes it clear that traditional techniques for protecting cloud content are just not sufficient.
The traditional solution for protecting data in the cloud is known as encryption in transit and at rest. This is a solution born of the simpler days of client-server computing. In those days, enterprise applications looked like this:
There was a client, which would access some kind of server application over the network. The application would usually need to access some data, which was stored in a database. The server and the database, both the software and hardware, were owned and operated by enterprise IT and totally under their control. The server would read and write against this database to handle the client request. That’s it! Securing such a system at its core was easy – you needed to protect the flow of information from the client to the server, and then protect the information stored in the database. The former was typically provided by technologies like HTTPS (secure HTTP), and the latter by encrypting the database. And thus the moniker – encryption in transit and at rest.
But, technology has evolved since then, and a large number of those enterprise applications have now moved to the Cloud. Modern cloud applications looks something more like this:
With the move to the cloud, four big things changed. Firstly, instead of the application running on an IT controlled server, it runs on someone else’s server. This is the core concept behind public compute clouds, also known as Infrastructure as a Service (IaaS), in the picture above. Since it’s owned by someone else, it’s colored in orange.
Secondly, instead of IT having sole access to that server, other customers use that server too. This is referred to as multi-tenancy, and is a core part of what makes public cloud cost effective – many customers can share the same computer so it can be efficiently utilized.
Third, instead of the application being a single app running on that computer, it’s now a whole bunch of separate smaller apps – called microservices – which run across many computers, talking to each other over a network. Breaking up a large monolithic application into many smaller microservices makes the system more reliable and scalable.
Finally, those microservices, in turn, act as clients and talk to other cloud applications, provided by third parties, which are built in the same fashion. Most modern cloud applications consume other cloud services for things like storage, analytics, metrics, messaging, databases, and so on. Those other cloud services are also multi-tenant, supporting multiple customers at the same time. And of course, they’re owned by someone else too.
When you add it all up, the surface area for an attack has grown exponentially.
The landscape for an attack looks much different today than it did in the days of client-server applications. In client-server model, there was a single network to attack – the access network. Now, there are many networks – the access network, the network within the public cloud provider, and the one between different cloud services. In client-server, there was a single actor to attack – the vendor of the application. Now, there are many – the vendor of the application, the IaaS vendor, the vendor of the cloud services it consumes, the vendor of third party microservices, and the vendor of any other app running in the same IaaS. And finally, in client-server, there was a single component to attack – the monolithic application. Now, there are many microservices of different types running on a wide range of hardware and networking systems. As a result, attacks can be launched against an increasingly larger set of places on the network, actors in the system, and layers in the software and hardware stack. When you add it all up, the surface area for an attack has grown exponentially.
What is the solution then? The answer is a new technology called end-to-end (e2e) encryption. What is e2e encryption? It’s a security technique where data is encrypted on the client before it even gets to the cloud, and is then decrypted by clients when it is received from the cloud. The cloud can store it, and process meta-data about it, but it can never peer into it. The keys for accessing this data live elsewhere – in the clients or in other computers which reside elsewhere (for example, on a customer premises). This means that it no longer matters whether data is accessed by attackers in the cloud – because even if it is – it is not useful. It is encrypted, and cannot be decrypted by the attacker without the keys, which aren’t present in the cloud that was attacked.
What is the solution then? The answer is a new technology called end-to-end (e2e) encryption.
E2e encryption represents a fundamentally different approach to content security. Instead of trying to prevent every possible data breach scenario, it makes it so that a breach doesn’t yield anything useful.
Consider what would happen to a Software as a Service (SaaS) product which was running in a public cloud when an attack was launched against that SaaS product using the Meltdown vulnerability. An attacker might be able to read the content out of the SaaS product. But, if it was e2e encrypted – it would be useless to the attacker. And whatever the next vulnerability is that allows cloud data to be compromised, it makes that one useless to attackers too. This is the ultimate insurance against the vulnerabilities which have yet to be discovered.
E2E encryption – used by Cisco Spark for example – is no longer a nice to have, or something that only the truly paranoid require. E2E encryption is the only way to melt down meltdown, and to make sure that cloud data stays safe against this vulnerability, and the ones which are sure to follow.
Learn more about how end-to-end encryption works within Cisco Spark.
Amazing information Jonathan!! Thank you!! Cisco Collab customers are in such good hands thanks to you and the team behind the immensely secure architecture of Cisco Spark Platform! Way to go Cisco!!!
Note that there is no URL Link to Cisco site in the US CERT site.
https://www.us-cert.gov/ncas/alerts/TA18-004A
I am still not clear about how Cisco Spark use E2E encryption. Does it mean that the data stored in the memory allocated for Cisco Spark is encrypted ?
Yes, it is encrypted while stored in memory, because the cloud never decrypted it anywhere. You can find a lot more details in our whitepaper here: https://www.cisco.com/c/dam/en/us/solutions/collateral/collaboration/cloud-collaboration/cisco-spark-security-white-paper.pdf
>> What is the solution then? The answer is a new technology called end-to-end (e2e) encryption. What is e2e encryption? It’s a security technique where data is encrypted on the client before it even gets to the cloud, and is then decrypted by clients when it is received from the cloud.
Isn't this already done with https? Though perhaps your point is that there is no additional decrypt/encrypt stage while the data is in the cloud?
>> The cloud can store it, and process meta-data about it, but it can never peer into it.
I assume that the meta-data is exposed and subject to the same potential attacks?
My main takeaways from this article are
(1) DO NOT add a decrypt/encrypt stage in the cloud and
(2) DO add enough meta data for the cloud to perform whatever processing is necessary
Sorry if I've missed some important insight.
E2E encryption is NOT addressed by HTTPS. HTTPS provides encryption in transit only. As you point out – the issue is that a decrypt is done in the cloud. With E2E, there is no decrypt in the cloud so the unencrypted information is never visible anywhere in the cloud.
Very helpful information here. Could someone comment on E2E encryption as it pertains to meeting traffic? With the meeting experience becoming singular in or out of the Spark application does this mean that my WebEx meeting initiated either from Spark or other mode is E2E encrypted as well?
The article nicely compares traditional and modern techniques for data confidentiality. And Cisco Spark is a great example leveraging this technique
Very helpful information here Jonathan, thank you!
It is puzzling why an E2E solution was a concept in the beginning for the cloud.
Will it always be reacting to threats once it occurs or was it found through a group of paid hackers.