Schlagwortarchiv für: BSI

Mit den Neuwahlen scheint die NIS2-Umsetzung in Deutschland vorerst gestoppt. Während andere europäische Länder schon bereit sind, müssen deutsche Firmen noch mehrere Monate warten, bis sich Rechtssicherheit einstellt. Dabei ist eigentlich alles gesagt, Vorlagen sind gemacht, doch durch den Regierungswechsel ist ein Neustart notwendig.

Wir haben mit einem der führenden Experten für NIS2 gesprochen: Dennis-Kenji Kipker ist Scientific Director des cyberintelligence.institute in Frankfurt am Main, Professor an der Riga Graduate School of Law und berät regelmäßig als Experte beim Bundesamt für Sicherheit in der Informationstechnologie (BSI) und vielen anderen öffentlichen und wissenschaftlichen Einrichtungen.

Warum hat die Bundesregierung den fertigen NIS2-Entwurf verworfen?

Porträt von Prof. Dr. Dennis-Kenji Kipker, Experte für IT-Recht und Cybersicherheit, im Interview zur Umsetzung der NIS2-Richtlinie

Prof. Dr. Dennis-Kenji Kipker

Kipker: Das liegt am sogenannten Diskontinuitätsprinzip. Genau wie bei der alten Regierung müssen da alle unerledigten Vorhaben archiviert werden. „Aufgrund der vorgezogenen Wahlen konnte das parlamentarische Verfahren zum NIS2UmsuCG nicht abgeschlossen werden“ heißt das im Amtsdeutsch. Im Sinne des Diskontinuitätsprinzips müssen mit der Konstituierung eines neu gewählten Bundestages alle vom alten Bundestag noch nicht beschlossenen Gesetzentwürfe neu eingebracht und verhandelt werden. Da fällt dann auch die bereits geleistete Arbeit zu NIS2 hinten runter. Aber man kann natürlich darauf aufbauen, könnte den fast gleichen Text erneut einbringen.

Wird das geschehen?

Kipker: Es gibt einen internen 100-Tage-Plan aus dem Bundesinnenministerium für die Zeit nach der Wahl. Gerüchten zufolge soll in dem Plan das Thema Cybersecurity sehr hoch aufgehängt sein, und gerade NIS2 soll jetzt sehr schnell umgesetzt werden. Wenn man es schafft, das vor Herbst/Winter 2025 (der eigentlich aktuelle Zeitplan) umzusetzen, vermeidet Deutschland zumindest die Peinlichkeit, hier europäisches Schlusslicht zu werden.

Ist das denn realistisch?

Kipker: Man müsste schon sehr viel recyclen, also trotz Diskontinuitätsprinzip Sachen aus der letzten Legislaturperiode übernehmen. Derzeit scheint es, als wolle das noch amtierende Innenministerium genau das erreichen. Ob das realistisch ist, wissen nur die direkt involvierten Politiker und Amtsträger. 100 Tage scheint mir im Berliner Politikbetrieb da aber schon sehr sportlich, auch wenn alle Beteiligten mitziehen. Man müsste einen Haushalt haben, im aktuellen NIS2UmsuCG-Entwurf Überarbeitungsbedarfe erkennen und angehen, aber auch finalisieren und den deutschen Anwendungsbereich des Gesetzes klarer fassen und an das EU-Recht angleichen. Überdies hat man zum Jahresende 2024 und zu Anfang 2025 noch nach der Expertenanhörung zu NIS2 im Bundestag vieles versucht durchzudrücken, was in Teilen doch eher fraglich ist. Das müsste in jedem Fall politisch neu verhandelt und fachlich bewertet werden.

Was schätzen Sie, wann das kommt?

Kipker: Schwer zu sagen, aber selbst, wenn man die 100-Tage-Frist reißt, sollte das schon machbar sein, eine nationale NIS2-Umsetzung vor dem Winter 2025/2026 fertigzustellen. Aber das ist nur eine sehr vorläufige Annahme, die ich immer wieder mal aus „gewöhnlich gut informierten Kreisen“ höre. Eines der Schlusslichter in der europaweiten Umsetzung werden wir so oder so werden, da ändern auch alle aktuellen Ambitionen nichts mehr dran.

Und wie schaut das in anderen europäischen Ländern aus?

