Im Mai war der Star der Stunde definitiv der überarbeitete Entwurf zum IT-Sicherheitsgesetz, kurz "IT-SiG 2.0". Sein Vorläufer hatte im Jahr 2015 unter anderem dafür gesorgt, dass kritische Infrastrukturen IT-Sicherheit nachweisen müssen.

Der nun bei intrapol.org verfügbare Referentenentwurf des IT-SiG 2.0 ist immer noch genau das - ein Entwurf. Wir unterhalten uns also über ungelegte Eier, werden aber ein paar (potenzielle!) Änderungen trotzdem beleuchten: Wer zählt zukünftig als KRITIS-Betreiber? Was darf das BSI? Müssen Hersteller Security bald zertifizieren? Und was ist nun mit der Chemiebranche?

Außerdem haben wir ein paar "long reads" zur IEC 62443-2-1 und Security for Safety im Gepäck. Los geht's.

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

1. Deutsche KRITIS im Fadenkreuz russischer Hacker
2. IT-Sicherheitsgesetz 2.0 geht in die Ressortabstimmung
3. Trump verbietet Komponenten von "foreign adversaries" im US-Stromnetz
4. Vorletzte Hürde genommen: Ausblick auf die neue IEC 62443-2-1
5. Security for Safety: Der lange Weg zum Konsens
6. CERT@VDE darf jetzt CVE-Nummern vergeben
7. Schwachstellen in OSI PI und Siemens SIPROTEC
8. Security-Engineering lernen in meinem IBF-Seminar

1. Deutsche KRITIS im Fadenkreuz russischer Hacker

Diese Nachricht hat es so gerade noch ins Briefing geschafft:

Deutsche kritische Infrastrukturen - vor allem in den Sektoren Energie, Wasser und Telekommunikation - werden in einem nicht öffentlichen Bericht von BSI, BfV und BND vom 18. Mai vor Angriffen gewarnt, die mutmaßlich von der russischen Hackergruppe "Berserk Bear" stammen. Grund für die Warnungen seien schon länger bestehende Kompromittierungen in Zusammenhang mit aktuellen Sicherheitsvorfällen, berichtet die Tagesschau am 27.05.2020.

Die erste öffentliche Nachricht dazu kommt interessanterweise aber nicht von der Tagesschau, sondern von der US-amerikanischen Website Cyberscoop:
German intelligence agencies warn of Russian hacking threats to critical infrastructure.

2. IT-Sicherheitsgesetz 2.0 geht in die Ressortabstimmung

Der Gesetzentwurf zum IT-Sicherheitsgesetz 2.0, Stand 07.05.20, ist nun vom Innenministerium zur Ressortabstimmung an die betroffenen Ministerien verschickt worden. Im Bundestag wird der Entwurf wohl erst im Herbst landen.

Also: Wir sprechen hier von einem Entwurf, der sich noch ändern kann und wohl auch wird.
Damit sind nun genug Disclaimer vorweggeschickt - schauen wir mal, was sich ändern würde, wenn das Gesetz genau so verabschiedet würde.

Kleine Gesetz-Sortierhilfe vorab:
Das IT-SiG 2.0 (IT-Sicherheitsgesetz 2.0, "Zweites Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme") ist ein Gesetz zur Änderung verschiedener anderer Gesetze und Verordnungen. Es hat fünf Artikel (der fünfte beinhaltet die Schlussbestimmungen):

1. Änderungen des BSIG (BSI-Gesetz, "Gesetz über das Bundesamt für Sicherheit in der Informationstechnik").
2. Änderungen des TKG (Telekommunikationsgesetz)
3. Änderungen des TMD (Telemediengesetz)
4. Änderungen der AWV (Außenwirtschaftsverordnung)

Hier picken wir nur einige Änderungen des BSI-Gesetzes heraus.

Das heißt, die folgenden Paragraphenangaben beziehen sich auf zu ändernde Paragraphen im BSIG:

• Neuer KRITIS-Sektor (§ 2 Absatz 10):
  Die Entsorgung soll zu den kritischen Infrastrukturen zählen.
