Richtlinien zur E-Mail-Authentifizierung

!! ACHTUNG !! Dieses Dokument wurde automatisch aus dem Italienischen übersetzt

Richtlinien

Konfiguration des E-Mail-Dienstes zur Authentifizierung

Die italienische nationale Agentur für Cybersicherheit hat die Richtlinien für die Konfiguration des E-Mail-Dienstes zur Authentifizierung, mit dem Ziel, die Zuverlässigkeit des E-Mail-Dienstes für alle interessierten Organisationen zu stärken und sein allgemeines Sicherheitsniveau zu erhöhen.

Versionskontrolle

INDEX

1. Einleitung

1.1. Prämisse

E-Mail zählt heute zu den wichtigsten Diensten im digitalen Kontext, da sie zu den Hauptkanälen gehört, die von Organisationen und Nutzern für die Kommunikation und den Informationsaustausch verwendet werden¹.

Die Funktionsweise des E-Mail-Dienstes und insbesondere die Übermittlung von Nachrichten basieren auf dem SMTP-Protokoll, das jedoch keine adäquaten Mechanismen zur Absenderauthentifizierung und zum Schutz der Vertraulichkeit und Integrität der Nachrichten nativ integriert. Diese Schwachstellen machen den Dienst anfällig für Angriffe wie Spoofing, Phishing, Manipulation und das Abfangen von Nachrichten während der Übertragung.

Um die Schwächen des SMTP-Protokolls zu beheben und dadurch das Risiko der zuvor genannten Angriffe zu verringern, wurden im Laufe der Zeit Mechanismen zur Absenderauthentifizierung und zum Schutz der Nachrichtenintegrität entwickelt, wie beispielsweise SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting and Conformance).

Diese Richtlinien veranschaulichen diese Mechanismen mit dem Ziel, die Zuverlässigkeit des E-Mail-Dienstes zu stärken und sein allgemeines Sicherheitsniveau zu erhöhen, insbesondere im Hinblick auf die in Kapitel 4 beschriebenen Bedrohungen.

Die Gegenmaßnahmen und Protokolle, die zum Schutz der Vertraulichkeit von E-Mail-Nachrichten erforderlich sind (wie S/MIME und OpenPGP, die die Nachrichtenverschlüsselung betreffen), sind nicht Gegenstand dieser Richtlinien.

1.2. Verweisbestimmungen

1.3. Referenzdokumente

» Zurück zum Seitenanfang

2. Regulatorischer Kontext

Zum Schutz der digitalen Vermögenswerte des Landes, einschließlich E-Mail-Dienste und der dazugehörigen Infrastrukturen, besteht ein breites Spektrum an Sicherheitsmaßnahmen, die sich aus der geltenden Gesetzgebung ableiten und ständig aktualisiert werden.

Der höchste Schutzstandard für die kritischsten Dienste des Landes im Zusammenhang mit der nationalen Sicherheit wird durch den Nationalen Cybersicherheitsperimeter gewährleistet. Dieser wurde mit dem Gesetzesdekret Nr. 105 vom 21. September 2019, geändert durch das Gesetz Nr. 133 vom 18. November 2019, eingerichtet. Er sieht Sicherheitsmaßnahmen mit besonders hohem Schutzniveau vor, die in Anhang B des Dekrets des Premierministers Nr. 81 vom 14. April 2021 detailliert beschrieben sind. Diese Maßnahmen gelten für die Netzwerke, Informationssysteme und IT-Dienste öffentlicher und privater Einrichtungen, von denen die Ausübung einer wesentlichen Staatsfunktion oder die Bereitstellung einer wesentlichen Dienstleistung zur Aufrechterhaltung ziviler, sozialer oder wirtschaftlicher Tätigkeiten abhängt, die für die Interessen des Staates von grundlegender Bedeutung sind. Eine Gefährdung dieser Systeme könnte die nationale Sicherheit beeinträchtigen.

Darüber hinaus unterliegen E-Mail-Dienste, wie alle digitalen Dienste der öffentlichen Verwaltung, den Bestimmungen der sogenannten Cloud-Verordnung. Diese wurde gemäß Artikel 33-septies des Gesetzesdekrets Nr. 179 vom 18. Oktober 2012 erlassen und von der Nationalen Agentur für Cybersicherheit (ACN) mit dem Dekret Nr. 21007 vom 27. Juni 2024 aktualisiert. Gemäß dieser Verordnung sind alle öffentlichen Verwaltungen verpflichtet, ihre digitalen Daten und Dienste nach dem von der ACN erstellten Modell als gewöhnlich, kritisch oder strategisch einzustufen. Ziel dieser Maßnahme ist es, sicherzustellen, dass die digitalen Daten und Dienste der öffentlichen Verwaltung über digitale Infrastrukturen und Cloud-Dienste verarbeitet und bereitgestellt werden, die den in der Verordnung festgelegten Anforderungen, einschließlich der Sicherheitsanforderungen, entsprechend den Risiken der jeweiligen Einstufung entsprechen.

Mit dem Gesetzesdekret Nr. 138 vom 4. September 2024 (dem sogenannten NIS-Dekret) zur Umsetzung der Richtlinie (EU) 2022/2555 wurden auch – durch die Anhänge 1 und 2 der ACN-Festlegung 379907/2025 – die grundlegenden Sicherheitsmaßnahmen festgelegt, die wesentliche und wichtige Einrichtungen für die Zwecke der Verpflichtungen nach Artikel 23 und 24 des NIS-Dekrets ergreifen müssen, und ein Sicherheitsrahmen zur Stärkung des Schutzes von Netzwerk- und Informationssystemen, einschließlich E-Mail-Diensten, definiert.

» Zurück zum Seitenanfang

3. E-Mail-Dienstarchitektur

Wie bereits in der Einleitung erwähnt, basiert die Funktionsweise des E-Mail-Dienstes auf dem SMTP-Protokoll, das die Übertragung von E-Mail-Nachrichten vom Absender zum Empfänger regelt.

Das SMTP-Protokoll wurde ursprünglich 1982 als Store-and-Forward-Protokoll definiert ^. Dabei generiert der Absender eine Nachricht über seinen E-Mail-Client (Mail User Agent, MUA), der diese an den Mailserver des Absenders sendet. Dieser leitet die Nachricht über einen Mail Transfer Agent (MTA) – gegebenenfalls über einen oder mehrere zwischengeschaltete MTAs – an den MTA des Ziel-Mailservers weiter. Der Empfänger ruft die Nachricht über seinen E-Mail-Client (MUA) ab . [1]

