Artikel von unseren Mitgliedern

Bundesinnenministerium ignoriert Fristen in den eigenen Gesetzen!

/in , /von

Unsere Mitglieder einfachnurmark und TheC haben diese Einschätzung aus Sicht der AG KRITIS vorgenommen.

Die Bevölkerung erhält über Versorgungsunternehmen kritischen Dienstleistungen wie z. B. Energie, Wasser oder Gesundheitsversorgung.

Überschreiten diese Versorgungsunternehmen den in der „Verordnung zur Bestimmung Kritischer Infrastrukturen nach dem BSI-Gesetz“ (KritisV) vorgegebenen Regelschwellenwert von aktuell 500.000 versorgten Personen, sind sie Betreiber einer kritischen Infrastruktur (KRITIS) im Sinne des BSI-Gesetzes (BSIG). Dadurch werden sie zur Umsetzung und Einhaltung von im BSIG geforderten Maßnahmen zum Schutz Ihrer Produktionsumgebungen verpflichtet.

Der Berliner Tagesspiegel berichtete erneut über unzureichend geschützte Wasserbetriebe:

Wasserbetriebe gegen Hackerangriffe mangelhaft geschützt

Dabei wirft der Tagesspiegel auch die Frage auf, ob die Schwellenwerte noch zeitgemäß sind oder einer Evaluierung bedürfen. Auf diese Fragestellung gehen wir hier näher ein.

Nehmen wir beispielsweise die Größe von Städten in Deutschland als Maßstab, überschreiten in Deutschland nur 14 von 81 Großstädten den Schwellenwert von 500.000 Einwohnern. Dies sind bei insgesamt mehr als 2.000 Städten lediglich ca. 20% aller Einwohner. Der Überwiegende Anteil aller Bürger wird also von Unternehmen versorgt, die nicht verpflichtet sind, ihre Systeme und IT-Infrastruktur entsprechend der Anforderungen für KRITIS-Betreiber abzusichern.

Evaluierung längst überfällig

Die KritisV, und damit auch die Schwellenwerte, soll laut § 9 KritisV alle zwei Jahre evaluiert werden. Die Frist für die Evaluierung ist allerdings bereits zweimal verstrichen, ohne dass das BMI eine entsprechende Evaluierung vorgelegt hat. Dabei hatte sich das BMI diese Evaluierungen und Fristen selbst verbindlich in der Verordnung vorgegeben.

Auch das IT-Sicherheitsgesetz von 2015 hätte bereits mindestens einmal (alle vier Jahre) evaluiert werden müssen.

Die AG KRITIS blickt daher mit großer Sorge darauf, dass die Versorgungssicherheit der Bevölkerung für das BMI nachrangig ist.

Statt also die gesetzlich vorgeschriebene Evaluierungen vorzunehmen und damit einhergehend auch eine Berücksichtigung von Kaskadeneffekten zu analysieren, drückt das BMI lieber eine zweite Version des IT-Sicherheitsgesetzes durch, ohne die erste Version evaluiert zu haben.

Auch Mario Brandenburg MdB, der technologiepolitische Sprecher der Fraktion der Freien Demokraten im Deutschen Bundestag veröffentlichte ein entsprechendes Statement dazu.

Die AG KRITIS fordert daher das BMI auf, die gesetzlich vorgegebene Evaluierung der KritisV umgehend – und damit vor allem noch vor Verabschiedung des IT-Sicherheitsgesetz 2.0 – vorzunehmen, um den Gesetzesbruch abzustellen. Damit einhergehend ist die offensichtlich benötigte Senkung der Schwellwerte in Bezug auf effektiven Bevölkerungsschutz zu realisieren. Nur so kann die Versorgungssicherheit der Bürger in Deutschland gewährleistet werden. Selbstverständlich fordern wir auch, dass das BMI die Evaluierung unter Einbeziehung der in diesem Bereich aktiven Interessensvertretungen aus Wirtschaft und Zivilgesellschaft durchführt und das Ergebnis im Sinne einer lebendigen Demokratie veröffentlicht.

Kritische Sicherheitslücke in F5 Produkten zeigt dramatische Schwachstelle für KRITIS-Betreiber

/in /von

Unsere Mitglieder Thomas Fricke und Manuel Atug haben sich die aktuelle Situation zu F5 angeschaut und eine Einschätzung aus Sicht der AG KRITIS vorgenommen.

Erneut ist eine wesentliche Komponente, die oftmals auch in kritischen Infrastrukturen zum Einsatz kommt, von einer schwerwiegenden Sicherheitslücke betroffen. Hersteller F5, bekannt für eine Reihe von Produkten aus dem Loadbalancer und VPN Bereich wie BIG-IP, die vor allem von großen Unternehmen eingesetzt werden, kann über die Management Schnittstelle angegriffen werden. Das CERT-Bund des BSI meldet schon seit einigen Tagen Scans und vor allem die aktive Ausnutzung der Remote Code Execution Schwachstelle mit der CVE-2020-5902. Eine Überwachung der Anfälligkeit eigenen Systeme via Shodan ist inzwischen auch schon möglich.

F5 BIG-IP

Quelle: https://support.f5.com/csp/article/K52145254?sf235665517=1

Mit F5 BIG-IP Loadbalancern können große verteilte Serverinfrastrukturen verwaltet werden. Normalerweise sind sie auch die DNS Server, VPN Server, Endpunkte für die Verschlüsselung, TLS Terminatoren und verwalten die privaten Schlüssel für hunderte oder tausende Internet Domains.

Aufgrund der bekannt gewordenen Schwachstelle ist es möglich, eine sog. Remote Code Execution, also das Ausführen von Schadcode aus dem Internet heraus auf den entsprechenden Systemen auszuführen. Ist das Traffic Management User Interface (TMUI), welches auch bekannt ist als „Configuration utility“, zur Verwaltung der Anwendung aus dem Internet erreichbar, können sich also Angreifer Zugriff auf die gesamte Zertifikatsinfrastruktur eines Unternehmens, einer Institution oder einer Behörde verschaffen.

Der Angriff ist bereits als Modul für Metasploit verfügbar, eigentlich ein Tool für Penetrationstests zur Beurteilung der Sicherheit von Umgebungen und Systemen, welches aber von Angreifern auch zum Aufspüren von verwundbaren Systemen genutzt werden kann.

Dabei ist der Angriff effektiv gesehen so einfach, dass er sogar in einen einzigen Tweet auf Twitter passt.

Das gleiche ist natürlich auch von innen heraus möglich, also aus jedem Netzsegment, aus dem man das Management Interface erreichen kann. Haben Angreifer hinreichende Kenntnisse, wie sie die Konfiguration auf der F5 verändern können, sind sie auch in der Lage, verschleierte Angriffe durchzuführen, wie z.B. die Umleitung bestimmter URL-Pfade der Webseiten auf andere Serversysteme.

Das eröffnet im KRITIS-Umfeld die Möglichkeit z.B. das Online Banking im Finanzsektor anzugreifen und tiefer in Kritische Infrastrukturen einzudringen. F5 Server als zentrale Schaltstelle – üblicher Weise in der Demilitarisierten Zone (DMZ) betrieben – haben daher in der Regel erweiterte Zugriffe auf eine Vielzahl von inneren und äußeren Diensten der hiervon Betroffenen KRITIS-Betreiber.

Nötig sind dazu lediglich einige elementare Linux- und TCL/TK-Kenntnisse und ein Grundverständnis der Funktionsweise von F5 selbst. Themenkomplexe, die sich eine organisierte Kriminalität oder auch staatliche Akteure und APT-Gruppen zügig aneignen können, wenn dieses Know-How nicht eh schon vorhanden ist.

Notwendige Maßnahmen

Selbstredend sind alle betroffenen Installationen umgehend zu patchen!

Da aktive Kompromittierungen bereits berichtet werden sind unbedingt im Nachgang die Systemlandschaft – und die betriebenen F5 Systeme im Speziellen – auf erfolgreiche Angriffe zu überprüfen.

Alle Schlüssel, die auf einer F5 verwaltet wurden, sollten daher als möglicherweise kompromittiert betrachtet und damit erneuert, sowie über die Certificate Revocation Lists (CRL) zurückgerufen und ihr Status über das Online Certificate Status Protocol (OCSP) als unsicher eingestuft werden. Im Einzelfall muss sogar die von den F5 erreichbare Infrastruktur als kompromittiert eingestuft und entsprechend neu aufgesetzt werden, wenn man Backdoors in der eigenen Systemlandschaft vermeiden möchte.

Bewertung

Bei genauer Betrachtung kommen wir hier einem erneuten Totalschaden in solchen Szenarien sehr nahe. Es ist aufgrund der Banalität der Schwachstelle anzunehmen, dass eine Sicherheitslücke dieses Ausmasses bei sorgfältigen, geordneten und kontinuierlichen Sicherheits- und Abnahmetests nicht übersehen worden wäre.

Forderungen

