Audit securite reseau air gapped : comment auditer un environnement isole sans faux sentiment de securite

Audit de securite d'un reseau air-gapped : comment auditer un environnement isole sans faux sentiment de securite

Un audit securite reseau air gapped doit commencer par prouver ce qu'est reellement l'environnement, pas par supposer que "pas d'internet" signifie "pas de chemin d'attaque exploitable". En pratique, beaucoup d'environnements d'entreprise presentes comme air-gapped sont seulement logiquement isoles, fortement segmentes, ou dependants de chemins de transfert controles. Cette distinction change ce que vous pouvez collecter, comment vous validez les findings, et quels risques residuels subsistent a l'interieur du perimetre.

Cet article reste dans le scope des reseaux d'entreprise isoles, pas des programmes de surete OT ou ICS. Si votre question principale reste l'audit d'Active Directory dans une foret isolee, utilisez Comment auditer Active Directory dans un environnement air-gapped comme deep dive. L'objectif ici est plus large : comment revoir les controles d'identite, d'hote, de reseau, de journalisation et de transfert qui continuent de compter quand l'environnement ne peut pas s'appuyer sur des outils connectes a Internet ni sur une visibilite cloud-native.

Ce qui compte comme reseau air-gapped pour un audit securite reseau air gapped

Le guide d'implementation CISA pour BOD 23-01 est utile parce qu'il trace une ligne nette entre les environnements physiquement air-gapped et ceux qui ne sont que logiquement isoles. Cela compte pour un audit, parce que des que vous avez encore un pont d'administration, un broker de transfert, un tunnel fournisseur, ou un systeme connecte a un autre systeme qui touche l'environnement isole, votre revue doit inclure ce chemin.

Le sujet n'est pas de gagner un debat de taxonomie. Le sujet est d'eviter le faux sentiment de securite. Un environnement isole peut encore avoir de la derive de privilege, des comptes admins obsoletes, des jump hosts non geres, de mauvaises pratiques sur les mots de passe admin locaux, des parametres de protocole fragiles, une retention de logs insuffisante, ou un chemin de transfert qui contourne les controles que l'equipe pense avoir.

Ce qu'un audit securite reseau air gapped doit vraiment prouver

Un audit de securite d'un reseau air-gapped utile ne s'arrete pas a "le reseau est difficile a atteindre". NIST SP 800-115 cadre l'evaluation de securite autour de la planification, de la collecte de preuves, de l'analyse des findings et de l'elaboration de mitigations. Dans un environnement isole, cela veut dire que l'audit doit au minimum prouver cinq choses :

Un minimum evidence pack pour ce type de revue devrait inclure :

Cadrer d'abord la frontiere, les chemins de transfert et les chemins d'administration

La premiere erreur de scoping dans un environnement isole consiste a auditer uniquement les serveurs clairement "dans" la zone et a ignorer les systemes qui peuvent les administrer. Si un jump server, un credential broker, un processus de media amovible, ou un host de staging peut pousser du contenu ou des changements dans l'environnement isole, il doit etre dans le scope.

Commencez par cartographier quatre types de chemins :

1. Les chemins d'administration : jump hosts, postes privilegies, comptes break-glass, chemins de maintenance fournisseur, et toute relation de trust de domaine ou de foret qui atteint encore la zone isolee.
2. Les chemins de transfert : workflows de media amovibles, file brokers, stations de transfert unidirectionnelles, miroirs de packages et chemins d'export manuel pour les logs ou les rapports.
3. Les chemins de controle : systemes capables de pousser des GPO, des scripts, des certificats, du logiciel ou des catalogues de mise a jour dans l'environnement.
4. Les chemins d'observation : serveurs WEC, collecteurs locaux, hotes d'export de logs et tout systeme utilise pour revoir les findings hors du reseau isole.

C'est la que beaucoup de revues "air-gapped" echouent. Le risque principal n'est pas toujours une surface publique. C'est souvent une dependance d'administration silencieuse que personne n'a documentee parce qu'elle ne ressemble pas a un acces Internet.

Si l'environnement isole repose sur Active Directory, cette etape de cadrage doit s'aligner sur la sequence de revue plus profonde de Audit de securite Active Directory : quoi verifier d'abord et comment prouver la remediation et sur le modele de repetabilite de Audit Active Directory recurrent : pourquoi les audits annuels deviennent obsoletes et comment surveiller la posture en continu. L'isolement ne supprime pas le besoin d'identifier qui peut reellement changer la politique, les memberships, les ACL, la journalisation ou l'emission de certificats.

Ce que vous pouvez encore auditer sans acces Internet

