Das war's auch schon mit 2020: Hier kommt das letzte Security-Briefing für dieses Jahr.
Zum Schluss hat das Jahr nochmal alles gegeben - ich wusste gar nicht, wo ich anfangen soll mit dem Erzählen, was alles passiert ist im November. Wir fangen also mit dem Offensichtlichen an: dem IT-Sicherheitsgesetz.
Wenn Sie's nicht mehr sehen können: Einfach vorbeiscrollen. Danach wird die Kost leichter, versprochen. Und es gibt auch nur einen einzigen Punkt zum Thema Ransomware!

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

1. IT-SiG 2.0: dritter Referentenentwurf und Timeline
2. Wie angreifbar sind kritische Infrastrukturen in Deutschland?
3. Rettungsleitstellen-Software: Unter Zeitdruck halt keine Zeit für Security
4. Update zum Uniklinik-Fall: Doch kein "Tod durch Ransomware"
5. BSI IT-Grundschutz: Neue Bausteine für industrielle IT
6. Security-Theater: Fühlt sich an wie Security, isset aber nicht
7. BSI-Studie dazu, wie Win 10 "nach Hause telefoniert"
8. IET Code of Practice Cyber Security and Safety
9. Leichte Lektüre zum Schluss: Dem Ingeniör ist nichts zu schwör!

1. IT-SiG 2.0: dritter Referentenentwurf und Timeline

Kurz nachdem der dritte Referentenentwurf des IT-SiG 2.0 „vom Laster gefallen“ war, hat das BMI ihn am 2. Dezember nun auch offiziell auf seiner Website veröffentlicht. Für Stellungnahmen wurde eine Frist von unglaublichen 5,5 Werktagen eingeräumt: Bis 9. Dezember nämlich. Kann man ja mal machen, nachdem man intern zwei Jahre an dem Gesetz geschraubt hat…
Jedenfalls finden Sie den Referentenentwurf zum Download im Lesestoff-Link 1.

Zur Erinnerung: Das IT-Sicherheitsgesetz (IT-SiG) ändert mehrere bestehende Gesetze, unter anderem das BSI-Gesetz (BSIG). Deswegen finden Sie in den untenstehenden Schlaglichtern immer Referenzen auf den Entwurf des BSI-Gesetzes ("BSIG-E").

Da wir uns im Juni-Briefing schon intensiv mit dem zweiten Entwurf befasst haben und auch dieser Referentenentwurf noch ein "ungelegtes Ei" ist, schauen wir uns diesmal nur ein paar Schlaglichter an, die mein Juristenkollege Peter Breidbach für Sie herausseziert hat:

• Begriffsdefinitionen sind konkreter geworden. Zum Beispiel für die "Unternehmen im besonderen öffentlichen Interesse", liebevoll "Uniböfi" genannt, durch die die Chemiebranche, aber auch Hersteller von Waffen und Sicherheitstechnik und generell große Unternehmen, die nicht als kritische Infrastrukturen gelten, trotzdem hinsichtlich IT-Security reguliert werden könnten. Für die Definition dieser "Uniböfi" werden die Höhe der inländischen Wertschöpfung, Betreiber eines Betriebsbereichs der oberen Klasse nach Störfallverordnung und Produzenten von Gütern gem. §60 der Außenwirtschaftsverordnung (--> Sicherheitstechnik).
  [§2 Abs. 13 und 14 BSIG-E]
• "Uniböfi" müssen nun kein IT-Sicherheitskonzept mehr vorlegen, sondern nachweisen, welche Zertifizierungen und Sicherheitsaudits durchgeführt wurden (und wie damit der angemessene Schutz sichergestellt ist).
  [§ 8f Abs. 1 BSIG-E]
