Kaizen 2 go 386 : Cyber-Security - GeeMco : Götz Müller Consulting

Inhalt der Episode:

Welche Rahmenbedingungen gibt es für das Thema Cyber-Security?
Was muss bei der Cyber-Security beachtet werden, welche Folgen können sich ergeben?
Warum sollten Produkt-Hersteller und -Importeure den Cyber Resilience Act (CRA) im Blick haben? Wer kann sich evtl. entspannt zurücklehnen?
Was fordert der CRA?
Wie wird Cyber-Security von Anfang an integriert?
Wie kann man Cyber-Security bei bestehenden Anwendungen nachrüsten?
Welche Rolle spielt KI, Automatisierung & Co. bei der Cyber-Security?
Welche Rolle spielt der Mensch als Anwender und Entwickler?
Wie wird sich das Thema noch weiterentwickeln?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei Apple Podcasts.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 386 : Cyber-Security

Eine KI-generierte Zusammenfassung finden Sie am Ende des Transkript.

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Merita und Christoph Fischer bei mir im Podcast-Gespräch. Sie sind Produkt-Security-Experten. Hallo zusammen.

Merita Fischer: Hallo.

Christoph Fischer: Ja, hallo.

Götz Müller: Jetzt habe ich schon ein kurzes Stichwort zu euch gesagt, aber weil jetzt wahrscheinlich nicht jeder Zuhörer so absolut da zu Hause ist, vielleicht vertieft ihr das noch ein bisschen.

Merita Fischer: Ja, ich bin Merita. Zusammen mit dem Christoph haben wir Secure Blueprint ins Leben gerufen. Gemeinsam haben wir über 20 Jahre Produkt-Security-Erfahrung. Wir kennen aber auch die andere Seite von der Produktentwicklung. Wir sind auch Produktentwickler von Software-Produkten. Das heißt, wir kennen die Seite von, ja, wir wollen die Produkte sicher machen, aber auch die andere Seite von, ja, wir wollen auch, dass das Produkt quasi besser wird, dass wir viele Features implementieren und natürlich kommt da, so wir müssen abwägen, ob die Features oder Security, wie die zusammenpassen. Unser Ziel ist, die Welt ein Stück sicherer zu machen. Deswegen haben wir auch Secure Blueprints gegründet. Und unsere Mission mit Secure Blueprints ist, Produktsicherheit für jeden zugänglich zu machen und das in die Breite zu tragen. Ich habe Erfahrung im Security-Testing-Bereich mit Schwerpunkt Automation, aber kenne auch die Seite von Infrastruktursicherheit bzw. Cloud AWS Security. Da bin ich auch Experte in dem Field.

Christoph Fischer: Genau, ich bin der Fischer, Christoph, seit 2012 im Produkt-Security-Umfeld tätig. Ich würde mich selbst als Security-Experte bezeichnen. Dort habe ich sehr viel, auch wie die Merita, in der Testecke verbracht. Aber es sind auch andere Themen wie Secure Coding oder Risikoanalysen, Vulnerability Management, einfach immer wieder Tagesgeschäft gewesen, beziehungsweise sind es noch immer. Und ein paar Jahre nach dem Start meiner Produkt-Security-Karriere bin ich dann auch Produktmanager von einem Software-Produkt im Security-Umfeld geworden. Und wie die Merita das eben schon kurz erklärt hat, da sind wir immer wieder in dem Spannungsfeld zwischen Security und Produktentwicklung gestanden, wo es auch mal darum gegangen ist, Kosten abzuschätzen von Security und einfach zu merken, was ist denn jetzt auch wichtiger für Nutzer. Ist es jetzt die Security, die jetzt quasi versucht, das Problem sehr stark zu lösen, aber das Produkt sehr kompliziert zu machen, oder einfach ein Feature, was man nicht implementieren kann, weil das der Security entgegensteht? Genau, das wäre jetzt zu mir.

Götz Müller: Jetzt haben wir uns ja auf das Thema, oder ich habe das in Anführungszeichen vorgegeben, Cyber Security. Was sind denn so Rahmenbedingungen, vielleicht um eben für die Zuhörer so ein bisschen das Feld auch aufzuspannen?

Christoph Fischer: Ja, genau. Zuallererst würde ich gerne das Security-Thema, also Cyber-Security-Thema ein bisschen untergliedern. Die meisten Leute kennen wahrscheinlich IT-Security. Da hat man irgendwie mit Computern, Servern und irgendwie so IT-Infrastruktur zu tun. Es gibt aber noch weitere Felder. Das eine wäre zum Beispiel die OT-Security, also Operational Technology Security. Da geht es dann eher darum, in einer Fabrik einen Prozess abzuarbeiten. Also zum Beispiel die Fertigung von einem Auto oder was auch zur OT-Security gehört, sind dann Gebäudeautomatisierungen, Brandmelder, Systeme und solche Dinge. Und das dritte Feld, was ich gerne quasi erwähnen möchte, ist die Produkt-Security. Und da geht es eben darum, wie man ein Produkt sicher gestaltet. Warum gibt es jetzt diese drei Bereiche oder warum unterscheide ich die drei Bereiche gern? Einfach deswegen, weil die Zielsetzung dieser Security-Felder ein bisschen unterschiedlich ist. Wenn man jetzt wieder die IT hernimmt, die kümmern sich sehr stark darum, dass die Server sicher sind, dass die Office-PCs sicher sind und die wollen vor allem dort auch Datensicherheit erreichen. Also dass nicht irgendwie Daten von einem Computer gestohlen werden oder irgendwie ein Server gehackt wird und dann eine falsche Webseite präsentiert wird oder solche Sachen. In der OT-Security ist das Hauptschutzziel wiederum anderes. Da geht es um Betrieb, um Ausfallsicherheit. Eine Fabrik, die steht, kostet richtig Geld. Eine Brandmeldeanlage, die nicht läuft, kann im schlimmsten Fall Leben gefährden. Und da sieht man schon, das ist vielleicht von den Anforderungen an das System zwischen IT und OT durchaus schon einmal was anderes. Und jetzt zum Dritten, zur Produkt-Security. Das unterscheidet sich wiederum daran, dass da ganz stark Anforderungsmanagement betrieben wird. Also zum Beispiel kommen die Anforderungen von Kunden mit, ja, ich erwarte vielleicht, dass meine IP-Kamera sicher ist, sodass mir nicht der Nachbar zuschaut, was ich im Wohnzimmer treibe. Und da gibt es eben neben den Kundenanforderungen jetzt immer mehr regulatorische Anforderungen. Also Staaten wie die USA, China, Vereinigtes Königreich, aber jetzt eben auch die EU haben immer mehr Regulatoren jetzt rausgebracht, um mehr Sicherheit in die Produktentwicklung beziehungsweise in die Produkte selbst hineinzubringen. Und da ja eigentlich das momentan umfangreichste Framework ist der Cyber Resilience Act der EU. Da kann es sogar bis dahin gehen, wenn man nicht compliant zu diesem Cyber Resilience Act sein wird, der ab Dezember 2027 dann voll aktiv ist, dann kann es sogar bedeuten, dass man das Produkt nicht mehr am EU-Markt verkaufen kann. Und das wiederum ist natürlich für viele Hersteller durchaus ein wichtiges Thema.

