1. Blog
  2. Cyberdefense
  3. Video killed the conferencing star

Video killed the conferencing star

Een security analyse van videoconferentie-oplossingen voor bedrijven.

Inleiding

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.

Het focussen op “Zoombombing” mist het grote plaatje…

https://twitter.com/zoom_us/status/1250238457944793089/photo/1

Een oplossing die nu veel aandacht krijgt, om goede en slechte redenen, is Zoom. Zoom Video Communications Inc, met het hoofdkantoor in San Jose, heeft in het eerste kwartaal van 2020 meer groei gezien dan in heel 2019. Met deze enorme toename van gebruik is ook een verhoogd niveau van toezicht gekomen, en er is geen twijfel over mogelijk dat Zoom ver onder de maat is gebleven op het gebied van veiligheid en privacy. Terwijl de Zoom-applicatie massaal (en vaak terecht) is bekritiseerd, hoe stapelen de concurrenten zich op? We hebben een analyse gemaakt van verschillende concurrerende videoconferentie-oplossingen om deze vraag te onderzoeken. De reikwijdte van onze analyse zijn bedrijfsgerichte oplossingen – “end user” producten zoals Skype, Discord, Ventrilo, Facetime en Whatsapp zijn niet in aanmerking genomen.

De producten die we zullen analyseren voor deze blogserie zijn:

  • Commercieel:
    • Zoom
    • Microsoft-teams
    • Cisco Webex
    • CiscoWebex-teams
    • Google Ontmoeten
    • Bluejeans
    • Skype for Business
    • Tixeo
  • Opensource:
    • Jitsi Meet
    • BigBlueButton

Update: 12/05/2020

Verschillende correcties en updates zijn door Zoom uitgebracht sinds we aan deze blogserie begonnen zijn, met als hoogtepunt de release van Zoom 5.0 op 27 april. Aangezien sommige van deze veranderingen een aanzienlijke impact hebben op de beveiligingsfuncties en -mogelijkheden van Zoom, hebben we ervoor gekozen om onze samenvattende tabel en analyse hieronder te updaten om een duidelijker beeld te geven van het product zoals we dat nu kennen en om enkele fouten te corrigeren die onder onze aandacht werden gebracht, met excuses aan de betrokken leveranciers!


Update: 01/06/2020

Dit bericht is bijgewerkt en bevat diverse correcties na feedback van Cisco. Er is ook een nieuwe tabel ingevoegd onder het kopje Vulnerability Management om enkele van de meer ‘subtiele’ aspecten van kwetsbaarheid als functie van productbeveiliging vast te leggen, ter ondersteuning van het argument dat kwetsbaarheid telt als een nuttige, maar eendimensionale meting.


Dit is de eerste in een reeks van zes blogposts waarin we de relatieve veiligheid van deze producten onderzoeken. In deze post schetsen we onze aanpak, presenteren we het model dat we in onze evaluatie hebben toegepast en geven we een samenvatting van onze bevindingen. Als u alleen geïnteresseerd bent in het eindresultaat, ga dan gewoon naar de samenvatting aan het eind van dit blog.

We presenteren ook een analyse van het aantal technische beveiligingslekken die de afgelopen twee jaar in deze producten zijn gemeld, in een poging om enige rationaliteit te brengen in de wijdverbreide hysterie rond de recentelijk gemelde kwetsbaarheden rondom Zoom. Onze bevindingen zijn te vinden in de ‘Kwetsbaarheidsvergelijking’ verderop in dit bericht.

In de volgende vijf blogberichten geven we een gedetailleerde analyse van elk van de bovenstaande producten, twee aan twee, tegen een standaard veiligheidsmodel dat we hieronder presenteren. Het blognummer binnen de serie voor elk product staat ook vermeld in de samenvattende tabel.

Videoconferencing: denken over veiligheid

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.

Een doelgericht veiligheidsmodel

We hebben het hieronder getoonde model voor veiligheidseisen ontwikkeld om onze analyse van de veiligheidskenmerken van de verschillende aanbiedingen in deze ruimte te structureren:

Authenticatie Een degelijk bedrijfssysteem moet de mogelijkheid bieden om legitieme gebruikers van het platform te identificeren en te bevestigen en te voorkomen dat anderen ongevraagd binnenkomen. Voor bedrijven betekent dit over het algemeen ook integratie met hun bestaande gebruikersmap, en bij voorkeur ondersteuning voor Single Sign On (SSO). In het moderne beveiligingsklimaat zouden we ook een sterke voorkeur hebben voor systemen die Multi Factor Authenticatie (MFA) ondersteunen.
Encryptie De vertrouwelijkheid van de spraak-, video- en tekstgegevens, die het lokale netwerk, het internet en (mogelijk) de servers van de providers doorkruisen, zijn ook van groot belang. Er zijn twee modellen om hier rekening mee te houden en ze pakken verschillende bedreigingen aan.

Data in transit: Spraak, video en tekst moeten vertrouwelijk zijn, omdat ze het LAN en openbare netwerken tussen de verschillende servers en endpoints in het systeem doorkruisen. De aanname is dat degelijke en geverifieerde encryptiestandaarden zullen worden aangenomen en correct worden geïmplementeerd, en dat de sleutels op de juiste manier worden beheerd.

End to end encryption: De gouden standaard is een ‘End to End’ (E2EE) versleuteling, waarbij het verkeer wordt versleuteld als het de ene user endpoint verlaat en pas weer wordt ontcijferd als het bij de andere aankomt. Cruciaal is dat “E2EE” inhoudt dat de provider geen gegevens kan ontcijferen die hun systemen doorkruisen, zelfs niet met toestemming van de klant of onder dwang van de overheid.

