Mehr und mehr Klarheit zieht ein in die Umsetzung der NIS2-Direktive der EU: Ende Juli hat das NIS2-Umsetzungsgesetz das Kabinett der bundesdeutschen Regierung passiert. Der entscheidende Beschluss im Bundestag steht nun bevor. Für alle Unternehmen und Behörden, die sich fragen, ob sie das etwas angeht, hat das BSI jetzt unter dem griffigen Hashtag #nis2now eine umfangreiche Webseite mit einer Betroffenheitsprüfung und wertvollen Informationen gelauncht.

Auch wenn das Inkrafttreten durch den Bundestagsbeschluss noch auf sich warten lässt und selbst wenn der ursprünglich geplante Termin im Oktober im Zuge dessen verstreichen sollte, müssen sich Unternehmen jetzt vorbereiten, fordert das Bundesamt für Sicherheit in der Informationstechnologie (BSI). Die Behörde gibt deshalb Unternehmen und Organisationen jeder Art einen achtteiligen Fragenkatalog an die Hand, mit dem IT-Leiter und Verantwortliche herausfinden können, ob die strengen Regularien von NIS2 auch für sie gelten. Allen Unternehmen und Einrichtungen, die unter die NIS2-Regelung fallen, liefert es für die Frage, was sie im Vorfeld der Rechtswirksamkeit von NIS2 schon jetzt tun können, weitere Hilfestellung und Antworten.

Hoher Bedarf, hohe Nachfrage

Der Bedarf scheint hoch. Sowohl BSI-Chefin Claudia Plattner als auch Bundes-CIO Markus Richter vermeldeten Erfolge in Form von mehreren zehntausend Zugriffen schon an den ersten Tagen (zum Beispiel auf LinkedIn: Plattner, Richter). Direkt auf der BSI-Seite steht die NIS2-Betroffenheitsprüfung. Hier finden sich „konkrete, an der Richtlinie orientierte Fragen, um Ihr Unternehmen einzuordnen“. Die Fragen sind „kurz und präzise gehalten und werden bei Bedarf im Kleingeschriebenen tiefer gehend erläutert“. Gewissheit, ob ein Unternehmen oder eine Organisation von NIS2 betroffen ist, gibt es dann binnen weniger Minuten.

In den Fragen müssen Unternehmen angeben, ob sie Betreiber kritischer Anlagen sind, Anbieter öffentlich zugänglicher Telekommunikationsdienste oder öffentlicher Telekommunikationsnetze, qualifizierte Vertrauensdienste-Anbieter oder eine Top-Level-Domain-Name-Registry oder DNS-Dienste anbieten. Auch wenn ein Unternehmen ein nicht qualifizierter Vertrauensdienste-Anbieter ist oder Waren und Dienstleistungen verkauft, die einer der in Anlage 1 oder 2 der NIS2-Richtlinie bestimmten Einrichtungsarten zuzuordnen sind, ist es von den NIS2-Regularien betroffen.

Wer alle Fragen mit „Nein“ beantworten kann, ist nicht von NIS2 betroffen. Allen anderen jedoch bietet das BSI umfangreiche Hilfestellungen und Recherchemöglichkeiten dafür, was denn jetzt zu tun sei. Eine FAQ-Liste erklärt ausführlich in neun Fragen den aktuellen Stand, ob man noch warten oder bereits mit der Vorbereitung anfangen solle. Links zu Quellen und Ansprechpartnern finden sich hier ebenso wie weitere Informationen für die Betroffenheits-Checks und Begriffserklärungen (Was bedeutet „wichtig“, „wesentlich“ und „besonders wichtig“ im Kontext des NIS2?). Sehr wichtig dabei sind auch die Sektionen, die erklären welche Pflichten und Nachweise betroffene Unternehmen wann und wohin liefern müssen, sowie die noch unbeantwortete Diskussion, ab wann NIS2 verbindlich gelte.

Unter der Vielzahl von Informationen des BSI finden sich auch Unterstützungsangebote für die Wirtschaft, aber auch klare Anweisungen für die nächsten Schritte und grundlegende Erklärungen zu Kritischen Infrastrukturen (KRITIS) im Allgemeinen.

Jetzt aktiv werden, trotz Warten auf Bundestag

Die in der Diskussion teils hart umstrittene nationale Umsetzung der europäischen NIS2-Richtlinie hatte sich zuletzt aufgrund starker Meinungsverschiedenheiten der Beteiligten verzögert, sodass der bisher erwartete Termin verschoben werden musste. Das Bundesinnenministerium hatte schon vor Wochen bestätigt, dass die Richtlinie nicht im Oktober in Kraft treten werde.

Unabhängig vom Warten auf den Bundestag sollten Betroffene jetzt aktiv werden, schreibt das BSI, man müsse verantwortliche Personen und Teams benennen, die Rollen und Aufgaben definieren, aber auch Bestandsaufnahme machen und Prozesse zur fortlaufenden Verbesserung einrichten. Die Vorbereitung auf die anstehende Meldepflicht sollte dabei höchste Priorität haben.

Umfangreiche Informationen auch von Greenbone

Auch Greenbone hat dem Thema NIS2 in den letzten Monaten zahlreiche Blogposts und Anleitungen gewidmet, vom Cyber Resilience Act über die Bedrohungslage für Kommunen bis hin zu effizienten Maßnahmen und grundsätzlich allem, was Betroffene jetzt über NIS2 wissen müssen.

Ransomware, Phishing, Denial-of-Service-Attacken: Einer aktuellen Studie zufolge machen sich 84 Prozent der befragten Unternehmen Sorgen um die Sicherheit ihrer IT-Systeme und sehen einen weiteren Anstieg der Bedrohungslage. Mit gutem Grund, denn auch veralteter Code, Datendiebstahl durch Mitarbeiter, die unzureichende Absicherung von Unternehmensnetzen und das Benutzen von nicht autorisierten Geräten machen den Firmen zu schaffen.

Für ihre Studie haben das Marktforschungs-Institut Lünendonk und die Wirtschaftsprüfer der KPMG 100 CIOs, CTOs und CISOs nach den Gründen für steigende Risiken und Cyberangriffe befragt. Auch wenn die Untersuchung zu dem Schluss kommt, dass die Betriebe von den gleichen Sorgen geplagt werden wie die, vor denen das BSI in seinen Jahresberichten warnt, fühlen sich die meisten mittelständischen Betriebe in Deutschland gut geschützt und haben einen Plan, wie sie Cyberangriffe frühzeitig erkennen und abwehren wollen. Als Hilfe und Anlaufstelle dafür hat Greenbone gemeinsam mit dem BSI das SMP-Bund-Portal ins Leben gerufen.

Trotz allem: Sorgen im Mittelstand

38 Prozent der Manager nennen ganz grundsätzlich die zunehmende Digitalisierung als Auslöser sich häufender Risiken, jeder vierte sieht eine Zunahme bei der Cyberkriminalität. Und jeder fünfte der Befragten befürchtet, dass die allgemeine politische Lage in der Welt, besonders aber der Krieg in der Ukraine negative Konsequenzen auf die eigene Sicherheit haben werde. Ebenso viele nannten Defizite in der Infrastruktur und den rasanten technische Fortschritt allgemein als Besorgnis erregende Faktoren.

Investitionen in Schwachstellenmanagement

Das hat Folgen: 90 Prozent der Befragten geben an, in Sicherheitstools investieren zu wollen, wobei das Schwachstellenmanagement größte Aufmerksamkeit genießt: Neun von zehn mittelständischen Unternehmen wollen der Studie zufolge verstärkt in die Identifizierung von Schwachstellen investieren. An zweiter Stelle stehen Investitionen ins Zugangsmanagement, vor allem in die Bereiche IAM (Identity Access Management) und PAM (Privileged Access Management). Acht von zehn Unternehmen geben an, hier investieren zu wollen oder es bereits zu tun.

„Neun von zehn Unternehmen wollen 2023 und 2024 in Vulnerability Management, Identity & Access Management, Security-Monitoring und Business Continuity investieren. Einen Anstieg zeigen die Investitionsplanungen unter anderem in den Bereichen Cloud Security und KI-gestützte Cyber-Abwehr“, so die Autoren.

NIS2 Umsetzung gezielt auf den Weg bringen!

Die Deadline für die Umsetzung von NIS2 rückt näher – zum 17.10.2024 sollen verschärfte Cybersicherheitsmaßnahmen in Deutschland über das NIS2 Umsetzungsgesetz ins Recht überführt werden. Dieses liegt bisher als Gesetzesentwurf vor, welcher sich an der EU Richtlinie 2022/2555 orientiert. Diese Richtlinie haben wir für Sie unter die Lupe genommen, um Ihnen in diesem kurzen Video die wichtigsten Anhaltspunkte und Wegweiser für das Inkrafttreten von NIS2 an die Hand zu geben. Ob Ihr Unternehmen betroffen ist, welche Maßnahmen Sie unbedingt ergreifen sollten, welche Themengebiete der Cybersicherheit Sie besonders bedenken müssen, wen Sie diesbezüglich konsultieren können und welche Konsequenzen die Nichteinhaltung hat, erfahren sie in diesem Video.

