Schlagwortarchiv für: Vulnerability Management

Joseph Lee

Greenbone erkennt CVE-2025-0994: Aktiv ausgenutzte Schwachstelle in Trimble Cityworks

Trimble Cityworks, eine Software für das Enterprise Asset Management (EAM) und die Verwaltung öffentlicher Gebäude, wird aktiv angegriffen. Die Kampagne begann als unbekannte Schwachstelle (Zero Day), wird aber jetzt als CVE-2025-0994 mit einem CVSS-Wert von 8.6 geführt. Es handelt sich um einen Fehler bei der Deserialisierung [CWE-502], der einem authentifizierten Angreifer ermöglichen könnte, beliebigen Code aus der Ferne auszuführen (Remote Code Execution; RCE). Greenbone enthält eine Erkennung für CVE-2025-0994 im Enterprise Feed.

Die aktive Ausnutzung von CVE-2025-0994 ist eine reale und gegenwärtige Gefahr. Trimble hat eine Erklärung veröffentlicht, in der die Angriffe auf das Produkt bestätigt werden. Dank der Transparenz des Herstellers hat die CISA (Cybersecurity and Infrastructure Security Agency) CVE-2025-0994 in ihren Katalog der bekannten ausgenutzten Schwachstellen (KEV) aufgenommen und einen ICS-Hinweis sowie ein CSAF-2.0-Dokument veröffentlicht. CSAF 2.0-Advisorys sind maschinenlesbare Dokumente mit Hinweisen auf Schwachstellen für den dezentralen Austausch von Cybersicherheitsinformationen.

Obwohl viele Medienberichte und einige Plattformen, die Bedrohungsinformationen sammeln, darauf hinweisen, dass es einen öffentlichen Proof-of-Concept (PoC) gibt, ist das einzige Suchergebnis auf GitHub lediglich ein Versionserkennungstest. Das bedeutet, dass es unwahrscheinlich ist, dass wenig qualifizierte Hacker leicht an Angriffen teilnehmen können. Die Fehlinformationen sind vermutlich auf schlecht konzipierte Algorithmen in Verbindung mit mangelnder menschlicher Kontrolle vor der Veröffentlichung von Bedrohungsdaten zurückzuführen.

Wer ist durch CVE-2025-0994 gefährdet?

Trimble Cityworks wurde vor allem für Kommunalverwaltungen und Anbieter kritischer Infrastrukturen wie Wasser- und Abwassersysteme, Energie, Verkehrssysteme, staatliche Industrieanlagen und Kommunikationsagenturen entwickelt und wird von ihnen genutzt. Cityworks erweitert geografische Informationssysteme (GIS) durch die Integration von Lösungen für die Verwaltung von Anlagen und öffentlichen Arbeiten direkt in Esri ArcGIS. Die Software soll Organisationen bei der Verwaltung der Infrastruktur, der Planung von Wartungsarbeiten und der Verbesserung der betrieblichen Effizienz helfen. Neben der CISA haben auch mehrere andere Regierungsbehörden Warnungen zu dieser Sicherheitslücke herausgegeben, darunter die US-Umweltschutzbehörde (EPA), das kanadische Zentrum für Cybersicherheit und der Bundesstaat New York.

Eigenen Angabe zufolge bediente Trimble Cityworks im Jahr 2019 über 700 Kunden in Nordamerika, Europa, Australien und dem Nahen Osten. Während spezielle Zahlen für Kommunalverwaltungen in den USA, Kanada und der EU nicht öffentlich bekannt gegeben werden, zeigen eine Suche auf Shodan und eine Censys-Karte jeweils nur etwa 100 öffentlich zugängliche Instanzen von Cityworks. Es wird jedoch davon ausgegangen, dass die Anwendung eine hohe Akzeptanz bei Kommunalverwaltungen und Versorgungsunternehmen hat. Wenn CVE-2025-0994 öffentlich zugänglich ist, könnte ein Angreifer einen ersten Zugang erhalten [T1190]. Für Angreifer, die bereits Fuß gefasst haben, ist die Schwachstelle eine Gelegenheit für laterale Bewegungen [TA0008] und stellt eine leichte Beute für Insider-Angriffe dar.

Technische Beschreibung von CVE-2025-0994

CVE-2025-0994 ist eine Schwachstelle in der Deserialisierung [CWE-502], die in Versionen von Trimble Cityworks vor 15.8.9 und Cityworks mit Office Companion vor 23.10 gefunden wurde. Sie entsteht durch die unsachgemäße Deserialisierung von nicht vertrauenswürdigen serialisierten Daten, die es einem authentifizierten Angreifer ermöglicht, beliebigen Code aus der Ferne auf dem Microsoft Internet Information Services (IIS) Webserver des Ziels auszuführen.

Die Serialisierung ist ein Prozess, bei dem Softwarecode oder Objekte kodiert werden, um zwischen Anwendungen übertragen und dann in dem von einer Programmiersprache verwendete Originalformat rekonstruiert zu werden. Wenn Trimble Cityworks serialisierte Objekte verarbeitet, werden nicht vertrauenswürdige Eingaben nicht ordnungsgemäß validiert oder bereinigt. Dieser Fehler ermöglicht es einem Angreifer mit authentifiziertem Zugriff, speziell gestaltete serialisierte Objekte zu senden, die eine beliebige Codeausführung auf dem zugrunde liegenden IIS-Server auslösen können. Die Deserialisierung von Daten aus nicht authentifizierten Quellen scheint an sich schon ein signifikanter Designfehler zu sein, aber das Versäumnis, serialisierte Daten ordnungsgemäß zu bereinigen, ist eine besondere Unsicherheit.

Konsequenzen der Ausnutzung von CVE-2025-0994 könnten sein:

  • Unbefugter Zugriff auf sensible Daten
  • Unterbrechung der Dienste für kritische Infrastruktursysteme
  • Mögliche vollständige Kompromittierung des betroffenen IIS-Webservers

Abhilfe gegen CVE-2025-0994 in Trimble Cityworks

Trimble hat gepatchte Versionen von Cityworks veröffentlicht, die die Schwachstelle in der Deserialisierung beheben. Diese Patches umfassen Cityworks 15.8.9 und Cityworks 23.10. On-premise-Anwender müssen sofort auf die gepatchte Version aktualisieren, während Kunden von Cityworks Online (CWOL) diese Updates automatisch erhalten.

Trimble wies darauf hin, dass bei einigen Vor-Ort-Installationen IIS mit überprivilegierten Identitätsberechtigungen ausgeführt wird, was die Angriffsfläche vergrößert. IIS sollte weder auf lokaler noch auf Domänenebene über administrative Berechtigungen verfügen. Befolgen Sie die Anweisungen von Trimble in den neuesten Cityworks-Versionshinweisen, um die IIS-Identitätskonfigurationen richtig anzupassen.

Empfohlene Aktionen für On-premises-Anwender von Trimble Cityworks:

  • Aktualisieren Sie die Cityworks 15.x-Versionen auf 15.8.9 und die 23.x-Versionen auf 23.10.
  • Prüfen Sie die IIS-Identitätsberechtigungen, um sicherzustellen, dass sie mit dem Prinzip der geringsten Rechte übereinstimmen.
  • Beschränken Sie die Stammkonfiguration des Anhangsverzeichnisses auf Ordner, die nur Anhänge enthalten.
  • Verwenden Sie eine Firewall, um den Zugriff auf den IIS-Server nur auf vertrauenswürdige interne Systeme zu beschränken.
  • Verwenden Sie ein VPN, um den Fernzugriff auf Cityworks zu ermöglichen, anstatt den Dienst öffentlich zugänglich zu machen.

Zusammenfassung

CVE-2025-0994 stellt ein ernsthaftes Sicherheitsrisiko für Trimble Cityworks-Benutzer dar, die größtenteils aus Behörden und kritischen Infrastrukturumgebungen stammen. Da bereits eine aktive Ausnutzung beobachtet wurde, müssen Organisationen sofortige Patches und Sicherheitsmaßnahmen implementieren, um das Risiko zu minimieren. Greenbone hat die Erkennung von CVE-2025-0994 zum Enterprise Feed hinzugefügt, sodass Kunden einen Überblick über ihre Gefährdungslage erhalten.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

November 2024 Threat Report: Schwachstellenmanagement wird entscheidend

Vielleicht tritt die Welt gerade in eine neue Phase der Cyber-Sicherheit und in ein neues technologisches Paradigma ein. Sogenannte „branchenführende“ Unternehmenssoftware erweist sich immer wieder als anfällig, da wöchentlich neue kritische Schwachstellen aufgedeckt werden und Beweise für eine aktive Ausnutzung vorliegen. Schicke neue Funktionen halten uns auf Trab, aber in Anbetracht des Risikos der sich schnell entwickelnden Technologien ist es wichtig, mit Unternehmen zusammenzuarbeiten, die die Dinge einfach halten, sich auf ihre Kernkompetenzen konzentrieren und es richtig machen.

In der November-Ausgabe des Greenbone Threat Report untersuchen wir einige kürzlich veröffentlichte Berichte des BSI und der CISA, um zu sehen, wie die staatlichen Cybersicherheitsbehörden die aktuelle Bedrohungslage einschätzen, und berichten anschließend über die dringendsten und am häufigsten ausgenutzten Schwachstellen dieses Monats. In Anbetracht des hohen Risikos, das die aktuelle Bedrohungslage im Bereich der Cybersicherheit darstellt, ist es wichtig, den Grundlagen der IT-Sicherheit – und dem Softwaredesign – Priorität einzuräumen, um zu vermeiden, dass der Betrieb auf einem sprichwörtlichen Kartenhaus aufgebaut wird.

BSI veröffentlicht IT-Sicherheitsbericht für 2024

Die Politik in der EU entwickelt sich als Reaktion auf die zunehmenden Cyberrisiken rasch weiter. Cybersicherheit für alle erfordert grenzüberschreitende Zusammenarbeit auf vielen Ebenen. Laut dem zusammenfassenden Bericht von 2024 konzentriert sich das Bundesamt für Sicherheit in der Informationstechnik (BSI) auf die Harmonisierung nationaler Spezifikationen mit bewährten Verfahren im Bereich der Cybersicherheit und prüft gleichzeitig die wirtschaftliche und technische Durchführbarkeit neuer Maßnahmen. Die als „Europäisierung der Cybersicherheit“ bezeichnete europäische Normung und die Zusammenarbeit Deutschlands mit den drei europäischen Normungsorganisationen CEN, CENELEC und ETSI fördern einen risikobasierten Ansatz zur Durchsetzung bewährter Sicherheitsverfahren bei kritischen Infrastrukturen und Anbietern praktisch aller digitalen Produkte.

