La dernière version de la plateforme Now baptisée Yokohama confirme l’engagement de l’éditeur vers les agents IA. Elle embarque plusieurs agents pré-configurés et se lance sur les traces de Salesforce.
Le début de l’année 2025 fait la part belle aux agents IA. Si Salesforce a tracé le chemin à la fin 2024 avec Agentforce, d’autres éditeurs ont pris le même chemin. C’est le cas de ServiceNow qui vient de présenter la dernière itération de sa plateforme ITSM Now. Connue sous le nom de code Yokohama, elle renforce son catalogue sur les agents IA qui avait fait leur apparition dans la version Xanadu de novembre 2024.
Les derniers agents pré-configurés adressent différents métiers. Ainsi, certains sont experts en sécurité opérationnelle (SecOps) en rationnalisant l’ensemble du cycle de vie des incidents, en supprimant les tâches répétitives et en laissant les équipes SecOps se concentrer sur le blocage rapide des menaces réelles. D’autres sont spécialisés en gestion du changement avec la mise en place de plans de mise en œuvre personnalisés, de test et de sauvegarde en analysant l’impact, …Enfin, des agents sont chargés de faire des tests et des réparations proactifs du réseau, comme des dépanneurs.
Une studio pour développer des agents IA
Le spécialiste de l’ITSM a également présenté AI Agent Studio qui donne la capacité aux développeurs de construire, gérer et surveiller leurs propres agents IA. Avec l’aide d’AI Agent Orchestrator lancé précédemment, les développeurs pourront combiner plusieurs agents et créer des flux d’automatisation. L’IA sera alimentée par la Workflow Data Fabric qui fournit une connectivité de données entièrement gouvernée à l’échelle de l’entreprise.
L’IA générative n’est pas oubliée avec plusieurs fonctionnalités ad hoc au sein de Yokohama. Les développeurs pourront s’en servir pour accélérer les tests (création de scénario et des cadres automatisés), pour générer des systèmes de RPA utilisant le langage naturel, …. « Cette version redéfinit la façon dont les agents IA travaillent, elle dynamise les flux et intègre des données en temps réel, accroît la connectivité de l’entreprise et élève l’expérience client », a déclaré Amy Lokey, vice-présidente exécutive et directrice de l’expérience chez ServiceNow, lors d’un point presse. Elle a insisté sur deux autres fonctionnalités que sont l’observabilité des services et les portails en libre-service. « Nous proposons un seul système, une visibilité totale pour l’observabilité des services. Les entreprises jonglent avec des dizaines d’outils de surveillance et d’observabilité ; nous les unifions en une seule source de vérité », a-t-elle poursuivi. « Les connaissances basées sur l’IA permettent d’identifier plus rapidement les causes profondes. Elles évaluent l’impact commercial et résolvent les problèmes avant qu’ils ne s’aggravent. Nous sommes donc très enthousiastes à l’idée d’intégrer cela à notre plateforme. » Quant aux portails de vente et de gestion des commandes en libre-service, ils permettent aux clients de passer des commandes, de configurer des produits et de suivre l’état d’avancement, sans avoir besoin d’un agent commercial ou d’un agent d’assistance.
Une opportunité face à Salesforce
Ces caractéristiques trouvent un écho auprès de Scott Bickley, analyste à l’Info-Tech Research Group, qui note que ServiceNow se trouve face à une opportunité similaire à celle qu’Oracle s’est offerte par inadvertance après avoir manqué la première vague de clouds publics et qui a profité ensuite des expériences des premiers hyperscalers. « ServiceNow est face à une opportunité comparable par rapport à Salesforce dont les clients peuvent certes avoir accès à des systèmes hautement configurés qui ne sont pas les plus fonctionnels, et à des données qui n’ont pas été maintenues et nettoyées au fil du temps », a-t-il fait remarquer. Selon lui, ServiceNow peut dire à ces clients que sa plateforme leur offre un nouveau départ, qu’ils pourront sauter des étapes qui leur prendraient des années à reconfigurer et à réarchitecturer dans un système existant. « C’est une opportunité prometteuse pour eux, ainsi que pour le marché intermédiaire qui pourrait bénéficier de certaines de ces capacités », a-t-il ajouté.
Sur l’observabilité des services, M. Bickley fait remarquer que c’est un cas d’usage prêt pour l’IA : la fonction peut examiner des signaux qui semblent normalisés et déterminer s’il y a des anomalies. « Il est alors assez simple d’établir des règles pour déterminer où se situent les écarts signalés et quelles sont les raisons probables de ces écarts, et même de commencer à construire une analyse automatisée des causes profondes, ce qui serait assez puissant », a expliqué M. Bickley. « ServiceNow a également une proposition de valeur unique, qui pourrait relier leur gestion des opérations IT (ITOM) et leur planification des ventes et des commandes pour des cas d’usage de l’OT, ce que ne peut pas faire Salesforce. » Cependant, M. Bickley conseille aux clients de commencer modestement. « Ils doivent vraiment adopter une approche prudente et réfléchie de l’évaluation et du déploiement de ces technologies ». D’après le matériel promotionnel, ces technologies paraissent tout à fait prêtes, mais ce n’est que si des éléments comme la gestion des données, des processus propres, des cas d’usage bien définis et des équipes trans-fonctionnelles internes créées pour ces scénarios sont en place que les clients commenceront à en voir la valeur. « Mais dans la plupart des cas, les entreprises vont devoir travailler dans ce sens », a-t-il estimé.
Des chercheurs de SafeBreach ont élaboré un exploit utilisant des failles critiques dans LDAP de Windows. Il est capable de planter des serveurs et pourrait à terme exécuter du code à distance.
Des chercheurs de l’entreprise de sécurité SafeBreach ont publié la preuve de concept d’un exploit pour deux failles dans LDAP (Lightweight Directory Access Protocol) de Windows qui pourraient entraîner des pannes de serveur ou l’exécution de code à distance (Remote Code Execution, RCE) sur des serveurs Windows. « Les contrôleurs de domaine Active Directory sont considérés comme un composant essentiel des réseaux informatiques d’entreprise », rappellent les experts qui ont étudié les failles. « Les vulnérabilités identifiées dans les contrôleurs de domaine sont généralement beaucoup plus critiques que celles que l’on trouve dans les postes de travail habituelles. La possibilité d’exécuter du code sur un contrôleur de domaine ou de faire planter des serveurs Windows affecte fortement la posture de sécurité du réseau », ont-ils insisté.
Peu d’information sur les deux failles critiques
Référencées CVE-2024-49112 (gravité 9,8 sur 10) et CVE-2024-49113 (gravité 7,5), ces vulnérabilités ont été corrigées dans les mises à jour du Patch Tuesday de décembre 2024 de Microsoft, sans beaucoup de détails. Cependant, en fin de semaine dernière, SafeBreach a publié une analyse approfondie sur ces failles, ainsi qu’une preuve de concept de l’exploitation de CVE-2024-49113 qui, selon les chercheurs, affecte tout serveur Windows non corrigé, et pas seulement les contrôleurs de domaine, la seule condition étant que le serveur DNS du contrôleur de domaine victime soit connecté à Internet.
Même si Microsoft n’a publié quasiment aucune information sur la CVE-2024-49113, sa FAQ pour la CVE-2024-49112 fournit quelques informations supplémentaires: « Un attaquant distant non authentifié qui réussirait à exploiter cette vulnérabilité pourrait exécuter un code arbitraire dans le contexte du service LDAP. Cependant, la réussite de l’exploitation dépend du composant ciblé. » Ajoutant : « Pour parvenir à exploiter un contrôleur de domaine pour un serveur LDAP, l’attaquant doit envoyer des appels à Active Directory (AD) via la procédure distante de réplication (RPC) spécialement conçus à la cible pour déclencher une recherche du domaine de l’attaquant ».
Un mode opératoire pour les failles dans LDAP. (Crédit Photo : Safebreach)
Un PoC qui plante les serveurs et un RCE en préparation
Sur la base de ces informations, SafeBreach a orienté ses efforts vers les exécutables et les bibliothèques de liens dynamiques (DLL) qui mettent en œuvre la logique du client LDAP, et a choisi lsass.exe ou l’une des DLL qu’il charge comme emplacement probable du bogue. Après avoir isolé la DLL incriminée – widap32.dll – les chercheurs ont trouvé un moyen de tromper la victime en lui faisant envoyer une requête LDAP au domaine de l’attaquant et en lui renvoyant une réponse qui a fait planter lsass.exe et l’ensemble du système d’exploitation. (Voir l’analyse pour plus de détails). Les chercheurs travaillent actuellement sur un autre exploit qui ne plante pas le système, mais qui permet l’exécution de code à distance.
Pour pimenter un peu plus la vie des équipes de sécurité, Microsoft indique dans sa FAQ qu’un attaquant pourrait utiliser des tunnels RPC entrants pour exploiter les vulnérabilités. Le fournisseur recommande aux clients qui ne peuvent pas appliquer de correctifs d’empêcher immédiatement les contrôleurs de domaine d’accéder à Internet ou d’interdire les tunnels RPC entrants provenant de réseaux non fiables, en précisant que « l’application de ces mesures d’atténuation réduira le risque qu’un attaquant réussisse à convaincre ou à tromper une victime pour qu’elle se connecte à un serveur malveillant ». Par contre, si une connexion est établie, « l’attaquant pourrait envoyer des requêtes malveillantes à la cible via SSL ». la firme de Redmond ajoute toutefois que « l’application des deux configurations constitue une défense en profondeur efficace contre cette vulnérabilité. »
Le département américain du Trésor a révélé une intrusion dans plusieurs stations de travail via l’accès distant du support technique. La Chine est suspectée d’être derrière cette campagne.
La tension entre les Etats-Unis et la Chine ne faiblit pas. Dernier exemple en date, le département américain du Trésor a annoncé qu’un pirate avait réussi à contourner la sécurité, à accéder à un nombre non divulgué de stations de travail et à voler « certains documents non classifiés ». L’attaque a quand même été qualifiée d’« incident de cybersécurité majeur ».
Dans une lettre adressée au comité sénatorial des affaires bancaires, d’habitation et d’urbanisme (Committee on Banking, Housing and Urban Affairs), le Trésor a indiqué que le 8 décembre, il avait été informé par BeyondTrust qu’un acteur de la menace avait mis la main sur une clé sécurisant l’accès au support technique à distance des postes de travail du département. « Sur la base des indicateurs disponibles, l’incident a été attribué à un acteur de la menace persistante avancée (APT) parrainé par l’État chinois », précise le courrier, qui ajoute que « conformément à la politique du Trésor, les intrusions attribuables à un APT sont considérées comme un incident de cybersécurité majeur ». Les autorités chinoises ont rapidement dénoncé ces accusations.
Des inquiétudes sur les intentions des pirates affiliés à la Chine
« Ce genre d’attaque est caractéristique des pirates informatiques parrainés par l’État chinois qui utilisent la supply chain pour s’en prendre au gouvernement américain », a déclaré David Shipley, CEO et cofondateur de Beauceron Security, dans un courriel. « Elle fait suite à des attaques très réussies contre la solution de productivité dans le cloud de Microsoft, et à des attaques antérieures liées à la Russie contre le gouvernement américain utilisant Microsoft 365 et, avant cela, SolarWinds. »
La lettre du Trésor indique que le service concerné a été mis hors ligne et que la CISA (Cybersecurity and Infrastructure Security Agency), le FBI, la communauté du renseignement et des enquêteurs post-mortem tiers s’efforcent de « caractériser pleinement l’incident et d’en déterminer l’impact global ». David Shipley s’étonne de la cible choisie et se demande ce que les pirates recherchaient exactement. « S’agit-il d’un simple espionnage, ou essayaient-ils de préparer le terrain pour maintenir la persistance et perturber les opérations du gouvernement américain ? », s’est-il interrogé. « Je serais moins inquiet s’il s’agissait d’un simple espionnage », a-t-il reconnu. Le Trésor a promis de livrer plus de détails dans le rapport complémentaire qu’il doit fournir d’ici 30 jours.
BeyondTrust corrige au fur et à mesure de l’enquête
Les investigations se poursuivent aussi du côté de BeyondTrust, qui étudie plus en profondeur la portée et l’impact de la compromission. L’entreprise a indiqué dans son avis de sécurité qu’un « comportement potentiellement anormal » impliquant un seul client avait été détecté le 2 décembre, ce qui avait donné lieu à une enquête. Le 5 décembre, elle a confirmé ce comportement qui affectait « un nombre limité » d’instances SaaS de support à distance et a révoqué la clé compromise.
Les instances concernées ont été suspendues et mises en quarantaine en vue d’une analyse forensique, et les clients ont été informés et se sont vus proposer d’autres instances SaaS Remote Support. Au cours de son enquête, l’entreprise de sécurité a identifié deux vulnérabilités, l’une de gravité critique et l’autre de sévérité moyenne, dans ses produits Remote Support et Privileged Remote Access (à la fois dans le cloud et sur site). Au 16 décembre, les instances cloud avaient été corrigées et des patchs avaient été publiés pour les versions managées. BeyondTrust s’est également engagé à effectuer des mises à jour régulières à mesure de l’avancement de l’enquête.
Après la déroute d’Edgio, Microsoft a annoncé que la fin du service de CDN était dorénavant établie au 15 janvier 2025 et non en novembre prochain. Les utilisateurs ont donc deux semaines pour migrer vers une autre solution.
Les choses s’accélèrent pour les développeurs qui pensaient pouvoir utiliser le réseau de diffusion de contenu (CDN) d’Edgio sur Azure jusqu’en novembre 2025. Microsoft a publié une alerte la semaine dernière pour doucher leur espoir et ramener la fin de l’offre au 15 janvier 2025. « Certains binaires et installateurs .NET sont hébergés sur des domaines Azure Content Delivery Network qui se terminent par .azureedge.net. Ces domaines sont hébergés par edg.io, qui cessera bientôt ses activités pour cause de faillite, ce qui nous oblige à migrer vers un autre CDN et à utiliser de nouveaux domaines. Il est possible que les domaines .azureedge.net connaissent des temps d’arrêt ou soient définitivement indisponibles », a écrit Rich Lander, gestionnaire principal de programme .NET core chez Microsoft dans un message publié sur Github. « Les outils d’installation Azure DevOps et GitHub Actions dépendent de certaines de ces ressources », a-t-il ajouté.
« Nous travaillons directement avec ces équipes pour maintenir la continuité du service. La migration vers ces autres domaines se fait aussi vite que possible. » Cependant, celui-ci a mis en garde contre une « possible interruption des services CDN d’Edgio avant que Microsoft, ses partenaires et ses utilisateurs n’aient eu la possibilité de s’adapter aux changements proposés d’une manière progressive et sûre », ajoutant que « si cela devait se produire, Microsoft modifierait les scripts et les liens existants pour utiliser immédiatement les nouvelles URL et un autre CDN. » Selon M. Lander, « cette approche devrait maintenir le service pour la majorité des utilisateurs, mais elle pourrait perturber les utilisateurs ayant des règles de pare-feu. »
La faillite d’Edgio accélère le processus de migration
En septembre, Edgio s’est placé sous la protection du Chapitre 11 afin de pouvoir vendre certains actifs qui « devraient assurer la poursuite des activités de l’entreprise par un autre propriétaire », selon un communiqué de presse. En novembre, suite à la vente aux enchères qui a suivi la faillite, il est apparu qu’Akamai avait remporté « certains de ces actifs ». L’accord a été conclu en décembre et, dans une FAQ consacrée à la fermeture, Microsoft indique « avoir été informé que la plateforme Edgio cesserait d’être opérationnelle le 15 janvier 2025. » Cette date ne laisse aucune marge de manœuvre, pas plus que les dates intermédiaires pour le verrouillage des profils (3 janvier) et le blocage de la migration automatique vers Azure Front Door (6 janvier).
Afin d’éviter toute interruption de service, Microsoft recommande aux clients de terminer leur migration de la plateforme Edgio vers le CDN Azure avant le 7 janvier 2025. Le fournisseur précise cependant que pour les utilisateurs qui auront des services fonctionnant sur Azure CDN from Edgio le 7 janvier 2025 et qui ne l’ont pas informé de leurs projets… Microsoft essaiera de migrer ces services vers Azure Front Door à cette date. « Dans la mesure du possible, cette migration sera effectuée vers Azure Front Door, ce qui pourrait entraîner des problèmes liés à la facturation, aux fonctionnalités, à la disponibilité et/ou aux performances consommées actuellement avec Azure CDN d’Edgio ». En d’autres termes, il est préférable de s’occuper soi-même de la migration d’Azure CDN d’Edgio vers une autre plateforme afin d’éviter tout problème. Microsoft a déjà publié des conseils sur la manière de procéder.
Après la déroute d’Edgio, Microsoft a annoncé que la fin du service de CDN était dorénavant établie au 15 janvier 2025 et non en novembre prochain. Les utilisateurs ont donc deux semaines pour migrer vers une autre solution.
Les choses s’accélèrent pour les développeurs qui pensaient pouvoir utiliser le réseau de diffusion de contenu (CDN) d’Edgio sur Azure jusqu’en novembre 2025. Microsoft a publié une alerte la semaine dernière pour doucher leur espoir et ramener la fin de l’offre au 15 janvier 2025. « Certains binaires et installateurs .NET sont hébergés sur des domaines Azure Content Delivery Network qui se terminent par .azureedge.net. Ces domaines sont hébergés par edg.io, qui cessera bientôt ses activités pour cause de faillite, ce qui nous oblige à migrer vers un autre CDN et à utiliser de nouveaux domaines. Il est possible que les domaines .azureedge.net connaissent des temps d’arrêt ou soient définitivement indisponibles », a écrit Rich Lander, gestionnaire principal de programme .NET core chez Microsoft dans un message publié sur Github. « Les outils d’installation Azure DevOps et GitHub Actions dépendent de certaines de ces ressources », a-t-il ajouté.
« Nous travaillons directement avec ces équipes pour maintenir la continuité du service. La migration vers ces autres domaines se fait aussi vite que possible. » Cependant, celui-ci a mis en garde contre une « possible interruption des services CDN d’Edgio avant que Microsoft, ses partenaires et ses utilisateurs n’aient eu la possibilité de s’adapter aux changements proposés d’une manière progressive et sûre », ajoutant que « si cela devait se produire, Microsoft modifierait les scripts et les liens existants pour utiliser immédiatement les nouvelles URL et un autre CDN. » Selon M. Lander, « cette approche devrait maintenir le service pour la majorité des utilisateurs, mais elle pourrait perturber les utilisateurs ayant des règles de pare-feu. »
La faillite d’Edgio accélère le processus de migration
En septembre, Edgio s’est placé sous la protection du Chapitre 11 afin de pouvoir vendre certains actifs qui « devraient assurer la poursuite des activités de l’entreprise par un autre propriétaire », selon un communiqué de presse. En novembre, suite à la vente aux enchères qui a suivi la faillite, il est apparu qu’Akamai avait remporté « certains de ces actifs ». L’accord a été conclu en décembre et, dans une FAQ consacrée à la fermeture, Microsoft indique « avoir été informé que la plateforme Edgio cesserait d’être opérationnelle le 15 janvier 2025. » Cette date ne laisse aucune marge de manœuvre, pas plus que les dates intermédiaires pour le verrouillage des profils (3 janvier) et le blocage de la migration automatique vers Azure Front Door (6 janvier).
Afin d’éviter toute interruption de service, Microsoft recommande aux clients de terminer leur migration de la plateforme Edgio vers le CDN Azure avant le 7 janvier 2025. Le fournisseur précise cependant que pour les utilisateurs qui auront des services fonctionnant sur Azure CDN from Edgio le 7 janvier 2025 et qui ne l’ont pas informé de leurs projets… Microsoft essaiera de migrer ces services vers Azure Front Door à cette date. « Dans la mesure du possible, cette migration sera effectuée vers Azure Front Door, ce qui pourrait entraîner des problèmes liés à la facturation, aux fonctionnalités, à la disponibilité et/ou aux performances consommées actuellement avec Azure CDN d’Edgio ». En d’autres termes, il est préférable de s’occuper soi-même de la migration d’Azure CDN d’Edgio vers une autre plateforme afin d’éviter tout problème. Microsoft a déjà publié des conseils sur la manière de procéder.
Mauvaises configurations vulnérabilités critiques et exposition publique sont de plus en plus fréquentes sur les instances cloud des entreprises, selon un rapport de Tenable. Des moyens de remédiation existent.
Le débat sur la sécurité du cloud est éternel. Tenable, spécialiste en cybersécurité, enfonce le clou en sortant son rapport sur les risques liés au cloud. Cette étude basée sur les données de télémétrie collectées par l’éditeur donne plusieurs enseignements. Ainsi, au cours du 1er semestre 2024, 38% des entreprises présentaient au moins une charge de travail dans le cloud extrêmement vulnérable, configurée avec des privilèges excessifs et exposée publiquement. « Ce trio toxique du cloud crée un chemin d’attaque à haut risque et fait des charges de travail des cibles de choix pour les acteurs malveillants », souligne le rapport. Et d’ajouter, « plus d’un tiers des entreprises pourraient faire les gros titres demain ».
« Même si les workload présentent un ou deux de ces facteurs de risque, leurs répercussions sur la sécurité de l’entreprise sont potentiellement énormes », estime encore l’éditeur. « Les utilisateurs finaux de ces entreprises ont leur part de responsabilité », a déclaré Jeremy Roberts, directeur de recherche principal chez Info-Tech Research Group, qui n’a pas participé à l’étude. « Certes, le cloud est un outil comme un autre, mais tout dépend comment il est utilisé », a-t-il ajouté. « Un grand nombre de failles du cloud ne sont pas liées au fournisseur, mais résultent d’une gestion inefficace, comme la faille Capital One de 2019. En particulier, elle suppose de vérifier régulièrement les autorisations, d’appliquer les principes de zero trust et de recourir à une gestion centralisée (tours de contrôle, etc.) pour normaliser une base de sécurité. »
Le stockage cloud trop exposé
Toujours selon l’étude, au total, 74 % des entreprises ont des données stockées dans le cloud publiquement exposées, dont certaines contenaient des informations sensibles. Cette exposition est souvent due à des autorisations inutiles ou excessives. De plus, « comme les entreprises utilisent de plus en plus d’applications nativement cloud, la quantité de données sensibles qu’elles y stockent augmente également, y compris les informations sur les clients et les employés, ainsi que la propriété intellectuelle de l’entreprise, ce qui est très attractif pour les pirates ».
De fait, pendant la période d’analyse, Tenable a pu constater qu’un grand nombre d’attaques par ransomware ciblant le stockage cloud visaient des ressources du cloud public avec des privilèges d’accès excessifs. Or ces attaques auraient pu être évitées. Une ventilation de la télémétrie du stockage exposé a révélé que 39 % des entreprises avaient des buckets publics, que 29 % avaient des buckets publics ou privés avec trop de privilèges d’accès, et que 6 % avaient des buckets publics avec des privilèges d’accès excessifs.
Des clés d’accès trop permissives
Le stockage n’est pas le seul problème. Il est inquiétant de constater que 84 % des entreprises possèdent des clés d’accès inutilisées ou anciennes avec des autorisations excessives de gravité critique ou élevée. Or, selon l’étude, « elles ont joué un rôle majeur dans de nombreuses attaques et compromissions basées sur l’identité ». Tenable cite trois exemples d’utilisation abusive des clés : la violation de données de MGM Resorts, le piratage de la messagerie électronique de Microsoft et le logiciel malveillant FBot qui a ciblé les serveurs web, les services cloud et les logiciels SaaS, qui persiste et se propage sur AWS via les utilisateurs d’AWS IAM (gestion des identités et des accès/Identity and Access Management).
« Les clés d’accès et les autorisations qui leur sont attribuées sont au cœur des risques de l’IAM. Combinées, elles donnent littéralement les clés d’accès aux données stockées dans le cloud », pointe l’étude. Ajouter à cela le fait que 23 % des identités dans le cloud sur les principaux hyperscalers (Amazon Web Services, Google Cloud Platform et Microsoft Azure), qu’elles soient humaines ou non, sont assorties de permissions excessives critiques ou de haute gravité, et il y a là tous les ingrédients d’un désastre.
Une multitude de CVE critiques
Scott Young, directeur consultatif principal chez Info-Tech Research Group, impute en partie cette situation à la nature humaine. « Le pourcentage élevé d’autorisations critiques accordées à des comptes humains reflète le penchant naturel de l’homme pour la voie de la moindre résistance. Malheureusement, cette résistance n’est pas là pour rien », a-t-il rappelé. « Cette obsession à vouloir réduire les frictions dans le travail sur les systèmes peut avoir des conséquences énormes en cas de compromission d’un compte ». L’étude a également révélé que 78% des entreprises avaient des serveurs API Kubernetes accessibles au public, dont 41% autorisaient l’accès internet entrant, une situation qualifiée de « troublante » par Tenable. De plus, 58 % autorisent certains utilisateurs à contrôler sans restriction les environnements Kubernetes, et 44 % exécutent les conteneurs en mode privilégié, or ces deux configurations de permissions amplifient les risques de sécurité.
En plus de toutes ces mauvaises configurations qui rendent les installations vulnérables, plus de 80 % des charges de travail présentent une CVE critique non corrigée malgré la disponibilité des correctifs. C’est le cas en particulier de la vulnérabilité d’évasion de conteneur CVE-2024-21626.
Des atténuations possibles
Pour aider les entreprises à réduire leurs risques, Tenable propose plusieurs stratégies d’atténuation :
– Créer une éthique axée sur le contexte : rassembler les informations sur les identités, les vulnérabilités, les erreurs de configuration et les risques liés aux données dans un outil unifié afin d’obtenir une visualisation précise, un contexte et une hiérarchisation des risques liés à la sécurité dans le cloud. « Tous les risques ne se valent pas. Identifier les combinaisons toxiques peut contribuer à les réduire considérablement. »
– Gérer étroitement l’accès à Kubernetes/aux conteneurs : Adhérer aux normes de sécurité Pod, en limitant notamment les conteneurs à privilèges et en appliquant des contrôles d’accès. Restreindre l’accès entrant, limiter l’accès entrant aux serveurs API Kubernetes et s’assurer que les configurations Kubelet désactivent l’authentification anonyme. Enfin, vérifier si les liaisons de rôles cluster-admin sont vraiment nécessaires. Si ce n’est pas le cas, lier de préférence les utilisateurs à un rôle moins privilégié.
– Gestion des informations d’identification et des autorisations : l’éditeur recommande « d’effectuer une rotation régulière des informations d’identification, de ne pas utiliser les clés d’accès sur une trop longue période et de mettre en œuvre des mécanismes d’accès Just-in-Time. Auditer et ajuster régulièrement les autorisations pour les identités humaines et non humaines afin d’adhérer au principe du moindre privilège ».
– Prioriser les vulnérabilités : Concentrer les efforts de remédiation, en appliquant notamment les correctifs sur les vulnérabilités à haut risque, en particulier celles dont le score VPR, qui évalue la priorité des vulnérabilités, est élevé.
– Minimiser l’exposition : Examiner tous les actifs exposés publiquement pour déterminer si cette exposition est nécessaire et si elle ne compromet pas des informations confidentielles ou des infrastructures critiques. Suivre l’évolution des correctifs.