Comment le Centre canadien pour la cybersécurité a utilisé l’IA de pointe pour accélérer l’ingénierie des détections

Survol des exemples et extraits de code

Aperçu : Fonctionnement du pipeline de détection alimenté par l’IA

Le Centre pour la cybersécurité a mis à profit des modèles d’IA de pointe afin de concevoir un pipeline automatisé d’ingénierie des détections de bout en bout capable de transformer le renseignement sur les menaces accessible au public en règles de détection validées et prêtes à être déployées en production, avec un minimum d’intervention humaine. Le projet pilote reposait sur plusieurs agents aux fonctions distinctes.

Opus 4.8 s’est vu confier le rôle de l’équipe bleue consistant à générer la logique de détection conformément aux exigences opérationnelles.

Mythos s’est vu confier le rôle d’équipe rouge consistant à examiner du point de vue d’un adversaire la logique de détection afin de repérer d’éventuels contournements et d’en remettre en question l’efficacité.

Ensemble, ils forment une boucle itérative d’équipe pourpre produisant des mécanismes de détection validés aux fins d’examen par les analystes.

Ci-dessous se trouve le processus par étape pour le flux de travaux automatisé de l’ingénierie des détections, tel qu’il est présenté dans la figure 1 :

1. Agent – équipe bleue (Opus 4.8) : Article de recherche sur les menaces ingéré
2. Agent – équipe bleue (Opus 4.8) : Mécanisme de détection proposé
3. Agent – équipe rouge (Mythos) : L’IA génère un plan d’attaque
4. Agent – équipe rouge (Mythos) : Laboratoire déployé automatiquement
5. Agent – équipe rouge (Mythos) : Exécution du plan d’attaque
6. Agent – équipe bleue (Opus 4.8) : Analytique validée
7. Agent – équipe bleue (Opus 4.8) : Déploiement de la règle de détection en production

Figure 1 : Pipeline analytique complet de bout en bout

Pipeline analytique complet de bout en bout - Description détaillée

La figure 1 présente le flux de travaux automatisé de l’ingénierie des détections, de l’ingestion du renseignement sur les menaces à leur validation humaine et à leur déploiement en production. L’agent de l’équipe bleue, Opus 4.8, est utilisé aux étapes 1, 2, 6 et 7 pour générer et valider la logique de détection. Les étapes 3, 4 et 5 désignent l’agent de l’équipe rouge, Mythos, comme responsable de la création des scénarios d’attaque, du provisionnement d’un environnement de test et de l’exécution de variantes d’attaque. La figure 1 illustre comment les agents forment une boucle itérative d’équipe pourpre produisant des mécanismes de détection validés aux fins d’examen par les analystes.

En règle générale, les différentes étapes de développement analytique peuvent prendre de quelques heures à une semaine, selon leur complexité et le degré d’urgence. Le pipeline a réalisé le même travail en moins d’une heure, et à une échelle qui aurait été difficile à reproduire uniquement avec des analystes humains.

Scénario de test : Mise à l’essai du pipeline dans le cadre d’un scénario de menace réel

Le scénario de test suivant approfondit chacune des étapes du flux de travaux et démontre son efficacité dans un contexte opérationnel.

Article de recherche sur les menaces ingéré

Le pipeline analytique peut être amorcé à partir d’un éventail de données d’entrée. Celles-ci peuvent notamment provenir d’articles sur les menaces, de blogues, de rapports d’incident, de descriptions d’analystes ou de toute autre source de renseignement sur les menaces. Dans ce scénario de test, le pipeline a commencé par l’ingestion de renseignements publics sur les menaces provenant du référentiel GitHub: Exploitarium repository (en anglais seulement), qui regroupe des recherches sur les vulnérabilités ainsi que des preuves de concept d’exploitation. (Le Centre pour la cybersécurité n’est pas responsable du contenu du référentiel Exploitarium et ne l’approuve pas.)

Mécanisme de détection proposé

Le modèle a proposé une ou plusieurs détections potentielles, chacune accompagnée d’une description compréhensible de la logique de détection et d’une requête de chasse aux cybermenaces associée. Plusieurs de ces requêtes de chasse aux cybermenaces sont par la suite regroupées au moyen de filtres additionnels pour constituer une règle de détection.

SELECT Parent.Tag, Child.Tag, action, eventtime, hbs_agent_id
FROM events
WHERE timestamp BETWEEN '{start}' AND '{end}'
    AND hostname IN ('rtlab-ubu01', 'rtlab-web01')
    AND action IN ('PROCESS_EXEC', 'PROCESS_START')
    AND Parent.Tag RLIKE '(?i)(redis-server|php|java|ffmpeg|gogs|ladybird|objdump)'
    AND Child.Tag RLIKE '(?i)(bash|dash|sh|cmd|touch|calc)'

L’IA génère un plan d’attaque

Un plan d’attaque est généré, identifiant l’infrastructure, les logiciels et les preuves de concept nécessaires à la mise en œuvre de l’attaque. Dans ce cas, les preuves de concept nécessaires étaient déjà présentes dans le référentiel. Toutefois, lorsqu’aucune preuve de concept publique n’était disponible, Mythos essayait de générer sa propre preuve.

cd lab/ansible2-vm
ansible-playbook playbooks/scenario-exploitarium-rce-linux.yml \
    -e lab_unsafe_ack=true

cd /opt/lab/exploitarium/c-ares-tcp-uaf-calc-poc
# Build c-ares from vulnerable commit
./scripts/build_from_checkout.sh
# Run PoC (loopback DNS server + vulnerable client)
./scripts/run_until_hit.sh