Im Rahmen des Cyber Resilience Act (CRA) wird jeder Mitgliedstaat befugt sein, nicht konforme Produkte vom Markt zu nehmen und Anbieter zu bestrafen, die gegen die Vorschriften verstoßen. „Wichtige Produkte“ (Klasse I) wie Passwortmanager und Router müssen harmonisierten europäischen Normen (hEN) entsprechen. Bezüglich NIS2 hat das BSI im Jahr 2024 bisher 726 Meldungen mit 141 Vorfällen aus kritischen Infrastruktureinrichtungen erhalten. Darunter fallen Sektoren wie Gesundheitswesen, Energie, Wasser, Lebensmittel, IT und Telekommunikation, Finanz- und Versicherungsdienstleistungen und andere mehr.

Das BSI beobachtete auch einen allgemeinen Anstieg neuer Malware-Varianten und einen Anstieg von 256 % bei Malware, die Windows ausnutzt. Die Lektüre des vollständigen Berichts gibt Aufschluss über Trends im Verhalten der Angreifer, wie z. B. die Zunahme von BYOVD-Angriffen (Bring Your Own Vulnerable Driver), mit denen EDR-Sicherheitsprodukte deaktiviert werden können. Hinzu kommen die anhaltenden Bemühungen, Botnetze zu versenken, die zu Massenangriffen in großem Umfang beitragen, und die wachsende Fragmentierung der Cyberkriminalität in Gruppen, die den ersten Zugang vermitteln sowie die zweite Stufe der Ransomware.

Was bedeuten diese Beobachtungen für Greenbone und Schwachstellenmanagement im Allgemeinen? Ein effektives Schwachstellenmanagement und die Prüfung der Einhaltung von Vorschriften sind zwar nur ein Teil des Puzzles der Cybersicherheit im Unternehmen, aber das Schließen bekannter Sicherheitslücken und die regelmäßige Bestätigung starker Sicherheitskonfigurationen ist eine wichtige Kernkompetenz, die alle Unternehmen beherrschen müssen.

CISAs Top-Schwachstellen für 2023 geben Aufschluss

Der Bericht „2023 Top Routinely Exploited Vulnerabilities“ der Cybersecurity & Infrastructure Security Agency (CISA) stellt fest, dass die Zahl der ausgenutzten Zero-Day-Schwachstellen im Vergleich zu 2022 zugenommen hat und dass diese bei Angriffen auf hochrangige Ziele verwendet werden. Neben den Zero-Days listet der Bericht die 47 häufigsten CVEs (Common Vulnerabilities and Exposures) auf, die von Angreifern ausgenutzt werden. Netzwerke (40 %) und Produktivitätssoftware (34 %) bilden die überwiegende Mehrheit der hochgradig gefährdeten CVEs. Auch bei der Art der am häufigsten ausgenutzten Softwarefehler ist ein deutlicher Trend zu erkennen. Der falsche Umgang mit nicht vertrauenswürdigen Eingaben macht 38 % der am häufigsten angegriffenen Softwarefehler aus, während die unsachgemäße Authentifizierung und Autorisierung 34 % ausmachen. Leider sind die Überlegungen zur Absicherung dieser Schwachstellen elementar und werden im Grundkurs für Anwendungsdesign behandelt. Außerdem befinden sich 90 % der am häufigsten ausgenutzten Schwachstellen in proprietären Closed-Source-Produkten, was darauf hindeutet, dass Cyberkriminelle nicht durch Reverse-Engineering-Schranken behindert werden.

Während die EU motiviert ist, die Sicherheit durch gesetzliche Vorschriften zu verbessern, plädiert die CISA weiterhin dafür, dass Softwarehersteller die Grundsätze des „Secure by Design“ während der Entwicklungsphasen anwenden. Sie schlagen auch vor, dass mehr Pay-to-Hack Bug Bounty-Programme Anreize für ethische Sicherheitsforscher schaffen könnten.

Kritische Lücken in Palo Alto-Produkten

Am 8. November 2024 veröffentlichte Palo Alto Networks einen Sicherheitshinweis, der eine Zero-Day-RCE-Schwachstelle (Remote-Code-Execution) im Betriebssystem PAN-OS aufdeckte. Der Hinweis wurde bald aktualisiert, nachdem klar war, dass die Schwachstelle aktiv ausgenutzt wurde. Im Folgenden finden Sie eine Zusammenfassung der neuen Sicherheitslücken in Palo Alto-Produkten, die im November 2024 bekannt wurden.

  • CVE-2024-0012 (CVSS 9.8 Hoch): Eine Umgehung der Authentifizierung in PAN-OS ermöglicht den unauthentifizierten Zugriff auf Administratorenrechte. Angreifer können administrative Aktionen durchführen, die Konfiguration manipulieren oder andere authentifizierte Schwachstellen zur Rechteerweiterung wie CVE-2024-9474 ausnutzen.
  • CVE-2024-9474 (CVSS 7.2 Hoch): Eine Schwachstelle in der PAN-OS-Software ermöglicht es PAN-OS-Administratoren, Aktionen auf der Firewall mit Root-Rechten auszuführen.
  • CVE-2024-9463 (CVSS 7.5 Hoch): Eine Command-Injection-Schwachstelle in Expedition ermöglicht es einem nicht authentifizierten Angreifer, beliebige OS-Befehle als Root auszuführen. Dies gestattet die unbefugte Offenlegung von Benutzernamen, Klartextpasswörtern, Gerätekonfigurationen und Geräte-API-Schlüsseln von PAN-OS Firewalls.
  • CVE-2024-9465 (CVSS 9.1 Hoch): Eine SQL-Injektion könnte es einem nicht authentifizierten Angreifer ermöglichen, Inhalte der Expedition-Datenbank, wie Passwort-Hashes, Benutzernamen, Gerätekonfigurationen und Geräte-API-Schlüssel, offenzulegen oder beliebige Dateien auf dem Expedition-System zu erstellen und zu lesen.
  • CVE-2024-5910 (CVSS 9.8 Hoch): Eine fehlende Authentifizierung für eine kritische Funktion in Expedition kann dazu führen, dass ein Administratorkonto aus der Ferne übernommen wird und Konfigurationsgeheimnisse, Anmeldeinformationen und andere Daten offengelegt werden.

Greenbone kann alle neuen CVEs erkennen, die in Palo Alto-Geräten im November 2024 veröffentlicht wurden. Idealerweise stellen Sie sicher, dass die Netzwerkverwaltungsschnittstellen nicht über das öffentliche Internet zugänglich sind, und verwenden Sie am besten eine Firewall-Konfiguration, um den Zugriff von nicht autorisierten internen Netzwerk-Endpunkten zu verhindern.

Kritische US-Telekommunikationsinfrastrukturen angegriffen

Die jüngsten Sicherheitsverletzungen bei großen US-Telekommunikationsanbietern sind eine deutliche Warnung für alle Unternehmen, die komplexe IT-Infrastrukturen in großem Umfang betreiben. Die Schuld wird chinesischen Hackergruppen zugeschrieben, die Berichten zufolge den Zugang zum Abhören von Anrufen politischer Beamter in den USA, zu SMS-Nachrichten und zu abgefangenen mobilen Metadaten nutzten. Laut Adam Meyers, Vice President of Intelligence bei CrowdStrike, umgehen die Bedrohungsakteure die Notwendigkeit, in die einzelnen Netzwerke ihrer Ziele einzudringen, indem sie die Telekommunikationsnetze direkt angreifen. Angesichts der großen Zahl kritischer Schwachstellen in Produkten von US-Netzwerkanbietern wie Palo Alto Networks, Oracle, Cisco, Citrix, Ivanti, Broadcom, Microsoft und Fortinet würde eine intensivere Prüfung der Anwendungssicherheit das Risiko für deren Hauptkunden – US-Unternehmen im In- und Ausland und andere große globale Firmen – erheblich verringern.

Liminal Panda, Salt Typhoon, Volt Typhoon und andere sind dafür bekannt, dass sie „Schatten-IT“ angreifen – ältere mobile Protokolle, von denen IT-Administratoren nicht wissen, dass sie noch aktiv sind oder aktiv überwacht werden. Raffinierte, hochqualifizierte APT-Akteure sind äußerst anpassungsfähig und verfügen über die Ressourcen, um Malware für praktisch jede bekannte Schwachstelle zu entwickeln, die ausgenutzt werden kann, sowie aktiv Zero-Day-Exploits zu entwickeln, die noch unbekannt sind.

5 Schwachstellen bei der Eskalation von Privilegien in Ubuntus Needrestart

Eine Schwachstelle in Ubuntus Needrestart-Funktion könnte es einem nicht privilegierten lokalen Angreifer ermöglichen, Shell-Befehle als Root-Benutzer auszuführen. Die neuen CVEs betreffen alle Versionen von Needrestart, die bis 2014 zurückreichen. Needrestart bestimmt, ob Prozesse neu gestartet werden müssen, nachdem systemweite Pakete aktualisiert wurden, um einen vollständigen Neustart zu vermeiden, und wird durch den apt-Package-Manager aufgerufen. Die Schwachstelle wird verursacht, wenn nicht vertrauenswürdige Daten wie Umgebungsvariablen nicht sauber an die Module::ScanDeps-Bibliothek übergeben werden, die als root ausgeführt wird. Diese Umgebungsvariablen auf Benutzerebene können auch die Python- und Ruby-Interpreter während der Ausführung von Needrestart beeinflussen.

Die Schwachstellen können durch ein Update von Needstart auf eine gepatchte Version oder durch Deaktivieren der Interpreter-Scan-Funktion durch Setzen von $nrconf{interpscan} = 0 in der Konfigurationsdatei needrestart.conf entschärft werden. Greenbone enthält eine Erkennung für alle CVEs, die mit der Needrestart-Funktion zusammenhängen [1][2][3].

