Cyber Resilience Act - Was Unternehmen jetzt wissen müssen!

00:00:01: Willkommen zum IT Security Podcast von cirosec, den bekanntesten Anbieter von IT Security Beratung, Pentests, Red-Teaming und Incident Response.

00:00:10: In dieser Episode sprechen Steffen & Benjamin über den Cyber Resilience Act und die Auswirkungen der neuen europäischen Regulierung auf Hersteller und Unternehmen.

00:00:18: Dabei geht es unter anderem um Meldepflichten für Schwachstellen und Sicherheitsvorfälle, Anforderungen an sichere Softwareentwicklungsprozesse, Risikobetrachtungen.

00:00:29: Außerdem klären die beiden, welche Produkte überhaupt vom Cyber Resilience-Act betroffen sind.

00:00:34: Welche Herausforderungen Unternehmen bei der Umsetzung erwarten und in welchen Bereichen Unterstützung und Beratung besonders gefragt sind?

00:00:42: Zu Beginn wäre es super wenn ihr euch einfach mal kurz vorstellen könntet!

00:00:45: Ich bin Benjamin, ich bin Senior Berater und ich habe als eines der Kernthemen die Softwareentwicklung also vor allem die sichere Softwareentwickelung.

00:00:55: Beschäftige ich mich zum Beispiel mit dem Software-Entwicklungsprozess und schaue wo kann man Stellschrauben anziehen oder neue Sachen einführen, die die Softwareentwicklung sicherer machen?

00:01:02: Oder das Produkt ist am Ende rauskommt sicherer.

00:01:05: Und dann beschäftige ich mir natürlich auch mit allem was da außen rum passiert also zb Tools die man in den Softwareentwirkungsprozess einbringen kann.

00:01:12: aber Ich schau auch das fertige Produkt an und einmal analysiere Softwarearchitekturen oder mach gegebenenfalls sogar Code Reviews.

00:01:20: du Steffen was machst Du so?

00:01:21: Ich beschäftige mich mit Informationssicherheitsmanagement.

00:01:24: Das heißt, ich helfe Kunden die ISONormSiebundzwanzigtausendeins zu implementieren und beschäftige mir viel mit gesetzlichen unregulatorischen Vorgaben wie NIS-II oder eben den Cyber Resilience Act.

00:01:39: Super!

00:01:40: Vielen Dank ihr zwei.

00:01:41: dann legen wir doch mal los Benjamin.

00:01:43: was ist denn eigentlich überhaupt der Cyber Resillience Act?

00:01:46: Der Cyber Resilliance Act is eine EU Verordnung Das Ziel hat, Produkte mit digitalen Elementen sicherer zu machen.

00:01:55: Und was das jetzt konkret bedeutet ist so ein bisschen komplexer weil naja man kann nicht einfach sagen macht eure Produkte sicherer sondern es besteht aus vielen verschiedenen Aspekten.

00:02:04: aber der Kern des Ganzen ist dass am Ende für Hersteller Vorgaben gemacht werden wie sie ihre Produkte zu entwickeln haben und darüber hinaus noch ein paar weitere Sachen die in der Sache geregelt werden.

00:02:16: Aber der Kern Ist, es gibt Vorgabe wie man bei der Entwicklung von Produkten, die irgendwie Software enthalten oder noch weitergefasst die digitale Elemente enthalten vorgehen muss.

00:02:27: Gut und was sind denn die typischen Themen, die der Cyber Resilience

00:02:30: Act abdeckt?

00:02:32: Ja, der Cyber Resillience Act deckt wie ich gerade schon gesagt habe ganz viel aus dem Software, dem Produktentwicklungsprozess und damit auch dem Software Entwicklungsprozesse ab.

00:02:39: aber es gibt auch andere Punkte zum Beispiel der Meldeprozess-Teile des Cyber Resalience Acts.

00:02:44: also Es gibt Anforderungen dass in bestimmten Fällen Meldung erfolgen muss.

00:02:50: Da können wir bestimmt nachher im Detail nochmal drüber reden, dann gibt es eben den Software-Entwicklungsprozess mit dem man sich beschäftigen muss.

00:02:56: Dann gibt es das Thema der langfristigen Wartung eines Produkts.

00:03:01: Ich muss mir überlegen na ja wie lange soll denn mein Produkt eigentlich bei den Anwendern unterwegs sein und Über welchen Zeitraum muss ich mein Produkt sicher gestalten?

00:03:11: oder wie muss die Sicherheit dieses Produkt gewährleistet sein?

00:03:16: entstehen sehr, sehr viele Dokumentationspflichten.

00:03:18: Und am Ende kommt noch eine Konformitätsbewertung in der ich sage, na ja ich erfülle den Cyber Resilience Act.

00:03:24: Gilt der Cyber Resillience Act denn überhaupt schon?

00:03:26: Der Cyber Resilliance Act ist ne EU-Verordnung und ist damit schon in Kraft.

00:03:30: also ich muss das nicht noch... Also nicht ich sondern die... Das müssen die einzelnen Nationalstaaten nicht noch ins nationale Recht umsetzen.

00:03:37: aber Nicht alles gilt sofort was jetzt ganz schnell in der nächsten Zeit kommt, am elften September nämlich.

00:03:46: Da kommen die ersten Meldepflichten und dann die vollständigen Anforderungen für Produkte, die kommen erst ab dem elften Dezember 2026.

00:03:54: Dann lass uns doch mal über die Meldpflichte reden!

00:03:57: Ja also ich habe als Hersteller sehr konkrete Anforderung was die Melldung angeht wenn bestimmte Fälle eintreten und zwar das was eintretend muss damit ich eine Meldung machen muss, ist dass ich eine ausgenutzte Schwachstelle in meinem Produkt habe.

00:04:14: Eine ausgenutze Schwachsstelle kann zum Beispiel sein das der Lock-in in meinen Produkt sei es einen Router

00:04:20: z.B.,

00:04:21: einfach nicht richtig funktioniert und man mit beliebigen Passpattern reinkommt.

00:04:23: Das wäre jetzt eine sehr offensichtliche Schwachsstelle.

00:04:25: aber wenn mir als Hersteller bekannt wird, dass eine Schwachställe in meinem produkt drin ist und diese Schwachstände aus genutzt wird ausgenutzt wird.

00:04:34: Nicht jede Schwachstelle muss sofort gemeldet werden, sondern wenn mir bekannt wird dass eine schwachstell ausgenutscht wird dann muss ich mich um diese Meldungen kümmern.

00:04:41: Wie

00:04:41: genau funktioniert denn das melden?

00:04:43: Das bedeutet konkret dass Ich an die Meldeplattform die von der Enisa bereitgestellt wird gehe und dort eine Erstmeldung mache.

00:04:52: Die Fristen sind relativ simpel gestaltet.

00:04:55: Ich habe erst mal nach vierundzwanzig Stunden muss ich gemeldete haben Dass ich eine schwache Stelle habe die auch aus genutzt.

00:05:02: Nach seventy zwei Stunden muss ich dann eine detailliertere Meldung erbringen.

00:05:06: in dieser Meldungen, müssen da zum Beispiel Maßnahmen drin sein die ergriffen werden können von Benutzern auch wie die Art der Ausnutzung ist und das es dann weiterhin keine vollständige Meldungs sondern es reicht hier eben noch nicht ganz präzise zu melden weil nach zwanzig Stunden hat man häufig auch einfach nicht die Information die man dafür braucht.

00:05:25: aber In den meisten Fällen muss ich dann nach zwei Wochen eine vollständige Meldung machen, wo ich das eben alles im Detail beschreiben kann.

00:05:32: Und gegebenenfalls je nach der Schwere der Ausnutzung muss ich auch meine Kunden informieren.

00:05:38: Gibt es noch weitere Meldpflichten oder geht es nur um die Schwachstellen im Produkt selber?

00:05:46: Im Produkt ist es relativ simpel da es sich an sich na wenns mit dem Produkt zu tun hat, dann muss ich's halt melden.

