Von wegen Sommerloch! Irgendwie war viel los im Juli. Besonders viel Lesestoff gibt es in diesem Monat, wenn Sie Betreiber kritischer Infrastrukturen sind oder - unwahrscheinlicher - einfach allgemein total gern Gesetzestexte lesen.
Wir haben aber auch was für Schwachstellengeplagte und ein Update zu den Secure Coding Practices für SPSen.

Bevor Sie sich zurücklehnen und losschmökern, schicken Sie noch schnell Ihren Beitrag für Security unter Kontrolle raus! Der ist nämlich diese Woche fällig.

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. KRITIS: Systeme zur Angriffserkennung gemäß IT-Sicherheitsgesetz
2. KRITIS: Dokumentation des Geltungsbereichs
3. KRITIS: Registrierungspflicht und Definition kritischer Komponenten für den Sektor Energie
4. Datenmodelle für den Schwachstellendschungel (CSAF und SBOM)
5. Ein Jahr Top 20 Secure PLC Coding Practices: Missverständnisse und Visionen
6. Call for Contributions für Security unter Kontrolle: Endspurt!

1. KRITIS: Systeme zur Angriffserkennung gemäß IT-Sicherheitsgesetz

Liebe Schutzhelmfreunde, es wird Zeit, eine neue Abkürzung zu lernen. Systeme zur Angriffserkennung kürzt das BSI in seiner Orientierungshilfe, die nun als Entwurf erschienen ist, nämlich selbstverständnlich ab: SzA.

Was bisher geschah: Während das IT-Sicherheitsgesetz in vergangenen Fassungen stets die recht neutrale Formulierung "Maßnahmen gemäß Stand der Technik" verwendet hat, gab es in der neuesten Fassung erstmals die Verpflichtung auf eine bestimmte Technologie - ebendiese Systeme zur Angriffserkennung, die KRITIS-Betreiber nun ab 1.5.2023 einsetzen müssen.
Was genau damit gemeint ist, dafür hat das Gesetz auf ein noch vom BSI zu veröffentlichendes Dokument verweisen. Und voilà - hier ist es (Lesestoff). Allerdings ist das Dokument erst einmal ein öffentlicher Entwurf, der noch kommentiert werden darf.

Die Orientierungshilfe teilt die Anforderungen an die SzA in drei Häppchen auf: Protokollierung, Detektion und Reaktion. Protokollierung bedeutet, dass fortlaufend Informationen gesammelt werden müssen. Detektion bedeutet, dass auf Basis dieser Informationen sicherheitsrelevante Ereignisse erkannt werden müssen. Reaktion bedeutet, dass technisch oder organisatorisch auf diese Ereignisse reagiert werden muss.

Die Orientierungshilfe umfasst 22 recht schlanke, gut lesbare Seiten. Einige weitere Notizen zu den Inhalten:

• Scope: Der Einsatz der SzA muss alle "Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der von ihnen betriebenen Kritischen Infrastrukturen maßgeblich sind" abdecken. Es werden explizit auch OT und Embedded Systems mit einbezogen. Das ist sportlich, denn Logging und Auswertungsfunktionen für die feldnahen OT-Komponenten gehören nicht gerade zur Standardausstattung dieser Systeme. Die "eierlegende Wollmilchsau", die die Protokollierung und Auswertung für den Zoo an verschiedenen Automatisierungskomponenten, die in KRITIS so üblich sind, komplett abdeckt, muss wohl noch erfunden werden. Das Problem ist hier oft, dass eine Monitoring-Lösung verschiedene proprietäre Protokolle sprechen muss, um den Datenverkehr zwischen OT-Systemen inhaltlich auszuwerten. Alle Protokolle abzudecken, ist schwierig.
• Die Reaktion muss nicht technisch erfolgen: Das ist eine wichtige Beobachtung. Oft wurde (vor allem von Herstellern einschlägiger Systeme) nach der Veröffentlichung des IT-SiG spekuliert, es seien auf jeden Fall Intrusion Prevention Systeme (IPS) notwenig, Intrusion Detection Systeme (IDS) würden nicht reichen. Grund: Ebenjene Verpflichtung zur Reaktion. Die muss aber gemäß der nun erschienen Orientierungshilfe explizit nicht technisch erfolgen. Also: technisches Monitoring-System und organisatorische Reaktion auf Ereignisse wäre auch ok. Es müssen dann aber Ressourcen für die organisatorische Reaktion eingeplant werden, schreibt die Orientierungshilfe.
  Das ist durchaus auch eine Chance für KRITIS-Betreiber. Denn auf diesem Wege muss für die Compliance mit dem IT-SiG nicht einfach nur Papier produziert und Blech angeschafft werden, sondern es müssen Menschen eingestellt werden - wahrscheinlich die aussichtsreichste IT-Sicherheitsmaßnahme in vielen - vor allem kleineren - KRITIS-Betrieben.
  ABER: Eine SOLLTE-Anforderung enthält die Forderung nach automatisierten Reaktionen des SzA. Wenn man dies nicht umsetzt, muss man es also gut begründen (siehe Nachweiserbringung).