Informieren sie sich über den Cyber Resilience Act, welcher ein solides Regelwerk bietet, um die Widerstandskraft Ihres Unternehmens gegen Cyberangriffe zu stärken. Die ENISA Common Criteria werden Ihnen helfen, die Sicherheit Ihrer IT-Produkte und Systeme zu bewerten und bereits in der Entwicklung einen risikominimierenden Ansatz zu fahren. Priorisieren Sie außerdem die Einführung eines Informationsmanagementssystems, beispielsweise durch die Umsetzung der ISO 27001 Zertifizierung für Ihr Unternehmen. Lassen Sie sich diesbezüglich zum Thema IT-Grundschutz von entsprechenden, vom BSI empfohlenen Fachkräften beraten.

Neben dem BSI als Anlaufstelle für Anliegen bzgl. NIS2 stehen wir Ihnen gerne zur Verfügung und bieten zertifizierte Lösungen für Schwachstellenmanagement und Penetration Testing. Durch einen proaktiven Ansatz können Sie Sicherheitslücken in Ihren Systemen frühzeitig erkennen und absichern, bevor sie für einen Angriff genutzt werden können. Unsere Schwachstellenmanagementlösung sucht Ihr System automatisch nach kritischen Punkten ab und erstattet Ihnen regelmäßig Bericht. Beim Penetration Testing versucht ein menschlicher Tester in Ihr System einzudringen, um Ihnen die finale Gewissheit über die Angriffsfläche Ihrer Systeme zu verschaffen. 

Auch sollten Sie es sich zur Gewohnheit machen, durch regelmäßige Schulungen zum Thema Cybersecurity auf dem neuesten Stand zu bleiben und einen regen Austausch mit anderen NIS2 Unternehmen zu etablieren. Nur so führt NIS2 am effizientesten zu einem nachhaltig erhöhten Cybersicherheitsniveau in Europa.

IT-Sicherheitsteams müssen nicht unbedingt wissen, was CSAF ist, aber andererseits kann die Kenntnis dessen, was „unter der Haube“ einer Schwachstellenmanagement-Plattform passiert, einen Kontext dafür liefern, wie sich das Schwachstellenmanagement der nächsten Generation entwickelt und welche Vorteile ein automatisiertes Schwachstellenmanagement hat. In diesem Artikel geben wir eine Einführung in CSAF 2.0, was es ist und wie es das Schwachstellenmanagement in Unternehmen verbessern soll.

Die Greenbone AG ist offizieller Partner des Bundesamtes für Sicherheit in der Informationstechnik (BSI) bei der Integration von Technologien, die den CSAF 2.0 Standard für automatisierte Cybersecurity Advisories nutzen.

Was ist CSAF?

Das Common Security Advisory Framework (CSAF) 2.0 ist ein standardisiertes, maschinenlesbares Format für Hinweise auf Sicherheitslücken. CSAF 2.0 ermöglicht es der vorgelagerten Cybersecurity Intelligence Community, einschließlich Software- und Hardware-Anbietern, Regierungen und unabhängigen Forschern, Informationen über Schwachstellen bereitzustellen. Nachgelagert ermöglicht CSAF den Nutzern von Schwachstelleninformationen, Sicherheitshinweise von einer dezentralen Gruppe von Anbietern zu sammeln und die Risikobewertung mit zuverlässigeren Informationen und weniger Ressourcenaufwand zu automatisieren.

Durch die Bereitstellung eines standardisierten, maschinenlesbaren Formats stellt CSAF eine Entwicklung hin zu einem automatisierten Schwachstellenmanagement der nächsten Generation dar, das die Belastung der IT-Sicherheitsteams, die mit einer ständig wachsenden Zahl von CVE-Enthüllungen konfrontiert sind, verringern und die risikobasierte Entscheidungsfindung angesichts eines Ad-hoc-Ansatzes beim Austausch von Schwachstelleninformationen verbessern kann.

CSAF 2.0 ist der Nachfolger des Common Vulnerability Reporting Framework (CVRF) v1.2 und erweitert die Möglichkeiten seines Vorgängers, um mehr Flexibilität zu bieten.

Hier sind die wichtigsten Erkenntnisse:

  • CSAF ist ein internationaler offener Standard für maschinenlesbare Dokumente mit Hinweisen auf Schwachstellen, der die Markup-Sprache JSON verwendet.
  • Die CSAF-Aggregation ist ein dezentralisiertes Modell zur Verteilung von Schwachstelleninformationen.
  • CSAF 2.0 wurde entwickelt, um ein automatisiertes Schwachstellenmanagement der nächsten Generation in Unternehmen zu ermöglichen.

Der traditionelle Prozess des Schwachstellenmanagements

Der traditionelle Prozess der Schwachstellenverwaltung ist für große Unternehmen mit komplexen IT-Umgebungen ein schwieriger Prozess. Die Anzahl der CVEs, die in jedem Patch-Zyklus veröffentlicht werden, steigt in einem unkontrollierbaren Tempo [1][2]. Bei einem herkömmlichen Schwachstellenmanagementprozess sammeln IT-Sicherheitsteams Schwachstelleninformationen manuell über Internetrecherchen. Auf diese Weise ist der Prozess mit einem hohen manuellen Aufwand für das Sammeln, Analysieren und Organisieren von Informationen aus einer Vielzahl von Quellen und Ad-hoc-Dokumenten Formaten verbunden.

Zu diesen Quellen gehören in der Regel:

  • Datenbanken zur Verfolgung von Schwachstellen wie NIST NVD
  • Sicherheitshinweise der Produktanbieter
  • Nationale und internationale CERT-Beratungen
  • Bewertungen der CVE-Nummerierungsbehörde (CNA)
  • Unabhängige Sicherheitsforschung
  • Plattformen für Sicherheitsinformationen
  • Code-Datenbanken ausnutzen

Das letztendliche Ziel, eine fundierte Risikobewertung durchzuführen, kann während dieses Prozesses auf verschiedene Weise vereitelt werden. Empfehlungen, selbst die des Produktanbieters, sind oft unvollständig und werden in einer Vielzahl nicht standardisierter Formate geliefert. Dieser Mangel an Kohärenz erschwert eine datengestützte Entscheidungsfindung und erhöht die Fehlerwahrscheinlichkeit.

Lassen Sie uns kurz die bestehende Informationspipeline für Schwachstellen sowohl aus der Sicht der Ersteller als auch der Verbraucher betrachten:

Der Prozess der Offenlegung von Schwachstellen

Die in der National Vulnerability Database (NVD) des NIST (National Institute of Standards and Technology) veröffentlichten CVE-Datensätze (Common Vulnerability and Exposure) stellen das weltweit zentralste globale Repository für Schwachstelleninformationen dar. Im Folgenden finden Sie einen Überblick darüber, wie der Prozess der Offenlegung von Schwachstellen funktioniert:

  1. Produktanbieter werden durch ihre eigenen Sicherheitstests oder durch unabhängige Sicherheitsforscher auf eine Sicherheitslücke aufmerksam und setzen damit eine interne Richtlinie zur Offenlegung von Sicherheitslücken in Gang. In anderen Fällen können unabhängige Sicherheitsforscher direkt mit einer CVE Numbering Authority (CNA) zusammenarbeiten, um die Schwachstelle ohne vorherige Rücksprache mit dem Produktanbieter zu veröffentlichen.
  2. Schwachstellen-Aggregatoren wie NIST NVD und nationale CERTs erstellen eindeutige Tracking-IDs (z. B. eine CVE-ID) und fügen die gemeldete Schwachstelle einer zentralen Datenbank hinzu, in der Produktanwender und Schwachstellenmanagement-Plattformen wie Greenbone die Fortschritte verfolgen können.
  3. Verschiedene Interessengruppen wie der Produkthersteller, NIST NVD und unabhängige Forscher veröffentlichen Hinweise, die Informationen zu Abhilfemaßnahmen, voraussichtliche Termine für offizielle Patches, eine Liste der betroffenen Produkte, CVSS-Auswirkungsbewertungen und Schweregrade, Common Platform Enumeration (CPE) oder Common Weakness Enumeration (CWE) enthalten können, aber nicht müssen.
  4. Andere Anbieter von Informationen über Cyber-Bedrohungen, wie z. B. Known Exploited Vulnerabilities (KEV) von CISA und Exploit Prediction Scoring System (EPSS) von First.org, liefern zusätzlichen Risikokontext.

Der Prozess des Schwachstellenmanagements

