Einführung der E-Mail-Fehlerprävention im Nur-Bericht-Modus

Das Aktivieren einer Kontrolle, die mit jedem Absender kommuniziert, erfordert eine durchdachte Planung, um niemanden zu verärgern. Eine Warnung, die zu häufig erscheint, wird ignoriert, und eine Kontrolle, die ignoriert wird, schützt niemanden. Der Erfolg der Fehlervermeidung bei E-Mails hängt davon ab, wie sie eingeführt wird.

Kiteworks Agent and Human Error Prevention (AHEP) bietet Administratoren einen klaren Ansatz. Richtlinien können im Modus „Nur Bericht“ ausgeführt werden, wodurch jede Nachricht bewertet und protokolliert wird, ohne dass eine einzige Warnung angezeigt wird. Das Risiko besteht darin, diese Phase zu überspringen, da eine neue Richtlinie standardmäßig aktiviert ist und sofort nach dem Speichern durchgesetzt wird.

Dieser Artikel beschreibt die Einführung Schritt für Schritt: Vorbereitung der Plattform, Erstellung der Richtlinien, Auswertung der Ausgangslage und der Übergang von Vorschlagen zu Warnen – mit belegbaren Daten.

Executive Summary

Eine sinnvolle AHEP-Einführung erfolgt in fünf Schritten: Voraussetzungen der Plattform prüfen, Richtlinien mit Status „Nur Bericht“ anlegen, die Ausgangslage einige Wochen beobachten, Vorschlagen mit einer wichtigen Pilotgruppe testen und ausgewählte Richtlinien auf Warnen umstellen, wenn die Daten es belegen. Bestehende Kiteworks-Kunden benötigen keinen zusätzlichen Anbieter, da AHEP eine Funktion der Data Policy Engine auf der bereits eingesetzten Plattform ist. Das Ergebnis: Richtlinien, die auf Ihre E-Mails abgestimmt sind, eine Pilotgruppe, die die Warnungen im Kontext erlebt hat, und ein Audit-Trail für Ihre Verantwortlichen in den Bereichen Sicherheit und Datenschutz.

wichtige Erkenntnisse

1. Prüfen Sie die Voraussetzungen der Plattform, bevor Sie etwas konfigurieren. AHEP benötigt Release 9.5 und den Validation Service auf der containerisierten Service-Ebene, den der technische Support von Kiteworks auf Anfrage aktiviert.
2. Setzen Sie den Status vor dem Speichern auf „Nur Bericht“. Eine neue Richtlinie ist standardmäßig aktiviert und wird sofort durchgesetzt. Beginnen Sie daher mit dem Statusfeld, nicht mit dem Schwellenwert.
3. „Nur Bericht“ liefert eine Ausgangslage ohne Auswirkungen auf Anwender. Jede Nachricht wird bewertet und jede Erkennung protokolliert. Nach einigen Wochen zeigen die Daten, wo Risiken bestehen.
4. Beginnen Sie mit Vorschlagen, wechseln Sie zu Warnen, wenn die Daten es belegen. Vorschlagen informiert den Absender, ohne zu stören. Warnen verlangt eine bewusste Entscheidung, sobald Ihre Zahlen dies rechtfertigen.
5. Kennen Sie die Client-Abdeckung, bevor Sie einer Abteilung etwas zusagen. Warnungen funktionieren in der Kiteworks Web App und Outlook Classic. Planen Sie daher für Anwender auf anderen Clients entsprechend.

Vorbereitung der Plattform für AHEP

Bevor eine Richtlinie erstellt wird, muss die Plattform vorbereitet sein. AHEP ist ab Release 9.5 verfügbar. Kunden mit älteren Versionen müssen zunächst ein Upgrade durchführen und die weiteren Schritte um das Upgrade-Fenster herum planen. Der Validation Service, der Nachrichten bewertet, läuft auf der containerisierten Service-Ebene (RKE2) von Kiteworks auf mindestens einem Applikationsknoten und wird vom technischen Support von Kiteworks aktiviert.

Anfrage stellen

Öffnen Sie die Anfrage über das Kiteworks Community-Portal, bevor Sie etwas konfigurieren. Richtlinien, die ohne den dahinterliegenden Service erstellt werden, können ihre Aufgabe nicht erfüllen. Das erst nach der Ankündigung eines Piloten an eine Abteilung zu entdecken, ist vermeidbar peinlich.

Benötigte Rollen

