MLSecOps : les bonnes pratiques pour sécuriser l’IA

Les risques liés à l’adoption de l’IA

Les modèles de machine learning et d’IA peuvent aider les entreprises à accroître leur efficacité, en automatisant des tâches répétitives, en améliorant le service client ou en réduisant certains coûts opérationnels. Parfois, ces algorithmes promettent de conserver des avantages concurrentiels.

Cependant, leur adoption introduit également des risques à différents niveaux, notamment pendant les phases de développement et de déploiement. Les risques les plus significatifs sont les suivants :

• Biais. Les outils d’IA peuvent produire des résultats biaisés en fonction des données sur lesquelles ils ont été entraînés.
• Violation de la vie privée, du droit d’auteur et de la propriété intellectuelle. Les systèmes d’IA sont souvent formés sur de grandes quantités de données, et il n’est parfois pas clair si les propriétaires de ces données ont donné leur consentement pour ce faire.
• Logiciels malveillants. Si la compromission de résultats ou la génération de contenus fallacieux obtenus après modification d’un algorithme ou d’un réseau de neurones semble peu rentable pour un cyberattaquant, ce risque n’est toutefois pas nul.
• Plugins non sécurisés. De nombreux LLM permettent l’utilisation de plugins pour recevoir du texte de forme libre. Un texte d’entrée mal conçu pourrait exécuter un code malveillant à distance, ce qui entraînerait une attaque par élévation de privilèges.
• Attaques de la chaîne d’approvisionnement. Bon nombre d’outils et de modèles utilisés par les entreprises et les éditeurs sont d’abord accessibles en open source. Plus probables que la modification d’un modèle, ces librairies logicielles peuvent être des portes d’entrée dans le système d’information de l’entreprise.
• Risques pesant sur l’infrastructure IT. Simplement, les attaquants peuvent tenter de perturber le fonctionnement d’un service d’IA en s’adonnant à des attaques de déni de service. Autre possibilité, si la compromission de la supply chain logicielle de l’entreprise intéresse fortement un attaquant, l’accès à la puissance de calcul utilisée pour entraîner ou déployer des modèles l’est tout autant. Les serveurs ou les accès aux instances peuvent être exploités pour mener d’autres attaques.

Le MLSecOps et ses principaux avantages

Le terme MLOps fait référence au processus d’opérationnalisation des modèles de machine learning en production. Il implique plusieurs phases :

• La sélection de l’algorithme et des jeux de données d’entraînement.
• Le nettoyage et le prétraitement des données d’entraînement pour le modèle ML.
• L’entraînement du modèle et l’évaluation de ses performances en regard d’indicateurs tels que l’exactitude et la précision.
• Son déploiement en production.
• La surveillance continue du modèle après le déploiement pour garantir son bon fonctionnement dans le temps et dans un contexte opérationnel donné.

L’approche MLSecOps, comme son nom l’indique, est une extension naturelle du MLOps. Tout comme l’approche DevOps a évolué vers le DevSecOps en intégrant des pratiques de sécurité dans le cycle de développement logiciel, le MLSecOps veille à ce que les modèles ML soient entraînés, testés, déployés et surveillés en utilisant les meilleures pratiques de sécurité.

Cette intégration assure la sécurité des modèles ML dans deux domaines :

• La sécurité des données utilisées pour former et tester les modèles IA/ML.
• La sécurité de l’infrastructure exploitée pour les entraîner et les déployer.

Les 5 piliers de la sécurité dans l’approche MLSecOps

1.   Lutte contre les vulnérabilités dans la chaîne d’approvisionnement

Comme n’importe quelle chaîne d’approvisionnement logicielle, celle utilisée pour entraîner ou déployer des modèles d’IA est dépendante de multiples composants :

• Des librairies logicielles et des composants matériels de fournisseurs externes.
• Des services d’hébergement tiers.
• Des services réseau spécifiques pour faire le lien entre le modèle et l’application qui l’utilise.

Ce sont des points d’entrée qu’il faut surveiller. C’est d’autant plus important que les autorités se montrent de plus en plus alertes en la matière.

Les États-Unis ont été les premiers à s’attaquer aux aspects sécuritaires de la chaîne d’approvisionnement en logiciels. En 2021, l’Administration Biden a publié le décret 14028, qui impose à toutes les organisations des secteurs public et privé de remédier aux failles de sécurité de leur chaîne d’approvisionnement. En Europe, des initiatives similaires sont soit en place, soit en cours d’élaboration.

2.   Vérification de la provenance des modèles

La provenance du modèle concerne le suivi de l’historique d’un système de ML au cours de son entraînement, de ses tests, de son déploiement, de sa surveillance et de son utilisation. La provenance du modèle aide les auditeurs de sécurité à identifier les personnes ou les entités qui ont apporté des modifications spécifiques au modèle, la nature de ces modifications et le moment où elles ont eu lieu.

Voici quelques éléments attendus :

• Les sources de données utilisées pour entraîner le modèle de ML.
• Les modifications apportées aux algorithmes de ML.
• Les informations concernant les modèles réentraînés, y compris la date de réentraînement, les nouvelles données d’entraînement et les sources de ces données.
• L’utilisation du modèle de ML au fil du temps.

