Interview mit Björn Ricks, Senior Software Developer, bei Greenbone Networks

Greenbone verstärkt sein Engagement für Open Source und die Community Edition seiner Schwachstellenmanagement-Software. Zusätzlich zu den Quelltexten auf Github stellt Greenbone nun auch vorkonfigurierte und getestete Docker-Container bereit.

Offizielle Container“ vom Hersteller selbst

Die Greenbone Community Container werden regelmäßig automatisch gebaut und stehen auch für ARM und Raspberrys zur Verfügung.

Björn Ricks sieht darin eine „große Verbesserung für Admins, die Greenbone einfach mal ausprobieren möchten. Unsere offiziellen Container ersetzen die vielen verschiedenen Docker-Images die es im Web gibt, mit einer offiziellen, stets aktuellen, immer gepflegten Version von Greenbone“.

Docker Container für die Greenbone Community Edition

Hallo Björn, was ist Deine Aufgabe bei Greenbone?

Björn Ricks: Eine meiner aktuellen Aufgaben ist die Bereitstellung von Community Container Builds bei Greenbone. Die Betreuung der Community war schon immer ein großen Anliegen von mir und ich wollte lange schon erreichen, dass wir auch „offizielle“ Docker-Images von Greenbone zur Verfügung stellen. Dass das jetzt geklappt hat, freut mich sehr.

Was ist der Nutzen der Images für die Community?

Björn Ricks: Wir machen es Administratoren und Anwendern, die Greenbone testen wollen, viel einfacher. Die Installation funktioniert nun komplett unabhängig vom verwendeten Betriebssystem: Einfach das Docker-Compose-file, das die Services beschreibt, herunterladen und ausführen, den Browser öffnen und das lokale Netzwerk scannen. Ich denke, das ist eine viel niedrigere Einstiegshürde, ideal auch für jeden, der die Details und Möglichkeiten unserer Produkte noch gar nicht kennt.

Warum stellt Greenbone jetzt selbst Container zur Verfügung? Es gab doch schon welche im Netz?

Björn Ricks: Ja, das ist richtig, aber wir haben erfahren, dass manche Menschen unsicher waren über Inhalt, Aktualität und Wartung dieser Images. Deshalb haben wir uns entschlossen, von uns signierte Docker-Images mit geprüften und gesicherten Inhalten anzubieten.
All die im Netz existierenden Container Images haben einen unterschiedlichen Versionsstand und erst recht unterschiedliche Qualitätsgüte. Es ist von außen oft nicht zu erkennen, ob ein Image „etwas taugt“ oder eben nicht. Auch muss man den externen Autoren und Maintainern natürlich vertrauen, dass sie wissen, was sie da tun, und ihre Images keine zusätzlichen Sicherheitslücken enthalten. Nur wir als Hersteller unserer eigenen Software können garantieren, dass die veröffentlichen Container Images den aktuellen Versionsstand und die gewünschte Qualitätsgüte haben.

Plant Greenbone auch, Docker-Images für die kommerzielle Produktlinie, Greenbone Enterprise Appliances, bereitzustellen?

Björn Ricks: Das hängt von den Anfragen unserer kommerziellen Kunden ab. Die Greenbone Community Edition, die wir als Docker-Image zur Verfügung stellen, enthält Zugang zum Community-Feed mit rund 100.000 Schwachstellentests. Unser kommerzieller Feed enthält noch mehr Tests, einschließlich derer für viele proprietäre Produkte, die unsere Kunden verwenden.

Wir haben festgestellt, dass unsere Kunden mit unseren Appliances, unseren Virtual Appliances und unserer Cloud-Lösung zufrieden sind – die sich alle für die Nutzung des kommerziellen Feed-Abonnements qualifizieren. Dies könnte sich jedoch ändern, und wenn, werden wir in Betracht ziehen, Docker-Container für kommerzielle Kunden anzubieten.

Wie häufig werden die Images aktualisiert und welcher Feed ist enthalten?

Björn Ricks: Die Images werden direkt aus den Quellcode-Repositories gebaut und veröffentlicht. Sie sind somit immer tagesaktuell und enthalten alle Patches. Im Moment steht nur der Community-Feed für die Images zur Verfügung, aber das könnte sich in Zukunft ändern.

Wo bekomme ich die Images und die Dokumentation?

Björn Ricks:
Das Docker-Compose-File zur Orchestrierung der Services ist in der Dokumentation verlinkt. Die Dockerfiles zum Bauen der Docker Images finden sich auch auf Github in den entsprechenden Repositories, und sind ganz einfach einfach downloadbar, beispielsweise hier.


Der weltweit führende Hersteller von Lösungen für Open-Source-Schwachstellenmanagement Greenbone hat ein Community-Portal für seine Anwender- und Entwicklergemeinschaft gestartet, das die umfangreichen Informationen für die Community-Editionen übersichtlicher und einfacher zugänglich macht.

Für wen ist das Portal?

Auf community.greenbone.net laden die Vulnerability-Management-Experten Anwender, Developer und alle IT-Profis, die sich professionell mit Sicherheit und Schutz vor Hackern beschäftigen ein, sich in Foren, Blogs, News und Dokumentation umzusehen und zu helfen, die Seiten zu gestalten.