Der Mail Transfer Agent (MTA) ist somit eine Komponente des E-Mail-Dienstes, die die Übertragung von E-Mail-Nachrichten vom Absender zum Empfänger übernimmt. MTA-Komponenten sind auf den Mailservern von Absender und Empfänger vorhanden, und es können auch zwischengeschaltete MTAs konfiguriert werden, beispielsweise zur Verwaltung von Verteilerlisten.

Obwohl der Begriff MTA eine bestimmte Komponente von E-Mail-Servern bezeichnet³, wird im Rahmen dieses Dokuments hauptsächlich auf die Funktion von E-Mail-Servern als MTAs Bezug genommen, wo keine Unklarheiten bestehen. Daher wird zur Vereinfachung der Darstellung häufig der Begriff E-Mail-Server anstelle des spezifischeren Begriffs MTA verwendet.

In diesem Leitfaden konzentrieren wir uns auf die Konfiguration der SPF-, DKIM- und DMARC-Protokolle, um Mailservern die Überprüfung der Authentizität und Integrität von E-Mail-Nachrichten zu ermöglichen.

» Zurück zum Seitenanfang

4. Bedrohungen

Das im vorherigen Kapitel vorgestellte SMTP-Protokoll war ursprünglich für den Einsatz in einem relativ kleinen akademischen Netzwerk konzipiert und berücksichtigte keine Aspekte der Sicherheit übertragener Nachrichten oder der Absenderauthentifizierung [1].

Die zunehmende Verbreitung von E-Mails und die systembedingten Schwächen des SMTP-Protokolls haben im Laufe der Zeit das Auftreten von Angriffen begünstigt, deren Haupttypen in den folgenden Absätzen kurz erläutert werden.

4.1. Absender-Spoofing

Spoofing ist eine Cyberangriffstechnik, bei der die Absenderadresse einer Nachricht gefälscht wird, sodass die Nachricht von einer vertrauenswürdigen Adresse zu stammen scheint (zum Beispiel von einem Kollegen, einem Bekannten oder dem eigenen Bankinstitut). Dadurch wird der Empfänger dazu verleitet, potenziell gefährliche Handlungen vorzunehmen, wie zum Beispiel einen E-Mail-Anhang zu öffnen oder auf in der Nachricht enthaltene Links zu klicken.

Diese Art von Angriff ist relativ einfach durchzuführen, da das SMTP-Protokoll keine Absenderauthentifizierungsmechanismen beinhaltet und es daher über den E-Mail-Client möglich ist, beim Versenden der Nachricht eine beliebige Absenderadresse zu konfigurieren.

Absender-E-Mail-Adresse: envelope-from und message-from

Das E-Mail-Nachrichtenformat sieht zwei separate Felder zur Angabe der Absenderadresse vor. Diese Felder heißen „envelope-from“ und „message-from“ : Das erste (auch als Rücksendeadresse bezeichnet, da es die E-Mail-Adresse angibt, an die Fehlermeldungen gesendet werden müssen, wenn eine E-Mail den Empfänger nicht erreicht) ist die Adresse, die für die korrekte Weiterleitung der Nachricht verwendet wird; das zweite ist die Adresse, die dem Empfänger im Nachrichtenkopf angezeigt wird.

In Anlehnung an das Versenden eines Briefes in einem Umschlag per Post stellt der Absendervermerk die Adresse des Absenders dar, die auf dem Briefumschlag angegeben ist, während der Absendervermerk der Kopfzeile im Brief entspricht, die angibt, wer den Brief an den Empfänger geschrieben hat.

Es ist wichtig zu beachten, dass die beiden Adressen nicht übereinstimmen müssen. Diese Unterscheidung ermöglicht die Verwaltung von Situationen wie beispielsweise dem Weiterleiten von Nachrichten von Drittanbietern, dem Versand über Mailinglisten oder automatischen E-Mail-Antworten.

Es ist durchaus möglich, jeden Absender sowohl auf der der Absenderadresse (die E-Mail-Adresse des Absenders, die dem Empfänger im Header der empfangenen Nachricht angezeigt wird) als auch auf der Ebene der Absenderadresse (die E-Mail-Adresse des Absenders, die für die Nachrichtenübermittlung verwendet wird) anzugeben.

Um diesen Bedrohungen entgegenzuwirken, ist es daher unerlässlich, Mechanismen bereitzustellen, die eine zuverlässige Authentifizierung des Absenders ermöglichen und überprüfen, ob die Person, die die Nachricht gesendet hat, tatsächlich dazu berechtigt ist.

4.2. Phishing

Phishing ist eine Cyberangriffstechnik, die auf den betrügerischen Erwerb von Informationen (wie zum Beispiel Anmeldeinformationen, Kreditkartennummern oder anderen sensiblen Daten) abzielt, in der Regel durch das Versenden von irreführenden Nachrichten, die den Anschein erwecken, von zuverlässigen Absendern zu stammen³.

Spoofing, das im vorangegangenen Absatz untersucht wurde, zählt zu den wichtigsten Techniken, die ein Angreifer einsetzt, um die Identität des Absenders zu fälschen und die Nachricht so aussehen zu lassen, als käme sie von einem legitimen Benutzer oder einer legitimen Domain.

Alternativ kann eine Absenderadresse/Domain verwendet werden, die einer für den Empfänger erkennbaren Adresse/Domain ähnelt. Dazu wird beispielsweise der sogenannte Anzeigename⁴ , um die scheinbare Authentizität der Nachricht zu verstärken.

Zum Versenden von Phishing-Nachrichten können auch legitime Konten verwendet werden, die zuvor vom Angreifer kompromittiert wurden.

Eine Phishing-Nachricht ist typischerweise so aufgebaut, dass sie beim Empfänger Dringlichkeit, Alarm oder wirtschaftliches Interesse erzeugt und Situationen schafft, die ihn zu impulsiven Reaktionen und bestimmten Aktionen verleiten, wie z. B. das Öffnen schädlicher Anhänge oder das Klicken auf Links, die zu scheinbar legitimen Webseiten weiterleiten, die aber in Wirklichkeit vom Angreifer mit dem Ziel erstellt wurden, Informationen zu stehlen und/oder Schadsoftware zu installieren.

Üblicherweise werden Phishing-Angriffe durchgeführt, indem dieselbe E-Mail-Nachricht an eine große Anzahl von Opfern versendet wird, ohne den Text an das jeweilige Profil der Opfer anzupassen.

