Question 1

Un agent IA qui touche à mon infra, c'est pas dangereux ?

Accepted Answer

C'est la bonne question à poser. ThreatClaw a été conçu autour de cette contrainte : plusieurs couches de défense sont compilées directement dans le binaire, non configurables, non contournables, non désactivables après déploiement. En mode par défaut, l'agent observe et propose : il n'agit jamais sans approbation humaine explicite (HITL via Slack/Telegram/email/Signal). Le code est open source sous AGPL v3, donc vous pouvez auditer chaque ligne avant de déployer.

Question 2

Et si le LLM hallucine ou propose une action absurde ?

Accepted Answer

L'IA ne peut jamais déclencher d'action toute seule. Chaque action proposée passe par un filtre statique compilé dans le binaire, qui ne reconnaît que des opérations connues, réversibles, avec une cible validée. Une suggestion qui ne correspond à aucune action prévue est rejetée avant exécution. En mode par défaut, l'opérateur reçoit la proposition complète (analyse + indicateurs + impact prévu) et valide d'un clic dans le chat ou refuse.

Question 3

IA locale ou IA cloud, laquelle choisir ?

Accepted Answer

Notre recommandation par défaut est l'IA locale (LLM via Ollama sur votre serveur) : 100 % de vos données restent chez vous, zéro fuite possible. L'IA cloud peut être ajoutée comme second avis sur les cas complexes ou ambigus, dans ce cas, toutes les données sensibles sont substituées automatiquement par des tokens réversibles avant l'envoi. Le LLM cloud ne voit jamais d'identifiant, d'IP, ou de credential. Le mapping de restitution vit en mémoire uniquement, jamais sur disque.

Question 4

Comment l'anonymisation fonctionne et que se passe-t-il si elle rate quelque chose ?

Accepted Answer

Avant tout appel à un LLM externe, les données passent par un anonymiseur écrit en Rust qui détecte automatiquement les identifiants sensibles courants (techniques, financiers, personnels) et les remplace par des tokens réversibles. À la réception de la réponse, les tokens sont restaurés en local. Le mapping vit en mémoire uniquement.

Le risque résiduel de tout anonymiseur basé sur des patterns existe, et nous le reconnaissons. Trois mitigations : (1) vous pouvez enrichir la couverture avec vos propres règles spécifiques à votre métier (noms de projets internes, conventions de nommage), (2) l'option par défaut reste l'IA souveraine locale qui ne sort aucune donnée du serveur, (3) le code de l'anonymiseur est open source AGPL, vous pouvez auditer ce qu'il sait détecter et le compléter si besoin.

Question 5

Concrètement, que fait ThreatClaw ?

Accepted Answer

ThreatClaw est un agent autonome de cybersécurité qui tourne en continu sur votre infrastructure. Il ingère les sources de signal disponibles (logs syslog, alertes IDS, événements SIEM, scans, CTI), corrèle les événements via plusieurs couches de détection, et produit pour chaque incident un dossier complet : verdict avec niveau de confiance, indicateurs de compromission, périmètre touché, et 1 à 3 actions correctives prêtes à exécuter. Selon le mode choisi : il vous notifie et vous validez (HITL), ou il exécute directement les actions à faible risque (autonome).

Question 6

Quelles actions peut-il exécuter sur mon système ?

Accepted Answer

Toutes les actions possibles sont définies dans le code source open source, aucun shell arbitraire, aucune commande dynamique. Globalement : isoler un endpoint compromis, bloquer une IP au pare-feu, verrouiller un compte utilisateur suspect, mettre en quarantaine un fichier malveillant, arrêter un container Docker, capturer une preuve forensique. Chaque action est tracée dans un audit-log signé cryptographiquement, et toute action destructive nécessite une approbation humaine en mode par défaut.

Question 7

Quelles sources d'observation ThreatClaw peut-il consommer ?

Accepted Answer

