L’impact direct de la « tokenomics » sur les processus de cybersécurité

Nous avons récemment publié un article sur la « tokenomics » et les attaques de type « déni de portefeuille », un nouveau type d’attaque DDoS visant à épuiser les jetons d’IA. Mais avant que les spécialistes de la sécurité ne se mettent à protéger les processus d’IA de leurs collègues contre cette nouvelle menace, ils doivent garder à l’esprit que le travail du service de sécurité de l’information lui-même peut devenir la cible d’une telle attaque. Étant donné que les équipes de sécurité testent et mettent désormais activement en œuvre divers types d’automatisation basés sur l’IA, la menace d’une ingérence extérieure visant à paralyser le système de défense affecte directement leurs propres processus et technologies.

Elastic a estimé que, selon l’architecture « SOC basée sur des agents », le triage d’une seule alerte provenant d’un hôte peut coûter 0,69 $ pour un ensemble d’agents hautement spécialisés ou 3,42 $ pour un agent polyvalent doté de 14 compétences différentes.

Cependant, ces moyennes masquent d’énormes écarts. À tout moment, le traitement de base d’une simple alerte (par exemple, un millier de jetons) peut se transformer en une cascade de recherches impliquant le traitement de millions d’entrées de journal, d’appels d’API et d’autres données associées, ce qui représente des millions de jetons en l’espace de quelques minutes.

Elastic reconnaît avoir utilisé le modèle 4.6 de Claude Sonnet dans son SOC. Ce constat soulève immédiatement la question suivante : que se passe-t-il lorsque le budget est épuisé ou que les filtres de sécurité du modèle se déclenchent ? Dans le pire des cas, voici ce qui se produit : le SOC d’IA lance un « ensemble d’agents » pour enquêter sur des événements suspects qui s’apparentent à un déplacement latéral au sein de l’infrastructure. L’agent interroge l’API Anthropic, mais le budget mensuel du service est épuisé et l’API renvoie des erreurs. L’enquête est au point mort, et tout le monde l’apprend une demi-journée plus tard. De plus, si les « filtres de sécurité » en constante évolution d’un grand fournisseur d’IA signalent les requêtes du SOC comme malveillantes, le même effet peut se produire même sans que le budget soit épuisé, comme l’a démontré l’expérience de Hugging Face lors de son enquête sur la violation de son infrastructure par OpenAI.

Bien sûr, un pirate a tout intérêt à ce que cela se produise. Ils peuvent influencer directement les coûts supportés par les défenseurs en injectant des instructions malveillantes dans les données mises à leur disposition (enregistrements TXT DNS, en-têtes HTTP, commentaires de code, noms de fichiers, etc.), en misant sur le fait que ces instructions seront traitées par les systèmes de sécurité informatique. Par exemple, dans le cas de l’attaque de type GhostJacking, les journaux WAF servent de vecteur d’injection de commandes, et dans le cadre d’une étude universitaire, une autre méthode a été proposée : les chercheurs ont réussi à attaquer les mécanismes de sécurité des modèles LLM eux-mêmes, ce qui a entraîné une augmentation de la latence de leurs requêtes de 148 et du nombre de tokens consommés de 63. Autrement dit, le système continue théoriquement à fonctionner correctement, mais le temps de latence dans le traitement des alertes et les coûts associés augmentent considérablement.

Erreur silencieuse dangereuse

Dans les scénarios basés sur des agents, l’épuisement du budget ne se traduit pas toujours par une erreur explicite accompagnée d’un message « limite de requêtes dépassée » et d’une alerte immédiate adressée aux responsables. Dans certaines configurations, des scénarios de type « guérilla » peuvent se produire : une requête adressée au modèle expire, le système bascule automatiquement vers un modèle moins coûteux, ce qui entraîne une baisse de la qualité des résultats, et les sous-agents ainsi que les tâches périodiques cessent de s’exécuter. Pendant ce temps, l’équipe de sécurité peut continuer à croire pendant des heures que tout fonctionne comme avant.

Comment maîtriser les coûts liés à l’IA dans le domaine de la cybersécurité

