Beiträge

Ein zweifelhafter Ruf haftet sowohl der Kryptowährung Bitcoin wie auch dem Darknet an. Medien schildern beide gerne als undurchsichtige, kriminelle Parallelwelten. Für Ransomware as a Service sind Bitcoin und Darknet willkommene Werkzeuge. Das organisierte Verbrechen hat sie sich längst zu Nutze gemacht, um seine Geschäfte zu verschleiern, auch wenn die Kriminellen damit keineswegs anonym und sicher vor Strafverfolgung sind.

Ransomware wurde 2021 zur weltweit größten Bedrohung von IT-Systemen. Wer sich erfolgreich davor schützen will, muss auch verstehen, wie die Beteiligten vorgehen. Im ersten Teil dieser Artikelserie ging es um das Geschäftsmodell von Ransomware as a Service. Teil zwei zeigte, warum diese „Professionalisierung“ auch zu einem veränderten Mindset bei den Angreifenden führt. Der dritte Teil erklärt nun, warum die IT-Werkzeuge, die die organisierte Kriminalität zur Bestellung und zur Geldübergabe nutzt, keineswegs sicher sind.

Ransomware as a Service: abstraktes Bild des Bitcoin-Logos

Anonym und sicher?

Bitcoin als Zahlungsmittel und das Darknet erweisen sich als praktisch, hilfreich und attraktiv für Angreifende. Unter dem Deckmantel der vermeintlichen Anonymität wähnen sie sich geschützt vor Strafverfolgung und abgeschirmt von Konsequenzen. Doch das ist ein verbreitetes Missverständnis: Weder Bitcoin noch Darknet sind in der Praxis anonym.

Während die Kryptowährung nie auf Anonymität ausgelegt war, sondern explizit auf Nachvollziehbarkeit von Transaktionen auch ohne zuverlässige zentrale Autorität, erweist sich das Darknet als nicht mal ansatzweise so anonym wie seine Macher es sich gewünscht hätten. Das zeigen auch Berichte wie die jüngsten über die „Deanonymisierungsangriffe“ von KAX17 auf das Tor-Netzwerk. Fast immer reicht der Strafverfolgung klassische Ermittlungsmethoden, um auch Ransomware-Agierende wie die REvil-Gruppe ausfindig zu machen. Die hatte laut Heise in mehr als 5.000 Infektionen eine halbe Million Euro an Lösegeldern eingetrieben.

Nie eine gute Idee: mit Kriminellen kooperieren

Egal, ob online oder offline, wer sich mit Erpressenden einlässt, ist verlassen. Als guter Rat gilt wie im richtigen Leben: niemals Lösegeld bezahlen. Ganz egal wie professionell die Hotline am anderen Ende auch scheint, Vertrauen ist nicht angebracht. Die Betreibenden von REvils Ransomware as a Service beispielsweise stahlen ihren Auftraggebenden sogar die erpressten Lösegelder über eine Backdoor in der Malware.

Dabei hatte alles so freundlich und idealistisch angefangen. Roger Dingledine und Nick Mathewson legten die Grundsteine für das Tor-Netzwerk Anfang der 2000er Jahre. Basierend auf der Idee der Zwiebelringe sollten zahlreiche kryptographisch gesicherte Schichten übereinander für zuverlässige Anonymität im Web sorgen – ihrer Meinung nach ein Grundrecht, analog zur Privacy-Definition von Eric Hughes „Cypherpunk’s Manifesto“. 2009 erblickte dann Bitcoin das Licht der Welt, erstmals beschrieben durch die fast schon mystische Figur des Satoshi Nakamoto.

Darknet und Bitcoin sind nicht „kriminell“

Weder Darknet noch Bitcoin wurden entworfen, um dunkle Machenschaften zu verschleiern oder zu ermöglichen. Ziel war das Schaffen freier, unabhängiger, vermeintlich unkontrollierbarer und weitgehend sicherer Strukturen für Informationsaustausch und Bezahlung. Wie ein Messer lassen sich die Dienste jedoch sowohl für Gutes als auch für Böses instrumentalisieren – und natürlich weiß die organisierte Kriminalität das für sich zu nutzen. Nicht immer liegt dabei der Schwerpunkt darauf, keine Spuren zu hinterlassen. Meist steht die Einfachheit und Verfügbarkeit der Mittel im Vordergrund. Bitcoin und das Darknet sind schlicht die Tools der Wahl, weil sie da sind.

Aber wie in der realen Welt schnappt man die Erpressenden am einfachsten bei der Geldübergabe: Eine Blockchain wie Bitcoin dokumentiert alle jemals getätigten Transaktionen inklusive der Wallet-Informationen (also den Bitcoin-Besitzenden) und macht sie jederzeit einsehbar. Gleiches gilt für das Darknet: Selbst, wenn technisch Anonymität möglich ist, scheitern Menschen regelmäßig an den einfachsten Anforderungen. Da finden sich dann GPS-Meta-Daten in Fotos oder UPS-Codes im illegalen Shop. Der legendäre Drogenshop Silkroad flog auf, weil Mitarbeitende Fehler machten und geständig waren.

Digitalisierte, organisierte Kriminalität

Das Darknet und die Kryptowährungen sind hilfreiche Werkzeuge für die organisierte Kriminalität und damit Brandbeschleuniger für die schnell wachsende Anzahl an gravierenden Ransomware-Attacken. Aber sie sind keineswegs essenziell, noch trifft sie eine Schuld. Derartige Cyber-Kriminalität ist nur die moderne IT-Variante dessen, was wir auch auf den Straßen beliebiger Großstädte erleben können. Ransomware ist sozusagen die moderne Schutzgelderpressung, Bitcoin der Abfalleimer für die Übergabe, das Darknet die dunkle Kneipe, in der Deals vereinbart werden.

Das Perfide steckt nicht in den Werkzeugen, sondern in den Methoden und der langen Erfahrung im „Business“. Trend Micro beschreibt beispielsweise den Ansatz der „Double Extortion Ransomware“. Dabei machen sich Angreifende erst ein Bild über die Daten und drohen, diese bei Nicht-Bezahlen (also bei Nicht-Entschlüsselung) zu veröffentlichen. Organisierte Kriminalität betreibt das Geschäft mit der Erpressung nicht erst seit es Bitcoin oder das Darknet gibt. Auch wenn die beiden Technologien es Cyber-Kriminellen heute ermöglichen, zunächst unerkannt große Geldsummen zu erpressen, reichen herkömmliche Methoden fast immer zur Aufklärung. Wichtigste Voraussetzung dabei ist, dass genug Personal für die Strafverfolgung zur Verfügung steht, nicht in erster Linie dessen technische Ausstattung.

Vorsorge treffen

Doch zu diesem Zeitpunkt ist das Kind im Unternehmen bereits in den Brunnen gefallen. Wer vor seinen verschlüsselten Daten steht und sich einer Lösegeldforderung gegenübersieht, dem sind das Darknet, Bitcoin und die Aufklärungsquote vermutlich erst mal zweitrangig. Viel wichtiger ist die Frage, wie man aus der misslichen Lage wieder herauskommt. Und das gelingt nur, wenn man vorbereitet war. Dazu gehören Backups, Restore-Tests und das sofortige Abtrennen aller betroffenen Maschinen (Network Split) – also proaktives Risikomanagement, Desaster Recovery Tests und stetige Pflege der eigenen Systeme. Ein weiterer wichtiger Baustein ist die Multi-Faktor-Authentifizierung, die verhindert, dass sich Angreifende allein durch erworbene Passwörter von einem System zum nächsten hangeln.

