Artikel von unseren Mitgliedern

weggeWARNttag – Der Warntag2020

/in , /von

Ein gemeinsamer Gastbeitrag von Herbert Saurugg, Andreas Kling, Björn Vetter, Jens von den Berken und unserem AG KRITIS Mitglied Manuel Atug

Der Warntag 2020 und die Abberufung Ungers als Vergrößerungsglas für die seit langem bestehenden Defizite im Bevölkerungsschutz.

Eine unvorbereitete Bevölkerung, Ladehemmungen in der Warnapp NINA und abgebaute Sirenen. Die Konsequenz: der Präsident des Bundesamtes für Bevölkerungsschutz und Katastrophenhilfe (BBK) Christoph Unger wird abberufen. Die Politik sendet mit der Abberufung Ungers das schlechtmöglichste Signal:

Unger hat seit der Neugründung des Bundesamtes 2004 immer wieder, zuletzt vor dem Bundestagsausschuss im Januar 2020, für die Verbesserung der strukturellen Defizite im Zivil- und Katastrophenschutz geworben. Erhört wurden er und das BBK nicht. Die Politik ignorierte die umfangreichen Ausarbeitungen sowie die Erkenntnisse aus der Forschung oder Übungen, wie der Länderübergreifenden Übung (LÜKEX). Daher stellt der nunmehrige Schritt wohl mehr ein Ablenken von den eigenen Versäumnissen dar, als die Bereitschaft, dieses wichtige Thema endlich anzugehen.

Der Warntag scheiterte, weil man sich zu viel vorgenommen hat. Vor allem, da man anscheinend seitens der Politik die Jubelmeldung erwartete: „Alles hat funktioniert, die jahrzehntelange Ignoranz hat sich nicht ausgewirkt.“

Zu erwarten, dass ein System beim ersten Test reibungslos funktioniert, das seit Jahrzehnten nicht angemessen betreut und koordiniert eingesetzt wurde, ist naiv. Daher war genau dieser Test dringend erforderlich, um zu sehen, was funktioniert und wo es noch einen Nachbesserungsbedarf gibt. Mit dem politischen Aktionismus, den Überbringer der schlechten Botschaft zu bestrafen, wird genau das Gegenteil erreicht! Man wird wohl in Zukunft solche Tests und Übungen tunlichst vermeiden, denn es könnte ja den eigenen Kopf kosten. Daher wird man zukünftig lieber schweigen oder schönreden. Ein fatales Signal für die Katastrophenhilfe. Die Folgen wird wiederum die Bevölkerung zu tragen haben.

Der Warntag hat auch einmal mehr den Reibungsverlust durch das Neben- und Gegeneinander von Bund, Ländern und Kommunen sichtbar gemacht. Das BBK ist nach wie vor eine Bundesbehörde mit einer nicht mehr zeitgemäßen Zuständigkeit: ausschließlich für den Spannungs- und Verteidigungsfall. Eine Richtlinien- oder Weisungskompetenz gibt es nicht. Für den Katastrophenschutz sind die Bundesländer und nicht das BBK zuständig, was 16 teils erheblich unterschiedliche Landeskatastrophenschutz-/Brandschutz- und Rettungsdienstgesetze zur Folge hat.

Wobei es hier nicht um ein entweder-oder, sondern um ein sowohl-als-auch gehen soll. Es ist durchaus zweckmäßig, dass es regionale Bestimmungen und Risikobeurteilungen gibt. Aber in einer zunehmend stärker vernetzten und damit wechselseitig abhängigen Welt braucht es auch eine gemeinsame Sicht und Leitlinien, die national abgestimmt und vorgegeben werden.

Ländergrenzenüberschreitende Ereignisse wie Hochwasserlagen, Cyber-Angriffe, Pandemien oder großflächige Strom- und Infrastrukturausfälle erfordern eine übergeordnete Führungsebene. Das ist in sämtlichen Dienstvorschriften in den entsprechenden Behörden und Organisationen mit Sicherheitsaufgaben Standard, endet aber faktisch auf der Landesebene als höchste Instanz.

Die Bundesländer stellen Katastrophenschutzkonzepte auf, die der Bund mit Ausrüstung ergänzt. Den Kommunen obliegt die allgemeine Gefahrenabwehr, also das Tagesgeschäft der Feuerwehren und Rettungsdienste. Oftmals fehlen übergreifende Gesamtkonzepte und Standards, was im Anlassfall auch eine überregionale Zusammenarbeit oder Hilfe erheblich aufwendiger oder sogar unmöglich macht.

