Introduction

En tant qu’analyste de sécurité, traiter un incident de phishing est une tâche courante mais cruciale. Avec XSOAR, cette gestion devient plus efficace et structurée grâce à l’automatisation et l’orchestration des processus. Dans cet article, je vais partager mon expérience de la gestion d’un incident de phishing, en détaillant chaque étape, depuis la détection jusqu’aux actions proactives.

Création de l’Incident

Tout commence par une alerte. Généralement, je reçois une notification d’un système de détection, comme un SIEM (Security Information and Event Management) ou une solution de sécurité des emails, indiquant qu’un email suspect a été reçu par un utilisateur. XSOAR peut automatiquement créer un incident basé sur ces alertes, en rassemblant toutes les informations pertinentes.

Pour ce faire, on utilise la configuration d’une intégration qui va s’interconnecter avec SIEM et on configure le Classifier (choix du type d’incident basé sur une condition concernant une donnée brut en entrée) et le Mapper à utiliser qui permettra, selon le type d’incident, de mapper tel ou tel donnée brute (possiblement modifié à l’aide de filters et transformers) vers un field lié au type d’incident dans XSOAR afin d’homogénéiser les données.

L’incident créer inclut donc tout les détails qui me seront utiles tels que l’expéditeur, le destinataire, le contenu de l’email et les pièces jointes.

Identification de la Criticité

Je commence par analyser les informations disponibles dans l’incident. L’une des premières choses à vérifier est le contenu de l’email et les liens ou pièces jointes qu’il contient. Des indicateurs comme des liens raccourcis, des pièces jointes exécutables ou des demandes de données sensibles sont des signes de phishing.

La criticité initiale de l’incident peut être définie par le mapper, une règle de pré-processing (qui permettra d’éviter les doublons ou de lier des incidents similaires, notamment dans le cas de campagnes de phishing) ou encore lors de l’exécution initiale du Playbook. À noter que l’on configure selon le type d’incident, le Playbook à exécuter, de manière automatique ou non.

La criticité d’un incident de phishing est souvent déterminée en fonction de plusieurs facteurs, comme la position du destinataire dans l’entreprise (par exemple, un cadre supérieur), la nature de l’email, la présence de pièces jointes malicieuses ou encore le fait que l’utilisateur ai cliqué sur un lien possiblement malveillant. De plus, un Dbot Score est calculé en fonction de la moyenne des scores de chaque indicateur trouvé dans l’email. XSOAR permet de définir des règles de priorité qui aident à classer les incidents en fonction de leur potentiel impact.

Vérification des Intégrations pour Obtenir Plus d’Informations

Pour enrichir les informations sur l’incident, je consulte diverses sources de threat intelligence intégrées à XSOAR. Cela inclut des bases de données de réputation des domaines et des adresses IP, ainsi que des sources de renseignement sur les menaces. Ces informations m’aident à évaluer si l’expéditeur ou les liens contenus dans l’email sont associés à des activités malveillantes.

J’utilise également les intégrations avec les SIEM pour vérifier les logs et rechercher des activités suspectes associées à l’incident. Cela peut inclure des tentatives de connexion inhabituelles ou des accès à des ressources sensibles à partir de l’adresse IP de l’expéditeur.

Exécution du Playbook

Pour un incident de phishing, XSOAR propose un Playbook générique conçu pour automatiser et orchestrer la réponse. Le Playbook commence par isoler l’email suspect et alerter les utilisateurs potentiellement affectés. Ensuite, il analyse le contenu de l’email, vérifie les liens et les pièces jointes contre les bases de données de menaces, et recherche des comportements similaires dans les logs.

Le Playbook exécute automatiquement plusieurs étapes, telles que l’analyse des en-têtes d’email, la vérification des liens contenus dans l’email et l’isolation des endpoints affectés. Il peut également envoyer des demandes de renseignement aux services de threat intelligence pour obtenir des informations supplémentaires sur les indicateurs de compromission (IOC).

Finalement, il peut également vérifier si le destinataire (ou l’expéditeur) de l’email est dans une liste VIP et adapter ses actions en conséquences pour demander un traitement manuel par un analyste ou clore automatiquement l’incident.

Interaction avec l’Utilisateur Final

Il est important d’informer l’utilisateur final affecté par l’email de phishing. XSOAR permet d’envoyer des notifications automatiques pour alerter l’utilisateur du potentiel danger et lui fournir des instructions sur ce qu’il doit faire (ou ne pas faire) avec l’email suspect.

Je peux également interagir avec l’utilisateur pour collecter des informations supplémentaires. Par exemple, je peux leur demander s’ils ont cliqué sur un lien ou téléchargé une pièce jointe, ce qui pourrait nécessiter une réponse plus agressive comme l’analyse et l’isolation de leur machine.

Actions Proactives

