DSGVO, Freelancer, E-Mails und ein Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – I

Als Freelancer hat man seine liebe Not mit der deutschen Last-Minute-DSGVO-Panik. Das Problem ist nicht der Datenschutz an sich; da sind die allgemeinen Anstrengungen eher lobenswert. Das Problem sind vielmehr pauschale Verträge oder Vereinbarungen zur Auftragsverarbeitung, die viele Datenschutzbeauftragte (in ihrer Hilflosigkeit?) uns Freelancern aufdrängen möchten. Dabei spiegeln solche pauschalen Verträge nach meiner Auffassung gerade nicht den Geist der DSGVO wider:

Verkannt wird dabei, dass Datenschutz und Datensicherheit gemeinsame Festlegungen erfordert (s. etwa Art.32 DSGVO). Der Auftraggeber muss nämlich die technischen und organisatorischen Maßnahmen kennen und damit in gewisser Weise auch gutheißen, die Bestandteil eines Vertrages werden sollen. Viele Datenschützer übersehen auch, dass die zu erwartenden personenbezogenen Daten und deren Schutzniveau erstmal definiert werden müssen. Entsprechend inhaltsleer fällt denn auch die Antwort auf die Rückfrage aus, welche personenbezogenen Daten denn in der Zusammenarbeit auftauchen werden.

Man ist als Freelancer also gut beraten, die Schutzbedingungen selbst mit zu definieren - gerade im Geiste der DSGVO, Art. 32, Pkt.1. Das gilt dann u.a. auch für den Austausch von Mails zwischen Auftraggeber und Auftragnehmer.

E-Mail-Verkehr als DSGVO-Problemzone

Das Thema E-Mail ist im Kontext des Datenschutzes für Freelancer durchaus ein kritisches. E-Mails sind von Haus aus mit personenbezogenen Daten behaftet und können weitere schützenswerte Inhalte beinhalten. Hier muss man das zu erreichende Schutzniveau von beiden Seiten also sorgfältig definieren. Dabei muss man einen zwischengeschalteten Provider berücksichtigen - aber natürlich auch die hauseigene E-Mail-Installation. Letztere wird bei Linux-Lovern und -Profis durchaus komplex ausfallen, da der Linux-Anwender/Admin aus vielen vernünftigen Gründen heraus ggf. einen eigenen Mail-Server mit oder ohne Zusammenspiel mit einem Mail-Server bei einem Providern betreiben wird.

Ende-zu-Ende-Verschlüsselung?
Sinnvolle Schutzwege führen bei E-Mail aus meiner Sicht eigentlich immer über Ende-zu-Ende-Verschlüsselung. Kann man die DSGVO also als eine Gelegenheit begreifen, Verschlüsselungspflichten endlich auch für den Auftraggeber zu fixieren? Am besten auf der Basis von OpenPGP? Ich bezweifle aus Jahren eigener schlechter Erfahrung leider, dass alle eure Auftraggeber zu diesem Schritt der Vernunft bereit sein dürften.
Alternative? DE-Mail mit OpenPGP? Ehrlich gesagt: Ich weiß nicht, warum das technisch einfacher sein soll, als gleich selber die Schlüsselverwaltung zu übernehmen - und dabei ganz ohne Browser- oder Client-Plugins auszukommen. DE-Mail ist zudem kostenpflichtig - und man handelt sich ein paar unangenehme Verbindlichkeiten bzgl. der Nutzung ein.
Dennoch ist Mail-Verschlüsselung (ob mit oder ohne DE-Mail) der zu wählende Königsweg.

Nur Verschlüsselung des Übertragungsweges?
Leider fühlen sich viele AGer mit OpenPGP überfordert. Was dann? Nun, meistens haben die Auftraggeber selber E-Mail-Provider - und zumindest erfolgt der Zugang zu den E-Mail-Servern selbiger Provider verschlüsselt. Dito natürlich beim Freelancer. An dieser Stelle erscheint es geboten, als Freelancer einen Auftragsverarbeitungs-Vertrag mit dem Provider abzuschließen, den die meisten Hosting-Provider in Deutschland in pauschaler, aber ggf. hinreichender Weise anbieten.

Schutz unverschlüsselter Mails?
Leider ist man mit der Verschlüsselung des Übertragungsweges als Freelancer nicht aus dem Schneider.