Die Preise für F5 Hardware und Softwarelizenzen gehen für individuelle Server bis weit über 100.000,- €. Eine Clusterinstallation kann auch schnell die Grenze von 1 Millionen € erreichen. Es kann daher zu Recht gefordert werden, dass die Haftung der Hersteller auf Schäden, die aus so groben Fehlern herrühren, ausgedehnt werden sollten. Weil es für einzelne Kunden nicht ohne weiteres möglich ist, in die internen Prozesse der Hersteller Einblick zu nehmen, muss die Beweislast umgekehrt und der Hersteller dazu gezwungen werden, mindestens seine Sicherheits- und Abnahmetests offen zulegen.

Es ist eine alte aber wie man sieht weiterhin aktuelle Forderung, Server- und Netzwerk-Komponenten als Open Source Lösungen zu implementieren. Die großen Cloud-Anbieter tolerieren schon seit längerem kaum noch Closed Source Komponenten in den Netzwerken ihrer Cloud-Rechenzentren. Diese Praxis muss auch in kritischen Infrastrukturen Einzug halten.

Der Druck auf einzelne Hersteller hat bereits zu Anpassungen geführt. Es gibt auch bekannte Marken und Hersteller, die mehrfach durch grobe Sicherheitslücken aufgefallen sind und jetzt auf ihrer Hardware Open Source Implementierungen unterstützen.

Insgesamt werden allein im professionellen Netzwerkbereich fast 100 Switches unterstützt. Es ist zu hoffen, dass KRITIS-Betreiber in Zukunft keine Closed Source Komponenten mehr einsetzen (müssen), wenn nötig, dann auch durch eine Änderung der Zertifizierungskriterien.

Hersteller mit einer unsicheren Historie sollten bei Audits zu einer Abwertung der Sicherheitseinschätzung vom Prüfer führen.

Und täglich grüßt das Murmeltier?!

Parallelen zu Citrix #Shitrix Anfang des Jahres sind erkennbar und eher ein strukturelles Defizit als purer Zufall.

 

KRITIS Betreiber von schwerwiegender Citrix-Schwachstelle betroffen

Kommentar zum neuen Referentenentwurf des IT-Sicherheitsgesetz 2.0 (IT-SiG2)

/in /von

Die beiden Leiter der AG KRITIS, Manuel Atug und Johannes Rundfeldt zum von netzpolitik.org veröffentlichten neuen Entwurf des IT-SiG2 von Mai 2020:

Das neue IT-Sicherheitsgesetz 2.0 (IT-SiG2) ist definitiv eine Verbesserung zum vorherigen Entwurf von März 2019. Aber nicht alle Details sind gut, einzelne Punkte sind leider auch ein Rückschritt und werfen neue Gefahren und Risiken auf.

Die AG KRITIS begrüßt die Tatsache, dass die hochkritischen Änderungen an der Strafprozessordnung und am Strafgesetzbuch, die noch im ersten veröffentlichten Entwurf von März 2019 aufgeführt wurden, nun nicht mehr enthalten sind. Auch begrüßen wir die Tatsache, dass die Entsorgung – also Teil der Abfallwirtschaft – nun auch als kritische Infrastruktur betrachtet wird. Dies ist überfällig und sinnvoll, schließlich entstehen sehr schnell katastrophale Gesundheitsrisiken für die Bevölkerung wegen der drohenden Seuchengefahr und Gefährdungen in der Umwelt bedingt durch gefährliche Stoffe, wenn die Abfallentsorgung nicht mehr funktionieren würde.

Leider hat sich damit jedoch nicht alles zum Guten verbessert. Es gibt insbesondere auch einige Neuerungen, die in dieser Weise unsere kritischen Infrastrukturen direkt gefährden können.

Unser größter Kritikpunkt ist die hochgefährliche Datensammlung, die sich hinter der unscheinbaren Formulierung in § 9b Absatz 1 BSIG verbirgt. Dort geht es um IT (oder OT) -Komponenten in kritischen Infrastrukturen.

„Der Einsatz einer kritischen Komponente (§ 2 Absatz 13), (…), ist durch den Betreiber einer Kritischen Infrastruktur dem Bundesministerium des Innern, für Bau und Heimat vor Einbau anzuzeigen. In der Anzeige ist die kritische Komponente und die Art ihres Einsatzes anzugeben.“

Bisher müssen Hersteller solcher Komponenten mit dem BSI zusammen arbeiten, um eine Zertifizierung von Komponenten zu erreichen. Dabei kann das BMI diese Zertifizierung aus Gründen der öffentlichen Sicherheit ablehnen, auch wenn das BSI zum Schluss kommt, dass die zu zertifizierende Komponente den Kriterien entspricht.

Der neue IT-SiG2-Entwurf schafft hier allerdings eine neue Anzeigepflicht. Nicht mehr nur der Hersteller der Komponente muss mit den Behörden in Kontakt treten, sondern der Betreiber der Komponente muss deren Einsatz beim BMI melden. Auf diese Weise plant das BMI eine Liste aufzubauen, welcher KRITIS-Betreiber welche Komponenten im Einsatz hat. So eine Liste ist jedoch höchst kritisch zu bewerten, da jeder Geheimdienst und jede ausländische Macht, die Zugriff auf diese hochsensible Liste erlangt, unsere kritische Infrastruktur gefährden kann. Getreu dem Motto „Wo ein Trog ist, da sammeln sich auch Schweine“ halten wir es für überflüssig und gefährlich, so eine hochsensible Datensammlung überhaupt anzulegen. Wenn man aus sicherheitstechnischen Erwägungen trotzdem zum Schluss kommt, so eine Liste zu benötigen, so muss diese besonders vor dem Zugriff von in- und ausländischen Ermittlungsbehörden und Nachrichtendiensten geschützt werden. Nur ein unabhängiges BSI, das nicht mehr unter der Aufsicht des BMI steht, könnte so eine Liste geeignet verwalten.

Leider wurde diese essentielle fachliche Unabhängigkeit des BSI nicht im § 1 des BSIG vorgesehen. Hier wünschen wir uns eine Nachbesserung, denn ein fachlich unabhängiges BSI ist notwendig und überfällig. Obwohl es verschiedene Ansätze gibt, wie dies juristisch erreicht werden könnte, halten wir die Anpassung des § 1 BSIG für den naheliegendsten Ansatz, wenn man sowieso gerade plant, das BSIG zu ändern. Dabei kann man sich in der Ausgestaltung der fachlichen Unabhängigkeit hervorragend am statistischen Bundesamt orientieren.

Der zweite nicht weniger relevante Kritikpunkt ist die offensichtliche Umgehung des frisch geschaffenen Nationalen Cyberabwehrzentrum (NCAZ) bei erfolgreichen Cyberangriffen auf IT-Systeme. Im zu ändernden § 109a TKG findet sich die Formulierung:

„(1a) Im Falle einer unrechtmäßigen Übermittlung an oder unrechtmäßigen Kenntniserlangung von Daten durch Dritte unterrichtet der Diensteanbieter unverzüglich das Bundeskriminalamt über diesen Sachverhalt, wenn bestimmte Tatsachen die Annahme rechtfertigen, dass 1. jemand Telekommunikations- oder Datenverarbeitungssysteme ohne Erlaubnis oder Billigung des Diensteanbieters verändert, auf diese eingewirkt oder Zugangseinrichtungen zu diesen überwunden hat und 2. dies nicht fahrlässig erfolgt ist.“

Im Fall der vorsätzlichen und erfolgreichen Umgehung von Zugangseinrichtungen, der Veränderung von Daten oder der Einwirkung von Dritten auf diese ist es wohl angebracht, dies als Cyberangriff zu bezeichnen. Je nachdem, wer der Täter ist, ändert sich die Zuständigkeit für die Vorfallsbehandlung und Ermittlung.

Handelt es sich um einen Angriff eines deutschen Bürgers auf eine technische Einrichtung der Bundeswehr, wäre der MAD zuständig. Wären wir im Krieg und hätte die Bundeswehr ein Mandat, wäre in diesem Fall das KdoCIR zuständig. Wenn ein System angegriffen wird, welches nicht zur Bundeswehr gehört, sondern z.B. zu einem Telekommunikationsanbieter, dann wäre das BKA nur dann zuständig, wenn der Angriff von einem deutschen Bürger ausgeht. Geht der Angriff von einem ausländischen Bürger aus, wäre der BND zuständig. Ginge der Angriff von einer ausländischen staatlichen Macht aus, wäre der BND und unter Umständen auch das Auswärtige Amt zuständig. In manchen Sonderfällen fiele auch eine Teil-Zuständigkeit an das BfV.

Zum Zeitpunkt der initialen Detektion eines Angriffs ist der Täter und dessen Nationalität aber unbekannt. Daher kann nicht von vornherein klar sein, wer wirklich zuständig ist. Aus genau diesem Grund wurde das NCAZ geschaffen, welches die Vorfallsbehandlung zwischen den möglicherweise zuständigen Bundesbehörden koordinieren soll. Im NCAZ sitzen deswegen Vertreter aller möglicherweise zuständigen Behörden, wie z.B. dem BKA, der BPol, dem BfV, dem BND, dem MAD und dem KdoCIR.