Hier eine kurze Beschreibung der neu veröffentlichten CVEs:

  • CVE-2024-11003 (CVSS 7.8 Hoch): Ungeschützte Daten, die an die Module::ScanDeps-Bibliothek übergeben werden, könnten einem lokalen Angreifer erlauben, beliebige Shell-Befehle auszuführen.
  • CVE-2024-10224 (CVSS 5.3): Ungeprüfte Eingaben, die an die Module::ScanDeps-Bibliothek übergeben werden, erlauben die Ausführung beliebiger Shell-Befehle durch das Öffnen einer „problematischen Leitung“ (z.B. durch die Übergabe von „commands|“ als Dateiname) oder durch die Übergabe beliebiger Strings an eval().
  • CVE-2024-48990 (CVSS 7.8 Hoch): Ermöglicht lokalen Angreifern die Ausführung von beliebigem Code als Root, indem sie Needrestart über die Umgebungsvariable PYTHONPATH dazu bringen, den Python-Interpreter auszuführen.
  • CVE-2024-48991 (CVSS 7.8 Hoch): Ermöglicht lokalen Angreifern, beliebigen Code als Root auszuführen, indem sie eine Wettlaufsituation nutzen und Needrestart auf einen gefälschten Python-Interpreter statt auf den echten Python-Interpreter des Systems verweisen.
  • CVE-2024-48992 (CVSS 7.8 Hoch): Ermöglicht lokalen Angreifern die Ausführung von beliebigem Code als Root, indem sie Needrestart über die Umgebungsvariable RUBYLIB dazu bringen, den Ruby-Interpreter auszuführen.

Kritische RCE-Schwachstellen in VMware vCenter: Aller guten Dinge sind drei?

VMware hat mit der Herausforderung zu kämpfen, kritische Sicherheitslücken in den vCenter-Serverprodukten effektiv zu schließen. Broadcom, zu dem VMware gehört, veröffentlichte im September zunächst Patches für zwei wichtige Schwachstellen in vCenter: CVE-2024-38812 (CVSS 9.8 Hoch), die als Heap-Overflow-Schwachstelle in der Implementierung des DCERPC-Protokolls eingestuft wird, und CVE-2024-38813 (CVSS 9.8 Hoch), die eine Ausweitung der Berechtigungen über speziell gestaltete Netzwerkpakete ermöglicht.

Diese ersten Patches waren jedoch unzureichend, sodass im Oktober eine zweite Runde von Patches durchgeführt wurde. Trotz dieser Bemühungen wurde im November bestätigt, dass die CVEs immer noch anfällig waren und in freier Wildbahn ausgenutzt wurden. vCenter ist aufgrund seiner weiten Verbreitung ein Hauptziel für Angreifer, und die Situation verdeutlicht die anhaltenden Sicherheitsprobleme. VMware-Anwender sollten umgehend Patches anwenden. Wenn CVEs wie diese in VMware vCenter mit neuen Informationen aktualisiert werden, überprüft das Greenbone-Team von Sicherheitsanalysten die Änderungen und aktualisiert unsere Schwachstellentests entsprechend.

Helldown Ransomware gegen Zyxel und Kunden

Im November 2024 wurde eine Linux-Variante der Helldown-Ransomware-Nutzlast entdeckt. Es ist bekannt, dass Helldown das IPSec-VPN von Zyxel-Geräten über CVE-2024-42057 (CVSS 8.1 High) für den Erstzugang ausnutzt. Nachdem er Fuß gefasst hat, stiehlt Helldown alle zugänglichen Anmeldedaten und erstellt neue Benutzer und VPN-Tunnel, um die Persistenz zu gewährleisten. Die neue Variante zielt auf virtuelle VMware ESXi-Maschinen ab, um deren Daten zu exfiltrieren und zu verschlüsseln. Diese Technik wird auch von anderen Ransomware-Gruppen wie der Play-Gang verwendet.

Die Ransomware-Gruppe Helldown gilt als aufkommende Bedrohung und hat seit August über 30 Opfer gefordert, darunter auch Zyxel selbst. Der Hersteller hat einen Artikel veröffentlicht, in dem die Angriffe bestätigt und Anweisungen zur Schadensbegrenzung gegeben werden, und der Security-Anbieter Truesec hat bekannte Helldown-TTPs (Tactics Techniques and Procedures) aus seinen Reaktionen veröffentlicht. Greenbone ist in der Lage, alle Schwachstellen zu erkennen, von denen bekannt ist, dass sie mit Helldown-Ransomware-Angriffen in Verbindung stehen, einschließlich CVE-2024-42057 in Zyxel-Produkten [1][2][3] sowie bekannter Software-Schwachstellen, die von anderen Ransomware-Bedrohungsakteuren genutzt werden, um anfänglichen Zugriff zu erlangen, Privilegien zu erweitern und sich seitlich zu hochwertigen Zielen im Netzwerk des Opfers zu bewegen.

Zusammenfassung

Von den Fortschritten in der EU-Politik bis hin zu den Erkenntnissen der CISA über ausgenutzte Schwachstellen: Die Notwendigkeit besserer Softwareentwicklungspraktiken, eines effektiven Schwachstellenmanagements und einer umfassenden Verteidigung ist offensichtlich. Die Ereignisse des Monats November, wie die Zero-Days von Palo Alto, die Needrestart-Schwachstellen von Ubuntu und die anhaltenden Herausforderungen von VMware vCenter, unterstreichen die Bedeutung einer rechtzeitigen Überwachung und des Patchens kritischer Infrastrukturen. Neue Bedrohungen wie Helldown Ransomware verstärken die Notwendigkeit proaktiver Verteidigungsstrategien. Greenbone unterstützt Unternehmen auch weiterhin, indem es kritische Schwachstellen aufspürt, verwertbare Erkenntnisse liefert und sich für einen sicherheitsorientierten Ansatz mit grundlegenden Best Practices für die IT-Sicherheit einsetzt.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht
/von
Joseph Lee

CSAF 2.0: Stakeholder und Rollen

Das Common Security Advisory Framework (CSAF) reguliert die Bereitstellung von maschinenlesbaren Sicherheitshinweisen nach einem standardisierten Prozess, damit sie automatisiert ausgetauscht werden können. Greenbone arbeitet kontinuierlich an der Integration von Technologien, die den CSAF 2.0-Standard für die automatisierte Bereitstellung von Cybersecurity-Informationen nutzen. Eine Einführung in CSAF 2.0 und wie es das Schwachstellenmanagement der nächsten Generation unterstützt, finden Sie in einem früheren Blogbeitrag.

Zu Beginn des Jahres 2024 hat der Ausfall der NIST National Vulnerabilities Database (NVD) den Fluss kritischer Cybersicherheitsinformationen an nachgeschaltete Verbraucher unterbrochen. Dies macht das dezentralisierte CSAF 2.0-Modell zunehmend wichtiger für Cybersicherheitsinformationen, um die Widerstandsfähigkeit gegenüber einem einzelnen Ausfallpunkt zu erhöhen. Wer CSAF 2.0 einführt, kommt einem zuverlässigeren Ökosystem für Cybersicherheitsinformationen einen Schritt näher.

Inhaltsverzeichnis

1. Zusammenfassung
2. Wer sind die CSAF-Stakeholder?
2.1. Rollen im CSAF 2.0-Prozess
2.1.1. CSAF 2.0 Ausstellende Parteien
2.1.1.1. Die Rolle des CSAF-Publishers
2.1.1.2. Die Rolle des CSAF-Providers
2.1.1.3. Die Rolle des Trusted Providers in CSAF
2.1.2. CSAF 2.0 Datenaggregatoren
2.1.2.1. Die Rolle des CSAF-Listers
2.1.2.2. Die Rolle des CSAF-Aggregators
3. Fazit

1. Zusammenfassung

Dieser Artikel stellt die verschiedenen Akteure und Rollen dar, die in der CSAF-2.0-Spezifikation definiert sind. Die Rollen regeln die Mechanismen zur Erstellung, Verbreitung und Nutzung von Sicherheitshinweisen innerhalb des CSAF-2.0-Ökosystems. Das Verständnis, wer die Stakeholder von CSAF sind und welche standardisierten Rollen das CSAF 2.0-Framework definiert, hilft Security-Verantwortlichen klarer zu sehen, wie CSAF funktioniert, ob es für ihre Organisation von Nutzen sein kann und wie CSAF 2.0 zu implementieren ist.

2. Wer sind die CSAF-Stakeholder?

Auf höchster Ebene hat der CSAF-Prozess zwei primäre Stakeholder-Gruppen: vorgelagerte Produzenten, die Cybersicherheitshinweise im CSAF-2.0-Dokumentenformat erstellen und bereitstellen, und nachgelagerte Konsumenten (Endnutzer), die die Hinweise konsumieren und die darin enthaltenen Sicherheitsinformationen anwenden.

Bei den vorgelagerten Herstellern handelt es sich in der Regel um Anbieter von Softwareprodukten (wie Cisco, Red Hat und Oracle), die für die Aufrechterhaltung der Sicherheit ihrer digitalen Produkte und die Bereitstellung öffentlich zugänglicher Informationen über Schwachstellen verantwortlich sind. Zu den vorgelagerten Akteuren gehören auch unabhängige Sicherheitsforscher und öffentliche Einrichtungen, die als Quelle für Cybersicherheitsinformationen dienen, wie die US Cybersecurity Intelligence and Security Agency (CISA) und das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI).

Zu den nachgelagerten Verbrauchern gehören private Instanzen, die ihre eigene Cybersicherheit verwalten, staatliche CERT-Agenturen, die mit dem Schutz der nationalen IT-Infrastruktur betraut sind, und Managed Security Service Provider (MSSP), die die Cybersicherheit von Kunden überwachen und managen. Die in den CSAF 2.0-Dokumenten enthaltenen Informationen werden von IT-Sicherheitsteams genutzt, um Schwachstellen in ihrer Infrastruktur zu identifizieren und Abhilfemaßnahmen zu planen, und von Führungskräften, um zu beurteilen, wie IT-Risiken den Betrieb beeinträchtigen.

Schaubild zu den CSAF 2.0 Stakeholdern: Links die Upstream Producers wie Softwareanbieter, Behörden und Forscher, rechts die Downstream Consumers wie CERTs, SOC-Teams und Sicherheitsplattformen – verbunden durch das CSAF 2.0 Advisory Format.

Der CSAF-2.0-Standard definiert spezifische Rollen für vorgelagerte Hersteller, die ihre Beteiligung an der Erstellung und Verbreitung von Hinweis-Dokumenten beschreiben. Diese offiziell definierten Rollen sehen wie folgt aus:

2.1. Rollen im CSAF 2.0-Prozess

CSAF 2.0-Rollen werden in Abschnitt 7.2 definiert. Sie werden in zwei verschiedene Gruppen unterteilt: Ausstellende Parteien („Issuer“) und Datenaggregatoren („Aggregatoren“). Erstere sind direkt an der Erstellung von Beratungsdokumenten beteiligt. Letztere sammeln diese Dokumente und verteilen sie an die Endnutzer, um die Automatisierung für die Verbraucher zu unterstützen. Eine einzelne Organisation kann sowohl die Rolle des Ausstellers als auch die des Aggregators übernehmen, diese Funktionen sollten jedoch als separate Einheiten betrieben werden. Selbstverständlich müssen Organisationen, die als vorgelagerte Produzenten agieren, auch ihre eigene Cybersicherheit gewährleisten. Daher können sie auch nachgelagerte Verbraucher sein, die CSAF-2.0-Dokumente aufnehmen, um ihre eigenen Aktivitäten im Bereich des Schwachstellenmanagements zu unterstützen.

