TITRE : Architecture adaptative pour la détection et la contention des mouvements latéraux dans des environnements multi-cloud fondée sur des graphes de privilèges et une analyse probabiliste

1. Introduction

La transformation numérique accélérée de la dernière décennie a consolidé le cloud computing comme infrastructure essentielle pour les services financiers, les systèmes de santé, les télécommunications, l’énergie et l’administration publique. Les modèles Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) et Software-as-a-Service (SaaS) coexistent dans des architectures hybrides et multi-cloud, dans lesquelles les organisations répartissent les charges de travail entre plusieurs fournisseurs afin d’éviter la dépendance technologique, d’optimiser les coûts ou de satisfaire à des exigences réglementaires.

Cependant, cette diversification introduit une complexité structurelle substantielle. Dans les environnements traditionnels on-premises, le périmètre réseau jouait un rôle central dans la segmentation et la défense. En revanche, les environnements cloud adoptent un paradigme orienté identité, dans lequel des politiques déclaratives définissent des permissions fines sur des API programmatiques. Le modèle de responsabilité partagée implique que les configurations incorrectes, les privilèges excessifs et les délégations mal comprises demeurent sous le contrôle direct du client.

Des rapports largement reconnus, tels que le Data Breach Investigations Report de Verizon, ont systématiquement identifié l’abus d’identifiants valides comme vecteur prédominant de compromission. Le framework MITRE ATT&CK documente des techniques telles que Valid Accounts (T1078), Use of Web Application Vulnerabilities pour l’obtention initiale d’accès, ainsi que des techniques ultérieures de Pass-the-Token (T1550) ou Account Manipulation (T1098), qui illustrent la progression latérale après la compromission initiale. La vulnérabilité CVE-2021-44228 (Log4Shell), identifiée dans la bibliothèque Apache Log4j, a démontré comment des failles dans des composants largement distribués peuvent entraîner l’exécution de code à distance et l’exfiltration subséquente de secrets stockés dans des variables d’environnement, incluant fréquemment des clés d’accès à des services cloud.

L’incident impliquant Capital One en 2019, largement analysé dans des rapports publics et dans des procédures judiciaires, a mis en évidence comment des configurations inappropriées de pare-feu d’application web combinées à des permissions excessives sur des services de stockage peuvent permettre une extraction massive de données. Indépendamment des détails spécifiques, le schéma récurrent est clair : l’impact maximal ne résulte pas seulement du vecteur initial, mais de la capacité à exploiter des chemins de privilège.

Dans les environnements multi-cloud, la situation est aggravée par des identités fédérées via SAML 2.0 ou OpenID Connect (OIDC), par des rôles assumables (tels que AWS STS AssumeRole), des Managed Identities dans Azure et des Service Accounts dans Google Cloud. Les relations de confiance croisées entre comptes et abonnements créent des graphes de délégation qui ne sont pas trivialement visibles depuis une seule interface d’administration.

Cette réalité soulève des questions fondamentales :

RQ1: Comment modéliser formellement les relations de privilège et de confiance dans des environnements multi-cloud de manière unifiée et évolutive, tout en préservant la sémantique spécifique à chaque fournisseur ?

RQ2: Est-il possible d’estimer quantitativement — même de manière probabiliste et non déterministe — la probabilité de réussite d’un mouvement latéral à partir d’un point initial compromis ?

RQ3: Comment réduire la surface d’attaque associée aux chemins critiques de privilège avec un impact minimal sur les opérations légitimes, dans le respect des principes de continuité d’activité ?

Nous proposons une architecture qui répond à ces questions en intégrant la théorie des graphes, l’analyse probabiliste et l’optimisation combinatoire sous contraintes opérationnelles. Notre approche se distingue en combinant une modélisation structurelle explicite avec une estimation probabiliste interprétable et des mécanismes adaptatifs de confinement.

2. Background and Related Work

2.1 Graphes d’attaque et modélisation structurelle

La littérature sur les graphes d’attaque remonte à des travaux classiques tels que Ammann, Wijesekera et Kaushik (2002), qui ont proposé des techniques de génération évolutive de graphes d’attaque (AMMANN; WIJESEKERA; KAUSHIK, 2002). Par la suite, Noel et al. (2009) ont exploré des métriques quantitatives de risque dans les réseaux (NOEL et al., 2009). Ces travaux ont établi les fondements pour représenter des états système et des transitions exploitables.

Cependant, nombre de ces modèles supposent des environnements réseau relativement statiques et ne capturent pas la nature déclarative et dynamique des politiques IAM dans le cloud. Des outils tels que BloodHound, présentés publiquement par Singla (2016), modélisent les relations de privilège dans Active Directory, permettant l’identification de chemins vers des comptes privilégiés. Bien que conceptuellement proches, ces approches se concentrent principalement sur des environnements on-premises et n’intègrent pas plusieurs fournisseurs cloud.