Götz Müller: Mir geht jetzt gerade so ein ziemlich schräger Vergleich durch den Sinn. Es gibt Verkehrsregeln und eine der Verkehrsregeln ist, fahre halt nicht bei Rot über die Ampel. Das ist jetzt, glaube ich, ziemlich einfach definiert und dem Einzelnen, der halt im Auto sitzt, ist auch ziemlich klar, was er tun muss. Da könnte ich mir jetzt vorstellen, ich bin da im Grunde blutiger Laie, was den Cyber Resilience Act angeht, ist das halt nicht so eindeutig, was ich tun oder was ich lassen muss.

Christoph Fischer: Ja, also grundsätzlich gibt es da schon im Act, also dieser Act ist 81 Seiten lang, zumindest in der englischen Variante. Und da steht schon relativ genau beschrieben, was alles zu tun und zu lassen ist. Aber wenn man das sich mal dann tatsächlich durchliest, ist es dann mit den Formulierungen dann wiederum nicht so einfach. Und dann wird aus, fahre nicht bei Rot über eine Ampel, dann gibt es da doch immer wieder Unklarheiten, in die man sich reinarbeiten muss und verstehen muss, wie das Ganze gemeint ist.

Götz Müller: Ja, vielleicht das noch ein bisschen vertieft. Natürlich, ich vermute mal, dass würde den Rahmen völlig sprengen, so ein bisschen, was passiert, wenn ich mich nicht dranhalte? Beziehungsweise eben, ja, vielleicht damit kombiniert auch, was wird denn da gefordert? Sofern wir das, wie gesagt, für uns Laien, und da zähle ich jetzt mal die meisten Zuhörer auch noch dazu, um was muss man sich denn, kann man es greifbar machen? Um was muss man sich denn kümmern?

Christoph Fischer: Ja, genau. Also grundsätzlich: Warum sollten wir uns darum kümmern? Ich habe es schon erwähnt, wenn man eben auf dem EU-Markt verkaufen möchte und sein Produkt nicht compliant zum Cyber Resilience Act macht, dann kann das durchaus sein, dass einfach der Verkaufsstopp eintritt. Man darf das Produkt nicht rauslegen, man erhält nicht das sogenannte CE-Kennzeichen, oder vergibt es sich nicht selbst und damit ist einfach ein großer Markt nicht adressierbar. Wie kann man jetzt feststellen, ob man vom Cyber Resilience Act betroffen ist? Also grundsätzlich vorweg, es ist nicht irgendwie an eine Firmengröße gekoppelt, also es trifft auch KMUs. Es hat aber andere Regeln. Also eine der Regeln ist, es muss ein Produkt mit digitalen Elementen sein. Also es muss in irgendeiner Art und Weise Software beinhalten. Egal, ob das jetzt eine Firmware ist oder irgendwie ein Softwareprogramm selbst oder sonst irgendein Maschinencode, der jetzt irgendetwas Programmiertes ist. Dann das zweite Kriterium wäre natürlich, man möchte es auf den EU-Markt verkaufen. Möchte man es nicht auf den EU-Markt verkaufen, dann muss ich auch nichts mit Cyber-Resilience- Act-compliant machen. Hingegen möchte mein Produkt vielleicht jemand auf den EU-Markt importieren und es ist nicht CA-compliant, dann muss sich tatsächlich auch der Importeur darum kümmern, dass diese CA-compliance existiert. Es gibt noch weitere Kriterien, eins davon ist die Verbindungen, also wenn diese Produkte irgendwie kommunizieren, also sei es zum Beispiel über Netzwerke, Bluetooth, Wi-Fi, irgendwelche Steckverbindungen, zum Beispiel USB-Anschlüsse, Kabel, USB-Sticks oder auch einfach nur über Datei-Uploads. Wenn so eine Verbindung existiert, dann muss einfach auch der Act befolgt werden, sofern das Ganze einen kommerziellen Hintergrund hat. Also bin ich zum Beispiel ein Open-Source-Contributor, hoste mein Projekt auf GitHub und stelle das gemeinnützig der Allgemeinheit zur Verfügung, dann gibt es da Sonderregelungen, wo man rausfällt. Aber wenn ich eine Firma bin, die ein Produkt jetzt entweder mit einem Preis oder auch gratis anbietet, dann trifft einen dieser Act. Und ja, im Prinzip gibt es da noch Ausnahmen, aber auf die, glaube ich, muss ich jetzt nicht im Detail eingehen, vielleicht sowas wie andere Regulatorien, die treffen für Automobil, Luftfahrt oder Medizin zu. Und ja, vielleicht erzählt uns die Merita, was der Cyber Resilience Act jetzt dann tatsächlich alles fordert.

