Cisco Spark en cloud-security

Cisco Spark is Cisco’s cloudgebaseerde Collaboration-dienst die Messages, Meetings en Calls combineert. Spark is dus onder andere een berichtendienst. Maar zodra je ‘cloud’ en ‘bedrijfsgegevens’ in dezelfde zin noemt, komt onvermijdelijk de vraag: “hoe veilig is dat?”

Laten we, om deze vraag te beantwoorden, eens kijken naar de verschillende soorten van messaging-services, en hoe Cisco Spark zich hierin onderscheidt.

Cisco Spark 1

De eerste groep: chat-apps voor consumenten

Voor consumenten zijn er diverse apps beschikbaar. Het zijn de chat-apps die je gebruikt om een buurtbarbecue te organiseren. Maar ze worden ook gebruikt door medewerkers, als er geen zakelijk alternatief is. En dat kan lastig zijn voor bedrijven die graag een vorm van controle hebben: want wat voor gegevens wisselen uw medewerkers uit en met wie? Als er later discussie over een bericht is, kunt u dat gewiste bericht dan terugvinden? Is het te herstellen als iemand per ongeluk iets naar de verkeerde ontvanger stuurt? En wordt er in chats niet gesproken over dat hyper-geheime project dat we aan het doen zijn?

De apps zijn er meer en meer op gericht om de privacy van de consument te beschermen, door chats niet op te slaan en het verkeer tussen clients te versleutelen. De consumenten-apps zijn dus behoorlijk secure, maar voldoen niet voor toegang tot de gegevens van een Enterprise. En zo komen we bij de tweede groep.

Groep 2: traditionele apps voor business-messaging

In deze groep zitten de traditionele Enterprise messaging-apps die de afgelopen jaren uit zijn gekomen; in eerste instantie met lokale opslag en inmiddels ook beschikbaar als cloudvariant. Communicatie tussen de client en server verloopt via een secure tunnel, en data wordt versleuteld op de harddisk of cloudstorage-locatie opgeslagen. Een op het eerste gezicht ideaal model.

Het addertje onder het gras (of in de cloud) zit hem in het security-model: communicatie tussen client en server is secure *EN* de opslag is secure, maar als je er wat dieper op ingaat, besef je dat berichten vrij leesbaar zijn op het moment dat ze aankomen bij de messaging-service. De service heeft dit nodig om een aantal functies uit te voeren, zoals indexing (voor zoekopdrachten), statistieken, compliancy en logfiles. Dit gebeurt allemaal op volledig onbeveiligde en leesbare berichten. Pas op het moment van opslag wordt weer vertrouwd op encryptie van het onderliggende operating system.

Maar wacht. Als ergens een fout gemaakt wordt en logfiles worden op de verkeerde plek neergezet, back-ups worden verkeerd verwerkt of zoek-indexen komen beschikbaar, dan ligt alle Enterprise-data op straat. Fouten zijn menselijk en als je kijkt naar het aantal recente data breaches, dan komt dit vaker voor dan je denkt. Voor wie de site niet kent: kijk eens op https://haveibeenpwned.com.

Interne en externe communicatie

Een andere uitdaging bij een hoop traditionele Enterprise messaging-apps is dat ze gemaakt zijn om *binnen* een organisatie te werken. Chatten tussen collega’s is prima geregeld. In de wereld van vandaag werken we echter ook veel samen met mensen buiten het bedrijf. Sommige systemen staan federatie toe, maar dan moet het chatsysteem aan de andere kant hetzelfde zijn. Sommige integreren met e-mail en voor sommige zijn interop-services beschikbaar. Het nadeel van al deze opties is dat op bijna alle koppelingen de data onversleuteld is, of dat je accountgegevens vrij moet geven aan de interop-dienst. Verre van ideaal.

In deze omgeving zijn zaken als Enterprise compliancy en data sovereignty wel simpel te regelen: data kan je opslaan op een lokale server of nationale cloudopslag, en omdat alle data binnen de messaging-service onversleuteld is, is compliancy of het meekijken en loggen van verkeer simpel. En toch klopt er hier gevoelsmatig iets niet. Het is alsof het postkantoor elke brief openmaakt, hoofdschuddend bekijkt, in een nieuwe envelop doet en dan pas doorstuurt naar de bestemming.

Kortweg kun je dus zeggen dat business messaging-apps secure zijn, compliancy en logging zijn eenvoudig, maar omdat de data onversleuteld door de service heengaat, is de kans op lekken altijd aanwezig.

En dan is er Cisco Spark

