Data Loss Prevention in der Kranken­versicherungsbranche

In einem Kundenprojekt bei einer Schweizer Krankenversicherung fand ein Audit statt. Ein prominentes Thema, das in diesem Audit beleuchtet wurde, war der Data Loss, also der ungewollte Datenabfluss. Dieser Use Case ist insofern spannend, da das Thema Data Loss Prevention (DLP) in der Schweizer Krankenversicherungsbranche noch Neuland ist, in Zukunft aber mehr und mehr an Bedeutung gewinnen wird. Dies nicht zuletzt, da die Eidgenössische Finanzmarktaufsicht (FINMA) sowie die Finanzdienstleister ihr Augenmerk nun vermehrt auf die Versicherer legen.

Im Folgenden möchte ich zunächst erklären, was genau unter Data Loss Prevention zu verstehen ist und wie es um die Zuverlässigkeit und die Fehlerrate von DLP-Tools steht. Im Anschluss gehe ich auf die Herausforderungen ein, die im Projekt aufgetaucht sind und erkläre, warum die Entscheidung gegen die Einführung eines umfangreichen Data Loss Prevention Tools fiel.

Was versteht man unter Data Loss Prevention?

Das Ziel von Data Loss Prevention (DLP) besteht darin, einen ungewollten Datenabfluss zu verhindern. DLP-Tools können zwar an verschiedenen Punkten der Überwachung ansetzen, doch in diesem Use Case lag der Fokus auf der E-Mail-Kommunikation an Empfänger außerhalb des Firmennetzes - zum Beispiel Kunden, Vermittler oder Behörden.

Entscheidet man sich für eine solche Art der Überwachung, müssen zunächst Kriterien definiert werden, nach denen das Tool entscheiden kann, ob eine E-Mail das Firmennetz verlassen darf oder ob sie abgefangen werden soll. Die Gesamtheit dieser Kriterien wird nachfolgend als „Regelwerk“ bezeichnet. Wird eine E-Mail abgefangen, wird ein Incident generiert. Diese „Vorfälle“ werden dann durch eine zentrale Stelle geprüft und beurteilt. Das bedeutet, ein Sachbearbeitender muss entscheiden, ob die E-Mail gerechtfertigt abgefangen wurde oder ob es sich um einen Fehlalarm handelt.

Im Folgenden möchte ich euch einige Szenarien vorstellen, in denen ein DLP-Tool ein Data Loss verhindern soll - unterteilt in unbeabsichtigte Fehlhandlungen und vorsätzliche Vergehen:

Unbeabsichtigte Fehlhandlung durch Mitarbeitende

• Externe Vermittler/Broker erhalten mehr Kundeninformationen, als für deren Arbeit nötig ist.
• Sensible Informationen werden verschlüsselt, aber an den falschen Kunden gesendet.
• Sensible Informationen werden - entgegen geltender Geschäftsweisung - unverschlüsselt versendet.

Vorsätzliche und widerrechtliche Handlungen

• Listen von Bestandskunden werden als Kandidaten für eine Abwerbung an die Konkurrenz oder an einen unabhängigen Vermittler gesendet.
• Sensible Daten von prominenten Kunden werden an die Presse gereicht.
• Eine unverschlüsselte E-Mail-Übertragung wird von einem externen Angreifer abgefangen.

Ein DLP-Tool muss also folgende Anforderungen erfüllen:

1. Erkennen, welche ausgehenden E-Mails schützenswerte Informationen enthalten.

2. Beurteilen, ob alle Empfänger berechtigt sind, diese schützenswerten Informationen zu empfangen. Ist das nicht der Fall, wird die E-Mail abfangen und ein Incident wird generiert.

3. Prüfen, ob die Kommunikation gemäß der Firmenrichtlinien verschlüsselt ist. Ist das nicht der Fall, wird die E-Mail ebenfalls abfangen und ein Incident wird generiert.

Zuverlässigkeit und Fehlerrate von DLP-Tools

