Kategorie: Themen

Ransomware

Ryuk-Zuck, Conti-nentaldrift: Die Wandlung der Ransomware

Kurzzeitig hatten Beobachtende und (potenziell) Betroffene zuletzt aufatmen können: Ransomware-Gangs wie die berüchtigte REvil-Gruppe waren durch konzertierte Aktionen von Strafverfolgungsbehörden unter Druck geraten. In der Folge hatten die Cyberkriminellen bestimmte Aktivitäten eingestellt; die sogenannte „victim shaming“-Site von REvil, auf der die gehackten Organisationen samt einem Teil ihrer gestohlenen Daten präsentiert wurden, um den Druck zur Zahlung des Lösegelds zu erhöhen, ging offline.

Nun scheint in den letzten Wochen eine Verlagerung der Aktivitäten und Anpassung der „Geschäftsmodelle“ stattgefunden zu haben. Die Kampagne „Conti“ etwa ist laut Informationen auf ihrer eigenen Website dazu übergegangen, neben den bisherigen Standbeinen „Lösegeld für Entschlüsselung“ und „Lösegeld oder wir leaken die Daten“, zusätzlich Zugriff in die Netze der gehackten Organisationen zum Kauf anzubieten.

Noch wird spekuliert, was der wirkliche Grund für diesen „Pivot“ ist. Einerseits würde dieser Schritt FIN12 – der Gruppe hinter Conti und Ryuk – eine zusätzliche Einnahmequelle ermöglichen. Zum anderen scheint das verlässliche und systematische Leaken von Daten, ohne das die Erpressung nicht wirken kann, die Gruppen vor erhebliche Herausforderungen zu stellen – technisch sowie hinsichtlich der Strafverfolgung. Denn Tor-/Onion-Sites im „Darknet“ haben eine geringe Bandbreite, während öffentliche Downloadseiten im Internet schneller gesperrt werden können. Es bleibt also zu beobachten, in welche Richtung sich die Marktbereinigung und Reorganisation weiterentwickelt und ob die Schläge von FBI und Co. am Ende eine positive Auswirkung hatten.

https://krebsonsecurity.com/2021/10/conti-ransom-gang-starts-selling-access-to-victims/

Ransomware

Gemein(de)heit: Kommunen im Visier

Banken, Versicherungen und ähnliche im Wesentlichen bitschubsende Branchen sind Bedrohungen aus der Cyber-Ecke schon länger gewohnt und haben daher ihre Abwehr bereits seit den 90er-Jahren schrittweise hochgefahren, bisweilen auch zusätzlich motiviert durch gewisse regulatorische Schachzüge. Die cyberphysischen Sektoren wie Energie, Produktion und Wasser sind irgendwann in der Folge von Stuxnet Ende der 2010er-Jahre nach und nach erweckt worden. Und Krankenhäuser etwa hat es nach 2015 zunehmend erwischt, sodass auch sie aufrüsten mussten und weiterhin müssen.

Kommunen wurden auch bisher schon vereinzelt Opfer organisierter Cyberkriminalität. Ebenso gab es den einen oder anderen spektakulären Fall, wie den des Admins, der bis ins Gefängnis hinein das Generalpasswort als Geisel hielt. Die Mehrheit der Fälle waren jedoch Zufallstreffer: Kollateralschäden der Angry-Bear-Strategie der Ransomware-Gangs. Wütende Bären, die es gezielt auf Gemeinden abgesehen hatten, anstatt hungrig wahllos auf Beutezug zu gehen, waren bisher anderen Zielen zugetan.

Nun scheint es einen Dammbruch zu geben: Kommunen werden aktuell am laufenden Band digital „aufgemacht“ und ausgenommen.

Das hat zumindest zwei Gründe: Erstens sind die Taschen der öffentlichen Hand bekanntlich tief. Zwar sind die Kommunen selbst meist klamm, aber wirklich Pleite gehen lassen wie bei einer in den Sand gesetzten Wirtschaftsunternehmung werden wir sie im föderalen System letztlich ja doch nicht. Und Verschuldung geht am Ende im Notfall doch immer unbegrenzt, wenn der Schuldner Staat heißt.

Zum anderen – auch das hat (auch) mit der begrenzten finanziellen Ausstattung zu tun – sind die Kommunen IT-mäßig noch einmal deutlich schlechter aufgestellt als Verwaltungen auf Landes- oder gar Bundesebene. Solange es hier angeblich auch weniger zu holen gab, konnte man das vielleicht sogar als angemessen – Fachleute sagen lieber „risikoorientiert abgewägt“ – durchgehen lassen. Seit die Gangs jedoch verstanden haben, dass hier lohnenswerte UND leichte Ziele zu Hunderten auf die Ernte warten, hat die Hölle angefangen loszubrechen.

Was wir aktuell sehen, dürfte nur der Anfang eines mehrjährigen Prozesses sein, aus dem die kommunale Verwaltung mit vielen Schrammen, aber am weit entfernten „Ende“ nur gestärkt hervorgehen kann. Alles andere können wir uns gar nicht leisten.

Es wird in der nächsten Zeit darauf ankommen, wie lang und schmerzhaft zu werden wir dem Prozess erlauben.

https://www.waz.de/region/rhein-und-ruhr/nach-witten-it-experten-erwarten-weitere-hacker-attacken-id233620623.html

Penetrationstest

HiSolutions Schwachstellenreport 2021

Hier gibt es unser Whitepaper Schwachstellenreport 2021 zum Download.

Immer wieder taucht die Frage auf, wie die Ergebnisse von Penetrationstests im Vergleich mit „typischen“ Ergebnissen einzustufen sind und ob die identifizierten Probleme bei anderen Unternehmen in ähnlicher Form und Schwere bestehen.

Wir haben diese Fragen zum Anlass genommen, die von uns in den letzten Jahren durchgeführten Tests auszuwerten und die jeweils identifizierten Schwachstellen nach Schweregrad und Kategorien zu analysieren. Diese Aggregation erlaubt uns, sowohl die Vertraulichkeit der Projektergebnisse gegenüber unseren Kunden zu wahren als auch Aussagen über typische Testergebnisse und Problembereiche abzuleiten, die entweder besonders häufig auftauchen oder besonders schwerwiegende Lücken darstellen. Durch die Fortschreibung der Auswertung über die Jahre hinweg werden dabei auch interessante Trends und wichtige Entwicklungen in der Sicherheitslage deutlich.

Vorgehen

Dieser Report beruht auf einer Auswertung der Ergebnisse aus insgesamt 89 Penetrations- und Schwachstellentests, die im Jahr 2020 durchgeführt wurden. Zusätzlich wurden die Befunde mit den Ergebnissen der Schwachstellenreports aus den Jahren 2013 bis 2019 verglichen.

Die durchgeführten Tests betreffen verschiedene Zielumgebungen von Netzwerkinfrastrukturen über Web-Anwendungen bis hin zu einzelnen Systemen und Verfahren, weswegen sie nicht direkt miteinander vergleichbar sind. Durch die Kategorienbildung bei den Schwachstellen lassen sich dennoch interessante Beobachtungen ableiten.

Für die Kategorien wurde sich zunächst an den „OWASP Top 10“ orientiert. Diese Veröffentlichung des OWASP-Projektes aus dem Jahr 2017[1] umfasst eine Systematik der schwerwiegendsten Schwachstellen für Web-Anwendungen, die dort auf der Grundlage einer Berechnung der Schweregrade auf der Basis von Häufigkeiten und Auswirkungen erstellt wurde. Die Kategorien lassen sich dabei zum Teil auch auf andere Testziele gut übertragen, decken jedoch nicht alle Befunde vollständig ab, sodass einige selbst erstellte Kategorien ergänzt wurden. Diese umspannen den gesamten Zyklus der Softwareentwicklung und des Betriebs von Architektur und Design über Implementierung bis hin zur Systempflege. Dadurch lassen sich auch entsprechende Sicherheitslücken jenseits von Web-Anwendungen feingranular einordnen.

Die Aggregation der Daten bringt einige praktische Schwierigkeiten mit sich: Aufgrund der Verschiedenartigkeit der durchgeführten Tests ließen sich keine relevanten Aussagen zur Häufigkeit von Schwachstellen in einem bestimmten System oder einer Anwendung ermitteln. Auch werden in den Projektberichten gleichartige Schwachstellen auf verschiedenen System häufig zu einem Befund zusammengefasst, sodass eine Zählung der Befunde hier ebenfalls nur begrenzte Aussagekraft hat. Aufgrund dessen wird als Maß die relative Häufigkeit von Projekten, in welchen ein Befund der entsprechenden Kategorie auftaucht, verwendet. Dadurch wird deutlich, welche Schwachstellen besonders häufig in Projekten auftreten und welche eher selten oder nur in besonderen Zielumgebungen vorkommen.

Für die Bewertung der Relevanz einer Schwachstelle wird in den Prüfberichten ein standardisiertes Schema verwendet, welches aus der Bewertung der Komplexität des Angriffs und des zu erwartenden Schadens zu einer Einordnung in die folgenden Kategorien führt:

     CRITICAL (C)            Systeme akut gefährdet, umgehendes Handeln erforderlich

     HIGH (H)                   hohe praktische Relevanz – sollte priorisiert behoben werden

     MEDIUM (M)             relevantes Schadenspotenzial in Verbindung mit anderen Problemen

     LOW (L)                    für sich genommen keine unmittelbare Gefahr

Rein informative Befunde (z. B. festgestellte funktionale Fehler ohne Sicherheitsbezug) wurden in der Auswertung nicht berücksichtigt.

Ergebnisse

Im Folgenden werden die Erkenntnisse aus der Auswertung der Penetrationstests des letzten Jahres vorgestellt. Es werden die durch die Tests gefundenen Sicherheitslücken im Vergleich der Ergebnisse der letzten Jahre begutachtet. Hierfür werden die Kategorie und der Schweregrad der Schwachstellen betrachtet. Die Auswertung von Nachtest-Ergebnissen erlaubt auch in diesem Jahr wieder eine Untersuchung über die Effizienz der im Anschluss an Penetrationstests durchgeführten Maßnahmen.

Bei der Auswertung der Projekte des Jahres 2020 müssen die Besonderheit des Jahres in Bezug auf die globale Covid-19-Pandemie im Blick behalten werden. So ist es dieses Jahr besonders wichtig, die Entwicklung der Ergebnisse der Penetrations- und Schwachstellentests im Zusammenhang mit den Einschränkungen zur Pandemiebekämpfung und den Auswirkungen auf die verschiedenen Projektarten zu begutachten und zu bewerten.

Die erste Abbildung zeigt die Entwicklung des Schweregrades von Sicherheitslücken von 2013 bis 2020. In diesem Fall werden alle Funde eines Penetrationstests betrachtet. Jedem Test wird die höchste Kritikalität seiner Funde zugeordnet, da eine einzige Schwachstelle des entsprechenden Schweregrades genügen kann, die Sicherheit des gesamten Systems zu beeinträchtigen.

Von 2013 bis 2015 gab es einen klaren Anstieg der kritischen, hohen und mittleren Befunde. Die Anzahl dieser sank in den nächsten Jahren bis 2018 zwar deutlich, um 2019 erneut stark zu steigen. Wie bereits im Bericht des letzten Jahres vermutet, liegt der starke Anstieg der als hoch eingestuften Funde in 2019 vermutlich im Rahmen der kurzzeitigen Schwankungen, welche zwar nicht direkt einen Negativtrend darstellt, aber dennoch beobachtet werden sollte.

Die Entwicklung der Kritikalitätsverteilung im Jahr 2020 zeigt im Vergleich zu 2019 einen Anstieg der Schwachstellen mit mittleren und niedrigen Auswirkungen und damit einhergehend eine Abnahme der kritischen und hohen Schwachstellen. Der Grund für diesen starken Unterschied liegt allerdings nicht in einem wesentlich verbesserten Sicherheitsniveau der Untersuchungsgegenstände, sondern lässt sich vielmehr durch die Auswirkungen der Covid-19-Pandemie erklären: Durch die Maßnahmen gegen die Pandemie (z. B. Lockdowns, Reisebeschränkungen und Home-Office-Regelungen) konnten im Jahr 2020 deutlich weniger interne Penetrationstests durchgeführt werden. Im Gegensatz zu externen Prüfungen über das Internet werden bei Penetrationstests in internen Netzwerken fast ausnahmslos eine wesentlich höhere Anzahl an Befunden und Schwachstellen mit hohen und kritischen Auswirkungen aufgedeckt.

Dies liegt unter anderem daran, dass extern erreichbare Systeme täglich im Fokus verschiedenster Angreifer stehen und kritische Schwachstellen kurzfristig ausgenutzt werden. Je nach den Folgen der Ausnutzung und gegebenenfalls vorhandener öffentlicher Berichterstattung zu den Schwachstellen führt dies dazu, dass Schwachstellen in externen Systemen schneller erkannt und behandelt werden. Dies gilt umso mehr, als dass heutzutage ein Großteil der Unternehmen weiterhin einen Netzwerkschutz nach dem Perimeter-System betreiben. Die Absicherung nach außen steht dabei im Fokus der Sicherheitsmaßnahmen, wobei die Behandlung von Sicherheitsrisiken in internen Systemen nachrangig behandelt wird oder durch Ressourcenmangel nicht oder nur stark verzögert erfolgen kann.

Abbildung 1: Entwicklung der Kritikalität von 2013 bis 2020

Um die Sicherheit von bestehenden Systemen zu verbessern und Sicherheitsaspekte im Entwurf neuer Systeme zu berücksichtigen, ist es wichtig zu verstehen, welche Art von Sicherheitslücken besonders häufig auftritt und welche Auswirkungen dies haben kann.

In Abbildung 2 wird daher zunächst die Entwicklung des Auftretens bestimmter Fehlerklassen in den letzten Jahren gezeigt. Dargestellt wird der Anteil der Penetrationstests, welche mindestens einen Befund der Kategorie erzeugt haben.

Im abgelaufenen Jahr ist besonders zu bemerken, dass eine Preisgabe von schützenswerten Daten, welche im letzten Jahr stark gesunken war, erneut enorm angestiegen und nun wieder in 8 von 10 Fällen zu finden ist. Zugleich ist aber die Anzahl der fehlerhaften Konfigurationen mit Auswirkung auf die Sicherheit eines Systems nach einem dramatischen Anstieg im letzten Jahr wieder gesunken, wobei eine solche noch immer in 80 % der Penetrationstests aufzufinden ist. Auch Funde im Bereich der Injektion und fehlerhafter Authentifizierung oder Sitzungsverwaltung sind im Vergleich zum vorherigen Jahr wieder häufiger geworden, wobei in diesen Fällen der Anstieg um ca. 5 % im Bereich normaler Schwankungen liegt.

Abbildung 2: Relative Häufigkeit der Kategorien[2] von 2016 bis 2020

Positiv zu vermerken scheint, dass der Anteil der Funde im Bereich von Implementierungsfehlern, mangelnder Systempflege und fehlerhafter Authentifizierung oder Sitzungsverwaltung im Vergleich zu 2019 wieder stark sank. Wie schon bei der Kritikalitätsentwicklung sind jedoch auch diese Entwicklungen mit großer Wahrscheinlichkeit den Auswirkungen der Covid-19- Pandemie zuzurechnen, da Fehler in diesen Bereichen zum Großteil bei internen Penetrationstests bemerkt werden.

Abbildung 3 zeigt die Schwere der Befunde im vergangenen Jahr aufgeschlüsselt nach Kategorie und im Vergleich zu den Befunden des vorangegangenen Jahres. Angegeben wird dabei der Anteil der unterschiedlichen Kritikalitätswerte an den Gesamtbefunden der jeweiligen Kategorie.

Abbildung 3: Entwicklung der Kritikalität[3] der Befunde nach Kategorie im Vergleich zum Vorjahr
 

Betrachtet man die Entwicklung der Häufigkeit der Kategorien zusammen mit der Kritikalität nach Kategorien, ergeben sich einige bemerkenswerte Veränderungen. So ist zwar die Häufigkeit der Funde im Bereich „Injektion“ nur leicht angewachsen, jedoch ist die Kritikalität der Funde in diesem Bereich, besonders von kritischen und hohen Funden, deutlich stärker gestiegen.

Im Gegenteil hierzu ist jedoch die Häufigkeit im Bereich „Fehlerhafter Authentifizierung oder Sitzungsverwaltung“ ähnlich zur Kategorie „Injektion“ gewachsen. Hier hat sich die Verteilung der Kritikalität allerdings in Richtung niedrig (low) verschoben.

Auch die Anzahl von Funden im Bereich des „Preisgebens von sensiblen Daten“ ist stark gestiegen – und ähnlich wie beim vorherigen Punkt ist auch hier die Verteilung der Kritikalität der Funde sogar noch eindeutiger in Richtung niedrig gewandert.

Während die Häufigkeit von Funden im Bereich des unzureichenden Loggings & Monitorings gesunken ist, ist hier die Kritikalität besonders stark angestiegen. Im Jahr 2020 wurden allerdings in diesem Bereich nur neun Funde entdeckt, im Gegensatz zum Vorjahr, wo es 22 Funde gab, weshalb die allgemeingültige Aussagekraft der Veränderung kritisch zu hinterfragen ist. Nichtsdestotrotz sollte dieser Bereich umso genauer im Blick behalten werden, da ein gutes Logging und Monitoring nicht nur bei der Fehlersuche, sondern auch bei der rechtzeitigen Erkennung und Behandlung von Angriffen essenziell ist.

Als letzter bemerkenswerter Punkt ist hervorzuheben, dass 40 % der Funde im Bereich von mangelnden Organisations- und Betriebsprozessen eine hohe Kritikalität vorzeigen und sogar bis zu 80 % als mittlere Kritikalität eingestuft werden.

Auswertung nach Testtyp

HiSolutions bietet eine Vielzahl unterschiedlicher Sicherheitsüberprüfungen an. Vergleichsweise häufig und insbesondere periodisch wiederkehrend werden externe Penetrationstests und Web-Penetrationstests ausgeführt, bei denen das Testteam die gleichen Möglichkeiten wie externe Angreifer besitzt. Zusätzlich wird auch eine Vielzahl an internen Penetrationstests durchgeführt, welche die Untersuchung der Auswirkungen eines erfolgreichen Angriffes in der Praxis ermöglichen. Bei diesen stehen dem Testteam wesentlich mehr Möglichkeiten zur Verfügung, da sie sich im internen Netz des Auftraggebers befinden. Auch diverse Pentests und gezielte Prüfungen von Hardware-Systemen, Anwendungen und ICS-Umgebungen sowie Überprüfungen von Quellcode, System- und Netzwerk-Architekturen und der Konfiguration von IT-Systemen wurden im Jahr 2020 von HiSolutions durchgeführt.

Abbildung 4 zeigt die Kritikalität abhängig vom Typ des durchgeführten Tests und im Vergleich die Ergebnisse des Vorjahres. In einem Penetrationstest können mehrere Überprüfungen unterschiedlicher Art vorkommen. Für die Auswertung werden die einzelnen Testbestandteile aller Penetrationstests betrachtet. Die in Abbildung 4 dargestellte Kritikalitätsverteilung ergibt sich, wie in vorherigen Auswertungen, aus der Zuordnung jedes Testbestandteils zu seiner maximalen ermittelten Kritikalität. Für eine bessere Vergleichbarkeit werden relative Häufigkeiten dargestellt.

Um im Vergleich einen Mindestwert an Aussagekraft zu erzielen, werden nur Testtypen berücksichtigt, für welche im Jahr 2020 mindestens 10 Projekte durchgeführt wurden.

Die Auswertung nach Testtyp zeigt, dass die generelle Verteilung der in den Projekten beobachteten Kritikalitäten größtenteils konstant geblieben ist.

Nach wie vor gilt nachweisbar: Je mehr Zugang das Testteam hat, desto kritischer sind die aufgedeckten Sicherheitslücken. Zwar wurden im Fall der internen Penetrationstests nur noch in ungefähr 35 % der Prüfungen Befunde identifiziert, die als kritisch eingestuft wurden, der Anteil der sonstigen internen Pentests, die dann mindestens einen als „hoch“ eingestuften Befund enthalten, ist von ca. 40 % auf ca. 60 % der Gesamtzahl angestiegen.

Da durch die Corona-Pandemie deutlich mehr Überprüfungen von über das Internet erreichbaren Testgegenständen stattgefunden haben, ist die Entwicklung hier besonders interessant. Sowohl bei externen als auch bei Web-Penetrationstests sind besonders die Funde von kritischen und hohen Schwachstellen zurückgegangen. Das könnte darauf hinweisen, dass die Absicherung nach außen sich bei einigen Systemen im Vergleich zum Vorjahr verbessert hat. Ob dies dadurch begründet werden kann, dass durch die Pandemie deutlich mehr Personal im Home-Office arbeitete und somit die Schnittstellen nach außen stärker abgesichert werden mussten, muss durch andere Untersuchungen beleuchtet werden.

Abbildung 4: Entwicklung der maximalen Kritikalität nach Testtyp im Vergleich zum Vorjahr

Auswertung der Nachtests