Kipker: Da geschieht gerade auch einiges. Man hat beispielsweise erkannt, dass die unterschiedlichen nationalstaatlichen Umsetzungen von NIS2 zu Reibungsverlusten und Mehraufwänden bei den betroffenen Unternehmen führen – das kommt ja nun nicht wirklich überraschend. Es gibt seit einigen Wochen von der European Union Agency For Cybersecurity (ENISA) einen lesenswerten Bericht, der den Reifegrad und die Kritikalität relevanter NIS2-Sektoren im europäischen Vergleich erläutert und bewertet. „NIS360 soll die Mitgliedstaaten und nationalen Behörden bei der Ermittlung von Lücken und der Priorisierung von Ressourcen unterstützen“, schreibt die EU-Cybersicherheitsbehörde. Und wir als cyberintelligence.institute haben im Auftrag des Schweizer Unternehmens Asea Brown Boveri eine umfassende Studie erstellt, die ebenfalls die EU-weite Umsetzung der NIS2-Richtlinie genauer unter die Lupe nimmt.

Welche zentrale Erkenntnis haben Sie dort gewonnen?

Kipker: Der Comparison Report richtet sich vor allem an transnational agierende Unternehmen, die einen ersten Anlaufpunkt für Cybersecurity-Compliance suchen. Vor allem fehlen zentrale administrativen Zuständigkeiten im Sinne eines „One Stop Shop“, und die auseinanderlaufenden Umsetzungsfristen machen Unternehmen Probleme. Stand Ende Januar hatten nur neun EU-Staaten NIS2 in nationales Recht umgesetzt, während bei 18 weiteren Staaten das Gesetzgebungsverfahren noch nicht abgeschlossen war. Eine weitere zentrale Erkenntnis: Nur weil ich in einem EU-Mitgliedstaat NIS2-konform bin, bedeutet das nicht zwangsläufig, dass dies auch für einen anderen Mitgliedstaat gilt.

Dann ist Deutschland zwar kein Vorreiter, aber auch kein Schlusslicht?

Kipker: Wir sind definitiv nicht vorne dabei, aber wenn wir die nationale Umsetzung noch dieses Jahr schaffen, sind wir vielleicht nicht die letzten, aber doch unter den letzten. Meine Vermutung in dieser Hinsicht ist zurzeit: Erst im vierten Quartal 2025 wird es wirklich belastbare Ergebnisse geben. Es wird also knapp, nicht doch noch die rote Laterne umgehängt zu bekommen. Ob das unserem Anspruch an die Cybersicherheit und digitale Resilienz gerecht werden kann, müssen Politikerinnen und Politiker entscheiden.

Wo können sich betroffene Firmen denn über den aktuellen Stand informieren?

Kipker: Es gibt fortlaufend Veranstaltungen und Beteiligungsmöglichkeiten. Am 18. März beispielsweise findet eine Informationsveranstaltung des BSI statt, wo man auch mal nach den Planungen fragen kann. Dann gibt es im Mai 2025 auch den NIS-2-Congress direkt nebenan bei uns in Frankfurt, für den man übrigens gerade den „anerkanntesten NIS-2 Community Leader“ wählen konnte. Hier wird es mit Sicherheit auch das eine oder andere interessante Informationshäppchen aufzuschnappen geben. Ansonsten: Mich jederzeit gerne anschreiben, wenn es Fragen zu NIS2 gibt!

Webbrowser sind ein primäres Einfallstor für Unternehmen und folglich auch oft das erste Einfallstor für Cyberangriffe. Mithilfe von Malware, die auf Browser abzielt, könnten Angreifer direkten, unbefugten Zugriff auf das Netzwerk und die Daten eines Zielsystems erlangen. Sie könnten aber auch menschliche Opfer mit Social Engineering dazu bringen, sensible Informationen preiszugeben, um ihnen unbefugten Zugriff, etwa auf Kontodaten, zu gewähren. Im Jahr 2024 wiesen die wichtigsten Browser (Chrome, Firefox und Safari) 59 Schwachstellen mit kritischem Schweregrad (CVSS3 ³ 9) und 256 mit hohem Schweregrad (CVSS3 zwischen 7,0 und 8,9) auf. Zehn CVEs (Common Vulnerabilities and Exposures) aus der Dreiergruppe wurden in den KEV-Katalog (Known Exploited Vulnerabilities) der CISA (Cybersecurity & Infrastructure Security Agency) aufgenommen. Browser-Sicherheit sollte daher für Sicherheitsteams oberste Priorität haben.