Zentrale Anlaufstelle
„Unser neues Community Portal ist die zentrale Anlaufstelle, wo sich Anwender, Experten, Greenbone Mitarbeiter und alle anderen Interessierten treffen und sich stets aktuell über die Produkte, die Firma oder neue Features informieren können.“ erklärt Greenbones Community-Managerin DeeAnn Little: „Wir möchten mit dem Portal der großen, weltweiten Greenbone Community ein Zuhause geben, mit allen Links und Informationen, die jeder braucht, der mit unseren Schwachstellenmanagement arbeitet.“

Was bietet das neue Portal
Sowohl für Greenbone OpenVAS als auch die Greenbone Community Edition finden sich (unter „Getting started“) zahlreiche Anleitungen zur Installation und Konfiguration der Community-Versionen. Dazu gibt’s News und Updates, beispielsweise zu den jüngst veröffenlichten Docker-Container-Releases der Community Edition aber auch aktuelle Zahlen über Greenbone-Installationen auf auf einer Weltkarte und ein komplett überarbeitetes Forum mit neuen Kategorien und Blog.

Für die Community, mit der Community
„All das wäre ohne die zahlreichen Beiträge aus der Greenbone-Community nicht möglich, aber gleichzeitig ist das auch nur der erste Schritt“, erklärt Little:„Zukünftig werden wir hier auch technische Details von unseren Experten erklären lassen und neue Features vorstellen.

Greenbone wünscht sich dabei viel Input und Anregungen aus seiner großen Community, erklärt Little:

„Wir freuen uns über jeden Input und alle Anregungen, Ideen und Verbesserungsvorschläge, genau dafür ist das Portal da. Schicken Sie uns Ihre Fragen. Was haben wir übersehen? Was wünschen Sie sich? Wie können wir das Portal, das Forum und die neuen Seiten noch besser machen? Welche Themen wünschen Sie sich – worüber sollten wir berichten?“ Hier können Sie Ihre Meinung hinterlassen, wir freuen uns darauf.

Greenbone Community Forum im neuen Look

Auch das beliebte User Forum hat Greenbone ins Community Portal integriert. Im neuen Look soll es auch weiterhin den Anwendern von Greenbones Software – unabhängig von ihrem technischen Hintergrund – eine Plattform für Ideen, gegenseitige Hilfe aber auch Feedback geben.

„Im Forum können sich User auf Augenhöhe begegnen und gegenseitig helfen – es ist ein Ort des Austausches, wo auch wir immer wieder lernen können.“ erklärt Little. „Egal ob es sich um eine Anfängerfrage, tiefergehende Howtos oder Getting Started Guides handelt – im Forum findet so mancher Anwender Hilfe von erfahrenen Usern, selbst in exotischen Setups.“

Greenbone hat als weltweit führender Hersteller von Open-Source-Software für das Schwachstellenmanagement seinen neuesten Scanner Notus veröffentlicht.

„Mit Notus ist in den letzten Jahren ein Meilenstein für die Performance von umfangreichen Vergleichen von Softwareversionen entstanden“, erklärt CIO Elmar Geese.

Mit Notus antwortet Greenbone auch auf den Wunsch von Kunden nach mehr Performance beim Versionscheck. Ob eine Sicherheitslücke gefährlich fürs Unternehmen ist, hängt überwiegend von den installierten Softwareversionen und deren Patchlevel ab. In sehr vielen Fällen muss ein Schwachstellenscanner also sehr viele Softwareversionen abgleichen und Kombinationen aus diesen erfassen. Mit zunehmender Komplexität der Setups wird dieser Test immer umfangreicher. Weil aber das Gesamtergebnis der Prüfung stark auch von dieser Datenerfassung abhängt, ermöglicht Notus derlei Scans deutlich schneller als alle seine Vorgänger.

Schneller dank Json

„Der Scanner klappert die relevanten Server ab und erfasst dort laufende Software. Für den eigentlichen Scan bekommt er im Wesentlichen nur die Infos über betroffene und gefixte Pakete“, erklärt Björn Ricks, Senior Software Developer bei Greenbone. „Beim bislang genutzten Scanner und seinen Vorläufern mussten wir in der Regel pro Versionscheck einen eigenen Prozess starten, das heißt ein separates manuell erstelltes Skript. Diese Skripte automatisch zu generieren ist aufwendig.“ Notus dagegen lädt nur noch die benötigten Daten aus JSON-Dateien. Ricks fasst das zusammen: „Notus ist deutlich effizienter, braucht weniger Prozesse, weniger Overhead, weniger Speicher, …“

CIO Geese erklärt den Notus-Scanner dann auch zu einem „Meilenstein für unsere Nutzenden, er wird die Performance deutlich verbessern. Unsere bekannt hohe Erkennungsqualität wie auch die Performance, zentrale Ziele unserer Produktstrategie, werden vom neuen Scanner optimal unterstützt.“

Notus, Greenbone und OpenVAS

Das Notus-Projekt besteht aus zwei Teilen: einem Notus-Generator, der die JSON-Dateien mit den Informationen über verwundbare RPM-/Debian-Pakete erzeugt und dem Notus-Scanner, der diese JSON-Dateien lädt und die Informationen daraus interpretiert.

OpenVAS, das Open Vulnerability Assessment System, entstand 2005, als das Entwicklungsteam des Schwachstellenscanners Nessus beschloss, nicht mehr unter Open-Source-Lizenzen zu arbeiten und zu einem proprietären Geschäftsmodell zu wechseln.