Eine Variante des Phishings ist das sogenannte Spear-Phishing, bei dem der Angreifer das Profil des Opfers kennt und gezielt ins Visier nimmt.

Im Gegensatz zu einer herkömmlichen Phishing-E-Mail verwendet eine Spear-Phishing-Nachricht präzisere Kontextinformationen, um den Empfänger davon zu überzeugen, dass er mit einem vertrauenswürdigen Absender kommuniziert [2].

4.3. Manipulation von Nachrichten

Der Inhalt einer E-Mail kann, wie jede andere Kommunikation, die über das Internetnetzwerk übertragen wird und keine Ende-zu-Ende-Verschlüsselung (E2EE) verwendet, während der Übertragung zwischen Absender und Empfänger abgefangen und verändert werden (eine Art von Bedrohung, die gemeinhin als Man-in-the-Middle bezeichnet wird).

Folglich besteht neben dem Verlust der Vertraulichkeit die Möglichkeit, dass die empfangene Nachricht nicht mehr der ursprünglich vom Absender verfassten Nachricht entspricht.

Ein Angreifer könnte beispielsweise den Nachrichteninhalt manipulieren, um den Anschein zu erwecken, die Nachricht stamme von einem vertrauenswürdigen Absender, den Text oder darin enthaltene Links und/oder Anhänge verändern oder bösartigen Code einfügen.

Der Empfänger, der auf die scheinbare Echtheit der Nachricht vertraut, kann so dazu verleitet werden, potenziell schädliche Handlungen vorzunehmen, wie z. B. die Übermittlung von Anmeldeinformationen, die Autorisierung von Zahlungen oder das Öffnen schädlicher Dateien.

Um diesen Bedrohungen entgegenzuwirken, ist es daher unerlässlich, Mechanismen einzuführen, die die Integrität und Authentizität der Nachricht gewährleisten und sicherstellen, dass der empfangene Inhalt nicht verändert wurde und dass der Absender tatsächlich derjenige ist, für den er sich ausgibt.

» Zurück zum Seitenanfang

5. Gegenmaßnahmen

Kapitel 2 erinnerte an die Vorschriften, die Sicherheitsmaßnahmen auch zum Schutz von E-Mail-Diensten vorsehen. Dieses Dokument dient in erster Linie als Leitfaden für die Umsetzung der in diesen Vorschriften vorgesehenen und in Anhang Adie auch für die Konfiguration von E-Mail-Diensten relevant sind, um die mit den in Kapitel 4. Es sei jedoch darauf hingewiesen, dass die in diesem Leitfaden enthaltenen Hinweise auch für diejenigen empfohlen werden, die nicht den genannten Vorschriften unterliegen.

Die betreffenden Sicherheitsmaßnahmen beziehen sich nicht explizit auf die Konfiguration des E-Mail-Dienstes, sondern – je nach der betrachteten Verordnung – auf die Konfiguration von IT-Systemen und industriellen Steuerungssystemen (PSNC- und Cloud-Verordnung) bzw. Informations- und Netzwerksystemen (NIS2). Die in diesen Richtlinien behandelten E-Mail-Dienste fallen in beide Systemkategorien.

Im Folgenden werden insbesondere die SPF, DKIMund DMARC erläutert. Diese bieten Sicherheitsmechanismen, die darauf abzielen, die allgemeine Sicherheit des E-Mail-Dienstes und insbesondere die Absenderauthentifizierung und die Integritätskontrolle der Nachrichten zu stärken.

5.1. Lichtschutzfaktor

SPF – Sender Policy Framework ist ein Authentifizierungsprotokoll, das in RFC 7208und es einem Domaininhaber ermöglicht, festzulegen, welche IP-Adressen berechtigt sind, in seinem Namen E-Mails zu versenden, und die Richtlinien festzulegen, die der Empfänger anwenden muss, wenn die mit der Domain⁵ der E-Mail-Adresse des Absenders verknüpfte IP-Adresse nicht zu den explizit autorisierten Adressen gehört.

Die autorisierten IP-Adressen sind in einem DNS-TXT-Eintrag aufgeführt, der sich auf die Absenderdomäne bezieht und als SPF-Eintrag bezeichnet wird. Dies wird im nachfolgenden Abschnitt dieses Absatzes erläutert.

Auf diese Weise kann der ^E -Mail-Server des Empfängers beim Empfang einer Nachricht von einer bestimmten Domain den zugehörigen SPF-Eintrag abfragen und deren Ursprung authentifizieren, indem er überprüft, ob die IP-Adresse, von der die Nachricht empfangen wurde, zu denjenigen gehört, die berechtigt sind, Nachrichten im Namen der Domain zu senden.

Es ist wichtig zu beachten, dass die auf SPF-Ebene verifizierte Domain diejenige ist, die sich auf den Absender des Umschlags bezieht. Folglich reicht die alleinige Anwendung des SPF-Protokolls nicht aus, um Spoofing zu verhindern, da diese Art von Angriff auch auf der Absenderebene der Nachricht erfolgen kann⁷.

Wenn eine Organisation ihren E-Mail-Dienst ganz oder teilweise an einen Drittanbieter, beispielsweise einen Cloud-Anbieter, auslagert, muss sie sicherstellen, dass die von diesem Anbieter versendeten Nachrichten die SPF-Prüfung bestehen. Zu diesem Zweck sollte die Organisation die IP-Adressen, von denen die Anbieter im Namen der Domain der Organisation E-Mails versenden, in ihren SPF-Eintrag aufnehmen.

Bei automatischer E-Mail-Weiterleitung werden Nachrichten üblicherweise über einen Zwischenserver umgeleitet. Daher stimmt die IP-Adresse des Empfängers nicht mehr mit der ursprünglich vom Absender autorisierten Adresse überein. Um in solchen Fällen einen Fehler bei der SPF-Verifizierung zu vermeiden, müssen auch alle zwischengeschalteten Weiterleitungsserver autorisiert werden. Alternativ können Mechanismen wie SRS (Sender Rewriting Scheme) oder ARC (Authenticated Received Chain) eingesetzt werden, die insbesondere bei einer Vielzahl von zwischengeschalteten Weiterleitungsservern effektiver sein können.

Es sollte hervorgehoben werden, dass SPF nur dann wirklich effektiv ist, wenn es nicht nur vom Absender, sondern auch vom Empfänger korrekt konfiguriert wird. Insbesondere:

• Der Absender muss den SPF-Eintrag auf dem entsprechenden DNS-Server veröffentlichen, in dem die Adressen aufgeführt sind, die berechtigt sind, in seinem Namen E-Mails zu versenden;
• Der Empfänger muss seinen eigenen Mailserver so konfigurieren, dass er eine SPF-Verifizierung für empfangene Nachrichten durchführt und die daraus resultierenden Richtlinien einheitlich anwendet.

5.1.1. SPF-Aufzeichnung

Ein SPF-Eintrag ist ein DNS-Eintrag vom Typ TXT, dessen Name der Absenderdomäne entspricht und dessen Inhalt aus dem Abschnitt, der die Version angibt ^{, und} einer Reihe von Direktiven besteht, die das Verhalten des Mailservers des Empfängers festlegen, wenn eine Übereinstimmung zwischen der IP-Adresse der Absenderdomäne und einer Direktive vorliegt.

Die Direktiven werden durch einen Mechanismus gebildet, dem ein Qualifikator vorangestellt ist. Die wichtigsten in SPF-Einträgen verwendeten Mechanismen sind: [2]:

• ip4, listet autorisierte IPv4-Adressen auf;
• ip6, listet autorisierte IPv6-Adressen auf;
• a, autorisiert IP-Adressen, die im A-Record der Domain vorhanden sind;
• mx, autorisiert IP-Adressen, die sich auf die MX-Einträge der Domain beziehen;
• include, autorisiert IPs, die im SPF-Eintrag einer anderen Domain vorhanden sind;
• all, repräsentiert alle IP-Adressen, die nicht explizit über die anderen Mechanismen autorisiert wurden.

Der „All“ -Mechanismus ermöglicht insbesondere die Festlegung von Richtlinien für Nachrichten, die von IP-Adressen stammen, die von früheren Mechanismen nicht erfasst wurden.

Darüber hinaus stellt SPF die folgenden Qualifikatoren zur Verfügung, die Mechanismen zugeordnet werden können:

• + (pass) bedeutet, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, autorisiert sind. Es ist der Standardqualifizierer, wenn kein anderer angegeben ist;
• - (Fehler) bedeutet, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, nicht autorisiert sind;
• ~ (softfail) bedeutet, dass IP-Adressen, die dem zugehörigen Mechanismus entsprechen, wahrscheinlich nicht autorisiert sind. Diese Aussage ist weniger eindeutig als die vorherige. In diesen Fällen sollte die Meldung zwar akzeptiert, aber zur genaueren Analyse markiert werden. Sie wird beispielsweise bei der Fehlersuche oder wenn absehbar ist, dass die SPF-Verifizierung fehlschlagen könnte, verwendet
• ? (neutral) bedeutet, dass keine Angabe zu IP-Adressen erfolgt, die dem zugehörigen Mechanismus entsprechen. Standardmäßig wird die Nachricht akzeptiert.

Es ist wichtig zu betonen, dass der SPF-Eintrag in der Praxis so zusammengesetzt ist, dass er autorisierte IP-Adressen angibt. Anschließend wird die Direktive `-all` , um festzulegen, dass alle anderen Adressen nicht autorisiert sind (siehe dazu die folgenden Beispiele). Dies ist die empfohlene Konfiguration, da sie die explizite Angabe autorisierter IP-Adressen und den Ausschluss aller anderen ermöglicht.

In jedem Fall wird davon abgeraten, die Direktive +all (oder das äquivalente all) zu verwenden, da dies der Autorisierung aller IP-Adressen entsprechen würde.

Beispiele für SPF-Einträge

Eine bestimmte IP-Adresse autorisieren

v=spf1 ip4:203.0.113.0 -all

Der oben gezeigte SPF-Eintrag verwendet SPF Version 1 und autorisiert über den IPv4- Mechanismus die IP-Adresse 203.0.113.0 (da für den IPv4- Mechanismus kein Qualifizierer angegeben ist, wird implizit das Standardpluszeichen (+ ) verwendet). Die „-all“ bestehend aus dem „all“ -Mechanismus und dem „-“ (Fehler), legt fest, dass alle anderen Adressen nicht autorisiert sind.

Einen bestimmten IP-Adressraum autorisieren

v=spf1 ip4:203.0.113.0/24 -all

Der oben gezeigte SPF-Eintrag ist analog zum vorherigen, autorisiert aber alle IP-Adressen des Adressraums 203.0.113.0/24

Mehrere IP-Adressen autorisieren

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

Der oben gezeigte SPF-Eintrag autorisiert ausschließlich die IPv4-Adressen 203.0.113.22 und 203.0.113.44.

MX-Record-Adressen und eine bestimmte Domain autorisieren

v=spf1 mx include:spf.emailprovider.it -all

Der oben gezeigte SPF-Eintrag autorisiert ausschließlich die IP-Adressen der MX-Einträge derselben Domain wie der SPF-Eintrag sowie diejenigen, die für die Domain spf.emailprovider.it (zum Beispiel die Domain eines E-Mail-Dienstleisters) autorisiert sind.

5.1.2. Authentifizierungsprozess

Wenn der E-Mail-Server des Empfängers für die SPF-Verifizierung korrekt konfiguriert ist, ruft er beim Empfang einer neuen E-Mail den SPF-Eintrag der Absenderdomain ab, indem er den DNS-Server abfragt, der die Einträge dieser Domain enthält. Die Abfrage basiert auf der im Feld „Absender“ angegebenen Adresse. Lautet die Adresse im Feld „Absender“ beispielsweise alice@example.com, ruft der E-Mail-Server des Empfängers den SPF-Eintrag der Domain example.com.

Der Mailserver des Empfängers führt anschließend die SPF-Verifizierung durch und analysiert den SPF-Eintrag, um festzustellen, ob die IP-Adresse, von der die Nachricht empfangen wurde, berechtigt ist, E-Mails für die example.com . Besteht die E-Mail die SPF-Verifizierung, wird sie an den Empfänger zugestellt.

Wenn beispielsweise der SPF-Eintrag der Domain example.com v=spf1 ip4:203.0.113.22 -all lautet , würde die Überprüfung nur dann erfolgreich sein, wenn die IP-Adresse des Absenderservers 203.0.113.22 lautet ; bei jeder anderen Adresse würde sie fehlschlagen.

» Zurück zum Seitenanfang

5.2. DKIM

