Auf in den Sommer! Bislang sieht es so aus, als würde es der Sommer der Security-Veranstaltungen und Security-Warnungen, zumindest wenn man nach den Inhalten dieses Briefings geht.
Ach ja, und vielleicht geht es sogar mit dem Dauerbrenner NIS-2 voran...

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

1. Warten auf NIS-2: Offizieller Referentenentwurf und Verbändeanhörung
2. Runter von Shodan! Rockwell Security-Advisory der anderen Art
3. MITRE EMB3D
4. Mehr Nutzen aus Pentesting-Ergebnissen ziehen
5. BSI-Warnung zu Check Point Security Gateways
6. Frag den CEO ... zum Hackerangriff auf PSI
7. Warum Security by Design bald auf dem Boden der Tatsachen ankommt

1. Beinahe ein Generalschlüssel fürs Internet: Hintertür in xz utils

Nach vielen Leaks und Munkeln hat das Bundesinnenministerium (BMI) am 7. Mai selbst den 3. Referentenentwurf für das NIS2UmsuCG (NIS-2-Umetzungs- und Cybersicherheitsstärkungsgesetz) veröffentlicht (Lesestoff) sowie die Verbände zum Kommentieren eingeladen. Das gab natürlich recht viel Resonanz, denn die Auswirkungen von NIS-2 sind riesig: Der Tagesspiegel schreibt, schätzungsweise 30.000 Unternehmen seien betroffen. Der VDMA schätzt, dass 60 % der Maschinenbauunternehmen unter NIS-2 fallen, die Mehrheit davon KMU.

Sie wissen ja mittlerweile - das sind alles ungelegte Eier.
Kurzer Überblick über Diskussionsstand und Verbändemeinungen (basierend auf Berichten im Tagesspiegel und der Stellungnahme der AG KRITIS):

Lob:

• Nachweis für Nicht-KRITIS nur auf Anforderung des BSI: Der Geltungsbereich von NIS-2 ist riesig - neben kritischen Infrastrukturen (KRITIS) gibt es nun auch wichtige und besonders wichtige Einrichtungen (WE, BWE). Eine Sorge der Verbände war, dass sich nun die zehntausenden betroffenen Unternehmen alle regelmäßig Nachweise erbringen müssen. Das sieht der neue Entwurf nicht mehr vor: Wer nicht KRITIS ist, muss Nachweise nur noch auf Anforderung des BSI erbringen.
• Gemeinsame Meldestelle: Für Sicherheitsvorfälle jeder Art soll es gemäß aktuellem Entwurf eine gemeinsame Meldestelle für BSI und BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe geben).

Kritik:

• Harmonisierung mit dem KRITIS-Dachgesetz: Das KRITIS-Dachgesetz regelt physische Sicherheit, das NIS2UmsuCG Cybersicherheit. Beides ist schwer trennbar und das Risiko- und Krisenmanagement sollte aus einem Guss gedacht werden, fordert u.a. die AG KRITIS.
• Managerhaftung: Das NIS2UmsuCG sieht vor, dass Geschäftsführer persönlich für Schäden durch Cyberrisken haften und dies nicht an Dritte übertragen können. Viele Verbände, u.a. der VDA (Verband der Automobilindustrie), kritisieren das als "realitätsfremd".
• Scope des Risikomanagements: Gemäß aktuellem Entwurf sind alle IT-Systeme ins Risikomanagement einzubeziehen - und nicht wie in der bisherigen Gesetzgebung nur die, die für die regulierte Versorgungsdienstleistung erforderlich sind. Das geht für die Verbände am Schutzziel vorbei und schränkt - besonders bei der Beschaffung von Komponenten, für die es auch Vorgaben gibt - zu sehr ein.
• Sonderlocken für Staat und Verwaltung: Verwaltung auf Länder- und Kommunalebene ist vom Geltungsbereich ausgeschlossen. Ich erinnere mich dabei an die Worte von Daniel Strauß und Max Greger beim DSLAM in Leipzig letzte Woche: Wenn eine Bundesbehörde mal ein paar Tage nicht mehr da ist...das merkt wahrscheinlich keiner. Aber wenn die Kommune nicht da ist, dann können Bürger plötzlich nicht mehr sterben, heiraten, geboren werden..... zumindest offiziell. Hm.
• Authentizität ist kein explizites Schutzziel mehr: Das bemängelt die AG KRITIS, vor allem, weil die Verletzung der Authentizität dann nicht mehr als Sicherheitsvorfall zu bewerten wäre. In bisherigen NIS2UmsuCG-Entwürfen und auch in der bisherigen KRITIS-Gesetzgebung ist die Authentizität explizit als Schutzziel aufgeführt (als eigentlich eher unübliche Ergänzung der drei klassichen Schutzziele Verfügbarkeit, Vertraulichkeit und Integrität).
• Und natürlich: Bürokratie, Bürokratie, Bürokratie - vielen haben Sorge, dass sie in Dokumentations- Nachweis- und Meldepflichten erstickt werden.

