Die Renaissance des DLP : Neue Bereitschaft und Best Practices zur Data-Leakage/LossPrevention

Von Thomas Hemker, Hamburg

Die eigentliche Notwendigkeit, Data-Leakage/Loss-Prevention/Protection (DLP) als geeignete organisatorische Maßnahme mit technischer Umsetzung einzuführen, wurde und wird oft nicht in Zweifel gezogen. Eine (vermeintliche?) Komplexität, die Kosten der Einführung, erwartete Widerstände seitens der Mitarbeiter und die teils fehlende Möglichkeit, wirklichen Nutzen nachzuweisen, standen einer tatsächlichen DLP-Einführung jedoch häufig im Wege. Diese Hindernisse wurden in der Vergangenheit sogar eher gesucht als konstruktiv durch das Sicherheitsprogramm eines Unternehmens gelöst.

Mittlerweile erfordern neue Entwicklungen wie eine verstärkte Cloud-Nutzung (SaaS, PaaS, IaaS) oder die Hinwendung zum mobilen Datenzugriff jedoch zusammen mit neuen Vorschriften (allem voran der DSGVO) sowie der Zunahme öffentlich bekannt gewordener großer Datendiebstähle, dass sich Verantwortliche neu mit dem Thema DLP beschäftigen. Gleichzeitig haben DLP-Lösungen mittlerweile einen höheren Reifegrad erreicht und sind somit auf dem Weg, in den Standardkatalog von Sicherheitsmaßnahmen aufgenommen zu werden – eine gute Zeit also, sich wieder einmal mit einem Best-Practice-Ansatz zu diesem Thema zu beschäftigen.

Definition und Scope

Wie so oft im Leben, sind aber Dinge, die für andere „passen“, für einen selbst nicht zwangsläufig auch anwendbar oder gut. Hier gilt es, sich durch das Vergegenwärtigen grundlegender Fragen und der zugehörigen Antworten den richtigen Rahmen für den Einsatz von DLP im eigenen Haus festzulegen.

Gängige DLP-Definitionen umfassen die Detektion und Verhinderung von Datenverlusten – manchmal wird unter DLP auch die Fähigkeit verstanden, den Zugriff auf Daten generell zu reglementieren. Im Grunde genommen gilt aber, dass DLP-Systeme folgende Kernaufgaben übernehmen:

• Identifikation von Daten, die geschützt werden müssen
• Monitoring der Kanäle, über die solche Daten abhandenkommen können
• Auslösen von Aktionen, um solche Daten zu schützen

Der im Folgenden vorgestellte Best-Practice-Ansatz basiert auf dieser „Definition des kleinsten gemeinsamen Nenners“.

DLP-Lösungen funktionieren in Teilen der digitalen Welt (E-Mail, USB, Web etc.) schon recht gut. Doch was macht man im Spannungsfeld klassischer Kommunikation (z. B. auf Papier) mit neueren Kommunikationskanälen? Soll man seine DLP-Aktivitäten in einen größeren Information-Governance-Rahmen stellen, der dann auch Fragen wie Speicherdauer, Löschung, Backups et cetera behandelt? Welchen Nutzen kann eine DLP-Lösung dabei bringen? Reicht es, eine DLP-Lösung für die automatische Klassifizierung und Detektion sensitiver Daten zu verwenden? Oder will man damit auch aktiv einen erkannten Datenabfluss stoppen beziehungsweise dynamisch weitere Sicherheitsmaßnahmen (z. B. Verschlüsselung) zuweisen? Wie groß ist letztlich der „Scope“ für die gewünschte DLP-Lösung? Muss dieser zwangsläufig „ganzheitlich“ sein oder sollte man sich zunächst mit einem taktischen Ansatz begnügen, um die dicksten Löcher zu stopfen?

Wie so oft in der IT-Security, ist ein wichtiges Thema das Zusammenspiel von Menschen, Prozessen und Technik: Bei DLP ist das womöglich sogar noch wichtiger als in anderen Bereichen, da hier die Regeln, „was“ zu schützen ist, eigentlich immer eine Business-Entscheidung sein sollten – das „wie“ ist dann meist Aufgabe der Informationssicherheit in der IT.