Am wichtigsten ist es jedoch, gar nicht erst in kritische Situationen zu gelangen und Schwachstellen in den eigenen Systemen zu erkennen und schnell zu schließen. Modernes Schwachstellenmanagement wie das von Greenbone leistet genau das: Es legt Angreifenden Steine in den Weg und macht das Firmennetzwerk unattraktiv, aufwändig und somit abschreckend für die professionellen Cyber-Kriminellen, nicht nur aus der Ransomware-as-a-Service-Welt.

Die Produkte von Greenbone überwachen das Unternehmensnetzwerk oder externe IT-Ressourcen auf potenzielle Schwachstellen, indem sie es fortlaufend und vollautomatisch untersuchen und garantieren als Greenbone Enterprise Appliances oder dem Greenbone Cloud Service (in deutschen Rechenzentren gehostete Software as a Service) Sicherheit durch stets aktuelle Scans und Tests.

Wie das funktioniert, beschreibt Elmar Geese, CIO/CMO bei Greenbone, ebenfalls hier im Blog anhand eines Posts rund um die log4j-Schwachstelle. Außerdem erklärt Geese, wie schnell und sicher die Administration und das Management auch bei den neuesten Schwachstellen informiert wird und wie genau der Scan nach Schwachstellen wie Log4Shell abläuft.


Wir sind stolz darauf, dass wir Ende 2021 die ISO-Zertifizierung unserer Managementsysteme für die Aspekte Qualität (ISO 9001) und Informationssicherheit (ISO 27001) erhalten haben.

Logos der ISO-Zertifizierung unserer Managementsysteme

Unser Erfolg lässt uns wachsen, und unser Wachstum fördert Strukturen und Prozesse. Deshalb begleiten wir aktiv die Entstehung von Strukturen und Prozessen noch stärker als in der Vergangenheit. Dabei orientieren wir uns an den folgenden Zielen:

  • Werte für unsere Kundschaft schaffen
  • Großartige Produkte und Dienstleistungen bereitstellen
  • Die Zufriedenheit unserer Mitarbeitenden stetig steigern
  • Förderung und Bewältigung unseres Wachstums

Als wir uns entschlossen haben, die Informationssicherheit und Qualität in unserem Unternehmen nach den Normen ISO 27001 und ISO 9001 zu zertifizieren, haben wir von Anfang an die Besonderheiten eines agilen Unternehmens berücksichtigt.

ISO-zertifizierte Managementsysteme und agiles Management scheinen ein Widerspruch zu sein, sind es aber nicht. In diesem Artikel werden wir kurz erläutern, wie sich diese beiden Welten perfekt ergänzen und wie wir die jeweiligen Vorteile in einem Unternehmen vereinen.

Obwohl Agilität kein Ziel an sich ist, waren wir uns bewusst, dass wir ein agiles Unternehmen auf eine agile Weise führen wollen. Wir verstehen das so:

  • Wir haben ein gemeinsames Ziel.
  • Klarheit und Eindeutigkeit in der Kommunikation sind Voraussetzung für ergebnisorientiertes Handeln.
  • Hierarchien sind Werkzeuge, keine Statusfunktionen.
  • Prozesse sind Wege zum Ziel, nicht Ziele an sich.

Wir haben erkannt, dass wir in den verschiedenen Bereichen unserer Organisation idealerweise einen möglichst universellen Werkzeugkasten einsetzen können, der uns einerseits hilft, unsere Prozesse bestmöglich zu organisieren und andererseits genügend Freiraum für die unterschiedlichen Bedürfnisse der verschiedenen Teams und Bereiche lässt.

Die Konzepte aus so unterschiedlichen Welten wie „ISO“ und „Agile“ haben uns dabei geholfen und helfen uns weiterhin. Sie haben gemeinsam, dass die Konzepte Managementsysteme erfordern, die in ihrer Grundstruktur ähnlicher sind, als man denkt.

Es geht immer um:

  • Fokussierung auf hinreichend klar definierte Ziele
  • Verlässliche und angemessene Leitlinien
  • Nachvollziehbar definierte und hilfreiche Prozesse
  • Messpunkte, um zu bewerten, anzupassen und ggf. zu verändern
  • Unterstützende Teammitglieder und dienende Führungskräfte, die innerhalb dieser Struktur agieren
  • Ein kontinuierlicher Verbesserungsprozess

Dies ist es, was wir ein Managementsystem nennen und die ihm innewohnende Agilität wird durch den Kontext und den Zweck definiert, wenn es angewendet wird. Es ermöglicht uns, die Ergebnisse und die Qualität der Prozesse anhand eines Systems von Zielen und Leistungsindikatoren zu messen.

Wir sind stolz und glücklich, dass wir unsere Managementsysteme nun sehr erfolgreich für die Aspekte „Qualität“ (ISO 9001) und „Informationssicherheit“ (ISO 27001) zertifizieren konnten. Es hilft uns und es hilft auch Ihnen als unsere Kundschaft. Es dokumentiert messbar zwei sehr wichtige Eigenschaften, die Sie von uns und unseren Produkten und Dienstleistungen erwarten und die Sie letztlich durch den Einsatz unserer Produkte in Ihrer eigenen Organisation sicherstellen wollen, nämlich:

  • Sicherheit und
  • Qualität der informationstechnischen Systeme

Es ist unsere Aufgabe bei Greenbone, dies durch eines der führenden Produkte für das Schwachstellenmanagement zu gewährleisten. Das tun wir jeden Tag, in über 100.000 Organisationen auf der ganzen Welt.


Update vom 20.12.2021: Informationen über weitere Schwachstellen, die für Log4j gefunden wurden, finden Sie hier.


Update vom 20.12.2021: Es sind nun auch Schwachstellentests für Produkte unter Microsoft Windows verfügbar.

Hinweis: Die Tests prüfen die Existenz von Log4j und dessen Version. Ein separater Schwachstellentest ist möglicherweise nicht für jede betroffene Anwendung verfügbar, aber alle Log4j-Dateien werden gefunden und gemeldet (/pfad-zur-log4j-datei/).

Die ausgegebenen Installationspfade müssen geprüft und ggf. der Hersteller kontaktiert werden. Es muss geprüft werden, ob für die jeweilige Anwendung bereits Updates verfügbar sind und ob der Fund relevant ist.

PowerShell-Ausführungsberechtigungen auf einem Zielsystem sind für den Account erforderlich, der in einem authentifizierten Scan verwendet wird. Einige Schwachstellentests führen PowerShell-Befehle aus, um die Genauigkeit der Ergebnisse zu erhöhen, wofür Berechtigungen für die Dauer eines Scans erforderlich sind.


Update vom 15.12.2021: ein zusätzlicher Angriffsvektor wurde identifiziert und in CVE-2021-45046 gemeldet. Wir arbeiten an Schwachstellentests für diesen Vektor, obwohl unsere Tests auch für diesen zusätzlichen Fall funktionieren. Wir empfehlen, auf die neueste Log4j-Version zu aktualisieren. Der Angriff ist komplizierter und ein Schutz erfordert eine andere Konfiguration. Da es sich aber um einen sehr neuen Vektor handelt, raten wir, besser auf Nummer sicher zu gehen. Mehr Informationen unter https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.


Dieser Artikel enthält Antworten auf die am häufigsten gestellten Fragen zu Greenbones Log4j-Schwachstellentests.

Worum handelt es sich bei der Log4j-Schwachstelle?

Die „Log4Shell“-Schwachstelle betrifft eine Softwarebibliothek, die für die Aufzeichnung von Ereignissen (das so genannte „Logging“) in Software zuständig ist, die in der Programmiersprache Java geschrieben wurde. Böswillige Angreifende können diese Sicherheitslücke nutzen, um Code auf den betroffenen Systemen auszuführen.