L'acces a Internet n'est pas un prerequis pour la plupart des preuves qui comptent dans un reseau isole riche en Windows. Les Open Specifications Microsoft pour Active Directory et Group Policy rendent le point essentiel explicite : les donnees de l'annuaire, les metadonnees de policy et le contenu de policy stocke en fichiers sont des protocoles et des stores locaux, pas des dependances cloud.

Une revue offline serieuse peut encore mesurer :

• la structure d'identite et de privilege : groupes privilegies, groupes imbriques, droits delegues, admins obsoletes, comptes de service, trusts et chemins d'administration
• l'etat de Group Policy et de SYSVOL : metadonnees GPO, contenu de policy stocke en fichiers, scripts, artefacts de preferences et integrite des chemins
• la posture des hotes : rotation des mots de passe admin locaux, signature SMB, signature LDAP, fallback NTLM, posture firewall Windows et baselines de hardening pertinentes
• l'exposition reseau dans le perimetre : chemins d'administration, protocoles autorises, surfaces exploitables pour du relay et reachability des jump hosts
• la visibilite des logs : generation des evenements, forwarding, couverture du collecteur, retention et procedure d'export
• les services de certificats, s'ils existent : surfaces d'enrollment, exposition des templates et chemins d'administration bases sur les certificats

C'est pour cela que l'audit reseau plus large doit faire un lien vers, et non remplacer, le pillar AD specifique Comment auditer Active Directory dans un environnement air-gapped. Les mecanismes d'identite plus fins restent importants; cet article elargit simplement le scope a la frontiere environnante, aux transferts, a la journalisation et aux contraintes operationnelles.

Sources de donnees et outils qui fonctionnent encore offline

Les audits les plus solides en reseau isole utilisent plusieurs sources de preuve locales, parce qu'aucun systeme unique ne raconte toute l'histoire.

Deux caveats Microsoft comptent particulierement ici.

D'abord, Group Policy n'est pas qu'un sujet AD. Microsoft documente que les GPO ont des composants logiques dans Active Directory et des composants physiques dans le Group Policy template stocke dans SYSVOL. Si vous inspectez uniquement LDAP, vous sous-revoyez la surface de policy.

Ensuite, WEF aide mais reste limite. Microsoft indique que WEF lit des evenements operationnels ou administratifs existants et forwarde les evenements selectionnes vers un serveur WEC, mais reste passif vis-a-vis de la generation des evenements. Il ne peut pas changer la taille des event logs, activer les event channels desactives, modifier les permissions des channels ni ajuster la security audit policy. Autrement dit, forwarder plus efficacement des logs incomplets reste de la journalisation incomplete.

En environnement de domaine, Microsoft note aussi que le trafic WEF est chiffre par Kerberos par defaut meme quand HTTP est utilise, HTTPS devenant surtout necessaire quand l'authentification par certificat remplace Kerberos. Cela rend WEF/WEC realiste dans beaucoup d'environnements Windows isoles, mais seulement si les sources d'evenements generent deja les bonnes preuves.

Revoir ensemble les controles d'identite, d'hote, de reseau et de journalisation

Les environnements isoles sont faciles a mal auditer quand chaque famille de controles est revue separement. L'approche plus defensible consiste a correler les controles d'identite, d'hote, de reseau et de journalisation dans la meme passe.

Identite et privileges

Commencez par ceux qui peuvent changer l'environnement, pas par ceux qui y appartiennent seulement. Cela inclut les admins de domaine et locaux, les comptes break-glass, les comptes de service, les droits delegues, et les operateurs des jump hosts ou serveurs de transfert. Pour les environnements fortement centres sur AD, utilisez Audit de securite Active Directory : quoi verifier d'abord et comment prouver la remediation pour la sequence detaillee de revue d'identite, et Windows LAPS non deploye : pourquoi les mots de passe admin locaux partages restent un risque quand des credentials admin locaux sont encore partages entre hotes Windows isoles.

Posture hote et protocoles

Les faiblesses de protocole ne cessent pas de compter simplement parce qu'elles sont a l'interieur du perimetre. Signature SMB, exposition NTLM, signature LDAP, pratiques obsoletes sur les admins locaux et chemins propices au relay restent des problemes locaux de mouvement lateral. Si le reseau repose fortement sur l'authentification Windows, Signature SMB desactivee : pourquoi elle expose encore au NTLM relay reste directement pertinente, tout comme la revue des chemins certificats via Chemins d'attaque ADCS : comment des erreurs de certificats deviennent des chemins d'escalade Active Directory si AD CS existe.

Reseau et chemins de transfert

Revoyez quels systemes peuvent parler a quels systemes pour l'administration, l'import des mises a jour, l'export des logs et le transfert de packages. Un bastion host qui peut atteindre les domain controllers, des miroirs de packages et des file brokers est un point de controle a forte valeur, meme s'il ne navigue jamais sur Internet. Si des media amovibles font partie du workflow, auditez l'approbation, le scan, le staging et l'import comme une surface de controle, pas comme une simple note operationnelle.