Seit 2008 bietet Greenbone professionelle Unterstützung für Schwachstellenscans. Greenbone übernahm dafür die Weiterentwicklung von OpenVAS, fügte mehrere Softwarekomponenten hinzu und verwandelte OpenVAS so in eine umfangreiche Schwachstellenmanagement-Lösung, die dennoch die Werte der freien Software in sich trägt. Die ersten Appliances kamen im Frühjahr 2010 auf den Markt.

Microsoft Office hat mit dem Windows-Sicherheitsupdate vom 14. Juni 2022 Patches für die Follina-Sicherheitslücke CVE-2022-30190 (Follina)  veröffentlicht. In den Greenbone Enterprise Feed und den Greenbone Community Feed wurden entsprechende Schwachstellentests implementiert, mit denen Sie ihr Netzwerk auf die Schwachstelle testen und Schutzmaßnahmen mithilfe der Patches ergreifen können. Lesen Sie hier weitere Informationen über das aktuelle Follina-Update.

  • KB5014678: Windows Server 2022
  • KB5014697: Windows 11
  • KB5014699: Windows 10 Version 20H2 – 21H2, Windows Server 20H2
  • KB5014692: Windows 10 Version 1809 (IoT), Windows Server 2019
  • KB5014702: Windows 10 1607 (LTSC), Windows Server 2016
  • KB5014710: Windows 10 1507 (RTM, LTSC)
  • KB5014738: Monthly Rollup Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
  • KB5014746: Security only Windows Server 2012 R2, Windows RT 8.1, Windows 8.1
  • KB5014747: Monthly Rollup Windows Server 2012
  • KB5014741: Security only Windows Server 2012
  • KB5014748: Monthly Rollup Windows Server 2008 R2, Windows 7 SP1
  • KB5014742: Security only Windows Server 2008 R2, Windows 7 SP1

Das bedeutet, dass Sicherheitsupdates für alle Versionen von Windows Server und Client verfügbar sind, die noch unterstützt werden. Die Sicherheitslücke wird als „wichtig“ eingestuft, was bedeutet, dass Nutzende die Updates umgehend installieren sollten, um die Lücke zu schließen.
Microsoft: „Das Update für diese Sicherheitslücke ist in den Windows-Updates vom Juni 2022 enthalten. Microsoft empfiehlt allen Kunden dringend, die Updates zu installieren, um sich vollständig vor der Sicherheitslücke zu schützen. Kunden, deren Systeme so konfiguriert sind, dass sie automatische Updates erhalten, müssen keine weiteren Maßnahmen ergreifen.“

Follina Update

Die Installation der Patches vom 14. Juni ist umso wichtiger, da Angreifende und Sicherheitsfachleute bereits mehrere Möglichkeiten gefunden haben, die Schwachstelle auszunutzen, Microsoft aber bisher nur Workarounds anbietet (siehe auch unseren Blogeintrag).
Greenbone hat entsprechende Schwachstellenstests in den Greenbone Community Feed und den Greenbone Enterprise Feed integriert und bietet somit die Möglichkeit, das Netzwerk auf diese Schwachstelle zu testen und gegebenenfalls Schutzmaßnahmen zu ergreifen bzw. die neuen Microsoft Patches zu nutzen.

Wieder einmal ist ein Fehler in Microsoft Office aufgetaucht, der es Angreifenden erlaubt, mit manipulierten Dokumenten aus der Ferne Schadcode auf den Systemen der angegriffenen User auszuführen. Die als „Follina“ bekannt gewordene Schwachstelle CVE-2022-30190 ist zwar seit Jahren bekannt, von Microsoft jedoch bis heute nicht gefixt. Greenbone hat seinen Feeds einen entsprechenden Schwachstellentest hinzugefügt, der die Schwachstelle Follina in Microsoft Office erkennt.

Follina (CVE-2022-30190)

Follina verlangt sofortiges Handeln

Die CVE mit dem Namen „Follina“ ist kritisch und verlangt sofortiges Handeln: Schon das Öffnen von Microsoft-Word-Dokumenten kann Angreifenden Zugang zu Ihren Ressourcen geben. Weil ein Fehler in Microsoft Office es Angreifenden erlaubt, Templates via ms-msdt:-URI-Handler aus dem Internet schon beim ersten Anklicken nachzuladen, können Angreifende manipulierte Dokumente erstellen, die schlimmstenfalls ganze Client-Systeme übernehmen oder Credentials ausspionieren.

Schutz bietet laut Microsoft die „geschützte Ansicht“. Weil Anwendende diese aber mit nur einem Klick deaktivieren können, rät der US-amerikanische Hersteller zum Deaktiveren des kompletten URL-Handlers via Registry-Eintrag. Betroffen sind nach heutigem Stand scheinbar alle Office-Versionen.

Greenbones Feeds helfen und schützen

Der Greenbone Enterprise Feed und der Greenbone Community Feed enthalten jetzt einen authentifizierten Check für den von Microsoft vorgeschlagenen Workaround, der Ihnen hilft, sich vor den Auswirkungen der Sicherheitslücke zu schützen. Unser Entwicklungsteam beobachtet die Veröffentlichung von Microsoft-Patches und -Empfehlungen für weitere Maßnahmen. Wir werden Sie hier im Blog über Updates informieren.

Nachhaltige Sicherung von IT-Netzwerken

