0Pricing
Cyber Security Academy · Leçon

Principes de la détection comme code

Traiter les détections comme des logiciels.

Principes de la détection comme code est une leçon Cyber Security Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cyber Security Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cyber Security Academy comprend 4 leçons au total.

Pourquoi la détection en tant que code

La détection en tant que code (DaC) applique la rigueur de l’ingénierie logicielle aux détections de sécurité. Au lieu que les analystes modifient manuellement les règles dans une console SIEM, les détections sont stockées dans des fichiers texte sous contrôle de version et déployées via une chaîne de traitement.

Les avantages sont concrets :

  • Modifications révisables via des demandes de fusion
  • Déploiements reproductibles entre environnements
  • Logique pouvant être testée avant d’atteindre la production
  • Historique vérifiable indiquant qui a modifié quoi et pourquoi

Une détection devient un artefact dont vous pouvez examiner les écarts, restaurer une version antérieure et analyser le fonctionnement comme celui de tout autre code.

Détections sous forme de fichiers versionnés

Chaque détection est stockée dans un fichier autonome, généralement au format YAML ou dans le langage de requête propre à un fournisseur, puis enregistrée dans un dépôt Git. L’organisation du dépôt reflète la manière dont vous structurez votre couverture.

Une structure courante sépare les règles par plateforme et par tactique :

detections/
  windows/
    credential_access/
      lsass_memory_dump.yml
    execution/
      suspicious_powershell.yml
  cloud/
    aws/
      root_account_usage.yml
tests/
  windows/
    lsass_memory_dump_test.yml

Revue des demandes de fusion

Toute détection nouvelle ou modifiée passe par une demande de fusion. Un deuxième ingénieur examine la logique, le risque de faux positifs et la correspondance ATT&CK avant sa fusion.

Les réviseurs se demandent :

  • La logique correspond-elle à la menace décrite ?
  • Quelle activité légitime pourrait déclencher cette détection ?
  • Le niveau de gravité et la référence ATT&CK sont-ils corrects ?
  • Des tests couvrent-ils les vrais et les faux positifs ?

Cela permet de détecter des erreurs qu’un analyste travaillant seul à modifier le SIEM à deux heures du matin ne verrait pas.

Validation de l’intégration continue

Une chaîne de traitement d’intégration continue s’exécute automatiquement à chaque envoi. Elle impose des contrôles qualité avant qu’une règle puisse être fusionnée.

Étapes typiques d’intégration continue pour un dépôt fondé sur Sigma :

# .github/workflows/validate.yml (excerpt)
steps:
  - name: Lint Sigma syntax
    run: sigma check ./detections
  - name: Validate against schema
    run: sigma check --validators all ./detections
  - name: Run unit tests
    run: pytest tests/

Déploiement automatisé

Une fois la fusion effectuée, une tâche de déploiement convertit les règles portables dans le langage de requête cible et les transmet au SIEM ou à l’EDR au moyen d’une interface de programmation.

Pour Sigma, vous exécutez généralement un convertisseur tel que sigma convert avec un moteur cible correspondant à votre plateforme (Splunk, Elastic, Microsoft Sentinel). La chaîne de traitement charge ensuite les recherches enregistrées ou les règles analytiques générées.

Aucun humain ne colle de requêtes dans une console. L’état déployé correspond toujours au contenu de main.

sigma convert -t splunk -p splunk_windows \
  detections/windows/execution/suspicious_powershell.yml

Tester les détections

Une détection sans tests relève de la conjecture. La DaC associe à chaque règle des données de test : des échantillons de journaux qui devraient la déclencher (vrais positifs) et des échantillons inoffensifs qui ne devraient pas la déclencher (faux positifs).

Les tests s’exécutent dans l’intégration continue ; une modification qui réduit la couverture ou réintroduit du bruit échoue lors de la compilation avant la fusion. C’est la principale source de confiance lors de la restructuration de règles à grande échelle.

test:
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 javascript:...' }
    expected: match
  - log: { Image: 'C:\\Windows\\System32\\rundll32.exe', CommandLine: 'rundll32 shell32.dll,Control_RunDLL' }
    expected: no_match

Métadonnées et cycle de vie des règles

Traitez les métadonnées comme un élément à part entière. Chaque détection enregistre son statut à mesure qu’elle évolue au cours de son cycle de vie :

  • experimental — nouvellement écrite, surveillée attentivement
  • test — en cours d’exécution, mais pas encore approuvée pour générer des alertes
  • stable — éprouvée, avec un faible taux de faux positifs
  • deprecated — remplacée ou retirée