Plus de 19 sources de signal sont supportées en natif : SIEM (Wazuh, FortiGate, OPNsense), pare-feu d'entreprise, agents EDR (Velociraptor), logs serveurs Linux/Windows via syslog, scans de vulnérabilités, threat intelligence (CrowdSec), alertes IDS/IPS, et tout équipement parlant le protocole syslog standard. Une PME typique génère 4 500 alertes/jour de bruit ; ThreatClaw consolide tout ça en quelques incidents qualifiés et actionnables.

Question 8

Comment je collecte mes logs ?

Accepted Answer

ThreatClaw inclut un collecteur syslog intégré qui écoute sur le port standard 514. Vous pointez vos serveurs Linux (auth.log, syslog), Windows (Event Log via syslog), pare-feu et conteneurs Docker vers cet endpoint. Les logs sont stockés en PostgreSQL local et passent par les couches de détection (règles Sigma, IDS, ML) qui génèrent des alertes priorisées. Pas de SaaS log management externe nécessaire, tout reste sur votre serveur.

Question 9

Pourquoi avoir choisi Rust pour le cœur de l'agent ?

Accepted Answer

Un agent de sécurité s'exécute avec des privilèges élevés sur l'infrastructure du client. S'il a lui-même des vulnérabilités mémoire, c'est un cauchemar. Rust élimine à la compilation les classes de bugs les plus exploitées (buffer overflow, use-after-free, race conditions, déréférencement de pointeur null). C'est un prérequis non négociable, pas un choix esthétique.

Question 10

ThreatClaw est-il conforme NIS2 / RGPD / ISO 27001 ?

Accepted Answer

Réponse honnête : la conformité est un processus organisationnel qui dépend de votre contexte, pas une case à cocher dans un outil. Ce que ThreatClaw apporte concrètement : audit-trail cryptographique opposable, 11 rapports réglementaires pré-remplis (NIS2, RGPD, ISO 27001, EU AI Act, ISO 42001, NIST AI RMF, NIST CSF 2.0, EU CRA, SOC 2, HDS, PCI-DSS), rétention de données configurable par table, anonymisation des données personnelles avant tout envoi cloud. L'outil documente votre démarche, il ne la remplace pas.

Question 11

Que se passe-t-il si l'agent lui-même est compromis ?

Accepted Answer

C'est exactement le scénario contre lequel les couches de défense compilées dans le binaire sont conçues. Sans entrer dans le détail (un agent défensif ne donne pas la map de ses défenses publiquement, politique anti-evasion), globalement : intégrité du binaire vérifiée au démarrage et refus de démarrer si modifié, surface d'action limitée à des opérations connues à compile-time qu'un attaquant ne peut pas étendre, audit-trail signé pour reconstituer après coup, mécanisme d'arrêt automatique sur comportement suspect. Le code source AGPL v3 reste accessible si vous voulez auditer le détail.

Question 12

Combien de CVEs dans ThreatClaw ?

Accepted Answer

Politique : zéro CVE critique tolérée dans le binaire de release. Le binaire est analysé par cargo audit dans la CI à chaque build, et le SBOM (software bill of materials) est publié à chaque tag de release. Toute CVE remontée ouvre un ticket public sur GitHub avec patch sous 72 heures pour les CVE critiques. Vous pouvez vérifier vous-même l'état du binaire en récupérant le SBOM et en le faisant scanner par votre outil habituel (Trivy, Grype, etc.).

Question 13

De quoi ai-je besoin pour déployer ThreatClaw ?

Accepted Answer

Un serveur Linux avec Docker installé. Minimum 8 Go de RAM (16 Go recommandés si vous activez le LLM local). 20 Go de disque (50 Go avec les modèles IA téléchargés). Une commande d'installation : `curl -fsSL https://get.threatclaw.io | sudo bash`. Un wizard d'onboarding configure ensuite l'IA, les canaux de communication, le niveau d'autonomie et les sources de logs. Compter 30 minutes pour un premier déploiement fonctionnel.

Question 14

ThreatClaw est-il vraiment gratuit ?

Accepted Answer