Merita Fischer: Um den Cyber Resilience Act einfach zu erklären, nehmen wir gerne so ein, wir nennen das CRA-Haus. Das heißt, dass das Ziel von der ganzen Sache ist, konform mit dem CRA zu sein. Für den Hersteller heißt das, für sein Produkt das CE-Kennzeichen zu erlangen. Dafür benötigt eine Konfirmitätserklärung, die unter bestimmten Voraussetzungen selbst von dem Hersteller gemacht werden kann oder durch eine unabhängige Partei und das bildet das Dach von unserem CRA-Haus. Ein Haus ohne Wände ist kein Haus und die Wände von unserem CRA-Haus bilden die Produkt-Security-Anforderungen, die der Cyber Resilience Act mitbringt und auch die Anforderungen an Dokumentation. Darunter fallen Kunden, aber auch technische Dokumentation. Und damit unser Haus nicht so wackelig ist, benötigt es ein Fundament. Und das ist in dem CRA-Haus die Risikoanalyse. Das heißt, die Risikoanalyse bildet die Basis für den ganzen Cyber Resilience Act und auch für Risikoentscheidungen. Sie dient aber auch als Steuerinstrument, um Security-Maßnahmen, Kosten, Entwicklungsaufwände, aber auch User-Experience in Balance zu halten. Der Cyber Resilience Act bringt viele Security-Anforderungen mit sich. Darunter fallen zum Beispiel Software-Updates. Wenn man das im Sinne von unserem CRA-Haus denkt, dann heißt es, dass unser Haus Risse bekommen kann, aber das hindert uns nicht, sie wieder zu schließen. Das heißt, wir schließen diese Risse in Form von Updates, so Aktualisierungen. Ein anderes Beispiel von Security-Anforderungen ist sichere Konfiguration. Im Hausaspekt ist das ja so, wir wollen, dass unsere Tür verschlossen ist, wenn wir zum Beispiel nicht da sind oder so. Der Cyber Resilience Act verlangt auch den Vulnerability-Handling-Prozess. Darunter kann man sich das so vorstellen, dass es eine eingreifende Truppe aus Feuerwehr und Polizei gibt und die greifen nur ein, wenn das Produkt angegriffen oder auch Schwäche aufweist. Das Interessante ist, dass auch dieses Vulnerability Handling Team auf die Risikoanalyse, das heißt die Basis von der ganzen Sache zugreift, wenn diese Cases gehandelt werden müssen. Ein weiteres Beispiel von Security-Anforderungen ist zum Beispiel Datenvertraulichkeit. Wenn wir das im Sinne von dem Haus denken, dann nutzen wir Vorhänge, damit wir in unserem Haus drinnen ja unsere Privatsphäre haben und der Nachbar zum Beispiel uns beim Duschen nicht sieht. Und das ist auch so bei dem Produkt. Das heißt, wir müssen auch feststellen, dass Datenvertraulichkeit da ist.

Götz Müller: Ja, das finde ich jetzt sehr spannend mit dem Haus, weil ich finde es eine gute Metapher und im Lean-Kontext haben wir etwas Vergleichbares. Dort nennt sich das typischerweise TPS-, Toyota-Production-System-Haus und es sind genau die gleichen Elemente, also metaphorisch gesprochen, wobei ich jetzt bei euch rausgehört habe gerade, allein dieser Gedanke mit den Gardinen, so etwas Vergleichbares ist mir im Lean-Kontext jetzt noch nicht begegnet. In dieser Benennung, da muss ich wirklich mal im Anschluss drüber nachdenken. Jetzt vielleicht nochmal einen Schritt zurück. Ihr hattet das Stichwort an ein paar Stellen genannt, Entwicklung, Entwicklungsprozess. Und wenn wir das jetzt auf das Haus abbilden, baue ich ja das Haus, im Sinne von auch ein Produkt, was diesem Haus genügt. Was muss ich da vielleicht auch zusätzlich tun, was man in der Vergangenheit, vor dem Cyber Resilience Act gar nicht drüber nachgedacht hat? Wenn wir jetzt mal, ich meine Software schreibt man schon seit ein paar Jahrzehnten, aber über viele Dinge, wenn ich mal so an meine eigene Geschichte zurückdenke, vor 20 Jahren hat man über viele Dinge gar nicht nachgedacht.

Christoph Fischer: Ja, genau. Also wir kennen es auch aus unserer eigenen Historie. Früher als Studenten haben wir vielleicht auch noch Code geschrieben, der Security-Aspekte jetzt nicht so sehr befolgt haben. Aber wenn man jetzt davon ausgeht, wie würde man jetzt Security in so ein Entwicklungsteam oder in so ein Entwicklungsprojekt zur Produktentwicklung reinbringen, und das geht auch immer wieder Hand in Hand mit dem, was im Cyber Resilience Act steht. Also das sind durchaus auch sehr sinnvolle Themen, die da drin sind, würde man zum Beispiel versuchen, einen Secure Development Prozess zu etablieren, das wird wahrscheinlich auch erst schrittweise gehen. Für diese Secure-Development-Prozesse, da gibt es jetzt auch, sage ich mal, fertige Frameworks, zum Beispiel der Standard IEC 62443, hier die 4-1, für Produkthersteller eine interessante Sache. Da sind halt einfach Aspekte drin, auf was muss man Wert legen. Secure Coding, irgendwie das Secure Design von einem Produkt. Aber was man dann auch immer wieder bei sowohl dem Cyber Resilience Act als auch diesen Standards sieht, das geht oft nicht ganz exakt ins Detail. Und es ist wahrscheinlich manchmal sehr gut, dass es nicht ins Detail geht. Manchmal wünscht man sich als Hersteller dann doch wieder mehr Hilfeführung, weil dann doch Unsicherheiten da drin sind mit, na ja, habe ich es jetzt tatsächlich richtig gemacht oder nicht, das muss man eben Schritt für Schritt für sich in die Entwicklung einführen und dann halt auch die Produkte schrittweise daran führen und besser machen. Auch als Startpunkt, wie die Merita eben mit dem Haus gesagt hat, eben als Fundament sehen wir die Risikoanalyse auch deswegen, weil im Cyber Resilience Act drinsteht, mit unter Beachtung des Risikos sind und dann kommt eine ganze Reihe an Anforderungen zu betrachten, was eben heißt, ich kann diese Anforderung für mich anpassen, sodass ich mir anschaue, was für Risiko ist jetzt für mein Produkt in meinem Kundenumfeld relevant und was für Risiko ist jetzt eigentlich vernachlässigbar. Und genau dieses Steuerinstrument hilft halt dann schon sehr, dass man, nicht einfach nur Security blind implementiert und dann die Kosten explodieren lässt, sondern halt wirklich sehr gezielt an diese Sache rangeht und wirklich schaut, dass man, oder ich würde empfehlen, mit den kritischsten Themen zuerst anzufangen.

Götz Müller: Ja, mir geht da konkret, das ist jetzt ein spontaner Gedanke, Risikoanalyse, fällt mir persönlich die FMEA ein, Fehlermöglichkeitseinflussanalyse, wo ja drei Elemente mit reinspielen, wie wahrscheinlich ist der Fehler, wie wahrscheinlich ist, dass ich ihn entdecke, solche Dinge. Ist das da vergleichbar?