Der ganzheitliche Ansatz ist prinzipiell natürlich richtig, da man idealerweise nur einmal eine Richtlinie für bestimmte Informationen definiert und diese dann in verschiedenen Kommunikationskanälen und Geschäftsprozessen (technisch und organisatorisch) umsetzt. Gleichwohl sind DLP-Projekte, die sich erstmal einen bestimmten Anwendungsfall vornehmen, meist erfolgreicher in der Umsetzung als jene, die gleich „alles“ – und dabei womöglich „zu viel“ – wollen.

Richtlinien-Hoheit

Die Notwendigkeit von Richtlinien ergibt sich sowohl aus der Einhaltung von Vorgaben, die von außen kommen (Gesetze, Regularien, Compliance), als auch aus der Risikobewertung durch Geschäftsverantwortliche, was den Verlust ihrer Daten angeht (z. B. geistiges Eigentum, Patente, Prozesswissen etc.). Solche Richtlinien werden oft in schriftlicher Form an die entsprechenden Mitarbeiter ausgegeben und deren Verständnis wird unter Umständen durch Trainings und Befragungen überprüft.

Für die Umsetzung in einer technischen DLP-Lösung, wie sie im Folgenden skizziert wird, muss man solche Richtlinien allerdings anpassen: Eine organisatorische Richtlinie ist also oft nicht die gleiche wie eine technische DLP-Policy – denn Letztere umfasst häufig bereits Konfigurationen und Einstellungen für konkrete Regeln, die Daten erkennen und schützen sollen.

Bestehend aus Bedingungen, Ausnahmen und Aktionen müssen Richtlinien konsistent sein, damit man definieren kann

• welche Daten gesendet, geposted, hochgeladen, bewegt, kopiert oder abgelegt werden können,
• wohin Daten gesendet werden können,
• wer Daten übertragen und empfangen kann und
• wie Daten geteilt werden.

Diese Bedingungen geben dem DLP-Werkzeug die Anweisung, nach welchen Daten es zu schauen hat und welche Aktionen auszuführen sind. Dabei definiert man sowohl den zu detektierenden Inhalt als auch den zugehörigen Kontext (z. B. Dateityp, Sender, Empfänger etc.). Wird eine Bedingung erfüllt, erzeugt das System einen „Incident“, der als Verletzung der Richtlinie gilt. Eventuelle Ausnahmen frühzeitig zu definieren, ist hierbei wichtig, um möglichst wenig Fehl-Alarme zu produzieren.

Die festgelegten Aktionen bestimmen dann, wie das DLP-Werkzeug weiter vorgeht, um Daten zu schützen: Dies kann vom Logging über die Benachrichtigung von Benutzern, eine Zuweisung von Verschlüsselungs- und Rights-Management-Regeln bis hin zum Blockieren und Löschen reichen. Meist sind Aktionen je nach Risikoeinstufung vorgesehen – überschrittene Schwellenwerte, eine Abweichung vom Normalverhalten sowie die Schwere einer Richtlinienverletzung können dann unterschiedliche Aktionen auslösen.

DLP-Policies werden oft mit Mustern erstellt, die das DLP-Werkzeug mitbringt. Darüber hinaus enthalten Werkzeuge meist auch eine Bibliothek von Richtlinien, die bestimmte Vorgaben von Branchen oder Ländern (z.B. DSGVO oder PCI-DSS) bereits abbilden und auch spezifische Datenformate verstehen und erkennen (z. B. Kreditkartendaten, Ausweisnummern etc.). Richtlinien lassen sich aber auch generisch erstellen und können auf manuelle Klassifizierungen oder beispielsweise OCR- und KI-basierte Einstufungen von Inhalten Bezug nehmen. Vordefinierte Richtlinienmuster sollte man zwar an die Bedürfnisse der eigenen Organisation anpassen, sie liefern aber sehr wohl einen guten Ausgangspunkt für das gesamte DLP-Projekt.

Sofern sie nicht für das gesamte Unternehmen gelten müssen, sollte die Anwendung von Richtlinien auf verschiedene Kommunikationskanäle und Anwendungsfälle dann beispielsweise nach Bedarf, Lokation oder Benutzergruppe erfolgen.

Qualitätskriterien

Schaut man sich die genannten Kernfunktionen einmal genauer an, lässt sich dadurch auch der grundsätzliche Aufbau des DLP-Systems beschreiben und verstehen: Die Identifikation der schutzwürdigen Daten ist sehr wichtig. Denn zumeist muss nicht jede Information im Unternehmen besonders gesichert werden, sondern man beschränkt sich besser auf bestimmte sensitive Daten und weist diesen je nach Typ und Inhalt unterschiedliche Richtlinien zu.

