Intégrer Trapster à Sekoia : guide pratique

Ce guide détaille, étape par étape, comment connecter Trapster à Sekoia, configurer des règles de détection adaptées, puis automatiser la réponse via un playbook.

Qu'est-ce que Sekoia ?

Sekoia est une plateforme de défense automatisée et d'opérations de sécurité (XDR/SIEM), pilotée par l'intelligence artificielle. Pensée pour simplifier le travail des équipes SOC, elle permet de centraliser l'ensemble des alertes de sécurité et d'y réagir automatiquement, réduisant ainsi le temps entre la détection d'une menace et sa neutralisation.

Qu'est-ce que Trapster ?

Trapster déploie des honeypots (leurres) sur le réseau pour détecter les mouvements latéraux, les scans malveillants et les menaces internes. Ces leurres n'ont aucun usage légitime : toute interaction avec eux signale immédiatement une activité suspecte. Pensé pour détecter une intrusion très rapidement, avec très peu de faux positifs, cet outil constitue une ligne de défense discrète mais redoutablement efficace.

Pourquoi intégrer les deux ?

Intégrer Trapster à Sekoia permet de faire remonter ces alertes à très faible taux de faux positifs directement dans la plateforme de pilotage de la sécurité. Le SOC dispose ainsi d'une visibilité centralisée sur ces interactions et peut déclencher une réaction quasi immédiate face à la menace, que ce soit sous la forme d'une notification, d'un enrichissement automatique, ou d'une action de confinement.

Premier pas

Pour commencer, voici un aperçu du dashboard. Celui-ci est généré par défaut par Sekoia, mais il est tout à fait possible d'en créer d'autres, entièrement personnalisés. On y retrouve l'ensemble des statistiques concernant les alertes détectées.

Différentes sections sont disponibles sur la plateforme, mais dans cet article, on se concentrera sur cinq d'entre elles, celles qui couvrent l'ensemble du parcours de l'intégration : Intakes, Events, Alerts, Rules Catalog et Playbooks.

Intégration de Trapster

Création de l'intake

En premier lieu, il faut créer un nouvel intake afin de pouvoir relier Trapster à Sekoia. Pour ce faire, il suffit de se rendre dans la section Intakes, puis de cliquer sur New Intake.

Il existe un format spécifique pour Trapster, qu'il faut sélectionner à cette étape.

Il suffit ensuite de nommer l'intake et de sélectionner son Entity (l'unité organisationnelle à laquelle l'intake sera rattaché).

Sekoia va ensuite fournir une Intake Key, qu'il faudra renseigner directement dans le dashboard de Trapster. Pour cela, rendez-vous dans Settings, puis Webhook, et enfin Add.

Il faut ensuite sélectionner Sekoia, puis entrer la clé (Intake Key) récupérée précédemment dans le champ prévu à cet effet.

Désormais, l'intake est correctement configuré, ce qui peut être vérifié dans la section Events de Sekoia. En déclenchant volontairement une alerte sur Trapster (avec un scan Nmap par exemple), on peut constater que Sekoia récupère correctement les données envoyées par Trapster.

En cliquant sur un événement, il est possible d'en voir le détail, comme le type d'alerte ou l'adresse IP source, par exemple.

Création des règles de détection

Les règles de détection permettent de définir les conditions dans lesquelles une alerte doit être déclenchée ou non. Il existe des règles préconfigurées, proposées en fonction du format d'intake sélectionné.

Elles ne sont pas toutes adaptées à Trapster : n'activez que celles qui correspondent à votre contexte, sous peine de diluer des alertes à très faible taux de faux positifs dans du bruit générique. Une règle intéressante est SEKOIA Intelligence Feed : elle détecte les menaces à partir de la base d'indicateurs de compromission de Sekoia. Générique, mais utile.

Ce qui est très intéressant ici, c'est qu'il est possible de créer ses propres règles personnalisées, en cliquant sur New Rule.

Voici un exemple de règle catch-all générique, qui permet de relever une alerte quelle que soit l'interaction avec Trapster :

detection:
  selection:
    observer.product: "trapster"
    observer.vendor: "ballpoint"
  condition: selection

Il est également possible d'indiquer le type de menace ainsi que son niveau de sévérité.

Un autre paramètre intéressant est la sélection des champs à afficher directement dans l'alerte. Cela permet à l'analyste de voir l'information essentielle d'un coup d'œil, sans avoir à ouvrir l'événement brut. Ici, il est intéressant d'afficher :

