Mittwoch früh erhielt ich eine Nachricht von einer guten Bekannten; der Mailinhalt bezog sich auf den SZ-Artikel
http://www.sueddeutsche.de/ digital/ exklusiv-so-schleusten-die-hacker-daten-aus-dem-auswaertigen-amt-1.3894534
zum Hacker-Angriff auf das IVBB. Offenbar wird dieser Angriff jetzt als “Bundeshack” bezeichnet – und beschäftigt wohl einige Sicherheitsexperten in der Republik. Meine Bekannte schrieb mir, ich hätte mit meinen regelmäßig kritischen Anmerkungen zur Sicherheit heutiger IT-Infrastrukturen und im Besonderen zu MS-Produkten – wie Outlook – wohl mal wieder Recht gehabt. Das stimmt in diesem Fall aber nicht so ganz, denn tatsächlich sind mit der Sicherheit des IVBB Fachleute befasst, die die Gefahrenlage und auch die eingesetzten SW-Produkte in und auswendig kennen. Und leider verführt der SZ-Artikel dazu, das Versagen primär bei Outlook zu sehen. Das ist aber zu kurz gedacht; die im IVBB aufgetretenen Probleme müssen – wenn man mal glaubt, was die Presse kolportiert – aus meiner Sicht noch tieferliegende Ursachen haben. Was mich als IT-affinen Bürger dann eher beunruhigt …