Le code est open source sous licence AGPL v3, gratuit et auditable sur GitHub (toutes les fonctionnalités sont identiques sur tous les tiers. Le tier Free permet de monitorer un nombre limité d'assets (idéal TPE / petite PME / labs). Pour les parcs plus grands, les tiers payants Starter / Pro / Business débloquent des plafonds plus élevés. Voir la page Tarifs pour les détails. L'accompagnement humain (déploiement, calibration, formation RSSI) est proposé séparément par CyberConsulting.fr) c'est le métier qui finance le développement de l'outil.

Question 15

Puis-je superviser plusieurs serveurs / sites ?

Accepted Answer

Oui. Vous définissez chaque cible dans la configuration avec un mode (HITL par défaut / autonome) et un type d'accès (SSH, WinRM, API exposée, ou agent local sur la cible). L'instance ThreatClaw centralise les analyses et exécute les actions approuvées sur la bonne cible. Pour les multi-sites, une architecture en collecteurs régionaux + agrégateur central est supportée.

Question 16

Comment je suis alerté en cas d'incident ?

Accepted Answer

Via les canaux que vous configurez : email, Slack, Telegram, Discord, Signal, ou webhook custom vers votre outil interne. En mode HITL, l'approbation se fait directement dans le chat (avec nonce anti-replay pour empêcher la réutilisation d'une approbation passée). Un dashboard web temps réel est aussi disponible pour la vue centralisée et les rapports de conformité.

Question 17

C'est quoi les packs de règles ThreatClaw ?

Accepted Answer

Un abonnement à des packs de règles de détection prêtes à l'emploi, mis à jour en continu et signés. Ils couvrent 8 moteurs, Sigma (SIEM/EDR), YARA (fichiers/mémoire), NIDS Suricata (réseau), Falco (conteneur/cloud), Nuclei (vulnérabilités), OPA (conformité IaC), osquery et Velociraptor (DFIR), plus des feeds IOC et LLM red-team. Chaque règle est livrée avec son playbook d'investigation. Catalogue complet : plus de 6 400 règles Sigma et 12 000 règles YARA.

Question 18

Ce ne sont pas juste des règles open source repackagées ?

Accepted Answer

Non. Nous forgeons nos propres règles maison (familles de malware, outils offensifs, LOLBins, drivers vulnérables, typosquatting de marque…) que vous ne trouverez nulle part ailleurs. Pour les sources communautaires que nous intégrons, nous les curons vraiment : licence vérifiée par fichier, déduplication, validation sur le vrai moteur (une règle qui ne compile pas ne part pas), anti-faux-positifs sur un large corpus. On ne revend pas des règles ramassées : on livre de la détection prouvée.

Question 19

Il y a un pack démo gratuit ?

Accepted Answer

Oui. Un échantillon gratuit de nos règles maison sur tous les moteurs que nous couvrons (Sigma, YARA, osquery, Velociraptor, Falco, réseau, policy), chaque détection avec son playbook d'investigation au standard CACAO 2.0. Les règles Sigma arrivent déjà converties pour 6 SIEM (Splunk, Sentinel, Elastic, QRadar, CrowdStrike, Panther), et un échantillon de conformité NIS2 est inclus. Téléchargeable directement depuis le menu « Règles » ou les pages feed, sans inscription.

Question 20

Les règles Sigma sont-elles converties pour mon SIEM ?

Accepted Answer

Oui. Chaque règle Sigma est livrée déjà convertie pour Splunk (SPL), Microsoft Sentinel (KQL), Elastic (Lucene), QRadar (AQL), CrowdStrike (LogScale) et Panther (SDYAML), à coller directement dans votre SIEM. Quand une règle ne se mappe pas proprement sur un SIEM (champ absent de son schéma), nous livrons ce qui se convertit réellement plutôt qu'une requête cassée.

Question 21

C'est quoi un « playbook d'investigation » ?

Accepted Answer

Pour chaque règle, une fiche pas-à-pas que l'analyste suit quand la règle se déclenche : confirmer l'alerte, trouver l'origine, mesurer la portée, pistes de remédiation. Au format standard CACAO 2.0 (OASIS), importable dans votre SOAR. Généré de façon déterministe, sans IA : chaque étape dérive d'un fait porté par la règle (ATT&CK, faux positifs connus, référentiel MITRE D3FEND), rien n'est inventé, et le playbook est en lecture seule (jamais de commande exécutable, la réponse reste une décision humaine).