• Auch die "Systeme zur Angriffserkennung", die auch schon im vorigen Referentenentwurf gefordert wurden, sind nun genauer beschrieben, und ehrlich gesagt klingt das nicht nur nach "Erkennung":
  "Die eingesetzten Systeme zur Angriffserkennung müssen geeignete Parameter bzw. Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten. Sie sollten dazu in der Lage sein, fortwährend Bedrohungen zu identifizieren und zu vermeiden sowie für eingetretene Störungen geeignete Beseitigungsmaßnahmen vorsehen."
  Außerdem sollen die Daten dieser Systeme für vier Jahre gespeichert werden.
  Für ein Gesetz, das sonst nur "angemessene Maßnahmen nach Stand der Technik" fordert, ist das eine auffällige Hervorhebung eines Maßnahmentypus'. Man kann die Lobby der Toolhersteller wohl zu ihrem Erfolg nur beglückwünschen...
  [§8a Abs. 1a und 1b BSIG-E]
• Im Gegensatz zum vorherigen Entwurf betrifft die Anforderung zu Systemen zur Angriffserkennung nun auch Betreiber von Energieversorgungsnetzen und Energieanlagen - indem auch das Energiewirtschaftsgesetz (EnWG) geändert wird
  [§11 Abs. 1d EnWG-E].
  Einige Umsetzungsfristen verkürzen sich. Registrierungs- und Meldepflichten für "Uniböfi" werden innerhalb von 6 Monaten verpflichtend (vorher war keine Frist genannt).
  [§ 8f Abs. 7,8 und 9 BSIG-E]
  Die Systeme zur Angriffserkennung müssen 1 Jahr nach Inkrafttreten des IT-SiG (statt 2 Jahre nach Inkrafttreten der Rechtsverordnung) implementiert sein.
  [§8a Abs. 3 BSIG-E]
• Für die KRITIS-Betreiber wurde die Anforderung zur Übermittlung aller verwendeten IT-Produkte kassiert. Die Festlegungen zu "kritischen Komponenten", die nur von vertrauenswürdigen Herstellern bezogen werden dürfen ("Huawei-Gesetz"), gibt es weiterhin, aber was eine kritische Komponente ist, definiert nun nicht mehr das BSI - stattdessen soll es gesetzlich geregelt werden.
  [§ 2 Abs. 13 BSIG-E]
• Gab es auch schon im vorigen Entwurf, aber nun wird das Kind "Portscans" beim Namen genannt: Das BSI kann unter gewissen Umständen Portscans bei KRITIS-Betreibern und Unternehmen im besonderen öffentlichen Interesse durchführen, um Sicherheitslücken zu identifizieren.
  [§7b BSIG-E]
• Die maximale Bußgeldhöhe liegt im aktuellen Entwurf bei 2 Mio € - das ist weniger als im zweiten Entwurf.
  [§ 14 Abs. 2 BSIG-E]

Weitere Zusammenfassungen und Stellungnahmen finden Sie in den Lesestoff-Links 2 bis 4.

Darüber, wann das IT-SiG 2.0 in Kraft treten könnte (und was vorher noch geändert wird), kann man nur spekulieren. Es ist vorstellbar, dass das Innenministerium es noch in dieser Legislaturperiode (als in der ersten Hälfte 2021) durchbekommen möchte.
Der Flurfunk munkelt, die Befassung im Kabinett sei für dieses Jahr geplant (in der letzten Kabinettssitzung am 16. Dezember) und danach Abstimmungen auf EU-Ebene und im Bundestag - ob es mit dieser Legislatur klappe, sei fraglich (Dank an Dennis Kenji-Kipker und André Meister).

Also: Abwarten und Glühwein trinken.

2. Wie angreifbar sind kritischen Infrastrukturen in Deutschland?

Das hat sich offenbar die FDP auch gefragt und als Reaktion auf den Ransomware-Angriff auf die Uniklinik Düsseldorf im September und der anschließenden Warnung des BSI dazu eine kleine Anfrage an die Bundesregierung gestellt (Anfrage mitsamt Antworten im Lesestoff-Link 1).
Die meisten Antworten sind wenig aussagekräftig, aber die Anzahl der gemäß KRITIS-Meldepflicht gemeldeten Angriffe aufgeschlüsselt nach KRITIS-Sektor sind interessant (s. S. 3 und 4).
Die Zahlen sind aus zwei Gründen mit Vorsicht zu genießen:

1. Einerseits wird bekanntermaßen wird trotz Meldepflicht nicht jeder Vorfall gemeldet; es dürfte also eine Dunkelziffer geben;
2. Andererseits sagt ein gemeldeter Vorfall noch nichts über dessen Schwere aus.

Trotzdem: Der Sektor Gesundheit ist mit bislang 43 gemeldeten Vorfällen in 2020 (2019 waren es 16) "nur" Zweiter nach dem Sektor Staat und Verwaltung mit 70 gemeldeten Vorfällen.

Und dann - der November war ein Monat mit viel Output! - sind hier noch drei weitere wertvolle Links mit Lese- und Anschau-Stoff zum Thema Security von kritischen Infrastrukturen in Deutschland:

• Video 2: Eine empfehlenswerte, kurze ZDF-Sendung (Frontal 21) befasst sich mit dem Szenario eines Strom-Blackouts in Deutschland.
• Lesestoff 3: Das Innenministerium hat ein umfassendes (278 Seiten) Kompendium zu "Cybersicherheit in Deutschland" herausgegeben. Darin wird unter anderem eine Übersicht zu allen Initiativen im Bereich Cybersicherheit gegeben - sortiert nach Zivilgesellschaft, Wissenschaft, Wirtschaft, Staat und Verbänden.
• Lesestoff 4: Julia Schuetze von der Stiftung Neue Verantwortung hat eine Studie zur Unterschieden, Gemeinsamkeiten und Kooperationspotenzial für die europäische und US-amerikanische Cybersecurity-Strategie veröffentlicht. Wer nicht viel Zeit hat, aber trotzdem die Grundzüge verstehen möchte, dem seien zumindest die "Key Takeaways" am Anfang ans Herz gelegt (s. 3-6).

3. Rettungsleitstellen-Software: Unter Zeitdruck halt keine Zeit für Security

Rettungsleitstellen: Das sind diejenigen, die aufgrund von freien Betten und Personalkapazitäten entscheiden, welches Krankenhaus ein Rettungswagen ansteuert.
Sie nutzen dafür - natürlich - Software, und zwar in vielen Fällen die Software "Ivena" des Frankfurter Hersteller mainis IT Service. Im Rahmen der Corona-Pandemie wurde unter Zeitdruck ein Zusatzmodul entwickelt - offenbar so viel Zeitdruck, dass ein Entwickler das Masterpasswort auf einem frei zugänglichen Server "liegengelassen" hat. Jeder im Besitz des Masterpassworts hätte z.B. Intensivstationen als belegt oder frei kennzeichnen können, schreiben Holger Bock und Lars Ohlenburg im NDR-Report (s. Lesestoff-Link 1).

"Hätten" - denn es ist offenbar nichts passiert. Unabhängig von der Frage, wie dramatisch Worst-Case-Szenarien überhaupt hätten sein können, ist ein Nebensatz des Berichts: Die Programmierung sei unter großem Zeitdruck erfolgt, "wie die Entwickler vom mainis IT-Service dem Heise-Verlag freimütig einräumten".
Klar können Fehler passieren, aber wenn Zeitdruck als Entschuldigung für einen derart sicherheitsrelevanten Fehler schon ausreicht, hat Security offenbar keine Priorität - sonst gibt es Prozesse, Checks and Balances, die wenigstens Security-Kardinalfehler verhindern. Und wenn die schiefgehen, ist man ausreichend zerknirscht.
Man stelle sich vor, BMW hätte die Airbags im Auto vergessen einzubauen und würde danach zum Besten geben "ja, sorry, der neue 3er musste echt schnell fertig werden, da passiert sowas eben...".