Von entscheidender Bedeutung ist die Zuverlässigkeit des Regelwerks. Es gibt zwei unbefriedigende Zustände: Ist das Regelwerk lückenhaft, bietet es keinen ausreichenden Schutz. Ist es hingegen zu engmaschig, steigt die Rate von Fehlalarmen. Dies hat verschiedene negative Auswirkungen:

• Einen großen Overhead an Personalaufwand bei der Bearbeitung von Incidents.
• Unverhältnismässig viel Kommunikation wird ohne ausreichenden Verdacht abgefangen und ausgewertet. Das kann aus Datenschutzgründen äußerst heikel sein.
• Wird ein Fehlalarm nicht als ein solcher von der Verwaltungskraft erkannt, könnten Mitarbeitende fälschlicherweise eines Vergehens bezichtigt werden.

Besonders die letzten beiden Punkte können rechtliche Konsequenzen und sogar einen Imageschaden nach sich ziehen. Wird also kein zuverlässiges Regelwerk definiert, wird eine Software betrieben, die einen ungenügenden Schutz bietet, das Unternehmen eventuell sogar schädigen kann und gegebenenfalls noch viel kostet.

In den nächsten beiden Abschnitten möchte ich daher zeigen, wo die Herausforderungen bei der Erstellung eines ausreichend zuverlässigen Regelwerks liegen.

1: Die Identifikation von sensiblen Inhalten ist hoch komplex

Im Vordergrund steht der Schutz von sensiblen Personendaten. Bei Banken sind diese Daten vorwiegend strukturiert - etwa Konto-, Kreditkarten- und Kundennummern. Diese sind dann für ein Software Tool ohne große Mühe zu erkennen. Das macht den Einsatz von DLP-Tools für Banken technisch und organisatorisch verhältnismäßig einfach. Anders sieht es im Versicherungsumfeld aus. Bei Krankenversicherern kommen sensible Kundendaten in vielfältigerer Form vor und sind häufig unstrukturiert. Oft ist es auch erst die Kombination von verschiedenen Informationen, die den Unterschied zwischen „sensibel“ und „nicht sensibel“ ausmacht.

Stellt euch vor, eine E-Mail wird offengelegt, die einen Kunden namentlich identifiziert, ansonsten aber keine sensiblen Daten enthält. Dies mag unerwünscht sein, der Schaden für die betroffene Person ist aber vermutlich gering. Heikler wird es, wenn in der gleichen E-Mail beispielsweise ein Krebsmedikament genannt wird. Dies lässt möglicherweise Rückschlüsse auf hoch sensible und private Informationen der betroffenen Person zu. Ein Tool müsste also in der Lage sein, ein kundenidentifizierendes Merkmal (in diesem Fall den Kundennamen) in Kombination mit der Nennung des Medikaments erkennen zu können.

Nun ist es aber so, dass nicht nur ein bestimmtes Medikament existiert, sondern eine unübersichtliche Vielfalt an Wirkstoffen, Produktnamen, Dosierungen und deren Kombinationen. Zudem gibt es neben Medikamenten für bestimmte Krankheiten auch Diagnosen, Behandlungen, Ärzte, Kliniken oder andere Institutionen, die Rückschlüsse zulassen. All diese Kombinationsmöglichkeiten müssten von einem Tool erkannt werden.

Ein anderes Beispiel: Ein Mitarbeitender im Case Management sendet eine E-Mail an einen Kunden und die E-Mail wird publik. Die E-Mail selbst ist unverfänglich, der Case Manager erkundigt sich zum Beispiel nach dem Befinden des Kunden. Aber aus der Kombination von Empfänger, Sender, E-Mail-Signatur („Case Management“) und dem unverfänglichen Inhalt, wird für einen unberechtigten Mitlesenden sofort deutlich, dass es sich um einen Kunden handelt, der vom Case Management des Krankenversicherers unterstützt wird.

Auch wenn nicht klar wird, aus welchem Grund der betreffende Kunde Anspruch auf Begleitung durch das Case Management hat, ist die Offenlegung dieses Sachverhaltes schon heikel. Vielleicht handelt es sich beim Empfänger sogar um eine politisch exponierte Person? Umgekehrt ist aber nicht automatisch jede E-Mail, in dem der Begriff „Case Management“ vorkommt, schützenswert. Es ist also nur bekannt, dass der Begriff „Case Management“ ein Kriterium für sensible Inhalte sein kann, aber nicht muss. Diese Erkenntnis hat keinen Mehrwert, da sich daraus kein scharfes Kriterium für das Regelwerk ableiten lässt.

