E-Mail-Sicherheit auf Knopfdruck. Geht doch!
SPF, DKIM und DMARC sind in aller Munde und teilweise sogar zur Pflicht geworden. Viele Firmen trauen sich jedoch nicht an die Umsetzung. Unser Partner Net at Work zeigt in diesem Webcast wie einfach es sein kann, den Absender einer E-Mail zu überprüfen, wenn man die richtigen Werkzeuge verwendet.
Auf Knopfdruck geben Sie Ihren Kommunikationspartnern die Möglichkeit, E-Mails aus Ihrem Hause einwandfrei zu identifizieren und gefälschte E-Mails mit Ihrer Domäne abweisen zu können. Darüber hinaus haben Sie die Möglichkeit zu erkennen, ob Ihre Domäne für Spam- und Malware-E-Mails missbraucht wird.
Ein weiterer wichtiger Aspekt ist beispielsweise der Schutz vor gefälschten PayPal-Rechnungen. Überlassen Sie die Absenderprüfung nicht Ihren Mitarbeitern, sondern einem E-Mail-Security Gateway Made in Germany.
Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.
The technologies are:
The following figure illustrates the protocol relations.
The use of SPF, DKIM, and DMARC are no substitute for email message encryption itself or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.
Keep in mind that SPF, DKIM, and DMARC are offerings for other emails servers. As a sending party, you do not control if and how SPF, DKIM, and DMARC are evaluated by the receiving server. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.
The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies, but to describe the implementation.
Each domain is used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name, if you will). An SPF RR is always valid for the entire DNS zone.
mcsmemail.de. 3600 IN TXT "v=spf1 mx a:mail.mcsmemail.de ?all"
The following screenshot illustrates adding a new SPF TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox remains empty.
Example explained:
v=spf1 SPF Version
mx MX server records defined within the DNS zone are valid senders
a:mail.mcsmemail.de The additional DNS hostname defined as A resource record is a valid sender as well
?all Neutral validation of non listed servers that send emails for this domain
SPF records can be created by using one of the various online resources.
DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case its called selector.
A DKIM TXT record is always created as a record in the subdomain _domainkey.
nsp._domainkey.mcsmemail.eu. 3600 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"
The following screenshot illustrates adding a new DKIM TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains the selector nsp followed by the subdomain _domainkey.
v=DKIM1 DKIM version
k=rsa Public key encryption method
p=MIGfMA.... The DKIM public key
DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.
_dmarc.mcsmemail.de. 3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"
The following screenshot illustrates adding a new DMARC TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains always the value _dmarc.
v=DMARC1 DMARC version
p=none No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject) rua=mailto:DMARCRUA@mcscmemail.de Email address for status reports
ruf=mailto:DMARCRUF@mcscmemail.de Email address for error reports
fo=1 Error report type
adkim=s DKIM alignment, s = strict
aspf=s SPF alignment, s = strict
rf=afrf Error report message format, afrf = Abuse Report Format following RFC 5965
The DMARC policy (p) should be raised step-by-step. The results for each policy type are:
Recommended reading on this topic: Google Support Post.
DMARC DNS zone entries can easily be checked by using the Net at Works PowerShell tool. The PowerShell script can only be used with NoSpamProxy11+. But there are some online tools available as well.
Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365?
Contact us at office365@granikos.eu or visit our website http://www.granikos.eu.
Für die Prüfung von gültigen E-Mail Absendern stehen unterschiedliche Technologien zur Verfügung. Jede für sich genommen stellt aber nur einen Baustein einer Gesamtlösung dar. Nach aktuellem Standard ist die Empfehlung, alle drei Technologien zu implementieren.
Die Technologien sind:
Das nachfolgende Schaubild verdeutlicht die Relation der Protokolle zu einander.
Die Konfiguration von SPF, DKIM und DMARC ist kein Ersatz für E-Mail Nachrichtenverschlüsselung oder eine Transportverschlüsselung bei der E-Mail Übertragung. Vielmehr mehr dienen die genannten drei Technologien der Erkennung und Bewertung von gültigen Absendern und stellen einen Schutzmechanismus vor Spam dar.
Man darf nicht vergessen, dass die Konfiguration der drei Technoligen nur ein Angebot für andere E-Mail Server darstellt. Als Absender hat man schlicht keine Kontrolle darüber, ob und wie SPF, DKIM oder DMARC von der empfangenden Seite ausgewertet werden. Werden sie aber ausgewertet, so müssen die Konfigurationen korrekt und fehlerfrei sein und keine Testeinträge mehr enthalten.
Die nachfolgenden Abschnitte beschreiben insbesondere die DNS Konfiguration für SPF, DKIM und DMARC. Dieser Blogeintrag stellt keine detaillierte Bewertung der drei Technologien dar, sondern beschreibt deren Implementierung.
Für jede Domäne, die E-Mails versendet, ist ein SPF Eintrag (Resource Record) in der DNS Zone einzutragen. Ein SPF Eintrag ist immer vom Typ TXT und nutzt keinen Hostnamen (oder Resource Record Namen). Er gilt immer für die gesamte zu betrachtende Zone.
Das nachfolgende Beispiel zeigt das Anlegen eines SPF TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen bleibt leer.
Die im Beispiel verwendeten Einträge bedeuten:
v=spf1 Die SPF Version des Texteintrage
mx Die in der DNS Zone konfigurierten MX Servereinträge für eingehende E-Mails sind valide Sender
a:mail.mcsmemail.de Der in der DNS Zone existierende A Resource Record ist ebenfalls an valider Sender
?all Neutrale Bewertung von nicht genannten Systemen, die ebenfalls E-Mails mit dieser Domäne senden
Die Erstellung der SPF Konfiguration erfolgt am einfachsten über einen der zahlreiche Online-Konfiguratoren. Diese werten bereits die aktuelle Konfiguration der DNS Zone aus.
Bei einem DKIM Eintrag erfolgt die Konfiguration ebenfalls über einen TXT Eintrag in der DNS Zone der Absenderdomäne. Im Gegensatz zum SPF Eintrag ist ein Name für den Resource Record verpflichtend. Im Zusammenhang mit DKIM spricht man hier vom einem Selektor.
Ein DKIM DNS Eintrag erfolgt immer unterhalb der DNS Subdomäne _domainkey.
Das nachfolgende Beispiel zeigt das Anlegen eines DKIM TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält den Selektor nsp und die Subdomäne _domainkey.
v=DKIM1 Die DKIM Version des DNS Eintrages
k=rsa Verschlüsselungsmethode des öffentlichen Schlüssels
p=MIGfMA.... Der öffentliche Schlüssel des DKIM Schlüsselpaares
Die Konfiguration von DMARC erfolgt ebenfalls über einen TXT Eintrag in der DNS Zone der absendenden Domäne. Für die Konfiguration wird der definierte Resource Record Name _dmarc verwendet.
Das nachfolgende Beispiel zeigt das Anlegen eines DMARC TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält immer den Namen _dmarc.
v=DMARC1 Die DMARC Version des DNS Eintrages
p=none Keine definierte Policy für DMARC (Dies sollte immer das Startszenario sein, bevor man zu Quarantine oder Reject wechselt)
rua=mailto:DMARCRUA@mcscmemail.de E-Mail Adresse für aggregierte Statusberichte
ruf=mailto:DMARCRUF@mcscmemail.de E-Mail Adresse für Fehlerbericht
fo=1 Definition der Art des Fehlerberichtes
adkim=s Definition DKIM Prüfung, s = strict
aspf=s Definiton der SPF Prüfung, s = strict
rf=afrf Nachrichtenformat des Fehlerberichtes, afrf = Abuse Report Format nach RFC 5965
Die Richtlinie (Policy, p) zur Auswertung und Reaktion sollte langsam gesteigert werden. Je Richtlinie sind die Ergebnisse wie folgt:
Sehr empfehlenswert zu diesem Thema ist ein Supportartikel von Google.
Für die Überprüfung der DNS Zoneneinträge kann das PowerShell Tool von Net at Work verwendet werden. Das PowerShell script kann nur mit NoSpamProxy 11 oder höher verwendet werden. Ebenso stehen zahlreiche Online-Tools zur Verfügung. Unten finden Sie direkt Verlinkungen zu den Tools von MXToolbox.
Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption. E-Mail Security Made in Germany. Wir beraten Sie gerne: info@granikos.eu
On July 28st 2015 Elastica, Inc., will host a cloud security webcast about
Nitin Kumar, Service Deployment Manager, Cisco Cloud Web Security and Kapil Raina, Cloud Security Expert at Elastica, talk about
More about this webcast
Interested in how to secure your Cloud apps and services? Contact uns at info@granikos.eu for a free SaaS audit to identify all the Cloud Apps already in use in your organization. Find the Shadow ITdeployed by your employees.
Anfang Juli wurde Version 11 der erfolgreichen Anti-Spam und E-Mail Verschlüsselungslösung NoSpamProxy veröffentlicht.
NoSpamProxy eignet sich sowohl für E-Mail Umgebungen, die sich rein On-Premises befinden, als auch für den Betrieb mit Office 365. Gerade hier zeigt sich der absolute Mehrwert durch den Einsatz der zentralen S/MIME Verschlüsselung oder des Portals zum einfachen und sicheren Austausches großer Dateien.
Ein schneller Blick auf die Unterschiede in der NoSpamProxy Verwaltungskonsole zeigt einen prägnaten neuen Menüpunkt.
Mit der neuen DKIM Funktion ist es ein Leichtes, DKIM Signaturen für die eigenen Domänen zu erstellen und diese im Regelwerk von NoSpamProxy anzuwenden. Mit Hilfe von DKIM wird sichergestellt, dass eine mit DKIM signierte Nachricht wirklich von der sendenden Domäne stammt. Ein empfangendes E-Mail System kann so die Echtheit des Absenders überprüfen.
In der Vergangenheit war die Einrichtung und Konfiguration von DKIM nicht trivial. In diesem Fall ist die Schlüsselerzeugung und die Bereitstellung des öffentlichen Schlüssels extrem einfach gehalten und beschränkt sich auf drei Schritte.
Schritt 1: Auswahl der gewünschten eigenen Domäne und Festlegung des DNS Names (Selector)
Nun wird in der Regel für ausgehende E-Mails die DKIM Signierung aktiviert. Mehr ist nicht mehr erforderlich, um eine zusätzliche E-Mail Sicherheitsfunktion zu aktivieren. Gerade beim Betrieb mehrerer E-Mail Gateways wird die Einfachheit der Konfiguration deutlich, da die DKIM Einrichtung nur einmal ausgeführt werden muss.
Ein weiteres neues Feature von NoSpamProxy ist die Möglichkeit, E-Mails mit einem zentral gesteuerten Disclaimer zu versehen. Neben dem Hinzufügen von rein rechtlichen Informationen, dem klassischen Disclaimer, können auch unternehmensweite E-Mail Signaturen mit Benutzerinformationen aus dem Active Directory hinzugefügt werden.
Die Verwaltung und Konfiguration erfolgt über eine eigene Weboberfläche, die für den Administrator bequem über die NoSpamProxy Verwaltungsoberfläche erreichbar ist.
Die Bereitstellung als Webseite ist besonders vorteilhaft für Unternehmen, in denen die Konfiguration und Pflege der E-Mail Signaturen einer Abteilung außerhalb der IT unterliegt. Für die Pflege der Disclaimer-Konfigurationen ist lediglich ein Browser und natürlich die erforderliche Berechtigung zur Verwaltung notwendig.
Die Funktion für zentrale Disclaimer in NoSpamProxy werden wir in einem separaten Blogartikel und einer Schritt-für-Schritt Anleitung beleuchten.
Version 11 von NoSpamProxy zeigt erneut, dass sichere E-Mail Kommunikation mit Software Made in Germany bequem und einfach zu realisieren ist. Es gibt keinen Grund, keine E-Mail Verschlüsselung und sichere E-Mail Übertragung einzusetzen.
Sie möchten die E-Mail Kommunikation Ihres Unternehmens sicherer machen? Sie möchten mehr über E-Mail Verschlüsselung erfahren? Wir helfen Ihnen gerne weiter, rufen Sie uns an 02433 9524780 oder senden Sie uns eine E-Mail an info@granikos.eu.
Wir selber begleiten das Produkt schon seit einigen Jahren und sind gerade vom Einsatz in Kombination mit Office 365 überzeugt.
Über das Desaster der Antragstellung für die NRW Soforthilfe 2020 wurde schon viel geschrieben und konnte den Eindruck gewinnen, dass Maßnahmen zum Schutz der Kommunikation und gegen weitere Betrugsversuche unternommen werden. Augenscheinlich hatte man nur die Antragstellung über das Online-Formular im Blick. Die dazugehörige E-Mail-Kommunikation der Bezirksregierung Köln war und ist aktuell nicht Bestandteil grundlegender Schutzmaßnahmen.
Das folgende Beispiel einer empfangenen E-Mail der Bezirksregierung Köln mit dem Absender Corona-Soforthilfe@bezreg-koeln.nrw.de habe ich zum Anlass genommen, mir die Konfiguration der Absenderdomäne einmal genauer anzuschauen. Die Ergebnisse sind beängstigend.
Ausgangspunkt der Recherche ist die empfange E-Mail-Nachricht. In dieser sind alle benötigten Informationen enthalten.
Eine E-Mail-Nachricht besteht, wie ein klassicher Brief, aus zwei Teilen. Zum einen gibt es den Umschlag, der alle Zustellinformationen, enthält, und als Zweites den Inhalt, der die lesbaren Informationen und vielleicht auch Dateianhänge für dem Empfänger bereithält.
Für eine genauere Betrachtung der E-Mail-Zustellung sind die Informationen des Umschlages, die sog. Kopfinformationen, von großem Interesse. Ich habe diese Informationen mit Hilfe des Message Header Analyzers von Microsoft in ein besser lesbares Format gebracht. Der nachfolgende Screen zeigt die wichtigsten Kopfinformationen der E-Mail:
Besonders interessant sind die rot umrandeten Zeilen 1 - 10. Diese Zeilen geben uns Aufschluss über alle beteiligten internen Systeme der IT.NRW, die als zentraler IT-Dienstleister für die Bezierksregierung Köln tätig ist. Die unkenntlich gemachten Textstellen beinhalten Informatioen über:
Als eine der einfachsten Schutzfunktionen für E-Mail-Nachrichten, die an externe Empfänger gesendet werden, werden die Informationen interner Systeme aus dem Kopfinformationen der E-Mail entfernt. Hierdurch wird sichergestellt, dass keine Informationen über interne Computeradressen oder -name nach aussen gelangen. Diese Informationen lassen u.U. Rückschlüsse zu, die eine möglichen Hackerangriff begünstigen können. Moderne E-Mail-Systeme entfernen solche Informationen mit Hilfe einer Header-Firewall aus einer E-Mail.
Idealerweise hätten die Kopfinformationen mit dem grünumrandeten Eintrag aus Zeile 11 begonnen. Das dort als Submitting Host eingetragene System ist das für die externe Zustellung verantwortliche System.
Die Informationen der Zeilen 1 -10 gehören nicht in eine externe E-Mail.
Nach einem Blick auf die Kopfinformationen der E-Mail geht es mit einer Prüfung der technischen Einstellungen für die E-Mail-Kommunikation der Absenderdomäne bezreg-koeln.nrw.de weiter.
Die einfachste Prüfung einer Absenderdomäne ist die Überprüfung auf E-Mail-Systeme für den Empfang von E-Mail-Nachrichten. In den meisten Fällen sind die diese Systeme auch für den Versand von Nachrichten zuständig. Wenn eine Domäne auch E-Mail-Nachrichten empfängt, muss sie über mindestens einen speziellen DNS-Eintrag verfügen. Mit Hilfe eines DNS-Eintrages vom Typ MX wird festgelegt, welche Systeme E-Mail-Nachrichten von anderen Absendern empfangen.
Der folgende Screenshot zeigt das Ergebnis der Überprüfung der MX-Einträge vom 6. Mai 2020.
Für die Domäne bezreg-koeln.nrw.de werden zwei Systeme mit unterschiedlicher Präferenz (Pref-Spalte) aufgeführt. Das System mit Präferenz 60 hat gegenüber dem zweiten System die höhere Priorität und wird daher bevorzugt von zustellenden Systemen angesprochen. Sollte das System nicht antworten, erfolgt ein Zustellversuch an das zweite System mit Präferenz 80.
Ein besonderes Augenmerk gilt den IP-Adressen der Systeme. In den Kopfinformationen der E-Mail hatte das sendende System die Adresse 93.184.128.152. Diese Adresse gehört zu keinem beiden aufgeführten Systeme. Damit ist klar, dass es noch weitere E-Mail-Systeme gibt, die augenscheinlich nur für den Versand verwendet werden. Aber dazu im nächsten Abschnitt mehr.
Eine weitere wichtige Information wird uns von MXToolbox ebenfalls mitgeteilt. Die Domäne verfügt über keinen DMARC-Eintrag. Was das ist und warum es gut ist, solch einen Eintrag vorzuhalten, erkläre ich weiter unten.
MX-Einträge sind für die E-Mail-Kommunikation existenziell. Neben diesem Eintragstyp gibt es noch weitere, die eine E-Mail-Kommunikation sicherer machen können. Kommen wir daher zur IP-Adresse des sendenden Systems zurück.
Ein System, das E-Mail-Nachrichten empfängt, verfügt über keinerlei Informationen, welche Systeme für den Versand einer Domäne berechtigt sind. Als Eigentümer einer Domäne kann ich mit Hilfe eines SPF-Eintrages definieren, welchen Systemen es explizit erlaubt ist, für meine Domäne E-Mail-Nachrichten zu versenden.
Der folgende Screenshot zeigt das Ergebnis der SPF-Prüfung für die Domäne bezreg-koeln.nrw.de vom 6. Mai 2020.
Es ist kein SPF-Eintrag vorhanden. Empfangende E-Mail-Systeme haben keine Möglichkeit zur Überprüfung des sendenden Systems. MIt dem Fehlen dieses Eintrages wird der Versand von betrügerischen E-Mail-Nachrichten begünstigt, wenn nicht sogar wissentlich in Kauf genommen.
Das Vorhandensein eines SPF-Eintrages stellt keinen vollständigen Schutz dar. Dazu bedarf es noch weiterer Maßnahmen. Jedoch ist die Nutzung eines SPF-Eintrages seit Jahren Stand der Technik.
Moderne E-Mail-Systeme und Anti-Spam-/Anti-Mailware-Lösungen bewerten das Nichtvorhandensein eines SPF-Eintrages immerhin mit einer Erhöhung der Spam-Wahrscheinlichkeit. Dies kann u.U. dazu führen dass Nachrichten der Bezirksregierung Köln nicht im Posteingang, sondern im Junk-E-Ordner landen.
Es gibt auch Positives zu berichten.
Der Name eines E-Mail-Systems ist nicht das einzige Merkmal, auf das ein empfangendes System achtet. Im Normalfall wird ein Computername zu einer numerischen Conmputeradresse aufgelöst. Es gibt aber auch das genaue Gegenteil, die sog. Rückwärtsauflösung. Das empfangende System versucht hierbei die numerische Computeradresse zu einem Namen aufzulösen. Dies erfolgt mit Hilfe eines sog. PTR-Eintrages, der im DNS des Internet-Leitungsanbieters erfolgt. Ist diese Auflösung erfolgreich und der gefundende Name entspricht dem Computernamen der Verbindung, gilt die Identität des Systems als einfach bestätigt.
Der folgende Screenshot zeigt die Ergebnis für die IP-Adressen der beiden MX-Einträge.
Beide System verfügen über einen zum Computernamen passenden PTR-Eintrag.
Als Abschluss der aktiven Tests erfolgte eine Prüfung der E-Mail-Verbindung zu einem der beiden Systeme mit MX-Eintrag. HIer gibt es wenig Auffälliges zu berichten.
Die Nutzung von HTML-Tags (<br />) in einem Server-Banner ist unüblich und eher hinderlich. E-Mail-Server erwarten eine klare Kennung des Status und des Computernamens. In diesem Fall wird der Status 220 und der Name relay1v.it.nrw.de gleich zweimal in einer Textzeile zurückgegeben. Es wird sicherlich Systeme geben, die dies als nicht protkollkonformes Format bewerten.
Der folgende Screenshot zeigt das Ergebnis des SMTP-Tests.
Der E-Mail-Server unterstützt verschlüsselte Verbindungen und lässt, wie die Liste der unterstützten Befehle zeigt, weitere E-Mail-Befehle erst nach dem Aufbau einer verschlüsselten Verbindung zu. Ob die Unterstützung des ETRN Befehls zeitgemäß ist, kann man diskutieren. Es wird sicherlich technische Anforderungen auf Seiten der IT.NRW geben, die dies erfordern.
Es fehlen allerdings zwei wichtige Komponenten, um E-Mail-Nachrichten der Domäne bezreg-koeln.nrw.de sicherer zu machen. DMARC und DKIM.
Die zu Anfang besproche Prüfung der MX-Einträge hat gezeigt, dass kein DMARC-Eintrag vorhanden ist. Ein DMARC-Eintrag legt für eine Domäne, in diesem Fall wäre es für bezreg-koeln.nrw.de, fest, ob und wenn ja welche Informationen ein empfangender E-Mail-Server über E-Mails dieser Domäne sammeln soll. Hierdurch ist es möglich, Fehlerberichte zu erhalten und so festzustellen, welche unberechigten Systeme im Internet E-Mail-Nachrichten im Namen der Bezirksregierung Köln versenden. Solch ein Eintrag fehlt vollständig.
DMARC ist aber nur im Zusammenspiel mit SPF- und DKIM-Einträgen sinnvoll. Die Funktion und die Wichtigkeit eines SPF-Eintrages habe ich schon besprochen. Kommen wir zu DKIM.
Die Aufgabe von DKIM ist Sicherstellung einer vertrauensvollen E-Mail-Zustellung. Diese Sicherstellung bezieht sich auf den E-Mail-Umschlag. Das empfangende System erkennt, dass der E-Mail-Umschlag mit Hilfe einer DKIM-Signierung gesichert wurde. Hierzu hat das Absendersystem Umschlagsinformationen mit einem Schlüssel, der nur auf dem Absendersystem exisitert, signiert. Das Empfangssystem findet den öffentlichen Schlüssel wiederum als besonderen DNS-Eintrag. Mit diesem Schlüssel können nun die Signaturinformation aufgelöst und anschließend überprüft werden. Hierdurch wird die Integrität des Absendersystems für die Domäne sichergestellt.
DKIM selbst ist kein neuer Standard für die Sicherung von E-Mail-Nachrichten. Alle großen E-Mail-Anbieter prüfen eingehenden E-Mail-Nachrichten auf DKIM-Signaturen.
Dies ist kein Ersatz für eine mögliche und auch notwendige Verschlüsselung des E-Mail-Inhaltes. Der im Übrigen ebenfalls nicht stattfindet.
Kommen wir zum Abschluss noch zur Verbindungsverschlüsselung.
Der folgende Screenshot zeigt das Ergebnis der Verschlüsselungsfunktionen im Hinblick auf gängige Industriestandards.
Das Ergegbis ist in amerikanischer Notenstufe (A-F) dargestellt, wobei ein A einer Schulnote 1 entspricht. Mehr muss nicht gesagt werden.
Der Hauptgrund für die schlechte Note liegt darin, dass die E-Mail-Systeme alte und unsichere Verbindungsprotokolle und Verschlüsselungstechnologien unterstützen. Diese unsicheren Protokolle und Verschlüsselungen sollten im Jahr 2020 nicht mehr aktiv sein.
Die aktuelle Konfiguration der E-Mail-Umgebung der Bezirksregierung Köln und anderer Behörden, die diese IT-Plattform nutzen, kann durch Betrüger ausgenutzt werden. Einfachste Konfigurationen für sichere E-Mail-Kommunikation, die seit Jahren Stand der Technik sind, finden keine Anwendung. Hier wird, meiner Einschätzung nach, grobfahrlässig gehandelt. Betrügerische E-Mail-Nachrichten können ohne Probleme im Namen der Bezirksregierung Köln versendet werden.
In der Pflicht ist nicht nur die Bezirksregierung Köln, sondern vielmehr der Landesbetrieb IT.NRW, der als zentraler IT-Dienstleister für zahlreiche Behörden und Dienststellen auftritt. Hier muss etwas passieren, um Bürger für betrügerischen E-Mail-Nachrichten, nicht nur im Zusammenhang der NRW Soforthilfe, zu schützen. Alle Behörden und Dienststellen in NRW, die auf eine sichere E-Mail-Kommunikation mit Bürgern und Unternehmen vertrauen und hierzu die Dienstleistungen der IT.NRW in Anspruch nehmen, sollten die für sie gültigen Einstellungen dringend überprüfen lassen.
E-Mail-Nachrichten der NRW Soforthilfe 2020 werden als Klartext versendet, obwohl sie persönliche Informationen enthalten und somit einem besonderen Schutzbedürfnis unterliegen. Der Einsatz einer sog. Gateway-basierten E-Mail-Verschlüsselung kann hier schnell und einfach Abhilfe schaffen. Ebenso ist die Implementierung von SPF, DKIM und DMARC Pflicht.
Ich wünsche mir, dass IT.NRW die Absicherung der E-Mail-Kommunikation ernster nimmt und ihrer Verantwortung, auch als Vorbildfunktion, nachkommt. In der heutigen Zeit vertrauen Bürger auf die IT-Sicherheit, die propagiert wird. Im Rahmen der NRW-Soforthilfe hat dieses Vertrauen sehr gelitten.
Ohne eine Verbessung der E-Mail-Sicherheit, ist dem Betrug weiterhin Tür und Tor geöffnet.
Das Blog Cumulative Update für Februar 2019 (CU0219) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Skype for Business des Monats Februar 2019 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu