Assumed Breach : objectifs, méthodologie, scénarios de tests et use cases

Dans un contexte où les cyberattaques ne cessent de croître en fréquence, en sophistication et en impact, les approches défensives traditionnelles, bien que nécessaires, ne suffisent plus.

Pour protéger efficacement les systèmes d’information et anticiper les attaques, les entreprises doivent adopter une posture offensive. Cette démarche proactive englobe des pratiques telles que les pentests, les audits Red Team et les exercices Assumed Breach.

Dans cet article, nous détaillons les principes et objectifs des exercices Assumed Breach. Nous abordons également la méthodologie de tests ainsi que des uses cases de scénarios courants.

Guide complet sur l’Assumed Breach

Des tests d’intrusion aux exercices Assumed Breach : pourquoi l’approche offensive est essentielle ?

Les tests d’intrusion ont longtemps été la pierre angulaire des évaluations de sécurité. Ils consistent à identifier et exploiter les vulnérabilités dans les systèmes d’une organisation afin de corriger les failles avant qu’elles ne soient découvertes par des attaquants. Bien qu’indispensables, ces tests restent axés sur une logique de couverture : leur objectif est de découvrir un maximum de faiblesses potentielles dans un laps de temps limité.

De leur côté, les audits Red Team offrent une approche plus ciblée et réaliste. Ils simulent des attaques complexes menées par des adversaires avancés, en combinant des techniques de piratage, d’ingénierie sociale et d’intrusion physique. Ces exercices mettent à l’épreuve l’ensemble des défenses de l’organisation, y compris la détection et la réponse des équipes SOC (Security Operations Center).

Cependant, à mesure que les organisations renforcent leurs périmètres de sécurité, les attaquants cherchent à contourner ces défenses et à exploiter des vecteurs plus subtils. C’est ici qu’intervient l’Assumed Breach, une approche encore plus ciblée et pragmatique, qui repose sur l’hypothèse que l’intrusion initiale a déjà eu lieu. Cette méthodologie offre une réponse essentielle à un monde où le « quand » l’organisation sera compromise est plus réaliste que le « si ».

Qu’est-ce que l’Assumed Breach ?

L’approche Assumed Breach repose sur l’hypothèse qu’une organisation a déjà été compromise ou le sera inévitablement.

Contrairement aux tests d’intrusion, qui cherchent à identifier un maximum de failles potentielles, l’Assumed Breach se concentre sur des scénarios spécifiques d’attaques réussies.

Cela permet de mesurer la capacité d’une organisation à détecter, répondre et contenir une menace active.

En effet, les exercices Assumed Breach représentent une progression logique des pratiques offensives de cybersécurité. Plutôt que de se concentrer sur les moyens d’entrer dans le système, cette approche commence à l’intérieur, en assumant qu’un attaquant a déjà un point d’accès. Cela peut inclure :

• Un accès réseau interne via un VPN ou un serveur d’accès.
• L’utilisation d’un poste de travail d’utilisateur simulé comme point de départ.
• Un compte compromis avec des droits standards ou élevés.

Ainsi, les exercices Assumed Breach permettent d’évaluer avec précision :

• Les capacités de détection : Les équipes de sécurité peuvent-elles identifier l’activité malveillante une fois le périmètre franchi ?
• La réponse aux incidents : Combien de temps faut-il pour contenir et neutraliser une menace active ?
• La résilience des systèmes critiques : Les protections existantes peuvent-elles limiter les impacts d’une compromission ?

Pourquoi adopter l’approche Assumed Breach ?

Répondre aux limites des tests d’intrusion

Les tests d’intrusion traditionnels offrent une vue globale des failles potentielles, mais ils sont souvent limités en temps et en budget.

Par conséquent, ils privilégient la couverture maximale au détriment de la profondeur dans des scénarios précis.

L’Assumed Breach comble cette lacune en se concentrant sur les attaques ciblées et les impacts réels qu’un attaquant pourrait causer.

Contourner les contraintes du Red Teaming

L’un des principaux défis du Red Teaming est son coût élevé. Simuler une attaque complète nécessite des ressources considérables en temps, en personnel et en budget. Ces simulations, bien qu’efficaces, peuvent également être longues à planifier et complexes à exécuter.

Les exercices Assumed Breach, en revanche, contournent ces contraintes en démarrant directement là où le Red Teaming vise à arriver : au cœur du réseau. Cette approche élimine le besoin de franchir les défenses périmétriques et se concentre sur les étapes ultérieures de l’attaque, comme le mouvement latéral, l’escalade de privilèges ou l’exfiltration de données.

Ainsi, l’Assumed Breach simplifie la logistique, réduit les coûts et maximise l’efficacité des tests offensifs, sans pour autant compromettre leur réalisme ni leur impact.