Journalisation et retention

La visibilite locale doit etre concue, pas supposee. Revoyez la generation des evenements sur les systemes qui comptent, la configuration de forwarding la ou WEF/WEC est utilise, la sante du collecteur, la retention, le comportement en backlog et la procedure d'export. Si l'equipe a besoin d'une cartographie event-by-event pour l'activite AD, Supervision Securite AD : Evenements Cles sert de reference plus profonde, mais l'audit reseau isole plus large doit d'abord repondre a la question suivante : l'environnement peut-il conserver assez de preuves locales pour soutenir ses propres affirmations de securite ?

Contraintes sur les mises a jour, les signatures et l'intelligence de vulnerabilite

C'est souvent ici que les revues de reseaux isoles deviennent trop optimistes.

Microsoft documente que Windows Update Agent peut scanner hors ligne des systemes pour des mises a jour de securite a l'aide d'un package Wsusscn2.cab fourni localement. C'est utile, mais ce n'est pas equivalent a une intelligence patch pleinement connectee. Le catalogue contient des metadonnees de mises a jour liees a la securite et aide a repondre a la question "quelles mises a jour de securite Microsoft semblent manquer ?" Il ne contient pas les mises a jour elles-memes, et il ne regle pas le sujet des logiciels non-Microsoft, des drivers, du firmware des appliances, ni du delai operationnel introduit par les imports manuels.

Un bon audit doit donc verifier le processus, pas seulement le resultat du dernier scan :

• Comment les catalogues de securite Microsoft sont-ils importes, et a quelle frequence ?
• Comment les signatures tierces, le contenu EDR ou les donnees de vulnerabilite sont-ils miroites dans l'environnement, si cela existe ?
• Combien de temps faut-il pour qu'un nouveau package ou une nouvelle signature traverse le perimetre ?
• Quels assets sont exclus intentionnellement parce qu'aucune methode offline fiable n'existe ?
• Qui approuve les exceptions quand une guidance connectee ne peut pas etre appliquee directement a l'interieur du perimetre ?

Si les reponses sont informelles, l'environnement depend de personnes qui se souviennent comment le maintenir a jour. Ce n'est pas un controle auditable.

Validation apres remediation

La remediation dans un reseau isole doit etre validee de la meme maniere qu'elle a ete decouverte : avec le meme scope local, depuis le meme cote de la frontiere, en utilisant les memes classes de preuves.

Une sequence de validation pratique ressemble a ceci :

1. Geler le scope du rerun : memes segments, memes domaines, memes collecteurs, memes hypotheses sur les chemins d'acces.
2. Remesurer la condition risquee : privileges, parametres hotes, journalisation, chemins de transfert ou etat des mises a jour.
3. Confirmer que le changement n'a pas degrade la visibilite locale : la journalisation, le forwarding WEF/WEC et les procedures d'export doivent encore fonctionner apres hardening.
4. Documenter les exceptions restantes avec un owner et une date de revue, surtout quand une compatibilite legacy bloque encore une correction propre.
5. Preserver les preuves avant/apres avec les dates de collecte, les hypotheses de frontiere et les blind spots connus.

Warning: un PDF exportable n'est pas une preuve a lui seul. Dans un environnement isole, la preuve repose sur une collecte locale repetable et une methode de rerun stable.

Comment EtcSec aide pour les audits de reseaux d'entreprise isoles

Pour ce use case, la frontiere produit importante est simple. Les documents officiels sur le collector EtcSec decrivent un collecteur read-only capable de tourner en mode standalone entierement local, de garder les donnees localement dans ce mode, et de collecter des preuves Active Directory via LDAP/LDAPS et SYSVOL. Ce modele de deploiement est materiellement plus pertinent dans un reseau d'entreprise isole que n'importe quelle promesse liee aux dashboards ou au confort du cloud.

En pratique, cela signifie qu'une equipe peut garder le collecteur dans la meme frontiere de confiance que les systemes qu'elle audite, rejouer l'audit localement apres remediation, et garder un modele de preuve coherent entre les cycles de revue. Si vous avez besoin du detail produit plutot que du guide de processus, utilisez ETC Collector pour le modele de deploiement et Comparatif d'outils d'audit AD : comment comparer PingCastle, Purple Knight et des workflows d'audit repetables pour comprendre a partir de quand un workflow local et repetable change la decision.

La valeur ici n'est pas de dire qu'un reseau isole a besoin d'un outil offline magique. La valeur est d'avoir une collecte locale read-only, des reruns stables, et des findings qui restent exploitables apres la premiere vague de nettoyage.

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