So bestimmt beispielsweise in den meisten Ländern im Rahmen der kommunalen Selbstverwaltung jede Gemeinde oder Stadt selbst, welche Fahrzeugtypen, Bekleidung oder Technik die Feuerwehren beschaffen. Vorgaben gibt es hier oftmals nur durch einschlägige DIN-Vorschriften oder durch das Vergaberecht.

Diese Problematik ist seit langem bekannt. Bereits 1967 war im Spiegel zu lesen: „Ämterwirrwarr und mangelhafte Koordination, Fehlbeschaffungen oder Fehlkonstruktionen, parkinsonsche Bürokratie wie technische Typenvielfalt stellen den Erfolg des Bonner Zivilschutzes von vornherein in Frage.“ Es gibt, so tadelte die SPD-Bundestagsabgeordnete Annemarie Renger, „viele Überschneidungen, Doppelarbeit und dadurch unnötige Kosten und leider kein Ergebnis.“ Und der Hamburger Innensenator Heinz Ruhnau spottet, es gebe „für jede Katastrophe einen besonderen Verein“.

Seither gab es offenbar keine wesentliche Verbesserung. Und das, obwohl den Beteiligten und der Politik auch heute diese Themen durchaus bekannt sind. Ein aktueller Antrag der FDP-Fraktion beschreibt vergleichbare Ursachen in knappen Sätzen:

„Eine weitere Schwierigkeit liegt in der Vielzahl der beteiligten Akteure im Rahmen des Bevölkerungsschutzes. So sind neben Bund, Ländern und Kommunen auch zahlreiche Akteure aus Zivilgesellschaft und Privatwirtschaft beteiligt. Diese Vielzahl verschiedener Akteure, deren Konstellation und Aufgabenbereiche sich mit den jeweiligen Krisenszenarien verändern, führt zu Intransparenz und Abgrenzungsproblemen im Rahmen der Aufgabenbereiche.“

Horst Seehofer (CSU) und sein Ministerium für Inneres, Bau und Heimat, das die Fachaufsicht für das BBK innehat, sind ihrer Verantwortung nicht in ausreichendem Maß nachgekommen. Eine Verknüpfung der Themen Bevölkerungsschutz, Ehrenamt und Heimat? Ohne nennenswerte Resultate.

Die bestehenden Ressourcen und Kompetenzen des BBK spielten in der Corona-Pandemie bisher keine relevante Rolle. Der Spiegel titelte dazu gar „das vergessene Amt“.

Die Pandemie hat gezeigt, dass es einer Verbesserung und Anpassung der Zuständigkeiten bedarf. Würden wir diese Defizite aufgreifen und das BBK mit einer besseren gesetzlichen Grundlage ausstatten, könnten wir durchaus am Warntag reifen. Es kam aber alles anders.

„Ein gesamtstaatliches oder gesamtgesellschaftliches Herangehen ist noch nicht erkennbar. […] Es fehlt an verpflichtenden Regeln und Befugnissen, insofern fordere ich an dieser Stelle, dass der Bund, konkret wir das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe eine Zentralstellenfunktion erhalten. [ich möchte Ihnen…] den Wunsch nahelegen, den Bevölkerungsschutz in Deutschland auch durch eine formale Stärkung der Bundeskompetenz langfristig und nachhaltig zukunftsfähig zu machen.“ Christoph Unger, 13.01.2020, Bundestagsausschuss.

Das Warnsignal, das Seehofer mit der öffentlichkeitswirksamen Demission Ungers hier in den gesamten Bevölkerungsschutz sendet, könnte nicht fataler sein. Es lautet: „Wir vernachlässigen den Bevölkerungsschutz, ja. Und wenn ihr Probleme aufzeigt, hören wir auch nicht zu. Wenn ihr dann aber an allseits bekannten Defiziten scheitert, betreffen die Konsequenzen alleine euch und nicht die Politik. Eine Fehlerkultur ist unerwünscht.“

Das im Bevölkerungsschutz zart aufgekommene Pflänzchen namens „Fehlerkultur“ könnte nicht brutaler zertreten werden. Diese können wir für die nächsten Jahre getrost vergessen, denn in Übungen scheitern wird keine Option mehr sein. Als Folge dessen wird sich jeder Verantwortliche sehr genau überlegen, ob und in welcher Form er Übungen überhaupt noch durchführen lassen muss. Auch bei desaströsen Ergebnissen werden wir „Die Übung war ein voller Erfolg“ als Resümee lesen, gepaart von gegenseitigem Schulterklopfen. Ob die Ergebnisse der LÜKEX 2007 „Pandemie“ bei dieser Kultur zustande gekommen wären? Das darf deutlich bezweifelt werden.

