Data Loss Prevention: Wie schützen sich Krankenversicherer?

von Thomas Lampart, adesso Schweiz

Neulich hat man sich bei einem adesso Kunden, einem Schweizer Krankenversicherer, mit ungewollten Datenabfluss (Data Loss) auseinandergesetzt. In diesem Erfahrungsbericht schildere ich, mit welchen Massnahmen sich der Kunde vor ungewolltem Datenabfluss schützen wollte, welche Herausforderungen dabei aufgetaucht sind und warum man sich gegen die Einführung eines umfangreichen Data Loss Prevention Tools entschieden hat.

Dies ist insofern ein spannender Case, da Data Loss Prevention in der Schweizer Krankenversicherungs-Branche noch Neuland ist, in Zukunft aber mehr und mehr an Bedeutung gewinnen wird. Dies nicht zuletzt, da die Eidgenössische Finanzmarktaufsicht (FINMA) nebst den Finanzdienstleistern, sein Augenmerk nun vermehrt auf die Versicherer legt.

Was versteht man unter Data Loss Prevention?

Data Loss Prevention (DLP) hat das oberste Ziel, einen ungewollten Datenabfluss zu verhindern. DLP Tools können an verschiedenen Punkten der Überwachung ansetzen – in diesem Bericht liegt der Fokus auf der E-Mail-Kommunikation an externe Empfänger ausserhalb des Firmennetzes (z.B. Kunden, Vermittler, Behörden, etc.).

Für deren Überwachung müssen Kriterien definiert werden, nach welchen 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.

Incidents werden dann durch eine zentrale Stelle geprüft und beurteilt. Das heisst, ein Sachbearbeiter muss entscheiden, ob die E-Mail gerechtfertigt abgefangen wurde oder ob es sich um einen Fehlalarm handelt.

Hier einige Szenarien, in welchen ein DLP Tool ein Data Loss verhindern sollte, unterteilt in unbeabsichtigte Fehlhandlung und vorsätzlichem Vergehen:

Unbeabsichtigte Fehlhandlung durch Mitarbeitende:

• Externe Vermittler/Broker erhalten mehr Kunden-Informationen, 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, widerrechtliche Handlungen:

• Listen von Bestandskunden werden als Kandidaten für eine Abwerbung an die Konkurrenz oder 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. Falls nicht: E-Mail abfangen und Incident generieren.
3. Prüfen, ob die Kommunikation gemäss Firmenrichtlinien verschlüsselt ist. Falls nicht: E-Mail abfangen und Incident generieren.

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. Aber ist es hingegen zu engmaschig, steigt die Rate von Fehlalarmen. Dies hat verschiedene negative Auswirkungen:

• Grosser 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 äussert heikel sein.
• Wird ein Fehlalarm nicht als solcher vom Sachbearbeiter erkannt, könnten Mitarbeiter fälschlicherweise eines Vergehens bezichtigt werden.

Besonders die letzten beiden Punkte können rechtliche Konsequenzen und sogar einen Imageschaden nach sich ziehen. Ist man also nicht in der Lage, ein zuverlässiges Regelwerk zu definieren, betreibt man eine Software, die ungenügenden Schutz bietet, das Unternehmen eventuell sogar schädigen kann und ausserdem noch viel kostet.

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

Punkt 1: Die Identifikation von sensiblen Inhalten ist hoch komplex

Im Vordergrund steht der Schutz von sensiblen Personendaten. Bei Banken sind diese Daten vorwiegend strukturiert, z.B. Konto-, Kreditkarten- und Kundennummern, und somit für ein Software Tool einfach zu erkennen. Dies macht den Einsatz von DLP Tools für Banken technisch und organisatorisch verhältnismässig einfach.

Im Gegensatz dazu kommen sensible Kundendaten bei Krankenversicherern 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.

Stellen Sie sich 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 z.B. ein Krebsmedikament genannt wird. Dies lässt möglicherweise Rückschlüsse auf hoch sensible private Informationen der betroffenen Person zu.

Ein Tool müsste also die Kombination vom kundenidentifizierendem Merkmal (in diesem Fall dem Kundennamen) in Kombination mit der Nennung des Medikaments erkennen können. Jetzt gibt es aber nicht nur ein bestimmtes Medikament, sondern eine unübersichtliche Vielfalt an Wirkstoffen, Produktnamen, Dosierungen und deren Kombinationen.

Zudem gibt es nebst Medikamenten für andere Krankheiten auch Diagnosen, Behandlungen, Ärzte, Kliniken oder andere Institutionen die Rückschlüsse zulassen. All diese müssten von einem Tool erkannt werden.

Ein anderes Beispiel: Wie kann man eine leere Gesundheitsdeklaration von einer handschriftlich ausgefüllten unterscheiden? Ersteres ist unbedenklich, letzteres kann schon hochsensible Informationen enthalten. Bedingung hierfür ist, dass ein Computer menschliche Handschriften lesen kann, was keinesfalls gewährleistet ist.

Im Laufe vieler Workshops haben wir festgestellt, dass wir nicht in der Lage sind, umfassende sinnvolle Suchkriterien zu definieren:

• Allgemein gehaltene Kriterien bedingten Fehlalarm-Raten 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 ausreichenden Schutz würden tausende von präzisen Suchkriterien benötigt werden, was in der Erstellung und Wartung unrealistisch ist.

Als möglichen Lösungsansatz könnte man nun alternativ mit einem iterativen, risikobasierten Ansatz arbeiten. Man startet mit wenigen ausgewählten Themen, misst den Nutzen und die Zuverlässigkeit des Regelwerks und bei Bedarf werden bestehende Kriterien angepasst und neue hinzugefügt.

Allerdings sind die hohen Sockelkosten eines DLP Tools (Lizenzen, Wartung, Betrieb) meist unabhängig von der Anzahl oder vom Umfang der Regeln, die zur Anwendung kommen. Das heisst, mit einem DLP Tool haben Sie die vollen Kosten, nutzen jedoch nur einen Bruchteil der Möglichkeiten. Dies war dann auch einer der Hauptgründe, die den Kunden im vorliegenden Fall gegen die Einführung eines DLP Tools bewogen haben.

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

Nebst der Identifikation von sensitiven Inhalten aus Punkt 1 kommt in Punkt 2 ein weiterer erschwerender Faktor hinzu. Viele dieser sensiblen Informationen dürfen und sollen im Daily Business den Firmenperimeter verlassen, sofern sie verschlüsselt und an den korrekten Empfänger geschickt werden.

Damit ein DLP Tool prüfen kann, ob ein Empfänger für bestimmte Inhalte berechtigt ist oder nicht, muss es für alle Kriterien aus Punkt 1 zusätzlich wissen, welche Empfänger überhaupt berechtigt sind, die entsprechenden Informationen zu erhalten. Dies ist aus folgenden Gründen kaum realisierbar:

• Eine Liste aller potentiellen Empfänger im Geschäftsalltag zu erstellen, ist als solches schon eine Mammutaufgabe.
• Selbst wenn so eine Liste erstellt wäre, ist diese dynamisch und kann kaum gewartet werden.
• Diese Empfängerliste müsste dann zudem mit den Kriterien zur Inhaltserkennung aus Punkt 1 kombiniert werden. Das heisst, der Umfang der Empfängerliste würde sich mit dem Umfang der Inhaltskriterien multiplizieren und für jeden Eintrag müsste ein Entscheid getroffen werden, ob die Kombination für den Versand OK ist oder nicht.

Zu erwarten ist ein Regelwerk mit Millionen von Einträgen, welche dazu noch ständigen Veränderungen unterliegen würden. Ein Schutz in brauchbarem Umfang ist somit auch in diesem Bereich unrealistisch. Ein inkrementelles Vorgehen würde hier auch wenig bringen, da sich die Komplexität schnell ins Unermessliche hochmultiplizieren würde.

Wie weiter?

Nach der ernüchternden Erkenntnis über die Komplexität des Vorhabens und dem daraus resultierenden Kundenentscheid gegen die Einführung eines DLP Tools, wurde der Scope reduziert, um wenigstens einen kleinen Schritt 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 heisst auch, dass kein Personenbezug bei den Auswertungen hergestellt wird (geringeres Risiko einer Datenschutzverletzung).
• Verschiebung vom Fokus von Mitarbeitersanktionierung im Einzelnen, auf Awareness der Unternehmung als Ganzes. Dadurch sind auch nicht-technische Massnahmen in den Vordergrund gerückt wie z.B. klare Handlungsanweisungen für die Belegschaft.

Parallel dazu wurden weitere Optionen ausgelotet. Die Bestrebungen sind jedoch noch in ihren Anfängen und Work-in-Progress. Eine grobe Skizze zu zwei Bereichen folgt in den nächsten Abschnitten.

Hilfe durch Künstliche Intelligenz (KI)?

Vielversprechende Resultate erzielte ein kleiner KI-Prototyp, spezifischer 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 selber Kriterien beigebracht, 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. Z.B. war die KI der Meinung, dass bestimmte E-Mail Signaturen relevant sind.

Wir konnten beim Review schnell feststellen, dass diese Schlussfolgerung wohl für den genutzten Datensatz nachvollziehbar war, sich jedoch nicht generalisieren lassen würde. Das heisst, 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), welches 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 einfach entscheiden, welche Daten das Unternehmen verlassen dürfen und welche nicht. Der Aufwand verschiebt sich dabei nur von DLP auf DRM, aber 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 in Form von KI oder Cloud Lösungen anbieten.

Autor: Thomas Lampart ist PMI zertifizierter Projektmanager und IT Consultant bei adesso Schweiz. Er hat einen Master of Science in Computational Biology und Bioinformatics und interessiert sich für alle Themen rund um Big Data und KI.

Bild: Unsplash.com / Austin Distel

Disclaimer: Dieser Artikel erscheint im Rahmen der Partnerschaft mit esurance, einem Mitglied von swissICT. Gemeinsam mit dem digitalen Versicherungsbroker esurance und dem Label swiss made software bietet swissICT seit April 2020 branchenspezifische und kostengünstige Versicherungslösungen an. Alle Informationen rund um dieses Angebot finden Sie unter www.swissict.ch/esurance