Diagramm der CSAF 2.0 Upstream-Rollen mit den Gruppen Issuing Parties (Producer, Provider, Trusted Provider) und Data Aggregators (Lister, Aggregator), die Cybersicherheitshinweise an Downstream Consumers weiterleiten.

Die spezifischen Verantwortlichkeiten der CSAF-2.0-Issuer und Datenaggregatoren stellen sich wie folgt dar:

2.1.1. CSAF 2.0 Ausstellende Parteien

Issuers sind die Quelle der CSAF-2.0-Cybersecurity-Hinweise. Sie sind jedoch nicht für die Übermittlung der Dokumente an die Endnutzer verantwortlich. Sie müssen angeben, wenn sie nicht wollen, dass ihre Hinweise von Datenaggregatoren aufgelistet oder gespiegelt werden. Außerdem können CSAF 2.0-Aussteller auch als Datenaggregatoren fungieren.

Hier sind die einzelnen Unterrollen innerhalb der Gruppe der ausstellenden Parteien:

2.1.1.1. Die Rolle des CSAF-Publishers

Publisher sind in der Regel Organisationen, die Hinweise nur im Namen ihrer eigenen digitalen Produkte entdecken und weitergeben. Sie müssen die Anforderungen 1 bis 4 in Abschnitt 7.1 der CSAF 2.0-Spezifikation erfüllen. Dies bedeutet, dass sie strukturierte Dateien mit gültiger Syntax und Inhalten herausgeben, die den in Abschnitt 5.1 beschriebenen CSAF 2.0-Dateinamenskonventionen entsprechen, und sicherstellen, dass die Dateien nur über verschlüsselte TLS-Verbindungen verfügbar sind. Außerdem müssen sie alle als TLP:WHITE klassifizierten Hinweise öffentlich zugänglich machen.

Alle Publisher müssen über ein öffentlich zugängliches provider-metadata.json-Dokument verfügen, das grundlegende Informationen über die Organisation, ihren CSAF-2.0-Rollenstatus und Links zu einem öffentlichen OpenPGP-Schlüssel enthält, mit dem das provider-metadata.json-Dokument digital signiert wird, um seine Integrität zu verifizieren. Diese Informationen werden von Softwareanwendungen verwendet, die die Hinweise der Publisher für Endbenutzer anzeigen.

2.1.1.2. Die Rolle des CSAF-Providers

Provider stellen CSAF-2.0-Dokumente für die breitere Gemeinschaft zur Verfügung. Zusätzlich zur Erfüllung der gleichen Anforderungen wie ein Publisher muss ein Provider seine provider-metadata.json.-Datei nach einer standardisierten Methode bereitstellen (mindestens eine der Anforderungen 8 bis 10 aus Abschnitt 7.1), eine standardisierte Verteilung für seine Hinweise verwenden und technische Kontrollen implementieren, um den Zugang zu allen Hinweisdokumenten mit dem Status TLP:AMBER oder TLP:RED zu beschränken.

Provider müssen außerdem wählen, ob sie die Dokumente auf der Grundlage eines Verzeichnisses oder auf der Grundlage von ROLIE verteilen wollen. Einfach ausgedrückt, stellt die verzeichnisbasierte Verteilung Hinweisdokumente in einer normalen Verzeichnispfadstruktur zur Verfügung, während ROLIE (Resource-Oriented Lightweight Information Exchange) [RFC-8322] ein RESTful-API-Protokoll ist, das speziell für die Automatisierung der Sicherheit, die Veröffentlichung, das Auffinden und die gemeinsame Nutzung von Informationen entwickelt wurde.

Verwendet ein Provider die ROLIE-basierte Verteilung, muss er auch die Anforderungen 15 bis 17 aus Abschnitt 7.1 erfüllen. Verwendet ein Provider die verzeichnisbasierte Verteilung, so muss er alternativ die Anforderungen 11 bis 14 aus Abschnitt 7.1 erfüllen.

2.1.1.3. Die Rolle des Trusted Providers in CSAF

Trusted Provider sind eine besondere Klasse von CSAF-Providern, die sich ein hohes Maß an Vertrauen und Zuverlässigkeit erworben haben. Sie müssen sich an strenge Sicherheits- und Qualitätsstandards halten, um die Integrität der von ihnen ausgestellten CSAF-Dokumente zu gewährleisten.

Zusätzlich zur Erfüllung aller Anforderungen an einen CSAF-Provider müssen Trusted Provider auch die Anforderungen 18 bis 20 aus Abschnitt 7.1 der CSAF 2.0-Spezifikation erfüllen. Diese beinhalten die Bereitstellung eines sicheren kryptographischen Hashs und einer OpenPGP-Signaturdatei für jedes ausgegebene CSAF-Dokument und sie stellen sicher, dass der öffentliche Teil des OpenPGP-Signierschlüssels öffentlich zugänglich gemacht wird.

2.1.2. CSAF 2.0 Datenaggregatoren

Datenaggregatoren konzentrieren sich auf die Sammlung und Weiterverteilung von CSAF-Dokumenten. Sie fungieren als Verzeichnis für CSAF-2.0-Issuers und deren Hinweis-Dokumente sowie als Vermittler zwischen Issuers und Endanwendern. Eine einzelne Instanz kann sowohl als CSAF-Lister als auch als Aggregator fungieren. Datenaggregatoren können je nach den Bedürfnissen ihrer Kunden wählen, welche Hinweis-Dokumente von vorgelagerten Publishern sie auflisten oder sammeln und weiterverteilen.

Hier sind einzelne Unterrollen in der Gruppe der Datenaggregatoren:

2.1.2.1. Die Rolle des CSAF-Listers

Sogenannte „Lister“ sammeln CSAF-Dokumente von mehreren CSAF-Herausgebern und listen sie an einem zentralen Ort auf, um das Auffinden zu erleichtern. Der Zweck eines Listers ist es, als eine Art Verzeichnis für CSAF 2.0-Hinweise zu fungieren, indem URLs konsolidiert werden, unter denen CSAF-Dokumente abgerufen werden können. Es wird nicht davon ausgegangen, dass ein Lister einen vollständigen Satz aller CSAF-Dokumente enthält.

Lister müssen eine gültige aggregator.json-Datei veröffentlichen, die mindestens zwei separate CSAF-Anbieter auflistet. Während ein Lister auch als Issuer fungieren kann, darf er keine gespiegelten Dateien auflisten, die auf eine Domain unter seiner eigenen Kontrolle zeigen.

2.1.2.2. Die Rolle des CSAF-Aggregators

Die Rolle des CSAF-Aggregators stellt den letzten Wegpunkt zwischen den veröffentlichten CSAF-2.0-Hinweis-Dokumenten und dem Endanwender dar. Aggregatoren bieten einen Ort, an dem CSAF-Dokumente durch ein automatisiertes Tool abgerufen werden können. Obwohl Aggregatoren als konsolidierte Quelle für Cybersicherheitshinweise fungieren, vergleichbar mit NIST NVD oder CVE.org der MITRE Corporation, handelt es sich bei CSAF 2.0 um ein dezentralisiertes Modell, im Gegensatz zu einem zentralisierten Modell. Aggregatoren sind nicht verpflichtet, eine umfassende Liste von CSAF-Dokumenten von allen Herausgebern anzubieten. Außerdem können die Herausgeber ihren CSAF-Beratungsfeed kostenlos zur Verfügung stellen oder als kostenpflichtigen Dienst betreiben.

Ähnlich wie Lister müssen Aggregatoren eine aggregator.json-Datei öffentlich zugänglich machen, und CSAF-Dokumente von jedem gespiegelten Issuer müssen in einem separaten Ordner zusammen mit der provider-metadata.json des Issuers abgelegt werden. Im Wesentlichen müssen Aggregatoren die Anforderungen 1 bis 6 und 21 bis 23 aus Abschnitt 7.1 der CSAF-2.0-Spezifikation erfüllen.

CSAF-Aggregatoren sind auch dafür verantwortlich, sicherzustellen, dass jedes gespiegelte CSAF-Dokument eine gültige Signatur (Anforderung 19) und einen sicheren kryptografischen Hash (Anforderung 18) besitzt. Wenn die ausstellende Partei diese Dateien nicht zur Verfügung stellt, muss der Aggregator sie erzeugen.

3. Fazit

Das Verständnis der CSAF 2.0-Stakeholder und -Rollen ist entscheidend für die ordnungsgemäße Umsetzung von CSAF 2.0 und die Nutzung der automatisierten Erfassung und Nutzung wichtiger Cybersicherheitsinformationen. Die CSAF 2.0-Spezifikation definiert zwei Hauptinteressengruppen: vorgelagerte Produzenten, die für die Erstellung von Cybersicherheitshinweisen verantwortlich sind, und nachgelagerte Verbraucher, die diese Informationen zur Verbesserung der Sicherheit nutzen. Zu den Rollen innerhalb von CSAF 2.0 gehören Issuer (Herausgeber, Anbieter und vertrauenswürdige Anbieter), die Hinweise erstellen und verteilen, und Datenaggregatoren wie Lister und Aggregatoren, die diese Hinweise sammeln und an die Endnutzer weitergeben.

Die Mitglieder jeder Rolle müssen sich an bestimmte Sicherheitskontrollen halten, die die sichere Übertragung von CSAF 2.0-Dokumenten unterstützen. Das Traffic Light Protocol (TLP) regelt, wie Dokumente freigegeben werden dürfen und welche Zugriffskontrollen erforderlich sind.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Juli 2024 Threat Tracking: Sommerpause für Schwachstellen?

Die Veröffentlichung von Schwachstellen legte im Juli eine Pause ein. Nur 3.135 neue CVEs wurden veröffentlicht, ein Rückgang von fast 40 % gegenüber dem Rekordmonat Mai 2024. Letzten Monat sprachen wir über Cybersicherheit am Rand des Netzwerks und bezogen uns dabei auf die zunehmende Zahl von Angriffen auf die Netzwerk-Peripherie. Der Titel dieses Beitrags deutete auch an, dass die IT weltweit an einem katastrophalen Ausfall vorbeischrammen könnte. Elmar Geese, CMO von Greenbone, hat eine schöne Einschätzung des fehlgeschlagenen Updates von CrowdStrike veröffentlicht, das am Freitag, dem 19. Juli, weltweit Windows-Systeme zum Absturz brachte.

