Vos règles de détection, mappées à NIS2 et ReCyF

Acheter des règles de détection et acheter une réponse conformité ont toujours été deux achats séparés. Un feed SIEM vous dit ce qu'il détecte, mappé à MITRE ATT&CK. Un GRC suit vos contrôles, sur le papier. Personne ne relie les deux : lesquelles de vos règles de détection fournissent réellement une preuve pour une exigence réglementaire donnée, et où sont les trous.

C'est ce qu'on vient de livrer. Chaque abonnement feed ThreatClaw inclut désormais une couche conformité, bundlée sans surcoût.

Ce que vous obtenez

Pour chaque exigence de NIS2 (la table technique ENISA) et de ReCyF (le Référentiel Cyber France publié par l'ANSSI), le bundle vous indique :

• lesquelles de vos règles la couvrent, typées par pack (détections, policy-as-code),
• les trous : les exigences qu'aucune règle ne traite, y compris celles qui sont purement organisationnelles et ne peuvent pas être couvertes par une règle,
• un rapport audit-ready (HTML) et un export OSCAL machine-readable pour vos autres outils,
• une couche ATT&CK Navigator qui montre visuellement votre couverture de détection.

Comment le mapping est construit

Le lien est traçable de bout en bout, et chaque étape s'appuie sur une source publique et redistribuable :

règle Sigma vers technique ATT&CK vers contrôle NIST 800-53 (MITRE CTID) vers sous-catégorie CSF 2.0 (NIST OLIR) vers exigence NIS2 (ENISA).

Vos règles Sigma sont déjà taggées ATT&CK. MITRE publie le mapping ATT&CK vers 800-53. NIST publie les références 800-53 vers CSF 2.0. ENISA publie la table NIS2 vers CSF 2.0. On ne fait que joindre ce qui existe déjà, avec des identifiants de contrôles, jamais le texte protégé des normes. Pour les cadres français (ReCyF, SecNumCloud, HDS), on projette via les libraries intuitem CISO Assistant, identifiants seulement.

Importez-le dans votre GRC

Si vous utilisez un GRC comme CISO Assistant, un connecteur crée ou met à jour votre audit et, pour chaque exigence couverte, 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. Cette distinction compte : notre couche prouve la conception (il existe une règle qui traite l'exigence), pas l'efficacité opérationnelle dans votre environnement dans le temps, et encore moins une certification.

Ce qu'il ne fait pas, honnêtement

On préfère perdre la vente que sur-promettre, parce qu'un auditeur le voit tout de suite.

• Ce n'est pas une certification ni une conformité automatique. La conformité est un processus organisationnel qui appartient à votre RSSI.
• La couverture est partielle par nature. Beaucoup d'exigences sont organisationnelles (gouvernance, formation, contrats fournisseurs) et aucune règle technique ne peut les couvrir. On les affiche en gaps.
• Pour DORA, il n'existe pas de table de correspondance officielle de l'UE : on cadre étroit et on l'affiche comme non-officiel. On adosse les articles que nos règles supportent directement (détection, tests de résilience), et notre pack red-team soutient l'article TLPT sans être la prestation TLPT certifiée.

Pourquoi c'est bundlé, pas un produit à part

Une carte de couverture n'a de valeur que si vous avez les règles qu'elle mappe. La couche conformité est donc livrée avec votre abonnement feed, scopée aux packs que vous prenez réellement : un abonné Sigma seul voit exactement ce que le feed Sigma couvre, et ce que le pack policy ajouterait. Ça rend les feeds plus utiles, ce n'est pas un produit qu'on achète tout seul.

Déjà abonné ? Le bundle conformité arrive à votre prochaine synchronisation. Nouveau ici ? Commencez par le pack de démo gratuit et jugez la couverture par vous-même.