Air-gapped netzwerk sicherheitsaudit: Wie sich eine isolierte Umgebung ohne falsche Sicherheit pruefen laesst

Sicherheitsaudit fuer ein Air-Gapped-Netzwerk: Wie sich eine isolierte Umgebung ohne falsche Sicherheit pruefen laesst

Ein air-gapped netzwerk sicherheitsaudit sollte damit beginnen zu belegen, was die Umgebung tatsaechlich ist, und nicht damit, anzunehmen, dass "kein Internet" gleichbedeutend mit "kein erreichbarer Angriffspfad" ist. In der Praxis sind viele Unternehmensumgebungen, die als air-gapped beschrieben werden, nur logisch isoliert, stark segmentiert oder von kontrollierten Transferpfaden abhaengig. Diese Unterscheidung veraendert, was sich erfassen laesst, wie Findings validiert werden und welche Restrisiken innerhalb der Grenze verbleiben.

Dieser Artikel bleibt im Scope isolierter Unternehmensnetzwerke und nicht bei OT- oder ICS-Sicherheitsprogrammen. Wenn Ihre Hauptfrage weiterhin die Active-Directory-Pruefung innerhalb einer isolierten Gesamtstruktur ist, nutzen Sie Active Directory in einer Air-Gapped-Umgebung auditieren als Deep Dive. Das Ziel hier ist breiter: Wie sich Identitaets-, Host-, Netzwerk-, Logging- und Transferkontrollen pruefen lassen, die auch dann zaehlen, wenn sich die Umgebung nicht auf internetverbundene Werkzeuge oder cloud-native Sichtbarkeit stuetzen kann.

Was fuer ein air-gapped netzwerk sicherheitsaudit als Air-Gapped-Netzwerk zaehlt

Die CISA-Implementierungshilfe zu BOD 23-01 ist nuetzlich, weil sie eine klare Linie zwischen physisch air-gapped Umgebungen und nur logisch isolierten Umgebungen zieht. Das ist fuer ein Audit relevant, weil Ihre Pruefung in dem Moment auch den Pfad selbst einschliessen muss, in dem noch eine Management-Bruecke, ein Transfer-broker, ein Lieferantentunnel oder ein System existiert, das an ein anderes System angebunden ist, das die isolierte Umgebung beruehrt.

Es geht nicht darum, eine Taxonomie-Diskussion zu gewinnen. Es geht darum, falsche Sicherheit zu vermeiden. Eine isolierte Umgebung kann weiterhin Privileg-Drift, veraltete Admin-Konten, nicht sauber verwaltete jump hosts, schwache lokale Admin-Passwortpraxis, unsichere Protokolleinstellungen, unzureichende Log-Retention oder einen Transferpfad haben, der die vermeintlichen Kontrollen umgeht.

Was ein air-gapped netzwerk sicherheitsaudit wirklich belegen muss

Ein nuetzliches Sicherheitsaudit fuer ein Air-Gapped-Netzwerk endet nicht bei "das Netzwerk ist schwer zu erreichen". NIST SP 800-115 beschreibt Sicherheitsbewertungen als Planung, Belegerhebung, Analyse der Findings und Entwicklung von Gegenmassnahmen. In isolierten Umgebungen bedeutet das, dass das Audit mindestens fuenf Dinge belegen muss:

Ein Minimum Evidence Pack fuer diese Art Review sollte enthalten:

Grenze, Transferpfade und Administrationspfade zuerst festlegen

Der erste Scoping-Fehler in isolierten Umgebungen besteht darin, nur die Server zu auditieren, die klar "innerhalb" der Zone liegen, und die Systeme zu ignorieren, die sie administrieren koennen. Wenn ein jump server, ein Credential-Broker, ein Wechseldatentraeger-Prozess oder ein Staging-Host Inhalte oder Aenderungen in die isolierte Umgebung bringen kann, gehoert er in den Scope.

Kartieren Sie zuerst vier Pfadtypen:

1. Administrationspfade: jump hosts, privilegierte Workstations, break-glass-Konten, Lieferanten-Wartungspfade und jede Domain- oder Forest-Trust-Beziehung, die die isolierte Zone noch erreicht.
2. Transferpfade: Wechseldatentraeger-Workflows, file brokers, Einweg-Transferstationen, Paketspiegel und manuelle Exportpfade fuer Logs oder Reports.
3. Kontrollpfade: Systeme, die GPOs, Skripte, Zertifikate, Software oder Update-Kataloge in die Umgebung pushen koennen.
4. Beobachtungspfade: WEC-Server, lokale Collector, Log-Export-Hosts und jedes System, das Findings ausserhalb des isolierten Netzwerks auswertet.