DKIM – DomainKeys Identified Mail ist ein Authentifizierungsprotokoll, das in RFC 6376 formalisiert ist und es einem Domaininhaber ermöglicht, die Authentizität von E-Mail-Nachrichten zu gewährleisten, indem er eine digitale Signatur (DKIM-Signatur) anhängt, die vom Mailserver mithilfe öffentlicher kryptografischer Algorithmen generiert und in die Header der zu übertragenden Nachricht eingefügt wird.

Damit der Empfänger überprüfen kann, ob die Nachricht während der Übertragung verändert wurde, wird der mit der DKIM-Signatur verknüpfte öffentliche Schlüssel in einem TXT-Eintrag des öffentlichen DNS der Absenderdomäne, dem sogenannten DKIM-Eintrag, gespeichert, der vom Empfänger-Mailserver beim Empfang der Nachricht abgefragt wird.

Die DKIM-Signatur und der DKIM-Datensatz werden in den nachfolgenden Abschnitten dieses Absatzes erläutert.

Wie bei SPF muss auch DKIM vom Absender und Empfänger korrekt konfiguriert werden, insbesondere:

• Der Absender muss seinen Mailserver so konfigurieren, dass er DKIM-Signaturen generiert und den DKIM-Eintrag im entsprechenden DNS-Server veröffentlicht;
• Der Empfänger muss seinen Mailserver so konfigurieren, dass er eine DKIM-Verifizierung für empfangene Nachrichten durchführt.

5.2.1. DKIM-Signatur

Die DKIM-Signatur wird aus bestimmten Elementen des Nachrichtentextes und der Header generiert und besteht aus einer Reihe von Schlüssel-Wert-Paaren, die Elemente spezifizieren, darunter:

• v: Protokollversion¹⁰;
• a: verwendeter Verschlüsselungsalgorithmus¹¹;
• d: Signaturdomäne, die die Authentizität der Nachricht erklärt¹²;
• s: Selektor, der angibt, nach welchem ​​DKIM-öffentlichen Schlüssel im DNS-Eintrag gesucht werden soll¹³;
• h: Liste der in der Signatur enthaltenen E-Mail-Header¹⁴;
• bh: Hash des Nachrichtentextes im Base64-Format¹⁵;
• b: tatsächliche digitale Signatur, die mit dem privaten Schlüssel erzeugt und im Base64-Format kodiert wurde¹⁶;
• x: Gültigkeitsdatum der Unterschrift;
• c: Art der Kanonisierung.

Die Kanonisierung ist der Prozess der Normalisierung von Nachrichtenelementen vor der digitalen Signatur. Dadurch werden die Auswirkungen kleiner Änderungen, die während der Übertragung auftreten können, wie z. B. wiederholte Leerzeichen oder Zeilenumbrüche, minimiert. Es gibt zwei Arten der Kanonisierung: die einfache, die eine exakte Übereinstimmung zwischen Original- und Empfangsnachricht erfordert, und die erweiterte, die Normalisierungen wie das Entfernen von Leerzeichen, die Umwandlung von Groß- in Kleinbuchstaben in den Headern und die Reduzierung aufeinanderfolgender Leerzeilen im Nachrichtentext anwendet.

5.2.2. DKIM-Datensatz

Der DKIM-Eintrag wird in einem DNS-Eintrag vom Typ TXT gespeichert, dessen Name die Struktur „ Selektor._Domainschlüssel.Domain “ aufweist. „_Domainschlüssel“ ist dabei eine Bezeichnung, die angibt, dass es sich um einen DKIM-Eintrag handelt. Der Inhalt des DKIM-Eintrags besteht aus einer Reihe von Schlüssel-Wert-Paaren, die unter anderem folgende Elemente spezifizieren:

• v: Protokollversion;
• k: Schlüsseltyp, standardmäßig RSA;
• p: Öffentlicher Schlüssel im Base64-Format.

Beispiel eines DKIM-Eintrags

Name: s1._domainkey.example.com
Wert: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