Da diese Schwachstelle über das Internet und ohne jegliche Authentifizierung ausgenutzt werden kann, kann dies für betroffene Systeme und Unternehmen sehr kritisch sein. Da die Software auch in einer Vielzahl von Software und Diensten enthalten ist, die über das Internet zugänglich sind, sind wahrscheinlich viele Unternehmen und Dienste betroffen.

Weitere Informationen zu dieser Sicherheitslücke finden Sie hier:

Sind Greenbone-Produkte und -Dienste betroffen?

Wir haben den Status der möglicherweise betroffenen Systeme mit höchster Priorität überprüft. Keine unserer Produkte oder intern und extern erbrachten Dienstleistungen sind betroffen.

Können Greenbone-Produkte diese Schwachstelle erkennen?

Ja, Schwachstellentests wurden in den Greenbone Community Feed und in den Greenbone Enterprise Feed integriert, beginnend mit Feed-Version 202112130808. Dies bedeutet, dass sowohl unsere Appliances als auch unser Cloud-Produkt in der Lage sind, diese Sicherheitslücke zu erkennen.

Es sind zwar Schwachstellentests verfügbar, aber aufgrund der Komplexität dieser Sicherheitslücke kann nicht garantiert werden, dass eine Erkennung jedes einzelne betroffene System oder Produkt findet. Dies gilt insbesondere für nicht-authentifizierte „Remote“-Überprüfungen, und zwar aus den folgenden Gründen:

  • Das Produkt oder der Dienst könnte nur unter ganz bestimmten Umständen verwundbar sein. Da die Log4j-Bibliothek sehr komplex und hochgradig konfigurierbar ist und in vielen Produkten unterschiedlich eingesetzt wird, ist es nicht möglich, alle verwundbaren Instanzen durch eine Remote-Prüfung zu finden.
  • Sicherheitskonfigurationen im zu scannenden Netzwerk können eine erfolgreiche Überprüfung der Schwachstelle verhindern.
  • Produkte und Dienste können auch indirekt betroffen sein.

Eine spezielle Scan-Konfiguration zur direkten und schnellstmöglichen Erkennung dieser Sicherheitslücke ist ebenfalls über beide Feeds verfügbar. Bitte beachten Sie, dass die aktuelle Scan-Konfiguration nur aktive Prüfungen (remote und lokal) enthält. Paketversionsprüfungen sind nicht enthalten, um die Scan-Konfiguration und damit die Scanzeit minimal zu halten.

Ist die Erkennung im Greenbone Community Feed enthalten?

Ja. In beiden Feeds ist eine grundlegende Erkennung der Sicherheitslücke enthalten. Zusätzliche Schwachstellentests für potenziell betroffene Unternehmensprodukte sind über den Greenbone Enterprise Feed verfügbar.

Welche Erkennung ist in welchem Feed enthalten?

Greenbone Enterprise Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Enterprise Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
  • Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
  • Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
  • Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
  • VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
  • ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
  • Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
  • Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
  • Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
  • SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
  • IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)
Greenbone Community Feed

Wir implementieren fortlaufend Schwachstellentests in den Greenbone Community Feed, daher kann die folgende Liste unvollständig sein, gibt aber den Stand vom 14.12.2021, 12:00 Uhr wieder.

Wichtig: Um die aktuellsten Informationen zu Ihrer Installation zu erhalten, können Sie nach  ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation suchen.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Consolidation of Apache Log4j detections
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

Über authentifizierte/unauthentifizierte Tests

Für einige Versionsprüfungen ist eine Authentifizierung erforderlich, für andere nicht. Außerdem können einige beides haben.

Die entsprechenden Informationen sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Die „Qualität der Erkennung“ enthält Informationen über die Erkennungsmethode. Ein Wert von „package (97 %)“ deutet auf eine authentifizierte Prüfung hin, andere Werte wie „remote_banner (80 %)“ geschehen unauthentifiziert.

Weitere technische Informationen hierzu finden Sie unter https://docs.greenbone.net/GSM-Manual/gos-21.04/de/reports.html#quality-of-detection-concept.

Über aktive Tests/Testprüfungsversion, QoD

Sie können anhand des QoD und der „Erkennungsmethode“ auf der Web-Oberfläche erkennen, ob es sich um eine aktive Prüfung handelt, wenn Sie sich die Details des Schwachstellentests anzeigen lassen.

Hinweis: Nur Systeme, die tatsächlich Eingaben protokollieren, die von Angreifenden verändert werden können (z. B. bestimmte HTTP-Anfrage-Header, URLs, …), sind verwundbar.

Die Erkennungsmethode, die Qualität der Erkennung, die Schadensminderung und viele weitere Details sind über die Links verfügbar, die bei der Suche nach ~CVE-2021-44228 im Abschnitt „CVE“ und „NVTs“ des Menüs „SecInfo“ auf der Web-Oberfläche Ihrer Installation angezeigt werden.

Scannen nach Knoten auf separaten VRFs & VLANs

  • Out-of-band-Scanning (OOB) ist derzeit nicht möglich. Bitte scannen Sie in jedem Segment.
  • Wir denken, dass eine solche Out-of-band-Kommunikation (OOB)/externe Interaktionsmöglichkeit in Zukunft integriert werden kann.


Der zweite Teil unserer Serie über die fortschreitende Professionalisierung der Angriffe auf IT-Systeme beschäftigt sich mit Veränderungen im Mindset der Angreifenden. Automatisierung, Kommerzialisierung und Cloudcomputing haben Ihre Spuren auch im typischen Profil von Cyber-Kriminellen hinterlassen, mit denen sich Admins und das Schwachstellenmanagement auseinandersetzen müssen. Entgegen gängiger Hollywoodklischees geht die Bedrohung durch Ransomware as a Service in der Regel nicht (mehr) von hochbegabten Script-Kiddies mit viel Zeit oder von anarchistischen Weltverbesserern im Hoodie aus. Auch nicht von hochqualifizierten und mit schier endlosen Ressourcen ausgestatteten Geheimdiensten.

Angriffe sind heute Auftragsarbeiten

Die gefährlichsten Angriffe heute arbeiten zunehmend „im Auftrag“, verfolgen also ein Geschäftsmodell und müssen sich dabei auch an Werten wie Effizienz oder Erfolgswahrscheinlichkeit orientieren. Genauso wie das Cloud-Computing fester Bestandteil der IT der meisten Unternehmen geworden ist, dient es mittlerweile auch Cyber-Kriminellen dazu, Angriffe zu automatisieren, zu organisieren und zu beschleunigen. Mit großem Erfolg: Ransomware ist zur größten Bedrohung erwachsen und bei Ransomware as a Service lassen sich Angriffe ganz einfach buchen.

Mehr und mehr Sicherheitsfachleute entwickeln gerade erst ein Verständnis für die Geschäftsmodelle der Angreifenden: Deren Logik unterscheidet sich kaum mehr von der anderer Unternehmen. Sie investieren die gleichen Ressourcen in die Entwicklung von Exploits und Tools und wollen den höchstmöglichen Return on Investment (ROI) erzielen. Deswegen achten sie häufig stark darauf, dass sich ihre Werkzeuge wiederverwenden lassen.

Angesichts begrenzter Ressourcen entwickeln Cyber-Kriminelle Exploits für weit verbreitete Technologien, die ein hohes Gewinnpotenzial für mehrere Ziele bieten.

Die Perspektive der Cyber-Kriminellen