00:05:52: aber es gibt auch darüber hinausgehende Sachen die zu einer Meldepflicht führen, zum Beispiel einen Sicherheitsvorfall der Auswirkungen auf das Produkt haben kann.

00:06:01: Also es muss gar nicht das Produkt selbst betroffen sein sondern zb wenn eine Datenbank mit Kundendaten von Kunden die dieses Produkt einsetzen abfließen und da noch irgendwelche Details drin enthalten sind wie Auswirkung auf die Nutzung des Produkts haben können dann muss ich auch ne Meldung erbringen.

00:06:15: dass ist ein Sicherheitsvorfall der gemeldet werden muss.

00:06:18: Das ist aber nur bei schwerwiegenden Sicherheits vor Fällen definiert als zu melden.

00:06:23: Schwerwiegend bedeutet konkret, dass es eben Auswirkungen hat auf das Produkt.

00:06:28: oder insbesondere zum Beispiel die Ausführung von Code ist ein exemplarisches Beispiel, die im Cyber Resilience Act konkret benannt wurde als Einfall in dem dann eine Meldung erfolgen muss.

00:06:40: Das ist übrigens jetzt direkt vergleichbar auch mit den Meldepflichten bei Danis II.

00:06:45: Auch dort sind enge Fristen vorgegeben – auch diese Vierundzwanzigstunden frisst und die Zweiundsiebzig Stunden frisst.

00:06:52: Auch dort müssen nur erhebliche Sicherheitsvorfälle gemeldet werden.

00:06:56: Und die Unternehmen haben eben jetzt die Herausforderung, dass sie diese Meldungen in ihren bestehenden Security-Incidentmanagementprozess einbauen.

00:07:06: Dass dort eben eine Bewertung erfolgt ist der Vorfall schwerwiegend oder erhebig und wenn ja muss dann eben die Meldung über die jeweilige Plattform erfolgen.

00:07:16: Bei NIS II wäre das eben das BSI-Protal Und beim Cyber Resilience Act diese NISA-Plattform, von der wir eben gehört haben.

00:07:24: Die NISA Plattform gibt es leider noch nicht.

00:07:26: die kommt ziemlich genau zum Stichtag hoffentlich dann raus.

00:07:30: Ein Punkt den ich noch klar machen möchte schwerwiegendes Sicherheitsvorfälle müssen gemeldet werden aber ausgenutzte Schwachstellen am Produkt müssen prinzipiell gemeldete werden.

00:07:38: da darf man nicht durcheinander kommen.

00:07:40: Gut jetzt haben wir schon einiges über das Meldewesen gehört Aber der Cyber Resillience Act deckt ja noch viel mehr Bereiche ab unter anderem die Softwareentwicklungsprozesse auf Sicherheit zu optimieren.

00:07:51: Was ist denn da konkret zu tun?

00:07:53: Ja, also wenn man nur melden würde würden die Produkte an sich ja nicht sicherer.

00:07:57: es würde vielleicht für ein bisschen schlechter PR sorgen.

00:07:59: aber man muss konkret dafür sorgen dass das Produkt sicherer wird.

00:08:03: zumindest ist die Hoffnung dass das produkt dadurch sicherer werden.

00:08:06: Man hat Vorgaben dass man zum Beispiel gleich beim Beginn eines der Produktentwicklung Darauf dafür sorgen muss, dass es so konzipiert wird, dass die grundlegenden Cyber-Sicherheitsanforderungen des Cyber Resilience Acts erfüllt werden.

00:08:20: Was sind denn die grundlehmenden Anforderungen?

00:08:23: Die sind im Anhang relativ klar definiert – das sind ein paar Sachen, die sind völlig offensichtlich.

00:08:28: da ist zum Beispiel drin, dass man für eine sichere Authentifizierung sorgen muss.

00:08:34: also wenn sie sich anmelden, dass alles sicher abläuft.

00:08:38: dann gibt's Themen, dass Berechtigungsprüfung implementiert werden müssen.