Schon im Jahr 2021 sagte Gartner voraus, dass bis 2025 ungezügelte Cyberangriffe Tod und Chaos verursachen werden. Die schlechte Nachricht ist, dass wir dem Zeitplan von Gartner voraus sind, aber die noch schlechtere Nachricht ist, dass wir keinen Cyberangriff brauchten, um dieses Ziel zu erreichen. Hier ein Überblick über die wichtigsten, aktiv ausgenutzten Schwachstellen und kritischen Risiken im Juli 2024.

Ransomware verbreitet sich über VMware-Schwachstelle

In diesem Monat wurden zwei Schwachstellen in VMwares ESXi-Hypervisor und vCenter Server-Produkten in den KEV-Katalog (Known Exploited Vulnerabilities, bekannte ausgenutzte Sicherheitslücken) der CISA aufgenommen. Bei einer Schwachstelle, CVE-2024-37085 in ESXi, wurde beobachtet, dass sie die Ransomware Akira und Black Basta verbreitet. Die Virtualisierungslösungen von VMware sind für das globale IT-Ökosystem von entscheidender Bedeutung. In der Vergangenheit hat der Anbieter verkündet, dass über 80 Prozent der virtualisierten Arbeitslasten auf seiner Technologie laufen, darunter alle Fortune 500- und Fortune Global 100-Unternehmen.

CVE-2024-37085 (CVSS 6.8 Medium) wurde von Microsoft entdeckt, das enthüllte, dass ESXi von vornherein äußerst unsicher ist und jedem Benutzer in einer Active Directory (AD)-Domänengruppe mit dem Namen „ESX Admins“ standardmäßig ohne ordnungsgemäße Validierung vollen administrativen Zugriff gewährt. Nur für den Fall, dass Sie nicht glauben können, was Sie gerade gelesen haben, möchte ich klarstellen: Jeder Benutzer in einer beliebigen AD-Gruppe mit dem Namen „ESX Admins“ erhält volle Administratorrechte auf einer ESXi-Instanz – und zwar absichtlich. Wir sollten alle fassungslos sein und unter Schock stehen.

In Anbetracht der Tatsache, dass CVE-2024-37085 für Ransomware-Angriffe ausgenutzt wird, sollten Sie daran denken, dass die Erstellung sicherer Backups von ESXi-Hypervisor-Konfigurationen und virtuellen Maschinen sowie die Durchführung von Tabletop- und Funktionsprüfungen zu einer schnellen Wiederherstellung nach einem Ransomware-Angriff beitragen können. Das Schließen von Sicherheitslücken durch Scannen auf bekannte Schwachstellen und das Anwenden von Abhilfemaßnahmen können dazu beitragen, dass Ransomware-Angriffe gar nicht erst erfolgreich werden.

CVE-2022-22948 (CVSS 6.5 Medium), das ebenfalls aktiv ausgenutzt wird, ist ein weiterer „Insecure by design“-Fehler in VMware-Produkten, diesmal in vCenter Server, der durch unsachgemäße Standard-Dateiberechtigungen [CWE-276] verursacht wird und die Offenlegung sensibler Informationen ermöglicht.

Greenbone kann aktiv verwundbare Versionen von VMware ESXi und vCenter Server mit separaten Schwachstellentests für CVE-2024-37085 und CVE-2022-22948 erkennen, seit diese im Jahr 2022 erstmals veröffentlicht wurden.

Geballte Ladung an Cisco CVEs mit kritischen Schweregraden

Im Juli 2024 wurden insgesamt 12 Schwachstellen, zwei kritische und drei mit hohem Schweregrad, in 17 verschiedenen Cisco-Produkten aufgedeckt. CVE-2024-20399 in Cisco NX-OS wird aktiv ausgenutzt und wurde in den KEV-Katalog (Known Exploited Vulnerabilities, bekannte ausgenutzte Sicherheitslücken) der CISA aufgenommen. Die CISA verwies auch auf CVE-2024-20399 in einer im Juli veröffentlichten Warnung zu „Secure by Design“. Die Behörde rät Softwareherstellern, ihre Produkte auf Schwachstellen für die Eingabe von Betriebssystembefehlen zu untersuchen [CWE-78]. Greenbone enthält eine Remote-Versionsprüfung für das aktiv ausgenutzte CVE-2024-20399.

Hier eine Übersicht über die wichtigsten CVEs:

  • CVE-2024-20399 (CVSS 6.7 Mittel): Eine Eingabe-Schwachstelle im Command Line Interface (CLI) von Ciscos NX-OS ermöglicht es, authentifizierten administrativen Benutzern, Befehle als Root auf dem zugrundeliegenden Betriebssystem (OS) auszuführen, da unzensierte Argumente an bestimmte Konfigurationsbefehle übergeben werden. CVE-2024-20399 kann nur von einem Angreifer ausgenutzt werden, der bereits privilegierten Zugriff auf die Schnittstelle in der Befehlszeile hat. Greenbone enthält eine Remote-Versionsprüfung für CVE-2024-20399.
  • CVE-2024-20419 (CVSS 10 kritisch): Das Authentifizierungssystem von Cisco Smart Software Manager On-Prem (SSM On-Prem) ermöglicht es einem nicht authentifizierten Angreifer, remote das Passwort eines beliebigen Benutzers, einschließlich Administratoren, über HTTP-Anfragen zu ändern. Greenbone enthält einen Test zur Erkennung von Remote-Versionen für CVE-2024-20419.
  • CVE-2024-20401 (CVSS 10 kritisch): Eine Schwachstelle in den Funktionen zum Scannen von Inhalten und Filtern von Nachrichten des Cisco Secure Email Gateway könnte es einem nicht authentifizierten, Angreifer ermöglichen, beliebige Dateien aus der Ferne auf dem Gerät über E-Mail-Anhänge zu überschreiben, wenn die Dateianalyse und die Inhaltsfilter aktiviert sind. CVE-2024-20401 erlaubt es Angreifern, Benutzer mit Root-Rechten zu erstellen, die Gerätekonfiguration zu verändern, beliebigen Code auszuführen oder das Gerät komplett zu deaktivieren. Greenbone kann anfällige Geräte erkennen, sodass Verteidiger die von Cisco empfohlenen Abhilfemaßnahmen anwenden können.

Weitere CVEs, die im Juli 2024 für führende Cisco-Produkte veröffentlicht wurden, umfassen:

CVE

Produkt

VT

CVE-2024-20400 (CVSS 5.0 M)

Cisco Expressway-Reihe

Erkennungstest

CVE-2024-6387 (CVSS 8.1 H)

Virtuelle Cisco Intersight-Anwendung

Erkennungstest

CVE-2024-20296 (CVSS 5.8 M)

Cisco Identity Services Engine (ISE)

Erkennungstest

CVE-2024-20456 (CVSS 6,5 M)

Cisco IOS XR-Software

Erkennungstest

CVE-2024-20435 (CVSS 6.8 M)

Sichere Web-Anwendung von Cisco

Erkennungstest

CVE-2024-20429 (CVSS 7.7 H)

Sicheres E-Mail-Gateway von Cisco

Erkennungstest

CVE-2024-20416 (CVSS 7.7 H)

Cisco Dual-WAN-Gigabit-VPN-Router

Erkennungstest

ServiceNow: Datendiebstahl und Remote Code Execution

Mit Abschluss des Monats Juli wurden zwei kritische Sicherheitslücken in ServiceNow – CVE-2024-4879 und CVE-2024-5217 – in die KEV-Liste der CISA aufgenommen. Beide CVEs werden mit CVSS 9.8 als kritisch eingestuft. Am selben Tag, dem 10. Juli, wurde ServiceNow noch eine dritte zugewiesen: CVE-2024-5178 (CVSS 6.8 Medium). Die drei Sicherheitslücken werden von Angreifern miteinander verknüpft, um unauthentifizierte Remote Code Execution (RCE) zu erreichen. Die Daten von über 100 Opfern werden Berichten zufolge auf BreachForums verkauft, einer Plattform für den Austausch gestohlener Daten für Cyberkriminelle.

ServiceNow ist eine führende Plattform für das IT-Service-Management (ITSM), die Incident Management, Problem Management, Change Management, Asset Management und Workflow-Automatisierung umfasst und sich auch auf allgemeine Geschäftsmanagement-Tools wie Personalwesen, Kundenservice und Sicherheitsabläufe erstreckt. ServiceNow wird entweder als Software as a Service (SaaS) installiert oder von Unternehmen selbst gehostet. Shodan meldet etwa 20.000 gefährdete Instanzen online und Resecurity hat Angriffe auf Unternehmen des privaten Sektors und auf Regierungsbehörden weltweit beobachtet.

Greenbone hat Schwachstellentests (VTs) [1][2] für alle drei CVEs eingeführt, bevor die CISA auf aktive Exploits aufmerksam wurde. Hotfixes sind beim Hersteller erhältlich [3][4][5] und Kunden, die das System selbst hosten, sollten diese dringend anwenden.

Kritische Sicherheitslücke in den eCommerce-Plattformen Adobe Commerce und Magento

Adobe Commerce und Magento in den Versionen 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 und früher sind von der Sicherheitslücke CVE-2024-34102 (CVSS 9.8 kritisch) betroffen, die durch eine unzulässige Einschränkung der XML External Entity Reference (‚XXE‘) [CWE-611] entsteht. Ein Angreifer könnte die Schwachstelle ohne Benutzerinteraktion ausnutzen, indem er eine bösartige XML-Datei sendet, um sensible Daten innerhalb der Plattform zu lesen.

CVE-2024-34102 wird aktiv ausgenutzt und ein grundlegender Proof-of-Concept-Exploit-Code ist auf GitHub [1] verfügbar. Bösartiger Exploit-Code [2] für die CVE wurde aufgrund der Richtlinien gegen Malware ebenfalls von GitHub entfernt, aber Angreifer verbreiten ihn aktiv über Dark-Web-Foren und Hacker-Kanäle auf Telegram. Außerdem stieg der EPSS-Wert (Exploit Prediction Scoring System) der CVE vor ihrer Aufnahme in die CISA KEV an, was EPSS als Frühwarnmetrik für Schwachstellenrisiken anerkennt.

Magento ist eine Open-Source-PHP-basierte eCommerce-Plattform für kleine und mittlere Unternehmen. Adobe Commerce, das 2018 von Adobe übernommen wurde, ist im Wesentlichen die Enterprise-Version von Magento Open Source mit zusätzlichen Funktionen für größere Unternehmen. Da es sich um eine eCommerce-Plattform handelt, besteht das Risiko, dass Angreifer Zahlungskartendaten oder andere sensible personenbezogene Daten von Kunden einer Website stehlen und darüber hinaus kostspielige Ausfallzeiten aufgrund von Umsatzeinbußen für den Eigentümer der Website verursachen.

