Frisch zurück aus Singapur habe ich mich beim Schreiben dieses Briefings kopfüber in deutsche und europäische Themen begeben. Und direkt das erste Thema erwies sich als umfangreicher als gedacht - deswegen gibt es wieder einmal ein längeres Erklärstück zum Cyber Resilience Act, denn da geht's momentan in großen Schritten voran (die auf den ersten Blick unscheinbar wirken).
Außerdem schauen wir auf die deutsche Hackback-Frage, polnischen Bahnfunk, singapurer KI-Pragmatismus - und zum Schluss noch schnell auf YouTube, denn die ersten Videos von SECURITY UNTER KONTROLLE sind da.

In dieser E-Mail gibt es Neuigkeiten und Lesestoff zu folgenden Themen:

1. CRA Standardization Request: So wird entschieden, welche Security-Anforderungen Produkte auf dem EU-Markt bald erfüllen müssen
2. Ist "aktive Cyberabwehr" dasselbe wie ein Hackback?
3. Bahnfunk ist "insecure by design"
4. KI in der Cybersecurity: Von Ängsten und Chancen
5. Security unter Kontrolle: YouTube-Kanal, Termin 2024 und Early-Bird-Tickets

1. CRA Standardization Request: So wird entschieden, welche Security-Anforderungen Produkte auf dem EU-Markt bald erfüllen müssen

 Es ist verständlicherweise die häufigste Frage, die ich zum Cyber Resilience Acts (CRA) bekomme: "Weiß man schon, welche Cybersecurity-Normen die Produkte werden erfüllen müssen?".
Nein, weiß man noch nicht, aber wir kommen der Antwort näher. Der Entstehungsprozess des CRA ist nämlich diesen Monat einen von der Öffentlichkeit kaum wahrgenommenen, aber dennoch wichtigen Schritt vorangegangen. Halten Sie sich fest:

Da der CRA das NLF unterstützt, haben CEN/CENELEC einen SReq erhalten, um hENs zu entwickeln.

Äh, was?
Klamüsern wir das mal auseinandern. Holen Sie sich lieber vorher einen Kaffee, das braucht jetzt ein bisschen.

CRA = Security ins CE-Kennzeichen
Sie erinnern sich vielleicht: Der CRA bedeutet nicht mehr und nicht weniger, als dass Security Teil des europäischen CE-Kennzeichens wird. Das ist keine kleine Sache, denn das CE-Kennzeichen ist nicht nur eine große Erfolgsgeschichte (wenn man einmal im Alltag anfängt, darauf zu achten, sieht man es überall), sondern auch ein komplexes Konstrukt. Darin verborgen stecken eine Menge EU-Werte.

"New Approach" und "New Legislative Framework" (NLF): Keine Überregulierung, kein Regulierungswirrwarr
Kleiner Exkurs in die Geschichte der "Conformité Européenne", dann dafür steht "CE": Die Geburtsstunde des Konzepts ist der 7. Mai 1985 bzw. der 21. Dezember 1989. Damals sind der "New Approach" für die Produktregulierung und das Gesamtkonzept für die EU-Konformitätsbewertung durch den europäischen Rat beschlossen worden.

Dem Wort "New Approach" kann man ansehen, dass es Schmerzpunkte gegeben haben muss, die eine Neuerung nötig machten. Und die gab es: Jeder EU-Mitgliedsstaat hatte andere Regeln für die Regulierung von Produkten, und dieser Regulierungswirrwarr machte es für Produkthersteller schwer, ihre Produkte in andere EU-Staaten zu exportieren.
Das CE-Konzept fußt deswegen seit seiner Geburt auf wichtigen Grundsätzen:

• Keine Überregulierung: Die Regulierung von Produkten durch die EU und ihre Mitgliedsstaaten soll auf ein unentbehrliches Mindestmaß beschränkt werden, die sogenannten "wesentlichen Anforderungen". Damit soll der Handlungsspielraum der Industrie und der technische Fortschritt gefördert werden.
• Risikobasierter Ansatz: Es ist klar geregelt, welche Produkte überhaupt ein CE-Kennzeichen brauchen - und das hängt von ihrem Risikopotential ab. Das bedeutet auch, dass alle anderen Produkte kein CE-Kennzeichen tragen dürfen.
• Einheitliche, verlässliche Anforderungen: EU-Richtlinien (und auch ihre Umsetzung in nationale Gesetze) sind nicht der richtige Ort, um detaillierte technische Anforderungen festzulegen: Erstens ändern sich solche Anforderungen tendenziell schneller als ein Gesetz. Zweitens gibt es für technische Anforderungen aus gutem Grund konsensbasierte Normungsverfahren, um die Expertise einer ganzen Industrie abzubilden. Daher bedient sich das CE-Konzept dieser Expertise, indem es auf EU-weit geltende Normen verweist - die heißen dann "harmonisierte europäische Normen (hEN)". Erfüllt ein Produkt diese Normen, ist die Übereinstimmung mit der CE-Richtlinie für dieses Produkt anzunehmen "Konformitätsvermutung". Das schafft Klarheit und Verlässlichkeit für Produkthersteller.
• Freie Wahl der technischen Lösung: Es bleibt dem Produkthersteller überlassen, ob er die harmonisierten Normen anwendet oder sich für eine andere technische Spezifikation entscheidet. Ebenso darf nicht vorgeschrieben werden, welche technische Lösung für die Umsetzung der Anforderungen gewählt wird.

2008 kam dann noch das New Legislative Framework (NLF) hinzu. Es erweitert und vereinheitlicht das bestehende Konzept und enthält auch wichtige Begriffsdefinitionen - einige davon werden wir noch brauchen. Eine wichtige inhaltliche Ergänzung war die Ausweitung der Herstellerpflichten über das "Inverkehrbringen" hinaus: Meldepflichten bei Gefahren und Rückrufmanagement bei Verdacht auf "Konformitätsmängel". Und eine Risikoanalyse wurde auch zur Pflicht.
Sie ahnen es schon: Deswegen ist im CRA das Schwachstellenmanagement für eine bestimmte Zeit nach Verkauf des Produkts so prominent verankert. Denn diese Grundsätze muss der CRA natürlich auch auf die Cybersecurity übertragen. Cybersecurity ins CE-Kennzeichen zu integrieren bedeutet eben, dass man nicht mit einem weißen Blatt beginnt, sondern buchstäblich auf der Basis von dutzenden Seiten eng bedruckten Papiers - das Produkt jahrelangen Verhandelns, Interessensausgleichs und Lernens aus der Praxis. Beim Thema Produktregulierung ist die EU nun wirklich ein "alter Hase".

Deswegen ist es wichtig zu verstehen, welche Werte hinter diesem Papier stehen - eben nicht der der EU grundsätzlich immer vorgeworfene "Regulierungswahn". Besser fasst es vielleicht das hier zusammen:
The CRA is standing On the shoulders of giants - mit allen Vor- und Nachteilen.

Hersteller, Inverkehrbringer: Wer ist für die CE-Konformität der Produkte verantwortlich?
Einen Begriff müssen wir noch schnell einführen, bevor es ans Eingemachte geht: Das "Inverkehrbringen".
Der Begriff ist in der Beschluss 768/2008/EC (Teil des New Legislative Frameworks) definiert als "die erstmalige Bereitstellung eines Produkts auf dem Gemeinschaftsmarkt".
(Die englische Übersetzung ist übrigens "placing on the market": "the first making available of a product on the Community market").

Das Inverkehrbringen definiert also einen Zeitpunkt, und zu diesem Zeitpunkt muss das CE-Kennzeichen angebracht sein. Der Hersteller ist derjenige, der das Konformitätsbewertungsverfahren durchführen und das CE-Kennzeichen anbringen muss. Aber es kann natürlich sein, dass jemand anders das Produkt "in Verkehr bringt": Ein Händler oder ein Importeur ("Einführer"). Importeuere müssen "gewährleisten", Händler "überprüfen", dass der Hersteller das Konformitätsbewertungsverfahren durchgeführt und das CE-Kennzeichen angebracht hat.

Es gibt eine Bedingung, die dazu führt, dass der Händler oder Importeur die Pflichten des Herstellers übernehmen muss, also selbst die Konformitätsbewertung durchführen muss - nachzulesen im Beschluss 768/2008/EC, Artikel R6: Nämlich wenn er "ein Produkt unter seinem eigenen Namen oder seiner eigenen Marke in Verkehr bringt oder ein bereits auf dem Markt befindliches Produkt so ändert, dass die Konformität mit den geltenden Anforderungen beeinträchtigt werden kann".

