Agent, agentenlos oder beides? Was jede Architektur wirklich sehen kann

Agenten sind im Schwachstellenmanagement nichts Neues. Die Frage taucht immer wieder auf, weil der gescannte IT-Bestand nicht mehr stillhält. Ein Scanner, der davon ausgeht, dass jeder Host zu einer festen Zeit über ein bekanntes Netzwerk erreichbar ist, beschrieb die meisten Unternehmen vor fünfzehn Jahren noch recht treffend. Heute beschreibt er nur noch sehr wenige, in einem IT-Bestand mit Laptops, die sich zweimal pro Woche per VPN verbinden, Cloud-Instanzen mit einer Lebensdauer von vierzig Minuten und OT-Segmenten, die bewusst von jedem Standpunkt aus unerreichbar sind, von dem ein Scanner aus operieren könnte.

Die eigentlich wichtige Frage lautet also nicht, ob agentenbasiertes Scanning besser ist als agentenloses Scanning. Sie lautet, was jede Architektur wirklich sehen kann und welche Teile Ihres IT-Bestands bei beiden außen vor bleiben.

Ein Hinweis zum aktuellen Stand, bevor es um die grundsätzliche Frage geht: Die Scanning-Agent-Funktion von Greenbone ist derzeit als TechPreview innerhalb von OPENVAS SCAN verfügbar (nur Enterprise, nur im neuen Lizenzmodell) und wird in kontrollierter Form gemeinsam mit unserem Professional-Services-Team ausgerollt, während sie validiert wird. Der Rest dieses Beitrags behandelt die architektonische Frage, also den Teil, der unabhängig davon zählt, welche Tools Sie einsetzen.

Was „agentenlos“ wirklich bedeutet

Agentenloses Scanning bedeutet, dass die Prüfung nicht auf dem Zielsystem selbst läuft, sondern woanders. Ein Scanner nimmt einen Blickwinkel im Netzwerk ein und befragt den Host über dessen eigene Schnittstellen.

Das lässt sich in zwei recht unterschiedliche Dinge aufteilen, die oft so diskutiert werden, als wären sie eines:

Unauthentifiziertes Scanning betrachtet den Host von außen, ohne jede Berechtigung: offene Ports, Service-Banner, TLS-Konfiguration, exponierte Anwendungen, Verhalten, das sich abfragen lässt. Es beantwortet die Frage, die sich ein Angreifer stellt.

Authentifiziertes Scanning meldet sich an, über SSH, WMI oder eine API, und liest das System von innen aus: installierte Pakete und Versionen, Patch-Stand, Konfiguration.

Diese Unterscheidung ist wichtig, weil sie die häufigste Behauptung zu diesem Thema entkräftet. Ein authentifizierter agentenloser Scan und ein Agent sehen weitgehend denselben Zustand des Hosts. Beide lesen den lokalen Paketbestand und die Konfiguration aus. Der Unterschied zwischen ihnen liegt in der Tiefe der Einsicht (z. B. das Scannen jeder einzelnen Datei) und, da der Agent direkt auf dem Host installiert ist, in der Geschwindigkeit.

Was ein Agent verändert

Ein Agent verlagert die Ausführung auf den Host. Der NIST-Leitfaden zu Technologien für das Enterprise-Patch-Management beschreibt die Architektur unmissverständlich: „Eine agentenbasierte Patch-Management-Technologie erfordert, dass auf jedem zu patchenden Host ein Agent läuft, zusammen mit einem oder mehreren Servern, die den Patch-Prozess steuern und mit den Agenten koordinieren.“ Dasselbe Dokument benennt auch klar, wo der Ansatz seine Stärken ausspielt. Agentenbasierte Technologien werden „für Hosts, die nicht ständig im lokalen Netzwerk sind, etwa Laptops von Telearbeitenden und Smartphones, stark bevorzugt.“