Der Beispiel-DKIM-Eintrag ist mit dem Selektor s1 der example.com , verwendet Version 1 und enthält den RSA-Public-Key im Base64-Format (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Authentifizierungsprozess

Wenn das DKIM-Protokoll auf den Mailservern von Absender und Empfänger korrekt konfiguriert ist, erstellt der Absender-Mailserver gemäß Abschnitt 5.2.1 die DKIM-Signatur der Nachricht, die dieser beigefügt wird. Die DKIM-Signatur enthält im „d“ die Signaturdomäne¹⁷ und im „b“ die mit dem privaten Schlüssel der Signaturdomäne erzeugte digitale Signatur der Nachricht.

Nach dem Empfang einer Nachricht ruft der Empfänger-Mailserver den DKIM-Eintrag der signierenden Domain („d“ der DKIM-Signatur) vom DNS-Server ab, der die Einträge dieser Domain enthält. Anschließend verwendet er den im DKIM-Eintrag enthaltenen öffentlichen Schlüssel, um die digitale Signatur („b“ ) zu verifizieren. Bei erfolgreicher Verifizierung wird die Nachricht an den Empfänger zugestellt.

5.2.4. Kryptografische Aspekte

Im Bereich der Kryptographie hat DKIM historisch gesehen den RSA- Algorithmus verwendet, insbesondere in der rsa-sha256 , die seit 2007 als Standard gilt. Die neue Alternative, die mit RFC 8463, ist Ed25519-SHA256, eine moderne Form der digitalen Signatur auf Basis elliptischer Kurven, die eine höhere Effizienz und wesentlich kompaktere Schlüssel gewährleistet.

Technisch gesehen ist RSA mit einer Schlüssellänge von 2048 Bit nach wie vor der universelle Standard. Allerdings sind die Schlüssel lang und die Signaturen relativ groß. Ed25519 hingegen bietet neunmal kürzere Schlüssel und viermal kleinere Signaturen bei einer bis zu dreißigmal höheren Signierleistung im Vergleich zu RSA 2048. Trotz dieser Vorteile ist die praktische Anwendung begrenzt: Im Jahr 2026 wird Ed25519 nur von wenigen Anbietern verifiziert, und einige große Netzbetreiber unterstützen weder Signierung noch Verifizierung zuverlässig. Daher eignet sich Ed25519 nicht als alleinige Lösung für den Produktiveinsatz.

Aus diesem Grund wird die Verwendung von Ed25519 trotz seiner technischen Überlegenheit zum Zeitpunkt der Erstellung dieses Dokuments nur in Kombination mit RSA mittels doppelter Signatur empfohlen – sowohl aus experimenteller Sicht als auch zur Gewährleistung zukünftiger Kompatibilität. Solange die großen Anbieter die Verifizierung nicht vollständig implementieren, bleibt RSA unerlässlich, um eine maximale Zustellungssicherheit zu gewährleisten.

Im Hinblick auf die langfristige Sicherheit ist zu beachten, dass weder RSA noch Ed25519 gegen Angriffe zukünftiger Quantencomputer resistent sind [3]und der Übergang zu Post-Quanten-Algorithmen neue DKIM-Standards erfordert, die derzeit noch nicht existieren. Daher ist es unerlässlich, die Entwicklungen der Kryptographie der nächsten Generation und zukünftige ACN-Empfehlungen in diesem Bereich zu beobachten.

Im Hinblick auf die Verwaltung kryptografischer Schlüssel muss der DKIM-Privatschlüssel durch strenge Sicherheitsmaßnahmen geschützt werden. Dazu gehört die Aufbewahrung auf isolierten Systemen, auf die nur autorisierte Dienste Zugriff haben, die Anwendung restriktiver Berechtigungen, die regelmäßige Rotation und die ständige Überwachung, um unbefugten Zugriff oder Kompromittierungen zu verhindern.

» Zurück zum Seitenanfang

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance ist ein Authentifizierungsprotokoll, das in RFC 7489integriert.^Dadurch kann ein Domaininhaber den Empfängern von Nachrichten, die von dieser Domain gesendet werden, die Richtlinien für den Umgang mit Nachrichten mitteilen, die die SPF- und DKIM-Verifizierung nicht bestehen.

DMARC führt insbesondere einen Authentifizierungsmechanismus ein – die sogenannte Ausrichtung –, der die Übereinstimmung zwischen den von SPF und DKIM authentifizierten Domänen und der Domäne des „message-from“ -Felds der empfangenen Nachricht überprüft. Die Ausrichtungsprüfung zwischen dem „message-from “-Feld und der SPF/DKIM-Domäne schlägt in jedem Fall fehl, wenn die entsprechende SPF/DKIM-Verifizierung fehlschlägt (siehe Abbildung 4).

Die Ausrichtung kann im strikten Modus überprüft werden , bei dem eine exakte Übereinstimmung zwischen den durch SPF/DKIM authentifizierten Domänen und derjenigen im Feld „message-from“ erforderlich ist , oder im lockeren Modus , bei dem es ausreicht, dass die primären Domänen übereinstimmen, selbst wenn die Subdomänen unterschiedlich sind.

Im Relaxed- Modus würde beispielsweise für die Domains sub1.example.com und sub2.example.com eine Übereinstimmung für die DMARC-Verifizierung gefunden (da die primäre Domain example.com identisch ist). Im Strict- Modus hingegen würde die DMARC-Überprüfung aufgrund der fehlenden exakten Übereinstimmung der Domains fehlschlagen.

Durch die Überprüfung der Ausrichtung würde DMARC selbst dann, wenn es einem Angreifer gelänge, die SPF- und/oder DKIM-Prüfungen mit einer anderen Absenderadresse als der von SPF und/oder der authentifizierten Signaturdomäne authentifizierten Absenderadresse zu bestehen, die Diskrepanz erkennen und so eine kohärente und zuverlässige Überprüfung der Identität des Absenders gewährleisten [2] .

Die Richtlinien für den Umgang mit Nachrichten, die die DMARC-Verifizierung nicht bestehen,^sind in einem TXT-Eintrag des zugehörigen DNS-Servers der Absenderdomäne, dem sogenannten DMARC-Eintrag, festgelegt und werden im nachfolgenden Abschnitt dieses Absatzes erläutert.

DMARC ermöglicht es Empfängern außerdem, Berichte an die Inhaber der Absenderdomain zu senden, wenn Nachrichten vorgeben, von dieser Domain zu stammen. So kann der Domaininhaber überprüfen, ob und in welchem ​​Umfang seine Domain unberechtigt genutzt wird, indem er beispielsweise analysiert, wie viele der Nachrichten, die vorgeben, von seiner Domain zu stammen, tatsächlich auf ihn zurückführbar sind.

Wie bei SPF und DKIM muss auch DMARC vom Sender und Empfänger korrekt konfiguriert werden, insbesondere:

• Der Absender muss den DMARC-Eintrag in seinem DNS veröffentlichen, in dem die Richtlinien für den Umgang mit Nachrichten, die die DMARC-Verifizierung nicht bestehen, angegeben sind;
• Der Empfänger muss seinen Mailserver so konfigurieren, dass er eine DMARC-Verifizierung für empfangene Nachrichten durchführt.

5.3.1. DMARC-Datensatz

Der DMARC-Eintragsname hat die Struktur _dmarc.domain, wobei _dmarc eine Bezeichnung ist, die angibt, dass es sich bei dem DNS-Eintrag um einen DMARC-Eintrag handelt, und domain die Domäne ist, auf die sich die Richtlinie bezieht.

Der DMARC-Eintrag besteht aus einer Reihe von Schlüssel-Wert-Paaren, die Elemente spezifizieren, darunter:

• v: DMARC-Protokollversion²⁰;
• p: Richtlinie, die auf Nachrichten angewendet werden soll, die die DMARC-Verifizierung nicht bestehen; kann einen der Werte none, quarantineoder reject;
• aspf: Ausrichtungsmodus für die SPF-Prüfung (kann relaxiert, Standardwert oder strikt);
• adkim: Ausrichtungsmodus für die DKIM-Prüfung (kann relaxiert, Standardwert oder strikt);
• rua: E-Mail-Adressen, an die aggregierte Berichte mit statistischen und zusammenfassenden Informationen über Nachrichten, die von der Absenderdomäne empfangen wurden, gesendet werden sollen;
• ruf: E-Mail-Adressen, an die detaillierte Berichte über einzelne Nachrichten gesendet werden sollen, die von der Absenderdomäne empfangen wurden und bei denen die DMARC-Verifizierung fehlgeschlagen ist.

Beispiel eines DMARC-Eintrags

Name:
_dmarc.example.com
Wert:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Der Beispiel-DMARC-Eintrag ist mit der example.com , verwendet Version 1 und legt die Ablehnungsrichtlinie für Nachrichten fest, die die DMARC-Verifizierung nicht bestehen. Er fordert strikten Modus (s) für die Überprüfung der Ausrichtung von SPF- und DKIM-Domains an und sendet aggregierte Berichte an die E-Mail-Adresse dmarc-reports@example.com und Fehlerberichte an die Adresse dmarc-fail@example.com.

5.3.2. DMARC-Richtlinien

Wie im vorherigen Absatz beschrieben, gibt der DMARC-Eintrag die Richtlinie an, die der empfangende Mailserver für Nachrichten anwenden soll, die die DMARC-Verifizierung nicht bestehen. Folgende Richtlinien sind möglich:

• keine: Die Absenderdomäne gibt keine Hinweise auf die Zustellung von Nachrichten, die die DMARC-Verifizierung nicht bestehen;
• Quarantäne: Die Absenderdomäne gibt an, dass Nachrichten, die die DMARC-Verifizierung nicht bestehen, als verdächtig einzustufen sind (z. B. einer weiteren Prüfung unterzogen, als Spam behandelt oder als verdächtig gekennzeichnet werden);
• reject: Die Absenderdomäne gibt an, dass Nachrichten, die die DMARC-Verifizierung nicht bestehen, zurückgewiesen werden sollen.

5.3.3. Richtlinienprüfung und Antragsverfahren

Wenn das DMARC-Protokoll auf den Mailservern von Absender und Empfänger korrekt konfiguriert ist, ruft der Empfänger-Mailserver nach dem Empfang einer Nachricht die SPF- und DKIM-Einträge ab, um die entsprechenden Überprüfungen durchzuführen, sowie die DMARC-Überprüfung (detailliert im Anfang von Abschnitt 5.2.4 beschrieben). Falls die Nachricht die DMARC-Überprüfung nicht besteht, wird die im DMARC-Eintrag angegebene Richtlinie (keine, Quarantäne oder Ablehnung) angewendet.

Beachten Sie, dass jeder Mailserver eigene Heuristiken und Richtlinien zur Bestimmung der Zustellung einer Nachricht anwenden kann und dabei auch die Ergebnisse von SPF-, DKIM- und DMARC-Prüfungen berücksichtigt. Daher gibt es im Allgemeinen nach den genannten Prüfungen einen zusätzlichen Entscheidungsprozess („Standardfilter“ in Abbildung 5), der weitere Prüfungen (wie beispielsweise Anti-Spam- und Anti-Malware-Filter) umfassen kann.

Des Weiteren kann der empfangende Mailserver Folgendes übertragen:

• an die im „rua“ des DMARC-Eintrags angegebenen Adressen: Zusammenfassungsberichte mit statistischen und zusammenfassenden Informationen über Nachrichten, die von der Absenderdomäne empfangen wurden;
• An die im „ruf“ des DMARC-Eintrags angegebenen Adressen werden detaillierte Berichte über einzelne Nachrichten gesendet, die von der Absenderdomäne empfangen wurden und bei denen die DMARC-Verifizierung fehlgeschlagen ist.

» Zurück zum Seitenanfang

6. Schlussfolgerungen

Wie im vorangegangenen Kapitel erörtert, ist es zur bestmöglichen Abwehr von Bedrohungen im Zusammenhang mit der Identitätsfälschung des Absenders erforderlich, dass alle drei untersuchten Protokolle gemeinsam implementiert werden und insbesondere, dass [3]:

• Die Absenderdomäne veröffentlicht SPF-, DKIM- und DMARC-Einträge korrekt im DNS;
• Der Mailserver des Absenders ist so konfiguriert, dass Nachrichten mit DKIM signiert werden;
• Der Mailserver des Empfängers ist so konfiguriert, dass er SPF- und DKIM-Verifizierungen durchführt und DMARC-Richtlinien anwendet.

Im Hinblick auf die Protokollumsetzung werden außerdem folgende Empfehlungen formuliert: [2]:

• Konfigurieren Sie SPF, indem Sie festlegen, welche IP-Adressen berechtigt sind, E-Mails im Namen der Domain zu versenden; für Domains, die nicht für die E-Mail-Übertragung verwendet werden, z. B. solche, die ausschließlich für Websites bestimmt sind, sollte dennoch ein SPF-Eintrag erstellt werden, der explizit angibt, dass es für diese Domain keine gültigen E-Mail-Absender gibt;
• Verwenden Sie modernste Verschlüsselungsprotokolle und -algorithmen, die für DKIM-Schlüssel als sicher gelten. Zum Zeitpunkt der Erstellung dieses Dokuments wird 2048-Bit-RSA empfohlen
• den auf dem Mailserver gespeicherten DKIM-Privatschlüssel angemessen schützen, indem restriktive Zugriffsrechte festgelegt werden und sichergestellt wird, dass nur die Mailserver-Software Leserechte für den Schlüssel besitzt;
• Um die Auswirkungen einer möglichen Kompromittierung des privaten Schlüssels zu minimieren, sollte jeder Mailserver mit einem eindeutigen Schlüsselpaar und Selektor konfiguriert werden
• den privaten Schlüssel sowohl vor versehentlicher Offenlegung als auch vor Zugriffs- oder Änderungsversuchen durch einen Angreifer schützen;
• vorausgesetzt, dass die Software, die mit Mailinglisten zusammenhängt, die DKIM-Signaturen eingehender Nachrichten überprüft und ausgehenden Nachrichten neue DKIM-Signaturen hinzufügt;
• Verwenden Sie für jeden Drittanbieter, der im Namen der Organisation E-Mails versendet, eindeutige DKIM-Schlüsselpaare;
• DKIM-Schlüsselpaare sollten regelmäßig (mindestens alle sechs Monate) rotiert werden, um die Auswirkungen einer möglichen Kompromittierung zu minimieren
• Schlüssel bei Verdacht auf Kompromittierung unverzüglich widerrufen;
• DMARC-Berichte überwachen, um Konfigurationsfehler oder Missbrauchsversuche zu erkennen.

Weitere Einzelheiten entnehmen Sie bitte den in den Referenzdokumenten.

Es ist festzustellen, dass zum angemessenen Schutz der E-Mail-Sicherheit neben den hier untersuchten Authentifizierungsprotokollen weitere Protokolle existieren, die nicht Gegenstand dieser Richtlinien sind, wie beispielsweise TLS (Transport Layer Security) , das die Verschlüsselung des Übertragungskanals gewährleistet, sowie SMIME und OpenPGP , die sich mit der Ende-zu-Ende-Verschlüsselung und der Nachrichtenauthentifizierung befassen.

Es sei außerdem darauf hingewiesen, dass – obwohl es sich im engeren Sinne nicht um ein E-Mail-Sicherheitsprotokoll handelt – die Implementierung von DNSSEC (Domain Name System Security Extensions) zur Erhöhung der Sicherheit von E-Mail-Diensten empfohlen wird. DNSSEC ist eine DNS-Protokollerweiterung, die DNS-Einträgen kryptografische Signaturen hinzufügt, um die Integrität und Authentizität von DNS-Anfragen zu gewährleisten. Dank DNSSEC werden beispielsweise Informationen zu SPF-, DKIM- und DMARC-Einträgen während der Übertragung geschützt, wodurch das Risiko von Manipulationen verringert und somit die Sicherheit von E-Mail-Diensten erhöht wird.

» Zurück zum Seitenanfang

Anhang A: Sicherheitsmaßnahmen

Nationaler Cybersicherheitsperimeter (PSNC)

PR.IP-1: Referenzverfahren (sogenannte Baselines) werden für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen definiert und verwaltet, die Sicherheitsprinzipien (z. B. das Prinzip der minimalen Funktionalität) beinhalten.

1. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes aussagt:
   • a) die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen geltenden Sicherheitsrichtlinien und die ausschließliche Verwendung der gewählten Konfigurationen;
   • b) die Liste der verwendeten IT- und industriellen Steuerungssystemkonfigurationen und die Verweise auf entsprechende Referenzverfahren;
   • c) die Prozesse, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen.