Simuler des scénarios réalistes

Les exercices Assumed Breach permettent de reproduire des situations de menace courantes, telles que :

• Vol de données sensibles après la compromission d’un poste utilisateur.
• Mouvement latéral dans le réseau pour atteindre des systèmes critiques.
• Exploitation de vulnérabilités non corrigées.

En focalisant les tests sur des scénarios crédibles, les équipes de sécurité peuvent identifier les lacunes spécifiques dans leurs défenses actuelles et prioriser les actions correctives.

Méthodologie et déroulement d’un exercice Assumed Breach

Définir les objectifs de l’exercice

Avant de commencer un exercice Assumed Breach, il est essentiel de clarifier les attentes et les priorités. Ces objectifs peuvent varier selon le niveau de maturité en cybersécurité de l’organisation.

Par exemple, une entreprise peut vouloir évaluer la robustesse de ses défenses internes en simulant des scénarios d’attaques avancées. D’autres peuvent chercher à tester la réactivité de leurs équipes face à une intrusion en cours.

Un autre objectif courant est d’évaluer l’impact potentiel d’une compromission sur des actifs critiques, tels que des bases de données sensibles ou des infrastructures cloud. Ces résultats doivent être alignés avec les enjeux stratégiques de l’entreprise pour maximiser la valeur de l’exercice.

Choix du scénario Assumed Breach

Le choix du scénario détermine la pertinence de l’exercice. Chaque scénario est conçu pour refléter des menaces réalistes adaptées au contexte organisationnel. Cela peut inclure :

• La compromission d’un compte utilisateur pour tester les systèmes SSO et la gestion des permissions.
• Une intrusion physique simulée pour vérifier la sécurité des accès aux locaux.
• Une attaque ciblée sur une application web ou une infrastructure DevOps.

Ce choix repose sur une analyse préalable des risques spécifiques à l’entreprise et de ses vulnérabilités potentielles.

Reconnaissance et cartographie

Une fois l’accès initial simulé, les testeurs se concentrent sur l’identification des cibles stratégiques. Cette phase inclut la cartographie du réseau interne, l’analyse des permissions des comptes utilisateurs, et la recherche de systèmes ou services mal configurés.

Les bases de données, les serveurs d’applications, ou encore les points d’accès au cloud font partie des cibles privilégiées. L’objectif est de repérer rapidement des faiblesses exploitables qui pourraient permettre un mouvement latéral ou une élévation de privilèges.

Exploitation et déplacement latéral

Dans cette phase, les testeurs mettent en œuvre les tactiques nécessaires pour exploiter les vulnérabilités découvertes. Cela peut inclure la prise de contrôle de comptes privilégiés, l’accès à des systèmes critiques ou l’exfiltration de données sensibles.

Ils simulent également des mouvements latéraux pour évaluer la capacité des systèmes de sécurité à détecter et contenir une progression dans le réseau interne. L’objectif est de reproduire les étapes post-compromission d’une attaque réelle.

Reporting et recommandations

L’exercice se conclut par la remise d’un rapport détaillé. Ce document inclut une analyse complète des vulnérabilités découvertes, des tactiques utilisées, et des impacts simulés sur l’organisation.

Des recommandations concrètes sont proposées pour chaque problème identifié, avec une priorisation en fonction de la criticité. Ce rapport est un outil précieux pour guider les équipes techniques et décisionnelles dans l’amélioration de leur posture de sécurité.

Exemples de scénarios Assumed Breach et use cases

L’approche Assumed Breach permet d’explorer différents scénarios de compromission qui reflètent les menaces réelles auxquelles les organisations sont exposées.

Voici des exemples détaillés, accompagnés de cas pratiques pour illustrer leur application.

Compromission d’un compte utilisateur via le SSO

Scénario : Un attaquant a obtenu les identifiants d’un employé via du phishing ou des fuites d’informations. Il utilise cet accès pour compromettre le portail Single Sign-On (SSO) et accéder aux applications tierces.

Use Case : Une compromission chez une entreprise utilisant Microsoft 365

• Contexte : Une entreprise utilise Microsoft 365 avec un portail SSO intégré pour ses employés. Un attaquant a obtenu les identifiants d’un utilisateur non privilégié via une attaque de phishing.
• Exploitation : L’attaquant accède à des documents sensibles sur SharePoint, utilise Teams pour envoyer des messages contenant des liens malveillants à d’autres utilisateurs, et explore les permissions des applications tierces.
• Objectifs : Identifier si des applications mal configurées permettent l’exfiltration de données, et tester les capacités de détection du système de sécurité.

