Sicherheitstools fuer isolierte Netzwerke

Welche sicherheitstools funktionieren in isolierten netzwerken ohne internetzugang? Die praktische Antwort ist enger, als die meisten Produktseiten vermuten lassen. Manche Tools funktionieren weiterhin vollstaendig lokal. Andere passen nur dann, wenn sich Updates, Lizenzen oder Plugin-Pakete kontrolliert ueber die Grenze transportieren lassen. Wieder andere fallen in dem Moment aus dem Raster, in dem die Umgebung keinen Cloud-Control-Plane, keinen Live-Feed und keine internetfaehige API mehr erreichen kann.

Dieser Artikel bleibt im Scope isolierter Unternehmensnetzwerke mit einem betriebsnahen Fokus auf Active Directory und Windows. OT- oder ICS-Sicherheitsprogramme sind nicht das Thema. Wenn Ihre Hauptfrage weiterhin lautet, wie die Umgebung selbst zu auditieren ist, nutzen Sie Air-Gapped-Netzwerk-Sicherheitsaudit als process-first Leitfaden und Active Directory in einer Air-Gapped-Umgebung auditieren als tieferen AD-Pfad. Das Ziel hier ist ein anderes: Welche Tools und Workflows bleiben realistisch, wenn Internetzugang fehlt, stark ueber Broker vermittelt wird oder nur ueber kontrollierte Offline-Transfers moeglich ist.

Welche sicherheitstools funktionieren in isolierten netzwerken ohne internetzugang?

Ein Tool sollte nur dann als ohne Internetzugang nutzbar gelten, wenn seine eigentliche Sicherheitsfunktion innerhalb der Grenze weiterlaufen kann und die verbleibenden Abhaengigkeiten explizit sind. In der Praxis heisst das, zuerst vier Fragen zu beantworten:

Frage	Warum das in einem isolierten Netzwerk wichtig ist
Kann das Tool Daten lokal sammeln oder analysieren?	Wenn die Erfassung einen Cloud-Control-Plane voraussetzt, passt es nicht in einen echten Air Gap.
Braucht es Live-Feeds oder kann es mit staged offline updates arbeiten?	Manche Tools bleiben nutzbar, aber nur mit einem disziplinierten Transfer-Workflow.
Laesst es sich nach einer Remediation von derselben Seite der Grenze erneut ausfuehren?	Ein einmaliger Scan ist schwaecher als ein stabiles lokales Rerun-Modell.
Haelt das Tool Belege bei Bedarf innerhalb der Umgebung?	In isolierten Netzwerken ist Datenausgang meist eine Kontrollflaeche, keine Komfortfunktion.

Diese Unterscheidung zaehlt, weil viele als offline bezeichnete Umgebungen in Wirklichkeit nur logisch isoliert sind oder von Bastions, Brokern oder manuellen Transferpfaden abhaengen. Die BOD-23-01-Implementation-Guidance von CISA ist weiterhin der klarste offizielle Hinweis darauf, dass physisch air-gapped etwas anderes ist als lediglich isoliert. Ein Tool, das mit staged Imports ueber eine Transfergrenze funktioniert, ist nicht dasselbe wie ein Tool ohne jede externe Abhaengigkeit.

Zuerst local-only Workflows von cloud-dependent Tools trennen

Die sauberste Art, Tooling in einer isolierten Umgebung zu bewerten, ist die Trennung in drei Modelle.

Tool-Modell	Was weiter funktioniert	Hauptgrenze
Local-only Workflow	Erfassung und Auswertung passieren vollstaendig innerhalb der Grenze.	Es braucht trotzdem genug lokale Belegquellen und genug operative Faehigkeit, um sie zu interpretieren.
Offline-capable mit staged updates	Das Tool laeuft lokal, aber Signaturen, Plugins, Lizenzen oder Kataloge muessen manuell importiert werden.	Die operative Frische haengt vom Transferprozess ab, nicht nur vom Tool.
Cloud-dependent	Das Produkt setzt einen SaaS-Control-Plane, internet-erreichbare APIs oder dauerhaft online verfuegbaren Content voraus.	In einem echten Air Gap passt es meist nicht mehr, selbst wenn sich ein Installer lokal starten laesst.

