Seit Jahren weiss man nun, dass interne Mitarbeiter ein erhebliches Risiko mitbringen, wenn es um das Thema Datenabfluss geht. Einen Lösungsansatz für dieses Problem bieten Data Leakage Prevention Tools (DLP). Einer der schlagenden Argumente dieser Tools ist die Möglichkeit Datenabfluss automatisiert zu unterbinden (Blocking-Rules). Das hört sich fast zu gut an, um wahr zu sein. Nach der Implementation eines DLP Tools einfach die vordefinierten Rules zu aktivieren, dann einige Wochen im Monitor-Mode das Verhalten prüfen und sogleich in den Blocking-Mode wechseln und die Risiken sind effektiv minimiert. Nein, so einfach ist es nicht. In Wahrheit gibt es kaum Unternehmen auf Enterprise Level, welche es wagen, den Blocking Mode auch nur ansatzweise scharf zu stellen.

Warum auf Blocking verzichtet wird

Einfach gesagt, weil die DLP-Rules ungenau sind und damit zu viele False Positives (FP) generieren. Zu viele wichtige Geschäftsprozesse würden durch das Blocken von FPs behindert oder sogar verunmöglicht werden.

Dafür kann es sehr verschiedene Gründe geben. Angefangen bei grundlegen Falschannahmen, wie eine DLP-Lösung einzusetzen ist. Bis hin zu sehr komplexen Schutzobjekten, die man nicht einfach in einer trivialen DLP-Rule beschreiben kann.

Drei Falschannahmen

1. DLP-Tools schützen das Unternehmen vor Datenabflüssen: Der Name Data Leakage Prevention ist vermeintlich und täuscht über den wahren Wert einer DLP-Lösung hinweg. Werden die grundsätzlichen Massnahmen zum Schutz von Daten (technisch und organisatorisch) nicht schon gut oder sehr gut umgesetzt, nützt eine DLP Lösung zum Schutz vor Datenabfluss wenig bis nichts. DLP könnte man eher als Controlling Tool betrachten. Ein gute DLP-Implementation zeigt einem auf, welche der bereits umgesetzten Massnahmen Lücken aufweise oder an welchen Stellen noch keine Massnahmen existieren. Daraufhin kann an diesen nachgebessert werden. Ein solcher oder ähnlicher Gedanke sollte die Definition von DLP-Rules vorantreiben.
2. Blocking-Mode ist das Ziel: Wie zuvor erwähnt, ist es wertvoller zu verstehen, welche Prozesse oder technischen Massnahmen Lücken aufweisen, um diese dann auch sinnvoll adressieren zu können. Ab einer hohen Maturität kann das Blocking bei sehr effektiven DLP-Rules natürlich als erstrebenswertes Ziel gesetzt werden
3. DLP-Projekte sind IT-Projekte: Wer glaubt, dass eine IT-Abteilung effektive und sinnvolle DLP-Rules definieren kann, der könnte sich irren. Die Kompetenz der Definition der Schutzobjekte, welche in den DLP Rules Abgebildet werden sollen, liegt bei den Risk und Business Abteilungen. Ohne deren Input kann die IT Abteilung keine sinnvollen Rules definieren. Hier muss organisatorisch sichergestellt werden, dass jene IT-Abteilungen die DLP implementieren, mit korrekten Daten über die zu schützenden Assets versorget werden. Leider verleiten die, in den DLP Lösungen mitgelieferten DLP-Rules allzu oft dazu, diese zu verwenden, ohne sich ernsthaft über die Struktur und Organisation der Schutzobjekte Gedanken zu machen.

Schutzobjekte

In den Use Cases, in denen die DLP-Lösungen das Risiko von Datenabfluss minimieren sollen, findet man so ziemlich jede Art von Daten. Neben den beschriebenen Falschannahmen, ist oft die Komplexität von diversen Schutzobjekten die Ursache von hohen FP-Raten. Im Folgenden wird anhand des Beispiels von Kundendaten die Problematik aufgezeigt.

Einfache Schutzobjekte