Für die Erstellung von Richtlinien in der Data Policies App benötigen Sie die Rolle System, Application, Compliance oder Policy Manager oder eine benutzerdefinierte Rolle mit Data Policies Zugriff. Prüfen Sie frühzeitig, wer in Ihrem Unternehmen diese Rollen innehat, da der Projektverantwortliche oft nicht die Richtlinie selbst anlegen kann.

Richtlinien erstellen und mit „Nur Bericht“ starten

Wählen Sie in der Data Policies App „Neue Richtlinie“ und dann „Agent and Human Error Prevention“ oder starten Sie mit der AHEP-Vorlage, die die BCC-Empfehlung vorauswählt. Ändern Sie den Status vor dem Speichern auf „Nur Bericht“, da die Standardeinstellung aktiviert ist. Für die BCC-Richtlinie legen Sie gleichzeitig den Schwellenwert für externe Empfänger fest.

Ausgangslage auswerten

Lassen Sie die Richtlinien einige Wochen laufen. Jede Nachricht wird bewertet und jede Erkennung protokolliert, ohne dass ein Absender eine Warnung sieht. Prüfen Sie Erkennungen pro Richtlinie, die Anzahl der Fehlalarme sowie die betroffenen Absender und Teams. Vergleichen Sie die Zahlen mit Ihrem Incident-Log und den Meldungen Ihrer DLP-Lösung im gleichen Zeitraum. Die Ausgangslage zeigt, welche Richtlinie zuerst Aufmerksamkeit verdient und welcher Schwellenwert angepasst werden sollte.

Zwei Details, die Zeit sparen

Die Erkennung funktioniert am besten, wenn Benutzernamen einem Standardformat wie Vorname Nachname oder Nachname, Vorname folgen und geschäftliche E-Mail-Adressen wie vorname.nachname@unternehmen aufgebaut sind. Das ist besonders wichtig für die Richtlinie zu persönlichen Adressen, die den Empfänger mit der Identität des Absenders vergleicht.

Von Vorschlagen zu Warnen wechseln

Nehmen Sie die Richtlinie mit dem höchsten Wert und stellen Sie sie für eine Pilotgruppe auf „Aktiv“ mit der Direktive Vorschlagen. Recht und Finanzen sind sinnvolle Startpunkte, da eine fehlgeleitete Nachricht dort besonders teuer werden kann. Vorschlagen informiert den Absender, ohne zu stören – so zeigt der Pilot, wie die Anwender reagieren, ohne Reibung zu erzeugen.

Wann Warnen sinnvoll ist

Warnen verlangt vom Absender, die Warnung vor dem Versand zu bestätigen oder zu verwerfen. Stellen Sie ausgewählte Richtlinien auf Warnen um, wenn die Daten es rechtfertigen. Verwerfungen werden protokolliert – so zeigen die Überschreibungsraten, wo Schwellenwerte oder Schulungen angepasst werden müssen. Eine Abteilung, die jede BCC-Warnung verwirft, gibt Ihnen einen Hinweis auf den Schwellenwert.

Belege für Ihre Security- und Datenschutzverantwortlichen

AHEP-Richtlinien erscheinen in der Liste „Report by Policy“ in der Audit Log und Reports App. So erhalten Ihr CISO und Ihr Datenschutzbeauftragter einen Nachweis über Erkennungen, Direktiven und Entscheidungen – basierend auf Ihren eigenen E-Mails, nicht auf Schätzungen eines Anbieters.

Fehlervermeidung über die gesamte Kiteworks Data Control Plane aktivieren

Die Einführung von AHEP ist kein separates Projekt mit eigenem Anbieter, Konsole und Protokoll. Sie ist eine Erweiterung der Kiteworks Data Control Plane, die Sie bereits betreiben. Die Data Policy Engine steuert E-Mail, Filesharing, SFTP, Managed File Transfer und Formulare. AHEP ergänzt Empfängerprüfungen für Datenbewegungen im Moment der Entscheidung durch Menschen und KI-Agenten. Ereignisse werden in einem manipulationssicheren Audit-Trail protokolliert, der Ihr SIEM-Tooling speisen kann. Die Arbeit ergänzt Ihre bestehenden DLP- und IAM-Lösungen.

Wenn Sie bereits Kiteworks-Kunde sind, vereinbaren Sie eine Enablement-Session mit unserem Team. Gemeinsam planen wir das Upgrade auf 9.5, die Anfrage für den Validation Service und Ihre Ausgangslage im Modus „Nur Bericht“, damit die erste Warnung, die ein Absender sieht, bereits optimal abgestimmt ist.