💻 computer science

Near-Deterministic Reconstruction of Enterprise Firewall Decisions for Policy Audit: Proxy Structure, Context Shift, and Residual Uncertainty

Cette étude démontre que les décisions de pare-feu d'entreprise peuvent être reconstruites de manière quasi déterministe à partir des journaux de trafic grâce à l'apprentissage supervisé, révélant qu'une grande précision du modèle reflète souvent la réplication de proxys de politiques spécifiques et de règles dépendantes du contexte plutôt qu'une détection de menaces indépendante, permettant ainsi des audits de politiques rétrospectifs tout en soulignant des limitations significatives en matière de généralisation entre environnements et de calibration de l'incertitude.

Auteurs originaux : Özkan Canay, Cem Özkurt, Fatmir Garri

Publié 2026-08-05

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Özkan Canay, Cem Özkurt, Fatmir Garri

Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de comprendre pourquoi un videur dans un club très sélect laisse passer certaines personnes et en écarte d'autres. Vous avez un immense carnet rempli de millions d'entrées, chacune enregistrant exactement ce que le videur a fait : « Autorisé », « Abandonné » ou « Refusé ». Dans le monde de la sécurité informatique, ce carnet est appelé un « journal de pare-feu » (firewall log), et le videur est un pare-feu — un gardien numérique qui protège le réseau d'une entreprise contre les acteurs malveillants. Habituellement, les experts en sécurité utilisent ces journaux pour traquer les hackers, à la recherche de modèles qui hurlent « danger ! ». Mais il existe un problème délicat : parfois, la décision du videur n'est pas liée au fait qu'une personne soit réellement un criminel ; c'est simplement une question de savoir si elle respecte le code vestimentaire spécifique ou la liste des membres du club. Si vous entraînez un ordinateur à deviner les décisions du videur, il pourrait simplement apprendre le code vestimentaire à la perfection, non pas parce qu'il est un détective de génie, mais parce que les indices dans le carnet (comme la pointure de chaussures de la personne ou l'heure de son arrivée) donnent la réponse trop facilement. Cette étude pose une question fascinante : si nous cachons les indices évidents, un ordinateur peut-il toujours deviner les mouvements du videur avec une précision quasi parfaite ? Et si c'est le cas, cela signifie-t-il que l'ordinateur est intelligent, ou que les indices étaient trop faciles à trouver ?

Cette étude plonge dans un carnet massif contenant plus d'un million d'enregistrements provenant d'un véritable pare-feu d'entreprise, spécifiquement un appareil Palo Alto. Les chercheurs voulaient voir s'ils pouvaient reconstruire la « surface de décision » — la ligne invisible que le pare-feu trace pour décider qui entre — en utilisant uniquement les détails environnants, tout en cachant les raisons directes de la décision. Ils ont traité les choix du pare-feu (Autoriser, Abandonner, Refuser) comme un puzzle. Ils ont retiré les pièces les plus évidentes du puzzle, comme le nom de l'application spécifique ou le numéro de règle qui a déclenché l'action, pour voir si les indices restants (comme la taille du paquet de données ou le numéro de port) étaient suffisants pour résoudre l'énigme.