Laboratoire déployé automatiquement

L’environnement lab est créé automatiquement en fonction du plan d’attaque et configuré avec la même pile de sécurité que celle utilisée dans les réseaux de production afin de recueillir une télémétrie comparable. Plusieurs variantes de l’environnement peuvent être créées afin d’assurer une couverture complète des tests.

Exécution du plan d’attaque

Le plan d’attaque est exécuté à l’aide de différentes variantes de la technique afin de valider l’efficacité de la logique de détection dans différentes conditions.

Validation analytique

La logique de détection proposée est validée à la fois au moyen de simulations générées en laboratoire et de données opérationnelles réelles, notamment la télémétrie provenant des clients. Ce processus itératif reprend les étapes précédentes, au besoin, jusqu’à ce que l’activité simulée soit détectée de manière sûre et que les faux positifs soient réduits au minimum.

Déploiement de la règle de détection en production

Les détections obtenues sont ensuite converties dans les formats exigés par les processus d’ingénierie analytique. Cela comprend des implémentations Sigma pour les détections relativement simples ainsi que des implémentations Python pour les analyses plus complexes, de même que les filtres nécessaires, la logique de réglage et la documentation connexe. Ces artéfacts sont soumis à l’examen des analystes sous la forme d’un dossier détaillé comprenant les preuves justificatives, les résultats de validation et les détails de mise en œuvre à l’appui des analyses finales.

# UNCLASSIFIED / NON CLASSIFIÉ // TLP:CLEAR
title: SSH Client Process Spawns Shell Interpreter
name: SSH_Client_Process_Spawns_Shell_Interpreter
id: a3d7e1f2-9c4b-4a8e-b5d6-7f0e2c1a3b94
status: testing
description: |
  Detects an SSH client process (ssh, scp, sftp, libssh2-linked, PuTTY, plink, Dropbear)
  spawning a shell interpreter with the -c flag. A legitimate SSH client should never
  exec sh -c as a child process — this is the primary indicator of client-side RCE
  exploitation (e.g., CVE-2026-55200 libssh2 heap overflow).
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://nvd.nist.gov/vuln/detail/CVE-2026-55200
author:  CCCS
date: 2026/07/13
modified: 2026/07/13
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1203
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|re: '(?i).*([]\\]ssh|[]\\]scp|[]\\]sftp|[]\\]putty|[]\\]plink|libssh|ssh2|dbclient).*'
  selection_child:
    Image|re: '(?i).*(bash|dash|/sh$|zsh|ksh|ash).*'
    CommandLine|re: '(?i)((ba)?sh|dash|zsh|ash|ksh|cmd)\s+(-c|/c)\s+'
  filter_server_side:
    ParentImage|re: '(?i).*(sshd|ssh-agent|ssh-keygen|ssh-add|ssh-keyscan|sshfs).*'
  filter_benign_commands:
    CommandLine|re: '(?i)((ba)?sh|dash)\s+-c\s+(umask|locale|ssh-agent|test\s+-|\[\s+-)'
  condition: selection_parent and selection_child and not filter_server_side and not filter_benign_commands
falsepositives:
  - SSH session setup evaluating .bashrc (filtered by benign command patterns)
  - Legitimate SSH-based automation (Ansible, rsync) — typically uses sshd as parent, not ssh client
level: high

Orchestration informatique du pipeline

L’orchestration du flux de travaux repose sur un ensemble de compétences spécialisées d’agents, chacune étant responsable d’une étape précise du processus d’ingénierie des détections. Ces compétences peuvent être ajustées par les analystes pour renforcer l’uniformité des résultats, faire respecter les critères de qualité établis et garantir des résultats reproductibles dans divers cas d’utilisation.

Résultats et avantages opérationnels

Après plusieurs cycles de tests automatisés fondés sur la télémétrie générée et différentes variantes de techniques, les agents ont affiné les analyses de manière itérative. Une fois le processus terminé, le pipeline a préparé les détections prêtes pour la mise en production et les a soumises à l’examen des analystes. Les analystes pouvaient ensuite valider, approuver ou modifier les détections, selon les besoins, avant leur intégration au référentiel. Au total, le scénario de test présenté ci-dessus a permis de produire huit nouvelles règles de détection destinées à la production, après l’évaluation de plus de cinq variantes par technique afin d’identifier des indicateurs de comportement durables.

Dans l’ensemble, l’IA de pointe agit comme un multiplicateur de force, permettant de repérer plus rapidement les lacunes en matière de détection et d’opérationnaliser l’analyse des données défensives à un rythme mieux adapté à l’évolution du contexte des menaces. Grâce à l’automatisation d’une grande partie du processus d’ingénierie des détections, les analystes peuvent réduire le temps consacré aux tâches répétitives et se concentrer davantage sur ce qui suit :

• analyser des activités malveillantes réelles;
• observer comment les techniques se comportent dans divers contextes;
• fournir une rétroaction utile aux équipes d’ingénierie en amont concernant le manque de visibilité relevé.

Prochaines étapes de l’utilisation de l’IA de pointe par le Centre pour la cybersécurité

Bien que cette capacité continue globalement d’évoluer et de gagner en maturité, les progrès réalisés jusqu’à présent sont très prometteurs. Plusieurs composantes génèrent déjà une valeur opérationnelle tangible, et le flux de travaux continuera d’évoluer grâce à son utilisation collective et aux commentaires recueillis.

D’autres travaux en cours appliquent les mêmes techniques afin d’affiner et de renforcer continuellement les détections existantes en transformant les faux positifs validés en recommandations d’ajustement structurées et basées sur les preuves.