Dans ce type de scénario, le résultat attendu peut concerner, entre autres :

• La découverte de failles dans la gestion des permissions des applications tierces.
• L’amélioration des configurations liées à la gestion des accès (authentification multi-facteurs par exemples) et des journaux de détection.

Pivot sur le réseau depuis une machine compromise

Scénario : Un attaquant prend le contrôle d’un poste utilisateur et utilise cet accès pour explorer le réseau interne et atteindre des systèmes critiques.

Use Case : Compromission d’un poste utilisateur via un fichier malveillant

• Contexte : Un employé télécharge un fichier Excel contenant une macro malveillant depuis un email de phishing. Une fois le fichier ouvert, le malware établit une connexion C2.
• Exploitation :
  • Reconnaissance : L’attaquant analyse les segments réseau accessibles à partir du poste compromis.
  • Mouvement latéral : Il tente d’exploiter des vulnérabilités dans des serveurs ou des stations connectées pour obtenir des privilèges plus élevés.
  • Objectif final : Accéder à une base de données contenant des informations sensibles.

Ici, l’objectif peut concerner, entre autres :

• L’identification des lacunes dans la segmentation réseau.
• La validation de la capacité des systèmes EDR à détecter les mouvements latéraux.

Exploitation des environnements DevOps

Scénario : Un attaquant cible l’infrastructure DevOps pour compromettre la chaîne de développement.

Use Case : Intrusion dans un dépôt Git privé

• Contexte : Une entreprise héberge son code source dans un dépôt Git interne. Un attaquant, après avoir compromis un compte développeur, accède aux dépôts et cherche des secrets ou des clés API.
• Exploitation :
  • Recherche de clés d’accès intégrées dans le code.
  • Accès à des environnements de test ou de préproduction mal sécurisés.
  • Injection de code malveillant dans un pipeline CI/CD pour déployer un malware en production.

Dans ce type de scénario, le résultat attendu peut concerner, entre autres :

• L’identification des pratiques à risque, comme le stockage de secrets dans le code.
• La mise en place de contrôles robustes pour sécuriser les pipelines CI/CD.

Pour plus d’infos sur ce scénario, vous pouvez consulter notre article, qui décrit une mission à mi-chemin entre pentest et Assumed Breach : Audit en boite blanche d’un pipeline CI/CD sur AWS.

Compromission d’un serveur exposé

Scénario : Un attaquant exploite une vulnérabilité connue sur un serveur public pour accéder au réseau interne.

Use Case : Exploitation d’une application web mal configurée

• Contexte : Une organisation héberge une application web qui n’a pas été mise à jour depuis plusieurs mois. Une vulnérabilité de type injection SQL est exploitée pour obtenir un accès shell (web shell) au serveur.
• Exploitation :
  • L’attaquant utilise le shell pour explorer l’infrastructure backend connectée.
  • Il pivote vers des bases de données ou d’autres applications internes.
  • Si possible, il déploie un ransomware pour maximiser l’impact.

Ici, l’objectif peut concerner, entre autres :

• L’identification des failles de configuration dans le WAF.
• Le renforcement des processus de gestion des correctifs et des mises à jour.

Intrusion physique et vol d’un dispositif interne

Scénario : Un attaquant obtient un accès physique aux locaux pour compromettre un terminal ou installer un dispositif malveillant.

Use Case : Intrusion lors d’une visite en entreprise

• Contexte : Lors d’une réunion dans les locaux d’une entreprise, un attaquant se connecte physiquement à un terminal non surveillé ou installe un dispositif malveillant comme un Raspberry Pi.
• Exploitation :
  • Accès au réseau interne via le dispositif installé.
  • Exploration des systèmes locaux pour récolter des identifiants ou exploiter des failles.
  • Déploiement d’un outil C2 pour une prise de contrôle à distance.

Dans ce type de scénario, les objectifs peuvent être les suivants :

• Tester les procédures de sécurité physique et de contrôle d’accès.
• Mettre en place une supervision accrue des dispositifs connectés au réseau.

Réaliser un exercice Assumed Breach avec Vaadata, entreprise spécialisée en sécurité offensive

Vaadata est une société spécialisée en sécurité offensive. Nous proposons des tests d’intrusion, du Red Teaming et des exercices Assumed Breach pour évaluer et renforcer la cyber-résilience de nos clients.

Certifiés ISO 27001, ISO 27701 et accrédités CREST, mous nous engageons respecter les meilleures pratiques de l’industrie et à offrir des prestations alignées sur les normes de sécurité les plus exigeantes.

Ces certifications garantissent une approche rigoureuse et une exécution conforme aux attentes de nos clients.

Auteur : Amin TRAORÉ – CMO @Vaadata