Sicherheit per Gesetz. kann das funktionieren? Der Cyber Resilience Act und seine Folgen

Michael: Hallo und herzlich willkommen zu einer neuen Ausgabe von Cybersecurity Basement, dem Podcast für echten Security-Content. Heute ist mal wieder zu Gast: der einzig wahre, unnachahmliche Andreas Papadaniil, Gründer und Geschäftsführer der suresecure GmbH. Andreas, einen wunderschönen guten Tag! Andreas: Danke für dieses warmherzige Intro. Michael: Wir wollen natürlich kurz den Bogen spannen. Worüber wollen wir heute sprechen? Ein wenig über Regulatorik. Regulatorik nimmt seit Jahren kontinuierlich zu. Das liegt daran, dass es eben so viele erfolgreiche Cyberangriffe gab und die tunlichst reduziert werden sollen. Und wir wollen heute im Schwerpunkt vor allem über den Cyber Resilience Act sprechen. Denn wir haben heute den 22. September, und im September wurden die Meldepflichten scharfgeschaltet. Deshalb wollen wir für euch einmal kurz einordnen: Was ist eigentlich der CRA? Wie grenzen wir das Ganze von den anderen Regulatoriken ab, die wir so kennen, NIS2 zum Beispiel? Und wir wollen darüber sprechen, was die Meldepflichten nun genau bedeuten und worauf zu achten ist. Klingt spannend, Andreas. Andreas: Ja, wie du sagst, ist das ein weiterer Baustein zur Verbesserung der Cybersecurity in Europa und auch darüber hinaus. Und ja, es gibt Dinge, die deckungsgleich mit NIS2 oder DORA etc. sind. Es gibt aber auch Dinge, die ein bisschen anders sind. Michael: Genau. Wir bewegen uns beim Thema CRA grundsätzlich in einem anderen Raum, denn auch Hardware kann natürlich Schwachstellen haben und angreifbar sein. Und hier geht es ja darum, dass Produkte hergestellt werden, die dann schon einen bestimmten Standard haben müssen. Stichwort Security by Design, dazu kommen wir gleich noch mal. Wo nun aber auch im Vorfeld geprüft werden soll, welche Schwachstellen es gibt. Und dafür gibt es dann eben solche Meldefristen. Vorweg: Abgrenzung zu NIS2. Andreas: Ja, ich denke, vor allem das: NIS2 richtet sich eher an die Unternehmen, also flächendeckend an eine Großzahl von Unternehmen, um die Sicherheit zu erhöhen. Der CRA kommt natürlich auch der Sicherheit der Unternehmen zugute. Aber adressiert werden erst mal Unternehmen, die etwas herstellen, sowohl Softwareprodukte als auch Hardwareprodukte als auch beides in Kombination. Denn wenn du dir das mal historisch anguckst, gab es vor dem CRA relativ wenig Regularien. Das heißt, du hast Geräte hergestellt, du bist zum Beispiel Maschinenbauer in Deutschland, hast Systeme hergestellt, und dann ging es erst mal darum, dass das Gerät funktioniert. Dann ging es vielleicht noch darum, irgendwelche Reports auswerten zu können, um zu sehen: Wie viel wird da gefertigt, in welcher Geschwindigkeit, in welcher Güte? Man kann es vielleicht ein bisschen konfigurieren, um die Beschaffenheit dessen, was gefertigt wird, zu bestimmen etc. Und bei all diesen Punkten spielte Sicherheit keine große Rolle. Das heißt, du hattest diese Geräte bei dir in der Produktion. Produktion nur als ein Beispiel, du kannst die Geräte auch in was weiß ich was haben. Und es gab kein großes Sicherheitskonzept. Zum Beispiel waren die Protokolle, die zur Übermittlung von Informationen genutzt wurden, unsicher, also etwa unverschlüsselt, sodass man sie im Netzwerk hätte auslesen können. Das ist das Thema Security by Design: Wie sicher ist diese Software, diese Hardware grundsätzlich gebaut? Was der CRA auch mitbringt, ist Schwachstellenmanagement. Wenn Geräte in der Vergangenheit in dein Netzwerk eingebunden worden sind, hat der Hersteller mit den Schultern gezuckt, ob dann Updates kommen oder nicht. Das hat einen nicht groß interessiert. Und dann das Thema Früherkennung und Reaktion. Wurden diese Geräte in deiner Infrastruktur angegriffen, hatte der Hersteller keine große Möglichkeit, das überhaupt festzustellen. Wenn man einen Strich drunter zieht, gab es da sehr viel Unklarheit. Der Endkunde, der die Geräte eingesetzt hat, kannte sie nicht und hatte sie auch nicht in der Verwaltung, weil das so geschlossene Geräte sind: Du hast keinen Zugriff, keine Administratorenrechte, du kommst nicht drauf. Vielleicht sagt der Hersteller sogar: Du darfst da gar nicht drauf, denn wenn du da was kaputt konfigurierst, bin ich nachher dafür verantwortlich und muss als Hersteller haften. Somit hat sich die Endkundenseite nicht darum kümmern können oder wollen, und die andere Seite hat auch nicht wirklich was getan. Um zum Punkt zu kommen: Der CRA klärt das jetzt komplett und sagt: Hier gibt es Dinge im Bereich der Cybersecurity, die in der Verantwortung des Herstellers liegen. Michael: Du hast jetzt viel über Produktion gesprochen. Das Ganze betrifft ja auch die Softwarehersteller, und es ist das erste Gesetz, das Hersteller quasi dazu zwingt. Du hast eben schon gesagt: Schwachstellen müssen gemeldet werden. Es gibt Pflichten, öffentlich über die, sage ich mal, eigenen kaputten Produkte zu sprechen. Fehler müssen eben gemeldet werden. Meldepflichten sind uns erst mal nicht neu, das ist bei uns ja eigentlich auch Kernbusiness. Sobald ein Vorfall vorliegt, gibt es auch hier Meldepflichten. Für Softwarehersteller und produzierende Unternehmen ist diese Pflicht nun mal neu. Und die Kette sieht so aus: Die erste Frühwarnung muss nach 24 Stunden erfolgen. Nach 72 Stunden braucht es eine Detailmeldung, einen Abschlussbericht spätestens 14 Tage nach dem Patch. Hältst du diese Fristen für realistisch? Und welche wird in der Praxis zuerst oder am stärksten strapaziert werden, was glaubst du? Andreas: Ja, es muss realistisch werden. Ich glaube, Stand heute ist das schon recht sportlich. Ich kriege natürlich nicht alles mit, aber wir waren in den letzten zwei Jahren an vielen Projekten in diesem Bereich beteiligt. Es gibt Hersteller, die das selbst machen und mit einbauen können. Es gibt aber auch Hersteller, die dabei auf Dienstleister angewiesen sind. Und was ich bei den Projekten gemerkt habe, wenn es Richtung Früherkennung ging: Die Ownership war nicht immer ganz klar. Gerade wenn wir in den Bereich Hardware, sagen wir Produktion, gehen: „Wir haben ein Gerät, das etwas herstellt. Könnt ihr dafür sorgen, dass wir Analyse- und Reaktionsfähigkeiten in das Gerät reinbekommen?“ Es gibt natürlich sehr große Hersteller, die so etwas umgesetzt haben. Aber ich glaube, die Mehrheit des deutschen Mittelstands hat noch nicht mal Projekte umgesetzt, die diese Erkennung überhaupt möglich machen. Und wenn du nicht erkennen kannst, wie willst du dann melden? Wenn ich mal weggehe vom Fertigen, gibt es noch ein anderes Beispiel für Security by Design: Router, die du benutzt, um ins Internet zu gehen. Ich will keine Namen nennen, aber es gibt etliche Modelle von etlichen Herstellern, bei denen es so war oder ist, dass die Router Standardpasswörter benutzen. Für das Admin-Konto ist dann zum Beispiel „Admin123“ als Default-Kennwort hinterlegt, und so werden sie ausgeliefert. Mit Security by Design soll das künftig nicht mehr so sein. Das heißt, bei Auslieferung sollen komplexere Passwörter verwendet werden oder vielleicht gar keine Default-Passwörter mehr. Und dann gab es einen Bot im Internet, der die ganzen Router abgefarmt hat: „Hey, ich versuche mal Admin123. Komme ich rein oder nicht?“ So wurden Botnetze gebildet, und Hunderttausende von Routern haben dann ein Ziel beschossen und es dazu gebracht, keine Anfragen mehr bearbeiten zu können. Also sogenannte DDoS-Attacken. Das soll sich dadurch verändern. Und ich bin mal gespannt, wie viele Router dann wirklich keine Default-Passwörter mehr haben, welche wirklich Security by Design sind und wie man Erkennungsmechanismen in diese Router einbaut. Denn das Worst-Case-Szenario wäre: Du bist Router-Hersteller, auf Basis deiner Router wird ein Botnetz gebildet, weil du ein Default-Passwort hattest. Das Ganze wird veröffentlicht, die Angreiferseite meldet das, und du hast davon überhaupt nichts mitbekommen. Das heißt, du brauchst jetzt Möglichkeiten. Am besten erst mal Security by Design, dann passiert das gar nicht. Oder du kriegst mit, dass deine Router gehackt werden. Oder du hast ein Darknet-Monitoring, sodass du es mitbekommst, wenn dein Default-Passwort irgendwo im Internet veröffentlicht wird. Du kannst dir ja Listen ziehen mit den Default-Passwörtern der Router, das machen die Angreifer auch so. Das sind Maßnahmen, die du im Vorfeld hättest treffen müssen, und ich bin gespannt, wie viele so etwas wirklich umgesetzt haben. Michael: Ja, das ist ein sehr wichtiger Punkt, denn diese 24 Stunden laufen ab Kenntniserlangung. Und es muss natürlich gewährleistet sein, dass ich selbst erkenne: Aha, hier habe ich eine Schwachstelle. Dann greift diese Meldepflicht. Was bedeutet das kulturell? Bis zum CRA war ja eher die Devise, dass man das nicht an die große Glocke hängt, einfach einen Patch bereitstellt, und dann ist es gut. Jetzt werden die Unternehmen dazu gezwungen, das zu melden. Andreas: Ja. Michael: Wenn ich mir dann später die Hersteller angucke – das wird ja alles in einer Datenbank gesammelt –, sieht der Hersteller, der nie etwas meldet, erst mal sauber aus. Er hat aber vielleicht nicht die beste Erkennung. Ist er dann besser oder schlechter als der, der gewissenhaft Früherkennungsmechanismen implementiert hat und so in der Lage ist, seine Schwachstellen fristgerecht zu melden? Andreas: Ja, das ist eine spannende Frage. Da will ich gar nicht Richter sein. Aber du musst auch bedenken: Es gibt nicht nur die ganz großen Softwarehersteller, die man so kennt, mit Tausenden oder Zehntausenden von Mitarbeitern. Mittlerweile gibt es gerade im Zeitalter von KI und Vibe Coding Software, die du ohne Entwickler an einem Wochenende schreiben kannst. Und der Markt wird mit Software überschwemmt. Wichtig ist, dass du ein Konzept hast, um selbst Meldungen entgegennehmen zu können. Es gibt ja auch White-Hat-Hacker, zum Beispiel Pentester, die am laufenden Band Software im Internet testen und schauen, ob es eine Schwachstelle gibt. Da solltest du schon einen gut dokumentierten und funktionierenden Prozess haben, um diese Meldungen entgegenzunehmen. Denn da haben wir auch schon alles erlebt. Ein Hacker findet eine Schwachstelle, und der Softwarehersteller reagiert einfach gar nicht, monatelang. Oder du kaufst das Ding tot: Du zahlst dem Angreifer Geld dafür, dass das Ganze nicht veröffentlicht wird und geheim bleibt. Du machst einen Patch, und keiner bekommt es mit. Das ist keine Empfehlung, so etwas zu tun, aber so etwas ist in freier Wildbahn passiert. Das wird durch den Cyber Resilience Act natürlich erschwert und sollte auch nicht passieren. Da müssen klare Prozesse her, denn irgendwer muss die Schwachstelle ja mitbekommen, und in der Regel bist du das nicht selbst, sondern irgendjemand da draußen. Du musst die Meldung entgegennehmen können, du musst damit umgehen können, und du musst sie dann melden können. Und wer wäre dann der Bessere? Gute Frage. Meiner Meinung nach der, der mehr Transparenz zeigt und genau diese Prozesse hat. Denn eine Softwareschwachstelle zu haben, ist keine Schande. Es gibt keine Software, die keine Schwachstelle hat. Wichtig ist der Umgang damit: Wenn du eine hast, dass du den Willen zeigst, das transparent zu machen, dass du schnell patchst und auch selbst alles dafür tust. Wenn ich sage, jede Software hat Schwachstellen, ist das keine Absolution. Das heißt nicht: Oh, da muss ich ja nichts machen, passiert ja eh. Du solltest vorher Tests gegen eine Software durchführen, bevor sie veröffentlicht wird, in verschiedener Form, auch mal ein Code-Review machen. Alles, was in deiner Macht steht. Wenn es dann trotzdem zu einer Schwachstelle kommt, hast du alles getan, was in deiner Macht ist. Dann sollst du sauber damit umgehen. Das ist der Punkt. Totschweigen hilft nicht, die Schwachstelle ist ja trotzdem da. Michael: Ja. Ab dem 11. September 2027 darf dann nur noch in Verkehr gebracht werden, was CRA-konform ist. Das heißt, die Unternehmen haben jetzt gut ein Jahr Toleranzzeit, um alles so umzustellen, dass es passt. Hältst du das für realistisch? Wenn ich den Vergleich zu NIS2 ziehe, wo wir, glaube ich, fast drei Jahre Zeit hatten, um Dinge nachzuziehen, erscheint mir das Zeitfenster recht ambitioniert und sportlich. Andreas: Ja, vor allem, wenn man überlegt, was da draußen an Software und Hardware im Umlauf ist und wie ein Produktlebenszyklus aussieht. Der erstreckt sich in der Regel über mehrere Jahre. Das heißt, was vielleicht sogar noch nächstes Jahr auf den Markt geworfen wird, entstammt vielleicht einer Idee oder einem Entwicklungsbeginn von vor vier Jahren, als das Thema noch keine so große Rolle spielte. Und die Aufwände, das Ganze zu implementieren, sind eben nicht gering. Deswegen glaube ich nicht, dass das so stattfindet. Ich glaube, es wird auch eine Frage sein, wie kontrolliert wird und wie viel Aufwand hinter die Kontrolle gesteckt wird. Das sehen wir ja auch bei der Datenschutzgrundverordnung, einem Thema, das etwas früher kam. Dort sind die Landesdatenschutzbehörden verantwortlich. Dort werden die Meldungen gemacht, und dort sollen Prüfungen durchgeführt werden, ob Datenschutzthemen eingehalten werden. Die haben Prüflisten, die noch mal zehn Jahre reichen, wenn sie heute anfangen, sie abzuarbeiten. Die Kapazitäten, um das zu prüfen, sind gar nicht da. Teilweise wird Meldungen gar nicht nachgegangen, weil die Kapazitäten fehlen. Wenn ich mich bei der Landesdatenschutzbehörde melde und sage: „Hey, da stimmt irgendwas nicht, da müsst ihr mal nachfragen“, dann dauert es ewig, bis die überhaupt an das Unternehmen herantreten. Und das wird beim Cyber Resilience Act auch die Frage sein: Wie sieht das Prüfkonzept aus, wie viele Kapazitäten stecken dahinter? Vielleicht ist man sich im Hinterkopf auch schon bewusst: Ja, das ist ein Jahr, aber realistisch ist es kaum einzuhalten. Aus meiner Sicht auf jeden Fall. Michael: Sportlich auf jeden Fall. Denn dazu gehört nicht nur das Schwachstellenmanagement, das wir schon angesprochen haben und das über den gesamten Supportzeitraum durchgeführt werden muss. Auch die Updatefähigkeit muss gewährleistet sein. Hinzu kommt das Thema SBOM, also Software Bill of Materials, was so viel bedeutet wie das Inhaltsverzeichnis für dieses Produkt. Die Hersteller sind verpflichtet aufzulisten: Welche Bibliotheken habe ich verbaut, welche Module? Damit derjenige, der das Produkt einsetzt, bei sich sehen kann: Ist dieser Baustein bei mir drin, und muss ich jetzt darauf reagieren? Glaubst du, dass das vor allem für bestehende Produkte so einfach nachzuarbeiten ist? Wenn ich mir IT-Projekte anschaue, in die ich involviert war: Dokumentation, welche Bibliotheken benutzt werden, ist da durchaus ein Thema. Das wird, glaube ich, keine so kleine Herausforderung werden. Andreas: Ja, wie du sagst, da gibt es eine ganze Menge, und dann gibt es auch noch Unterschiede. Nicht nur Version 17 und dann 18, sondern es geht teilweise bis ins Kleinste runter, dann hast du 4.7 und weiß ich nicht was. Das ist schon sehr granular, was diesen Baum angeht. Und ich glaube, das kannst du nur durch Automatismen abbilden. Wenn du zum Beispiel die Software für ein Release paketierst und ausrollen möchtest, musst du etwas einbauen, das sagt: „Zieh bitte einmal alle Versionsstände, Bibliotheken etc., die da drin sind, und schreib sie mir auf.“ Das geht heute Gott sei Dank durch Automatismen relativ gut, aber es muss eben auch abgebildet werden. In deine bestehenden Softwareproduktionsprozesse musst du das einbauen. Wenn du das an deine Mitarbeiter weitergibst und sagst: „Mach mal bitte eine Excel-Tabelle auf und schreib daneben, welche Bibliotheken drin sind“, dann kann das eigentlich nicht funktionieren. Es gibt viel Veränderung zwischen Versionen, gerade wenn du in agilen Projekten steckst, gerade heute mit unseren Innovationszyklen, in denen teilweise sehr schnell Änderungen und Updates für die Produkte kommen. Das kannst du eigentlich nur durch Automatisierung abbilden. Aber diese Automatisierung muss erst mal implementiert, getestet und eingebaut werden. Ich bin gespannt, wie das in der Masse abgebildet wird. Michael: Und wenn du jetzt in die Praxis schaust, auf Ausschreibungen und Kundenanfragen: Ist dir das Thema schon häufiger begegnet, obwohl die Vollanwendung erst 2027 kommt? Oder hat es aktuell einfach noch gar nicht so viel Präsenz? Andreas: Als solches noch nicht. Wobei man sagen muss: Wir sind kein Softwarehersteller, sondern wir nutzen Software, nehmen einen Service dazu und verkaufen dann einen Managed Service. Das ist unser Hauptgeschäft. Aber was man durch den CRA schon merkt, ist das Thema Security by Design. In den RFPs sehen wir, dass detaillierter gefragt wird, wie die Software arbeitet, und dass man zum Beispiel bestätigen muss, dass keine unsicheren Protokolle genutzt werden. Das geht schon in diese Richtung. Und das ist, glaube ich, erst mal der größte Mehrwert in der ersten Phase des Cyber Resilience Act: Awareness zu schaffen und zu zeigen, worauf man achten sollte. Das kommt so langsam bei den Leuten an, auch wenn man vielleicht noch nicht so perfekt ist, das alles schon genau so abbilden zu können. Da sind, glaube ich, alle realistisch genug, dass sich das nicht von heute auf morgen verändert. Aber es muss ja irgendwo ein Datum geben, ab dem es gilt. Ich merke schon, dass es das Bewusstsein der Leute schärft. Es ist gerade ein bisschen viel, muss man sagen. Die Fachabteilungen beschäftigen sich mit NIS2, mit DORA, mit dem Cyber Resilience Act. Gerade internationale Unternehmen, die nicht nur in Europa agieren, weil genau die gleichen Dinge gerade auch in den USA, in Asien, in Afrika und im Middle East kommen. Wenn du auf allen Kontinenten aktiv bist und produzierst, multipliziert sich der Aufwand, den du betreiben musst. Aber im Ganzen ist ziemlich klar, worauf das hinausläuft. Was wir gerade machen, ist Nacharbeiten, also Dinge, die in der Vergangenheit nicht getan wurden. Wir haben gesagt, Sicherheit ist schon wichtig, aber es gab diese Menge an Cyberangriffen nicht, wie wir sie heute haben. Man hat eher gesagt: Hauptsache, es funktioniert, Sicherheit spielt keine große Rolle. Jetzt gibt es so viele Angriffe, und der Schaden ist so immens, dass wir dafür sorgen müssen, sicher zu sein. Der Effekt wird sich in fünf bis zehn Jahren zeigen, wenn man ein Selbstverständnis und einen Reifegrad hat, der ganz woanders liegt als heute. Michael: Glaubst du, dass „Ich bin CRA-konform“ oder „Ich bin NIS2-konform“ künftig auch Qualitätssiegel sein werden, wie es jetzt eine ISO 27001 ist? Die ist im Gegensatz dazu natürlich nicht verpflichtend, aber wir erleben in Ausschreibungen schon, dass die Anforderung da ist: ISO 27001 ist uns wichtig, ansonsten kannst du an dieser Ausschreibung gar nicht teilnehmen. Damit wird es quasi ein Marktzugangsthema. Wenn du das nicht nachweisen kannst, hast du perspektivisch vielleicht keine Chance mehr, bestimmte Deals an Land zu ziehen. Andreas: Ja, das kann ich mir vorstellen. Es wird sicherlich immer Ausnahmen geben, weil, wo Geld gemacht wird, auch mal ein Auge zugedrückt wird. Dann sagt man: Okay, wir brauchen diese Maschinen jetzt. Die entsprechen vielleicht nicht dem CRA, also nicht Security by Design, aber man setzt sie trotzdem ein und sichert sie im Netzwerk anders ab, sodass sie nicht erreichbar sind oder wie auch immer. Es wird Ausnahmen geben. Aber ich denke, es wird darauf hinauslaufen, dass gerade in Europa gewisse Dinge nicht mehr geduldet oder akzeptiert werden. Auch wenn manche sagen, wir sind in Europa teilweise schon überreguliert, das ist alles ein bisschen viel. Andere Länder und Kontinente interessiert das eher weniger, muss man sagen. Ich bin gespannt, wie sich das in Zukunft darstellt, gerade bei Produkten aus Europa, die diese ganzen Cyberthemen beherrschen und abbilden können. Ob dann eher die anderen Länder und Kontinente dorthin gucken und sagen: „Hey, das müssen wir eigentlich auch so machen, wir haben viel zu viele Cyberangriffe, das geht so alles nicht mehr.“ Oder ob wir irgendwann an den Punkt kommen, an dem wir so überreguliert sind, dass wir Innovationen ausbremsen und die anderen Länder das Rennen machen, weil sie sich nicht daran halten müssen. Michael: Dann schauen wir mal auf die Realität in Deutschland, wenn wir NIS2 als regulatorische Maßnahme noch mal heranziehen. Bis Ende Juli sollten sich eigentlich alle Unternehmen, die von NIS2 betroffen sind, registriert haben. In den Medien kursiert immer die Zahl 29.500. Stand Ende Juli haben sich 11.500 Unternehmen registriert, also knapp 4/10 haben diese fristgerechte Registrierung geschafft. Was glaubst du, ist der häufigste Grund: Überforderung oder schlichtweg immer noch Unwissenheit? Das ganze Thema rund um NIS2 oder Regulatorik grundsätzlich bekommt die Cybersecurity-Bubble natürlich sehr, sehr gut mit. Aber wenn ich mir vorstelle, ich bin Produzent von, weiß ich nicht, Rohlingen für Bäckereien, dann liegt mein Fokus darauf: Wie beschaffe ich meine Rohstoffe? Funktionieren meine Maschinen? Und eben nicht so sehr darauf, wie sicher eigentlich meine digitale Infrastruktur ist. Andreas: Ja, ich denke, es hat auf jeden Fall damit zu tun, dass viele Geschäftsführer noch gar nichts davon mitbekommen haben. Oder auch Fachabteilungen, selbst IT-Leiter etc. Da wird es sicherlich noch viele geben, die das gar nicht so verstanden haben. Die zweite Sache ist die schwache Definition, würde ich behaupten, weil gar nicht klar ist, wer betroffen ist. Es gibt eine Umschreibung, und ich verstehe auch, warum man das so gemacht hat. Wenn man das so weich definiert, könnte man meinen, es sind vielleicht mehr, als es eigentlich sind. Und man nimmt sich ein bisschen die Verantwortung, weil keiner dafür verantwortlich ist, wer betroffen ist oder nicht. Die Verantwortung für die Betroffenheit wurde an die Unternehmen verlagert: Ihr müsst jetzt mal prüfen, ob ihr betroffen seid oder nicht, weil wir das nicht so ganz vorgeben können. Ich verstehe auch, dass da keiner die Verantwortung übernehmen will. Nur ist nicht ganz klar angekommen oder kommuniziert worden, dass das der First Step ist: erst mal die Betroffenheit prüfen. Weiß ja keiner. Also machen es die Leute teilweise nicht. Verstehe ich auch, es ist nicht deren Kosmos. Wie du sagst: Wenn ich Rohlinge für Bäckereien mache, ist das meine Welt, in der ich mich bewege. Als Geschäftsführer habe ich nicht unbedingt auf dem Schirm, wie viele Gesetze im Jahr rauskommen. Arbeitszeitnachweisgesetz, dies Gesetz, das Gesetz. Jedes Jahr im Januar kommt unser Anwalt und sagt: Hier gibt es 14 neue Gesetze, die du umsetzen musst. Wir haben ja einen Fachanwalt bei uns im Unternehmen, weil wir Service Verträge schreiben und Security-Provider sind. Aber die allermeisten Unternehmen haben nicht mal eigene Anwälte. Selbst Unternehmen mit 1.000, 2.000 Mitarbeitern arbeiten mit irgendeiner Kanzlei zusammen, und manchmal schreibt die einen Newsletter, was es Neues gibt, manchmal aber auch nicht. Deswegen glaube ich, viele wissen das noch gar nicht. Hätte man gewollt, dass sich auch alle 29.000 registrieren – wobei ich mich frage, wie der Filter gesetzt wird und woher sie das so genau wissen –, dann hätte man die Unternehmen klar definieren müssen. Zum Beispiel: Hier ist ein Inventar aller Unternehmen, die betroffen sind, als Datenbank oder Webseite. Das sind die 29.000, ihr seid alle namentlich benannt. Dann kannst du ihnen allen einen Brief schicken. Das machen wir in Deutschland bei den Ämtern ja gerne. Dann wird ein schöner Brief verschickt: „Hallo, du bist betroffen. Du musst das und das und das machen.“ Dann können wir uns nicht mehr beschweren, dann haben wir die Gesamtmenge und klare Anweisungen. So, wie es jetzt ist, wird das quasi auf das Unternehmen verlagert, und die Erwartungshaltung ist, dass ich als Unternehmer prüfe, ob ich überhaupt betroffen bin. Und das ist schwer. Unsere Aussage ist ja auch oft: vermutlich schon oder vermutlich nicht. Gerade bei den Sektoren oder Branchen, in denen du bist, kannst du nicht klar sagen: Du bist hier klar betroffen. Michael: Der Ansatz war ja gut. Das BSI hat eine Seite veröffentlicht, auf der du deine Angaben machen kannst, und dann sollte dir das System sagen: Du bist betroffen oder du bist nicht betroffen. Das Verrückte daran ist, dass als Ergebnis teilweise auch steht: „Sie sind wahrscheinlich betroffen.“ Und dann denkst du natürlich: Wie wahrscheinlich ist es jetzt? Bin ich betroffen oder nicht? Eigentlich wäre es gut gewesen, wenn man zumindest eine klare Aussage bekommen hätte, was nun Sache ist. Andreas: Man muss ja auch sagen: Wenn ich konform sein möchte, stehen dahinter je nach Unternehmensgröße sechs- bis siebenstellige Investitionen. Wenn mir jemand sagt, du bist sehr wahrscheinlich betroffen, würde ich mir als Geschäftsführer vielleicht wünschen, eher nicht betroffen zu sein. Gerade wenn wir uns die aktuelle Wirtschaftslage in Deutschland angucken: Viele Unternehmen struggeln, setzen sich eher mit Massenentlassungen auseinander, schließen Werke oder bauen keine neuen. Die sagen sich dann: Diese sechs- bis siebenstelligen Investitionen in IT-Sicherheit spare ich mir gerade lieber. Michael: Ja, das verstehe ich. Auf der anderen Seite hast du natürlich das Problem, dass schon erste Sanktionen fällig sein können, wenn du dich nicht registrierst, obwohl du betroffen bist. Auch blöd, wenn dann plötzlich eine Rechnung kommt: „Ja, sorry, 200.000 €.“ Willst du auch nicht bezahlen. Dazu wird es sicherlich bald die ersten Meldungen geben. Denn wenn man feststellt, dass gar nichts sanktioniert wird und es doch irgendwie egal ist, dann macht es am Ende auch nicht so viel Sinn. Andreas: Ich glaube, das wird noch mal einen anderen Druck erzeugen. Das ist genauso wie mit den Ransomware-Angriffen. Es hat auch erst mal gedauert, bis das überall durchgedrungen ist. Bei deinem Nachbarn, deinem Inhaberkollegen oder beim CEO einer anderen Firma aus der Branche hat es dann irgendwo geknallt, und irgendwann hat man gesehen: Oh, zweistelliger Millionenschaden. Die konnten zwei Wochen nicht produzieren, Umsatzeinbußen und, und, und. Das darf uns nicht passieren, hier müssen wir investieren. Das hat man ja schon jahrelang gepredigt: Bereite dich vor, damit dir das nicht passiert. Aber so richtig geglaubt hat man es erst, als man einen Betroffenen kennengelernt hat. Und dann wurden plötzlich Budgets bewilligt. Das kann hier das gleiche Thema sein. Irgendwann erzählt jemand: „Ich habe Sanktionen bekommen, weil ich mich nicht gemeldet oder die Maßnahmen nicht erfüllt habe.“ Und dann sagen die anderen: „Das will ich aber nicht, dass mir das passiert.“ Aber eigentlich wissen wir, worauf es hinausläuft. Michael: Ja. Wir reden gerade die ganze Zeit nur über die Unternehmen, die für sich selbst prüfen: Bin ich von NIS2 betroffen? Manchmal sitzt du aber auch einfach in einer Lieferkette und bist dadurch quasi auch betroffen. Auch da gilt es zu schauen: Was trifft gerade auf mich zu? Wir sind da ein gutes Beispiel. Deshalb: Wer es noch nicht getan hat, sollte diese Frage mittlerweile auf jeden Fall beantworten können: Bin ich betroffen oder nicht? Ich denke, wir bewegen uns gerade noch in einer Toleranzphase, in der man sich vielleicht auch ohne Bußgelder nachmelden kann. Und wenn ihr Fragen habt: Andreas, du hast gesagt, wir haben dafür einen Fachanwalt im Unternehmen, der sicherlich gerne eine klare Aussage dazu trifft, ob oder wie man betroffen ist. Wir waren gerade dabei: Wie hoch ist das Risiko, dass ich wegen eines Verstoßes gegen NIS2 oder den CRA belangt werde? Wenn wir mal an die Geschäftsführung denken – du bist selbst auch Geschäftsführer –, die sieht ja eher die betriebswirtschaftlichen Aspekte. Wie eben schon gesagt: Die Investitionen können relativ hoch werden. Wenn ich komplett konform sein will mit NIS2, mit dem CRA, gegebenenfalls auch noch mit DORA und so weiter, muss ich immense Summen ausgeben. Ist es dann nicht die rationalere, cleverere Entscheidung zu sagen: Okay, ich sitze das erst mal ein bisschen aus? Andreas: Das wird es bestimmt geben. Für uns als Security Company ist es ein Must-have und ein Wettbewerbsvorteil. Wenn wir nicht mit all diesen Dingen konform sind, können wir den Laden zumachen. Und wie du sagst, wir gewinnen dann auch keine Aufträge im Markt, weil die Erwartungshaltung an uns ist, dass wir das erfüllen, was wir predigen. Aber alle anderen, die nicht in der Branche sind und vielleicht auch nicht von der Lieferkette abgefragt werden, haben zehn Gesetze auf dem Tisch liegen, nicht nur zur Cybersecurity. Die kennen das auch schon und sagen: Ich warte erst mal und gucke, was passiert. Es gibt ja auch Unternehmen, die sich bei der Datenschutzgrundverordnung eine Maximalstrafe ausgerechnet haben: „Wenn ich irgendwann mal verurteilt werde, ist die Strafe 500.000 €. Aber meine Investitionen in Security liegen bei rund 4 Millionen. Also lasse ich es darauf ankommen: Risiko akzeptiert. Eine Strafe von 500.000 € könnte irgendwann auf mich zukommen, das ist aber immer noch günstiger, als 4 Millionen zu investieren.“ Das heißt nicht, dass diese Unternehmen gar keine Cybersecurity machen, aber eben in einem abgespeckten Umfang. Auch in der Datenschutzgrundverordnung ist ja vom Stand der Technik die Rede, was sehr schwammig ist. Da tut man das dann vielleicht nicht in diesem Maße und hält es ein bisschen kleiner. Für uns ist es klar ein Muss. Wir und viele unserer Zuhörer stecken komplett in der Thematik Cybersecurity drin, und wir predigen ja auch immer, wie wichtig das ist, sonst gibt es Angriffe und dann wird viel Geld bezahlt und so weiter. Aber ein Geschäftsführer hat eine ganze Palette an Themen auf dem Tisch liegen, alle sind total bedrohlich, allen muss man nachkommen, und überall muss man viel Geld investieren. Würde man das alles tun, könnte man wahrscheinlich den Laden zumachen, weil man nicht mehr profitabel ist. Also musst du bewusst auch Risiken akzeptieren. Das ist jetzt keine Aufforderung an liebe Geschäftsführer, nicht in Cybersecurity zu investieren. Ihr wisst, meine Meinung ist klar: Regularien hin oder her, wir sollten das tun. Ich habe in über 50 Sicherheitsvorfällen live miterlebt, welchen Schaden das anrichtet, finanziell, aber auch mental, und wie man als Geschäftsführer dadurch belastet wird. Die meisten Geschäftsführer haben das noch nicht erlebt. Wer einmal so einen Angriff mitgemacht hat, würde wahrscheinlich auch sagen: „Das will ich nie wieder erleben, sorgt bitte dafür, dass die Cybersicherheit im Topzustand ist.“ Aber die Mehrheit in Deutschland hat es noch nicht erlebt. Gott sei Dank. Michael: Diese ganzen regulatorischen Vorgaben sind ja auch immer recht schwammig formuliert, das haben wir bei der NIS2-Richtlinie auf jeden Fall festgestellt. Du kannst immer viel hineininterpretieren. Welches System du am Ende zur Früherkennung nutzt, ist nicht ganz konkret vorgeschrieben. Und wir wissen auch, dass der Markt recht dynamisch ist und sich immer wieder verändert und neu entwickelt. Es gibt ja auch Pläne, die DSGVO perspektivisch vielleicht durch eine übergeordnete EU-Richtlinie zu ersetzen. In diesem ganzen Wust kann ich sehr gut verstehen, dass man nicht dazu tendiert, diese Dinge immer direkt zu 100 Prozent umzusetzen. Weil du nicht weißt: Was denken die sich als Nächstes aus? Wann ist das überhaupt wieder überholt? Und vieles in der NIS2-Richtlinie sind nun mal Hygiene-Basics, die wir brauchen und einhalten müssen. Du hast es eben angesprochen: Wir stolpern in Sicherheitsvorfällen häufig darüber, dass einfach Basics nicht implementiert sind. Absolute Basics, die man auch implementieren sollte, wenn es gar keine Regulatorik gäbe. Wer die Tür auflässt, bei dem kommt halt irgendwann jemand rein. Das ist zwar blöd, aber relativ nachvollziehbar und verständlich. Wenn du jetzt eine dieser Regulierungen ersatzlos streichen dürftest: Welche wäre das, und warum? Andreas: Damit mache ich mir jetzt keine Freunde. Da bringst du mich aber in eine pikante Situation. Meinst du eine gesamte Gesetzgebung oder eine einzelne geforderte Maßnahme? Michael: Nein, eine gesamte Regulierung. Sprich NIS2, CRA, DORA ... DSGVO ganz. Andreas: Ja, die kam mir tatsächlich als Erstes in den Sinn. Wobei ich schon sagen muss: Der Pluspunkt der Datenschutzgrundverordnung ist, dass sie eine extreme Awareness für das Thema Datenschutz gebracht hat. Auf einmal denken Menschen darüber nach: Mache ich hier ein Foto von diesen Personen? Muss ich die vorher fragen oder nicht? Wobei das eher Mittel- und Nordeuropa, also auch Deutschland betrifft. Es gibt etliche Länder, die schert das gar nicht. Aber in Deutschland kriegst du das schon mal mit: Da macht einer ein Foto, du bist zufällig drauf, gehst zu der Person und sagst: „Du hast ein Foto von mir gemacht, das darfst du aber nicht.“ Woanders spielt das gar keine Rolle. Wie dem auch sei: Ich glaube, am ehesten die Datenschutzgrundverordnung, weil sie sehr weich ist und extrem viel Aufwand erzeugt. Davon kannst du selbst vielleicht ein Lied singen, was Kindergartenveranstaltungen und so weiter angeht. Extrem viel Aufwand, extrem wenig Wirkung, weil die Großkonzerne am Ende trotzdem mit den Daten machen, was sie wollen. Und da bringen auch die Kontrollen nichts und so weiter. Das ist alles ein bisschen hart. Wie gesagt, die Leute werden mich für das hassen, was ich sage. Aber praktischer Nutzen: naja. Awareness: mega geil. Versteh mich nicht falsch, ich finde die Datenschutzgrundverordnung gut und wichtig. Sie hat dafür gesorgt, dass das Thema viel präsenter ist und man sich Gedanken darüber macht. Aber sie ist eben auch zu weich. Auch das Thema Stand der Technik war nicht klar genug. Da hätte man schon viel früher die Chance gehabt, Cybersicherheit klar mit konkreten Maßnahmen zu definieren, so wie es jetzt zum Beispiel in NIS2 geregelt ist. Hätte man damals schon angefangen, wären die Unternehmen in Sachen Cybersicherheit jetzt vielleicht schon weiter. Das wurde ein bisschen verpasst. Das wäre so mein Punkt. Dann haben wir aber nichts mehr, was den Datenschutz regelt. Das wäre sehr schade. Aber die anderen Regulierungen sind ein bisschen schärfer. Man hat gelernt, was bei der Datenschutzgrundverordnung versäumt wurde, und es besser umgesetzt, muss ich ehrlich sagen. Also sorry an die Leute, die die Datenschutzgrundverordnung mitgeschrieben haben: Ihr seid Pioniere, aber man kann immer noch was besser machen. Michael: Ja, ich glaube auch, dass es ein wichtiges Instrument ist. Es gibt natürlich Länder, die auch ganz gut ohne leben, das stimmt. Aber um welchen Preis? Gerade wenn du dir anguckst, was in den USA alles möglich ist, denkt man sich schon: Ich weiß nicht, ob ich das hier so haben möchte. Spannender Ansatz, aber am Ende haben wir eh keine Macht, eine davon zu streichen. Wir müssen mit allem leben und lernen, damit umzugehen. Und damit kommen wir langsam zum Ende der Folge. Vielen Dank für die Einordnung und dafür, dass du nicht einfach Paragrafen zitiert hast. Ich denke, das war ein sehr ehrlicher Blick auf die Dinge, wie wir sie aktuell vorfinden. Und wenn ihr noch weitere Fragen zu CRA und NIS2 habt, meldet euch gerne bei uns, schreibt uns, dann nehmen wir die Themen vielleicht in der nächsten Folge noch mal mit rein. Das war das Update zu CRA und NIS2. Andreas, ich danke dir, dass du da warst. Andreas: Gerne. Bis zum nächsten Mal. Michael: Bleibt sicher und vor allem gesund, liebe Leute!