CRA und Robotik

00:00:04: Hey, neuer Sound,

00:00:05: neuer

00:00:05: Dean.

00:00:06: Überlassen

00:00:06: heute

00:00:07: Keba die Steuerung.

00:00:12: Hallo und herzlich willkommen zu einer neuen Ausgabe von Robotik in der Industrie.

00:00:16: Auch bei dieser Episode übernimmt Keba Industrial Automation wieder das Steuer.

00:00:21: Wir haben in den vorigen Ausgaben über Robotik Trends, Plattformen und Ökosysteme geredet und haben anhand von Herausforderungen und eigenen Use Cases die Rolle von Keba im Bereich Robotik auf den Punkt gebracht.

00:00:33: Heute im Podcast zu Gast sind Bernhard Lehner, Spezialist zum Teba Cyber Resilience Act bei Keber und Michael Gasternauer, Product Manager Robotics bei Keber.

00:00:42: Und wir reden über den Cyber Resilience Act, den aktuellen Status, aber auch, was es zu berücksichtigen gilt, wenn ich Robotics integrieren will, um nur ein Beispiel zu bringen.

00:00:52: Mein Name ist Philipp Mirmans und bin zuständig für die Kommunikation von Keber Industrial Automation.

00:00:57: Bernhard und Michael, herzlich willkommen im Studio.

00:01:00: Hallo und danke für die Einladung.

00:01:02: Danke auch von meiner Seite.

00:01:04: Beim noch mal in aller Kürze.

00:01:07: Cyber Resilience-Akt wird jetzt für die meisten Zuhörerinnen nicht neu sein, aber warum geht's?

00:01:13: Das Cyber Resilience-Akt ist eine Verordnung der EU, die darauf abzählt, dass alle Produkte am europäischen Markt ein Mindestmaß an Cyber Security bieten.

00:01:21: Er gilt für alle Produkte mit digitalen Elementen vereinfacht gesagt für Software und Geräte, auf denen Software ausgeführt wird.

00:01:27: Der Eck gilt für... Industrieprodukte, aber genauso für Konsumaprodukte, vom Smart-Kühlschrank über Computerspiele, Smartphone-Apps, bis zu eben auch Robotersteuerungen.

00:01:39: Die Füllung des CAAs ist Voraussetzung für die CE-Erklärung, die alle neuen Produkte auf dem europäischen Markt haben müssen.

00:01:47: Jetzt werden wir überlegen, wo wir gerade stehen.

00:01:49: Machen wir kurz ein Recap.

00:01:50: In Oktober, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, April, In Dezember des halben Jahres, das ist ein Krafttreten der Verordnung und Beginn der Übergangsphase, in der wir jetzt sind.

00:02:05: Mai, der Konformitätsbewertung stellen können mit der Bewertung der Umsetzung der CRA Grundsätze beginnen.

00:02:14: In Mai, der Konformitätsbewertung stellen können mit der Bewertung der Umsetzung der CRA Grundsätze beginnen.

00:02:23: August, der Meldepflicht für Hersteller beginnt.

00:02:27: bei aktiv ausgenutzten Schwachstellen und schwerwiegende Sicherheitsvorfallen.

00:02:32: In Dezember, siebenundzwanzig ist der letzten Meilenstein vollständige Anwendbarkeit.

00:02:37: Das heißt, alle neue Produkte, die aus diesem Datum auf den EU-Markt gebracht werden, müssen vollständig den Sierra-Anforderungen entsprechen.

00:02:46: Bernhard, wie befinden uns in dieser sogenannten Übergangsphase?

00:02:49: Was bedeutet die genau?

00:02:51: Die wichtigsten beiden Deadlines sind die letzten beiden.

00:02:55: für Hersteller, wichtigsten.

00:02:56: Im Jahr zwanzig, sechsundzwanzig Meldepflichten für aktiv ausgenützte Schwachstellen, das heißt zu diesem Zeitpunkt müssen Hersteller, die an Produkte gehackt wurden oder über die an Produkte bekannt wurde, das ist diese Schwachstellen enthalten, die auch tatsächlich ausgenützten werden, diese an Marktüberwachungsbehörden melden können, müssen auch ein Einmeldepartal haben.

00:03:17: und im Dezember, für die vollinhaltliche Erfüllung des Cyber Resilience Acts von allen neu auf den Markt gebrachten Produkte.

00:03:26: Das erste Jahr auf drei Jahre in Übergangsfrist ist jetzt vorbei, noch ist es nicht so spät, sich mit dem CA zu beschäftigen, allerdings für diejenigen, die das nicht gemacht haben, ist es jetzt höchste Zeit.

00:03:37: Verständnisfrage für mich, aktiv ausgenutzte Schwachstelle, das heißt, wenn der Schwachsteller einmal ausgenutzt wurde, Bedeutet das schon aktiv ausgenutzt oder muss es mehrmals passieren?