Und hier schließt sich der Kreis zur Diskussion über die Security-Verantwortung für Open-Source-Software aus dem letzten Monat: Die Open-Source-Community setzt sich dafür ein, dass für Open-Source-Software genau diese Bedingung gelten soll. Das ist gemeint, wenn davon die Rede ist, dass der "Inverkehrbringer" der Software für ihr CE-Kennzeichen verantwortlich sein soll.

Übrigens: Den im Deutschen im Zusammenhang mit dem CE-Kennzeichen häufig verwendeten Begriff "Inverkehrbringer" gibt es in der EU-Gesetzgebung gar nicht. Es gibt nur das "Inverkehrbringen", das einen Zeitpunkt im Produktlebenszyklus kennzeichnet. Den "Inverkehrbringer" könnte man vereinfacht zusammenfassen als den "Hersteller, Einführer oder Händler, der das Produkt erstmals auf dem Gemeinschaftsmarkt bereitstellt".

Harmonisierte europäische Normen (hEN): Das, was Produkte tatsächlich erfüllen müssen
So, jetzt wird es endlich konkret. Wenn nun also ein Hersteller (oder "Inverkehrbringer" ein CE-Kennzeichen braucht, interessiert ihn eher weniger der Gesetzgebungswust von oben, sondern umso mehr: "Was muss das Produkt denn jetzt können"? Und damit kommen wir zu den harmonisierten europäischen Normen (hEN).

Eine Norm muss ein paar Bedingungen erfüllen, damit sie eine hEN werden kann.
Schauen wir noch einmal in den Beschluss 768/2008/EC: Eine harmonisierte Norm ist eine "Norm, die von einem der in Anhang I der Richtlinie 98/34/EG anerkannten europäischen Normungsgremien auf der Grundlage eines Ersuchens der Kommission nach Artikel 6 jener Richtlinie erstellt wurde". Super, machste eine EU-Richtlinie auf, kriegste einen Verweis auf die nächste (die übrigens schon gar nicht mehr in Kraft ist).

Ich erspare Ihnen das - wir kürzen ein wenig ab:

1. Eine europäische Norm muss von einer europäischen Normungsorganisation (CEN, Cenelec und ETSI) verabschiedet werden.
2. Eine harmonisierte Norm ist (verkürzt gesagt) eine europäische Norm, die die Vermutungswirkung für das CE-Kennzeichen erfüllt.
3. Die EU-Kommission kann CEN, Cenelec und ETSI mit der Erarbeitung von Normen in einer bestimmten Frist beauftragen. Die Normen müssen "marktorientiert sein, dem öffentlichen Interesse und den in dem Auftrag der Kommission klar dargelegten politischen Zielen Rechnung tragen und auf Konsens gegründet sein."
4. Sobald es eine harmonisierte Norm zu einem Thema gibt, darf es keine nationalen Normen mehr geben, die dieser Norm widersprechen oder auch nur nicht vollständig entsprechen.

Nachlesen können Sie all das in der EU-Regulierung 1025/2012.

Eine harmonisierte Norm ist also ein überaus wichtiges Dokument. Es regelt, welche Anforderungen in einem bestimmten Bereich (z.B. Cybersecurity) tatsächlich gelten, um ein CE-Kennzeichen zu bekommen (ohne das das Produkt nicht auf den EU-Markt darf). Doch damit nicht genug: Wenn es eine harmonisierte Norm gibt, müssen alle nationalen Normen zum selben Thema zurückgezogen werden. Das hat gute Gründe: die EU möchte ja Regulierungswirrwarr vermeiden.

Trotzdem bedeutet es, dass sich nun auf EU-Ebene bald entscheiden muss, welche Cybersecurity-Norm  "das Rennen macht" und welche in der Irrelevanz (aka Archiv der "zurückgezogenen Normen") verschwindet.

Das ist neu. Bislang gab es ja kein CE-Kennzeichen für Cybersecurity, und somit auch keine harmonisierten Cybersecurity-Normen. Bislang konnten verschiedene nationale und internationel Nomen gemütlich nebeneinanderherexistieren. Das geht bald nicht mehr. Die ein oder andere DIN-, VDI- oder VDE-Norm zur Cybersecurity wird also demnächst verschwinden, und möglicherweise die ein oder andere ISO- oder IEC-Norm an Bedeutung gewinnen oder verlieren.
Oder es entstehen ganz neue Normen, die wird jetzt noch gar nicht kennen.

Draft Standardization Request (SReq): Bald werden die Normen für den CRA ausgewählt (oder geschrieben)
So.
Jetzt haben Sie alles Rüstzeug, um die Bedeutung des Statements ganz oben zu verstehen:
Da der CRA das NLF unterstützt, haben CEN/CENELEC einen SReq erhalten, um hENs zu entwickeln.

Klar, oder?

Die CRA-Umsetzung soll nicht im Regulierungswirrwarr enden (das sagt das New Legislation Framework, NLF). Deswegen müssen die europäischen Normungsorganisationen CEN / CENELEC nun entscheiden, welche Normen (harmonisierte europäische Normen, hEN) für die Umsetzung des CRA relevant werden ("die Vermutungswirkung erfüllen") - und möglicherweise ganz neue Normen schreiben.
Der Prozess dafür beginnt, sobald CEN/CENELEC von der EU-Kommission einen Standardization Request (SReq) erhalten, den sie dann beantworten müssen. Da der CRA noch nicht verabschiedet ist, haben CEN/CENELEC vorab einen Entwurf des geplanten SReq zur Kommentierung erhalten.

Das Dokument hat drei Teile:

1. Den Haupttext, der den Bezug zum (noch nicht verabschiedeten) Cyber Resilience Act erklärt und von den Adressaten (CEN / CENELEC) die Erarbeitung von Standards oder die Revision existierender Standards einfordert.
2. Den ersten Annex, der detailliert die Inhalte der zu erstellenden / revidierenden Standards auflistet. Er is aufgeteilt in produktübergreifende Security-Anforderungen, produktspezifische Security-Anforderungen und Anforderungen an das Schwachstellenmanagement. Bei den produktspezifischen Anforderungen werden explizit auch Anforderungen an industrielle Automatisierungssysteme, SPSen, IoT etc. gefordert. Außerdem sind Deadlines angegeben, die zwischen Ende Mai 2025 und Ende Mai 2026 liegen.
3. Den zweiten Annex, der formale und inhaltliche Anforderungen enthält, die die entwickelten / revidierten Standards erfüllen müssen. Das sind durchaus sehr konkrete inhaltliche Vorgaben - etwa die Notwendigkeit, Anforderungen für sichere Softwareentwicklung und SBOMs zu definieren.

Also, fassen wir noch einmal zusammen, warum die Existenz des Draft Standardization Request (SReq) für den CRA so eine große Nachricht ist:

Wir wissen sicher, dass in den nächsten drei Jahren europäische Standards entstehen oder bestehende Standards als europäische Standards verabschiedet werden, die entscheiden, welche Security-Anforderungen Produkthersteller (bzw. "Inverkehrbringer") erfüllen müssen, um ihr Produkt in der EU verkaufen zu können. Und im SReq ist auch schon recht deutlich erahnbar, was in diesen Standards stehen wird - teilweise, weil es explizit gefordert ist (siehe SBOMs und Co), teilweise gibt es Hinweise in den "Metadaten".
Für OT konkret diesen: Der Draft SReq wurde auch ans technische Komittee CLC/TC 65X geschickt, das "bereits als relevant identifiziert wurde". Das TC 65X ist das Bindeglied des IEC-Komittees TC 65 (internationale Standardisierung) in die europäische
Standardisierung beim CENELEC. Und das TC 65 ist verantwortlich für eine internationale Normenreihe, von der Sie sicher schon gehört haben: Die ISA/IEC 62443. Die EU-Kommission erwartet also offenbar, dass die ISA/IEC 62443 eine Rolle bei der Auswahl der harmonisierten Normen spielen könnte.

Der SReq gibt inhaltlich noch mehr her, wenn man sich im Detail mit ihm befasst. Für heute sprengt das hier den Rahmen...
Wenn Sie Interesse an einer genaueren Analyse haben, geben Sie mir doch kurz Bescheid - dann knöpfen wir uns das Dokument in einem der nächsten Briefings vor.

Wie geht es jetzt weiter?
Beim CEN/CENELEC wird nun eine "Standardization Request Ad Hoc Group (SRAHG)" einberufen, die sich um die Beantwortung des SReq (und die Kommentierung des Entwurfs) kümmert. Dort wird also entschieden, welche harmonisierten europäischen Normen (hEN) künftig definieren, welche Security-Anforderungen in der EU verkaufte Produkte erfüllen müssen. Klingt spannend? Finde ich auch. Ich bleibe dran, versprochen.

Weil dieser Text recht lang geworden ist, finden Sie ihn auch als Blogbeitrag zum einfacheren Lesen und Teilen - siehe Lesestoff 1 und 2.

2. Ist "aktive Cyberabwehr" dasselbe wie ein Hackback?

Wechseln wir an eine andere politische Front.

Schon seit mindestens sechs Jahren gibt es eine Debatte darüber, ob deutsche Sicherheitsbehörden künftig "Hackbacks" durchführen dürfen sollen, also ob sie auf Cyberangriffe ihrerseits mit einem Cyberangriff reagieren dürfen.

Bislang dürfen sie das (im Gegensatz zu Behörden vieler anderer Staaten) nicht. Das Bundesinnenministerium (BMI) möchte das ändern und eine Rechtsgrundlage für solche Gegenangriffe schaffen - oder?

Die Realität ist, wie immer, wohl komplizierter. Im Koalitionsvertrag steht explizit, Hackbacks lehne man ab. Aber im Interview sagt Innenministerin Nancy Faeser: "Vergessen Sie mal die Formulierung Hackback." Die Bundesregierung spricht lieber von "aktiver Cyberabwehr".

Und nun tobt ein Definitionskrieg. Was ist mit "aktiver Cyberabwehr" gemeint? Ist sie dasselbe wie ein "Hackback"?
Zwei unterschiedliche Meinungen dazu hat der Tagesspiegel diesen Monat abgebildet:

Variante 1: Ein Hackback ist eine Unterkategorie von aktiver Cyberabwehr.
Sven Herpig erklärt in einem Tagesspiegel-Gastbeitrag (Paywall), aktive Cyberabwehr umfasse eine ganze Litanei an möglichen Aktionen, einige auch jetzt schon legal: Honeybots, Umleitung und Analyse von Datenverkehr, teschnische Bereinigung von Systemen, Eingriff in ausländische IT-Systeme zur Auslands-Fernmeldeaufklärung - also klassische Geheimdiensttätigkeiten zur "Gefahrenfrüherkennung".
Aber eine Form der aktiven Cyberabwehr seien eben auch die Hackbacks. Ihre Besonderheit: Sie seien "intrusiv", hätten also Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.

Variante 2: Ein Hackback ist keine aktive Cyberabwehr, sondern davon zu trennen.
Tanya Gärtner und Annika Selzer erklären in einem weiteren Tagesspiegel-Gastbeitrag, ein Hackback sei etwas grundsätzlich anderes als aktive Cyberabwehr. Der Hauptunterschied läge in Zeitpunkt und Ziel: Aktive Cyberabwehr geschähe während eines akuten Cyberangriffs und diene der Verteidigung. Ein Hackback geschähe nach Abschluss des Angriffs und diene der Vergeltung.

Welche Definition "stimmt"? Das ist wahrscheinlich weniger wichtig, als sich beim Verfolgen der auf uns zukommenden öffentlichen Debatte darüber bewusst zu sein, dass es verschiedene Definitionen gibt. Natürlich werden die Begriffe strategisch eingesetzt. Der Hackback ist in der öffentlichen Debatte unbeliebt - das BSI könnte ihn also als "aktive Cyberabwehr" tarnen. Es könnte aber auch einen anderen Begriff verwenden, um sich vom Hackback tatsächlich inhaltlich abzugrenzen.

Sie sind nun jedenfalls gewappnet, um beim wahrscheinlich bald kommenden BMI-Gesetzesentwurf genau hinschauen zu können: Was fordert das BMI da wirklich? Wer sich vorher noch ein wenig ins Thema einlesen möchte, dem sei die Leseliste von Sven Herpig empfohlen - liegt im Lesestoff.

3. Bahnfunk ist "insecure by design"

Züge, die stillstehen - kennen wir in Deutschland. Türstörung, Weichenstörung, Störungen im Betriebsablauf, Personen auf dem Gleis.... alles schon gehört.
"Cyberangriff" hat zumindest auf meinen Bahnfahrten aber noch kein Lokführer als Grund für eine Verspätung durchgesagt.

In Polen hat nun ein solcher Angriff zum Stillstand von über 20 Züge geführt. Wobei...ob "Cyberangriff" es wirklich trifft, das ist umstritten - denn die Kompromittierung eines IT-Systems im engeren Sinne war gar nicht notwendig. Es wurde lediglich von Angreifern per Funk ein Stoppsignal an die Züge übermittelt. Ein total legitimes Signal, das tat, was es soll - und es braucht dafür keinerlei Authentifizierung. Jeder kann so ein Signal mit einer etwa 30 Dollar teuren Funkausrüstung an Züge senden, schreibt WIRED (Lesestoff 1). Die notwendigen Signale sind in EU-Dokumentationen nachlesbar; die Schwachstelle ist also bekannt. "Kein Cyberangriff" titelt daher auch Golem (Lesestoff 2).

Ich würde sagen: Willkommen in unserer ICS-Security-Welt - denn was wir da lesen, ist wohl ein klarer Fall von "insecure by design". Da intendierte Features oft keinerlei Schutz haben, sobald man einmal am System ist, sind sie auch leicht auszunutzen. Das Besondere bei Zügen ist halt, dass sie nicht durch einen halbwegs abgeschlossenen Schaltschrank in einem geschützten Perimeter fahren - sondern durch den öffentlichen Raum.

Ach ja, wer war's? Mutmaßlich die Russen natürlich, denn die störenden Funksignale sollen mit der russischen Nationalhymne und einer Putin-Rede unterlegt worden sein. Das kann freilich auch jeder Nicht-Russe tun.... eine falsche Spur, die genauso simpel wäre wie der Angriff selbst.

4. KI in der Cybersecurity: Von Ängsten und Chancen

Ende August habe ich wie letztes Jahr eine Woche in Singapur verbracht, um Teil des OT Cybersecurity Expert Panels der Singapore Cyber Security Agency (CSA) zu sein. Videos und Erkenntnisse kommen noch, aber eine Randnotiz möchte ich vorab schon einmal loswerden:

Woran denken Sie, wenn ich "künstliche Intelligenz (KI) und Cybersecurity" schreibe? Wahrscheinlich vor allem an den nicht abreißenden Strom an Warnungen, wie Angreifer KI nutzen können: Um bessere Phishing-Mails zu schreiben, Malware coden zu lassen oder - jüngstes Beispiel - mit ChatGPT eine Bombe zu bauen.

Als Gegenpol skizziere ich Ihnen ein kurzes Gespräch während meiner Zeit in Singapur: Betreiber kritischer Infrastrukturen müssen in Singapur jährlich Pentests durchführen und die Ergebnisse der CSA schicken. Ich, wissend um die Schwierigkeiten des deutschen BSI, schon die KRITIS-Auditberichte genügend zu sichten, frage verwundert, ob die CSA denn die ganzen Informationen überhaupt verarbeiten könne.
Antwort, in fast beiläufigem, komplett unaufgeregten Tonfall: "Oh, das machen wir natürlich mit KI."

Tja, das war ein trauriger Augenöffner.
Dass uns (mir?) diese Möglichkeit gar nicht erst einfällt, während sie in Singapur total selbstverständlich schon umgesetzt ist.
Dass uns stattdessen auf Knopfdruck jede Menge Probleme einfallen, die die Nutzung von KI in der Cybersecurity brächte.

Natürlich, blinder Enthusiasmus gegenüber neuen Technologien ist auch nicht angebracht, aber das war in Singapur auch nicht zu spüren. Aber es gibt eben auch keinerlei Berührungsängste, das Nutzen neuer Technologien ist dort einfach eine totale Selbstverständlichkeit.

Natürlich, Skepsis gegenüber dem Singapurer Weg (inklusive Gesichtserkennung beim Besuch von kritischen Infrastrukturen) ist angebracht.
Und trotzdem: Ein bisschen weniger Technikberührungsangst hätte ich in Deutschland auch gern.

5. Security unter Kontrolle: YouTube-Kanal, Termin 2024 und Early-Bird-Tickets

Zu guter Letzt gibt es noch zwei Updates zu Ihrem neuen Lieblingskongress SECURITY UNTER KONTROLLE.

Unseren YouTube-Kanal gibt es nun, und er ist auch schon mit den ersten vier Videos bevölkert. Von Hakan Tanriverdi und Stephan Gerling gibt es bereits jeweils das Video ihres Vortrags und ein kurzes Interview. Alle weiteren Videos kommen nach und nach. Schauen Sie mal rein - Link unten.

Außerdem steht das Datum für 2024. Kalender raus: Am 4. und 5. September 2024 findet die zweite Auflage des deutschsprachigen Automation-Security-Kongresses statt. (Wir mussten eine Woche nach vorne ausweichen, um das Alte Kesselhaus wieder zu bekommen).
Ab heute können Sie sogar Early-Bird-Tickets buchen - Link ebenfalls unten. Der Call for Contributions wird im Herbst beginnen.

Stay secure!
Sarah Fluchs