00:08:42: dann gibt es Themen, dass das Produkt frei von Schwachstellen sein muss.

00:08:47: Dann gibt es das Thema, dass eine sichere Standardkonfiguration drin sein muss die Kontrollmechanismen zum Schutz vor unbefugten Zugriff und habe ich im Wesentlichen ja schon gesagt Es muss die Vertraulichkeitsschützen der Daten, die da drauf gespeichert sind.

00:09:00: Das muss die Integrität von den Daten, wie gespeicherter oder übermittelt werden schützen usw.

00:09:05: Also viele, viele Themen drin, die eigentlich klassischerweise bei der sicheren Softwareentwicklung halt e-beachtet werden müssen.

00:09:12: Aber eben hier sind sie ganz konkret formuliert als ein Thema, das schon im Konzept des Produktes bedachtet werden

00:09:18: muss."

00:09:19: Wie kann ich denn diese Anforderungen in meinen Softwareentwicklungsprozess integrieren?

00:09:24: Was muss sich beim Konzept

00:09:26: beachten?".

00:09:27: Die Frage ist wie fange ich überhaupt an bei einer Konzeptionierung und dass ich auf die Sachen achte.

00:09:31: Und um das zu identifizieren, muss ich halt erstmal eine Risikobewertung machen.

00:09:35: also Ich muss überlegen welche Cyber Sicherheitsrisiken bringt mein Produkt mit?

00:09:40: Gibt es dafür bestimmte Techniken für die Risikobetrachtung?

00:09:44: Typischerweise ist das, was man in der IT-Sicherheit als ein Thread Modeling kennt.

00:09:48: Also eine Bedrohungsmodellierung.

00:09:50: Ich versuche, Bedrohhungen für mein Produkt zu identifizieren.

00:09:54: Da gibt's viele verschiedene Techniken und Ansätze, die man wählen kann.

00:09:58: Zum Beispiel gibt´s... Das bekannteste Modell ist Stride Aber der Cyber Resilience Act schlägt hier nicht vor, dass ich ein konkretes Modell nutze sondern der Kern ist.

00:10:07: Ich muss mir überlegen welche Cyber-Sicherheitsrisiken sich da ergeben.

00:10:12: Da liegt keine Pflicht vor eine bestimmte Struktur zu wählen.

00:10:17: Der Kern ist nur in meinen Produktentwicklungsprozessen oder Softwareentwickungsprozesse einen Schritt haben indem ich diese Risiken strukturiert erfasse.

00:10:28: Wenn ich die Risiken mal identifiziert habe, wie geht es denn dann weiter?

00:10:33: Und basierend auf diesen Risiken sind dann die restlichen Maßnahmen zu identifizieren, die ich ergreife um mein Produkt sicherzumachen.

00:10:39: Der Kern ist also dass sich in meinem Softwareentwicklungsprozess oder in meinen Produktentwickungsprozess sehr früh anfangen wir darüber Gedanken zu machen was kann denn schief gehen bei meinem Produkt und dann eben in der weiteren Entwicklung Maßnahmen gegen diese Risiken zu ergreifen.

00:10:52: Kernes auch, dass ich eben am Ende abgleiche ob ich diese Risiken die ich identifiziert habe tatsächlich adressiert hab und das ist dann eben auch ein Teil der Konformitätsbewertung die am ende prüft.

00:11:01: Ja, habe ich denn überhaupt Risiken erfasst?

00:11:02: Habe ich die Maßnahmen ergriffen nicht aufgeschrieben hat Und liegen alle Dokumentationen die ich dafür erzeugt habe?

00:11:07: Ich muss also auch dokumentieren was für Risiken denn vorliegen und welche Risiken ich überhaupt adressiere oder auch in welchem Kontext das Produkt überhaupt eingesetzt wird und worauf Welchen auf welchen Annahmen meine risikomodellierung fußt Dass das alles sinnvoll dokumentiert ist nicht nach außen gegeben wird, aber intern im Unternehmen vorliegt.

00:11:24: Dass eben sichergestellt werden kann dass diese Modellierung und dieses Vorgehensweise sinnvoll und angemessen ist für das jeweilige Produkt.

