Data Loss Prevention (DLP): Wie schützen Sie sich vor Datenabfluss in der Cloud?

Die Nutzung von Public Cloud Services wie Microsoft 365 als digitaler Arbeitsplatz nimmt in Schweizer Unternehmen stetig zu. Immer mehr Daten werden in die Cloud ausgelagert, gleichzeitig steigen die Anforderungen an den Datenschutz.

Denn trotz der Auslagerung von Daten in die Cloud bleibt die Verantwortung für den Datenschutz und die Datensicherheit bei den Unternehmen. Diese müssen sicherstellen, dass sie alle regulatorischen und gesetzlichen Anforderungen erfüllen. Mit dem Inkrafttreten des revidierten Bundesgesetzes über den Datenschutz (nDSG) am 1. September 2023 werden diese Anforderungen weiter steigen. Angemessene technische und organisatorische Massnahmen zum Schutz von Personendaten werden verlangt.

Was ist Data Loss Prevention?

Um vertrauliche Personendaten zu schützen, wird in diesem Zusammenhang häufig der abstrakte Marketing-Begriff «Data Loss Prevention» oder auch «Data Leak Prevention», kurz «DLP», verwendet. Unter DLP versteht man Strategien sowie hard- oder softwarebasierte Lösungen, die den ungewollten Abfluss von Daten verhindern.

Insbesondere im Umfeld von Microsoft 365 (M365) dominiert die Annahme, mit der integrierten DLP-Lösung Purview die Anforderungen lückenlos abdecken zu können. In der Praxis zeigt sich jedoch, dass viele Unternehmen Schwierigkeiten mit den DLP-Standardprodukten der Hersteller (nicht nur von Microsoft) haben.

Einsatzgebiete von DLP und der Weg zum ISO-Standard 27002

Literatur zum Thema DLP zu finden, ist wahrlich ein schwieriges Unterfangen und sollte diese noch auf Deutsch sein, kann man relativ schnell mit der Suche aufhören. Die grossen DLP-Anbieter Forcepoint, Symantec (jetzt Teil von Broadcom) oder Trellix (früher McAfee) verwenden jeweils ihre eigene Terminologie, die auf ihren Webseiten mehr oder weniger gut beschrieben ist.

Auch auf den Webseiten anderer Hersteller, die keine eigenständigen DLP-Suiten anbieten, sondern DLP als Zusatzfunktionalität in ihre bestehende Systemlandschaft integriert haben, wie z.B. Microsoft, finden sich Beschreibungen zur nativen DLP-Lösung Purview, die primär in der Lage ist, die M365-Plattform auf mögliche DLP-Verstösse zu scannen.

Ein DLP-System kann unerwünschten Datenabfluss über drei verschiedene DLP-Kanäle verhindern. Dazu gehören die Datenkanäle:

• Data at Rest (Daten im Ruhezustand): z.B. wenn Dateien in der Cloud, auf einem Fileserver oder Daten in Datenbanken gespeichert sind.
• Data in Motion (Daten während der Übertragung): z.B. wenn Daten per E-Mail ausgetauscht oder via Browser ins Internet hochgeladen werden.
• Data in Use (Daten in Verarbeitung): z.B. wenn Daten auf dem Endgerät verarbeitet, auf externen Speichermedien (USB) gespeichert oder ausgedruckt werden.

DLP hat als technische Massnahme auch Eingang in den aktualisierten und weltweit anerkannten Informationssicherheitsstandard ISO 27002:2022 (Kapitel 8.11) gefunden. Mit der zunehmenden Nutzung von Cloud-Diensten und mobilen Endgeräten gilt es, dem Risiko eines möglichen Datenverlustes auf verschiedenen Ebenen wie Web, Netzwerk oder Endgeräten, die sensible Informationen verarbeiten, mit DLP als Schutzmassnahme Rechnung zu tragen.

Out-Of-the-Box DLP-Lösungen wie Purview von Microsoft helfen nur bedingt