Die Angreifenden haben sich organisiert, bestellt wird im Darknet, bezahlt via Bitcoin. Gewinnmaximiert, effizienzorientiert und professionell strukturiert: Die neue, wirtschaftlich orientierte Logik kann und muss aber auch ein Schlüssel zu besseren Abwehrmechanismen sein. Gerade wenn Security-Verantwortliche sich unter einer Lawine von Sicherheitswarnungen begraben sehen, ist es hilfreich, zu verstehen, wie Cyber-Kriminelle „ticken“.

Um die eigenen Systeme abzusichern, muss die Verteidigung jetzt umdenken und über den eigenen Tellerrand blicken. Die Logik der Cyber-Kriminellen hilft, die entscheidenden Signale zu entschlüsseln und Lücken zu schließen. David Wolpoff, CTO von Randori, hat in einem Blogbeitrag auf Threatpost sechs zentrale Fragen formuliert, die das Mindset der modernen Cyber-Kriminellen gut beschreiben:

  1. Welche nützlichen Informationen über ein Ziel lassen sich von außen erkennen?
  2. Wie wertvoll ist das Ziel für die Angreifenden?
  3. Ist das Ziel als leicht zu hacken bekannt?
  4. Welches Potenzial bieten Ziel und Umgebung?
  5. Wie lange wird es dauern, einen Exploit zu entwickeln?
  6. Gibt es einen wiederholbaren ROI für einen Exploit?

Je mehr Wissen Cyber-Kriminelle über eine Technologie oder eine Person in einem Unternehmen sammeln können, desto besser können sie die nächste Angriffsphase planen. Im ersten Schritt stellen sie so die Frage, wie detailliert sich das Ziel von außen beschreiben lässt. Je nach Konfiguration kann ein Webserver beispielsweise keine Serverkennung oder Servernamen und detaillierte Versionssnummern verraten. Ist die genaue Version eines verwendeten Dienstes und seine Konfiguration sichtbar, lassen sich präzise Exploits und Angriffe ausführen. Das maximiert die Erfolgschancen und minimiert zeitgleich die Entdeckungswahrscheinlichkeit und die Aufwände.

Nicht mehr wahllos

Das zunehmend wichtigere wirtschaftliche Interesse sorgt dafür, dass Cyber-Kriminelle Faktoren wie Aufwand, Zeit, Geld und Risiko stärker berücksichtigen müssen. Dementsprechend lohnt es sich nicht, wahllos Systeme anzugreifen oder auszuspähen. Angreifende klären heutzutage zuerst den potentiellen Wert, bevor sie handeln und konzentrieren sich auf vielversprechende Ziele wie VPNs und Firewalls, Anmeldedatenspeicher, Authentifizierungssysteme oder Remote-Support-Lösungen am Netzwerkrand. Die könnten sich als Generalschlüssel entpuppen und den Weg ins Netzwerk oder zu Anmeldeinformationen aufsperren.

Immer wieder tauchen Meldungen über kritische und brandgefährliche Schwachstellen auf, die offenbar niemand für Angriffe ausgenutzt hatte. Es klingt unglaublich, aber oft hat sich einfach niemand die Arbeit gemacht, für eine Schwachstelle einen Exploit zu programmieren. Moderne Cyber-Kriminelle folgen immer mehr dem Prinzip des Return on Investment und bedienen sich existierender Proof of Concepts (PoC).

Komplexität ist unerwünscht

So ergeben sich manchmal überraschende Erkenntnisse: Moderne Cyber-Kriminelle meiden wohldokumentierte Schwachstellen. Umfangreiche Untersuchungen und Analysen zu einer bestimmten Sicherheitslücke sind eher ein Indikator für unerwünschte Komplexität und Aufwand, den man möglichst gering halten möchte. RaaS-Hacker:innen fahnden nach verfügbaren Tools oder kaufen für ein bestimmtes Objekt bereits erstellte Exploits. Angreifende wollen sich unbemerkt in den von ihnen kompromittierten Systemen bewegen. Sie suchen sich also Ziele mit wenigen Abwehrmechanismen aus, wo Malware und Pivoting-Tools funktionieren, etwa Desktop-Telefone und VPN-Apps sowie andere ungeschützte Hardware. Viele Anwendungen dort sind mit oder für Linux erstellt, besitzen einen vollständigen Nutzungsbereich und verfügen über vertrauenswürdige, vorinstallierte Tools. Das verspricht, sie nach einem Exploit weiterhin nutzen zu können und macht sie umso attraktiver für Cyber-Kriminelle.

Überraschende Kosten-Nutzen-Rechnung

Ist das Ziel erst einmal anvisiert, gilt es für Angreifende Zeit, Kosten und Wiederverwendbarkeit einzuschätzen. Schwachstellenforschung (Vulnerabilty Research) geht hierbei auch über das bloße Aufdecken ungepatchter Geräte hinaus. Cyber-Kriminelle müssen beurteilen, ob die Kosten für die Recherche und Entwicklung der daraus resultierenden Tools im Verhältnis zum Gewinn nach einer Attacke stehen. Gut dokumentierte Software oder Open-Source-Tools, die leicht zu beschaffen und zu testen sind, bedeuten ein vergleichsweise leichtes Ziel.

Ebenfalls überraschend: Insgesamt spielt laut Wolpoff der Schweregrad einer Sicherheitslücke für Cyber-Kriminelle nicht die zentrale Rolle. Einen Angriff zu planen ist weit komplexer und erfordert wirtschaftliches Denken. Die Erkenntnis, dass auch die Gegenseite Kompromisse eingehen muss, hilft der Verteidigung von Cloud-Umgebungen, diese sinnvoll abzusichern. Alles, überall und jederzeit vor allen Angreifenden zu schützen ist illusorisch. Mehr wie sie zu denken, erleichtert aber die Priorisierung.

Im dritten Teil dieser Artikelserie dreht sich alles um die Frage, ob das Ransomware-as-a-Service-Modell auch ohne Bitcoin und Darknet möglich wäre und ob die beiden Technologien eigentlich in dem Kontext halten, was die Angreifenden versprechen.

Immer wieder werden deutsche Behörden und Kommunen Ziele von Cyber-Angriffen. Der anschließende Wiederaufbau dauert oft mehrere Monate. Mit einem Schwachstellenmanagement kann das Risiko von Cyber-Angriffen drastisch reduziert werden – denn durch das Beseitigen von Schwachstellen wird Angreifenden die notwendige Grundlage genommen. Auch das Schwachstellenmanagement von Greenbone schützt Behörden – zu Sonderkonditionen.

Landkreise und Krankenhäuser gehackt, ganze IT-Infrastrukturen liegen lahm, zu behandelnde Personen werden ausgelagert, die Bundeswehr muss helfen: Was vor wenigen Jahren noch apokalyptisch anmutete, wurde im Sommer 2021 verstörende Realität. Zum ersten Mal in der deutschen Geschichte wurde der Katastrophenfall ausgerufen, weil sich Angreifende erfolgreich Zugriff auf die Netzwerke von Behörden oder deren Dienstleistenden verschafft hatten. Schwerin, Witten, Bitterfeld, Ludwigslust: Die Liste ist lang und nur großflächiges Deaktivieren der Server half den Betroffenen.

Abschalten hilft nur akut, der Neuaufbau dauert Monate

Wer sind die Angreifenden? Nicht immer ist es im digitalen Raum möglich, die Personen zu finden, die hinter den Taten stecken, sogar dann, wenn erpresserische Geschäftsmodelle und Lösegeldforderungen vorliegen. Meldepflichten und IT-Sicherheitsgesetze helfen den Betroffenen auch nicht konkret dabei weiter, denn der Schaden ist bereits entstanden: In der Regel wissen die Opfer noch nicht einmal gesichert, ob sie gezielt oder per Zufall angegriffen wurden. Die Schadenssummen sind immens, manche Behörden sind Monate mit dem Aufräumen und Wiederherstellen beschäftigt, nicht selten müssen ganze Systemlandschaften neu aufgebaut werden.