Wir sind daher zu der Meinung gekommen, dass an dieser Stelle die Meldung an das NCAZ erfolgen soll und eben nicht an das BKA. Das NCAZ kann dann koordinieren, welche Bundesbehörde auf Basis der vorliegenden Indizien wahrscheinlich zuständig ist. Nichtsdestotrotz sind, egal welche Behörde für die Ermittlungen zuständig ist, immer auch andere Bundesbehörden einzubinden, wie z.B. das BSI, welches nötigenfalls Warnungen und Meldungen über das CERT-Bund herausgeben müsste.

„Man muss Gesetze kompliziert machen, dann fällt es nicht so auf“, sagte Bundesinnenminister Horst Seehofer im Juni 2019. An dieses Mantra hält man im BMI auch beim IT-SiG2 konsequent fest. Im alten Entwurf fand sich noch die Formulierung, dass die Rüstungsindustrie zur sog. „Infrastruktur in besonderem öffentlichen Interesse“ (ISBÖFI) gehören soll. Die „ISBÖFI“ ist quasi eine Art „KRITIS light“. Nicht alle KRITIS Pflichten werden auferlegt, aber manche. Im neuen IT-SiG2-Entwurf findet sich das Wort „Rüstung“ nun nicht mehr, trotzdem gehört Rüstung weiterhin zu ISBÖFI. Dies wird nun durch die verschleiernde Erwähnung des „§ 60 AWV Absatz 1 Satz 1-5“ festgelegt und auch in den Begründungen zum Gesetz weder erläutert noch aufgeklärt.

Die AG KRITIS ist der Meinung, dass Rüstung weder KRITIS ist, noch zu einer Art „KRITIS light“ gehören kann – denn die Rüstungsindustrie gehört eben nicht zu solchen Diensten, „die von wesentlicher Bedeutung für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen, der Gesundheit, der Sicherheit und des wirtschaftlichen oder sozialen Wohlergehens der Bevölkerung sind und deren Störung oder Zerstörung erhebliche Auswirkungen hätte“ (KRITIS-Definition).

Selbst wenn man argumentieren würde, dass die hergestellten Rüstungsgüter nach Bestellung, Produktion und Lieferung der Bundeswehr zu Gute kommen würden und damit bei der Aufgabenerfüllung der Bundeswehr (Verteidigungsarmee) helfen sollen – selbst dann wäre die Rüstungsindustrie noch nicht KRITIS, da die Bundeswehr diese Aufgaben mit Ihren Beständen erfüllen muss und die Beschaffung neuer Waffen so lange dauert, das diese neuen Waffen wohl kaum zur Bewältigung der dann aktuellen Lage eingesetzt werden können. Eine Mitverantwortung für die öffentliche Sicherheit kann daher bei der Rüstungsindustrie nicht behauptet werden. Entsprechend gehört die Rüstungsindustrie auch nicht zu den kritischen Infrastrukturen und darf daher auch nicht der neu geschaffenen Vorstufe „ISBÖFI“ zugeordnet werden.

Unser dritter Kritikpunkt ist, dass im IT-SiG von 2015 festgelegt wurde, dass eine Evaluierung der Gesetzesänderungen spätestens vier Jahre nach Inkrafttreten vorgenommen werden soll. Unserer Kenntnis nach ist diese Evaluierung aber bisher nicht erfolgt. Konsequenterweise sieht das BMI auch keine Evaluierung des neuen IT-SiG2 vor, sondern stellt in Aussicht, die aktuell gesetzeswidrig(!) überfällige Evaluierung des IT-SiG von 2015 doch noch vorzunehmen. Dies reicht dem BMI als Begründung, warum eine Evaluierung der zweiten Version des IT-SiG nicht notwendig wäre, weil man ja Erkenntnisse aus dem Gesetzesentwurf des IT-SiG2 in die Evaluierung des IT-SiG von 2015 einfließen lassen könne.

Selbstverständlich ist das nicht ausreichend – das BMI soll, wie aus gutem Grund im Gesetz vorgesehen, erst das vorhandene IT-SiG von 2015 evaluieren und dann diese Erkenntnisse, genau wie geplant, in das IT-SiG2 einfließen lassen – aber nicht andersherum, wie es aktuell im IT-SiG2 angegeben wird.

Weiterhin findet sich im IT-Sig2 auch noch eine Passage, die uns als AG KRITIS mit Freude erfüllt. Uns zeigen diese Änderungen, dass man auch ehrenamtlich erfolgreichen und sinnvollen Lobbyismus betreiben kann.

Es scheint so, als wurden bestehende Forderungen der AG KRITIS im IT-SiG2 berücksichtigt. So soll das unserer Ansicht nach zu schwach besetzte MIRT deutlich anwachsen. Dies vergrößert die staatlichen Krisenbewältigungskapazitäten signifikant. Auch das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) bekommt wichtige Aufgaben und weitere Personalstellen zugeteilt, um erstmalig in die Lage versetzt zu werden, auch für IT-Katastrophen Krisenreaktionspläne auszuarbeiten. Auch lesen wir den neu geschaffenen § 5c BSIG fast schon wie die initiale rechtliche Grundlage für den Einsatz eines zu schaffenden Cyberhilfswerks – wie von uns im Februar 2020 vorgestellt – und verortet die Kompetenzen und Verantwortlichkeiten an den richtigen Stellen, nämlich dem BSI gemeinsam mit dem Partner BBK.

Hier findet Ihr unser CHW-Konzept:

Konzept zur Steigerung der Bewältigungskapazitäten in Cyber-Großschadenslagen

Golem: Sandsäcke stapeln im Internet

/in /von

Das Onlinemagazin Golem hat sich mit unserem Mitglied @ijonberlin über die Fortschritte und den aktuellen Stand des CHW-Konzept erkundigt und einen Artikel dazu veröffentlicht.

Wie ein Technisches Hilfswerk für IT-Vorfälle stellen sich Aktivisten ein Cyberhilfswerk vor. Es soll eingreifen, wenn es zum Ernstfall kommt. Die Initiatoren sehen sich als Mittler zwischen Nerds und Behörden.

Artikel von Anna Biselli

Der vollständige Artikel bei Golem findet sich hier:

Artikel von Golem

Ohne Security keine Safety in Kritischen Infrastrukturen – Begriffliche Trennung und Zusammenführung

/in /von

Unsere Mitglieder Lars Fischer und Michel Messerschmidt haben sich mit der begrifflichen Trennung und Zusammenführung von Security und Safety für die AG KRITIS auseinandergesetzt.Paper der AG KRITIS: Ohne Safety keine Security in Kritischen Infrastrukturen

Wenn es erst einmal brennt bleibt keine Zeit mehr, um Missverständnisse auszudiskutieren. Und auch davor, wenn Systeme entwickelt und aufgebaut werden, um die Infrastruktur für die Grundversorgung unserer Gesellschaft zu bilden, ist es wesentlich, dass die Akteure miteinander Kommunizieren und eine einheitliche Sprache sprechen können. In diesem Artikel wollen wir die Unterscheidung der englischen Begriffe Safety und Security formulieren, was insbesondere deshalb wichtig ist, weil diese beiden Begriffe in vielen Sprachen mit nur einem Wort beschreiben werden. Die beiden Begriffe formulieren in Konzepten allerdings unterschiedliche und durchaus auch konkurrierende Ziele. Daher ist es wesentlich, diese Begriffe klar zu definieren und in der Arbeit zu unterscheiden. Im Folgenden geben wir deshalb eine Einführung und praktische Definitionen und zeigen beispielhaft das Konfliktpotential auf.

Kritische Infrastrukturen

Das wesentliche Merkmal von Systemen, die unter dem Begriff Kritische Infrastrukturen gebündelt werden, ist die Notwendigkeit ihrer Funktionalität und Verfügbarkeit für den Erhalt der Gesellschaft. Ein Ausfall Kritischer Infrastrukturen birgt das unmittelbare Risiko des Zusammenbruchs der Grundversorgung für wesentliche Teile der Bevölkerung.

Gemäß § 2 Abs 10 BSI-Gesetz sind Kritische Infrastrukturen jene, deren Ausfall oder Beeinträchtigung erhebliche Versorgungsengpässe oder Gefährdungen für die öffentliche Sicherheit verursachen kann.

Diese Begriffsbestimmung leitet sich aus der EU Richtlinie 2008/114 ab, welche die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen und die Gesundheit, Sicherheit und das wirtschaftliche oder soziale Wohlergehen der Bevölkerung als Aufgabe Kritischer Infrastrukturen begreift.

Aus diesem Grund ergibt sich die Notwendigkeit des besonderen Schutzes Kritischer Infrastrukturen und die Bereithaltung von Notfallplänen, -reserven und -personal. Der Ausfall Kritischer Infrastrukturen ist nicht tolerierbar.

Um dieser Anforderung mit endlichen Ressourcen gerecht zu werden, müssen Risiken bestimmt und Maßnahmen zur Reduktion der Risiken auf ein akzeptables Maß geplant, umgesetzt, geprüft, kontinuierlich aufrechterhalten und verbessert werden. Kritische Infrastrukturen beinhalten physische Komponenten. Durch die Digitalisierung von Kommunikation und Steuerung ist Software bzw. programmierbare Logik aber ein unverzichtbarer Bestandteil Kritischer Infrastrukturen geworden. Diese können daher auch als Cyber-physische Systeme bezeichnet werden. Das bedeutet auch, dass es nicht mehr genügt, nur die physische Sicherheit und den Schutz von Anlagen zu betrachten. Schutz- und Sicherheitsmaßnahmen beinhalten immer auch IT-Sicherheit.