Im konkreten Fall des Warntags passierte – basierend auf öffentlich verfügbaren Informationen, denn ein Abschlussbericht liegt noch nicht vor – folgendes: Zeitgleich versuchte eine größere Anzahl von Anwendern wie das BBK, Bezirksregierungen oder Leitstellen, jeweils Warnmeldungen an die Bevölkerung einzuspeisen. Die Einspeisung von vielen berechtigten Benutzern an eine überlappende Anzahl von Warnempfängern überforderte das System. Rechenbeispiel: wenn der Bund alle Nutzer der Warn-App NINA warnen (5 Mio Nutzer, Stand 6/2019, siehe Meldung des BBK), jeweils ein Bundesland alle Nutzer in der Fläche des Bundeslandes warnen und zusätzlich noch diverse Gebietskörperschaften jeweils die Nutzer in der Gebietskörperschaft warnen wollen, dann ergibt dies eine Warnanzahl, die signifikant höher ist als die Gesamtnutzerzahl der App, für die das System ausgelegt ist. Es scheint auch so – und jetzt begeben wir uns auf eine Spekulation – dass es in dem System keine Hierarchie gibt, wonach Warnungen des Bundes priorisiert vor Warnungen der Länder und nachgelagert dann die Gebietskörperschaften behandelt werden. Es war ein selbstgemachter DDoS, basierend auf der Zuständigkeitsverteilung. Dies erklärt zumindest schlüssig, warum unterschiedliche Nutzer der NINA Warn-App zu unterschiedlichen Zeitpunkten gewarnt wurden.

Eine Warninformation darf keine Pull-Information sein, die ein Benutzer aktiv einholen muss. Eine Warninformation muss das Push-Prinzip mit Weckfunktion abdecken. Eine Warn-App, die bei einem Handy im Vibrationsmodus oder im Nachtmodus stumm bleibt, verliert erheblich an Wirkung der Schutzfunktionalität. Die Lücke im System ist der aktive Part des Benutzers, der die Warn-App NINA aktiv herunterladen muss. Der Erreichungsgrad ist noch zu schlecht. Andere Länder nutzen dazu Cell Broadcast, bei dem eine SMS an alle Geräte in einer Netzzelle gesendet wird. Christoph Unger wurde unlängst im Spiegel zitiert, dass man von dieser Möglichkeit der Warnung Abstand genommen habe, da die „Mobilfunknetze – wie man etwa an Silvester sieht – im Fall der Fälle nicht ausreichen“. Darüber hinaus gäbe es Datenschutzprobleme, da auch Bewegungsdaten erfasst würden. Zwischenzeitlich wurde im Spiegel-Artikel diese Aussage richtigerweise durch das BBK nachträglich korrigiert, Stichwort offene Fehlerkultur. Es heißt nun „Cell-Broadcasting wird derzeit aber von keinem deutschen Mobilfunkanbieter angeboten und steht daher zu Zwecken der Bevölkerungswarnung aktuell nicht zur Verfügung.“

Es gibt argumentativ keine Grundlage gegen Cell Broadcast. Es funktioniert technisch in vielen anderen Ländern der Welt einwandfrei, die EU hat entsprechende Weichen mit einer Verordnung gestellt. Gerade dann, wenn die Mobilfunknetze völlig überlastet sind und Daten an Apps wie NINA nicht mehr durchkommen, funktionieren Cell Broadcasts aufgrund der sehr geringen Datenlast noch am wahrscheinlichsten. Die Funktion wird von so ziemlich allen Mobiltelefonen unterstützt, da Cell Broadcasts im amerikanischen, asiatischen und auch im europäischen Absatzmarkt der Gerätehersteller genutzt werden. Der datenschutzrechtliche Einwand, dass Bewegungsdaten erfasst würden, ist nicht haltbar. Im Gegenteil: Bei Cell Broadcasts gibt es keinen Rückkanal – es kann nicht nachvollzogen werden, welches Gerät die Nachricht empfangen hat. Die Telekommunikationsanbieter in Deutschland warten vermutlich nur noch auf eine entsprechende gesetzliche Grundlage. Hier wäre das BMI gefordert, sich aktiv in die Gesetzgebung und die Umsetzung einzubringen. Aber Prävention ist nicht sexy und damit erlangt man offenbar nicht genügend Wählerstimmen.