Wenn Sie wissen wollen, welche Systeme in ihrem Netzwerk (noch) anfällig für Schwachstellen – einschließlich der mit CVE-2022-30190 verbundenen kritischen Schwachstelle – sind, hilft Ihnen unser Schwachstellenmanagement. Es findet Anwendung in Systemen, die auf jeden Fall gepatcht oder anderweitig geschützt werden müssen. Je nach Art der Systeme und Schwachstelle können diese besser oder schlechter gefunden werden. Auch die Erkennung verbessert sich ständig und wird fortlaufend aktualisiert. Neue Lücken werden gefunden. Es können daher immer noch weitere Systeme mit Schwachstellen im Netz vorhanden sein. Daher lohnt sich eine regelmäßige Aktualisierung und das Scannen aller Systeme. Hierfür bietet das Greenbone-Schwachstellenmanagement entsprechende Automatisierungsfunktionen.

Schwachstellenmanagement ist ein unverzichtbarer Bestandteil der IT-Sicherheit. Es kann Risiken finden und liefert wertvolle Hinweise zu deren Behebung. Eine 100%ige Sicherheit bietet jedoch keine einzelne Maßnahme, auch kein Schwachstellenmanagement. Um ein System sicher zu machen, werden viele Systeme eingesetzt, die in ihrer Gesamtheit die bestmögliche Sicherheit bieten sollen.

Greenbone ist nun ein TISAX-Mitglied und sein Information Security Management System (ISMS) und seine Datenschutzprozesse sind im Rahmen des TISAX-Programms der deutschen Automobilindustrie zertifiziert. „Wir haben diesen Schritt unternommen, um unserer Kundschaft den bestmöglichen Schutz sensibler und vertraulicher Informationen zu bieten, als nächsten logischen Schritt nach der erfolgreichen Zertifizierung nach weltweit anerkannten internationalen Industriestandards wie ISO 27001 und ISO 9001.“ – Dr. Jan-Oliver Wagner, CEO von Greenbone. Die Ergebnisse sind auf dem ENX-Portal unter der Scope-ID S3LW9L und der Assessment-ID A1P7V9 verfügbar. TISAX und die TISAX-Ergebnisse sind nicht für die Allgemeinheit bestimmt.

TISAX-Logo

TISAX, der „Trusted Information Security Assessment Exchange“, ist ein Mechanismus zur Überprüfung und zum Austausch von Testergebnissen nach branchenspezifischen Standards. Ursprünglich als System für den Austausch von standardisierten Testergebnissen in der Automobilindustrie geschaffen, ist es für die Risikobewertung von Zulieferern optimiert. Deshalb wird TISAX von der ENX Association entwickelt und verwaltet und vom Verband der Automobilindustrie (VDA) herausgegeben. Der Fokus liegt auf der sicheren Informationsverarbeitung zwischen Geschäftspartnern, dem Schutz von Prototypen und dem Datenschutz gemäß der EU-Datenschutzgrundverordnung (DSGVO) bei möglichen Geschäften zwischen Automobilherstellern und ihren Dienstleistern oder Lieferanten.

Als wesentlicher Bestandteil einer sicheren Lieferkette ist TISAX ein Standard für Information Security Management Systems (ISMS), der im Jahr 2017 ursprünglich von der Norm ISO/IEC 27001 abgeleitet wurde, sich aber inzwischen weiterentwickelt hat. Für die Automobilindustrie bringt TISAX Standardisierung, Qualitätssicherung und garantiert, dass Informationssicherheitsmaßnahmen von Auditanbietern nach den VDA-Standards bewertet werden. Audits nach TISAX, insbesondere bei Dienstleistern und Zulieferern, werden von sogenannten „TISAX-Prüfdienstleister“ durchgeführt und umfassen drei Reifegrade, über die Sie sich im TISAX-Teilnehmerhandbuch und auf den Websites von Zertifizierungsanbietern wie Adacor einen Überblick verschaffen können.

Greenbones Zertifizierungen erhöhen den Wert unserer Produkte für unsere Kundschaft, nicht nur durch Zeit- und Kostenersparnis, sondern auch durch den Nachweis eines hervorragenden Sicherheitsniveaus und hoher Standards. Elmar Geese, CIO bei Greenbone: „Mit TISAX haben wir unseren unabhängig geprüften Sicherheitsstatus dokumentiert. Unsere Kundschaft muss keine individuellen Bewertungen vornehmen, nicht mit langwierigen Fragebögen arbeiten oder all die anderen Dinge tun, die für ein Bottom-up-Audit erforderlich sind. Wir garantieren, dass wir ihre Sicherheitsanforderungen erfüllen.“

Deshalb folgt Greenbone dem Fragenkatalog zur Informationssicherheit des Verbandes der Automobilindustrie (VDA ISA). Die Bewertung wurde von einem Auditanbieter durchgeführt. Das Ergebnis ist ausschließlich über das ENX-Portal abrufbar (Scope-ID: S3LW9L, Assessment-ID: A1P7V9).


In der vernetzten Produktion wachsen IT und OT immer stärker zusammen. Wo früher eine Sicherheitslücke „nur“ ein Datenleck verursacht hat, kann heute die gesamte Produktion zusammenbrechen. Wer regelmäßige aktive und passive Schwachstellenscans durchführt, kann sich schützen.