Cloud-Regulierung – Digitale Infrastrukturen und Dienste für die öffentliche Verwaltung

PR.IP-01: Referenzverfahren (sogenannte Baselines) werden für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen definiert und verwaltet, die Sicherheitsprinzipien (z. B. das Prinzip der minimalen Funktionalität) beinhalten.

1. Richtlinien und Verfahren werden unter Berücksichtigung der Anwendungssicherheit definiert, um eine angemessene Unterstützung für die Planung, Realisierung und Aufrechterhaltung von Anwendungssicherheitsfunktionen zu gewährleisten. Diese müssen mindestens jährlich überprüft und aktualisiert werden.
2. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes aussagt:
   • a) die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen geltenden Sicherheitsrichtlinien und die ausschließliche Verwendung der gewählten Konfigurationen;
   • b) die Liste der verwendeten IT- und industriellen Steuerungssystemkonfigurationen und die Verweise auf entsprechende Referenzverfahren;
   • c) die Prozesse, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen.
3. Die grundlegenden Sicherheitsanforderungen für verschiedene Anwendungen werden definiert und dokumentiert.
4. Es werden Kennzahlen technischer Art definiert und implementiert, die zur Überwachung des Grades der Einhaltung festgelegter Sicherheitsanforderungen und Compliance-Verpflichtungen nützlich sind.
5. Zur Behebung von Anwendungsschwachstellen und zur Wiederherstellung der Anwendungssicherheit gibt es einen Prozess, der die Behebung nach Möglichkeit automatisiert.
6. Es gibt ein Verfahren zur Überprüfung der Gerätekompatibilität mit Betriebssystemen und Anwendungen.
7. Es gibt ein System zur Verwaltung von Abweichungen im Hinblick auf Betriebssysteme, Patches und/oder Anwendungen.

