![[Illustration]](images/08-4-012-1.jpg)
Abbildung 1: Serverbasierte DLP-Architektur
Der Begriff Data Leakage Prevention (auch Data Loss Prevention, DLP) ist in den letzten Monaten verstärkt bemüht worden, um Lösungen gegen den Verlust vertraulicher Daten durch Innentäter zu beschreiben. Auch wenn das modische DLP im Wesentlichen ein Synonym für das altbewährte Content Monitoring & Filtering (CMF) ist, zeigt sich doch ein gesteigertes Interesse an dieser Produktkategorie, die abgehende Daten genauer unter die Lupe nimmt.
Richteten Sicherheitsverantwortliche und IT-Administratoren im Unternehmensbereich ihr Augenmerk früher hauptsächlich auf Probleme durch externe Angreifer, gewinnen seit einiger Zeit auch firmeninterne Vorfälle an Bedeutung. Dabei handelt es sich sowohl um Datenverluste aufgrund von fahrlässigen Aktionen unbescholtener Mitarbeiter als auch um mutwilligen Diebstahl vertraulicher Daten durch kriminelle Betriebsangehörige.
Die klassischen Mechanismen der Datensicherheit lassen sich leider nicht unverändert auf die Anforderungen des DLP übertragen: Schützt man Informationen gegen Angriffe von außen im Wesentlichen durch Zugriffskontrolle und Verschlüsselung, so ist damit (alleine) kein praktikabler Schutz gegen den Vertraulichkeitsverlust durch Interne zu erzielen: Es gibt viele legitime Gründe, wieso ein loyaler Mitarbeiter Dokumente aus einer gesicherten Domäne heraus auf ein Medium unter seiner Kontrolle oder auf ein Ziel im Internet kopieren möchte – beispielsweise die Kopie einer Präsentation auf einen USB-Stick zur Vorstellung beim Kunden oder auch der Datei-Versand an ein privates E-Mail-Konto zur weiteren Bearbeitung von zu Hause.
Bei den betroffenen Dateien kann es sich sowohl um nicht-vertrauliche als auch um vertrauliche Dokumente handeln – ein generelles Unterbinden solcher Kopieroperationen würde Arbeitsabläufe unnötig behindern und stieße vermutlich auf wenig Akzeptanz. Datensicherheitsmaßnahmen sollten nur dann aktiv werden, wenn es sich wirklich um ein vertrauliches Dokument handelt! Das entlastet erst einmal alle Anwender, die sich prinzipiell nur mit nicht-vertraulichen Dokumenten beschäftigen. Und Mitarbeiter, die sich gelegentlich mit vertraulichen Dokumenten beschäftigen, können ihr Bewusstsein dafür schärfen, welche Dateien und Informationen wirklich vertraulich sind und welche Maßnahmen diese Klassifizierung nach sich zieht. Für Anwender, die routinemäßig mit vertraulichen Dokumenten arbeiten, ändert sich meist nichts, da sie ohnehin mit den entsprechenden Sicherheitsmaßnahmen vertraut sind. Es sei denn, ihre Absichten wären unlauter: Dann würden sie durch die entsprechenden Maßnahmen gestoppt (Zugriffskontrolle) oder zumindest behindert.
Man kann bei DLP-Systemen im Wesentlichen zwei Architekturen unterscheiden:
Serverbasierte Architekturen setzen zwingend den Einsatz eines (oder mehrerer) Rechner in der Serverdomäne voraus und führen ihre Überwachungsfunktionen großteils oder ausschließlich innerhalb dieser Domäne durch (vgl. Abb. 1). Sie erfordern typischerweise den Einsatz individueller Proxies für HTTP-, FTP- und E-Mail-Verkehr (SMTP, IMAP) zur Überwachung des abgehenden Netzwerkverkehrs über die entsprechenden Protokolle. Solche dedizierten Proxies ermöglichen eine effiziente Überwachung auch bei hohem Datenaufkommen und ermöglichen es durch ihre Store-and-Forward-Architektur, jedes zu inspizierende Element so lange zu blockieren bis auch zeitraubende Überprüfungen abgeschlossen sind. Aus Performance- und Sicherheitsgründen sind sie typischerweise auf dedizierten Unix-Appliances implementiert.
Abbildung 1: Serverbasierte DLP-Architektur
Rein serverbasierte Lösungen besitzen den Vorteil, dass sie keine Installationen auf den Endpoints erfordern. Das verringert den logistischen Aufwand und vermeidet Kompatibilitätsprobleme mit anderen "kritischen" Client-Anwendungen (z. B. Virenscanner). Dem steht jedoch der Nachteil gegenüber, den Export vertraulicher Daten auf dem Endpoint nicht überwachen zu können. Inwieweit das durch administrative Maßnahmen, etwa die Deaktivierung oder Blockade jeglicher Geräte mit externen Datenträgern sowie aller Netzwerkschnittstellen durch Betriebssystemmittel, kompensiert werden kann, hängt vom Einzelfall ab – bei portablen Geräten ist das meist schwierig bis unmöglich.
Endpointbasierte Architekturen arbeiten direkt auf dem Endgerät. Der zugehörige Server hat dabei typischerweise die Aufgaben zentraler Administration, Policy-Verteilung, Speicherung gemeldeter Log-Events und nur bei manchen Produkten einer zusätzlichen Unterstützung der Überwachungsfunktionalität – letzteres setzt natürlich eine permanente Netzwerk-Verbindung zwischen Server und Endgerät voraus.
![[Illustration]](images/08-4-012-2.jpg)
Abbildung 2: Endpointbasierte DLP-Architektur
Lösungen auf den Endgeräten können (bei entsprechend vollständiger Implementierung) praktisch jeden Datenexport auf externe Medien, Netzwerkziele sowie über drahtgebundene und drahtlose Schnittstellen überwachen. Das umfasst zum Beispiel Kopieroperationen von Dateien auf USB-Sticks, den Versand von E-Mails im Internet-Café über WLAN, einen Export von Fotodateien über Bluetooth et cetera. Als Nachteile stehen dem die notwendige Installation eines DLP-Agenten auf jedem Endgerät sowie die technische Herausforderung für den Hersteller gegenüber, einen leistungsfähigen Agenten zu implementieren, der möglichst alle vorhandenen Exportkanäle abdichtet. Letzteres ist, gemessen an den Produkten, die sich derzeit auf dem Markt befinden, nicht zu unterschätzen.
Können Proxies die zu untersuchenden Dateien vergleichsweise leicht aus dem Datenstrom herausfischen, ist die technische Implementierung auf dem Endgerät schwieriger, da die Prüfroutinen zumeist in den lokalen Netzwerk-Stack "hineingemogelt" werden. Dies muss so intelligent und leistungsfähig erfolgen, dass beispielsweise beim temporär blockierten E-Mail-Versand nicht gleich die SMTP-Verbindung abbricht. Noch schwieriger wird es, wenn man Nachrichten in Microsoft Outlook oder Lotus Notes überwachen will, wo sich häufig im Netzwerk-Stack keine brauchbaren Daten abgreifen lassen (z. B. wegen Verschlüsselung zwischen Client und Server), sodass Plug-ins für die jeweiligen Clients zum Einsatz kommen müssen. Ähnliches gilt auch für Instant Messenger, die sich ausschließlich auf dem Endpoint überwachen lassen.
Eine generelle Herausforderung ist die Vielzahl der heute verwendeten Dokumentenformate und Transportkodierungen: Eine Worddatei beispielsweise muss die DLP-Lösung zunächst "entpacken", damit ihr Suchalgorithmus mit den Daten arbeiten kann. Der eingesetzte Konverter sollte einige hundert gängige Formate unterstützen, um eine effiziente Kontrolle zu ermöglichen.
Um eine Datei oder einen Datentransfer als vertraulich zu erkennen, kommen bei DLP-Produkten im Wesentlichen drei Konzepte zum Einsatz:
Nicht jedes Auftreten eines Suchworts markiert jedoch den unautorisierten Export eines vertraulichen Dokuments! Die DLP-Lösung sollte daher das Auftreten von Übereinstimmungen innerhalb von Kategorien gewichten, aufaddieren und erst beim Erreichen eines definierbaren Schwellwertes eine Reaktion (bzw. Sanktion) auslösen.
Der einfachste Ansatz, um ein Dokument nach Stichwörtern zu durchsuchen, ist sicherlich der Vergleich aller Wörter des Textes mit der Stichwortliste. Bei regulären Ausdrücken sollte der verwendete Prüfalgorithmus zudem nicht nur die Übereinstimmung mit der Schablone verifizieren, sondern weitere Plausibilitätstests durchführen (z. B. Prüfsumme bei Kreditkartennummern), um das Auftreten von False Positives zu reduzieren.
Was in einer Sprache wie dem Englischen mit seiner einfachen Grammatik noch zu geringen Einschränkungen führt, verursacht bei Sprachen – wie Deutsch – mit starker Flexion (Beugung) von Substantiven, Adjektiven und Verben schon deutliche Einbußen: So wird zum Beispiel der Plural "Züge" nicht durch das Stichwort "Zug" erkannt. Allerdings ist es nicht sehr wahrscheinlich, dass in einem zu durchsuchenden Dokument der entsprechende Begriff ausschließlich im Plural vorkommt.
Leistungsfähiger ist dennoch ein System, das mittels integrierter Linguistikfunktionen gebeugte Formen in ihre jeweilige Grundform überführen kann (zum Beispiel Maskulinum Singular bei Substantiv und Adjektiv, Infinitiv beim Verb). Solche Systeme ermöglichen dann über die reine Suche nach Übereinstimmungen hinaus schon eine gewisse Form der Ähnlichkeitsanalyse, da sich auch Flexionen prüfen lassen – gleichzeitig ergibt sich eine bessere Messbarkeit. Leistungsfähigere Systeme bieten zudem eine Skriptsprache an, die unter anderem die Kombination von Stichwörtern über logische Verknüpfungen (und, oder, nicht usw.) zulässt sowie weitere Elemente einer regulären Programmiersprache enthält.
Eine weiter gehende Ähnlichkeitsanalyse kann durch so genanntes Fingerprinting durchgeführt werden: Dabei handelt es sich um Hashwerte, also eine Abbildung der Daten auf eine konstante, kurze Länge, die jedoch nicht über das gesamte Dokument, sondern nur über relativ wenige charakteristische Fragmente des Texts erfolgt (in der Größenordnung von vielleicht 20–30 Zeichen). Die große Kunst des verwendeten Fingerprinting-Algorithmus liegt darin, diejenigen Fragmente mit der größten inhaltlichen Relevanz herauszufinden und nur über sie die Hashes zu berechnen. Der Lohn für die intelligente Auswahl liegt sowohl in einer geringen Größe der Fingerprint-Sammlung pro registriertem Dokument als auch in der guten Performance der Vergleichsoperationen (bei der Prüfung). Zudem wird das System weitgehend resistent gegen zufälliges oder mutwilliges Umsortieren von Textbestandteilen, da diese meist größer sind als die Fragmente, über welche die Fingerprints errechnet wurden.
Der Workflow beim Fingerprinting sieht typischerweise so aus, dass der für die Einführung eines DLP-Produkts verantwortliche Administrator zunächst eine Datenbank von Dokumenten mit relevanten (vertraulichen) Inhalten anlegt und das Produkt über diese Dokumente die Fingerprints errechnen lässt. Diese werden dann serverseitig als Referenz gespeichert und bei Bedarf en bloc in die Proxies beziehungsweise DLP-Agenten geladen. Bei der Ausgangskontrolle eines Dokuments errechnet die Lösung dessen Fingerprints in Echtzeit und vergleicht sie mit den gespeicherten Samples – bei Übereinstimmung wird eine Sanktion ausgelöst.
In der Praxis nutzen DLP-Systeme häufig eine Kombination von Stichwortsuche und Fingerprints. Für eine tiefer gehende fundierte und detaillierte technische Übersicht der grundsätzlichen Klassifizierungskonzepte sei auf die Literatur, insbesondere auf [1], verwiesen.
Wird der versuchte Export eines vertraulichen Dokuments festgestellt, so kommt es – je nach Policy – zu entsprechenden Sanktionen vom ausschließlichen Protokollieren bis hin zum Abbruch des Vorgangs. Eine elegante Variante ist der interaktive Dialog mit dem Benutzer: Ein DLP-System weist dabei den Benutzer auf Sicherheitsbedenken hin und fordert ihn auf, eine Begründung für den Export einzugeben, die entsprechend protokolliert wird. Dieser Ansatz ist sehr nützlich bei der "sanften" Einführung eines sicheren Dokumenten-Workflows im Unternehmen, da er dem Benutzer nichts pauschal verbietet, sondern seine Kooperation einfordert. Nicht zuletzt kann es überdies auch sinnvoll sein, die Verschlüsselung des Dokuments in der E-Mail oder auf dem Zieldatenträger zu erzwingen.
Nicht in jeder Unternehmensumgebung ist es erforderlich, sofort mit der Brechstange den Export vertraulicher Dokumente zu unterbinden! Häufig genügt es schon, sich einen Überblick über die Gefährdung zu verschaffen, indem man den vorhandenen Dokumentenbestand vollständig analysiert und klassifiziert. Technisch ist ein solcher Scan wesentlich einfacher, da man fast vollständig auf Eingriffe in Betriebssystem und Netzwerk-Stack verzichten kann. Sind beispielsweise Windows-Endgeräte per Netzwerk-Share vom Server zu erreichen, könnte sogar die Installation eines Agenten auf dem Client entfallen (allerdings ggf. zulasten des Netzwerkverkehrs).
Hat man sich einen Überblick über den Dokumentenbestand verschafft, gilt es den Umgang mit vertraulichen Dokumenten zu überdenken und gegebenenfalls entsprechende Richtlinien zu schaffen. Bei Bedarf kann man dann immer noch ein vollwertiges DLP-Produkt mit Echtzeit-Überwachung einführen. Der empfehlenswerte Workflow lautet also klar: zunächst Erfassen und Klassifizieren, erst dann eventuell Einrichten von Schutzmaßnahmen.
Wer versucht, mittels eines DLP eine tragfähige Exportkontroll-Policy zu erstellen, muss zudem erst einmal eine Anforderungsanalyse innerhalb seiner Organisation durchführen. Meist wird dies auf eine intelligente Kombination aller zur Verfügung stehenden Mechanismen hinauslaufen und jede Abteilung wird ihre eigene Policy erstellen. Mit dem weitgehend automatisierten Erstellen einer Fingerprint-Datenbank aus allen von Such-Agenten gefundenen Dokumenten ist es jedenfalls nicht getan!
Wichtig ist auch die Erkenntnis, dass DLP keine exakte Wissenschaft ist: Das gilt sowohl für die Inhaltsanalyse als auch für die Exportkontrolle. Bei der Inhaltsanalyse können durch Doppeldeutigkeiten von Stichwörtern leicht False Positives auftreten, nicht-linguistische Systeme können Suchwörter bei Flexion übersehen (speziell bei Umlautbildung im Deutschen).
Und auch die Exportkontrolle ist nicht sicher vor "IT-Spezialisten" unter den Innentätern: So genügt es zum Beispiel, einen Text mit dem früher im Usenet populären ROT-13-Algorithmus zu verschleiern (jedes Zeichen im Alphabet wird um 13 Zeichen verschoben), um ihn unbehelligt von gängigen DLP-Produkten exportieren zu können; ein entsprechendes Add-on ist zum Beispiel für Mozilla/Thunderbird frei verfügbar.
Weitere Probleme ergeben sich bei den unterstützten Dokumentenformaten sowie den abgesicherten Exportkanälen auf dem Endgerät: Der Hersteller eines DLP-Produktes muss hier ständig aktuellen Neuerungen (z. B. bei Instant Messengers) hinterherlaufen und in seiner nächsten Produktversion nachziehen. Bis dahin bleibt es Aufgabe des Administrators, gegebenenfalls die Nutzung entsprechender Programme zu unterbinden – wie dies auch schon bei klassischen Sicherheitsprodukten häufig der Fall ist.
Das DLP-Lager wurde einige Jahre lang im Wesentlichen von kleineren Firmen, teilweise Startups, beherrscht. In den letzten Jahren hat jedoch das "große Fressen" durch die etablierten Datensicherheitsfirmen eingesetzt: McAfee hat Onigma übernommen, Tablus ging an EMC, TrendMicro akquirierte Provilla und schließlich Symantec Vontu. Es bleibt zu hoffen, dass mit dieser Marktbereinigung eine Professionalisierung der Branche sowie eine bessere Integration der bislang alleinstehenden DLP-Produkte in klassische Sicherheitslösungen (Verschlüsselung, Virenscanner etc.) einhergeht.
DLP bietet mit seinem inhaltsbasierten Ansatz eine interessante Alternative zu klassischen Datensicherheitskonzepten mit ihren relativ statischen Policies. Als softwarebasiertes Werkzeug zur Bekämpfung von Datenverlusten durch Innentäter ist es derzeit ohne Alternative. Auch wenn es mit seinen technischen Möglichkeiten nicht hundertprozentig jeden mutwilligen Datendiebstahl verhindern kann, bietet es doch mächtige Instrumente sowohl zur Bestandserfassung und Risikoanalyse als auch zur sanften Durchsetzung von Workflows im Sinne der Verhinderung von unerwünschten Datenlecks.
Dr. Michael Alfred Schmidt ist Software-Architekt bei Utimaco.
![[externer Link]](../../images/link.gif)
www.inf-wiss.uni-konstanz.de/infwiss/download/isi2000/isi2000_9.pdf http://theory.stanford.edu/~aiken/publications/papers/sigmod03.pdf ftp://ftp.cs.arizona.edu/reports/1993/TR93-33.pdf www.csse.monash.edu.au/projects/MDR/papers/ICCS2002-monostori.pdf
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2008#4, Seite 12
tag:kes.info,2007:lp:2008-4-B
| 