00:03:46: Wenn es einmal aktiv ausgenutzt wurde von einem Hacker, nicht unbedingt, wenn ein Cyber Security Researcher die Schwachstelle gefunden hat und mir eine Vulnerabilität gemeldet hat, dann muss ich diese auch beheben.

00:04:00: Also neue Produkte müssen ohne ausnutzbare Schwachstellen in Verkehr gebracht werden.

00:04:06: Aber tatsächlich, im Sinne eines Hackerangriffs aktiv ausgenutzte Schwachstellen, müssen eben dann Behörden gemeldet werden.

00:04:13: werden, also nationalen Marktüberwachungsbehörden und Ada Enissa.

00:04:18: Wenn ich mich jetzt mit integrierten Robotik auseinandersetze oder Vorhaben und Roboter zu integrieren, was muss ich beachten bezüglich Cyber Resilience Act Konformität?

00:04:28: Also das erste Mal muss ich mir dessen bewusst sein, dass auch ein Roboter ein Produkt mit digitalen Elementen ist, eben die Robotersteuerung, das Teedspendent etc.

00:04:37: und ich damit eigentlich auch den Cyber Resilience Act für den Roboter, für das Gesamtsystem eben erfüllen muss.

00:04:44: Und können bestimmte Entscheidungen, die einem später in gesetzliche Schwierigkeiten bringen, zum Beispiel wegen Fahrlässigkeit?

00:04:52: Das Thema selber, was sie ins Eck komplett zu ignorieren, kann jemand natürlich in Schwierigkeiten bringen.

00:04:57: Es ist im ersten Schritt immer wichtig, sich mit den eigenen Produkten auseinanderzusetzen.

00:05:00: Der Hersteller muss definieren, wie der vorherigelsehene Einsatzzweck für jedes Produkt ist.

00:05:06: Ein wichtiger Begriff in dem Bereich ist der Intended Purpose and Reasonable Forseable Use.

00:05:12: Das Cyberisierensekt ist ein risikobassierter Ansatz.

00:05:14: Das bedeutet, die Risik- und Bedrohungsanalyse ist eines der zentralen Werkzeuge für die Erfüllung des CAAS.

00:05:21: Diese muss für jedes Produkt erstellt werden.

00:05:23: ist auch Teil der technischen Dokumentation, auf deren Basis dann die CE-Erklärung ausgestellt wird.

00:05:29: Diese technische Dokumentation muss dann gegebenenfalls auch Marktüberwachungsbehörden zur Verfügung gestellt werden können.

00:05:34: Es ist nicht so, dass der CIA alles verbieten würden, aber der CIA verlangt eben als risikobassierten Ansatz, dass das Risiko für die jeweiligen anderen Wendungsfall angepasst sein muss.

00:05:49: Herausforderungen ein, dies oder Pain Points aus Sicht der Industrie bezüglich Cyber Resilience Act oder auch der Umsetzung dieses Acts.

00:06:00: Welche Pain Points habt ihr da geordnet?

00:06:03: Natürlich, wenn ich ein neues Produkt designe, habe ich die Aufgabe, das jetzt gleich als secure by design zu machen, habe nicht immer den Luxus ein Produkt komplett neu designen zu können, sondern vielfach auch das Thema WG mit Legacy-Produkten um, beziehungsweise mit Produkten, die zum Teil schon vor der ersten Version des Cyber Resilience Act, bevor das publiziert worden ist, bereits entwickelt wurden, Produkt-Serien.

00:06:27: Ich habe hier an der Stelle eher die Aufgabe, dass ich unter anderem die technische Dokumentation mal nachschärfen muss, die noch nicht gemacht wurde, während ich eben bei einer wirklich neuen Entwicklung gleich von vornherein in Richtung Security-Sign und sicherem Entwicklungsprozess gehen kann.

00:06:42: Wenn es wirklich leise ist, sind Produkte vor allem die Kombination von Neuprodukten mit älteren Produktgenerationen.

00:06:49: Schwierig.

00:06:50: Also das Cyberosiliensekt gilt im Prinzip jetzt für Gesamtprodukte?

00:06:54: Auch Systeme oder einzelne Produkte.

00:06:56: Vorher haben wir gesagt, so ein Thema Roboterik ist es immer ein System.

00:06:59: Das Cyberosiliensekt kennt eigentlich nur den Begriff Produkt.

00:07:02: Wie groß das Produkt ist, ob das jetzt aus mehreren Einzelprodukten zusammengesetzt ist.

00:07:06: Ja, wird es in der Qualität sein.

00:07:08: Im Prinzip regelt er nur... von der Begrifflichkeit kennt der Resilien-Sekt eigentlich nur das Produkt.

00:07:13: Secure by Design war ein Stolperstein oder Schwierigkeit?

00:07:17: Es ist etwas, das ich berücksichtigen muss, wenn ich ein neues Produkt mache, dann ist das auch einfacher als im Nachhinein Secure, die für Legacy Produkt nachzurüsten, was auch nicht unmöglich ist.