Vor diesem Hintergrund sind wir stolz, die Erweiterung unserer Compliance-Funktionen um CIS Google Chrome Benchmark v3.0.0 Level 1 bekannt zu geben. Mit dieser neuesten Funktion können unsere Enterprise-Feed-Abonnenten ihre Google Chrome-Konfigurationen anhand des branchenführenden Compliance-Frameworks des CIS (Center for Internet Security) überprüfen. Die neuen Google Chrome-Benchmark-Tests werden neben unseren anderen CIS-Kontrollen in kritischen Cybersicherheitsbereichen wie Apache, IIS, NGINX, MongoDB, Oracle, PostgreSQL, Windows und Linux [1] [2] eingesetzt.

CIS Google Chrome Benchmark für Windows

Der CIS Google Chrome Benchmark v3.0.0 Level 1 ist jetzt im Greenbone Enterprise Feed verfügbar. Er legt eine gehärtete Konfiguration für den Chrome-Browser fest. Werden die Kontrollen für Windows implementiert, müssen auch Windows-Registry-Schlüssel gesetzt sein, um die Sicherheitskonfiguration von Chrome zu definieren. Eine kontinuierliche Überprüfung ist wichtig, denn wenn der Chrome-Browser auf Benutzerebene verändert wird, wird er anfälliger für Datenlecks, Social-Engineering-Angriffe oder andere Angriffsvektoren.

Unser Enterprise Vulnerability Feed nutzt Compliance-Richtlinien, um Tests auf den Endgeräten durchzuführen und jede Anforderung des CIS-Benchmarks durch einen oder mehrere spezielle Schwachstellentests zu überprüfen. Diese Tests werden in Scankonfigurationen gruppiert, die zur Erstellung von Scan-Aufgaben verwendet werden können, die dann auf Zielsystem-Gruppen zugreifen, um deren Sicherheitsstatus zu überprüfen. Greenbone unterstützt Sie bei der Einhaltung interner Risikovorgaben oder behördlicher Richtlinien.

Warum ist Browser-Security so kritisch?

Ein Großteil der wichtigen Informationen, die in einem durchschnittlichen Unternehmen fließen, wird über den Browser übertragen. Durch die Zunahme von Außendienstmitarbeitern und Cloud-basierten Webanwendungen sind Webbrowser die wichtigste Schnittstelle für geschäftliche Aktivitäten geworden. Es überrascht nicht, dass Internet-Browser in den letzten Jahren zu einer Brutstätte für Angriffe geworden sind. Nationale Cybersicherheitsbehörden wie das Bundesamt für Sicherheit in der Informationstechnik (BSI) [3] [4], das amerikanische CISA [5] [6] und das kanadische Zentrum für Cybersicherheit [7] haben allesamt Empfehlungen zum Umgang mit den von Internetbrowsern ausgehenden Risiken veröffentlicht.

Browser können über technische Schwachstellen und Fehlkonfigurationen ausgenutzt werden, die zu Remote Code Execution (RCE), zum Diebstahl sensibler Daten und zur Übernahme von Konten führen können, sind aber auch ein Einfallstor für Social-Engineering-Angriffe. Die Browsersicherheit muss durch die Implementierung eines gehärteten Sicherheitsprofils, dessen kontinuierliche Überprüfung und durch regelmäßige Updates zur Behebung neu entdeckter Schwachstellen gewährleistet werden. Greenbone kann bekannte Schwachstellen für veröffentlichte CVEs in allen wichtigen Browsern aufspüren. Mit unserer neuesten CIS Google Chrome Benchmark-Zertifizierung sind wir nun in der Lage, die Konformität von Browsern mit Industriestandards zu bestätigen.

Wie der CIS Google Chrome Benchmark die Browsersicherheit verbessert

Jeder CIS-Benchmark wird im Rahmen eines Konsensprüfungsprozesses entwickelt, an dem eine globale Gemeinschaft von Fachexperten aus verschiedenen Bereichen wie Beratung, Softwareentwicklung, Audit, Compliance, Sicherheitsforschung, Betrieb, Regierung und Recht beteiligt ist. Dieser gemeinschaftliche Prozess soll sicherstellen, dass die Benchmarks praxisnah und datengestützt sind und reales Fachwissen widerspiegeln. Somit sind die CIS-Benchmarks ein wichtiger Bestandteil eines soliden Cybersicherheitsprogramms.

