Dans le contexte du rôle croissant de l’intelligence artificielle (IA) dans divers domaines, la question de son impact sur le marché du travail en cybersécurité devient de plus en plus pertinente. D’une part, l’automatisation et les systèmes intelligents peuvent considérablement accélérer et améliorer les processus de protection des données et de l’infrastructure informatique. D’autre part, il existe une crainte que l’IA puisse remplacer les humains dans certaines fonctions, ce qui entraînerait une réduction du nombre d’emplois disponibles. D’après mes observations, ce sera tout le contraire (du moins pour les spécialistes en sécurité) !
Les possibilités de l’IA en cybersécurité
L’IA a la capacité d’analyser d’énormes quantités de données en peu de temps, ce qui est crucial en cybersécurité, où la rapidité de réaction aux menaces est souvent décisive. Les algorithmes d’apprentissage automatique peuvent détecter des menaces inconnues en se basant sur l’analyse des schémas de comportement et des données historiques. Cela permet une identification et une réaction plus rapides et plus précises aux incidents de sécurité. L’automatisation des processus d’analyse et de réponse aux menaces peut entraîner une réduction des postes pour les analystes de sécurité de niveau inférieur, qui se consacrent à la surveillance et à la réaction aux alarmes de routine. En revanche, de nouvelles spécialités apparaissent, telles que l’ingénierie de l’apprentissage automatique en cybersécurité, la gestion des systèmes de défense intelligents ou l’analyse des menaces avancées utilisant l’IA. Les spécialistes devront non seulement comprendre le fonctionnement des outils modernes d’IA, mais aussi être capables de les développer et de les adapter aux besoins spécifiques en matière de sécurité.
Automatisation de la création de code = plus d’erreurs de sécurité + nouvelles classes de vulnérabilités
Introduction d’erreurs par des outils automatiques
Jamais auparavant la création d’applications n’a été aussi simple, accessible aux personnes non techniques et rapide. Cela entraîne une prolifération de nouvelles applications. En parallèle, on assiste à une vague d’intégration d’éléments d’IA dans les logiciels existants. Cependant, l’automatisation, en particulier sous forme de générateurs de code ou de frameworks de développement, peut entraîner des erreurs et des failles de sécurité non intentionnelles. Ces outils, fonctionnant sur la base de modèles et d’algorithmes établis, peuvent ne pas tenir compte des conditions spécifiques ou des subtilités de sécurité comprises et appliquées par des programmeurs expérimentés. Par exemple, le code généré automatiquement peut ne pas être suffisamment protégé contre des attaques telles que l’injection SQL ou le Cross-site Scripting (XSS), si l’outil n’est pas correctement configuré pour tenir compte de ces menaces.
XSS dans Zoomin Zdocs
Un exemple de telle erreur est un simple « Reflected Cross-site Scripting » trouvé par moi dans l’application Zoomin Zdocs. Introduire un assistant IA pour gérer la documentation d’une application semble être une excellente idée, car on peut lui poser des questions pour savoir comment utiliser un logiciel donné. Cependant, il faut se rappeler que les réponses de l’IA peuvent être imprévisibles et provoquer des erreurs de sécurité. Dans l’application Zoomin, il suffisait de demander à l’assistant ce qu’il pensait de :
<img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?
pour qu’il réponde qu’il ne pouvait pas trouver de réponse à notre question, en la citant :
I'm sorry, but I couldn't find a definitive answer to: <img src=1 href=1 onerror="javascript:alert(document.domain)"></img>?. Please provide more context or clarify your query.
La requête entière ressemblait à ceci :
POST /api/aisearch/stream HTTP/1.1 |
Réponse du serveur :
HTTP/2 200 OK |
Comme on peut le voir, les données d’entrée n’ont pas été correctement validées et désinfectées, ce qui a entraîné l’exécution du code javascript injecté :
Pseudocode exemple avec affichage incorrect de la réponse :
function displayResponse(userInput):
# Lire les données d'entrée de l'utilisateur
query = userInput
# Afficher la réponse sans désinfection des données d'entrée
# Cela est incorrect, car cela permet l'exécution du script contenu dans userInput
print("Réponse à votre question: " + query)
Pseudocode exemple avec affichage correct de la réponse :
function sanitize(input):
# Supprimer ou encoder les caractères spéciaux HTML dans les données d'entrée, ex. <, >, ", ' et autres
return input.replace("<", "<").replace(">", ">").replace("\"", """).replace("'", "'")
function displayResponse(userInput):
# Lire les données d'entrée de l'utilisateur
query = userInput
# Désinfecter les données d'entrée
safeQuery = sanitize(query)
# Afficher la réponse en toute sécurité
# La désinfection empêche l'exécution de code malveillant
print("Réponse à votre question: " + safeQuery)
La vulnérabilité (ainsi qu’une série d’autres) a été signalée et corrigée par le fabricant.
Réplication des erreurs
L’un des principaux défauts de l’automatisation est la réplication du même code à plusieurs endroits, ce qui peut entraîner une propagation massive des erreurs ou des vulnérabilités. Lorsqu’une erreur se trouve dans un composant générateur de code (et que l’IA peut être formée sur du code contenant des erreurs), chaque application ou système utilisant ce code est potentiellement exposé. Ce phénomène amplifie le problème de sécurité, le rendant plus difficile à gérer et à corriger.
Difficultés d’audit et de révision du code
Le code généré automatiquement est souvent complexe ou généré de manière non intuitive pour les programmeurs humains. Cela peut compliquer les révisions manuelles du code, essentielles pour identifier des erreurs logiques subtiles ou des vulnérabilités de sécurité. Le manque de transparence et de compréhension du code généré peut conduire à l’omission de problèmes importants lors des tests de sécurité.
Nouvelles classes de vulnérabilités
L’automatisation peut introduire de nouvelles classes de vulnérabilités qui seraient moins probables en cas de création manuelle du code. Par exemple, les dépendances entre modules générés automatiquement peuvent ne pas être complètement comprises ou contrôlées par les développeurs, ouvrant la voie à des attaques liées aux dépendances et à la logique des applications. De nouvelles classes de vulnérabilités apparaissent également, comme l’injection de prompt.
OWASP Top 10 pour les applications de modèles linguistiques étendus
OWASP a lancé un projet il y a un an pour identifier et émettre des recommandations de protection contre les principales menaces résultant de l’utilisation de LLMA – OWASP Top 10 for LLLM. La liste est la suivante :
LLM01 : Injection de prompt
La manipulation d’un grand modèle linguistique (LLM) par des entrées de données appropriées provoque des actions non intentionnelles de la part du LLM. Les injections directes remplacent les prompts système, tandis que les injections indirectes manipulent les données de sources externes.
LLM02 : Manipulation dangereuse des sorties
La vulnérabilité se produit lorsque les sorties LLM sont acceptées sans vérification, ce qui peut exposer les systèmes backend. L’exploitation peut entraîner des conséquences graves telles que XSS, CSRF, SSRF, escalade des privilèges ou exécution de code à distance.
LLM03 : Empoisonnement des données d’entraînement
Elle se produit lorsque les données d’entraînement LLM sont manipulées, introduisant des vulnérabilités ou des erreurs affectant la sécurité, l’efficacité ou le comportement éthique. Les sources incluent Common Crawl, WebText, OpenWebText et des livres.
LLM04 : Détournement du modèle
Les attaquants provoquent des opérations consommatrices de ressources sur le LLM, entraînant une dégradation du service ou des coûts élevés. La vulnérabilité est aggravée par l’intensité des ressources du LLM et l’imprévisibilité des entrées utilisateur.
LLM05 : Vulnérabilités de la chaîne d’approvisionnement
Le cycle de vie des applications LLM peut être compromis par des composants ou services vulnérables, entraînant des attaques de sécurité. L’utilisation de jeux de données externes, de modèles pré-entraînés et de plugins peut augmenter le nombre de vulnérabilités.
LLM06 : Divulgation d’informations sensibles
LLM peut divulguer involontairement des données sensibles dans ses réponses, entraînant un accès non autorisé aux données, des violations de la vie privée et des violations de la sécurité. Il est essentiel de mettre en œuvre la désinfection des données et des politiques d’utilisation strictes pour prévenir cela.
LLM07 : Conception dangereuse des plugins
Les plugins LLM peuvent avoir des entrées non sécurisées et un contrôle d’accès insuffisant. Le manque de contrôle des applications facilite l’exploitation et peut entraîner des conséquences telles que l’exécution de code à distance.
LLM08 : Autonomie excessive
Les systèmes basés sur LLM peuvent prendre des mesures entraînant des résultats non intentionnels. Le problème résulte d’une fonctionnalité excessive, de privilèges trop étendus ou de l’autonomie accordée aux systèmes basés sur LLM.
LLM09 : Dépendance excessive
Les systèmes ou les personnes trop dépendants de LLM sans supervision peuvent être exposés à la désinformation , aux erreurs de communication, aux problèmes juridiques et aux erreurs de sécurité en raison de contenus incorrects ou inappropriés générés par LLM.
LLM10 : Vol de modèle
Il s’agit de l’accès non autorisé, de la copie ou du vol de modèles LLM propriétaires. L’impact inclut des pertes économiques, la perte d’un avantage concurrentiel et un accès potentiel à des informations sensibles.
Que faire? Comment vivre?
OWASP, avec la liste Top 10 for LLLM, a publié une série de recommandations pour une approche sécurisée de l’implémentation des LLM dans votre organisation – LLM AI Cybersecurity & Governance Checklist. Celles-ci concernent la programmation, que je présente ci-dessous :
- Modélisez les menaces pour les composants LLM et définissez les limites de confiance de l’architecture.
- Sécurité des données : vérifiez comment les données sont classées et protégées en fonction de leur sensibilité, y compris les données personnelles et d’entreprise. (Comment les autorisations des utilisateurs sont-elles gérées et quels mécanismes de protection sont mis en place ?)
- Contrôle d’accès : mettez en œuvre des contrôles d’accès basés sur le principe du moindre privilège et appliquez des mesures de défense en profondeur.
- Sécurité du processus de formation : exigez un contrôle rigoureux de la gestion des données de formation, des processus, des modèles et des algorithmes.
- Sécurité des entrées et des sorties : évaluez les méthodes de validation des entrées ainsi que la façon dont les sorties sont filtrées, désinfectées et validées.
- Surveillance et réponse : cartographiez le flux de travail, surveillez et réagissez pour comprendre l’automatisation, assurez-vous de la journalisation et de l’audit. Confirmez la sécurité des enregistrements d’audit.
- Intégrez les tests d’application, les revues de code source, le processus d’évaluation des vulnérabilités et les tests de pénétration dans le processus de développement du produit.
- Vérifiez les vulnérabilités existantes dans le modèle LLM ou la chaîne d’approvisionnement.
- Considérez l’impact des menaces et des attaques sur les solutions LLM, telles que l’injection de prompts, la divulgation d’informations sensibles et la manipulation du modèle.
- Examinez l’impact des attaques et des menaces sur les modèles LLM, y compris l’empoisonnement du modèle, la mauvaise manipulation des données, les attaques de la chaîne d’approvisionnement et le vol de modèle.
- Sécurité de la chaîne d’approvisionnement : exigez des audits de tiers, des tests de pénétration et des revues de code pour les fournisseurs externes (tant au départ que dans le processus régulier).
- Sécurité de l’infrastructure : interrogez la fréquence des tests de résilience effectués par le fournisseur. Quelles sont leurs SLA en termes de disponibilité, de scalabilité et de performance ?
- Mettez à jour les manuels de réponse aux incidents et incluez les incidents liés aux LLM dans le scénario d’exercice de sécurité régulier.
- Identifiez ou élargissez les métriques pour comparer l’IA générative en cybersécurité avec d’autres approches afin de mesurer l’amélioration attendue des performances.
