Repérer les dérives — Signaux de détection

Un compte volé ne se voit pas à l'ouverture d'une session : il se voit à ce qu'il fait de différent. Connexions depuis plusieurs pays, de nuit, volumes inhabituels, application sensible que personne ne surveille.

Les journaux sont dans votre SIEM ; ce que le SIEM ne sait pas, c'est ce qui est critique chez vous. InfraRiver croise les deux, sans devenir un SIEM : il ne rapatrie jamais un événement, seulement des compteurs agrégés, et il produit peu de signaux, à forte valeur.

Page : Sécurité → Signaux de détection (/detection/).

Qui détecte, qui explique

Les règles sont du code déterministe. L'IA ne crée jamais un signal : elle reformule en français les faits d'un signal existant, et son texte est vérifié (un nom, un nombre ou une adresse qui ne figure pas dans les faits le fait rejeter au profit d'un texte assemblé par le code).

Ce que la page montre

Quatre cartes (critiques à traiter, hautes ou critiques, ouverts ou en cours, sous exception), puis cinq onglets :

Onglet	Contenu
Signaux	Le tableau des signaux (filtres par colonne, filtre avancé ET/OU, tri, filtres sauvegardés, export CSV et Excel).
Applications sensibles	Les constats calculés à partir de la fiche de chaque application (voir plus bas).
Règles et seuils	Les onze règles, la disponibilité de leurs données, les seuils réglables.
Exceptions (« Exceptions et réinitialisations » en info-bulle)	Les comportements acceptés, et les comptes réinitialisés pour compromission.
Export vers le SIEM	La liste de contexte et les règles Sigma (voir plus bas).

Le droit Détection — lecture donne accès aux signaux de votre périmètre : un signal n'est visible que s'il concerne au moins un serveur que vous voyez. Le droit gestion permet de traiter les signaux, d'accepter des exceptions et de régler les règles.

Les onze règles

Code	Signal	Gravité de base
D1	Première connexion jamais vue d'un compte sur une crown jewel ou un serveur d'application sensible	haute
D2	Chemin d'administration utilisé pour la première fois	moyenne
D3	Compte de service en session interactive (RDP, SSH)	haute
D4	Compte à privilèges dormant (aucune connexion depuis 90 jours) qui se réveille	moyenne
D5	Même compte depuis au moins trois pays ou réseaux en sept jours	haute
D6	Pays ou réseau jamais vu pour ce compte, ou adresse marquée malveillante par le SIEM	moyenne, haute si adresse malveillante
D7	Connexion de nuit dans une plage horaire où le compte n'a jamais été vu	moyenne
D8	Volume servi à un compte par une application très supérieur à son habitude	haute
D9	Compte réinitialisé pour compromission puis réutilisé depuis une adresse déjà vue sur un compte compromis	haute
D10	Serveur critique ou d'application sensible qui n'émet plus de journaux	moyenne
D11	Rafale d'échecs d'authentification puis succès, pour le même compte, dans la même heure	moyenne

La gravité est relevée d'un cran par votre contexte : crown jewel, application sensible, serveur exposé (Internet ou DMZ), application accessible depuis un réseau large. La raison est affichée sur le signal. D1 et D10 ne concernent déjà que des cibles sensibles : pas de relèvement.

« Habituel » se calcule sur une référence glissante de 30 jours. Les règles de comparaison (D1, D6, D7, D8…) ne se déclenchent qu'à partir de 14 jours de compteurs : avant, InfraRiver ne prétend pas savoir ce qui est inhabituel.

Données absentes : si votre SIEM n'indexe pas le pays ou le réseau d'origine, les règles D5 et D6 sont désactivées et l'onglet Règles et seuils l'affiche (« donnée non disponible »), avec la raison. Aucune erreur, aucun faux « tout va bien ».

Traiter un signal

Cliquer une ligne ouvre le signal : les preuves agrégées (jours, origines, heures, volumes), le contexte qui a relevé la gravité, une explication, et les actions :

En cours / Clore / Rouvrir, avec une note ;
Ouvrir un dossier (Cases) : le signal devient un dossier suivi, partageable, avec motif de clôture ;
Accepter ce comportement : une exception avec un motif obligatoire et une date de fin. Le signal passe en « exception » : il est masqué mais toujours calculé et tracé. Retirer l'exception le fait revenir ;
✦ Expliquer : texte en français (IA vérifiée), ou texte assemblé par le code si l'IA ne peut pas répondre sans inventer.

Un signal ouvert n'est pas recréé : son compteur et sa dernière date sont mis à jour. Un signal clos qui revient devient un nouveau signal. Les signaux de gravité haute ou critique envoient un message dans la messagerie aux personnes autorisées qui voient les serveurs concernés, et apparaissent dans la rubrique « signaux de détection » de l'analyse hebdomadaire.

Applications sensibles

Sur la fiche d'une application (Modifier), trois champs :

Données sensibles (oui / non) ;
Journaux d'accès supervisés par le SOC (oui / non / inconnu) et leur source ;
Accessible depuis : Internet, partenaires / tiers, réseau inter-entités, interne seulement. Laissé vide, le réseau est déduit de la zone d'exposition des serveurs de l'application (Internet → Internet, DMZ → partenaires) et marqué « déduit ».

Deux constats en découlent, calculés à l'affichage : application sensible non supervisée (gravité haute si « non », moyenne si « inconnu ») et application sensible accessible depuis un réseau large. Quand le SIEM connecté voit des journaux de l'application, « Oui » est proposé sur le formulaire, jamais appliqué tout seul. Le constat disparaît dès que le champ est corrigé.

Brancher le SIEM

Dans Connecteurs → ELK, section Signaux de détection :

cocher Collecter les compteurs de détection (désactivé par défaut) ;
choisir le fuseau horaire (pour les heures de connexion) ;
choisir l'historique initial ;
si vous voulez la règle de volume, indiquer les index des journaux d'accès des applications (mode ES|QL).

Ce que l'on collecte : des compteurs par heure (connexions, échecs, origine, protocole) et par jour (volume par compte et application). Chaque champ facultatif est détecté dans votre SIEM : un champ absent désactive seulement la règle qui en a besoin.

Les règles sont évaluées toutes les heures et après chaque synchronisation. Le bouton Évaluer maintenant force un passage.

Réinitialisations de comptes (règle D9)

La règle D9 a besoin de savoir quels comptes ont été réinitialisés pour cause de compromission. Saisissez-les dans l'onglet Exceptions (compte, date, motif).

Donner le contexte au SIEM, et des règles Sigma

Onglet Export vers le SIEM :

la liste de contexte (CSV ou JSON) : serveur, adresse, criticité, crown jewel, exposition, applications, données sensibles, réseau d'accès. À importer comme liste d'enrichissement. Le SIEM peut aussi la relire seul : GET /detection/api/context.json avec l'en-tête Authorization: Bearer <jeton> (jeton généré sur la page, affiché une seule fois, stocké haché) ;
des règles Sigma : celles qui n'ont pas besoin de mémoire (compte de service en session interactive, rafale d'échecs), remplies avec votre liste de comptes de service et votre seuil. Les règles qui comparent à l'habitude restent dans InfraRiver : le format Sigma ne sait pas les exprimer. À relire et convertir avec votre outillage avant de les déployer.

Limites à connaître

Aucun journal brut n'est lu ni conservé : seulement des compteurs, supprimés après 130 jours.
Les règles D5 à D7 reposent sur les champs d'origine et d'heure de votre SIEM ; le mode de requête _search (OpenSearch, Elasticsearch ancien) ne collecte ni les volumes ni l'activité des hôtes (règles D8 et D10 indisponibles dans ce mode).
Un signal n'est pas une preuve d'intrusion : c'est un écart à l'habitude, à confirmer.