Question 22

À quelle fréquence les packs sont-ils mis à jour ?

Accepted Answer

En continu. Les packs sont reconstruits et publiés quotidiennement ; votre script de synchronisation récupère la nouvelle version à son prochain passage. Chaque publication est signée (Ed25519) et passe une porte anti-empoisonnement qui refuse les changements suspects (retrait massif de détections, capacité dangereuse apparaissant sans revue).

Question 23

Puis-je utiliser les règles sans l'agent ThreatClaw ?

Accepted Answer

Oui. L'abonnement aux règles est découplé de l'agent : c'est un feed autonome que vous branchez sur votre propre stack (SIEM, moteur YARA, Suricata, osquery, etc.). L'agent ThreatClaw sait les consommer nativement, mais ce n'est pas requis.

Question 24

Vous agrégez plusieurs sources : comment gérez-vous les doublons ?

Accepted Answer

Par comparaison de similarité entre règles, pas par simple égalité de nom ou de hachage, ce qui laisserait passer les variantes. Les quasi-doublons sont retirés du pack livré, et la zone grise, celle des règles proches sans être identiques, est mise de côté pour revue humaine plutôt que livrée par défaut. C’est une part invisible du travail et pourtant la première raison pour laquelle un agrégat brut est inutilisable en production.

Question 25

Dans quel format arrivent les packs ?

Accepted Answer

Dans le format natif du moteur concerné, prêt à charger : rien à convertir de votre côté. S’y ajoutent un index qui décrit chaque règle avec ses références de sécurité, et des regroupements thématiques par catégorie, par technique d’attaque ou par exigence de conformité. C’est ce qui vous permet de charger un sous-ensemble ciblé plutôt que tout le pack, et de justifier une couverture devant un auditeur.

Question 26

Comment je sais que le pack n’a pas été altéré en route ?

Accepted Answer

Chaque publication est signée en Ed25519, et votre script de synchronisation vérifie le sceau avant toute extraction : sans sceau vérifiable, il refuse et s’arrête, il n’existe pas de repli. Le point qui compte est où vit la clé privée : jamais sur la machine d’intégration continue, celle qui télécharge du contenu tiers et fait tourner des moteurs dessus. Elle ne quitte pas notre propre machine. La règle est simple : celle qui ingère du contenu non fiable ne détient jamais la clé.

Question 27

Qu’est-ce qui empêche quelqu’un d’affaiblir une règle en amont ?

Accepted Answer

C’est le vrai modèle de menace sur un feed de détection, et ce n’est pas le malware : personne n’a besoin d’exécuter du code, il suffit d’ajouter une exclusion ou de casser une condition pour aveugler tous les abonnés d’un coup, silencieusement. Deux garde-fous. Les sources sont épinglées à une version précise, donc prendre une évolution amont est un acte délibéré et pas une conséquence du temps qui passe. Et chaque publication passe une porte de comparaison avec la précédente : un écart anormal met la version en quarantaine et le flux que vous recevez reste inchangé.

Question 28

Y a-t-il du code exécutable dans vos packs ?

Accepted Answer

Non, jamais. Un pack ne contient que du texte : des règles, du YAML, du JSON, du SQL. Le scénario où vous téléchargez et exécutez un binaire piégé n’existe pas chez nous. Pour le pack de templates de vulnérabilité, un filtre supplémentaire écarte tout ce qui pourrait agir plutôt qu’observer, ainsi que les catégories intrusives et de déni de service.

Question 29

Comment vous évitez qu’une règle noie mon SOC de faux positifs ?

Accepted Answer

Deux étages. À la construction, chaque règle doit compiler sur le moteur réel que vous faites tourner, pas sur un analyseur syntaxique, et ce contrôle est bloquant : ce qui ne passe pas ne part pas. Ensuite, le pack entier est audité contre un corpus d’activité légitime réelle, pas synthétique, et les règles qui s’y déclenchent sont écartées ou passées en observation. Nous ne prétendons pas au zéro faux positif dans votre environnement, qui n’est pas le nôtre : nous garantissons qu’une règle bruyante sur du trafic normal ne vous est pas livrée sans avoir été vue.

