Scénarios de menace
Un scénario de menace est une séquence de gestes d'attaquant : un courriel piégé reçu, le lien cliqué, une connexion à risque, une règle de boîte… La bibliothèque, sous Configuration → Scénarios de menace, est le seul endroit où les menaces se configurent, et chaque scénario sert deux usages :
- greffé au hasard sur une communauté — il tourne alors, d'heure en heure, avec les autres scénarios de sa rotation sur les hôtes compromis (voir Bruit de fond pirate) ;
- lancé à la demande depuis l'onglet Menaces d'une communauté — maintenant, pour une durée bornée.
Les menaces étaient des archétypes de nature « menace », configurés avec l'éditeur des journées de travail. Elles sont devenues des scénarios : un archétype est désormais toujours une journée métier.
La bibliothèque, pré-peuplée
| Scénario | Famille | Ce qu'il enchaîne |
|---|---|---|
| Compromission de messagerie (BEC) | Compromission de messagerie | Courriel piégé → clic → connexion à risque depuis l'étranger → session volée → règle de transfert → lecture de la boîte → demande de virement frauduleuse → charge sur le poste → élévation de privilèges → vol d'identifiants → rebond → élévation sur le serveur |
| Déni de service distribué | Déni de service | Sondage d'un site → rafale de requêtes venues de milliers d'adresses → retour du trafic légitime |
| Rançongiciel | Rançongiciel | Charge → exécution → ancrage → reconnaissance → vol d'identifiants → rebond → sortie des données → chiffrement et suppression des documents en masse → détection |
| Pulvérisation de mots de passe | Attaque sur les identifiants | Échecs d'authentification en rafale depuis l'extérieur → pulvérisation détectée → connexion réussie, signalée à risque → second facteur demandé |
| Sabotage d’automate (type Triton) | Systèmes industriels | Balise C2 → balayage du réseau de conduite → altération du programme d'un automate de sécurité → mise à l'arrêt de l'automate |
| Débordement de l’IT vers l’OT | Systèmes industriels | Charge → exécution sur un poste de gestion → vol d'identifiants → rebond → découverte du réseau de conduite → arrêt d'un contrôleur |
| Homme du milieu industriel | Systèmes industriels | Usurpation ARP sur le segment de conduite → commandes de conduite non autorisées injectées au contrôleur |
| Micrologiciel piégé | Systèmes industriels | Domaine malveillant résolu → micrologiciel récupéré → chargement d'un micrologiciel non constructeur → redémarrage du contrôleur |
| Déni de service industriel | Systèmes industriels | Balayage du réseau de conduite → inondation SYN qui sature le contrôleur |
| Commandes de conduite malveillantes (type Industroyer2) | Systèmes industriels | Reconnaissance IEC-104 → commandes d'ouverture de disjoncteurs → arrêt des automates de poste |
| Pirate | Intrusion | La chaîne d'attaque complète, de la force brute à l'exfiltration, en moins d'une heure |
| Balise vers le serveur de commande | Commande et contrôle | Résolution du serveur de commande → balise toutes les dix minutes |
| Téléchargement de charge | Intrusion | Résolution → récupération du second étage → exécution |
| Reconnaissance | Intrusion | Énumération de l'annuaire |
| Vol d’identifiants et rebond | Attaque sur les identifiants | Extraction de secrets → rebond vers un autre hôte |
| Exfiltration | Exfiltration | Téléversement vers l'attaquant → sortie massive détectée |
| Ancrage et persistance | Intrusion | Réveil de l'implant → ancrage sur la machine |
| Battement de l’implant | Commande et contrôle | Une balise toutes les deux heures — un scénario de fond |
Les huit derniers sont les menaces qui existaient avant la bibliothèque — converties, pas réécrites. Le semis est create-only : un scénario modifié depuis l'écran survit au semis suivant.
Six scénarios démontrent la détection sur les réseaux industriels (OT), avec Nozomi Vantage
comme capteur. L'automate visé étant une destination, l'alerte Nozomi et les observateurs de flux
(pare-feu, EDR) nomment la même IP et le même port, à la même seconde — la commande d'arrêt n'est pas
vue de la seule sonde. On les joue sur une population industrielle (par exemple
demo-cyberdyne-systems) : sur une population sans équipement de terrain, leurs étapes OT sont
sautées.
L'identité d'un scénario
| Champ | Ce qu'il décide |
|---|---|
| Famille | Une étiquette pour ranger la bibliothèque — rien ne se décide sur elle |
| Cibles | Les tranches de la population qui peuvent jouer ses étapes : postes, serveurs, sites |
| Scénario de fond | Greffé, il joue toute la journée hors de la rotation — c'est le cas du battement de l'implant |
Un scénario qui ne vise que des sites — le déni de service — ne se greffe pas : la greffe compromet des postes et des serveurs. Il se lance à la demande.
Les étapes
Chaque étape est un geste du catalogue d'actions — celui-là même qu'assemblent les archétypes —, placé à un décalage en minutes depuis le début du scénario.
| Colonne | Ce qu'elle dit |
|---|---|
| Décalage | Minutes depuis le début — ou depuis le début de l'heure, dans une rotation |
| Action | Le geste : une action de menace, ou une action métier que le scénario emprunte (un courriel frauduleux est un courriel) |
| Libellé | Le nom du geste dans le journal de menace — celui du catalogue s'il est vide |
| Fois | Combien de gestes — vide signifie « jusqu'à la fin », toutes les n minutes |
| Toutes les | Minutes entre deux gestes, requises dès que l'étape se répète |
| Dispersion | Jusqu'à une heure d'écart autour de chaque échéance |
| Simultanés | Gestes simultanés à chaque échéance — une rafale de déni de service —, jusqu'à cinquante |
| Joué par | Une tranche, ou toute cible du scénario que l'action admet |
| Hors site | Le geste a lieu hors du bureau — une connexion depuis l'étranger |
Chaque étape attend la fin de la précédente. Une dispersion ne peut donc jamais faire passer le clic avant l'arrivée du courriel. Une étape répétée « jusqu'à la fin » n'a pas de fin à attendre : la suivante s'enchaîne alors à la dernière étape bornée qui la précède.
Dans une rotation, un scénario se rejoue dans chaque heure qui lui revient, depuis le début de cette heure. Une étape dont le décalage dépasse la première heure n'y a jamais lieu — l'éditeur en avertit, sans refuser : le même scénario se lance très bien à la main sur deux heures.
Sous chaque étape, l'éditeur nomme les sources de logs qui ont un message pour son action, sur une ligne qui occupe toute la largeur du tableau. Jusqu'à trois sources, elle est dépliée d'office ; au-delà, elle se replie sur son compte et les premiers noms — « Vu par 14 sources, dont 3 en alerte seule — Bind · Fortinet FortiGate · … » — et se déplie d'un clic. Dépliée, elle range les sources en deux groupes de pastilles, Émettent puis Alerte seule. La ligne suit le sélecteur dès que l'action change, avant tout enregistrement. Une source du groupe Alerte seule ne couvre le geste que par des messages types d'alerte : un lancement les envoie, en repli quand la source n'a rien d'autre pour décrire le geste ; la rotation d'une greffe, qui joue le flux normal, les tait. Le courriel d'hameçonnage reçu en est le cas : les deux sources Office 365 ne le décrivent que par des alertes. Quand aucune source ne couvre l'action, la ligne le dit en ambre. La liste nomme toutes les sources du catalogue, là où un lancement ne joue que les technologies de sa communauté, et n'envoie que pour celles qui ont une clé d'intake : une étape qu'aucune d'elles ne couvre figure parmi les « Étapes qu’aucune technologie active ne couvre ».
Sans JavaScript, la séquence s'édite en JSON dans le même champ — un objet par étape — et les sources de logs des étapes enregistrées sont listées dessous. L'éditeur et l'API la valident avec la même fonction : l'écran ne peut pas accepter ce que l'API refuserait.
Enregistrer les étapes atteint, dans la minute, les communautés qui greffent le scénario : leur plan du jour se périme et se reconstruit au tic suivant. Un scénario greffé ne se supprime pas — le refus nomme les communautés ; ses lancements passés lui survivent, sous son nom.
Les actions de menace
Onze gestes de menace existaient ; six se sont ajoutés pour les scénarios, et la couverture du corpus les nomme :
| Action | Ce que les journaux en montrent |
|---|---|
| Courriel d'hameçonnage reçu | Renseignement sur la menace d'Office 365, quarantaine du suivi des messages |
| Clic sur un lien piégé | Clic d'URL d'Office 365 |
| Connexion à risque | Détection de risque d'Entra ID, autorisation risquée de Google Workspace |
| Règle de boîte aux lettres malveillante | Règle de boîte d'Office 365, transfert externe de Google Workspace |
| Élévation de privilèges | Service privilégié de Windows, rôle d'administration d'Office 365, SentinelOne Identity |
| Rafale de déni de service | Limitation de débit et refus de bot ou de réputation d'Akamai WAF — jouée par un site |
La plupart de ces messages types sont réservés aux alertes : le flux minute par minute ne les émet jamais. Un scénario lancé à la demande les émet quand la technologie n'a rien d'autre pour décrire le geste — sans quoi une compromission de messagerie serait muette à la boîte aux lettres.
Il n'y a pas d'action de rançongiciel : aucun message type du corpus n'en nomme une. Le scénario Rançongiciel se compose donc de gestes existants — le chiffrement est une rafale de modifications de documents.