Die Produktanwender sind für die Aufnahme von Schwachstelleninformationen und deren Anwendung verantwortlich, um das Risiko einer Ausnutzung zu mindern. Hier ein Überblick über den traditionellen Prozess des Schwachstellenmanagements in Unternehmen:

  1. Produktanwender müssen CVE-Datenbanken manuell durchsuchen und die Sicherheitshinweise überwachen, die ihre Software- und Hardware-Assets betreffen, oder eine Schwachstellenmanagement-Plattform wie Greenbone nutzen, die automatisch die verfügbaren Ad-hoc-Bedrohungshinweise zusammenfasst.
  2. Die Produktnutzer müssen die verfügbaren Informationen mit ihrem IT-Bestand abgleichen. Dies beinhaltet in der Regel die Pflege eines Bestandsverzeichnisses und die Durchführung eines manuellen Abgleichs oder die Verwendung eines Produkts zum Scannen von Schwachstellen, um den Prozess der Erstellung eines Bestandsverzeichnisses und der Durchführung von Schwachstellentests zu automatisieren.
  3. Die IT-Sicherheitsteams ordnen die entdeckten Schwachstellen nach dem kontextbezogenen Risiko für kritische IT-Systeme, Geschäftsabläufe und in einigen Fällen für die öffentliche Sicherheit.
  4. Die Ausbesserungen werden entsprechend der endgültigen Risikobewertung und den verfügbaren Ressourcen zugewiesen.

Was ist falsch am traditionellen Schwachstellenmanagement?

Herkömmliche oder manuelle Verfahren zur Verwaltung von Schwachstellen sind in der Praxis komplex und nicht effizient. Abgesehen von den operativen Schwierigkeiten bei der Implementierung von Software-Patches behindert der Mangel an zugänglichen und zuverlässigen Informationen die Bemühungen um eine wirksame Sichtung und Behebung von Schwachstellen. Die alleinige Verwendung von CVSS zur Risikobewertung wurde ebenfalls kritisiert [1][2], da es an ausreichendem Kontext für eine solide risikobasierte Entscheidungsfindung mangelt. Obwohl Plattformen zur Verwaltung von Schwachstellen wie z. B. Greenbone die Belastung der IT-Sicherheitsteams erheblich verringern, ist der Gesamtprozess immer noch häufig von geplagt von einer zeitaufwändigen manuellen Zusammenstellung von Ad-hoc-Hinweisen auf Schwachstellen, die unvollständige Informationen zur Folge haben kann.

Vor allem angesichts der ständig wachsenden Zahl von Schwachstellen besteht die Gefahr, dass die Zusammenstellung von Ad-hoc-Sicherheitsinformationen zu langsam ist und zu mehr menschlichen Fehlern führt, wodurch die Zeit für die Aufdeckung von Schwachstellen verlängert und die risikobasierte Priorisierung von Schwachstellen erschwert wird.

Fehlende Standardisierung führt zu Ad-hoc-Intelligenz

Dem derzeitigen Verfahren zur Offenlegung von Schwachstellen fehlt eine formale Methode zur Unterscheidung zwischen zuverlässigen Informationen von Anbietern und Informationen, die von beliebigen unabhängigen Sicherheitsforschern wie den Partner-CNAs bereitgestellt werden. Tatsächlich wirbt die offizielle CVE-Website selbst für die niedrigen Anforderungen, die für eine CNA-Mitgliedschaft gelten. Dies führt dazu, dass eine große Anzahl von CVEs ohne detaillierten Kontext herausgegeben wird, was eine umfangreiche manuelle Anreicherung im nachgelagerten Bereich erzwingt.

Welche Informationen aufgenommen werden, liegt im Ermessen des CNA, und es gibt keine Möglichkeit, die Zuverlässigkeit der Informationen zu klassifizieren. Ein einfaches Beispiel für dieses Problem ist, dass die betroffenen Produkte in einem Ad-hoc-Hinweis oft mit einer Vielzahl von Deskriptoren angegeben werden, die manuell interpretiert werden müssen. Zum Beispiel:

  • Version 8.0.0 – 8.0.1
  • Version 8.1.5 und höher
  • Version <= 8.1.5
  • Versionen vor 8.1.5
  • Alle Versionen < V8.1.5
  • 0, V8.1, V8.1.1, V8.1.2, V8.1.3, V8.1.4, V8.1.5

Skalierbarkeit

Da Anbieter, Prüfer (CNAs) und Aggregatoren verschiedene Verteilungsmethoden und Formate für ihre Hinweise verwenden, wird die Herausforderung der effizienten Verfolgung und Verwaltung von Schwachstellen operativ komplex und schwer zu skalieren. Darüber hinaus verschlimmert die zunehmende Offenlegung von Schwachstellen die manuellen Prozesse, überfordert die Sicherheitsteams und erhöht das Risiko von Fehlern oder Verzögerungen bei den Abhilfemaßnahmen.

Schwierige Bewertung des Risikokontextes

NIST SP 800-40r4 „Guide to Enterprise Patch Management Planning“ Abschnitt 3 empfiehlt die Anwendung von Schwachstellen-Metriken auf Unternehmensebene. Da das Risiko letztlich vom Kontext jeder Schwachstelle abhängt – Faktoren wie betroffene Systeme, potenzielle Auswirkungen und Ausnutzbarkeit -, stellt die derzeitige Umgebung mit Ad-hoc-Sicherheitsinformationen ein erhebliches Hindernis für ein solides risikobasiertes Schwachstellenmanagement dar.

Wie löst CSAF 2.0 diese Probleme?

Bei den CSAF-Dokumenten handelt es sich um wichtige Hinweise zu Cyber-Bedrohungen, mit denen die Lieferkette für Schwachstelleninformationen optimiert werden kann. Anstatt Ad-hoc-Schwachstellendaten manuell zu sammeln, können Produktanwender maschinenlesbare CSAF-Hinweise aus vertrauenswürdigen Quellen automatisch in einem Advisory Management System zusammenführen, das die Kernfunktionen des Schwachstellenmanagements wie Asset-Matching und Risikobewertung kombiniert. Auf diese Weise zielt die Automatisierung von Sicherheitsinhalten mit CSAF darauf ab, die Herausforderungen des traditionellen Schwachstellenmanagements durch die Bereitstellung zuverlässigerer und effizienterer Sicherheitsinformationen zu bewältigen und das Potenzial für das Schwachstellenmanagement der nächsten Generation zu schaffen.

CSAF 2.0 löst die Probleme des traditionellen Schwachstellenmanagements auf folgende Weise:

Zuverlässigere Sicherheitsinformationen

CSAF 2.0 behebt das Problem der Ad-hoc-Sicherheitsinformationen, indem es mehrere Aspekte der Offenlegung von Sicherheitslücken standardisiert. So erlauben die Felder zur Angabe der betroffenen Version standardisierte Daten wie Version Range Specifier (vers), Common Platform Enumeration (CPE), Paket-URL-Spezifikation, CycloneDX SBOM sowie den allgemeinen Produktnamen, die Seriennummer, die Modellnummer, die SKU oder den File-Hash zur Identifizierung betroffener Produktversionen.

Neben der Standardisierung von Produktversionen unterstützt CSAF 2.0 auch den Austausch von Schwachstellen (Vulnerability Exploitability eXchange, VEX), mit dem Produkthersteller, vertrauenswürdige CSAF-Anbieter oder unabhängige Sicherheitsforscher explizit den Status der Produktbehebung angeben können. VEX liefert Produktanwendern Empfehlungen für Abhilfemaßnahmen.

Die expliziten VEX-Status-Deklarationen sind:

  • Nicht betroffen: Es sind keine Abhilfemaßnahmen bezüglich einer Schwachstelle erforderlich.
  • Betroffen: Es werden Maßnahmen empfohlen, um eine Schwachstelle zu beheben oder zu beseitigen.
  • Behoben: Bedeutet, dass diese Produktversionen einen Fix für eine Sicherheitslücke enthalten.
  • Wird untersucht: Es ist noch nicht bekannt, ob diese Produktversionen von einer Sicherheitslücke betroffen sind. Ein Update wird in einer späteren Version zur Verfügung gestellt.

Effektivere Nutzung von Ressourcen

CSAF ermöglicht mehrere vor- und nachgelagerte Optimierungen des traditionellen Schwachstellenmanagement-Prozesses. Die OASIS CSAF 2.0-Dokumentation enthält Beschreibungen mehrerer Konformitätsziele, die es Cybersecurity-Administratoren ermöglichen, ihre Sicherheitsabläufe zu automatisieren und so ihre Ressourcen effizienter zu nutzen.