Die einfachsten Schutzobjekte sind Identifikationsnummern wie Kontonummern. IDs, besonders jene mit mehr Zeichen als eine Telefonnummer, sind einfach zu implementieren (mit Indexierungs- oder Regularexpression-Rules). Bei solchen IDs sind keine oder nur marginale FP-Raten zu erwarten.

Komplexe Schutzobjekte

Die Problematik liegt bei Daten, welche nicht immer einem gleichen Muster entsprechen. Dies sind Freitextfelder, wie z.B. Namen oder Adressen. Solche Daten sind grundsätzlich für FP anfällig, da im Prinzip alles Erdenkliche darin vorkommen kann.

Möchte man z.B. seinen Kundenstamm in einer DLP Rule abbilden, so indexiert man höchstwahrscheinlich die Daten aus der Kundendatenbank in eine DLP-Rule. Dies wirft aber eine ganze Reihe von Problematiken hervor. Selbst im eher seltenen Fall, dass die Kundendatenbank zu 100% bereinigt und validiert ist, bergen die diversen Eigenschaften der Freitext-Felder noch genügen Knackpunkte.

Es ist sehr wahrscheinlich, dass ein Prozess definiert werden muss, der verhindert, dass nicht validierte Daten in die DLP-Rules gelangen. Nur ein ungewolltes Attribut in der DLP-Rule kann ein Sturm von FPs auslösen.

Hat man die Datenqualität im Griff, bleiben immer noch die diversen Eigenheiten der Freitextfelder, welche die FP-Raten ansteigen lassen, dazu folgendes Beispiel: Ein beliebter Asiatischer Vorname ist “An”. “An” ist aber auch eine häufig verwendete Präposition in der deutschen Sprache. Wie soll damit umgegangen werden, den Kunden mit Vorname “An” ausschliessen oder die hohe FP Raten durch die Präposition in Kauf nehmen?

Schlussendlich kommt man meist nicht darum herum, gewisse Daten aus den DLP-Rules auszuschliessen. Vor allem wenn man tausende oder hunderttausende Dateneinträge abdecken muss. Schliesst man nun gewisse Daten aus um die FP-Raten klein zu halten, mindert sich zugleich der Abdeckungsgrad der DLP-Rule. Musste man 5% oder 10% der initialen Daten der Kundendatenbank ausschliessen, muss dies dokumentiert und als Restrisiko akzeptiert werden.

Ist man an diesem Punkt angelangt, helfen einem die in den DLP-Lösungen verfügbaren Werkzeuge nicht mehr viel. Das DLP-Setup ist nun schon stark auf das Unternehmen zugeschnitten und es muss selbst mit dieser Komplexität klar kommen.

Die Lösung

Parallel zur technischen DLP-Implementation sollte auch organisatorisch eine Verwaltungsinstanz, insbesondere der DLP-Rules eingeführt werden. Ein solches DLP Policy Management soll die nötige Transparenz schaffen und damit Auskunft über die Qualität und den Status von DLP Rules geben, sowie die Qualität der DLP Rules stetig verbessern.

DLP Policy Management

Ein DLP Policy Management sollte zwischen Business und IT-Abteilungen angesiedelt werden. Eventuell bietet sich ein Zweierteam an, jemand aus dem Business (Risk) und jemand aus der IT Abteilung (DLP Rule Autor).

Wichtig ist zu verstehen, dass DLP Rules in einem initialen (Implementations) Projekt zwar erstellt werden können, aber auch meist sehr hohe FP Raten aufweisen werden. Das wichtige Tuning (Minimieren der FP Raten und Erhöhen des Abdeckungsgrades) der DLP-Rules kann erst über die Zeit erfolgreich sein. Somit soll ein Policy Management sicherstellen, dass auch nach Beendigung des Projekts, während dem Betrieb, die Möglichkeit DLP Rules iterativ zu verbessern gegeben ist.

Tools und Prozesse

Wie soll nun ein DLP Policy Management seine Arbeit verrichten? Grundsätzlich muss verstanden werden, dass bei grossen zu schützenden Datenvolumen nur ein iterativer Prozess zielführend sein kann. Zu viele Faktoren beeinflussen die Qualität der DLP-Rules und meist sind diese Faktoren im initialen DLP Projekt noch nicht bekannt. Daher bieten sich folgenden Konzepte an.