Christoph Fischer: Ja, also sehr, sehr ähnlich. Also es gibt mehrere Modelle in der Cyber-Security-Risikoanalyse. Wir halten uns da sehr gerne an die CIA. Also das ist ein Ansatz, wo es um Schutzziele geht. Das eine ist Confidentiality, also die Vertraulichkeit, Integrity, die Datenintegrität und die Availability, die Verfügbarkeit von dem System. Und dass man immer wieder abgleicht anhand dieser Schutzziele. Was trifft denn jetzt auf mein Produkt zu? Ist es ein Problem, wenn zum Beispiel mein ferngesteuertes Auto mal eine kurze Zeit nicht funktioniert? Das ist wahrscheinlich eine andere Antwort, als wenn man sagt, naja, mein Rauchmelder funktioniert eine kurze Zeit nicht. Und an dem macht man sich halt die Risiken fest. Und dann bewertet man, wie wahrscheinlich ist dieses Risiko und da die Eintrittswahrscheinlichkeit und vielleicht kann man das Ganze quasi angreifen. Ist das möglich für einen zum Beispiel Angreifer über das Internet mit einem Befehl zu erledigen oder muss ich mich zuerst irgendwo an einen Account erschleichen, damit ich dann irgendwas anderes machen kann, um dann das Gerät abstürzen zu lassen.

Götz Müller: Ja, ein anderer Gedanke, der mir noch durch den Kopf geht, ist, viele Produkte haben ja in irgendeiner Form eine Vorgeschichte, also ein Leben vor dem Cyber Resilience Act. Muss ich da jetzt was tun oder kann ich sagen, das habe ich halt und das ist ja schon im Markt?

Christoph Fischer: Ja, das ist eine sehr essentielle Frage. Also zur Erinnerung, wie läuft der Cyber Resilience Act ab? Also in Kraft getreten ist der Act am 10. Dezember 2024 und der wird dann quasi in Wellen scharf geschalten. Wobei die erste Welle kommt jetzt dann am 11. September 26, wo erste Meldepflichten relevant werden, und im Prinzip für die ganzen Produkthersteller. Und da geht es darum, wenn ich als Produkthersteller Erkenntnis bekomme, dass hier, wie sagt man, exploited, also Schwachstellen aktiv ausgenutzt werden, dass man das dann an die Behörden melden muss. Einfach damit dann auch die Kunden informiert werden können mit: Hey, passt mal auf, hier, dieses Produkt hat gerade ein Problem, da muss man etwas tun. Und das Etwas-Tun ist dann oft auch eben im Rahmen dieses Incident-Handling-Prozesses, also diese Feuerwehr- und Polizeitruppe, die man dann im Idealfall schon hat, wo es dann einfach darum geht, diese Probleme einfach wieder zu schließen und dann, ja, im Prinzip auch wieder an die Kunden zu verteilen. Also man kann sich da, ich kenne da eine kleine Geschichte, es gibt einen Hersteller, der hat ein Schloss, also ein Türschloss entwickelt. Das ist ein smartes Türschloss und da ist man mit Fingerprint reingekommen und da gab es auch Vulnerability. Jetzt hat man dieses Türschloss nicht updaten können und im Endeffekt hat das dazu geführt, dass der Hersteller einfach nur noch die Möglichkeit gehabt hat, den Kunden zu empfehlen: Ja, bitte tauscht das Türschloss aus. Das kann eventuell nicht ganz so ideal sein für die Reputation, das bringt Kosten mit sich und eben gerade diese Update-Funktionalität ist auch etwas Zentrales, was im Cyber Resilience Act gefordert wird, was man dann halt umsetzen muss. Jetzt hast du noch nach Bestandsschutz gefragt. Im Prinzip steht da was drin, dass Legacy-Geräte oder Legacy-Produkte im allgemeineren Fall so weiter betrieben werden können ohne Cyber Resilience Act. Und der Cyber Resilience Act, das habe ich, glaube ich, noch nicht erwähnt, wird eben im Dezember 2027 dann vollumfänglich scharf geschaltet. Aber das heißt eben, dass wenn neue Produkte auf den Markt kommen, die müssen dann den Cyber Resilience Act quasi erfüllen.

Götz Müller: Ja, ich vermute mal, in dem Augenblick, wo ich eine Download-Möglichkeit habe, ein bisschen flapsig ausgedrückt, komme ich aus der Nummer ja nicht mehr raus.

Christoph Fischer: Ja, man kommt tatsächlich aus der Nummer sehr, sehr schwer raus. So ein FAQ von der Europäischen Union bringt da auch ein Beispiel mit einem Fernseher, wo eben gesagt wird, man hat ein Smart-TV, die verkauften Smart-TVs, die müssen nicht, compliant sein, aber wenn ich denselben Typ des Smart-TVs neu produziere und wiederum verkaufe, dann muss die neu produzierte Einheit Cyber-Resilience-Act-compliant sein.

Götz Müller: Gut, jetzt eine Frage, die ich immer gern mit einbaue, weil man an dem Thema im Grunde ja nicht mehr vorbeikommt, ist KI, Automatisierung und Co. Ihr habt am Anfang schon ein bisschen das Stichwort Testen genannt. Welche Rolle spielt es dort? Weil ich glaube immer, dass bei solchen Fragen, solchen allgemeinen Fragen, glaube ich, kann man halt auf viele andere Dinge, und da setze ich dann wieder die Lean-Brille auf, kann man halt auch sich vielleicht auch neue Inspirationen holen. Wie gehen denn andere mit dem Thema um?