Hier scheitern viele "air-gapped" Reviews. Das Kernrisiko ist nicht immer eine oeffentliche Angriffsoberflaeche. Oft ist es eine stille Management-Abhaengigkeit, die niemand dokumentiert hat, weil sie nicht wie Internetzugang aussieht.

Wenn die isolierte Umgebung AD-gestuetzt ist, sollte dieser Scoping-Schritt zur tieferen Review-Sequenz in Active Directory-Sicherheit auditieren: Was zuerst zu pruefen ist und wie sich Remediation nachweisen laesst und zum Wiederholungsmodell in Wiederkehrendes Active Directory Audit: Warum jaehrliche Audits veralten und wie kontinuierliches Posture Monitoring funktioniert passen. Isolation beseitigt nicht die Notwendigkeit, zu kartieren, wer Richtlinien, Mitgliedschaften, ACLs, Logging oder Zertifikatsausstellung tatsaechlich aendern kann.

Was sich auch ohne Internetzugang noch auditieren laesst

Internetzugang ist keine Voraussetzung fuer den Grossteil der Belege, die in einem Windows-lastigen isolierten Netzwerk wichtig sind. Microsoft Open Specifications fuer Active Directory und Group Policy machen den Kernpunkt deutlich: Verzeichnisdaten, Policy-Metadaten und dateibasierte Policy-Inhalte sind lokale Protokolle und lokale Stores, keine Cloud-Abhaengigkeiten.

Ein ernsthaftes Offline-Review kann weiterhin messen:

• Identitaets- und Privilegstruktur: privilegierte Gruppen, verschachtelte Gruppen, delegierte Rechte, veraltete Admins, Servicekonten, Trusts und Admin-Pfade
• Zustand von Group Policy und SYSVOL: GPO-Metadaten, dateibasierte Policy-Inhalte, Skripte, Preference-Artefakte und Pfadintegritaet
• Host-Posture: Rotation lokaler Admin-Passwoerter, SMB-Signierung, LDAP-Signierung, NTLM-Fallback, Windows-Firewall-Posture und relevante Hardening-Baselines
• Netzwerk-Exposition innerhalb der Grenze: Administrationspfade, erlaubte Protokolle, fuer Relay relevante Oberflaechen und Erreichbarkeit von jump hosts
• Log-Sichtbarkeit: Event-Erzeugung, Forwarding, Collector-Abdeckung, Retention und Exportverfahren
• Zertifikatsdienste, falls vorhanden: Enrollment-Oberflaechen, Template-Exposition und zertifikatbasierte Admin-Pfade

Darum sollte das breitere Netzwerk-Audit auf das AD-spezifische Pillar Active Directory in einer Air-Gapped-Umgebung auditieren verlinken und es nicht ersetzen. Die tieferen Identitaetsmechaniken bleiben wichtig; dieser Artikel erweitert den Scope lediglich auf die umgebende Grenze, den Transfer, das Logging und die operativen Einschraenkungen.

Datenquellen und Werkzeuge, die offline weiter funktionieren

Die belastbarsten Audits isolierter Netzwerke nutzen mehrere lokale Belegquellen, weil kein einzelnes System die ganze Geschichte erzaehlt.

Zwei Microsoft-spezifische Caveats sind hier wichtig.

Erstens ist Group Policy nicht nur ein AD-Thema. Microsoft dokumentiert, dass GPOs logische Komponenten in Active Directory und physische Komponenten im in SYSVOL gespeicherten Group Policy Template haben. Wenn Sie nur LDAP-Daten inspizieren, unterpruefen Sie die Policy-Oberflaeche.

Zweitens ist WEF hilfreich, aber begrenzt. Microsoft beschreibt, dass WEF vorhandene operative oder administrative Events liest und ausgewaehlte Events an einen WEC-Server weiterleitet, dabei aber hinsichtlich der Event-Erzeugung passiv bleibt. Es kann weder Event-Log-Groessen aendern, deaktivierte Event-Channels aktivieren, Channel-Berechtigungen anpassen noch die Security Audit Policy veraendern. Anders gesagt: Unvollstaendige Logs effizienter weiterzuleiten bleibt unvollstaendiges Logging.

