Audit di sicurezza di una rete air-gapped: come auditare un ambiente isolato senza falso senso di sicurezza
Un audit sicurezza rete air gapped deve iniziare dimostrando che cosa sia davvero l'ambiente, non assumendo che "niente internet" significhi "nessun percorso di attacco raggiungibile". In pratica, molti ambienti aziendali descritti come air-gapped sono soltanto logicamente isolati, fortemente segmentati o dipendenti da percorsi di trasferimento controllati. Questa distinzione cambia che cosa si puo raccogliere, come si validano i findings e quali rischi residui rimangono dentro il perimetro.
Questo articolo resta nello scope delle reti aziendali isolate, non dei programmi di sicurezza OT o ICS. Se la vostra domanda principale resta l'audit di Active Directory all'interno di una foresta isolata, usate Come auditare Active Directory in un ambiente air-gapped come deep dive. L'obiettivo qui e piu ampio: come rivedere i controlli di identita, host, rete, logging e trasferimento che continuano a contare quando l'ambiente non puo dipendere da strumenti connessi a internet o da visibilita cloud-native.
Che cosa conta come rete air-gapped per un audit sicurezza rete air gapped
La guida di implementazione CISA per BOD 23-01 e utile perche traccia una linea netta tra ambienti fisicamente air-gapped e ambienti solo logicamente isolati. Questo conta per un audit perche, nel momento in cui esiste ancora un bridge di amministrazione, un broker di trasferimento, un tunnel di un fornitore o un sistema connesso a un altro sistema che tocca l'ambiente isolato, anche quel percorso deve rientrare nella review.
| Modello di isolamento | Significato pratico per un audit | Conseguenza per l'audit |
|---|---|---|
| Niente internet | Nessun accesso diretto in uscita verso internet, ma i percorsi interni di routing e amministrazione esistono ancora. | Un audit locale e di solito praticabile, ma i workflow dipendenti dal cloud possono risultare inutilizzabili. |
| Isolamento logico | L'accesso e limitato tramite bastions, broker, jump hosts, firewall o percorsi di trasferimento controllati. | La definizione del perimetro e dei percorsi di trasferimento fa parte dell'audit, non del semplice contesto. |
| Segmentato | L'ambiente e instradabile ma limitato da ACL, VLAN o policy firewall. | Va trattato come connesso per i rischi di privilegio, protocollo e movimento laterale. |
| Air-gapped fisico | Non esiste alcun percorso di rete verso internet o verso l'ambiente operativo piu ampio. | Raccolta, review, export e prova della remediation richiedono un workflow interamente locale. |
Il punto non e vincere una discussione di tassonomia. Il punto e evitare falsa sicurezza. Un ambiente isolato puo avere ancora deriva dei privilegi, admin obsoleti, jump hosts non governati, pratiche deboli sulle password degli admin locali, configurazioni di protocollo insicure, retention dei log insufficiente o un percorso di trasferimento che aggira i controlli che il team pensa di avere.
Che cosa un audit sicurezza rete air gapped deve davvero dimostrare
Un audit di sicurezza di rete air-gapped utile non si ferma a "la rete e difficile da raggiungere". NIST SP 800-115 inquadra la valutazione di sicurezza come pianificazione, raccolta di evidenze, analisi dei findings e sviluppo di mitigazioni. Negli ambienti isolati, questo significa che l'audit deve dimostrare almeno cinque cose:
| Domanda di audit | Che cosa deve essere dimostrato localmente |
|---|---|
| Qual e il vero perimetro? | Quali sistemi sono all'interno, quali sistemi possono amministrarli e quali percorsi di manutenzione o trasferimento attraversano ancora il confine |
| Chi detiene il potere effettivo? | Quali account, gruppi, service principals, admin locali e ruoli delegati possono modificare identita, policy, logging o stato degli aggiornamenti |
| Che cosa consente ancora movimento laterale? | Quali protocolli, condivisioni, percorsi di relay e rotte di amministrazione restano disponibili tra host o segmenti |
| Quali evidenze sopravvivono offline? | Quali log, subscriptions, impostazioni di retention e procedure di export preservano davvero telemetria utile all'interno del perimetro |
| I fix possono essere rivalidati? | Se lo stesso metodo di raccolta locale puo essere eseguito di nuovo dopo la remediation per provare che la condizione rischiosa e sparita |
Un minimum evidence pack per questo tipo di review dovrebbe includere:
| Classe di evidenza | Perche conta |
|---|---|
| Documentazione aggiornata del confine di rete e del routing | Non si verificano affermazioni di isolamento con un diagramma obsoleto |
| Inventario di jump hosts, bastions, broker e percorsi di trasferimento | Spesso sono i veri ponti attraverso l'"air gap" |
| Inventario degli account privilegiati e dei percorsi amministrativi | Il rischio di identita resta locale anche quando l'esposizione internet non lo e |
| Configurazione locale di logging, WEF/WEC e retention | Essere offline non aiuta se l'evidenza viene sovrascritta prima della review |
| Processo di import di patch, firme e cataloghi | La freschezza degli aggiornamenti e un processo operativo, non un'ipotesi |
| Metadati di rerun prima e dopo | Le affermazioni di remediation sono deboli se scope o collector cambiano tra le esecuzioni |
Definite prima il confine, i percorsi di trasferimento e i percorsi di amministrazione
Il primo errore di scoping in un ambiente isolato consiste nell'auditare solo i server chiaramente "dentro" la zona e ignorare i sistemi che possono amministrarli. Se un jump server, un credential broker, un processo basato su supporti rimovibili o un host di staging puo portare contenuti o modifiche nell'ambiente isolato, deve rientrare nello scope.
Iniziate mappando quattro tipi di percorso:
- Percorsi di amministrazione: jump hosts, workstation privilegiate, account break-glass, percorsi di manutenzione dei fornitori e qualsiasi relazione di trust di dominio o foresta che raggiunga ancora la zona isolata.
- Percorsi di trasferimento: workflow con supporti rimovibili, file brokers, stazioni di trasferimento unidirezionale, mirror di pacchetti e percorsi di export manuale di log o report.
- Percorsi di controllo: sistemi che possono spingere GPO, script, certificati, software o cataloghi di aggiornamento nell'ambiente.
- Percorsi di osservazione: server WEC, collectors locali, host usati per esportare log e qualunque sistema impiegato per rivedere findings fuori dalla rete isolata.
E qui che molte review "air-gapped" falliscono. Il rischio principale non e sempre una superficie pubblica. Spesso e una dipendenza silenziosa di amministrazione che nessuno ha documentato perche non assomiglia a un accesso internet.
Se l'ambiente isolato e basato su AD, questo passaggio di scoping dovrebbe allinearsi alla sequenza di review piu profonda di Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation e al modello di ripetibilita di Audit ricorrente di Active Directory: perche gli audit annuali diventano obsoleti e come monitorare la postura in continuo. L'isolamento non elimina la necessita di mappare chi puo davvero cambiare policy, memberships, ACL, logging o emissione di certificati.
Che cosa si puo ancora auditare senza accesso a internet
L'accesso a internet non e un prerequisito per gran parte delle evidenze che contano in una rete isolata con forte presenza di Windows. Le Open Specifications Microsoft per Active Directory e Group Policy rendono esplicito il punto chiave: i dati di directory, i metadati delle policy e i contenuti di policy basati su file sono protocolli e archivi locali, non dipendenze cloud.
Una review offline seria puo ancora misurare:
- struttura di identita e privilegi: gruppi privilegiati, gruppi annidati, diritti delegati, admin obsoleti, account di servizio, trust e percorsi amministrativi
- stato di Group Policy e SYSVOL: metadati GPO, contenuto di policy basato su file, script, artefatti di preferences e integrita dei percorsi
- postura degli host: rotazione delle password degli admin locali, firma SMB, firma LDAP, fallback NTLM, postura del firewall Windows e baseline di hardening rilevanti
- esposizione di rete all'interno del perimetro: percorsi amministrativi, protocolli consentiti, superfici rilevanti per relay e reachability dei jump hosts
- visibilita dei log: generazione degli eventi, forwarding, copertura del collector, retention e procedura di export
- servizi di certificazione, se presenti: superfici di enrollment, esposizione dei template e percorsi amministrativi basati su certificati
Per questo il piu ampio audit di rete dovrebbe collegarsi al pillar AD specifico Come auditare Active Directory in un ambiente air-gapped e non sostituirlo. La meccanica di identita piu profonda continua a essere importante; questo articolo amplia semplicemente lo scope al confine circostante, al trasferimento, al logging e ai vincoli operativi.
Fonti di dati e strumenti che funzionano ancora offline
Gli audit piu solidi di reti isolate usano piu fonti locali di evidenza perche nessun singolo sistema racconta tutta la storia.
| Fonte di dati o workflow | Che cosa dimostra | Limite chiave |
|---|---|---|
| Query LDAP o LDAPS | Utenti, gruppi, computer, delegation, trust, configurazione della directory e molti attributi rilevanti per i privilegi | I dati di directory da soli non mostrano i contenuti GPO basati su file ne ogni impostazione host |
| SYSVOL tramite SMB | Script, file di Group Policy template, artefatti basati su policy e alcune esposizioni di password o preferences | Deve essere correlato con i metadati GPO archiviati in AD |
| Event log locali piu WEF/WEC | Che cosa e stato davvero generato, inoltrato, conservato e centralizzato nel perimetro | WEF e passivo; non abilita la audit policy, non ridimensiona i log e non attiva channels disabilitati |
| PowerShell locale e inventario read-only degli host | Impostazioni di protocollo, postura degli admin locali, stato software ed evidenze selezionate di hardening | Scope e permessi devono essere documentati per mantenere i rerun comparabili |
Scan offline degli aggiornamenti Microsoft con WUA e Wsusscn2.cab | Se mancano aggiornamenti di sicurezza Microsoft su sistemi Windows senza accesso live a internet | Copre metadati relativi ad aggiornamenti di sicurezza, non i payload ne telemetria pienamente connessa |
| Pacchetto di export controllato | Quali evidenze possono uscire dal perimetro, con quali approvazioni e in quale formato | La comodita di export non equivale a una chain of custody difendibile |
Qui contano due caveat Microsoft specifici.
Primo, Group Policy non e solo un tema AD. Microsoft documenta che le GPO hanno componenti logici in Active Directory e componenti fisici nel Group Policy template archiviato in SYSVOL. Se ispezionate solo i dati LDAP, sottorivedete la superficie di policy.
Secondo, WEF aiuta ma ha limiti. Microsoft afferma che WEF legge eventi operativi o amministrativi esistenti e inoltra gli eventi selezionati a un server WEC, ma resta passivo rispetto alla generazione degli eventi. Non puo modificare la dimensione degli event log, abilitare event channels disabilitati, cambiare i permessi dei channels ne regolare la security audit policy. In altre parole, inoltrare log incompleti in modo piu efficiente resta logging incompleto.
In contesti di dominio, Microsoft nota inoltre che il traffico WEF e cifrato con Kerberos per impostazione predefinita anche quando viene usato HTTP, mentre HTTPS diventa necessario soprattutto quando l'autenticazione basata su certificato sostituisce Kerberos. Questo rende WEF/WEC realistico in molti ambienti Windows isolati, ma solo se le sorgenti di evento stanno gia generando l'evidenza corretta.
Rivedete insieme i controlli di identita, host, rete e logging
Gli ambienti isolati sono facili da auditare male quando ogni famiglia di controlli viene rivista in modo separato. L'approccio piu difendibile e correlare controlli di identita, host, rete e logging nello stesso passaggio.
Identita e privilegi
Partite da chi puo cambiare l'ambiente, non da chi ne fa soltanto parte. Questo include admin di dominio e locali, account break-glass, account di servizio, diritti delegati e operatori di jump hosts o server di trasferimento. Per ambienti fortemente centrati su AD, usate Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation per la sequenza dettagliata di review dell'identita e Windows LAPS non distribuito: perche le password locali di amministratore condivise restano un rischio quando credenziali locali condivise esistono ancora tra host Windows isolati.
Postura degli host e dei protocolli
Le debolezze di protocollo non smettono di contare solo perche sono all'interno del perimetro. Firma SMB, esposizione NTLM, firma LDAP, pratiche obsolete sugli admin locali e percorsi favorevoli al relay restano problemi locali di movimento laterale. Se la rete usa molto l'autenticazione Windows, Firma SMB disabilitata: perche abilita ancora NTLM relay resta direttamente rilevante, cosi come la review dei percorsi certificati tramite Percorsi di attacco ADCS: come errori nei certificati diventano percorsi di escalation in Active Directory quando esiste AD CS.
Rete e percorsi di trasferimento
Rivedete quali sistemi possono comunicare con quali altri sistemi per amministrazione, import di aggiornamenti, export di log e trasferimento di pacchetti. Un bastion host che raggiunge domain controllers, mirror di pacchetti e file brokers e un punto di controllo di alto valore anche se non naviga mai su internet pubblico. Se i supporti rimovibili fanno parte del workflow, auditate approvazione, scansione, staging e import come superficie di controllo, non come nota operativa.
Logging e retention
La visibilita locale deve essere progettata. Rivedete la generazione degli eventi sui sistemi che contano, la configurazione di forwarding dove si usa WEF/WEC, la salute del collector, la retention, il comportamento in backlog e la procedura di export. Se il team ha bisogno di una mappa event-by-event dell'attivita AD, usate Monitoraggio Sicurezza AD: Event ID e SIEM come riferimento piu profondo, ma il piu ampio audit di rete isolata deve prima rispondere alla domanda se l'ambiente sia in grado di conservare evidenze locali sufficienti a sostenere le proprie affermazioni di sicurezza.
Vincoli su aggiornamenti, firme e intelligence di vulnerabilita
E qui che le review delle reti isolate diventano spesso troppo ottimistiche.
Microsoft documenta che Windows Update Agent puo eseguire scan offline di sistemi per gli aggiornamenti di sicurezza usando un pacchetto Wsusscn2.cab fornito localmente. Questo e utile, ma non equivale a un'intelligence patch pienamente connessa. Il catalogo contiene metadati relativi agli aggiornamenti di sicurezza e aiuta a rispondere alla domanda "quali aggiornamenti di sicurezza Microsoft sembrano mancare?". Non include gli aggiornamenti stessi e non risolve il tema del software non Microsoft, dei driver, del firmware delle appliance o del ritardo operativo introdotto dai processi manuali di import.
Per questo un buon audit deve controllare il processo e non solo l'ultimo risultato di scan:
- Come vengono importati i cataloghi di sicurezza Microsoft e con quale frequenza?
- Come vengono mirrorati nell'ambiente eventuali firme di terze parti, contenuti EDR o dati di vulnerabilita?
- Quanto tempo impiega un nuovo pacchetto o una nuova firma ad attraversare il perimetro?
- Quali asset sono esclusi intenzionalmente perche non esiste un metodo offline affidabile?
- Chi approva le eccezioni quando la guidance connessa non puo essere applicata direttamente all'interno del perimetro?
Se le risposte sono informali, l'ambiente si affida al fatto che le persone si ricordino come mantenerlo aggiornato. Questo non e un controllo auditabile.
Validazione dopo la remediation
La remediation nelle reti isolate dovrebbe essere validata nello stesso modo in cui e stata scoperta: con lo stesso scope locale, dallo stesso lato del confine e usando le stesse classi di evidenza.
Una sequenza pratica di validazione e questa:
- Congelare lo scope del rerun: stessi segmenti, stessi domini, stessi collectors e stesse ipotesi sui percorsi di accesso.
- Misurare di nuovo la condizione rischiosa: privilegi, impostazioni host, logging, percorsi di trasferimento o stato degli aggiornamenti.
- Confermare che la modifica non abbia rotto la visibilita locale: logging, forwarding WEF/WEC e procedure di export devono continuare a funzionare dopo l'hardening.
- Registrare le eccezioni rimanenti con un owner e una data di review, soprattutto quando la compatibilita legacy blocca ancora una correzione pulita.
- Conservare le evidenze prima e dopo con date di raccolta, ipotesi di confine e blind spots noti.
Warning: un PDF esportabile non e una prova da solo. Negli ambienti isolati, la prova dipende da raccolta locale ripetibile e da un metodo di rerun stabile.
Come EtcSec supporta gli audit di reti aziendali isolate
Per questo use case, il confine di prodotto che conta e semplice. I materiali ufficiali di EtcSec sul collector descrivono un collector read-only che puo funzionare in modalita standalone completamente locale, mantenere i dati in locale in quella modalita e raccogliere evidenze Active Directory tramite LDAP/LDAPS e SYSVOL. Questo modello di deployment e materialmente piu rilevante in una rete aziendale isolata di qualsiasi affermazione su dashboard o comodita cloud.
In pratica, questo significa che un team puo tenere il collector all'interno dello stesso confine di fiducia dei sistemi revisionati, rieseguire l'audit localmente dopo la remediation e mantenere coerente il modello di evidenza tra un ciclo di review e l'altro. Se vi serve il dettaglio di prodotto piu che la guida di processo, usate ETC Collector per il modello di deployment e Confronto tra strumenti di audit AD: come confrontare PingCastle, Purple Knight e workflow di audit ripetibili per capire quando un workflow locale e ripetibile cambia la decisione.
Il valore qui non e sostenere che le reti isolate abbiano bisogno di uno strumento offline magico. Il valore e avere raccolta locale read-only, rerun stabili e findings che restano utilizzabili dopo la prima ondata di pulizia.
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