Auch wenn es um eine andere Branche geht: Zum Thema passt ein in der Oktober im "ISA Inside" veröffentlichter Beitrag des Philosophen Eric B. Litwack. Es geht um "Automation Ethics" - mit Schwerpunkt auf der Sorge, Automatisierung könne Arbeit von Menschen ersetzen (s. Lesestoff-Link 2).
Auch wenn Litwack explizit darauf hinweist, dass er sich mit nur einem Teilgebiet der Ethik von Automatisierung befasst - vielleicht wird es Zeit, neben der Standardfrage "Mensch oder Maschine" ein weiteres Thema zum Dauerbrenner zu machen: Die Entwicklung von (Automatisierungs)systemen, die resilient gegen böswillige Eingriffe sind...

4. Update zum Uniklinik-Fall: Doch kein "Tod durch Ransomware"

Der Schlagzeile konnte im September kein Medium widerstehen: Tod durch Ransomware! Die Uniklinik Düsseldorf war Opfer eines Verschlüsselungstrojaners geworden und hatte daraufhin die Notaufnahme bei der Rettungsleitstelle (s.o.) abgemeldet. Deshalb musste eine Notfallpatientin in ein weiter entferntes Krankenhaus in Wuppertal gebracht werden und starb kurze Zeit spät, wohl aufgrund der verzögerten Behandlung.

Oder?

Ebenso wenig überraschend wie die Nutzung der unwiderstehlichen Schlagzeile ist, dass die weitere Verfolgung nun kaum noch Medienpräsenz findet. Die kleinteiligen Ermittlungen im Nachgang sind weniger spektakulär, waren aber notwendig, nachdem Strafanzeige wegen Verdacht auf fahrlässige Tötung gegen die unbekannten Hacker gestellt wurde. Das mit der fahrlässigen Tötung hätte nämlich nur geklappt, wenn man gerichtsfest hätte nachweisen können, dass die Frau wirklich aufgrund des Ransomware-Angriffs gestorben wäre, schreibt Wired in einem lesenswerten Artikel (s. Lesestoff-Link).

Sie merken an der Konjunktiv-Häufung: Das ist nicht gelungen. Medizinische Gutachten und eine Autopsie haben ergeben, dass die Frau aufgrund ihrer Erkrankung gestorben wäre, auch wenn die Behandlung nicht verzögert worden wäre.

Man kann das Ganze als juristische Haarspalterei abtun. In jedem Fall ist ein logischer Zusammenhang, selbst wenn er da ist, nicht immer gerichtsfest beweisbar. Auch der Wired-Artikel zitiert Chefermittler Markus Hartmann mit den Worten, es sei nur eine Frage der Zeit, bis Ransomware tatsächlich direkt einen Tod verursache, und es sei auch juristisch möglich, Hacker für Totschlag durch Ransomware verantwortlich zu machen.

Aber man muss festhalten: Dieses spezifische Ereignis in der Uniklinik Düsseldorf als "Tod durch Ransomware" zu referenzieren, ist nicht korrekt.

Weil wir gerade beim Thema Ransomware sind: Sie ist weiterhin in aller Munde, vor allem, weil die Angriffe auf den Gesundheitssektor in der Corona-Pandemie deutlich steigen.
Deswegen wird dazu auch viel geschrieben. Vier handgepflückte Links:

• Es gibt sie: Ransomware-Trojaner für Linux. Nun sogar einen, der von Windows zu Linux portiert wurde, schreibt Forbes.
• Mit dem häufigen Ransomware-Trojaner Ryuk soll die Rekordsumme von 34 Millionen Dollar Lösegeld von einem einzigen Opfer eingetrieben haben, schreibt Bleeping Computer.
• Wer zahlt sowas? Jeder Vierte, schreibt ZDnet: Jedes Vierte Ransomware-Opfer zahlt angeblich das Lösegeld.
• Dabei wäre es besser, wenn das Zahlen von Ransomware-Erpressergeld illegal wäre, schreibt die Frankfurter Allgemeine Sonntagszeitung. Was die Community so von der Idee hält, wollte ich wissen - das können sie nun Nachlesen auf Twitter und auf LinkedIn.