Isolation de l’Endpoint

Si l’analyse révèle que l’utilisateur a interagi avec le contenu de l’email, une des premières actions est d’isoler l’endpoint pour empêcher toute propagation potentielle de la menace. Cela peut être fait automatiquement via les intégrations avec les solutions EDR ou encore les domaines (Azure) Active Directory, notamment.

Blocage des Adresses IP et Domaines

Je peux également bloquer les adresses IP et les domaines malveillants associés à l’email de phishing. XSOAR permet d’automatiser cette action en envoyant des commandes aux pare-feu et autres dispositifs de sécurité du réseau.

Mise à Jour des Politiques de Sécurité

Enfin, je peux mettre à jour les politiques de sécurité pour prévenir des incidents similaires à l’avenir. Cela peut inclure l’ajout de nouvelles règles de filtrage d’email, l’ajustement des politiques de détection d’intrusion ou la formation des utilisateurs sur les menaces de phishing.

Actions pro-actives dans XSOAR

Lors de futurs emails, qu’ils viennent du même expéditeur, cible d’autres utilisateurs au sein de l’entreprise ou qu’ils aient une similarité forte. XSOAR permet de regrouper ces incidents, les clôres automatiquement ou encore permettrent à l’analyste de voir très rapidement le lien. Un incident de type Phishing Campaign peut également être créer afin d’avoir un regard beaucoup plus large lors du traitement de ces incidents, sans avoir à se soucier de chaque email de cette campagne.

Finalement, les capacités de machine-learning de XSOAR peuvent nous assister à traiter plus rapidement et de manière automatique la majorité de ces incidents.

Conclusion

En tant qu’analyste de sécurité, XSOAR fournit les outils et les automatisations nécessaires pour gérer efficacement un incident de phishing. Depuis la détection initiale et l’analyse, jusqu’à la réponse et la résolution, chaque étape est optimisée grâce aux fonctionnalités robustes de XSOAR. La collaboration entre analystes, l’enrichissement des indicateurs et la capacité à exécuter des actions proactives rendent le processus de gestion des incidents plus fluide et plus efficace.

Chez Alouest IT, nous sommes prêts à vous aider à tirer le meilleur parti de XSOAR pour vos besoins spécifiques en matière de sécurité. Contactez-nous pour découvrir comment nos services et formations peuvent vous aider à optimiser la gestion de vos incidents de sécurité.

Introduction

Les automations dans XSOAR sont des scripts et des actions automatisées qui permettent d’incorporer des développements custom dans XSOAR. Elles jouent un rôle crucial en réduisant le travail manuel, en standardisant les processus et en améliorant la réactivité des équipes de sécurité. Dans cet article, nous allons explorer les fonctionnalités des automations dans XSOAR, illustrer leur utilisation avec des exemples réels et fournir des extraits de code pour mieux comprendre leur mise en œuvre.

Qu’est-ce qu’une Automation dans XSOAR ?

Une automation dans XSOAR est un script Python qui peut être executé dans un grand nombre de contextes :

• task de Playbook
• règle de pre-processing
• source de donnée pour un widget de dashboard
• condition, filter ou transformer personnalisés
• lors de la modification d’un champs d’un incident
• ou encore mon préféré, les sections dynamiques de layout d’incident et d’indicateurs

Ces Automations seront exécuté dans XSOAR soit via des tâches de Playbooks ou encore dans la War Room d’un incident. C’est pourquoi il est important de différencier les commandes d’intégrations (ex: !glpi-get-ticket) des noms d’Automations (ex: !Base64Encode) comme expliqués dans l’article précédent.

Paramètres Communs des Automations

Les Automations dans XSOAR incluent plusieurs paramètres communs qui permettent de personnaliser leur comportement.

• Name : Nom de l’automation pour l’identifier dans le playbook.
• Description : Description détaillée de ce que fait l’automation.
• Timeout : Durée maximale pendant laquelle l’automation peut s’exécuter avant de se terminer automatiquement.
• Inputs : Variables ou données d’entrée nécessaires pour l’automation.
• Tags : C’est ce qui nous permettra de différencier une Automation servant en tant que filter, transformer, condition ou autres.

Ces informations sont disponibles depuis les paramètres de celle ci, accessible via ce bouton :

Décomposition d’un automation

Commençons par un exemple simple :

import demistomock as demisto  # noqa: F401
from CommonServerPython import *  # noqa: F401

array = demisto.args().get('inputArray')
list_name = demisto.args().get('listName')

res = demisto.executeCommand("getList", {"listName": list_name})[0]

for item in array:
    if str(item) in res['Contents']:
        demisto.results('yes')
        break

Laissons deux premières lignes de cette Automation permettent lors de développement de simuler (« mocker« ) les entrées sorties du script afin de l’exécuter localement et de run les tests sans avoir une réelle instance de XSOAR nécessaire.