00:11:32: Was muss man denn darüber hinaus noch beachten?

00:11:35: Was auch darüber hinaus geht über den Software-Entwicklungsprozess ist ganz spannend, dass natürlich ich nicht nur einen Produkt einfach auf den Markt werfen kann und sagen ja hier jetzt ist es sicher sondern ein wesentlicher Bestandteil ist auch da sich dafür sorgen muss dass das Produkt über einen Unterstützungszeitraum hinweg unterstützt wird.

00:11:52: Und diesen Unterstützungsraum muss ich definieren.

00:11:57: Typischerweise geht man von mindestens fünf Jahren aus im Cyber Resilience Act, aber der muss der typischen Nutzungszeit des Produkts entsprechen.

00:12:05: Das heißt ich muss vorher mir Gedanken darüber machen ja wie lang wird dann das Produkt typischerweise leben?

00:12:11: und dann ist die Frage naja was bedeutet denn Diese?

00:12:14: bedeuten diese Risiken dann über die gesamte Lebenszeiten.

00:12:17: Jetzt muss ich über diese Lebenszeit auch dafür sorgen, dass Schwachstellen, die mir dann bekannt werden, auch adressiert

00:12:22: werden.".

00:12:22: Das klingt ja ganz schön kompliziert!

00:12:25: Wie kann ich das denn in den Griff bekommen?

00:12:27: Also ich brauche jetzt wieder ein Prozess zum Schwachstellenmanagement für dieses Produkt.

00:12:32: Ich muss mir überlegen... Auch was passiert denn wenn ich eine Schwachsstelle

00:12:34: identifiziere?!

00:12:35: Ich brauche dann einen Prozess für….

00:12:36: Wenn ich eine schwachstelle habe, muss sich Maßnahmen ergreifen.

00:12:40: Das kann ich natürlich abwägen Wie schwerwiegend die Schwachstelle ist, aber im Kern ist die Aussage des Cyber Resilience Act.

00:12:46: Ich muss Software Updates für meine Produkte bereitstellen und das kann natürlich ziemlich komplex werden je nachdem wie mein Produkt aufgebaut ist.

00:12:53: es gibt ja auch Produkte mit digitalen Elementen die jetzt nicht direkt dem Internet hängen Und trotzdem muss ich prinzipiell in der Lage sein Schwachstellen dafür zu beheben und die dann auf irgendeine Art und Weise diese Behebungsmaßnahmen zum Kunden zu bringen.

00:13:06: Ich glaube dass ist was gerade viele Hersteller von tatsächlich Geräten nicht von Software ganz schön ins Schwitzen bringen könnte.

00:13:14: Sind wir jetzt damit schon durch mit der Erfüllung der Anforderungen oder gibt es noch mehr zu tun?

00:13:19: Ja, also diese Konformitätsbewertung ist natürlich ein großes Ding weil gerade im Bereich derer die bisher vor allem Software entwickeln und nicht tatsächlich Produkte entwickeln ist so eine Konformität Bewertung was neu ist.

00:13:32: da muss ich mir jetzt Prozesse für überlegen definieren und die dann auch umsetzen, wie denn so eine Konformitätsbewertung zu erfolgen hat.

00:13:39: In den meisten Fällen kann man diese Konformität selbst machen.

00:13:43: Da prüft man habe ich alle Dokumente richtig abgelegt, habe ich dann alle Schritte durchgeführt usw.. Für reine Softwareentwickler ist das wahrscheinlich schwieriger für sie, die bisher schon Produkte herstellen, die dann in andere Produktkonformitätes Bewertungen machen müssen.

00:13:58: da ist es wahrscheinlich einfacher.

00:13:59: Die haben dafür dann andere Probleme bei der ganzen Sache weil die häufig die Software-Entwicklung etwas stiefmütterlich betrachten.

00:14:06: Der Cyber Resilience Act scheint mir ja ganz schön weitreichend zu sein und viele Anforderungen an die Unternehmen zu stellen, was gilt es denn hier genau zu beachten?