Dekoratives Bild einer Behörde

Cyber-Kriminelle nutzen Schwachstellen, die bereits gefixt waren

Warum aber fällt es Angreifenden so leicht, in fremde Netze einzudringen? Die meisten Angriffe, vor allem automatisierte, nutzen eigentlich schon lange geschlossene Schwachstellen für die Einbrüche.

Das funktioniert derzeit so gut, weil sich durch Systempflege allein nicht alle Systeme ausreichend auf Angriffe vorbereiten lassen. Schwachstellen können in Produkten, Systemkomponenten oder deren Konfiguration verborgen sein, die sich in den üblichen Infrastrukturen zu vielen tausenden Angriffspunkten summieren. Da stehen Hintertüren offen, die Angreifende aufspüren können, oft mit relativ einfach zu handhabenden Werkzeugen.

Schwachstellenscanner informieren und helfen, Lücken zu schließen

Dabei sind Admins, Behörden und Firmen keinesfalls machtlos. Was zählt, ist das Wissen über Verwundbarkeiten, Schwachstellen oder offene Flanken in den Netzwerken. Mit den richtigen Tools sind Sie Cyber-Kriminellen immer einen Schritt voraus, weil sie die Lücken Ihrer IT-Verteidigung erkennen, bevor Cyber-Kriminellen dies gelingt – mit den Greenbone-Lösungen klappt das kontinuierlich und automatisch.

Greenbone-Enterprise-Produkte untersuchen fortlaufend das Unternehmensnetzwerk oder externe IT-Ressourcen auf potenzielle Schwachstellen. Die speziell gehärtete Appliances – virtuell oder als Hardware verfügbar – oder der als Software-as-a-Service verfügbare Greenbone Cloud Service garantieren täglich aktuelle Updates zu den neuesten Schwachstellen. Admins und IT-Management werden bei Bedarf sofort informiert, wenn sich bedrohliche Sicherheitslücken offenbaren.

Sonderkonditionen für Behörden

Das erkennen auch mehr und mehr Behörden, die sich im Kampf gegen Cyber-Attacken für Greenbone entscheiden. Greenbone schützt Behörden zu Sonderkonditionen und die Lösungen können einfach über das Kaufhaus des Bundes beschafft werden.

 


Mithilfe der Greenbone-Produkte können bekannte Schwachstellen in einer IT-Infrastruktur aufgespürt werden, um sie anschließend zu beseitigen. Den Schweregrad einer Schwachstelle zu bewerten, ist ein essenzielles Hilfsmittel, um die nachfolgenden Beseitigungsmaßnahmen zu planen und zu priorisieren. CVSS bietet solch eine Bewertung nach einem Kennzahlensystem. Seit 2021 unterstützen die aktuellen Greenbone-Lösungen auch die CVSS-Versionen 3.0 und 3.1. Zur selben Zeit hat Greenbone begonnen, alle Schwachstellentests, für die eine entsprechende Bewertung verfügbar ist, mit dieser zu versehen. Seit Oktober 2021 ist diese Arbeit nun abgeschlossen und es gibt – soweit möglich – eine vollständige CVSSv3x-Abdeckung in den Greenbone-Feeds.

Hilfreiche Schweregrad-Kennzahlen

Jeder Cyber-Angriff benötigt eine Schwachstelle, um erfolgreich zu sein. Die meisten Schwachstellen, nämlich 999 von 1.000, sind bereits seit über einem Jahr bekannt und können daher proaktiv aufgedeckt und beseitigt werden. Zur Erkennung kommt dabei ein Greenbone-Schwachstellenscanner zum Einsatz, welcher die bekannten Schwachstellen in einer IT-Infrastruktur aufspürt.

Werden Schwachstellen aufgedeckt, können sie anschließend mit den unterschiedlichsten Maßnahmen beseitigt werden. Die am dringendsten zu beseitigenden Schwachstellen sind die, die ein kritisches Risiko für das IT-System darstellen. Für die Auswahl der Maßnahmen und der Reihenfolge, wird eine Priorisierung benötigt.

Zur Priorisierung ist der Schweregrad ein essenzielles Mittel. Wie Schwachstellen aber überhaupt einen Schweregrad erhalten und wie dieser berechnet wird, schauen wir uns hier einmal genauer an.

Wie Bewertungen des Schweregrads entstehen

In der Vergangenheit entdeckten und meldeten unterschiedliche Organisationen und Security-Research-Teams Schwachstellen zur gleichen Zeit und benannten diese mit unterschiedlichen Namen. Dies führte dazu, dass die gleiche Schwachstelle von z. B. mehreren Scannern unter unterschiedlichen Namen gemeldet wurde, was die Kommunikation und den Vergleich der Ergebnisse erschwerte.

Um das zu beheben, gründete MITRE das Projekt „Common Vulnerabilities and Exposures“ (CVE). Jeder Schwachstelle erhielt als zentrale Referenz eine eindeutige Kennzeichnung, die aus dem Veröffentlichungsjahr und einer einfachen Nummer besteht. Die CVE-Datenbank wird genutzt, um Schwachstellen-Datenbanken mit anderen Systemen zu verbinden und den Vergleich von Sicherheitswerkzeugen und -diensten zu ermöglichen.

CVEs enthalten somit keine detaillierten, technischen Informationen oder Informationen bezüglich der Risiken, Auswirkungen oder Beseitigung einer Schwachstelle. In manchen Fällen ist die Version hinterlegt, in der die Schwachstelle beseitigt wurde.

Nähere Informationen zu einer Schwachstelle finden sich in der National Vulnerability Database (NVD). Die NVD – ein Datenspeicher für das Schwachstellenmanagement der US-Regierung – ergänzt die CVEs mit Informationen bezüglich der Beseitigung, den möglichen Auswirkungen, den betroffenen Produkten und auch dem Schweregrad einer Schwachstelle.

Wie berechnet sich der Schweregrad einer Schwachstelle?

Um die Bewertung von Schwachstellen zu ermöglichen, wurde das Common Vulnerability Scoring System (CVSS) entwickelt. Das CVSS ist ein Industriestandard zum Beschreiben der Schweregrade von Sicherheitsrisiken in IT-Systemen. Es wurde von der CVSS Special Interest Group (CVSS-SIG) des Forum of Incident Response and Security Teams (FIRST) entwickelt. Die neueste CVSS-Version ist 3.1.
Der CVSS-Score bewertet Schwachstellen hinsichtlicht verschiedener Kritierien, sogenannter „Metrics“: Base-Score-Metrics, Temporal-Score-Metrics und Environmental-Score-Metrics.

  • Base-Score-Metrics: Die Base-Score-Metrics stellen die grundlegenden Merkmale einer Schwachstelle dar, die unabhängig von der Zeit und der IT-Umgebung sind: Wie gut lässt sich die Schwachstelle ausnutzen und welche Auswirkungen hat dies?
  • Temporal-Score-Metrics: Die Temporal-Score-Metrics stellen Eigenschaften dar, die sich über die Zeit ändern können, aber in unterschiedlichen IT-Umgebungen gleich sind. So würde beispielsweise das Bereitstellen eines Patches durch das bereitstellende Unternehmen den Score senken.
  • Environmental-Score-Metrics: Die Environmental-Score-Metrics stellen die Merkmale dar, die für eine spezifische IT-Umgebung gelten. Relevant sind hierbei, wie gut die betroffene Organisation erfolgreiche Angriffe abfangen können oder welchen Stellenwert ein bestimmtes angreifbares System innerhalb der IT-Infrastruktur hat.

