Der Cyber Resilience Act (CRA) fordert, dass bald fast jedes digitale Produkt, das in der EU verkauft werden soll, Security-Anforderungen erfüllt. Damit ist die Regulierung ist weltweit ein Vorreiter für Product Security. Benjamin Bögel hat in der EU-Kommission an dem gesamten Entstehungsprozess des CRA mitgewirkt: Gesetzentwurf, Verhandlung mit Verbänden und Lobbyisten, Trilog-Verhandlungen zwischen der europäischen Kommission, Parlament und Rat, und die Anforderung harmonisierter Standards bei den Standardisierungsorganisationen. Er erklärt, was hinter den Formulierungen im CRA steckt, welche Themen besonders strittig waren, wie es nun weiter geht – und was das alles nun für (OT-)Produkthersteller bedeutet.

Mit der europäischen NIS-2-Richtlinie ist Security plötzlich für viel mehr Unternehmen verpflichtend als die bisherigen kritischen Infrastrukturen (KRITIS): Unter anderem Maschinenbau und Produktion, Herstellung und Handel mit chemischen Stoffen werden explizit als relevante Sektoren erwähnt und viele Mittelständler fallen unter NIS-2, zum Beispiel wenn sie mehr als 50 Mitarbeitende haben und dann als wichtige Einrichtungen oder besonders wichtige Einrichtungen gelten.

Was genau von NIS-2 betroffene Unternehmen in Deutschland nun tun müssen, definiert das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz – NIS2UmsuCG. Gemäß EU-Vorgabe sollte das Gesetz eigentlich bis 17.10.2024 in Kraft treten, aber schon jetzt ist klar, dass es sich mindestens um zwei Monate verzögern wird.

Manuel Atug ist in Politik und Verbänden gut vernetzt und teilt seinen „Blick in den Maschinenraum“ zum aktuellen Stand der NIS-2-Umsetzung in Deutschland: Wo stehen wir, was sind besonders herausfordernde Anforderungen, was wird heiß diskutiert – und warum dauert das eigentlich alles so lange?

Keine andere Maßnahme ist so direkt in der KRITIS-Gesetzgebung vorgeschrieben: Die „Systeme zur Angriffserkennung“ haben Betreibern kritischer Infrastrukturen in den letzten Jahren Kopfzerbrechen bereitet. Aber die „SzA“ sind nicht nur für kritische Infrastrukturen Pflicht. Sie sind auch in ähnlichen Formulierungen in der Gesetzgebung wie NIS2 oder Normen wie der aktuellen ISO/IEC 27001 oder unter der Haube in der ISA/IEC 62443 enthalten.

Muss man, um Systeme zur Angriffserkennung umzusetzen, ein teures Tool kaufen? Christian Arlt entwirrt das komplexe Thema und den Gesetzestext dazu und schlägt 10 leicht umsetzbare Maßnahmen vor, die schon genügen, um die berühmten „Systeme zur Angriffserkennung“ umzusetzen.

Kein Hersteller hat Freude daran, seinem Kunden mitzuteilen, dass es ein Problem mit dem Produkt gibt. Ein gutes Security-Advisory liefert dem Kunden aber mehr als nur das Problem. Details, Kontext und Einschätzungen des Herstellers sind unerlässlich, um das Problem begreifen und behandeln zu können. Mit maschinenlesbaren Security-Advisories werden neue Möglichkeiten eröffnet, viel manuellen Aufwand auf Hersteller und Kundenseite einzusparen. Um ihr volles Potenzial auszuschöpfen, braucht es aber mehr als eine reine Konvertierung in das maschinenlesbare Format. Sören Finster zeigt die Voraussetzungen und Herausforderungen auf Herstellerseite, stellt Lösungsansätze vor und klärt auf, welche Rolle CPE, SBOMs, CVEs und sichere Software-Entwicklungsprozesse (SDL) spielen.

Theoretisch kann ein Betreiber basierend auf einem maschinenlesbaren CSAF-Security-Advisory automatisch prüfen, ob die Schwachstellen für seine Anlage relevant sind.