In Domaenenumgebungen weist Microsoft ausserdem darauf hin, dass WEF-Traffic standardmaessig auch dann mit Kerberos verschluesselt wird, wenn HTTP genutzt wird, waehrend HTTPS hauptsaechlich dann erforderlich ist, wenn zertifikatbasierte Authentifizierung Kerberos ersetzt. Das macht WEF/WEC in vielen isolierten Windows-Umgebungen realistisch, aber nur dann, wenn die Event-Quellen bereits die richtigen Belege erzeugen.

Identitaets-, Host-, Netzwerk- und Logging-Kontrollen gemeinsam pruefen

Isolierte Umgebungen lassen sich leicht schlecht auditieren, wenn jede Kontrollfamilie getrennt geprueft wird. Der belastbarere Ansatz ist, Identitaets-, Host-, Netzwerk- und Logging-Kontrollen im selben Durchgang zu korrelieren.

Identitaet und Privilegien

Beginnen Sie mit denjenigen, die die Umgebung veraendern koennen, nicht mit denjenigen, die nur zu ihr gehoeren. Dazu zaehlen Domain- und lokale Admins, break-glass-Konten, Servicekonten, delegierte Rechte und die Betreiber von jump hosts oder Transferservern. Fuer stark AD-zentrierte Umgebungen nutzen Sie Active Directory-Sicherheit auditieren: Was zuerst zu pruefen ist und wie sich Remediation nachweisen laesst fuer die detaillierte Identitaets-Review-Sequenz und Windows LAPS nicht bereitgestellt: Warum gemeinsam genutzte lokale Admin-Passwoerter riskant bleiben, wenn gemeinsame lokale Admin-Credentials ueber isolierte Windows-Hosts hinweg weiter existieren.

Host- und Protokoll-Posture

Protokollschwaechen verlieren nicht an Relevanz, nur weil sie sich innerhalb des Perimeters befinden. SMB-Signierung, NTLM-Exposition, LDAP-Signierung, veraltete lokale Admin-Praktiken und Relay-relevante Pfade bleiben lokale Lateral-Movement-Probleme. Wenn das Netzwerk stark auf Windows-Authentifizierung setzt, ist SMB-Signierung deaktiviert: Warum sie NTLM-Relay weiter ermoeglicht weiterhin direkt relevant, ebenso wie die Review von Zertifikatspfaden ueber ADCS-Angriffspfade: wie Zertifikat-Fehlkonfigurationen zu Eskalationspfaden in Active Directory werden, falls AD CS existiert.

Netzwerk- und Transferpfade

Pruefen Sie, welche Systeme mit welchen anderen Systemen fuer Administration, Update-Import, Log-Export und Pakettransfer kommunizieren duerfen. Ein Bastion-Host, der Domain Controller, Paketspiegel und file brokers erreichen kann, ist ein hochrelevanter Kontrollpunkt, selbst wenn er nie im oeffentlichen Internet surft. Wenn Wechseldatentraeger Teil des Workflows sind, auditieren Sie Freigabe, Scan, Staging und Import als Kontrolloberflaeche und nicht als operative Fussnote.

Logging und Retention

Lokale Sichtbarkeit muss gestaltet werden. Pruefen Sie Event-Erzeugung auf den relevanten Systemen, Forwarding-Konfiguration bei WEF/WEC, Collector-Zustand, Retention, Backlog-Verhalten und Exportverfahren. Wenn das Team eine Event-by-Event-Karte fuer AD-Aktivitaet benoetigt, dient AD Sicherheitsüberwachung: Event IDs und SIEM als tiefere Referenz. Das breitere Review isolierter Netzwerke sollte aber zuerst die Frage beantworten, ob die Umgebung genug lokale Belege bewahren kann, um ihre eigenen Sicherheitsbehauptungen zu stuetzen.

Einschraenkungen bei Updates, Signaturen und Vulnerability Intelligence

Hier werden Reviews isolierter Netzwerke oft zu optimistisch.

Microsoft dokumentiert, dass Windows Update Agent Offline-Systeme mit einem lokal bereitgestellten Wsusscn2.cab-Paket auf Sicherheitsupdates pruefen kann. Das ist nuetzlich, aber nicht gleichbedeutend mit voll verbundener Patch-Intelligence. Der Katalog enthaelt sicherheitsbezogene Update-Metadaten und hilft bei der Frage "welche Microsoft-Sicherheitsupdates scheinen zu fehlen?" Er enthaelt nicht die Updates selbst und loest weder das Thema Nicht-Microsoft-Software, Treiber, Appliance-Firmware noch die durch manuelle Importprozesse entstehende operative Verzoegerung.