00:07:29: Wenn ich jetzt schon ein neues Produkt denke, ist es sinnvoll und eben auch notwendig, gleich von vornherein in Richtung Secure by Design zu gehen.

00:07:36: Was gibt es neben Secure by Design noch?

00:07:40: Steuerbesteilen oder Hürden für die Industrie?

00:07:42: Das Thema Standards ist leider nicht ganz so klar, wie man es eigentlich erwarten könnte.

00:07:49: Vor allem die zeitliche Verfügbarkeit dieser Standards ist einfach sehr knapp mit dem Inkrafttreten des Cyber Resilience Acts.

00:07:58: Und wenn man die Prozesse kennt von Lieferanten, Kunden, Umsetzung an Passungen, die in den jeweiligen Organisationen erforderlich sind und zum jetzigen Zeitpunkt sind für unter Anführungszeichen normale Produkte keine harmonisierten Standards verfügbar, dann ist es durchaus knapp an, was man sich da orientieren soll und orientieren kann und stellt die ganze Industrie durchaus vor Herausforderungen.

00:08:26: Kannst

00:08:26: du ein Beispiel nennen eines solchen Standards, der fehlt?

00:08:30: Ob er nicht klar definiert ist?

00:08:32: Es gibt einfach zu vielen EU-Richtlinien oder Verordnungen typischerweise sogenannte harmonisierte Standards, die einen kleinen Rahmen geben, mit dem er vorgeht.

00:08:43: Also das ist für die Robotik-Safety-Norm lang etabliert.

00:08:48: Dort gibt es diese passende harmonisierte Norm und wenn man sich an die hält, dann macht man nicht viel falsch.

00:08:54: Im CAA ist diese Situation aktuell noch nicht gegeben.

00:08:58: Vielleicht mal nicht ergänzen das.

00:09:01: Es wird seitens der EU bzw.

00:09:03: beauftragten Normierungsgremien sehr wohl daran gearbeitet, harmonisierte Normen zu entwickelt.

00:09:11: In erster Linie mal für die im CAA als wichtig und kritisch betrachteten Produkte.

00:09:16: Da muss man ein bisschen unterscheiden zwischen wichtigen und kritischen Produkten des CAA.

00:09:20: Bitte nicht verwechseln mit kritischer Infrastruktur im Sinne von NISS.

00:09:24: Wie ist das dann so für stehen?

00:09:25: Aus Sicht des CAAs sind kritische, wichtige Produkte, die Produkte.

00:09:29: auf denen die Cyber-Sicherheit anderer Produkte basiert.

00:09:32: Also Beispiel Passwortmanager, Beispiel Betriebssysteme, Beispiel Firewall.

00:09:37: Das sind aus Sicht des Cyber-Silience Acts die kritischen Produkte.

00:09:41: Das sind die ersten für die harmonisierte Standards beauftragt worden, die alle auch noch in Arbeit sind.

00:09:49: Im Bereich der Industrie wird öfters die IEC-C-C-C-V-V-V-III genannt, die ist als Isonorm nicht harmonisiert mit dem Cyber Resilience Act.

00:09:58: Es gibt aber auch hier Bemühungen, eine Variante dieses Standards, also den Standard dahingehend zu überarbeiten, dass ein harmonisierter Standard daraus fehlt.

00:10:08: Seitens Kehber beteiligen wir uns auch an dieser Arbeit an diesem Standard.

00:10:11: Er ist allerdings Stand heute nur nicht fertig, natürlich.

00:10:16: Wenn ich mich als Unternehmen mit dem Cyber Resilience Act auseinandersetze und ich hätte gerne Klarheit bezüglich Standards oder Normen, wo kann ich da Beratung oder Unterstützung bekommen?

00:10:27: Also bezüglich Standards und Normen wird man diese Klarheit nicht schaffen, weil es die einfach nicht gibt, aber bezüglich bester Vorgehensweisen kann man sich am Regelwerk orientieren und es gibt natürlich auch Berater, die entsprechend unterstützen.

00:10:43: Natürlich Wenn man wesentliche Produkte oder Komponenten seines Produkts bei Lieferanten bezieht, dann kann man auch mit denen in den Dialog gehen und dort gemeinsam an Konzepten arbeiten.

00:10:56: An welchen Beinbeins denkt sich noch Umsetzung Cyber Resilience-Act in der Industrie?

00:11:01: Ein Thema, das auch angegangen werden muss, nämlich noch vor dem Dezember twenty-seven, ist alles Richtung Meldepflichten.

00:11:08: Ein Portal zu haben, an denen Kunden aber auch, sagen wir mal, externe Security-Researcher oder gegebenenfalls auch Ämter einen Hersteller kontaktieren können und vermuterte Schwachstellen im Produkt melden, die dann auch behandelt werden müssen.