Greenbone enthält eine aktive Prüfung und Tests zur Erkennung von Schwachstellen (VTs), um anfällige Versionen dieser hochgefährlichen Schwachstelle zu identifizieren.

GeoServer: Hohes Risiko für RCE

Eine CVSS 9.8 kritische CVE wurde in GeoServer vor den Versionen 2.23.6, 2.24.4 und 2.25.2 gefunden. GeoServer ist eine Open-Source-Anwendung für die gemeinsame Nutzung, Bearbeitung und Anzeige von Geodaten. Die als CVE-2024-36401 verfolgte Schwachstelle wird aktiv ausgenutzt und kann zu beliebiger Remote Code Execution (RCE) führen. Der Exploit-Code ist öffentlich zugänglich [1][2], was das Risiko noch erhöht. CERT-EU hat eine Warnung für alle EU-Institutionen, Agenturen und Mitgliedsstaaten herausgegeben. Greenbone enthält Remote-Erkennungstests zur Identifizierung von CVE-2024-36401, so dass Benutzer der betroffenen GeoServer-Produkte benachrichtigt werden können.

Die Schwachstelle, die als Abhängigkeit von einer anfälligen Drittanbieterkomponente [CWE-1395] klassifiziert ist, liegt in der GeoTools-Komponente – einer Open-Source-Java-Bibliothek, die als Grundlage für verschiedene Geospatial-Projekte und -Anwendungen, einschließlich GeoServer, dient. Ähnlich wie sich Log4Shell auf eine unbekannte Anzahl von Anwendungen auswirkte, die die Log4j 2.x-Bibliothek verwenden, gilt das Gleiche für GeoTools. Verschiedene OGC (Open Geospatial Consortium) Request-Parameter (einschließlich WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic und WPS Execute Requests) verfallen einer RCE, da die GeoTools Bibliotheks-API unsichere Property/Attribute-Namen an die commons-jxpath Bibliothek weitergibt, die die Fähigkeit hat, beliebigen Code auszuführen [CWE-94].

Benutzer sollten auf die GeoServer-Versionen 2.23.6, 2.24.4 oder 2.25.2 aktualisieren, die einen Patch für dieses Problem enthalten. Diejenigen, die nicht aktualisieren können, können die Datei „gt-complex-<Version>.jar“ entfernen, um den anfälligen Code zu beseitigen, was jedoch die Funktionalität beeinträchtigen kann, wenn das gt-complex-Modul erforderlich ist.

Zusammenfassung

Im Juli 2024 wurden weniger Schwachstellen gemeldet, dennoch gab es erhebliche Bedrohungen. Insbesondere wurde beobachtet, dass CVE-2024-37085 in VMwares ESXi aufgrund von unsicheren Designfehlern für Ransomware-Angriffe ausgenutzt wird. Zu den neuen Schwachstellen von Cisco gehören CVE-2024-20399, die aktiv für die Einschleusung von Befehlen ausgenutzt wird, sowie zwei kritische Schwachstellen in den Produkten. Die CVEs von ServiceNow, darunter CVE-2024-4879 und CVE-2024-5217, werden zur Verbreitung von Ransomware und zum Datendiebstahl genutzt. CVE-2024-34102 von Adobe Commerce und CVE-2024-36401 von GeoServer stellen ebenfalls ein großes Risiko dar. Unternehmen müssen Patches, Schwachstellenmanagement und die Reaktion auf Vorfälle priorisieren, um diese Bedrohungen zu entschärfen.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Joseph Lee

Wie CSAF 2.0 automatisiertes Schwachstellenmanagement vorantreibt

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Markus Feilner

„Security-Krisen sind wie Erdbeben“ – Greenbone-CEO Jan-Oliver Wagner auf dem PITS-Kongress 2024

„Unterstützung zur Krisenfrüherkennung“ lautete das Thema eines hochkarätig besetzten Panels am zweiten Tag des diesjährigen PITS-Kongresses. Mit Greenbone-CEO Jan-Oliver Wagner diskutierten Experten vom Bundeskriminalamt, der Bundeswehr, dem Verband Kommunaler IT-Dienstleister VITAKO und des Bundesamts für Sicherheit in der Informationstechnik.

Podiumsdiskussion beim PITS-Kongress 2024 zum Thema Krisenfrüherkennung mit Greenbone-CEO Dr. Jan-Oliver Wagner und Vertreterinnen und Vertretern von BSI, Bundeswehr, BKA und VITAKO.

Auch in diesem Jahr organisierte der Behörden Spiegel wieder seine beliebte Konferenz zur Public IT Security (PITS). Im renommierten Hotel Adlon in Berlin trafen sich dazu hunderte Security-Experten an zwei Tagen zu Foren, Vorträgen und einer Ausstellung von IT-Security-Firmen. 2024 stand das Event unter dem Motto „Security Performance Management“ – und da war es nur naheliegend, dass auch Greenbone als führender Anbieter von Schwachstellenmanagement geladen war (wie schon 2023), beispielsweise im Panel zur Krisenfrüherkennung, das der Greenbone-Vorstand Dr. Jan-Oliver Wagner mit einem Impulsvortag eröffnete.

Jan-Oliver Wagner erklärte seine Sicht auf die strategische Krisenerkennung, sprach von den typischen „Erdbeben“ und den beiden wichtigsten Komponenten: Erstens, das Wissen, wo Schwachstellen sind, und zweitens Technologien bereitzustellen, um diese zu beseitigen.

Über lange Jahre hat Greenbone eben diese Expertise aufgebaut, die Firma stellt sie auch in Open Source der Allgemeinheit zur Verfügung und arbeitet dazu stets mit den wichtigen Playern auf dem Markt zusammen. Von Anfang an waren die Kontakte mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) da: „Das BSI hatte das Thema Schwachstellenmanagement schon auf dem Radar, als IT-Security sich noch auf Firewall und Antivirus beschränkte“, lobt Wagner das BSI, die zentrale Behörde für IT-Sicherheit des deutschen Staates.

Heute sei die Bedeutung zweier Faktoren klar: „Jede Organisation muss wissen, wie und wo sie angreifbar sie ist, die eigenen Reaktionsfähigkeiten kennen und fortlaufend an deren Verbesserung arbeiten. Cyberbedrohungen sind wie Erdbeben. Die können wir nicht verhindern, sondern nur uns darauf vorbereiten und bestmöglich darauf reagieren.“

„Krise ist meist da, bevor die Tagesschau berichtet“

Aus den ständigen Cyberbedrohung wird nach Jan-Oliver Wagners Definition eine „Krise“, wenn eine Bedrohung beispielsweise „auf eine Gesellschaft, Wirtschaft oder Nation trifft, wo viele Organisationen viele Schwachstellen haben und eine geringe Fähigkeit, schnell zu reagieren. Die Geschwindigkeit ist da sehr wichtig. Man muss schneller sein, als der Angriff passiert.“ Auch die anderen Teilnehmer des Panels thematisierten das und nutzten dafür den Begriff „Vor die Welle kommen“.

Oft sei die Krise eben schon da, lange bevor sie in der Tagesschau Erwähnung findet. Einzelne Organisationen müssen sich schützen und sich vorbereiten, damit sie mit täglicher Routine in die Lage kommen, auch auf unbekannte Situationen reagieren zu können. „Eine Cybernation unterstützt Organisationen und die Nation, indem sie Mittel zur Verfügung stellt, diesen Zustand zu erreichen“, so Jan-Oliver Wagner.

Unterschiede zwischen Militär und Kommunen

Die Sicht der Bundeswehr erklärte Generalmajor Dr. Michael Färber, Abteilungsleiter Planung und Digitalisierung, Kommando Cyber- & Informationsraum: Ihm zufolge ist eine Krise dann gegeben, wenn die Maßnahmen und Möglichkeiten zu reagieren nicht mehr ausreichen. „Dann entwickelt sich etwas zu einer Krise.“

Aus Sicht der Kommunen jedoch ergibt sich ein anderes Bild, wusste Katrin Giebel, die Geschäftsstellenleiterin der VITAKO, der Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister, zu berichten. „80 Prozent der Verwaltungsdienstleistungen finden auf der kommunalen Ebene statt. Da gibt es schon Tumulte, wenn die KFZ-Zulassung nicht verfügbar ist.“ In den immer wieder stark gebeutelten Städten und Gemeinden fangen Krisen deutlich früher an: „Für uns sind schon die Bedrohungen fast gleichzusetzen mit einer Krise.“

Erschreckend fürs BSI: Nachlässigkeit in Organisationen

Das BSI dagegen definiert eine „Krise“, wenn eine einzelne Organisation nicht oder nicht mehr in der Lage ist, ein Problem allein zu lösen. Dr. Dirk Häger, Abteilungsleiter Operative Cyber-Sicherheit beim BSI: „Sobald zwei Ressorts betroffen sind, tritt der Krisenstab zusammen, für uns ist eine Krise gegeben, sobald wir ein Problem mit der Standardorganisation nicht gelöst bekommen.“ Da komme dann auch den Mitarbeitern, die über die Einberufung entscheiden, eine wichtige Rolle zu. „Man erreicht eben einen Punkt, wo man sich einig ist: Jetzt brauchen wir den Krisenstab.“

Erschreckend, etwa angesichts der Vorgänge rund um die Log4j-Schwachstelle findet Häger aber eher, wie lange nach eigentlich schon gelösten Krisen noch erfolgreiche Angriffe stattfinden. „Wir betreiben da gerade am Anfang sehr, sehr viel Aufwand. Die Log4j-Krise war eigentlich vorbei, aber sehr viele Organisationen waren immer noch angreifbar und hatten unzureichende Reaktionsfähigkeiten. Aber keiner kuckt mehr drauf“, klagt der Abteilungsleiter aus dem BSI.

Wie die Reaktionsgeschwindigkeit erhöhen?

Von der Moderatorin Dr. Eva-Charlotte Proll, Chefredakteurin und Herausgeberin beim Behörden Spiegel, gefragt, was angesichts dieser Einsichten denn konkret helfe, schildert er das typische Vorgehen und die Entscheidungsfindung beim aktuellen Checkpoint-Vorfall: „Ob etwas eine Krise ist oder nicht, ist Expertenwissen. In dem Fall war das erst eine Lücke, die von staatlichen Akteuren initiiert wurde.“ Handlungsbedarf war spätestens dann gegeben, als die Checkpoint-Backdoor von anderen Angreifern ausgenutzt wurde. Auch das Wissen um diese konkrete Gefährdungslage ist für Betroffene von zentraler Bedeutung.