2.2 Détection fondée sur les anomalies et les journaux

Les systèmes de détection d’intrusion (AXELSSON, 2000; SCARFONE; MELL, 2007) ont évolué d’approches fondées sur les signatures vers des méthodes comportementales. Des travaux comme DeepLog (DU et al., 2017) ont appliqué des réseaux neuronaux récurrents à la modélisation séquentielle des journaux. Dans le contexte cloud, des journaux tels que AWS CloudTrail et Azure Activity Logs sont fréquemment analysés pour détecter des anomalies d’API.

Toutefois, les approches purement comportementales rencontrent des défis d’interprétabilité et peuvent souffrir d’un taux élevé de faux positifs dans des environnements très dynamiques. En outre, détecter des anomalies n’implique pas nécessairement l’identification des chemins structurels qui rendent possible l’escalade de privilèges.

2.3 Zero Trust et architectures fondées sur l’identité

Le NIST SP 800-207 définit les principes de Zero Trust Architecture (ROSE et al., 2020), en mettant l’accent sur la vérification continue et le moindre privilège. Le NIST SP 800-53 Rev.5 (NIST, 2020) établit des contrôles de sécurité applicables aux systèmes fédéraux. Cependant, ces documents fournissent des directives normatives, et non des algorithmes concrets pour l’analyse probabiliste de graphes multi-cloud.

2.4 Lacunes identifiées

À partir de la revue, nous identifions trois lacunes principales :

1. Absence d’un modèle formel unifié intégrant plusieurs fournisseurs tout en conservant la sémantique de délégation.
2. Manque d’intégration entre la structure des privilèges et l’estimation probabiliste de l’exploitation.
3. Rareté de méthodes systématiques de mitigation optimisée avec analyse explicite de l’impact opérationnel.

Notre travail se situe à l’intersection de ces lacunes.

3. Threat Model and Problem Formalization

3.1 Définitions formelles

Définition 1 (Environnement multi-cloud).
Un environnement multi-cloud est modélisé comme un graphe dirigé pondéré $G = (V, E, w, \lambda)$, où :

• $V = V_I \cup V_R$ est l’ensemble des sommets, partitionné en identités $V_I$ et ressources $V_R$ ;
• $E \subseteq V \times V$ est l’ensemble des arêtes représentant des permissions ou des relations de confiance ;
• $w: E \rightarrow (0,1]$ attribue des poids interprétés comme des probabilités conditionnelles d’exploitation ;
• $\lambda: V \rightarrow {AWS, Azure, GCP, …}$ étiquette le fournisseur associé.

Définition 2 (Chemin de mouvement latéral).
Un chemin $p = (v_0, v_1, …, v_k)$ est une séquence telle que $(v_i, v_{i+1}) \in E$ pour tout $i$.

En supposant une indépendance conditionnelle simplificatrice entre les arêtes, le risque cumulé est :

$$ R(p) = \prod_{i=0}^{k-1} w(v_i, v_{i+1}). $$

Nous reconnaissons que l’hypothèse d’indépendance constitue une approximation ; nous en discutons les limites à la Section 7.

3.2 Modèle d’adversaire

Nous définissons des classes de capacité :

• Classe A1 : Compromission initiale d’une identité valide.
• Classe A2 : Capacité d’énumérer les métadonnées via des API autorisées.
• Classe A3 : Exploitation automatisée de chaînes de délégation.
• Classe A4 : Persistance via la manipulation des politiques (lorsque cela est permis).

Nous n’assumons pas la compromission du plan de contrôle du fournisseur ni des défaillances cryptographiques sous-jacentes à TLS ou aux mécanismes de signature.

3.3 Jeu de sécurité

Nous modélisons l’interaction comme un jeu probabiliste :

1. Le défenseur choisit la politique $E$.
2. L’adversaire choisit $v_0 \in V_I$.
3. Le système évolue selon la distribution induite par $w$.

Définition 3 (Nœud critique).
Un nœud $v$ est critique s’il représente une ressource à forte valeur (par exemple, une base de données sensible).

L’objectif du défenseur est de minimiser :

$$ \Pr[\exists p: v_0 \leadsto v_{crit} \land R(p) \geq \tau]. $$

4. Proposed Methodology

4.1 Architecture générale

L’architecture se compose de :

1. Ingestion des politiques : collecte des politiques IAM, rôles, bindings et relations fédérées.
2. Normalisation sémantique : traduction vers un modèle intermédiaire commun.
3. Construction du graphe : persistance dans une base orientée graphe.
4. Moteur probabiliste : calcul de centralité et de risque via RWR.
5. Mécanisme de mitigation : optimisation sous contraintes.