Da im Allgemeinen lediglich die Base-Score-Metrics aussagekräftig sind und dauerhaft bestimmt werden können, werden in der Regel nur diese veröffentlicht und genutzt.

CVSSv3.0/v3.1-Unterstützung seit GOS 21.04

Seit GOS 21.04, welches im April 2021 veröffentlich wurde, werden auch die Versionen 3.0 und 3.1 von CVSS unterstützt. Zwar enthalten einige CVEs – und somit auch die zugehörigen Schwachstellentests – weiterhin CVSS-Daten der Version 2, allerdings betrifft dies hauptsächlich ältere CVEs aus dem Jahr 2015 und früher, für die in der NVD noch keinen CVSS-v3.0/v3.1-Score hinterlegt sind.

Blicken wir auf die größten Änderungen, die die Versionen 3.0 und 3.1 beinhalten.

Im Vergleich zu CVSS Version 2.0 wurden in Version 3.0 zwar die Hauptgruppen der Metrics – Base, Temporal und Environmental – beibehalten, aber neue Kriterien hinzugefügt. Beispielsweise die Metrics „Scope (S)“, was angibt, ob eine Schwachstelle auch andere Bestandteile eines IT-Netzwerks beeinträchtigen kann und „User Interaction (UI)“.

Auch wurden einige bereits vorhandene Kriterien durch neuere ersetzt: so wurde „Authentication (Au)“ zu „Privileges Required (PR)“. Gemessen wird nicht mehr, wie oft sich Angreifende bei einem System authentifizieren müssen, sondern welches Zugriffslevel für einen erfolgreichen Angriff notwendig ist.

Außerdem wurden die Schweregrade feiner unterteilt. In Version 2.0 wurden die Werte von 0 bis 10 auf drei Schweregrade aufgeteilt: „Low“ (0,0 – 3,9), „Medium“ (4,9 – 6,9) und „High“ (7,0 – 10,0). Seit Version 3.0 gibt es fünf Stufen: „None“ (0,0), „Low“ (0,1 – 3,9), „Medium“ (4,0 – 6,9), „High“ (7,0 – 8,9) und „Critical“ (9,0 – 10,0).

CVSS-Version 3.1 brachte keine Änderungen an den Metrics oder den Berechnungsformeln mit sich. Stattdessen lag der Fokus darauf, herauszustellen, dass CVSS den Schweregrad einer Schwachstelle misst und nicht das Risiko, welches sie darstellt. Ein weit verbreiteter Fehler war es, den CVSS-Score als alleiniges Merkmal für das Risiko einer Schwachstelle zu sehen und keine vollumfängliche Risikobewertung vorzunehmen.

In diesem Zuge wurden die Definitionen der Metrics eindeutiger formuliert und das Glossar erweitert.

Vollständige CVSSv3.0/v3.1-Abdeckung im Feed

Mit der Unterstützung von CVSS-v3.0/v3.1 im April 2021 begann Greenbone damit, alle Schwachstellentests, denen ein CVSSv3.0/v3.1-Score in der NVD zugewiesen wurde, zu aktualisieren und mit einem CVSSv3.0/v3.1-Score zu versehen.

Dies erfolgte in täglichen Etappen von 500 – 600 Schwachstellentests. Die Aktualisierung und Umstellung wurde dabei gründlich reviewt und geprüft. Seit Oktober 2021 ist diese Arbeit nun abgeschlossen. Somit gibt es – soweit es möglich ist – eine vollständige CVSSv3x-Abdeckung in den Greenbone-Feeds.

Ab dem 30.04.2021 ist die neueste GOS-Version – Version 21.04 – verfügbar und sie bringt wie immer viele neue Features und Verbesserungen mit sich! Was genau? Verschaffen Sie sich hier einen Überblick über alle wichtigen Neuerungen mit GOS 21.04!

Neue Hardware für unsere Midrange-Klasse

Für die Hardware-Appliances der Midrange-Klasse, welche für mittelgroße Unternehmen oder auch für Zweigstellen großer, verteilter Unternehmen genutzt werden, wurde eine neue Hardware-Generation eingeführt.

Die neue Hardware verwendet nun Festplatten vom Typ SSD statt HDD, welche 10-mal schneller, leiser und leichter sind. Außerdem steht auch mehr Festplattenspeicher zur Verfügung. Auch der Arbeitsspeicher wurde verbessert. Dieser ist nun vom Typ DDR4 statt DDR3, was ihn durch eine höhere Taktrate (3200 MHz) deutlich schneller macht. Des Weiteren steht doppelt bis viermal so viel Arbeitsspeicher zur Verfügung als vorher. Zusätzlich wurde eine neue, schnellere CPU der neuesten Generation verbaut. Auch die Ports der Appliances ändern sich: statt 6 Ports GbE-Base-TX und 2 Ports 1 GbE SFP sind nun 8 Ports GbE-Base-TX und 2 Ports 10 GbE SFP+ vorhanden.

Die Modellnamen bleiben unverändert.

Boreas-Erreichbarkeitsscanner jetzt als Standard

Der Boreas-Erreichbarkeitsscanner ist ein Host-Erreichbarkeitsscanner, der die aktiven Hosts in einem Zielnetzwerk identifiziert. Er wurde mit GOS 20.08 eingeführt, war bisher aber noch optional. Mit GOS 21.04 wurde der Boreas-Erreichbarkeitsscanner zum Standard.

Im Vergleich zum zuvor standardmäßig verwendeten Portscanner Nmap ist der Boreas-Erreichbarkeitsscanner hinsichtlich der maximalen Anzahl gleichzeitig durchgeführter Erreichbarkeitsscans nicht limitiert und damit schneller.

Der Boreas-Erreichbarkeitsscanner reduziert die Scanzeit für große Netzwerke mit einem geringen Anteil an erreichbaren Hosts deutlich. Dadurch ist es auch möglich, die ersten Scan-Ergebnisse schneller zu erhalten, unabhängig davon, wie hoch der Anteil erreichbarer Hosts im Netzwerk ist.

Übersichtlichere Ergebnisse durch neue Berichtformate

Für den Export von Berichten sind nun zwei weitere Berichtformate vorhanden, die die bisherigen Standardberichtformate ersetzen: Vulnerability Report PDF und Vulnerability Report HTML. Die Berichtformate sind klar strukturiert und übersichtlich. Spezielle zielgruppenrelevante Informationen können schnell erkannt und verstanden werden.

Die Berichtformate bieten eine Basis für benutzerdefinierte Berichte, welche für zukünftige GOS-Versionen geplant sind.

 

Neues Netzwerk-Backend für eine stabilere Verbindung

Mit GOS 21.04 wurde das Backend für die Netzwerkkonfiguration in GOS verbessert, indem der Netzwerkmodus gnm eingeführt wurde. Dies verhindert Verbindungsverluste in bestimmten Netzwerkkonfigurationen sowie Verbindungsprobleme mit SSH-Sitzungen. Außerdem muss der GSM nicht mehr neu gestartet werden, nachdem bestimmte Netzwerkeinstellungen geändert wurden.