• Änderungen für bestehende KRITIS-Sektoren (§ 8a, mehrere Absätze):
  Kritische Infrastrukturen sollen die Befugnis erhalten, die Vertrauenswürdigkeit ihrer Beschäftigten zu überprüfen, sowie die Pflichten, Systeme zur Angriffserkennung einzusetzen und eine Liste aller eingesetzten IT-Produkte ans BSI zu übermitteln.
• Unternehmen im besonderen öffentlichen Interesse (§ $2 Absatz 14) („Uniböfi“):
  Auf diesem Wege könnte unter anderem die Chemiebranche im Geltungsbereich des ITSiG landen: Diese neue Kategorie zählt nicht zu den kritischen Infrastrukturen, soll aber trotzdem Sicherheitsvorfälle melden müssen.
  Es können je nach Einstufung weitere Pflichten dazukommen: Die Pflicht zur Registrierung beim BSI und die Pflicht, ein Sicherheitskonzept vorzulegen, das dem Stand der Technik entspricht und Sicherheitsvorfälle vermeiden soll.
  Zu den "Uniböfi" sollen nach aktuellem Entwurf Rüstungsunternehmen gehören, außerdem Unternehmen von erheblicher volkswirtschaftlicher Bedeutung und solche, die der Gefahrstoffverordnung unterliegen.
• Bußgelder (§ 14):
  Die Höhe der Bußgelder bei Verstößen gegen im IT-SiG definierte Pflichten soll an DSGVO-Dimensionen angeglichen werden: Im Maximalfall 20 Mio. Euro oder 4 % des gesamten weltweit erzielten jährlichen Unternehmensumsatzes.
• Neue BSI-Kompetenzen (diverse §§):
  Das BSI soll weiterreichende Befugnisse (und mehr Personal) bekommen. Zum Beispiel durfte es bislang nicht einmal einen Portscan selbst durchführen; zukünftig soll dies aber erlaubt sein, auch die Einrichtung von Honeypots oder aktives Vorgehen etwa gegen Botnetze.
  Das BSI soll außerdem den Verbraucherschutz im Bereich Security fördern (siehe unten: IT-Sicherheitskennzeichen) und die nationale Behörde für Cybersicherheitszertifizierung gemäß EU Cybersecurity Act werden.
  Auch eine engere Zusammenarbeit mit dem BBK (Bundesamt für Bevölkerungs- und Katastrophenschutz), BKA (Bundeskriminalamt) und BDBOS (Bundesanstalt für den Digitalfunk der Behörden und Organisationen mit Sicherheitsaufgaben) ist vorgesehen.
• IT-Sicherheitskennzeichen (§ 9a):
  Das IT-Sicherheitskennzeichen soll für Hersteller freiwillig sein (verpflichtend geht auf nationaler Ebene nicht, da dies den EU-weit regulierten Marktzugang einschränken würde). Das Kennzeichen ist also kein Zertifikat, sondern eher eine Verbraucherschutzidee, ähnlich wie die Lebensmittelampel: Der Käufer soll schnell einordnen können, welche Security-Merkmale ein Produkt erfüllt und welche nicht. Das Kennzeichnen soll aus zwei Teilen bestehen, einer Herstellererklärung zu Sicherheitseigenschaften und BSI-Informationen, zum Beispiel zu Sicherheitslücken des Produkts.
• Kritische Komponenten (§ 2 Absatz 13):
  Die neue Bezeichnung "kritischen Komponenten" soll für die IT-Produkte gelten, die bei KRITIS eingesetzt werden und dort von hoher Bedeutung für das Funktionieren der kritischen Dienstleistung sind.
• Hersteller-Garantieerklärung (§ 9b):
  Kritische Komponenten sollen nur noch dann eingesetzt werden dürfen, wenn eine Hersteller-Garantieerklärung über die Vertrauenswürdigkeit des Herstellers vorliegt. Ist ein Hersteller nicht vertrauenswürdig, etwa weil er gegen seine Garantieerklärung verstößt, Schwachstellen nicht meldet und beseitigt oder nicht regelmäßig Penetrationstests vornimmt, soll das Innenministerium den Einsatz seiner Produkte als kritische Komponenten untersagen dürfen.