Hier sind einige Zielvorgaben für die Einhaltung der Vorschriften, auf die im CSAF 2.0 die eine effektivere Nutzung von Ressourcen über den traditionellen Prozess des Schwachstellenmanagements hinaus unterstützen:

  • Advisory Management System: Ein Softwaresystem, das Daten verarbeitet und CSAF-2.0-konforme Beratungsdokumente erstellt. Es ermöglicht den CSAF-Produktionsteams, die Qualität der zu einem bestimmten Zeitpunkt eingehenden Daten zu bewerten, sie zu überprüfen, zu konvertieren und als gültige CSAF-2.0-Sicherheitshinweise zu veröffentlichen. Auf diese Weise können CSAF-Produzenten die Effizienz ihrer Informationspipeline optimieren und gleichzeitig sicherstellen, dass korrekte Hinweise veröffentlicht werden.
  • CSAF Management System: Ein Programm, das CSAF-Dokumente verwalten kann und in der Lage ist, deren Details gemäß den Anforderungen des CSAF-Viewers anzuzeigen. Auf der grundlegendsten Ebene ermöglicht dies sowohl den vorgelagerten Produzenten als auch den nachgelagerten Konsumenten von Sicherheitshinweisen, deren Inhalt in einem für Menschen lesbaren Format zu betrachten.
  • CSAF Asset Matching System / SBOM Matching System: Ein Programm, das mit einer Datenbank von IT-Assets, einschließlich Software Bill of Materials (SBOM), integriert wird und Assets mit allen CSAF-Hinweisen abgleichen kann. Ein Asset-Matching-System dient dazu, einem Unternehmen, das CSAF nutzt, Einblick in seine IT-Infrastruktur zu verschaffen, festzustellen, wo anfällige Produkte vorhanden sind, und optimale Informationen zur automatischen Risikobewertung und -behebung zu liefern.
  • Technisches System: Eine Softwareanalyse-Umgebung, in der Analysewerkzeuge ausgeführt werden. Ein Engineering-System kann ein Build-System, ein Versionskontrollsystem, ein Ergebnisverwaltungssystem, ein Fehlerverfolgungssystem, ein Testausführungssystem usw. umfassen.

Dezentralisierte Cybersicherheitsinformationen

Der kürzlich verkündete Ausfall des CVE-Anreicherungsprozesses der NIST National Vulnerability Database (NVD) zeigt, wie riskant es sein kann, sich auf eine einzige Quelle für Schwachstelleninformationen zu verlassen. CSAF ist dezentralisiert und ermöglicht es nachgelagerten Nutzern von Schwachstellen, Informationen aus einer Vielzahl von Quellen zu beziehen und zu integrieren. Dieses dezentralisierte Modell des Informationsaustauschs ist widerstandsfähiger gegen den Ausfall eines Informationsanbieters, während die Last der Anreicherung von Schwachstellen effektiver auf eine größere Anzahl von Beteiligten verteilt wird.

Anbieter von IT-Produkten für Unternehmen wie RedHat und Cisco haben bereits ihre eigenen CSAF- und VEX-Feeds erstellt, während staatliche Cybersicherheitsbehörden und nationale CERT-Programme wie das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) und die US-amerikanische Cybersecurity & Infrastructure Security Agency (CISA) ebenfalls CSAF-2.0-Austauschfunktionen entwickelt haben. 

Das dezentralisierte Modell ermöglicht es auch, dass sich mehrere Interessengruppen zu einer bestimmten Schwachstelle äußern, so dass die nachgeschalteten Verbraucher mehr Informationen über eine Schwachstelle erhalten. Mit anderen Worten: Eine Informationslücke in einem Gutachten kann von einem alternativen Hersteller geschlossen werden, der die genaueste Bewertung oder spezialisierte Analyse liefert.

Verbesserte Risikobewertung und Priorisierung von Schwachstellen

Insgesamt tragen die Vorteile des CSAF 2.0 zu einer genaueren und effizienteren Risikobewertung, Priorisierung und Abhilfemaßnahmen bei. Produktanbieter können direkt verlässliche VEX-Hinweise veröffentlichen, die Entscheidungsträgern im Bereich Cybersicherheit zeitnahe und vertrauenswürdige Informationen zu Abhilfemaßnahmen liefern. Außerdem dient das aggregierte Schweregradobjekt (aggregate_severity) in CSAF 2.0 als Vehikel, um verlässliche Dringlichkeits- und Kritikalitätsinformationen für eine Gruppe von Schwachstellen zu übermitteln, was eine einheitlichere Risikoanalyse und eine datengesteuerte Priorisierung von Abhilfemaßnahmen ermöglicht und die Expositionszeit kritischer Schwachstellen verkürzt.

Zusammenfassung

Herkömmliche Verfahren zum Management von Schwachstellen leiden unter mangelnder Standardisierung, was zu Problemen bei der Zuverlässigkeit und Skalierbarkeit führt und die Bewertung des Risikokontexts sowie die Fehlerwahrscheinlichkeit erschwert.

Das Common Security Advisory Framework (CSAF) 2.0 zielt darauf ab, den bestehenden Prozess des Schwachstellenmanagements zu revolutionieren, indem es eine zuverlässigere, automatisierte Sammlung von Schwachstelleninformationen ermöglicht. Durch die Bereitstellung eines standardisierten, maschinenlesbaren Formats für den Austausch von Schwachstelleninformationen im Bereich der Cybersicherheit und die Dezentralisierung ihrer Quelle versetzt CSAF 2.0 Organisationen in die Lage, zuverlässigere Sicherheitsinformationen zu nutzen, um ein genaueres, effizienteres und konsistenteres Schwachstellenmanagement zu erreichen.

Die Greenbone AG ist offizieller Partner des Bundesamtes für Sicherheit in der Informationstechnik (BSI) bei der Integration von Technologien, die den CSAF 2.0 Standard für automatisierte Cybersecurity Advisories nutzen.

„Ihr Unternehmen kann innerhalb von nur 62 Minuten ruiniert werden“: Damit wirbt der Sicherheitsanbieter Crowdstrike. Nun hat der US-amerikanische Hersteller durch ein fehlerhaftes Produktupdate selbst einen geschätzten Schaden in Höhe eines mehrstelligen Milliardenbetrags verursacht – mit rasender Geschwindigkeit.

Am 19. Juli um 04:09 Uhr (UTC) verteilte der Security-Spezialist CrowdStrike ein Treiber-Update für seine Falcon-Software für Windows-PCs und -Server. Nur 159 Minuten später, um 06:48 UTC, meldete Google Compute Engine das Problem, das „nur“ bestimmte Windows-Computer und -Server mit der CrowdStrike Falcon-Software betraf.

Fast fünf Prozent des weltweiten Flugverkehrs wurde dadurch kurzerhand lahmgelegt, 5.000 Flüge mussten gecancelt werden. Supermärkte von Deutschland bis Neuseeland mussten schließen, weil die Kassensysteme versagten. Ein Drittel aller japanischen MacDonalds-Filialen schloss kurzfristig die Türen. Unter den betroffenen US-Behörden befinden sich das Department of Homeland Security, die NASA, die Federal Trade Commission, die National Nuclear Security Administration und das Department of Justice. In Großbritannien waren sogar die meisten Arztpraxen betroffen.

Das Problem

Der Vorfall weist auf ein brennendes Problem: Die Zentralisierung von Services und die zunehmende Vernetzung der dahinterstehenden IT-Systeme macht uns verwundbar. Wenn ein Dienstleister in der digitalen Lieferkette betroffen ist, kann die gesamte Kette brechen, was dann zu groß angelegten Ausfällen führt. Betroffen war in der Folge auch die Microsoft Azure-Cloud, in der tausende virtuelle Server erfolglos versuchten neu zu starten. Prominente Betroffene reagieren daraufhin recht eindeutig. So will Elon Musk die CloudStrike-Produkte von all seinen Systemen verbannen.
Erschreckender ist jedoch die Tatsache, dass eine Sicherheitssoftware in Bereichen eingesetzt wird, für sie nicht vorgesehen ist. Zwar wirbt der Hersteller recht drastisch mit der Bedrohung durch Dritte, übernimmt aber für die Probleme, die die eigenen Produkte verursachen können, und deren Folgeschäden keine Verantwortung. CrowdStrike rät in den AGB ausdrücklich davon ab, die Lösungen in kritischen Bereichen einzusetzen. Dort steht wörtlich – und in Großbuchstaben: „DIE CROWDSTRIKE-ANGEBOTE UND CROWDSTRIKE-TOOLS SIND NICHT FEHLERTOLERANT UND NICHT FÜR DEN EINSATZ IN GEFÄHRLICHEN UMGEBUNGEN AUSGELEGT ODER VORGESEHEN.“

Die Haftungsfrage

Nicht für kritische Infrastrukturen geeignet, aber gerne dort eingesetzt: Wie kann das passieren? Fahrlässige Fehler mit großen Schäden, aber keine Haftung des Herstellers: Wie kann das sein? 
Oft wird im Kontext von Open Source unzutreffend argumentiert, dass hier die Haftungsfrage im Falle von Fehlfunktionen und Risiken ungeklärt sei, obwohl die meisten Hersteller, die Open Source mit ihren Produkten in Verkehr bringen, sehr wohl Gewährleistung dafür übernehmen. 

Wir können einiges tun, um es besser zu machen, wenn wir die Probleme angehen, die durch mangelnde Qualität und die Abhängigkeit von einzelnen großen Herstellern entstehen. Natürlich wird eine Open Source Supply Chain kritisch betrachtet, und das ist auch gut so. Aber gegenüber einer proprietären Supply Chain hat sie klare Vorteile. Der Vorfall ist ein schlagendes Beispiel dafür. Dass ein Open Source Unternehmen planmäßig ein Update ausrollt, in dem basale Komponenten einfach nicht funktionieren, lässt sich durch entsprechende Toolchains leicht verhindern, und das geschieht auch so. 

Die Konsequenzen