• source.ip : l'adresse IP de l'attaquant, à l'origine de l'interaction avec le honeypot.
• destination.ip : l'adresse IP du honeypot Trapster ciblé.
• destination.port : le port visé par l'attaquant (par exemple 21 pour FTP, ou 443 pour un honeytoken web).
• ballpoint.trapster.channel : le type d'interaction détecté par Trapster (ftp, http, honeytoken, portscan...).
• ballpoint.trapster.extra : des informations complémentaires liées à l'interaction, comme les identifiants utilisés lors d'une tentative de connexion.
• host.name : le nom du honeypot précis qui a été touché, utile si plusieurs leurres sont déployés.

Pour cette règle catch-all, il est recommandé de définir la stratégie de similarité sur les champs source.ip et destination.ip. L'objectif est de regrouper toutes les interactions provenant d'un même attaquant sur un même honeypot en une seule alerte, plutôt que d'en générer une nouvelle à chaque événement, ce qui évite de noyer l'analyste sous des alertes redondantes. L'ajout de destination.ip permet en outre de distinguer un attaquant qui scanne plusieurs honeypots à la fois (une alerte par honeypot touché) d'un attaquant qui s'acharne sur un seul leurre.

La règle est maintenant prête à être testée, mais avant cela, voici différents exemples de règles intéressantes pour Trapster :

Règle 1 : interaction avec un honeytoken

name: trapster_honeytoken_triggered
detection:
  selection:
    observer.product: "trapster"
    ballpoint.trapster.channel: "honeytoken"
  condition: selection

Règle 2 : tentative de login FTP (credentials)

name: trapster_ftp_login_attempt
detection:
  selection:
    observer.product: "trapster"
    ballpoint.trapster.channel: "ftp"
    ballpoint.trapster.category: "login"
  condition: selection

Règle 3 : scan de ports (nmap) ou requête HTTP

name: trapster_scan_or_http_probe
detection:
  selection:
    observer.product: "trapster"
    ballpoint.trapster.channel:
      - "portscan"
      - "http"
  condition: selection

Vérification du fonctionnement

Après un scan Nmap réalisé sur le honeypot, l'alerte est bien remontée dans l'onglet Alerts, ainsi que dans le dashboard.

Elle est également comptabilisée dans le dashboard :

Construction d'un playbook

Enfin, il ne reste plus qu'à automatiser la réponse grâce à la création d'un playbook, afin d'être informé immédiatement lorsqu'une alerte se produit, ou d'y réagir automatiquement.

Accéder à la création

Pour créer un playbook, il faut disposer du rôle intégré Analyst ou Admin, ou d'un rôle personnalisé disposant des permissions liées aux playbooks. Il suffit ensuite de se rendre dans la section Playbooks, puis de cliquer sur + Playbook.

Créer un playbook de zéro peut s'avérer complexe. C'est pourquoi Sekoia propose des modèles prêts à l'emploi, disponibles dans le catalogue de playbooks (en cliquant sur + Playbook, puis Use a template), qui constituent une bonne base de départ. Ici, on va utiliser un template pour des notifications Slack.

Configurer le trigger

Un exemple de trigger est le déclenchement d'une alerte dans Sekoia : il existe un trigger qui surveille les créations d'alertes. Dès qu'une nouvelle alerte est créée, tous les playbooks en attente de cet événement se déclenchent automatiquement.

Dans le template utilisé, ce trigger est déjà présent, mais il faut néanmoins le configurer : pour Trapster, il suffit de choisir un filtre sur la règle "any interaction", afin de ne déclencher le playbook que sur les alertes liées à Trapster.

Configurer l'action Send to Slack

Il faut également configurer l'action Send to Slack, afin de lui fournir l'URL du webhook Slack, qu'il faut préalablement créer sur Slack.

Une fois tout configuré, voici le résultat obtenu lors du déclenchement d'une alerte :

Pour aller plus loin

Au-delà de la notification, d'autres actions peuvent être ajoutées au playbook pour automatiser davantage la réponse :

• Enrichissement de l'IP : interroger une source externe (IPInfo, Shodan, VirusTotal) sur l'adresse IP de l'attaquant, afin d'obtenir plus de contexte (réputation, géolocalisation).
• Création de ticket : ouvrir un ticket dans un outil comme Jira, ServiceNow ou TheHive, avec les détails de l'alerte.

Conclusion

En quelques étapes, Trapster est désormais pleinement intégré à Sekoia : les interactions avec les honeypots remontent automatiquement sous forme d'événements, sont converties en alertes grâce à des règles de détection sur mesure, et déclenchent une notification Slack en temps réel via un playbook. Cette chaîne complète, de la détection à la notification, permet de repérer une intrusion à très faible taux de faux positifs et d'y réagir en quelques secondes, sans intervention manuelle.

Le même exercice avec une autre plateforme est décrit dans notre article sur l'intégration de Trapster à ELK.