Wrapping up our security analysis of videoconferencing tools
The idea of developing a comparative security analysis of videoconferencing products wasn’t actually ours. Rather two of our colleagues (and co-authors on this blog series) actually tackled the problem first, but when we saw what they’d done we recognised that they’d taken on something important and partnered up with them to address the question in a comprehensive manner. We had been finding the ‘hysterics’ (for lack of a better word) about the apparent security issues with Zoom to be misplaced and ill-considered, so the opportunity to investigate the issue thoroughly and objectively was appealing.
We had no idea of the scale of the investigation we were embarking on, or how little we knew about the issue.
Whilst reviewing the various solutions it soon became apparent that they offered far more than simple videoconferencing and presentation capabilities. Indeed, they are multi-faceted platforms offering, with varying degrees of integration, features including file transfer and storage, meeting recordings, collaboration capabilities, PSTN, routing, trunking and in many cases hardware also. The depth and breadth of these capabilities made a balanced analysis extremely difficult. In the end we limited our work to a basic ‘core’ of features – focusing on those offered most universally across the various products – but ignoring many elements that would really be required by any business wanting to complete a thorough risk assessment of a potential product.
If anything, we learned how little we really understand this domain – a realisation many soapbox commentators and Zoom detractors apparently still need to rise to.
Comparison is actually very hard. It depends on use cases and threat models
When choosing a solution, organizations need to factor in both their intended use cases and their realistic threat model. Without these fundamental insights to hand it is extremely difficult to compare the available solutions meaningfully. If certain features are required, such as meeting recordings for example, then this is likely to have a cost in terms of the security levels available. Similarly, if full end-to-end encryption is a necessity due to your threat model then this will most definitely impact on what features are available.
But the security attributes and features offered by conferencing and telephony vendors go well beyond obvious capabilities like encryption and access control. Conferencing and collaboration happen across complex and overlapping trust domains, including employees, partners, customers and complete outsiders, and therefore require a much more nuanced view of authentication and authorisation then most technologies we deal with. People using corporate conferencing and collaboration technologies are also both private individuals and corporate representatives, and so the right to privacy needs to be weighed up against corporate requirements for auditing, IP protection and the fiduciary rights and responsibilities a business carries for what its employees say.
It should be obvious that none of these more nuanced objectives can be met if a technology fails at the basic implementation of security features and vulnerability management. The public’s anger and angst when failures in these disciplines are reported is therefore completely understandable, but to focus solely on these two areas when comparing offerings is to grossly oversimplified a complex equation.
Vulnerability Management is multi-faceted.
As much of the public indignation around Zoom had centred on vulnerabilities and exploits threatening their software, we wanted to include an assessment of product vulnerability history and the vendor’s vulnerability management ‘maturity’ in our analysis. Our initial goal was to discover whether the volume and severity of security bugs reported for Zoom were extraordinary when compared to other comparable vendors.
The overall effectiveness of a Vulnerability Management program turns out to be a very complex area to assess, however, and it is easy to misconstrue the data available. For example, is a vendor who publicly discloses several vulnerabilities as they are found and resolved less secure than one where no vulnerabilities have been publicly disclosed? It would be easy for us to infer that a vendor with few vulnerabilities on record is more secure than one with many. However this may just as easily be a function of the vendor’s defensive attitude to transparency, rather than their competence at security.
Zoom was lambasted for perceived vulnerabilities and privacy failures, but to their credit have since placed enormous focus on resolving the reported issues and transparently reporting on their progress and plans.
Likewise, our original analysis may have had the unfortunate effect of painting Cisco Webex in a bad light by visually illustrating the large number of vulnerabilities recorded for their platforms. In fairness they have a complex and feature-rich offering that is bound to be challenged by more bugs, and they are also very transparent about the vulnerabilities they find and resolve, suggesting that are actually trustworthy where vulnerability management is concerned.
E2EE is nuanced and poorly understood
The other major criticism of Zoom had to do with how they implemented a security feature they called ‘End to end Encryption’. True end-to-end encryption (E2EE) is supposed to absolutely ensure that only the communicating parties can read anything that is sent, but a third-party analysis demonstrated that Zoom itself would theoretically be able to intercept communications between clients. This criticism was technically true, but much of the outrage centred on the apparently misleading language in Zoom’s collateral about the feature. Or analysis of the issue suggests that Zoom was by no means the exception amongst its peers in this regard. Indeed, we discovered that the term E2EE is frequently poorly defined, inconsistently used and probably generally misunderstood.
Our research suggests that whilst several of the vendors we examined advertised E2EE in their products, the implementations of this feature varied substantially. For instance, some solutions technically provide E2EE since traffic remains encrypted even whilst traversing the vendors servers, but still have the theoretical ability to decrypt the traffic as they hold or generate the encryption keys. Moreover, all solutions fundamentally must compromise on E2EE in order to offer features such as recording, streaming, conference room hardware support or PSTN integration. Some solutions offered significantly less than Zoom whilst still claiming E2EE and others can provide E2EE only in specific deployment modes (e.g. onsite) or under particular licensing agreements.
In their later discussions about their planned new E2EE offering Zoom also raised the issue of the ‘public good’ as a consideration in the E2EE debate, arguing that there is a balance to be struck between the individual right to privacy and their corporate responsibility not to enable private and anonymous channels that could be used for unlawful purposes. This is a complex question and beyond the scope of this short summary, but it serves to illustrate that a single-dimensional criticism of one product’s implementation of this ‘feature’ is probably less than useful.
For businesses evaluating their options this is again an area where they will have to make a choice between security and feature requirements.
Enterprise ‘security’ requirements are very different to end-user, and in ways we didn’t expect.
Through the course of our review it became apparent that there were important elements that an enterprise had to consider from a security perspective that an end user, and certainly a home user, would not even think about. A prime example of this is Legal Hold, part of the e-discovery process, which is a notification to not delete any stored data that may be relevant to a new or imminent legal case. Other factors an enterprise may have to consider are granular Role Based Access Control and integration with existing user directories and SSO solutions, logging and auditing and whether they can control the geographic regions of servers that their data routes through or is stored on. Most businesses also need the ability to collaborate with guest users from outside the organisation and will need the ability to granularly control the use of certain features, such as file transfers, as part of their data leakage prevention strategy. The offerings of the more ‘mature’ players, like Cisco, Microsoft and Google are typically more advanced where features like these are concerned. Indeed we found them to be completely absent in several of the offerings we reviewed.
It’s hard to know the ‘truth’. Approaches to documentation vary dramatically and its often very hard to find and interpret information on how products really work.
Part of our approach to carrying out this assessment of the different products was to attempt to glean as much information as possible from publicly available content. As simple as that sounds, in truth it turned out to be a lot more difficult than we anticipated. Much of the documentation we reviewed was very light on technical details and in several cases glossed over the details by using buzz words. As a rule, we had to dig quite deeply into support and sales documentation to pull together the information we required, often from several different documents which in some cases seemed to contradict each other. We compliment Zoom on the clarity and transparency with which they detailed their response to the security criticism they received, and other vendors may also want to consider making the technical details a bit more transparent and easier for potential customers to find. Out of all the vendors we researched Cisco came the closest to having that level of transparency although we still encountered some points of confusion surrounding their “Meetings” and “Teams” offerings.
It should be noted that several of the vendors made themselves available to answer our technical question and we found all of those to be more than willing to be clear and transparent with us. More on these discussions later.
Licensing is significant factor – most vendors offer security features on a tiered model.
Following Zoom’s announcement that they had acquired Keybase to bolster full E2EE service, they announced that E2EE would only be available to users of a paid account. This led to what we believe is unfair criticism from several parties, who argued that this essential feature should be universally available. Indeed, it appears to be common practice that most of the vendors that offer a free tier of service either have restrictions of functionality in place and/or deliver advertising via the product or service used. Most vendors will have several licensing tiers, with some features being reserved only for customers who pay for the very top tier. Most commonly inn fact full E2EE is only available to customers who procure and deploy and manage a fully on-premise version of the solution.
Observations on observers
One thing we did not anticipate was the level of attention we would receive from some of the vendors we covered in our piece. Many of them were keen to engage with us to ensure we had the correct information in areas where we had misinterpreted something or otherwise done them a disservice. We found the vendors we engaged with to be passionate about their products and happy to share details of both their existing products and future roadmaps. In all cases the people we spoke to were decent, balanced and well-informed in their views.
We couldn’t help contrasting this with the way some elements of the press and social media reacted to the initial concerns around Zoom, where they were happy to jump on the bandwagon and follow the hype to denigrate Zoom, often without any apparent effort to truly understand the issues. Whilst some of the criticism of Zoom was undoubtedly fair (some traffic was accidentally routed via China, for example), we felt that a lot of the criticisms could equally be levelled at other vendors also, and some of it simply had no reasonable basis.
Getting back to Zoom
We end back where we began – with Zoom. In summary:
- The issue of vulnerabilities and exploits that caused such a fuss was almost certainly a red herring. All vendors will struggle with software vulnerabilities and Zoom is neither the best nor the worst of its competitors. We encourage our readers to develop a disciplined approach to evaluating the maturity of vendors, which encompasses their track record with fixing reported bugs (not how often they are reported) as well as a broader look at the structures and processes the vendor has in place and (perhaps most importantly) their level of transparency regarding these issues.
- The criticism of Zoom’s E2EE offering missed most of the real issues and generally failed to present a mature threat model to argue from. Zoom was correctly called-out for mis-labelling their solution as ‘End to End’, but we feel that the term is generally misunderstood and frequently misused across the market. We encourage our users to carefully consider what specific threats they need the technology to address, in order of importance, and to perform their evaluations from that perspective. Our view is that technical terms like “E2EE”, “AES 256” and “DLP” require a precise definition in the context of a buyer’s specific threat model to be meaningful.
- From our discussions with Zoom we have come to believe that the issue of the ‘China’ routing was almost certainly a red herring. A small amount of traffic was indeed routed via a server in China but this appears to be as the result of a bug in their routing algorithms rather than through malice or poor architecture. The broader question of data sovereignty is key to “privacy” but needs to be seen through the lens of the buyer’s threat model and geopolitical orientation, not narrowly through an oversimplified ‘good vs evil’ dichotomy.
- It’s our view that in most of the public discourse about Zooms their security features and capabilities were generally under-estimated and their bugs and issues generally exaggerated. In fairness to Zoom some of the security and privacy concerns centred around settings that could be applied if the end user chose to do so, and Zoom did respond rapidly and aggressively to correct the remaining issues raised. This responsiveness and transparency is a far more important marker of maturity than the fact of the bugs being reported in the first place.
- That said, and probably more importantly, Zoom does arguably present a less comprehensive offering in terms of enterprise security management and compliance than vendors like Teams and Webex.
Even as we were putting together this final post developments in this area continue apace. A prime example of this is that despite us stating above that Zoom would only offer E2EE for paid accounts they then changed their mind. Likely due to the significant public outcry when it was announced that users on the free tier would not get E2EE, Zoom announced that they would offer this to free users who verify their accounts by providing additional identification information such as their phone number. They stated that this verification step will ensure they can identify and prevent any abuse of the service.
In a similar vein BlueJeans have also announced a number of new features and security controls, the most notable being the change from AES-128 based encryption to AES-256 instead. Other features, which should be available by the end of the summer, include virtual backgrounds, waiting room, meeting transcription, non-raise hand interactions, and an enhanced integration with Slack.
What comes next
There is still much more work that could be done to examine questions like PSTN switching, hardware integration, federated rights management, encryption key management and Data Leak Protection in complex environments, but we will leave that for other better qualified than us to consider.
Our work on this topic comes to an end now. We hope our blog series on video conferencing solutions security has been illuminating. Thank you for reading!