00:11:25: Also diagnostiziert, ob sie wirklich ausnutzbar sind, behandelt und gegebenenfalls in der nächsten Version behoben werden oder gegebenenfalls beim höheren Risiko auch mit einem Sofort-Fix behoben werden müssen, der dann ein... eingespielt werden muss auf allen Produkten und im Fall eben da wirklich tatsächlich aktiv ausgenutzten Schwachstellen, die bereits erwähnte Meldepflicht auch an Behörden.

00:11:47: Ist ein tendenziell zusätzlicher Prozess, zusätzliches Team, das Product Security Insiderance Response Team, das für diese Aufgabe erforderlich ist?

00:11:57: Was vor das Portal genannt gibt, ist da Klarheit bezüglich Standards oder was das Portal können muss, um was einzumelden?

00:12:05: Da gibt es Best Practices bei Standard Formate, wie man das machen sollte.

00:12:11: Aber rein rechtlich eine scharfe Vorgabe, genau so muss es sein, ist es nicht.

00:12:14: Also in der Praxis gibt es zwei gängige Wege, das eine ist eben Einmeldung über eine E-Mail-Adresse, die hat... auf der Webseite oder in der Produktdokumentation genannt ist.

00:12:25: Das Zweite ist die Einmeldung über Webformular.

00:12:28: Beides ist möglich.

00:12:29: Aus Sichtgeber haben wir auf der Webseite eine Vulnerability Disclosure Policy veröffentlicht.

00:12:35: Das ist auch, sagen wir mal, jedem Hersteller nagelegtes zu tun, wo im Prinzip dann nochmal zusammengefasst ist, wie wir mit gemeldeten Schwachstellen grundsätzlich umgehen, wohin man sie melden kann.

00:12:46: was wir gerne dabei hätten bei dieser Meldung.

00:12:48: Aus Sichtgeber haben wir die Möglichkeit, dass man die auch anonym abgibt, die Schwachstellenmeldung, quasi whistleblower Portal oder eben einfach per E-Mail.

00:12:57: Und wenn Unternehmen dann oder potenzielle Kunden was eingemeldet haben, besteht dann der Prozess, wie man damit umgeht mit dem Feedback, damit das abgearbeitet wird.

00:13:06: Gibt es da Klarheit, gibt es da Standards?

00:13:09: Oder müssen da völlig neue Prozesse entwickelt werden?

00:13:11: Gibt

00:13:11: es auch Best Practices, die man prinzipiell folgen kann, denn wir auch folgen

00:13:16: Weitere Hürden bei der Umsetzung, das sei passieren, sagt ihr euch einfallen.

00:13:20: Das Thema Security schränkt ja oft einmal auf den ersten Blick ein und dadurch gibt es vielleicht an der einen oder anderen Stelle Abweichungen von etablierten Umgang.

00:13:33: Also manche Benutzer oder Stakeholder an Systemen müssen dann sich um lernen, um trainieren, sei es der Bediener, der tägliche Bediener.

00:13:46: das Servicepersonal oder auch jemand, der im Bereich der Anlagenwartung tätig ist.

00:13:56: Und da ist es einfach im Systemdesign essentiell, dass das Thema Usability nicht zu kurz kommt, weil sonst die Akzeptanz für neue Produkte einfach nicht geschaffen werden kann, sondern die Benutzer einfach um Gehungslösungen suchen und einfach unzufrieden sind, die Produktivität sinkt.

00:14:20: Das sind alles Themen, die auf die man bei der Umsetzung schon acht geben muss.

00:14:25: Stichwort User-Wir-Security, aber auch da, Michael, gibt es doch bereits Vielzahl an Standardlösungen und Anbieter?

00:14:32: Also das Rad muss hier nicht neu erfunden werden.

00:14:34: Da gibt es genau das, nämlich eine Vielzahl von Standards und das ist gerade für den, der eine Produktion betreibt und dann ein heterogenes Bild von Maschinen und Anlagen hat, durchaus eine Herausforderung.

00:14:48: Es gibt keinen klaren Industriestandard, wie der CA umgesetzt werden soll, welche Methodenmechanismen in Summe angewendet werden sollen.

00:14:59: Es ist auch fraglich, wie weit das ein One-Size-Fits-All-Ansatz überhaupt funktionieren könnte, weil die Produkte, also die gesamte Industrie ja doch sehr breit gefächert ist.

00:15:10: Wovon hängt denn die Komplexität der Umsetzung ab?

00:15:13: von der Komplexität der Produktpalette?

00:15:15: Grundsätzlich der CA, kommen wir darauf zurück, ist ein Risikopassierter Ansatz.

00:15:20: Ich muss mir eigentlich die Risiken und Bedrohungen für das System überlegen und entsprechend dann adäquate Mechanismen für genau die Risiken, die mit genau diesem Produkt habe, umsetzen.

00:15:33: Soll aber auch nicht in die Richtung gehen, damit Maßnahmen zu überschießen.

00:15:37: die dann die Usability massiv einschränken, ohne überhaupt ein nennenswertes Risiko zu reduzieren.

