Video killed the conferencing star

De COVID-19 epidemie heeft voor veel bedrijven het thuiswerken tot het enige haalbare alternatief gemaakt om hun werknemers ter plaatse te hebben. De video call is essentieel geworden om effectief samen te werken terwijl men thuis werkt. Teams, Webex, Zoom en andere samenwerkingsplatforms zijn onderdeel geworden van ons dagelijks leven.

In het tijdperk van corona is videoconferencing de vervanger geworden van groepsbijeenkomsten, conferenties, webinars, trainingen of zelfs een eenvoudig gesprek met collega's. Dankzij deze technologieën is er in de geschiedenis nog nooit een "betere" tijd geweest om vanuit huis te werken. Maar het gebruik van deze ongelooflijk nuttige technologie is niet zonder risico's.

De keuze voor een videoconferentie-oplossing is altijd een compromis tussen functies en pasvorm aan de ene kant en veiligheid en privacy aan de andere kant. Gebruikersvereisten zoals prestaties, beschikbaarheid, functies (audio/video, delen van documenten, whiteboard, vragenlijsten, enz.), platforms (smartphones, computers, vergaderzalen, telefoongesprek, enz.) en technische beperkingen zoals beschikbare bandbreedte (breedband of beperkte verbinding) moeten worden afgewogen tegen veiligheidsvereisten zoals encryptie, toegangscontrole, compliance, exploitatiebeperking en dergelijke.

Een effectieve oplossing is een evenwicht van al het bovenstaande. Het gebruik van een extreem veilige oplossing is niet nuttig als deze niet voldoet aan de basis communicatiebehoeften van de medewerker op afstand. Ook is het niet verstandig om een zeer functionele oplossing te kiezen die geen passend beveiligingsniveau biedt.

Bij het beoordelen van de geschiktheid van platforms voor videoconferencing moeten we niet vergeten dat de term 'veilig' geen precieze definitie heeft. Beveiliging is het vermogen om een passend niveau van vertrouwelijkheid, integriteit en beschikbaarheid te bieden voor het specifieke geval van gebruik. Met andere woorden - er is geen eenduidig antwoord op de vraag of een communicatieplatform veilig genoeg is - het hangt af van wie het gebruikt en waarvoor.

In deze reeks blogberichten bieden we de lezer een samenvatting van de belangrijkste beveiligings- en bruikbaarheidsfuncties die bruikbaar zouden moeten zijn bij het bepalen of een bepaald platform geschikt is voor uw specifieke use-case.

Om dit op een objectieve manier te bereiken, beginnen we met het presenteren van een ‘doelgericht veiligheidsmodel' dat volgens ons de beveiligingsbehoeften van de 'gemiddelde' zakelijke gebruiker moet samenvatten. Met het model in het achterhoofd gaan we vervolgens aan de slag met het installeren, configureren en testen van elk systeem waarover we hier rapporteren. Waar dit niet mogelijk was, probeerden we gebruik te maken van inzichten van collega's die al gebruik maakten van de platforms of (in het ergste geval) afhankelijk waren van informatie die door de leverancier of andere bronnen van derden werd gepubliceerd. We streven ernaar om duidelijk te zijn over waar onze inzichten vandaan komen.

Update: 21/05/2020

De bovenstaande grafiek is bijgewerkt om de huidige gegevens weer te geven..

Update: 02/06/2020

De onderstaande tabel is ingevoegd om een evenwichtiger overzicht te geven van de mogelijkheden van de verschillende leveranciers op het gebied van kwetsbaarheidsbeheer.

Bovenstaande grafiek vergelijkt het aantal officieel door de NIST NVD geregistreerde kwetsbaarheden voor 2019 met het jaar 2020 tot nu toe. Om een 'genormaliseerde' vergelijking van de kwetsbaarheden per product te kunnen maken, presenteren we het aantal als percentage van het totale aantal geregistreerde kwetsbaarheden in de database voor de periode.

Er zijn geen kwetsbaarheden opgenomen in de NVD voor Tixeo, Google Meet of BlueJeans, maar dit mag niet betekenen dat er geen kwetsbaarheden zijn voor deze producten, of dat deze meer vertrouwd kunnen worden dan in de grafiek wordt weergegeven. Aangezien cloudproducten over het algemeen niet door de klant kunnen worden gepatcht, zullen leveranciers de kwetsbaarheden vaak niet met NIST registreren, zelfs niet wanneer ze worden ontdekt of gerapporteerd.

BlueJeans, bijvoorbeeld, hebben een bug bounty programma via Bugcrowd, maar maken de problemen die aan hen worden gemeld niet bekend. Er zijn verschillende mensen in de hall of fame van het programma die suggereren dat er kwetsbaarheden zijn gevonden, maar niet openbaar zijn gemaakt.