00:14:16: Wir haben nicht so viel Zeit um den Cyber Resillience Act ganz zeitlich zu betrachen, um da jetzt alle Anforderung im Detail zu besprechen.

00:14:22: also da gibt's viele, viele spannende Dinge, um die man sich kümmern muss.

00:14:25: zum Beispiel ein Punkt, den ich wahnsinnig sinnvoll finde der aber In den letzten jahren auch immer größer wurde aber halt immer noch stiefmütterlich behandelt wird in vielen fällen ist eben dass ich.

00:14:37: Wissen muss was für Trittanbieterkomponenten in meinem Produkt drin sind also klassische Produktentwicklung.

00:14:42: Ich habe eine bill of materials, ich brauche jetzt ein Software Bill of Materials.

00:14:46: Ich muss wissen welche Tritt Anbieter Komponent bei mir drin sind das es eigentlich Keine große Neuigkeit, weil sich das in den letzten Jahren etabliert hat.

00:14:54: Trotzdem muss ich es jetzt strukturiert machen!

00:14:57: Ich muss diese Software Bill of Materials für das ausgelieferte Produkt haben und ich muss dann aber auch Prozesse haben die beschreiben wie ich denn bei der Auswahl von solchen Trittanbieter-Komponenten vorgehe dass ich eben auch sichere Tritt Anbietern einsetze oder sichere Komponenteneinsätze.

00:15:13: und das ist was was viele bisher nicht auf dem Schirm haben, weil das Erzeugung von so einer Software Bill of Materials ist ein Automatismus.

00:15:19: Da gibt es Tools für... Das habe ich schnell abgebildet in meiner Pipeline.

00:15:22: aber dieses Ding wie wähle ich eigentlich die Komponenten aus?

00:15:25: Und da hab' ich jetzt Anforderungen aus dem Cyber Resilience Act.

00:15:28: Ich glaube dass es etwas noch ein bisschen Arbeit ist.

00:15:32: Und müssen die Hersteller auch dokumentieren und Dokumente für die Verbraucher- und Kunden bereitstellen?

00:15:38: Ja sie müssen Dokumenter an die Verbaucher bereit stellen.

00:15:42: in diesen Dokumenten für die Verbraucher, also im Prinzip in der Bedienungsanleitung muss drinstehen wie man das Produkt sicher einsetzt.

00:15:49: Also Hinweise darauf zum Beispiel ja dieses Gerät bitte nicht direkt ins Internet exponieren wäre eine naheliegender Hinweis für die Anwender.

00:15:58: aber der Kern ist im Wesentlichen dass sehr viel interne Dokumentation entsteht.

00:16:02: ich habe gerade die Software Bill of Materials benannt.

00:16:04: Ich hab diese Dokumentations der erfassten Risiken, die Dokumentions der Rahmenbedingungen und so weiter intern zu erbringen.

00:16:14: Wie kann ich als Unternehmen feststellen, ob ich überhaupt vom Cyber Resilience Act betroffen bin?

00:16:19: Kannst du da vielleicht noch mal ein paar Hinweise geben?

00:16:21: Ja also das muss man bisschen abgrenzen.

00:16:23: in manchen Fällen ist es relativ offensichtlich wenn ein Produkt entwickelt wird dass digitale Elemente hat dann trifft der Cyber Resillience Act zu.

00:16:34: Das heißt da fällt auch Spielzeug darunter so wie beispielsweise Puppen die sprechen

00:16:39: können.

00:16:40: ja wenn sie sprechen kann Dann ist die Frage Fällt es schon unter ein Produkt mit digitalen Elementen?

00:16:46: Hat das entsprechende Schnittstellen über die drauf zugegriffen werden kann?

00:16:49: Da möchte ich keine definitive Aussage treffen.

00:16:52: Die Frage einer digitalen Schnittstelle ist hier ein bisschen unspezifiziert, eine digitale Schnittsstelle kann halt sehr viel sein!

00:16:59: Ich denke da wird sich in den nächsten Wochen, Monaten und Jahren zeigen was denn da konkret drunter fällt.

