SekoiaCraft

SekoiaCraft est un générateur de logs de sécurité multi-tenant. Il simule le comportement réaliste d'utilisateurs fictifs sur des technologies de cybersécurité (CrowdStrike, Microsoft Defender, Palo Alto NGFW…) et envoie les logs vers des webhooks configurables.

L'idée dont tout découle

La journée d'un utilisateur simulé se décrit une fois, sans nommer une seule technologie : un workflow de gestes abstraits — arriver au bureau, naviguer, ouvrir un document, se connecter à un serveur. Chaque geste est ensuite projeté vers toutes les technologies retenues qui savent le décrire, avec le même instant, la même entité et les mêmes faits.

C'est ce qui rend la sortie corrélable : une même ouverture de session apparaît à la même seconde dans l'EDR, dans le journal Windows et dans la console d'identité, et une même navigation nomme le même hôte chez le proxy, le pare-feu et le résolveur DNS. Aucun générateur de bruit ne donne cela quand chaque technologie tire sa destination dans son coin.

Ce qui fonctionne aujourd'hui

Treize écrans, rangés ici comme l'est cette documentation :

Écran	Ce qu'on y fait
/	État de santé des cinq backends et de leurs dépendances, en temps réel
/essais	Rejouer la journée d'un archétype vers de vraies intakes — aperçu, puis envoi
/journal	Le relevé des essais lancés, par banc, entreprise ciblée, archétype et utilisateur simulé
/communautes	Faire vivre une population toute seule, minute après minute
/pools	Donner exactement le même contenu à plusieurs équipes — une communauté par équipe, chacune vers ses intakes
/envois	Tout ce qui a été posté vers un intake : issue, origine, durée et les messages eux-mêmes
/envois/file	Ce qui attend d'être posté — déplier, rejouer, retirer, suspendre
/inventaires	Chaque exécution d'un connecteur d'assets, et ce qu'elle a construit et posté — conservé 24 h
/generators	Créer une technologie source, ses messages types et leurs templates
/archetypes	Décrire un type d'utilisateur simulé et le workflow de sa journée
/datasets	Éditer les données de référence : pools d'échantillons et populations fictives
/configuration	Les réglages qui valent pour toute l'installation — la clé du feed d'indicateurs et le feed CVE
/utilisateurs	Les comptes et les rôles, décrits dans Sécurité et comptes

Deux d'entre eux n'ont pas encore de page à eux — le dashboard et /journal. Ce tableau est, pour l'instant, toute la documentation qu'ils ont.

Le corpus de l'ancien projet s'importe par un script : 28 technologies, leurs 470 messages types, leurs templates, 383 pools d'échantillons et six populations de démonstration. Là où le corpus est absent — la CI, les environnements déployés, un poste sans Python —, la base reçoit les mêmes données par l'instantané SQL versionné dans le dépôt.

Une communauté peut aussi porter du bruit de fond pirate : des scénarios de la bibliothèque des menaces greffés sur quelques hôtes compromis, qui continuent leur journée de travail pendant qu'une balise, un téléchargement de charge et une exfiltration s'y ajoutent — en nommant tous le même indicateur de compromission, quelle que soit la technologie qui les observe.

Chaque jour, une communauté envoie aussi à son espace Sekoia un inventaire d'assets OCSF : ses postes et serveurs, ses utilisateurs, leurs vulnérabilités et leurs logiciels. C'est la projection de la population même que ses journaux nomment — un analyste qui passe d'une alerte à l'asset retrouve la même machine.

Ce qui n'existe pas encore

• La couche ambiante et les alertes. Un banc et une communauté ne jouent que la couche corrélée — les gestes du workflow. Le trafic propre à chaque technologie, et les alertes que son moteur de détection lève, viendront avec les étapes qui les produisent ; les volumes d'une production réelle seraient plus élevés.
• Les familles d'alertes du projet d'origine — Elevate, Sigma, POI. Un scénario de menace lancé à la demande joue des gestes d'attaquant, pas ces jeux de règles.
• La simulation de l'activité SOC — assignation de cas, changements de statut, commentaires de clôture.

Architecture

Le tableau dit ce que chaque service fait aujourd'hui, pas ce qu'il fera :

Service	Port	Rôle
web	3000	Dashboard, éditeur de configuration et écrans (React Router)
api-config	3001	CRUD de la configuration : communautés, générateurs, archétypes, datasets, comptes
api-activity	3002	Ordonnanceur par minute, essais, historique et file d'envoi, flux temps réel
api-scenario	3003	Le feed d'indicateurs de compromission ; le lancement à la volée des scénarios
api-sender	3004	Consomme la file d'envoi et poste vers les intakes
docs	3005	Cette documentation
api-asset	3006	Inventaire OCSF quotidien de chaque communauté, envoyé à Sekoia ; CVE depuis NVD

Les backends ne communiquent jamais entre eux en HTTP : ils partagent PostgreSQL (via packages/database) et Redis (files BullMQ). Seul le web est un client HTTP — ses loaders appellent api-config, et ses compteurs temps réel viennent des flux SSE que relaie api-activity.

Démarrer en local

Cinq commandes, du dépôt cloné à l'application qui tourne :

pnpm install     # dépendances + client Prisma
pnpm docker:up   # PostgreSQL, Redis, pgAdmin
pnpm db:push     # le schéma en base
pnpm db:seed     # les données de référence
pnpm dev         # les 7 services

Les prérequis, le .env et ce que fait chaque commande sont détaillés dans Démarrer en local. L'API de configuration expose son Swagger sur http://localhost:3001/api.