Ein gutes Audit muss deshalb den Prozess und nicht nur das letzte Scan-Ergebnis pruefen:

• Wie werden Microsoft-Sicherheitskataloge importiert und wie oft?
• Wie werden Drittanbieter-Signaturen, EDR-Inhalte oder Vulnerability-Daten in die Umgebung gespiegelt, falls ueberhaupt?
• Wie lange braucht ein neu noetiges Paket oder eine neue Signatur, um die Grenze zu passieren?
• Welche Assets sind bewusst ausgeschlossen, weil es keine verlaessliche Offline-Methode gibt?
• Wer genehmigt Ausnahmen, wenn verbundene Guidance innerhalb der Grenze nicht direkt angewendet werden kann?

Wenn die Antworten informell sind, verlaesst sich die Umgebung darauf, dass sich Menschen daran erinnern, wie sie aktuell gehalten wird. Das ist kein auditierbarer Kontrollmechanismus.

Validierung nach der Remediation

Remediation in isolierten Netzwerken sollte genauso validiert werden, wie sie entdeckt wurde: mit demselben lokalen Scope, von derselben Seite der Grenze und mit denselben Belegklassen.

Eine praktische Validierungssequenz sieht so aus:

1. Rerun-Scope einfrieren: gleiche Segmente, gleiche Domaenen, gleiche Collector und gleiche Annahmen zu jump-Pfaden.
2. Die riskante Bedingung erneut messen: Privilegien, Host-Einstellungen, Logging, Transferpfade oder Update-Status.
3. Bestaetigen, dass die Aenderung die lokale Sichtbarkeit nicht zerstoert hat: Logging, WEF/WEC-Forwarding und Exportverfahren muessen nach dem Hardening weiter funktionieren.
4. Verbleibende Ausnahmen mit Owner und Review-Datum dokumentieren, insbesondere dort, wo Legacy-Kompatibilitaet einen sauberen Fix weiter blockiert.
5. Vorher-/Nachher-Belege mit Erfassungsdaten, Grenzannahmen und bekannten Blind Spots aufbewahren.

Warning: Ein exportierbares PDF ist fuer sich allein kein Beweis. In isolierten Umgebungen entsteht Beweiskraft aus wiederholbarer lokaler Erhebung plus stabiler Rerun-Methode.

Wie EtcSec Audits in isolierten Unternehmensnetzwerken unterstuetzt

Fuer diesen Use Case ist die relevante Produktgrenze einfach. Die offiziellen Collector-Materialien von EtcSec beschreiben einen read-only Collector, der in einem vollstaendig lokalen Standalone-Modus laufen kann, Daten in diesem Modus lokal haelt und Active-Directory-Belege ueber LDAP/LDAPS und SYSVOL sammelt. Dieses Bereitstellungsmodell ist in einem isolierten Unternehmensnetzwerk wesentlich relevanter als jede Aussage ueber Dashboards oder Cloud-Komfort.

In der Praxis bedeutet das, dass ein Team den Collector innerhalb derselben Vertrauensgrenze wie die geprueften Systeme halten, das Audit nach Remediation lokal erneut ausfuehren und das Belegmodell zwischen Review-Zyklen stabil halten kann. Wenn Sie Produktdetails statt Prozessfuehrung brauchen, nutzen Sie ETC Collector fuer das Bereitstellungsmodell und AD-Audit-Tool-Vergleich: Wie sich PingCastle, Purple Knight und wiederholbare Audit-Workflows vergleichen lassen, um zu verstehen, ab wann ein wiederholbarer lokaler Workflow die Entscheidung veraendert.

Der Wert liegt hier nicht darin zu behaupten, dass isolierte Netzwerke ein magisches Offline-Tool brauchen. Der Wert liegt in read-only lokaler Erfassung, stabilen Reruns und Findings, die nach der ersten Aufraeumwelle weiter nutzbar bleiben.

Primary References

• CISA: BOD 23-01 Implementation Guidance
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• Microsoft Learn: Use Windows Event Forwarding to help with intrusion detection
• Microsoft Learn: Using WUA to Scan for Updates Offline
• Microsoft Open Specifications: MS-ADOD
• Microsoft Open Specifications: MS-GPOD Group Policy Structure
• ANSSI: Recommandations pour l'administration securisee des SI reposant sur AD