Weitergeleitet ist nicht gemeldet

Awareness-Programme berichten meist eine Zahl: wie viele geklickt haben. Die zweite Zahl wäre interessanter. Wie viele haben die Mail gemeldet? Denn nur das hilft im Ernstfall. Ein Klick, der nicht passiert, verhindert einen Vorfall. Eine Meldung, die ankommt, verhindert die nächsten zwanzig.

Diese Zahl bekommt man aber erst, wenn der Meldeweg funktioniert. Und da fängt das Problem an.

Nicht jeder Meldeweg ist gleich gut

Der übliche Rat lautet: Verdächtige Mail an die IT weiterleiten. Das ist richtig, aber unpräzise, denn Weiterleiten ist nicht gleich Weiterleiten.

Beim gewohnten Weiterleiten im Text entsteht eine neue Nachricht, in der die alte im Rumpf zitiert wird. Absender der neuen Nachricht ist die meldende Person. Die Kopfzeilen der verdächtigen Mail sind damit weg, und mit ihnen die Authentifizierungsergebnisse, an denen man ablesen könnte, ob der Absender überhaupt echt war. Wird die Mail dagegen als Anhang weitergeleitet oder umgeleitet, bleibt das Original erhalten. Beim Umleiten steht die meldende Person in Resent-From und der ursprüngliche Absender bleibt im Kopf, beides ist sauber trennbar.

Sichtbar wird der Unterschied dann in der Meldung selbst. Dort stehen Melder und Absender als zwei getrennte Felder. Ist ein Resent-From vorhanden, sind beide gefüllt. Fehlt es, bleibt das Absenderfeld leer. Nicht aus Nachlässigkeit, sondern weil die Angabe in der Nachricht nicht mehr existiert. Wer eine solche Meldung in der Triage aufmacht, hat nichts, woran er ansetzen könnte.

Deshalb Buttons, aber als Komfort

Man kann Leuten beibringen, als Anhang weiterzuleiten oder umzuleiten. Nur kennen die wenigsten diese Funktionen, und in manchen Clients sind sie versteckt. Ein Ein-Klick-Meldebutton nimmt die Entscheidung ab: Er überträgt die Nachricht im Original, mit unveränderten Kopfzeilen, Text- und HTML-Rumpf.

Wichtig ist dabei die Einordnung: Die Buttons sind Komfort, keine Voraussetzung. Der Weg über ein Melde-Postfach funktioniert in jedem Programm und bleibt der unterstützte Standard. Wer keine Software ausrollen will oder darf, verliert dadurch nichts, solange als Anhang weitergeleitet oder umgeleitet wird.

Auch für HCL Notes

Es gibt Buttons für Thunderbird, Outlook, Gmail und HCL Notes. Der letzte ist der ungewöhnliche: Die verbreiteten Awareness-Werkzeuge liefern Outlook und Gmail, teils Thunderbird. Für Notes und Domino findet man wenig, obwohl die Plattform in Kommunen, Versicherern und Teilen des Mittelstands weiter läuft. Wir haben dafür einen Java-Agenten gebaut, weil die Domino-Java-Laufzeit HMAC-SHA256 und einen HTTPS-Aufruf mitbringt.

Dazu gehört ein Vorbehalt, den wir nicht verstecken. Der Agent kann die echte Originalnachricht nur liefern, wenn Domino die Mail als MIME belassen hat. Wandelt der Server eingehende Mail in Notes-Richtext um, was eine verbreitete Voreinstellung ist, sind die ursprünglichen Kopfzeilen verloren. Der Agent baut dann eine Ersatznachricht und markiert sie als rekonstruiert. Dieser Befund wird in der Triage angezeigt, damit niemand aus fehlenden DKIM-Angaben schließt, die Mail sei unauffällig gewesen. Wo sich die Serverkonfiguration nicht ändern lässt, ist der Postfachweg die genauere Meldemethode. Das steht so auch in unserer Anleitung.

Eine Meldung ist ein Vorgang, kein Postfacheintrag

Was danach passiert, entscheidet, ob Leute weiter melden. Jede Meldung bekommt eine Nummer, einen Status von neu bis bestätigt oder unbedenklich, eine Einstufung als Phishing, Spam, Schadsoftware, Chef-Masche oder legitim, einen Schweregrad und einen Zuständigen. Links und Anhänge werden ausgelesen und gezählt, und was die meldende Person selbst dazugeschrieben hat, steht als eigenes Feld da, statt im Zitat unterzugehen.

Der Teil, der uns am meisten Arbeit gemacht hat

Ein Meldebutton, der während einer Awareness-Kampagne läuft, bekommt zwangsläufig die eigenen Simulationen gemeldet. Es liegt nahe, die einfach als unbedenklich auszusortieren. Genau das wäre aber eine Einladung: Ein Angreifer müsste seine Mail nur wie eine Simulation aussehen lassen, um an der Triage vorbeizukommen.

Deshalb wird geprüft statt geglaubt. Der Abgleich schaut in die Authentifizierungsergebnisse der Nachricht und vergleicht sie mit der erwarteten Absenderdomain der eigenen Simulation. Und zwar mit einer Asymmetrie, die uns wichtig war: Ein ausdrückliches Fehlschlagen auf der erwarteten Domain wiegt schwerer als ein Treffer an anderer Stelle. Ein DKIM-Fail dort ist ein aktives Warnsignal, kein fehlender Beleg. Nebenbei ist das der Grund, warum die Kopfzeilen so wichtig sind: Ohne sie gibt es nichts zu prüfen.

Und was der Server zurückmeldet: möglichst wenig

Eine Meldung wird immer gleich bestätigt, ohne Auskunft darüber, ob die Mail als Simulation erkannt oder als Verdachtsfall angelegt wurde. Das ist Absicht. Der Button läuft im Postfach der meldenden Person, und diese Auskunft würde ihr verraten, welche Mails Simulationen sind. Damit ließe sich der Test aushebeln. Auch eine Ablehnung unterscheidet nicht zwischen falscher Signatur und abgelaufenem Zeitstempel, weil das nur beim Raten hülfe.

Wer meldet, bekommt keine Strafe

Üblicherweise bekommt Schulung, wer klickt. Bei uns kann auch die meldende Person dem Awareness-Kurs zugewiesen werden, ausdrücklich als Anerkennung. Das dreht das Signal um: Melden ist nichts, wofür man sich rechtfertigt, sondern das erwartete Verhalten. Dasselbe gilt für den Kanal: Simulationen laufen inzwischen auch per SMS, die Frage bleibt dieselbe.

Mehr auf der Modulseite. Warum die Melderate in den Human Security Index einfließt und was dabei bewusst nicht gemessen wird, stand hier gestern.