Das ist der Rahmen fuer den Rest des Artikels. Die Frage ist nicht, ob ein Hersteller behauptet, seine Software koenne auf einem Windows-Host installiert werden. Die Frage ist, ob der Sicherheitswert bestehen bleibt, wenn es keinen direkten Internetpfad und keinen unsichtbaren Ausnahmeweg mehr gibt, der die eigentliche Arbeit uebernimmt.

Native Windows- und Active-Directory-Werkzeuge funktionieren weiterhin offline

Der verlaesslichste Startpunkt in einem isolierten Unternehmensnetzwerk bleibt das native Windows- und Active-Directory-Belegmodell.

Microsoft-Dokumentation und Open Specifications machen den Kernpunkt eindeutig: Verzeichnisdaten, Group-Policy-Metadaten, in SYSVOL liegende Richtliniendateien, lokale Event-Logs und Windows Event Forwarding benoetigen keinen Internetzugang, um zu existieren oder geprueft zu werden. Ein serioeser lokaler Workflow kann sich daher weiterhin stuetzen auf:

LDAP- oder LDAPS-Abfragen fuer Benutzer, Gruppen, Delegationen, Trusts und privilegienrelevante Attribute
eine Group-Policy-Pruefung, die sowohl AD-Metadaten als auch SYSVOL-getragene Richtlinieninhalte umfasst
lokale Event-Logs plus WEF/WEC zur Zentralisierung von Belegen innerhalb der Grenze
lokales PowerShell fuer Host-Konfiguration, Protokoll-Posture und Kontrollvalidierung
Windows-Update-Agent-Offline-Scans mit Wsusscn2.cab zur Erkennung fehlender Microsoft-Sicherheitsupdates

Die Grenze dabei ist: Native Werkzeuge liefern Belegquellen, aber kein fertiges Sicherheitsprogramm. WEF/WEC hilft beim Weiterleiten dessen, was bereits existiert, aber Microsoft dokumentiert ausdruecklich, dass der Mechanismus in Bezug auf Event-Erzeugung, Log-Groesse, deaktivierte Kanaele und Audit-Policy passiv bleibt. Ebenso kann ein WUA-Offline-Scan fehlende Microsoft-Sicherheitsupdates zeigen, ersetzt aber keinen verbundenen Workflow fuer Schwachstellenintelligenz.

Darum stehen native Werkzeuge in der ersten Zeile der Matrix weiter unten. Sie sind die am besten vertretbare Offline-Basis, aber eben nicht allein die vollstaendige Antwort.

Point-in-time Assessment-Tools, die in isolierten Netzwerken laufen koennen

Zwei AD-zentrierte Tools lassen sich hier weiterhin sauber nennen, weil ihr Offline- oder Disconnect-Verhalten offiziell dokumentiert ist und weil ihre Rolle enger ist als die einer Cloud-Sicherheitsplattform.

PingCastle

PingCastle ist eines der klarsten Beispiele fuer ein Tool, das in isolierten Netzwerken weiter passt, weil die offizielle Dokumentation mehrere entkoppelte Deployment-Muster explizit beschreibt. Health Check ist der Standardreport. Die Deploy-Dokumentation behandelt Domaenen ohne Netzwerkverbindung, Sammeln ueber Bastions, woechentliche Planung und verschluesselten Report-Transfer ueber unsichere Kanaele. Die Consolidation-Dokumentation beschreibt das Zusammenfuehren mehrerer Reports in eine uebergeordnete Sicht.

Das macht PingCastle zu einer realistischen Option fuer AD-Bewertung point-in-time, wenn die Anforderung ist:

nur on-prem Active Directory
ein lokaler HTML-first Report
Ausfuehrung pro Domaene oder ueber ein Bastion-System
ein praktikables Modell fuer Report-Sammlung selbst dann, wenn Zentralisierung unbequem ist

Es ist ein guter Fit fuer AD-Scorecards offline. Es ist keine allgemeine Offline-Sicherheitsplattform und loest weder Update-Intelligenz noch hybride Identitaet noch breite Host- und Netzwerk-Transparenz ausserhalb seines AD-orientierten Modells.

Purple Knight

Purple Knight bleibt ebenfalls relevant, aber nur dann, wenn es praezise beschrieben wird.

Semperis sagt in der offiziellen FAQ, dass Purple Knight installierte Software ist, keine Aenderungen an Active Directory vornimmt, die Faehigkeit zum Ausfuehren von PowerShell-Skripten voraussetzt, fuer bestimmte Schwachstellen-Scans LDAP ueber RPC nutzt und keine Phone-home-Funktionen besitzt. Dieselbe FAQ sagt ausserdem, dass Purple Knight eine point-in-time Scorecard liefert und dass der Report gescannte Indikatoren, Pass/Fail-Status, MITRE ATT&CK-Mapping und Remediation-Hinweise enthaelt.

Damit bleibt Purple Knight fuer eine on-prem AD-Bewertung in einer isolierten Windows-centric Umgebung brauchbar, wenn ein lokal installiertes Assessment-Tool gefragt ist und kein Cloud-Control-Plane. Purple Knight ist von Semperis aber zugleich als AD- und Entra-Assessment-Produkt positioniert. Die offizielle FAQ erklaert, dass fuer Entra eine App Registration und Microsoft-Graph-Berechtigungen noetig sind.

ℹ️ Dokumentierte Inferenz aus den offiziellen Quellen: Purple Knight bleibt fuer die Pruefung von on-prem AD innerhalb eines isolierten Netzwerks geeignet, aber der Entra-Teil faellt aus einem echten Umfeld ohne Internetzugang heraus, weil Microsoft Graph ausserhalb dieser Grenze liegt.

Dieser Caveat ist wichtig. Purple Knight gehoert in diesen Artikel fuer die AD-Seite, nicht als pauschale Behauptung, dass sein gesamter hybrider Umfang in einem echten Air Gap weiter funktionieren wuerde.

Schwachstellen-Scanner, die mit staged offline updates weiter funktionieren

Das am besten vertretbare Scanner-Beispiel hier ist Tenable Nessus im Offline Mode, weil Tenable den Workflow explizit dokumentiert.

Tenable dokumentiert offiziell, dass Nessus in den Offline Mode gesetzt werden kann und empfiehlt diesen Modus fuer Scanner, die offline oder air-gapped sind. Dieselbe Dokumentation sagt auch, dass der Offline Mode Funktionen deaktiviert, die eine Verbindung zum Nessus-Feed brauchen, darunter Core- und Plugin-Updates, Feed-Status-Updates, die Anbindung an Tenable Vulnerability Management und weitere In-App-Funktionen.

Der operative Kernpunkt ist, dass offline-capable nicht self-sufficient bedeutet. Die Tenable-Dokumentation zu Offline-Installation und Offline-Updates macht klar, dass:

Offline-Registrierung ein eigener Prozess ist
ein internetverbundenes Hilfssystem benoetigt wird, um Artefakte abzurufen
Plugin-Pakete manuell transferiert werden muessen
die Aktualitaet des Scanners davon abhaengt, wie gut dieser Transferprozess gepflegt wird

Damit bleibt Nessus trotzdem ein gueltiger Eintrag in einem tools-first Artikel fuer isolierte Netzwerke. Es wird dadurch nur nicht einfach. In einem echten Air Gap ist der Scanner nur so aktuell wie der staged-update-Pfad, der ihn versorgt.