Niet alle gebruikers zullen dezelfde risico-overwegingen hebben en dus zijn beide attributen niet noodzakelijkerwijs een vereiste voor alle klanten.

Regelgeving en rechtspraak De geopolitieke ligging en de rechtsbevoegdheid van de aanbieder spelen een belangrijke rol bij het bepalen van het risico. De aanbieder van een conferentiedienst zal een rechtspersoon zijn die onder de jurisdictie (en dus onder de regelgeving) van een soevereine juridische staat valt. Dat kan niet alleen gevolgen hebben voor het soort beveiligingsnormen dat de verkoper toepast, maar het heeft ook aanzienlijke gevolgen voor de beveiliging van gegevens die door de verkoper kunnen worden opgeslagen of verwerkt, in het licht van mogelijke overheidsinspanningen om toegang tot die gegevens te krijgen.
Beveiligingsfuncties en management Complexiteit is de vijand van de beveiliging en daarom verwachten we dat een essentieel systeem beheerders voorziet van duidelijke en uitgebreide tools waarmee de beveiligingsfuncties kunnen worden begrepen, geïmplementeerd en gecontroleerd.
Kwetsbaarheid en exploitatiegeschiedenis De beveiligingsfuncties en -besturingselementen waarvan een platform beweert dat ze alleen nuttig zijn als die besturingselementen niet kunnen worden ondermijnd door hackers die misbruik maken van kwetsbaarheden in de technologie. We moeten daarom rekening houden met de staat van dienst van de verkoper op het gebied van technische beveiliging, de mate van transparantie en het vermogen om snel en effectief te reageren wanneer er beveiligingsfouten worden gemeld.

 

Kwetsbaarheidsvergelijking

Zoals eerder gezegd, willen we rekening houden met de staat van dienst van de verkoper op het gebied van technische beveiliging, de mate van transparantie en het vermogen om snel en effectief te reageren wanneer er beveiligingsfouten worden gemeld. De subtielere elementen van de beveiligingscultuur en het reactievermogen zullen aan bod komen in onze analyse van de afzonderlijke producten, maar in de tussentijd zullen we de kennelijke staat van dienst van de verschillende leveranciers onderzoeken met betrekking tot het aantal beveiligingslekken dat publiekelijk is gemeld en geregistreerd in de National Institute of Science and Technology (NIST) National Vulnerability Database (NVD).


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.

Samenvatting

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/2020

Lezers 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.

Resultaten tabel

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

 

Zoom Teams Webex
Meetings
Webex
Teams
Google Meet BlueJeans
Encryptie
Gebruikt een geschikt encryptie-algoritme ?
Gebruikt een sterke encryptiesleutel ?
De gegevens worden bij normaal gebruik gecodeerd tijdens het transport
Gegevens blijven gecodeerd tijdens het transport op de servers van de provider ? ?
Stem, video en tekst zijn allemaal gecodeerd
Bestandsoverdrachten & sessie-opnamen zijn versleuteld
De vendor kan de gegevens technisch gezien op geen enkel moment ontcijferen, zelfs niet onder druk van de regelgeving (volledige E2EE)
Encryptie-implementatie heeft het onderzoek in de loop van de tijd doorstaan
Authenticatie
Beheerders kunnen het beveiligingsbeleid voor wachtwoorden definiëren
Ondersteunt MFA als standaard
Kan integreren met Active Directory of vergelijkbaar
Kan integreren met SSO-oplossingen via SAML of vergelijkbaar
Biedt RBAC aan
Maakt het mogelijk om wachtwoorden in te stellen voor vergaderingen
Maakt het mogelijk om het beveiligingsbeleid voor vergaderingen met wachtwoorden in te stellen
Jurisdictie
Adres hoofdkantoor USA USA USA USA USA USA
De vendor heeft technisch gezien geen toegang tot de gegevens zonder toestemming van de klant
Een volledige on-prem versie is beschikbaar voor gebruikers die de vendor niet willen vertrouwen
Voor het gebruik van SaaS kan de klant kiezen in welke landen of politieke regio’s de gegevens worden opgeslagen of verwerkt
Voldoet aan de toepasselijke veiligheidscertificaten (bv. ISO27002 of BSI C5)
Voldoet aan de juiste privacynormen (bijv. FERPA of GDPR)
Biedt een transparantierapport met informatie over verzoeken om gegevens, dossiers of inhoud
Security Management
Biedt andere vormen van toegangscontrole tot vergaderingen, bijvoorbeeld wachtkamers, lock-out, verbieden, enz.
Maakt het mogelijk gedetailleerde controle uit te oefenen op acties binnen de vergadering, zoals het delen van het scherm, bestandsoverdracht, afstandbediening.
Biedt duidelijke centrale controle over alle beveiligingsinstellingen
Maakt het mogelijk om endpointsoftwareversies te monitoren en te onderhouden
Biedt compliance-functies zoals eDiscovery & Legal Hold
Auditing en reporting
Extra content veiligheidscontroles zoals DLP, watermerken, enz.
Vulnerability Management
Percentage van NVD 2019 0.02 0.01 0.15 0.03 0.00 0.00
Percentage van NVD 2020 0.08 0.00 0.09 0.02 0.00 0.00
Vendor maakt bekend welke kwetsbaarheden zijn aangepakt ?
Vendor heeft een bug bounty

Conclusie

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.

Bezoek onze blog de komende dagen opnieuw om onze gedetailleerde analyse van alle tien producten tegen het doelgerichte beveiligingsmodel te lezen en inzicht te krijgen in waarom we de beoordelingen die we hebben toegekend.

Delen