Eine weitere Herausforderung: Wie kann eine leere Gesundheitsdeklaration von einer handschriftlich ausgefüllten unterschieden werden? Erstere ist unbedenklich, letztere kann aber schon hochsensible Informationen enthalten. Die Bedingung ist also, dass ein Computer menschliche Handschriften lesen kann, was aber keinesfalls gewährleistet ist.

Im Laufe vieler Workshops innerhalb unseres Kundenprojektes wurde festgestellt, dass es nicht möglich ist, umfassende und sinnvolle Suchkriterien zu definieren. Das hatte folgende Gründe:

• Allgemein gehaltene Kriterien bedingten Fehlalarmraten von bis zu 90 Prozent und waren somit nicht brauchbar.
• Sehr spezifische Kriterien deckten nur einen verschwindend kleinen Bruchteil von möglichen Fällen ab. Für einen ausreichenden Schutz würden tausende von präzisen Suchkriterien benötigt. Dieser Umstand machte die Erstellung und Wartung eines solchen Tools recht unrealistisch.

Als möglichen Lösungsansatz hätte man nun alternativ mit einem iterativen, risikobasierten Ansatz arbeiten können. Hier würde man mit wenigen und ausgewählten Themen starten, den Nutzen und die Zuverlässigkeit des Regelwerks messen und bei Bedarf die bestehende Kriterien anpassen sowie neu hinzufügen. Der Nachteil: In der Regel sind die hohen Sockelkosten eines DLP-Tools (Lizenzen, Wartung, Betrieb) meist unabhängig von der Anzahl oder auch vom Umfang der Regeln, die zur Anwendung kommen. Das bedeutet, mit der Nutzung eines DLP-Tools entstehen volle Kosten, obwohl nur ein Bruchteil der Möglichkeiten genutzt wird.

Das war dann auch einer der Hauptgründe, wieso sich unser Kunde im vorliegenden Fall gegen die Einführung eines DLP-Tools entschieden hat.

Punkt 2: Das Erkennen von berechtigten Empfängern ist praktisch ausgeschlossen

Neben der Identifikation von sensitiven Inhalten kam ein weiterer erschwerender Faktor hinzu: Viele dieser sensiblen Informationen durften und sollten im Daily Business den Firmenperimeter verlassen, sofern sie verschlüsselt sind und an den korrekten Empfänger geschickt werden. Damit ein DLP-Tool allerdings prüfen kann, ob ein Empfänger für bestimmte Inhalte berechtigt ist oder nicht, muss es für alle Kriterien aus dem ersten Punkt zusätzlich wissen, welche Empfänger überhaupt berechtigt sind, die entsprechenden Informationen zu erhalten. Dies war aus folgenden Gründen kaum realisierbar:

• Eine Liste aller potenziellen Empfänger im Geschäftsalltag zu erstellen, ist als solches schon eine Mammutaufgabe.
• Selbst wenn so eine Liste erstellt werden würde, ist diese dynamisch und kann nur mit enorm großem Aufwand gewartet werden.
• Die Empfängerliste müsste zudem mit den Kriterien zur Inhaltserkennung aus dem ersten Punkt kombiniert werden. Das bedeutet, der Umfang der Empfängerliste würde sich mit dem Umfang der Inhaltskriterien multiplizieren und für jeden Eintrag müsste eine Entscheidung getroffen werden, ob die Kombination für den Versand in Ordnung ist oder nicht.

Zu erwarten wäre ein Regelwerk mit Millionen von Einträgen, die zudem noch ständigen Veränderungen unterliegen würden. Ein Schutz in brauchbarem Umfang wäre somit auch in diesem Bereich unrealistisch. Ein inkrementelles Vorgehen hätte hier ebenfalls wenig gebracht, da sich die Komplexität schnell ins Unermessliche hochmultipliziert hätte.

