Meilleures pratiques pour renforcer la sécurité de l’apprentissage automatique

La sécurité de l’apprentissage automatique est essentielle pour l’entreprise

La sécurité ML a le même objectif que toutes les mesures de cybersécurité : réduire le risque d’exposition de données sensibles. Si un mauvais acteur interfère avec votre modèle ML ou les données qu’il utilise, ce modèle peut produire des résultats incorrects qui, au mieux, compromettent les avantages du ML et, au pire, ont un impact négatif sur votre entreprise ou vos clients.

« Les cadres doivent s’en soucier car il n’y a rien de pire que de faire la mauvaise chose très rapidement et en toute confiance », déclare Zach Hanif, vice-président des plateformes d’apprentissage automatique chez Capital One. Et tandis que Hanif travaille dans une industrie réglementée – les services financiers – nécessitant des niveaux supplémentaires de gouvernance et de sécurité, il dit que chaque entreprise adoptant ML devrait saisir l’occasion d’examiner ses pratiques de sécurité.

Devon Rollins, vice-président de la cyber-ingénierie et de l’apprentissage automatique chez Capital One, ajoute : « La sécurisation des applications critiques pour l’entreprise nécessite un niveau de protection différencié. Il est prudent de supposer que de nombreux déploiements d’outils ML à grande échelle sont essentiels compte tenu du rôle qu’ils jouent pour l’entreprise et de leur impact direct sur les résultats pour les utilisateurs. »

Nouvelles considérations de sécurité à garder à l’esprit

Alors que les meilleures pratiques pour sécuriser les systèmes ML sont similaires à celles de tout système logiciel ou matériel, une plus grande adoption du ML présente également de nouvelles considérations. « L’apprentissage automatique ajoute une autre couche de complexité », explique Hanif. « Cela signifie que les organisations doivent tenir compte des multiples points d’un flux de travail d’apprentissage automatique qui peuvent représenter des vecteurs entièrement nouveaux. » Ces éléments de flux de travail de base incluent les modèles ML, la documentation et les systèmes autour de ces modèles et les données qu’ils utilisent, ainsi que les cas d’utilisation qu’ils permettent.

Il est également impératif que les modèles ML et les systèmes de support soient développés en tenant compte de la sécurité dès le départ. Il n’est pas rare que les ingénieurs s’appuient sur des bibliothèques open source librement disponibles développées par la communauté des logiciels, plutôt que de coder chaque aspect de leur programme. Ces bibliothèques sont souvent conçues par des ingénieurs en logiciel, des mathématiciens ou des universitaires qui ne sont peut-être pas aussi versés dans l’écriture de code sécurisé. « Les personnes et les compétences nécessaires pour développer des logiciels ML hautes performances ou de pointe peuvent ne pas toujours se croiser avec le développement de logiciels axés sur la sécurité », ajoute Hanif.

Selon Rollins, cela souligne l’importance de nettoyer les bibliothèques de code open source utilisées pour les modèles ML. Les développeurs doivent envisager de considérer la confidentialité, l’intégrité et la disponibilité comme un cadre pour guider la politique de sécurité des informations. La confidentialité signifie que les actifs de données sont protégés contre tout accès non autorisé ; l’intégrité fait référence à la qualité et à la sécurité des données ; et la disponibilité garantissent que les bons utilisateurs autorisés peuvent facilement accéder aux données nécessaires pour le travail en cours.

De plus, les données d’entrée ML peuvent être manipulées pour compromettre un modèle. L’un des risques est la manipulation des inférences, qui consiste essentiellement à modifier les données pour tromper le modèle. Étant donné que les modèles ML interprètent les données différemment du cerveau humain, les données peuvent être manipulées de manière imperceptible par les humains, mais qui modifient néanmoins les résultats. Par exemple, tout ce qu’il faut pour compromettre un modèle de vision par ordinateur peut être de changer un pixel ou deux dans une image d’un panneau d’arrêt utilisé dans ce modèle. L’œil humain verrait toujours un panneau d’arrêt, mais le modèle ML pourrait ne pas le catégoriser comme un panneau d’arrêt. Alternativement, on pourrait sonder un modèle en envoyant une série de données d’entrée variables, apprenant ainsi comment le modèle fonctionne. En observant comment les entrées affectent le système, explique Hanif, des acteurs extérieurs pourraient découvrir comment déguiser un fichier malveillant afin qu’il échappe à la détection.

Un autre vecteur de risque est constitué par les données utilisées pour entraîner le système. Un tiers pourrait « empoisonner » les données de formation afin que la machine apprenne quelque chose de manière incorrecte. Par conséquent, le modèle formé fera des erreurs, par exemple en identifiant automatiquement tous les panneaux d’arrêt comme des panneaux de cession.