Ein Risikoregister für die E-Mail-Authentifizierung sollte erläutern, welcher Unternehmensdienst geschädigt werden könnte und welche Entscheidung dieses Risiko verringert. „DMARC „fehlt“ ist ein technischer Befund und keine vollständige Risikoerklärung. Verknüpfen Sie die Bedingung mit einem glaubwürdigen Bedrohungs- oder Fehlerpfad, einem betroffenen Prozess, vorhandenen Sicherheitsmaßnahmen und einem verantwortlichen Eigentümer.
Beschreiben Sie den Dienst und das Szenario
Erfassen Sie für jeden Eintrag den Dienst, die Domäne, den Anwendungseigentümer, den technischen Zustand, den Beweiszeitpunkt und die wahrscheinlichen Folgen. Halten Sie die Unsicherheit explizit. Ein unbeobachteter Absender stellt eine Beweislücke dar, während ein verifizierter, nicht ausgerichteter, legitimer Absender einen Authentifizierungsfehler darstellt. Beides beweist nicht automatisch, dass ein Angreifer den Dienst ausgenutzt hat.
RFC 9989 Gibt die Domänenauthentifizierung an und Ausrichtung Verhalten. Seine Schutzmaßnahmen stellen nicht sicher, dass jede authentifizierte Anfrage legitim ist. Ein Risikoregister muss den direkten Identitätswechsel Ihrer Domain von einem kompromittierten autorisierten Konto oder einem solchen unterscheiden Lookalike-Domäne das die Authentifizierung für sich selbst besteht.
Trennen Sie inhärentes und verbleibendes Risiko
Beschreiben Sie das Szenario vor den Kontrollen und erläutern Sie dann, was sich durch die einzelnen vorhandenen Schutzmaßnahmen ändert. Bei Rechnungsanweisungen kann die Zahlungsrückrufüberprüfung auf betrügerische Geschäftsanfragen reagieren, die durch die Domänenauthentifizierung allein nicht gelöst werden können. Bedeuten Sie nicht, dass die Existenz einer schriftlichen Rückrufrichtlinie beweist, dass die Leute diese konsequent befolgen.
Verwenden Sie die von der Organisation vereinbarten Wahrscheinlichkeits- und Auswirkungsdefinitionen. Vermeiden Sie es, erfundene Präzision wie eine jährliche Betrugswahrscheinlichkeit von 17,3 % ohne Beweise darzustellen. Wenn die Daten nicht ausreichen, verwenden Sie eine qualitative Bewertung mit Begründung und Überprüfungsauslöser. Halten Sie fest, wer befugt ist, das verbleibende Risiko zu übernehmen, anstatt die technische Freigabe durch einen E-Mail-Administrator als geschäftliche Akzeptanz zu betrachten.
Verwenden Sie ein verlinktes Beispiel
Angenommen, der hypothetische Eintrag R-1 betrifft die Gehaltsabrechnung. Die Bedingung ist das Fehlen aktueller, ausgerichteter Nachweise für einen registrierten kritischen Dienst. Die mögliche Folge sind verpasste Gehaltsabrechnungsbenachrichtigungen, wenn eine ungetestete Route während der Durchsetzung fehlschlägt. Dies ist ein bedingtes Szenario und keine Behauptung, dass Mitarbeiter Nachrichten verpasst haben. Die Finanzabteilung ist Eigentümer des Dienstes, das E-Mail-Team ist für die Untersuchung zuständig und für den Abschluss ist ein aktueller Routentest sowie eine Bestätigung des Dienstinhabers erforderlich.
R-2 deckt den Identitätsbetrug bei Rechnungszahlungen über eine Lookalike-Domain im Besitz des Angreifers ab. Die vorgeschlagene Kontrolle ist eine unabhängige Überprüfung über eine bereits vertrauenswürdige Kontaktroute. Das Veröffentlichen einer strengeren Richtlinie auf der Domain des Opfers erfüllt den Abschlusstest von R-2 nicht. Fordern Sie für jeden Eintrag eine Feststellung, einen Eigentümer, eine Entscheidung und einen expliziten Schließungsnachweis an, bevor Sie das vorgeschlagene Register als vollständig betrachten. Hierbei handelt es sich um eine empfohlene Überprüfungsregel, nicht um eine durchgeführte Validierung oder den Nachweis, dass eine Kontrolle funktioniert.
Halten Sie das Register umsetzbar
Wählen Sie die Behandlung explizit aus: Abhilfe schaffen, die riskante Aktivität vermeiden, gegebenenfalls eine definierte Exposition übertragen oder das verbleibende Risiko durch den autorisierten Entscheidungsprozess akzeptieren. Legen Sie ein Fälligkeitsdatum und einen Überprüfungsauslöser fest. Ein Behandlungsplan ist kein Beweis für den Abschluss; Bewahren Sie den eigentlichen Test- oder Entscheidungsdatensatz separat auf.
Diese hypothetischen Einträge veranschaulichen unterschiedliche Szenarien, nicht beobachtete Angriffe oder akzeptierte Geschäftsrisiken. Eine Vollständigkeitsprüfung kann fehlende Felder identifizieren, jedoch keine Risikobewertung validieren oder feststellen, dass tatsächliche Sicherheitsmaßnahmen funktionieren. Bewahren Sie die tatsächlichen Beweise und die genehmigte Annahmeentscheidung getrennt von der vorgeschlagenen Behandlung auf.
Überprüfen Sie das Register nach Migrationen, neuen Absendern, Vorfällen und Geschäftsänderungen. Schließen Sie nur das spezifische Szenario, dessen Beweise den angegebenen Test erfüllen, und bewahren Sie genügend Verlauf auf, um zu erklären, warum es geschlossen wurde.
In den Abschnitten 2.3 und 3.2 NIST SP 800-30 Rev. 1 werden Risikofaktoren, Bewertungsansätze und die Dokumentation von Bewertungsergebnissen beschrieben. Sie unterstützen die explizite Angabe von Wahrscheinlichkeit, Auswirkung und Unsicherheit; Bei den oben genannten E-Mail-spezifischen Registerfeldern und Beispielen handelt es sich um eine vorgeschlagene Anwendung und nicht um eine vorgeschriebene Compliance-Checkliste. Leitfaden zur Risikobewertung.