Concentrons nous sur la 4ème ligne. L’objet demisto appelé est donc l’instance de XSOAR qui expose tout un ensemble de fonctions permettant d’intéragir avec celui-ci. Ici la fonction args() comme son nom l’indique va récupérer un argument inputArray qui sera à passer lors de l’appel à cet automation.

La ligne 7 quand à elle va exécuter la commande getList de XSOAR comme vous le feriez depuis le Playground de XSOAR (!getList) en lui passant en paramètre l’argument listName récupéré ligne 5.

La fonction results() ligne 11 va permettre de retourner des informations à l’analyste/XSOAR, que ce soit sous la forme d’un boolean, d’une str, d’indicateurs ou même d’un fichier. Nous y reviendrons au titre suivant.

En l’occurrence, ici il s’agit d’une automation de condition (avec comme Tag « Condition »), la valeur de retour se devant d’être un boolean. Vous le voyez depuis les paramètres de cette Automation :

Contexte et Outputs

Il existe une norme concernant les valeurs de contextes et d’outputs dans Xsoar :

https://xsoar.pan.dev/docs/integrations/context-and-outputs

Afin d’avoir une plus grande finesse, notamment pour les commandes d’intégration, voici le format utilisé :

demisto.results({
    'Type': entryTypes['note'],
    'ContentsFormat': formats['json'],
    'Contents': anomalies,
    'ReadableContentsFormat': formats['markdown'],
    'HumanReadable': 'Found Anomalies: '   '\n'.join(anomalies),
    'EntryContext': {
        'LogAnalysis.Anomalies': anomalies
    }
})

Et voici les références obligatoires concernant les outputs de commandes : https://xsoar.pan.dev/docs/integrations/context-standards-mandatory

https://xsoar.pan.dev/docs/integrations/context-standards-recommended

Conclusion

Les automations dans XSOAR offrent une flexibilité et une puissance exceptionnelles pour automatiser et orchestrer les réponses aux incidents de sécurité. En utilisant des scripts personnalisés, des commandes d’automations, et des intégrations avec des API externes, vous pouvez créer des workflows sophistiqués qui améliorent considérablement l’efficacité de votre équipe de sécurité. Les exemples réels et les extraits de code présentés ici illustrent comment tirer parti de ces fonctionnalités pour renforcer votre posture de sécurité.

Chez Alouest IT, nous sommes prêts à vous aider à concevoir et implémenter des automations efficaces pour vos besoins spécifiques. Contactez-nous pour découvrir comment nos services et formations peuvent vous aider à maîtriser XSOAR et à automatiser vos opérations de sécurité.

Introduction

Les Playbooks sont au cœur de l’automatisation et de l’orchestration dans XSOAR, la plateforme de sécurité de Palo Alto Networks. Ils permettent de définir des séquences d’actions automatisées pour répondre aux incidents de sécurité de manière cohérente et efficace. Dans cet article, nous allons explorer en détail les Playbooks , les différents types de tasks disponibles, et les paramètres associés à chaque type de task.

Qu’est-ce qu’un Playbook ?

Un Playbook dans XSOAR est une séquence d’actions prédéfinies qui s’exécutent automatiquement en réponse à un incident de sécurité. Les Playbooks sont conçus pour automatiser les tâches répétitives et standardiser les réponses aux incidents, améliorant ainsi la rapidité et l’efficacité des équipes de sécurité.

En réalité, il existe des Playbook et des sub-Playbook. Les Playbooks sont souvent associé à un type d’incident. On peut voir les Playbooks comme des fonctions s’exécutant lorsqu’un certain type d’incident est rencontré, afin de le traiter de manière générique. Un Playbook peut donc faire appel à d’autres « sub-Playbook » afin de découper fonctionnellement les portions pouvant être réutilisables voir génériques.

Types de Tasks dans les Playbooks

Prenons l’exemple du Playbook « Phishing – Generic v3 » associé à l’incident type « Phishing » pour l’exemple. Nous reviendrons dans un prochain article sur l’association des différents objets.

Tasks Section Header

Ces tâches permettent de structurer le Playbook et ces différentes tâches. Dans l’exemple suivant, on voit très bien que nous sommes sur la partie Remediation et que 2 sous branches ont été développées, chacune ayant un rôle spécifique :

Certains Playbooks pouvant accueillir des centaines de tâches, je vous invite donc fortement à les structurer de manière claire pour votre propre confort autant que pour celui de vos collègues. D’autant plus que ces Section Header peuvent vous permettre de démarrer et stopper des Timers (icône de sablier avant Remediation) permettant de mesurer le temps d’exécution de l’ensemble du Playbook ou d’un sous groupe de tâches).

Tasks Standard

