Quels outils de securite fonctionnent dans les reseaux isoles sans acces internet ? La reponse pratique est plus etroite que ne le suggerent la plupart des pages produit. Certains outils fonctionnent encore entierement en local. D'autres ne tiennent que si vous pouvez faire passer des mises a jour, des licences ou des paquets de plugins a travers la frontiere. D'autres enfin cessent d'etre adaptes des que l'environnement ne peut plus joindre un plan de controle cloud, un flux en direct ou une API exposee sur Internet.
Cet article reste dans le scope des reseaux d'entreprise isoles avec un modele d'exploitation centre sur Active Directory et Windows. Il ne cherche pas a couvrir les programmes de surete OT ou ICS. Si votre question principale est encore de savoir comment auditer l'environnement lui-meme, utilisez Audit de securite d'un reseau air-gapped comme guide process-first et Comment auditer Active Directory dans un environnement air-gapped comme deep dive AD. L'objectif ici est different : quels outils et quels workflows restent realistes quand l'acces Internet est absent, etroitement court-circuite par des brokers, ou seulement possible via des transferts offline controles.
Quels outils de securite fonctionnent dans les reseaux isoles sans acces internet ?
Un outil ne devrait compter comme utilisable sans acces Internet que si sa fonction de securite principale peut encore s'executer a l'interieur du perimetre et si les dependances restantes sont explicites. En pratique, cela revient a poser quatre questions d'abord :
| Question | Pourquoi c'est important dans un reseau isole |
|---|---|
| L'outil peut-il collecter ou analyser les donnees localement ? | Si la collecte exige un plan de controle cloud, il ne tient pas dans un vrai air gap. |
| A-t-il besoin de flux en direct ou peut-il fonctionner avec des mises a jour staged offline ? | Certains outils restent utilisables, mais seulement avec un workflow de transfert discipline. |
| Peut-on le relancer apres remediations depuis le meme cote de la frontiere ? | Un scan unique est plus faible qu'un modele de rerun local stable. |
| L'outil garde-t-il les preuves dans l'environnement si necessaire ? | Dans les reseaux isoles, la sortie de donnees est souvent une surface de controle, pas une commodite. |
Cette distinction compte parce que beaucoup d'environnements decrits comme offline ne sont en realite que logiquement isoles ou dependants de bastions, de brokers ou de chemins de transfert manuels. Le guide d'implementation du BOD 23-01 de la CISA reste le rappel officiel le plus clair : un environnement physiquement air-gapped n'est pas equivalent a un environnement simplement isole. Un outil qui fonctionne avec des imports stages a travers une frontiere de transfert n'est pas la meme chose qu'un outil qui fonctionne sans aucune dependance externe.
Commencer par separer les workflows local-only des outils cloud-dependent
La facon la plus propre d'evaluer l'outillage dans un environnement isole est de separer trois modeles.
| Modele d'outil | Ce qui continue de fonctionner | Contrainte principale |
|---|---|---|
| Workflow local-only | La collecte et la revue se font entierement dans le perimetre. | Il faut tout de meme assez de sources de preuve locales et assez de competences pour les interpreter. |
| Offline-capable avec staged updates | L'outil tourne localement, mais les signatures, plugins, licences ou catalogues doivent etre importes manuellement. | La fraicheur operationnelle depend du processus de transfert, pas seulement de l'outil. |
| Cloud-dependent | Le produit suppose un plan de controle SaaS, une API joignable sur Internet, ou du contenu en ligne continu. | Il cesse generalement de convenir a un vrai air gap, meme si un installeur peut tourner localement. |
C'est la grille de lecture du reste de l'article. La question n'est pas de savoir si un editeur dit que son logiciel peut s'installer sur un hote Windows. La question est de savoir si la valeur securite tient encore quand il n'y a ni acces Internet direct, ni chemin d'exception invisible qui fait en realite le vrai travail.
Les outils Windows natifs et l'outillage Active Directory fonctionnent encore offline
Le point de depart le plus fiable dans un reseau d'entreprise isole reste le modele de preuve natif Windows et Active Directory.
La documentation Microsoft et les Open Specifications disent explicitement l'essentiel : les donnees d'annuaire, les metadonnees Group Policy, les fichiers de strategie stockes dans SYSVOL, les journaux d'evenements locaux et Windows Event Forwarding n'ont pas besoin d'Internet pour exister ni pour etre revus. Un workflow local serieux peut donc encore s'appuyer sur :
- des requetes LDAP ou LDAPS pour les utilisateurs, groupes, delegations, relations d'approbation et attributs lies aux privileges
- une revue Group Policy couvrant a la fois les metadonnees AD et le contenu de strategie porte par SYSVOL
- les journaux d'evenements locaux ainsi que WEF/WEC pour centraliser les preuves dans le perimetre
- PowerShell local pour la configuration hote, la posture protocolaire et la validation des controles
- le scan offline de Windows Update Agent avec
Wsusscn2.cabpour detecter les mises a jour de securite Microsoft manquantes
La limite, c'est que l'outillage natif fournit des sources de preuve, pas un programme de securite cle en main. WEF/WEC aide a transmettre ce qui existe deja, mais Microsoft documente explicitement que le mecanisme reste passif pour la generation d'evenements, la taille des logs, les canaux desactives et la politique d'audit. De la meme facon, le scan WUA hors ligne peut signaler des mises a jour de securite Microsoft manquantes, mais il ne remplace pas un workflow connecte de veille de vulnerabilites.
C'est pour cela que l'outillage natif apparait sur la premiere ligne de la matrice plus bas. C'est la base offline la plus defensible, mais pas la reponse complete a lui seul.
Outils d'evaluation point-in-time qui peuvent tourner dans des reseaux isoles
Deux outils centres sur AD restent recevables ici parce que leur comportement offline ou deconnecte est documente officiellement et parce que leur role est plus etroit que celui d'une plateforme cloud de securite.
PingCastle
PingCastle est l'un des exemples les plus clairs d'un outil qui reste adapte aux reseaux isoles, parce que sa documentation officielle decrit explicitement plusieurs modes de deploiement deconnectes. Le Health Check est le rapport par defaut. La documentation Deploy couvre les domaines sans connexion reseau, la collecte via bastion, la planification hebdomadaire et le transfert chiffre de rapports via des canaux non fiables. La documentation Consolidation couvre le regroupement de plusieurs rapports dans une vue de plus haut niveau.
PingCastle reste donc une option realiste d'evaluation AD point-in-time quand le besoin est :
- de l'Active Directory on-prem uniquement
- un rapport local HTML-first
- une execution depuis chaque domaine ou depuis un bastion
- un modele praticable de collecte de rapports meme quand la centralisation est difficile
C'est un bon fit pour des scorecards AD offline. Ce n'est pas une plateforme generale de securite offline, et il ne traite ni l'intelligence de mise a jour, ni l'identite hybride, ni la visibilite hote et reseau au-dela de son modele oriente AD.
Purple Knight
Purple Knight reste lui aussi pertinent, mais uniquement si on le decrit avec precision.
Semperis indique dans la FAQ officielle que Purple Knight est un logiciel installe, qu'il ne modifie pas Active Directory, qu'il exige la capacite d'executer des scripts PowerShell, qu'il utilise des requetes LDAP sur RPC pour certains scans de vulnerabilites, et qu'il n'a pas de capacites de phone-home. La meme FAQ precise egalement qu'il fournit une scorecard point-in-time et que le rapport inclut les indicateurs analyses, leur statut pass/fail, le mapping MITRE ATT&CK et des recommandations de remediations.
Cela rend Purple Knight utilisable pour une evaluation AD on-prem dans un environnement Windows-centric isole lorsque l'on veut un outil d'evaluation installe localement plutot qu'un plan de controle cloud. Mais Purple Knight est aussi positionne par Semperis comme un produit d'evaluation AD et Entra. La FAQ officielle explique que l'evaluation Entra exige une app registration et des permissions Microsoft Graph.
ℹ️ Inference issue des docs officielles : Purple Knight reste valable pour l'audit AD on-prem dans un reseau isole, mais la partie Entra sort du perimetre d'un veritable environnement sans Internet parce que la connectivite Microsoft Graph se situe hors de cette frontiere.
Ce caveat est important. Purple Knight a sa place dans cet article pour le cote AD, pas comme affirmation generale selon laquelle toute sa portee hybride resterait utilisable dans un vrai air gap.
Des scanners de vulnerabilites qui fonctionnent encore avec des staged offline updates
L'exemple de scanner le plus defensible ici est Tenable Nessus en offline mode, parce que Tenable documente explicitement le workflow.
La documentation officielle de Tenable indique que Nessus peut etre place en offline mode et recommande ce mode pour les scanners offline ou air-gapped. La meme documentation precise aussi que l'offline mode desactive les fonctions qui exigent une connexion au feed Nessus, notamment les mises a jour core et plugin, les feed status updates, le rattachement a Tenable Vulnerability Management et d'autres fonctions applicatives.
Le point operationnel important est que offline-capable ne veut pas dire self-sufficient. La documentation Tenable sur l'installation et les mises a jour hors ligne montre clairement que :
- l'enregistrement offline est un processus distinct
- un systeme auxiliaire connecte a Internet sert a recuperer les artefacts necessaires
- les paquets de plugins doivent etre transferes manuellement
- la fraicheur du scanner depend de la qualite reelle du processus de transfert
Cela fait toujours de Nessus une entree valable dans un article tools-first sur les reseaux isoles. Cela n'en fait pas une solution simple. Dans un vrai air gap, le scanner n'est aussi a jour que le chemin de staged update qui l'alimente.
Ce qui casse le plus souvent dans un vrai air gap
Certaines categories d'outils cessent generalement de convenir des que l'environnement ne peut plus atteindre Internet ou une API externe approuvee.
- les produits SaaS-only dont l'analyse, la politique ou le modele de preuve vivent dans un plan de controle distant
- les produits qui exigent un rafraichissement continu de signatures, de reputation ou de threat intelligence sans chemin d'import offline documente
- les outils qui peuvent s'installer localement mais supposent quand meme une inscription de tenant, un acces a une API cloud ou une correlation Internet pour produire leur valeur principale
- les ecosystemes d'agents dont la version, la synchronisation de politique ou l'analytique se degradent fortement des que l'environnement perd sa connectivite en ligne
C'est ici que les equipes perdent du temps. Une demo produit peut sembler assez locale jusqu'a ce qu'on cartographie la chaine de dependances cachees : enregistrement, verifications de licence, feeds de plugins, acces Graph, scoring cloud, ou mises a jour et aides livrees depuis le web. Dans les environnements isoles, ces dependances font partie de la revue de conception, pas du bruit de fond.
Matrice courte : outils de securite pour reseaux isoles sans acces internet
| Outil ou workflow | Fonctionne sans Internet ? | Ce dont il a encore besoin | Meilleur fit | Ce qui casse dans un vrai air gap |
|---|---|---|---|---|
| Native Windows / AD tooling | Oui | Des competences operateur, un acces local a la collecte et un modele de preuve discipline | Revue locale de base d'AD, GPO, journaux, WEF/WEC, PowerShell et scan WUA offline | Cela ne fournit pas a lui seul un programme de securite package. |
| PingCastle | Oui, pour l'evaluation AD | Une connectivite AD, un point d'execution local ou bastion, et une collecte de rapports | Health checks AD point-in-time dans des environnements deconnectes ou difficiles a centraliser | Cela reste etroit : oriente AD, HTML-first, et pas un workflow complet d'identite hybride ou de veille de vulnerabilites. |
| Purple Knight | Oui, pour l'evaluation AD on-prem | Une execution locale, PowerShell, et LDAP sur RPC pour certains scans | Evaluation AD locale rapide avec remediations au niveau des indicateurs | La partie Entra depend de Microsoft Graph, donc la portee hybride ne se transpose pas dans un vrai air gap. |
| Tenable Nessus Offline Mode | Oui, sous conditions | Un enregistrement offline ainsi qu'un transfert manuel des plugins et artefacts | Vulnerability scanning local quand un processus de staged updates est deja accepte | Il perd les commodites dependantes du feed et devient operationnellement lourd si les mises a jour offline sont mal maintenues. |
| ETC Collector standalone | Oui | Un deploiement local, un acces read-only, et le meme workflow de rerun dans le perimetre apres remediations | Revue de securite repeatable par collecte locale et rerun dans des environnements d'entreprise prudents ou isoles | Il n'est pas fait pour remplacer chaque source d'intelligence connectee ; il est le plus fort quand les preuves locales et les reruns repeatables comptent le plus. |
Le point de cette matrice n'est pas de declarer un gagnant. Il s'agit de separer les outils qui restent operationnellement honnetes offline de ceux qui n'ont l'air offline que tant que l'on n'a pas examine leur chaine de dependances.
Comment choisir le bon mix dans un reseau d'entreprise isole
Un bon stack d'outils pour reseau isole est generalement un mix, pas un produit unique.
- Commencez par les sources de preuve locales qui fonctionnent encore nativement : donnees AD, SYSVOL, journaux locaux, WEF/WEC et revue de configuration hote.
- Ajoutez un outil d'evaluation AD point-in-time si vous avez besoin d'une vue plus rapide sur les privileges et les politiques. PingCastle et Purple Knight sont tous les deux valables, mais pas pour les memes raisons.
- Ajoutez un scanner offline-capable seulement si l'organisation est prete a maintenir correctement le chemin de staged updates. Sinon, la sortie du scanner vieillira plus vite que l'environnement ne change.
- Preferez les outils que vous pouvez rerun localement apres remediations depuis le meme cote de la frontiere. Cela compte davantage que l'aspect plus ou moins poli du premier dashboard.
- Gardez les produits cloud-dependent hors perimetre sauf si l'environnement n'est qu'isole logiquement et que le chemin de dependance est formellement approuve et documente.
C'est aussi ici que les articles de fond restent utiles. Utilisez Comment auditer la securite d'Active Directory pour la sequence de revue, Audit Active Directory recurrent pour la logique de rerun, Windows LAPS non deploye quand la reutilisation des comptes admins locaux est encore presente, et Signature SMB desactivee quand le risque de mouvement lateral reste faconne par la posture protocolaire.
Si AD CS existe dans l'environnement isole, l'exposition certificats appartient aussi au review tier initial, meme si ce n'est pas le sujet principal ici. Utilisez Attaques ADCS ESC1 a ESC8 pour cette partie.
Comment EtcSec s'integre dans des workflows de securite offline
Pour ce cas d'usage, le seul claim produit qui compte vraiment est le modele de deploiement et de collecte.
La documentation officielle d'EtcSec decrit un collector read-only capable de tourner dans un mode standalone entierement local. Dans ce modele, la GUI et l'API REST restent locales, les donnees restent locales, et la collecte peut toujours couvrir les preuves Active Directory via LDAP ou LDAPS et SYSVOL. C'est la bonne frontiere produit a mettre en avant dans un reseau isole, parce qu'elle colle a la contrainte reelle : la collecte locale et les reruns locaux comptent plus que la commodite cloud.
Si vous avez besoin du cadrage process plus large, utilisez Audit de securite d'un reseau air-gapped. Si vous avez besoin du cadrage plus large sur l'evaluation des outils, utilisez Comparatif d'outils d'audit AD. Si vous avez besoin du detail de deploiement pour le modele de collector local lui-meme, utilisez ETC Collector.
Le fit pratique est simple : EtcSec a sa place lorsque le besoin est une collecte locale read-only repeatable et une revue par rerun dans la meme frontiere de confiance, pas quand l'equipe veut seulement une capture ponctuelle.
Actionable next steps
- Cartographiez d'abord les sources de preuve qui restent entierement locales : AD, SYSVOL, journaux, WEF/WEC et scans WUA offline.
- Verifiez ensuite quels outils exigent un transfert manuel de mises a jour, de licences ou de plugins avant de les considerer comme reellement exploitables.
- Testez enfin un rerun apres une petite remediaton reelle pour confirmer que l'outil reste utilisable apres changement, et pas seulement pour un premier snapshot.
References primaires
- CISA: BOD 23-01 Implementation Guidance
- 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
- PingCastle Documentation
- PingCastle Health Check
- PingCastle Deploy
- PingCastle Consolidation
- Semperis: Purple Knight FAQ
- Semperis: Active Directory Security Assessment | Purple Knight
- Tenable Nessus: Offline Mode
- Tenable Nessus: Install Tenable Nessus Offline
- Tenable Nessus: Update Plugins Offline
- ETC Collector
- ANSSI: Recommandations pour l'administration securisee des SI reposant sur AD

