Des développeurs examinent du code sur un grand écran dans un espace de travail sombre.

Automatisation des tests ATT&CK avec SOAR et Atomic Red Team

5 Lecture en une minute

 

MITRE ATT&CK ATT&CK constitue le cadre de référence de facto permettant aux organisations de mesurer leur posture de défense. ATT&CK propose des catégories verticales sous la forme de tactique, qui correspondent aux méthodologies courantes utilisées par les attaquants. Au sein de ces verticales se trouvent un ensemble (et des sous-ensembles) de méthodes courantes employées par les attaquants pour mettre en œuvre une tactique (verticale). Celles-ci sont connues sous le nom de techniques.

Certaines techniques peuvent être communes à plusieurs systèmes d'exploitation. Cela correspond généralement à une définition large du terme « technique ». En tant que spécialistes de la sécurité, cela signifie que nous devons comprendre comment une même technique peut être mise en œuvre sur différentes plateformes, ce qui peut s'avérer complexe pour beaucoup, y compris pour moi. Heureusement, des organisations comme Red Canary ont fourni à notre communauté un cadre de travail complet pour faciliter le test de ces techniques.

Red Canary a rendu open-source l'équipe Atomic Red Ce projet, lancé il y a plusieurs années, vise à aider la communauté de la sécurité en fournissant un ensemble d'Atomics (tests) alignés sur le framework MITRE ATT&CK. Chaque Atomic est associé à une technique spécifique d'ATT&CK et propose un ou plusieurs tests exécutables sur un système. Ces Atomics sont conçus pour simuler ou émuler la manière dont un attaquant exploite une technique au sein de votre environnement.

En plus de fournir un ensemble de tests exécutables, Red Canary propose également plusieurs frameworks d'exécution permettant de les lancer. Ces frameworks sont écrits en Python, PowerShell (Core) et Ruby, mais le plus récent (et le plus actif) est de loin le framework PowerShell (Core). À noter également :, J'ai réécrit le framework PowerShell en septembre 2018., mais elle a subi de nombreux changements depuis.

L'idée est d'utiliser un framework d'exécution pour lancer un ou plusieurs tests atomiques sur un système. En retour, votre solution EDR, SIEM, etc., déclencherait des alertes/détections et commencerait à mesurer votre efficacité par rapport à des techniques spécifiques au sein de votre environnement. Cependant, cette démarche s'est avérée être un processus manuel complexe, fastidieux et chronophage.

Étant fan de longue date de Red Canary et de leur projet Atomic Red Team, je me suis fixé deux objectifs principaux :

  1. Pour exécuter des tests à distance sur plusieurs types de systèmes d'exploitation à l'aide d'un seul framework.
  2. Associer les détections/alertes aux tests atomiques au sein d'un environnement.

J'ai récemment présenté comment j'ai pu atteindre ces objectifs grâce à Swimlane SOAR.. De plus, je souhaitais contribuer à la communauté de la sécurité en publiant en open source un composant de ce cas d'utilisation.

Cas d'utilisation

Test de l'équipe rouge

Le principal cas d'utilisation concerne plusieurs applications au sein d'un même espace de travail. J'ai pu extraire les données d'Atomic Red Team Atomics et les regrouper dans un seul enregistrement. Atomiques application. Comme je l'ai mentionné précédemment, chaque Atomic peut avoir plusieurs tests associés, et ces tests peuvent ne pas concerner un seul type de système d'exploitation. J'ai donc créé une application secondaire appelée Essais atomiques, qui contient les détails de chaque test et est associé à l'enregistrement parent Atomics.

Essai atomique unique
Un enregistrement de test atomique unique associé à un enregistrement Atomics parent.

Le principal point d'entrée qu'un analyste utiliserait est le Hôte L'application hôte contient des informations sur l'hôte sur lequel vous souhaitez exécuter un test. Un analyste créera un enregistrement et fournira (au minimum) un nom, une adresse (IP ou DNS) et le type de système d'exploitation. Une fois cette nouvelle application créée, l'application hôte sera enregistrée. Hôte L'enregistrement étant sauvegardé, un analyste doit choisir les tests qu'il souhaite exécuter. Il utilise pour cela un enregistrement de référence. Essais atomiques Dans l'application, une fois les tests ajoutés, ils peuvent choisir d'exécuter un ou plusieurs tests associés à l'enregistrement.

gouvernail

Vous vous demandez peut-être : “ Comment vont-ils réaliser ces tests à distance ? ” Eh bien, j’aimerais vous présenter un nouvel outil open source appelé gouvernail. gouvernail est un package Python qui exécute à distance des commandes sous Windows, macOS ou *nix, et il est multiplateforme.