00:15:44: Misi ist aus mit dem Konflikt zwischen funktionaler Sicherheit und dynamisches Cyber-Sicherheit.

00:15:50: Na ja, grundsätzlich in der Industrie ist man es gewohnt, dass man Maschinen und Anlagen in Betrieb nimmt und dann möglichst nicht angreift.

00:16:01: Das heißt, etablierte Prozesse so laufen lässt, wie sie laufen, da typisch gibt es ja eine Eingewöhnungsphase, wo eigentlich der tägliche Betrieb geübt wird, wo mit besonderen Eigenschaften gelernt wird, umzugehen und wo man einfach einen Weg findet zu arbeiten.

00:16:22: Wenn man jetzt aber das Thema Cyber Resilience betrachtet, dann kann es durchaus sein, dass man auch Systeme update muss und zwar nicht, weil man Funktional irgendein Problem hat, sondern weil sich eine Security-Lücke gegeben hat.

00:16:38: Und da ist nicht immer gewährleistet, dass das möglich ist, ohne gewisse Kompatibilitäten zu verletzen.

00:16:45: Das heißt, dort wird man mehr Dynamik in die Systeme reingregen als bisher.

00:16:52: Das hängt natürlich von den verwendeten Schnittstellen ab und von der verwendeten Zugänglichkeit zu den Systemen, also von der Risikoanalyse, inwieweit diese Auswirkungen sich ziehen.

00:17:04: Aber es ist durchaus denkbar, dass es da mehr Dynamik in der Produktion gibt als bisher.

00:17:10: Wir sind eine mögliche Lösungsansätze oder Ideen, um diesen Konflikt zu entschärfen.

00:17:14: Aber wir haben ja ständig, du hast gesagt, relativ wenig Veränderung im Prozess.

00:17:18: Wenn er mal steht, dann sollen wir nicht mehr allzu viel anfassen.

00:17:22: Selber Sicherheit führt ja zuständig notwendiger Updates und auch eine sehr schnelle Reaktion da drauf.

00:17:28: Da kann man durchaus auch Konzepte der Eingrenzung wählen, sodass man einfach die kritischen Systeme, die für die Produktion kritischen Systeme sehr klar abgrenzt von den Schnittstellen über die Risiko.

00:17:45: reingetragen wird und das entschärft die Situation, aber ganz beheben wird es wahrscheinlich auch nicht.

00:17:52: Das ist eine sehr systemspezifische Angelegenheit, das kann man nicht im Allgemeinen beantworten, aber das bleibt, glaube ich, am Ende doch eine kleine Herausforderung.

00:18:03: Also patchen oder mitingieren muss ich die ausnutzbaren Schwachstellen.

00:18:07: Das heißt, man muss unterscheiden zwischen Schwachstelle, ausnutzbare Schwachstelle und aktiv ausgenutzte Schwachstelle.

00:18:14: Ich muss nicht jeder Schwachstelle, die in einer Open Source Komponente in irgendeiner speziellen Konfiguration vorkommen könnte, immer patchen, wenn ich sage, diese Schwachstelle ist in meinem System nicht ausnützbar.

00:18:27: Also weil ich die Komponente nicht so benutze, dass diese Schwachstelle tatsächlich zu irgendeinem Risiko führen würde.

00:18:34: Und eben die, tatsächlich die aktiv ausgenützter Schwachstelle ist, wenn ich dann jetzt Hinweise darauf habe, dass eben eine ausnutzbare Schwachstelle auch tatsächlich ausgenutzt wurde.

00:18:46: Eine Hürde, die ich mir noch vorstellen kann, ist das Thema Lieferketten und Lieferketten-Sicherheit, denn auch Zulieferer müssen Cyber-Silence-Acte-Anforderungen erfüllen, was umfangreiche Prüfungen und auch mehr Dokumentationen erfordert.

00:19:00: Stehen hier bereits Prozesse, wie man damit umgehen kann als Unternehmen, herrscht schon Klarheit auch über die Erwartungshaltung und die Verhandlungen gegenüber?

00:19:07: Das ist abhängig pro Lieferamt.

00:19:09: Lieferanten natürlich, wenn sie innerhalb der EU sind, müssen sie ihre Produkte entsprechend verkaufen.

00:19:14: Auch über Impoteure müssen auch die den Cyber Resilience Act erfüllen.

00:19:19: Ebenfalls ein risikobassiertes Ansatz pro Produktkategorie ist hier sehr unterschiedlich, je nach Produkt, welchen Standards die Lieferanten folgen oder welcher secure Strategie sie grundsätzlich folgen, muss ja nicht immer ein kompletter Standard sein.

00:19:35: Aber das ist Aufgabe, quasi das Integrator, der dann ein Gesamtprodukt daraus baut, eben auch darauf zu achten, dass alle Komponenten, alle Bestandteile, die er einsetzt, ein adäquates Level an Cybersecurity mitbringen, beziehungsweise in der Verwendung in dem Gesamtsystem keine ausnutzbaren Schwachstellen durch Verwendung von dieser Komponente übernommen werden.