Das erste Thema sind E-Mail-Clients (PCs, Notebooks, ..), die E-Mails in einer unverschlüsselten Umgebung puffern, öffnen oder gar mit Servern synchronisieren (unter Linux etwa über KDE's Akonadi oder z.B. über Evolutions und Thunderbirds eigene Tools). Auf den Clients bleibt dann halt viel auf deren meist unverschlüsselten Platten liegen.

Das zweite Thema, das vermutlich gerade Linux-Lover trifft, sind eigene E-Mail-Server im (Home-) Office-LAN. Jeder Freelancer oder auch der Admin eines KMU, der bei seiner Infrastruktur auf Linux setzt, wird aus einer Vielzahl von Gründen früher oder später einen eigenen Mail-Server aufgesetzt und den ggf. an einen Mail-Server bei einem Provider angeschlossen haben. Das gilt im Besonderen dann, wenn noch weitere Mitarbeiter oder Unterauftragnehmer im Spiel sind: Unter Upgrade-, Migrations- und Backup-Gesichtspunkten stellen eigene Mail-Server (trotz der Mühen beim Setup) für den Freelancer letztlich eine Arbeitserleichterung dar. Auf einem solchen Server lagert nun womöglich eine Masse an unverschlüsselten Mails auf unverschlüsselten Festplattenpartitionen. Steht etwa im eigenen (Home-)Office-LAN ein eigener Linux-Mail-Server, stellt sich die Frage wo und wie man die dort auflaufenden E-Mails bei Abwesenheiten/Urlaub von der Wohnung oder seines Office schützt.

Physikalischer Zugangsschutz? Nun, Freelancer werden kaum die Möglichkeit haben, ihre Wohnungen voll zu verriegeln, ohne sich Ärger mit Vermietern einzuhandeln. Wie sichert man sich dann gegen Diebstahl zu schützender Mails im Falle eines Einbruchs während eines Urlaubs ab? Tja - genau mit diesem Problem muss man sich nun ggf. wegen relativ strikter (pauschaler) Auftragsverarbeitungsvereinbarungen mal wieder auseinandersetzen. Das halte ich persönlich für durchaus sinnvoll ...

Gefordert ist natürlich erneut Verschlüsselung - diesmal aber von Platten oder Partitionen.

Verschlüsselung von Platten und Partitionen - auf Mail-Servern wie Mail-Clients?

Während Notebooks sowieso durchgehend kryptierte HHDs/SSDs erfordern, ist eine Vollverschlüsselung von Festplatten/ Partitionen bei Servern und umfänglichen Workstations ein viel komplexeres und problematischeres Thema, das auch mit Risiken verbunden ist. Ich nenne nur mal beschädigte Krypto-Header als eines der potentiellen Probleme.

Nehmen wir mal an, man traut sich zu, die Risiken, die mit Kryptographie verbunden sind, zu beherrschen. Wie kann dann für den Linux-Lover ein praktikables Modell für den Schutz unverschlüsselter Mails aussehen? Ich meine, dass drei strategische Elemente zum Ziel führen:

  1. Abseparation von bestimmten E-Mail-Accounts für Kunden
  2. Virtualisierung der E-Mail-Server - wie einer E-Mail-Client-Umgebung unter KVM/QEMU
  3. Verschlüsselung der (Raw-) Partitionen/Volumes, auf denen E-Mail-Server oder aber die Client-Umgebung operieren.

Auf mobilen Laptops/Notebooks ist eine Kryptierung der benutzten Partitionen sowieso Pflicht. Für SSDs ist dabei zu beachten, dass die Verschlüsselung schon im jungfräulichen Zustand erfolgen muss.

Nun wollen wir die Verschlüsselung aber auch auf Workstation-Clients und Server anwenden. Der E-Mail-Datenverkehr läuft dann meiner Ansicht etwa wie folgt aus:

Ein Router mit Perimeter-Firewall übernimmt die Kommunikation mit dem Internet. Er trennt ggf. ein Gastnetz [GNS} von einem Frontend-Segment [FNS]ab. Ein System mit einer Paket-Filter-Firewall und/oder WAF-Firewall trennt weitere nachgelagerte Segmente ab. Ein zweites System GWS2 realisiert einen E-Mail-Server in einer Art sekundärer DMZ. Dieser Server wird entweder direkt von normalen Clients in weiteren Zonen angesprochen (Lösung für "Arme") oder synchronisiert Mails ggf. mit einem weiteren Groupware-Server in internen Segmenten (Lösung für "Reiche").

Kennt man sich gut mit Paketfiltern im Kontext virtualisierter Netze gut aus, kann das angedeutete System "GWS1" ggf. entfallen. Auch der Groupware-Server ist für einen reinen Mail-Betrieb nicht erforderlich.

Die Verschlüsselung der Volumes, die von den unter KVM/QEMU virtualisierten Servern/Clients genutzt werden, kann dabei auf dem Host bereits auf der Ebene einer Linux-"Raw"-Partition oder eines "Raw"-LVM-Volumes genutzt werden. Ich halte in einem solchen Szenario allein aus Performance-Gründen Einiges davon, die Verschlüsselung dem Virtualisierungshost zu überlassen. Sollte jemand dagegen gute Einwände haben, bitte ich um Kontakt per E-Mail ....

Zusammenfassung und Ausblick auf den folgenden Artikel

Der regelmäßige Austausch von E-Mails, die personenbezogene und andere vertrauliche Daten beinhalten, erfordert mit Auftraggebern ggf. einen Vertrag, der die Art und Qualität personenbezogener Daten definiert, zu erreichende Schutzniveaus festlegt und technische wie organisatorische Maßnahme zu deren Umsetzung regelt.

Eine wichtige Maßnahme bei Freelancern, die keinen hinreichenden Zugangsschutz zu eigenen Systemen garantieren können, erscheint mir dabei die Lagerung der E-Mails auf verschlüsselten Partitionen und Volumes zu sein. Will man nicht gleich alles verschlüsseln können virtualisierte Systeme zum Zuge kommen.

In kommenden Artikel

DSGVO, Freelancer, E-Mails und Umzug KVM-virtualisierter Linux-E-Mail-Server auf verschlüsselte Platten/Partitionen – II

gehe ich zunächst noch einmal auf ein paar Aspekte der DSGVO ein und begründe etwas genauer, warum ein vertragliches Abkommen mit einem Auftraggeber sinnvoll ist. In einem dritten Artikel widme mich dann mal dem Umzug eines Linux-E-Mail-Servers - und dabei speziell dem Umzug einer bereits existierenden virtualisierten Lösung - auf neue, verschlüsselte Partitionen oder LVM-Volumes des Hosts. Entsprechende Arbeiten für Client-Systeme sind dann recht ähnlich.

Bundeshack: Outlook kann nicht das einzige Problem sein – I

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.