Les résultats sont un peu comme découvrir que le videur du club suit en réalité un script très rigide et prévisible. Les chercheurs ont découvert que même après avoir supprimé les « raccourcis » les plus évidents (comme le nom de l'application), de puissants programmes informatiques appelés « ensembles d'arbres » (pensez à eux comme des arbres de décision super intelligents qui posent une série de questions par oui ou par non) pouvaient toujours deviner la décision du pare-feu de manière presque parfaite. En fait, deux de ces programmes, XGBoost et LightGBM, ont obtenu un score parfait, ne faisant aucune erreur sur les données de test. Il s'avère que la décision du pare-feu est si étroitement liée aux autres détails du journal que vous n'avez même pas besoin de connaître la règle pour connaître le résultat. Par exemple, ils ont découvert que le simple fait de connaître le « Port Source » (un numéro spécifique identifiant la connexion) et les « Octets » (la taille des données) suffisait à déterminer la décision dans des millions de cas.

Cependant, l'article prend grand soin de ne pas présenter cela comme une « victoire » pour la détection des hackers. Les auteurs soutiennent que ce score quasi parfait ne signifie pas que l'ordinateur a appris à repérer de vrais hackers. Au contraire, cela signifie que l'ordinateur a appris la « grammaire » interne du pare-feu. C'est comme un étudiant qui mémorise le corrigé d'un examen plutôt que de comprendre les mathématiques. Lorsque les chercheurs ont tenté de rendre le puzzle plus difficile en supprimant encore plus d'indices — comme la taille des données ou le pays d'origine — le score parfait de l'ordinateur a chuté, mais restait toujours étonnamment bon. Cela suggère que les décisions du pare-feu sont « encodées de manière redondante », ce qui signifie que la même information est répétée dans de nombreux champs différents du journal.

L'étude a également examiné ce qui se passe lorsque l'ordinateur est confronté à une situation qu'il n'a jamais vue auparavant, comme un nouveau type d'application ou une destination différente. Ici, le sortilège se brise. La confiance de l'ordinateur vacille, et il commence à faire des erreurs, particulièrement pour les décisions « Refusé » qui sont rares. Les chercheurs ont utilisé des outils spéciaux pour mesurer cette incertitude, montrant que si l'ordinateur est un maître pour deviner les mouvements du pare-feu dans un territoire familier, il se perd lorsque le contexte change. Ils ont découvert que si l'on cache les détails de l'« application », l'ordinateur peut toujours deviner avec une précision de 99,9 %, mais si l'on cache le « volume » et la « durée » du trafic, la précision chute légèrement, prouvant que ces détails agissaient comme des raccourcis cachés.

En fin de compte, cet article ne porte pas sur la création d'un meilleur détecteur de hackers, mais sur l'audit du pare-feu lui-même. Il montre que, pour cette entreprise spécifique et pour cette fenêtre de temps précise (environ 46 minutes de trafic), les décisions du pare-feu sont presque entièrement prévisibles à partir des données environnantes. Les chercheurs ont trouvé sept petites combinaisons de seulement quatre champs qui pouvaient prédire le résultat parfaitement. Mais ils avertissent également que c'est une reconstruction « quasi-déterministe », ce qui signifie que cela fonctionne parce que les données sont cohérentes, et non parce que l'ordinateur comprend la sécurité. Si les règles du pare-feu changent ou si l'environnement réseau évolue, cette prédiction parfaite pourrait disparaître. L'article conclut que, bien que nous puissions reconstruire le processus de décision du pare-feu avec une grande précision, nous devons faire attention à ne pas confondre cette reconstruction avec une véritable capacité à détecter de nouvelles menaces inconnues. C'est un outil puissant pour vérifier si le pare-feu se comporte de manière cohérente, mais ce n'est pas une boule de cristal pour l'avenir.

Résumé Technique : Reconstruction Quasi-Déterministe des Décisions de Pare-feu d'Entreprise

Énoncé du Problème
Cette étude traite d'un risque d'interprétation méthodologique dans l'apprentissage automatique (machine learning) appliqué à la sécurité réseau : la confusion entre l'apprentissage supervisé de haute performance sur les journaux de pare-feu et la détection de menaces indépendante. Les décisions des pare-feu d'entreprise (Allow, Drop, Deny) sont des résultats déterministes générés par des politiques configurées, l'identification d'applications et des comportements de terminaison de session, plutôt que des étiquettes de malveillance validées par l'humain. Lorsque les modèles atteignent une précision quasi parfaite sur ces journaux, il n'est pas clair s'ils ont appris un raisonnement de sécurité généralisable ou simplement la « grammaire opérationnelle » et les structures de proxy d'un dispositif spécifique. L'article examine dans quelle mesure la surface de décision des journaux d'un pare-feu déployé peut être reconstruite à partir de champs de journaux structurés après exclusion des champs sources directs de l'étiquette, et quelle incertitude résiduelle subsiste lorsque les variables de proxy sont réduites ou que les contextes changent.

Méthodologie
La recherche utilise un ensemble de données réelles de 1 048 576 enregistrements de journaux de trafic provenant d'un pare-feu de nouvelle génération Palo Alto Networks, capturés sur une fenêtre de 46 minutes. La variable cible est une décision opérationnelle à trois classes (Allow, Drop, Deny), construite à partir des champs de sous-type de trafic et de raison de fin de session.

Prétraitement des Données : Les champs sources directs de l'étiquette (action brute, sous-type de trafic, raison de fin de session) sont strictement exclus de toutes les vues de prédicteurs. L'ensemble de données est divisé en un échantillon de test stratifié 80/20 (variantes aléatoires et ordonnées dans le temps) et un échantillon limité pour la validation croisée.
Vues de Caractéristiques (Feature Views) : L'étude emploie plusieurs configurations de caractéristiques pour tester la dépendance aux proxies :
- Baseline Noyau (Core Baseline) : 24 champs incluant le contexte applicatif, les zones, les interfaces, les ports, les pays et la télémétrie post-décision (octets, durée).
- Sans Contexte Applicatif (No-Application-Context) : Supprime la taxonomie et les champs de catégorie d'application pour tester la dépendance aux proxies d'application manifestes.
- Proxy-Minimal Strict (Strict Proxy-Minimal) : Ne conserve que les champs de zone/interface et de transport/port (avec ou sans pays), supprimant l'application, le volume et les champs proximaux de la politique.
- Avec Politique (With-Policy) : Ajoute les champs de règle et de source d'action comme diagnostic de borne supérieure empirique.
Audit Sans Modèle (Model-Free Audit) : Avant l'entraînement des classificateurs, les auteurs effectuent un audit déterministe par groupement exact pour identifier les ensembles déterminants minimaux (sous-ensembles de champs prédisant parfaitement l'étiquette) et calculer l'entropie conditionnelle. Cela inclut la vérification des lignes de conflit (contextes avec plusieurs étiquettes) et des contextes uniques (singleton).
Modèles d'Apprentissage Automatique : L'étude évalue des ensembles d'arbres scalables (XGBoost, LightGBM, Extra Trees, CatBoost) et des arbres de décision simples. Les modèles sont entraînés avec des poids de classe équilibrés pour traiter le déséquilibre de classe sévère (Allow : ~77 %, Drop : ~22 %, Deny : ~1,3 %).
Diagnostics d'Incertitude : L'étude utilise la prédiction conforme (variantes marginale et Mondrian), les ensembles de prédiction adaptatifs (APS) et la classification sélective (abstention basée sur la confiance) pour quantifier l'incertitude résiduelle, la calibration (ECE, score de Brier) et les poches d'erreur sous changement de contexte.

