Aufgrund des Feiertags eine Woche später begrüße ich Sie ganz herzlich im Herbst. Wie jeden Monat gibt es ein Thema, in dem ich mich viel länger festgelesen habe als geplant - dieses Mal ist es das Systems Security Engineering für cyber-physische Systeme. Systems Engineering finde ich ja total sympathisch....aber kann es mir praktisch kaum vorstellen. Vielleicht kann ja jemand in der Leserschaft helfen?
Neben diesem dicken Brett strotzt dieses Briefing nur so vor guten Nachrichten - in unserem Miesmacherthema Security ist das ja alles andere als selbstverständlich. Das BKA versprüht Optimismus für das Finden von Cyberkriminellen, die EU macht Nägel mit Köpfen beim Cyber Resilience Act, wir haben nach drei Jahren Security-by-Design-Forschung erste Ergebnisse - und einen Veranstaltungstipp für das schöne Kopenhagen habe ich auch noch. Klingt nach einem Plan? Dann los.

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

1. Security-by-Design-Tool: Erste Validierungsergebnisse veröffentlicht
2. SAE JA7496: Systems Security Engineering für Cyber-Physical Systems
3. Cyberkriminelle findet man sowieso nicht? Gute Nachrichten!
4. Cyber Resilience Act: Verhandlung über finalen Text hat begonnen
5. Industrial Security Conference in Kopenhagen

1. Security-by-Design-Tool: Erste Validierungsergebnisse veröffentlicht

Ich beginne den Oktober mal mit dem Thema, in dem mein Kopf momentan sowieso ständig steckt: Security by Design, beziehungsweise unser Forschungsprojekt IDEAS.
Wir haben nämlich die dritte Validierungsrunde für unser modellbasiertes Security-by-Design-Tool hinter uns gebracht. Drei Testläufe liegen hinter uns: Mit der Integrations- sowie der Entwicklungsabteilung bei HIMA Paul Hildebrandt GmbH, einem Hersteller, und mit der Engineeringabteilung bei INEOS in Köln, einem Betreiber.

Die Validierungsphase hat unser Forschungsteam einiges an Schweiß und Tränen gekostet:

Die Methodenentwickler, weil es etwas ganz anderes ist, eine Methode in ein hübsches Paper zu schreiben und sie dann tatsächlich praktisch nutzbar zu machen...
Die echten Systeme der Kunden sehen dann doch anders aus alle Demo-Daten ("wie bilden wir das denn jetzt ab?"), die echten Security-Entscheidungen nehmen viel verschlungenere Wege als man sich das am Reißbrett überlegen kann...und vor allem denken Anwender einer Methode oder eines Tools ja doch immer anders, als man es sich vorher ausgedacht hat.
Die Softwareentwickler, weil in so einem Forschungsprojekt sich die Anforderungen der Nutzer noch schneller verändern als im normalen Softwaredesign ohnehin schon ("was interessiert mich mein Geschwätz von gestern?" können sie wahrscheinlich nicht mehr hören....).

Wir sitzen gerade im Maschinenraum und werten die Ergebnisse der letzten beiden Validierungsrunden aus, aber in der Zwischenzeit habe ich Lesestoff für Sie: Die Ergebnisse der ersten Validierungsrunde sind nämlich zwischenzeitlich auch auf Deutsch veröffentlicht worden, und zwar bei der Zeitschrift "at - Automatisierungstechnik". Link im Lesestoff 1. Auf Englisch gibt es die Ergebnisse schon eine Weile beim Journal "Sensors" - siehe Lesestoff 2.

2. SAE JA7496: Systems Security Engineering für Cyber-Physical Systems

Wenn neue Standards auftauchen die Cybersecurity in Engineering-Prozesse integrieren wollen, bin ich ja immer ganz Ohr. Insofern habe ich mich sehr über den Hinweis von Kenneth Crowther auf den Standard SAE JA7496 gefreut, der gerade in der Überarbeitung für seine zweite Version ist.

Wer schreibt den Standard?
Die SAE ist eine gemeinnützige Organisation, in dem vor allem die Automobil- und Luftfahrtbranche organisiert ist und Standards schreibt.

Worum geht's?
Achtung, neue Abkürzung: Der Standard beinhaltet einen "Cyber-Physical Systems Security Engineering Plan (CPSSEP)". Was das bedeutet? Cybersecurity soll in den Engineering-Lebenszyklus von Cyber-Physical Systems (CPS) integriert werden.