• Auswirkungen für B3S: Die Orientierungshilfe ist branchenübergreifend. Für branchenspezifische Informationen verweist sie auf das aus BSI-Sicht bewährte Konstrukt der branchenspezifischen Sicherheitsstandards (B3S). Die müssen in Zukunft Vorgaben für SzA enthalten. Also, an alle B3S-Nutzer: Sie erwartet eine neue Runde an Aktualisierungen. Und eine erneute Warteschleife, bis endlich klar ist, was SzA nun eigentlich bedeutet.
  (Erinnerung an dieser Stelle: KRITIS-Sektoren, für die es einen B3S gibt, sind nicht verpflichtet, diesen zu nutzen).
• Konzeption der Lösung: Die Anforderungen in der Orientierungshilfe legen einen Fokus auf die Planung der SzA. Klar: Anhand einer gut dokumentierten Planung für SzA kann man solche Systeme am besten auditieren. Natürlich ergibt das Planen vor der Einführung eines so umfangreichen technischen Systems aber auch davon unabhängig Sinn und die Anforderungen geben dazu auch wertvolle Hinweise, etwa auf MITRE ATT&CK als Methode für die Planung der Detektion.
• Nachweiserbringung: Für den Nachweis, dass KRITIS-Betreiber SzA gemäß Orientierungshilfe eingesetzt haben, gibt es ein Reifegradmodell. "Reifegradmodell" ist dabei die fancy Umschreibung für "wenn ihr die Systeme wenigstens schon mal geplant habt, ist es besser als nichts".
  Aber: Angestrebt ist die verpflichtende Umsetzung aller MUSS-Anforderungen aus der Orientierungshilfe, und die Umsetzung aller SOLLTE-Anforderungen - außer, sie werden begründet ausgeschlossen (Reifegrad 4). Im ersten Überprüfungszyklus, also ab 2023, reicht aber auch die Umsetzung aller MUSS-Anforderungen aus (Reifegrad 3).
  Das ist bis in einem guten halben Jahr zumindest sportlich. Für das Kleingedruckte (in begründeten Ausnahmefällen sind Abweichungen nach unten möglich) gilt daher wohl wie bislang für KRITIS-Prüfungen: Man wähle seinen Prüfer mit Bedacht.

Technisch tiefergehende Hilfen, was für Systeme zur Angriffserkennung es gibt (oder gar welche Hersteller), liefert das BSI-Papier erwartungsgemäß nicht.
Aber es gibt ja durchaus noch weitere Quellen, von denen Hilfe naht - zum Beispiel ist vonseiten der NAMUR (und mit BSI-Beteiligung) ein Papier in Arbeit, das verschiedene Methoden der Angriffserkennung gut strukturiert und praktisch hilfreich aufbereitet und erklärt.

2. KRITIS: Dokumentation des Geltungsbereichs

Und nochmal kritische Infrastrukturen: Das BSI hat außerdem ein Papier "Zur Dokumentation des Geltungsbereiches bei KRITIS-Betreibern" veröffentlicht (Lesestoff). Es trägt den Untertitel "Erfahrungen aus den Nachweisen gemäß § 8a Absatz 3 BSIG – Hilfestellung und Beispiel" und hält, was es verspricht. Wer sich mit der Geltungsbereich-Dokumentation seiner kritischen Infrastrukturen schwer tut, findet hier eine brauchbare Anleitung inklusive Beispiel.

Wer mit seinem Geltungsbereich bislang immer hervorragend durch die §8a-Nachweise gekommen ist, kann das Papier wahrscheinlich guten Gewissens zu den Akten legen. Allerdings, wie es immer so ist mit Hilfestellungen für Nachweise: Das sind auch Hilfestellungen für Prüfer. Gut möglich also, dass sich Ihr Prüfer in der nächsten §8a-Prüfung an diesem neuen Papier orientiert. Zumindest ein Querlesen ist daher empfehlenswert.