Neue Hypervisoren für unsere virtuellen Appliances
Die offiziell unterstützten Hypervisoren für die virtuellen Appliances wurden mit GOS 21.04 geändert. Der GSM EXA/PETA/TERA/DECA und 25V kann mit Microsoft Hyper-V, VMware vSphere Hypervisor (ESXi) und Huawei FusionCompute verwendet werden, der GSM CENO mit Microsoft Hyper-V und VMware vSphere Hypervisor (ESXi) und der GSM ONE mit Oracle VirtualBox, VMware Workstation Pro und VMware Workstation Player. Zusätzlich unterstützt GOS 21.04 den ARM-Befehlssatz auf Huawei FusionCompute.

Verbesserung des Webservers, der Ciphers und der Web-Zertifikate

Mit GOS 21.04 wird zusätzlich zum Greenbone Security Assistant Daemon (gsad) der Webserver nginx verwendet. Dieser nutzt OpenSSL anstelle von GnuTLS zur Definition der verfügbaren Ciphers und Protokolle des Servers. Für die Konfiguration der TLS-Version gibt es nun im GOS-Administrationsmenü ein neues Menü. Außerdem wurde das Menü zum Konfigurieren der Ciphers angepasst.

Eine weitere Änderung findet sich bei der Generierung von HTTPS-Zertifikaten. Hier ist es nun möglich, einen oder mehrere Subject Alternative Name(s) (SAN) zu definieren. Diese dienen dazu, mehrere Domainnamen und IP-Adressen durch ein Zertifikat abzudecken.

Unterstützung von CVSS v3.0/v3.1 zur Schweregradberechnung

Für die Berechnung der Schweregrade von CVEs (Common Vulnerability Enumeration) wird nun auch Version 3.0 und 3.1 von CVSS unterstützt.

NVTs und CVEs können CVSS-Daten der Version 2 und/oder der Version 3.0/3.1 enthalten. Wenn ein/e NVT/CVE sowohl CVSS-v2-Daten als auch CVSS-v3.0/v3.1-Daten enthält, werden immer die CVSS-v3.0/v3.1-Daten verwendet und angezeigt.

Die Seite CVSS-Rechner enthält nun sowohl einen Rechner für CVSS v2 als auch einen Rechner für CVSS v3.0/v3.1.

Open Scanner Protocol macht alle Sensor-GSMs leichtgewichtig

Bereits mit GOS 20.08 war es optional für alle Sensoren möglich, diese über das Open Scanner Protocol (OSP) steuern zu lassen. Dies führt dazu, dass die Sensoren leichtgewichtig werden und vermeidet, dass zusätzliche Anmeldedaten auf dem Sensor benötigt werden.

Mit GOS 21.04 wird nun nur noch OSP als Protokoll genutzt, um einen Sensor-GSM über einen Master-GSM zu steuern. Das Greenbone Management Protocol (GMP) wird nicht mehr verwendet.

Vereinfachte und intuitivere Funktionen auf der Web-Oberfläche

Mit GOS 21.04 wurden zudem einige kleinere Änderungen an GOS und an der Web-Oberfläche vorgenommen, um die Bedienung des GSM und das Scannen übersichtlicher und intuitiver zu machen.

So wurden die Auto-FP-Funktion und die alternativen Schweregradklassen-Schemata – BSI Schwachstellenampel und PCI-DSS – entfernt.

Einige Geräte – insbesondere IoT-Geräte – können abstürzen, wenn sie über mehrere IP-Adressen gleichzeitig gescannt werden. Dies kann zum Beispiel passieren, wenn das Gerät über IPv4 und IPv6 verbunden ist. Mit GOS 21.04 ist es möglich, das Scannen über mehrere IP-Adressen gleichzeitig zu vermeiden, indem beim Anlegen eines Ziels die neue Einstellung Erlaube das gleichzeitige Scannen über verschiedene IPs verwendet wird.

Sehen Sie selbst!

Überzeugen Sie sich selbst von unseren neuen Features und Änderungen! Ab sofort sind neue Appliances mit GOS 21.04 erhältlich und auch bestehende Appliances können auf die neueste Version aktualisiert werden. Auch unsere kostenlose Testversion ist mit GOS 21.04 verwendbar.

SiSyPHuS Win10 ist ein Projekt des Bundesamts für Sicherheit in der Informationstechnik (BSI).
Auf Basis einer Analyse der sicherheitskritischen Funktionen im Betriebssystem Microsoft Windows 10, wurden Handlungsempfehlungen zu dessen Härtung entwickelt. Diese Empfehlungen sind jetzt auch in Form einer Compliance-Richtlinie Bestandteil des Greenbone Security Feeds und können für Greenbone-Kunden komfortabel direkt mit den Greenbone-Appliances geprüft werden.

Die Maßnahmen beinhalten unter Anderem Konfigurationsempfehlungen, Kennwortrichtlinien, Verschlüsselungsvorgaben und natürlich Aktualisierungen. Sie helfen dabei, Windows-10-Systeme deutlich sicherer zu machen. Durch die Integration der Compliance-Richtlinie in den Greenbone Security Feed, sind die Maßnahmen einfach in die Prüfroutinen des Greenbone-Schwachstellenmanagements integrierbar.

Weitere Informationen finden Sie hier.

Wir freuen uns Ihnen mitteilen zu dürfen, dass ab dem 30.04.2021 die neueste Version unseres Betriebssystems Greenbone OS verfügbar ist! Dabei haben wir viele Ihrer Wünsche berücksichtigt: Im Fokus der Verbesserung stand das Scannen großer Netzwerke mit vielen Scanergebnissen und umfangreichen Berichten. GOS 21.04 bietet unter anderem eine neue Hardware, eine Verbesserung der Hosterkennung und übersichtlichere Berichte.

Unseren Kunden das beste Schwachstellenmanagement zu liefern – dieses Ziel steht schon immer bei unseren Produkten im Mittelpunkt. Mit dem neuen Release unseres Betriebssystems Greenbone OS bleiben wir diesem Anspruch treu und machen unsere Produkte nach leistungsfähiger: besonders für große Netzwerke mit vielen verteilten Zweigstellen wird das Scannen mit GOS 21.04 schneller und die Scanergebnisse noch übersichtlicher.

Leistungsstärkere und schnellere Hardware für die Midrange-Klasse

In großen Netzwerken kommen meist mehrere verteilte mittelgroße bis große Appliances zum Einsatz, die über ein Master-Sensor-Konzept miteinander verknüpft sind. Aus diesem Grund wurden die Hardware-Appliances der Midrange-Klasse gestärkt, indem ihre Hardware verbessert wurde.

Unsere neue Hardware verwendet nun Festplatten vom Typ SSD statt HDD, welche 10-mal schneller, leiser und leichter sind. Außerdem steht mehr Speicherplatz zur Verfügung. Auch der Arbeitsspeicher wurde verbessert: statt vom Typ DDR3 ist dieser nun vom Typ DDR4, welcher durch eine höhere Taktrate (3200 MHz) deutlich schneller ist. Des Weiteren steht doppelt bis viermal so viel Arbeitsspeicher zur Verfügung als zuvor. Zusätzlich erhielt die Hardware neue, schnellere CPU der neuesten Generation und auch die Ports der Appliances wurden aktualisiert: statt 6 Ports GbE-Base-TX und 2 Ports 1 GbE SFP sind nun 8 Ports GbE-Base-TX und 2 Ports 10 GbE SFP+ vorhanden.

Boreas-Erreichbarkeitsscanner für schnellere Verfügbarkeit der Ergebnisse nun als Standard

Auch das Scannen wird schneller – was insbesondere in großen Netzwerken hilfreich ist. Bereits mit GOS 20.08 wurde der Boreas-Erreichbarkeitsscanner eingeführt, ein Host-Erreichbarkeitsscanner, der die aktiven Hosts in einem Zielnetzwerk identifiziert. Mit GOS 21.04 wird der Boreas-Erreichbarkeitsscanner zum Standard, was die manuelle Aktivierung erspart.