Insgesamt werden die grundsätzliche Notwendigkeit und die inhaltlichen Anforderungen der Gesetzgebung kaum infrage gestellt. Zitat Tagesspiegel: "Während von Anfang viel über den Anwendungsbereich und konkrete Auslegungsfragen diskutiert wurde, stören sich die wenigsten an den konkreten Anforderungen zum Sicherheitsmanagement."

Und jetzt?

Na, eigentlich müsste das NIS2UmsuCG bis Mitte Oktober in Kraft sein, wenn man die EU-Frist einhalten wollte. Das hält aber schon länger niemand mehr für realistisch. Bald hat der Bundestag auch Sommerpause...wenn es vorher noch Fortschritte geben soll, müssten ein finaler Regierungsentwurf spätestens in der ersten Juliwoche auf die Agenda des Bundestags und Bundesrats, schreibt der Tagesspiegel, und dann kommt noch die Notifizierung der EU-Kommission, die mindestens drei Monate dauert.

Wenn NIS-2 in Kraft ist, sollen die Anforderungen gemäß aktuellem Entwurf ohne Übergangsfrist gelten.

Dann beobachten wir mal weiter und bleiben bei (siehe Hard Hats-Briefing aus dem März):

2. Runter von Shodan! Rockwell-Security-Advisory der anderen Art

Security-Advisories von Herstellern gibt es in der Regel, wenn neue Schwachstellen in Produkten bekannt werden. Im Mai hat Rockwell aber ein anders geartetes Security-Advisory veröffentlicht (Lesestoff 1). Darin werden zwar auch Schwachstellen für diverse Rockwell-Produkte referenziert, aber keine davon ist neu.
Der Anlass für das Advisory ist vielmehr die geopolitische Lage und die beobachtete Angreiferaktivitäten, und Rockwell mahnt alle Kunden, für alle Rockwell-Produkte zu überprüfen, ob sie das öffentlich auffindbar im Internet sind - und falls ja, das sofort zu ändern (Ausnahme: dedizierte Cloud-/Edge-Geräte, die dafür gemacht sind, im Internet zu stehen).

Die US Cybersecurity and Infrastructure Security Agency (CISA) verbreitet die Rockwell-Meldung auch als eigenes Advisory und legt noch eine Anleitung bei (Lesestoff 2), die den schönen Titel "Stuff Off Shodan" trägt (übersetzt etwa: "Runter von Shodan mit eurem Kram!").
Shodan ist eine Art Suchmaschine für Geräte, die direkt mit dem Internet verbunden sind - wenn die eigenen (OT-)Geräte dort auftauchen, ist das also in der Regel keine gute Nachricht.

3. MITRE EMB3D

MITRE ist ja bekannt für fancy Akronyme mit Zahlen und Sonderzeichen: ATT&CK, D3FEND.
Nun gibt's erstmals eine spezifisch für OT: EMB3D (Lesestoff).

EMB3D ist ein Bedrohungsmodell für eingebettete Systeme wie Steuerungen, Microcontroller und (I)IoT. Im Unterschied zu MITRE ATT&CK beschreibt es nicht Angriffsschritte anhand einer Kill Chain, sondern geht von einer "Properties List" aus, also einer Liste typischer Eigenschaften eingebetteter Systeme. Je Eigenschaft gibt es zugeordnete Bedrohungen und Mitigations. MITRE legt Ihnen also im übertragenen Sinn einen Hacker-Hoodie neben Ihre eingebettenen Devices bereit und macht es Ihnne leichter, die Angreiferperspektive einzunehmen.

Das mit den Properties ist ein interessanter Ansatz, um Bedrohungen individueller auf bestimmte Systeme zuzuschneiden (und sehr ähnlich zu dem Security-Parameter-Ansatz, der auch Teil der Forschungsergebnisse unseres Security-by-Design Projekts "IDEAS" ist).

4. Mehr Nutzen aus Pentesting-Ergebnissen ziehen

Ist das hier ein gutes Symbolbild für Ihre Pentesting-Ergebnisse?