3. KRITIS: Registrierungspflicht und Definition von kritischen Komponenten für den Sektor Energie

So, das letzte mal Gesetztesstaub für heute, versprochen. Dieses Mal geht es um das Energiewirtschaftsgesetz (EnWG). Mein Kollege (und Jurist) Peter Breidbach hat die Änderungen für Sie zusammengefasst:

1. Registrierungspflicht beim BSI nun auch für den KRITIS-Sektor Energie
   Registrierungspflicht beim BSI nun auch für den KRITIS-Sektor Energie Das EnWG betrifft Betreiber von Energieversorgungsnetzen und Betreiber von Energieanlagen, die die Schwellenwerte der BSI-KritisV überschreiten. Mit Wirkung zum 29.07.22 wurde das Gesetz im Rahmen des „Gesetz zur Änderung des Energiewirtschaftsrechts im Zusammenhang mit dem Klimaschutz-Sofortprogramm und zu Anpassungen im Recht der Endkundenbelieferung“ unter anderem im Security-relevanten § 11 abgeändert (Gesetzestext siehe Lesestoff 1).
   Betroffene Betreiber sind nach dem neu gestaltetem § 11 Abs. 1d nun „verpflichtet, spätestens bis zum 1. April jeden Jahres, die von ihnen betriebene Anlage beim Bundesamt für Sicherheit in der Informationstechnik zu registrieren und eine Kontaktstelle zu benennen“.
   Das EnWG zieht damit mit den Regelungen des BSIG für Kritische Infrastrukturen gleich, welches bereits zuvor eine Registrierungspflicht vorsah.
   Betreiber von Energieanlagen, die erst mit der Herabsenkung der Schwellenwerte auf 104 MW zum 01.01.2022 zu den Kritischen Infrastrukturen zählen, haben sich also spätestens bis zum 01.04.2023 beim BSI zu registrieren. Denn die BSI-KritisV sieht vor, dass Betreiber von Energieanlagen bei einer erstmaligen Überschreitung der Schwellenwerte erst zum 01.04. des folgenden Kalenderjahrs als Kritische Infrastruktur gelten. Folglich greifen auch erst dann die o.g. neuen Regelungen.
2. Weiterer Sicherheitskatalog für kritische Komponenten
   Weiterer Sicherheitskatalog für kritische Komponenten Eine weitere gesetzliche Änderung, die ebenfalls den Energiesektor betrifft, lag bereits im Mai diesen Jahres. Im „Gesetz zur Änderung des Energiesicherungsgesetzes 1975 und anderer energiewirtschaftlicher Vorschriften“ wurden ebenfalls Ergänzungen am § 11 EnWG vorgenommen (Gesetzestext s. Lesestoff 2). Dieses Mal ging es um die Festlegung von den sogenannten kritischen Komponenten. Demnach haben BSI und Bundesnetzagentur nun die Hausaufgabe, bis zum 22.05.2023 einen Katalog von Sicherheitsanforderungen für das Betreiben von Energieversorgungsnetzen und Energieanlagen festzulegen, der bestimmt, welche Komponenten und welche Funktionen als kritisch einzustufen sind.
   Zur Erinnerung: Das Konzept der kritischen Komponenten und Funktionen wurde bereits im Rahmen des IT-Sicherheitsgesetz 2.0 eingeführt. Ihr Einsatz ist dem Bundesinnenministerium anzuzeigen und ein solcher kann unter bestimmten Umständen, beispielsweise bei Bezug kritischer Komponenten von nicht vertrauenswürdigen Herstellern, untersagt werden.
   Bisher wurden solche Komponenten lediglich für den Sektor Telekommunikation definiert.

4. Datenmodelle für den Schwachstellendschungel (CSAF und SBOM)

Über das hier könnte man Romane schreiben, aber wir halten es heute mal kurz und bündig: Die Version 2.0 des Common Security Advisory Framework (CSAF, Lesestoff 1) ist Ende Juni veröffentlicht worden. Das BSI hatte daran mitgewirkt, wie Jens Wiesner unter anderem im seinem Vortrag bei der diesjährigen S4 erklärt hat (das Video dazu ist noch nicht online).

Die Vision von CSAF ist, dass die vielen verschiendenen Security Advisories, mit denen Hersteller Informationen über Schwachstellen in ihren Produkten publik machen, endlich einheitlich und automatisiert verarbeitbar bereitgestellt werden. Wer sich mit Schwachstellenmanagement in der OT befasst, weiß: Das wäre ein Riesending und eine gewaltige Arbeitserleichterung. Bislang bedeutet Schwachstellenmanagement nämlich meist: Man lädt händisch Informationen von Dutzenden Herstellern in ebensovielen Formaten herunter und versucht, die für sich relevanten Informationen darin zu finden.

