L'année dernière, l'essor de l'intelligence artificielle générative (IA générative) a également mis sur le devant de la scène les grands modèles de langage (LLM) polyvalents. Les entreprises s'empressent désormais d'exploiter les capacités des LLM afin d'améliorer leur service client, d'optimiser leurs tâches, de créer du contenu et d'accroître leur productivité globale.

Avec la multiplication rapide des applications intégrant l'IA, comme les LLM, le risque de failles associées augmente. Les entreprises veulent être les premières sur le marché, mais malheureusement, cela relègue souvent la sécurité au second plan.

Or, comme pour toute nouvelle application, il est crucial d'évaluer les mesures de sécurité mises en place. Bien qu'il existe des similitudes avec les approches traditionnelles d'évaluation des applications, il y a également des différences subtiles à prendre en compte lors de la conception, de la création et de l'évaluation d'applications basées sur l'IA de manière générale.

^{Les LLM sont de grands réseaux de neurones entraînés sur de vastes ensembles de données. Selon le type d'ensemble de données sur lequel ils sont entraînés, ils peuvent être personnalisés pour effectuer diverses tâches, comme générer, traduire et résumer du texte, mais aussi répondre à des questions générales.}

^{La plupart des organisations déploient les LLM sur le Web. Les clients et les utilisateurs peuvent ainsi interagir avec eux dans un format familier (par le biais d'une application Web), et les développeurs ont la possibilité de les exploiter de manière bien définie en utilisant des interfaces de programmation d'application Web exposées (API).} 

^{Les LLM génèrent habituellement du langage à usage général et imitent la capacité à "comprendre" les utilisateurs et leurs requêtes personnalisées. C'est ce qui rend les LLM Web particulièrement adaptés pour offrir une expérience utilisateur améliorée, comme les chatbots, les moteurs de recherche et les assistants virtuels.}

Voici les quatre caractéristiques communes à l'ensemble des LLM Web à usage général qui expliquent leur attrait.

Le prompt : il s'agit d'une requête fournie par l'utilisateur final dans l'interface de l'application qui permet de définir le contexte de l'interaction entre le LLM et l'utilisateur ainsi que la nature de la conversation. Plus le prompt est précis, plus le LLM est en mesure d'exploiter son ensemble de données pour répondre à la question de l'utilisateur.

Les API exposées : les LLM exposent sciemment une API pour qu'elle soit utilisée par l'application finale. Ces API permettent aux applications Web traditionnelles d'exploiter les capacités des LLM.

Les données : les données fournissent au modèle les informations dont il a besoin pour répondre au prompt de l'utilisateur. La qualité de ces données est essentielle. Leur quantité et leur spécificité permettent au LLM de mieux traiter la requête de l'utilisateur et de proposer une réponse à la fois utile et précise.

L'ensemble d'entraînement : il s'agit des données sur lesquelles le modèle a été entraîné initialement afin d'être adapté à son objectif final. Encore une fois, la qualité est essentielle.

À mesure que les applications Web évoluent et se généralisent, les failles qui leur sont associées font malheureusement de même. L'Open Web Application Security Project (OWASP) liste le nombre et les types de failles signalées publiquement sur des applications Web, et publie régulièrement un classement des 10 failles les plus courantes. 

Sur le même modèle, l'OWASP a créé une nouvelle liste des 10 principales failles spécifiques aux applications intégrant des LLM :

Les LLM Web ont révolutionné la façon dont les utilisateurs interagissent avec les systèmes traditionnels. Ils n'ont plus à recourir à des requêtes bien définies et structurées, mais peuvent interagir avec les applications et les systèmes de manière plus naturelle et conversationnelle. Les usages de cette technologie ne cessent de se développer au gré de la curiosité et de l'inventivité humaines.

Les applications intégrant des LLM Web peuvent être évaluées essentiellement de la même manière que les applications Web traditionnelles. Les contrôles tels que l'encodage des sorties, l'authentification et l'autorisation, la protection des données et la sécurité des API sont bien définis après de nombreuses années de tests et de mise en œuvre de la sécurité des applications.

À l'avenir, les professionnels de la sécurité devront faire évoluer leurs méthodes d'évaluation des applications pour y inclure des stratégies de tests probabilistes. L'intégration de ces tests peut aider à mieux évaluer et protéger les applications basées sur des LLM Web contre l'injection de prompt, l'excès d'autonomie et la dépendance excessive, afin de maintenir une approche de sécurité fiable et adaptée aux menaces actuelles.

En 2024, les systèmes de gestion des informations et des événements de sécurité (SIEM) restent la clé de voûte de la plupart des centres des opérations de sécurité (SOC). Les systèmes SIEM ont toujours été utilisés pour collecter et analyser les données de sécurité de l'ensemble d'une organisation afin d'identifier les menaces, de les examiner et d'y répondre. Or, les solutions SIEM d'aujourd'hui ne ressemblent plus beaucoup à celles qui ont été conçues il y a plus de 15 ans. Les solutions modernes incluent une architecture cloud native et des fonctionnalités telles que l'analyse du comportement des utilisateurs et des entités, l'orchestration de la sécurité, l'automatisation et la réponse, la gestion des surfaces d'attaque et l'intelligence artificielle, pour n'en citer que quelques-unes.

Les solutions SIEM traditionnelles sont souvent lentes, fastidieuses et difficiles à utiliser. Leur ancienne architecture les empêche souvent d'évoluer pour ingérer des sources de journaux dont le volume est élevé, et elles ne sont pas toujours en mesure de faire face aux dernières menaces ni de prendre en charge les dernières fonctionnalités. Elles n'offrent pas nécessairement la flexibilité nécessaire pour répondre aux besoins spécifiques de votre organisation et ne sont pas forcément adaptées à la stratégie multicloud que la plupart des entreprises adoptent aujourd'hui. Enfin, elles ne sont parfois pas en mesure d'exploiter les dernières avancées technologiques, comme l'IA.

Récemment, le domaine des solutions SIEM a connu des changements majeurs dont l'importance ne doit pas être sous-estimée. Ces évolutions vont accélérer la migration d'anciennes plates-formes SIEM vers des solutions modernes, et de nombreuses entreprises vont devoir se demander non pas si elles doivent migrer, mais plutôt quand elles doivent le faire. 

Principaux événements sur le marché des solutions SIEM au cours de l'année écoulée : 

Septembre 2023 :

• Cisco annonce son intention d'acquérir Splunk.

Mai 2024 :

• Crowdstrike lance une nouvelle offre SIEM.
• Exabeam et LogRhythm annoncent leur intention de fusionner.
• IBM vend son activité cloud Qradar à Palo Alto Networks et cesse de développer de nouvelles fonctionnalités pour les clients des solutions Qradar sur site.

Les experts en sécurité de Google Cloud ont observé et accompagné des centaines de migrations SIEM pendant des décennies. Nous avons ainsi pu identifier des bonnes pratiques que les entreprises de toutes tailles peuvent appliquer. Découvrez nos meilleurs conseils pour migrer votre solution SIEM en 2024.

Lorsque vous évaluez une nouvelle solution SIEM avec votre équipe de sécurité, commencez par vous poser les questions suivantes. Elles vous aideront à identifier les points forts et les points faibles de chaque option, et à déterminer celle qui répondra aux besoins de votre entreprise :

À terme, migrer d'un ancien système SIEM vers une solution moderne sera inévitable pour suivre l'évolution des menaces. Même si les défis à relever peuvent sembler intimidants, une migration bien planifiée et bien exécutée peut permettre d'améliorer nettement les fonctionnalités de détection des menaces, d'investigation et de réponse de votre entreprise, ainsi que sa stratégie de sécurité globale.

Pour obtenir un guide détaillé sur la migration SIEM, consultez le livre blanc "The great SIEM migration: A guide to ditching dinosaurs".

Si vous souhaitez en savoir plus sur la plate-forme SecOps moderne et cloud native de Google, consultez notre page Web.

Avec l'augmentation du nombre d'environnements "digital native", il est indispensable que les équipes de sécurité, et plus particulièrement les Red Team et les Blue Team, comprennent les défis de sécurité inhérents à ces nouveaux écosystèmes, car ils diffèrent de ceux rencontrés dans les déploiements sur site traditionnels. Les questions suivantes se posent alors : quels sont ces défis uniques et quelles compétences les professionnels de la cybersécurité doivent-ils posséder pour les relever ? 

Les pirates informatiques et les défenseurs ne font plus la course pour sécuriser quelques composants clés de l'infrastructure, comme un contrôleur de domaine ou un service de certificat. Désormais, chaque ressource cloud, application SSO et connexion de données représente la même menace pour une organisation. Lorsque l'architecture "digital native" repose sur des technologies telles que les API, l'IAM, Kubernetes, Docker, les fonctions sans serveur, les microservices, les bases de données cloud, le stockage, la gestion de réseaux, les pipelines CI/CD ou d'autres passerelles, chacune d'elles représente un point d'entrée potentiel pour les pirates informatiques. Sans tests de sécurité approfondis, comment une entreprise peut-elle savoir qu'une application SaaS tierce compromise pourrait donner à un pirate un accès illimité à son environnement cloud ? Le niveau d'interconnexion observé dans les environnements "digital native" matures brouille les frontières entre les applications tierces et les applications stratégiques de l'entreprise. 

Les protocoles utilisés pour mener des attaques représentent un autre défi propre aux environnements "digital native". Ces environnements étant principalement composés d'applications et de services conçus pour être accessibles via le navigateur Web d'un employé, de nombreuses attaques se produisent au niveau de la couche 7, là où les interactions avec les ressources de l'entreprise sont facilitées par des protocoles d'utilisateurs finaux courants, comme HTTP. Les professionnels de la sécurité sont ainsi contraints d'adopter le rôle d'un utilisateur dans l'environnement et d'interagir avec les applications et les services principalement par le biais d'un navigateur Web, au lieu d'utiliser des utilitaires de ligne de commande dédiés. Cette restriction augmente considérablement le travail manuel nécessaire pour dresser un tableau complet de la situation dans un nouvel environnement "digital native". 

D'un autre côté, cette focalisation sur les navigateurs a aussi pour effet de rendre les solutions traditionnelles de détection et de réponse au niveau des points de terminaison bien moins efficaces. Lorsque les utilisateurs légitimes et malveillants interagissent avec l'environnement de la même manière, cela augmente considérablement le nombre de vérifications manuelles que les défenseurs doivent effectuer pour distinguer les menaces réelles des requêtes utilisateur inoffensives. De ce point de vue, la sécurisation des environnements "digital native" commence à s'apparenter à la sécurisation d'une série d'applications Web distinctes liées par l'authentification unique (SSO) et par des relations de confiance avec la plate-forme cloud. 

Par ailleurs, chaque entreprise ayant besoin d'un ensemble différent d'applications et de services pour mener ses activités, les informations recueillies concernant un environnement d'entreprise sont rarement applicables à la compréhension d'un autre environnement. Ce manque de normalisation exige un niveau de créativité et d'ingéniosité plus élevé de la part des professionnels de la sécurité.

Mandiant s'appuie sur les tendances d'attaques "digital native" observées sur le terrain pour orienter la méthodologie utilisée lors des missions de sa Red Team. Lors d'une de ces missions auprès d'une grande entreprise "digital native", l'objectif défini par Mandiant et le client était d'accéder à une application Web d'administration interne, identifiée par l'entreprise comme une application stratégique. 

Le code de cette application stratégique avait récemment fait l'objet d'un audit tiers et elle reposait sur un fournisseur SSO réputé. Puisqu'il était peu probable que l'application elle-même soit vulnérable aux attaques Web courantes, les membres de la Red Team de Mandiant ont concentré leurs tests sur d'autres applications SSO du même environnement qui pouvaient avoir des connexions avec l'application en question. Parmi ces applications se trouvaient des plates-formes de gestion des demandes d'accès, des gestionnaires Kubernetes et des outils de développement d'API. Mandiant a rigoureusement documenté les connexions et a commencé à évaluer les niveaux d'accès disponibles pour chacune d'elles. 

Au fil de son évaluation, Mandiant a découvert un vecteur d'élévation des privilèges qui permettait d'obtenir un accès administrateur à une application de développement SaaS utilisée pour développer des outils d'automatisation internes. Au début de la mission, cette application de développement SaaS avait été classée comme présentant un "risque faible", car au sein même de l'application, les utilisateurs étaient toujours limités aux rôles et aux autorisations qui leur étaient attribués par le biais du fournisseur SSO. Au départ, rien n'indiquait qu'un administrateur de cette application pouvait obtenir des accès ou des autorisations supplémentaires pour les autres applications SSO de l'environnement. 

En utilisant son accès administrateur à l'application de développement SaaS, Mandiant a constaté qu'un grand nombre d'employés s'authentifiaient auprès de l'application et exécutaient au moins l'un des outils qu'elle contenait toutes les heures. La Red Team a alors réorienté sa mission pour se concentrer sur la compréhension de ces workflows utilisateur spécifiques et sur la façon dont ils pourraient être compromis pour accéder à d'autres ressources privilégiées dans l'environnement.

Une exploration plus poussée de l'application de développement SaaS de ce point de vue administrateur a révélé que Mandiant disposait des autorisations nécessaires pour modifier les paramètres servant à connecter les utilisateurs à l'application stratégique. Mandiant a utilisé ces autorisations pour injecter une requête supplémentaire à la fin du processus d'authentification unique de chaque utilisateur de sorte à envoyer des jetons SSO en texte brut à un serveur contrôlé par Mandiant. Une fois cette nouvelle configuration enregistrée, les membres de la Red Team de Mandiant ont commencé à recevoir des requêtes d'authentification de la part d'utilisateurs légitimes de l'application stratégique. Ces requêtes contenaient des identifiants que Mandiant a pu exploiter pour usurper l'identité des utilisateurs à l'origine de la requête. Après avoir laissé cette injection s'exécuter jusqu'au lendemain, les membres de la Red Team ont pu récupérer les jetons SSO d'un utilisateur avec accès administrateur disposant de nombreux droits et ainsi accéder à l'application stratégique.

Les entreprises "digital native" et les environnements cloud dans lesquels elles opèrent sont en constante évolution. De nouvelles technologies sont développées, implémentées et abandonnées plus rapidement que jamais. La seule certitude pour ces entreprises est que les cybercriminels n'attendront pas qu'elles se familiarisent avec leurs nouveaux environnements. C'est pourquoi des mesures de sécurité proactives sont essentielles pour assurer une cyberdéfense efficace, dont des contrôles de cybersécurité continus, des exercices de red teaming réguliers et une expertise spécialisée en sécurité cloud.