Klassifizierung

Meist werden dabei folgende Arten sensitiver Daten unterschieden: personenbezogene Daten, Kundendaten, geistiges Eigentum, Prozessdaten, Geschäftsdaten, Finanzdaten, Gesundheitsdaten sowie Vertriebs- und Marketinginformationen. Natürlich kann man auch generell von „vertraulichen Informationen“ sprechen – das umfasst dann aber sehr viel mehr als nur den Schutz der sogenannten Kronjuwelen, also derjenigen Daten, die wirklich wichtig für den Erfolg und das Fortbestehen einer Organisation sind.

Die Verfahrensweisen zur Identifikation von Daten sind essenziell für den Erfolg eines DLP-Projekts: Nur wer möglichst alle Daten findet, die es zu schützen gilt, kann erfolgreich ein DLP-Programm umsetzen! Für gewöhnlich findet man in den einschlägigen Lösungen dafür folgende Methoden:

• Abgleich mit definierten Inhalten, der durch reguläre Ausdrücke, spezifizierte Textstrings, Schlüsselwörter, Muster oder Wörterbücher erfolgt – hierzu zählen auch das Auffinden von Kreditkartennummern oder Metadaten (z. B. der Klassifizierung als „vertraulich“) in Dateien
• Indexierung von Daten mittels „Fingerprinting“ durch einen oder viele kryptografische Hashes von Informationen, damit die DLP-Lösung diese später auch dann findet, wenn nur Teile davon erkannt werden – diese Methode lässt sich sowohl für strukturierte als auch für unstrukturierte Daten verwenden, erfordert aber eine gewisse Vorbereitung der Daten
• Verfahren des maschinellen Lernens werden eingesetzt, um mit statistischen Methoden anhand von Trainingsdaten in Beispieldokumenten einen Klassifizierungsmechanismus zu erstellen – diese dienen beispielsweise dazu, um vertraulichen (eigenen) Sourcecode von Open-Source-Bibliotheken zu unterscheiden
• Verfahren der Bilderkennung wie Optical Character-Recognition (OCR) oder zur Texterkennung – damit lassen sich Screenshots oder andere Bilder auf vertrauliche Informationen hin untersuchen

Überwachung

Das Monitoring von Daten sollte natürlich alle Kanäle abdecken, die benutzt werden können, um vertrauliche Daten abfließen zu lassen. Dies umfasst Kommunikationsprotokolle wie E-Mail, Webanwendungen über HTTP/HTTPS, Instant-Messaging, Dateitransfer sowie Speichermedien (z. B. CDs, USB-Sticks etc.), aber auch unverschlüsselte und öffentlich zugängliche Cloudspeicher. Durch das eigentliche Monitoring lassen sich die Datennutzung kontrollieren, das damit verbundene Risiko besser verstehen und Abflussquellen aufdecken. Ein Datenabfluss kann dabei vielfältige Gründe haben, die von der Exfiltration von Informationen durch gezielte Angriffe über den Missbrauch durch gefährliche Insider bis hin zu Mitarbeitern reichen, die einfach gerne am Wochenende weiterarbeiten möchten und dazu private Ressourcen nutzen, an die sie die Daten senden. In diesem Sinne ist es auch wichtig, das DLP-Monitoring an den Mitarbeiterdatenschutz anzupassen und hier geeignete Mechanismen (z. B. Vier-Augen-Prinzip, Anonymisierung etc.) zu verwenden, die gängige Lösungen in diesem Bereich durchaus auch unterstützen.

Re-Aktionen

Aktionen, die DLP-Lösungen ausführen oder anstoßen, sollten einen ungewollten Datenabfluss nicht nur erkennen, sondern auch verhindern können. Sollte eine Verletzung einer Richtlinie festgestellt werden, führt ein DLP-Werkzeug meist eine Aktion aus, die einer der Kategorien „Loggen“, „Benachrichtigen“ oder „Blockieren“ zuzuordnen ist. Die Scharfschaltung dieser Aktionen erfolgt meist sequenziell, damit Richtlinien zwar aktiv sind, aber initial keine wichtigen Geschäftsprozesse stören, sondern diese mit der Zeit immer strikter absichern. Insofern startet man idealerweise mit dem reinen Logging, welches einem Monitoring gleichzusetzen ist, um erkannte Vorfälle (bzw. Fehlalarme) zu analysieren.