La gestion des dépenses ne se résume bien sûr pas simplement à « éviter les dépenses excessives ». Le secteur est déjà tombé dans ce piège lors de la mise en œuvre des solutions SIEM : lorsque les entreprises devaient s’acquitter de frais calculés en fonction du volume de données télémétriques collectées, elles ont commencé à limiter de manière sélective (et pas toujours efficace) la collecte des journaux. En conséquence, elles se sont retrouvées avec des angles morts de détection. La même situation pourrait se produire avec les jetons, mais plus rapidement et à plus grande échelle. Une stratégie de réduction des coûts mal conçue pourrait nuire à la rigueur des enquêtes et à la qualité des réponses. Et en l’absence d’une telle stratégie, la décision de supprimer un élément ne serait pas prise par l’architecte ou le RSSI lors de la phase de conception du système, mais par l’analyste de garde à 3 heures du matin. Un limiteur automatique défini par le fournisseur du système pourrait également intervenir.

Quelques principes simples peuvent permettre d’éviter les dépassements de coûts prévisibles et de mieux gérer les situations qui sont véritablement imprévisibles.

Ne fournissez pas au modèle d’IA des informations qui peuvent être vérifiées à l’aide d’une requête standard. Tout ce qui est répétitif et prévisible doit être géré de manière traditionnelle, c’est-à-dire à l’aide de règles et de requêtes de données. Ces systèmes peuvent être développés à l’aide de l’IA, mais ils doivent fonctionner de manière déterministe. Ce modèle ne doit être utilisé que lorsqu’une évaluation d’une situation ambiguë s’avère réellement nécessaire.

Appliquez des limites strictes et avertissez les utilisateurs de manière claire et ferme en cas de dépassement. Les limites doivent être combinées : une limite par tâche, une limite quotidienne, etc. Les alertes signalant des dépassements de limites doivent être transmises immédiatement aussi bien aux analystes en service qu’aux responsables du système dans son ensemble.

Déterminez à l’avance ce qui se passe lorsqu’une limite est atteinte. Choisir entre s’arrêter pour faire des économies (tout en perdant un peu de contrôle) ou continuer et payer est une décision qui doit être prise avant qu’un incident ne se produise.

Limitez les autorisations des agents ainsi que l’ensemble des outils mis à leur disposition. Moins le système a accès à des actions, plus il fonctionne efficacement sur une tâche ciblée, moins il a d’occasions de faire grimper les coûts, et moins il risque d’être « exploité » par un tiers.

Effectuez systématiquement une analyse des données externes non fiables. Les requêtes, demandes de renseignements, messages et commentaires entrants, ainsi que divers champs techniques susceptibles de contenir du texte arbitraire (enregistrements DNS, en-têtes HTTP, noms de fichiers) peuvent non seulement entraîner une injection de commande immédiate, mais aussi augmenter délibérément la charge de travail. Limitez leur taille et surveillez la charge qu’ils génèrent.

Pour éviter les interruptions de service liées aux fournisseurs externes et conserver un contrôle total sur les données de votre organisation, envisagez la possibilité d’utiliser des modèles locaux déployés sur site, au moins pour répondre aux besoins en matière de sécurité informatique. Même si ces modèles ne sont peut-être pas à la pointe de la technologie, leur spécialisation ciblée et leur ajustement à partir des données de l’entreprise permettront d’obtenir des performances satisfaisantes sans défaillances imprévues.

Dans une architecture plus complexe, l’utilisation des LLM peut être divisée en plusieurs niveaux. La première ligne de défense (routage, filtrage du bruit, enrichissement des données) est assurée par des modèles compacts déployés sur site. Cette approche réduit considérablement la volatilité budgétaire. Le deuxième niveau consiste en un vaste modèle local qui se charge du travail de fond : relier les événements entre eux, tester des hypothèses et reconstituer le tableau d’un incident. De plus, il n’est pas facturé à la requête, mais son débit est limité. Par conséquent, au lieu de dépassements de budget, ce sont des surcharges et des files d’attente d’événements qui peuvent se produire. Seuls les cas isolés, véritablement complexes, sont transmis à des modèles avancés basés sur le cloud, de préférence avec l’accord explicite d’un analyste humain. Dans ce modèle, les coûts variables persistent, mais ils se limitent à un petit nombre de cas, et chacun d’entre eux résulte d’un choix délibéré plutôt que d’un effet secondaire d’un script s’exécutant pendant la nuit.

Concrètement, ce système reproduit le modèle classique de SOC à plusieurs niveaux, où la première ligne assure le filtrage et la troisième ligne mène les enquêtes, à la seule différence que ces rôles sont assumés par des modèles plutôt que par des personnes.