Was bei der physischen Infrastruktur etwas befremdlich wirkt – wer stellt schon einen Einbruch nach, um seine Alarmanlage zu testen – ist in der IT ein probates Verfahren, um Schwachstellen zu identifizieren. Dieses sogenannte aktive Scanning kann täglich und automatisch durchgeführt werden. Passives Scanning hingegen erkennt einen laufenden Einbruch, denn auch jeder Cyber-Einbruch hinterlässt Spuren, wenn auch oft verdeckt.

Den Verkehr kontrollieren

Firewalls und Antivirus-Programme nutzen beispielsweise passive Scans und überprüfen so den Traffic, der ein System erreicht. Diese Daten werden dann mit einer Datenbank abgeglichen. Dort sind Informationen zu Schadsoftware, unsicheren Anfragen und anderen Anomalien hinterlegt. Wenn die Firewall etwa eine Anfrage von einem unsicheren Sender bekommt, der Profildaten von Nutzenden auslesen will, lehnt sie die Anfrage ab. Das System selbst bekommt davon nichts mit, denn der passive Scan greift nicht auf das System zu, sondern nur auf den Datenverkehr.

Der Vorteil dabei: Das System muss keine zusätzliche Rechenleistung aufwenden. Trotz der Überprüfung kann die volle Bandbreite genutzt werden. Das ist vor allem bei kritischen Komponenten sinnvoll. Sie sollen eine möglichst hohe Verfügbarkeit aufweisen. Je weniger Zusatztätigkeiten sie ausführen, desto besser.

Der Nachteil des passiven Scannings: Nur Systeme, die selbst aktiv kommunizieren, kann man auch sehen. Nicht dazu gehört beispielsweise Büro-Software oder PDF-Reader. Aber auch Dienste, die kommunizieren, tun das vor allem mit ihren Hauptfunktionen. Funktionen mit Schwachstellen, die selten oder gar nicht im Regiebetrieb genutzt werden, sind nicht sichtbar oder eben erst dann, wenn der Angriff bereits läuft.

Die Infrastruktur überprüfen

Aktive Scans arbeiten anders und simulieren Angriffe. Sie stellen Anfragen an das System und versuchen dadurch, unterschiedliche Reaktionen auszulösen. Der aktive Scanner schickt zum Beispiel eine Anfrage zur Datenübermittlung an verschiedene Programme im System. Reagiert eines der Programme und leitet die Daten an die simuliert unbefugte Stelle weiter, hat der Scanner eine Sicherheitslücke gefunden.

Unterschiede zwischen aktiven und passiven Schwachstellenscans

Links: Beim aktiven Scan werden Anfragen an das System gesendet und dadurch versucht, unterschiedliche Reaktionen auszulösen. Rechts: Passive Scans überprüfen den Traffic, der ein System erreicht und gleichen diese Daten mit einer Datenbank ab.

Der Vorteil: Die Datenqualität, die beim aktiven Scannen erreicht werden kann, ist höher als beim passiven Scannen. Da die Interaktion direkt mit der Software und den Schnittstellen stattfindet, können Probleme in Programmen erkannt werden, die normalerweise nicht direkt mit dem Netz kommunizieren. Auf diese Weise werden auch Schwachstellen in Programmen wie Office-Anwendungen entdeckt.

Bei der direkten Interaktion müssen Systeme allerdings Extraanfragen bearbeiten, die dann unter Umständen die Grundfunktionen eines Programms beeinträchtigen. Betriebstechnik wie Maschinensteuerungen sind zum Beispiel nicht unbedingt dafür ausgelegt, Nebentätigkeiten auszuführen. Hier empfiehlt sich zum Beispiel Scannen unter Aufsicht und als Ergänzung kontinuierliches passives Scannen.

Aktiv scannen, aber minimalinvasiv

Trotzdem sind aktive Scans für die betriebliche Cyber-Sicherheit essenziell. Denn das Risiko, welches von der kurzfristigen Überbeanspruchung einer Systemkomponente ausgeht, ist klein im Vergleich zu einem Produktionsausfall oder einem Datenleck. Zudem decken aktive Scans nicht nur Schwachstellen auf, sie können auch passive Scans verbessern. So lassen sich die Schwachstellen, die erkannt werden, etwa in die Datenbanken von Firewalls aufnehmen. Das hilft auch anderen Unternehmen, die ähnliche Systeme nutzen.

Aktives und passives Scannen arbeiten Hand in Hand

Da der passive Scanner dem aktiven Scanner auch hilfreiche Informationen wie beispielsweise zu Mobiltelefonen oder Eigenschaften zu Netzwerk-Diensten geben kann, kann man von einer komplementären Ergänzung dieser beiden Sicherheitstools sprechen. Beiden ist gemein, dass sie aus der gegebenen Situation im Netzwerk automatisch immer das Beste herausholen. Für die Techniken des passiven und aktiven Scannens ist es egal, aus welchen oder wie vielen Komponenten und Programmen das Netzwerk besteht. Beide Sicherheitstechnologien erkennen dies von selbst und stellen sich darauf ein. Erst mit einem höheren Sicherheitsgrad beginnt die optimierte Abstimmung von Netzwerk und Scannern.

Es ist also keine Frage, ob man das eine oder das andere anwenden sollte. Beide Verfahren sind notwendig, um eine sichere Netzwerkumgebung zu gewährleisten. Ein rein passiver Ansatz wird in vielen Fällen nicht helfen. Ein proaktives Schwachstellenmanagement benötigt aktive Scans und Tools, um diese zu verwalten. Das ist es, was Greenbones Schwachstellenmanagement-Produkte bieten.