Dabei fällt in der Praxis auf, dass der Begriff „Sicherheit“ bzw. „öffentliche Sicherheit“ oft nur einseitig verstanden wird. Denn im deutschen Sprachgebrauch werden sehr verschiedene Themenbereiche unter dem Begriff „Sicherheit“ versammelt. Wenn wir Begriffe wie Schutz, Sicherheit oder auch IT-Sicherheit verwenden, kann ein gemeinsames Verständnis also nicht vorausgesetzt werden. Klare Begrifflichkeiten sind aber alleine schon deshalb wichtig, weil die unterschiedlichen Bereiche deutlich unterschiedliche und oft auch widersprüchliche Anforderungen oder Ziele haben.

In der deutschen Ausgabe der EU Richtlinie 2008/114 findet sich zur Definition Kritischer Infastrukturen nur der mehrdeutige Begriff „Sicherheit„, obwohl die englische Ausgabe derselben EU Richtlinie nach „Safety“ und „Security“ differenziert:

„kritische Infrastruktur“ [bezeichnet] die in einem Mitgliedstaat gelegene Anlage, ein System oder ein Teil davon, die von wesentlicher Bedeutung für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen, der Gesundheit, der Sicherheit und des wirtschaftlichen oder sozialen Wohlergehens der Bevölkerung sind und deren Störung oder Zerstörung erhebliche Auswirkungen auf einen Mitgliedstaat hätte, da diese Funktionen nicht aufrechterhalten werden könnten; Richtlinie 2008/114/EG des Rates der Europäischen Union

Es ist also sinnvoll die Bereiche Safety und Security genauer zu differenzieren, auch wenn dieser Unterschied im deutschen Sprachgebrauch nicht offensichtlich ist.

Konflikte von Safety und Security

Wo der Brandschutz einen lebensrettenden Notausgang sieht (Safety), sieht der Sicherheitsberater eine Schwachstelle im Zugangsschutz (Security). Dieses simple Beispiel zeigt den Konflikt, der oft zwischen dem besteht, was im Englischen als Security und Safety unterschieden wird. Im Kern des Konflikts steht die Frage, welche Sicherheit für welche Schutzfunktionen benötigt werden und welche Schutzmaßnahmen notwendige Sicherheitsmaßnahmen untergraben. Die Beschäftigung mit dieser Frage ist notwendig, weil die beiden Seiten oftmals von unterschiedlichen Experten bearbeitet werden. Kommunikation ist notwendig, um die unterschiedlichen Ziele miteinander zu verbinden und Missverständnisse zu vermeiden.

Kommunikation setzt ein gemeinsames Verständnis der Begrifflichkeiten voraus, weshalb wir im Folgenden den Versuch einer Begriffsbestimmung der Sicherheit durch die zwei Begriffe Safety und Security unternehmen wollen. In der Literatur finden sich verschiedene Merkmale, die zur Unterscheidung herangezogen werden.

  1. Unterscheidung nach Schadensursache:
    • Safety als Schutz eines Systems vor zufälligen, nicht-bewusst herbeigeführten Schadereignissen, z.B. Wetterphänomene oder Fehlbedienung.
    • Security als Schutz eines Systems vor bewusst herbeigeführten, zielgerichteten Schadereignissen, z.B. Cyberangriffe.
  2. Unterscheidung nach Art des Schadens und nach Schädigungsrichtung:
    • Safety als Schutz vor Personenschäden, in der Regel durch das betrachtete System.
    • Security als Schutz vor allen Schadensarten am betrachteten System.

Diese Situation ist natürlich unbefriedigend und macht es nötig, dass das Verständnis der Sicherheitsgrundbegriffe neu ausgehandelt werden muss.

Safety und Security nach dem Ursachekriterium

Von Safety sprechen wir, wenn es darum geht Anlagen, Prozesse oder Personen vor Beeinträchtigung durch ungesteuerte, zufällige oder natürliche Ereignisse zu schützen. In diese Klasse fallen Ereignisse die durch „ungewollte Fehlbedienung“ ausgelöst werden, ebenso wie die Beschädigung durch Umweltereignisse wie Erdbeben oder Stürme.

Demgegenüber verstehen wir Security als Verhinderung oder Vermeidung von unerlaubter, absichtlicher Beeinflussung, mit dem Willen zur Schädigung von Werten (Assets). Im Gegensatz zur Safety sind der wesentliche Faktor im Bereich Security die Angreifer (Attacker oder auch Threat Agents), die sich insbesondere dadurch auszeichnen, dass sich ihre Fähigkeiten und ihr Verhalten schlecht vorhersagen lassen. Während es vergleichsweise einfach ist, die erwarteten Sturmereignisse in einer Region historisch aufzuzeichnen, statistisch zu beschreiben und damit zu prognostizieren, ist das Verhalten von Angreifern nicht durch empirische Beobachtung vorhersagbar. Schlimmer noch, es ist anzunehmen, dass, wenn Sicherheitsmaßnahmen auf bekannte Angriffsmuster optimiert werden, sich die Angreifer anpassen und insbesondere die verbleibenden Lücken oder genau die Sicherheitsmaßnahmen selbst angreifen.

Die Definition über die Schadensursache ist für die Planung von Schutzmaßnahmen einfach anzuwenden. Bei der Analyse und Reaktion auf Schadensereignisse ist jedoch gerade dieses einfache Kriterium der bewussten Schädigung schwer zu ermitteln. Denn es erfordert eine Attribution der Schadensursache bzw. Verursacher. Eine eindeutige Attribution ist in einer digitalen Welt aber grundsätzlich nicht möglich. Deshalb ist es sinnvoll, zusätzlich die Definition nach anderen Kriterien zu berücksichtigen.

Safety und Security nach dem Schadenskriterium

Das Kriterium der Schadensrichtung besagt, dass die Unterscheidung sich dadurch ergibt, ob ein möglicher oder tatsächlicher Schaden am betrachteten System oder ein Schaden durch das betrachtete System an einer anderen Sache vorliegt. Der Begriff Safety bezieht sich deshalb auf Schaden, der durch das System selbst entsteht, z.B. einem Zug, dessen Bremssystem versagt. Der Begriff Security bezieht sich auf Schadenswirkung am System.

Das informelle Glossar der Internet Engineering Task Force, welche wesentliche Internet Standards spezifiziert hat, empfiehlt die folgende Definition:

Safety: „The property of a system being free from risk of causing harm (especially physical harm) to its system entities.“ IETF RFC 4949

Sicher, im Sinne von Safety, ist ein System dann, wenn kein Risiko besteht, dass von einem betrachteten System Schaden ausgeht.

Für den Begriff Security werden, je nach Kontext drei unterschiedliche Definitionen angeboten:

  1. Als Zustand wird Security als Ergebnis der Einführung und Aufrechterhaltung von Maßnahmen zum Schutz des Systems verstanden.
  2. Security kann weiterhin als Oberbegriff für genau diese Maßnahmen verstanden werden.
  3. Als Gegenstück zur Safety wird Security analog zur IT-Sicherheit als Zustand in dem ein System frei ist von möglichem Schaden von außen; in Bezug auf die Unmöglichkeit von unautorisiertem Zugang, Veränderung, oder Datenverlust, aber auch zufälligen Schadenseinwirkungen.

Security: „A system condition in which system resources are free from unauthorized access and from unauthorized or accidental change, destruction, or loss.“ IETF RFC 4949

Safety und Security unterscheiden sich auch nach der Art des Schadens. Safety wird immer als ein Schutz vor Personenschäden verstanden, also Verletzung oder Tod von Menschen.

Demgegenüber bezieht sich Security sowohl auf den Schutz vor Personenschäden wie auch vor materiellen und ideellen Schäden. Deshalb ist es sinnvoll, bei Security zusätzlich nach IT Security und Physical Security zu unterscheiden, um besser nach Schadensart differenzieren zu können.

Der Begriff IT-Sicherheit bzw. IT Security oder Computer Security im Englischen kann als Spezialfall der oben definierten Security betrachtet werden. Informationstechnik (IT) ist ein wesentliches Element der aktuellen Veränderungen in Kritischen Infrastrukturen. IT-Sicherheit geht üblicherweise von der Definition des National Institutes for Standards and Technology (NIST) aus. Das NIST definiert Computer Security als die Sicherstellung von Integrität, Geheimhaltung und Verfügbarkeit von Systemen und Daten:

Computer Security: The protection afforded to an automated information system in order to attain the applicable objectives of preserving the integrity, availability, and confidentiality of information system resources (includes hardware, software, firmware, information/data, and telecommunications). NIST Computer Security Handbook, 1995

Der Begriff Physical Security kommt aus dem Militär und bezeichnet im engeren Sinne alle physischen Schutzmaßnahmen gegen unerlaubten Zugriff. Ein vergleichbarer deutscher Begriff ist Objektschutz. Im weiteren Sinne umfasst Physical Security alle Schutzmaßnahmen durch Sicherheitskräfte, auch im nicht-militärischen Bereich wie zum Beispiel durch die Polizei.