Les tasks automatiques s’exécutent sans intervention humaine et sont idéales pour les tâches répétitives et les actions de base. Chaque tâche possède un numéro de tâche unique au Playbook, généré automatiquement de manière incrémentale (ex: #212). Suivi d’un titre que je vous invite à définir de manière synthétique et explicite.

Run Command / Script

Exécute une commande sur un système ou une application intégrée.

Paramètres :

Sous le titre, on commence par le choix d’une « Automation:« , c’est à dire la commande d’intégration ou l’Automation à exécuter. On les différencie grâce à la case de la première lettre de l’Automation ou de la commande d’intégration à exécuter.

Ensuite viennent les onglets :

• Inputs : les arguments pour cette commande, ils diffèrent selon la commande utilisée. N’hésitez pas à passer votre souris sur le point d’interrogation de chaque argument pour avoir plus d’informations sur les valeurs attendues
• Les onglets Outputs, Mapping et Advanced seront documentés dans un autre article dédiés à la manipulation du contexte.
• L’onglet Details vous permettra notamment de fixer un Timeout et un nombre de retry en cas d’échec d’exécution de cette commande
• L’onglet On Error quand à lui, permettra de définir la manière de réagir de la tâche en cas d’erreur : doit-on continuer comme si de rien n’était, stopper le Playbook ou encore appelé une tâche différente afin de signaler l’erreur par mail par exemple ?

Tasks Conditionnelles

Les tasks conditionnelles permettent de définir des branches dans le Playbook en fonction des conditions spécifiques.

Vous les différenciez grâce au losange précédent le titre de la tâche. Les tâches de commandes ont une flêche, comme pour la tâche #85 de cet exemple.

Rentrons dans le détails de ces tâches conditionnelles :

Ici l’on peut définir un nombre important de condition des plus complexes.

Notons d’abords que chaque condition à un nom, la première dans notre exemple étant Yes.

Suite à cela, on définit à sur la partie gauche de la condition, la valeur à laquelle on va appliquer une condition. Dans notre exemple, on va aller chercher la valeur du field reporteremailaddress de l’incident (un article sur la manipulation des valeurs est en cours d’écriture, celui ci nécessitant largement un article entier).

Vient ensuite la condition en elle même. Voici une partie des conditions disponibles :

Ces conditions sont pour certaines Built-In, mais les autres sont en réalité des automations avec un tag spécifique que nous verrons plus tard. Vous pouvez donc également développer vos propres conditions de manières très simple.

Pour illustrer la partie droite de la condition, imaginons que nous souhaitions vérifier si l’adresse de la personne ayant report le mail de phishing soit bien un de nos employés. Nous pourrions le faire très simplement avec la condition suivante :

Notez l’utilisation d’un Transformers que j’ai rajouté sur la partie gauche afin de m’assurer que les deux soient en lower case. Nous reviendrons également dans un autre article afin de présenter la puissance quasi sans limite des filters et transformers.

Tasks Data Collection

Enfin, les tasks de collection de données nécessitent une intervention humaine pour continuer.

Ici nous prenons donc un exemple basique pour l’exemple qui va demander à l’analyste de répondre à un petit questionnaire généré par XSOAR. Les plus malins aurons noté que je réutilise la tâche conditionelle précédente. Ce questionnaire sera généré automatiquement à partir de l’onglet Questions.

Ici nous demandons à l’analyste de vérifier si l’adresse de l’expéditeur lui semble louche ou non.

Nous pourrons ensuite continuer sur une tâche conditionnelle qui ne sera exécuté qu’après la réponse de l’analyste et qui choisira des chemins différents selon cette même réponse.

Bien sûr ceci n’est qu’un apperçu des Data Collection, les lecteurs les plus attentifs auront remarqués les Add Question based on field, la sélection du type de réponse attendu ou encore l’onglet Timing qui seront détaillée dans un prochaine article

Conclusion

Les playbooks dans XSOAR offrent une puissance et une flexibilité extraordinaires pour automatiser et orchestrer les réponses aux incidents de sécurité. En combinant différents types de tasks, des tasks automatiques aux tasks conditionnelles, vous pouvez créer des workflows sophistiqués qui améliorent considérablement l’efficacité de votre équipe de sécurité. Nous n’avons fait qu’effleurer le sujet car les capacités de XSOAR sont sans limites. Nous reviendrons sur une multitude de détails au fil de cette série.

Toute fois j’espère que ce post vous aura permit de comprendre les types de tasks disponibles et leurs paramètres afin de vous permettre de tirer le meilleur parti de XSOAR et de renforcer votre posture de sécurité.

Chez Alouest IT, nous sommes prêts à vous aider à concevoir et implémenter des Playbooks efficaces pour vos besoins spécifiques. Contactez-nous pour découvrir comment nos services et formations peuvent vous aider à maîtriser XSOAR et à automatiser vos opérations de sécurité.