Open Source ist bei der überwiegenden Mehrheit der Firmen, Softwarehersteller und -anbieter unaufhörlich auf dem Vormarsch. Mit diesem Siegeszug steigt aber auch die Bedeutung der Überwachung der Supply Chain, also der „Lieferkette“ der eingesetzten Software, die Dritte gemäß den Open-Source-Traditionen entwickelt haben. Doch nicht jeder, der Open-Source-Software benutzt, beachtet dabei alle bewährten Regeln. Greenbone kann helfen, solchen Fehlern auf die Schliche zu kommen. Dieser Blogpost erklärt das Problem und wie es sich vermeiden lässt.

Supply Chains in Open-Source-Software

 

Schwachstellen in Log4j, Docker oder NPM

Ende 2021 schlug das Bundesamt für Sicherheit in der Informationstechnik (BSI) wegen einer aus der Ferne ausnutzbaren Schwachstelle in der Logging-Bibliothek Log4j offiziell Alarm – sogar die Tagesschau berichtete. Prompt meldeten sich damals die Kritiker von Open-Source-Software zu Wort: Quelloffene Software wie Log4j sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko.

Zwar hatten die Open-Source-Entwickelnden selbst das Problem binnen weniger Stunden gefixt, dennoch schlummern in zahllosen kommerziellen Produkten noch heute veraltete Versionen von Log4j – ohne Chance darauf, jemals ausgetauscht zu werden. Das ist kein Einzelfall: kürzlich sorgte die Geschichte eines Entwicklers für NPM (Node Package Manager, ein Softwarepaket-Format für den Webserver Node.js) für Aufsehen, der mit seinem eigentlich gut gemeinten Protest gegen den Krieg in der Ukraine das Vertrauen in die Open-Source-Supply-Chain und die Entwicklungsgemeinschaft massiv erschütterte.

Open Source in der Kritik

Es war nicht das erste Mal, dass NPM zum Ziel wurde. Schon Ende 2021 war der Paketmanager von Angriffen betroffen. Damals veröffentlichte der Entwickler Oleg Drapeza einen Fehlerbericht bei GitHub, nachdem er bösartigen Code zum Abfischen von Passwörtern in der Bibliothek UAParser.js gefunden hatte. Stück für Stück konnte der ursprüngliche Autor der Software, Faisal Salman, rekonstruieren, dass sich jemand in seinen Account im Paketsystem von NPM gehackt und dort Schadcode hinterlegt hatte. Das Problem: UAParser.js ist ein Modul für Node.js und kommt in Millionen von Setups weltweit zum Einsatz. Entsprechend gewaltig war der Kreis der betroffenen Nutzenden.

Wieder hieß es seitens der Open-Source-Kritischen, quelloffene Software wie UAParser.js sei implizit unsicher und in der Supply Chain anderer Programme ein praktisch unkalkulierbares Risiko. Mehr noch: Open-Source-Entwickelnde, so der explizit vorgetragene Vorwurf, bänden externe Komponenten wie Bibliotheken oder Container-Images viel zu unvorsichtig ein und verschwendeten kaum einen Gedanken an die damit verbundenen Sicherheitsimplikationen. Aus diesem Grund sei ihr Werk latent anfällig für Sicherheitsangriffe, vor allem eben in der Open-Source-Supply-Chain. Alyssa Shames diskutiert auf docker.com das Problem am Beispiel von Containern und schildert dabei ausführlich die Gefahren.

Die Schattenseiten des Basars

Tatsächlich haben DevOps und Cloud Native die Arbeitsweise in der Entwicklung in den vergangenen Jahren stark beeinflusst. In der Community existierende Komponenten in die eigene Anwendung einzubinden statt vergleichbare Funktionalität selber neu zu programmieren ist dabei Teil des Selbstverständnisses der gesamten Open-Source-Szene. Diese Community und ihr Angebot lassen sich mit einem Basar vergleichen, mit allen Vor- und Nachteilen. Viele Entwickelnde stellen ihre Programme gerade deshalb unter eine offene Lizenz, weil sie die Beiträge der anderen „Basarbesuchenden“ schätzen. Auf diese Weise können andere, die ähnliche Probleme haben, profitieren – unter denselben Bedingungen – und müssen das Rad nicht neu erfinden. Galt das früher mehr oder weniger nur für einzelne Bestandteile von Software, haben Cloud und Container dazu geführt, dass Entwickelnde inzwischen nicht mehr nur einzelne Komponenten übernehmen, sondern gleich ganze Images. Dabei handelt es sich um Softwarepakete, eventuell sogar inklusive Betriebssystem, die auf der eigenen Infrastruktur dann schlimmstenfalls ungeprüft starten.

Ein wachsendes Risiko?

In der Tat ist der mögliche Angriffsvektor dabei deutlich größer als zuvor und wird aktiv ausgenutzt. Laut Dev-Insider beispielsweise ist im vergangenen Jahr „die Zahl der Angriffe auf Open-Source-Komponenten […] von Software-Lieferketten laut einer Studie des Anbieters Sonatype […] um 430 Prozent gestiegen.“ Das bestätigt auch der Risiko-Analyse-Bericht von Synopsis, der zudem feststellt, „dass kommerzieller Code heute hauptsächlich aus Open-Source-Software besteht.“ Schon 2020 berichtete der Cloud-Native-Experte Aquasec auf seinem Blog von Angriffen auf die Docker-API, über die Cyber-Kriminelle Cryptomining in Docker-Images betrieben.