Wie ging es weiter?

Nach der ernüchternden Erkenntnis über die Komplexität des Vorhabens und der daraus resultierenden Kundenentscheidung gegen die Einführung eines DLP-Tools, wurde der Scope reduziert, um wenigstens einen kleinen Schritt in Richtung Verbesserung der Situation machen zu können:

• Auf eine proaktive Überwachung wurde verzichtet und stattdessen das bestehende E-Mail-Archiv für retrospektive Auswertungen beigezogen.
• Der Schwerpunkt wurde auf Auswertungen statistischer Natur verschoben, um Hot Spots zu identifizieren: Wie viele E-Mails werden pro Organisationseinheit extern versendet? Welcher Anteil davon ist verschlüsselt? Das heißt auch, dass kein Personenbezug bei den Auswertungen hergestellt wird (geringeres Risiko einer Datenschutzverletzung).
• Der Fokus wurde verschoben - von der Mitarbeitersanktionierung im Einzelnen auf die Awareness der Unternehmung als Ganzes. Dadurch rückten auch nichttechnische Maßnahmen in den Vordergrund – etwa klare Handlungsanweisungen für die Belegschaft.

Parallel dazu wurden weitere Optionen ausgelotet. Die Bestrebungen sind derzeit jedoch noch in ihren Anfängen und im Work in Progress.

Hilfe durch Künstliche Intelligenz (KI)?

Vielversprechende Resultate erzielte ein kleiner KI-Prototyp, spezifisch ein Text-Mining-Ansatz. Dabei wurde eine Text-Mining-KI mit einem Set von wenigen hundert E-Mails gefüttert, von denen bekannt war, ob sie sensible Daten beinhalten oder nicht. Die KI hat sich anhand dieser Daten eigenständig Kriterien erarbeitet, um sensible von nicht sensiblen E-Mails zu unterscheiden. Im Testlauf waren nur 20 Prozent der Incidents Fehlalarme. Schaut man sich die gefundenen Kriterien an und wendet menschliche Intuition darauf an, lassen sich die Ergebnisse weiter verbessern. Beispielsweise war die KI der Meinung, dass bestimmte E-Mail-Signaturen relevant sind. Das Projektteam konnte beim Review aber schnell feststellen, dass diese Schlussfolgerung wohl für den genutzten Datensatz nachvollziehbar war, sich jedoch nicht generalisieren lassen würde. Das bedeutet, die KI hat aufgrund des kleinen und möglicherweise einseitig ausgewählten Trainingssets teilweise falsche Schlussfolgerungen gezogen.

DLP in der Cloud?

In den höheren Businesslizenzstufen von Microsofts Azure/O365 ist bereits eine DLP-Funktionalität enthalten. Grundlage für einen Schutz durch DLP ist im Fall von O365 ein sauber konfiguriertes Document Rights Management (DRM), das ebenfalls Bestandteil der höheren Azure/O365-Lizenzen ist. Mit sauber und durchgängig definierten Rechten und Vertraulichkeitsstufen auf Dokumentenebene, kann ein DLP-Tool viel einfacher entscheiden, welche Daten das Unternehmen verlassen dürfen und welche nicht. Der Aufwand verschiebt sich dabei nur von DLP auf DRM. Bei integrierten Gesamtlösungen fallen die Aufwände für zusätzliche Schnittstellen weg und auch der Support für DLP, DRM und deren Zusammenspiel kommt aus einer Hand.

Fazit

DLP in der Krankenversicherungsbranche ist ein schwieriges Thema, wird jedoch in Zukunft an Bedeutung gewinnen. Erfolgreiche Referenzprojekte von on-premise DLP-Tools fehlen (zumindest in der Schweiz) und Alternativen sind noch kaum ausgelotet. Vielversprechende Ansätze könnten sich jedoch in Form von KI- oder Cloud-Lösungen anbieten.

Ihr möchtet mehr über spannende Themen aus der adesso-Welt erfahren? Dann werft auch einen Blick in die bisher erschienenen Blog-Beiträge.