Le suivi du statut dans le fichier vous permet de promouvoir, rétrograder et retirer les règles délibérément, plutôt que de laisser une logique obsolète persister en production.

Portabilité entre les moteurs cibles

L’un des principaux avantages de la DaC consiste à écrire la logique de détection une seule fois dans un format indépendant du fournisseur, puis à la compiler vers plusieurs moteurs cibles. Sigma est le standard de fait pour les détections fondées sur les journaux.

Le même fichier de règle peut cibler Splunk SPL, Elastic Lucene/EQL, Microsoft Sentinel KQL et d’autres plateformes grâce à des correspondances de champs propres à chaque chaîne de traitement. Vous évitez de réécrire cinq fois la même idée et vous évitez la dépendance à un fournisseur.

sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml
sigma convert -t splunk rule.yml

Chaînes de traitement de correspondance des champs

Les différentes sources de journaux nomment différemment les mêmes données. Un événement de création de processus de Sysmon utilise Image ; un journal de sécurité Windows peut utiliser NewProcessName. Les chaînes de traitement comblent cet écart.

Les chaînes de traitement transforment les noms de champs génériques de Sigma en champs précis utilisés par vos données, de sorte qu’une règle logique s’applique proprement à tout schéma ingéré par votre SIEM. La gestion centralisée des chaînes de traitement permet de corriger une modification de schéma une seule fois, plutôt que dans chaque règle.

sigma convert -t splunk -p sysmon rule.yml

Environnements et promotion

Comme le code applicatif, les détections passent par plusieurs environnements avant d’atteindre la production. Un flux courant va du développement à la préproduction, puis à la production.

  • Développement — rédigez les règles et exécutez les tests unitaires dans l’intégration continue
  • Préproduction — déployez sur une copie de la télémétrie réelle en mode audit
  • Production — promouvez la règle lorsque le taux de faux positifs est acceptable

La promotion est une étape volontaire et revue, liée au statut du cycle de vie de la règle, et non le résultat accidentel d’une fusion. Ce déploiement progressif reprend la discipline « alerter puis bloquer » utilisée pour les détections en ligne.

Couverture et métriques

Comme les détections sont du code, vous pouvez mesurer la couverture par programmation. Associez chaque règle aux techniques MITRE ATT&CK et générez une carte thermique de ce que vous couvrez ou non.

Métriques utiles à suivre au fil du temps :

  • Techniques couvertes par rapport au total de votre modèle de menace
  • Taux de faux positifs par règle
  • Temps moyen entre l’idée d’une règle et sa mise en production
  • Nombre de règles dans chaque état du cycle de vie

Ces chiffres font passer l’ingénierie de la détection de l’anecdote à un programme géré.

Vérification rapide

Testez votre compréhension des fondamentaux de la détection en tant que code.

Récapitulatif

La détection en tant que code apporte la rigueur de l’ingénierie logicielle aux détections :

  • Les règles résident dans des fichiers versionnés sous Git
  • Les modifications passent par un examen des demandes de modification
  • L’intégration continue effectue une analyse statique, valide et exécute automatiquement les tests
  • Les règles fusionnées sont déployées via une chaîne de traitement, ce qui maintient la production synchronisée avec la branche principale
  • Les tests protègent contre les faux positifs et les régressions
  • La portabilité (Sigma et chaînes de traitement) permet à une même règle de cibler plusieurs systèmes dorsaux
  • Les métadonnées, le cycle de vie et les métriques transforment la détection en un programme géré

Ensuite, vous écrirez les règles portables elles-mêmes avec Sigma.

Questions Fréquemment Posées

La leçon « Principes de la détection comme code » est-elle gratuite ?

Oui — le texte complet de « Principes de la détection comme code » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cyber Security Academy, passe à CoddyKit PRO. Le cours Cyber Security Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Principes de la détection comme code » ?

Traiter les détections comme des logiciels. Tu pratiques Cyber Security Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cyber Security Academy ?

Aucune expérience préalable n'est requise. Cyber Security Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « Principes de la détection comme code » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cyber Security Academy ?

Oui. Chaque leçon Cyber Security Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Principes de la détection comme code
  2. Écrire des règles Sigma
  3. Cartographier avec MITRE ATT&CK
  4. Tester et régler les détections
← Retour à Cyber Security Academy