+KONF.13 Senden und Empfangen von Nachrichten
---+KONF.13.1 Filtern schädlicher Nachrichten
------+KONF.13.1.1 SPAM-Filter
------+KONF.13.1.2 Interpretation aktiver Inhalte
---+KONF.13.2 Authentizität von Nachrichten
------+KONF.13.2.1 Verifikation der Sendeberechtigung
------+KONF.13.2.2 Verifikation der Serversignatur
---+KONF.13.3 Kryptographische Signatur des Mailservers
---+KONF.13.4 Kryptographische Signatur durch Nutzende
---+KONF.13.5 Publikation der Sendeberechtigung
------+KONF.13.5.1 Strenge Senderpolicy
---+KONF.13.6 Publikation der Serversignatur
---+KONF.13.7 TLS-Reports
---+KONF.13.8 DMARC-Reports
---+KONF.13.9 Publikation der DMARC-Richtlinie
---+KONF.13.10 Authentifizierung der Server-Zertifikate über DNS
---+KONF.13.11 MTA-STS
|
KONF.13 Senden und Empfangen von Nachrichten
1. Přehled
| Název |
Standard |
|
KONF.13.1 Filtern schädlicher Nachrichten
|
Konfiguration für Interpersonelle Kommunikation SOLLTE eine Filterung schädlicher Nachrichteninhalte aktivieren. Erläuterung Unter Filterung schädlicher Nachrichteninhalte versteht man Verfahren, die Inhalte automatisch prüfen und unerwünschte, gefährliche oder manipulative Bestandteile erkennen, blockieren oder kennzeichnen können. Der Sinn dieser Vorgabe liegt darin, potenziell gefährliche Inhalte wie Phishing-Versuche, schadhaften Code oder gezielte Desinformation frühzeitig abzufangen. Ohne eine solche Filterung könnte Schadsoftware über Anhänge eingeschleust werden oder Mitarbeitende könnten durch manipulierte Links zu vertraulichen Datenabgaben verleitet werden. Mit einer wirksamen Filterung kann die Angriffsfläche reduziert, das Vertrauen in die Kommunikationskanäle erhöht und die Produktivität geschützt werden. Zur Umsetzung kann eine Institution technische Maßnahmen kombinieren: (1) E-Mail-Gateways oder Chat-Schnittstellen können mit Inhaltsfiltern ausgestattet werden, die bekannte Malware-Signaturen, verdächtige Links oder gefährliche Dateitypen erkennen. (2) Ergänzend kann heuristische Analyse und maschinelles Lernen eingesetzt werden, um Muster verdächtiger Inhalte zu identifizieren, auch wenn diese noch nicht in Signaturdatenbanken enthalten sind. (3) Regeln zur Blockierung bestimmter Dateianhänge (z. B. ausführbare Dateien) können eingerichtet werden, während sichere Alternativen für den Austausch bereitgestellt werden. (4) Schließlich kann ein klarer Prozess vorgesehen werden, um falsch-positive Erkennungen manuell zu prüfen und legitime Kommunikation wieder freizugeben.
|
|
KONF.13.2 Authentizität von Nachrichten
|
Konfiguration für Interpersonelle Kommunikation SOLLTE eine automatische Verifikation der Authentizität von Nachrichten aktivieren. Erläuterung Die Authentizität von Nachrichten bezeichnet in diesem Zusammenhang die nachweisbare Echtheit und Unverfälschtheit einer digitalen Mitteilung im Rahmen der interpersonellen Kommunikation, also die Sicherheit, dass eine Nachricht tatsächlich von der angegebenen Quelle stammt und auf dem Übertragungsweg nicht manipuliert wurde. Im Fachjargon wird hier häufig von Message Authenticity oder auch von Origin Authentication gesprochen, wobei beide Begriffe eng mit kryptographischen Verfahren wie Digital Signatures oder Message Authentication Codes (MACs) verbunden sind. Der Sinn dieser Anforderung liegt darin, sicherzustellen, dass Angreifer keine falschen Identitäten vortäuschen oder den Inhalt von Nachrichten unbemerkt verändern können. Andernfalls könnte etwa eine gefälschte Anweisung in einem Chat zu Fehlhandlungen führen oder ein manipuliertes Dokument im E-Mail-Verkehr falsche Entscheidungen auslösen. Eine automatische Verifikation kann hingegen das Vertrauen in die Integrität und Herkunft der Kommunikation gewährleisten. Zur Umsetzung kann eine Institution beispielsweise digitale Signaturen einsetzen, die durch etablierte Standards wie S/MIME oder OpenPGP realisiert werden können, sodass E-Mail-Programme die Echtheit automatisch überprüfen. Auch der Einsatz von Ende-zu-Ende-Verschlüsselung mit eingebauter Authentizitätsprüfung, etwa bei Protokollen wie Signal Protocol oder TLS mit Client-Zertifikaten, kann eine geeignete Maßnahme sein. Darüber hinaus kann die Integration einer zentralen Public Key Infrastructure (PKI) oder die Nutzung verteilter Vertrauensmodelle (z. B. Web of Trust) sicherstellen, dass Schlüsselpaare zuverlässig verwaltet werden und Anwender ohne manuelle Prüfungen von Zertifikaten auskommen.
|
|
KONF.13.3 Kryptographische Signatur des Mailservers
|
Konfiguration für E-Mail SOLLTE die Kryptographische Signatur des Mailservers aktivieren. Erläuterung Die kryptographischen Signatur des Mailservers ist ein digitaler Stempel des versendenden Mailservers selbst, mit dem die Authentizität des sendenden Mailservers belegt wird. Ein bekannter technischer Standard hierfür ist DomainKeys Identified Mail (DKIM). Diese Signatur wird durch den absendenden Mailserver (oder einen vorgeschalteten Dienst) unter Verwendung eines privaten kryptographischen Schlüssels erzeugt. Der Empfänger kann die Signatur mit einem öffentlich zugänglichen Schlüssel, der typischerweise im Domain Name System (DNS) der sendenden Domain hinterlegt ist, verifizieren. Diese Schutzmaßnahme kann die Glaubwürdigkeit der E-Mails erhöhen und trägt zur Prävention von Risiken bei, wie dem Spoofing des Absenders: Ein Angreifer könnte ohne eine solche Signatur die Identität der Institution vortäuschen, was zu Phishing-Vorfällen führen könnte.
|
|
KONF.13.4 Kryptographische Signatur durch Nutzende
|
Konfiguration für E-Mail KANN die kryptographische Signatur durch Nutzende aktivieren. Erläuterung Wird eine vom E-Mail vom Sendenden signiert, so können bei Empfang die Authentizität und Integrität der Nachricht verifiziert werden. Dies kann mit S/MIME oder PGP umgesetzt werden.
|
|
KONF.13.5 Publikation der Sendeberechtigung
|
Konfiguration für E-Mail SOLLTE die Publikation der eigenen Sendeberechtigung im DNS aktivieren. Erläuterung Dies wird typischerweise über spezielle DNS-Einträge wie den Sender Policy Framework (SPF) realisiert. Damit kann eine Institution im DNS festlegen, welche Mail-Server berechtigt sind, E-Mails im Namen ihrer Domäne zu versenden. Ein entsprechender DNS-Eintrag, der sogenannte SPF-Record, ermöglicht es empfangenden Mail-Servern, die Absender-Adresse einer eingehenden E-Mail zu überprüfen. Dies kann die Schutzwirkung gegen gängige Risiken wie E-Mail-Spoofing verbessern, bei dem sich ein Angreifer als legitimer Absender ausgibt, um die Empfänger zu täuschen. Ohne eine solche Konfiguration könnte ein Angreifer beispielsweise E-Mails mit gefälschter Absenderadresse verschicken, die scheinbar von der Geschäftsleitung stammen, um einen Nutzer zur Herausgabe von sensiblen Informationen zu verleiten (Phishing). Durch die Aktivierung von SPF kann das Risiko verringert werden, dass solche bösartigen Nachrichten die Postfächer von Nutzern erreichen. Es ist wichtig, den Eintrag sorgfältig zu erstellen, um alle legitimen Absender abzudecken, einschließlich Diensten von Drittanbietern. Ein häufiger Fehler ist, dass nicht alle autorisierten Mail-Server korrekt gelistet sind, was dazu führen könnte, dass legitime E-Mails fälschlicherweise als Spam markiert werden.
|
|
KONF.13.6 Publikation der Serversignatur
|
Konfiguration für E-Mail SOLLTE die Publikation der Serversignatur im DNS aktivieren. Erläuterung Eine Serversignatur, auch bekannt als DKIM (DomainKeys Identified Mail), ist eine kryptografische Signatur, die der E-Mail-Dienst der Institution an jede ausgehende Nachricht anhängt. Sie stellt sicher, dass die E-Mail tatsächlich von der angegebenen Domain gesendet wurde und während der Übertragung nicht manipuliert wurde. Ohne diese Signatur könnte ein Angreifer E-Mails im Namen der Institution versenden (E-Mail-Spoofing), was zu Phishing-Angriffen, dem Diebstahl von Zugangsdaten oder der Verbreitung von Malware führen könnte. Das Aktivieren der Publikation im DNS bedeutet, den öffentlichen Teil dieses kryptografischen Schlüssels im Domain Name System (DNS) der Domain zu veröffentlichen. Empfangende E-Mail-Server können diesen öffentlichen Schlüssel verwenden, um die Signatur der E-Mail zu verifizieren und somit deren Echtheit zu bestätigen. Zur Umsetzung kann die Institution E-Mail-Server-Software so konfigurieren, dass sie DKIM-Signaturen automatisch zu ausgehenden Nachrichten hinzufügt. Dies kann oft durch die Installation und Konfiguration von speziellen DKIM-Filter-Plugins erreicht werden.
|
|
KONF.13.7 TLS-Reports
|
Konfiguration für E-Mail KANN TLS-Reports [regelmäßig] überprüfen. Erläuterung TLS-Reports, auch TLS-RPT (Transport Layer Security Reporting) genannt, sind Berichte, mit denen Betreiber von Mailservern einander Probleme beim E-Mail-Versand über TLS melden können. Sie können Informationen zu Verbindungsproblemen und möglichen Sicherheitsproblemen enthalten. Hierzu kann TLS-RPT (Transport Layer Security Reporting) genutzt werden.
|
|
KONF.13.8 DMARC-Reports
|
Konfiguration für E-Mail KANN DMARC-Reports [regelmäßig oder bei Eingang] überprüfen. Erläuterung Mit DMARC kann der Empfänger dem Sender automatische Berichte über den DMARC-Status empfangener E-Mails bereitstellen. Diese Berichte liefern Hinweise auf fehlgeschlagene Authentifizierungsprüfungen, Fehlkonfigurationen oder Missbrauchsversuche. Eine automatisierte Auswertung unterstützt dabei, Zustellprobleme frühzeitig zu erkennen und geeignete Korrekturmaßnahmen abzuleiten.
|
|
KONF.13.9 Publikation der DMARC-Richtlinie
|
Konfiguration für E-Mail SOLLTE die Publikation der DMARC-Richtlinie aktivieren. Erläuterung Eine DMARC-Richtlinie legt fest, welchen Umgang sie sich von Empfängern wünschen, die E-Mails von ihrer Domain nicht authentifizieren können. Die Information der Empfänger kann über einen DMARC-Eintrag im DNS erfolgen.
|
|
KONF.13.10 Authentifizierung der Server-Zertifikate über DNS
|
Konfiguration für E-Mail SOLLTE die Authentifizierung der Server-Zertifikate über das DNS aktivieren. Erläuterung Die Authentifizierung der Server-Zertifikate über das DNS (Domain Name System) kann die Sicherheit der E-Mail-Kommunikation erheblich steigern. Dabei werden Zertifikatsinformationen in DNS-Einträgen genutzt, um die Echtheit der TLS/SSL-Zertifikate eines E-Mail-Servers zu überprüfen und sicherzustellen, dass man tatsächlich mit dem beabsichtigten Kommunikationspartner spricht. Techniken wie DANE (DNS-based Authentication of Named Entities) oder CAA (Certificate Authority Authorization) nutzen spezifische DNS-Resource Records (wie TLSA oder CAA Records), um entweder die verwendeten Zertifikate oder die autorisierten Zertifizierungsstellen im DNS zu hinterlegen. Dies kann verhindern, dass ein Angreifer eine gefälschte Identität vortäuschen oder eine Man-in-the-Middle-Attacke durchführen könnte, indem er ein nicht autorisiertes oder kompromittiertes Zertifikat präsentiert. Ohne diese zusätzliche Überprüfung könnte ein Angreifer beispielsweise den E-Mail-Verkehr der Institution abfangen und mitlesen, während er sich als der legitime Server ausgibt. Die Aktivierung dieser DNS-basierten Überprüfung kann also die Vertraulichkeit und Integrität der übertragenen E-Mails schützen. Zur Umsetzung werden Informationen über eigene Serverzertifikate im DNS hinterlegt und die Prüfung eingehender E-Mails auf hinterlegte Einträge der sendenden Servers aktiviert.
|
|
KONF.13.11 MTA-STS
|
Konfiguration für E-Mail SOLLTE MTA-STS aktivieren. Erläuterung Die Mail Transfer Agent Strict Transport Security (MTA-STS) ist ein wichtiger Standard zur Erhöhung der Sicherheit im E-Mail-Verkehr, der die verschlüsselte Zustellung von Nachrichten durch die Erzwingung von Transport Layer Security (TLS) auf der Übertragungsebene gewährleistet. MTA-STS stellt dabei sicher, dass versendende Mail Transfer Agents (MTA) nur verschlüsselte Verbindungen zum Ziel-MTA aufbauen, wodurch Downgrade-Angriffe oder die Umleitung auf unsichere Kanäle wirksam unterbunden werden können. Der Zweck dieser Vorschrift liegt darin, die Vertraulichkeit und Integrität von E-Mail-Inhalten während der Übertragung zu schützen. Ohne MTA-STS könnte ein Angreifer die Kommunikation abfangen und den unverschlüsselten E-Mail-Verkehr mitlesen (Eavesdropping) oder die Nachricht manipulieren, bevor sie den Empfänger erreicht. Die Aktivierung kann das Risiko minimieren, dass E-Mails über unsichere oder unauthentifizierte Verbindungen übertragen werden, selbst wenn die Ziel-Institution TLS unterstützt, was einen robusten Schutz gegen gängige Man-in-the-Middle-Angriffe bietet. Obwohl DNS-Based Authentication of Named Entities (DANE) eine stärkere kryptografische Authentifizierung des TLS-Zertifikats des Ziel-MTA bietet, sollte MTA-STS zusätzlich aktiviert werden, da es eine alternative oder ergänzende Schutzschicht darstellt, falls DANE beim Kommunikationspartner noch nicht implementiert ist oder dessen DNS-Sicherheit (DNSSEC) nicht vertrauenswürdig ist.
|
1.1 Odkazy
1.2 Identifikované požadavky
1.3 Související regulace
2. Identifikované požadavky
Požadavky
| Zdroj |
Požadavek |
3. Související regulace
|