Die Hersteller-Garantieerklärung hat heise.de in der IT-SiG-Berichterstattung vom 09. Mai als zentrales Thema behandelt, weil sie je nach Ausgestaltung das Potenzial hat, Hersteller vom Markt auszuschließen - zum Beispiel Huawei für das 5G-Netz.

3. Trump verbietet Komponenten von "foreign adversaries" im US-Stromnetz

Während hierzulande alle Augen auf das IT-Sicherheitsgesetz gerichtet waren, hat US-Präsident Trump bereits am 1. Mai einen Erlass mit dem Titel "Executive Order on Securing the United States Bulk-Power System" getätigt.

Der Geltungsbereich sind hier nicht alle kritischen Infrastrukturen, sondern nur der Energiesektor. Eine deutliche Vorstellung hat die US-Regierung offenbar dazu, welche Hersteller als vertrauenswürdig gelten und welche nicht: Statt sich mit Garantieerklärungen aufzuhalten, verbietet der Erlass den Einsatz aller Komponenten von "foreign adversaries" im US-amerikanischen Energieerzeugungs- und -übertragungsnetz.

Eine Task Force soll nun Kriterien und Beschaffungsrichtlinien (procurement policies) für den Energiesektor erarbeiten und in einem Jahr einen Bericht vorlegen.

Was war der Auslöser für den Erlass? Joe Weiss erklärt in seinem Blog, es sei die Reaktion auf einen konkreten Vorfall gewesen, bei dem in einem chinesischen Transformator Hintertüren ("back doors") gefunden wurden - und zieht seinerseits die Verbindung zur Diskussion um Huawei-Komponenten im 5G-Mobilfunknetz.

4. Vorletzte Hürde genommen: Ausblick auf die neue IEC 62443-2-1

Letzten Monat haben wir uns die Reorganisation der ISO/IEC 27001 vorgenommen. Dieses Mal geht es - versprochen ist versprochen - um ihr Äquivalent für OT-Betreiber. Zumindest um den Teil der IEC 62443, der einem Äquivalent am nächsten kommt.

Die letzte veröffentlichte Version der IEC 62443-2-1 stammt von 2010. Seitdem hat es viele Diskussionen um das Angleichen der -2-1 an die Struktur ISO/IEC 27001 gegeben. Letztendlich hat man sich entschieden, bei seiner eigenen Struktur zu bleiben, jedoch ein Mapping zu ISO/IEC 27001-Controls zu integrieren.
Die neue Version der IEC 62443-2-1 verwendet auch den an das ISMS angelehnten Begriff "CSMS" (Cyber Security Management System) nicht mehr, sondern nennt das Kind stattdessen deutlich abweichend "Security Program".

Diese Diskussionen verbunden und die Tatsache, dass die 62443-Standards mit ISA, IEC und ISO zur Kommentierung in drei Standardisierungsorganisationen zirkuliert werden, sind zwei Gründe für den etwas zähen Entwicklungsprozess des neuen -2-1-Entwurfs. Mitte 2019 ist der Entwurf aber in der CDV-Stufe gelandet (Committee Draft for Vote, die letzte Stufe, an der noch inhaltliche Kommentare übermittelt werden können) und akzeptiert worden. Im Februar 2021 wird der Standard dann mit der FDIS-Stufe (Final Draft International Standard) die letzte Hürde zur Veröffentlichung nehmen.
Warum dauert das so lange? Nun, die Arbeitsgruppe, die den Entwurf vorgelegt hat, muss nun 90 Seiten Kommentare einarbeiten...

Da der Standardentwurf aber insgesamt positiv aufgenommen wurde, lohnt es sich, schon einmal einen Blick in die neue Struktur zu werfen.