00:19:58: Danke dafür.

00:19:59: Das war mal ein Überblick über die Hürden.

00:20:03: Die Schwierigkeiten, die wir sehen bei der Umsetzung von Cybersilience-Act in der Industrie.

00:20:08: Jetzt steht Keba in Verbindung mit vielen Industrieunternehmen und auch mit Maschinenbauen.

00:20:12: Wie wird man uns jetzt einige Fragen aus unserer Erfahrung mit diesen Industriepartnern fragen, die immer wieder gestellt werden?

00:20:20: Wie haut ich mein bestehendes Portfolio cyber-sicher, ohne das Geschäft zu stören?

00:20:26: Grundsätzlich ist es entscheidend, dass man im Systemdesign schaut, dass man möglichst wenig Angriffsfläche bildet.

00:20:33: Da gibt es die Möglichkeit, dass man sich die Schnittstellen, die potenzielle Einfallstore sind, gut überlegt, gut designt und dann so umsetzt, dass sie im Wesentlichen selber sicher sind.

00:20:48: Was man auf jeden Fall auch machen kann, ist abschotten.

00:20:51: Die Systeme gegen Zugang von außen absichern.

00:20:56: Und mit diesen beiden Methoden kann man ganz viel umsetzen und lösen, ohne dass dann die tägliche Security-Warnung aufgeht.

00:21:08: Wie kann ich neue Risiken im frühen Entwicklungsprozess erkennen und auch steuern?

00:21:13: Ein Element ist die Risik- und Bedauungsanalyse für jedes neue System.

00:21:18: Die mache ich einerseits natürlich bei der neuen Systemkonzeption, andererseits ist das auch etwas, das man regelmäßig, also z.B.

00:21:26: jährlich oder für jede neue Version eines Produkts auch wiederholen sollte, ob sie z.B.

00:21:32: jetzt die Risikolage grundsätzlich geändert hat, ob zusätzliche neue Risiken bekannt sind oder eben auch, ob das System modifiziert wurde, neue Features dazu gekommen worden, dann wiederhole ich eben diese Risikonbetreuung, sondern die sind unter Gänze sehen und das.

00:21:47: Im Maschinenbau wird ja auch geerbt, wie gehe ich mit Leigesystemen und Software um?

00:21:52: Eine Frage, die diesbezüglich auch immer wieder kommt, ist, inwieweit Systeme, die vor dem Inkrafttreten des Cyber Resilience Acts geliefert wurden, unter den Cyber Resilience Acts fallen oder nicht?

00:22:04: Also prinzipiell fallen sie nicht drunter, solange ich keine wesentliche Änderungen an dem System vornehme.

00:22:11: Also eine kleine Fehlerbehebung ist keine wesentliche Änderung am System.

00:22:15: Bei Legacy Produkten werde ich tendenziell mehr in Richtung Abschottung gehen.

00:22:19: unter Umständen was vorbauen und diese Systeme sichern.

00:22:23: Bei neuen Systemen gibt man eher wirklich in Richtung Secure by Design.

00:22:28: Wie schulde ich mein Team, damit Security by default eine Selbstverständlichkeit wird?

00:22:32: Was braucht es dazu?

00:22:34: Oft braucht es erst mal eine Basiserwehrnis in Form einer Schulung oder durchaus auch mal an die Mannschaft bringen kann.

00:22:42: Vielfach ist den Leuten gar nicht bewusst, wie ihr Handeln, Einfluss auf die Cybersecurity der Produkte hat.

00:22:50: Also vom irgendwo gefundernen privaten USB-Stick, über dem man was einschleibt, irgendwelche Einstellungen, die man halt schnell mal aus Komfortgründen ändert, ohne zu wissen, was sie eigentlich dahinter wirklich bewirken.

00:23:04: Das sind Themen, die natürlich einerseits in der Dokumentation eines Produkts stehen sollen und das Produkt soll auch secure by default sein.

00:23:13: Nichtsdestotrotz ist es... oft mal erforderlich, wenn man so eine Basis erwährende Schulung auch bei den Anwendern lässt sich zu machen.

00:23:23: Gibt es noch weitere Dinge, die man machen kann?

00:23:24: Ich denke da an integrierte Sicherheit oder standardisierte Sicherheit?

00:23:28: Die Sicherheitsmaßnahmen bei einem neuen System sollte jeweils secure by design und secure by the default sein.

00:23:34: Damit ist es hier leicht, das aber mit einem neuen System entsprechend zu arbeiten, wo eben diese Dokumentationen auch von Anfang an mit schon gemacht wurden.

00:23:43: Bei Legacy-Systemen muss ich mir im Einzelfall auch ein Konzept überlegen, wie ich damit umgehen kann.

00:23:51: Wie kann ich Änderungen Kunden gegenüber kommunizieren?

00:23:54: Und die Änderungen besieren sich auf Kosten, Zeitaufwand, Zertifizierung oder auch Verfügbarkeit?

