Schutz vor fehlgeleiteten E-Mails – erkennt, was Data Loss Prevention (DLP) übersieht

Die meisten Sicherheitsteams betreiben ein Data Loss Prevention-Programm, das in der Regel wie vorgesehen funktioniert. Dennoch gelangen vertrauliche Daten per E-Mail an falsche Empfänger, weil Musterregeln nur den Inhalt einer Nachricht prüfen, nicht aber den Empfänger. Die Vermeidung fehlgeleiteter E-Mails schließt diese Lücke.

Stellen Sie sich eine Kundenliste vor, bei der vierzig Namen im An-Feld sichtbar sind, einen Vertrag, der eine Woche vor der Kündigung an ein persönliches Gmail-Konto gesendet wird, oder eine Domain, die sich durch einen Buchstaben vertippt. Der Absender ist autorisiert, die Datei darf das Unternehmen verlassen, und keine Regel schlägt an. Die Daten sind korrekt, der Empfänger jedoch falsch.

Dieser Artikel erklärt, wo Muster-basierte DLP an ihre Grenzen stößt, wie der Kiteworks Agent und Human Error Prevention (AHEP) den Empfänger bereits während des Schreibens einer Nachricht prüft und wie Sie die Lösung anhand Ihrer eigenen Vorfallhistorie testen können, bevor Sie sich entscheiden.

Executive Summary

Muster-basierte DLP und Empfängerprüfung beantworten unterschiedliche Fragen. DLP prüft, ob eine Nachricht Daten enthält, die sie nicht enthalten sollte. AHEP, eine Funktion der Kiteworks Data Policy Engine, prüft, ob der Empfänger für diese Nachricht sinnvoll ist – und zwar, solange der Absender das Problem noch beheben kann. Für Sicherheitsverantwortliche ist dies ein Kontrollmechanismus für eine Risikokategorie, die bestehende Tools nicht abdecken – bereitgestellt auf der Plattform, die bereits vertrauliche Daten in Bewegung steuert. Im Report Only-Modus können Sie das Risiko messen, bevor ein einziger Absender eine Warnung sieht.

Wichtige Erkenntnisse

1. DLP prüft die Daten, nicht den Empfänger. Autorisierte Daten, die an die falsche Person gesendet werden, passieren jede Musterregel – Empfängerfehler benötigen daher eine eigene Kontrolle. Die Anpassung von DLP-Regeln schließt diese Lücke nicht.
2. Fehlgeleitete E-Mails sind ein häufiges und gut dokumentiertes Vorfallmuster. Laut Osterman Research rangiert dieser Vorfalltyp mit 21 Prozent an erster Stelle der bei Datenschutzbehörden gemeldeten Vorfälle. 96 Prozent von über 300 befragten Führungskräften bei Abnormal berichten von Datenverlusten durch solche Fehler.
3. Jede AHEP-Richtlinie greift nur bei spezifischen Bedingungen. Empfängertyp, externes Volumen, Identitätsabgleich und Vorhandensein von Anhängen fließen in drei vorgefertigte Richtlinien ein, sodass Warnungen selten genug bleiben, um ernst genommen zu werden.
4. Im Report Only-Modus wird das Risiko gemessen, bevor jemand eine Warnung sieht. Jede Nachricht wird stillschweigend geprüft und protokolliert. So erhalten Sie eine Basislinie der Erkennungen pro Richtlinie, die Sie mit Ihrem Vorfallprotokoll und den DLP-Ergebnissen vergleichen können.
5. Jede Warnung und jede Entscheidung landet im Audit-Trail. Richtlinie, Anweisung, Empfänger, Reaktion und Zeitstempel werden erfasst – das unterstützt die Audit-Bereitschaft, wenn jemand nachweist, dass die Kontrolle funktioniert hat.

Warum Muster-basierte DLP einen falschen Empfänger nicht erkennt

DLP erfüllt eine wichtige Aufgabe und sollte keinesfalls deaktiviert werden. Sie prüft Nachrichten und Anhänge auf Daten, die das Unternehmen nicht verlassen dürfen, wie Kartennummern, Identifikatoren oder gekennzeichnete Dokumente. Das Problem beginnt, wenn die Daten das Unternehmen verlassen dürfen, aber der Empfänger falsch ist. Dann gibt es keine Regel, die greift, und der Vorfall fällt erst auf, wenn der tatsächliche Empfänger antwortet oder ein Kunde sich beschwert.

Was Musterregeln prüfen

Musterregeln prüfen die Nachricht selbst: ihren Text, ihre Anhänge, ihre Kennzeichnungen. Sie beantworten die Frage: Enthält diese Nachricht einen Datentyp, den wir einschränken? Das funktioniert bei Exfiltration und versehentlichen Leaks von Daten, die niemals per E-Mail versendet werden sollten. Es hilft jedoch nicht, wenn ein legitimes Dokument an eine ungewollte Partei geht.

Was sie nicht prüfen können