Wer mit der IEC 62443-2-1:2010 schon einmal gearbeitet hat, kennt die höchst einprägsamen Anforderungs-IDs: 4.3.4.5.7. oder so ähnlich. Damit ist in der neuen Version definitiv Schluss. Im aktuellen Entwurf sind die grundlegend neu verfassten Anforderungen in acht "Security Program Elements" (SPEs) unterteilt:

1. ORG: Organizational security measures
2. CM: Configuration management
3. NET: Network and communications security
4. COMP: Component security
5. DATA: Protection of data
6. USER: User access control
7. EVENT: EVent and incident management
8. AVAIL: System integrity and availability

Jedes SPE beinhaltet zwischen vier und 18 Anforderungen mit praxistauglichem OT-spezifischem Fokus. Beispiel: Abgelaufene Accounts automatisch deaktivieren? Ja bitte, aber keine, die für die Verfügbarkeit wichtig sind.

Die neue -2-1 ist eine echte Verbesserung und bis Februar 2021 ist es nicht mehr lange hin - also wenn Sie gerade anfangen, die IEC 62443-2-1 in der 2010er-Version für sich zu entdecken, gewöhnen Sie sich besser nicht zu sehr an ihre Inhalte.

5. Security for Safety: Der lange Weg zum Konsens

Wie geht man mit der Security von Safety-Systemen um? Bei dem Thema treffen Welten aufeinander, und entsprechend leidenschaftlich wird es seit Jahren diskutiert. Wer ist dafür eigentlich zuständig, die Security-Experten oder die Safety-Experten? Kann es einen Safety-Nachweis ohne Security-Nachweis geben? Und funktioniert Security für Safety-Systeme eigentlich anders als für andere Systeme?

Oder, auf des Pudels Kern reduziert aus Standardisierungs-Sicht: Ist Security in den Safety-Standards eine Muss- oder eine Kann-Anforderung?

Nach jahrelangem Ringen geht es in diesem Thema nun voran. Zumindest für den Safety-Horizontalstandard ist Konsens für einen Kompromiss in Sicht: Die IEC 61508 soll ein "Muss" enthalten - aber nur für die Forderung nach einer Security-Risikoanalyse, und nur für die Forderung, DASS diese durchgeführt wird, nicht WIE. (Danke für die Infos, Holger Laible!).

Dieser unscheinbare Konsens hat das Potenzial, eine zähe Diskussion zu beenden und ebnet den Weg, sich nun konstruktiv mit dem WIE zu beschäftigen - an anderer Stelle, in Security-for-Safety-Standards.
Eine dieser anderen Stellen ist der Technical Report IEC TR 63069, dessen eigentlich guter Inhalt in der ersten Ausgabe im Kommentierungsverfahren ob der oben umrissenen umgeklärten Diskussion einige Federn lassen musste. Die IEC-Arbeitsgruppe nimmt nun die Arbeit wieder auf mit Vorschlägen zum WIE der Security for Safety-Risikoanalyse.
Eine zweite "andere Stelle" ist der ISA TR 84.00.09, der einen "integrierten Lebenszyklus" für Security und Safety anstrebt - und mit der IEC TR 63069 nun eine Liaision, also Zusammenarbeit, anstrebt.

Zu Grundproblemen von Security for Safety, dem Ansatz des ISA TR 84.00.09, an dem ich mitarbeite, und meiner persönlichen Hoffnung, dass Security for Safety ein Kristallkeim für Security by Design werden könnte, finden Sie einen fluchsfriction-Blogpost im Lesestoff-Link.

Sinclair Koelemij hat außerdem einen lesenswerten Überblick zu Safety-Architekturen und ihren Vor- und Nachteilen geschrieben: Interfaced oder integrated?

6. CERT@VDE darf jetzt CVE-Nummern vergeben

Das rechtzeitige Wissen über Schwachstellen ist ein Kampf gegen die Zeit. Und: Mit dem Wissen hört es nicht auf, man muss ja auch noch identifizieren, ob man betroffen ist und dann entscheiden, was gegen die Schwachstelle zu tun ist (und ob überhaupt etwas zu tun ist).