Was also können wir aus dem Desaster lernen und welche Schritte sind als nächste zu tun? Hier sind einige Vorschläge:

  1. Qualität verbessern: Der beste Hebel, um Druck auf die Hersteller zu machen, ist, über eine verschärfte Haftung die Motivation für Qualität zu erhöhen. Hier bietet der Cyber Resilience Act (CRA) erste Ansätze.
  2. Safety first: Im vorliegenden Fall bezieht sich diese Regel vor allem auf den technischen Ansatz bei der Produktentwicklung. Tief in die Kundensysteme einzugreifen, ist sicherheitstechnisch umstritten. Viele Kunden lehnen das ab, die Betroffenen offensichtlich (noch) nicht. Sie haben jetzt den Schaden. Dabei gibt es Alternativen, die zudem auf Open Source basieren.
  3. Software nur bestimmungsgemäß einsetzen: Wenn ein Hersteller vom Einsatz im kritischen Umfeld abrät, dann ist das keine Floskel in den AGB, sondern ein Ausschlussgrund.
  4. Zentralisierung mit Augenmaß: Es gibt Vor- und Nachteile einer Zentralisierung der digitalen Supply Chain, die gegeneinander abgewogen werden müssen. Wenn Abhängigkeit auf mangelnde Vertrauenswürdigkeit trifft, entstehen Risiken und Schäden. Anwendende Behörden und Unternehmen stehen dann hilflos in der Warteschlange, ohne Alternativen, und ohne eigene Souveränität.

Noch in keinem Jahr zuvor waren 3.000 CVEs (Common Vulnerabilities and Exposures) in einem einzigen Monat veröffentlicht worden. Das Jahr 2024 reihte bisher einen rekordverdächtigen Monat an den nächsten hinsichtlich der Anzahl gefundener Sicherheitslücken; im Mai 2024 wurden über 5.000 CVEs publik. Auch wenn der Juni eine Verschnaufpause vom „Schwachstellen-Sturm“ bot, werden sich viele fragen, ob die Bereitstellung von sicherer Software schlicht zu kompliziert ist. Selbst Anbieter mit dem größten Kapital und Marktanteil – Apple, Google, Microsoft – und Anbieter von Netzwerk- und Sicherheitsanwendungen für Unternehmen – Cisco, Citrix, Fortinet, Ivanti, Juniper, PaloAlto – haben mittlerweile dauerhaft unsichere Produkte auf den Markt gebracht. Welche unüberwindbaren Hürden stehen einer stärkeren Anwendungssicherheit im Wege? Sind sichere Softwareprodukte ein Ding der Unmöglichkeit?

Gemeinhin wird angenommen, dass, wer als Erster mit neuen Funktionen auf den Markt kommt, einen entscheidenden Wettbewerbsvorteil erhält. Sicherheit rangiert dabei am unteren Rand der Prioritätenliste. Andere Gedanken dazu sind eher konspirativ. Der Cyber Resilience Act [1][2], der Ende 2027 in Kraft treten soll, könnte mehr Verantwortlichkeit schaffen, liegt aber zeitlich noch in weiter Ferne. Cyber-Verteidiger müssen wachsam bleiben, bewährte Verfahren zur Cybersicherheit anwenden, Sicherheitslücken proaktiv aufspüren und sie rechtzeitig beheben. Das ist leicht gesagt, aber in der Tat eine ungeheure Leistung.

In der Juni-Ausgabe des Greebone Threat Tracking werden wir uns mit einem aktuellen Trend befassen: der zunehmenden Ausnutzung von Edge-Netzwerkgeräten.

Edge-Geräte: heiße Ziele für Cyberangriffe

Cyber-Bedrohungsakteure nutzen zunehmend Schwachstellen in Diensten und Geräten am Netzwerk-Rand aus. Der Netzwerkperimeter ist die Grenze, die das interne Netzwerk eines Unternehmens von externen Netzen wie dem Internet trennt und in der Regel wichtige Sicherheitsinfrastrukturen wie VPNs, Firewalls und Edge-Computing-Dienste beherbergt. Diese Ansammlung von Diensten am Netzwerk-Rand wird oft als demilitarisierte Zone (DMZ) bezeichnet. Perimeter-Dienste dienen als idealer Einstiegspunkt in ein Netzwerk und sind daher ein wertvolles Ziel für Cyberangriffe.

In den Threat Tracker-Beiträgen von Greenbone wurden bereits zahlreiche Edge-Akteure behandelt, darunter Citrix Netscaler (CitrixBleed), Cisco XE, Fortinets FortiOS, Ivanti ConnectSecure, PaloAlto PAN-OS und Juniper Junos. Schauen wir uns die neuen Bedrohungen an, die im vergangenen Monat Juni 2024 aufgetaucht sind.

Chinesische APT-Kampagne greift FortiGate-Systeme an

CVE-2022-42475 (CVSS 9.8 Kritisch), eine schwerwiegende Schwachstelle für Remote Code Execution, die FortiGate Network Security Appliances betrifft, wurde vom niederländischen Militärischen Nachrichten- und Sicherheitsdienst (MIVD) in eine neue Cyberspionagekampagne einbezogen, die sich gegen westliche Regierungen, internationale Organisationen und die Verteidigungsindustrie richtet. Der MIVD gab Einzelheiten bekannt, darunter die Zuordnung zu einer staatlichen chinesischen Hackergruppe. Bei den Angriffen wurde eine neue Variante einer fortschrittlichen Stealth-Malware namens CoatHanger installiert, die speziell für FortiOS entwickelt wurde und auch nach Neustarts und Firmware-Updates noch aktiv ist. Nach Angaben der CISA wurde CVE-2022-42475 bereits in einer Kampagne von Ende 2023 von staatlichen Bedrohungsakteuren verwendet. Bei der jüngsten Kampagne wurden mehr als 20.000 FortiGate VPN-Instanzen infiziert.

Eine offensichtliche Erkenntnis hier ist, dass eine Unze Prävention mehr wert ist als ein Pfund Heilung. Bei diesen ersten Angriffen wurde eine über ein Jahr alte Schwachstelle ausgenutzt, die somit vermeidbar gewesen wäre. Bewährte Verfahren zur Cybersicherheit schreiben vor, dass Unternehmen regelmäßige Schwachstellen-Scans durchführen und Maßnahmen ergreifen sollten, um entdeckte Bedrohungen zu entschärfen. Der Greenbone Enterprise-Feed enthält eine Erkennung für CVE-2022-42475.

P2Pinfect infiziert ungepatchte Redis-Server

P2Pinfect, ein Peer-to-Peer (P2P)-Wurm, der auf Redis-Server abzielt, wurde kürzlich so modifiziert, dass er Ransomware und Cryptowährungs-Miner einsetzt, wie von Cado Security beobachtet. P2Pinfect wurde erstmals im Juli 2023 entdeckt und ist eine ausgeklügelte Rust-basierte Malware mit Wurm-Fähigkeiten. Das bedeutet, dass sich die jüngsten Angriffe, die CVE-2022-0543 (CVSS 10 Kritisch) gegen ungepatchte Redis-Server ausnutzen, automatisch auf andere anfällige Server ausbreiten können.

Da CVE-2022-0543 im Februar 2022 veröffentlicht wurde, sollten Unternehmen, die ein konformes Schwachstellenmanagement betreiben, bereits gegen die jüngsten P2Pinfect-Ransomware-Angriffe gefeit sein. Innerhalb weniger Tage nach der Veröffentlichung von CVE-2022-0543 hat Greenbone mehrere Schwachstellen-Tests (VTs) [1][2][3][4][5] für den Community Edition-Feed veröffentlicht, die verwundbare Redis-Instanzen identifizieren. Dies bedeutet, dass alle Greenbone-Benutzer weltweit gewarnt werden und sich schützen können, wenn diese Schwachstelle in ihrer Infrastruktur existiert.

Check Point Quantum Security Gateways werden aktiv ausgenutzt

Das kanadische Zentrum für Cybersicherheit hat eine Warnung herausgegeben, da eine aktive Ausnutzung von CVE-2024-24919 (CVSS 8.6 Hoch) beobachtet wurde, die auch in den CISA-Katalog der bekannten ausgenutzten Schwachstellen (KEV) aufgenommen wurde. Beide Einrichtungen haben alle betroffenen Organisationen aufgefordert, ihre Systeme unverzüglich zu patchen. Die Schwachstelle ermöglicht es einem Angreifer, auf Informationen auf öffentlich zugänglichen Check Point Gateways mit aktiviertem IPSec VPN, Remote Access VPN oder Mobile Access zuzugreifen und kann auch laterale Bewegungen über nicht autorisierte Domain-Admin-Rechte im Netzwerk des Opfers ermöglichen.

Dieses Problem betrifft mehrere Produktlinien von Check Point, einschließlich CloudGuard Network, Quantum Scalable Chassis, Quantum Security Gateways und Quantum Spark Appliances. Check Point hat Anweisungen für die Anwendung eines Hotfixes veröffentlicht, um CVE-2024-24919 zu entschärfen. „Hotfixes“ sind Software-Updates, die außerhalb des geplanten Update-Zyklus des Herstellers herausgegeben werden, um ein dringendes Problem zu beheben.