Auch benachbarte Tool-Kategorien schließen diese Lücke nicht. DSPM findet und klassifiziert vertrauliche Daten im ruhenden Zustand. IAM entscheidet, wer sich anmelden darf. Zero trust regelt, wer worauf zugreifen darf. Alle drei sind wertvoll, aber keiner prüft, ob die Person im An-Feld auch die ist, die der Absender gemeint hat. Diese Frage gehört in den Moment des Verfassens – daher muss eine Empfängerprüfung im Erstellungsfenster stattfinden.

Wie Kiteworks AHEP den Empfänger vor dem Versand prüft

AHEP ist Teil der Kiteworks Data Policy Engine und benötigt Release 9.5. Es prüft eine Nachricht bereits während des Schreibens und erneut, wenn der Absender einen Empfänger hinzufügt oder entfernt oder eine Datei anhängt. Die E-Mail wird weiterhin direkt vom Client an den Mailserver gesendet. Der AHEP Validation Service prüft nur die Nachricht und versendet selbst keine E-Mails.

Drei vorgefertigte Richtlinien für typische Empfängerfehler

Drei Richtlinien sind sofort einsatzbereit. Eine empfiehlt BCC, wenn die Anzahl externer Empfänger einen von Ihrem Administrator festgelegten Schwellenwert überschreitet. Eine verhindert das Senden an persönliche E-Mail-Adressen, wenn eine bekannte persönliche Domain, ein Identitätsabgleich mit dem Absender und ein nicht-inline Anhang zusammen auftreten. Eine erkennt Tippfehler in Domains, kennzeichnet Domains, die sich um einen Buchstaben von einer bekannten Consumer-Domain unterscheiden, sowie Domains ohne gültigen MX-Record. Administratoren legen für jede Richtlinie den Status auf Aus, An oder Report Only fest und wählen eine Suggest- oder Warn-Anweisung. Eine individuelle Entwicklung ist nicht erforderlich.

Warum Warnungen selten genug bleiben, um gelesen zu werden

Die Richtlinie für persönliche Adressen benötigt alle drei Bedingungen gleichzeitig, sodass eine persönliche Adresse ohne Anhang sie nicht auslöst. Diese Zurückhaltung ist bewusst gewählt. Menschen ignorieren Warnungen, die ständig erscheinen – eine Warnung, die nur bei erfüllten Bedingungen angezeigt wird, wird ernst genommen. Wenn eine Warnung erscheint, kann der Fehler direkt im Erstellungsfenster behoben werden: externe Empfänger ins BCC-Feld verschieben, Domain korrigieren oder den markierten Empfänger entfernen. Bei Suggest kann der Absender fortfahren. Bei Warn muss der Absender die Warnung erst beheben oder verwerfen. Es wird nichts stillschweigend blockiert.

Testen Sie AHEP mit Ihren eigenen Vorfalldaten

Sie müssen keine Herstellerangaben ungeprüft übernehmen. Lassen Sie jede Richtlinie einige Wochen im Report Only-Modus laufen. AHEP prüft und protokolliert jede Nachricht, ohne den Anwendern etwas anzuzeigen. Vergleichen Sie anschließend die Erkennungen mit Ihrem eigenen Vorfallprotokoll und den DLP-Ergebnissen im gleichen Zeitraum. Die Differenz ist Ihre eigene Zahl – und das stärkste Argument gegenüber Budgetverantwortlichen.

Was Sie vor dem Pilotbetrieb prüfen sollten

Planen Sie die Rahmenbedingungen. Warnungen funktionieren in der Kiteworks Web App und Outlook Classic. AHEP benötigt die Kiteworks containerisierten Services (RKE2) und den Validation Service, den der technische Support von Kiteworks aktiviert. Die Erkennung ist am genauesten, wenn Benutzernamen einem Standardformat folgen und geschäftliche Adressen wie vorname.nachname@unternehmen aufgebaut sind. Nicht jede persönliche Adresse wird erkannt, etwa bei einer eigenen Domain. Klären Sie diese Punkte vorab mit Ihrem Messaging-Team, damit der Pilot aussagekräftige Ergebnisse liefert.

Die Empfängerlücke auf der Kiteworks Data Control Plane schließen

Posture-Tools zeigen, wo vertrauliche Daten liegen und wer darauf zugreifen kann. DLP prüft, was das Unternehmen verlässt. Der letzte Schritt ist der aktive Schutz von Daten in Bewegung – genau dann, wenn eine Person oder ein KI-Agent einen Empfänger auswählt. Hier setzt die Kiteworks Data Control Plane an. AHEP ist in die Data Policy Engine integriert, die bereits E-Mail, Filesharing, SFTP, Managed File Transfer und Formulare steuert. So stehen Empfängerprüfungen direkt neben den datenbasierten Richtlinien, die Sie für andere Kanäle nutzen. Die Validierung läuft in Ihrer eigenen Umgebung, und jede Warnung, Verwerfung und Entscheidung wird in einem manipulationssicheren Audit-Trail erfasst, der Ihre SIEM-Tools speisen kann.

Die Lösung ergänzt Ihre Investitionen in DLP, DSPM und IAM, statt sie zu ersetzen. Wenn Sie die drei Richtlinien in der Kiteworks Web App und Outlook Classic in Aktion sehen möchten, vereinbaren Sie eine individuelle Demo mit unserem Team und bringen Sie Ihre eigenen Vorfallbeispiele mit.