Die Basisfunktionalitäten (Event-Erkennung auf Basis von Standard-Runbooks) der am Markt angebotenen DLP-Produkte sind massentaugliche Lösungen, um möglichst viele Kunden mit einer «Starter-Lösung» bedienen zu können. Doch zwei wesentliche Aspekte wie das Incident- und Policy-Management werden von den Standard-DLP-Produkten nur unzureichend abgedeckt. Da diese beiden Anforderungen sehr kundenspezifisch sind, reicht die Basisfunktionalität hier meist nicht aus.

Das Incident Management ist bei den meisten DLP & SIEM Lösungen primär eine Arbeitsliste. DLP Sicherheitsvorfälle werden wie andere Sicherheitsvorfälle behandelt. DLP-Events sind aber deutlich näher am Business zu adressieren als technische IT-Events. Hinzu kommt, dass die meisten Lösungen auf rollenbasierten Access-Modellen (RBAC) basieren und damit eine organisatorisch dezentrale Bearbeitung von DLP Incidents erschweren.

Je nach Art des Sicherheitsereignisses führt dies zu hohen manuellen Aufwänden, da ein DLP-Fall n Incidents erzeugen kann. Ohne Automatismen im Bereich des Incident- bzw. Case-Managements ist der Bearbeitungsaufwand pro Event massiv höher.

Im Bereich des DLP Policy Managements ist die Datenlogistik sowohl bei der initialen Implementierung als auch im operativen Betrieb ein zentraler Aspekt. Bei der Datenlogistik geht es darum, die Rohdaten aus den Quellsystemen wie z.B. CRM zu exportieren, zu aggregieren, zu bereinigen (bessere Datenqualität für Suchindexe), zu selektieren und nach der Indizierung in das DLP Management System zu importieren.

Eine Automatisierung ist aufgrund der wiederkehrenden Tätigkeiten im Bereich der Datenlogistik für die Unternehmen alternativlos. Zudem müssten bei einer manuellen Lösung die für die Indexierung notwendigen Daten wie Kundenname, Adresse oder IBAN-Nummer an den externen Dienstleister weitergegeben werden. Aus Gründen der Vertraulichkeit wäre dies für die meisten Unternehmen keine Option.

Bessere Erkennung mit «Fingerprinted Policies» statt «Regular Expressions»

Es gibt verschiedene Arten von DLP-Policies, die helfen, kritische Daten zu identifizieren und dann nach vordefinierten Regeln eine Aktion wie z.B. «Blockieren» auszulösen. Zu den bekanntesten gehören deskriptive Suchmuster-Policies, die auf «regulären Ausdrücken», also typischen Zeichenketten, basieren.

Ein gutes Beispiel für ein Muster mit solchen Eigenschaften ist die IBAN-Nummer. IBANs sind in der Schweiz 21-stellig und werden in der Korrespondenz in 4er-Blöcken dargestellt. Auch wenn es nicht sofort ersichtlich ist, folgen diese 21 Zeichen einem bestimmten Muster. So sollte eine Schweizer IBAN-Nummer (z.B. CH99 0099 0999 0123 4567 9) immer mit Leerzeichen und ohne Sonderzeichen (z.B. Trennzeichen) geschrieben werden, da es sonst zu vielen False-Positives kommen kann. Auch sollten Einschränkungen in den Suchmustern definiert werden, so dass z.B. private IBAN-Nummern von Mitarbeitenden nicht analysiert und blockiert werden.