00:17:05: also einen Lautsprecher der irgendeinen Digital-Analogwandler betrieben wird hat ja auf der einen Seite eine digitale Schnittstelle.

00:17:12: Die wird aber nicht für den Kunden exponiert, deshalb wahrscheinlich nicht!

00:17:17: Aber wenn irgendwas an einer Stelle ne Debug-Schnittstell hat?

00:17:20: Vielleicht doch... ...aber ich glaube man kann definitiv sagen in dem Moment wo das Ding irgendwie in ein Netzwerk eingebunden wird Dann trifft er Cyber Resilience Act zu.

00:17:33: Ob jetzt ne Fernbedienung mit ner Infrarotschnittsstelle die ja im Kern auch digital ist Ob das tatsächlich schon dazu führt, dass man den Cyber Resilience Act führt, fällt möglicherweise.

00:17:44: Aber hier ist vielleicht eine Frage die eher eine Anwaltskanzlei beantworten kann als wir.

00:17:49: Was denkst du denn?

00:17:50: Wie hoch der Aufwand für die Unternehmen ist?

00:17:53: Haben es die Unternehmen schwer oder würde es ihnen leicht fallen?

00:17:58: Das ist eine ganz schwierige Frage weil die Unternehmen halt dann doch zu heterogen sind.

00:18:05: Ich glaube, dass in vielen Unternehmen das Thema der sicheren Softwareentwicklung nicht ausreichend betrachtet wird aktuell.

00:18:14: Gerade dieses Thema der Durchfung einer Bedrohungsmodellierung – das wird bei zu wenigen Unternehmen gemacht und das muss jetzt sein!

00:18:22: Ich glaub da werden einige ganz schön Arbeit reinstecken müssen.

00:18:26: Unternehmen die das schon machen?

00:18:28: Bei denen wird es einfacher.

00:18:29: Die haben halt wesentliche Anteile.

00:18:30: Die Voraussetzung für den Cyber Resilience Act einfach schon erfüllt….

00:18:35: Für die kommt natürlich weiterhin Arbeit dazu, zum Beispiel die Dokumentationspflichten oder das Meldewesen.

00:18:41: Aber dann wird es einfacher.

00:18:44: Steffen aber du kennst ja ein paar andere regulatorische Sachen, die die Erfüllung des Cyber Resilience Acts vielleicht ein bisschen einfacher machen?

00:18:51: Es geht durchaus überschneidungen da man natürlich aktuell den IS-II Richtlinien, die ganz viele Unternehmen betrifft.

00:18:57: Da sind ungefähr dreißig Tausend Unternehmen allein in Deutschland von Betroffen und den IS II fordert analog zum Cyber Resilience Act Prozesse zur Entwicklung von sicherer Software.

00:19:10: Das heißt, Unternehmen, die schon eines zwei dran sind und in diesem Bereich schon tätig sind können die Ergebnisse direkt auch für die Erfüllung des Cyber Resillience Acts nutzen.

00:19:21: Die ganze Dokumentation und der bürokratische Overhead, den wir gerade eben gehört haben, da muss natürlich trotzdem noch geleistet werden aber die inhaltliche Seite ist dann vielleicht teilweise abgedeckt Und ganz viele Unternehmen orientieren sich ja an der ISO-27001-Norm.

00:19:38: Sie sind vielleicht sogar zertifiziert und auch dort gibt es einige Controls, also Vorgaben zur Entwicklung von sicherer Software.

00:19:46: Dort ist zum Beispiel auch vorgesehen dass man Risikobetrachtungen durchführt, endlich wie wir das eben schon gehört haben für den Cyber Resilience Act.

00:19:54: Das heißt Unternehmen die schon länger ISO-27001 umsetzen können direkt auf der inhaltlichen Ebene davon profitieren und müssen wahrscheinlich dann weniger tun für die Umsetzung des Cyber Resilience Act.

00:20:09: Und können sich dann auf die Dokumentationen, auf die Konformitätserklärung und auf das Meldewesen fokussieren.