Was in einem echten Air Gap meist nicht mehr traegt

Einige Tool-Kategorien passen in dem Moment meist nicht mehr, in dem die Umgebung weder das Internet noch eine genehmigte externe API erreichen kann.

SaaS-only Produkte, deren primaeres Analyse-, Policy- oder Belegmodell in einem entfernten Control Plane lebt
Produkte, die eine dauerhafte Aktualisierung von Signaturen, Reputation oder Threat Intelligence ohne dokumentierten Offline-Importpfad voraussetzen
Werkzeuge, die sich lokal installieren lassen, aber fuer ihren Hauptnutzen trotzdem Tenant-Registrierung, Cloud-API-Zugriff oder internetbasierte Korrelation annehmen
Agenten-Oekosysteme, deren Versionierung, Policy-Synchronisierung oder Analytik deutlich abbauen, sobald die Umgebung ihre Online-Konnektivitaet verliert

Hier verlieren Teams Zeit. Eine Produktdemo kann lokal genug aussehen, bis die versteckte Abhaengigkeitskette sichtbar wird: Registrierung, Lizenzpruefungen, Plugin-Feeds, Graph-Zugriff, Cloud-Scoring oder webbasierte Hilfe und Updates. In isolierten Umgebungen gehoeren diese Abhaengigkeiten zur Design-Pruefung und sind kein Hintergrundrauschen.

Kurze Matrix: Sicherheitstools fuer isolierte Netzwerke ohne Internetzugang

Tool oder Workflow	Funktioniert ohne Internet?	Was weiterhin noetig ist	Bester Fit	Wo es in einem echten Air Gap bricht
Native Windows / AD tooling	Ja	Operative Faehigkeit, lokaler Erfassungszugang und ein diszipliniertes Belegmodell	Lokale Basispruefung von AD, GPO, Logs, WEF/WEC, PowerShell und WUA-Offline-Scan	Es liefert fuer sich allein kein verpacktes Sicherheitsprogramm.
PingCastle	Ja, fuer AD-Bewertung	AD-Konnektivitaet, einen lokalen oder Bastion-Ausfuehrungspunkt und Report-Sammlung	Point-in-time AD-Health-Checks in entkoppelten oder schwer zu zentralisierenden Umgebungen	Es bleibt eng: AD-fokussiert, HTML-first und kein kompletter Workflow fuer hybride Identitaet oder Schwachstellenintelligenz.
Purple Knight	Ja, fuer on-prem AD-Bewertung	Lokale Ausfuehrung, PowerShell und LDAP ueber RPC fuer bestimmte Scans	Schnelle lokale AD-Bewertung mit indikatorbasierter Remediation	Der Entra-Teil haengt an Microsoft Graph, daher traegt der hybride Umfang nicht in einem echten Air Gap.
Tenable Nessus Offline Mode	Ja, bedingt	Offline-Registrierung sowie manueller Transfer von Plugins und Artefakten	Lokales Vulnerability Scanning, wenn ein staged-update-Prozess bereits akzeptiert ist	Feed-abhaengiger Komfort faellt weg, und das Modell wird operativ schwer, wenn Offline-Updates schlecht gepflegt sind.
ETC Collector standalone	Ja	Lokales Deployment, read-only Zugriff und derselbe boundary-interne Rerun-Workflow nach Remediations	Repeatable Sicherheitspruefungen per lokaler Sammlung und Reruns in vorsichtigen oder isolierten Unternehmensumgebungen	Es soll nicht jede verbundene Intelligenzquelle ersetzen; am staerksten ist es dort, wo lokale Belege und repeatable Reruns am meisten zaehlen.

Der Punkt dieser Matrix ist nicht, einen Sieger auszurufen. Sie soll trennen zwischen Tools, die offline operativ ehrlich bleiben, und solchen, die nur so lange offline wirken, bis ihre Abhaengigkeitskette geprueft wird.