Anbieter von Penetrationstests empfehlen in der Regel eine Verifikation der im Anschluss umgesetzten Maßnahmen als wirkungsvolles Mittel zur Verbesserung der Sicherheitseigenschaften von IT-Systemen. Die tatsächliche Wirksamkeit der umgesetzten Maßnahmen wird im Folgenden an Beispielen aus der Praxis überprüft. Zu diesem Zweck werden Befunde betrachtet, bei denen ein Nachtest durch HiSolutions stattgefunden hat, also eine Überprüfung der nach dem Penetrationstest implementierten Maßnahmen.

Abbildung 5 zeigt die Anzahl der Befunde und deren Kritikalität nach Kategorien. Der obere Balken bezieht sich dabei auf die Befunde im initialen Penetrationstest, der untere auf die Befunde im Nachtest.[4]

Im Allgemeinen kann erneut hervorgehoben werden, dass besonders kritische und hohe Schwachstellen bis auf wenige Ausnahmen erfolgreich behoben wurden. Allerdings waren in den Bereichen sicherheitskritische Fehlkonfiguration und Nutzen von Komponenten mit bekannten Schwachstellen selbst im Nachtest noch immer Schwachstellen der Kritikalität „hoch“ zu finden.

Abbildung 5: Kritikalität im Vergleich vom Penetrationstest zum Nachtest 2020

Der Grund für die Unterschiede bei diesen beiden Kategorien war dabei häufig, dass es sich um schwerwiegende systematische Schwachstellen handelt, deren Behebung längere Zeit in Anspruch nimmt oder größere Umstrukturierungen notwendig macht. Bei Schwachstellen etwa, die auf veraltete Systeme und Komponenten zurückzuführen sind, ist ein funktionierendes Patch- und Life-Cycle-Management essenziell, um die Probleme dauerhaft zu beheben. Sind diese Management-Prozesse nicht ausreichend etabliert, werden Systeme im Nachgang an einen Penetrationstest oft einmalig aktualisiert, sind aber bis zum Zeitpunkt des Nachtests erneut veraltet. Vor dem Hintergrund, dass Ransomware-Trojaner und -Angreifer immer wieder Schwachstellen in veralteten Systemen ausnutzen, empfiehlt HiSolutions auch in internen Netzwerken dringend die Umsetzung eines zeitnahen Patch- und Life-Cycle-Managements.

Fazit

Auch dieses Jahr zeigten die identifizierten Befunde, wie wichtig und notwendig Penetrationstests und praktische technische Sicherheitsüberprüfungen sind.

Schwachstellen in internen Netzwerken stellen nach wie vor den Großteil der Schwachstellen mit hohem oder kritischen Risiko für Unternehmen dar. Unter der Annahme, dass es Angreifern gelingt, die externen Sicherheitsmaßnahmen zu umgehen und in ein internes Netzwerk vorzudringen, spiegelt dieses in der Praxis ein beträchtliches Risiko wider. Auch die Erfahrungen von HiSolutions im Bereich Incident Response und Forensik und andere unabhängige Untersuchungen zeigen klar, dass Angreifer in internen Netzwerken gezielt Schwachstellen ausnutzen, um darüber ihre Berechtigungen zu erweitern und Schadsoftware auf weiteren Systemen zu verbreiten. Diverse in internen Penetrationstests identifizierte Angriffspfade ließen sich direkt oder in abgewandelter Form auch in realen Angriffen beobachten. Nur durch einen systematischen Umgang mit dem Thema IT-Sicherheit, welcher teilweise größere Umbau- und Um-Organisationsmaßnahmen und eine langfristige sicherheitsorientierte Ausrichtung in dem Bereich nach sich zieht, kann dieses komplexe Thema zukünftig verbessert werden.

Die sonstigen Entwicklungen der Zahlen aus diesem Jahr stehen stark unter dem Eindruck der durch die Covid-19-Pandemie veränderten Projektzusammensetzung. Üblicherweise in Web-Anwendungen und externen Systemen vorzufindende Schwachstellen wie die „Preisgabe schützenswerter Daten“ sind durch die gestiegene Anzahl an Projekten in diesem Bereich ebenfalls merklich angestiegen. Die Anzahl an kritischen und hoch eingestuften Schwachstellen ist, bedingt durch die geringere Anzahl an internen Penetrationstests bei Kunden vor Ort, insgesamt gesunken. Ein Blick in die Einzelprojekte zeigt jedoch kein signifikant gestiegenes Sicherheitsniveau in den einzelnen Bereichen.

Aus den Ergebnissen lässt sich auch ablesen, dass im Bereich des Loggings und Monitorings weiterhin größere Probleme existieren. Ein zielgerichtetes Logging und Monitoring wurde nur in wenigen Kundenumgebungen beobachtet. Teilweise war zwar eine umfangreiche Protokollierung eingerichtet, die Daten wurden aber nicht geeignet ausgewertet und konnten daher nicht effizient und präventiv genutzt werden. Da besonders dieser Bereich, wenn richtig durchgeführt, eine enorme Hilfe bei der Überprüfung von Systemen und insbesondere auch der frühzeitigen Erkennung von Sicherheitsvorfällen sein kann, empfehlen wir eine stärkere Fokussierung aus das Thema in der Zukunft.

Auch für das vergangene Jahr zeigen die Ergebnisse deutlich, dass anhand von Penetrationstests viele Sicherheitsprobleme in IT-Infrastrukturen erkannt werden können, die ohne externe Kontrolle (bis zu einem Angriff) verdeckt geblieben wären. Einmal identifiziert, führten die betroffenen Unternehmen in den meisten Fällen ausreichende Maßnahmen bis zum Nachtest durch, sodass die Probleme dauerhaft behoben wurden. Bei der Interpretation dieser Ergebnisse muss allerdings beachtet werden, dass die Durchführung eines Nachtests für sich bereits ein gesteigertes Sicherheitsbewusstsein oder etabliertere IT-Sicherheits-Strukturen bei Unternehmen aufzeigt. So werden Nachtests in der Regel nicht geplant und beauftragt, wenn keine Änderungen an den Systemen vorgenommen wurden. Auch wenn die Ergebnisse der Nachtests grundlegende Verbesserungen an den Systemen darlegen, zeigen sie auch deutlich, dass nicht immer alle angemahnten Schwachstellen tatsächlich effektiv behoben wurden. Die Durchführung von Nachtests ist damit weiterhin als effektives Mittel zur Bestätigung von getroffenen Maßnahmen sowie zur Identifikation möglicher Restrisiken anzusehen.

Übrigens: Unser Angebot im Bereich Pentest/Penetrationstest finden sie hier.