Jan Oliver Wagner betonte hier noch einmal die Bedeutung des Faktors Wissen. Oft werde die Gefährdung nicht angemessen diskutiert. Anfang 2024 beispielsweise reduzierte eine wichtige US-Behörde (NIST) den Informationsumfang ihrer Schwachstellendatenbank – eine Krise für jeden Anbieter von Vulnerability Management und deren Kunden. Außerdem zeuge es von Handlungsbedarf, dass die NIST immer noch nicht als kritische Infrastruktur definiert sei.

Die vom NIST gelieferten Informationen sind auch für die Fähigkeiten des nationalen Cyberabwehrzentrums, ein Lagebild zu erstellen, von zentraler Bedeutung, pflichtet ihm Färber bei. Das betrifft auch die Zusammenarbeit mit der Branche: Eine Reihe von großen Firmen „rühmen sich damit, Exploit-Listen binnen fünf Minuten an ihre Kunden zu liefern. Da können auch wir noch besser werden.“

Carsten Meywirth, Leiter Abteilung Cybercrime beim BKA, betonte die Unterschiede zwischen staatlichen und kriminellen Angriffen, auch am Beispiel des Supply-Chain-Angriffs auf Solarwinds. Kriminelle Angreifer haben oft wenig Interesse, eine Krise hervorzurufen, weil zu viel mediale Aufmerksamkeit die möglichen finanziellen Erträge gefährdet. Auch Sicherheitsbehörden müssten da stets vor die Welle kommen. Und dafür brauche es Aufklärung und das Potential, die Infrastruktur der Angreifer zu stören.

BKA: Internationale Zusammenarbeit

Deutschland sei, so Generalmajor Färber, bei den Angriffen immer unter den Top 4 Ländern. Die USA rangierten stets auf Platz eins, doch in den Schleppnetzen der Angreifer landen wir schon allein wegen unserer Größe. Das mache die hervorragende internationale Zusammenarbeit bei Aufklärung und Täterjagd so wichtig. „Vor allem die Achse Deutschland-USA-Niederlande ist da sehr erfolgreich, aber auch die „Datasprints“ mit den Five-Eyes-Staaten (USA, UK, Australien, Kanada und Neuseeland), wo man auch Geheimdiensterkenntnisse auf einen gemeinsamen Tisch legt und abgleicht, seien von elementarer Bedeutung. „Eine erfolgreiche Täteridentifizierung ist ohne solche Allianzen meistens unmöglich“, so Michael Färber. Deutschland ist mit seinen dafür relevanten Organisationen gut aufgestellt. „Wir haben deutlich höhere Redundanz als andere, und das stellt in diesem Kampf ein großes Asset dar.“ In der beispielhaften „Operation Endgame“, eine vom FBI gestartete Kooperation der Sicherheitsbehörden mit der freien Wirtschaft zeige sich dann gerade jetzt auch die ganze Schlagkraft dieser Strukturen. „Das müssen und werden wir weiter ausbauen.“

„Wir brauchen eine Notrufnummer für Kommunen in IT-Krisen“

So vor die Welle zu kommen, ist für die Kommunen noch Zukunftsmusik. Die seien stark angewiesen auf interföderale Unterstützung und eine Kultur der Zusammenarbeit, ein aktuelles Lagebild ist für sie unabdingbar, berichtet Katrin Giebel von VITAKO. Als Vertreter der kommunalen IT-Dienstleister kenne man viele kritische Situationen und die Nöte der Gemeinden gut – von Personalnot bis hin zu fehlender Expertise oder einer heute noch fehlenden Notrufnummer für IT-Krisen. So eine Hotline wäre nicht nur hilfreich, sie entspricht wohl auch der Definition aus Wagners einführenden Vortrag: „Eine Cybernation schützt sich, indem sie die Unternehmen dabei unterstützt, sich zu schützen.“

BSI: Vorsorge ist das Wichtigste

Auch wenn das BSI sich nicht in der Lage sieht, einen solchen Anspruch allein zu erfüllen, habe man diese dezentrale Denkweise schon immer verinnerlicht. Aber ob das BSI zu einer Zentralstelle in diesem Sinne ausgebaut werden soll, müsse man erst diskutieren, erklärt Dirk Häger vom BSI. „Viel wichtiger ist aber Prävention. Wer heute ein ungesichertes System ins Netz stellt, wird schnell gehackt. Die Bedrohungslage ist da. Wir müssen das abwehren können. Und genau das ist Prävention.“

Dafür, ergänzt Wagner, sei die Information zentral. Und die Informationen zu verteilen, sei durchaus eine Aufgabe des Staates, da sieht er „die existierenden Organisationen in der perfekten Rolle.“

Sponsorenwand des PITS-Kongresses 2024 mit Logos führender IT-Sicherheitsunternehmen wie Greenbone, Cisco, HP und weiteren Partnern aus Verwaltung und Wirtschaft.


Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Dirk Boeing

NIS2: Von drohendem Unheil zu effizienten Maßnahmen

Der Winter naht: Der Leitspruch des Hauses Stark aus der Serie „Game of Thrones“ deutet auf das Heraufziehen eines nicht näher definierten Unheils hin. Ist NIS2 eine Walze aus Eis und Feuer, die die gesamte europäische IT-Landschaft unter sich begräbt und vor der sich nur retten kann, wer eines der zahllosen Webinare besucht und alle Ratschläge befolgt?

NIS2 als solches ist lediglich eine Richtlinie, die von der EU erlassen wurde. Sie soll die vielleicht noch nicht optimale IT-Sicherheit von Betreibern wichtiger und kritischer Infrastrukturen sicherstellen und die Cyberresilienz erhöhen. Auf Basis dieser Richtlinie sind nun die Mitgliedsländer aufgerufen, ein entsprechendes Gesetz zu schaffen, das diese Richtlinie in nationales Recht umsetzt.

Was soll geschützt werden?

Bereits 2016 wurde die NIS-Richtlinie durch die EU eingeführt, um für die Gesellschaft relevante Branchen und Dienstleister vor Angriffen in der Cybersphäre zu schützen. Diese Regelung enthält verbindliche Vorgaben zum Schutz von IT-Strukturen in Unternehmen, die als Betreiber kritischer Infrastrukturen (KRITIS) tätig sind. Hierbei handelt es sich um Unternehmen, die eine unverzichtbare Rolle innerhalb der Gesellschaft spielen, weil sie in Bereichen wie Gesundheitsdiensten, Energieversorgung und Transport tätig sind. Bereiche also, in denen vorsätzlich herbeigeführte Störungen oder Ausfälle zu katastrophalen Zuständen führen können – wessen Haushalt gerüstet ist, einen mehrtägigen Stromausfall mit allen Konsequenzen zu überstehen, der möge die Hand heben…

Angesichts der weiter voranschreitenden Digitalisierung musste die EU eine Nachfolgeregelung (NIS2) schaffen, die zum einen strengere Anforderungen an die Informationssicherheit stellt, zum anderen aber auch einen größeren Kreis an Unternehmen erfasst, die für die Gesellschaft „wichtig“ oder „besonders wichtig“ sind. Diese Unternehmen werden nun in die Pflicht genommen, gewisse Standards in der Informationssicherheit zu erfüllen.

Obwohl die NIS2-Richtlinie bereits im Dezember 2022 verabschiedet wurde, haben die Mitgliedsländer bis zum 17. Oktober 2024 Zeit, ein entsprechendes Umsetzungsgesetz zu verabschieden. Deutschland wird es bis dahin wohl nicht schaffen. Trotzdem gibt es keinen Grund, sich zurückzulehnen. Das NIS2UmsuCG wird kommen, und mit ihm erhöhte Anforderungen an die IT-Sicherheit vieler Unternehmen und Institutionen.

Wer muss jetzt handeln?

Betroffen sind Unternehmen aus vier Gruppen. Einmal sind das die besonders wichtigen Einrichtungen mit 250 oder mehr Mitarbeitern oder 50 Millionen Euro Jahresumsatz und einer Bilanzsumme ab 43 Millionen Euro. Ein Unternehmen, das diese Kriterien erfüllt und in einem der Sektoren Energie, Transport/ Verkehr, Finanzen/ Versicherungen, Gesundheit, Wasser/ Abwasser, IT und TK oder Weltraum tätig ist, gilt als besonders wichtig.

Daneben gibt es die wichtigen Einrichtungen ab 50 Mitarbeitern oder 10 Millionen Euro Umsatz und einer Bilanzsumme von 10 Millionen Euro. Erfüllt ein Unternehmen diese Kriterien und ist es in einem der Sektoren Post/ Kurier, Chemie, Forschung, verarbeitendes Gewerbe (Medizin/ Diagnostika, DV, Elektro, Optik, Maschinenbau, Kfz/ Teile, Fahrzeugbau), digitale Dienste (Marktplätze, Suchmaschinen, soziale Netzwerke), Lebensmittel (Großhandel, Produktion, Verarbeitung) oder Entsorgung (Abfallwirtschaft) tätig, so gilt es als wichtig.

Neben besonders wichtigen und wichtigen Einrichtungen gibt es die kritischen Anlagen, die weiterhin durch die KRITIS-Methodik definiert werden. Zusätzlich werden auch Bundeseinrichtungen reguliert.

Was ist zu tun?

Konkret bedeutet das, dass alle betroffenen Unternehmen und Institutionen, ganz gleich ob „besonders wichtig“ oder „wichtig“, eine Reihe von Auflagen und Pflichten zu erfüllen haben, die wenig Interpretationsspielraum lassen und daher strikt zu beachten sind. Auf folgenden Gebieten muss gehandelt werden:

Risikomanagement

Betroffene Unternehmen sind verpflichtet, ein umfassendes Risikomanagement einzuführen. Dazu gehören neben einer Zugangskontrolle, Multi-Faktor-Authentifizierung und Single Sign-On (SSO) auch Training und Incident Management sowie ein ISMS und Risikoanalysen. Darunter fallen auch das Schwachstellenmanagement und die Anwendung von Schwachstellen- und Compliance-Scans.

Meldepflichten

Für alle Unternehmen besteht eine Meldepflicht für „erhebliche Sicherheitsvorfälle“: Diese müssen unverzüglich, spätestens aber innerhalb von 24 Stunden der Meldestelle des BSI berichtet werden. Weitere Updates haben innerhalb von 72 Stunden und 30 Tagen zu erfolgen.

Registrierung

Die Unternehmen sind verpflichtet, ihre Betroffenheit von der NIS2-Gesetzgebung selbst festzustellen und sich innerhalb einer Frist von drei Monaten selbst zu registrieren. Wichtig: Niemand sagt einem Unternehmen, dass es unter die NIS2-Regelung fällt und sich registrieren muss. Die Verantwortung liegt ausschließlich bei den einzelnen Unternehmen und deren Geschäftsführern.

