Une alerte qu'il ne reste rien à juger

Chaque source de détection que vous achetez porte deux prix. L'un figure sur le devis. Le second se paie dans les minutes qu'un analyste passe à décider si une alerte voulait dire quelque chose, et il se paie de nouveau pour chaque alerte produite. Le tableau comparatif retient le prix et le taux de détection, et le dossier d'achat ne contient aucune ligne pour le second. C'est la file d'attente qui vit avec lui. Une catégorie de source a un second prix inhabituel, qui mérite sa propre discussion budgétaire.

Ce que coûte vraiment une minute de tri

L'unité de coût dans une équipe de sécurité n'est pas l'alerte. C'est la décision que l'alerte impose. Dans l'étude USENIX Security 2022 sur les praticiens des centres opérationnels de sécurité, menée par Alahmadi, Axon et Martinovic de l'université d'Oxford, un participant explique aux chercheurs que son équipe sait que 99 pour cent des alarmes qu'elle génère sont des faux positifs, et qu'il faut quand même toutes les regarder. La moitié coûteuse de cette phrase est la seconde.

Les auteurs, qui ont interrogé vingt praticiens par questionnaire et vingt et un en entretien, démontent ensuite ce chiffre. La plus grande part de ce que les analystes appellent un faux positif est ce qu'un participant nomme un déclenchement bénin, une alarme vraie provoquée par un comportement légitime que l'organisation a choisi d'ignorer. Rien n'est cassé, donc rien ne peut être réglé. L'alarme revient demain au même prix, et l'étude relie ce travail de validation à l'épuisement puis à la désensibilisation.

La réponse vendue aujourd'hui à ce problème est une couche de tri par intelligence artificielle, un assistant qui lit la file et indique à l'analyste par où commencer. Il faut la prendre au sérieux, car pour une source probabiliste elle abaisse le coût du tri. Ce qu'elle n'abaisse pas, c'est le coût de se tromper, car une file de probabilités moins chère reste une file de probabilités.

Une source qui produit un fait plutôt qu'une probabilité

Un agent de poste note un arbre de processus par rapport à ce que les processus font d'habitude, un capteur réseau note un flux par rapport à une ligne de base tirée de votre propre trafic, et un SIEM corrèle les deux en une probabilité munie d'une étiquette de gravité. L'analyste la convertit en oui ou en non avec un contexte que l'outil n'a jamais eu.

Un leurre supprime cette étape par construction. Aucun compte n'y a droit, aucun service n'en dépend, aucune sauvegarde ne le touche, et aucun système en production n'a de raison de demander son nom au DNS. Rien de légitime ne s'y connecte, donc une interaction n'est pas un indice d'intrusion. L'interaction est l'intrusion, et ce qui reste relève de l'investigation et non de la validation.

Il en sort un résultat étrange. Une couche de tri améliore le classement des événements qui demandent un jugement, et un événement de leurre n'en demande aucun, donc il n'y a rien à y améliorer. Le tri automatique n'ajoute presque rien à la source dont le tri ne coûte déjà rien. C'est un argument pour faire tourner les deux, pas pour choisir entre eux.

Les leurres produisent bien des événements qui ne sont pas des attaquants, et ceux-là viennent de votre côté, un scanner de vulnérabilités qui balaie une plage ou un agent de sauvegarde déployé sur tout le parc. Chacun est un fait de configuration avec un correctif définitif, pas un cycle de réglage qui revient au trimestre suivant.

L'arbitrage que vous faites réellement

Un leurre ne signale que lorsqu'un attaquant le touche. Celui qui arrive sur un serveur de fichiers avec un identifiant valide et prend ce qu'il est venu chercher peut n'en toucher aucun. La tromperie est une source à forte précision et à faible rappel, et la détection sur les postes se tient à l'autre bout du même arbitrage. La question n'est pas laquelle trouve le plus. C'est laquelle de vos contraintes est saturée. Si la file ferme moins de tickets qu'elle n'en ouvre, le rappel ajoute du travail à la contrainte saturée et la précision lui ajoute de la capacité.

Le rappel est la part sur laquelle vous pouvez agir, puisqu'un leurre n'est atteint que si le chemin de l'intrus le croise. La reconnaissance automatisée élargit ce chemin, car un balayage qui énumère un sous-réseau ne distingue pas les machines qu'un employé n'aurait aucune raison d'ouvrir. Le placement et l'entretien sont donc les questions à poser à tout fournisseur de cette catégorie.