Während die IT Security sich überwiegend auf finanzielle Werte bzw. Schäden konzentriert, ist die Physical Security mit finanziellen (Raub), menschlichen (Mord, Verletzung, Entführung, Stalking), ideellen (Rufschädigung, Beleidigung), wirtschaftlichen (Sabotage) und gesellschaftlichen (Terrorismus) Schäden bzw. Werten befasst.

Safety und Security in Cyber-physischen Systemen

Allgemein werden Systeme, die aus verknüpften physischen und digitalen Prozessen bestehen, als Cyber-physisches System bezeichnet. In Cyber-physischen Systemen lässt sich die Beschränkung auf IT Security nicht mehr aufrechterhalten, weil hier grundlegende Eigenschaften von IT-Prozessen und -Artefakten nicht gelten. Zum Beispiel sind physische Assets, anders als Daten, nicht beliebig, nahezu kostenfrei und instantan kopierbar. Auf der anderen Seite sind IT-Prozesse formal rigide, während physische Prozesse regelmäßig Spielräume sowohl bei den Ergebnissen, als auch bei den (menschlichen) Entscheidungen benötigen.

Die Security Cyber-physischer Systeme muss im Vergleich mit IT Security deutlich mehr Schadensarten berücksichtigen, da alle Werte gemäß den oben aufgeführten Definitionen Kritischer Infrastrukturen zu schützen sind. Insbesondere handelt es sich bei Kritischen Infrastrukturen um Anlagen und Systeme, die immer auch menschliche Schäden bewirken können (Safety Schadensart) und daher sowohl gegen Safety wie Security Ereignisse (Ursachen) zu schützen sind.

Dabei können Konflikte zwischen Safety und Security Schutzmaßnahmen kaum vermieden werden. Safety Maßnahmen wie Redundanz oder Notfall-Kontrollsysteme können gerade erst Angriffe ermöglichen. Und IT Security Maßnahmen können potentiell Safety Maßnahmen blockieren.

Während in physischen Prozessen schon durch räumliche Nähe eine grundsätzliche, und flexible Form von Autorisierungsprüfung besteht, sind diese in der digitalen Welt immer formal streng umgesetzt und absolut. Dies führt zum Beispiel dazu, dass der Übergang in einen – wie auch immer gearteten – Notzustand digital schwieriger Umzusetzen ist. Wir wollen das nachfolgend kurz an Beispielen demonstrieren.

Der Zugriff auf Notbremsen ist üblicherweise nicht eingeschränkt. Jede Person, welche sich in räumlicher Nähe befindet (sowie eine minimale Körpergröße und physische Kraft mitbringt) soll eine Notbremsung auslösen können. Eine Autorisierungsprüfung findet nicht statt. Der Vorgang der Notbremsung stellt dazu mit einer hohen Wahrscheinlichkeit sicher, dass die auslösende Person für diese Aktion verantwortlich gemacht werden kann. Bei Notbremsen findet eine Abwägung statt, welche das Missbrauchspotential durch unautorisierte Auslösung einer Notbremsung (Security) gegen den möglichen Schaden eines Feuers oder einer vermeidbaren Kollision (Safety) abwägt. Darüber hinaus ist die Motivation der denkbaren Angreifer für einen Missbrauch sehr gering. In Kombination mit der möglichen Strafhöhe, ist der Missbrauch anscheinend sehr selten.

Eine andere Art der Abwägung findet bei Notrufnummern statt. Obwohl die Missbrauchsrate (Security) der Polizei- und Feuerwehr-Notruftelefonnummern signifikant ist, überwiegt der Nutzen, in prozentual wenigen Fällen, großen Schaden (Safety) verhindern zu können.

Fazit

Schon bei diesen einfachen Beispielen zeigt sich, dass die Anforderungen von Safety und Security nicht einfach in Einklang zu bringen sind und sich Maßnahmen oftmals wechselseitig beeinflussen. Es ist offensichtlich, das insbesondere Schutzmaßnahmen (im Sinne der Safety) gegen Angriffe auf die Verfügbarkeit und Integrität geschützt werden müssen (im Sinne der Security). Schutzsysteme sind regelmäßig selbst „kritisch“ für den Schutz vor Schaden an Leib und Leben oder für den Erhalt kritischer Funktionen. Eine Beeinflussung der Schutzsysteme durch Angreifer ist ein wesentliches Ziel für den Betrieb solcher Anlagen. In diesem Sinne gibt es keine Safety ohne Security.

Security ist wiederum auch kein Selbstzweck. Die primäre Aufgabe kritischer Systeme ist die Versorgung der Gesellschaft mit absolut notwendigen Diensten und Gütern. Das bedeutet aber auf der anderen Seite nicht, dass wir im Namen der Notfallvorsorge auf grundsätzliche Prinzipien und Regeln unserer Gesellschaft verzichten können. Gerade in der Krise und seiner Bewältigung zeigt sich oftmals das wahre Gesicht eines Menschen – und vielleicht auch einer Gesellschaft.

In diesem Wechselspiel der Anforderungen gibt es sicher viele offene Fragen und wenige endgültige Antworten. Dieser Text ist deshalb auch eher als Anfang einer Diskussion zu verstehen, denn als finale Lösung.

Quellen (Auszug aus dem Paper)

Safety and Security

  • Einzige Quelle zu Safety Security in der deutschen WP: Sichere Industrie (nicht wirklich autoritativ)
  • Aircraft Security Glossary (Englisch)
  • BDEW Whitepaper: Definiert Safety = Freiheit von untragbaren Risiken
  • BSI 100-1: Begriff Safety taucht nicht auf
  • BSI 200-1: Definiert und unterscheidet IT-Sicherheit, Informationssicherheit und Cyber-Sicherheit
  • IEC 62351-1:
    • Security
      • A condition that results from the establishment and maintenance of protective measures that ensure a state of inviolability from hostile acts or influences. [JP1]
      • With respect to classified matter, the condition that prevents unauthorized persons from having access to official information that is safeguarded in the interests of national security. [After JP1]
      • Measures taken by a military unit, an activity or installation to protect itself against all acts designed to, or which may, impair its effectiveness. [JP1] [ATIS]
      • All aspects related to defining, achieving, and maintaining confidentiality, integrity, availability, non-repudiation, accountability, authenticity, and reliability. [ISO/IEC 13335-1]
  • EU Directive Critical Infrastructure
    • „essential for the maintenance of vital societal functions, health, safety, security, economic or social well-being of people“
  • Common Criteria
    • „Security is concerned with the protection of assets.“ §192
    • Keine Erwähnung von „safety“
  • RFC 4949
    • $ safety (I) The property of a system being free from risk of causing harm (especially physical harm) to its system entities. (Compare: security.)
    • security 1a. (I) A system condition that results from the establishment and maintenance of measures to protect the system. 1b. (I) A system condition in which system resources are free from unauthorized access and from unauthorized or accidental change, destruction, or loss. (Compare: safety.)

Critical Infrastructure

  • RFC 4949:
    • critical information infrastructure (I) Those systems that are so vital to a nation that their incapacity or destruction would have a debilitating effect on national security, the economy, or public health and safety.

Paper der AG KRITIS: Ohne Safety keine Security in Kritischen Infrastrukturen

#Shitrix: Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern?

/in /von

Seit dem 07.01.2020 hat das CERT-Bund des BSI deutsche Netzbetreiber, die Bundesverwaltung, Betreiber Kritischer Infrastrukturen und andere -Nutzergruppen über verwundbare Citrix-Systeme informiert. Darüber hinaus wurde beispielsweise am 16.01.2020 nochmal verschärft darauf hingewiesen, dass seit dem 10.01.2020 verstärkt Exploit-Code zur Ausnutzung der Schwachstelle veröffentlicht wurde. Trotzdem sind heute immer noch viele Systeme verwundbar und werden aktiv kompromittiert, wie beispielsweise auch die Landeshauptstadt Potsdam und die Stadt Brandenburg!

Wie kann es sein, dass nach Veröffentlichung von Schwachstellen durch Hersteller und Entdecker als auch nach Warnmeldungen vom BSI ein sicherer Betrieb und eine zügige Absicherung der IT-Infrastruktur nicht gewährleistet werden kann? Bis heute sind immer noch viele Systeme ungepatcht.

Um den beschriebenen Herausforderungen auf geeignete Weise begegnen zu können, bedarf es staatlicher Unterstützung, die wir in diesem Beitrag zu politischen Forderungen zur Diskussion stellen möchten.

So kann es nicht weitergehen. Die Politik ist jetzt gefragt, einige wenige, aber sehr notwendige gesetzliche Änderungen durchzuführen.

Politische Forderungen

Was kann der Gesetzgeber aus dem Citrix-Vorfall als auch der kürzlich bekannt gewordenen Krypto-Schwachstelle bei Microsoft lernen und für uns alle verbessern?

Unabhängigkeit des Bundesamt für Sicherheit in der Informationstechnik