Google is ook op geen enkele wijze immuun voor beveiligingsfouten en exploits, en een paar kwetsbaarheden werden in feite gemeld in hun vorige 'Hangouts' product.

Tixeo is vooral erg stil over de kwestie van kwetsbaarheden en patches. Een commentaar in 2014 op hun blog over de 'Heartbleed'-kwetsbaarheid was vol vertrouwen in hun beveiliging, maar miste naar onze mening de technische details die nodig zijn om vertrouwen te wekken[1].

The table below attempts to capture some of the more ‘subtle’ aspects of vulnerability as a function of product security.

Product	Solution Type	Transparent Vulnerability Disclosure	Runs a Bug Bounty	Vendor has a clear CSIRT/PSIRT Function
Zoom	SaaS & Partial On Premise
MS Teams	SaaS
Webex Meetings	SaaS & On Premise
Webex Teams	SaaS
Google Meet	SaaS	?
Bluejeans	SaaS
Tixeo	SaaS & On Premise
BigBlueButton	On Premise
Skype for Business	SaaS & On Premise
Jitsi Meet	On Premise

Desalniettemin is de hoeveelheid geregistreerde kwetsbaarheden voor een product in de loop van de tijd en de manier waarop de leverancier hiermee omgaat een belangrijke indicator voor de volwassenheid en de ernst van de onderneming op het gebied van beveiliging.

Wij zijn geneigd de voorkeur te geven aan producten die een zichtbare geschiedenis hebben in het vinden van en reageren op beveiligingsfouten boven producten waarvoor geen informatie beschikbaar is. In onze samenvattende tabel hebben we de producten waar we geen zicht hebben op de kwetsbaarheden, gemarkeerd door een lege cel voor het betreffende veld op te nemen.

Hoewel het teleurstellend is dat er niet voor alle producten gegevens beschikbaar zijn, dient de bovenstaande grafiek wel om wat licht te werpen op de aandacht die Zoom de laatste tijd heeft gekregen voor de bugs in hun producten. Van de drie producten is Webex het oudste en aantoonbaar het meest ingeburgerd, dus het is logisch dat er meer kwetsbaarheden zouden zijn ontdekt en gerapporteerd. Uit de gepresenteerde gegevens blijkt dat sommige producten de afgelopen twee jaar veel beter hebben gepresteerd dan andere qua kwetsbaarheid. Teams en Zoom zijn echter relatief nieuwe spelers en hebben daarom minder controle gekregen en minder bugs behandeld. Sommige leveranciers zijn puur SaaS, terwijl andere echte softwareproducten hebben. Sommige zijn propriëtair, andere zijn open source. Het is daarom moeilijk om uit deze gegevens alleen al te lezen wat de beveiligingsmogelijkheden van de leveranciers zijn.

Uit deze gegevens kan echter worden geconcludeerd dat de Microsoft-teams in de loop van de tijd met aanzienlijk minder beveiligingsproblemen te maken hebben gehad dan zowel Zoom als Webex. Het lijkt ook eerlijk om te zeggen dat de kwetsbaarheden die de afgelopen maanden voor Zoom zijn gemeld, weliswaar zorgwekkend zijn, maar dat ze Zoom in dit opzicht op geen enkele manier tot een uitzondering maken.

Wat betreft de recente opwinding in de pers en op social media over de specifiek in Zoom ontdekte kwetsbaarheden, er moet met deze gegevens rekening worden gehouden.

Naar onze mening zou de acid test voor Zoom kunnen zijn hoe hun kwetsbaarheid in de NVD eruit ziet als een percentage van alle gerapporteerde kwetsbaarheden aan het einde van 2020.

Dit perspectief zou ons in staat stellen om objectief te beoordelen hoe zij het als 'grote speler' hebben gedaan met de toegenomen controle die dat met zich meebrengt, en hoe goed zij op een fundamenteel niveau hebben gereageerd om hun vermogen te verbeteren om veiligheidsproblemen op hun manier tot een minimum te beperken.

De onderstaande tabel geeft een samenvatting van de analyse die we in de volgende blogberichten zullen presenteren. Elk product dat we hebben geëvalueerd zal worden besproken in termen van de elementen van doelgericht veiligheidsmodel dat we hebben geconstrueerd.