Was sind Cyber-Physical Systems?
"Cyber-Physical Systems" oder auf Deutsch cyberphysische Systeme sind ungefähr so etwas wie OT, aber der Begriff ist nach meiner (subjektiven) Erfahrung eher in akademischen und Standardisierungskreisen verbreitet. Eigentlich ein schönerer Begriff als OT (zumindest, wenn man sich einmal zähneknirschend mit der Verwendung von "cyber" für "alles mit Computern" angefreundet hat...), denn er trägt die Erklärung direkt in sich: Gemeint sind Systeme, die sowohl mit der physischen Welt als auch mit der "Cyber"-Welt interagieren. Also alles, was im Weitesten Sinne Sensorik und Aktorik hat.

Und was ist Systems Security Engineering?
Systems Security Engineering bedeutet, Security in die Prinzipien des Systems Engineering zu integrieren. Wenn Standard von "Systems Engineering" sprechen, meinen sie in der Regel die Prozesse, die in der ISO/IEC/IEEE 15288 definiert werden, so auch in diesem Fall. Es gibt außerdem ein NIST-Dokument (NIST SP 800-160), das Security-Erweiterungen für diese Prozesse definiert; auch auf diesem baut der vorliegende Standard auf. Er stellt also eine Alternative / Verfeinerung (?) zu den bestehenden Systems Engineering Standards speziell für cyberphysische Systeme dar.

Was ist der Kern des Standards?
Der Kern des Standards ist eigentlich nur ein Kapitel, das für ausgewählte Systems-Engineering-Prozesse aus der ISO/IEC/IEEE 15288 erklärt, wie dort Security untergebracht werden sollte. Im Prinzip kann man das zusammenfassen als eine sehr ausführliche Erklärung, wie Teile einer Risikoanalyse in wirklich allen Engineering-Phasen eines Systems untergebracht werden müssen. Systems Engineering legt den Begriff "Engineering" sehr weit aus, sodass er neben klassischen Engineering-Prozessen wie Anforderungsdefinition, Architekturdefinition, Systemanalyse und Integration auch Betrieb, Wartung und Entsorgung umfasst.
Für viele Prozesse ist logisch, wie man dort eine Risikoanalyse unterbringt. Architekturdefinition? Klar, Risikoanalyse der Architektur. Aber an einigen Stellen haut der Standard dann doch echte Klopper quasi im Nebensatz raus: Security Assurance Level sollen während der Anforderungsdefinition festgelegt werden. Puh! Darüber zerbricht sich die ISA mit ihren Security Leveln seit einem Jahrzehnt kollektiv den Kopf.

Übrigens fährt der JA7496 damit eine andere Strategie als die von ihm referenzierte ISO/IEC/IEEE 15288. Dort ist das Thema Risikomanagement nämlich ein eigener Prozess anstatt einer Ergänzung in jedem anderen Prozess. Ist wohl eine Philosophiefrage.

Brauchte die Welt diesen Standard?
Weniger provokativ formuliert: Was hat dieser Standard, was bestehende Standards nicht haben?

Erstens: Eine explizite Ergänzung der Systems Engineering-Prozesse der ISO/IEC/IEEE 15288 um Security-Aspekte (genauer: eine Security-Risikoanalyse) gibt es bislang wohl nirgends sonst. Das ist der Kern des Standards, und der ist neu.

Zweitens: Was andere Security-Standards von dem rigorosen Systems-Engineering-Ansatz des Standards lernen können, ist die klare Formulierung von "Assurance Requirements", die dann auch nachverfolgt und abgenommen werden. Klare, messbare Security-Ziele direkt neben den funktionalen und sonstigen nicht-funktionalen Anforderungen - das wäre ein großer Fortschritt. Zwei weitere Standardteile mit testbaren "assurance requirements" für Hardware und Software werden gerade erarbeitet. Diesen Schubs in die Engineering-Richtung tut der Security gut.
Und: Solche "assurance requirements" werden spätestens dann wirklich wichtig, wenn die Marktzulassung von Produkten davon abhängt - der Cyber Resilience Act (siehe unten) lässt grüßen.
Also ja - schon für diese zwei Punkte hat der Standard seine Daseinsberechtigung.