4.2 Random Walk with Restart (RWR)

Soit $W$ la matrice de transition normalisée telle que :

$$ W_{ij} = \frac{w(j,i)}{\sum_{k} w(j,k)}. $$

Le vecteur de risque $r$ satisfait :

$$ r = (1-\alpha) W^T r + \alpha r_0. $$

Théorème 1 (Convergence).
Pour $0 < \alpha < 1$, l’itération converge vers une solution unique.

Esquisse de la preuve :
La matrice $(1-\alpha)W^T$ a un rayon spectral strictement inférieur à 1, garantissant une contraction dans l’espace normé $\ell_1$.

Complexité par itération : $O(|E|)$.
Nombre d’itérations jusqu’à la convergence $\epsilon$ : $O(\log(1/\epsilon))$ sous les hypothèses usuelles.

4.3 Optimisation de la mitigation

Nous formulons :

$$ \min_{\Delta E} |\Delta E| $$

sous les contraintes :

$$ r_{crit} < \tau $$

où $r_{crit}$ est la composante de $r$ associée aux nœuds critiques.

Le problème est NP-difficile par réduction au problème de coupe minimale avec contraintes multiples. Nous utilisons une heuristique gloutonne fondée sur la contribution marginale :

Définition 4 (Contribution marginale).

$$ \Delta_e = r_{crit}^{(E)} - r_{crit}^{(E \setminus {e})}. $$

Nous sélectionnons itérativement les arêtes ayant le plus grand $\Delta_e / C_e$, où $C_e$ représente le coût opérationnel estimé.

Complexité approximative : $O(k|E|)$ pour $k$ suppressions.

5. Implementation

Nous avons implémenté un prototype en Python 3.11. La collecte utilise :

• AWS boto3 (IAM, STS, Organizations).
• Azure SDK for Python (Microsoft Graph, Role Assignments).
• Google Cloud Client Libraries (IAM Policy Bindings).

Le graphe est stocké dans Neo4j, permettant des requêtes Cypher pour l’identification de motifs.

5.1 Pipeline de données

1. Extraction périodique des politiques.
2. Stockage dans un format intermédiaire JSON normalisé.
3. Construction incrémentale du graphe.
4. Exécution asynchrone du RWR.

5.2 Intégration avec les journaux

Journaux pris en charge :

• AWS CloudTrail.
• Azure Activity Logs.
• Google Cloud Audit Logs.

Exemple de règle Sigma pour la détection d’un AssumeRole inhabituel :

title: AWS AssumeRole from Unusual IP
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: AssumeRole
  condition: selection
level: medium

Exemple de signature Suricata pour la détection de l’exploitation Log4Shell (simplifiée) :

alert http any any -> any any (msg:"Possible Log4Shell Exploit"; content:"${jndi:"; nocase; sid:100001;)

Exemple de règle YARA pour identifier des artefacts d’outils d’énumération IAM :

rule IAM_Enum_Tool
{
    strings:
        $s1 = "iam:ListRoles"
        $s2 = "iam:ListUsers"
    condition:
        any of ($s)
}

Ces mécanismes complètent l’analyse structurelle.

5.3 Considérations de déploiement

• Exécution dans un cluster Kubernetes.
• Segmentation par fournisseur.
• Contrôle d’accès au graphe lui-même (principe du moindre privilège).
• Journaux immuables stockés dans un stockage avec versionnement.

6. Experimental Evaluation

Afin d’éviter des affirmations invérifiables, nous présentons une évaluation méthodologique fondée sur des scénarios contrôlés.

6.1 Méthodologie

Nous avons construit des environnements de test sur plusieurs fournisseurs avec :

• Des comptes isolés pour l’expérimentation.
• Des politiques délibérément configurées avec différents niveaux de privilège.
• L’injection contrôlée de scénarios de mauvaise configuration (par exemple, des rôles largement assumables).

Baselines comparées qualitativement :

• Outils natifs d’analyse d’accès (AWS IAM Access Analyzer).
• Revue manuelle fondée sur les bonnes pratiques du NIST SP 800-53.

6.2 Métriques

• Nombre relatif de chemins critiques identifiés.
• Réduction en pourcentage des arêtes à haut risque après mitigation.
• Impact opérationnel mesuré par des échecs dans des tests automatisés de workloads.

Nous observons, de manière cohérente, que la priorisation probabiliste permet d’identifier un sous-ensemble réduit d’arêtes dont la suppression réduit significativement la connectivité vers les nœuds critiques, par comparaison avec des approches purement fondées sur la correspondance de motifs.

6.3 Analyse de l’évolutivité

La construction du graphe croît linéairement avec $|E|$. Dans des expériences internes contrôlées, le temps d’exécution du RWR a présenté un comportement approximativement linéaire en fonction du nombre d’arêtes, cohérent avec la complexité théorique.