5. BSI IT-Grundschutz: Neue Bausteine für industrielle IT

Neue Final Drafts für IT-Grundschutz-Bausteine sind veröffentlicht worden (siehe Lesestoff-Link). Sie sollen 2021 in die nächste Edition des IT-Grundschutz-Kompendiums aufgenommen werden.

Darunter sind auch sechs Bausteine aus der Kategorie "IND" (industrielle IT):

• IND.1 Prozessleit- und Automatisierungstechnik
• IND.2.1 Allgemeine ICS-Komponente
• IND.2.2 Speicherprogrammierbare Steuerung (SPS)
• IND.2.3 Sensoren und Aktoren
• IND.2.4 Maschine
• IND.2.7 Safety Instrumented Systems

Man muss positiv anerkennen, dass das BSI wirklich IND-Bausteine vorantreibt, und Rom wurde nicht an einem Tag erbaut (es gibt Gründe, warum die Standardbeschwerde zur ISA 62443 ist, sie würde ja nie fertig). Dennoch: Die Qualität der IND-Bausteine ist eher durchwachsen.

Die "übergreifenden" Bausteine zur "Prozessleit- und Automatisierungstechnik" und "Allgemeinen ICS-Komponente" sind recht umfangreich, die Anforderungen aber erwartungsgemäß generisch - böse gesagt: Würde das BSI stattdessen einfach die ISO/IEC-27002-Controls hinschreiben, man würde es wohl nicht merken.
Die BSI-Baustein-Krankheit, fehlende Maßnahmen als Gefährdung zu deklarieren (und dann als Anforderung dazu - tadaaa! - das Schließen ebendieser "Lücke"), zeigt sich in Gefährdungsstilblüten wie "unsicheres Administrationskonzept", "unzureichendes Testkonzept" oder "unzureichende Überwachungs- und Detektionsverfahren".
Klar, wir brauchen die Anforderung, weil....wir gesagt haben, dass wir sie brauchen. Ich warne ja in Risikoanalysen gern vor "Rückwärtsrisiken", die man rückwärts von der Maßnahme definiert....das BSI liefert prima Schulungsmaterial dazu.

Den Baustein zur SPS habe ich mir, die laufende Arbeit am PLC Secure Coding-Projekt stets im Hinterkopf, naturgemäß genauer angeschaut.
Was soll man sagen: Der Baustein enthält genau eine Gefährdung (unvollständige Dokumentation) und genau zwei Anforderungen: erweiterte Systemdokumentation (tadaa!) und Zeitsynchronisation.
Rom wurde nicht an einem Tag erbaut, aber man darf wirklich hoffen, dass das "Final" bei dem SPS-Baustein nur aus Versehen in den Titel "Final Draft" gerutscht ist.

Versöhnliches zum Schluss: Der Baustein "Safety Instrumented Systems" (SIS) ist ein schon deutlich soliderer Final Draft. Angesichts der Tatsache, dass ein SIS technisch gesehen von einer SPS nicht so weit entfernt ist, kann man die Frage stellen, warum es sinnvolle Anforderungen aus den SIS-Baustein wie "Sichere Übertragung von Engineering-Daten auf SIS" nicht in den SPS-Baustein geschafft haben.

6. Security-Theater: Fühlt sich an wie Security, isset aber nicht

Nach den vielen länglichen Themen haben wir nun zum Abschluss des Hardhats-Briefings noch ein paar flotte Links.

Los geht's mit einem wirklich lesenswerten - und zum Schmunzeln anregenden - Twitter-Thread, der mit der Frage begann: "Was fühlt sich an wie Security, ist aber keine?".
Eine wunderbare Sammlung von How-Not-To-Dos.

Die gefühlt häufigste Antwort: Ablaufende Passwörter.

7. BSI-Studie dazu, wie Win 10 "nach Hause telefoniert"