Cisco heeft Cisco Spark ontwikkeld met een simpele opdracht aan het ontwikkelteam: de data van onze klanten moet op geen enkel moment onversleuteld op onze systemen beschikbaar zijn. Nooit. Er mag geen enkel punt in de backoffice-architectuur zijn waar we mee kunnen kijken naar de chats van onze klanten.

Het Cisco Spark-team noemt dit ‘Just Right’-datasecurity: een hoog niveau van encryptie, inclusief de compliancy-features die IT zoekt.

Cisco Spark 2

Simpele opdracht, toch?

Nou… Ja en nee. Het is simpel als je de aanpak van de consumenten-apps kiest, maar dan kun je geen persistent chat maken (waar de data centraal opgeslagen wordt), het indexeren van data (waarmee zoekopdrachten werken) wordt onmogelijk en Enterprise compliancy is ineens ook een probleem. Wat een simpele opdracht leek, bleek een behoorlijke – maar oplosbare – uitdaging.

Het basisidee is simpel: berichten worden door de endpoints versleuteld met een unieke cryptokey. De berichten worden versleuteld getransporteerd, versleuteld opgeslagen, versleuteld verplaatst naar de bestemming en pas daar heeft de ontvanger zijn eigen sleutel om de data weer zichtbaar te maken. Op deze manier loopt de data wel door Cisco’s services en clouddiensten heen, maar die data is onzichtbaar voor iedereen zonder sleutel. Nu praten we over een postkantoor waar de enveloppen niet opengemaakt worden. Sterker nog, de enveloppen kúnnen niet eens open.

Cisco Spark 3

Het mooie van dit concept is dat de sleutels onafhankelijk van de data getransporteerd en uitgegeven worden, en dat een klant er ook voor kan kiezen om zelf het key-management te verzorgen. In dat geval is de klant de enige partij die sleutels beheert om berichten zichtbaar te maken, en Cisco heeft alleen het beheer over encrypted berichten.

Zoals eerder gesteld levert dit een hoop interessante uitdagingen op op het gebied van indexeren, samenwerken met derde partijen, toegang voor BOTs en andere applicaties. Indexeren gebeurt bijvoorbeeld daar waar de keymanagement-server staat. Als een klant zijn eigen keys beheert, wordt ook dáár de cleartext indexing gedaan. De resultaten worden vervolgens encrypted, en alleen de gesalte, gehashte en encrypted zoekindex gaat terug naar de Cisco Spark-cloud voor een enorm efficiënt zoekalgoritme. Hetzelfde geldt voor externe integraties of applicaties: een Enterprise maakt zelf een whitelist van applicaties die mogen integreren en alleen applicaties met de juiste rechten krijgen een sleutel van de keymanagement-server.

Bij het werken met externe partijen, hetzij via API’s, de (mobiele) Spark-applicatie of de HTML5-webapplicatie, worden keys in samenspraak door diverse keyservers beheerd en uitgegeven, waardoor elke partij controle heeft over zijn eigen encryptie.

Dit en veel meer is beschreven door het ontwikkelteam in het ‘Cisco Spark Security and Privacy’-whitepaper – overigens ook voor niet-security-experts een zeer leesbaar document: http://www.cisco.com/c/dam/en/us/solutions/collateral/collaboration/cloud-collaboration/cisco-spark-security-white-paper.pdf

Cisco Spark 5

Security gaat verder dan chats

Het model stopt niet bij chats. Dezelfde security wordt gebruikt voor encryptie van bestanden en interactieve whiteboards. De whiteboarding-sessie op een Spark Board, iPad, laptop, etc. is alleen live te volgen of later op te roepen op endpoints die een sleutel hebben, en nergens anders.

Cisco Spark 6

Ook op het gebied van data-compliancy levert het unieke mogelijkheden op: de compliancy-service heeft toegang tot de versleutelde data, maar de keyserver bepaalt wat daarvan zichtbaar is. In omgevingen waar data gedeeld wordt tussen verschillende bedrijven, is het mogelijk het model zo in te regelen dat compliancy-servers en medewerkers alleen de data zien van hun eigen bedrijf, en geen niet-publieke data van andere bedrijven, ook al wordt dit gedeeld in dezelfde Spark-space.

Compliancy-whitepaper

Over compliancy is ook een fascinerend whitepaper beschikbaar. Op dit moment is dit alleen intern beschikbaar voor Cisco Partners en klanten, maar neem contact met ons op en we gaan er graag verder op in!

Meer links:

Laat een reactie achter