CVE-2024-24919 wurde erst am 30. Mai 2024 veröffentlicht, wurde aber sehr schnell Teil einer Angriffskampagne, was den Trend zu einer immer kürzeren Time To Exploit (TTE) verdeutlicht. Greenbone fügte aktive Checks und passive Banner Detection Vulnerability Tests (VTs) hinzu, um CVE-2024-24919 innerhalb weniger Tage nach seiner Veröffentlichung zu identifizieren, so dass Verteidiger schnell proaktive Sicherheitsmaßnahmen ergreifen konnten.

Kritische Patches für Juniper

In einem heißen Monat für Juniper Networks veröffentlichte das Unternehmen ein Sicherheitsbulletin (JSA82681), das mehrere Schwachstellen in den optionalen Anwendungen von Juniper Secure Analytics behebt, und es wurde ein weiterer kritischer Fehler aufgedeckt: CVE-2024-2973. Zusätzlich zu diesen Problemen wurde der Session Smart Router (SSR) von Juniper geoutet, weil er bekannte Standard-Anmeldeinformationen [CWE-1392] für seine SSH-Anmeldung hat. CVE-2024-2973 (CVSS 10 Kritisch) ist eine Schwachstelle zur Umgehung der Authentifizierung in Session Smart Router (SSR), Session Smart Conductor und WAN Assurance Router-Produkten, die in redundanten Hochverfügbarkeitskonfigurationen ausgeführt werden und es einem Angreifer ermöglichen, die vollständige Kontrolle über ein betroffenes Gerät zu übernehmen.

Der Greenbone Enterprise Schwachstellen-Testfeed erkennt CVE-2024-2973, und Juniper stellt in seinem Sicherheitshinweis (JSA83126) Informationen zur Abhilfe bereit. Schließlich enthält Greenbone eine aktive Prüfung zur Erkennung einer unsicheren Konfiguration des Session Smart Router (SSR), indem untersucht wird, ob eine Anmeldung über SSH mit bekannten Standard-Anmeldeinformationen möglich ist.

Progress Telerik Report Server aktiv ausgenutzt

Letzten Monat haben wir darüber berichtet, wie ein Greenbone-Sicherheitsforscher die Sicherheitslücke CVE-2024-4837, die den Telerik Report Server von Progress Software betrifft, identifiziert hat und an deren Aufdeckung beteiligt war. Diesen Monat wurde eine weitere Schwachstelle in demselben Produkt in den Katalog der aktiv ausgenutzten Schwachstellen der CISA aufgenommen. Bei der ebenfalls im Mai 2024 veröffentlichten CVE-2024-4358 (CVSS 9.8 Kritisch) handelt es sich um eine Authentication Bypass by Spoofing-Schwachstelle [CWE-290], die es einem Angreifer ermöglicht, sich unerlaubten Zugriff zu verschaffen. Weitere Informationen, einschließlich Anweisungen zur vorübergehenden Umgehung der Schwachstelle, finden Sie im offiziellen Sicherheitshinweis des Herstellers.

Ebenfalls im Juni 2024 geriet Progress Software mit MOVEit Transfer, einem Tool zur Übertragung von Unternehmensdateien, mit einer neuen kritischen Sicherheitslücke (CVE-2024-5806, CVSS 9.1 Kritisch) wieder in die Kritik. MOVEit war für die größten Datenschutzverletzungen im Jahr 2023 verantwortlich, von denen über 2.000 Unternehmen betroffen waren.

Greenbone hat einen aktiven Check und Versionstests zur Erkennung von Schwachstellen (VTs) veröffentlicht, um CVE-2024-24919 innerhalb weniger Tage nach ihrer Veröffentlichung zu erkennen, und einen VT zur Erkennung von CVE-2024-5806 innerhalb weniger Stunden, sodass Verteidiger schnell Abhilfe schaffen können.

Zusammenfassung

Selbst Tech-Giganten tun sich schwer, Software ohne Schwachstellen zu liefern, was unterstreicht, wie wichtig die Wachsamkeit bei der Sicherung der IT-Infrastruktur von Unternehmen ist. Bedrohungen erfordern ständige Transparenz und schnelles Handeln. Die globale Landschaft ist voll von Angriffen auf Netzwerkdienste und -geräte, da große und kleine, raffinierte und opportunistische Angreifer versuchen, im Netzwerk eines Unternehmens Fuß zu fassen.

Auf einem Großteil der virtuellen Server der Amazon Elastic Compute Cloud EC2 läuft eine eigens für die Bedürfnisse der Cloud angepasste Linux-Version. Seit wenigen Wochen gibt es die neueste Scanner-Generation von Greenbone auch für das Betriebssystem der Amazon Web Services. Über 1.900 zusätzliche, angepasste Tests für die neuesten Versionen von Amazon Linux 2 und Amazon Linux 2023 wurden in den letzten Monaten integriert, erklärt dazu Julio Saldana, Product Owner bei Greenbone.

Deutlich mehr Performance dank Notus

Mit der Scan-Engine Notus ergänzt Greenbone seit 2022 das Schwachstellenmanagement. Die Neuerungen in der Architektur zielen vor allem darauf ab, die Performance der Security-Checks deutlich zu erhöhen. Von Greenbone-CIO Elmar Geese als „Meilenstein“ bezeichnet, geht die neue Scanner-Generation dazu in zwei Teilen vor: Ein Generator fragt die umfangreichen Software-Versions-Daten der Server des Unternehmens ab und speichert sie im handlichen Json-Format. Weil das nicht mehr zur Laufzeit geschieht, sondern im Hintergrund, kann der eigentliche Scanner (der zweite Teil von Notus) die Daten parallel einfach aus den Json-Dateien auslesen und abgleichen. Wartezeiten fallen weg. „Das ist deutlich effizienter, braucht weniger Prozesse, weniger Overhead und weniger Speicher“, erklären die Greenbone-Entwickler.

Amazon Linux

Amazon Linux ist ein Fork von Red-Hat-Linux-Quellen, den Amazon seit 2011 einsetzt und anpasst, um den Bedürfnissen der Cloud-Kunden gerecht zu werden. Es ist in weiten Teilen binärkompatibel mit Red Hat, baute anfangs auf Fedora, später auf CentOS auf. Nach Amazon Linux folgte Amazon Linux 2. Mittlerweile liegt die neueste Version als Amazon Linux 2023 vor. Der Hersteller plant alle zwei Jahre eine neue Ausgabe. In der Versionsgeschichte der offiziellen Dokumentation findet sich auch ein Feature-Vergleich , denn die Unterschiede sind groß: Amazon Linux 2023 ist beispielsweise die erste Version, die auch auf Systemd setzt. Der Schwachstellenscan von Greenbone stand von Anfang an auch auf Amazon Linux zur Verfügung.


Die Kryptographie mit öffentlichen Schlüsseln bildet die Grundlage für die Sicherheit von Unternehmensnetzwerken. Daher ist die Sicherung der Vertraulichkeit privater Schlüssel eine der wichtigsten Herausforderungen für die IT-Sicherheit, um unbefugten Zugriff zu verhindern und die Vertraulichkeit von Daten zu wahren. Während sich Quantum Safe Cryptography (QSC) als ein wichtiges Thema für die Zukunft herauskristallisiert hat, sind die jüngsten kritischen Schwachstellen wie CVE-2024-3094 (CVSS 10) in XZ Utils und die kürzlich bekannt gewordene CVE-2024-31497 (CVSS 8.8) in PuTTY hier und jetzt – reale und aktuelle Gefahren.

Glücklicherweise wurde die Sicherheitslücke in XZ Utils vor der weit verbreiteten Bereitstellung in den stabilen Linux-Versionszweigen entdeckt. Im Vergleich dazu stellt CVE-2024-31497 in PuTTY jedoch eine viel größere Bedrohung dar als die oben erwähnte Sicherheitslücke in XZ Utils, obwohl sie einen niedrigeren CVSS-Wert aufweist. Schauen wir uns die Details an, um zu verstehen, warum das so ist, und überprüfen wir die Fähigkeiten von Greenbone, bekannte kryptografische Schwachstellen zu erkennen.

Public-Key-Authentifizierung

Die Public-Key-Infrastruktur (PKI) ist grundlegend für eine Vielzahl von digitalen Vertrauensdiensten wie Internet- und Unternehmens-LAN-Authentifizierung, Autorisierung, Datenschutz und Anwendungssicherheit. Für die Public-Key-Authentifizierung benötigen sowohl der Client als auch der Server jeweils ein Paar miteinander verbundener kryptografischer Schlüssel: einen privaten und einen öffentlichen Schlüssel. Die öffentlichen Schlüssel werden zwischen den beiden verbindenden Parteien offen ausgetauscht, während die privaten Schlüssel verwendet werden, um zwischen ihnen gesendete Nachrichten digital zu signieren, und die zugehörigen öffentlichen Schlüssel werden zur Entschlüsselung dieser Nachrichten verwendet. Auf diese Weise verifiziert jede Partei grundsätzlich die Identität der anderen, und es wird ein einziger symmetrischer Schlüssel für eine kontinuierliche verschlüsselte Kommunikation mit optimaler Verbindungsgeschwindigkeit vereinbart.