Wie Sie den richtigen Mix fuer ein isoliertes Unternehmensnetzwerk waehlen

Ein gutes Tool-Set fuer ein isoliertes Netzwerk ist meist ein Mix und kein Einzelprodukt.

Starten Sie mit den lokalen Belegquellen, die nativ weiter funktionieren: AD-Daten, SYSVOL, lokale Logs, WEF/WEC und Host-Konfigurationspruefung.
Ergaenzen Sie ein point-in-time AD-Assessment-Tool, wenn Sie schneller einen Ueberblick ueber Privilegien und Richtlinien brauchen. PingCastle und Purple Knight sind beide valide, aber aus unterschiedlichen Gruenden.
Ergaenzen Sie einen offline-capable Scanner nur dann, wenn die Organisation bereit ist, den staged-update-Pfad sauber zu pflegen. Sonst altert die Scanner-Ausgabe schneller als die Umgebung selbst.
Bevorzugen Sie Tools, die Sie nach Remediation lokal von derselben Seite der Grenze erneut ausfuehren koennen. Das ist wichtiger als ein schoenes erstes Dashboard.
Lassen Sie cloud-dependent Produkte ausserhalb des Scopes, ausser die Umgebung ist nur logisch isoliert und der Abhaengigkeitspfad ist formal freigegeben und dokumentiert.

Hier bleiben auch die tieferen Artikel hilfreich. Nutzen Sie Active Directory Sicherheit auditieren fuer die Pruefsequenz, Wiederkehrendes Active Directory Audit fuer die Rerun-Logik, Windows LAPS nicht bereitgestellt, wenn lokale Admin-Wiederverwendung weiter existiert, und SMB-Signierung deaktiviert, wenn das Risiko fuer laterale Bewegung weiter durch die Protokoll-Posture bestimmt wird.

Wenn AD CS in der isolierten Umgebung vorhanden ist, gehoert Zertifikats-Exposure weiterhin in dieselbe erste Review-Stufe, auch wenn es hier nicht das Hauptthema ist. Nutzen Sie ADCS-Zertifikatangriffe ESC1 bis ESC8 fuer diesen Pfad.

Wie EtcSec in Offline-Sicherheits-Workflows passt

Fuer diesen Anwendungsfall ist die einzig wirklich wichtige Produkt-Aussage das Deployment- und Collection-Modell.

Das offizielle Collector-Material von EtcSec beschreibt einen read-only Collector, der in einem vollstaendig lokalen Standalone-Modus laufen kann. In diesem Modell bleiben GUI und REST-API lokal, die Daten bleiben lokal, und die Sammlung kann weiter Active-Directory-Belege ueber LDAP oder LDAPS sowie SYSVOL abdecken. Das ist die richtige Produktgrenze fuer ein isoliertes Netzwerk, weil sie zur echten Restriktion passt: lokale Sammlung und lokale Reruns zaehlen mehr als Cloud-Komfort.

Wenn Sie den breiteren Prozessrahmen brauchen, nutzen Sie Air-Gapped-Netzwerk-Sicherheitsaudit. Wenn Sie den breiteren Rahmen zur Tool-Bewertung brauchen, nutzen Sie Vergleich von Active-Directory-Sicherheitsaudit-Tools. Wenn Sie das Deployment-Detail des lokalen Collector-Modells brauchen, nutzen Sie ETC Collector.

Der praktische Fit ist einfach: EtcSec gehoert in die Diskussion, wenn lokale read-only Collection und Rerun-basierte Reviews innerhalb derselben Vertrauensgrenze gefordert sind, nicht wenn das Team nur einen einmaligen Screenshot will.

Welche Sicherheitstools funktionieren in isolierten Netzwerken ohne Internetzugang? Praktischer Leitfaden fuer offline-faehige Sicherheits-Workflows