Update: 12/05/2020Lezers zullen opmerken dat we zijn overgestapt van een eenvoudig 'rating'-model naar een gedetailleerde onderverdeling van specifieke kenmerken en eigenschappen die men zou willen zien in elk van de vier beveiligingsgebieden die werden overwogen. Elk product dat we hebben geëvalueerd zal worden besproken in termen van de elementen van het beoogde beveiligingsmodel dat we hebben geconstrueerd en voor elk element zullen we een splitsing zien van de beveiligingskenmerken die een product zou kunnen bieden, met een indicator of het 'Volledig', 'Gedeeltelijk' of 'Niet' wordt aangeboden.

Gezien onze eerdere opmerkingen over het feit dat 'veilig' geen eenvoudig, binair concept is, hebben we niet geprobeerd om voor elk product een geordende of totale beoordeling te geven. We laten het eerder aan de lezer over om elk element afzonderlijk te onderzoeken en te bepalen welke elementen, en welke soorten functionaliteit en bruikbaarheid, het best geschikt zijn voor hun specifieke behoeften.

U vindt de resultaten ter vergelijking in de onderstaande tabel. Bedenk dat dit niet het hele verhaal is, maar slechts een zeer beknopt overzicht. Om te voorkomen dat we een onvolledig beeld geven zullen we de overzichten van elke tool publiceren samen met een gedetailleerde blogpost waar u de gedetailleerde review kunt vinden.

	: Full support
	: Partial support
	: No support
?	: Not clear to us

Encryption
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)								N/A		N/A
Encryption implementation has withstood scrutiny over time
Authentication
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							?
Offers RBAC							?
Allows passwords to be set for meetings
Allows meeting password security policies to be set
Jurisdiction
Headquarters address	USA	USA	USA	USA	USA	USA	FRA	N/A	USA	N/A
The vendor cannot technically access any data without the client’s consent								N/A		N/A
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							?	N/A	?	N/A
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.								N/A
Security Management
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.									?
Vulnerability Management
Percentage of NVD 2019	0.02	0.01	0.15	0.03	0.00	0.00	0.00	0.00	0.02	0.00
Percentage of NVD 2020	0.08	0.00	0.09	0.02	0.00	0.00	0.00	0.04	0.00	0.01
Vendor discloses which vulnerabilities have been addressed					?
Vendor runs a bug bounty

Bij de beoordeling van de geschiktheid van platforms zoals videoconferenties moeten we niet vergeten dat de term 'veilig' geen precieze definitie heeft. ‘Beveiliging' impliceert de mogelijkheid om een passend niveau van vertrouwelijkheid, integriteit en beschikbaarheid te bieden voor het specifieke geval in kwestie. Met andere woorden - er is geen eenduidig antwoord op de vraag of een communicatieplatform veilig genoeg is - het hangt af van wie het gebruikt en waarvoor. Een familie die in contact wil blijven met dierbaren zal heel andere veiligheidseisen stellen dan een overheid die kabinetsbijeenkomsten wil houden.

Met elk conferentieplatform zal er een functie-, beveiliging-, en  kostenafweging zijn. Sommige platforms zullen op sommige gebieden sterker zijn dan op andere. Voor 'use-cases' waar veiligheid een serieuze zorg is, moet de koper een uitgebreide risico-evaluatie uitvoeren op basis van zijn eigen unieke risicomodel en van daaruit beslissen.

Voor thuisgebruikers zullen de risico's over het algemeen laag zijn en kunnen ze meestal worden beperkt door de beschikbare technische controles (zoals degene die bijna dagelijks worden verduidelijkt en verbeterd door Zoom) of door gewoonweg de technologie  op de juiste manier te gebruiken. Voor de meeste gebruikers is het bijvoorbeeld voldoende om eenvoudigweg te updaten naar de nieuwste versies, een wachtwoord toe te voegen aan vergaderingen en te beseffen dat hun gesprekken niet fundamenteel 'privé' zijn (zoals het geval is met de meeste platformen die ze op het internet gebruiken), om van Zoom een perfect aanvaardbaar platform te maken. Voor een overheid, militair of farmaceutisch bedrijf zou meer nodig zijn, en iets dat meer geschikt is voor bedrijfsgebruik zoals Teams zou meer geschikt kunnen zijn.

Kortom, de beveiligings- en privacyvoorzieningen die we van een technologie verlangen, zijn afhankelijk van ons use-case en bedreigingsmodel. Beveiligingsevaluatie moet beginnen met het overwegen van wat we proberen te beschermen, en tegen wie. Bedrijven moeten deze evaluatie grondig uitvoeren. Thuisgebruikers moeten begrijpen dat ze bijna altijd een bepaald niveau van privacy zullen inruilen, begrijpen de afweging voor de producten die ze gebruiken, hun software up-to-date houden en de beveiligingsfuncties gebruiken die het product biedt.