Wie einem Mitglied der AG KRITIS vertraulich zugetragen wurde, hätte die Citrix-Sicherheitslücke bereits einige Tage oder Wochen vor der ersten Meldung von Citrix am 17.12.2019 an das BSI gemeldet werden können. Mitarbeiter eines Unternehmens hatten schon früher Kenntnis über die Sicherheitslücke erlangt – entschieden sich aber, diese die Kenntnis der Sicherheitslücke vorerst nicht dem BSI öffentlich zu machen oder zu melden. Mangels Vertrauen, dass diese Erkenntnisse nicht auch an Angreifer oder über das BMI an die Sicherheitsbehörden zur Ausnutzung gelangen würden!

Stellungnahme vom 29.01.2020 zum obigen Abschnitt: Es handelte sich hierbei nicht um eine Meinung des Unternehmens, sondern um eine private Meinung, die in dieser Weise nicht für die Veröffentlichung vorgesehen war. Dafür entschuldigen wir uns nachdrücklich.

Das BSI muss aus den Strukturen des Bundesinnenministeriums herausgelöst werden, um eine unabhängige und defensive IT-Sicherheit in Deutschland zu etablieren. Das BMI ist auch für deutsche Sicherheitsbehörden zuständig, die zwangsläufig aufgrund ihres staatlichen Auftrags den IT-Sicherheitszielen gegensteuern müssen.

Ein unabhängiges und ausschließlich defensiv agierendes BSI kann zum einen das benötigte Vertrauen schaffen, so dass Sicherheitsforscher alle gefundenen Schwachstellen dem Hersteller als auch dem BSI möglichst umgehend bereitstellen. Zum anderen kann es dann wiederum auch konsequent die Entwicklung eines Patches und das ausrollen und installieren bei KRITIS Betreibern als Kunden dieser Hersteller überwachen und sicherstellen. Zur Not auch durch den Einsatz von Bußgeldern und Strafzahlungen, vergleichbar dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit im Rahmen der DSGVO.

Solange dieses Vertrauen nicht hergestellt ist, werden durch Sicherheitsforscher entdeckte Sicherheitslücken nicht konsequent an das BSI gemeldet. Des weiteren wird dadurch auch der Schwarzmarkt zum Handel mit Sicherheitslücken (0days oder zero day exploits) und zugehörigen Exploits zum Ausnutzen der Lücken angefeuert und nicht ausgetrocknet.

Gesetzlich verpflichtendes Patchmanagement

KRITIS Betreiber können häufig nicht ihre eigene Software für Spezialanwendungen schreiben und müssen diese zukaufen. Wir fordern daher neben der Veröffentlichung des Quellcodes, oder aber der treuhänderischen Verwaltung des Quellcodes eine gesetzliche Verpflichtung der KRITIS-Betreiber, Aktualisierungen und Softwareverteilung auf Integrität und Herkunft zu prüfen, aber auch binnen einer vorgegebenen und Bußgeldbewehrten Frist, Empfehlungen und Mindeststandards des BSI umzusetzen. Dies erfordert, dass Hersteller entsprechende Signaturen implementieren. Unsignierte Software, die nicht Open Source ist, und wo sich der Quellcode nicht in treuhändischer Verwaltung befindet, darf im KRITIS-Umfeld unserer Meinung nach nicht eingesetzt werden.

Patches müssen gesichert eingespielt werden können, um einen dauerhaften Schutz der IT-Landschaft zu gewährleisten.

Implikationen für KRITIS durch Schwachstelle in Microsoft Krypto-Bibliothek

/in /von

Update zum Thema: Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern?

Was haben elliptische Kurven, Zertifikate und Windows-Updates mit Kritischen Infrastrukturen zu tun?

Mehr als man zunächst denken mag.

Was ist passiert?

Am 14. Januar 2020 veröffentlichte Microsoft ein Update, das bereits im Vorfeld viel Aufmerksamkeit erhalten hat. Der amerikanische Geheimdienst NSA hatte den Softwarehersteller auf einen Fehler aufmerksam gemacht, sodass die Schwachstelle behoben werden kann.