Merita Fischer: Ja, so… Wir sehen auch, dass so Automation, Automatisierung eigentlich key ist. Und vor allem, wenn es darum geht, CRA-compliant zu werden und auch zu bleiben. Wir sehen, dass der Cyber Resilience Act ein paar Anforderungen hat. Aber wenn man das so wirklich gut implementiert, das ist nicht so wenig Aufwand. Und vor allem, weil der Cyber Resilience Act auch verlangt, dass wir, also wenn wir dieses Produkt weiterhin am EU-Markt verkaufen wollen, dass das auch compliant bleibt. Und zum Beispiel Software-Produkte, heutzutage alles ist so dynamisch, dass Features werden jeden Tag implementiert. Das heißt, wir müssen ständig sicherstellen, dass unser Produkt weiterhin compliant bleibt. Und das kann meiner Meinung nach nur so mit Automatisierung erreicht werden. Der ganze Prozess, wie gesagt, ist zu komplex, um das manuell zu machen. Das ist einfach nicht möglich. Wir sehen auch die Anzahl an Vulnerabilities, das wird weiter steigen. Es ist jetzt auch so, wenn man im Vergleich zum Beispiel vor zwei, drei Jahren oder vielleicht noch länger das anschaut, dass jetzt jeden Tag mehr Vulnerabilities kommen, weil Leute mehr darauf achten. Es gibt Researcher, die mehr schauen, wie sicher ein Produkt ist, aber auch zum Beispiel die Nutzer und so weiter oder selbst die Hersteller. Und ja, meiner Meinung nach, nur mit Automatisierung kannst du das wirklich gut im Griff haben. Es gibt so mehrere, wenn wir den Produktlebenszyklus von einem Produkt anschauen, es gibt mehrere Bereiche, die eigentlich automatisiert werden können, wo Automatisierung den Entwicklern sehr helfen könnte. Da können wir zum Beispiel so mit Testing, dass wir das ganze Produkt so, wir implementieren ein Feature, dann laufen Tests, zum Beispiel statische Code-Analyse oder auch dynamische Tests und wir sehen, wie sicher das ganze Produkt ist. Dann kommt das Produkt auf den Markt und dieser Zyklus wird wiederholt. Und welche Rolle KI spielt? Also zumindest Stand jetzt, KI ist keine Wunderwaffe. Sie unterstützt Cyberkriminelle bei Angriffen. Ein leichtes Beispiel ist so Phishing. Das ist jetzt viel leichter gemacht. Es ist nicht mehr so leicht zu erkennen, ist diese E-Mail eine Phishing-E-Mail oder nicht. Weil früher hat man das merken können, ja okay, hier gibt es grammatische Fehler, hier ist das so und so und jetzt ist das mit Text generieren sehr einfach geworden und man sieht, für den Nutzer ist das viel schwieriger zu erkennen, ist das jetzt wirklich eine legitime E-Mail oder nicht. KI hilft auch den Cyberkriminellen bei der Code-Analyse. Das heißt, die können diesen Code analysieren und schauen, welche Schwachstelle kann ich nutzen. Aber es gibt auch die andere Seite, das heißt, dass auch die Entwickler können KI nutzen, so als Code Companion, um das Ganze, so ein bisschen Geschwindigkeit bei der Code generieren zu bekommen, dass man schneller so Code schreibt und so weiter. Aber vielleicht zwei Stories, so KI bringt auch Angriffsfelder mit sich. Wir haben gesehen, so bei einem Tool, so einem Survey-Tool, was eigentlich benutzt wurde, um Daten, so Surveys anonym zu beantworten, dass man so diese Chats, die jetzt in den Tools so einfach integriert werden, dass man den Chat fragen kann, wenn man so gezielte Fragen stellt, um herauszufinden, was zum Beispiel der Christoph geantwortet hat. Auch wenn es versprochen wurde, dass diese Survey anonym ist. Also das war ein Fall, was wir selbst erlebt haben. Oder wenn wir so mit unserem Tesla fahren und dann Pixel wurden eingeschleust. Und wir haben so in den Bildern, wo man so Navigationssysteme hat und dann fährt man mit dem Auto und auf einmal so, statt links zu biegen, wie die Kurve so ist, dann biegt das Auto rechts, weil das Bild, also so da wurden Pixel eingeschleust und jetzt wird in dem Bild gezeigt, dass die Kurve auf einmal rechts ist. Was vielleicht auch interessant zu erwähnen ist, SANS ist eine führende Organisation im Bereich Cyber Security Training und die haben jetzt eine Survey gemacht, um zu fragen, so wie weit wird KI im Cyber Security genutzt. Da kam heraus, das wurde im September 2025 gemacht, dass es eigentlich momentan für einfachere Aufgaben genutzt wird und noch nicht für Aufgaben, die die KI selber ohne Hilfe von einer Person erledigen kann. Und was man auch vielleicht erwähnen sollte, ist, KI bringt momentan auch ganz viele False Positives. Das heißt, du als Security Experte solltest vielleicht auch mal double checken, ob das tatsächlich auch so ist, so wie die KI sagt. Und damit verschwendet man auch ganz viel Zeit.

Götz Müller: Ja, mir ging gerade noch der Gedanke durch den Kopf, ich meine Risikoanalysen machen ja typischerweise Menschen und ist ja dann immer auch abhängig von der Vorstellungskraft der Beteiligten. Dann habe ich die Vorstellung, das könnte ein Risiko sein. Und da kenne ich jetzt aus meinem Umfeld, da kann eine KI, eine generative KI durchaus eben mal Ideen formulieren, auch wenn sie vielleicht zum Teil Blödsinn sind, aber sie bringt einen unter Umständen auf Gedanken, die ich halt selber vielleicht so im stillen Kämmerchen gar nicht gehabt hätte.

Merita Fischer: Ja, das kann, also natürlich so, wenn man eine Risikoanalyse durchführt, dann, da sind mehrere Personen beteiligt, zum Beispiel von der Entwicklungsperspektive, so die Entwickler, die kennen die Entwicklungsseite ganz gut, dann ist so ein oder mehrere Security-Menschen, die die Security-Brillen haben oder Managers oder vielleicht auch Nutzer und so. Und man versucht so zu Szenarien zu kommen, die vielleicht für dieses Produkt relevant sind. Aber in dem Fall, wie du auch sagst, man könnte vielleicht ja auch KI fragen, um so zu diesen potenziellen Szenarien zu kommen.

Christoph Fischer: Kurzer Nebensatz. Ich würde sagen, dass die AI an der Stelle gut Ideen liefern kann, aber man muss halt einfach dann noch einmal mit Sinn und Verstand drüber lesen und sich das durcharbeiten, um wirklich diese Threads auch zu verifizieren. Also alleine auf die AI zu vertrauen, würde ich jetzt noch nicht. Aber wie du gesagt hast, es ist ein interessantes Hilfsmittel, um einfach mehr Ideen zu generieren.

Götz Müller: Ja, das ist auch eine Frage, die ich mir auch immer wieder stelle. Im Grunde haben wir es gerade schon angerissen, Faktor Mensch, beziehungsweise eben die Rolle des Menschen. Ihr habt schon ein paar Rollen angerissen, gerade im Risikoumfeld. Kann man das noch ein bisschen vertiefen, welche Rolle der Mensch da spielt? Und eventuell eben auch im Sinne von, da kommt dann halt KI wieder als eine Variante ins Spiel. Ich muss halt lernen, ich brauche neue Kompetenzen, damit umzugehen.