Auch positiv: Der JA7496 beschränkt sich wirklich (fast) auf diese Aspekte und definiert wenig Bestehendes neu. Ausnahme: Die "Domains of Consideration" - das ist im Prinzip eine Liste von Kategorien für Security-Maßnahmen. Gibt es tausendfach, ist nicht neu. Dasselbe gilt für den langen Anhang, der unter anderem Risikoanalysemethoden detailliert beschreibt. Nichts Neues, nicht zum ersten Mal aufgeschrieben - aber Praktiker freuen sich vermutlich darüber, und immerhin ist das Ganze im Anhang gelandet.

Hier könnte ich enden, wenn ich nicht immer wieder bei meinem generellen Systems-Engineering-Problem landen würde - obwohl ich mit dem Ansatz durchaus sympathisiere: Systems Engineering bedeutet, dass man einen Haufen detaillierter Prozesse befolgen muss, oder um es deutlicher zu machen: Einen großen Haufen - 28 Prozesse in der ISO/IEC/IEEE.

Hier ist das Problem: Ich habe Systems Engineering noch in keinem Unternehmen umgesetzt gesehen. Klappt das wirklich irgendwo (außerhalb von Raketenforschung)? So richtig etabliert im Alltag?
Ernst gemeinter Aufruf: Wenn Sie Systems Engineering wirklich leben oder jemanden kennen, der es lebt - melden Sie sich. Ich wäre super gespannt auf einen Einblick.

Und wenn ich Systems Engineering dann mal live und in Farbe gesehen habe, fällt es mir vielleicht auch leichter zu beurteilen, ob jemand den JA7496 tatsächlich anwenden wird - und ob die Philosophiefrage "Risiko in jeden Prozess statt Risiko als Prozess" überhaupt praktische Auswirkungen hat.

Document Stage?
Diese Information darf zu einem Standard nicht fehlen, also voilà: Die erste Version des JA7496 ist bereits veröffentlicht (Link im Lesestoff, man muss den Standard aber kaufen), der Entwurf für die zweite Version ist noch Work in Progress.

3. Cyberkriminelle findet man sowieso nicht? Gute Nachrichten!

Es ist immer eine gewisse Resignation im Raum spürbar, wenn es um die Verfolgung der Kriminellen hinter einem Cybersecurity-Angriff geht: Findet man eh nicht, unsere Polizei ist dafür gar nicht gerüstet, und im Zweifel war's ja eh Russland.

Zeit für ein paar gute Neuigkeiten:

1. Durch internationale Kooperation konnte das Botnetzwerk Qakbot zerschlagen werden. Das Bundeskriminalamt (BKA) und die Generalstaatsanwaltschaft haben in Kooperation mit den USA, Frankreich, Niederlanden, Grißbritannien und Europol / Eurojust die Infrastruktur der Kriminellen übernommen. Zum Botnetz gehörten zuletzt über 700.000 Rechner, die für Cyberangriffe gebucht werden konnten, meist, um einen Zugang zu Firmennetzwerken zu erhalten und später Ransomware zu installieren. "Malware as a service" heißt dieses florierende Geschäftsmodell.
   Solche Ermittlungserfolge sind durchaus keine Einzelfälle mehr.
2. Die Tools der deutschen Ermittlungsbehörden sind besser als öffentlich bekannt: IT-Rechtsanwalt Jens Ferner analysiert auf LinkedIn anhand von Pressemitteilungen des LKA und BKA, dass das BKA offenbar eine "Cybertoolbox" hat, die zum Beispiel den Fluss von Kryptowährungen nachvollziehen kann. Das ist ein mächtiges Werkzeug, denn Cyberkriminelle verwenden Kryptowährungen wie Bitcoin beispielsweise für Ransomware-Zahlungen. Sind die Zahlungen nachvollziehbar, hat man eine Spur zu den Angreifern.
3. Anzeige (gegen Unbekannt) nach einem Cyberangriff zu erstatten ist sinnvoll: Kein* Mensch / Unternehmen erstattet nach einem erlittenen Cyberangriff Anzeige (*genauer: 10%). Bringt eh nichts, es macht nur Arbeit und dann wird das Verfahren ja doch eingestellt, so der Tenor. Das stimmt zwar oft - es sei aber ein Mythos, dass nichts passiert, erklärt Markus Hartmann, Leiter der Zentralen Ansprechstelle Cybercrime (ZAC) der Justiz in NRW gegenüber dem Tagesspiegel. Bei den polizeilichen Ermittlungen werde fast immer das Einfallstor für den Angriff gefunden. Die Polizei statt ein teurer Dienstleister für das Finden der Schwachstelle nach einem Angriff? Zumindest ein Gedanke wert. Wenn möglich, so Hartmann weiter, werde auch versucht, eine Spur zu den Angreifern zu finden, zum Beispiel über Bitcoin-Konten - siehe 2. Und wenn es Lösegeldforderungen gib, hat die Polizei Verhandlungsexperten.
4. Nicht immer war es Russland: Ob das jetzt eine gute Neuigkeit ist, weiß ich auch nicht - aber es ist zumindest eine Abwechslung in all den Berichten über "mutmaßlich russische" Hackerangriffe: Hakan Tanriverdi berichtet für den Spiegel von einem Angriff der chinesischen Hackergruppe APT15 auf das Bundesamt für Kartographie und Geodäsie - und darüber, dass chinesische Hacker insgesamt unterschätzt werden. Und: Bei kleineren Ransomware-Angriffen (die deutsche Unternehmen oft plagen, es aber eher selten in die Schlagzeilen schaffen) ist es natürlich ohnehin nicht immer Russland.

