12 November 2013
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, videoconferencing 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.
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:
Skype for Business
Several fixes and updates have been released by Zoom since we first started working on this blog series, culminating with the release of Zoom 5.0 on April 27th. Since some of these changes have a significant impact on the security features and capabilities Zoom provides, we have opted to update our summary table and analysis below so as to provide a clearer view of the product as we understand it to be currently, as well as to correct some errors that were brought to our attention, with apologies to the vendors concerned!
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.
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.
Readers will note that we have migrated from a simple ‘rating’ model to a detailed breakdown of specific features and properties one would want to see in each of the four security areas were considering. 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 see a breakdown of security features a product might offer, with an indicator of whether its ‘Fully’, ‘Partially’ or ‘Not’ offered.
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.
You can find the results for comparison in the table below. Notice that this is not the whole story but only a very short overview. To avoid giving an incomlete picture we will publish the overviews of each tool along with the detailed blog post where you can find the detailed review.
|: Full support|
|: Partial support|
|: No support|
|?||: Not clear to us|
|Uses an appropriate encryption algorithm|
|Uses a strong encryption key|
|Data is encrypted in transit under normal use|
|Data stays encrypted in transit on provider servers||?|
|Voice, Video and Text are all encrypted|
|File transfers & session recordings are encrypted|
|Vendor technically can’t decrypt the data at any point, even under regulatory pressure (full E2EE)|
|Encryption implementation has withstood scrutiny over time|
|Administrators can define password security policies|
|Supports MFA as default|
|Can integrate with Active Directory or similar|
|Can integrate with SSO solutions via SAML or similar|
|Allows passwords to be set for meetings|
|Allows meeting password security policies to be set|
|The vendor cannot technically access any data without the client’s consent|
|A full on-prem version is available for users who don’t want to trust the vendor|
|For SaaS modes of deployment, the client can select which countries or political regions data is stored or processed in|
|Complies with appropriate security certifications (e.g. ISO27002 or BSI C5)|
|Complies with appropriate privacy standards (e.g. FERPA or GDPR)|
|Provides a transparency report that details information related to requests for data, records, or content.|
|Offers other forms of access control to meetings, e.g. waiting rooms, lockout, banning etc.|
|Allows granular control over in-meeting actions like screen sharing, file transfer, remote control.|
|Offers clear central control over all security settings|
|Allows for monitoring and maintenance of endpoint software versions|
|Provides compliance features like eDiscovery & Legal Hold|
|Auditing and Reporting|
|Additional content security controls like DLP, watermarking, etc.|
|Percentage of NVD 2019||0.02||0.01|
|Percentage of NVD 2020||0.08||0.00|
|Vendor discloses which vulnerabilities have been addressed|
|Vendor runs a bug bounty|
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…
Head of Security Research
Charl van der Walt
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.
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.
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.
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.