[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[2] Die Kategorien „XML External Entities (OWASP A4)“ und „Insecure Deserialization (OWASP A8)“ sind aufgrund der geringen absoluten Zahlen aktuell nicht aufgeführt.

[3] Ohne Befunde, aus welchen sich keine direkten sicherheitsrelevanten Auswirkungen ergaben.

[4] Da lediglich Befunde betrachtet werden, für welche ein Nachtest stattgefunden hat, können nur etwa 20 % der Befunde verwendet werden. Es kann daher zu Abweichungen zu Abbildung 3 kommen, da für diese mehr Datenpunkte zur Verfügung stehen. Die Kategorie „Insufficient Logging & Monitoring (OWASP A10)“ wird mangels Daten nicht berücksichtigt.

Cloud

Keine Gaudi: Fast Super-Cloud-GAU bei Microsoft

Bei Microsoft ist eingetreten, wovor sich viele Cloud-Anbieter insgeheim fürchteten: Getroffen hat es Azure mit seiner Cosmos DB, einer beliebten NoSQL-Datenbank. Das Datenbankmanagement wird dabei ganz im Sinn von PaaS weitgehend von Microsoft übernommen.

Nun haben Sicherheitsforscher eine Schwachstelle in der Funktion Jupyter-Notebook entdeckt. Dieses Feature war erst im Februar diesen Jahres durch Microsoft aktiviert worden. Der Vorgang zeigt, wie wichtig es ist, die Konfiguration in allen genutzten Cloud-Diensten beständig im Blick zu behalten und gerade neue Features sicherheitstechnisch kritisch zu bewerten.

Die Entdecker WIZ Research haben zur Schwachstelle folgendes Video erstellt:

Eine Webseite mit Informationen zur Schwachstelle ist hier zu finden: https://chaosdb.wiz.io/

Laut Microsoft kam es glücklicherweise nicht zu einem aktiven Ausnutzen dieser Schwachstelle, siehe folgende Stellungnahme:

Update on the vulnerability in the Azure Cosmos DB Jupyter Notebook Feature

Positiv hervorzuheben ist, dass nur zwei Tage nach Meldung der Sicherheitslücke das betroffene Jupyter-Notebook-Feature durch Microsoft deaktiviert wurde, sowie der offene Umgang mit der Schwachstelle.

Fix Once, Secure Everywhere

Dies zeigt einen weiteren Vorteil der Cloud: Wenn eine Schwachstelle im Zuständigkeitsbereich des Cloud-Anbieters liegt, muss diese in der Regel nur durch den Cloud-Anbieter gefixt werden. Auf der anderen Seite ist dies auch ein Unterscheidungsmerkmal in Bezug auf Anbieterqualität: Nur ein Cloud-Anbieter, der schnell reagiert, bietet den Kundendaten entsprechenden Schutz.

CV? Neee…

Leider gibt es – anders als für Schwachstellen in Anwendungen und Betriebssystemen – keine dedizierte Datenbank für Schwachstellen in Cloud-Diensten. Denn CVE-Nummer werden nur vergeben, wenn die die Software durch den Kunden kontrollier- bzw. installierbar ist (https://cloudsecurityalliance.org/blog/2018/08/13/cve-cloud-services-part-1/).

Blockchain

­Der 0 Millionen Dollar Raub: Mr. White Hat gibt’s zurück

Kryptowährungen an sich sind riskante Investitionsobjekte – nicht nur aufgrund der Volatilität und der häufigen Scam-Versuche, sondern auch wegen spektakulärer Security Incidents, die hier nicht selten gleichbedeutend sind mit dem Verlust von vielen Millionen Euro bzw. Dollar.

Umso wilder geht es bei „#Defi“ zu: „Decentralized Finance“ ist die nächste Entwicklungsstufe der „Kryptos“ und verbindet mehrere Blockchains zu größeren Netzwerken.

Hier konnte ein unbekannter Angreifer – später durch das bestohlene Poly-Netzwerk „Mr. White Hat“ getauft – umgerechnet 610 Millionen US-Dollar auf eigene Adressen in verschiedenen Kryptowährungen abzweigen. Dabei nutzte er einige spannende Designfehler von Poly aus. Insbesondere wurden Hashes nicht exakt genug geprüft.

Nach anfänglichem Betteln um Rückgabe der Beute schwenkte Poly bald um und bot dem Angreifer den Job als Sicherheitsberater an. Zwar scheint das Jobangebot im engeren Sinn nicht angenommen worden zu sein, aber das Geld wurde doch Stück für Stück zurückgebracht, ohne die Identität von Mr. White Hat zu enthüllen.

Sollte es wirklich seine bzw. ihre Absicht gewesen sein, auf Sicherheitslücken in #Defi bzw. Poly hinzuweisen – es wäre spektakulär gelungen.

https://threatpost.com/poly-network-recoups-610m-stolen-from-defi-platform/168906/

Kritis

6 Jahre Branchenspezifische Sicherheitsstandards (B3S) – Eine Bestandsaufnahme im Vergleich

Von Konrad Degen.

Branchenspezifische Sicherheitsstandards (B3S) haben sich in zahlreichen KRITIS-Sektoren in Deutschland etabliert. Nach der durch das IT-Sicherheitsgesetz 1.0 ausgelösten Entstehungswelle entwickeln sich aufgrund der zweijährigen Gültigkeit die Standards weiter. Eine Vergleichsanalyse zeigt, dass sieben Schritte für die Erstellung eines B3S notwendig sind. 

Mit Inkrafttreten des IT-Sicherheitsgesetzes 1.0 im Juli 2015 hat der Gesetzgeber sich zum Ziel gesetzt, die IT-Sicherheit in Deutschland zu stärken. Betreiber von kritischen Infrastrukturen wurden aufgrund ihrer Bedeutung für die Gesellschaft verpflichtet, ein Mindestmaß an IT-Sicherheit zu gewährleisten, da ein Ausfall oder eine Störung der öffentlichen Daseinsvorsorge negative Auswirkungen für Staat, Wirtschaft und Gesellschaft zur Folge haben. KRITIS-Betreibern wurde die Möglichkeit eingeräumt, branchenspezifische Sicherheitsstandards (B3S) zu entwickeln.  Die in der Regel durch Verbände entwickelten B3S werden nach Eignungsfeststellung durch das BSI für die Dauer von zwei Jahren als gültig erklärt.

Im Zuge der Diskussion um die Verabschiedung des IT-Sicherheitsgesetzes 2.0 und einer geplanten Überarbeitung der B3S Orientierungshilfe durch das BSI ist es sinnvoll, sich die bestehende B3S-Landschaft genau anzuschauen. Auf der Webseite des BSI werden 10 existierende B3S u. a. für die KRITIS-Sektoren Wasser, ITK, Ernährung, Gesundheit und Pharma sowie Verkehr veröffentlicht. Allerdings besteht keine Veröffentlichungspflicht; die Anzahl tatsächliche existierender B3S liegt deutlich höher.

Überblick über B3S

Betrachtet man nur die öffentlich verfügbaren B3S, lassen sich folgende Erkenntnisse ableiten:

  • Die meisten B3S wurden durch Verbände herausgegeben und die erste Version in den Jahren 2018 und 2019 veröffentlicht.
  • Im Zuge der Weiterentwicklung bzw. Verlängerung der B3S wurden die Inhalte teilweise vertieft und aktualisiert, aber nur kleine Änderungen vorgenommen, und es erfolgte meist keine Änderung der Grundstruktur.
  • In der Regel orientieren sich die B3S-Autorinnen und Autoren an der einschlägigen Orientierungshilfe des BSI (Ausnahme: Der B3S für Verkehrssteuerungs- und Leitsysteme im kommunalen Straßenverkehr ist nach DIN ISO/IEC 27001 strukturiert)
  • Alle B3S umfassen nicht nur den B3S-Betreiber, sondern auch Dienstleister und Dritte, welche Teilleistungen bzw. Teilfunktionen erbringen. Der KRITIS-Betreiber muss dabei sicherstellen, dass die B3S-Anforderungen eingehalten werden.
  • Alle B3S verfolgen einen Allgefahrenansatz, und der Einsatz eines Informations-Sicherheitsmanagementsystems (ISMS) wird empfohlen und ist teilweise verpflichtend (u.a. B3S Gesundheitsversorgung im Krankenhaus)
  • Alle B3S verweisen auf allgemeine Normen (z. B. ISO 27001, IT-Grundschutz) und weitere branchenspezifische Standards, welche gemeinsam mit dem B3S angewendet werden müssen.
  • Alle B3S zeigen konkrete Maßnahmen und abzudeckende Themen auf, welche sich an der Orientierungshilfe orientieren und auf den speziellen KRITIS-Sektor angepasst wurden.

Vergleich B3S

Zukünftige B3S

Basierend auf den analysierten B3S lässt sich für die Erstellung zukünftiger B3S folgende Struktur empfehlen:

  1. Zunächst sollte die Festlegung des Scopes des B3S erfolgen. Dies beinhaltet die Nennung der Rechtsgrundlage, die Definition wichtiger Schlüsselbegriffe sowie die Festlegung der Zielsetzung des B3S mit einer Abgrenzung, welche Aspekte der kritischen Infrastruktur nicht Gegenstand des B3S sind.
  2. In einem zweiten Schritt sollte die KRITIS-Infrastruktur ausführlich beschrieben werden. Hierbei sollte auf die Funktionsweise und die Rollen/Akteure eingegangen werden. Im Mittelpunkt sollte die Beschreibung der Abhängigkeit der KRITIS-Infrastruktur von der IT stehen.
  3. Als dritter Schritt erfolgt die Festlegung und Formulierung der Schutzziele des B3S. Hierbei sollte auf die Anwendung eines Allgefahrenansatzes eingegangen, die KRITIS-Schutzziele genannt und auch die IT-Schutzziele beschrieben werden. Einbezogene Standards und Vorgaben, welche die Grundlage für den B3S bilden, können ebenfalls beschrieben bzw. auf diese verwiesen werden.
  4. Die Beschreibung der branchenspezifischen Gefährdungslage ist der vierte Schritt. Hierbei wird die kritische Dienstleistung definiert, indem deutlich wird, wann diese erfüllt oder nicht erfüllt wird. Des Weiteren werden die allgemeinen und IT-spezifischen Bedrohungen je nach Relevanz für den spezifischen B3S aufgelistet und gegenübergestellt. Die Benennung der Bedrohungskategorien und Schwachstellenkategorien sowie die Beschreibung des Umgangs bei Änderungen der Gefährdungslage sollten ebenfalls in diesem Schritt erfolgen.
  5. Im fünften Schritt erfolgt die Beschreibung des Vorgehens und Nennung von Maßnahmen für die Risikoanalyse und das Risikomanagement. Hierbei werden die Risikokategorien festgelegt und bewertet sowie Handlungsempfehlungen abgeleitet. Des Weiteren werden die Techniken und Methoden zur Durchführung der Risikoanalyse beschreiben und die Risikotoleranz definiert.
  6. Schritt sechs beinhaltet die Maßnahmen und Handlungsempfehlungen für den Umgang mit Risiken. Hierbei sollte sich an den abzudeckenden Themen der Orientierungshilfe orientiert werden:
    1. Relevanz eines ISMS
    2. Relevanz des Business Continuity Management für die kDL
    3. Relevanz des Asset Management
    4. Anforderungen an eine robuste/resiliente Architektur
    5. Anforderungen an eine bauliche/physische Sicherheit
    6. Bedeutung der personellen und organisatorischen Sicherheit
    7. Relevanz der branchenspezifischen Technik und Nennung spezifischer Anforderungen an die Ausgestaltung
    8. Bedeutung der branchenspezifischen Architektur und Verantwortung
    9. Anforderungen an die Vorfallserkennung und -bearbeitung
    10. Umgang mit Überprüfungen und die Bedeutung von Übungen
    11. Relevanz der externen Informationsversorgung und Unterstützung
    12. Rolle und Bedeutung von Lieferanten, Dienstleister und Dritte
    13. Beschreibung der technischen Informationssicherheit
  7. In Schritt sieben erfolgt die Definition der zulässigen Arten von Nachweisen, welche für die Erfüllung des B3S erforderlich sind. Hierbei sollen auch die für den Nachweis zulässigen Standards bzw. Anforderungen genannt werden. Des Weiteren müssen die Anforderungen an das Prüfschema sowie das Prüfteam beschrieben werden. Zum Schluss wird auch die Nachweispflicht gegenüber dem BSI geregelt.

Zusätzlich zu den skizzierten Schritten kann durch einen Anhang die Übersichtlichkeit etwa von Schwachstellen und Bedrohungskategorien verbessert werden. Weiterhin ist es empfehlenswert, Schlüsselwörter wie „MUSS“, „SOLL“ und „KANN“ zu verwenden, damit die Bedeutung von Maßnahmen sofort ersichtlich ist. Ein Literaturverzeichnis, Abkürzungsverzeichnis, sowie ein Glossar sorgen für ein besseres Verständnis des B3S.

Kritis

Show Your HighNIS: Highlights des EU NIS Investment Reports

von Tim Goos.

Im Dezember 2020 wurde der NIS Investment Report veröffentlicht. Dieser analysiert, wie die EU NIS Direktive in den zwei Jahren seit ihrer Umsetzung in die nationalen Gesetze von Organisationen implementiert wurde. Dabei betrachtet der Report als repräsentative Stichprobe für die gesamte EU nur Organisationen aus den vier Ländern Deutschland, Frankreich, Spanien und Polen. So konnte ein Vergleich zwischen den Ländern, aber auch zwischen verschiedenen Sektoren gezogen werden. Dabei stellte sich heraus, dass in Bezug auf die Umsetzungstiefe die Länder von Deutschland und die Sektoren vom Banken- sowie vom Energiesektor angeführt werden. Abgeschlossen wird der Bericht durch eine Umfrage zu den gewählten Schwerpunkten und Komplikationen bei der Implementierung. Nicht überraschend werden unklare Erwartungen der nationalen Autoritäten und Konflikte mit anderen Gesetzen als die größten Hindernisse genannt.

Zusammengefasst bietet der NIS Investment Report einen Einblick in die Umsetzung der NIS Direktive, aber leider keinen tiefen.

Abbildung1: Darstellung der aktuellen Implementierung der NIS Direktive[1]

Insgesamt haben rund 80 % aller betrachteten Organisationen mit der Implementierung begonnen oder haben diese schon vollendet. Nur eine der 251 betrachteten Organisationen weigert sich, die NIS Direktive zu implementieren oder sich an dieser zu orientieren. Weiterhin dauert die Implementierung im Schnitt zwischen 14 und 18 Monaten, womit dreiviertel der Organisationen im Jahr 2018 oder 2019 starteten. Vorreiter bei der vollendeten Implementierung der NIS Direktive ist Deutschland mit ~70 %, dicht gefolgt von Frankreich und Italien mit ~67 % bzw. ~64 %. Spanien und Polen folgen mit unter 50 % Umsetzung. Gründe hierfür sind unter anderem die Geschwindigkeit, mit der die NIS Direktive in die nationalen Gesetze umgesetzt wurde, sowie deren Priorisierung.

Die eingesetzten dedizierten Ressourcen umfassen zu 90 % ein Budget zwischen 50.000 € und 1 Million € mit einer 50/50-Verteilung, ob neue oder externe Arbeitskräfte eingesetzt werden. Da keine Korrelation zwischen den erhobenen Daten und der Größe der entsprechenden Organisationen vorliegt, können die Daten schlecht interpretiert werden. Es ist anzunehmen, dass kleinere Organisationen mehr auf neue oder externe Arbeitskräfte setzen, um die NIS Direktive zu implementieren, während große Organisationen durch entsprechend größere IT-Abteilungen und Know-how diese selbständig umsetzen können. Ein interessanter Ausreißer ist der Sektor Digitale Infrastruktur. In diesem gaben ~39 % der Organisationen ein Budget unter 50.000 € an. Im Vergleich zum Energiesektor zeigen sich große Diskrepanzen. Daraus lässt sich schließen, dass die einzelnen Sektoren unterschiedlichen Wert auf IT-Sicherheit legen.

Den größten Einfluss auf die IT-Sicherheit der Organisationen hat die NIS-Direktive in den drei Sicherheitsbereichen „Governance, Risk and Compliance“, „Security Analytics“ und „Network Security“. Dies zeigt sich z. B. dadurch, dass 81 % aller betrachteten Organisationen einen Mechanismus zum Melden von Vorfällen in der IT-Sicherheit an nationale Autoritäten eingerichtet haben. Außerdem sieht die überwiegende Mehrheit aller betrachteten Organisationen die NIS-Direktive als einen positiven Beitrag zu Ihrer IT-Sicherheit. Dies könnte an den wenigen neuen Technologien liegen, die laut Umfrage eingesetzt werden. Es wurden also meist schon bestehende Systeme erweitert oder ausgebaut, was es den Organisationen einfacher machte. Schließlich gaben die betrachteten Organisationen die verschiedenen Umsetzungen in nationale Gesetze und mögliche Konflikte mit alten Gesetzgebungen sowie die Priorisierung anderer Regulierungen und die unklaren Erwartungen von Seiten nationaler Autoritäten als die größten Schwierigkeiten bei der Implementierung der NIS Direktive an.

[1] S. 18 des NIS Investments Report https://www.enisa.europa.eu/publications/nis-investments

Kritis

Verbändeanhörung zur neuen KRITIS-Verordnung

An die einschlägigen Verbände wurde heute ein Vorab-Entwurf der Änderung der KRITIS-Verordnung zur Anhörung verschickt. Das BMI sieht darin signifikante neue bzw. verschärfte Anforderungen für KRITIS-Betreiber und – erstmalig – auch andere Unternehmen vor. Der Entwurf ist wohl innerhalb der Bundesregierung, anders als ein typischer Referentenentwurf, noch nicht abschließend abgestimmt.

KRITIS-Betreiber bleibten weiter verpflichtet, ihre Anlagen für kritische Dienstleistungen (kDL) nach „Stand der Technik“ abzusichern, was alle zwei Jahre durch zu überprüfen ist. Verstöße könnten zukünftig jedoch mit bis zu 20 Millionen Euro für juristische Personen geahndet werden (heute: 100.000 Euro).

BMI, Auswärtiges Amt und zuständiges Fachministerium könnten zukünftig den Einsatz bestimmter kritischer Komponenten verbieten („Lex Huawei“).

Betreiber würden zudem verpflichtet, Systeme zur „automatischen Angriffserkennung“ (lies: SIEM, ggf. SOC) zu nutzen und die Daten aus diesen vier Jahre lang aufzubewahren,

Kein neuer Schwellwert, aber neue Schwellen

Zwar bleibt die Orientierungsgröße von 500.000 mit einer kDL versorgten Menschen für die Einstufung als Kritis-Anlage erhalten. Im Detail wurde deren Interpretation aber verändert und ausgeweitet.

Für Verkehrsbetriebe etwa würde sich die Formulierung von „125 Millionen Fahrgästen im Jahr“ zu „125 Millionen unternehmensbezogener Fahrgastfahrten im Jahr“ konkretisieren, was Querelen wie bei der BVG (inzwischen beigelegt) die Grundlage entzieht.

Software und IT-Dienste als KRITIS

Neu als KRITIS-Anlagen werden nun „Software und IT-Dienste, die für die Erbringung einer kritischen Dienstleistung notwendig sind“ genannt. Hier ist jedoch noch eine konkrete Interpretation vonnöten.

Bis zum 17. Mai erwartet das BMI die Stellungnahmen der Verbände. Am 26. Mai ist eine Anhörung per Videokonferenz terminiert.

Kritis

IT-Sicherheitsgesetz 2.0 verabschiedet

Nach langen Verhandlungen hat der Bundestag am 23.4.2021 „nach halbstündiger Aussprache“ – sprich, kurz und (je nach Standpunkt) schmerzlos bzw. -voll die Neuausgabe des IT-Sicherheitsgesetzes von 2015 beschlossen. Seit 2019 hatte es für die Novelle des Gesetzes, welches bis zuletzt nicht evaluiert worden war, eine Reihe von öffentlichen, nichtöffentlichen, geleakten und teilweise schnell wieder veralteten Entwürfen gegeben, die der kommentierenden Zivilgesellschaft einiges an Agilität abverlangten.

Am Ende konnte die viele – nicht wenige sagen: vernichtende – Kritik am Gesamtwerk nur wenig Änderungen bewirken; auch die Anträge der verschiedenen Oppositionsparteien wurden sämtlich abgeschmettert. Nun ist es, was es ist – und wird, wie bereits das ursprüngliche IT-SiG – konkret vor allem mit den folgenden Rechtsverordnungen ausgestaltet werden.

Klar ist aber schon, dass die Kompetenz des BSI stark erweitert wird. Es kann künftig Sicherheitslücken in IT-Systemen über öffentliche Telekommunikationsnetze mithilfe von Portscans suchen und semi-offensive Methoden wie Honeypots und Sinkholes einsetzen. Dazu mischt das BSI jetzt im Verbraucherschutz mit, etwa mit einem IT-Sicherheitskennzeichen.

Kritis-Betreiber sowie Betreiber im Energie-Sektor müssen bald Systeme zur Angriffserkennung („SOC“/„SIEM“) einsetzen. Außerdem müssen Erklärungen von Herstellern kritischer Komponenten eingeholt werden, dass keine Sabotage oder Spionage zu erwarten ist.

Bestimmte bislang schon geltende Pflichten für Kritis-Betreiber (v. a. die Meldepflicht) betreffen demnächst auch „Unternehmen in besonderem öffentlichen Interesse“ („UNBÖFI“), etwa in der Rüstungsindustrie und im Bereich Verschlusssachen („KRITIS-light“). Ebenso auf dem Radar sind nun Unternehmen, die der Störfallverordnung unterliegen, und Konzerne „von erheblicher volkswirtschaftlicher Bedeutung“ im Inland oder als Zulieferer mit „Alleinstellungsmerkmalen“. Neu betroffen ist der Sektor Entsorgung.

https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2020/12/it-sig-2-kabinett.html

Kryptographie

Kein Ende-zu-Ende gut, alles gut bei E-Mail

Ende-zu-Ende-Verschlüsselung ist heute bei E-Mails faktisch nicht vorhanden. Es gibt dafür zwei große Konzepte bzw. Standards: PGP (inline/MIME) und S/MIME. Doch sowohl mangels intuitiver Verwendung in den gängigsten E-Mail-Anwendungen als auch aufgrund des schlechten Rufs – hauptsächlich in Bezug auf Benutzbarkeit, aber auch auf Sicherheit – finden sie keine große Akzeptanz.

Dann halt WhatsApp?

Die gängigen Messenger sind inzwischen deutlich sicherer als E-Mail. Viele Organisationen scheuen zudem den Aufwand, eine Ende-zu-Ende-Verschlüsselung einzuführen. Sie fürchten einerseits die schlechte Außenwirkung, wenn E-Mails erst nach organisatorischem Aufwand ausgetauscht werden können (Schlüsselaustausch), und andererseits den Verlust von E-Mail-Historie (Backups), wenn Schlüsselmaterial verlorengeht. Auch das Einbinden von Spam- und Viren-Scanner ist keine einfache Angelegenheit. Es herrscht noch immer das Mantra: „Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie.“

Stellt eine Organisation die Möglichkeit, E-Mails verschlüsselt zu senden, als Option zur Verfügung, greifen die Mitarbeiterinnen und Mitarbeiter nur sehr selten darauf zurück. Oft sind es vermeintlich nur „nicht-sensible“ Informationen, die ausgetauscht werden. Später, bei kritischeren Daten, heißt es häufig, einmal sei keinmal – bis dann hochsensible Informationen zeitkritisch ausgetauscht werden müssen und keine Zeit mehr für einen Schlüsselaustausch ist.

Pfeiler der Verschlüsselung

Eine gute E-Mail-Verschlüsselung basiert auf drei Pfeilern:

  1. Sichere Software,
  2. Schulung (zur richtigen Verwendung) und
  3. Sensibilisierung (zur Motivation)

Schwächelt nur ein Pfeiler, bricht die ganze Konstruktion zusammen. Gerade die dritte Säule hat einen großen Feind: den Frust. Zu häufig kommt es vor, dass die Gegenseite aus verschiedenen Gründen nicht in der Lage ist, verschlüsselte E-Mail-Kommunikation durchzuführen, während eine unverschlüsselte E-Mail einfach funktioniert.

„Wir haben ein E-Mail-Gateway, das kann das alles.“, ist ein Lösungsansatz, den man öfters mal hört. Es ist richtig, E-Mail-Gateways adressieren einige Schwächen gängiger E-Mail-Anwendungen. Aber intuitive Verwendung ist auch hier Fehlanzeige. Meistens gilt auch hier: Die E-Mail muss raus – und der Schlüsselaustausch verbleibt beim Endanwender. Im Zweifel wird die E-Mail dann doch unverschlüsselt versandt.

Ist eine Verschlüsselung nur optional, kann man aus Versehen unverschlüsselt versenden oder die Notwendigkeit verschlüsselt zu versenden solange hinauszögern, bis eine vertrauliche E-Mail aus zeitlichen Gründen unverschlüsselt versendet werden muss.

Zentrale Qual: S/MIME

S/MIME ist vergleichbar mit HTTPS in folgender Hinsicht: Es braucht eine Welt umspannendes Netz aus PKIs (Public-Key-Infrastrukturen), um gut zu funktionieren.

Was S/MIME im Gegensatz zu HTTPS fehlt, ist ein Schlüsselaustausch-Element. Beim Entwurf von S/MIME (1995) stellte man sich einen Verzeichnisdienst oder eine Verzeichnisdienst-Infrastruktur vor, hatte jedoch die Rechnung ohne den Datenschutz gemacht. Die Alternative zu einem Verzeichnis, sich gegenseitig signierte E-Mails zu senden, kann schnell zu einem größeren Delay führen, wenn nicht beide Parteien gleichzeitig am Rechner sitzen.

Was S/MIME mit HTTPS gemeinsam hat, es werden vertrauenswürdige Zertifizierungsstellen benötigt. Man kann eine eigene Zertifizierungsstelle aufbauen, doch dann hat man das Problem, diese als vertrauenswürdig an alle (auch potentielle) Kommunikationspartner zu verteilen. Hier gibt es keinen einheitlich definierten Weg. Oder man wendet sich an die wenigen öffentlich anerkannten Zertifizierungsstellen, die neben Server-Zertifikaten auch Personen-Zertifikate ausstellen. Diese lassen sich dies jedoch gut bezahlen, vor allem im Vergleich zu Server-Zertifikaten, wo der öffentliche Dienst Let’s Encrypt für einen drastischen Preisverfall gesorgt hat. Ob aber eine öffentlich anerkannte Zertifizierungsstelle wirklich gute Arbeit leistet, ist auch nicht immer sichergestellt. Hier gibt es im Bereich der Server-Zertifikate viele Negativ-Beispiele. Nicht umsonst drohen Größen wie Google, Mozilla und Apple mit dem Rauswurf von Zertifizierungsstellen, wenn diese einmal wieder „Blödsinn“ gemacht haben. Nur gibt es eine solche Marktmacht bei S/MIME nicht.

Pretty Bad: PGP

PGP hat von Anfang an auf eine PKI verzichten wollen, kommt aber ohne einen (dezentralen) Verzeichnisdienst auch nicht wirklich aus. Und die Idee eines Web-Of-Trust kann man weitestgehend als gescheitert betrachten, da braucht man noch nicht einmal die Datenschutz-Karte zu zücken:

„Ach ja, ich konnte Deine E-Mail nicht öffnen“ – und das Tage oder Wochen nach dem Versenden der E-Mail und erst auf Nachfrage. Trotz Schlüsselaustauschs. Was ist passiert? Der Empfänger hat seinen Schlüssel „verloren“, sieht aber keine Notwendigkeit zu handeln, weder proaktiv noch reaktiv. Solche E-Mail-Empfänger adressieren ganz klar den Feind „Frust“.

Transportverschlüsselung als Rettung?

„Aber was ist mit der Transportverschlüsselung, da kann doch dann auch keiner mitlesen?“ Das Hauptproblem auch hier: Eine E-Mail muss ankommen und vom Empfänger gelesen werden können, egal wie. Schlägt beim Versenden die Zertifikatsprüfung fehlt, wird trotzdem übertragen. Bietet die Gegenstelle keine Verschlüsselung an, wird trotzdem übertragen. Interessanterweise ist es immer erstmal ein Fehler des Senders, wenn eine E-Mail nicht versendet werden kann, auch wenn die Gegenstelle sich nicht an geltende Normen hält. Auch das Thema Sender-Authentizität wird von der Transportverschlüsselung nicht geleistet.