Cybersécurité et intelligence artificielle générative
Les nouveaux risques liés aux LLMs
Hello world !
Si vous trouvez cette newsletter utile, vous pouvez vous abonner et la partager. N'hésitez pas à me faire part de vos questions et vos feedbacks. Merci !
Shadow AI
Selon le rapport X-Force IBM, la surface d’attaque concernant l’IA générative augmentera avec la maturité du marché. Si une technologie IA détient 50% de part de marché, l'écosystème cybercriminel investira dans le développement de malware.
Un monitoring des forums darkweb révèle une hausse de 800K de sujets autour l’IA générative, ChatGPT, LLMs, etc.
l’IA générative apporte sa part de failles sécuritaires et son usage peut présenter également des nouvelles portes d’entrée pour les hackers. Shadow AI est un terme émergent qui désigne l’utilisation des outils d’intelligence artificielle non approuvés ou réglementés par l’IT par des employés pour effectuer leur travail. Cette utilisation en mode sous-marin menace la sécurité des entreprises : fuite de données, risque de générer des analyses incorrectes ou de générer des réponses non conforme à une procédure déjà en place, etc.
Selon une étude Salesforce, 58% des employés français avouent utiliser l’IA générative en dehors d’un cadre défini par leur entreprise.
La sensibilisation de tous les collaborateurs aux risques est aussi primordiale que la formation aux usages des IA génératives. Un collaborateur non averti des risques cliquera sur un lien de phishing !
Les risques :
Open Web Application Security Project livre le rapport : OWASP Top 10 For Large Language Model Applications. Ce rapport liste les 10 vulnérabilités critiques des applications LLMs.
Prompt injection ou jailbreaking : nous fait penser à SQL injection. L’objectif est de pousser le LLM à générer du contenu faux, indésirable ou nuisible. Il y a deux types d’injections : directe via un prompt soumis à un LLM ou indirecte via un prompt caché dans les données.
Insecure output handling : autrement dit, l’output d’un LLM doit montrer patte blanche avant d’être manipulé par d’autres composants de l’application.
Training data poisining : les données d’apprentissage sont en soi altérées : contaminées par des données fausses, nuisibles, indésirables et qui compromettent l’efficacité et le comportement éthique du LLM.
Model denial of service : nous fait penser au déni de service (Denial of service), une attaque qui a pour but de rendre un service indisponible, inaccessible pour les utilisateurs. Dans les cas des LLMs, qui sont par nature très coûteux. Une attaque qui vise à saturer le service par des envois de prompts peut coûter encore plus cher.
Supply chain vulnerabilities : Toute la supply chain doit être contrôlée. Si on utilise des données tiers pour l’apprentissage ou le fine tuning, ou un modèle pré-entraîné, un plugin ou une API, le tout doit être contrôlé et authentifié. La récente nouvelle sur l’existence d’une centaine de modèles malveillants sur Hugging Face, rappelle que l’open source doit redoubler de prudence.
Sensitive information disclosure : un LLM peut involontairement donner accès à des informations sensibles et confidentielles. Il faut mettre à l’abri toutes les données qui ne doivent pas être exploitées par un LLM.
Insecure plugin design : Contrôler tous les plugins appelés par le LLM pour éviter d’utiliser un avec des failles de sécurité.
Excessive Agency : accorder à un LLM une degré d’autonomie pour s’interfacer avec d’autres systèmes et prendre des décisions. Le LLM devient un agent avec des privilèges qui peuvent être exploités pour lancer des attaques.
Overreliance : une sur confiance accordée par un système ou un utilisateur à un LLM pour prendre des décisions ou générer du contenu sans contrôle suffisant ou sans esprit critique.
Model theft : un LLM privé ou propriétaire peut être volé par extraction de ses connaissances qui sont le fruit d’un long et coûteux entraînement.
La checklist OWASP pour sécuriser les applications LLMs
Si vous ne savez pas par quel bout commencer pour sécuriser vos projets AI-driven, OWASP checklist peut vous guider et aider à cocher les cases pour éviter les attaques sur le LLM, sur les données et l'infrastructure.
Cette checklist liste 13 points de vigilance :
Adversarial Risk : garder l'œil aussi bien sur les concurrents que sur les hackers.
Threat Modeling : la modélisation des menaces est un ensemble de processus systématiques et répétables qui permettent de prendre des décisions de sécurité raisonnables pour les applications, les logiciels et les systèmes.
AI asset inventory : un inventaire des assets d’IA en termes de données, de solutions internes ou externes mais aussi en compétence humaine.
AI security and privacy training : pour tous les employés, on doit mettre en place formation, sensibilisation, communication et acculturation aux risques, à la sécurité et la confidentialité dans les projets AI-driven.
Establish business cases : lister les cas d’usage à plus haute valeur. Tester et évaluer le retour sur investissement.
Governance : ajouter une dimension IA générative dans la gouvernance.
Legal : examiner les licences des solutions utilisées. respect de la confidentialité, de la propriété intellectuelle, des données personnelles, etc.
Regulatory : se conformer aux réglementations et se préparer aux éventuels changements dans la législation. Dans le cas de l’IA générative, le terrain est encore à découvrir.
Using or implementing LLMs : être avisé de toutes les vulnérabilités des LLMs.
Testing, Evaluation, Verification and Validation (TEVV) : un processus continu tout au long du cycle de vie de l’écosystème IA, une recommandation donnée par le National Institute of Standards and Technology NIST.
Model cards and Risk cards : l’un pour documenter le design, les capacités et les contraintes, et l'autre pour documenter les risques, les inconvénients et les points de vigilances.
RAG / LLMs optimization : Retrieval augmented generation pour optimiser les LLMs, les spécialiser sur un domaine donnée et garantir une réponse basée sur les données de l’entreprise.
AI Red teaming : simuler une cyberattaque pour tester les processus en place d’identification des assets à protéger, les protections (backups, crypto), les détections des malwares, les réponses apportées, la remise en état (recovery) et la communication suite à l’incident.
En cybersécurité, le zéro risque n’est pas garanti. Cependant, il faut avoir un processus qui permet :
d’identifier les assets sensibles,
de les protéger via crypto ou backups,
de détecter les malware,
de résoudre l’incident,
de restaurer l’intégrité des systèmes affectés,
et d’exécuter un plan de communication suite à l’incident.
J’espère que cet article vous a aidé à y voir un peu plus clair. Merci de m’avoir lu.
N'hésitez pas à me faire un feedback ou me dire ce qui pourrait vous intéresser comme sujet.
A bientôt!
Sofia
Malware attacks and robot going crazy. By Designer Microsoft.
Sources :