Christoph Fischer: Ja, korrekt. Also ich glaube, ich würde mal auf der Anwenderseite anfangen. Auch der Endnutzer bekommt neue Verantwortungen. Zum Beispiel, der muss sich darum kümmern, dass Updates eingespielt sind für sein Produkt oder dass das Produkt sicher konfiguriert ist. Zum Beispiel wären da Standardpasswörter, die man öfter mal in Handbüchern sieht. Und wenn ich jetzt irgendwie ein Gerät ans Internet hänge, dann wäre vielleicht nicht ideal, wenn ich das Standardpasswort behalte, damit der nicht einmal geübte Angreifer einfach nur ins Handbuch reinschauen muss und sich dann auf dem Gerät einloggen kann. Da muss eben der Anwender schon auch Security, ja, eigentlich mitdenken, im Idealfall macht es allerdings der Hersteller und der Entwickler, dem Anwender so leicht, dass er eigentlich gar nicht groß über die Security darüber nachdenken muss Zum Beispiel Updates einspielen, ist vielleicht jetzt noch mit irgendwie ein, ja, keine Ahnung, ein Gerät mit einer Firmware ein Problem. Also zum Beispiel Router upzudaten aus den Jahren 2010. Heutzutage die Fritzbox, die aktualisiert sich einfach automatisch und man muss nicht mehr darüber nachdenken. Und genauso haben sich die Handys ja auch weiterentwickelt. Die Updates, die kommen automatisch rein. Ja, manchmal ärgert man sich drüber, aber im Grunde ist es natürlich eine gute Sache. Ich als Nutzer brauche mich eigentlich nicht mehr darum kümmern, weil es automatisch passiert. Dann vielleicht jetzt ein bisschen mehr aus der Hersteller-Entwickler-Brille. Ich glaube, ganz wichtig ist eben, dass dann der Produkthersteller sich Usable Security überlegt, also UX-Design sich anschaut, wie kann ich die Nutzerführung machen, wie kann ich die ganzen Abläufe in meinem Produkt gestalten, dass Security keine Hürde ist. Also es gibt manche Tools, die mir so untergekommen sind, wo man sich so kompliziert einloggen muss, dass man dann im Prinzip als Nutzer schon gar keinen Bock mehr gehabt hat, das Produkt zu verwenden. Und im Endeffekt, das will man ja als Hersteller gar nicht. Deswegen muss man sich schon überlegen, ja, okay, jetzt habe ich hier eine gewisse Security-Anforderung. Wie kann ich das so hinkriegen, dass der Nutzer es einfach verwendet, es einfach umgesetzt kriegt? Und zusätzlich, was man da natürlich immer wieder auch in der Standardisierungsecke hört, Secure by Design und Secure by Default, das sind dann zwei so Schlagwörter, wo es auch Hilfestellung für den Nutzer ist. Okay, das Produkt soll so designt sein, dass es sicher ist von Natur aus. Und idealerweise per Default, sodass wenn ich das Gerät, das Produkt aus der Box nehme und irgendwo anstecke, dass dann die Security schon voreingestellt ist und nicht irgendwelche Tore offenstehen, die ich dann erst zumachen muss. Bei den Kompetenzen würde ich jetzt eben noch einmal sagen, dass man eigentlich die Security als Querschnittsthema in der Entwicklung platzieren sollte. Also es war bei uns aus der eigenen Erfahrung auch sehr interessant, wenn die Entwickler, die Architekten, die Tester alle sehr security-aware sind und dann diese unterschiedlichsten auch Security-Probleme mitdiskutieren, weil da einfach sehr, sehr viel Know-how mit einfließt und sehr viele unterschiedliche Gedankenrichtungen, was im Endeffekt dann dafür sorgt, dass eigentlich die Gesamtlösung beziehungsweise das Gesamtprodukt dann schon um ein ganzes Stück besser ist, als wie wenn jetzt nur eine Einzelperson sich um Security kümmern muss. Nichtsdestotrotz würde ich auch vorschlagen, zumindest einen, ja, man könnte Security Champion im Team haben, der so als Security-Experte dieses Thema Security in diesem Produkt überwacht und treibt, dass einfach die Leute und die Entwickler auch immer wieder daran erinnert werden mit, hey, da haben wir dieses Security-Thema, da müssen wir auch nochmal drauf schauen. Und als letzte Kompetenz, die ich gerne nochmal erwähnen würde, ist das Incident-Handling bei solchen Produkten. Also quasi, was passiert denn, wenn ein Researcher, also quasi ein gutartiger Hacker, vielleicht eine Universität oder so, eine Vulnerability in dem Produkt findet und dann auf den Hersteller zugeht? Dann gibt es zumindest aus der Historie viele Hersteller, die vielleicht etwas abwehrend reagieren. Meine Empfehlung dazu wäre, dass man eigentlich einen sehr willkommenen Kontakt annimmt, weil dieser Researcher hat sich Mühe gemacht, einen Fehler in meinem Produkt zu finden und damit hat der Hersteller die Möglichkeit, auch diesen Fehler zu beheben. Klar, das kann einmal Geld kosten, das kann Ressourcen binden, aber es ist besser, wir als Hersteller haben das Problem geschlossen, als wie ein Hacker kommt auf das Problem und nutzt einfach das Problem aus, um unser Produkt kaputt zu nutzen. Und da gibt es eben dann die Rolle des Produkt-Security-Incident-Response-Teams. Das kann bei kleinen Organisationen vielleicht eine Person sein, aber im Idealfall sind es vielleicht ein paar mehrere, die auch da im Idealfall eher organisationszentral auftreten und dann mit den Entwicklungseinheiten koordinieren. Ja, okay, hier ist eine Schwachstelle gemeldet worden oder hier ist das Produkt gehackt worden. Wie gehen wir denn mit der Situation um? Wie können wir den Patch bauen, damit das Ganze wieder sicher ist? Und wie kriegen wir das von unseren Kunden raus?

Götz Müller: Ja, das ist dann der Punkt, wo mir das Thema Prozess wieder in den Sinn kommt. Ich sollte da halt irgendwas mal ganz neutral formuliert haben, wie ich damit umgehe. Aber eben zum Beispiel ähnlich wie bei Reklamationen, da kann man jetzt ja auch in eine totale Abwehrhaltung gehen, nach dem Motto, es ist halt der dumme Nutzer, der damit nicht zurechtkommt oder ich kann es halt als Chance nutzen, mein Produkt besser zu machen und ich glaube, da gibt es hohe Affinitäten zur Security oder zur Cyber Security.

