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é.