Der Boreas-Erreichbarkeitsscanner ist hinsichtlich der maximalen Anzahl gleichzeitig durchgeführter Erreichbarkeitsscans nicht limitiert und damit schneller als sein Vorgänger Nmap. Dadurch reduziert sich die Scanzeit für große Netzwerke deutlich. Die ersten Scan-Ergebnisse sind schneller verfügbar, unabhängig davon, wie hoch der Anteil erreichbarer Hosts im Netzwerk ist.

Übersichtlichere Berichte durch neue Berichtformate

Auch die Auswertung der Scans wird übersichtlicher – durch neue Berichtformate. Mit dem Format Vulnerability Report als PDF und als HTML sind die Berichte klar strukturiert und übersichtlich. Spezielle zielgruppenrelevante Informationen können schnell erkannt und verstanden werden.

Überzeugen Sie sich selbst

Scannen mit GOS 21.04 ist noch schneller, zuverlässiger und übersichtlicher. Überzeugen Sie sich selbst von unseren neuen Features und Änderungen! Ab sofort sind neue Appliances mit GOS 21.04 zu erhalten. Für bestehende Appliances wird das Upgrade auf die neueste Version in der nächsten Woche verfügbar sein. Auch unsere kostenlose Testversion wird dann mit GOS 21.04 verwendbar sein.

Compliance-Richtlinien werden von Unternehmen, Organisationen oder Behörden genutzt, um zu prüfen, ob alle verwendeten Produkte, Anwendungen, Betriebssysteme und andere Komponenten bestimmte Vorgaben erfüllen. Das Center for Internet Security (CIS) stellt dafür sogenannte CIS Benchmarks bereit. Auch die Greenbone-Lösungen bieten seit März 2021 die Möglichkeit, die Erfüllung von CIS Benchmarks zu prüfen – mithilfe von neuen Compliance-Richtlinien.

Was versteht man aber überhaupt unter einer Compliance-Richtlinie?

Zusätzlich zu gesetzlichen Vorgaben unterliegen Unternehmen, Organisationen und Behörden oft auch anderen Anforderungen, die für die sichere Konfiguration eines Systems erfüllt werden müssen. Solche Anforderungen können beispielsweise von einem Software- oder Anwendungshersteller für die eigenen Produkte formuliert werden, aber auch von IT-Sicherheits-Organisationen.

Ziel dabei ist es, für die Informations- und Datensicherheit eines Unternehmens oder einer Behörde zu sorgen, indem die Vertraulichkeit, die Integrität, die Verfügbarkeit und die Authentizität von Informationen sichergestellt wird.

Alle Vorgaben und Richtlinien, aber auch Empfehlungen, die dafür zu erfüllen sind, werden in einer Richtlinie in schriftlicher Form gebündelt.

Diese Richtlinien bilden die Grundlage für von Greenbone Networks entwickelte Compliance-Richtlinien, also für die Zusammenstellung an Tests, die eine Greenbone-Lösung auf einem Zielsystem ausführt. Dabei wird für jede einzelne Anforderung oder Empfehlung ein Schwachstellentest entwickelt, der die Erfüllung jener Anforderung oder Empfehlung prüft. Alle Tests werden von Greenbone Networks zu Scan-Konfigurationen zusammengefasst und zum Greenbone Security Feed hinzugefügt.

Da die Scan-Konfigurationen in diesem Fall Richtlinien von Unternehmen oder Behörden abbilden, werden sie als „Compliance-Richtlinien“ bezeichnet.


Beispiel: Ein Unternehmen bringt eine Richtlinie mit den folgenden Anforderungen heraus:

  • Version 2 der Software A ist auf dem Zielsystem installiert
  • SSH ist auf dem Zielsystem aktiviert
  • Software B ist nicht auf dem Zielsystem installiert

Greenbone Networks entwickelt für jede der Anforderungen jeweils einen Schwachstellentest, der abfragt, ob die jeweilige Bedingung erfüllt ist.

Die drei Tests werden dann zu einer Compliance-Richtlinie zusammengefasst, die ein Nutzer der Greenbone-Lösungen zum Ausführen eines Schwachstellenscans wählen kann. Während des Scans wird dann geprüft, ob die oben genannten Bedingungen auf dem Zielsystem erfüllt werden.


CIS Benchmarks als maßgebende Security-Richtlinien

Auch das Center for Internet Security (CIS) veröffentlich solche Security-Richtlinien: die sogenannten CIS Benchmarks. CIS ist eine im Jahr 2000 gegründete Non-Profit-Organisation, die Best Practices für die IT-Sicherheit bereitstellen, die von Regierungen, der Industrie und der Wissenschaft genutzt werden.

Mit eines der größten Tätigkeitsfelder der Organisation sind die sogenannten CIS Benchmarks. Dabei handelt es sich um Handlungs- und Konfigurationsempfehlungen für zahlreiche Produkte aus den unterschiedlichsten Produktfamilien. So gibt es beispielweise CIS Benchmarks für Webbrowser wie Mozilla Firefox oder Google Chrome, für Betriebssysteme wie Microsoft Windows oder unterschiedliche Linux-Distributionen, aber auch für die Microsoft-Office-Produkte.

Im Gegensatz zu vielen anderen Security-Standards, die nur grundsätzliche Vorgaben bezüglich der IT-Sicherheit machen – beispielsweise, dass es ein Schwachstellenmanagement geben muss – sind die CIS Benchmarks sehr detailliert. Sie stellen Anforderungen bereit, die erfüllt werden müssen, um ein System zu härten, sprich sicherer zu machen und vor Angriffen zu schützen. Dazu können unter anderem Kriterien für Passwörter, aber auch Vorgaben für bestimmte installierte Software-Versionen gehören.

Die CIS Benchmarks werden von CIS kostenlos als PDF zur Verfügung gestellt und ständig erweitert. Für CIS SecureSuite Member – so wie Greenbone Networks es seit 2021 ist – sind die CIS Benchmarks aber auch über die CIS Workbench in anderen Formaten, zum Beispiel für Microsoft Word oder Excel, verfügbar.

CIS-zertifizierte Compliance-Richtlinien bei Greenbone Networks

Wie auch bei den Security-Richtlinien anderer Unternehmen, Organisationen oder Behörden hat Greenbone Networks nun basierend auf den CIS Benchmarks eigene Compliance-Richtlinien entwickelt. Diese ermöglichen es Nutzern einer Greenbone-Lösung, ihre Netzwerke, Systeme und Anwendungen auf die Anforderungen aus den CIS Benchmarks zu überprüfen. Seit März 2021 sind mehrere Compliance-Richtlinien, die CIS Benchmarks abbilden, im Greenbone Security Feed enthalten.

Und das Besondere daran: Die von Greenbone Networks entwickelten Compliance-Richtlinien sind von CIS zertifiziert! Das bedeutet, dass Nutzer sicher gehen können, dass ihr System gemäß den Härtungsempfehlungen von CIS geprüft wird.

Nutzer können nun also ihre Systeme daraufhin prüfen, ob die Vorgaben von CIS erfüllt werden. Das vereinfacht auch die Vorbereitung von Audits. Wichtige Kriterien können bereits vorab mit einem Scan durch eine Greenbone-Lösung geprüft und gegebenenfalls gefundene Schwachstellen behoben werden.

Doch bei diesen CIS-zertifizierten Compliance-Richtlinien wird es nicht bleiben. Viele weitere Compliance-Richtlinien, die CIS Benchmarks abbilden, sind bei Greenbone Networks in der Planung oder sogar bereits in der Entwicklung.