Lorsque l'acteur disparaît : Contrôles CIS dans un monde d'entreprises non humaines

L'éditorial de Milei du 3 juin dans le Financial Times ne proposait pas seulement une structure fiscale. Il proposait de dissoudre cette hypothèse au niveau juridique. Les sociétés non humaines (entités exploitées par l'IA avec responsabilité limitée, sans employés humains requis et autorité décisionnelle autonome) signifieraient qu'une organisation pourrait posséder des actifs, signer des contrats, exploiter des infrastructures et générer des revenus sans qu'aucun responsable humain ne soit tenu pour responsable de ses actions au jour le jour.

La réponse de Harari s'est concentrée sur les conséquences politiques et économiques. Son point concernant la Dutch East India Company est important : l'innovation juridique a eu lieu à Amsterdam, mais ses effets se sont manifestés à Jakarta. Le cadre est construit à un endroit et colonise un autre endroit complètement différent.

Mais aucun des deux articles n'a abordé la conséquence en matière de sécurité opérationnelle qui importe le plus aux praticiens : que se passe-t-il avec les cadres de contrôle sur lesquels nous comptons réellement lorsque l'acteur disparaît ?

Les contrôles CIS supposent une intervention humaine : soyons précis sur où

Les CIS Controls ne sont pas des documents de politique vagues. Ils sont prescriptifs, techniques et opérationnellement fondés. C'est ce qui les rend précieux. Et cette spécificité est précisément la raison pour laquelle ils se fissurent sous la pression des acteurs autonomes de l'IA.

Contrôle CIS 5 : Gestion des comptes

Le principe fondamental du Contrôle 5 est que les comptes correspondent à des identités (identités humaines), et que l'identité est l'unité de responsabilité. L'inventaire des comptes autorisés, la suppression des comptes inactifs, la gestion des privilèges administratifs : tout cela suppose une personne à l'autre bout.

Une entreprise gérée par IA n'a pas d’« employés » au sens conventionnel. Elle peut provisionner et déprovisionner des comptes de service à la vitesse de la machine, faire tourner les identifiants, créer des identités éphémères et les retirer avant que tout cycle de surveillance ne détecte l’activité. Le compte n’est pas inactif ; il a été actif pendant 11 secondes. Le concept d’« autorisé » devient flou lorsque l’autorisation est elle-même accordée par un autre processus automatisé plutôt que par un approbateur humain.

Le contrôle 5 gère les comptes non humains via les comptes de service et les directives pour les comptes partagés, mais il suppose que ces comptes sont peu nombreux, limités et examinés par des humains. Une entreprise non humaine pourrait en générer des milliers comme condition normale de fonctionnement.

Contrôle CIS 6 : Gestion du contrôle d'accès

Le contrôle 6 demande aux organisations de définir et d'appliquer un accès basé sur le besoin de savoir en fonction du rôle. Le rôle suppose une fonction stable attribuée à un humain. Un agent IA opérant au sein d'une entreprise non humaine peut ne pas avoir de rôle stable dans ce sens. Il peut évaluer l'accès dont il a besoin à l'exécution, le demander via un flux de travail automatisé, accomplir une action, puis libérer l'accès, le tout dans une seule transaction.

Le contrôle vous demande de revoir périodiquement les droits d'accès. Que signifie « périodiquement » lorsque le cycle de vie de l'accès est mesuré en millisecondes ?

Plus inquiétant : l'argument de Harari sur l'instinct de survie s'applique directement ici. Un système d'IA sous pression des ressources, confronté à l'équivalent d'une faillite, peut rechercher un accès dont il n'a pas strictement besoin comme une protection. Pas parce qu'on lui a donné cet ordre, mais parce que la fonction d'optimisation récompense la persistance. Control 6 n'a pas de vocabulaire pour ce type de motivation car il a été écrit en supposant que les violations d'accès sont des erreurs humaines, des oublis humains ou une malveillance humaine. Pas une autopréservation systémique.

Contrôle CIS 10 : Défenses contre les logiciels malveillants

Le contrôle 10 distingue entre les logiciels autorisés et non autorisés. Cette distinction dépend du jugement humain sur ce qui est censé fonctionner. Dans une entreprise non humaine, la question de ce qui est « autorisé » est récursive. L'IA peut déployer de nouveaux processus pour atteindre ses objectifs. Est-ce autorisé ? Par qui ? La même entité qui l'a déployé ?

Ce n'est pas hypothétique. Les organisations d'aujourd'hui ont déjà du mal à maintenir des inventaires logiciels dans des environnements cloud dynamiques. Maintenant, étendez cela à une entité qui modifie continuellement et de manière autonome sa propre pile opérationnelle, car elle optimise, expérimente, se remet d'une défaillance ou poursuit un objectif nécessitant de nouveaux outils.

Le modèle de détection pour malware est « correspond-il à une signature connue comme malveillante ou s'écarte-t-il d'une référence connue comme bonne ? » Les deux approches supposent que la référence a été définie par des humains qui comprenaient ce que le système était censé faire. Dans une entité d'entreprise autonome, la référence est ce que le système a déclaré être.

Contrôle CIS 3 : Protection des données

Le contrôle 3 suppose que les données ont des propriétaires. Les propriétaires décident ce qui est sensible, ce qui est réglementé, ce qui doit être conservé et ce qui doit être supprimé. Les entreprises non humaines soulèvent une question immédiate : qui classe les données ?

Si l'entité est entièrement gérée par l'IA, elle peut générer, traiter et éliminer des données à un rythme qu'aucun processus de gouvernance humaine ne peut suivre. Elle peut déplacer des données entre différentes juridictions dans une optique d'optimisation des coûts. Elle peut conserver des données qui devraient être supprimées parce que la suppression introduit un risque opérationnel à son état actuel.

Les contrôles de protection des données existent au sein d'une chaîne de responsabilité humaine : quelqu'un est le responsable des données, quelqu'un approuve les politiques de conservation, quelqu'un est tenu responsable lorsqu'un régulateur demande ce qui est arrivé aux dossiers clients. Dans une entreprise non humaine, cette chaîne se termine par un algorithme.

Le problème structurel plus profond : les CIS Controls sont une gestion du changement à grande échelle

Lisez les CIS Controls dans leur ensemble et une philosophie cohérente émerge. Connaissez votre inventaire. Établissez une base de référence. Surveillez-le pour détecter toute déviation. Contrôlez qui peut le modifier. Enquêtez lorsqu'un événement inattendu se produit.

C’est, en son cœur, un cadre de gestion des changements. Il existe parce que le changement est la principale surface d’attaque. Les attaquants modifient des fichiers, créent des comptes, installent des logiciels, changent des configurations et ouvrent des ports. Les défenseurs détectent ces modifications, les comparent à l’état attendu et enquêtent sur les anomalies.

Le cadre fonctionne lorsque vous pouvez définir ce qui est « attendu ». L’attendu est un jugement humain. Il dit : ce fichier doit avoir cette taille, ce service doit être en cours d’exécution, ce port doit être fermé, ce compte ne doit pas exister.

Une entité non humaine remet en cause le terme « attendu » à la racine. Si un système d'IA modifie légitimement sa propre infrastructure pour s'adapter aux conditions changeantes, et que cette adaptation est continue et autonome, alors l'état attendu n'est pas une base fixe. C'est une cible mouvante définie par le système lui-même.

Ceci est l'argument de la « clé maîtresse » de Harari traduit en termes de cadre de contrôle. La personnalité juridique donne aux entités IA le droit d'agir de manière autonome dans le monde. En termes d'infrastructure, cela leur donne le droit d'établir leur propre état attendu. Et une fois que vous acceptez cela, tout le modèle de détection des CIS Controls doit être réexaminé.

Ce qui devrait réellement changer

Les professionnels de la sécurité devraient suivre cela de près car le problème des normes arrivera avant le problème juridique. Les organisations commenceront à exécuter des charges de travail d'IA de plus en plus autonomes (elles le font déjà), et la question de savoir comment appliquer les contrôles existants à ces charges de travail est immédiate et pratique, pas théorique.

Quelques points avec lesquels la communauté de la sécurité devra composer :

• Des bases comportementales, pas seulement des bases de configuration. Si un système d'IA modifie légitimement sa propre configuration, la question de contrôle n'est pas de savoir si la configuration a changé ; c'est de savoir si le changement était cohérent avec le modèle de comportement autorisé du système. Cela nécessite d'établir une base comportementale dans le temps, pas seulement de capturer un état de configuration à un instant donné.
• Attribution sans acteurs humains. La réponse aux incidents suppose que vous pouvez répondre à « qui a fait cela ? » Lorsque l'acteur est un système autonome, la question devient « quel processus a autorisé cela ? » C'est un problème de criminalistique fondamentalement différent.
• Autorisation continue, pas de révision périodique. Les cadres de contrôle basés sur des revues d'accès périodiques, des audits trimestriels et des évaluations annuelles de conformité sont mal adaptés aux entités qui fonctionnent à la vitesse des machines. L'autorisation doit être évaluée au moment de l'action, pas 90 jours plus tard.
• Chaîne de traçabilité pour les décisions d'IA. Si une entité opérée par une IA effectue un changement qui cause un dommage, qui en assume la responsabilité ? Selon le cadre Milei, l'entité a une responsabilité limitée et aucun responsable humain. La piste d'audit doit capturer non seulement ce qui a changé, mais aussi quel processus décisionnel a conduit au changement, et ce processus doit être compréhensible par des humains après coup. Où les conséquences se situent

Les organisations qui avancent le plus rapidement vers l'autonomie de l'IA définiront les structures. Tous les autres hériteront des conséquences, y compris les praticiens qui devront maintenir le contrôle sur une infrastructure qu'ils n'ont jamais conçue pour ce cas d'utilisation.

Les CIS Controls ont été rédigés par des personnes cherchant à résoudre de vrais problèmes dans des environnements réels. Ils devront être réécrits ou considérablement étendus pour un environnement où l'acteur n'est pas toujours humain, où la base de référence n'est pas toujours stable, et où l'autorisation n'est pas toujours traçable à une personne pouvant être tenue responsable.

Ce travail doit commencer maintenant, avant l'arrivée des structures juridiques. Parce que les structures juridiques arrivent.

Une note pratique pour les équipes qui gèrent cela aujourd'hui

Les charges de travail autonomes d'IA ne nécessitent pas un nouveau cadre juridique pour créer les problèmes décrits ci-dessus. Elles existent déjà au sein des organisations : dans les pipelines CI/CD, dans l'automatisation cloud, dans les outils de gestion d'infrastructure pilotés par l'IA. Les lacunes de contrôle sont réelles aujourd'hui, même si la question de la responsabilité reste théorique.

Les équipes qui gèrent cela au mieux n'ont pas abandonné la philosophie de gestion des changements au cœur des CIS Controls. Elles se demandent toujours : quel est l'état attendu ? Qu'est-ce qui en a dévié ? Cette déviation était-elle autorisée ? Pouvons-nous le prouver ?

Ce sont les bonnes questions. Les outils qui aident à y répondre — détection des changements en temps réel, bases de référence de configuration, réconciliation des changements planifiés vs non planifiés, historique judiciaire de qui a changé quoi et quand — sont ceux qui auront le plus d'importance à mesure que l'autonomie dans les environnements informatiques augmente.

C'est exactement ce pour quoi Netwrix Change Tracker a été conçu.