BSI-Richtlinie Sicherer E-Mail-Transport: Was ist davon zu halten?
Mit einer Richtlinie „Sicherer E-Mail-Transport“ will das Bundesamt für Sicherheit in der Informationstechnik (BSI) die Provider dazu bringen, endlich flächendeckend die vorhandenen und nutzbaren Sicherheitsstandards einzusetzen. Doch nicht nur das: Anbieter, die die Anforderungen erfüllen, sollen eine entsprechende Zertifizierung erhalten können. - Heinlein Support hat als Mitglied der BSI-Arbeitsgruppe die neue Richtlinie mit erarbeitet. Rund 9 Monate wurde an der Richtlinie „TR-03108“ gearbeitet und mit Fachleuten und Provider-Vertretern in den Räumen des Bonner Innenministeriums abgestimmt und verbessert. Am Ende steht eine Richtlinie, die sich sehen lassen kann:
- https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html
Kein Rocket Science -- aber auch kein fauler Kompromiss
Die Richtlinie fordert nichts, was verschiedene Provider wie mailbox.org nicht bereits vollständig erfüllen können. Sie enthält nichts revolutionär Neues, aber eben auch keinen faulen Kompromiss in der Sache. Die Messlatte liegt angemessen hoch: Technisch genau auf dem Stand der Zeit. Fakt ist dennoch, dass einige Anbieter die Anforderungen der Richtlinie noch nicht erfüllen und sich entsprechend strecken müssen -- und dies ist durchaus gewollt. TR-03108 fordert unter anderem:
- Den Einsatz vertrauenswürdiger Zertifikate entsprechend Richtlinie TR-03145
- Das Vorliegen einer ISO27001-Zertifizierung oder eines IT-Sicherheitskonzeptes nach TKG, sowie die Erfüllung der gesetzlichen Datenschutzvorgaben entsprechend BDSG/GDPR
- Den Einsatz von DNSSEC
- Die Sicherung des SSL-Zertifikats durch DANE (TLSA-Records im DNSSEC)
- Eine aktive Informationspolitik über IT-Sicherheit gegenüber den Usern, u.a. soll offengelegt werden, welche E-Mails mit SSL versendet werden/wurden.
DNSSEC verpflichtend -- das erfüllen noch nicht viele
In der Arbeitsgruppe wurden die verschiedenen Anforderungen durchaus kontrovers diskutiert. So wurde lange Zeit DNSSEC als nur wünschenswert, nicht aber verpflichtend gehandelt. Wohl auch darum, weil verschiedene einflussreiche Provider selbst noch nicht ausreichend in der Umsetzung von DNSSEC vorangekommen waren und die Richtlinie nicht hätten erfüllen könne. So starteten web.de und GMX erst vor wenigen Tagen DNSSEC und DANE – und sind der Version 1.0 der Richtlinie damit nur knapp zuvorgekommen. Zufall? Erst in der letzten finalen Arbeitsgruppe am 12. April 2016 in Bonn konnte sich die Auffassung durchsetzen, dass DNSSEC von Anfang an als verpflichtend gelten muss. Eine Position, die wir von Heinlein Support maßgeblich vorangetrieben und vertreten haben und die dann zum Glück auch Zustimmung der anderen Vertreter erhalten hat und so beschlossen werden konnte.
Aufwändige, teure Zertifizierung könnte kleine Provider abhalten
Unklarheiten gibt es noch bei der Frage, auf welche Art und Weise Anbieter an die (aus Marketingsicht vielleicht erstrebenswerte) Zertifizierung gelangen können. Die entsprechenden Richtlinien liegen noch nicht ganz in der finalen Fassung vor. Die vorliegende Kritik der Arbeitsgruppe hängt konkret an dem Punkt, dass für die Zertifizierung ein aufwändiger, viele Manntage langer (und damit teurer) manueller Prüfprozess eines Gutachters vor Ort stattfinden soll, obwohl verschiedene Experten der Meinung sind, 95% der für die Zertifizierung notwendigen Tests sollten sich vollautomatisiert prüfen lassen. Ob ein Provider DNSSEC anbietet und seine Mailrelays dies ausreichend unterstützen ist eine mathematisch-beweisbare Frage, die schon heute verschiedene Testwebseiten automatisiert beantworten können, dazu braucht es keinen teuer bezahlten Zertifizierungs-Abnehmer vor Ort, der das Rad neu erfindet. Auch das Vorliegen einer ISO-Zertifizierung lässt sich relativ trivial mit JA und NEIN beantworten - lediglich „weiche“ Faktoren, beispielsweise ob das IT-Sicherheitskonzept die gesetzlichen Anforderungen ausreichend erfüllt, sind von einem Experten inhaltlich zu bewerten. Die Befürchtung bleibt, dass die hohen Zertifizierungskosten und der hohe eigene Personal-/Zeitaufwand des Providers verschiedene klein- und mittelständige Anbieter vom Erreichen der offiziellen Zertifizierung abhalten, während Großprovider angesichts des zu erwartenden Marketingeffekts die Kosten gerne und problemlos tragen. Wenn dem BSI an einer flächendeckenden Verbreitung neuer Sicherheitsstandards bei der E-Mail-Kommunikation gelegen ist, muss die Richtlinie nicht nur am technischen Wert, sondern auch daran gemessen werden, dass eine entsprechende Zertifizierung unkompliziert für alle Provider erreichbar bleibt.
mailbox.org erfüllt die TR-3108 von Anfang an
Unser Provider mailbox.org erfüllt schon lange sämtliche Anforderungen der Richtlinie – auch der Punkt, dass der Absender vor Versand auf das TLS-Sicherheitsniveau der E-Mail hingewiesen wird [Anforderung "ADDREQ_3"], wird von mailbox.org bereits umgesetzt. -Das entsprechende Feature haben wir als erster Provider im Mai 2015 eingeführt. Trotzdem werden wir prüfen müssen, ob der Aufwand und die derzeit von uns erwarteten hohen Kosten, den Nutzen einer solchen Zertifizierung rechtfertigen und wir diesen Weg gehen - oder aus wirtschaftlichen Gründen darauf verzichten.
Heinlein Support hilft Providern bei der Umsetzung
Unser Team betreut seit Jahren kleine und auch sehr große E-Mail-Cluster anderer Unternehmen und auch Provider. Heinlein Support hilft anderen Providern gern bei der Umsetzung der neuen BSI-Richtlinie. Sprechen Sie uns an.
Weitere Beiträge zum Thema
Was ändert sich mit der neuen Datenschutz-Grundverordnung?
Die Pflicht zur revisionssicheren E-Mailarchivierung
Kommentare
5 Antworten zu BSI-Richtlinie Sicherer E-Mail-Transport: Was ist davon zu halten?
Das ist ja im Prinzip alles eine schöne Sache, es scheitert meiner Meinung aber auch daran, dass keiner der großen Provider Nameserver mit DNSSEC-Unterstützung der breiten Öffentlichkeit anbietet. Wer nicht selbst die DNS-Server betreiben will, weil er sich auf die Infrastruktur und die Erfahrung von namhaften Providern verlassen will (ich denke da mal an diverse Flooding-Angriffe), der wird im Regen stehen gelassen. Und auf die Angebote von diversen kleinen und unbekannten Hostern einzugehen, steigert auch nicht gerade das Gefühl nach erhöher Sicherheit/Stabilität.
Ich würde mir wünschen, dass hier die Großen mal einen Schritt vorangehen. Aber leider verdienen gerade diese meist auch am Verkauf von SSL-Zertifikaten, worin natürlich ein gewisser Widerspruch steckt.
Peer, wie sieht es denn mit Euch aus? Bietet Ihr dies mittlerweile auch offiziell mit eigenem Kundeninterface an, sodass man hier auf Euch setzen kann und seine DNS-Zonen + Keys eigenständig verwalten kann? Das wäre doch mal was.
Gruß
Carsten
Mal abgesehen davon, dass ich von DNSSEC nicht viel halte (siehe z.B. [1]): Für DNSSEC gibt es immer noch viel zu wenig clientseitige Unterstützungen. Kein Browser, E-Mail-Programm und ähnliches zeigt an ob ein Server jetzt DNSSEC unterstützt, ob es valid ist oder besteht gar darauf. Für den Firefox gibt es zwar ein Plugin, doch wirklich benutzt scheint es nicht zu werden [2].
Statt dem Prinzip von DNSSEC (was mMn nicht wirklich tut was es soll) sollte man lieber Blockchain-basierte Prinzipe a la Blockstack weiter vorantreiben, die im Gegensatz zu DNSSEC das wirkliche Potential haben diese Probleme zu lösen :)
Schade das DNSSEC Pflicht für die Richtlinie ist, aber ich habe sie ja (noch :)) nicht zu erfüllen.
[1] http://sockpuppet.org/blog/2015/01/15/against-dnssec/
[2] https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/statist…
Kleine Berichtigung: das Treffen in Bonn war am 12. April 2016, nicht am 12. März 2016.
Viele Grüße
Michael
Das Thema DNSSEC sollte man nicht nur aus der Sicht der E-Mail Clients sehen. Die Mailserver wie Postfix unterstützen DNSSEC und DANE und die Server-2-Server Kommunikation kann damit sehr wohl sinnvoll verbessert werden, wenn die Provider gezwungen werden, ihre Domains mit DNSSEC und DANE zu sichern.
Wer für seinen Desktop Client über DNSSEC diskutiert will, der müsste auch DNScrypt in die Diskussion aufnehmen. Ohne DNScrypt ist die "letzte Meile" zwischen dem validierenden DNS-Server und Nutzer ungesichert und kann manipuliert werden, die Anfragen können auf einen anderen Server umgeleitet werden, die DNSSEC Signaturen können entfernt werden usw. (so wie es im Rahmen des "Internet Zugangserschwernis Gesetzes", ZugErschwG, 2009 vorgesehen war). DNSSEC für Clients ist also eigentlich aus kryptografischer Sicht eine ziemlich sinnlose Diskussion.
Das Thema DNSSEC sollte man nicht nur aus der Sicht der E-Mail Clients sehen. Die Mailserver wie Postfix unterstützen DNSSEC und DANE und die Server-2-Server Kommunikation kann damit sehr wohl sinnvoll verbessert werden, wenn die Provider gezwungen werden, ihre Domains mit DNSSEC und DANE zu sichern.
Wer für seinen Desktop Client über DNSSEC diskutiert will, der müsste auch wissen, dass die "letzte Meile" zwischen dem validierenden DNS-Server und Nutzer ungesichert und manipuliert werden kann , die Anfragen können auf einen anderen Server umgeleitet werden, die DNSSEC Signaturen können entfernt werden usw. (so wie es im Rahmen des "Internet Zugangserschwernis Gesetzes", ZugErschwG, 2009 vorgesehen war).
DNSSEC für Clients ist ohne DNScrypt o.ä. zur Sicherung der "letzten Meile" eine ziemlich sinnlose Diskussion. Es gibt ganz wenige Ausnahmen.