The second day of Enterprise Connect is always my favorite, as it’s when the keynotes begin. As in previous years, Cisco took the first slot, with Jonathan Rosenberg, VP and CTO of the company’s Collaboration Technology group, doing the honors. I’ve known Rosenberg for years, and have always felt that he has a good understanding of technology and business issues, making him a compelling speaker for Enterprise Connect.
His keynote focused on the four things that need to happen to drive the adoption of team collaboration tools. These are:
The bottom three are widely discussed meeting problems that many vendors are attempting to solve. Some are being more successful than others. The security point is one that I’ve long felt gets overlooked by companies -- a mistake that could have disastrous implications in the face of a data breach.
It’s important to understand team collaboration beyond messaging. It’s a place for making calls, holding meetings, and storing company files, which could contain sensitive information. Protecting data within the team collaboration space is of the utmost importance.
End to What End?
During his keynote, Rosenberg highlighted the company’s end-to-end encryption scheme, now called Breach Lock. This is Cisco’s way of ensuring that if data is stolen, the threat actor is treated to a dose of encrypted data that can’t be read. To demonstrate the capability, he ran a breach simulation that pulled actual data from the Spark cloud and showed the payload as a string of gibberish. Cisco has been offering this capability for a while, simply referring to it as end-to-end encryption -- a nebulous term, as “end to end” can have so many different meanings.
Almost every team collaboration vendor says it has end-to-end security, encrypting traffic in transit and at rest. But is that really end to end? The answer is, “Not really.” The data coming in from the network may be encrypted, but then often needs to be unencrypted when it passes through servers, load balancers, and other infrastructure, and then is finally re-encrypted when it’s at rest. Cisco’s approach is to keep the encryption persistent across the entire path; this is why, should a breach occur, the data looks like garbage. This is an interesting approach, as it’s somewhat of an admission that no matter how good the security tools and processes are in place, a breach is still possible. So, to ensure that when one does happen, the data can’t be read.
Cisco is able to do this because of the way it handles security keys. Many of the team collaboration vendors offer a “bring your own key” model in which businesses can choose their own security keys. This makes total sense, but the question then becomes one about key storage. Some of the vendors store the keys in their clouds on behalf of the customers. This sounds good, but in actuality it’s like picking your ATM PIN and then handing it to your bank to store beside your account number. If the cloud provider is breached, the hacker could steal the account number and the PIN, making stealing your money a breeze.
Instead, Cisco places the key management server on the customer premises, putting control of them in the business’s hands. If the cloud is breached, the data can’t be read without those keys, so the data is protected from end to end.
A Federated Effort
Another point to consider is the risk created by cloud federation. All of the team collaboration tools are SaaS applications, and each has a spot on its website where it describes its security approach. What many businesses don’t know is that most cloud providers rely on federation with other cloud providers to deliver their services. A couple of weeks ago, during a keynote at DigiCert’s Security Summit, security expert Kevin Mitnick (renowned “first” hacker who now spends his time penetration testing for large enterprises)
discussed the current threat landscape. Cloud federation, he said, is one of the biggest security threats today, with the entire federated chain subject to comprise should one provider experience a breach.
To understand this, consider the case where a team collaboration vendor builds its tool using a communications platform as a service, and runs it on public cloud infrastructure. It then stores the data on one or more cloud storage drives, and initiates and terminates calls using yet another public cloud. Each of those cloud providers might use multiple cloud providers to build their service. This can cascade out to many levels, creating a large mesh of federated clouds to deliver one service.
There’s a common expression that “you’re only as secure as your weakest link,” and the more federation that’s done, the greater likelihood of a weak link in the chain. The startling fact is that it’s difficult, if not impossible, to know where your data is. Checking the team collaboration providers site isn’t sufficient. Correctly, you’d have to check every cloud vendor it federates with, and the ones that provider works with, and so on.
The net of this is that securing a SaaS app, like Spark or other team collaboration tools, isn’t easy. Securing data at rest and in transit protects against things like hard drive theft and WiFi eavesdropping, but doesn’t help with things like data flow to less secure cloud providers in the federated chain, inter-tenant attacks in shared compute environments or insider attacks.
For buyers of team collaboration apps, it’s critically important to know the right questions to ask a potential vendor. The website may say something like “data encryption in transit and at rest” but that can be very misleading as it doesn’t tell you what happens in between. Instead, ask if the system offers end-to-end encryption on the user’s content. Without something like Breach Lock in place, businesses might find themselves in the news for the wrong reasons.
Follow Zeus Kerravala on Twitter and Google+!
@zkerravala
Zeus Kerravala on Google+