Im Allgemeinen konzentrieren sich die CIS-Benchmarks auf sichere technische Konfigurationen und sollten zusammen mit grundlegenden Cyberhygiene-Praktiken verwendet werden, wie z. B. der Überwachung und dem zeitnahen Patchen von Schwachstellen in Betriebssystemen, Anwendungen und Bibliotheken.

Der CIS Google Chrome Benchmark definiert Sicherheitskontrollen wie zum Beispiel:

  • Keine Domäne kann die Überprüfung auf gefährliche Ressourcen wie Phishing-Inhalte und Malware umgehen.
  • Strenge Überprüfung der von Websites ausgestellten SSL/TLS-Zertifikate.
  • Verringerung der allgemeinen Angriffsfläche von Chrome, indem sichergestellt wird, dass die neuesten Updates regelmäßig automatisch eingespielt werden.
  • Der Chrome-Browser ist so konfiguriert, dass er das Abfangen von DNS erkennt, was möglicherweise DNS-Hijacking ermöglichen könnte.
  • Chrome und Erweiterungen können nicht mit anderer Software von Drittanbietern interagieren.
  • Websites und Browser-Erweiterungen können keine Verbindungen mit Medien, dem lokalen Dateisystem oder externen Geräten wie Bluetooth, USB oder Media-Casting-Geräten missbrauchen.
  • Es können nur Erweiterungen aus dem Google Chrome Web Store installiert werden.
  • Alle vom Chrome-Hauptprozess abgezweigten Prozesse werden angehalten, sobald die Chrome-Anwendung geschlossen wurde.
  • SafeSites Inhaltsfilterung blockiert Links zu nicht jugendfreien Inhalten in den Suchergebnissen.
  • Verhindern Sie den Import unsicherer Daten, wie z. B. automatisch ausgefüllte Formulardaten, Standard-Homepage oder andere Konfigurationseinstellungen.
  • Sicherstellen, dass kritische Warnungen nicht unterdrückt werden können.

Greenbone ist Mitglied des CIS-Konsortiums

Als Mitglied des CIS-Konsortiums entwickeln wir unsere CIS Benchmark-Scan-Konfigurationen ständig weiter. Alle entsprechenden Richtlinien sind an den CIS-Härtungsrichtlinien ausgerichtet und von der CIS zertifiziert, um maximale Sicherheit für System-Audits zu gewährleisten. Darüber hinaus haben wir mit dem Greenbone Security Assistant (GSA) eine neue Konformitätsansicht hinzugefügt, die den Prozess für Unternehmen vereinfacht, die Schwachstellen in ihrer Infrastruktur beseitigen wollen, um Sicherheitsverletzungen zu verhindern.

Zusammenfassung

CIS-Kontrollen sind entscheidend für den Schutz von Systemen und Daten, da sie klare, umsetzbare Anleitungen für sichere Konfigurationen bieten. Der CIS Google Chrome Benchmark ist besonders auf Unternehmensebene wichtig, wo Browser viele Arten sensibler Daten beeinflussen. Greenbone erweitert die branchenführenden Fähigkeiten zur Erkennung von Schwachstellen um einen neuen Compliance-Scan: den CIS Google Chrome Benchmark v3.0.0 Level 1. Mit dieser Zertifizierung stärkt Greenbone die Position als zuverlässiger Verbündeter für proaktive Cybersicherheit. Die neuesten Funktionen spiegeln unser Engagement für die Förderung der IT-Sicherheit und den Schutz vor sich entwickelnden Cyber-Bedrohungen wider.

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.

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.

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

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.

Vorschaubild zum Video ‚Was Sie zu NIS2 wissen müssen‘ mit europäischem Sternenkreis und NIS2-Schriftzug – leitet zu YouTube weiter

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.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

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

Nachdem Experten bereits 2023 einen rapiden Zuwachs bei Cyberangriffen auf Kommunen und Behörden feststellen mussten, hören die Schreckensmeldungen auch 2024 nicht auf. Der Handlungsdruck ist enorm, denn ab Oktober tritt die NIS2-Richtline der EU in Kraft und macht Risiko- und Schwachstellenmanagement zur Pflicht.