Nachweise

Es reicht nicht aus, die vorgegebenen Vorkehrungen lediglich zu treffen, sondern es müssen auch entsprechende Nachweise erbracht werden. Wichtige und besonders wichtige Einrichtungen werden stichprobenartig durch das BSI kontrolliert werden, wobei entsprechende Dokumentationen vorgelegt werden müssen. KRITIS-Einrichtungen werden turnusmäßig alle drei Jahre überprüft.

Informationspflichten

Sicherheitsvorfälle unter den Teppich zu kehren, ist zukünftig nicht mehr möglich. Das BSI erhält eine Weisungsbefugnis zur Unterrichtung von Kunden über Sicherheitsvorfälle. Ebenso erhält das BSI eine Weisungsbefugnis über die Unterrichtung der Öffentlichkeit von Sicherheitsvorfällen.

Governance

Geschäftsführer werden verpflichtet, Maßnahmen zum Risikomanagement zu billigen. Ebenso werden Schulungen zum Thema Pflicht. Besonders gravierend: Geschäftsführer haften persönlich mit ihrem Privatvermögen bei Pflichtverletzungen.

Sanktionen

In der Vergangenheit war es gelegentlich so, dass Unternehmen lieber die diffuse Möglichkeit eines Bußgeldes in Kauf nahmen als konkrete Investitionen in Cybersicherheitsmaßnahmen zu tätigen, da das Bußgeld im Verhältnis durchaus annehmbar erschien. NIS2 wirkt dem nun durch neue Tatbestände und teils drastisch erhöhte Bußgelder entgegen. Verschärft wird das nochmal durch die persönliche Haftung von Geschäftsführern.

Wie man sieht, ist das zu erwartende NIS2-Umsetzungsgesetz ein komplexes Gebilde, welches sich auf eine Vielzahl von Bereichen erstreckt und dessen Anforderungen in den seltensten Fällen mit einer einzigen Lösung abgedeckt werden können.

Welche Maßnahmen sind möglichst bald zu treffen?

Scannen Sie Ihre IT-Systeme kontinuierlich auf Schwachstellen. Sicherheitslücken werden damit schnellstmöglich aufgedeckt, priorisiert und dokumentiert. Dank regelmäßiger Scans und ausführlicher Berichte schaffen sie die Grundlage zur Dokumentation der Entwicklung der Sicherheit Ihrer IT-Infrastruktur. Gleichzeitig erfüllen Sie damit Ihre Nachweispflichten und sind im Fall einer Prüfung bestens gewappnet.

Experten können auf Wunsch den kompletten Betrieb des Schwachstellenmanagements in Ihrem Unternehmen übernehmen. Dazu gehören auch Leistungen, wie Web-Application Pentesting, bei dem gezielt Schwachstellen in Webanwendungen aufgedeckt werden. Damit decken Sie einen wichtigen Bereich im NIS2-Anforderungskatalog, und erfüllen die Anforderungen des § 30 (Risikomanagementmaßnahmen).

Fazit

Es gibt es nicht die eine, alles umfassende Maßnahme, mit der Sie sofort rundum NIS2-konform sind. Vielmehr ist eine Vielzahl unterschiedlicher Maßnahmen, die zusammengenommen eine gute Basis ergeben. Ein Bestandteil davon ist Schwachstellenmanagement mit Greenbone. Wenn Sie das im Hinterkopf behalten und rechtzeitig auf die richtigen Bausteine setzen, sind Sie als IT-Verantwortlicher auf der sicheren Seite. Und der Winter kann kommen.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Markus Feilner

Schutz von Office-Paketen: Greenbone integriert weitere BSI-Grundschutz- und CIS-Vorgaben

Das Grundschutz-Handbuch des Bundesamts für Sicherheit in der Informationstechnologe (BSI) macht seit wenigen Jahren auch klare Vorgaben für Anwender von Microsoft Office. Seit April 2024 integrieren die Enterprise-Produkte von Greenbone auch Tests, die belegen sollen, ob ein Unternehmen diese Anweisungen umsetzt. Dabei werden die BSI-Anweisungen mit den Leitlinien des Center for Internet Security (CIS) in Übereinstimmung gebracht.

Im Abschnitt „APP:Anwendungen 1.1. Office Produkte“ legt das BSI fest, welche „Anforderungen an die Funktionsweise der Komponenten von Office-Produkten“ zu stellen sind. Ziel ist der Schutz der durch die Office-Software bearbeiteten und genutzten Daten. Auch wenn in den meisten Fällen Microsoft Office gemeint sein dürfte – hat es doch immer noch die bei weitem größte Marktdurchdringung –, so möchte das Modell hinter den BSI-Vorgaben diese auf jedes Office-Produkt anwenden können, „das lokal installiert ist und mit dem Dokumente betrachtet, bearbeitet oder erstellt werden, außer E-Mail-Anwendungen“.

BSI-Vorgaben

Das Modul baut ausdrücklich auf die Vorgaben des Bausteins „ APP.6 Allgemeine Software“ auf und verweist auf die Module „APP.5.3 Allgemeiner E-Mail-Client“ sowie „APP.4.3 Relationale Datenbanken“ und „OPS.2.2 Cloud-Nutzung“, berücksichtigt diese jedoch ausdrücklich nicht.

Das BSI macht dabei drei wesentliche Gefährdungen für Office-Pakete aus:

  • Fehlende Anpassung der Office-Produkte an den Bedarf der Institution
  • Schädliche Inhalte in Office-Dokumenten
  • Integritätsverlust von Office-Dokumenten

Die im BSI-Grundschutzhandbuch genannten Bausteine umfassen 16 Punkte, von denen aber einige bereits wieder entfallen sind. Greenbone hat mehrere hundert Tests entwickelt, die vor allem für fünf der genannten Basis-Anforderungen zum Einsatz kommen, darunter beispielsweise das „Sichere Öffnen von Dokumenten aus externen Quellen“ (APP.1.1. A3) und den in APP.1.1. A15 aufgeführten „Einsatz von Verschlüsselung und Digitalen Signaturen“. In diesen Vorgaben schreibt das BSI zum einen:

„Alle aus externen Quellen bezogene Dokumente MÜSSEN auf Schadsoftware überprüft werden, bevor sie geöffnet werden. Alle als problematisch eingestuften und alle innerhalb der Institution nicht benötigten Dateiformate MÜSSEN verboten werden. Falls möglich, SOLLTEN sie blockiert werden. Durch technische Maßnahmen SOLLTE erzwungen werden, dass Dokumente aus externen Quellen geprüft werden.“

Hinsichtlich der Verschlüsselung heißt es: „Daten mit erhöhtem Schutzbedarf SOLLTEN nur verschlüsselt gespeichert bzw. übertragen werden. Bevor ein in ein Office-Produkt integriertes Verschlüsselungsverfahren genutzt wird, SOLLTE geprüft werden, ob es einen ausreichenden Schutz bietet. Zusätzlich SOLLTE ein Verfahren eingesetzt werden, mit dem Makros und Dokumente digital signiert werden können.“

CIS-Leitlinien verbessern den Grundschutz

Zusätzlich zu den im BSI-Grundschutzhandbuch genannten Vorgaben finden sich im CIS-Benchmark des Centers for Internet Security (CIS) für Microsoft Office noch weitergehende und spezifischere Vorschläge zur Absicherung der Microsoft-Produkte. Die CIS-Vorgaben entstehen in einer Community aus Sicherheitsexperten und stellen eine im Konsens entstandene Best-Practice-Sammlung, hier für Microsoft Office dar.

Als einer der ersten und einzigen Anbieter von Schwachstellenmanagement bringt Greenbone nun Tests auf dort genannte sicherheitsrelevante Features und vereint dabei erstmals die CIS- und BSI-Anleitungen zu zahlreichen, teils tiefgehenden Tests, beispielsweise auf die ActiveX-Control Initialisierung in Microsoft Office. Das Greenbone Vulnerability Management testet hier beispielsweise, ob dieser Schalter auf „enabled“ gesetzt ist, aber auch viele andere Settings, beispielsweise „Always prevent untrusted Microsoft Query files from opening“ is set to „Enabled“ und viele andere mehr.

Viele der Tests beschäftigen sich dabei mit externen Inhalten, dem Einbinden von Makros und der Frage, ob und wie diese externen Inhalte signiert, verifizierbar und daher vertrauenswürdig oder nicht sind, und ob die Administratoren ihre Hausaufgaben bei der Konfiguration von Microsoft Office gemacht haben. Denn, so das BSI, eine der wichtigsten Bedrohungen (und die als erste genannte) ist die mangelnde Anpassung der Office-Produkte an die Realität und die Business-Prozesse im Unternehmen. Hier sorgt Greenbone mit den neuen Tests für eine effiziente Erfüllung von Compliance-Vorgaben und erschwert es Angreifern und Malware, im Unternehmen Fuß zu fassen und Schaden anzurichten.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von
Greenbone AG

PITS 2024 Public IT Security

Save the date: Der „Fachkongress Deutschlands für IT- und Cyber-Sicherheit bei Staat und Verwaltung“ (12. bis 13. Juni 2024) informiert über aktuelle Trends, Strategien und Lösungen in der IT-Security.

Im Hauptprogramm: „IT-Unterstützung zur Krisenfrüherkennung“ (Moderation: Dr. Eva-Charlotte Proll, Chefredakteurin und Herausgeberin, Behörden Spiegel).

Teilnehmer:

  • Dr. Jan-Oliver Wagner, Vorstandsvorsitzender Greenbone
  • Carsten Meywirth, Leiter Abteilung Cybercrime, Bundeskriminalamt
  • Generalmajor Dr. Michael Färber, Abteilungsleiter Planung und Digitalisierung, Kommando Cyber- & Informationsraum
  • Katrin Giebel, Geschäftsstellenleiterin, VITAKO Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister
  • Dr. Dirk Häger, Abteilungsleiter Operative Cyber-Sicherheit, Bundesamt für Sicherheit in der Informationstechnik

Wo? Berlin, Hotel Adlon Kempinski, Unter den Linden 77
Wann? 13.06.2024; 9:40 Uhr

Schwachstellen in IT-Systemen werden heute immer stärker von böswilligen Angreifern ausgenutzt. Mit Vulnerability Management können Sie Ihre IT-Systeme schützen. Besuchen Sie uns in unserer Lounge an Stand 44. Wir freuen uns auf Sie!

Anmeldung: https://www.public-it-security.de/anmeldung/


Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

/von