00:24:00: Die meisten Kunden sind bezüglich Security durchaus bereit, Verbesserungen zur bisher üblichen Praxis gerne aufzunehmen, weil viele der Anwender entsprechend anderen Richtlinien unterliegen, zum Beispiel den NIS-II und dort die Sicherheit der Produktionssysteme einen wesentlichen Beitrag leistet, um diese Standards zu erfüllen, die unsere Kunden jeweils erfüllen müssen.

00:24:35: Und so gesehen muss man frühzeitig in einen Dialog gehen, die unsere Kunden und Betreiber bald involvieren und über den veränderten Zugang informieren und bald in die täglichen Prozesse integrieren.

00:24:51: Cyber Resilience Act verknüpfen viele Leute mit sehr viel Arbeit, mit Veränderungen.

00:24:56: Wie kann ich jetzt Security so dokumentieren, ohne in Bürokratie zu versinken?

00:25:01: Es gibt zwei verschiedene Arten der Dokumentation, die der Cyber Resilience Act vorsieht.

00:25:07: Die eine ist die technische Dokumentation.

00:25:10: die der Hersteller haben muss, als Nachweise dafür, also für die CE-Erklärung bzw.

00:25:16: für die Erfüllung des Cyber Resilience Acts, das sind Themen enthalten, eben wie die Risik- und Bedrohungsanlüsse, wie die S-Bomb, also die Software-Build of Materials, Dokumentationen zu Tests, das Dokumentationen zum sicheren Entwicklungsprozess, wenn ich alle Schritte gemacht habe und dokumentiert habe, nachweisend für habe, Stellt es die technische Dokumentation da?

00:25:36: Die muss ich nicht modernerweise den Benutzer zur Verfügung stellen.

00:25:39: Die zweite Dokumentation ist die... Benutzerdokumentation, in der ich den Anwender, den Kunden darüber informiere, wie mein vorhergesehener Produkt-Einsatz weg ist, wo er sich hinwenden kann für, sagen wir, Support, für vulnerability-Meldungen, wie das System sicher zu konfigurieren ist, sicher zu betreiben ist, zu bestimmen, ob die Sicherheit noch gewährleistet ist, auch wie das System sicher außer Betrieb genommen werden kann.

00:26:07: Also zum Beispiel, indem sensible Daten gelöscht werden, bevor das Produkt entsorgt wird.

00:26:13: Die zweite Dokumentation ist deutlich weniger als die interne technische Dokumentation.

00:26:20: Die hat wirklich dann den Anwender im Fokus und dessen Newscases.

00:26:26: Also ihr geht es nicht darum, Neues zu schaffen, so eine bestehende Format der Kanäle zu nutzen und die Inhalte ein bisschen zu verfeinern.

00:26:34: Welche besondere Herausforderungen haben Industrieunternehmen bei der Umsetzung des Cyber Resilience Act in der Industrie Robotik?

00:26:42: Die Industrierobotik oder Robotersteuerungen im Allgemeinen sind ganz normale digitale Produkte.

00:26:48: Sie haben halt oft recht viele Schnittstellen nach außen.

00:26:52: Der Betreiber oder Anwender kommt in vielen Bereichen in Kontakt.

00:26:57: Es werden Roboterprogramme adaptiert, es werden Konfigurationen vorgenommen, es werden Schnittstellen geschaffen und so gesehen ist es durchaus herausfordernd.

00:27:09: Man muss da einfach an viele Dinge denken und berücksichtigen, um diese Konzepte richtig zu gestalten.

00:27:16: Wenn man aber den Best Practices folgt, dann kann man dann auch recht gute, brauchbare Lösungen, die einen guten Kompromiss zwischen Security und Usability schaffen, zustande kriegen.

00:27:29: Man muss an viele Dinge denken, was sind Bewertestrategien und die Softwareentwicklung in der Robotik, Branche spezifisch, Anizära, Anforderungen anzupassen.

00:27:42: Was wir jetzt ganz gute Praxis sehen, ist, dass man einfach auf etablierte Kommunikationsprotokolle setzt, die bereits Security mitbringen, wo man einfach nicht Dinge neu erfinden muss, sondern auf bewährten Standards, die vielleicht auch aus anderen Industrien kommen, aufsetzt und sich dann einfach das Leben deutlich leichter macht, wenn man etablierte Standards benutzt.

00:28:08: Wir verwenden z.B.

00:28:09: bei uns etablierte Webstandards mit sicherer Authentifizierung, um Schnittstellen zu anderen Systemen zu schaffen und haben damit einfach eine sehr gute Grundlage, um gerade dieses kritische Thema API und Schnittstelle zu unserer Software gut im Griff zu haben.

00:28:32: Wie kann User-Bus Security bei vernetzenden Roboter-Systemen die Sicherheitslücken minimieren?

00:28:37: Usability ist ein wesentliches Thema in der Robotik.