„Die Gefährdungslage ist so hoch wie nie“ sagt die Präsidentin des Bundesamtes für Sicherheit in der Informationstechnik (BSI), Claudia Plattner bei der Bitkom Anfang März. Die Frage sei nicht, ob ein Angriff erfolgreich ist, sondern nur wann. Auch die jährlichen Berichte des BSI, zum Beispiel der jüngste Report von 2023 sprächen da Bände. Auffällig sei aber, so Plattner, wie oft Kommunen, Krankenhäuser und andere öffentliche Institutionen im Mittelpunkt der Angriffe stünden. Aber es gebe „kein Maßnahmen- sondern ein Umsetzungsproblem in den Unternehmen und Behörden“.  Klar ist: Schwachstellenmanagement wie das von Greenbone kann dabei schützen und helfen, das Schlimmste zu vermeiden.

US-Behörden durch chinesische Hacker unterwandert

Angesichts der zahlreichen gravierenden Sicherheitsvorfälle wird das Schwachstellenmanagement von Jahr zu Jahr wichtiger. Knapp 70 neue Sicherheitslücken kamen in den letzten Monaten täglich hinzu. Einige von Ihnen öffneten tief in US-Behörden hinein Tür und Tor für Angreifer, wie im Greenbone Enterprise Blog berichtet:

Über gravierende Sicherheitslücken waren US-Behörden Medien zufolge seit Jahren durch chinesische Hackergruppen wie die wohl staatlich gesponserte „Volt Typhoon“ unterwandert. Dass Volt Typhoon und ähnliche Gruppierungen ein großes Problem sind, bestätigte sogar Microsoft selbst in einem Blog bereits im Mai 2023. Doch damit nicht genug: „Volt Typhoon macht sich die reichlich auftretenden Sicherheitslücken in VPN-Gateways und Routern der Marken FortiNet, Ivanti, Netgear, Citrix und Cisco zunutze. Diese gelten derzeit als besonders verwundbar“, war bei Heise zu lesen.

Dass der Quasi-Monopolist bei Office, Groupware, Betriebssystemen und diversen Clouddiensten 2023 auch noch zugeben musste, dass er sich den Masterkey für große Teile seiner Microsoft-Cloud hat stehlen lassen, zerstörte das Vertrauen in den Redmonder Softwarehersteller vielerorts. Wer diesen Key besitzt, braucht keine Backdoor mehr für Microsoft-Systeme, schreibt Heise. Vermutet werden hierbei ebenfalls chinesische Hacker.

Softwarehersteller und -Lieferanten

Die Lieferkette für Softwarehersteller steht nicht erst seit log4j oder dem Europäischen Cyber Resilience Act unter besonderer Beobachtung bei Herstellern und Anwendern. Auch das jüngste Beispiel um den Angriff auf den XZ-Komprimierungsalgorithmus in Linux zeigt die Verwundbarkeit von Herstellern. Bei der „#xzbackdoor“ hatte eine Kombination aus purem Zufall und den Aktivitäten von Andres Freund, ein sehr an Performance orientierter, deutscher Entwickler von Open-Source-Software für Microsoft, das Schlimmste verhindert.

Hier tat sich ein Abgrund auf: Nur dank der Open-Source-Entwicklung und einer gemeinsamen Anstrengung der Community kam heraus, dass Akteure über Jahre hinweg mit hoher krimineller Energie und mit Methoden, die sonst eher von Geheimdiensten zu erwarten sind, wechselnde Fake-Namen mit diversen Accounts benutzt hatten. Ohne oder mit nur wenig Benutzerhistorie bedienten sie sich ausgeprägter sozialer Betrugsmaschen, nutzen die notorische Überlastung von Betreibern aus und erschlichen sich das Vertrauen von freien Entwicklern. So gelang es ihnen, fast unbemerkt Schadcode in Software einzubringen. Nur dem Performance-Interesse von Freund war es schließlich zu verdanken, dass der Angriff aufflog und der Versuch scheiterte, eine Hintertür in ein Tool einzubauen.