00:20:16: Ich denke damit ist zumindest ein Anfang erzählt.

00:20:18: zum Cyber Resillience Act da jetzt im Detail den ganzen Gesetzestext zu lesen.

00:20:24: Das ist natürlich für wenige möglich und manchmal ist es auch relativ schwer zu lesern.

00:20:28: ich würde aber für alle die damit in Verrührungen kommen empfehlen zumindest den Artikel dreizehn für die Erpflichten bei der Entwicklung der Produkte zu lesen.

00:20:37: Artikel vierzehn, für die Meldepflichten bei Sicherheitsvorfällen ist auf jeden Fall sinnvoll und für die Konformitätsbewertung sollte man Artikel zweiunddreißig lesen.

00:20:47: Und dann Anhang eins für konkrete Anforderungen und Anhang sieben für die Inhalte der technischen Dokumentation.

00:20:53: Dann hat man schon einen wesentlichen Teil geschafft um einmal zu verstehen was man eigentlich tun muss.

00:20:59: Ja, vielen Dank, Benni.

00:21:00: Das ist ja schon mal eine gute Hilfestellung für unsere Zuhörerinnen und Zuhörer!

00:21:04: Was sind denn eigentlich deine typischen Beratungsthemen rund um den Cyber Resilience Act?

00:21:09: Wo benötigen denn unsere Kunden besonders deine Unterstützung?

00:21:13: Die meisten fangen mit einer Gap-Analyse an.

00:21:15: also sie wollen wissen was müssen wir dann eigentlich noch tun, um den cyber resilience act zu erfüllen?

00:21:22: Machen wir einen Workshop und sprechen darüber, wie denn die Softwareentwicklung funktioniert.

00:21:26: Was eigentlich für Produkte dabei sind?

00:21:27: Dann gucken wir an welchen Stellen man gegebenenfalls nochmal ein Anwalt fragen muss ob das Produkt überhaupt darunter fällt.

00:21:33: dann guckt man ja habt ihr denn schon Meldeprozesse?

00:21:36: gibt's irgendwo eine Stelle wo Dritte euch Schwachstellen melden können diesen euren Produkten gefunden haben usw.

00:21:42: Und dann dokumentieren wird es und identifizieren halt was fehlt?

00:21:46: und dann ist da schon mal zumindest ... einen grober Rahmen geschaffen, dass man weiß wie viel man dann eigentlich noch zu tun hat bis es dann Ende... ... twenty-seven und zwanzig tatsächlich vollumfänglich umgesetzt werden muss.

00:21:57: Und dann geht's natürlich darum das man jetzt den Softwareentwicklungsprozess betrachtet.

00:22:02: Man guckt dann ja ihr müsst das Thread Modeling machen.

00:22:05: an welcher Stelle bei euch passt denn das rein?

00:22:06: Habt ihr überhaupt ein Softwareentwirkungsprozess der niedergeschrieben ist?

00:22:10: Dann muss man da eben anfangen sich Gedanken darüber zu machen bietet tatsächlich die Softwareentwickelung abläuft und wie man das Ganze in den Prozess Gießen kann und an welcher Stelle dann die wesentlichen Punkte des Cyber Resilience Acts umgesetzt werden müssen.

00:22:22: Dann gibt es natürlich auch noch Tooling Fragen, die Frage zum Beispiel naja Wie erzeug ich denn meine S-Bomb?

00:22:28: wie verfolge Ich den nach ob ich schwachstellen in Trittanbieter Komponenten drin habe dass sich auch diese Tritt Anbieterkomponentin rechtzeitig aktualisieren kann und solche Themen.

00:22:36: also Da gibt's viel was wir tun können und was wir auch tun.

00:22:39: Ja ihr beiden, vielen Dank auch dir nochmal Steffen.

00:22:42: Damit sind wir am Ende dieser Folge angelangt.

00:22:45: wenn sie sich weiter informieren möchten schauen Sie gerne rein auf www.cirosec.de und seien sie

00:22:51: gespannt auf die nächste Folge.