7. Case Studies

7.1 Secteur financier

Dans un environnement représentatif d’une institution financière avec plusieurs comptes segmentés par domaine métier, nous avons identifié des chaînes impliquant :

1. Compromission d’un compte de développeur.
2. Assumation d’un rôle d’intégration CI/CD.
3. Accès à un bucket contenant des artefacts de déploiement.
4. Extraction d’identifiants intégrés dans une configuration héritée.

En appliquant la mitigation, nous avons restreint la confiance cross-account et appliqué des conditions fondées sur l’origine réseau.

7.2 Secteur de la santé

Dans une organisation de santé avec des charges sur Azure et GCP :

• Managed Identity avec des permissions étendues sur une base de données.
• Fédération OIDC avec un fournisseur externe.

Le modèle a identifié un chemin potentiel vers des données sensibles. La mitigation a impliqué la segmentation des rôles et l’application de politiques conditionnelles basées sur les attributs du dispositif.

8. Discussion

La modélisation structurelle probabiliste offre un avantage interprétable par rapport aux méthodes purement statistiques. Toutefois, les limitations incluent :

• L’hypothèse d’indépendance des arêtes.
• La difficulté d’estimer les poids $w$ avec précision.
• Une possible explosion combinatoire dans des environnements extrêmement vastes.

Comparativement aux graphes d’attaque classiques, notre modèle intègre explicitement la sémantique des identités fédérées multi-cloud.

Pour les praticiens, l’implication principale est la nécessité d’une visibilité globale et d’une normalisation sémantique. Pour les chercheurs, cela ouvre un agenda impliquant la vérification formelle des politiques IAM à l’aide de techniques de model checking et l’intégration avec la cryptographie appliquée pour la preuve de l’intégrité des journaux.

9. Conclusion and Future Work

Nous avons présenté une architecture adaptative pour la détection et le confinement du mouvement latéral dans les environnements multi-cloud, fondée sur des graphes de privilèges et une analyse probabiliste. Nous avons formalisé le modèle de menace, démontré la convergence mathématique de l’algorithme de risque et discuté une heuristique de mitigation sous contraintes opérationnelles.

Comme programme futur, nous proposons :

1. Intégration avec la vérification formelle (par exemple, traduction des politiques IAM en logique temporelle et utilisation du model checking).
2. Estimation bayésienne des poids $w$ fondée sur des données historiques.
3. Utilisation d’une optimisation robuste tenant compte de l’incertitude adversariale.
4. Incorporation de l’apprentissage par renforcement avec des garanties formelles de sécurité.
5. Évaluation à grande échelle avec collaboration interinstitutionnelle.

Nous estimons que la convergence entre théorie formelle, analyse probabiliste et pratiques opérationnelles est essentielle pour faire face à la complexité croissante des environnements multi-cloud.

References

AMMANN, P.; WIJESEKERA, D.; KAUSHIK, S. Scalable, graph-based network vulnerability analysis. In: ACM CCS, 2002. Available at: https://dl.acm.org/doi/10.1145/586110.586145

AXELSSON, S. Intrusion detection systems: A survey and taxonomy. Technical Report, Chalmers University, 2000. Available at: https://www.cse.chalmers.se/~svenaxel/publications/

DU, M. et al. DeepLog: Anomaly Detection and Diagnosis from System Logs. In: ACM CCS, 2017. Available at: https://dl.acm.org/doi/10.1145/3133956.3134015

NIST. Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev.5), 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

NOEL, S. et al. Measuring security risk of networks using attack graphs. IEEE Security & Privacy, 2009. Available at: https://ieeexplore.ieee.org/document/4812701

ROSE, S. et al. Zero Trust Architecture (SP 800-207). NIST, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final

SINGLA, A. BloodHound. Black Hat USA, 2016. Available at: https://www.blackhat.com/docs/us-16/materials/us-16-Singla-BloodHound.pdf

SCARFONE, K.; MELL, P. Guide to Intrusion Detection and Prevention Systems (SP 800-94). NIST, 2007. Available at: https://csrc.nist.gov/publications/detail/sp/800-94/final

VERIZON. 2023 Data Breach Investigations Report. Available at: https://www.verizon.com/business/resources/reports/dbir/

MITRE. ATT&CK Framework. Available at: https://attack.mitre.org/

ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, 2010. Available at: https://dl.acm.org/doi/10.1145/1721654.1721672

ENISA. Cloud Security Risk Assessment, 2022. Available at: https://www.enisa.europa.eu/publications

ISO/IEC. 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services. Available at: https://www.iso.org/standard/43757.html

KATZ, J.; LINDELL, Y. Introduction to Modern Cryptography. CRC Press, 2014. Available at: https://www.cs.umd.edu/~jkatz/imc.html