Sécuriser ce dont on ne peut pas lister les comportements
L’ingénieur sécurité IA prolonge la sécurité applicative sur un terrain où deux de ses hypothèses de base tombent. La première est que les entrées peuvent être validées : ici, une entrée légitime est du texte libre, et un système qui lit un courriel, un document ou une page traite un contenu que personne ne contrôle, éventuellement rédigé pour infléchir son comportement. La seconde est que les comportements peuvent être énumérés : ici, le nombre de chemins possibles dépend du nombre d’outils et de la longueur de la boucle, et il devient très grand très vite. La conséquence méthodologique est nette : il faut renoncer à la question habituelle, celle de savoir ce que le système fera, et la remplacer par une autre, beaucoup plus solide, celle de savoir ce qu’il lui est matériellement possible de faire avec les droits accordés. Une équipe capable de répondre à la seconde est mieux protégée qu’une équipe qui a listé cent scénarios d’attaque, parce que sa réponse reste vraie face à la situation que personne n’avait imaginée.
Ingénieur sécurité IA, en bref
Métier émergent| En une phrase | Sécurise des systèmes dont les entrées sont du texte non fiable et dont le comportement ne s’énumère pas entièrement. |
|---|---|
| Jugé sur | Le fait qu’un attaquant puisse ou non faire agir le système au-delà des droits qui lui ont été accordés. |
| Échoue quand | Le modèle de menace a été écrit pour du logiciel et le système est un agent porteur d’une habilitation d’écriture. |
| Confondu avec | La sécurité applicative, qu’il prolonge plutôt qu’il ne la remplace. |
Un travail réel, dont le périmètre varie assez d’un employeur à l’autre pour que l’intitulé seul n’apprenne pas grand-chose. Aucun chiffre de rémunération : voir notre méthode.
Le modèle de menace, réécrit
Le travail commence par une liste que peu d’organisations possèdent : quels outils le système peut appeler, sur quels objets, avec quels droits, et lesquels de ces gestes sont irréversibles.
Cette liste est plus utile qu’un catalogue d’attaques, pour une raison simple : elle borne ce qui est possible, alors qu’un catalogue borne ce qui a été imaginé. Elle se maintient à jour, ce qui suppose qu’un ajout d’outil déclenche une revue, et c’est la discipline qui protège le plus efficacement dans la durée.
Elle répond en outre à la première question posée après un incident, ce qui transforme les premières heures d’une crise en travail utile plutôt qu’en reconstitution.
La séparation qui traite le risque principal
Le risque propre à ces systèmes est qu’un contenu extérieur obtienne une action. La mesure qui le traite est structurelle : un composant qui lit du contenu non fiable ne porte pas les habilitations qui permettent d’agir.
Il produit une proposition, et une étape distincte, écrite et prévisible, décide de l’exécuter selon des règles que personne ne peut infléchir par du texte. Cette séparation coûte peu quand elle est prévue dès la conception, et cher quand il faut la rétrofitter sur un système dont les outils ont été ajoutés un par un.
Elle ne supprime pas le risque qu’une proposition soit mauvaise, qui reste un problème de qualité et se traite par la mesure. Elle supprime la classe d’incidents la plus grave, celle où le système agit contre l’intérêt de son propriétaire.
Pourquoi les consignes ne sont pas des contrôles
Dire à un système de refuser certaines choses est un contrôle qui repose entièrement sur son interprétation, et qui fonctionne dans les cas prévus. Les cas prévus ne sont pas ceux qui posent problème.
Restreindre une habilitation est d’une autre nature : si le jeton ne permet pas d’écrire, aucun raisonnement, aucune formulation habile et aucune situation inédite ne permettra d’écrire. C’est la seule propriété qui compte pour un contrôle de sécurité.
Les consignes gardent leur utilité pour orienter la qualité des réponses. Une équipe qui les compte comme barrières croit disposer d’une protection alors qu’elle n’a exprimé qu’une préférence, et cette confusion est le défaut le plus répandu des dispositifs actuels.
Ce que le métier exige en plus
La compétence supplémentaire n’est pas d’entraîner des modèles, elle est de comprendre comment ces systèmes décident : pourquoi une recherche remonte un passage plutôt qu’un autre, pourquoi une boucle s’allonge, ce qui pousse un système à appeler un outil.
Sans cette compréhension, les contrôles sont placés aux mauvais endroits, généralement en bordure du système alors que le problème se joue à l’intérieur de sa boucle de décision.
C’est pourquoi les profils qui tiennent ce poste viennent presque toujours de la sécurité applicative et non de la recherche. Ils apportent la discipline du métier, et ils ajoutent en quelques mois la compréhension du comportement qui leur manquait, ce qui est le sens le plus rapide dans lequel la double compétence se construit.