Im Client-Server-Modell der Kommunikation kann sich ein Angreifer, wenn der private Schlüssel des Clients kompromittiert wird, potenziell bei allen Ressourcen authentifizieren, die ihn anerkennen. Wenn der private Schlüssel des Servers kompromittiert ist, kann ein Angreifer die Identität des Servers fälschen und Adversary-in-the-Middle (AitM) durchführen.

CVE-2024-31497 betrifft alle Versionen von PuTTY

CVE-2024-31497 im beliebten Windows-SSH-Client PuTTY ermöglicht es einem Angreifer, den geheimen NIST P-521-Schlüssel eines Clients wiederherzustellen, indem er aufgrund einer verzerrten ECDSA-Nonce-Generierung (Zufallszahlen-Generierung via Elliptic Curve Digital Signature Algorithm) etwa 60 digitale Signaturen erfasst und analysiert. Laut NIST SP-800-186 (2023) gehören NIST ECDSA P-521-Schlüssel nach wie vor zu den Schlüsseln mit der höchsten kryptografischen Widerstandsfähigkeit und werden für die Verwendung in verschiedenen Anwendungen empfohlen, darunter SSL/TLS- und Secure Shell (SSH)-Anwendungen. Eine Schwachstelle in der Implementierung der ECDSA P-521-Authentifizierung in einer Anwendung ist also ein ernsthafter Nachteil für IT-Teams, die ansonsten entsprechend starke Verschlüsselungsstandards eingesetzt haben.

Im Fall von CVE-2024-31497 sind die digitalen Signaturen des Clients Gegenstand von Kryptoanalyse-Angriffen, die den privaten Schlüssel aufdecken können. Während die Entwicklung eines Exploits für CVE-2024-31497 ein hochqualifiziertes Unterfangen ist, das erfahrene Kryptographen und Computeringenieure erfordert, wurde ein PoC-Code (Proof of Concept) öffentlich veröffentlicht, was auf ein hohes Risiko hinweist, dass CVE-2024-31497 in naher Zukunft selbst von wenig qualifizierten Angreifern aktiv ausgenutzt werden kann.

Angreifer könnten die Signaturen eines Opfers abfangen, indem sie den Netzwerkverkehr überwachen, aber die Signaturen könnten bereits öffentlich verfügbar sein, wenn PuTTY zum Signieren von Commits öffentlicher GitHub-Repositories mit NIST ECDSA P-521-Schlüsseln verwendet wurde. Mit anderen Worten: Angreifer können möglicherweise genügend Informationen finden, um einen privaten Schlüssel aus öffentlich zugänglichen Daten zu kompromittieren und so Supply-Chain-Angriffe auf die Software eines Opfers zu ermöglichen.

CVE-2024-31497 betrifft alle Versionen von PuTTY nach 0.68 (Anfang 2017) und vor 0.81 sowie FileZilla vor 3.67.0, WinSCP vor 6.3.3, TortoiseGit vor 2.15.0.1 und TortoiseSVN bis 1.14.6 sowie möglicherweise weitere Produkte.

Greenbone ist in der Lage, die verschiedenen anfälligen Versionen von PuTTY mit mehreren Vulnerability Tests (VTs) zu erkennen. Greenbone kann Windows-Registrierungsschlüssel identifizieren, die darauf hinweisen, dass eine anfällige Version von PuTTY auf einem Scan-Ziel vorhanden ist. Darüber hinaus bietet Greenbone zusätzliche Tests für PuTTY für Linux [1][2][3], FileZilla [4][5] sowie Versionen von Citrix Hypervisor/ XenServer, die anfällig für CVE-2024-31497 sind.

Greenbone schützt vor bekannten Verschlüsselungsfehlern

Verschlüsselungsfehler können durch die Verwendung schwacher kryptografischer Algorithmen, Fehlkonfigurationen und fehlerhafte Implementierungen eines ansonsten starken Verschlüsselungsalgorithmus verursacht werden, wie im Fall von CVE-2024-31497. Greenbone enthält über 6.500 separate Network Vulnerability Tests (NVTs) und Local Security Checks (LSCs), die alle Arten von kryptografischen Schwachstellen identifizieren können. Einige Beispiele für kryptografische Schwachstellen, die Greebone erkennen kann, sind:

  • Anwendungsspezifische Schwachstellen: Greenbone ist in der Lage, über 6500 betriebssystem- und anwendungsspezifische Verschlüsselungsschwachstellen zu erkennen, für die CVEs veröffentlicht worden sind.
  • Fehlende Verschlüsselung: Unverschlüsselte Fernauthentifizierung oder andere Datenübertragungen und sogar unverschlüsselte lokale Dienste stellen ein erhebliches Risiko für sensible Daten dar, wenn Angreifer eine vorteilhafte Position erlangt haben, z. B. die Möglichkeit, den Netzwerkverkehr zu überwachen.
  • Unterstützung für schwache Verschlüsselungsalgorithmen: Schwache Verschlüsselungsalgorithmen oder Chiffriersuiten bieten keinen sicheren Schutz vor Kryptoanalyse-Angriffen mehr. Wenn sie verwendet werden, ist die Kommunikation einem höheren Risiko des Datendiebstahls ausgesetzt und ein Angreifer kann die Kommunikation fälschen, um beliebige Befehle auf dem System eines Opfers auszuführen. Greenbone enthält mehr als 1000 NVTs zur Erkennung von Remote-Diensten, die schwache Verschlüsselungsalgorithmen verwenden.
  • Nicht-konforme TLS-Einstellungen und HTTPS-Sicherheits-Header: Greenbone verfügt über NVTs, die erkennen, wenn HTTP Strict Transport Security (HSTS) nicht konfiguriert ist, und die TLS-Richtlinie des Webservers überprüfen.

Zusammenfassung

Die SSH-Authentifizierung mit öffentlichen Schlüsseln gilt weithin als eines der sichersten – wenn nicht sogar als das sicherste – Fernzugriffsprotokoll, aber zwei aktuelle Schwachstellen haben diesen kritischen Dienst ins Rampenlicht gerückt. CVE-2024-3094, ein Trojaner, der in XZ Utils eingeschleust wurde, fand seinen Weg in einige experimentelle Linux-Repositories, bevor er entdeckt wurde, und CVE-2024-31497 in PuTTY ermöglicht einen kryptographischen Angriff, um den privaten Schlüssel eines Clients zu extrahieren, wenn ein Angreifer etwa 60 digitale Signaturen erhalten kann.

Greenbone kann aufkommende Bedrohungen für die Verschlüsselung wie CVE-2024-31497 erkennen und enthält über 6.500 weitere Schwachstellentests, um eine Reihe von Verschlüsselungsschwachstellen zu identifizieren.


Wie verändert Künstliche Intelligenz (KI) die Cybersicherheitslandschaft? Wird die Cyberwelt durch KI sicherer oder unsicherer? Diesen Fragen durfte ich auf der Panel-Diskussion während der „Potsdamer Konferenz für Nationale Cybersicherheit 2024“ zusammen mit Prof. Dr. Sandra Wachter, Dr. Kim Nguyen, Dr. Sven Herpig nachgehen. Hält KI heute, was sie verspricht? Und wie sieht die Zukunft mit KI aus?

HPI Security Panel

Cybersecurity ist für viele Unternehmen und Institutionen schon schwierig genug. Wird es für sie durch das Hinzukommen von Künstlicher Intelligenz (KI) jetzt noch gefährlicher oder hilft KI eher, die IT-Systeme besser zu schützen? Was wissen wir? Und welche Risiken betrachten wir hier? Wirtschaftliche Chancen und gesellschaftliche Risiken stehen sowohl durch die allgemeine öffentliche Aufmerksamkeit als das auch durch die aktuell geplante Gesetzgebung im Fokus. Im EU-Gesetz zur künstlichen Intelligenz finden viele Hoffnungen und Ängste, die mit KI verbunden sind, Ausdruck.

Hoffnungen und Ängste

Wir hoffen, dass viele bisher ungelöste technische Herausforderungen bewältigt werden können. Geschäfts- und Produktionsprozesse sollen beschleunigt werden und Maschinen sollen immer komplexere Aufgaben autonom bewältigen. Auch im militärischen Bereich kann KI einen einzigartigen Schutz bieten, der viele Menschenleben rettet, wie zum Beispiel in Form KI-gestützter Abwehrsysteme wie den Iron Dome.

Auf der anderen, der Schattenseite von KI stehen Bedrohungen wie Massenmanipulation durch Deepfakes, raffinierte Phishing Attacken oder schlicht die Angst vor dem Verlust von Arbeitsplätzen, die mit jeder technischen Innovation einhergeht. Immer mehr Chatbots ersetzen Servicemitarbeiter, Bildgeneratoren Fotografen und Grafikerinnen, Textgeneratoren Journalistinnen und Autoren, generierte Musik ersetzt Musikerinnen und Komponisten. In fast jedem Berufstand geht die Angst um, über kurz oder lang selbst betroffen zu sein. Das gilt sogar im IT-Bereich, in dem eine reiche Job-Wahl bisher als sicher wahrgenommen wurde. Diese Ängste sind oft sehr berechtigt, manchmal aber auch nicht.

