Architektur der Quantenresilienz
Vorausgeschaut: Die Architektur der Quantenresilienz
Kryptoanalytisch relevante Quantencomputer sind nur noch ein Frage der Zeit. Ob 2 oder 4 Jahre, ist noch unklar. Durch sie werden aber die Sicherheitsparadigmen von gestern schnell zu den Schwachstellen von morgen. Wahre Post-Quantum-Kryptografie (PQC) erfordert daher nicht nur den Wechsel eines Algorithmus, sondern eine strategische Verlagerung hin zu kryptografischer Agilität, sprich die Vorbereitung auf ein immer wieder anzunehmenden Austausch. Im Zentrum dieser Entwicklung steht die wichtigste – und doch oft übersehene – Grundlage: die umfassende Bestandsaufnahme.
Die Dokumentation Ihres kryptografischen Bestands
Um einen Perimeter zu verteidigen, müssen Sie ihn zunächst erfassen und kartografieren. Analog erfordert eine nachhaltige PQC-Umstellung ein zentrales Repository, das über einfache Tabellenkalkulationen hinausgeht. Dieses Inventar muss Folgendes sorgfältig dokumentieren:
- System-/Modulkategorisierung: Detaillierte Nachverfolgung von nationalen Sicherheitssystemen, Geschäftsanwendungen, Waffensystemen, Cloud-Umgebungen und IoT-/unbemannten Systemen.
- Kryptografische Metadaten: Identifizierung aller verwendeten Algorithmen, ihres Zwecks (Vertraulichkeit, Integrität oder Authentifizierung) und ihrer spezifischen Implementierung – sei es in Hardware, Mobilgeräten oder physischen Zugangskontrollen.
- Eigentumsverhältnisse und Governance: Identifizierung der Schlüsselpersonen und Komponentenleiter, die für die Migration, das Risikomanagement und die Koordination verantwortlich sind.
- Compliance-Artefakte: Pflege von Testplänen, Ergebnissen und Sicherheitsbewertungen, um sicherzustellen, dass jedes Engagement den strengen Standards des Bundes oder der Organisation entspricht.
Die Macht der Transparenz
Die Vorteile eines solchen Repositorys sind transformativ. Es bietet die strategische Transparenz, die erforderlich ist, um die Aufnahme zu optimieren und PQC-Lösungen dort zu priorisieren, wo das Risiko am höchsten ist. Durch die Identifizierung veralteter „Zombie“-Systeme – wie beispielsweise seit Jahrzehnten verwendete symmetrische Schlüsselprotokolle – können Unternehmen veraltete Technologien mit bewusster Dringlichkeit und ohne reaktive Panik auslaufen lassen, bzw. gezielt erneuern.
Integration von Risiken in den Prozess
Ein isoliertes Inventar ist statisch. Um echte Agilität zu erreichen, sollte Ihr kryptografisches Repository in Ihr Anwendungsrisikomanagement-Framework eingebunden sein. Nur diese Integration stellt sicher, dass eine Schwachstelle in einem bestimmten Algorithmus nicht nur ein Ticket auslöst, sondern eine automatisierte Bewertung der Auswirkungen auf das gesamte Ökosystem ihrer Lösung umfasst. So kann die Unternehmensleitung Risiken in Echtzeit bewerten und vor der Bereitstellung überprüfen, ob die Maßnahmen zur Risikominderung wirksam sind.
Der Vorteil von TrustSource
Um diese Komplexität zu bewältigen, benötigen Sie eine Lösung, die die Schnittstelle zwischen Sicherheit und Lieferkette versteht. TrustSource bietet eine einzigartige Integration von Risikomanagement und Software Supply Chain Security, deren Vorteile speziell im Kontext von Quantensicherheit zum Tragen kommen. Durch die Kombination von automatisierter Asset-Erkennung und der Überführung der Erkenntnisse in das Risiko-Management, stellt TrustSource sicher, dass Ihre Migration zu PQC nicht nur eine einzelne Compliance-Aufgabe ist, sondern eine nachhaltige Strategie in Sachen Resilienz darstellt.
Ist Ihr Bestand bereit für den Quantensprung?
Lesen Sie hier, wie TrustSource mit ts-scan die oben erwähnte Phase „Erkennung und Bestandsaufnahme” automatisieren kann!
Wollen Sie mehr zu dem Thema erfahren?
ts-scan nun auch als Github Action im Github Marketplace verfügbar
Optimieren Sie die Sicherheit Ihrer Lieferkette: TrustSource ts-scan jetzt als GitHub Action verfügbar
Wir freuen uns, Ihnen mitteilen zu können, dass das leistungsstarke Software Composition Analysis (SCA)-Tool von TrustSource, ts-scan, jetzt direkt im GitHub Marketplace verfügbar ist. Die Integration robuster Sicherheitsscans und Compliance in Ihre CI/CD-Pipeline war noch nie so einfach.
Mit der neuen ts-scan-action können Entwickler Software-Stücklisten (SBOMs) in Standardformaten – einschließlich SPDX und CycloneDX – direkt in ihren Workflows und direkt aus dem GitHub Marketplace heraus automatisch generieren.
Entscheidend ist, dass ts-scan auf Einfachheit und Datenschutz ausgelegt ist. Es arbeitet vollständig lokal, d. h. für die grundlegenden Aktionen sind keine API-Schlüssel erforderlich und während des Scanvorgangs verlassen keine Daten Ihre Umgebung, sofern Sie nicht die zusätzlichen TrustSource-SaaS-Angebote wie Risikomanagement, automatisierte Rechtskonformität oder Genehmigungsabläufe nutzen möchten. (Weitere Informationen finden Sie unter https://www.trustsource.io )
Intelligentes Scannen ohne viel Konfiguration
Das Alleinstellungsmerkmal von ts-scan ist seine intelligente Ziel-Erkennung. Im Gegensatz zu vielen Tools, die eine mühsame Konfiguration zur Definition des zu scannenden Zieles erfordern, ist ts-scan in der Lage, fast alle Zieltypen automatisch zu scannen, ohne dass explizite Anweisungen erforderlich werden.
Unabhängig davon, ob Sie gängige Paketverwaltungssysteme, bestimmte Dateien, ganze Repositorys oder Docker-Images scannen möchten, ts-scan identifiziert die Struktur und führt die Analyse durch.
Sie überlegen noch? Einfach ausprobieren!
Steigern Sie noch heute die Transparenz und Sicherheit Ihres Projekts, indem Sie TrustSource in Ihre GitHub-Workflows integrieren.
- Holen Sie sich die GitHub-Aktion: Starten Sie sofort über den Marktplatz: https://github.com/trustsource/ts-scan-action
- Tiefgehende Informationen: Erfahren Sie mehr über die umfangreichen Funktionen des Tools in unserer Dokumentation: https://trustsource.github.io/ts-scan
- Entdecken Sie den Code: Sehen Sie sich das Kern-Tool-Repository auf GitHub an: https://github.com/trustsource/ts-scan
PostQuantumGefahr
DER STILLE STURM: WIE SIE DIE POST-QUANTUM-KRYPTOGRAPHIE-GEFAHR MEISTERN
In der digitalen Welt halten wir unsere „Verschlüsselung“ – die Algorithmen, die unsere Banküberweisungen, Staatsgeheimnisse und privaten Nachrichten sichern – oft für unüberwindbar. Jahrzehntelang war dies auch der Fall. Doch am Informatik-Horizont braut sich ein stiller Sturm zusammen: das Aufkommen von kryptoanalytisch relevanten Quantencomputern.
Die Quantenbedrohung: Das Unknackbare knacken
Aktuelle kryptografische Standards wie RSA und Elliptic Curve Cryptography (ECC) basieren auf mathematischen Problemen, deren Lösung für klassische Computer unmöglich ist (z. B. die Faktorisierung großer Primzahlen). Ein Quantencomputer, der die Prinzipien der Superposition und Verschränkung nutzt, kann Informationen auf eine Weise verarbeiten, die für klassische Maschinen unmöglich ist.
Insbesondere ermöglicht der Shor-Algorithmus einem ausreichend leistungsfähigen Quantencomputer, diese asymmetrischen „Schlösser” innerhalb von Minuten zu knacken. Daraus entsteht ein Risiko, das man mit der Bezeichnung „jetzt ernten, später entschlüsseln” beschreibt: Angreifer könnten heute verschlüsselte Daten erfassen, bzw. einsammeln und darauf warten, dass die Technologie ausgereift ist, um sie in Zukunft zu entschlüsseln.
Lehren aus der Geschichte: Die Qualen des Übergangs
Wir haben das schon einmal erlebt, allerdings noch nie mit so hohen Einsätzen. Historische Übergänge bieten jedoch eine warnende Lehre:
- DES zu AES: Als der Data Encryption Standard (DES) Ende der 90er Jahre geknackt wurde, dauerte die Umstellung auf den Advanced Encryption Standard (AES) fast ein Jahrzehnt.
- SHA-1-Abkündigung: Die Abkehr vom SHA-1-Hashing-Algorithmus (nachdem er als anfällig erkannt wurde) wurde durch „Zombie“-Systeme erschwert, die den unsicheren Standard noch jahrelang weiterverwendeten, was zu weit verbreiteten Schwachstellen führte.
- Der Y2K-Vergleich: Wie bei Y2K gibt es auch bei der PQC-Migration eine „Frist“, die durch den Fortschritt der Hardware vorgegeben ist. Im Gegensatz zu Y2K kennen wir jedoch nicht das genaue Datum, an dem die Uhr „12“ schlägt. Eine Näherung s.bspw. Quantum doom clock.
Die größte Herausforderung bei diesen historischen Veränderungen war nicht die neue Mathematik, sondern die Sichtbarkeit. Unternehmen wussten oft nicht, wo ihre Kryptografie „fest codiert” war, was Updates zu einem manuellen, fehleranfälligen Albtraum machte, bei dem man sich durch Legacy-Code und Hardware kämpfen musste.
Die Lösung: Kryptografische Agilität
Globale Sicherheitsexperten, Kryptografie-Wissenschaftler und inzwischen auch das US-Kriegsministerium in einem Memo an seine Führung im vergangenen November fordern einen pro-aktiven Ansatz: Kryptografische Agilität.
Krypto-Agilität ist die Fähigkeit eines Informationssystems, zwischen kryptografischen Algorithmen zu wechseln, ohne dass dafür erhebliche Änderungen an der Infrastruktur oder umfangreiche Code-Neuprogrammierungen erforderlich sind. Anstatt „angeschraubt“ zu sein, wird Sicherheit modular. Dieser Ansatz ist aus folgenden Gründen unerlässlich:
- Algorithmen entwickeln sich weiter: Da das NIST PQC standardisiert, müssen die ersten Versionen möglicherweise aktualisiert werden, wenn neue Schwachstellen entdeckt werden.
- Hybridisierung: Bei der Migration müssen während einer Übergangsphase häufig ältere und quantenresistente Algorithmen parallel ausgeführt werden.
- Zukunftssicherheit: Ein agiles System kann sich an die nächste Bedrohung anpassen, ohne dass ein mehrjähriger „Rip-and-Replace“-Zyklus erforderlich ist.
Um dies zu erreichen, müssen Unternehmen zunächst ein umfassendes Kryptografie-Inventar erstellen und dabei jede Instanz der Verschlüsselung in nationalen Sicherheitssystemen, Cloud-Assets und IoT-Geräten identifizieren.
„ Seien Sie der Zeit voraus. Sichern Sie noch heute Ihre digitale Zukunft
Machen Sie den nächsten Schritt mit TrustSource
Die Umstellung auf Post-Quantum-Kryptografie (PQC) muss keine Reise ins Ungewisse sein. TrustSource bietet die Tools und das Fachwissen, um sicherzustellen, dass Ihre Software Lösungen widerstandsfähig bleiben.
- TrustSource Cryptographic Discovery Services:
Wir helfen Ihnen dabei, Ihre aktuelle kryptografischen Algorithmen zu identifizieren, zu inventarisieren und zu bewerten, um einen Risiko-orientierten Weg zur Quantenresistenz zu entwerfen. - TrustSource SBOM-Bestands- und Compliance-Workflows:
Speichern Sie Ihre SBOMs im TrustSource-Bestand oder nutzen Sie die Genehmigungs-Workflows, um die Risiken vor der Veröffentlichung Ihrer Software zu verwalten. Dokumentieren Sie die Existenz und Verwendung von Kryptoalgorithmen auf der Grundlage unseres Komponenten-Know-hows, sei es für Exportkontrollen oder Ihre Krypto-Agility-Implementierungen. - TrustSource Crypto Reporting:
Profitieren Sie von der Portfolio-weiten Analyse der verwendeten Kryptoalgorithmen und definieren Sie Migrationsstrategien auf der Grundlage von Komponenten und Portfolio-Risiken. - TrustSource Crypto Policies:
Verwenden Sie Richtlinien, um die Implementierung und/oder Verwendung schwacher Algorithmen im gesamten Unternehmen direkt in beim Bau der Software zu verhindern.
Wollen Sie mehr zu dem Thema erfahren?
Wichtiges ts-scan update
ts-scan update v1.5.2
Auf Basis der Ereignisse rund um den Shai-Hulud-Wurmhaben wir die Grundkonfiguration von unserem SCA Scanner ts-scan angepasst. Er führt in der Standard-Konfiguration keine Skripten aus der <scripts> Sektion der package.json mehr aus. Stattdessen wird eine Warnung ausgegeben, dass eine ggf. unsichere Konfiguration vorliegt. Um die Skripten dennoch auszuführen, ist ab Version 1.5.2 dem Scan-Aufruf explizit der Parameter node:enableLifecycleScripts hinzuzufügen.
Wir empfehlen unseren Kunden und Benutzern, ts-scan auf die neueste Version – hier v1.5.2 – zu aktualisieren, um Ihre Umgebung besser vor böswilligen Aktivitäten zu schützen, die durch unerwünschte Skriptausführungen ausgelöst werden.
BITTE BEACHTEN SIE: Dies ist keine durch ts-scan verursachte Schwachstelle. Die Fähigkeit, beliebige Skripten in der package.json zu verankern und ausführen zu lassen, ist eine Eigenschaft der Node-Umgebung. Diese existiert bereits seit geraumer Zeit und wurde auch bereits vor Jahren als mögliche Sicherheitslücke thematisiert. Jedoch wurde bisher nichts dagegen unternommen.
Den nx-Hack meistern
So identifizieren Sie bösartige NX-Versionen in Ihrer Codebasis
Kürzlich ist es wieder passiert: Einige böswillige Akteure haben einen ausgeklügelten Supply-Chain-Angriff gestartet. Das nx-team und mehrere Sicherheitsforscher (1, 2) haben bereits über diesen Vorfall berichtet. Hier finden Sie eine kurze Zusammenfassung:
Was ist passiert?
nx ist ein Paket mit etwas mehr als 23 Millionen Downloads im NPM-Paketregister. Es umfasst mehrere Plugins, die Entwickler zur Vereinfachung von Code-Verwaltungsaktivitäten verwenden, wie z. B. einige Hilfsfunktionen zum Schreiben von Dateien, zum Aktualisieren der Konfiguration (devkit), zum Verwalten des Knotens selbst (node) oder zum Linitieren von JavaScript- und Typescript-Code (lint).
Die Versionen um 20.9.0 und 21.5.0 bzw. 3.2.0 (key & enterprise-cloud) wurden böswillig verändert. Sie führten eine KI-basierte Suche durch, bei der die lokalen Dateistrukturen des Arbeitsbereichs des Entwicklers ausgewertet und alle Arten von Geheimnissen zusammengetragen wurden. Diese wurden dann unter Verwendung der Git-Anmeldedaten des Entwicklers in einem öffentlichen Git-Repository veröffentlicht.
Was kann man dagegen tun?
Der allererste Schritt wäre, festzustellen, ob jemand in Ihrem Unternehmen die betroffenen nx-Tools verwendet. Wenn Sie TrustSource verwenden, müssen Sie lediglich den „Component Impact Report” öffnen und nach den betroffenen Komponenten in den angegebenen Versionen suchen, z. B. @nx/devkit in Version 21.5.0 oder 20.9.0. TrustSource listet Ihnen alle Projekte auf, in denen genau diese Komponentenversionen in der Liste der transitiven Abhängigkeiten enthalten sind.
Dies ist ein gutes Beispiel dafür, warum transitive Abhängigkeiten so wichtig sind. nx hat etwa 663 abhängige Projekte, oder anders ausgedrückt: Es gibt 663 andere Tools, die nx-Tools verwenden. Sie können sich vorstellen, wie schnell und weit sich die Verbreitung ausdehnen kann.
Wenn ein Projekt jedoch die betroffenen Versionen verwendet, müssen die Entwickler davon ausgehen, dass ihre gesamte CI/CD-Kette kompromittiert ist. Jeder Entwickler sollte überprüfen, ob er ein Repository mit „s1ngularity” im Namen hat, das in den letzten 2–3 Wochen veröffentlicht wurde. Alle Anmeldedaten, die Sie in diesem Repository finden, müssen als geleakt betrachtet werden.
Bevor Sie diese jedoch ersetzen, sollten Sie Ihren Arbeitsbereich bereinigen!
Weitere Informationen und Details zur Bereinigung Ihres Arbeitsbereichs finden Sie in diesem Artikel.
Was können wir daraus lernen?
Wir sind froh, dass wir dieses Tool nicht verwenden. Aber es gibt zwei interessante Erkenntnisse für uns:
a) Bislang haben wir uns sehr auf das Lieferartefakt konzentriert. Aus diesem Grund umfasst ts-scan beispielsweise standardmäßig keine Dev-Abhängigkeiten. Um Dev-Abhängigkeiten in Ihren Scan einzubeziehen, müssen Sie den Parameter npm:includeDevDependencieshinzufügen. Wenn Sie noch nie einen Scan mit diesen Parametern durchgeführt haben, ist es sehr wahrscheinlich, dass der oben genannte TrustSource-Komponenten-Auswirkungsbericht keine Ergebnisse anzeigt, obwohl die Tools möglicherweise von Ihren Entwicklern verwendet werden.
Dies ist wichtig zu verstehen und der Grund, warum wir empfehlen, alle Entwickler in Ihrem Unternehmen über die Situation zu informieren. Wir empfehlen sogar, Scans mit dem oben genannten Parameter anzufordern und den Bericht in den nächsten Tagen und Wochen erneut auszuführen. Einige der 663 Tools, die nx verwenden, nutzen es möglicherweise im Hintergrund, z. B. nx-python codegen, reactionary, goodiebag usw., sodass es für Ihre Entwickler möglicherweise nicht offensichtlich ist.
Wir empfehlen außerdem, die Scans, die die Entwicklungsabhängigkeiten enthalten, in ein separates Projekt/Modul zu verschieben. Angenommen, Sie haben Projekt A mit den Modulen A1 und A2, dann könnten die Scans mit den Entwicklungsabhängigkeiten auf Projekt A-DEV mit den Modulen A1 und A2 abzielen. Auf diese Weise könnten Sie alle Entwicklungsabhängigkeiten verfolgen, sie aber aus den üblichen Compliance-Abläufen heraushalten. Projekte, die kein PROJECTNAME-DEV bereitstellen, können einfach durch Sortieren der Projektliste in aufsteigender Reihenfolge identifiziert werden.
b) Oft sind Entwicklungsumgebungen offen und weniger sicher. Oft hört man den Spruch „Wer sollte in Betracht ziehen, dies zu brechen, und was könnte er dadurch erreichen?“ Aber hier sehen Sie, welche Auswirkungen dies haben kann. Angefangen bei der Verschlüsselung bis hin zur Offenlegung von Informationen und Anmeldedaten könnte die Arbeit jedes Entwicklers direkt beeinträchtigt werden. Indirekt kann dies zur Einführung von bösartigem Code führen, die Produkte des Entwicklers gefährden, den Ruf des Unternehmens des Entwicklers schädigen und das Geschäft seiner Kunden beeinträchtigen.
Während dies vor fünf Jahren noch unwahrscheinlich gewesen wäre, muss es heute als Realität berücksichtigt werden. Sie sollten Ihre Entwicklungsumgebungen entsprechend einrichten (interne Paket-Proxys, geschützte und klar dokumentierte Builds (SBOMs), strenger Schutz von CI/CD-Anmeldedaten, API-Schlüsseln und Verwendung von Schlüsselspeichern usw.). Führen Sie von Anfang an das richtige Risikomanagement ein: Was könnte schiefgehen, wenn unser Code bösartig/fehlerhaft/gehackt ist? Wie könnte das passieren? Welche Auswirkungen hätte dies auf die Vertraulichkeit/Verfügbarkeit oder Integrität der Daten/Geschäfte/Geschäftstätigkeiten unserer Kunden?
Wenn Sie Unterstützung bei der Beantwortung dieser Fragen benötigen, wenden Sie sich gerne an uns. Unsere Muttergesellschaft ist darauf spezialisiert, ihre Kunden bei der Beantwortung solcher Fragen zu unterstützen und Strategien zur Sicherung von CI/CD und den Entwicklungsergebnissen zu entwickeln. Weitere Informationen finden Sie hier.
Cyber Resilience Act veröffentlicht
EU Cyber Resilience Act veröffentlicht
Heute wurde der EU Cyber Resilience Act (CRA) veröffentlicht. Damit sind seine Gültigkeit und der Zeitplan festgeschrieben, da sich aus dem Veröffentlichungsdatum die entsprechenden Daten für die Umsetzung ergeben: Beginn der tatsächlichen Gültigkeit – also der Zeitpunkt, ab dem jeder Software-Hersteller oder Vertreter eines solchen, der in der EU eine Software auf den Markt bringt, sich konform verhalten muss – ist der 11. Dezember 2027.
Genauer: Die Regelungen, insbesondere Art. 13 sowie Anhang I und II, gelten für alle Produkte mit digitalen Elementen, die ab diesem Termin in der EU auf den Markt kommen. Für Produkte, die vor diesem Termin auf den Markt kommen oder gebracht wurden, gelten die Anforderungen, sobald sie nach dem Termin wesentliche Änderungen erfahren, s. Art. 69 II CRA. Die Berichtserfordernisse aus Art. 14 sind jedoch für alle Produkte bereits ab dem 11. September 2026 zu bedienen, unabhängig vom Termin des Markteintritts (Art. 69 III CRA).
Von jetzt an zählt die Übergangsfrist, bis zu der sich Software-Anbieter mit den neuen Anforderungen auseinandersetzen, bzw. diese umsetzen müssen. Die Umsetzung ist stellenweise nicht trivial und erfordert einiges an organisationalem Wandel, bspw. die Aufnahme ggf. noch nicht vorhandener Risikoanalysen und -bewertungen in den Release-Prozess, die Deklaration von Unterstützungszeiträumen oder den Aufbau geeigneter Schwachstellen-Management-Prozesse.
– soweit nicht anders dargestellt, beziehen sich im Folgenden alle Verweise auf den Text des CRA –
Sie wollen klären, welche Anforderungen der CRA an Ihre Organisation stellt?
Sprechen Sie unverbindlich mit unserem Experten!
Für wen ist der Cyber Resilience Act von Bedeutung?
Der CRA betrifft grundsätzlich alle, die ein Produkt mit digitalen Elementen, also einer Software-Unterstützung bereitstellen. Allerdings schränkt er seine Gültigkeit auch gegenüber bereits anderweitig regulierten Gruppen ein. So werden Produkte, die sich nur im Automotive-Bereich, im Marine- oder Aviation-Umfeld bewegen oder der Medical Device Regulation unterliegen, ausgenommen. Es ist jedoch anzunehmen, dass eine Dual-Use-Möglichkeit, also eine Nutzbarkeit in anderen, nicht regulierten Bereichen, die Gültigkeit auch wieder herstellen wird.
Rollen der Akteure
Weiterhin ist die Rolle des Handelnden relevant für die Beurteilung der Gültigkeit. Konzeptuell versucht die Regulierung den Nutznießer der wirtschaftlichen Transaktion in die Verantwortung zu nehmen, der innerhalb der EU das Geschäft abbildet. Was bedeutet das?
Im einfachen Fall stellt ein europäischer Anbieter ein Produkt mit digitalen Elemente her, welches in den regulierten Bereich (s.o.) fällt. Somit steht der Anbieter direkt in der Pflicht, die CRA-Anforderungen für sein Produkt zu erfüllen, beispielsweise ein Hersteller für Stereoanlagen oder Musikboxen, die Musik-Streaming unterstützen oder eine Werkzeugmaschine, welche per Fernüberwachung gewartete werden kann.
Sitzt der Hersteller des Produktes außerhalb der EU, gehen diese Pflichten an seinen Stellvertreter über, den „Inverkehrbringer“. Dies kann ein Händler, ein Partner oder ein Implementierungspartner sein, eben der nächste wirtschaftliche Nutznießer. Interessant ist, dass dieser auch für die Einhaltung der Pflichten bei der Herstellung bürgen muss. Das bringt eine komplett neues Haftungsregime für bspw. Lizenzverkäufer amerikanischer Software mit sich!
Open Source
Sobald Open Source ins Spiel kommt, wird die Kette etwas unklarer. Aber der CRA kennt und berücksichtigt das Open Source Konzept. Der eigentliche Urheber einer Open Source Lösung bleibt von den Anforderungen verschont. Nimmt ein Akteur jedoch eine Open Source Lösung und nutzt sie wirtschaftlich, sei es durch Support-Verträge, treffen ihn die Regelungen analog zu denen eines Anbieters. Beispielsweise ist eine SUSE im Sinne des CRA verantwortlich für die von ihr bereitgestellte Distribution.
Ausnahmen gibt es nur für sogenannte Stewards. Diese haben weniger scharfe Anforderungen zu erfüllen. Diese Rolle wurde für die sogenannten Foundations (Eclipse, Cloud native, etc.) geschaffen, da sie zwar eine Form des Inverkehrbringers darstellen, jedoch keine mit einem herkömmlichen Software-Anbieter vergleichbaren, wirtschaftlichen Vorteile aus der Bereitstellung und Verbreitung ziehen. Um als Steward zu gelten, ist eine Anerkennung erforderlich.
Was sind die wesentlichen Neuerungen?
Der leitende Gedanke hinter dem CRA ist die Verbesserung der Sicherheitslage für die Konsumenten von Software. Da heutzutage fast alles von und mit Software gesteuert wird, bzw. ausgestattet ist, sind Cyber-Angriffe fast überall möglich. Jede Komponente, die durch eine Internetverbindung, ein WLan oder auch eine Near-Field-Kommunikation wie ZigBee oder Bluetooth zählt zur potentiellen Angriffsoberfläche – neu-deutsch: Attack Surface- und ist daher mit Bedacht zu nutzen, bzw. bereitzustellen.
Der Anbieter einer Software im europäischen Markt hat daher zukünftig folgende Anforderungen zu erfüllen:
- Bereitstellen eines Software Bill of Materials (SBOM), s. Anhang I
- Regelmäßiges Durchführen einer Risikobetrachtung der Sicherheitsrisiken sowie deren Aufnahme in die Dokumentation, s Art. 13, III und IV
- Erstellen einer Konformitätserklärung, s. Art. 13 XII, bzw. Art. 28 I sowie Anhang IV
- Bereitstellen einer CE-Kennzeichnung, s. Art. 12 XII, bzw. Art. 30 I
- Definition einer zu erwartenden Lebensdauer des Produktes und die Bereitstellung kostenloser Sicherheits-Updates innerhalb dieses Zeitraumes, s. Art. 13 VIII ff
- Einfordern umfangreicher Meldepflichten (gem. Art. 14)
- Mitteilung aktiv ausgenutzter Schwachstellen innerhalb von 24h an die European Network and Information Security Agency (ENISA) über eine noch zu schaffende Meldeplattform (vermutlich analog der bereits im Telekom-Umfeld bestehenden Lösung)
- Ergänzend hierzu eine Präzisierung der Einschätzung sowie der Maßnahmen innerhalb von 72h
- Information der Nutzer des Produktes sowie die von diesen zu ergreifenden Maßnahmen, s. Art. 14 VIII.
Wie kann TrustSource helfen?
- Einheitliche Plattform für Software Analyse, Compliance & Release-Management
- Integriertes Risiko-Management
- Automatisiertes Schwachstellen-Management
- Durchgängige, CRA-konforme Dokumentation
- CSAF-konforme Meldungen
- Einheitlicher Schwachstellen-Meldeprozess
- Umsetzungsunterstützung
Was sind die Auswirkungen der Nicht-Einhaltung?
Jedes Gesetz ist zunächst nur die Deklaration einer Verhaltensvorgabe. Was ist jedoch die Folge, wenn man sich nicht der Vorgabe gemäß verhält? Welche Risiken drohen den Anbietern?
Mit Veröffentlichung werden die Mitgliedsstaaten beauftragt, eine Stelle zu benennen, die für die Aufsicht in dem jeweiligen Land verantwortlich ist. In Deutschland wird dies nach aller Voraussicht das BSI sein. Dieses wiederum kann dann im Verdachtsfall entsprechende Prüfungen durchführen, bzw. beauftragen. Werden dabei Missstände festgestellt, führt dies in der Regel zur Aufforderung der Nachbesserung, kann jedoch auch entsprechend sanktioniert werden. Der CRA sieht folgende, mögliche Sanktionen vor:
- Bei Verstoß gegen grundlegende Sicherheitsanforderungen (Anhang I) bis zu 15 Mil. EUR oder, bei Unternehmen, bis zu 2,5% des weltweiten Jahresumsatzes im vorangegangenen Geschäftsjahr. (s. Art. 64 II)
- Bei Verstoß gegen Pflichten, die der CRA auferlegt, bis zu 10 Mil. EUR oder – für Unternehmen – bis zu 2% des ww Umsatzes (Vorjahr) (s. Art. 64 III)
- Für unrichtige, unvollständige oder irreführende Meldungen gegenüber den Behörden, bis zu 5 Mil. EUR, bzw. 1% des Jahresumsatzes für Unternehmen (s. Art. 64 IV)
Darüber hinaus besteht die Möglichkeit, bei nachhaltiger Nicht-Konformität die Verbreitung des Produktes einzuschränken, bzw. es vom Markt zu nehmen, s. bspw. Art. 58 II.
Sie sind sich nicht sicher, was das für Ihre Organisation bedeutet?
Sprechen Sie unverbindlich mit einem unserer Experten!
TrustSource zeigt OpenSSF Scorcards an
Hier klicken, um das Bild zu vergrößern
In unserer Komponentendatenbank, in der wir Meta- und Clearing-Informationen zu Komponenten sammeln, haben wir die Open Source Security Foundation (OpenSSF) Scorecard ergänzt. Diese erlaubt es, den Sicherheitsstatus von Open-Source-Projekten zu erkennen. Der Score, der vom OpenSSF-Projekt der Linux Foundation im Jahr 2020 eingeführt wurde und derzeit regelmäßig für etwa 1 Million Open-Source-Projekte auf Github ausgewertet wird, ist ein aggregierter Wert, der die vom Open-Source-Projekt getroffenen Sicherheitsmaßnahmen widerspiegelt. Er kann als Anhaltspunkt dafür verwendet werden, wie sehr Sie den Sicherheitsbemühungen eines bestimmten Projekts vertrauen können, ohne es weiter zu evaluieren.
Was sagt die Scorecard aus?
Der Wert oder die Punktzahl der Scorecard ist das Ergebnis von sechzehn Prüfungen, die die Best Practise der sicheren Softwareentwicklung widerspiegeln. Sie umfassen die Bereiche Entwicklung, Tests, Wartung und Schwachstellen, aber auch Code- und Build-Management. Auf der Grundlage eines umfassenden Satzes Best Practises durchsuchen die Tests das Code-Repository nach Belegen dafür, dass die Praktiken vom Projekt aktiv angewendet werden.
Derzeit sind 18 Tests verfügbar, von denen 16 über die API zugänglich sind. Eine ausführliche Dokumentation der Tests ist hier zu finden. Jeder Test wird mit einer Punktzahl zwischen 0 und 10 bewertet, wobei 10 die bestmögliche Punktzahl darstellt. Die Testergebnis und einem Risiko gewichtet ergeben zusammen eine Gesamtpunktzahl.
In einigen Fällen, kann es sein, dass Tests aufgrund von Projekt-Setups nicht anwendbar sind. Beispielsweise könnte es sein, dass ein Projekt keine Pakete über Github bereitstellt. Dadurch wird der Test auf Pakete nicht anwendbar sein, da die aktuelle Implementierung noch keinen Mechanismus zur Überprüfung anderer Paketmanager bietet.
Wenn Sie jedoch eine Entscheidung treffen wollen, ob Sie eine bestimmte Komponente einsetzen wollen oder nicht, hilft Ihnen die Durchführung eines Scorecard-Tests – oder ein Blick auf die Komponente in unserer Datenbank – dabei, einen Eindruck zu bekommen, welchen Aufwand Sie in die Absicherung der Komponente investieren müssen. Je höher die Punktzahl, desto mehr Vertrauen können Sie in die Komponente setzen.
Was sagt die Scorecard NICHT aus?
Bitte verstehen Sie eine hohe Punktzahl aber nicht als Garantie für eine sichere Komponente! Auch eine niedrige Punktzahl deutet nicht unmittelbar auf eine schwache oder fehlerhafte Komponente hin! Es wäre schlicht falsch, anzunehmen, dass eine niedrige Punktzahl ein Hinweis auf eine anfällige Komponente ist! Derzeit sind die Tests noch nicht umfänglich und prüfen nur auf ein Set ihnen bekannter Sicherheitswerkzeuge. Auch werden nur die im Repository sichtbaren Informationen geprüft. Bleiben diese auf einem Entwickler- oder CI-System und finden nicht den Weg in das Git-Repository, tauchen sie auch nicht im Testergebnis auf!
Die Punktzahl gibt an, welche Schritte das Projekt unternimmt, um sicherzustellen, dass der von ihm bereitgestellte Code bewährten Praktiken folgt und daher mit hoher Wahrscheinlichkeit frei von Fehlern und Schwachstellen ist. Aber es ist eben keine Garantie! Wenn alles gut läuft, alle Tests 10 zurückgeben, kann es immer noch vorkommen, dass eine Schwachstelle in einer vorgelagerten Komponente auftritt, die für das Projekt selbst nicht einfach oder gar nicht zu beheben bzw. zu umgehen ist.
Verwenden Sie die Punktzahl als Indikator. Aber machen Sie die Entscheidung, ob Sie eine Komponente verwenden wollen oder nicht, primär von ihrer Funktionalität abhängig und nicht von der Punktzahl. Sie werden – vor allem in diesen frühen Tagen, in denen der Score noch nicht weit verbreitet ist – noch viele gute Projekte mit geringen Scores finden.
Was kommt als Nächstes?
Wir empfehlen, dies Scorecards als Indikator für eine Eignungsbeurteilung hinzuzuziehen, da sie einen Hinweis darauf geben, wie stark Sie sich auf Ihre vorgelagerten Komponenten verlassen können. Zudem lässt sich über eine historische Betrachtung der Veränderung des Scores eine Tendenz erkennen, die eine interesante Aussage über das Projekt und seine Einstellung zu den Best Practises erkennen lässt. Wir werden Anfang kommenden Jahres genügend Werte gesammelt haben, um diese „Tendenz“ auswerten zu können.
Da TrustSource alle KomponentenIhrer Lösung kennt, wird es nun auch möglich sein, mehr aus den einzelnen Scores in Bezug auf das Projekt zu machen. Ein einfacher Durchschnittswert wäre sinnlos. Aufgrund der Menge der Komponenten wäre ein Durchschnittswert irgendwo bei einer bedeutungslosen 5 zu erwarten. Aber wir experimentieren derzeit mit Quantilen oder Top-10- und Low-10-Durchschnitten sowie dem Verhältnis von Nicht-bewerteten Komponenten zu bewerteten Komponenten.
Außerdem werden wir einen Service anbieten, mit dem man seine eigenen Komponenten oder nicht geprüfte Open Source Repositories überprüfen kann, indem man – wie beim DeepScan einfach eine URL angibt oder auch die Scorecard auf nicht-Github-Projekte überträgt. Wenn wir erfolgreich sind, werden wir unsere Entwicklungen in OpenSSF einbringen.
Sie wollen mehr über SBOMs oder OpenSSF Coding Best Practises erfahren? Kontaktieren Sie uns!
TrustSource @ IIOT SBOM in Antwerpes
Wir sehen uns am 10. November auf der IIOT SBOM !
Vielen Dank an @LSEC – Leaders In Security – für die Einladung, über #SBOM #DevSecOps und die kommenden Herausforderungen aus Perspektive der IT Security zu sprechen. @Jan wird in seinem Vortrag „Getting the SBOM right, and then?“ auf die Herausforderungen rund um die Erstellung von SBOMs eingehen und wie man diese auf der Automatisierungsseite angehen kann. Des Weiteren wird er sich mit der Lebenszyklus-Perspektive befassen, d.h. was nach der Erstellung von SBOMs kommt. Dabei wird er auch über die Arbeit der #LinuxFoundation #OpenChain Automation-Arbeitsgruppe berichten und zu einer neuen Art von SBOM-Benutzergruppe einladen, die Best Practices für die Definition von SBOMs umreißt.
Wir freuen uns auf tolle Gespräche und darauf, noch mehr über die Herausforderungen zu erfahren, mit denen Sie bei der Erstellung von SBOMs in der IIOT-Welt konfrontiert sind.
Bis übermorgen in Antwerpen!
Nachlese
(22.11.22) Vielen Dank noch einmal für die vielen interessanten Vorträge und animierenden Gespräche! Es hat Spaß gemacht, mit den Teilnehmern und Referenten sich auszutauschen und Ideen und Anforderungen zu diskutieren. Die Vorträge sind auf der Seite von IIOT SBOM als Videos verfügbar. Jan’s Vortrag haben wir hier verlinkt.
Der erste Teil beschäftigt sich mit SBOMs, was gehört rein, wie kann man sie ablegen, Formate, etc.,Der zweite teil beschäftigt sich mit den Themen Automatisierung und was lässt sich mit den generierten Informationen anfangen. Die Zweiteilung des Vortrages ergab sich aus der Agenda, welche auch die Koordination mit Vortragenden aus anderen Zeitzonen erforderte.
TrustSource und SCANOSS wollen künftig enger zusammenarbeiten
TrustSource und SCANOSS wollen zukünftig enger zusammenarbeiten
Im Vorfeld des Open Source Summit Europe 2022 haben SCANOSS – Anbieter der vermutlich größten Datenbank für Open Source Informationen – und TrustSource – die Automationslösung für Prozesse im Bereich Open Chain Security und Compliance – vereinbart, künftig enger zusammenzuarbeiten.
Im Zuge der Arbeiten im Kontext der OpenChain Tooling Workgroup wurde das Open Source Compliance Capability Modell entwickelt. Dieses Modell beschreibt die unterschiedlichen Kompetenzen und Fähigkeiten, die für eine umfängliche Abwicklung von Open Source Compliance erforderlich sind. „SCANOSS hat das >Snippet-Scanning< mit der ersten Open-Source-Lösung standardisiert, die von Open-Source-Communities wie OSS Review Toolkit aufgenommen wurde.“, berichtet Jan Thielscher, der die Arbeitsgruppe derzeit koordiniert. „Das ist genau der Bereich, aus dem wir (TrustSource) uns bisher herausgehalten haben. Zusammen mit der unglaublichen Informationsbasis, die SCANOSS für die Identifikation von Snippets aufgebaut hat, können wir durch eine engere Zusammenarbeit den letzten weißen Flecken auf unserer Capability Map schließen.“
Derzeit ist es bereits möglich, Scan-Ergebnisse, die mit Hilfe der SCANOSS-Workbench oder dem SCANOSS-CLI erzeugt werden, in TrustSource zu importieren und somit in den von TrustSource verwalteten Compliance-Prozess zu überführen. SCANOSS-Nutzer erhalten somit die Möglichkeit, Ergebnisse nicht nur in Form eines Audit-Ergebnisses vorliegen zu haben, sondern in den regulären Kontext eines unternehmensweiten Portfolio-Managements einzubinden. Die TrustSource-Benutzer profitieren zunächst von der Möglichkeit, die zusätzlichen Erkenntnisse von SCANOSS zu nutzen. In Kürze werden auch die erweiterten Erkenntnisse wie Export-Controls, etc., die SCANOSS bereitstellen kann, in TrustSource zu verwalten bzw. deren Einhaltung zu monitoren sein.
„Das macht die Sache dann rund.“, meint Jan Thielscher. „Natürlich stellen unzureichende Metadaten, nicht deklarierte Lizenzen oder unklare Commiter-Situationen auch weiterhin Herausforderungen für die OSPOs dar, aber der Großteil der Aufgaben lässt sich durch die hohe Integration und die vielen Berichte, die aufgrund der hohen Integration einfach möglich sind, schon weitgehend automatisiert abbilden. Und da liegt der immense Effizienzgewinn!“
Treffen Sie uns auf dem Open Source Summit in Dublin @ B.19
Lernen Sie mehr über das Open Chain Tooling Workgroup Capability Modell, TrustSource und wie viel Prozess-Automation auch in dem Bereich Open Source Compliance bereits möglich ist.
Openchain - Umfrage zu Open Source
Openchain - Umfrage zur Opensource Nutzung
Die Openchain Workgroup der Linux Foundation, die in den letzten Jahren vor allem den Standard ISO 5230 – Open Source Compliance geprägt hat, hat ein Umfrage über den Einsatz und Umgang von Open Source in Unternehmen erarbeitet. Als internationale Erhebung soll sie helfen die Arbeit der Organisation zu fokussieren und den teilnehmenden Unternehmen eine Möglichkeit geben, sich selbst in Bezug auf Open Source zu reflektieren. Die Ergebnisse der Umfrage werden unter Creative Commons zero (CC-0) lizenzesiert und lassen sich somit frei verwenden.
Als Unterstützer der Openchain Initiative rufen wir unsere Kunden und Partner auf, die Umfrage zu unterstützen und damit den Pool an Informationen anzureichern. Die Umfrage erfordert ca. 10 Minuten Zeit und kann unter diesem Link erreicht werden.