Das BBK ist aber an der ganzen Sache nicht ganz aus der Verantwortung zu nehmen, denn die Fokussierung auf den Zivilschutz war in den friedlichen Jahren bequem. Die Konzepte des Bundes – als Vorplanung auf den Zivilschutz – gestalten sich oft schwerfällig und wenig detailliert. So sind über Deutschland flächendeckend Fahrzeuge verteilt (Betreuungskombis des Bundes mit Lautsprechereinheiten und Durchsagemodul). Diese wurden aber für den Warntag nicht eingeplant. Es gibt für diese Lautsprecherfahrzeuge auch kein bundesweites Konzept. Man ging im BBK stillschweigend davon aus, dass diese von den Kommunen eingebunden werden. Die Kommunen kennen diese Ressource und die Fähigkeit dieser aber oft nicht – und setzen diese daher auch nicht ein.

Auch gefiel man sich in der Rolle eines forschenden Amtes, dessen eigentlicher Zweck zu unwahrscheinlich erschien. Das BBK betreibt immense Forschungsanstrengungen, hat aber ein Nachhaltigkeitsproblem (Siehe Forschungsvorhaben 5 und 6/ 2020). Die Erkenntnisse aus den vielfältigen Forschungsprojekten und den LÜKEX Übungen kommen in der Fläche nicht an. Der Bevölkerungsschutz in dieser Form ist oftmals ein System ohne Anpassung. Fahrzeuge sind 10-15 Jahre alt und noch im Originalbeladungszustand. Änderungen am Fahrzeug sind nur mittels einem langwierigen und bürokratischen Formänderungsantrag möglich. Es fehlt ein transparenter und kontinuierlicher Verbesserungsprozess, der Erkenntnisse aus Übungen und Einsätzen in die Ausrüstung und Fahrzeuge oder Konzeptionen einfließen lässt. Maximal fließen diese Erkenntnisse in die Neukonzeption der nächsten Fahrzeuggeneration ein.

Die Aufteilung der Kompetenzen sorgt immer wieder für Verzögerungen. So wird seit 2007 an der Konzeption einer Spezialeinheit namens „Medizinische Task Force“ für die medizinische Versorgung bei großflächiger Zerstörung von Infrastruktur gearbeitet. Trotz des englisch klingenden Fachbegriffes ist diese für den internationalen Einsatz nicht vorgesehen und erfüllt keine internationalen Standards wie z.B. der Emergency-Medical-Team (EMT)-Zertifizierung der WHO. Von der MTF sollen in Deutschland 61 Stück aufgestellt werden. Vollständig mit Fahrzeugen ausgerüstet sind 13 Jahre nach Start: Null. Die Abstimmung mit den Bundesländern gestaltete sich schwierig, Nordrhein-Westfalen verglich die Medizinische Task Force mit seinen eigenen Bundeslandkonzepten und sagte „Danke, aber nein Danke“ und entschied sich für eine Sonderlösung.

Ein Wechsel an der Spitze des Bundesamtes für Bevölkerungsschutz und Katastrophenhilfe wird die strukturellen Defizite nicht beheben, wenn diese nicht durch umfangreiche Reformen und der dazu erforderlichen Ressourcenbereitstellung begleitet werden. Nicht zuletzt die fehlende nationale Koordinierungsrolle des BBK muss angegangen werden. Es liegt an der Bundesregierung, insbesondere an Horst Seehofer und dem BMI, hier tätig zu werden. Ohne das Scheitern des Warntags 2020 würde es die Möglichkeit der Verbesserung für einen Warntag 2021 nicht geben – falls dieser nicht durch den designierten Nachfolger von Unger, den CDU-Bundestagsabgeordneten Armin Schuster, still eingestellt wird, um die Karriere nicht zu gefährden. Denn seit 2020 gilt: Wer Übungen macht, riskiert seinen Job. Lerneffekte und Fehlerkultur unerwünscht.

Bundesweiter #Warntag2020

/in /von

Gut, dass die bundesweite Warnung der Bevölkerung nach ca. 30 Jahren wieder getestet worden ist. Es wäre fatal, wenn erst im Ernstfall feststellt wird, dass dies nicht wie vorgesehen funktioniert.

