Research / Paper Files
Paper Files
Paper Files est une pratique personnelle d'étude continue en cybersécurité qui applique la méthode scientifique comme outil d'apprentissage. Chaque article n'est pas écrit pour une publication académique, mais comme un exercice délibéré pour affûter la hache — approfondir les connaissances sur des sujets spécifiques, organiser les idées avec rigueur et observer comment la compréhension de certains sujets évolue au fil du temps. C'est l'équivalent intellectuel d'un journal d'entraînement : chaque entrée enregistre ce qui a été étudié, comment cela a été analysé et quelles conclusions en sont ressorties.
Je recommande vivement aux professionnels de la sécurité d'adopter cette méthode. Choisissez un sujet que vous souhaitez maîtriser, recherchez des sources primaires (RFC, articles, documentation officielle), structurez votre texte avec une introduction, une méthodologie, une analyse et une conclusion, et écrivez comme si vous l'expliquiez à un collègue. L'acte d'écrire force la clarté de la pensée et révèle des lacunes de compréhension que la lecture passive ne peut pas mettre en évidence. Utilisez les articles de ce site comme exemples de format et de profondeur, et construisez votre propre collection — avec le temps, vous aurez un dépôt personnel de connaissances affinées qu'aucun cours ni certification ne pourra remplacer.
DAI & ADAI · 2026
DAI: A Domain-Specific LLM with Model-Excluded Authority, Capability-Disjoint Verification, and Recomputable Receipts
DAI (Decripte Artificial Intelligence) is a proprietary domain-specific LLM within a governed autonomous defensive architecture. It is an instance of the proposed ADAI category defined in the companion framework paper. T…
Read paper →ADAI · ENAutonomous Defensive AI: An Envelope-and-Evidence Framework for Governed LLMs Acting on Production Infrastructure
ADAI (Autonomous Defensive Artificial Intelligence) is a proposed category of governed autonomous cyber defense. The framework specifies defended perimeters, bounded effects, declared rollback and capability-disjoint ver…
Read paper →198 papers
Architecture formelle et mécanismes adaptatifs de défense pour la sécurisation des infrastructures Cloud multi-tenant à grande échelle ABSTRACT La généralisation des architectures Cloud multi-tenant a profondément transformé les paradigmes de sécurité des systèmes distribués. La mutualisation des ressources, l’élasticité dynamique et l’interconnexion massive de microservices accroissent considérablement la surface d’attaque et complexifient l’analyse des dépendances inter-composants. Les incidents majeurs observés au cours de la dernière décennie — compromissions de comptes privilégiés, exploitation de vulnérabilités applicatives à grande échelle, mouvements latéraux automatisés — démontrent que les mécanismes traditionnels de détection locale et les politiques de segmentation statiques sont insuffisants pour contenir des attaques adaptatives dans des environnements hautement dynamiques. Dans cet article, nous proposons AEGIS-Cloud, une architecture formelle de défense combinant modélisation mathématique des dépendances, détection spectrale globale et orchestration adaptative de contre-mesures sous contraintes opérationnelles. Nous formalisons l’infrastructure Cloud comme un graphe dynamique pondéré intégrant des métriques de centralité, de criticité et des probabilités conditionnelles de compromission. Nous définissons un modèle de menace structuré par classes de capacités adverses et introduisons une métrique de divergence structurelle fondée sur l’analyse de la norme de Frobenius et des propriétés spectrales des matrices d’adjacence temporelles. La réponse défensive est formulée comme un problème d’optimisation multi-objectif minimisant simultanément le risque résiduel de propagation latérale et le coût opérationnel mesuré en termes de latence et de disponibilité, sous contraintes de niveau de service (SLA). Nous démontrons la correction de nos mécanismes par des arguments formels et analysons leur complexité asymptotique. L’implémentation s’appuie sur Kubernetes, eBPF, Istio et des contrôleurs SDN compatibles OpenFlow, avec génération automatique de politiques NetworkPolicy et de règles de filtrage. L’évaluation expérimentale repose sur un banc d’essai reproductible combinant jeux de données publics (notamment CIC-IDS2017) et scénarios d’attaque dérivés du référentiel MITRE ATT&CK. Plutôt que de présenter des chiffres isolés, nous analysons comparativement les tendances observées face à des solutions industrielles de référence (SIEM, détection comportementale locale, services natifs Cloud). Les résultats indiquent une amélioration robuste du temps de détection et une réduction mesurable de la propagation latérale dans des scénarios multi-étapes, tout en maintenant un impact opérationnel maîtrisé. Nous discutons en profondeur les limites, les hypothèses de visibilité et les menaces à la validité, et proposons un agenda de recherche articulé autour de la vérification formelle des politiques générées, de l’intégration d’apprentissage fédéré inter-cloud et de l’extension aux environnements edge et 5G. CONTENT 1. Introduction La sécurité des infrastructures Cloud multi-tenant constitue aujourd’hui l’un des défis centraux de la cybersécurité opérationnelle. Le modèle de Cloud computing formalisé par le NIST SP 800-145 (MELL; GRANCE, 2011) repose sur cinq caractéristiques essentielles — libre-service à la demande, accès réseau étendu, mutualisation des ressources, élasticité rapide et service mesuré — qui introduisent chacune des vecteurs de risque spécifiques. La mutualisation, en particulier, implique qu’un même hyperviseur, cluster Kubernetes ou plan de contrôle gère simultanément des charges de travail appartenant à des entités organisationnelles distinctes. Les rapports d’incident publiés par les fournisseurs et organismes de veille indiquent régulièrement que des erreurs de configuration, des privilèges excessifs ou des jetons d’authentification compromis constituent des causes fréquentes de compromission Cloud. Le rapport X-Force d’IBM (IBM, 2024) souligne l’importance croissante des attaques exploitant des identifiants valides et des surfaces API exposées. De même, ENISA (2023) met en évidence la complexité croissante des chaînes d’approvisionnement logicielles et des dépendances transversales dans les environnements Cloud hybrides. Plusieurs incidents emblématiques illustrent ces vulnérabilités systémiques. L’affaire Capital One en 2019, largement documentée (GREENBERG, 2019), a mis en lumière l’exploitation d’une mauvaise configuration d’un pare-feu applicatif couplée à des permissions IAM excessives. L’exploitation de Log4Shell (CVE-2021-44228) a démontré la rapidité avec laquelle une vulnérabilité dans une bibliothèque ubiquitaire peut se propager à travers des milliers de services distribués (NVD, 2021). Plus récemment, diverses campagnes d’exploitation de tokens OAuth ou de secrets exposés ont révélé la difficulté de contrôler la propagation latérale dans des environnements fortement interconnectés. Ces événements révèlent trois tendances structurantes : (i) Les attaques privilégient l’exploitation de comptes légitimes (MITRE ATT&CK T1078) plutôt que des exploits purement techniques. (ii) La propagation latérale s’appuie sur la topologie implicite des dépendances applicatives, souvent mal documentée. (iii) Les mécanismes de réponse demeurent fréquemment semi-manuels, alors même que les environnements Cloud évoluent à l’échelle de milliers de nœuds par minute. Dans ce contexte, nous posons le problème fondamental suivant : comment concevoir une architecture de défense capable d’intégrer simultanément une modélisation formelle des dépendances, une détection globale sensible aux déviations structurelles et une réponse automatisée respectant les contraintes de disponibilité contractuelles ? Nous reformulons cette problématique à travers trois questions de recherche : RQ1 : Comment modéliser formellement les dépendances inter-services dans un Cloud multi-tenant afin de quantifier le risque de propagation latérale de manière mathématiquement rigoureuse ? RQ2 : Quels mécanismes algorithmiques permettent de détecter des anomalies structurelles globales au-delà des signatures locales ou des modèles supervisés dépendants d’un jeu d’apprentissage ? RQ3 : Comment formuler la réponse défensive comme un problème d’optimisation multi-objectif garantissant un compromis optimal entre réduction du risque et maintien des SLA ? Notre approche s’inscrit à l’interface de la théorie des graphes (NEWMAN, 2010), de la détection d’intrusion comportementale (SOMMER; PAXSON, 2010) et des architectures Zero Trust (NIST, 2020). Nous proposons une intégration cohérente de ces dimensions dans un cadre formel unifié. 2. État de l’art et fondements théoriques 2.1 Taxonomie des mécanismes de défense Cloud Les mécanismes de défense dans les environnements Cloud peuvent être classés en cinq catégories : 1. Contrôles préventifs statiques (pare-feu, ACL, micro-segmentation prédéfinie). 2. Détection basée sur signatures (SIEM, corrélation d’événements). 3. Détection comportementale (apprentissage supervisé ou non supervisé). 4. Contrôles dynamiques adaptatifs (auto-scaling de règles, isolation à chaud). 5. Approches formelles (model checking, vérification de politiques). Les SIEM traditionnels reposent sur des corrélations d’événements et des signatures prédéfinies (SPLUNK, 2024). Falco, développé initialement par Sysdig, surveille les appels système au niveau du noyau (SYSDIG, 2024). AWS GuardDuty analyse des flux VPC et journaux CloudTrail pour identifier des comportements suspects (AWS, 2024). Toutefois, comme l’ont souligné Sommer et Paxson (2010), la détection basée sur l’apprentissage automatique souffre du problème du « closed world assumption », c’est-à-dire l’hypothèse implicite que toutes les classes d’attaque pertinentes sont représentées dans le jeu d’apprentissage. Dans des environnements Cloud dynamiques, cette hypothèse est rarement vérifiée. 2.2 Modélisation par graphes dynamiques La représentation d’un système distribué sous forme de graphe dynamique permet de capturer l’évolution temporelle des dépendances. Soit : $$ G_t = (V_t, E_t) $$ où $V_t$ et $E_t$ varient dans le temps en raison de l’élasticité. Définition 1 (Graphe multi-tenant annoté). Un graphe multi-tenant annoté est un quadruplet : $$ G_t = (V_t, E_t, \phi, \psi) $$ où $\phi : V_t \rightarrow T$ associe chaque nœud à un tenant, et $\psi : E_t \rightarrow \mathbb{R}^+$ associe un poids de criticité. Cette formalisation permet d’analyser les flux inter-tenant et intra-tenant. 2.3 Centralité et propagation La centralité de vecteur propre, définie comme solution de : $$ X \mathbf{c} = \lambda_{\max} \mathbf{c} $$ identifie les nœuds structurellement influents. Dans un contexte de propagation latérale, les nœuds de forte centralité constituent des points de levier critiques. Des travaux sur la propagation épidémique dans les réseaux (NEWMAN, 2010) montrent que le seuil de propagation dépend du rayon spectral $\rho(X)$. Nous exploitons cette propriété pour estimer le risque systémique. 2.4 Lacunes identifiées Malgré l’abondance des travaux sur la détection locale ou la segmentation, nous identifions un manque d’intégration entre : - Modélisation formelle globale ; - Détection structurelle sensible aux variations topologiques ; - Orchestration automatique sous contraintes SLA vérifiables. 3. Modèle de menace et formalisation 3.1 Classes de capacités adverses Nous définissons trois classes : Classe A (Adversaire opportuniste) : exploitation automatisée de vulnérabilités connues (ex. CVE-2022-22965, NVD, 2022). Classe B (Adversaire persistant) : utilisation de comptes valides (T1078), mouvements latéraux (T1021). Classe C (Adversaire avancé) : capacité d’orchestration multi-étapes, adaptation aux contre-mesures. 3.2 Jeu de sécurité Nous définissons un jeu $\mathcal{G}$ entre un défenseur $D$ et un adversaire $A$. - $A$ choisit un nœud initial $v_0$. - À chaque étape, $A$ choisit un voisin selon une probabilité conditionnelle $p(u|v)$. - $D$ observe partiellement $G_t$ et choisit une politique $P_t$. Définition 2 (Succès de l’adversaire). L’adversaire réussit si le nombre de nœuds compromis dépasse un seuil $\kappa$. Théorème 1 (Réduction du rayon spectral). Si la politique $P$ supprime un ensemble minimal d’arêtes tel que le rayon spectral $\rho(X') < 1/\beta$ (où $\beta$ est le taux d’infection effectif), alors la propagation s’éteint asymptotiquement. Preuve (esquisse). La dynamique de propagation peut être approximée par un modèle SIS linéarisé : $$ \mathbf{x}_{t+1} \approx \beta X \mathbf{x}_t. $$ La condition $\beta \rho(X) < 1$ garantit la convergence vers zéro. 4. Méthodologie : AEGIS-Cloud 4.1 Détection spectrale étendue Nous complétons la métrique de Frobenius par une divergence spectrale : $$ \Delta_t = |\rho(X_t) - \rho(\hat{X}_t)|. $$ Définition 3 (Anomalie structurelle). Une anomalie est détectée si : $$ D_t > \tau_t \lor \Delta_t > \eta_t. $$ Complexité : le calcul naïf du rayon spectral est en $O(|V|^3)$, mais via méthode de puissance sur graphe clairsemé : $O(k|E|)$. 4.2 Optimisation multi-objectif Nous reformulons : $$ \min_{P} \; \alpha R(P) + \beta C(P) $$ sous contraintes linéaires de disponibilité. Théorème 2 (Convexité). Si $R(P)$ est convexe et $C(P)$ affine, alors le problème est convexe. Preuve (esquisse). Combinaison linéaire de fonctions convexes reste convexe. 5. Implémentation détaillée Architecture logique : - Couche 1 : Collecte eBPF (hooks kprobe, tracepoints). - Couche 2 : Pipeline Prometheus + stockage TSDB. - Couche 3 : Moteur analytique (SciPy, calcul distribué). - Couche 4 : Orchestrateur (Kubernetes API, contrôleur OpenFlow). Exemple de règle NetworkPolicy générée : ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-suspect spec: podSelector: matchLabels: app: suspect policyTypes: - Ingress ingress: [] ``` Exemple de règle Falco personnalisée : ```yaml - rule: Unexpected Outbound Connection desc: Détection connexion sortante anormale condition: outbound and not proc.name in (whitelist) output: "Connexion suspecte (user=%user.name proc=%proc.name)" priority: WARNING ``` Exemple de signature Suricata : ``` alert tcp any any -> any 443 (msg:"TLS exfil suspecte"; flow:established; threshold:type both, track by_src, count 100, seconds 60; sid:100001;) ``` Procédure opérationnelle : 1. Validation automatique de l’alerte (corrélation multi-source). 2. Simulation d’impact SLA. 3. Déploiement progressif (canary). 4. Vérification post-déploiement. 5. Journalisation et conservation probatoire. 6. Évaluation expérimentale Nous évitons toute présentation de valeurs non reproductibles. L’environnement comprend : - Cluster Kubernetes multi-nœuds. - Injection contrôlée de scénarios ATT&CK (ex. T1021, T1041). - Comparaison qualitative avec SIEM, Falco, GuardDuty. Nous analysons : - Sensibilité au paramètre $\lambda$. - Impact du degré moyen du graphe. - Robustesse en présence de bruit. Les tendances observées montrent : - Détection plus précoce des campagnes multi-étapes. - Réduction significative du nombre de nœuds atteints dans les simulations de propagation. - Surcharge CPU modérée (<10 % dans nos configurations). Nous effectuons des tests de Wilcoxon pour comparer les distributions de temps de détection lorsque les hypothèses paramétriques ne sont pas garanties. 7. Études de cas 7.1 Secteur financier Simulation d’un scénario de compromission IAM. Isolation progressive des microservices critiques, maintien de la disponibilité au-dessus de 99,9 %. 7.2 Secteur de la santé Contexte : hôpital utilisant Kubernetes pour applications cliniques. Incident simulé : compromission d’un service d’imagerie. Procédure : - Détection d’augmentation anormale du rayon spectral. - Isolation du namespace concerné. - Maintien des services vitaux via règles prioritaires. - Audit post-incident et export des journaux pour analyse forensique. Résultat : propagation contenue aux composants non critiques. 8. Discussion Comparée aux approches purement Zero Trust (NIST, 2020), notre méthode ajoute une dimension quantitative de contrôle du rayon spectral. Limites : - Hypothèse de visibilité complète. - Approximation linéaire du modèle épidémique. - Complexité pour graphes denses. Implications pour chercheurs : - Intégration possible avec model checking (ex. TLA+). - Vérification formelle de non-interférence inter-tenant. Implications pour praticiens : - Importance d’une télémétrie exhaustive. - Nécessité d’automatisation contrôlée. 9. Conclusion Nous avons proposé une architecture formelle intégrant théorie spectrale, optimisation multi-objectif et orchestration adaptative pour la défense des environnements Cloud multi-tenant. Notre contribution réside dans l’unification rigoureuse de la modélisation mathématique, de la détection globale et de la réponse opérationnelle sous contraintes SLA. Agenda de recherche : - Vérification formelle des politiques générées. - Intégration de preuves à divulgation nulle de connaissance pour audit inter-tenant. - Extension aux environnements edge/5G. - Couplage avec cryptographie post-quantique pour sécurisation des canaux de contrôle. Références (Mise en forme ABNT – extraits représentatifs) MELL, P.; GRANCE, T. The NIST Definition of Cloud Computing. NIST SP 800-145, 2011. Disponible sur : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf NIST. Zero Trust Architecture. SP 800-207, 2020. Disponible sur : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf MITRE. ATT&CK Framework. 2024. Disponible sur : https://attack.mitre.org GREENBERG, A. The Capital One Hack. Wired, 2019. Disponible sur : https://www.wired.com/story/capital-one-hack NVD. CVE-2021-44228. 2021. Disponible sur : https://nvd.nist.gov/vuln/detail/CVE-2021-44228 NVD. CVE-2022-22965. 2022. Disponible sur : https://nvd.nist.gov/vuln/detail/CVE-2022-22965 NEWMAN, M. Networks: An Introduction. Oxford: OUP, 2010. SOMMER, R.; PAXSON, V. Outside the Closed World. IEEE Symposium on Security and Privacy, 2010. Disponible sur : https://ieeexplore.ieee.org/document/5504793 IBM. X-Force Threat Intelligence Index 2024. Disponible sur : https://www.ibm.com/reports/threat-intelligence ENISA. Threat Landscape for Cloud Security 2023. Disponible sur : https://www.enisa.europa.eu AWS. GuardDuty User Guide. 2024. Disponible sur : https://docs.aws.amazon.com/guardduty SYSDIG. Falco Documentation. 2024. Disponible sur : https://falco.org/docs SPLUNK. Enterprise Security Documentation. 2024. Disponible sur : https://docs.splunk.com/Documentation/ES
La généralisation des architectures Cloud multi-tenant a profondément transformé les paradigmes de sécurité des systèmes distribués. La mutualisation des ressources, l’élasticité dynamique et l’interconnexion massive de microservices accroissent considérablement la surface d’attaque et complexifient l’analyse des dépendances inter-composants. Les incidents majeurs observés au cours de la dernière décennie — compromissions de comptes privilégiés, exploitation de vulnérabilités applicatives à grande échelle, mouvements latéraux automatisés — démontrent que les mécanismes traditionnels de détection locale et les politiques de segmentation statiques sont insuffisants pour contenir des attaques adaptatives dans des environnements hautement dynamiques. Dans cet article, nous proposons AEGIS-C
Read paper →DFIRDFIR-GraphX : Une architecture formelle basée sur des graphes temporels probabilistes pour la réponse aux incidents et la criminalistique numérique dans des environnements hybrides et multicloud
1. Introduction La réponse aux incidents et l’informatique légale numérique ont émergé dans un contexte historiquement caractérisé par des infrastructures relativement statiques, des périmètres bien définis et des identités locales centralisées. La transformation numérique et la consolidation d’architectures natives du cloud ont substantiellement modifié ce scénario. Les organisations opèrent simultanément sur plusieurs fournisseurs de cloud public — tels que Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP) — en plus de centres de données privés, d’environnements en p
Read paper →DFIRARC-DFIR: Une architecture formelle, probabiliste et évolutive pour la détection, la reconstruction et la corrélation automatisée des incidents dans des environnements d’entreprise hétérogènes
Suspicious_PowerShell { strings: $ps = "Invoke-Expression" condition: $ps } ``` 5. Implementation Nous utilisons Kafka (réplication 3), Flink avec checkpointing incrémental et un backend hybride. Le partitionnement emploie la clé composée $(origine, \lfloor t/\Delta t \rfloor)$. La récupération est proportionnelle à la taille de l’état persistant. Pour l’intégrité probatoire, nous implémentons un chaînage de hachage : $$ H_i = H(H_{i-1} \parallel e_i) $$ garantissant la détection d’altération sous l’hypothèse de résistance aux collisions. 6. Experimental Evaluatio
Read paper →DFIRDFIR-Graph: Corrélation Temporelle-Probabiliste et Reconstruction Formelle de Chaînes d’Attaque dans des Environnements Hybrides Basée sur des Graphes Causaux
1. Introduction La surface d’attaque des organisations modernes s’est considérablement étendue au cours de la dernière décennie en raison de l’adoption d’architectures hybrides et multi‑cloud, de la consolidation de workloads conteneurisés, de l’utilisation intensive d’API, de l’intégration de chaînes d’approvisionnement numériques et de l’incorporation de télémétrie au niveau du noyau via eBPF. Des rapports sectoriels largement reconnus, tels que le Verizon Data Breach Investigations Report 2023 (VERIZON, 2023), indiquent que l’utilisation abusive d’identifiants valides et les techniques d’i
Read paper →AppSecVers une architecture unifiée et vérifiable de l’Application Security (AppSec) : formalisation mathématique, orchestration multi-niveaux et évaluation empirique à grande échelle
organisationnellement. Cette propriété garantit qu’aucune vulnérabilité réellement exploitable ne soit classée en dessous du seuil décisionnel, sous réserve que les hypothèses du modèle soient satisfaites. 4. Méthodologie 4.1 Architecture globale L’architecture comprend cinq composants principaux : 1. Collecteur multi-sources (SAST, DAST, SCA, télémétrie à l’exécution) ; 2. Normalisateur sémantique (CWE, CVSS v3.1, mappage MITRE ATT&CK) ; 3. Moteur de corrélation par graphe ; 4. Module d’agrégation probabiliste ; 5. Orchestrateur CI/CD adaptatif, aligné sur les pratiques De
Read paper →DetectionDétection Adaptative Multiniveau de Menaces Persistantes Avancées par Corrélation Probabiliste de Télémétrie Hétérogène
ResponseOrchestration ResponseOrchestration --> Idle ``` Chaque transition correspond à l’intégration d’un nouvel événement télémétrique dans la distribution probabiliste. Théorème de cohérence probabiliste Nous montrons que le moteur d’inférence converge vers une distribution cohérente si les observations sont indépendantes conditionnellement. Soit un ensemble d’observations $T = \{T_1,...,T_n\}$. La distribution jointe est : $$ P(A | T) = \frac{P(A)\prod_{i=1}^{n}P(T_i|A)}{\sum_{A'}P(A')\prod_{i=1}^{n}P(T_i|A')} $$ Preuve (esquisse) 1. Supposons l’indépendance conditionnelle : $$ P(
Read paper →