La provenance des modèles est essentielle pour se conformer aux diverses réglementations de conformité en matière de protection des données, telles que le RGPD dans l’Union européenne, l’HIPAA et le CCPA aux États-Unis et les réglementations spécifiques à l’industrie telles que les normes de paiement (PCI DSS, BCBS 239, etc.) et bientôt l’AI Act.

3.   Gouvernance, analyse des risques et conformité

Les cadres de gouvernance, de risque et de conformité (GRC) sont utilisés au sein des organisations pour répondre aux réglementations imposées par le gouvernement et l’industrie. Pour les systèmes de ML, la GRC couvre plusieurs éléments du MLSecOps, avec pour objectif principal de garantir que les organisations utilisent les outils d’IA de manière responsable et éthique.

Par exemple, lors du développement d’un système ML, les entreprises devraient tenir une liste de tous les composants utilisés dans le développement, y compris les jeux de données, les algorithmes et les frameworks. Cette liste est désormais connue sous le nom de « machine learning bill of materials » (MLBoM), un inventaire cousin du SBOM (Software Bill Of Materials). À l’instar d’une nomenclature logicielle pour les projets de développement de logiciels, les MLBoM documentent tous les composants et services utilisés pour créer des outils d’IA et leurs modèles de ML sous-jacents.

4.   IA de confiance

L’IA de confiance traite des aspects éthiques de l’utilisation des outils d’IA pour différents cas d’usage. Ils sont de plus en plus utilisés par des entreprises ou des organisations publiques pour accomplir des tâches critiques. Il est de plus en plus nécessaire de s’assurer que les outils d’IA et leurs modèles ML sous-jacents donnent des réponses éthiques et ne sont pas biaisés par des caractéristiques telles que la race, le sexe, l’âge, la religion, l’éthique ou la nationalité.

L’une des méthodes permettant de vérifier l’équité des systèmes d’IA consiste à imposer dès la conception du modèle des moyens d’expliquer les résultats. Par exemple, si un utilisateur demande à un outil d’IA générative de lui recommander le meilleur pays à visiter en été, le modèle doit justifier sa réponse. Cette explication aide les humains à comprendre quels facteurs ont influencé la décision.

5.   Attaques par exemples contradictoires

L’apprentissage automatique antagoniste s’intéresse à la façon dont les utilisateurs peuvent exploiter les systèmes d’IA de diverses manières, pour mener des actions malveillantes. Il existe quatre types d’attaques par exemples contradictoires :

• Empoisonnement. Les attaquants injectent des données malveillantes dans les jeux de données d’entraînement du modèle, ce qui les amène à produire des réponses incorrectes.
• Évasion. Cette attaque se produit une fois que le modèle de ML a fini de s’entraîner. Elle consiste à envoyer des messages spécialement conçus au système de ML pour obtenir des réponses incorrectes. Par exemple, certains prompts permettaient au lancement de ChatGPT de lui faire générer des contenus insultants ou proscrits.
• Inférence. Il s’agit d’effectuer une rétro-ingénierie du modèle de ML afin de révéler les données utilisées pour entraîner le modèle, qui peuvent contenir des informations très sensibles.
• Extraction. Dans cette attaque, les attaquants tentent d’extraire ou de reproduire soit l’intégralité du modèle de ML, soit uniquement les données utilisées pour l’entraîner.

Une partie de ces techniques sont exploitées par les membres des « red teams » afin de prévenir les dérives des modèles et les usages malveillants.

Les meilleures pratiques MLSecOps

Les équipes de data science peuvent utiliser efficacement la méthodologie MLSecOps pour atténuer les cyberattaques lors de l’élaboration de modèles de ML. Voici quelques bonnes pratiques :

• Identifier les menaces. Il s’agit de lister les vecteurs d’attaque potentiels liés au développement des ML. Par exemple, il existe des vulnérabilités de sécurité particulières liées au développement de ML, telles que l’empoisonnement des données, l’extraction de modèles et les attaques par exemple contradictoires.
• Sécuriser les données du modèle. Si les données utilisées pour entraîner le modèle contiennent des informations sensibles, telles que des informations d’identification personnelle des clients, celles-ci doivent être dûment traitées par le biais d’un chiffrement ou de méthodes de pseudonymisation.
• Utiliser des sandbox. L’environnement de développement des modèles de ML doit être isolé de l’environnement de production. Cela permet de s’assurer que les attaquants ne peuvent pas accéder aux modèles de ML pendant la phase de développement, au cours de laquelle le modèle est testé et peut être mal protégé.
• Recherche de vulnérabilités et de malwares. Tous les composants logiciels utilisés pour créer le modèle de ML, en particulier les composants open source, doivent être analysés à la recherche de logiciels malveillants et d’autres failles de sécurité. Les composants provenant de fournisseurs tiers doivent faire l’objet d’une analyse approfondie pour s’assurer qu’ils ne présentent pas de failles de sécurité.
• Effectuer des tests dynamiques. Les tests dynamiques consistent à fournir des instructions malveillantes au modèle de ML pendant les tests pour s’assurer qu’il peut les traiter. Ceci est essentiel pour les modèles qui sont exposés à l’Internet.

Nihad A. Hassan est un consultant indépendant en cybersécurité, un expert en criminalité numérique et en renseignement de source ouverte (OSINT), ainsi qu’un blogueur et un auteur de livres. Depuis plus de 15 ans, Nihad Hassan mène des recherches dans divers domaines de l’IT et a élaboré de nombreux cours et guides techniques sur la cybersécurité.