We all know the story of Goldilocks and her ill-fated visit to the house of the three bears. What lesson, if any, one might take away from this story is that too much of a good thing doesn’t necessarily make it the right thing. Porridge is best hot, but too hot and that’s not good. Big chairs are big, but if they’re too big, they’re not comfortable.
What is true for Goldilocks – and bear with me on this analogy here – is also true when considering security technologies for business. These days, the industry is abuzz with consumer players that have decided to implement end-to-end (E2E) security in their messaging products. It started with Apple and its battle with the U.S. government on access to iPhone data. Then, WhatsApp switched its messaging technology in such a way that no one could have access to messages except for the end-user client. Recently, rumors have circulated that Facebook plans to make a similar change for Facebook Messenger.
When evaluating messaging technologies for the workplace, these kinds of solutions seem like they would be a good thing. But if you dig a little deeper, they’re not. The reason is that the workplace environment requires that certain parties can access message content. The legal department will need access in case of a lawsuit. The infosec department will need access when tracking a possible data leak. They may also want real-time access in order to audit shared content to make sure users are complying with company policy (e.g., no sharing of restricted information with outside parties).
As such, when evaluating messaging technologies, the question to think about is: What parties should have access to content, and which should not? When you do that, you quickly draw a simple 2×2 matrix that looks like this:
One dimension is the level of data access that is available to Enterprise IT (including Infosec, Legal, and other authorized parties). This is desirable access. The second dimension is data access by the cloud provider of the messaging service, as well as data access available to attackers and external parties. This is undesirable access.
E2E secure consumer tools – like WhatsApp – provide low data access for attackers and the cloud provider (WhatsApp itself), but also provide low data access for anyone else – including IT. For any business seriously considering “just use WhatsApp at work,” this should give you great pause. In essence, these providers are “too locked down.”
On the other end of the spectrum, we have enterprise messaging providers – Slack and Hipchat are examples in the industry. They typically use transport security combined with encrypted databases. These provide some security but ultimately enable the provider, attackers, and perhaps enterprise IT (assuming such features are developed and made available) to have access. This is also not a great solution since it means critical business data is potentially in the hands of many parties. Worse still, the more successful and more popular the provider is, the more data it has, and the more attractive of a target it becomes for attackers and other parties who seek access to data. These solutions are “too insecure.”
With Cisco Spark, we’ve built a solution that is “just right.” Our unique security solution locks out Cisco – as the cloud provider – from having access to the content. At the same time, it enables enterprise IT to have the access it needs. And, of course, since Cisco as the cloud provider doesn’t have access, any attackers to our cloud won’t have it either.
How, perchance, is this possible? Well, the great news is that we’ve decided to open up the kimono, so to speak, and reveal all of the details on how Cisco Spark security works. We’ve just published a white paper that reveals information on our architecture. It covers:
- Our split-security model–a core layer and a security layer–and describes how clients build and maintain trusted relationships with the security layer with the core in the middle.
- How we enable search of content–a critical user feature–using this split architecture.
- How the architecture works in the face of multiple security domains (which we call KMS federation) and provides details on key authorization and access controls.
We’re proud of this amazing architecture, and pleased we’re finally able to open up and reveal to the world how it works.
Once you’ve read through the white paper, you’ll see how our solution meets the seemingly impossible goal of providing “just right” security for the workplace – access to those who need it, and not for those who don’t.
Read the full “Cisco Spark Security and Privacy” white paper.
Great analogy – who would have thought that, by locking ourselves out of our own cloud, would be a great benefit to our customers?