Nachdem man dann mit der Zeit die Richtlinien weiter angepasst und „feingetunt“ hat, kann man, sobald diese wie gewünscht funktionieren, damit beginnen, Benachrichtigungen an einzelne Benutzer zu senden, die über die Richtlinienverletzung aufklären. Hierbei gibt es natürlich unterschiedliche Ausprägungen der Benachrichtigungskette (z. B. Information an den Manager bei wiederholten Verstößen), die organisatorisch einzurichten sind. Solche Benachrichtigungen werden meistens per E-Mail oder als Pop-up ausgeliefert und enthalten Information über die beeinträchtigte Richtlinie sowie gegebenenfalls Links zu Trainings und Wahlmöglichkeiten für den Benutzer.

Ein Blockieren kennt nochmals unterschiedliche Stufen. Hier unterscheidet man zwischen „weichem“ und „hartem“ Blocken sowie weiteren Aktionen: Ein hartes Blocken greift aktiv ein und verhindert etwa den Versand von E-Mails, einen Up- oder Download, das Kopieren und Drucken oder löscht gar eine Datei. Als weiches Blocken beschreibt man hingegen das Bewegen von Dateien in andere (sichere) Speicherorte, die Quarantäne von E-Mails (zum späteren Genehmigen) sowie das Redigieren vertraulicher Informationen aus Webposts und E-Mails, bevor diese versendet werden können.

Andere Aktionen umfassen sowohl ein visuelles Markieren (Tagging) als auch die Veränderung der Zugriffsrechte einer Datei. Oft gehen sie auch noch einen Schritt weiter und binden weitere Sicherheitsmaßnahmen ein, die entweder per Skript oder mittels API-Zugriff gesteuert werden. Dies umfasst beispielsweise die Anwendung von Verschlüsselung, aber auch von Digital-Rights-Management (DRM) auf Dateien und E-Mails.

Architektur und Aufbau

Marktübliche DLP-Werkzeuge wenden, abhängig davon, ob sich die betrachteten Daten in der Übertragung („Data in Motion/Transit“), in Benutzung („Data in Use“) oder an einem Speicherort befinden („Data at Rest“), verschiedene Techniken für das Monitoring an (vgl. Abb. 1).

Bei Daten, die sich über Netzwerke und Dienste (E-Mail, Web, Dateitransfer etc.) in der Übertragung befinden, kommt neben dem sogenannten Sniffing und der Netzwerkanalyse auch eine tiefergehende Inspektion einzelner Pakete zum Einsatz, um vertrauliche Informationen darin finden zu können.

Auf Endgeräten der Nutzer können installierte Agenten sowohl die Aktivitäten einer Datei kontrollieren als auch durch Einbindungen in verschiedene Programme vertrauliche Informationen schützen. In Speichernetzwerken und -infrastrukturen (Server, Datenbanken, Clouddiensten etc.) können DLP-Werkzeuge nach Dateien und Informationen scannen (zeitgesteuert oder bei Zugriff), Metainformationen erhalten und DLP-Richtlinien anwenden. Diese sind entweder direkt auf den Speichersystemen installiert oder operieren von Remote-Rechnern aus. Der Zugriff auf Cloudspeicherdienste wird häufig – mittels API-Unterstützung der Clouddienste – durch die Integration in einen sogenannten Cloud-Access-Security-Broker (CASB) realisiert.

Der technische Aufbau eines DLP-Systems und die Integration in die bestehende Infrastruktur bedürfen einer sorgfältigen Planung. Ein typisches System umfasst dabei verschiedene architektonische Komponenten: Im Netzwerk, in der Cloud, am Endpunkt und in der Speicherinfrastruktur sind jeweils Mechanismen sowohl für das Monitoring als auch für Aktionen installiert, die zentral von einer Verwaltungsinstanz mit Richtlinien versorgt werden und Vorfälle an diese zurückmelden.

Die zentrale Instanz umfasst ein rollenbasiertes Administrationskonzept, um verschiedenen Funktionen innerhalb der Organisation die passenden Rechte und Ansichten zuzuweisen. Eine Integration in Service-Management-Systeme (Helpdesk, Ticketing etc.) ist ebenfalls sinnvoll, obwohl viele Systeme neben dem zentralen Logging, Reporting und der Alarmierung auch eine Vorfallbehandlung ermöglichen.