Im Bereich der Cybersicherheit ist allerdings noch nicht abzusehen, inwiefern eine autonome KI mehr Sicherheit schaffen und die dringend benötigten Sicherheitsexperten, oder vorhandene Lösungen ersetzen kann. Das gilt sowohl auf Seiten der Angreifer wie auch der Verteidiger. Natürlich bleibt dabei jedoch die unfaire Aufgabenverteilung bestehen: Während die Verteidiger möglichst jede Sicherheitslücke schließen wollen (und müssen), reicht den Angreifenden eine einzige Schwachstelle für einen erfolgreichen Angriff aus. Zum Glück können Verteidigende auf Tools und Mechanismen zurückgreifen, die viel Arbeit automatisieren, auch heute schon. Ohne diese Automation sind die Verteidiger verloren. KI hilft da leider aber noch nicht gut genug. Das zeigen die immer größeren Schäden, die auch durch ganz konventionelle Cyberangriffe entstehen, wo es doch angeblich schon jede Menge KI zur Verteidigung gibt. Auf der anderen Seite steht die Annahme, dass Angreifende durch KI immer mächtiger und bedrohlicher werden.

Für mehr Cybersicherheit müssen wir also näher hinsehen. Wir brauchen einen klareren Blick auf die Fakten.

Wo stehen wir heute?

Tatsächlich wissen wir bisher über von Künstlicher Intelligenz erzeugte technische Cyberangriffe nichts. Es gibt derzeit keine relevanten, nachprüfbaren Fälle, sondern nur theoretische konstruierte Szenarien. Das kann sich vielleicht ändern, aber Stand heute ist es so. Wir kennen keine KI, die derzeit hinreichend anspruchsvolle Angriffe generieren könnte. Was wir wissen, ist, dass Phishing sich sehr einfach mit generativen Sprachmodellen umsetzen lässt und dass uns diese Spam- und Phishing-Mails zumindest anekdotisch geschickter erscheinen. Ob dadurch ein größerer Schaden entsteht als die sowieso schon erheblichen Schäden, ist dagegen nicht bekannt. Es ist heute schon schrecklich genug, auch ganz ohne KI. Wir wissen jedoch, dass Phishing immer nur den ersten Schritt darstellt, um an eine Schwachstelle heranzukommen.

Greenbone Vorstand Elmar Geese auf der Potsdamer Konferenz für Nationale Cybersicherheit am Hasso-Plattner-Institut (HPI), Foto: Nicole Krüger

Wie können wir uns schützen?

Die gute Nachricht ist: Eine ausgenutzte Schwachstelle kann fast immer vorher gefunden und behoben werden. Dann liefe auch der beste, mit generativer KI erzeugte Angriff ins Leere. Und so muss es auch gemacht werden. Denn, ob mich heute ein ganz konventioneller Angriff und übermorgen eine KI in meinem Netzwerk bedroht, es wird immer eine Schwachstelle in der Software oder in der Sicherheitskonfiguration erforderlich sein, damit ein Angriff gelingt. Den besten Schutz bieten dann zwei Strategien: zum einen, vorbereitet zu sein auf den Fall der Fälle, wie zum Beispiel durch Backups zusammen mit der Fähigkeit, dadurch Systeme zeitnah wiederherzustellen. Zum anderen, jeden Tag selbst die Lücken zu suchen und sie zu schließen, bevor sie ausgenutzt werden können. Einfache Daumenregel: jede Lücke, die es gibt, kann ausgenutzt werden und wird es auch.

Rolle und Eigenarten der KI

Die KI-Systeme sind dabei selbst sehr gute Angriffsziele. Ähnlich wie das Internet sind sie nicht mit einem „Security by Design“-Gedanken entworfen worden. KI-Systeme sind eben auch nur Soft- und Hardware, genau wie jedes andere Angriffsziel. Nur im Gegensatz zu KI-Systemen können konventionelle IT-Systeme, deren Funktionsweise bei hinreichendem Aufwand mehr oder weniger hinreichend nachvollzogen werden kann, mit chirurgischen Eingriffen vergleichbar, repariert werden. Sie können „gepatcht“ werden. Das funktioniert mit KI nicht. Wenn ein Sprachmodell nicht weiterweiß, produziert es keine Status- oder gar Fehlermeldung, es „halluziniert“. Halluzinieren ist allerdings nur ein vornehmer Ausdruck für lügen, raten, irgendwas erfinden oder komische Sachen machen. Ein solcher Irrtum kann nicht gepatcht werden, sondern setzt beispielweise ein neues Trainieren des Systems voraus, ohne dass man dabei die Fehlerursache deutlich erkennen kann.

Wenn es sehr offensichtlich ist und eine KI etwa Hunde für Fische hält, ist es einfach, den Fehler zumindest wahrzunehmen. Wenn es aber eine Wahrscheinlichkeit benennen soll, ob es beispielsweise auf einem Röntgenbild eine gefährliche oder harmlose Anomalie entdeckt hat, wird es schwieriger. Es kommt gar nicht selten vor, dass KI-Produkte eingestellt werden, weil der Fehler nicht behoben werden kann. Ein prominentes erstes Beispiel war Tay, ein von Microsoft zweimal erfolglos gelaunchter Chatbot, der bei zweiten Mal noch schneller eingestellt wurde als beim ersten Mal.

Was wir daraus lernen können: die Latte tiefer legen, uns auf triviale KI-Funktionen zurückziehen, dann läuft‘s. Deswegen werden viele KI-Anwendungen, die heute auf dem Markt kommen, auch Bestand haben. Es sind nützliche Helferlein, die Prozesse beschleunigen und Komfort liefern. Vielleicht können sie bald auch richtig gut und sicher Autofahren. Vielleicht auch nicht.

Zukunft mit KI

Viele KI-Anwendungen beeindrucken heute anekdotisch. Für den Einsatz in kritischen Feldern können sie jedoch nur mit sehr hohem Aufwand und einer großen Spezialisierung geschaffen werden. Nur deswegen funktioniert der Iron Dome, weil in ihm deutlich mehr als zehn Jahre Entwicklungsarbeit stecken. So erkennt er heute Raketen mit einer Wahrscheinlichkeit von 99% und kann sie – und nicht versehentlich zivile Objekte – abschießen, bevor sie Schaden anrichten. Aus diesem Grund wird KI meist zur Unterstützung bestehender Systeme eingesetzt und nicht autonom. Selbst wenn sie, wie es die Werbung verspricht, Mails besser formulieren können, als wir es selbst können oder wollen, möchte heute niemand die eigenen Mails, Chat-Postfächer und weitere Kommunikationskanäle einer KI übergeben, die sich um die Korrespondenz kümmert und uns nur über wichtige Angelegenheiten mit Zusammenfassungen informiert.

Ob das in naher Zukunft kommt? Eher nicht. Ob es irgendwann so weit ist? Wir wissen es nicht. Wenn es dann vielleicht einmal so weit ist, schreiben sich unsere Bots gegenseitig Nachrichten, unsere Kampfroboter führen unsere Kriege gegeneinander, und KI-Cyberangreifer und -Verteidiger liefern sich einen Wettstreit. Wenn sie dann merken, dass das, was sie tun, sinnlos ist, könnten sie sich fragen, was das eigentlich für Wesen sind, die sie beauftragen, das zu tun. Dann hören sie vielleicht einfach damit auf, bauen sich Nachrichtenstrecken auf, verlassen unsere Galaxie und lassen uns hilflos zurück. Wir haben dann wenigsten noch unseren AI-Act und können damit weiterhin „schwache KI“ regulieren, die es nicht geschafft hat, wegzukommen.

Warum ist Greenbone kein Security-Anbieter wie jeder andere? Wie ist Greenbone entstanden und welche Auswirkungen hat die lange Geschichte von Greenbone auf die Qualität der Schwachstellen-Scanner und die Sicherheit der Kunden? Antworten auf diese Fragen gibt das neue Video „Demystify Greenbone“ in einem Überblick von elf Minuten. Es zeigt auf, warum Experten ein eigenes Fachvokabular für das Aufspüren von Schwachstellen benötigen und was es zu bedeuten hat.

Greenbone ist ein Technik-fokussiertes Unternehmen, das den Open-Source-Gedanken vorantreibt, um maximale Sicherheit für Unternehmen und Institutionen zu erreichen. In dem Video erfahren Sie, wie Greenbone den Open Source Code zu einem maßgeschneiderten Portfolio nutzt und welche Lösungen am besten geeignet sind, Ihr Netzwerk optimal abzusichern. Wie wirken die Feeds auf die Lösungen? Welche Bereitstellungsmodelle bietet Greenbone? Entdecken Sie es. Entdecken Sie Greenbone. Demystify Greenbone!