US-Offizielle sehen auch in diesem Fall Behörden und Institutionen besonders bedroht, selbst wenn der Angriff eher ungezielt, für den massenhaften Einsatz ausgerichtet zu sein scheint. Das Thema ist komplex und noch lange nicht ausgestanden, geschweige denn vollumfänglich verstanden. Sicher ist nur: Die Usernamen der Accounts, die die Angreifer verwendet haben, waren bewusst gefälscht. Wir werden im Greenbone Blog weiter darüber berichten.

Europäische Gesetzgeber reagieren

Schwachstellenmanagement kann solche Angriffe nicht verhindern, aber es leistet unverzichtbare Dienste, indem es Administratoren proaktiv warnt und alarmiert, sobald ein derartiger Angriff bekannt wird – und dies meist, noch bevor ein Angreifer Systeme kompromittieren konnte. Angesichts aller Schwierigkeiten und dramatischen Vorfälle überrascht es nicht, dass auch Gesetzgeber die Größe des Problems erkannt haben und das Schwachstellenmanagement zum Standard und zur Best Practice in mehr und mehr Szenarien erklären.

Gesetze und Regulierungen wie die neue NIS2-Richtline der EU schreiben den Einsatz von Schwachstellenmanagement zwingend vor, auch in der Software-Lieferkette. Selbst wenn NIS2 eigentlich nur für etwa 180.000 Organisationen und Unternehmen der Kritischen Infrastruktur (KRITIS) beziehungsweise „besonders wichtige“ oder „bedeutende“ Unternehmen Europas gilt, sind die Regulierungen grundsätzlich sinnvoll – und ab Oktober Pflicht. Die „Betreiber wesentlicher Dienste“, betont die EU-Kommission, „müssen geeignete Sicherheitsmaßnahmen ergreifen und die zuständigen nationalen Behörden über schwerwiegende Vorfälle informieren. Wichtige Anbieter digitaler Dienste wie Suchmaschinen, Cloud-Computing-Dienste und Online-Marktplätze müssen die Sicherheits- und Benachrichtigungsanforderungen der Richtlinie erfüllen.“

Ab Oktober vorgeschrieben: Ein„Minimum an Cyber-Security-Maßnahmen“

Die „Richtlinie über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der gesamten Union (NIS2)“ zwingt Unternehmen der europäischen Gemeinschaft, einen „Benchmark eines Minimums an Cyber-Security-Maßnahmen zu implementieren“, darunter auch Risikomanagement, Weiterbildung, Policies und Prozeduren, auch und gerade in der Zusammenarbeit mit Software-Lieferanten. In Deutschland sollen die Bundesländer die genaue Umsetzung der NIS2-Regelungen definieren.

Haben Sie Fragen zu NIS2, dem Cyber Resilience Act (CRA), zu Schwachstellenmanagement allgemein oder den beschriebenen Sicherheitsvorfällen? Schreiben Sie uns! Wir freuen uns darauf, mit Ihnen zusammen, die richtige Compliance-Lösung zu finden und Ihrer IT-Infrastruktur den Schutz zu geben, den sie heute angesichts der schweren Angriffe benötigt.


Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

Wir bei Greenbone freuen uns sehr, in Zusammenarbeit mit dem Bundesamt für Sicherheit in der Informationstechnik (BSI) das Greenbone SMP-Bund-Portal einzuführen. Als führender Anbieter von IT-Sicherheitslösungen sind wir stolz darauf, diese speziell auf die Bedürfnisse der Bundesbehörden zugeschnittene Plattform anbieten zu können.

Ein Portal, das Maßstäbe setzt

Das Greenbone SMP-Bund-Portal ist die zentrale Anlaufstelle für IT-Sicherheit und Schwachstellenmanagement. Es wurde entwickelt, um Behörden konkrete Unterstützung bei den aktuellen Herausforderungen der IT-Sicherheit zu bieten.