00:28:40: Wir sehen auch, also meine Hypothese ist, dass die Robotik deswegen nur eher langsam etabliert ist, weil es einfach sehr oft die Usability Schwierigkeiten im täglichen Einsatz gibt.

00:28:54: Die Security macht es nicht leichter und deswegen ist es einfach wichtig, dass man Usability Aspekte beim Design der Sicherheitslösung mitbetrachtet.

00:29:06: Das ist genauso wie die funktionale Sicherheit, ist die Cyber Security ein wesentliches Feld, wo man die Usability ganz schnell kaputt machen kann und man muss es einfach sauber machen, sauber beide Ansätze berücksichtigen, dann kann man das durchaus so hinkriegen, dass das für den täglichen Einsatz tauglich ist.

00:29:30: Der CIA legt da Offiziell keinen Wert drauf, aber unsere Kunden und die Anwender unserer Kunden natürlich.

00:29:38: Also User-centered Design ist grundsätzlich kein Widerspruch zur Security.

00:29:44: Schauen wir nochmal auf die Beziehung zwischen Komponenten, Hersteller und Anlagenbetreibern.

00:29:49: Wie kann man da die Zusammenarbeit verbessern, um Komplex zu sichern?

00:29:55: Natürlich kann man mit seinen Anwändern, größeren Anwändern in einen Co-Design gehen.

00:30:00: und sagen, okay, was ist euer Anwendungszweck jetzt ganz genau und worauf legt ihr Wert bei bäuererem Produkt?

00:30:08: Andererseits ist natürlich die Anwendung von etablierten Standards auch sinnvoll, weil dann wissen beide Seiten, worauf sie sich genau einlassen.

00:30:18: Das haben wir einige Fragen diskutiert.

00:30:20: Wir sind auch auf viele Themen eingegangen.

00:30:22: Zusammenfassend, welche Best Practices oder welche Tipps würdet ihr den Zuhörerinnen und den Zuhörern mit auf den Weg geben?

00:30:30: Secure by Design, wenn ich denn ein neues Produkt auf den Markt bringe, ein neues Produkt entwerfe, ist es viel einfacher Secure, die von Anfang an mitzudenken als nachzurüsten.

00:30:42: Das Thema Update und Patch Management muss man von Anbeginn mit betrachten.

00:30:48: Wenn man jetzt im täglichen Geschäft ist, im Serienmaschinenbau, dann kann es schon sein, dass man viele Systeme gleichzeitig updaten muss und dazu muss es adäquate Methoden im System verankert geben, um solche Patch und Update-Aktionen effizient und einfach durchführen zu können.

00:31:11: Etablierer eines Risikomanagements, sowohl für die initiale Risikobewertung eines neuen Produkts, als auch für eine Bewertung von eventuellen nachträglich gefundenen Schwachstellen.

00:31:24: Welche Tipps gehen wir noch mit?

00:31:25: Bald mit den Prüfstellen.

00:31:28: und den Lieferanten in Kontakt gehen, sodass man nicht auf der grünen Wiese arbeitet, sondern in dem Ökosystem, in dem man täglich aktiv ist und dort zu einer praktikablen Lösung insgesamt kommt.

00:31:44: Usability darf kein Widerspruch zur Security-Design.

00:31:47: Usability von Anfang an mitdenken, User-Tender-Design auch in Security-Punkten, seinen Anwender verstehen, das Produkt entsprechend designen.

00:31:57: Man kann sich an etablierten Standards anhalten, wie wir schon erwähnt haben, gibt es leider keinen harmonisierten Standard, mit dem man das viel einfacher machen könnte.

00:32:09: Aber es gibt zumindest Hinweise und etwas Orientierung, wenn man etablierte Standards anwendet.

00:32:16: Automatisierte Tests als Teil des Entwicklungsprozesses gleich von vornherein vorzusehen.

00:32:22: Also Penetration-Tests, Fast-Tests, Vulnerabilität, Scanning, diverse Benchmarks gibt es schon einiges an guten Standard-Tests, die man bei der Produktentwicklung auch verwenden sollte.

00:32:35: Und fast als W-Listerpunkt ist das gemeinsame Security Mindset.

00:32:40: Es sind viele unterschiedliche Abteilungen oder Funktionen im Unternehmen mit der Security beschäftigt oder konfrontiert und jeder kann da seinen Beitrag leisten.

00:32:52: und jeder muss auch seinen Beitrag leisten und es muss allen klar sein, dass das sehr wertvoll ist, wenn Produkte und Leistungen eines Unternehmens secure sind.

00:33:03: Cyber Resilience Act hat ein sehr, sehr wichtiges Thema, relativ wenig Standards, dafür aber die Bedeutung dasselbe Verständnis im Unternehmen davon zu haben, das hilft dann sehr stark dabei bei der Umsetzung.

00:33:15: Michael, Bernhard, vielen Dank für den sehr guten Austausch und dass ihr heute auch die Zeit genommen habt.

00:33:21: Danke auch.