Das als Unternehmen alles allein zu stemmen, ist eine Zeit- und Budgetfrage. Aber da Security-Probleme in der OT meist branchenübergreifend verschiedene Industrieunternehmen betreffen, kann man ihre Behandlung ja auch mit gemeinsamer Kraft stemmen - das ist die Idee des CERT@VDE. Dort können Industrieunternehmen ihr Wissen über Security-Probleme sammeln und sich über deren Lösung austauschen (CERT steht für Computer Emergency Response Team).

Das CERT hat nun einen wichtigen Schritt gemacht: Es ist nun eine CVE Numbering Authority (CNA) und darf damit international anerkannte Schwachstellen-IDs vergeben, sogenannte CVEs (Common Vulnerabilities and Exposures). Die eindeutige Benennung von Schwachstellen sorgt für Überblick im Schwachstellen-Dschungel und ist somit ein wichtiger Pfeiler in der effizienten internationalen Kommunikation von Security-Problemen, da ein und dasselbe Problem oft mehrfach gefunden wird.

Das CERT@VDE ist nun eine von acht CVE Numbering Authorities in Deutschland und eine von 127 weltweit. CVE wird von der US-amerikanischen Organisation MITRE verwaltet und besteht seit 1999.

7. Schwachstellen in OSI PI und Siemens SIPROTEC

Zwei Neuigkeiten von der OT-Schwachstellenfront:

Die erste ist vor allem für den Energiesektor relevant und betrifft Siemens SIPROTEC 5 Relays und die dazugehörige Engineering-Software DIGSI 5. Die Schwachstellen könnte ein Angreifer unter anderem nutzen, um schädliche Dateien hochzuladen. Siemens bietet kein Patch an, aber Workarounds: Port 443 blocken, rollenbasierte Zugangssteuerung und ein Passwort für die Verbindung im SIPROTEC aktivieren. Schön wäre ja, wenn das "by default" so wäre...
Und da wir heute schon über CVEs gesprochen haben: Die Schwachstellen haben die IDs CVE-2019-10930 und CVE-2019-10931.
Hier ist das Security Advisory des Siemens ProductCERT.

Die zweite ist ziemlich branchenübergreifend: Sie betrifft mit OSI PI ein weit verbreitetes Prozessdateninformationssystem. Eigentlich ist das auch nicht nur eine Schwachstelle, sondern gleich zehn, die das US-amerikanische ICS CERT in seinem Security Advisory bündelt.
Die Schwachstellen lesen sich wie ein Who is Who der Application Security-Schwachstellen: Falsche Default-Berechtigungen, nicht abgefangene Sonderfälle in Nutzereingaben, fehlende Input-Validierung, fehlerhafte Verifikation kryptografischer Signaturen. Gegen manche Schwachstellen hilft ein Upgrade, für andere gibt es Workarounds.
Das Security-Advisory des ICS CERT finden Sie hier.

8. Security-Engineering lernen in meinem IBF-Seminar

Genug gelesen, Sie wollen auch mal wieder mit echten Menschen über Security diskutieren? Ich auch, kann ich Ihnen sagen! Im Juli gibt's die Chance dazu.

In Kooperation mit IBF haben wir ein neues Seminar konzipiert: Security by Design für Maschinen und Anlagen.
In zwei Tagen lernen Sie rechtliche Grundlagen und Standards kennen und - viel wichtiger - bekommen Werkzeuge in die Hand, mit denen Sie Security für Ihr Problem auch umgesetzt bekommen. Wie geht Security Engineering so, dass es die Bezeichnung "Ingenieurdisziplin" verdient?
Wie fühlen sich Risikoanalysen weniger nach Glaskugel und mehr nach Werkzeug an?
Und was ist jetzt eigentlich mit der Security für Safety?

Das alles lernen Sie gemeinsam mit mir an Beispielen - idealerweise an solchen, die Sie selbst mitbringen. Das erste Seminar findet am 14. und 15. Juli als Webinar statt, im September und Dezember gibt's Präsenztermine – so Covid-19 uns denn lässt.

Stay secure!
Sarah Fluchs