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

Logbuch Netzpolitik 331: Kritische Infrastruktur – LNP-Spezial zu Kritischer Infrastruktur, die AG KRITIS und das Cyber-Hilfswerk

/in /von

@timpritlove hat im Podcast @me_netzpolitik mit unseren beiden Mitgliedern @HonkHase und @ijonberlin Kritischer Infrastruktur, die AG KRITIS und das Cyber-Hilfswerk besprochen.

„Im Nachgang zur DefensiveCon (Aufzeichnungen aller Vorträge), einer auf die Probleme der Sicherung von Kritischer Infrastruktur im digitalen Zeitalter fokussierten Konferenz der @AG_KRITIS, spricht @timpritlove heute mit den Leitern des Projekts, @ijonberlin und @HonkHase über ihre Themen. Dabei definieren wir zunächst den Begriff KRITIS und diskutieren, welche realen Bedrohungen kritische Infrastruktur heutzutage und künftig ausgesetzt ist und sein wird. Abschließend stellen die beiden ihre Idee eines Cyber-Hilfswerks vor, das inspiriert vom Gedanken des Technischen Hilfswerks (THW) eine zivile Organisation zur Abmilderung digitaler Katastrophenfälle postuliert.“

Den vollständigen @me_netzpolitik Podcast „LNP331 Kritische Infrastruktur“ mit @HonkHase und @ijonberlin findet ihr hier:

Podcast Logbuch Netzpolitik

Heise: Arbeitsgruppe KRITIS will Cyber-Hilfswerk für IT-Katastrophenfälle gründen

/in /von

Heise hat einen Überblick über die AG KRITIS und das Cyber-Hilfswerk veröffentlicht.

„Die AG KRITIS will ehrenamtliche Helfer zu IT-Notfalleinsätzen in Kritische Infrastrukturen schicken. Bundesbehörden zeigten sich vom Konzept interessiert.“

Der vollständige Artikel bei Heise findet sich hier:

Artikel von Heise

Spiegel: Hacker wollen Cyber-Hilfswerk gründen

/in /von

Spiegel hat ein Interview mit unserem Mitglied @ijon über die AG KRITIS und insbesondere das Cyber-Hilfswerk veröffentlicht.

„Sollten Deutschlands kritische Infrastrukturen von Hackern lahmgelegt werden, gäbe es zu wenige Katastrophenhelfer, sagt @ijon. Zusammen mit anderen Aktivisten will er eine Art Cyber-THW aufbauen.“

Der vollständige Artikel bei Spiegel findet sich hier:

Artikel von Spiegel

Vorstellung des CHW-Konzepts auf der DefensiveCon

/in /von

Am 07.02.2020 haben wir unser Konzept zur Steigerung der Bewältigungskapazitäten in Cyber-Großschadenslagen auf der DefensiveCon in Berlin vorgestellt.

Ergebnisprotokoll des ersten Behördenworkshops zum Cyber-Hilfswerk (CHW)

/in /von

Am 02.10.2019 haben wir uns mit Vertretern des Bundesamt für Sicherheit in der Informationstechnik (BSI) und mit Vertretern des Bundesamts für Bevölkerungsschutz und Katastrophenhilfe (BBK) getroffen und unsere Ideen gemeinsam diskutiert.

Besprochen wurde in dem Fachgespräch auf Arbeitsebene das Thema der Bewältigung von Großschadenslagen, die durch Cyber-Vorfälle entstehen können. Unsere Idee eines „Cyber-Hilfswerk“ (CHW – aktueller Arbeitstitel) wurde gemeinsam diskutiert und ins Rollen gebracht.

Zu Beginn der Veranstaltung haben wir zwei Impulsvorträge gehalten – „Vorstellung der Arbeitsgruppe Kritische Infrastrukturen“ von @ijonberlin und „Was könnte ein CHW leisten?“ von @Jedi_meister, der Rest der Veranstaltung wurde nicht gefilmt, aber protokolliert.

Das detaillierte Ergebnisprotokoll der Veranstaltung wurde von uns erstellt und an die Teilnehmer versandt. Auch für euch stellen wir es hier zur Einsicht bereit.

AG KRITIS Ergebnisprotokoll Behördenworkshop 20191002

 

Die Aufzeichnungen zu den beiden Impulsvorträgen findet ihr hier:

Vorträge im Rahmen des ersten Behördenworkshops

Deutschlandfunk Kultur Breitband: Überleben im digitalen Winter

/in /von

@neuspreeland von @dlfkultur hat in ihrem Podcast @breitband den „digitalen Winter“ vom Australier Paul Gardner-Stephen auf dem 36c3 des CCC thematisiert und vor Ort auch unsere Expertise zu Kritischen Infrastrukturen und ganzheitlichen Lösungsansätzen besprochen und diese im Podcast mit eingebracht.

„…Eigentlich brauche es so etwas wie eine freiwillige Feuerwehr, ein „digitales THW”, sagt
@HonkHase von der @AG_KRITIS…“

Den vollständigen @breitband Podcast „Überleben im digitalen Winter“ mit unserem Mitglied @HonkHase findet ihr hier:

Podcast Breitband Überleben im digitalen Winter

#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.