Viele Mitglieder der AG KRITIS zeichnen sich auch dadurch aus, dass sie aus eigenem Engagement in Hinblick auf den Bevölkerungsschutz sehr interessiert an frühzeitigen Warn- und Katastrophenmeldungen sind. Um 11:00 Uhr war es heute deshalb etwas ernüchternd, statt Warnmeldungen das Scheitern des Modularen Warnsystems (MoWas) zu erleben.

Ein kurze, nicht-repräsentative Umfrage in der Runde hat ein eher ruhiges Bild gezeichnet. In Bundesländern wie Bremen und Städten wie München und Berlin, in denen die Sirenen vor Jahren schon abgebaut wurden, blieb es erwartungsgemäß ruhig. Aber auch die Warn-App Nina des BBK hat sich nicht bemerkbar gemacht. Immerhin hat sich KatWarn mindestens an einer Stelle gemeldet. Auch in Bundesländern und Städten mit Sirenen, deren sonntäglicher Test regelmäßig erfahrbar ist, hat sich heute um 11 nicht immer ein Warnton eingestellt.

Eine Warnung direkt über Nachrichten im Mobilfunknetz, mittels Cell Broadcast wurde im deutschen Mobilfunknetz überhaupt nicht erst eingerichtet, hätte also auch nicht der Teil des bundesweiten Tests sein können, der großflächig funktioniert. Wir möchten da durchaus den Hinweisen aus dieser Diskussion auf Twitter zustimmen. Katastrophenwarnungen gehören nicht in einen großen Softwarestapel in einer App verbuddelt.

Ein bisschen Überraschung gab es dann vereinzelt noch über die Entwarnung, die Nina dann an vielen Stellen erfolgreich verteilt hat. Auch, wenn die Entwarnung dann auf eine „unvorbereitete Bevölkerung“ (Zitat Christoph Unger, Präsident des BBK) traf. Leider hat der bundesweite Test der Warninfrastruktur aber auch eine unvorbereitete Warninfrastruktur erwischt.

Sehen wir das ganze mal konstruktiv: wir freuen uns, dass der Test Defizite aufgezeigt hat, die jetzt behoben werden können, um für den Ernstfall gewappnet zu sein. Dafür sind Krisenübungen und Tests von Anlagen und Systemen ja auch da. Wer nicht übt, bemerkt auch keine Defizite. Insofern ist dies ein gutes Resultat, wenn das After Action Review und die Lessons Learned konsequent angegangen und die Defizite strukturiert eliminiert werden.

Daher warten wir dann jetzt mit Spannung auf den offiziellen Fehlerbericht.

BMI gefährdet die Umsetzung des Onlinezugangsgesetzes

/in /von

Das Bundesministerium des Inneren für Bau und Heimat (BMI) hat es versäumt, eine wichtige Rechtsverordnung zu erlassen – entsprechend ist es möglich, dass die bisher entwickelte Software zur Digitalisierung der staatlichen Verwaltung neu entwickelt werden muss.

2017 hat sich die Bundesregierung zum Ziel gesetzt, innerhalb von 5 Jahren alle Dienstleistungen aller Behörden zu digitalisieren. Das Ziel ist, das Bürger zukünftig alle Verwaltungsdienstleistungen auch von zu Hause aus per Internet erreichen können. Aus diesem wichtigen Ziel folgte ein Gesetz – das sogenannte Onlinezugangsgesetz. Dort findet sich der wichtige Paragraph 5.

§ 5 IT-Sicherheit

Für die im Portalverbund und für die zur Anbindung an den Portalverbund genutzten IT-Komponenten werden die zur Gewährleistung der IT-Sicherheit erforderlichen Standards durch Rechtsverordnung des Bundesministeriums des Innern, für Bau und Heimat ohne Zustimmung des Bundesrates festgelegt. (…)

Unser Mitglied clarity hat eine Anfrage (nach Informationsfreiheitsgesetz) über Fragdenstaat.de gestellt, um genau diese Rechtsverordnung einsehen zu können. Die Anfrage findet sich hier. Die IFG-Anfrage förderte zu Tage, dass diese Rechtsverordnung, in der beschrieben wird, welche IT-Sicherheits-Standards für die IT-Komponenten der digitalen Verwaltung gelten sollen, bisher nicht erlassen worden ist. Auch einen Entwurf dazu gibt es bisher nicht.

 

Die Umsetzung des Onlinezugangsgesetzes geschieht nach dem Prinzip „Einer für Alle“ – jedes Bundesland soll einen der Lebensbereiche komplett digitalisieren und die so entstandene Software den anderen Ländern zur Verfügung stellen. Die meisten Länder haben bereits angefangen und geben sich große Mühe, die Versäumnisse der letzten 20 Jahre im Bereich eGovernment unter Hochdruck nachzuholen.