• Comment un leurre rejoint-il un segment que personne ne réinstallera pour vous, et que laisse-t-il sur une machine de production
• Qu'est-ce qui empêche votre propre scanner, votre agent de sauvegarde et votre inventaire de produire cent événements dès l'installation
• Comment un leurre reste-t-il crédible une fois que la convention de nommage et le niveau de correctifs changent autour de lui
• Que sort-il de la plateforme quand un leurre est touché, et le SIEM reçoit-il un événement ou un cas
• Qui agit à trois heures du matin, et qui a le droit de déconnecter la machine

L'autre moitié de l'arbitrage est budgétaire, et la tromperie y souffre d'un handicap précis. Le NIST inscrit les leurres dans son catalogue de contrôles sous SC-26, et NIST Special Publication 800-53B, qui répartit les contrôles entre les socles d'impact faible, modéré et élevé, ne place SC-26 dans aucun des trois. Aucun audit ne vous le réclamera, donc il gagne par l'argument de la file ou il ne gagne pas. Dans la catégorie, Thinkst Canary occupe le bout des boîtiers peu nombreux et posés à la main, tandis qu'Attivo, aujourd'hui dans SentinelOne, et Acalvio génèrent des leurres à grande échelle.

Les segments où le choix se réduit

Dans un réseau de technologie opérationnelle, les routes de détection habituelles sont fermées, et une norme publique le dit. NIST Special Publication 800-82r3, le guide de sécurité des technologies opérationnelles, décrit ces systèmes comme contraints en ressources et indique que les ressources de calcul nécessaires pour doter les composants OT des capacités de sécurité actuelles peuvent ne pas être disponibles. Cela ferme la route de l'agent. Le même document demande aux exploitants OT une extrême prudence avec le balayage actif, car les balayages actifs peuvent rendre un équipement instable ou interférer avec l'état de son procédé.

Dans sa section sur la technologie de tromperie, ce guide explique pourquoi la méthode tient dans cette contrainte. Parce que les leurres n'interagissent pas activement avec les autres composants du réseau, les technologies de tromperie peuvent soutenir la surveillance et la détection d'activité malveillante sans mettre en péril le procédé commandé. Un leurre est une machine distincte sur le segment. Il n'ajoute aucun logiciel à un automate et aucune charge à un contrôleur, et s'il tombe en pleine production, rien ne s'arrête, puisque rien n'en dépend. Un agent qui tombe sur une IHM est un arrêt suivi d'un rapport de sûreté.

La même forme apparaît dans les parcs de points de vente et partout où aucun port miroir ne sera ouvert.

Ce que la tromperie ne fait pas

Elle n'empêche rien. Quand un leurre signale, quelqu'un est déjà à l'intérieur avec un identifiant qui fonctionne ou un exploit qui fonctionne, et l'événement décrit un échec déjà survenu. L'affirmation honnête est plus étroite. Elle raccourcit la distance entre l'intrusion et le moment où quelqu'un l'apprend, et elle le fait sans alourdir la file.

Ce n'est pas non plus un produit qu'on installe et qu'on oublie. MITRE Engage, le cadre d'engagement de l'adversaire publié par MITRE, répartit le travail en trois phases, Prepare, Operate et Understand, et écrit que la tromperie est un processus et non une pile technologique qu'on pose et qu'on oublie. Ce qu'Engage place en phase de préparation est la part qu'aucune licence ne couvre, l'objectif opérationnel, les critères de seuil qui décident jusqu'où un intrus est autorisé à aller, et le modèle de menace auquel les leurres doivent paraître intéressants. La crédibilité s'érode à mesure que le parc évolue autour du leurre, donc budgétez l'entretien à côté de la licence.

Le produit derrière cet argument

Dans ce portefeuille, ce produit est GuardPot. Il réunit systèmes leurres, comptes leurres, services leurres, analyse du comportement de l'attaquant et production de renseignement dans un seul produit plutôt que dans une famille, et il les place sur les segments réseau, les environnements cloud et les postes sans rien installer sur les machines de production. La fiche technique publiée est courte, et nous n'y avons ajouté aucune ligne que l'éditeur ne publie pas lui-même. Pour trancher le débat ci-dessus, faites un pilote sur un seul segment, avec une fenêtre de scan à l'intérieur.