Christoph Fischer: Ja, ganz genau. Also ich sehe es auch als Chance, um die ganze Sache besser zu machen. Wenn man sich zu sehr in die Abwehrrolle stellt, dann ist das jetzt schon sehr ungern in der Cyber Security Community gesehen. Das heißt, da kann man sich relativ schnell böse Presse einhandeln. Hinzu kommt eben, dass gerade dieser Cyber Resilience Act auch reinschreibt, dass so etwas, was Coordinated Disclosure genannt wird, umgesetzt wird, wo es eben wirklich darum geht, wenn Schwachstellen an Hersteller gemeldet werden, da soll quasi im Übereinkommen von dem Melder und dem Hersteller so gehandelt werden, dass nicht irgendwie das Problem zu früh bekannt wird. Also keine Ahnung, der Hersteller hat gar keine Chance, das zu patchen. Aber es soll natürlich auch nicht so sein, dass der Hersteller gar nie das Problem angeht. Beziehungsweise, und da kommt jetzt dann wieder die Risikoanalyse mit rein, der Hersteller muss sich mal anschauen. Erstens, ist es überhaupt ein Problem in meinem Kontext? Und wenn ja, wie schwerwiegend ist das Problem? Es ist durchaus, sagen wir mal, auch gängig, dass Themen einfach als Known-Issue deklariert werden. Das sieht man zum Beispiel auch bei Betriebssystemen wie Linux. Da wird nicht jede Security-Schwachstelle gefixt. Aber die Schwerwiegenden, die müssen halt schon gefixt werden, damit wir alle sicher mit unseren Linux oder Routern oder sonst irgendwelchen Systemen weiterarbeiten können.

Götz Müller: Ja, ich vermute mal, ich muss es mindestens auch über einen Prozess dokumentieren, wie ich mich entschieden habe, nachvollziehbar, wenn dann nochmal irgendwas passiert, damit ich zumindest irgendwas aus der Schublade ziehen kann und sagen kann: Ja, wir haben es aufgenommen und wir haben es halt so entschieden. Die Entscheidung kann halt auch mal verkehrt sein.

Christoph Fischer: Ja, natürlich. Also wir sind alle Menschen und können uns da auch mal falsch entscheiden oder einfach einen Aspekt nicht betrachtet haben. Das spiegelt ein bisschen wieder das zurück, was du früher erwähnt hast mit, naja, komme ich überhaupt auf alle Threads, die für mich relevant sind? Und, ja, wenn man dann so einen wichtigen Aspekt oder einen Aspekt, der einfach vielleicht ganz neu ist, aufgrund zum Beispiel neuer Technologie, ja, dann muss man sich dem halt annehmen, den neu bewerten und dann schauen, was hat das für mein Produkt wiederum für eine Auswirkung und schau, dass ich dann quasi angemessen damit umgehe. Also es bringt auch nichts, wenn man versucht, in ein Produkt 100% Security reinzuimplementieren. Mal davon abgesehen, dass 100% Security schon mal per se nicht geht. Aber wenn das Produkt dann so teuer wird, dass keiner mehr kauft, dann hat man auch nichts gewonnen als Hersteller.

Götz Müller: Gut, so ein mit bisschen Blick auf die Uhr auch eine Frage, die ich zum Schluss immer ganz gern stelle, auch wenn jetzt vielleicht Cyber Security Act, ihr hattet es ja vorhin angedeutet, 2027 erst so richtig voll scharf geschaltet wird, würde ich trotzdem mal vermuten, er hat ja dann im Grunde so Pi mal Daumen drei Jahre Historie und wenn wir jetzt meinetwegen fünf, zehn, zwanzig Jahre zurückgehen, hat über das Thema noch keiner gesprochen. Also die Frage, die dahintersteckt, kann man schon irgendwie in irgendeiner Form abschätzen, wie sich es vielleicht 2030 noch entwickeln wird?

Merita Fischer: Ja, also man kann abschätzen. Also so meiner Meinung nach, Security wird tendenziell mehr. Das sieht man ja so mit dem Cyber Resilience Act, dass ja, um alleine diese CE-Erklärung zu erlangen, muss für die Produkte mit digitalen Elementen Cyber Security als Teil davon sein, also mit betrachtet sein. Aber da ist natürlich die Frage, ob die Industrie einen Weg findet, um die Regulierungen auszuhöhlen. Das ist natürlich noch offen. Wir sehen zum Beispiel, wenn wir eine Webseite aufrufen, dann kommen diese Klicks, die wir immer machen, so mit ja alle Cookies akzeptieren oder was auch immer. Und da ist ein bisschen, ja, so dieses mit Data Privacy Act, so DSGVO, ein bisschen, ja, so nicht direkt das Ziel gewesen. Und wir, natürlich, hoffen, dass die Hersteller den Cyber Resilience Act als Chance sehen, um Produkte wirklich sicherer zu machen. Also Security in die Entwicklungsprozesse zu integrieren, Security in die Entwicklungskultur zu integrieren und das nicht als Bürde zu sehen. Und natürlich hoffen wir auch, dass ja, so wie es mit Regulatorien und Standards immer wieder ist, dass die Leute nicht nur schauen, so diese Boxes zu ticken und dann zu sagen, ja, so mein Produkt ist compliant, aber dass man das Produkt wirklich sicher gestaltet. Im Endeffekt, ja, wir hoffen auf eine sichere Zukunft, also sowohl die Produkte schon sicherer sind und unsere Daten nicht einfach so offen irgendwo liegen. Wie du schon erwähnt hast, so der Cyber Resilience Act tritt voll in Kraft am 11. Dezember 2027. Das heißt, dass ab dann alle Produkte, die auf dem EU-Markt, davon abgesehen, dass diese Ausnahmen, die Christoph am Anfang erwähnt hat, dass die Produkte dann Security mit betrachten sollen und auch so als Teil der CE-Erklärung haben sollen. Und vielleicht als Tipp am Ende, so wenn man wirklich gar nicht sicher ist, womit man startet, Risikoanalyse ist immer ein guter Start.

Götz Müller: Ja, das kann ich aus allgemeiner Prozesssicht nur betonen. Nicht umsonst gibt es ja jetzt in dem Kontext, wo ich unterwegs bin, eben eine Prozess-FMEA, wo über genau solche Dinge gesprochen wird. Und warum nicht eben auch die gleichen schon bekannten Konzepte, FMEA zum Beispiel, eben auch für sowas einsetzen. Merita, Christoph, ich danke euch für eure Zeit, für die spannenden Einblicke in wahrscheinlich ein Feld, wo die allermeisten nur als Anwender vielleicht mit in Berührung kommen, aber eben auch mit in Berührung kommen und das wahrscheinlich vom eigenen Kontext nicht völlig fernhalten können. Deshalb vielen Dank für eure Zeit.