Da sind Sie wahrlich nicht allein. Viel zu oft landen die Berichte dann in der (digitalen) Schublade und dienen als Baugerüst für Spinnweben. Und wenn man den Pentest ein Jahr später wiederholt, könnte man den Bericht eigentlich 1:1 kopieren und nur das Datum austauschen. Wer hat schon Zeit, die 197 Detail-Findings abzuarbeiten?

Warum das eigentlich so ist und wie man das besser hinbekommen kann, das analysiert Dietmar Marggraff sehr ausführlich in einem Blogpost (Lesestoff).

Drei gute Tipps, die ich mitgenommen habe:

1. Vorher überlegen, wie man den Pentest mit bestehenden Prozessen verzahnen kann. Was sind eigentliche sinnvolle Auslöser für Pentests? Und, vielleicht noch wichtiger: In welche Prozesse fließen die Ergebnisse eines Pentests?
   Wie können sie ins Risikomanagement einfließen, zum Beispiel weil Risiken anderes bewertet werden müssen? Ins Patchmanagement, weil offenbar wurde, dass bestimmte Software oder Protokolle nicht aktualisiert worden sind? In Awareness-Trainings, weil gegen manche Findings einfach nichts hilft außer ein wacher Nutzer?
   Das sind viel besserer, weil nachhaltigere Fragen, als mal eben schnell das fehlende Patch zu installieren und damit das Symptom, nicht aber die Ursache zu beheben.
2. Den Test-Scope aus Business-, nicht aus technischer Sicht definieren: Der nächste Pentest steht an - was testen wir diesmal? In der Regel ist die Antwort auf die Frage eine Liste von IP-Adressen. Und oft ist die Liste länger (und damit teurer), als sie sein müsste - und spart zum Leidwesen der Tester die eigentlich interessanten Server trotzdem aus.
   Das geht besser: Dietmar schlägt vor, vor einem Pentest darüber nachzudenken, für welche wichtigen Geschäftsprozesse eigentlich die Resilienz getestet werden soll - und dann gezielt zu überlegen, welche Systeme (aka IP-Adressen) für diese Geschäftsprozesse problematisch werden können. Auch gut: Den Pentestern ein Ziel mitgeben, das sie versuchen sollen zu erreichen ("klaut die Daten von Kunde XY").
3. Die Ergebnisse des Pentests so kommunizieren, dass das Management etwas damit anfangen kann: Scheitert die Behebung der Pentests-Findings an den Ressourcen? Dann müssen die Ergebnisse so kommuniziert werden, dass das Management versteht, warum die Behebung wichtig ist. Das funktioniert nicht auf Finding-Ebene. Auch nicht, weil ein CVSS-Score rot leuchtet. Sondern genau dann, wenn man - siehe oben - dem Management klar machen kann, wie ein Finding sich auf wichtige Geschäftsprozesse auswirken kann.
   Pentester haben üblicherweise nicht genug Kontext, um das herauszuarbeiten. Es gibt zwei Möglichkeiten, es trotzdem zu tun: Entweder Pentestern die nötigen Informationen geben - oder es selbst tun.

(Bonustipp für alle, die das Thema spannend finden, aber nicht viel Zeit zum Lesen langer Texte haben haben: Im Blog wenigstens die Grafiken anschauen, die sind ein sehr gutes Destillat des Inhalts.)

5. BSI-Warnung zu Check Point Security Gateways

Sie haben sie Anfang Juni wahrscheinlich auch erhalten: Die BSI-Warnung CSW-Nr. 2024-248589-10F2 mit dem Titel "Check Point Security Gateways: Abfluss von Zugangsdaten möglich" (Lesestoff 1).

Check Point stellt Security-Appliances her: Firewalls, Intrusion-Detection, VPN-Gateways ud so weiter. Also alles, was man sich so ins Haus holt, um sicherer zu werden.

...außer, die Geräte bringen einem neue Schwachstellen ein. Und genau das ist bei den betroffenen Produkten der Fall.

Check Point hat am 26. Mai ein Security-Advisory zur Schwachstelle herausgegeben und auch bekannt gemacht, dass die Lücke bereits seit dem 7. April aktiv ausgenutzt wird.
Die Schwachstelle hat es in sich: Bei betroffenen Check Point-Geräten kann man aus der Ferne und ohne Authentifizierung mit root-Rechten beliebige Daten auslesen. Was das sein könnte? Na, Benutzernamen, Passwörter und VPN-Zugangsdaten zum Beispiel.
Natürlich nur, wenn die Systeme im Internet sind...aber das sind sie natürlich oft, denn das ist ja ihr Job.