Daraus ergeben sich mehrere Konsequenzen. Der Host muss zum Zeitpunkt der Prüfung nicht vom Scanner aus erreichbar sein; der Agent erfasst die Daten lokal und meldet sie, sobald wieder ein Rückweg besteht. Es müssen keine Scan-Zugangsdaten mehr an jedes einzelne Ziel verteilt oder dort gespeichert werden, wodurch ein dauerhaftes Problem mit privilegiertem Zugriff aus dem Netzwerk verschwindet. Und die Erreichbarkeit hängt nicht mehr von Firewall-Regeln, NAT oder der Segmentierung zwischen Scanner und Ziel ab.

In der Praxis bedeutet das eine Verschiebung weg vom Scan-Fenster hin zu etwas, das einem kontinuierlichen Zustand näherkommt.

Worauf jede Architektur verzichtet

Das ist die Hälfte des Themas, die Hersteller-Material gerne auslässt, und genau der Teil, den Praktiker brauchen.

Agentenloses Scanning bewertet keine Hosts, die gar nicht anwesend sind. NIST beschreibt diese Einschränkung so, dass „Hosts außerhalb des lokalen Netzwerks, etwa Laptops von Telearbeitenden und mobile Geräte“ ausgelassen werden, und weist darauf hin, dass Firewalls und Network Address Translation die Prüfung beeinträchtigen können. Kurzlebige Cloud-Workloads sind die moderne Variante desselben Problems: Ein Container, der nur für die Dauer eines Jobs existiert, wird sich nie mit einem nächtlichen Scan überschneiden. Authentifiziertes agentenloses Scanning benötigt außerdem Zugangsdaten mit echten Berechtigungen für jedes einzelne Ziel, was eine eigene Angriffsfläche darstellt und einen operativen Aufwand, der mit dem IT-Bestand wächst.

Agentenbasiertes Scanning stößt an eine härtere strukturelle Grenze: Ein erheblicher Teil eines typischen IT-Bestands kann überhaupt keinen Agenten ausführen. NIST weist erneut darauf hin, dass Hosts, „die keinen direkten Administratorzugriff auf das Betriebssystem erlauben, wie viele Appliances, in der Regel keine Agenten ausführen können,“ und dass Agenten möglicherweise nicht für jede Plattform verfügbar sind. In der Praxis umfasst diese Kategorie Netzwerk- und Sicherheitsgeräte, Storage-Appliances, Drucker, die meisten industriellen Systeme und Gebäudeleittechnik, eingebettete Geräte sowie alles im Netzwerk, worüber niemand die administrative Kontrolle hat, also genau jene Gruppe, die ohnehin am ehesten vernachlässigt wird. Ein Agent ist außerdem Software, die jetzt auf jedem Host installiert ist, mit eigenem Lebenszyklus, eigenem Ressourcenbedarf und eigenem Patch-Bedarf.

Die tiefere Grenze betrifft nicht die Reichweite, sondern die Perspektive. Ein Agent betrachtet den Host von innen. Er kann Ihnen sagen, dass ein verwundbares Paket installiert ist. Er ist aber schlecht dafür geeignet, Ihnen zu sagen, dass der betroffene Dienst aus dem Internet erreichbar ist, hinter einem falsch konfigurierten Proxy liegt oder auf einer Schnittstelle lauscht, die dafür nie vorgesehen war. Das ist eine Frage danach, wie das Netzwerk den Host sieht, und sie lässt sich nur aus dem Netzwerk heraus beantworten.

Warum Hybrid die Antwort ist, die einem echten IT-Bestand standhält

So betrachtet wirkt Hybrid nicht mehr wie ein Kompromiss zwischen zwei Optionen, sondern wie eine logische Folge daraus, dass beide unterschiedliche Fragen beantworten.