Merita Fischer: Danke auch.

Christoph Fischer: Vielen Dank auch von unserer Seite und alles Gute.

Götz Müller: Das war die heutige Episode im Gespräch mit Merita und Christoph Fischer zum Thema Cyber-Security. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 386.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

KI-generierte Zusammenfassung

In dieser Episode spricht Götz Müller mit Merita Fischer und Christoph Fischer über Cyber-Security im Kontext von Produktentwicklung und regulatorischen Anforderungen, insbesondere dem Cyber Resilience Act der Europäischen Union. Beide Gesprächspartner bringen umfangreiche Erfahrung aus der Produkt-Sicherheit sowie der Softwareentwicklung mit und beleuchten das Spannungsfeld zwischen funktionalen Anforderungen eines Produkts und dessen Sicherheit.

Zu Beginn ordnen Merita Fischer und Christoph Fischer das Thema Cyber-Security in drei zentrale Bereiche ein: IT-Security, OT-Security und Produkt-Security. Während sich IT-Security primär mit dem Schutz von Daten und IT-Infrastruktur beschäftigt, liegt der Fokus der OT-Security auf der Betriebssicherheit technischer Anlagen wie Produktionssystemen. Die Produkt-Security wiederum richtet sich auf die sichere Gestaltung von Produkten selbst und gewinnt durch steigende Kundenanforderungen und regulatorische Vorgaben zunehmend an Bedeutung.

Ein zentraler Bestandteil der Diskussion ist der Cyber Resilience Act (CRA), der künftig verbindliche Anforderungen für Produkte mit digitalen Elementen definiert. Christoph Fischer erläutert, dass Unternehmen ohne Einhaltung dieser Anforderungen künftig keinen Zugang mehr zum EU-Markt haben könnten. Der CRA betrifft dabei nicht nur große Unternehmen, sondern auch kleine und mittlere Betriebe, sofern ihre Produkte Software enthalten und in irgendeiner Form kommunizieren, etwa über Netzwerke oder Schnittstellen.

Merita Fischer erklärt den CRA anschaulich anhand eines „Haus-Modells“. Das Dach bildet die Konformitätserklärung inklusive CE-Kennzeichnung. Die Wände bestehen aus konkreten Sicherheitsanforderungen und Dokumentationspflichten. Das Fundament bildet die Risikoanalyse, die als zentrales Steuerungsinstrument dient. Sie hilft dabei, Sicherheitsmaßnahmen gezielt zu priorisieren und in ein sinnvolles Verhältnis zu Kosten, Entwicklungsaufwand und Nutzerfreundlichkeit zu setzen.

Die Risikoanalyse wird von beiden Gesprächspartnern als essenzieller Ausgangspunkt hervorgehoben. Christoph Fischer beschreibt dabei Ansätze wie das CIA-Modell, das die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit betrachtet. Diese helfen, Risiken systematisch zu bewerten und angemessene Maßnahmen abzuleiten. Dabei wird betont, dass nicht maximale Sicherheit das Ziel ist, sondern eine risikobasierte, wirtschaftlich sinnvolle Umsetzung.

Ein weiterer wichtiger Aspekt ist die Integration von Security in den Entwicklungsprozess. Christoph Fischer spricht von „Secure Development“, das schrittweise etabliert werden sollte und sich an bestehenden Standards orientieren kann. Gleichzeitig bleibt ein gewisser Interpretationsspielraum, was für Unternehmen sowohl Herausforderung als auch Chance darstellt.

Auch bestehende Produkte werden thematisiert. Während sogenannte Legacy-Produkte unter bestimmten Bedingungen weiterhin betrieben werden dürfen, müssen neu produzierte oder aktualisierte Produkte den Anforderungen des CRA entsprechen. Besonders wichtig ist dabei die Fähigkeit zu Software-Updates, um Sicherheitslücken nachträglich schließen zu können.

Ein weiterer Schwerpunkt liegt auf der Rolle von Automatisierung und Künstlicher Intelligenz. Merita Fischer betont, dass die kontinuierliche Einhaltung der Sicherheitsanforderungen ohne Automatisierung kaum möglich ist, da Softwareprodukte ständig weiterentwickelt werden. Automatisierte Tests und Analysen helfen dabei, Sicherheitslücken frühzeitig zu erkennen. Gleichzeitig weist sie darauf hin, dass KI sowohl von Entwicklern als auch von Angreifern genutzt wird. Während sie die Effizienz in der Entwicklung steigern kann, erleichtert sie auch Angriffe wie Phishing oder das Auffinden von Schwachstellen. Zudem ist die Qualität von KI-Ergebnissen noch nicht zuverlässig genug, um vollständig darauf zu vertrauen.

Der Faktor Mensch spielt ebenfalls eine zentrale Rolle. Nutzer tragen Verantwortung, etwa durch das Einspielen von Updates oder die sichere Konfiguration von Geräten. Gleichzeitig liegt es in der Verantwortung der Hersteller, Sicherheit möglichst benutzerfreundlich zu gestalten. Konzepte wie „Secure by Design“ und „Secure by Default“ sollen sicherstellen, dass Produkte bereits in ihrer Grundkonfiguration sicher sind.

Innerhalb von Unternehmen sollte Security als Querschnittsthema verstanden werden. Unterschiedliche Rollen wie Entwickler, Tester und Architekten sollten gemeinsam an Sicherheitsfragen arbeiten. Ergänzend empfiehlt Christoph Fischer die Etablierung eines „Security Champions“ im Team sowie klar definierte Prozesse für den Umgang mit Sicherheitsvorfällen. Eine offene Zusammenarbeit mit externen Sicherheitsforschern wird als Chance gesehen, Produkte kontinuierlich zu verbessern.

Abschließend werfen Merita Fischer und Christoph Fischer einen Blick in die Zukunft. Sie erwarten, dass die Bedeutung von Cyber-Security weiter zunehmen wird. Entscheidend wird sein, ob Unternehmen regulatorische Anforderungen lediglich formal erfüllen oder tatsächlich als Anlass für nachhaltige Verbesserungen nutzen. Als pragmatischen Einstieg empfehlen beide, mit einer fundierten Risikoanalyse zu beginnen, um systematisch und zielgerichtet in das Thema einzusteigen.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...