Afin d'utiliser gouvernail, Vous devez lui fournir un ensemble d'identifiants permettant d'utiliser soit PowerShell Remoting/WinRM (Gestion à distance Windows), soit SSH sur l'hôte prévu.

Gouvernail

Une fois que vous aurez fourni un ensemble d'identifiants au sein de notre Keystore, Vous pouvez exécuter des tests sur plusieurs hôtes et systèmes d'exploitation depuis Swimlane. Pour chaque test exécuté sur un hôte, nous créons un historique dans une autre application appelée Historique des tests. Cette application conserve l'historique de tous les tests effectués sur un hôte, ainsi que la réponse du système. Chaque test est associé à l'hôte sur lequel il a été exécuté, fournissant ainsi des informations contextuelles historiques.

Une fois le premier test exécuté sur un hôte, nous recherchons immédiatement les alertes et détections entrantes similaires à celles de notre test. Pour ce faire, nous analysons les applications et les champs spécifiques à surveiller. Nous prenons également en compte les points de données suivants pour établir notre décision (tous ces éléments peuvent être facilement modifiés ou personnalisés selon les besoins de votre organisation) :

  1. Comparaison d'horodatages
    1. La recherche des heures de début est basée sur l'horodatage du lancement du test sur l'hôte.
    2. La durée finale est configurable, mais par défaut, elle est fixée à 3 heures depuis l'exécution du test.
  2. Comparaison d'adresses
    1. Nous examinons les champs fournis et vérifions si le nom/l'adresse de l'hôte d'alerte correspond à l'adresse sur laquelle le test a été exécuté.
  3. Comparaison d'exécution
    1. Normalisation des détails des tests et alertes atomiques
      1. Minuscule
      2. Supprimer les caractères (ex. |, \\, etc.)
    2. Comparez deux listes de commandes pour trouver la différence en pourcentage entre des chaînes et des valeurs similaires.
    3. Facultatif:
      1. Nous avons offert la possibilité d'utiliser les calculs de distance de Levenstein et les comparaisons de hachage SSDeep, mais ces méthodes sont coûteuses et sont mieux adaptées à des valeurs source et destination similaires.

Une fois la comparaison effectuée et si nous avons déterminé qu'une alerte/détection est similaire à notre test, nous associons alors cet enregistrement d'alerte à notre historique de tests unique. À ce stade, nous créons un enregistrement ou associons notre historique de tests à une autre application appelée Enregistrements de la carte thermique.

Équipe rouge de l'interface utilisateur de Swimlane
Un enregistrement d'historique de test associé à un enregistrement d'alerte identifié et à un enregistrement de carte thermique
 

A Enregistrement de la carte thermique Ce système permet de suivre, de signaler et d'afficher les données relatives à notre capacité à détecter (ou non) certaines techniques lors de nos tests. Si un test a été exécuté et qu'aucune alerte n'a été identifiée, nous enregistrons tout de même cet événement, mais notre rapport sera légèrement différent de celui que nous aurions utilisé si nous avions pu détecter avec précision une technique lors de tous les tests effectués.

Une fois ces enregistrements créés ou un historique de test associé à une technique, nous pouvons alors visualiser où nous sommes capables de détecter les activités malveillantes et où nous échouons.

À l'intérieur du damier Alertes de couloir de nage
Widget du tableau de bord MITRE ATT&CK affichant les détections et leur absence.
 

Ci-dessus figure une image du widget Tableau de bord MITRE ATT&CK de Swimlane. Ce tableau de bord extrait des données de notre Enregistrements de la carte thermique et l'affichage est dynamique. Si une case de la grille est incolore, cela signifie que nous n'avons pas effectué de tests pour cette technique spécifique. Le bleu foncé indique que nous avons effectué au moins un test et que nous avons pu la détecter. À mesure que de nouveaux tests et détections sont identifiés, la couleur s'éclaircit pour devenir bleu turquoise. Sous (Windows). Si un test a été effectué et qu'aucune détection n'a été identifiée, alors cette technique sera signalée en rouge.

En utilisant L'équipe rouge atomique de Red Canary Avec Swimlane SOAR, automatisez vos tests ATT&CK et obtenez une visibilité complète sur vos capacités de détection et vos lacunes. Fini les tests, les analyses et les corrélations manuelles ! Ce cas d’usage vous permet d’identifier rapidement les lacunes et de lancer de nouveaux tests en quelques minutes.

Automatisation des tests ATT&CK avec SOAR, illustrée sur un fond réseau sombre.

Automatisation des tests d'attaque avec SOAR et Atomic Red Team (46:31)

Regardez maintenant

Demander une démo en direct