Mehr als Technik

Trotz der vielen Komponenten bei vollem Ausbau eines DLP-Systems macht in den meisten DLP-Projekten der Anteil der Inbetriebnahme von technischen Komponenten nur etwa ein Viertel der Aktivitäten aus – der Rest findet organisatorisch auf der Geschäftsebene statt. Wie schon erwähnt, beginnen die meisten Projekte, die einen bestimmten Anwendungsfall behandeln, nur mit dem zentralen System und einer weiteren Komponente, um diese mittels DLP zu schützen.

Die technische Implementierung von DLP-Verfahren, ihre Integration in bestehende Systeme, Infrastrukturen und Anwendungen sowie weitere Sicherheitsmaßnahmen reichen allein aber nicht aus, um ein DLP-Projekt erfolgreich zu machen. Erst ein umfassendes DLP-Programm kann hier ein wirkliches Businessproblem und nicht nur eine technische Herausforderung lösen. Die wesentlichen Merkmale eines solchen DLP-Programms sind Governance, Vorbereitung und Implementierung:

• Die Governance umfasst die Unterstützung seitens des Managements, die Definition der Ziele des DLP-Programms und die Zuweisung von Rollen und Verantwortlichkeiten.
• Zur Vorbereitung sollten Verantwortliche aus den Geschäftsbereichen involviert werden, man nimmt eine Priorisierung der zu schützenden Daten vor, wählt DLP-Verfahren und -Werkzeuge aus und plant die Integration in die bestehende Umgebung. Die Datenklassifizierung kann innerhalb der Vorbereitung eine wichtige Rolle spielen: Unternehmen, die bereits ein Klassifizierungsschema haben und eventuell mit einer manuellen Lösung arbeiten, um Dokumente mit Vertraulichkeitsstufen zu kennzeichnen, erleichtern sich sowohl das Erstellen von Richtlinien als auch deren Zuweisung, da DLP-Lösungen solche Metadaten auslesen und Aktionen zuweisen können.
• Die Implementierung des Programms beschäftigt sich dann mit der Steigerung des Bewusstseins für Datensicherheit, der Reaktion auf Richtlinienverletzungen sowie Vorfälle und der schrittweisen Inbetriebnahme der eigentlichen DLP-Lösung. Da das DLP-Programm meist eher pragmatischer Natur ist und gegebenenfalls nur das Ziel verfolgt, bestimmte vertrauliche Daten zu schützen, sollte man es als ein Element in der übergeordneten Datensicherheitsstrategie oder Information-Governance eines Unternehmens betrachten. Die Implementierung eines DLP-Programms ist darüber hinaus eine Aufgabe, die nicht mit der Inbetriebnahme eines Werkzeugs endet, sondern von fortwährender Begutachtung, Anpassung und Verbesserung gekennzeichnet ist.

Fazit

Die erfolgreiche Inbetriebnahme von DLP-Verfahren setzt sowohl ein DLP-Programm als auch die Auswahl eines geeigneten ersten Anwendungsfalls voraus. Ein ganzheitlicher Ansatz bei der Auswahl eines geeigneten Werkzeugs samt vieler Integrationsmöglichkeiten ist sehr wichtig – denn er ermöglicht die Nutzung erstellter Richtlinien auch für weitere Szenarien. Eine inkrementelle Erweiterung ist hier empfehlenswert. Auf der organisatorischen Seite sind die Unterstützung durch das Management sowie der ständige Austausch mit den Eignern der Daten (also dem „Business“) wichtige Erfolgsfaktoren.

Letztendlich liefert die erfolgreiche Umsetzung eines DLP-Projekts nicht nur Compliance zu bestimmten gesetzlichen Vorgaben, sondern ermöglicht Unternehmen, ihre Werte und Reputation aktiv zu schützen. Die Kosten, die mit einem Datenabfluss verbunden sind, wären in den meisten Fällen ungleich höher als diejenigen für eine DLP-Implementierung. ■

Thomas Hemker (CISSP, CISM, CISA – @THeSecurityInfo) ist Director Security Strategy im CTO-Office der Symantec (Deutschland) GmbH.