Cloud-Regulierung – Cloud-Dienste für die öffentliche Verwaltung

PR.IP-01: Referenzverfahren (sogenannte Baselines) werden für die Konfiguration von IT-Systemen und industriellen Steuerungssystemen definiert und verwaltet, die Sicherheitsprinzipien (z. B. das Prinzip der minimalen Funktionalität) beinhalten.

1. Richtlinien und Verfahren werden unter Berücksichtigung der Anwendungssicherheit definiert, um eine angemessene Unterstützung für die Planung, Realisierung und Aufrechterhaltung von Anwendungssicherheitsfunktionen zu gewährleisten, die mindestens jährlich überprüft und aktualisiert werden müssen [IaaS, SaaS].
2. Es gibt ein detailliertes, aktualisiertes Dokument, das – auch in Bezug auf die Kategorie ID.AM – mindestens Folgendes aussagt:
   • a) die für die Entwicklung von Konfigurationen von IT- und industriellen Steuerungssystemen geltenden Sicherheitsrichtlinien und die ausschließliche Verwendung der gewählten Konfigurationen;
   • b) die Liste der verwendeten IT- und industriellen Steuerungssystemkonfigurationen und die Verweise auf entsprechende Referenzverfahren;
   • c) die Prozesse, Methoden und Technologien, die zur Einhaltung der Sicherheitsrichtlinien beitragen [SaaS].
3. Die grundlegenden Sicherheitsanforderungen für verschiedene Anwendungen werden definiert und dokumentiert.
4. Es werden technische Kennzahlen definiert und implementiert, die zur Überwachung der Einhaltung definierter Sicherheitsanforderungen und Compliance-Vorgaben dienen. 5. Für die Anwendungssicherheit existiert ein Prozess zur Behebung von Anwendungsschwachstellen und zur Wiederherstellung, der die Behebung nach Möglichkeit automatisiert.
5. Es gibt ein Verfahren zur Überprüfung der Gerätekompatibilität mit Betriebssystemen und Anwendungen [PaaS, SaaS].
6. Es gibt ein Variationsmanagementsystem in Bezug auf Betriebssysteme, Patches und/oder Anwendungen [PaaS, SaaS].

NIS 2

PR.PS-01: Konfigurationsmanagementpraktiken werden etabliert und angewendet.

1. Für zumindest relevante Informations- und Netzwerksysteme sind deren sichere Basiskonfigurationen (gehärtet) definiert und in einer aktualisierten Liste dokumentiert.
2. In Übereinstimmung mit den in Maßnahme GV.PO-01 genannten Richtlinien werden Verfahren in Bezug auf Punkt 1 eingeführt und dokumentiert.

» Zurück zum Seitenanfang

Bibliographie

[1] NIST, „Technische Notiz 1945“.
[2] NIST, „NIST-Sonderveröffentlichung 800-177 Revision 1“.
[3] Nationale Agentur für Cybersicherheit, „Post-Quanten- und Quantenkryptographie – Vorbereitung auf die Quantenbedrohung“.
[4] Nationale Agentur für Cybersicherheit, „Framework für E-Mail-Authentifizierung“.

» Zurück zum Seitenanfang