Praktisch holpert das noch: Denn eindeutige Produktbezeichnungen fehlen. Bis es die gibt, hilft nur ein Abgleich auf Basis von anderen Attributen. Klaus Biß hat in den vergangenen Jahren Open-Source-Projekte sowie Abschlussarbeiten für eine bessere Geräteidentifikation im industriellen Umfeld betreut und erklärt, was funktioniert, was nicht und was wir in Zukunft brauchen: Welche Attribute stehen zur Verfügung und welche wären praktisch? Was sind Informationsquellen für Geräte-Attribute und wie gleicht man sie ab (wie exact match, regex, fuzzy? Wie könnte KI dabei helfen? Und löst das digitale Typenschild all diese Probleme?

2016 stand Stephan Gerling vor der Aufgabe, eine 30m-Yacht mit Internet auf See auszustatten. Seitdem hat er die IT auf mehreren Yachten inspiziert, Sicherheitsprobleme entdeckt und den Herstellern gemeldet.

In so einer Yacht steckt mehr OT, als man auf den ersten Blick denkt: Da gibt es Steuerungen, Sensorik und Rechnersysteme für die Antriebsaggregate im Maschinenraum, für die Stromversorgung, für die Stabilisierung des Schiffes auf der Wasserlinie, für Antriebswelle und Propeller – und natürlich für die Navigation. Und ein „Office-Netz“ gibt es natürlich auch, denn Crew und Gäste erwarten natürlich Internet.

Wie interagieren all diese Systeme? Wie bekommen sie eigentlich Updates? Wie geht Fernwartung auf See? Stephan Gerling gibt Einblicke in eine seltener betrachtete OT-Umgebung, in der technische Superlative und „Old-School-OT“ friedliche koexistieren.

In fast jedem Unternehmen steckt mittlerweile OT. Häufig wird deren Funktionalität als selbstverständlich erachtet. Selten hat man diese bei der klassischen Absicherung (IT-/OT-Security) oder innerhalb einer Krise (Cyberangriff) „auf dem Schirm“. Die daraus resultierenden Konsequenzen bekommen wir bei unseren zahlreichen Incident Response Einsätzen oft zu spüren.

Was ganz lustig erscheinen mag, ist in der Realität ein wahrer Albtraum: Plötzlich steht man vor einem verschlossenen Gebäude und kommt nicht mehr rein. Tja, wer weiß denn jetzt wo der Notschlüssel ist - hoffentlich nicht im Gebäude? Die Einbruchmeldeanlage als dein Feind bei Einbrüchen ins Gebäude, aber dein Freund bei Einbrüchen ins IT-Netzwerk. Und bei der USV kann man doch mal eine Ausnahme machen, allow Any:Any und Root/Dom-Admin klingt gut!

Neben spannenden Geschichten aus der Incident-Reponse-Praxis lädt Vincent Rockenfeld dazu ein, einen Blick auf die Gefahren solcher „übersehener“ OT und mögliche Lösungswege zur Absicherung zu werfen.

OT-Security-Regulierungen kommen mittlerweile aus allen Ecken: Mal geht’s um Versorgungssicherheit, mal um das Verhindern von Störfällen und in wieder anderen Fällen um die Einhaltung der Arbeitssicherheit.

Die Regelungen werden dabei immer schwieriger zu verstehen. Im Kern erfinden sie das „Security-Rad“ aber eigentlich nicht neu. Netzsegmentierung, sichere Fernzugriffe und Dienstleistermanagement gehört mittlerweile bereits zum kleinen Einmaleins des OT-Security-Managements.

Wie behält man den Überblick in seinem Security-Management, wenn man gleich von mehreren OT-Security-Regulierungen betroffen ist? In seinem Vortrag geht Peter Breidbach darauf ein, wie Betreiber eine Vielzahl regulatorischer OT-Security-Anforderungen im Konzernumfeld mit einem übergreifenden Ansatz erfüllen können und  behält dabei sowohl die pragmatische Machbarkeit als auch die Rechtssicherheit im Auge.

Ein Security-Programm bei einer Betreiberorganisation aufzusetzen, ist ein Mammutprojekt. Wo fängt man da an? Was ist wichtig? Wie macht man Auditoren glücklich? Wie bekommt man das nötige Geld von der Geschäftsführung? Wie motiviert man Automatisierer, ihre ohnehin knappe Zeit in das leidige Thema Security zu stecken? Wie machen das andere?

Betreiber findet man viel zu selten auf den Bühnen von Security-Kongressen – deswegen haben wir hier gleich mehrere auf einmal eingeladen (plus einen Hersteller). Unsere Panelisten teilen ihre Stolperstricke und Aha-Momente beim Aufbau eines Security-Programms im „echten Leben“ einer Betreiberorganisation. Das Publikum wird die ganze Zeit über Fragen einbringen können.