Allerdings sind Entwickelnde, die auf Open-Source-Komponenten zurückgreifen oder aus der Open-Source-Community stammen, nicht annähernd so unaufmerksam, wie es solche Meldungen suggerieren. Anders etwa als in proprietären Produkten, in denen lediglich die Mitarbeitenden eines Unternehmens den Code im Auge haben können, schauen in Open-Source-Projekten viele Menschen auf den verwalteten Quelltext. Dass dabei regelmäßig auch Sicherheitslücken wie im Fall von Log4j, Docker oder NPM ans Tageslicht kommen, liegt auf der Hand. Hier beweist die Open-Source-Szene dass sie gut funktioniert, nicht etwa dass ihre Software grundsätzlich unsicher(er) wäre.

Nicht schutzlos ausgeliefert

Ein großes Problem ist dagegen – unabhängig, ob Open-Source- oder proprietäre Software – die mangelnde Weitsicht bei der Update- und Patch-Strategie mancher Anbieter. Nur deshalb finden sich vielerorts Geräte mit veralteten, oft angreifbaren Softwareversionen, die als Scheunentor für Angreifende dienen können. Die Greenbone Enterprise Appliance, die professionelle Produktlinie von Greenbone, hilft dabei, solche Lücken zu finden und sie zu schließen.

Hinzu kommt, dass komplexe Sicherheitslecks wie die oben beschriebenen in Log4j oder UAParser.js eher die Ausnahme als die Regel darstellen. Die meisten Angriffe erfolgen mit deutlich simpleren Methoden: In den fertigen Images für Docker-Container im Docker Hub etwa findet sich regelmäßig Malware, die aus einer Datenbank den oben beschriebenen Bitcoin-Miner macht. Auch diesem Treiben stehen Entwickelnde, die Open-Source-Komponenten integrieren, jedoch keineswegs schutzlos gegenüber. Längst gibt es Standards, die Angriffe der beschriebenen Art verhindern, beispielsweise fertige Container-Images nur direkt beim Hersteller einer Lösung zu beziehen oder sie besser gleich per CI/CD-Pipeline selbst zu bauen. Ganz grundsätzlich steht Entwickelnden obendrein ein gesundes Misstrauen gut zu Gesicht, etwa wenn Software aus einer Quelle kommt, die erkennbar nicht jene des Herstellers ist.

Supply-Chain-Überwachung bei Greenbone

Dass Open-Source-Software im eigenen Programm kein unkalkulierbares Risiko ist, zeigt Greenbone in seinen Produkten, den Greenbone Enterprise Appliances. Im Unternehmen gelten eine Reihe von Richtlinien, die das Thema Supply Chain in der Softwareentwicklung in den gesamten Entwicklungszyklus einbinden. Neben umfangreichen Funktionstests unterzieht Greenbone seine Produkte dabei beispielsweise automatisierten Tests mit gängigen Sicherheitswerkzeugen. Wer bei Greenbone kauft, verlässt sich zu Recht auf das starke Gespann aus Open-Source-Transparenz und sorgfältigster Qualitätssicherung des Herstellers, ein Aufwand den sich nicht generell alle Open-Source-Projekte leisten können.

Apache, IIS, NGINX, MongoDB, Oracle, PostgreSQL, Windows, Linux: Ein Jahr nach Einführung bringt Greenbone zahlreiche neue Compliance-Richtlinien für CIS Benchmarks in seinen Produkten. CIS Benchmarks werden von Unternehmen, Organisationen oder Behörden genutzt, um zu prüfen, ob alle verwendeten Softwareprodukte, Anwendungen, Betriebssysteme und andere Komponenten sichere Vorgaben erfüllen. Ähnlich dem IT-Grundschutz-Kompendium des Bundesamts für Sicherheit in der Informationstechnik (BSI) stellt das Center for Internet Security (CIS), eine im Jahr 2000 gegründete Non-Profit-Organisation, umfangreiche Best Practices für die IT-Sicherheit von Regierungen, Industrie und Wissenschaft bereit. Schon 2021 entwickelte Greenbone erste Compliance-Richtlinien für CIS Benchmarks. Nun kommen 18 weitere Compliance-Richtlinien hinzu.

Compliance-Richtlinien für CIS Benchmarks

Benchmarks für die Unternehmenssicherheit

Die CIS Benchmarks bilden Richtlinien von Unternehmen und Behörden ab, die als Messlatte (Benchmark) für das Einhalten von Anforderungen dienen. Ausführlich beschreiben die Benchmarks Konfigurationen, Bedingungen, Audits und Tests für diverse Setups und Systeme. Nach erfolgreichem Scan erhalten IT-Admins einen umfangreichen Bericht mit einer Prozentzahl, die Aufschluss über die Compliance der Systeme, aber auch gleich Empfehlungen für weitere Härtungsmaßnamen liefert.

Im Vergleich zu den Vorgaben des IT-Grundschutz erweisen sich CIS Benchmarks häufig als deutlich detaillierter, damit aber auch als umfangreicher. Anders als die vielen Tests im Greenbone Enterprise Feed, die Sicherheitslücken und Schwachstellen suchen, um bei der Abwehr von Angriffen zu helfen, dienen die CIS Benchmarks dem Nachweis, dass ein Unternehmen oder eine Behörde die geltenden Compliance-Vorschriften zu jedem Zeitpunkt einhält und stets eingehalten hat.