Also, Memo an alle (inklusive mich selbst), die beim Thema Verfolgung von Cybersecurity-Angreifern schnell in die "bringt eh nix"-Leier einrasten: Es ist Zeit, das Default-Schulterzucken zu überdenken. Vielleicht kommt die Zeit für vorsichtigen Optimismus?

4. Cyber Resilience Act: Verhandlung über finalen Text hat begonnen

Am 27. September war ein großer Tag: Erstmals sind EU-Kommission, Rat und Parlament zusammen, um über den finalen Gesetzestext des CyberResilienceAct zu beraten. Die EU-Kommission hat einen Vorschlag gemacht, Rat und Parlament haben ihre Positionen aufgeschrieben - und nun muss ein Kompromiss gefunden werden.

Sie ahnen schon - das ist wahrscheinlich nicht in einem Tag gegessen. Es sind noch drei weitere Termine angesetzt: 8. November, 30. November und 12. Dezember. Das Ziel ist, im ersten Quartal 2024 fertig zu sein, damit der CRA verabschiedet werden kann, bevor das EU-Parlament im Juni 2024 neu gewählt wird.

Wenn der CRA verabschiedet ist, kann auch der Standardization Request (SReq) offiziell gestellt werden. Die Antwort der europischen Standardisierungsorganisationen CEN/CENELC auf den Standardization Request legt fest, welche Standards für die Erfüllung des CRA maßgeblich sind.

Bislang gibt es nur eine Entwurfsfassung des SReq, mit der sich eine CEN/CENELEC-Arbeitsgruppe am 22.09. erstmals befasst hat (ich war dabei). Auch zum Entwurf gibt es schon über 90 Kommentare.

Eine kurze Zusammenfassung zum Trilog, den wichtigsten Verhandlungspunkten und zum weiteren Zeitplan hat Steffen Zimmermann vom VDMA in einen LinkedIn-Post geschrieben - siehe Lesestoff.

5. Industrial Security Conference in Kopenhagen

Zu guter Letzt noch ein Terminhinweis für November: Am 14. Und 15. November findet die “Industrial Security Conference” in Kopenhagen statt.

Die Konferenz ist in den letzten Jahren zu einer der herausstechenden europäischen OT-Security-Veranstaltungen geworden, und auch dieses Jahr sieht das Programm gut aus. Erwartungsgemäß ist die NIS2-Direktive dieses Jahr ganz hoch im Kurs, aber auch praktischere Themen sind vertreten: Case studies zu Security by Design, wie man ein SOC aufbaut oder auch wie man Security in Abnahmetests (SAT / FAT) überprüft.

Ich selbst bin leider nicht vor Ort, freue mich aber ganz besonders, hier den Vortrag meines Kollegen Tobias Halmans ankündigen zu dürfen: Er wird am Dienstagnachmittag darüber sprechen, wie Security by Design durch Wiederverwendung von Security-Lösungen effizienter werden kann. Der Teufel steckt da nämlich im Detail, wie wir in den letzten drei Jahren Security-by-Design-Forschung feststellen durften: Was macht überhaupt Sinn wiederzuverwenden? Wie müssen Lösungen dokumentiert werden, damit man sie wiederverwenden kann? Und wie bekommt man die Wiederverwendung so organisiert, dass sie tatsächlich schneller geht als "mal eben neu machen"?

Wenn Sie nun Lust auf einen Trip nach Kopenhagen bekommen haben: Man kann sich noch registrieren. Ich haben Ihnen das Programm im Lesestoff verlinkt.

Stay secure!
Sarah Fluchs