Viele Vorteile für Bundesbehörden

  1. Einfach verständliche Einblicke: Das Portal bietet klare und anwenderfreundliche Informationen zum Schwachstellenmanagement. Es ist ideal sowohl für Einsteiger als auch für Experten in der IT-Sicherheit.
  2. Exklusive Rahmenvertragskonditionen: Bundesbehörden genießen spezielle Angebote und Vorzüge. Die Ausschreibungspflicht entfällt, was Zeit und Ressourcen spart.
  3. Persönlicher Support: Das kompetente Support-Team steht unseren Kunden stets zur Seite, um Fragen zu beantworten und Unterstützung zu gewährleisten.
  4. Direkter Draht zum Behörden-Sales Team: Fachkundige Beratung unseres Teams, das sich bestens mit den spezifischen Anforderungen für Bundesbehörden auskennt. Wir freuen uns auf die weitere vertrauensvolle Zusammenarbeit mit dem BSI und stehen für Rückfragen gerne zur Verfügung.
  5. Gelegenheit zum Austausch: Nutzen Sie das gemeinsame Forum um Ihre Erfahrungen und Fragen zu teilen.

https://smp-bund.greenbone.net/

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht

Für gleich zwei kritische Sicherheitslücken in verbreiteter Enterprise-Software haben unsere Entwickler Schwachstellentests bereitgestellt. Innerhalb kürzester Zeit konnten so Tests auf CVE 2023-22518 und CVE 2023-46747 integriert und die Kunden des Greenbone Enterprise-Feed geschützt werden.

Fehlerhaftes Login bei Atlassian Confluence und Jira

Die Wissensmanagementtools Confluence und Jira des australischen Herstellers Atlassian sind von einer gravierenden Sicherheitslücke mit 9,8 von 10 Punkten auf der CERT-Skala betroffen. Seit dem 8. November wird die Schwachstelle CVE 2023-22518 laut Medienberichten von Angreifern aktiv ausgenutzt, die sich unberechtigten Zugriff auf Firmendaten verschaffen.

Der „Fehler in der Authentifizierung“ betrifft laut Hersteller alle Versionen von Confluence Data Center und Server, nicht aber die Cloud-Variante bei Atlassian selbst. Für alle anderen, auch Anwender von Jira, vor allem aber alle öffentlich zugänglichen Confluence-Server bestehe „großes Risiko und der Zwang zum sofortigen Handeln“, schreibt Atlassian.

Unsere Entwickler reagierten schnell und wir konnten unseren Kunden entsprechende Tests bereitstellen, bevor Ransomware-Angriffe erfolgreich sein konnten. Kunden des Greenbone Enterprise Feeds wurden gewarnt und an einen Patch via Update erinnert.

Remote Code Execution: F5 BIG-IP erlaubt „Request Smuggling“

Ebenfalls Ende Oktober fanden Sicherheitsforscher der Praetorian Labs eine gravierende Lücke (CVE-2023-46747) in den Produkten des Application-Security-Experten F5. Die Lösungen des amerikanischen Herstellers sollen eigentlich umfangreiche Netzwerke und Softwarelandschaften beschützen. Vor allem in großen Unternehmen kommt die 1997 als Load Balancer gestartete Software zum Einsatz.

Angreifer können jedoch, so die Experten, aus der Ferne Code auf den BIG-IP-Servern ausführen lassen, indem sie über manipulierte URLs beliebige Systembefehle in die Administrationswerkzeuge schleusen. Details finden sich bei Praetorian, Patches sind vorhanden. Betroffen ist eine lange Liste von BIG-IP-Produkten der Versionen 13, 14, 15, 16 und 17, sowohl in Hard- als auch in Software.

Auch hier haben wir schnell reagiert und noch am gleichen Tag in unseren Schwachstellenscannern Tests integriert, die die BIG-IP-Installationen auf verwundbare Versionen testen und gegebenenfalls auf die bei F5 gelisteten Patches hinweisen.

Unser Schwachstellenmanagement, die Greenbone Enterprise Appliances, bieten besten Schutz.

Die professionelle Verwaltung von Schwachstellen ist ein unerlässlicher Bestandteil der IT-Sicherheit. Sie ermöglicht die frühzeitige Identifizierung von Risiken und liefert wertvolle Handlungsanweisungen für ihre Beseitigung.

Der Greenbone Enterprise Feed wird täglich aktualisiert, um stets neue Schwachstellen aufdecken zu können. Deshalb empfehlen wir eine regelmäßige Aktualisierung und das Durchführen von Scans für alle Ihre Systeme. Lesen Sie dazu auch diesen Artikel über IT-Sicherheit und über die Zeitleiste gängiger Angriffsvektoren.

Kontakt Kostenlos testen Hier kaufen Zurück zur Übersicht