Eine wesentlich genauere Erkennung bieten so genannte «Fingerprint-Policies», auch Listen-Policies genannt. Für die Indexbildung werden Rohdaten z.B. aus CRM-Systemen benötigt. Danach werden die definierten Rohdaten wie z.B. Kundenname, Adresse oder Kontonummer in «Blacklists» mit einem Hash-Wert zur eindeutigen Identifikation ergänzt. Die Erkennung dieser Daten, z.B. in einer E-Mail oder in Office-Dokumenten, erfolgt über eine Inhaltsprüfung. Beim Scannen der Daten oder Dokumente wird ein Hash-Wert gebildet und mit den bei der Indexierung erzeugten Hash-Werten verglichen. Bei einer Übereinstimmung wird ein Treffer erzielt und entsprechend eine vordefinierte Aktion ausgeführt.

DLP Incident Management nach der Fan-In oder Fan-Out Strategie

Da die erzeugten DLP Incidents den grössten Aufwandsblock im operativen Betrieb darstellen, ist es wichtig, eine kostensparende Bearbeitungsstrategie zu haben. Grundsätzlich wird zwischen einer eskalierenden Bearbeitung (Fan -In) und einer delegierenden Bearbeitung der Incidents (Fan -Out) unterschieden. Je nach Unternehmensgrösse können beide Strategien angewendet werden.

Generell ist eine dezentrale Lösung zu bevorzugen, da die meisten DLP-Vorfälle im Rahmen von «gebrochenen» Geschäftsprozessen auftreten und die Vorgesetzten am besten beurteilen können, ob der Vorfall false/positiv ist oder weiter analysiert werden muss. Hinzu kommt, dass eine Integration des DLP Incident Managements in einen klassischen IT Service Desk aufgrund der meist fehlenden Ressourcen nicht sinnvoll wäre, da ohnehin schon genug IT Anfragen und Störungen kanalisiert werden.

DLP Incident- und Policy Management à la carte?

Nun kann man sich die Frage stellen, ob es überhaupt eine DLP-Suite am Markt gibt, die sowohl technisch DLP-Vorfälle mit verschiedenen Policy-Typen (wie z.B. Exact Data Match, Waiver-Mapping etc.) erkennt und gleichzeitig automatisierte Prozesse zu den Themen Incident Management und Policy Management bietet und damit das Ganze im operativen Betrieb verdaulich und umsetzbar macht. Leider ist die Antwort bei den bisherigen Marktanbietern NEIN.

Wie oben beschrieben, stossen die Basisprodukte der grossen Anbieter an ihre Grenzen. Glücklicherweise gibt es speziell im Schweizer Markt DLP Integratoren wie z.B. die Firma e3 (nicht zu verwechseln mit Microsoft E3 Lizenzen :)), welche diese Basisfunktionalitäten mit ausgereiften automatisierten und flexibel gestalteten Funktionen insbesondere im Bereich Incident und Policy Management erweitern. Eine Auswahl an vorgefertigten EDM Policy Sets und automatisierten Incident Management Prozessen steht à la carte zur Verfügung, anstatt diese komplett mit den Bordmitteln der Anbieterlösung abbilden zu müssen. Auch dann bliebe die Herausforderung einer Multi-Cloud-Strategie bzw. der Abdeckung externer SaaS-Lösungen ungelöst. Mit einer Kombinationslösung aus einem DLP-Basisprodukt und einer Erweiterung mit der e3 DLP-Lösung kann jedes gewünschte Schutzniveau erreicht werden.

Fazit

Die Bedeutung von Datenschutz und Datensicherheit nimmt in der Cloud noch einmal deutlich zu. Grundlegende Abwehrmaßnahmen wie IAM (Access Management) oder ein IDS (Intrusion Detection System) reichen nicht mehr aus, um beabsichtigte oder unbeabsichtigte Datenabflüsse zu erkennen und ggf. präventiv zu verhindern. Eine ausgereifte DLP-Lösung mit automatisierten Prozessen im Bereich Incident- und Policy-Management kann hier wesentliche Abhilfe schaffen. Natürlich sind neben DLP weitere flankierende Massnahmen wie Datenklassifizierung, Rechtemanagement oder ein CASB (Cloud Access Security Broker) notwendig, um einen umfassenden Informationsschutz zu gewährleisten.