Und tatsächlich gibt es bereits einige Hersteller, die Advisories im CSAF-Format anbieten: Siemens, Schneider Electric, Redhat und SICK zum Beispiel. Das ist ein großer Erfolg.

Im US-amerikanischen Raum ist das Buzzword zum selben Thema übrigens nicht CSAF, sondern SBOM. Die Software Bill of Materials soll strukturiert alle in einer Software "verbauten" Komponenten auflisten (ebenfalls automatisiert auswertbar natürlich) und damit ebenfalls den Überblick über Schwachstellen und notwendige Updates erleichtern.
Dale Peterson hat sich mit dem Thema ausführlich befasst und nun eine Marktanalyse zum Thema veröffentlicht (Lesestoff 2). Eine neue Abkürzung kann man da auch lernen: Ein "VEXie" ist die maschinenlesbare Information darüber, ob eine Schwachstelle, die in einem SBOM identifiziert wurde, ausnutzbar ist.

Noch in Singapur hat Dale erzählt, dass in den USA SBOMs das Buzzword schlechthin in der OT-Security momentan sind. Hierzulande sind die Themen Patchen und Advisories ebenfalls auf der Tagesordnung. Das Ganze ist eigentlich "nur" ein Digitalisierungsproblem, oder genauer gesagt, ein Datenmodellierungsproblem. Wir brauchen ein einheitliches Format für die Verarbeitung von Schwachstellen und Patches, das maschinenlesbar, maschineninterpretierbar und maschinenverarbeitbar ist.

Wie immer, wenn es um Datenmodelle geht, wird am Ende nicht zwangsläufig das beste oder schönste Modell das Rennen machen, sondern das, was die meisten benutzen. Der Ausgang ist wohl noch offen.

5. Ein Jahr Top 20 Secure PLC Coding Practices: Missverständnisse und Visionen

Im Juli war ich in Singapur, als Teil des OT Cybersecurity Expert Panels der Singapore Cybersecurity Agency (CSA). Die CSA ist so etwas wie das BSI für Singapur. Es gibt sie noch keine zehn Jahre, aber in dieser Zeit ist einiges aus dem Boden gestampft worden - unter anderem die Gesetzgebung für die Singapurer kritischen Infrastrukturen.

Für das Juli-Event hatte mich die CSA gebeten, über die Top 20 Secure PLC Coding Practices zu sprechen. "Die Top 20", wie sie mittlerweile liebevoll genannt werden, sind in Singapur nämlich dieses Jahr in den verpflichtenden "Cybersecurity Code of Practice" aufgenommen worden.

Tja, unser kleines Projekt ist mittlerweile schon über ein Jahr alt (wenn man als Geburtstatg die ersten Veröffentlichung des Top 20-Dokuments wertet). In der Zwischenzeit hat das Projekt ganz schön viel Staub aufgewirbelt, ist viel diskutiert und aus meiner Sicht auch manchmal mit Erwartungen überfrachtet worden. Also: Es war ein guter Zeitpunkt, ein paar Dinge zu klären, die in der Vergangenheit zu Missverständnissen geführt haben könnten: Was die Top 20 sind, was sie nicht sind, wo sie besser werden können und was Sie mit ihnen tun sollten, wenn Sie Betreiber, Integrator oder Hersteller sind.

Für diejenigen, die nicht in Singapur oder virtuell dabei sein konnten, habe ich die Präsentation verschriftlicht - Link im Lesestoff. Eine Aufzeichnung der Live-Präsentation wird in Kürze als Video auf der Website des OT Cybersecurity Expert Panel Forums verfügbar sein.

6. Call for Contributions für Security unter Kontrolle: Endspurt!

Abschließend noch einmal der Hinweis: Diese Woche (am 10. August) endet der Call for Contributions für Security unter Kontrolle. Die Einreichung ist unbürokratisch und muss weder ellenlang, noch poliert sein - ist also locker noch diese Woche zu schaffen.

Unser Programmbeirat freut sich auf die Beiträge (und auch schon sehr über die, die bereits eingegangen sind - vielen Dank an alle Frühstarter!).

Alle Details zur Einreichung stehen im CfC-Formular (Lesestoff-Link).

Stay secure!
Sarah Fluchs