Principales Contributions

Audit de Reconstructibilité Sans Modèle : L'étude identifie sept ensembles déterminants de quatre champs minimum dans l'export complet qui déterminent parfaitement l'étiquette de décision. Ces ensembles incluent systématiquement le port source et les octets de fin de session, combinés à deux autres champs (ex: interface de sortie, catégorie d'application). L'audit confirme l'absence de lignes de conflit dans l'export observé, établissant un déterminisme empirique.
Diagnostics de Stress de Frontière : À travers des ablations de familles de caractéristiques et des tests de maintien de contexte (exclusion de groupes entiers d'applications/catégories, de services de destination ou de règles), l'article cartographie la stabilité de la frontière de décision. Il démontre que si la reconstruction reste quasi parfaite lors de la suppression du contexte applicatif, elle se dégrade significativement sous des vues proxy-minimales strictes et lors de changements de contexte.
Diagnostics Conformes et Sélectifs : La recherche expose que la prédiction conforme marginale peut masquer un manque de couverture de la classe rare « Deny ». Elle montre que les files d'attente de seuil de probabilité et la classification sélective basée sur la confiance sont hautement sensibles à la représentation du modèle (ordinal vs catégoriel natif) et à la calibration, particulièrement sous changement de contexte.
Instanciation Indépendante du Schéma : Le protocole est appliqué à un ensemble de données public indépendant (UCI Internet Firewall), reproduisant une haute reconstructibilité et l'écart « précision vs performance de la classe minoritaire », confirmant que les motifs observés ne sont pas uniques au schéma de l'export d'entreprise spécifique.

Résultats

Performance de Reconstruction : Dans la baseline noyau (excluant les sources directes de l'étiquette), XGBoost et LightGBM ont atteint une performance de test parfaite (Macro-F1 de 1,000, 0 erreur). Même dans l'ablation « sans contexte applicatif », la performance est restée quasi parfaite (Macro-F1 de 0,999981).
Déterminisme : L'audit sans modèle a révélé que 64,7 % à 71,4 % des enregistrements occupent des contextes clés uniques (singleton). Les sept ensembles déterminants de quatre champs trouvés dans l'export complet ont également tenu exactement dans la découverte sur les données d'entraînement et ont maintenu l'accord sur les contextes observés lors des tests de hold-out.
Réduction de Proxy : La suppression des champs de volume et de durée a réduit le Macro-F1 à 0,9962. Une vue proxy-minimal plus stricte (zones, interfaces, ports uniquement) a provoqué une chute significative : XGBoost s'est stabilisé autour d'un Macro-F1 de 0,951, tandis que LightGBM est devenu instable (plage de 0,42 à 0,90) selon la graine aléatoire (seed).
Changement de Contexte : Lorsque des groupes entiers d'applications/catégories ont été exclus, le Macro-F1 pour le LightGBM ordinal est tombé à ~0,673. Cependant, le CatBoost à catégories natives a récupéré ce score à 0,9923 sur les mêmes données, indiquant que la représentation (gestion des catégories non vues) est un facteur critique de performance sous changement de contexte.
Incertitude : Dans les séparations aléatoires, les métriques d'incertitude (entropie, ECE) étaient proches de zéro. Sous changement de contexte, l'incertitude a augmenté, et les ensembles conformes se sont élargis ou sont devenus vides. Crucialement, les ensembles conformes marginaux ont montré un manque de couverture significatif pour la classe rare « Deny » (ex: 58 % de couverture à $\alpha=0,10$ ), qui a été restauré à >90 % grâce à la prédiction conforme de type Mondrian (conditionnelle à la classe).
Temps d'Exécution : La reconstruction complète d'un million de lignes était informatiquement faisable sur un matériel cloud modeste, avec un entraînement XGBoost en ~25 secondes et une prédiction à ~6 ms pour 1 000 lignes.

Signification et Revendications
L'article soutient que les scores de décision de pare-feu quasi parfaits doivent être interprétés comme la preuve d'une surface de décision stable et déterministe au sein d'un export spécifique, plutôt que comme une preuve de détection d'attaque générale ou de raisonnement de sécurité indépendant. La haute reconstructibilité provient du fait que les journaux opérationnels contiennent des traces redondantes de la politique qui a généré la décision (ex: les octets de fin de session et les ports reflètent le résultat).

L'étude se positionne comme un outil de reconstruction de décision rétrospective à limites de revendication et de diagnostics d'incertitude simulés. Elle soutient que de tels modèles sont précieux pour les audits de politiques, les répétitions de migration et l'identification des incohérences de configuration ou des problèmes de qualité de données, mais qu'ils ne peuvent remplacer l'analyse de règles déterministes ni servir de détecteurs d'intrusion inter-environnements. Les conclusions soulignent que les scores « parfaits » en ML de sécurité reflètent souvent la provenance des données et les structures de proxy, nécessitant des ablations rigoureuses, des tests de changement de contexte et une quantification de l'incertitude avant de tirer des conclusions opérationnelles.

Articles similaires