Bei der Schwachstelle (CVE-2020-0601, auch bekannt als #curveball) handelt es sich um einen Fehler in der Überprüfung von kryptographischen Zertifikaten. Zertifikate werden unter anderem für die Validierung von Softwarepaketen und -updates oder HTTPS-Verbindungen verwendet. Der Fehler ist in einer Microsoft Windows Standardbibliothek entdeckt worden und betrifft daher gleichzeitig auch viele andere Programme. Bei bestimmten kryptographischen Methoden wird ein eigentlich ungültiges Zertifikat als trotzdem gültig gekennzeichnet – eine eigentlich nicht vertrauenswürdige Verbindung, wird vertrauenswürdig oder ein Softwarepaket bzw. Update erhält den Eindruck, es kommt von einer vertrauenswürdigen Quelle. Neben Webseiten und Programmen kommen Zertifikate aber auch bei der Signatur und Verschlüsselung von E-Mails zum Einsatz. Outlook nutzt bei S/MIME Zertifikate – diese können ebenfalls gefälscht werden. Benjamin Deply hat hierzu ein entsprechendes Video veröffentlicht.

Details können der entsprechenden Veröffentlichung der amerikanischen Regierung entnommen werden. Die kryptographischen Details hat Tal Be’ery analysiert. Die Schwachstelle wird auch unter dem Namen ChainOfFools (Zertifikatsketten) oder CurveBall (elliptische Kurven) geführt.

Innerhalb weniger Tage ist von Forschern bereits ein entsprechender Angriff entwickelt und veröffentlicht worden, der fehlerhafte, aber gültige Zertifikate erstellt. Erste Schadsoftware wurde identifiziert, die mit vermeintlich gültigen Zertifikaten signiert worden ist.

Implikationen für KRITIS

Kryptographische Verfahren sind für einige KRITIS Betreiber auf dem ersten Blick eher von nachrangigem Interesse. Bestimmte Branchen wie Banken oder Telekommunikation nutzen Krypto als Teil ihres Geschäftsmodells oder sind bereits seit Jahrzehnten zur Verschlüsselung gezwungen. Es ist davon auszugehen, dass diese Branchen ein erhöhtes Augenmerk auf die oben genannte Schwachstelle haben.

Die Schwachstelle betrifft aber alle Betreiber und Internetanwender – nicht nur die, die Bank- oder Telekommunikationsdaten verschlüsseln. KRITIS Betreiber verwenden natürlich auch das Internet und verschlüsselte Verbindungen für einen gesicherten Datenaustausch. HTTPS (also verschlüsselte Internetverbindungen) beruht auf Vertrauen. Von zentralen vertrauenswürdigen Instanzen werden Zertifikate ausgegeben, die validiert werden können. Auf Basis der Validierung können Betreiber zwischen betrügerischen Webseiten bzw. Angreifern und dem eigentlichen Kommunikationspartner unterscheiden. Diese Validierung ist auf einem ungepatchten und somit anfälligen Windows System nur noch eingeschränkt möglich und es werden ggf. Daten durch einem unbefugten Dritten ausgetauscht oder heruntergeladen.

Zertifikate als Vertrauensanker und die Validierung dieser wird nicht nur bei HTTPS-Verschlüsselung eingesetzt, sondern auch im Umfeld von signiertem Programmcode. Entwickler können entsprechende Signaturzertifikate beantragen, um die Herkunft und Integrität ihrer Software bestätigen zu lassen. Setzen Unternehmen für kritische Geschäftsprozesse auf signierte oder verschlüsselte E-Mails können diese durch gefälschte E-Mail-Signaturen gestört werden.

Falsche Validierung wiederum eröffnet die Möglichkeit eines Supply-Chain-Angriffs. Die Kompromittierung der ukrainischen Softwarefirma MeDoc führte durch manipulierte Updatepakete zu einer der größten Ransomware-Infektionen weltweit. Nutzen nun Lieferanten für Kritische Infrastrukturen entweder keine Signatur oder validieren Betreiber diese unzureichend, so können Angriffe auf KRITIS erfolgen, ohne die Betreiber direkt anzugreifen. Die Schwachstelle erlaubt es einem Angreifer, Software gültig zu signieren, selbst wenn die Software manipuliert wurde.

KRITIS-Unternehmen, die das Microsoft Update nicht eingespielt haben, laufen daher dringend Gefahr, dass schädliche oder manipulierte Software einen legitimen Eindruck macht und deshalb innerhalb ihrer IT-Landschaften ausgeführt wird.

Gegenmaßnahmen

Wie bei fast allen öffentlich bekannt gewordenen Schwachstellen ist die erste Gegenmaßnahme die Evaluierung von Risiken im Patchmanagement-Prozess und anschließend zumeist das zeitnahe Einspielen der verfügbaren Sicherheitsaktualisierungen des Herstellers. Microsoft hat koordiniert aktualisierte Pakete bereitgestellt, die durch Kunden bzw. deren Systemadministratoren installiert werden müssen. Patchmanagement und Systemaktualisierungen in Kritischen Infrastrukturen ist ein sehr komplexes Thema, das an dieser Stelle nicht weiter vertieft werden soll. KRITIS Betreiber nutzen zum Teil weiterhin alte, nicht mehr unterstützte und nicht sichere Software – beispielsweise aufgrund von Legacy Komponenten in der Produktionsumgebung – und setzen sich und anderen damit stärker den Gefahren von Cyber-Angriffen aus.

Zulieferer für Kritischen Infrastrukturen sollten sich ihrer Supply-Chain-Verantwortung bewusst sein. Gerade in so einer Umgebung ist es notwendig, im Rahmen des Patchmanagements Aktualisierungen und Softwareverteilung auf Integrität und Herkunft zu prüfen. Dies erfordert, dass die Hersteller entsprechende Signaturen implementieren, die Betreiber müssen diese Signaturen aber auch auf Gültigkeit prüfen.

Politische Forderungen

Was kann der Gesetzgeber von diesem Vorfall lernen und für uns alle verbessern?

Quellcode Open Source oder in treuhänderischer Verwaltung

Schwachstellen in (insbesondere komplexer) Software können nie ausgeschlossen werden, daher empfiehlt sich immer ein geregeltes Patchmanagement im Rahmen eines etablierten Informationssicherheitsmanagementsystems (ISMS) – wie es auch über § 8a Abs. 1 BSIG als Stand der Technik gefordert und in  branchenspezifischen Sicherheitsstandards (B3S) nach § 8a Abs. 2 enthalten ist. Für sicherheitskritische Komponenten sollten jedoch höchste Standards gefordert und im Idealfall auch überprüfbar gemacht werden.

Durch Open Source oder treuhänderische Verwaltung von Quellcode und ggf. zugehöriger Patente kann die Überprüfbarkeit als auch eine sichere und dauerhafte Weiternutzung der Software gewährleistet werden, sofern der Hersteller irgendwann einmal nicht mehr verfügbar ist (Stichwort Insolvenz). Es sollte nicht dem Zufall oder den Interessen einzelner Institutionen überlassen werden, dass sicherheitsrelevante Software überprüft und weitergenutzt werden kann.

Gesetzlich verpflichtendes Patchmanagement

KRITIS Betreiber können häufig nicht ihre eigene Software für Spezialanwendungen schreiben und müssen diese zukaufen. Wir fordern daher neben der Veröffentlichung des Quellcodes, oder aber der treuhänderischen Verwaltung des Quellcodes eine gesetzliche Verpflichtung der KRITIS-Betreiber, Aktualisierungen und Softwareverteilung auf Integrität und Herkunft zu prüfen, aber auch binnen einer vorgegebenen und Bußgeldbewehrten Frist, Empfehlungen des BSI umzusetzen. Dies erfordert, dass Hersteller entsprechende Signaturen implementieren. Unsignierte Software, die nicht Open Source ist, und wo sich der Quellcode nicht in treuhändischer Verwaltung befindet, darf im KRITIS-Umfeld unserer Meinung nach nicht eingesetzt werden.

Responsible Disclosure von Schwachstellen – verpflichtend auch für Sicherheitsbehörden!

Die Schwachstelle wurde initial durch die NSA an Microsoft gemeldet, sodass eine Fehlerbehebung vorgenommen werden kann. Ein Meldeverfahren zur Behebung von Schwachstellen durch den Hersteller sollte auch für alle deutschen Sicherheitsbehörden verpflichtend vorgegeben sein – werden Schwachstellen an unsere Sicherheitsbehörden gemeldet, durch diese ermittelt oder anderweitig Kenntnis davon erlangt, so dürfen diese nicht für offensive Angriffe verwendet werden, da der Schutz der Kritischen Infrastrukturen im Vordergrund stehen muss. Responsible Disclosure und das Beheben von Schwachstellen trägt wesentlich zu einer sicheren und stabilen digitalen Gesellschaft bei, als das Zurückhalten und Ausnutzen von Schwachstellen.

Ist ein angemessener Schutz von digitalen Cyberwaffen möglich?

Wie lange die Sicherheitslücke dem staatlichen Akteur bekannt war ist nicht öffentlich bekannt. Die vergleichbar kritische Schwachstelle EternalBlue wurde vermutlich von der NSA Spezialeinheit Tailored Access Operations über fünf Jahre lang zurückgehalten und für eigene Angriffe (aktive Cyber-Abwehr oder auch Hack-Back) genutzt. Man hat diese digitale Cyberwaffe mit vielen anderen gehortet aber es nicht geschafft, diese Sammlung so zu sichern, dass kein anderer daran gelangen konnte und eine Sammlung an digitalen Cyberwaffen der NSA sind inzwischen öffentlich gewordenen.

Daher wurden auf Basis dieses NSA-Expoits die Erpressungstrojaner WannaCry und anschließend NotPetya entwickelt, die unter anderen auch die Institutionen Telefónica, FedEx, Deutsche Bahn und Schenker, Sandvik, Beiersdorf, Maersk, Rosneft oder auch Mondelez usw. betroffen und Schäden in Millionenhöhe verursacht haben.

Ransomware lähmt Unternehmen, Verwaltung und Kritische Infrastrukturen

/in /von

Die Meldungen von Institutionen, die teilweise tagelang vom Internet getrennt waren bzw. sich als Maßnahme zur Schadensreduktion selber vom Internet getrennt haben, häuften sich zum Jahresende 2019. Viele der Vorfälle waren auf die Schadsoftware Emotet und die damit in Verbindung stehenden Malware-Familien zurückzuführen. Nach fast zwei Wochen „Urlaub“ ist Emotet zurück und infiziert erneut Institutionen und Privatpersonen auf der ganzen Welt. Selbst ein anschauliches Video einer Infektion der initialen und unsichtbaren ersten Schadsoftware ist verfügbar. Das Perfide daran ist, dass Betroffene erst den Angriff bemerken, wenn die Verschlüsselung bereits begonnen hat. Die Dunkelziffer von Betroffenen, die keine Mitteilung machen, ist vermutlich sehr hoch.

Allein im November und Dezember 2019 waren unter anderem folgende KRITIS-Sektoren durch Emotet-Angriffe betroffen:

  • Staat und Verwaltung
    • Stadtverwaltung Frankfurt
    • Kammergericht Berlin
    • Bundesanstalt für Immobilienaufgaben
  • Gesundheit
    • Klinikum Fürth
    • Universität Gießen
    • Spital Wetzikon (Schweiz)
  • Telekommunikation
    • Everis (Spanien)
  • Medien
    • Rundfunksender Cardena SER (Spanien)
  • Transport und Verkehr
    • RavnAir (USA)
  • Energie
    • Stadtwerke Langenfeld

Eine kontinuierlich gepflegte Liste von Ransomware-Infektionen führt der Twitter Nutzer @GerritOpper.

Ursachen für Ransomware-Infektionen

Als ein Beispiel für eine entsprechende Schadsoftwareinfektion kann die mit Emotet in Verbindung stehende Malware-Familie genannt werden. Diese dringt initial über ein Office-Dokument mit Makros in ein Netzwerk ein. Makros sind aktiver Code, der in Word, Excel und ähnlichen Dokumenten eingebunden werden kann. Derartiger Code wird bereits seit Jahrzehnten für die Verteilung von Schadsoftware verwendet, hat aber in den letzten Jahren eine Renaissance erlebt.

Folgende Ursachen erleichtern diese Art der Infektion:

  • Die Standard-Einstellungen der Microsoft-Produkte ermöglichen das Ausführen von Code in Makros. Die erscheinenden Warnungen sind viel zu unauffällig und werden so vom Benutzer ignoriert. Viele Organisationen wollen diese Standardeinstellungen nicht anpassen.
  • Eine Software-Monokultur fördert die Verbreitung. Mit den Vorteilen der Standardisierung geht der Nachteil einher, dass ein Angreifer ebenfalls Skaleneffekte nutzen kann. Wenn ein Angriff fertig entwickelt wurde, kann er weltweit zum Einsatz kommen.
  • Benutzer wurden nicht oder nur unzureichend für das Thema sensibilisiert. Die Awareness für Gefahren und die Konsequenzen des Zulassens aktiver Inhalte in Office-Dokumenten ist noch ausbaufähig.
  • Die IT-Abteilungen setzen Sicherheitsmaßnahmen nach Stand der Technik nur unzureichend um, Filter für eingehende E-Mails würden in Verbindung mit restriktiven Regeln eine Infektion wirksam verhindern. Die Weiterverbreitung innerhalb der betroffenen Institution wird durch unzureichende Regeln für die IT-Administration erleichtert.

Technische Details und Hintergründe zu Emotet, auch im Zusammenspiel z.B. mit Trickbot und Ryuk sind von Thomas Hungenberg aus dem CERT-Bund des BSI veröffentlicht worden.

Warum sind gerade Krankenhäuser, die öffentliche Verwaltung und Universitäten (nicht KRITIS) betroffen? Die Ursachen sind sicherlich vielfältig. Unter anderem wurde aber in den letzten Jahren so an der IT und dem Personal als auch der Ausbildung selbiger gespart bzw. andere Prioritäten gesetzt, dass ein erheblicher „Schuldenberg“ bezüglich der Umsetzung von Sicherheitsmaßnahmen entstanden ist.

Forderungen für KRITIS

KRITIS-Betreiber sind nach § 8a BSI-Gesetz dazu verpflichtet, Sicherheitsmaßnahmen nach Stand der Technik umzusetzen. In der Praxis erfolgt diese Umsetzung allerdings nur sehr schleppend. Insbesondere auch, weil Sanktionen und eine effektive Prüfung fehlen. Hier müssen andere Kontrollmöglichkeiten als die im Moment üblichen und weitestgehend folgenlosen Überprüfungen (alle zwei Jahre) gefunden werden.

Die Bewältigungskapazitäten sind insgesamt zu gering, wenn sich die Fälle weiter häufen. Institutionen sind schlichtweg überfordert, wenn die gesamte Institution oder Teile davon nicht mehr arbeitsfähig sind. Dies geht aber über gewöhnliche IT-Sicherheit und -Betrieb hinaus. Ein effektives und erprobtes Business Continuity Management muss in der heutigen Zeit zur Steigerung der Resilienz auch den Ausfall von IT-Infrastruktur durch Schadsoftware beinhalten. Wie lange dauert es, Backups wieder einzuspielen wenn die restliche Infrastruktur offline ist? Wenige Organisationen können hier eine belastbare Aussage treffen.

KRITIS Betreiber von schwerwiegender Citrix-Schwachstelle betroffen

/in /von

Update zum Thema: Was kann der Gesetzgeber aus dem Citrix-Vorfall lernen und für KRITIS Betreiber verbessern?

Das zentrale Zugriffsgateway des Herstellers Citrix, welches auch in Leitstellen für Polizei und Feuerwehr, in Krankenhäusern und Stadtwerken, aber auch in vielen Unternehmen zum Einsatz kommt, wird aktuell angegriffen und ausgenutzt. Dabei wird eine im Dezember 2019 bekannt gewordene Sicherheitslücke ausgenutzt, die es erlaubt, beliebigen Schadcode auf den IT-Systemen betroffener Unternehmen und KRITIS-Betreiber auszuführen. Das BSI bestätigt, dass es derzeit aktive Angriffe gegen anfällige Systeme gibt.

Im Dezember 2019, vor 23 Tagen, ist eine schwerwiegende Sicherheitslücke in Citrix Netscaler VPN Gateways bekannt geworden. Diese Schwachstelle erlaubt es einem Angreifer, beliebigen Code auf Systemen auszuführen und anschließend weiter in betroffene Infrastrukturen vorzudringen. Details hierzu wurden von Tripwire veröffentlicht. Der Angriff ist vergleichsweise einfach und entsprechende Angriffswerkzeuge bereits frei verfügbar. Es erfolgt zudem bereits eine aktive Ausnutzung – das heißt, dass anfällige KRITIS Betreiber bereits kompromittiert sein können.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat bereits ab dem 07.01.2020 begonnen, Unternehmen in Deutschland zu informieren. Dennoch sind tausende von Systemen weiterhin anfällig und bieten Angreifern ein mögliches Einfallstor in deren Umgebungen. Zwar konnten seit dem 07.01.2020 bereits über 500 anfällige Systeme geschützt werden, allerdings sind laut BSI über 3.600 Systeme in Deutschland weiterhin anfällig. Unter den Betroffenen sind weiterhin auch Kritische Infrastrukturen.

Eine Recherche in entsprechenden Suchmaschinen für IT-Systeme (z. B. Shodan) ergibt, dass neben Baumarktketten und Automobilzulieferern auch KRITIS Betreiber mit unter denen dabei sind, die keine Gegenmaßnahmen umgesetzt haben. Dazu gehören unter anderem auch:

  • Kreisverwaltungen
  • Landwirtschaftskammern
  • Leitstellen für Polizei und Feuerwehr
  • Krankenhäuser
  • Stadtwerke

Die nachfolgenden Screenshots zeigen detaillierte Systeminformationen von ausgewählten Systemen, die über öffentlich verfügbare Suchmaschinen abgerufen werden können. Eine dieser Suchmaschinen ist Shodan – das Google für IT-Systeme. Diese durchsucht das Internet nach öffentlich erreichbaren Systemen und erlaubt es Benutzern nach bestimmten Attributen zu suchen. So können die anfälligen Systeme und die zugehörigen Organisationen auch einfach den KRITIS Unternehmen zugeordnet werden.

Ciritx Fail 1/3

Ciritx Fail 2/3

Ciritx Fail 3/3

Der Vorfall zu dieser Sicherheitslücke zeigt erneut, dass sowohl auf Seiten der Softwarehersteller, der KRITIS Betreiber und ihrer IT-Dienstleister, als auch bei den Behörden der Umgang mit Schwachstellen weiterhin verbessert werden kann und muss. Solange Betreiber und Behörden mit der Aktualisierung von verwundbaren Systemen hinterherhinken und sowohl Softwarehersteller als auch IT-Dienstleister Schwachstellen nicht umgehend beheben bzw. gar nicht erst erzeugen, solange sind dann eben auch die Angreifer den Verteidigern der Kritischen Infrastrukturen einen Schritt voraus. Ein direkter Zugriff auf wesentliche Anlagenteile in Kritischen Infrastrukturen ist zwar oftmals nicht möglich; sind aber Angreifer in der Lage, in der Umgebung eines KRITIS Betreibers Fuß zu fassen, so kann zumindest indirekt auch auf die Versorgungsleistung und Verfügbarkeit Einfluss genommen werden. Dies zeigen die durch Erpresser vorgenommenen Ransomware-Angriffe und dadurch bedingten Ausfälle auf Stadtverwaltungen, Versorgungsunternehmen, Universitäten und Krankenhäuser in den letzten Monaten.

Das BSI hat zwar betroffene KRITIS Betreiber und Unternehmen informiert, allerdings scheinen entweder die Organisationen und ihre IT-Dienstleister mit der Aktualisierung überfordert zu sein, die Dringlichkeit nicht verstanden zu haben oder die Informationen nicht die richtigen Adressaten gefunden zu haben. Ein sicherer Betrieb unserer Kritischen Infrastrukturen erfordert qualifiziertes Personal sowohl bei Behörden, als auch bei den Betreibern und ihren IT-Dienstleistern. Dies schließt auch ein, Schwachstellen bewerten zu können und zeitnah Korrekturmaßnahmen zu etablieren. Darüber hinaus müssen IT-Betreiber und ihre IT-Dienstleister sich mit der Frage der Haftung konfrontiert sehen. Werden die falschen Personen durch Behörden oder Sicherheitsforscher kontaktiert? Müssen Korrekturmaßnahmen wie Patchmanagement und zugehörige Konfliktpotentiale wie Einhaltung von SLAs in Vertragswerken beim Auslagerungsmanagement (Outsourcing) richtig adressiert werden? Sind aufgrund von Wochenenden oder Feiertagen wichtige Ressourcen nicht verfügbar? Dann müssen KRITIS-Betreiber,  Unternehmen und Behörden ihre Organisationsstrukturen und Maßnahmen überdenken und neu ausrichten.

Nicht nur die direkten Anlagen und Komponenten von Kritischen Infrastrukturen selbst müssen gemäß § 8a BSI-Gesetz nachweislich sicher betrieben werden, sondern auch die Systeme, die für den Zugriff auf die Infrastrukturen genutzt werden, beispielsweise für die Fernadministration. Dazu gehören insbesondere auch mit dem Internet verbundene Büro-Systeme von Administratoren, die einen Zugriff auf wesentliche interne Ressourcen zulassen.

 

Studie warnt: Digitale Souveränität des Staates gefährdet

/in /von

Die vom Bundesministerium des Inneren  beauftragte Studie „Strategische Marktanalyse zur Reduzierung von Abhängigkeiten von einzelnen Software-Anbietern“ findet deutliche Worte über die Abhängigkeit der deutschen Behörden von nur wenigen zentralen Softwareherstellern. Dies gilt insbesondere für Microsoft, da deren Produkte „in allen Schichten des Software-Stacks“ vielfach eingesetzt werden. Dies führe zu „Schmerzpunkten bei der Bundesverwaltung, die im Widerspruch zu den strategischen Zielen der IT des Bundes stehen“. Die Verfasser der Studie kommen zu dem Schluss, dass ein dringender Handlungsbedarf bestehe, da eine eingeschränkte Informationssicherheit und (datenschutz)-rechtliche Unsicherheiten die „digitale Souveränität“ des Staates gefährden.

Eine mögliche Handlungsoption für diese Misere sei der Umstieg auf Open Source Software (OSS). Dies sei ein „probates Mittel“, um die „digitale Souveränität der Bundesverwaltung langfristig zu sichern“.

Die Studie folgt in diesem Punkt unserer Forderung nach Open Source Software in KRITIS, so dass wir als AG KRITIS diese Empfehlung ausdrücklich unterstützen. Insbesondere im Bereich der kritischen Infrastrukturen sehen wir den Einsatz quelloffener Software, bei Bedarf auch unter treuhänderischer Verwaltung, als dringend geboten. Neben der notwendigen Transparenz z.B. im Bereich von Sicherheitslücken oder versteckten Zugängen (Backdoors), kann nur so gewährleistet werden, dass Produktions- und Industrieanlagen über den gesamten Lebenszyklus von teilweise vielen Jahrzehnten sicher betrieben werden können.

Die daraus resultierende Steigerung der Resilienz kritischer Infrastrukturen unterstützt unmittelbar eine defensive Cybersicherheitsstrategie, die der Staat dringend etablieren muss, um seine Bevölkerung angemessen zu schützen.