Question 30

Comment c'est licencié et facturé ?

Accepted Answer

L'abonnement au feed de règles est distinct de la licence de l'agent (open source AGPL v3). Une partie des règles maison est propriétaire (non redistribuable) ; les sources communautaires gardent leur licence d'origine, vérifiée par fichier et documentée. Pour les tarifs de l'abonnement, voir la page Tarifs ou nous contacter.

Question 31

Vos feeds de détection sont-ils mappés aux exigences réglementaires (NIS2, ReCyF) ?

Accepted Answer

Oui. Chaque abonnement feed est livré avec une carte de couverture par exigence : pour chaque exigence NIS2 (annexe ENISA) et ReCyF, on indique quelles de vos règles la traitent, plus la liste des trous. La chaîne est traçable et publique (Sigma vers ATT&CK vers NIST 800-53 vers CSF 2.0 vers NIS2). C'est une couverture de conception, elle atteste que le catalogue traite l'exigence, ce n'est ni une certification ni une mesure temps réel. Beaucoup d'exigences sont purement organisationnelles et ne sont pas couvrables par des règles : on les affiche honnêtement en gaps. La carte est fournie en rapport lisible et au format OSCAL (standard machine-readable).

Question 32

J'utilise un GRC (CISO Assistant, etc.). Puis-je y importer votre couverture ?

Accepted Answer

Oui, via un connecteur. Il crée ou met à jour votre audit dans le GRC et, pour chaque exigence que vos règles couvrent, y attache une preuve et un contrôle ThreatClaw, puis passe l'exigence en statut « à valider ». Vous, ou votre RSSI, validez et posez le « conforme » final : le connecteur ne coche jamais votre conformité tout seul, il vous fait gagner le pré-remplissage. Nous fournissons aussi une library de correspondance chargeable et l'export OSCAL pour les autres outils. Note technique : CISO Assistant n'ingère pas l'OSCAL, notre connecteur passe donc par son API REST.

Question 33

Couvrez-vous DORA ?

Accepted Answer

Partiellement, et nous le disons franchement. Contrairement à NIS2, il n'existe pas de table de correspondance DORA officielle de l'UE. Nous adossons donc nos règles aux articles DORA qu'elles supportent directement : détection (art. 8, 10), protection (art. 9), tests de résilience (art. 24 à 27). Notre pack red-team est un outil de test qui soutient l'article TLPT, ce n'est pas la prestation TLPT certifiée à périmètre validé par l'autorité. La correspondance vers ISO ou NIST passe par un référentiel tiers reconnu (SCF), cité comme tel. Nous ne revendiquons pas la gouvernance, le reporting d'incidents, la gestion des tiers ni la continuité.

Question 34

Puis-je déployer vos règles chez mes clients ?

Accepted Answer

Oui pour la part agrégée, qui provient exclusivement de sources sous licence permissive et reste redistribuable, y compris en MSSP. Les composants sous licence copyleft sont isolés dans leur propre bundle, sous leur licence, avec l’attribution. Nos règles forgées en interne, elles, sont sous licence propriétaire et réservées à votre usage d’abonné : elles ne se redistribuent pas. Chaque pack embarque un fichier NOTICE qui détaille exactement ce qui relève de quoi.

Question 35

Que se passe-t-il si j’arrête mon abonnement ?

Accepted Answer

Vous gardez ce que vous avez déjà téléchargé, nous ne désactivons rien à distance. Ce que vous perdez, c’est le flux : plus de nouvelles règles, plus de corrections de faux positifs, plus de couverture des menaces qui apparaissent après votre départ. C’est le point important à comprendre sur ce produit : la valeur n’est pas dans le paquet du jour, elle est dans le fait qu’il change chaque semaine.

Vos questions. Nos réponses honnêtes.

L'IA et vos données