Neutraler und sachlicher im Ton als der SZ-Beitrag ist der kommentierende Artikel bei Heise (s. https://www.heise.de/ security/ meldung/ Bundeshack-Daten-sollen-ueber-Outlook-ausgeleitet-worden-sein-3987759.html?xing_share=news). Dort wird zu Recht festgestellt, dass die Informationen der SZ mehr Fragen aufwerfen, als sie beantworten.

Ich fasse nachfolgend und in einem weiteren Artikel ein paar eigene Gedanken zum Thema “Bundeshack” zusammen. Ich hoffe, das hilft, eben jene Fragen besser zu erkennen, die sich nach dem SZ-Artikel aufdrängen. Meine Argumente sind dabei weitgehend unabhängig von der Frage “MS oder nicht” – und deshalb hoffentlich auch für Linux-Freunde interessant. Kommentare könnt ihr gerne per Mail an mich schicken.

Verschlüsselte Kommunikationsverbindungen ins Internet – und ihre zwei Seiten

Zunächst wollen wir die Grund-Information des SZ-Artikels – nämlich, dass die Hacker Mails (ggf. über Manipulationen von Outlook) zur Kommunikation mit einer Schad-Software und zum Transfer von geheimen Informationen nach außen genutzt haben – genauer einordnen. Als Voraussetzung ist dazu, für den einen oder anderen vielleicht überraschenderweise, ein Blick auf Datenverschlüsselung erforderlich.

Ich gehe mal davon aus, dass der Leser mit mir einig ist, dass ein essentielles Problem von Angriffen auf Behördennetze ein nachfolgender unkontrollierter Abfluss von Daten an Unbefugte ist. (Das ist natürlich nur ein Bedrohungsaspekt von Hacker-Angriffen; andere blende ich hier aber mal aus). Der illegale Zugriff auf Daten betrifft u.a. geheime Informationen der Exekutive sowie der Legislative, die z.Z. auch im Behördennetz hängt, aber ggf. auch Daten der Judikative. In keinem Fall kann man wollen, dass Hackern ein unbefugter Zugriff auf geheimzuhaltende Daten von Behörden (wie etwa dem Auswärtigen Amt) gelingt und diese nach außen transferiert werden. Wie erfolgt denn eigentlich ein unbemerkter Daten-Transfer von einem gehackten Gerät (PC, Notebook, Smartphone, …) und aus einem Firmen/Behörden-Netzwerk nach außen an irgendwelche Empfänger im Internet? Wieso ist das überhaupt möglich?

Antwort: U.a. wegen zu großen Freiräumen für elektronische Kommunikation am Arbeitsplatz und ausgerechnet auch noch durch ein wichtiges IT-Sicherheits-Element – nämlich Verschlüsselung. Wie das?

Als ich vor Jahren mal an einem Projekt in einer öffentlichen Institution arbeitete, hatte ich eine erbitterte “Diskussion” mit einer hoch positionierten – und politisch gut verdrahteten – Führungskraft zum Thema HTTPS. Es gab im Zuge der
Auseinandersetzung sogar eine schriftliche Beschwerde: Ich könne doch wohl nicht am Vormittag HTTPS-Verbindungen fordern und am Nachmittag HTTPS in einem anderen Kontext als problematisch darstellen. Tja, … kann ich doch … Es ging dabei nämlich um zwei ganz verschiedene Dinge: Am Vormittag wurde HTTPS als (halbwegs) sicheres Verbindungsprotokoll diskutiert, das es Kunden/Bürgern ermöglichen sollte, über das Internet auf einen künftig zu betreibenden Web-Service der Institution zuzugreifen. Am Nachmittag aber waren verschlüsselte Web-Verbindungen von den Arbeitsplatz-PCs der Behörden-Angestellten aus zu Web-Mail-Diensten privater Anbieter im Internet das Thema. Letzteres war erlaubt …

Mancher sicherheitsbewusster Leser wird schon jetzt den Kopf schütteln … Ich hatte damals (am Nachmittag) diese “Policy” als ideale Möglichkeit für korrupte, unzufriedene oder schlicht böswillige Mitarbeiter charakterisiert, unkontrollierbar und auch im Nachhinein nur äußerst schwer nachweisbar interne, geheimzuhaltende Daten nach außen abfließen zu lassen.

Meine Kritik stieß damals leider auf völliges Unverständnis. Man müsse seinen Mitarbeitern/innen doch wohl vertrauen können … Nun ja, ich sehe das von Haus aus anders. Zudem sind bei Sicherheitsthemen nicht nur die Mitarbeitermotivation sondern auch Gefahrenpotentiale zu berücksichtigen, die durch das unbedarfte Handeln von Mitarbeitern im Kontakt mit dem Internet ungewollt auftreten können (s.u.). Unabhängig davon: Der Versuch, einem Politiker den Unterschied

• zwischen den Gefahrenpotentialen ausgehender verschlüsselter Verbindungen vom Arbeitsplatz-PC eines Angestellten (oder dortiger Programme) ins Internet einerseits
• und den Gefahren bei der Behandlung von Daten eingehender verschlüsselter Verbindungen zu vom Betreiber kontrollierten Webservern in einer gesicherten Zone andererseits

zu vermitteln, erwies sich im Nachgang jedenfalls als unerwartet, ja geradezu verblüffend schwierig…

Den Lesern dieses Linux-Blogs ist dagegen natürlich klar, dass Verschlüsselung ab einem Endgerät (PC, Notebook, …) und aus einem Verwaltungsnetz heraus zu externen Servern ein echtes Problem darstellt. Grund: Niemand kann dann mehr kontrollieren, was über eine solche Verbindung an ggf. unbefugte Empfänger im Internet übertragen wird. Zumindest nicht ohne Zusatzmaßnahmen. Man erkennt bei etwas Nachdenken unschwer, dass Sicherheit durch Verschlüsselung immer eine Frage der Autorität über die verschlüsselten Daten ist und zum zweischneidigen Schwert werden kann:

Als Privatperson sollte ich unzweifelhaft der Herr meiner Daten sein – und z.B. auf einer Verschlüsselung in der Kommunikation mit Behörden bestehen. Als Behörde habe ich stellvertretend die Autorität über die mir vom Bürger anvertrauten Daten erlangt – und muss durch Sicherheitsmaßnahmen u.a. Folgendes garantieren:

• Behörden müssen kontrollieren können, dass zu schützende Daten nur Befugte erreichen und von Unbefugten nicht eingesehen werden können.
• Behörden müssen dafür sorgen, dass zu schützende Daten im Transfer zu Befugten verschlüsselt werden, wenn dabei öffentliche Netze passiert werden.

Hierbei gibt es aber Risiken (u.a. durch böswillige Mitarbeiter), denen durch Maßnahmen zu begegnen ist. Die Autorität über Datenflüsse nach außen und über evtl. zu schützende Inhalte kann ich aus Gründen der Risikoeindämmung in der IT nicht an einzelne Mitarbeiter oder Programme am Arbeitsplatz-PCs abtreten. Erforderlich ist vielmehr eine unabhängige, unbestechliche Kontrolle darüber, welche elektronischen Daten über welche Kanäle nach außen wandern. Das ist zumindest meine Erwartung an Behörden in demokratisch verfassten Staaten. Unkontrollierter Abfluss von geheim zu haltenden Daten von Arbeitsplatz-PCs
aus geht gar nicht. Und eine durchgehende Verschlüsselung durch Mitarbeiter vom Arbeitsplatz zu Empfängern im Internet erweist sich hier gerade als Problem, da die Verschlüsselung i.d.R. irreversibel ist und auch im Nachhinein keine Inhalts- und Berechtigungskontrolle zu dem Transfervorgang mehr möglich ist.

Das gilt u.a. für Mail-Verschlüsselung in Mail-Anwendungen am Arbeitsplatz genauso wie für HTTPS-Verbindungen zu irgendwelchen Web-Servern. Betroffen sind potentiell aber auch andere Netzwerk-Protokolle. Die nach außen übermittelten verschlüsselten Inhalte sind in allen Fällen auch im Nachhinein nur schwer zu – wenn überhaupt – zu ermitteln. Ggf. durch die Koinzidenz von Zeitstempeln bei Datei-Zugriffen und darauf anschließendem Mailversand. Zeitstempel liefern aber nur Indizien. Ein rechtskräftiger Beweis lässt sich daraus nur schwerlich ableiten, wenn man die Verschlüsselung nicht knacken kann. Gut verschlüsselter Inhalt an illegitime Empfänger ist halt immer noch gut verschlüsselt.

Wenn man dann noch die Aufnahme verschlüsselter Verbindungen zu vom Arbeitsplatz zu beliebigen Zieladressen im Internet zulässt, wird das Problem immens:

Nicht nur ein böswilliger Mitarbeiter kann über einen verschlüsselten Kanal von einem Endgerät aus geheime Daten nach außen schleusen. Über verschlüsselte Verbindungen kann man sich ggf. auch Malware unkontrolliert einhandeln, bevor ein lokaler Virenscanner die eliminieren kann. Und – noch schlimmer: Prinzipiell kann natürlich auch jede Malware (Schad-Software), die man sich irgendwie und irgendwann mal durch Unachtsamkeit eingefangen hat, einen verschlüsselten Verbindungskanal nach außen nutzen, um Informationen an externe Empfänger zu senden.

Vertrauen in Mitarbeiter ist eine Sache; unerkannte Malware, die mit der Nutzerkennung des Anwenders ausgehende Verbindungen zu Systemen im Internet aufnimmt, ein andere.

Nun wird der eine oder andere Leser sagen: Aber wir haben ja Firewalls!? Tja, schon – aber der transferierte Inhalt wurde ja schon im Browser am Arbeitsplatz mit einem zwischen Browser und Zielserver ausgehandelten Schlüssel verschlüsselt. Die Firewall kann die Legitimität der Verbindung damit in keinem Fall mehr am Inhalt festmachen. Höchstens und vielleicht noch am Adressaten. Aber auch ein legitimer Adressat kann illegitime Inhalte über verschlüsselte Verbindungen erhalten.

Nächste Frage: Warum sind verschlüsselte Verbindungen in der öffentlichen Verwaltung dann überhaupt sinnvoll und erlaubt? Hatte ich weiter oben nicht gerade selbst verlangt, dass Kommunikation über das Internet verschlüsselt werden muss? Liegt hier nicht ein Widerspruch vor?

Gute Frage! Betrachten wir zunächst mal eine Privatperson: Die braucht Verschlüsselung, um über das Internet sicher mit anderen Diensteanbietern (in der “Cloud”) kommunizieren zu können. Man denke dann z.B. an die Notwendigkeit der Verschlüsselung von Daten im Online-Banking, aber – und ebenso wichtig – an die Notwendigkeit, die Identität eines Webservers feststellen zu können, um nicht auf vorgegaukelte Webseiten hereinzufallen, die dem Original täuschend ähnlich sehen. Auf privaten PCs/Notebooks/Smartphones wird eine dortige “Personal Firewall” deshalb also kaum HTTPS-Verbindungen nach außen blocken. Im Gegenteil sind Privatpersonen eher dazu zu ermuntern, HTTPS wann und wo immer möglich zu nutzen.

Das gilt für Privatpersonen. Im Grunde aber doch auch für Behörden?

Wir dürfen bei der Beurteilung den oben diskutierten Punkt nicht übersehen: Die Tatsache, dass verschlüsselte Verbindungen von Nutzer-Geräten nach außen zu Web- und Dienste-Servern der “Cloud” in unserer internet-dominierten Welt so (überleben-) wichtig sind, dass sie zumindest auf normalen PCS, Smartphones, etc. nicht ohne weiteres geblockt werden können, ist aber eben auch ein erheblicher Schwachpunkt moderner web-orientierter IT und macht einmal eingefangene Schad-Software so erfolgreich und gefährlich:

Der Mensch wird einerseits als Schwachstelle für das Einschleusen von Malware genutzt; die Malware nutzt danach verschlüsselte Verbindungen vom Gerät des Anwenders zu Computern im Internet, welche direkt oder wiederum über Schad-Software durch den Angreifer kontrolliert werden. Was dabei alles vom eigenen PC, aus dem umgebenden Firmen- oder Behördennetz nach außen übertragen wird, können wir dann leider nicht mehr kontrollieren.

Darin besteht die problematische, “dunkle” Seite von Verschlüsselung in bestimmten Arbeitsumgebungen. Kann man diese negative Seite und andererseits die positive Seite von Verschlüsselung bei Behörden überhaupt in Einklang bringen?

Verschlüsselung und Closed Source

Mal (nicht) ganz nebenbei: Unter dem Gesichtspunkt “unkontrollierter Datenabfluss” stellt “Closed Source-Software”, die regelmäßig verschlüsselte Verbindungen zu Herstellern und deren Servern aufnimmt, von Haus aus ein großes Problem dar. Auch da haben wir überhaupt keine Chance zu prüfen, was da von unseren Systemen nach außen abfließt. Für mich ist das ein entscheidender Grund dafür, warum der Einsatz von Closed Source Software und Betriebssystemen im öffentlichen Verwaltungsbereich grundsätzlich ein Fehlgriff ist.

Die Umkehrung der Bedrohungsverhältnisse

Nicht nur ein böswilliger Mitarbeiter, sondern auch jede Art von Schad-Software wird typischerweise versuchen, vom “beherbergenden” System aus verschlüsselte Kommunikationskanäle von innen nach außen (!) zu Systemen im Internet aufzubauen, die unter Kontrolle des Angreifers liegen. Der nachfolgende Kommunikationsfluss erfolgt in beide Richtungen; er kann dabei sowohl Kommandos zur Steuerung der Schad-SW (und nach einer Rechteeskalation ggf. des gesamten umgebenden Systems) beinhalten oder aber den Transfer von Informationen zum Angreifer in ganz unterschiedlicher Form.

Früher betrachtete man die Absicherung von Netzen als Aufgabe, zu deren Lösung man einen “Schutzwall” um das eigene Netz aufbaut, der von außen kommende Angriffs- und Eindring-Versuche blockt. Das war schon immer ein unzureichendes Bild. Der Angriff auf IT-Strukturen erfolgt nicht nur von außen nach innen; mit “Social Engineering” und dem Ausnutzen mentaler Schwachpunkte von Menschen gelingt die Platzierung von Malware im Zeitalter von “Bring your own device” auch in Firmen immer irgendwann. Der wirkliche Angriff läuft danach aber sozusagen eher ungeblockt von innen nach außen. Modetrends wie “Bring your own Device (BYOD)” und das Nutzen von Cloud-Diensten lassen zudem die Grenzen zwischen Firmen- und Behörden-Netzen und dem Internet immer weiter verschwimmen. Wenn System-Administratoren meinen, sie müssten in der heutigen Zeit vor allem den Datenverkehr von außen nach innen kontrollieren, irren sie gewaltig. Die Überwachung des Verbindungsaufbaus von innen nach außen und die Überwachung zugehöriger Datenströme ist in bestimmten Netzen noch wichtiger. Übrigens: UDP-basierte Multimedia-Anwendungen, die mit Internet-Diensten kommunizieren, stellen dabei ein besonderes Problem-Umfeld dar und haben in sicheren IT-Umgebungen meiner Meinung nach nichts verloren. Das betrifft im besonderen Skype und dessen Ableger für Firmen.

Leider ignorieren das viele Firmen … Auch manche Behörden erheben eine Policy zur Erlaubnis verschlüsselter Verbindungen vom Arbeitsplatz-PC ins Internet geradezu zum mitarbeiterfreundlichen Prinzip .. und verlieren dabei jegliche Kontrolle über den Datenabfluss.

Verschlüsselte Verbindungen – ein Dilemma?

Unsere bisherige Diskussion hat bislang ein Dilemma beschrieben:
In einem Behördennetz mit Geheimhaltungsbedarfen sind verschlüsselte Verbindungen/Mails zwischen User-Endgeräten und Servern im Internet ein großes Problem. Andererseits erscheint Verschlüsselung im Datenaustausch über das
Internet geradezu als Pflicht … (Tatsächlich werden ausgehende verschlüsselte Verbindungen ins Internet in vielen Netzen – u.a. denen von Behörden – erforderlich und werden von sog. Perimeter-Firewalls oft auch zugelassen.)

Das Dilemma gipfelt in der Frage: Sollte man Verwaltungsangestellten die Aufnahme verschlüsselter Verbindungen von Netzen, in denen geheimzuhaltenden Informationen gelagert sind, nach außen überhaupt erlauben? Eigentlich kann die Antwort nach dem bisher Ausgeführten nur “Nein” lauten.

Was ist also tun? Der entscheidende Punkt besteht darin, die Irreversibilität von Verschlüsselung ab dem Arbeitsplatz zu vermeiden.

Im Fall hoher Sicherheitsbedürfnisse wird man daher im Regelfall Verschlüsselung nicht direkt von den Endgeräten der Anwender aus zulassen. Das Ziel typischer Lösungsansätzen ist es vielmehr, die Kommunikation über aktive Server des eigenen Netzes zu leiten, bevor ein irreversibler Verschlüsselungsprozess einsetzt. Zentrale Sicherheits-Appliances auf Servern, die im eigenen Netz platziert sind und die die Kommunikation nach außen herstellen, müssen dabei die Kontrolle über die über die ausgehende Verbindung sowie die ausgetauschten Daten und Inhalte behalten.

Entsprechende Lösungsansätze bestehen im Fall von E-Mail darin, Mailverschlüsselung erst ab einem und über einen zentralen Mailserver zuzulassen und automatisiert sowie in Abhängigkeit von den Empfängeradressen durchzuführen. Die Verbindung zwischen Enduser-PC und Mailserver verbleibt dabei unverschlüsselt – oder wird mit eigenen Schlüsseln geregelt, die an den zentralen Servern eine Entschlüsselung der Inhalte erlauben. Die eigenen Server behalten dabei die Kontrolle über die transferierten Inhalte in beide Richtungen. Nicht besonders datenschutzfreundlich bzgl. der Mitarbeiter? Die Frage ist eher, ob private verschlüsselte Mails in Verwaltungsnetzen, in denen hohe Sicherheitsbedarfe gegeben sind, überhaupt etwas zu suchen haben.

Im Fall von HTTP / HTTPS bestehen Lösungswege darin, ausgehende HTTPS-Verbindungen und andere verschlüsselte Verbindungen von User-Geräten entweder zu verbieten oder aber zwischengeschaltete Web-Proxy-Server einzusetzen, die die Verschlüsselung/Entschlüsselung sozusagen als legitimierte “Man-in-the-Middle”-Instanz übernehmen. Proxys müssen dabei die Zertifikate der Zielserver prüfen, den Inhalt der ausgetauschten Datenströme analysieren, protokollieren, etc.. Der User kann dabei evtl. sogar in Richtung Proxy verschlüsseln, aber eben mit Schlüsseln, die mit dem Proxy ausgehandelt werden und nicht mit Schlüsseln für Zielserver im Internet. Der Proxy kann daher Inhalte des Datenstrom entschlüsseln und behält so die Kontrolle über die ausgetauschten Inhalte. Letztere verschlüsselt er dann automatisch neu im Rahmen einer separat aufzubauenden Verbindung mit dem Zielserver im Internet. (Ein verschmerzbarer Nachteil ist, dass der Anwender selbst die Gültigkeit von Zertifikaten der Empfangsstelle nicht direkt kontrollieren kann.)

IVBB und verschlüsselte Verbindungen

Gem. SZ und Heise-Artikel sind verschlüsselte Verbindungen von Anwendern aus dem IVBB nach außen verboten. Gut so! Genau richtig! Das entspricht meinen Erläuterungen von oben. Worin besteht dann das beim Bundeshack laut SZ aufgetretene Problem?

Mail als Kommunikationskanal zu Schad-SW ?

Nun kennen professionelle Angreifer/Hacker/Geheimdienste vermutlich die Verschlüsselungspolitik im IVBB genau. Sie werden sich also intensiv Gedanken darüber gemacht haben, wie sie “Kommunikationskanäle” von einer einmal auf einem angegriffenen IVBB-Gerät implantierten Schad-SW nach außen aufbauen können. Das “unauffällige” und “elegante” Vorgehen, wie die SZ einen Sicherheitsfachmann zitiert, besteht nun wohl darin, ein Mail-Programm als Kommunikationskanal zu nutzen.

Das ist allerdings viel naheliegender als die Presse das
darstellt. E-Mail-Kommunikation wird in Organisationsnetzen womöglich noch weniger unterbunden und von den Zieladressen her eingegrenzt als HTTPS- und HTTP-Verbindungen. Behörden müssen ja auch mit anderen Institutionen des öffentlichen Lebens und ggf. sogar Bürgern kommunizieren. Das ist Teil ihrer Aufgabe.

Ein- und ausgehende dienstliche Mails von und zu Mitarbeitern in Behörden werden aber (hoffentlich) auf die dabei transferierten Inhalte geprüft – u.a. durch Virenscanner – und in besonders sicherheitslastigen Umgebungen (hoffentlich) auch durch intelligentes Scannen der textuellen Inhalte: Eingehende Texte u.a. wegen Spam, ausgehende Texte in Kombination mit der Empfängeradresse u.a. wegen illegitimer Inhalte. Voraussetzung ist wiederum, dass eine evtl. Verschlüsselung der Mails erst ab einem eigenen Ausgangsserver (SMTP-Server) erfolgt.

Was aber, wenn ein Angreifer in den Inhalten einlaufender Mails (durch einfache Sprach- oder Buch-Codes) gar keine Malware oder Spam-Inhalte, sondern gestückelt und über den Text verteilt Kommandos an eine SW unterbringt? Und umgekehrt eine Schad-Software oder ein böswilliger Mitarbeiter ausgehende Geheiminformationen illegalerweise in scheinbar harmlosen Texten oder Bildern einer Mail verbirgt – und die geheimzuhaltenden Informationen nur stückweise über mehrere Mails an unbefugte Empfänger überträgt? So, dass das mengenmäßig nicht auffällt? Dann haben Virenscanner ein Problem. Und wird dann zusätzlich nicht auf “seltsame” Empfangs- und Zieladressen reagiert, so gibt es ein absehbares Sicherheitsloch.

Es braucht dann theoretisch nur noch zwei Zutaten für ein Sicherheits-Desaster:

1. Die bereits vorhandene, implantierte Schad-SW muss eingehende Mails und/oder deren Anhänge auslesen können.
2. Die Schad-SW muss eigene Mails kodieren und über zentrale Server zu Zieladressen, die der Angreifer kontrolliert, verschicken können – ohne dass das auffällt.

Wie konnte der Datenabfluss über Mails nach außen eigentlich gelingen?

Der SZ-Artikel hebt vor allem auf die Methodik ab, dass von den Angreifern E-Mails zur Steuerung einer ansonsten autonom lebenden Schad-SW, die in diesem Fall offnbar keine aktiven Verbindungen nach außen aufnahm, genutzt wurde. Ja, das ist in der Tat bemerkenswert – und sollte zu einer anderen Einstellung gegenüber dem Aufbau von Arbeitsplätzen in sicherheitsrelevanten Bereichen führen. Darauf komme ich im zweiten Artikel zurück.

Aber viel naheliegender und kritisch zu betrachten ist doch folgender Punkt:
Der Schaden ist vor allem dadurch entstanden, dass Informationen nach außen geschleust werden konnten. Wir hatten aber festgestellt, dass man in sicherheitsrelevanten Netzen die Kontrolle über alle auslaufende Datenströme und deren Inhalte behalten muss. Deswegen wurde ja im IVBB gerade – zumindest gemäß der SZ – der Aufbau verschlüsselter Verbindungen nach außen unterbunden. Nun würde man annehmen, dass das dann auch für den E-Mail-Kanal gilt. Sprich:

1. Alle Mails gehen ausschließlich über einen eigenen zentralen Mail-Versand-Server (SMTP-Server). Der direkte Versand von Mails mittels eines Mail-Clients vom Arbeitsplatz aus über andere (externe) SMTP-Server wird durch Firewalls strikt unterbunden.
2. Der eigene Versandserver kann die Identität des Senders nicht nur anhand der IP-Adressen des Arbeitsplatz-PCs sondern auch über elektronische Signaturen an den Mailinhalten feststellen. Die intern verwendeten Signaturschlüssel sind natürlich durch Passwörter geschützt …
3. Der eigene Mailserver kann den Mailinhalt und den Inhalt von Anhängen analysieren, bevor vor dem Versand nach außen eine ggf. erforderliche Verschlüsselung in Richtung Adressat erfolgt. Bereits am Arbeitsplatz-PC verschlüsselte Inhalte werden vor dem Versand erkannt und nicht akzeptiert.
4. Alle Klartext-Inhalte ausgehender Mails (und deren Anhänge) werden zumindest auf Schlüsselbegriffe und versteckte Botschaften hin analysiert. Die Möglichkeit von kodierten Botschaften in Multimediadateien (Steganographie) wird in Betracht gezogen und geprüft (statistische Analyse oder Vergleiche mit Originalen aus definierten offiziellen Datei-Depots. Unbekannte Multimediadateien werden eliminiert.)
5. Der zentrale Versandserver prüft die Mail-Adresse des Adressaten auf Auffälligkeiten – und stoppt die Mail gegebenenfalls. In diesem Zusammenhang sind von Mitarbeitern ggf. explizite Deklarationen und Freigaben von Ziel-Adressaten in zentralen Listen/Datenbanken einzufordern.

Nun drängt sich – unabhängig von Problemen mit Outlook – der Verdacht auf, dass an einem dieser Punkte etwas schief gegangen sein muss. Oder, dass meine – hoffentlich einsichtige Haupt-Annahme – nicht stimmt und zentrale Mail-Versand-Server und dortige Prüfungen durch die Schad-Software umgangen werden konnten. Was beides peinlich wäre, da alle genannten Punkte grundsätzlicher Natur sind. Entsprechende Schwachpunkte hätten dann ja auch bereits Menschen – z.B. korrupte Angestellte – ausnutzen können. Zu allen oben genannten Punkten fallen einem natürlich noch weitere Unterpunkte und Fragen ein.

Zum ersten Punkt ist zu sagen, dass eine Perimeter-Firewall einen Mailversand über IVBB-externe SMTP-Server natürlich unterbinden muss. Davon ist hoffentlich auszugehen?

Bei Punkt 2 kommt die Frage ins Spiel, wie die Schad-SW überhaupt die ausgehenden Mails konstruiert hat – mit oder ohne Nutzung bzw. steuernde Manipulation von Outlook? Wenn letzteres: Wieso war/ist das überhaupt möglich und zugelassen? Und wieso wird überhaupt ein so anfälliger und durch Dritt-Software unter Windows manipulierbarer Mailclient wie Outlook in einem Netz mit hohen Sicherheitsbedarfen eingesetzt?

Falls die Schad-Software ihre Mails aber autonom verfasst hat: Wieso und wie konnte sie interne Signatur-Schlüssel erfassen? Oder werden im IVBB gar keine internen Signaturen zur Authentizitätsfeststellung der Verfasser vor dem Versand verwendet?

Punkt 4 ist fundamental, aber in der Praxis ggf. problematisch. Aber daran hängt doch irgendwie alles! Das Thema muss sich doch jemand bereits gründlich durchdacht haben – zumindest beim BSI. Ein gestückelter Datenabfluss über versteckte Nachrichten in Texten und Multimedia-Dateien ist doch ein Grund-Risiko, das sich zur Behandlung durch technische Maßnahmen geradezu aufdrängt. Erst recht, wenn man schon richtigerweise ein Verbot verschlüsselter Verbindungen nach außen gegenüber Mitarbeitern durchsetzt, um ausgetauschte Inhalte kontrollieren zu können.

Punkt 5 ist ebenfalls fundamental. Mailversand zu x-beliebigen ungeprüften Empfangsadressen in der Welt erscheint irgendwie als ein “No Go”. Dass es in diesem Kontext nicht reicht zu prüfen, ob es zu einer Mailadresse auch schon mal einen Eingang gab, liegt auf der Hand. Die Gültigkeit einer Adressaten-Adresse muss sich an viel mehr Kriterien festmachen.

An dieser Stelle schließt sich eine weitere interessante Unterfrage an: War die Zieladresse vielleicht gar eine bekannte? Wenn ja, dann würde das bedeuten, dass auch die dortigen Systeme unter Kontrolle von Angreifern liegen und der Hack insgesamt viel größere Ausmaße hat als bislang gedacht.

Zusammenfassend müssen sich die Betreiber des IVBB folgende Fragen gefallen lassen :

• Wie konnten Mails mit kritischen Inhalten überhaupt an den Angreifer versandt werden? Welche Lücken wurden da ausgenutzt? Sind diese Lücken ggf. von allgemeinem öffentlichen Interesse, weil sie mit Schwachpunkten der SW Outlook und/oder bestimmter Mailserver zu tun haben?
• Wieso und wie haben andere befreundete Geheimdienste das mitbekommen? Waren die in der Lage die Mails abzufangen und die Kritikalität der Inhalte zu erkennen? Wieso? Und
  wieso die IVBB-Betreiber nicht?
• Im Kontext von E-Geovernment in Deutschland tauchen regelmäßig die Themen “verschlüsselnde OSCI-Infrastruktur” (s. Wikipeadia zu Online-Services-Computer-Interface), “Virtuelle Poststelle des Bundes”, “Governikus-Server” (https://www.governikus.de/ anwendung-des-it-planungsrates/faqs-zur-anwendung-governikus/ und Governikus-Portfolioueberblick-Juni2017-Einzelseiten.pdf) u.a. in der Funktion als sichere Mail-Gateways ins Internet auf. Wie passen die offenbar vorhandenen Lücken und Defizite eigentlich damit zusammen?

Bzgl. des letzten Punkts ist auch interessant, dass 2017 Sicherheitslücken im OSCI-Transport-Protokoll festgestellt wurden.

Es sollte nun hinreichend klar geworden sein, dass es beim Bundeshack nicht allein um Schwächen von Outlook geht.

Nachtrag 23.03.2018:
Zwei Nachrichten passen gut zum Kern der obigen Ausführungen:
http://www.sueddeutsche.de/ digital/ attacke-auf-auswaertiges-amt-die-geschichte-eines-cyber-angriffs-1.3917502
Tja, irgendwie peinlich, dass ein ausländischer Nachrichtendienst verdächtige Mails aus dem eigenen Netz entdeckt. Dass einer eigenen Überwachung gesetzliche Hindernisse im Wege stehen könnten, dürfte wohl bei Scans nach selbst versandten Mails, eigenen IP-Adressen und zugehörigen Mustern kein Argument sein.

Bzgl. des Bezugs zu proprietärer Software ist folgender Artikel interessant:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Ich finde es beunruhigend, wenn man Desktop-Systeme von Spezialkräften aus Sicherheitsgründen so hinbiegen lassen muss, dass sie für die Verwaltung geeignete sind und eine Überwachung von Datenströmen zwischen Clients und Servern (s.o.) überhaupt erlauben.

Im nächsten Beitrag befasse ich mich ein wenig mit der Frage, ob ein Standard-Arbeitsplatz, bei dem Mail, Dateibearbeitung, Internet-Browsing durch Programme einer Desktop-Umgebung abgewickelt werden, überhaupt noch zeitgemäß und höchsten Sicherheitsanforderungen in Behörden angemessen ist.