Video killed the conferencing star
A security analysis of videoconferencing solutions for business
For many businesses the COVID-19 epidemic has made teleworking the only feasible alternative to having their workers on site. The video call has become essential to collaborating effectively while working from home. Teams, Webex, Zoom and other collaborative platforms have become a part of our daily lives.
In the age of corona, video conferencing has become the substitute for group meetings, conferences, webinars, training or even a simple conversation with colleagues. Thanks in large part to these technologies, there has never been a “better” time in history to be working from home. But utilizing this incredibly useful technology is not without risks.
Focussing on “Zoombombing” misses the big picture
One solution that is getting a lot of attention now, for good reasons and for bad, is Zoom. Zoom Video Communications Inc, headquartered in San Jose, has seen more growth in the first quarter of 2020 than in the entire year of 2019. With this massive increase in adoption has also come an increased level of scrutiny, and there’s no doubt that Zoom has fallen far short of the mark in terms of security and privacy. Whereas the Zoom application has been massively (and often rightfully) criticized, how do its competitors stack up? We’ve undertaken an analysis of several competing videoconferencing solutions to consider this question. The scope of our analysis are business-focused solutions – “end user” products such as Skype, Discord, Ventrilo, Facetime and Whatsapp were not considered. The products we will analyze for this blog series are:
- Microsoft Teams
- Cisco Webex
- CiscoWebex Teams
- Google Meet
- Skype for Business
- Jitsi Meet
This is the first in a series of six blog posts in which we explore the relative security of these products. In this post we’ll outline our approach, present the model applied in our evaluation and submit a summary of our findings. If you’re only interested in the bottom line then just skip down to the summary at the end of this post.
We also present an analysis of the number of technical security vulnerabilities reported in those products over the last two years, in an attempt to inject some rationality into the widespread hysteria around the vulnerabilities recently reported for Zoom. You can see our findings in the ‘Vulnerability Comparison’ section further down in this post.
In the next five blog posts we will provide a detailed analysis of each of the products above, two by two, against a standard security model we present below. The blog number within the series for each product is also given in the summary table.
Videoconferencing: thinking about security
The choice of a video conferencing solution is always a compromise between features and fit on the one hand, and security and privacy on the other. User requirements like performance and availability, features (audio/video, document sharing, whiteboard, questionnaires, etc.), platforms (smartphones, computers, meeting rooms, telephone call, etc.) and technical restrictions such as available bandwidth (broadband or limited connection) need to be weighed up against security requirements like encryption, access control, compliance, exploit mitigation and the like.
An effective solution is a delicate balance of all the above. Using an extremely secure solution is not helpful if it doesn’t fulfill the remote employee’s basic communications needs. Similarly, it is not wise to select a very functional solution which does not provide an appropriate level of security.
When assessing the suitability of platforms for video conferencing we need to remember that the term ‘secure’ has no precise definition. Security is the ability to provide an appropriate level of confidentiality, integrity and availability for the specific use-case. In other words – there is no single answer to the question of whether any communications platform is secure enough – it depends on who’s using it and what for.
In this series of blog posts we offer the reader a summary of salient security and usability features that should be helpful in determining whether a given platform is appropriate for your particular use-case.
To accomplish this in an objective manner, we start by presenting a ‘target security model’ that we believe should summarize the security needs of the ‘average’ corporate user. With the model in mind we then set out to install, configure and test each of the systems we report on here. Where this was not possible, we sought to leverage insights from colleagues who were already using the platforms or (in the worst case) depended on information published by the vendor or other third-party sources. We endeavor to be clear about where our insights were gleaned in each case.
We developed the security requirements model shown below to structure our analysis of the security attributes of the various offerings in this space:
|Authentication||A robust business system must provide the ability to identify and confirm legitimate users of the platform and prevent others from entering uninvited. For businesses this would generally also imply integration with their existing user directory, and preferably support for Single Sign On (SSO). In the modern security climate, we would also have a strong preference for systems that support Multi Factor Authentication (MFA).|
|Encryption||The confidentiality of the voice, video and text data as it traverses the local network, Internet and (potentially) the providers’ servers are also key. There are two models to consider here and they address different threats.Data in transit: Voice, video and text should be confidential as they traverse the LAN and public networks between the various servers and endpoints in the system. The assumption is that robust and verified encryption standards will be adopted and properly implemented, and that keys are properly managed.
End to End Encryption: The gold standard is ‘End to End’ (E2EE) encryption, where the traffic is encrypted as it leaves the one user endpoint and only decrypted again as it arrives at the other. Crucially, “E2EE” implies that the provider cannot decrypt data that traverses their systems, even with the customer’s consent or under government coercion.
Not all users will have the same risk considerations and so both attributes are not necessarily a requirement for all customers.
|Regulations and Jurisdiction||The geopolitical location and legal jurisdiction of the provider play an important role in determining the risk.The provider of a conferencing service will be a legal entity that falls under the jurisdiction (and thus regulation) of a legal sovereign state. Not only might that impact the kinds of security standards the vendor implements, but it also has significant implications for the security of data that might be stored or processed by the vendor, in the face of possible government efforts to access that data.|
|Security Features and Management||Complexity is the enemy of security and so we would expect a critical system to provide administrators with clear and comprehensive tools through which the security features can be understood, implemented and monitored.|
|Vulnerability and Exploit History||The security features and controls that a platform lays claim to are only useful if those controls can’t be subverted by hackers exploiting vulnerabilities in the technology. We therefore need to consider the track record of the vendor with regards to technical security, its level of transparency and ability to respond quickly and effectively when security bugs are reported.|
As argued previously, we want to consider the track record of the vendor with regards to technical security, its level of transparency and ability to respond quickly and effectively when security bugs are reported. The subtler elements of security culture and responsiveness will be touched upon in our analysis of the individual products, but in the mean time we will explore the apparent track record of the various vendors with respect to the number of security vulnerabilities that have been publicly reported and recorded in the the National Institute of Science and Technology (NIST) National Vulnerability Database (NVD).
The graph above compares the number vulnerabilities officially recorded by the NIST NVD for 2019 and the 2020 year to date. To provide a ‘normalized’ comparison of the vulnerabilities for each product we present the number as a percentage of the total number of vulnerabilities recorded in the database for the period.
There are no vulnerabilities recorded in the NVD for Tixeo, Google Meet or BlueJeans, but this should not be taken to mean that there are no vulnerabilities for these products, or that these should be trusted more than those reflected in the chart. Indeed, as cloud products generally cannot be patched by the customer, vendors will frequently not record the vulnerabilities with NIST even when they are discovered or reported.
BlueJeans, for example, do have a bug bounty program through Bugcrowd, but do not disclose the issues that are reported to them. There are several people listed on the program’s hall of fame suggesting that vulnerabilities have been found but not been made public.
Google is also by no means immune to security bugs and exploits either, and a few vulnerabilities were in fact reported in their previous ‘Hangouts’ product.
Tixeo is especially very quiet on the question of vulnerabilities and patches. A 2014 comment on their blog regarding the “Heartbleed” vulnerability was confident of their security, but in our opinion lacked the technical detail required to garner trust.
Nevertheless, the volume of vulnerabilities recorded for a product over time and the way the vendor deals with these is an important indicator of the firm’s maturity and seriousness where security is concerned.
We are inclined to favor products that have a visible history of finding and responding to security bugs over those for which no information is available. In our summary table we have highlighted those products where we have no visibility regarding vulnerabilities by recording a blank cell for the relevant field.
Whilst it is disappointing that data is not available for all the products, the graph above does serve to shed some light on the attention Zoom has been receiving for the bugs in their products recently. Of the three products, Webex is the oldest and arguably the most well established, so it stands to reason that more vulnerabilities would have been discovered and reported. From the data presented it would appear that some products have performed much better than others vulnerability-wise over the last two years. However, Teams and Zoom are relatively new players and have therefore received less scrutiny and dealt with fewer bugs. Some vendors are purely SaaS, whilst others have actual software products. Some are proprietary while others are open source. It’s therefore difficult to read very much about the security capabilities of the vendors from this data alone.
One can, however, conclude from this data that Microsoft Teams has had to deal with significantly fewer security issues than both Zoom and Webex over the period. It would also seem fair to say that, whilst the vulnerabilities reported for Zoom over the last few months are concerning, they by no means make Zoom exceptional in this regard.
Regarding the recent excitement in the press and on social media about vulnerabilities discovered in Zoom specifically, they need to be considered with this data in mind.
In our view the acid test for Zoom would be what their vulnerability count in the NVD looks like as a percentage of all vulnerabilities reported at the end of 2020.
This perspective would allow us to objectively assess how they have fared as a ‘major player’ with the increased scrutiny that implies, and how well they have responded at a fundamental level to improve their ability to minimize security issues in their code.
The table below captures a summary of the analysis that we will present over the next few blog posts. Each product we evaluated will be discussed in terms of the elements of the target security model we constructed, and for each element we will present a relative ‘rating’ score between 0 and 5 – ‘0’ implying the attribute is simply not existent in the product, and ‘5’ suggesting it could probably not be implemented better. You’ll see these ratings summarized in the table below.
It is important to understand that these ratings represent our efforts to rank the capabilities of each product relative to the others. As there is no empirical or fully objective way to do this, we have used this simple approach to capture and present our subjective assessment based on the research we conducted.
Given our previous comments about ‘secure’ not being a simple, binary concept, we have not attempted to provide a collated or total rating for each product. Rather we leave it to the reader to examine each element separately, and determine which elements, and what kinds of functionality and usability, are best suited for their specific needs.
A white square in the table below represents a half (1/2) point. We decided to use them where we felt it was important to make a distinction in the level we assigned.
 We are not aware of any central security management features in v4
When assessing the suitability of platforms like video conferencing, we need to remember that the term ‘secure’ has no precise definition. ‘Security’ implies the ability to provide an appropriate level of confidentiality, integrity and availability for the specific use-case in question. In other words – there is no single answer to the question of whether any communications platform is secure enough – it depends on who’s using it and what for. A family wanting to stay in touch with loved ones will have very different security requirements to a government wanting to hold cabinet meetings.
With any conferencing platform there will be a features / security / cost trade-off. Some platforms will be stronger in some areas than in others. For ‘use-cases’ where security is a serious concern the buyer needs to perform a comprehensive risk assessment based on their own unique threat model and decide from there.
For home users the risks are generally going to be low and can usually be mitigated either through available technical controls (like those being clarified and improved by Zoom almost daily) or by simply using the technology appropriately. For example, for most users simply updating to the latest versions, adding a password to meetings and appreciating that their conversations are not fundamentally ‘private’ (as is the case with most platforms they use on the internet) should be enough to make Zoom a perfectly acceptable platform. For a government, military or pharmaceutical company more would be required, and something more fit for corporate use-cases like Teams might be more appropriate.
In short, the security and privacy features we require from a technology depend on our use case and threat model. Security evaluation needs to start by considering what we are trying to protect, and against whom. Businesses need to perform this evaluation thoroughly. Home users need to understand that they will almost always be trading off some level of privacy, understand the trade-off for the products they’re using, keep their software updated and use the security features the product provides.
Please visit our blog again over the next few days to read our detailed analysis of all ten products against the target security model and gain some insight into why we assigned the ratings that we did…
Technical thought leader, spokesman and figurehead for Orange Cyberdefense world-wide, leading and managing the OCD Security Research Center – a specialist security research unit. We identify, track, analyze, communicate and act upon significant developments in the security landscape.
Quentin Aguesse (Senior Consultant Cybersecurity)
Graduated from a French Business School, Quentin is now senior consultant at Orange Cyberdefense operating from Casablanca (Morocco). With nearly 10 years of experience, Quentin has specialised in risk assessment , disaster recovery planning, as well as cybersecurity awareness.
Jérôme Mauvais (Consultant Cybersecurity)
As a specialist in regulatory compliance, Jérôme Mauvais is a security consultant for Orange Cyberdefense. Highly invested in the protection of personal data, Jérôme has also been remarked all along his career for his great capacities of knowledge transmission.
Carl Morris (Lead Security Researcher – MSIS Labs)
Carl has over 20 years’ experience working within IT, covering the whole breadth of the IT infrastructure, with a primary focus and interest on the security related solutions. This has been followed by a decade working in MSSP’s, the latest of which being at SecureData for over 7 years. Initially as an Escalation Engineer followed by moving into Professional Services then to the Managed Threat Detection team as a Senior Security Analyst before moving into the Labs team as a Lead Security Researcher.
Share the post