CIS Benchmarks bei Greenbone

Bereits seit 2021 integriert Greenbone zahlreiche Compliance-Richtlinien für CIS Benchmarks. Bei diesen Richtlinien handelt es sich um Zusammenstellungen an Tests, die eine Greenbone-Lösung auf einem Zielsystem ausführt. Vereinfacht gesagt wird dabei für jede einzelne Anforderung oder Empfehlung aus einer CIS Benchmark ein Schwachstellentest entwickelt, der die Erfüllung jener Anforderung oder Empfehlung prüft. Alle Tests werden von Greenbone zu Scan-Konfigurationen zusammengefasst und zum Greenbone Enterprise Feed hinzugefügt. Da die Scan-Konfigurationen in diesem Fall Richtlinien von Unternehmen oder Behörden abbilden, werden sie als „Compliance-Richtlinien“ bezeichnet.

2022 baut Greenbone den Satz an CIS-Compliance-Richtlinien, der im Greenbone Enterprise Feed enthalten ist, deutlich aus. 18 weitere Compliance-Richtlinien für CIS Benchmarks für diverse Produktfamilien wurden hinzugefügt. Neben einer Compliance-Richtlinie für Docker-Container stehen jetzt auch Tests für Windows 10 Enterprise, Windows 2019 Server, Centos und distributionsunabhängige Linux-Benchmarks zur Verfügung. Außerdem können jetzt auch Webmaster mit Servern wie Apache (2.2 und 2.4), NGINX, Tomcat und Microsoft IIS 10 sowie Datenbankadministrationen (MongoDB 3.2 und 3.6, Oracle Community Server 5.6 und 5.7 sowie PostgreSQL 9.6, 10, 11 und 12) auf Compliance-Richtlinien für CIS Benchmarks zurückgreifen.

CIS Benchmarks: Level 1, 2 und STIG

Die CIS Benchmarks gliedern sich in mehrere Level (Level 1, 2 und STIG) und umfassen meist mehrere zu testende Konfigurationsprofile. Level 1 gibt grundlegende Empfehlungen zur Verringerung der Angriffsfläche eines Unternehmens, Level 2 adressiert Nutzende mit besonderen Sicherheitsbedürfnissen. STIG – das ehemalige Level 3 – kommt dagegen vor allem im militärischen oder behördlichen Umfeld zum Einsatz. STIG steht für Security Technical Implementation Guide. Das US-amerikanische Verteidigungsministerium pflegt hierzu eine Webseite mit allen Details. Die dort beschriebenen DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) sind eine Anforderung des US-Verteidigungsministeriums.

Zertifiziert von CIS

Greenbone ist Mitglied des CIS-Konsortiums und erweitert seine CIS-Benchmark-Scan-Konfigurationen fortlaufend. Wie alle von Greenbone auf Basis von CIS Benchmarks entwickelten Compliance-Richtlinien sind auch die neuesten von CIS zertifiziert – das bedeutet maximale Sicherheit, wenn es darum geht, ein System gemäß den Härtungsempfehlungen von CIS zu prüfen. Das vereinfacht nicht nur die Vorbereitung von Audits, wichtige Kriterien lassen sich schon vorab mit einem Scan durch eine Greenbone-Lösung prüfen und gegebenenfalls gefundene Schwachstellen beheben, bevor Probleme auftauchen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt vor dem Einsatz der Antivirensoftware des russischen Herstellers Kaspersky. Kein Wunder, denn Sicherheit ist Vertrauenssache. Sicherheitssoftware erst recht.

Im Zuge des Ukraine-Kriegs trifft es einen Closed-Source-Anbieter wie Kaspersky an seiner schwächsten Stelle. Denn seine Kundschaft muss etwas glauben, was sie aber wissen wollen und in kritischen Einsatzbereichen sogar wissen müssen: Dass der Einsatz einer Software keine nicht auditierbaren Risiken beinhaltet.

Bundesamt für Sicherheit in der Informationstechnik (BSI) warnt vor Kaspersky

Der Anbieter hat versucht, diesem Anspruch zu genügen, ohne seine Quellen Open Source zu stellen – durch sogenannte Transparenzzentren, in denen Quellcode eingesehen werden darf. Doch das reicht den Nutzenden aus verschiedenen Gründen nicht mehr.

Aktueller Anlass ist der Krieg in der Ukraine und letztlich die Tatsache, dass es sich um ein russisches Unternehmen handelt. Doch die Gründe und Ursachen liegen tiefer. Letztlich sind nicht nur russische Anbieter vom grundsätzlichen Problem betroffen. Software (und auch Hardware) kann, genauso wie die Daten, die verarbeitet werden, nur dann vertrauenswürdig sein, wenn die Quellen offen sind und der Produktionsprozess transparent ist.

Wir kennen das Problem bereits auch aus anderen Kontexten – ob ein Konstrukt „Transparenzzentrum“, „Safe Harbour“ oder „Privacy Shield“ heißt – letztlich sind dies Marketingbegriffe, die nicht verschleiern können, dass sie nicht die Transparenz und das Vertrauen bieten können, welches wir für sichere digitale Infrastrukturen brauchen. Das kann nur Open Source.