Zu welchen Zwecken und auf welchen Wegen verbinden sich Windows-10-Geräte ohne zu fragen mit Microsoft und wie konfiguriert man sie, damit sie damit aufhören?

Das BSI hat im November eine weitere Studie im Rahmen seines "SiSyPHuS Win10"-Projektes zur Windows-10-Telemetrie veröffentlicht: MS Office Telemetry (s. Lesestoff-Link 1).

Auch die bisherigen Projektergebnisse sind lesenswert - unter anderem die Konfigurations- und Protokollierungsempfehlungen für die Telemetriekomponente in Windows 10 (s. Lesestoff-Link 2). Die Erkenntnisse sollten in Ihren Härtungsrichtlinien nicht fehlen.

8. IET Code of Practice: Cybersecurity und Safety

Security for Safety ist ein dickes Brett. Es ist schon viel dazu geschrieben worden - leider auch viel Halbwissen, und vieles, was mit umständlichen Methoden versucht zu vermeiden, dass sich Safety-Experten mit Security überhaupt herumschlagen müssen.

Erfrischend klar, unverschwurbelt und vor allem inhaltlich korrekt kommt da der "Code of Practice Cyber Security and Safety" der gemeinnützigen "Institution of Engineering and Technology" (IET) daher (Lesestoff-Link).
Solide Leseempfehlung für den Einstieg ins Thema sind die Sections 1 bis 3. Ein klares Highlight ist die Section 3, die Unterschiede zwischen Security und Safety gut zusammenfasst. Nicht neu, aber übersichtlich.

Ab Section 4 beginnt der Teil des "then what", also die praktische Umsetzung, und der fällt leider etwas spärlich aus und "rettet" sich in Governance-Themen, along the lines of "The organization promotes an open/learning culture whilst maintaining appropriate confidentiality". Tjanun.

9. Leichte Lektüre zum Schluss: Dem Ingeniör ist nichts zu schwör!

Im November durfte ich die - leider virtuelle - Keynote bei der schwedischen SCADA Säkerhet halten. "Leider" virtuell muss man sagen, denn ohne Kontakt zum Publikum direkt "in die Tüte" zu sprechen ist wirklich nicht dasselbe.
Das Intro zur Keynote mit dem Titel "nothing to fear for an engineer" - das englische Pendant zum Daniel-Düsentrieb-Motto "dem Ingeniör ist nichts zu schwör", finden Sie im Lesestoff-Link. Es ist leichte Kost und mein Pladoyer dafür, mit mehr Daniel-Düsentrieb-Mindset an die OT-Security heranzugehen. Ich verspreche, ich habe meine Hausaufgaben gemacht und fleißig Entenhausen-Comics gelesen - um herauszuarbeiten, was das eigentlich ist, ein Daniel-Düsentrieb-Mindset...

Zwei weitere kleine Infos zum Schluss, dann entlasse ich Sie aber wirklich in die Vorweihnachtszeit:

• Dale Peterson testet gerade alternative Online-Formate als Trostpflaster für die ausfallende S4x21. Eins davon sind Broadcasts auf LinkedIn Live. Im November war ich dort zu Gast und habe mit ihm über den aktuellen Stand und die Vision des Secure PLC Coding Projects gesprochen. Wer's nachschauen möchte: Hier ist der Link zum Video, mit den Top 20 PLC geht es etwa ab Minute 43 los.
• Und nochmal S4: Das ICS OnRamp-Training, 10 Videos von ICS Security-Profis auf Einsteigerniveau, sind nun frei verfügbar auf YouTube. Schneller, günstiger und bequemer bekommt man seine OT-Security-Grundlagenbildung wohl nicht...
  Hier geht's zur Playlist.

Ich hoffe, Sie können im Dezember wenigstens für eine Weile den Schutzhelm gegen die Nikolausmütze tauschen. Kommen Sie gut durch die Feiertage!
In der ersten Januarwoche kommen wir gemeinsam wieder in Schwung.

Stay secure!
Sarah Fluchs