Aus einigen Ländern und Kommunen hört man bereits jetzt, das man an der fristgemäßen Umsetzung zweifelt, da die Entwicklung langsamer voranschreitet als geplant.

Bei der Digitalisierung der Verwaltungsdienstleistungen müssen ebenen-übergreifende Verknüpfung geschaffen werden, denn notwendige Daten liegen sowohl in den Kommunen, den Ländern aber auch beim Bund. Es ist technisch eine immense Herausforderung, Software zu entwickeln, die unserem Föderalismus gerecht wird, denn zugegriffen wird hier auf sämtliche bei Bund, Ländern und Kommunen vorliegenden Informationen. Wenn Sicherheit in diesem komplexen System erst nachträglich implementiert werden muss, kann dies sehr aufwendig oder sogar unmöglich sein. Eine gute Konzeption (Privacy by Design), die sich intensiv mit Verschlüsselung, Zugrifftokens und den Nutzern befasst, wäre daher sinnvoller als eine spätere Nachrüstung der Sicherheit.

Die gemeinsamen IT-Sicherheits-Grundsätze dieser drei Ebenen, dem Bund, der Länder und den Kommunen, fehlen jedoch nicht nur im OZG, sondern auch an anderen Stellen. Bei kritischer Infrastruktur werden die Anforderungen an den Sektor Staat und Verwaltung auf Bundesebene durch den sogenannten Umsetzungsplan Bund (UP Bund) festgelegt. Die notwendigen Regelungen für Länder und Kommunen treffen die Länder selbst, aber auch diese Regelungen fehlen bisher. Die Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung des IT-Planungsrates ist immerhin verbindlich für Bund und Länder – für Kommunen ist sie aber leider nur empfehlend.

Der Sektor „Staat und Verwaltung“, und damit auch manche Teile der Verwaltung, die bürgernahe Verwaltungsdienstleistungen erbringen, fallen auch unter die kritischen Infrastrukturen, auch wenn in diesem Sektor die Kritis-Verordnung nicht anwendbar ist. Umso wichtiger ist es, dass der Staat bei Softwareprojekten in diesem Bereich höchste Sorgfalt walten lässt, den Stand der Technik beachtet und IT-Sicherheit von Anfang an mitdenkt.

Das Onlinezugangsgesetz (OZG) trat am 18. August 2017 in Kraft. Es regelt, dass bis zum 31.12.2022 die Umsetzung abgeschlossen sein muss. Der Gesetzgeber hat den Ländern also 1961 Tage oder auch 5,37 Jahre gegeben, die 578 Verwaltungsdienstleistungen, geteilt in 14 sog. „Lebensbereiche“ digital abzubilden.

Nun sind von den 1961 Tagen Projektdauer bereits 1115 Tage (Stand 06.09.2020) verstrichen. Das sind 56,8% der gesamten Projektdauer, ohne das festgelegt wurde, welche IT-Sicherheits-Standards beachtet werden sollen. Selbstverständlich haben die Länder und die Kommunen bereits angefangen, Software zu entwickeln.

Es ist zu befürchten, das ein Großteil dieser bisher geleisteten Arbeit der Länder und Kommunen „für die Tonne“ ist – denn wie sollen sich Softwareentwickler an Standards halten, wenn nicht feststeht, welche Standards das sind?

Durch das Versäumnis des Bundesministerium des Inneren (BMI) diese Rechtsverordnung zu Projektbeginn zu erlassen, droht nun das Projekt zu scheitern, denn eine jahrelange Verzögerung dieses mehr als überfälligen Projekts wäre nichts anderes als ein Scheitern.

Da bereits mehr als die Hälfte der Projektdauer verstrichen ist, ohne das die notwendigen Standards festgelegt wurden, ist eine fristgemäße Fertigstellung der digitalisierten Verwaltungsdienstleistungen mehr als unwahrscheinlich geworden.

Es ist daher dringend notwendig, dass diese Rechtsverordnung nun zügig erlassen wird. Bundesminister des Inneren Horst Seehofer muss nun dafür sorgen, das trotz des Versäumnisses seiner Behörde, das Prinzip „Security by Design“ eingehalten wird. IT-Sicherheit darf kein nachgerüstetes Feature sein, sondern muss von Anfang an in jeder Architektur und jeder Entscheidung mitgedacht werden.

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

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.