Also: Eine Schwachstelle, bei der es sich lohnt, hinzuschauen. Stephan Gerling hat das für Sie erledigt - siehe Lesestoff 2.

Fun fact: Checkpoint empfiehlt, vor das verwundbare Checkpoint Gateway.....Trommelwirbel....ein Checkpoint-Gateway zu stellen. Oder wie Stephan schreibt: Auf das Schlangenöl noch ein bisschen mehr Schlangenöl zu werfen.

6. Frag den CEO ... zum Hackerangriff auf PSI

Das Programm für SECURITY UNTER KONTROLLE (SuK) steht ja schon eine Weile fest (siehe Lesestoff) und Tickets kann man auch schon kaufen.

Bei einer der Keynotes stand aber noch "to be announced".... jetzt nicht mehr.
Ich freue mich kolossal, dass wir Robert Klaffus, President und CEO von PSI Software, als Keynote-Speaker gewinnen konnten.

Wie aufmerksame Leser des Schutzhelmbriefings (und alle Kunden von PSI sowieso) wissen, gab es im Frühjahr 2024 einen Hackerangriff auf PSI.
PSI hat sich für eine ungewöhnlich transparente Krisenkommunikation an die Öffentlichkeit entschieden; auf der Übergangswebsite konnte man Details zum Angriff und den Stand der Wiederherstellung verfolgen. Wie sich der Angriff und vor allem die Phase danach „von innen“ anfühlte, was gut lief, was schlecht lief und was er aus all dem gelernt hat, das wird Robert Klaffus auf der SuK-Bühne teilen.

Security-Vorfälle werden oft (verständlicherweise) eher unter der Decke gehalten, mit viel glattgebügelter Kommunikation und wohldosierten Informationshäppchen. Deswegen kann man Robert Klaffus gar nicht laut genug dafür applaudieren, dass er auf unsere Bühne kommt.

Wir wissen, wie sehr der Vorfall PSIs Kunden bewegt hat. Deswegen überlegen wir, im Anschluss an die Fragerunde nach der Keynote auch noch privatere Frage-und-Antwort-Sessions mit Robert Klaffus am Rande des Kongresses zu organisieren. Dafür sammeln wir gerade ein Stimmungsbild: Hätten Sie Interesse daran? (Bonusfrage: Was interessiert Sie?). Einfach kurz auf diese E-Mail antworten.

5. BSI-Warnung zu Check Point Security Gateways

...und dann war ich noch bei Nico Werner im Podcast "Cybersecurity ist Chefsache" zu Gast. Bei Nico dürfen die Zuhörer abstimmen, über welches Thema wir sprechen - und für mich haben sie sich Security by Design gewünscht.

Nico hat wirklich gute Fragen gestellt, über die ich immer wieder nachdenken musste. Vor allem seine Glaskugelfrage am Ende des Podcasts: "Wohin, glaubst du, geht die Reise für Security by Design in den nächsten Jahren?"

Meine Antwort, aus dem Bauch heraus: Ich glaube, Security by Design wird - durchaus hart - auf dem Boden der Tatsachen aufkommen. Momentan reden alle darüber. Weil es viele Supply-Chain-Angriffe gab. Weil die CISA in den USA Wirbel dazu macht. Weil es nun verpflichtende Regulierungen gibt, die Security by Design fordern.
Alle reden über Security by Design, aber keiner macht's.

Nun tritt die ganze Regulierung in Kraft, CRA, RED, UNECE R155, PSTI und wie sie alle heißen, und plötzlich muss Butter bei die Fische. Unternehmen müssen sich real überlegen, wie sie Security by Design umsetzen.

Das wird unperfekt. Das wird nicht so schick wie in White Papern und auf Websites. Es wird unsexy, mühsam, kleinteilig und langsam. Aber es wird uns viel mehr weiterbringen als die jahrelange Buzzwordphase.
Ganz ehrlich: Ich freu mich drauf, zu sehen, wie Security by Design in echt aussieht, es hundert Mal umzusetzen unter anderem mit den Methoden, die wir in den letzten 3 Jahren erarbeitet haben - und jedes Mal ein bisschen besser zu werden.

Und in 5 Jahren machen wir noch mal einen Security by Design-Podcast und lachen über die Aussagen von heute. Das wird ein Spaß!

Link zur Podcast-Folge bei YouTub siehe unten...und ansonsten auch überall, wo es Podcasts gibt.

Stay secure!
Sarah Fluchs