Keine der beiden Architekturen kann ihre eigenen blinden Flecken mit eigenen Stärken ausgleichen, aber beide gleichen die Schwächen der jeweils anderen aus. Agentenbasiertes Scanning erreicht genau die Hosts, die agentenloses Scanning verpasst: die abwesenden, mobilen und kurzlebigen. Agentenloses Scanning erreicht genau das, was Agenten nicht können, also alles, worauf sich kein Agent installieren lässt, und liefert zugleich die Außenperspektive, die ein Agent strukturell nicht erzeugen kann. Das ist eine ungewöhnliche Eigenschaft. Normalerweise dominiert ein Ansatz, und der andere wird zum Auslaufmodell.

Standards gehen längst von mehr als einem Blickwinkel aus. CIS Controls v8, Control 7.5, verlangt von Unternehmen, für interne Assets „sowohl authentifizierte als auch unauthentifizierte Scans mit einem SCAP-konformen Tool zur Schwachstellenerkennung durchzuführen.“ Diese Anforderung existierte schon vor der Agenten-Frage und ist unabhängig davon, aber die Begründung ist dieselbe: Eine einzelne Perspektive reicht nicht aus, um die Exposition eines Hosts zu beschreiben.

Hybrid richtig umgesetzt bedeutet nicht, alles doppelt zu scannen. Es bedeutet, für jede Asset-Klasse zu entscheiden, welcher Blickwinkel die Frage beantwortet, die Sie tatsächlich zu diesem Asset haben.

Ein praktischer Vorschlag für die Aufteilung

Mobile Endpunkte und alles, was nur zeitweise verbunden ist: ein Agent, sofern die Plattform das unterstützt. Das ist der Fall, für den agentenloses Scanning keine gute Antwort hat.

Appliances, Netzwerk- und Sicherheitsgeräte, OT und eingebettete Geräte: agentenlos, weil es keine Alternative gibt. Diese Assets sitzen zudem oft in Segmenten, die ein Scanner nur von einem gezielt platzierten Blickwinkel aus erreicht, was man besser plant, als es zu entdecken.

Server und langlebige Cloud-Instanzen: Hier funktioniert beides, also entscheiden Sie anhand Ihrer Zugangsdaten-Richtlinie und der Geschwindigkeit, mit der sich die Systeme ändern. Wenn die Verteilung von Scan-Zugangsdaten über einen großen Serverbestand ein Problem ist, das Sie lieber vermeiden möchten, nehmen Agenten es Ihnen ab. Wenn die Installation von Software auf Produktivsystemen intern das schwierigere Gespräch ist, ist authentifiziertes Scanning ein ausgereiftes und gut verstandenes Verfahren.

Öffentlich erreichbare Systeme: immer auch unauthentifiziert und von außen prüfen, unabhängig davon, was sonst noch bewertet. Das ist die einzige Sicht, die zeigt, was ein Angreifer erreichen kann, und kein Agent kann sie liefern.

Kurzlebige Workloads: Hier passt keine der beiden Architekturen wirklich gut. Das Image oder Template vor dem Deployment zu bewerten, ist meist die bessere Antwort, als zu versuchen, die Instanz während ihrer kurzen Lebenszeit zu erwischen.

All das macht agentenloses Scanning nicht zu einer unvollständigen Antwort für den IT-Bestand, für den es entwickelt wurde. Ein im Netzwerk befindlicher Host, der authentifiziert geprüft wurde, ist vollständig bewertet, und die Außensicht darauf zeigt nach wie vor als Einzige, was ein Angreifer erreichen kann. Da Agenten direkt auf dem Zielhost installiert sind, erweitern sie das Schwachstellenmanagement um detaillierte Informationen zu Hosts, die agentenlose Scans nicht entdecken können.

Quellen

1. NIST SP 800-40 Rev. 3, Guide to Enterprise Patch Management Technologies, §4.1.1 und §4.1.2. nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-40r3.pdf
2. CIS Controls v8, Control 7.5. cas8.docs.cisecurity.org/en/latest/source/Controls7