Die einfachste Darstellung einer DLP-Rule ist deren Konfiguration in der DLP-Lösung. Jedoch sagt dies nichts über die Qualität einer Rule aus. Um eine End-to-End View einer DLP-Rule zu erhalten, sollten mindestens folgenden Faktoren per Rule dokumentiert sein:

• Anforderung an die DLP-Rule (Soll-Zustand: 100% alle Kundennamen abdecken / keine FPs)
• Aktuelle Implementierung (Ist Zustand: 80% Abdeckung)
• Analyse der Resultate (Ist-Zustand: 30% FPs)

Um dem iterativen Aspekt entgegen zu kommen soll eine Versionsverwaltung eingeführt werden.

Reporting

Werden die DLP-Rules in einer End-to-End View durch ihren Lifecycle verwaltet, ist das Reporting ein leichtes. Die Informationen sind logisch und es muss nicht interpretiert werden. Jedoch nur wenn die Datenlage auch zentral und automatisiert gesammelt werden kenn. Wiederum bieten die gängigen DLP-Lösungen dazu nur wenige Werkzeuge und man ist auf sich gestellt. Es empfiehlt sich daher, in dem DLP-Implementations-Projekt, die Reporting Funktionalitäten genau zu evaluieren und die Anforderungen eines DLP Policy Management zu berücksichtigen.

Fazit

DLP Projekte sollten vom Business getrieben werden. IT-Abteilungen sind Dienstleister, welche die Anforderungen des Business umsetzen möchten. Da die Inhaltlichen Anforderungen an DLP-Lösungen nicht, wie etwa einer Antivieren-Lösung, durch die IT-Abteilugen spezifiziert werden können, muss dieser Input klar von der Business-Seite aufgearbeitet und zur Verfügung gestellt werden.

DLP-Lösungen können viel Geld kosten und doch nur minimal zu Minderung der Risiken von Datenabflüssen beitragen. Man ist verleitet, ein Tool mit dem Ziel Blocking-Mode zu installieren und dann davon auszugehen, Risiken effektiv minimiert zu haben. Vor allem auf Enterprise Level ist diese Problematik weit verbreitet. Aber versteht man DLP-Lösungen als Controlling-Tool für bestehen Massnahmen gegen Datenabflüsse, lässt es sich hervorragend als Broken-Process-Detector nutzen.

Doch Inkonsistenzen in der Datenhaltung (hier zeigt DLP allenfalls schon erste kaputte Prozesse auf) und die Eigenheiten der vielen verschiedenen Arten von zu schützenden Daten machen das Erstellen und Nutzen von effektiven DLP-Rules komplex. Die DLP Lösungen bringen dazu meist unzureichende Tools mit sich. Daher empfiehlt sich ein klar strukturiertes Policy Management als Betriebs-Standard mit einzuführen, ausserdem sollte bei der Evaluation der DLP-Lösung besonders auf die Reporting-Funktionalitäten geachtet werden. Ist in der Budgetierung kein Policy Management vorgesehen, gerät man meist in einen stagnierenden Zustand. Dieser wird durch verfälschtes Rapportieren verschwiegen (womit sich Risiken erhöhen!) oder man evaluiert bereits die nächst DLP-Lösung, die es dann richten soll. Die Kosten waren hoch und der Nutzen leider begrenzt.

Wer die Möglichkeit hat ein DLP Policy Management von Anfang einzuführen, sollte dies gewissenhaft tun. Jene die noch mit massiven FP-Stürmen oder nicht befriedigende Abdeckungsraten kämpfen, sollten in Erwägung ziehen, ebenfalls ein DLP Policy Management einzuführen. Auch wenn dafür eventuell einige Schritte rückwärts gemacht werden müssen.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
• http://www.isaca.org/Groups/Professional-English/strategic-planningalignment/GroupDocuments/Kicking%20DLP%20Tires%20Not%20Enough.docx
• http://www.techradar.com/news/top-5-best-data-loss-prevention-services
• https://www.kpmg.de/docs/central-and-eastern-european-data-theft-survey-2012.pdf