Des problèmes de code ou bogues annoncés par Apple semblent créer quelques soucis. La firme aurait ainsi mis sur pause son travail sur les fonctionnalités des dernières versions de son OS pour iPhone et pour Mac le temps en attendant de les corriger.
Selon Mark Gurman de Bloomberg, Apple aurait mis en pause le développement de nouvelles fonctionnalités pour ses prochains systèmes d’exploitation (IOS 18 et MacOS 15) afin de consacrer plus d’efforts à la correction des bogues et à l’amélioration des performances. Dans l’article, il est indiqué qu’une annonce interne a été faite la semaine dernière. La première étape majeure (M1) de Crystal (le nom de code d’iOS et d’iPadOS 18) et de Glow (le nom de code de MacOS 15) a apparemment été franchie le mois dernier. Malgré les changements majeurs apportés ces dernières années à la manière dont Apple développe ses logiciels, en mettant l’accent sur la qualité et la prévention de l’introduction de nouveaux bugs et régressions, ce premier jalon n’a pas été à la hauteur des attentes.
L’équipe d’ingénieurs a trouvé trop d’échappatoires – des bogues qui n’ont pas été détectés lors des tests – et a pris la décision inhabituelle d’interrompre le développement de toute nouvelle fonctionnalité pendant une semaine pour travailler à la correction de ces bogues, rapporte Mark Gurman. La pause devrait toucher à sa fin cette semaine, ce qui, en fin de compte, aura duré seulement deux semaines.
iOS 18 et MacOS 15 seront-ils retardés ?
Cela n’aura probablement pas d’impact majeur sur le calendrier de sortie des systèmes d’exploitation de l’année prochaine. Ce genre de changement de priorité n’est pas rare, en revanche le fait d’en être informé est plutôt inhabituel. Corriger les bogues et les défauts maintenant, au lieu de poursuivre le développement de fonctions supplémentaires, donne l’impression d’un retard, mais cela signifie simplement moins de correction de bogues plus tard. Il s’agit d’une décision de gestion destinée à maintenir l’équipe sur la bonne voie pour sortir un produit solide.
L’arrêt du développement de fonctionnalités s’applique apparemment à WatchOS 11 ainsi qu’à la mise à jour iOS 17.4 qui devrait être publiée aux alentours du mois de mars 2024. Le pire scénario pour cette pause est que nous verrons quelques autres fonctionnalités d’iOS 18 et de MacOS 15 publiées sous forme de mises à jour plutôt que dans la version initiale – une pratique courante qu’Apple a déployée ces derniers temps. Le meilleur scénario est que l’effort concerté pour mettre de l’ordre dans le code maintenant rende le développement plus fluide tout au long de l’année 2024 et que nous obtenions plus de fonctions dans des versions plus précoces.
Il faut s’attende à voir pour la première fois iOS 18 et MacOS 15, ainsi que les fonctionnalités et les changements de conception qu’ils apporteront, lors du rendez-vous annuel, la WWDC en juin prochain.
Un rapport de Venafi montre que les risques de sécurité lors du passage au cloud sont sous-estimés par les équipes de sécurité des entreprises.
Un rapport sur l’état de la sécurité « cloud native » a révélé qu’un nombre considérable d’adoptants du cloud ne comprennent pas les risques de sécurité liés au transfert d’applications existantes vers le « cloud », s’exposant ainsi à un certain nombre d’attaques basées sur le « cloud ». Pour son enquête, l’entreprise Venafi spécialisée dans la cybersécurité, a interrogé 800 responsables de la sécurité et de l’IT travaillant pour des entreprises situées aux États-Unis, au Royaume-Uni, en Allemagne et en France. L’objectif de l’étude était d’examiner les principales menaces et défis auxquels est confrontée aujourd’hui la sécurité « cloud native ».
« Les équipes de développement d’applications vont de plus en plus vite pour maintenir leur entreprise dans le peloton de tête, en se tournant vers des stratégies de conteneurisation et de microservices grâces auxquelles l’amélioration rapide des applications est devenue une réalité », indique le rapport de Venafi. « Très souvent, la sécurité cloud native est à la traîne, et la responsabilité de la prise en charge de la fonction de sécurité au sein des équipes d’ingénierie, de plateforme et de développement reste floue ». Le rapport note que ce manque de clarté est un énorme problème quand il s’agit de sécuriser les identités des machines – les authentificateurs qui sécurisent les communications et les connexions au sein d’un cluster de conteneurs – car elles servent de base à la sécurité cloud native. « Malgré leur importance relative, l’application des identités machine dans les implémentations cloud natif – services mesh, sécurité du cycle de développement des logiciels et signature du code des artefacts de développement – est fréquemment mal comprise », ajoute le rapport.
Des répercussions sur les coûts et la sécurité
Les personnes interrogées dans le cadre de l’étude ont révélé qu’elles passaient rapidement au cloud pour se débarrasser des longs cycles de développement et de publication d’applications, car elles ne peuvent pas se permettre d’attendre de nouvelles fonctionnalités essentielles. 87 % des personnes interrogées ont déclaré avoir transféré leurs anciennes applications dans le cloud. Plus de la moitié (59 %) des personnes interrogées ont déclaré ne pas comprendre les risques de sécurité liés au transfert des applications existantes vers le cloud. Par ailleurs, 53 % des personnes interrogées ont admis qu’elles avaient simplement transféré leurs applications dans le cloud, la majeure partie du code de l’application restant inchangée.
Autre inconvénient du passage aveugle au cloud : le coût associé à l’opération. « 52 % des entreprises ont souffert de la prolifération des clouds et du niveau de leurs factures depuis qu’elles ont transféré leurs applications existantes dans le cloud », indique le rapport. « 77 % de ceux qui en ont souffert ont reconsidéré le transfert de leurs applications vers le cloud ». Une autre tendance clé mise en évidence par l’étude est que la course au cloud a fait de la conteneurisation un choix populaire parmi les développeurs, 84 % des répondants à l’enquête estimant que Kubernetes serait bientôt la principale plateforme utilisée pour développer toutes les applications. Or, au fur et à mesure que l’utilisation de Kubernetes augmente et mûrit, la complexité des stratégies « cloud native » devient plus évidente.
Plus de défis avec Kubernetes
Les répondants ont convenu d’un certain degré d’incertitude en ce qui concerne l’adoption de Kubernetes, 75 % d’entre elles estimant que la vitesse et la complexité de Kubernetes et des conteneurs créaient des angles morts en matière de sécurité. Parmi les autres problèmes majeurs liés à la conteneurisation, on peut citer les difficultés d’application des correctifs (43 %), les vulnérabilités causées par des configurations erronées (41 %), les pannes dues à des certificats mal gérés (32 %) et l’échec des audits de sécurité (22 %). 59 % des personnes interrogées ont déclaré avoir rencontré des problèmes de sécurité dans des environnements Kubernetes ou de conteneurs. Les principales causes de ces problèmes sont les brèches dans le réseau (42 %), les vulnérabilités des API (41 %) et la mauvaise configuration des certificats (39 %). La mauvaise configuration des certificats – un défi pour l’identité des machines – s’est avérée être une préoccupation plus importante aux États-Unis, avec 45 %.
En outre, 68 % des sondés ont déclaré que les développeurs n’utilisaient parfois pas de certificats parce que leur émission ralentit le processus de développement. Malgré les défis liés aux identités des machines, ils sont 88% à estimer que le concept d’identité des machines est essentiel au succès des modèles zero trust. Cependant, l’appropriation de la gestion de l’identité des machines n’est toujours pas claire, 74 % des répondants s’inquiétant du fait que les développeurs sont confrontés à plusieurs priorités contradictoires, de sorte que la sécurité n’arrive pas toujours en tête de leurs préoccupations.
Un rapport de Salt Security insiste sur l’importance de la sécurisation de l’implémentation OAuth pour se protéger contre l’usurpation d’identité, la fraude financière et l’accès aux informations personnelles.
Le dernière bug découvert par des chercheurs dans l’implémentation OAuth sur divers sites web permet aux utilisateurs de s’authentifier avec leurs identités à partir de services tiers comme Facebook ou Google. Or, certains sites ne parviennent pas à franchir une étape importante de la chaîne d’autorisation OAuth, qui consiste à valider l’application pour laquelle un jeton d’accès a été émis par le fournisseur d’identité. En exploitant cette faille, un attaquant pourrait collecter les jetons émis pour une app ou un site web leurre, créés de toute pièce, puis les utiliser pour accéder aux comptes des victimes sur des sites vulnérables à ce problème. Les chercheurs de l’entreprise de sécurité Salt Security en ont fait la démonstration sur trois sites web populaires : le service d’aide à la saisie Grammarly, le site de streaming vidéo indonésien Vidio et la plateforme de commerce électronique indonésienne Bukalapak.
Si ces entreprises ont été informées en privé et ont corrigé le problème, les chercheurs estiment que toutes les entreprises devraient vérifier leurs implémentations pour s’assurer qu’elles n’exposent pas leurs utilisateurs à des attaques similaires. « Ces trois sites nous suffisent pour prouver notre point de vue, et nous avons décidé de ne pas chercher d’autres cibles, mais nous pensons que des milliers d’autres sites web sont vulnérables à l’attaque que nous détaillons dans cet article et mettent en danger des milliards d’internautes supplémentaires chaque jour », ont déclaré les chercheurs de Salt Security dans leur rapport.
Les jetons d’accès liés aux apps émettrices de la requête
Très populaire sur le web, la norme d’autorisation et de pseudo-authentification OAuth sert pour un site web ou une application à demander à un fournisseur d’identité comme Google, Facebook, Apple ou Microsoft de vérifier qu’un utilisateur est bien celui qu’il prétend être. Cette méthode facilite le processus d’authentification pour les utilisateurs, car ils peuvent utiliser leurs identités Facebook, Google ou Microsoft, ce qui leur évite de créer et de retenir des mots de passe distincts pour différents sites. En réalité, OAuth ne se limite pas à l’authentification. Le mécanisme offre aux utilisateurs d’accorder à des sites web externes l’accès à diverses informations de profil associées à chaque fournisseur d’identité via l’API du fournisseur. Cependant, ce problème découvert par Salt Security s’applique à la partie authentification, c’est-à-dire quand un site demande au fournisseur d’identité de confirmer que l’utilisateur est bien le propriétaire de l’identité (adresse électronique) qu’il souhaite utiliser. Et si pour leur démonstration, les chercheurs ont utilisé « Login with Facebook », elle pourrait techniquement fonctionner avec n’importe quel fournisseur d’identité.
Le processus OAuth fonctionne de la manière suivante : un utilisateur souhaite créer un compte sur un site web et choisit l’option « Login with Facebook » en fournissant une adresse électronique. Le site web redirige le navigateur de l’utilisateur vers Facebook afin d’apporter la preuve que l’utilisateur dispose bien d’un compte sous cette adresse électronique auprès du fournisseur d’identité. La première fois, pour confirmer que le site web ou l’application de tierce partie sont autorisés à accéder aux informations relatives à son compte, comme l’adresse électronique, Facebook affiche une demande d’autorisation à l’utilisateur. Ensuite, il génère un jeton secret et redirige le navigateur de l’utilisateur vers le site web demandeur, le jeton étant joint à l’URL de la requête.
Des permissions mémorisées
Le site web prend le jeton et l’utilise pour accéder à l’API Facebook Graph au nom de l’utilisateur et demande au réseau social quelle est l’adresse électronique associée au jeton. Facebook répondra avec l’adresse électronique de l’utilisateur et le site web aura la confirmation que l’utilisateur est bien celui qu’il prétend être et l’autorisera à créer son compte. Pour toute connexion ultérieure, le processus se répète, sauf que Facebook ne demandera plus à l’utilisateur de fournir un accès puisqu’il lui a déjà été accordé. L’utilisateur cliquera simplement sur « Login with Facebook », le site redirigera son navigateur vers Facebook pour obtenir un jeton, Facebook redirigera le navigateur de l’utilisateur vers le site avec le jeton attaché dans l’URL et le site utilisera le jeton pour confirmer le courriel de l’utilisateur via l’API de Facebook et le laisser entrer. Cependant, la sécurité de ce processus comporte un élément très important : Facebook, et tout fournisseur d’identité OAuth, lie le jeton à l’app ID du site web qui a demandé le jeton via le navigateur de l’utilisateur. Chaque site web ou application qui souhaite proposer la fonctionnalité « Login with Facebook » doit d’abord s’enregistrer auprès de Facebook et recevra son propre identifiant d’application unique dans la base de données de Facebook.
Le problème est qu’il incombe au site web de vérifier le jeton avant de l’accepter et de l’utiliser. Cette validation implique de vérifier que le jeton a été généré pour son propre app ID et non pour une autre application. Pour ce faire, une requête est adressée à un point de terminaison spécial de l’API de Facebook avant d’utiliser le jeton pour demander à Facebook de valider l’identité de l’utilisateur et de lui permettre d’accéder à son compte. Si cette étape est omise – et il s’avère que de nombreux sites web l’omettent – il est possible d’usurper l’identité de l’utilisateur et de s’emparer de son compte. Par exemple, un pirate peut créer un site web ou une application légitime qui fournit un service, l’enregistrer auprès de Facebook pour fournir la fonction « Login with Facebook », puis l’utiliser subrepticement pour générer et collecter des jetons OAuth auprès d’utilisateurs qui souhaitent légitimement utiliser le service. Les jetons que Facebook générera pour que les utilisateurs valident leur identité sur le site web de l’attaquant seront valides, même s’ils seront émis pour l’app ID du site web. Mais, si un autre site web ne vérifie pas l’identifiant d’application des jetons qu’il reçoit et se contente de les utiliser, l’attaquant pourrait prendre un jeton généré par un utilisateur pour son site web et l’utiliser sur un site web vulnérable pour accéder au compte de l’utilisateur sur ce site web. Si ce site est une plateforme de commerce électronique comme Bukalapak, l’utilisateur a peut-être stocké dans son profil des informations de facturation et de paiement. S’il s’agit d’un service comme Grammarly, l’utilisateur peut avoir des documents sensibles, etc.
Autres variantes et défauts d’implementation
OAuth est une norme complexe qui offre plusieurs variantes de mise en œuvre. Par exemple, au lieu d’utiliser des URL de redirection entre le site et le fournisseur d’identité, le site peut choisir d’utiliser la fonction PostMessage, mais l’attaque est toujours possible dans une telle implémentation si le jeton n’est pas validé. Le passage de jetons via des URL est potentiellement vulnérable aux attaques de type « man-in-the-middle » si un attaquant a la capacité de surveiller passivement le trafic et d’extraire le jeton OAuth de l’URL qu’il observe. Pour cette raison, OAuth propose également une approche plus sûre dans laquelle le fournisseur d’identité émet un code unique au lieu d’un jeton d’accès, puis le site web prend ce code avec un secret d’application que seuls lui-même et Facebook connaissent et échange le code en jeton à l’aide de l’API de Facebook. Grammarly a effectivement utilisé cette méthode plus sûre basée sur le code quand l’équipe de Salt Security a testé sa mise en œuvre d’OAuth. Cependant, les chercheurs ont constaté que le script OAuth de Grammarly prenait des requêtes avec le code d’entrée dans la requête et se sont demandés s’il pouvait inclure une fonction qui prendrait aussi des jetons. Ils ont donc essayé de faire des demandes en remplaçant le code par différents mots comme token, facebookToken, FBtoken et d’autres variations, jusqu’à ce qu’ils trouvent que access_token fonctionnait et était accepté.
En d’autres termes, ils ont réussi à faire passer l’implémentation de Grammarly à la variante la plus sécurisée parce que le code permettant de gérer les jetons directement à la place du code était encore laissé en option dans le script. Et il s’est avéré qu’il n’y avait pas d’étape de validation du jeton pour vérifier l’app ID. Par le passé, les chercheurs de Salt Security ont trouvé d’autres failles dans l’implémentation d’OAuth sur des sites web importants, dont certaines auraient pu permettre à des attaquants d’accéder à des comptes Booking.com. « Il est extrêmement important de s’assurer que l’implémentation d’OAuth est sécurisée », ont déclaré les chercheurs. « Le correctif se résume à une simple ligne de code. Quand OAuth sert pour fournir une authentification de service, toute faille de sécurité peut conduire au vol d’identité, à la fraude financière et à l’accès à diverses informations personnelles, y compris les numéros de cartes de crédit, les messages privés, les dossiers médicaux, et plus encore, en fonction du service spécifique attaqué », ont encore déclaré les chercheurs.
Le SIEM nativement cloud d’IBM, QRadar prend désormais en charge l’interopérabilité des clouds hybrides, les solutions open source et la détection automatisée des menaces.
Toilettage d’hiver pour QRadar, l’offre SIEM en mode cloud d’IBM qui intègre plusieurs éléments dans la surveillance des cloud hybrides, des solutions open source et des wokload d’IA. L’offre combine la structure SIEM existante de la suite QRadar avec des capacités d’IA générative et de détection des menaces pour améliorer l’ingestion des données et la mise à l’échelle de la recherche et de l’analyse.
« Nous avons reconstruit notre SIEM à partir de zéro, en utilisant Red Hat Open Shift comme architecture de données sous-jacente et en tirant parti d’une technologie d’entreposage de données haute performance pour la gestion des logs », a déclaré Chris Meenan, vice-président de la gestion des produits chez IBM Security. « Les clients actuels de QRadar pourront désormais moderniser leurs opérations de sécurité avec une base de données construite spécifiquement pour les besoins des environnements hybrides multicloud », a-t-il ajouté. IBM QRadar Cloud-Native SIEM sera disponible d’ici la fin de l’année, d’abord en mode SaaS, en attendant la livraison des logiciels pour les environnements sur site et multicloud prévue pour 2024.
Du SIEM natif pour l’interopérabilité
Construit sur Red Hat OpenShift pour un déploiement agnostique, le SIEM d’IBM sera ouvert à un « niveau fondamental », de façon à assurer l’interopérabilité avec de multiples fournisseurs de cloud et leurs outils. QRadar s’appuiera sur des logiciels libres et des normes ouvertes pour les fonctions principales, notamment les règles de détection des menaces et les langages de recherche. « L’approche ouverte d’IBM est absolument essentielle pour permettre aux clients de profiter des avantages du cloud dans les environnements hybrides multicloud », a déclaré Chris Meenan. « D’autres fournisseurs proposent une architecture basée davantage sur une approche de cloud unique, ce qui fait que les analyses de sécurité, les intégrations et les options de recherche fonctionnent bien dans leur cloud natif, mais sont difficiles à mettre en œuvre dans un environnement de cloud hybride distribué ».
Dans le cadre de cette orientation « ouverte », le SIEM d’IBM prend en charge les règles unifiées communes et partagées du langage de détection Sigma, si bien que les clients peuvent importer d’autres indicateurs provenant directement de la communauté responsable de la sécurité à mesure de l’évolution des menaces. L’utilisation de technologies open source promet une « recherche fédérée et des capacités de chasse aux menaces », avec la possibilité de rechercher et d’enquêter sur les menaces à travers toutes les sources de données du cloud et sur site d’une « manière unique et unifiée, sans déplacer les données de leur source d’origine », a déclaré IBM. Cependant, l’approche « cloud-natif » en elle-même pourrait ne pas suffire à IBM pour concurrencer les acteurs existants. « Cette seule architecture cloud-native n’offre pas d’avantage à IBM par rapport à des fournisseurs comme Devo, Google, Microsoft et Splunk qui ont adopté une stratégie similaire », a déclaré Jon Oltsik, analyste chez ESG. « IBM doit rivaliser sur les caractéristiques/fonctionnalités, mais le fournisseur a de bons arguments à faire valoir en matière d’ouverture, de fédération des données, de soutien des normes, d’écosystème de partenaires, etc. »
IA et automatisation
Pour automatiser la détection des menaces et les processus d’investigation, le SIEM restructuré introduit et emprunte plusieurs capacités d’IA. Parmi les fonctionnalités à base de cette technologie, on peut citer la priorisation des alertes, l’enquête sur les menaces et la détection adaptative. Les algorithmes d’IA développés par IBM servent à réduire le bruit et à automatiser le regroupement, la contextualisation et l’escalade des alertes prioritaires. L’enquête sur les menaces utilise également des moteurs d’IA pour effectuer des recherches automatisées dans les systèmes connectés, générant une chronologie visuelle de l’attaque, des correspondances MITRE ATT&CK et des actions recommandées. La détection adaptative fait référence à la mise à jour automatique des règles de détection à mesure de l’arrivée des informations. « Les technologies d’IA de QRadar ont été développées au sein d’IBM et affinées pendant plusieurs années, entraînées sur des millions d’alertes provenant de milliers de clients, ainsi que sur le contexte externe des menaces et les modèles historiques de réponse des analystes », a encore déclaré Chris Meenan. « Certaines de ces capacités d’IA ont aussi été développées en collaboration avec l’équipe des services de cybersécurité d’IBM, qui gère les opérations de sécurité pour des milliers de clients dans le monde ».
Simultanément à cette annonce, IBM a fait part de son intention de lancer des capacités de sécurité génératives basées sur l’IA via QRadar Suite au début de 2024. Celles-ci seront principalement construites sur watsonx, la plateforme d’IA et de données de l’entreprise. « Compte tenu de son expérience avec Watson et de l’engagement global d’IBM en faveur de l’IA à l’échelle de l’entreprise, je pense que ses capacités d’IA générative seront solides, mais c’est un domaine qui reste assez déroutant pour les clients », a déclaré Jon Oltsik d’ESG. « IBM doit aider le marché à s’orienter avec un leadership éclairé et faire en sorte que les clients puissent mettre en œuvre l’IA générative en toute transparence. Le fournisseur continuera à soutenir son offre SIEM QRadar actuelle, tout en offrant aux clients une option de transition vers la solution SIEM cloud native ».
Le SIEM nativement cloud d’IBM, QRadar prend désormais en charge l’interopérabilité des clouds hybrides, les solutions open source et la détection automatisée des menaces.
Toilettage d’hiver pour QRadar, l’offre SIEM en mode cloud d’IBM qui intègre plusieurs éléments dans la surveillance des cloud hybrides, des solutions open source et des wokload d’IA. L’offre combine la structure SIEM existante de la suite QRadar avec des capacités d’IA générative et de détection des menaces pour améliorer l’ingestion des données et la mise à l’échelle de la recherche et de l’analyse.
« Nous avons reconstruit notre SIEM à partir de zéro, en utilisant Red Hat Open Shift comme architecture de données sous-jacente et en tirant parti d’une technologie d’entreposage de données haute performance pour la gestion des logs », a déclaré Chris Meenan, vice-président de la gestion des produits chez IBM Security. « Les clients actuels de QRadar pourront désormais moderniser leurs opérations de sécurité avec une base de données construite spécifiquement pour les besoins des environnements hybrides multicloud », a-t-il ajouté. IBM QRadar Cloud-Native SIEM sera disponible d’ici la fin de l’année, d’abord en mode SaaS, en attendant la livraison des logiciels pour les environnements sur site et multicloud prévue pour 2024.
Du SIEM natif pour l’interopérabilité
Construit sur Red Hat OpenShift pour un déploiement agnostique, le SIEM d’IBM sera ouvert à un « niveau fondamental », de façon à assurer l’interopérabilité avec de multiples fournisseurs de cloud et leurs outils. QRadar s’appuiera sur des logiciels libres et des normes ouvertes pour les fonctions principales, notamment les règles de détection des menaces et les langages de recherche. « L’approche ouverte d’IBM est absolument essentielle pour permettre aux clients de profiter des avantages du cloud dans les environnements hybrides multicloud », a déclaré Chris Meenan. « D’autres fournisseurs proposent une architecture basée davantage sur une approche de cloud unique, ce qui fait que les analyses de sécurité, les intégrations et les options de recherche fonctionnent bien dans leur cloud natif, mais sont difficiles à mettre en œuvre dans un environnement de cloud hybride distribué ».
Dans le cadre de cette orientation « ouverte », le SIEM d’IBM prend en charge les règles unifiées communes et partagées du langage de détection Sigma, si bien que les clients peuvent importer d’autres indicateurs provenant directement de la communauté responsable de la sécurité à mesure de l’évolution des menaces. L’utilisation de technologies open source promet une « recherche fédérée et des capacités de chasse aux menaces », avec la possibilité de rechercher et d’enquêter sur les menaces à travers toutes les sources de données du cloud et sur site d’une « manière unique et unifiée, sans déplacer les données de leur source d’origine », a déclaré IBM. Cependant, l’approche « cloud-natif » en elle-même pourrait ne pas suffire à IBM pour concurrencer les acteurs existants. « Cette seule architecture cloud-native n’offre pas d’avantage à IBM par rapport à des fournisseurs comme Devo, Google, Microsoft et Splunk qui ont adopté une stratégie similaire », a déclaré Jon Oltsik, analyste chez ESG. « IBM doit rivaliser sur les caractéristiques/fonctionnalités, mais le fournisseur a de bons arguments à faire valoir en matière d’ouverture, de fédération des données, de soutien des normes, d’écosystème de partenaires, etc. »
IA et automatisation
Pour automatiser la détection des menaces et les processus d’investigation, le SIEM restructuré introduit et emprunte plusieurs capacités d’IA. Parmi les fonctionnalités à base de cette technologie, on peut citer la priorisation des alertes, l’enquête sur les menaces et la détection adaptative. Les algorithmes d’IA développés par IBM servent à réduire le bruit et à automatiser le regroupement, la contextualisation et l’escalade des alertes prioritaires. L’enquête sur les menaces utilise également des moteurs d’IA pour effectuer des recherches automatisées dans les systèmes connectés, générant une chronologie visuelle de l’attaque, des correspondances MITRE ATT&CK et des actions recommandées. La détection adaptative fait référence à la mise à jour automatique des règles de détection à mesure de l’arrivée des informations. « Les technologies d’IA de QRadar ont été développées au sein d’IBM et affinées pendant plusieurs années, entraînées sur des millions d’alertes provenant de milliers de clients, ainsi que sur le contexte externe des menaces et les modèles historiques de réponse des analystes », a encore déclaré Chris Meenan. « Certaines de ces capacités d’IA ont aussi été développées en collaboration avec l’équipe des services de cybersécurité d’IBM, qui gère les opérations de sécurité pour des milliers de clients dans le monde ».
Simultanément à cette annonce, IBM a fait part de son intention de lancer des capacités de sécurité génératives basées sur l’IA via QRadar Suite au début de 2024. Celles-ci seront principalement construites sur watsonx, la plateforme d’IA et de données de l’entreprise. « Compte tenu de son expérience avec Watson et de l’engagement global d’IBM en faveur de l’IA à l’échelle de l’entreprise, je pense que ses capacités d’IA générative seront solides, mais c’est un domaine qui reste assez déroutant pour les clients », a déclaré Jon Oltsik d’ESG. « IBM doit aider le marché à s’orienter avec un leadership éclairé et faire en sorte que les clients puissent mettre en œuvre l’IA générative en toute transparence. Le fournisseur continuera à soutenir son offre SIEM QRadar actuelle, tout en offrant aux clients une option de transition vers la solution SIEM cloud native ».
Cisco a mis à jour plusieurs services de sécurité réseau après la découverte de failles critiques. Celles-ci conduisent à l’injection de commandes ou la génération de dénis de service.
Les administrateurs réseaux et les équipes de sécurité sont mobilisés pour appliquer rapidement les correctifs publiés par Cisco. Ces patchs concernent plusieurs produits de sécurité réseau de la firme : Firepower, Identity Services Engine (ISE) et Adaptive Security Appliance (ASA). La CISA (équivalent de l’Anssi aux Etats-Unis) a publié une alerte sur ces dispositifs qui offrent aux attaquants une position privilégiée sur le réseau pour se déplacer latéralement.
Un risque d’injection de commandes pour la faille la plus grave
La faille la plus grave se trouve dans le logiciel Management Center de Firepower. Elle donne à un attaquant authentifié la capacité d’envoyer des commandes de configuration non autorisées aux dispositifs Firepower Threat Defense (FTD). Le cybercriminel peut s’authentifier sur l’interface web et exploiter la vulnérabilité en envoyant une requête HTTP spécialement conçue au terminal cible.
Même si Cisco ne précise pas dans son avis quelles actions peut réaliser le pirate grâce à ces commandes de configuration, la faille est considérée comme critique. La brèche n’existe que dans le logiciel Management Center Software, de sorte que les équipements FTD autonomes gérés par Firepower Device Manager (FDM) ne sont pas concernés. Le logiciel Adaptive Security Appliance (ASA), prédécesseur de Firepower, n’est pas non plus affecté.
D’autre failles sérieuses
Deux autres vulnérabilités liées à l’injection de commandes ont également été corrigées dans Firepower Management Center, mais elles peuvent entraîner l’exécution de commandes sur le système d’exploitation sous-jacent, et non sur les terminaux managés. Pour exploiter ces faiblesses, l’attaquant doit aussi disposer d’informations d’identification valides, mais il n’est pas nécessaire qu’il s’agisse du compte administrateur. Ces deux vulnérabilités ont été qualifiées de « gravité élevée ».
Un quatrième bug d’injection de code a été découvert et corrigé dans Firepower Management Center et Firepower Threat Defense. Le problème se situe dans un mécanisme de communication entre terminaux et permet à un attaquant authentifié d’exécuter des commandes en tant que root. Cependant, pour y parvenir, l’attaquant doit avoir le rôle d’administrateur sur un dispositif FTD pour cibler le dispositif Management Center, ou avoir des privilèges d’administrateur sur Management Center pour exécuter des commandes root sur un dispositif FTD associé. Deux problèmes d’injection de commandes de haute gravité ont également été corrigés dans Identity Services Engine (ISE) et pourraient offrir à un attaquant local authentifié d’exécuter des commandes en tant que root sur le système d’exploitation sous-jacent. L’ISE a par ailleurs reçu des correctifs pour deux failles aboutissant au téléchargement de fichiers arbitraires sur le terminal ou de désactiver le traitement du protocole de découverte Cisco Discovery Protocol (CDP).
D’autres vulnérabilités exposent à un déni de service
D’autres vulnérabilités à haut risque pouvant entraîner des dénis de service ont été corrigées dans les logiciels Adaptive Security Appliance, Firepower Threat Defense, Firepower Management Center et les pare-feu de la série Cisco Firepower 2100. Ces problèmes étaient localisés dans les fonctionnalités suivantes : le traitement des messages ICMPv6, le VPN d’accès à distance, les règles d’inspection du pare-feu, l’API Log, et l’inspection ICMPv6 avec détection Snort 2.
La demande en compétence cybersécurité dans le monde ne faiblit pas. Selon une étude, il manquerait 4 millions de personnes dans ce secteur. A noter que les sondés jugent le déficit de compétences plus problématique que la pénurie de main d’oeuvre.
La situation s’aggrave sur le front de l’emploi dans la cybersécurité. Selon une étude, la pénurie de main d’œuvre atteint un niveau record de 4 millions de personnes, alors que les effectifs dans ce domaine ont augmenté de près de 10% au cours de l’année écoulée. C’est ce qui ressort de la dernière étude « Cybersecurity Workforce Study », réalisée par l’ISC2, une organisation à but non lucratif qui propose des formations et délivre des certifications à des professionnels de la cybersécurité.
D’après cette étude, l’écart entre le nombre de personnes nécessaires et celui de personnes disponibles a augmenté de 12,6 % d’une année sur l’autre, essentiellement du fait d’une réduction des effectifs, de l’incertitude économique, de l’intelligence artificielle (IA) et d’un environnement de la menace difficile. Selon l’ISC2, le déficit actuel de main-d’œuvre au niveau mondial est estimé à 3 999 964, tandis que la main-d’œuvre elle-même est estimée à 5 452 732.
Des plans sociaux impactant les équipes de cybersécurité
Deux tiers (67 %) des 14 865 professionnels de la cybersécurité interrogés ont déclaré que leur entreprise manquait du personnel nécessaire pour prévenir et résoudre les problèmes de sécurité. Un paradoxe au moment où 47% des sondés ont subi des réductions d’effectifs en lien avec le domaine, 22 % d’entre eux ayant été touchés par des licenciements. Près de la moitié des personnes interrogées ont déclaré que les réductions ont affecté leur équipe de sécurité de manière disproportionnée par rapport au reste de leur entreprise, 71 % d’entre elles ayant subi un impact négatif sur leur charge de travail et 57 % ayant vu leur capacité à répondre aux menaces de cybersécurité affectée en conséquence.
Les secteurs du divertissement (33 %), de la construction (31 %) et de l’automobile (29 %) ont été particulièrement touchés par les licenciements dans le domaine de la cybersécurité. Les secteurs de l’armée et des fournisseurs militaires (8 %), du gouvernement (9 %) et de l’éducation (13 %) ont été les moins touchés. Sur le plan géographique, c’est en Amérique latine (Brésil et Mexique) que les licenciements ont été les plus nombreux, suivie du Nigeria et des Émirats arabes unis. Les pays où les licenciements sont les moins nombreux sont Hong Kong, les États-Unis et l’Arabie saoudite.
Un déficit de compétences pire que la pénurie de main d’oeuvre
L’étude de l’ICS2 soulève un point critique sur la problématique du manque de personnel. En effet, plus de la moitié des sondés (59%) jugent que les lacunes de compétences sont plus préjudiciables que la pénurie de main d’œuvre. Les équipes de sécurité ont besoin d’expertise et de spécialisation pour fonctionner correctement. Parmi les plus recherchées, il y a la sécurité du cloud, l’IA/ML et la mise en œuvre du zero trust. Selon le rapport, l’incapacité à trouver des personnes possédant les bonnes compétences (44 %), la difficulté à garder les personnes possédant des compétences en demande (42 %) et le manque de budget pour embaucher des personnes (41 %) expliquent principalement ces lacunes en matière de compétences.
De plus, les licenciements semblent avoir un effet plus important sur les lacunes en matière de compétences que sur les pénuries totales de personnel. Selon l’ISC2, la plupart des entreprises qui ont procédé à des licenciements dans le domaine de la cybersécurité (51 %) ont été affectées par une ou plusieurs lacunes importantes en matière de compétences, contre seulement 39 % des entreprises qui n’ont pas procédé à des suppressions de poste. Il est intéressant de noter que 58 % des sondés ont déclaré que l’impact négatif de la pénurie de main-d’œuvre peut être atténué en comblant les lacunes en matière de compétences clés.
Un moral en léger retrait et une diversité revendiquée
Selon le rapport, les entreprises se concentrent sur des stratégies visant à remédier à la pénurie de personnel et de compétences en cybersécurité à laquelle elles sont confrontées. Investir dans la formation (72 %), offrir des conditions de travail plus souples (69 %), investir dans des initiatives de diversité, d’équité et d’inclusion (DEI), recruter, embaucher et intégrer de nouveaux employés (67 %) et utiliser la technologie pour automatiser certains aspects du travail de sécurité (65 %) sont autant de priorités citées dans le rapport. Malgré de réelles turbulences, les personnes travaillant dans la cybersécurité « semblent assez satisfaites de leur rôle », fait remarquer l’ISC2. Près des trois quarts d’entre eux (70 %) se déclarent plutôt ou très satisfaits de leur travail, en baisse de 4 % par rapport à l’année dernière, et 82 % affirment qu’ils travaillent bien avec les membres de l’équipe de sécurité.
Les données montrent également que la composition de la main-d’œuvre en cybersécurité évolue tant sur le plan du sexe que de la race ou de l’origine ethnique. Les professionnels du secteur accordent une grande importance à la diversité de leur personnel, 69 % d’entre eux déclarant qu’un environnement inclusif est essentiel à la réussite de leur équipe et 65 % déclarant qu’il est important que leur équipe de sécurité soit diversifiée. Plus de la moitié des personnes interrogées (57 %) ont déclaré que la diversité, l’équité et l’inclusion gagnera en importance pour leur équipe au cours des cinq prochaines années. « Alors que nous nous réjouissons du nombre record de recrutement dans la cybersécurité, la réalité urgente est que nous devons doubler cette main-d’œuvre pour protéger efficacement les entreprises et leurs actifs critiques », a déclaré Clar Rosso, CEO de l’ISC2. « Dans le paysage actuel des menaces, qui est le plus complexe et le plus sophistiqué qu’il ait jamais été, les défis croissants auxquels sont confrontés les professionnels de la cybersécurité soulignent l’urgence de notre message : les entreprises doivent investir dans leurs équipes, à la fois en termes de nouveaux talents et de personnel existant, en les dotant des compétences essentielles pour faire face à un paysage des menaces en constante évolution ».
Selon l’entreprise de cybersécurité Deep Instinct, la dernière campagne du groupe d’espions MuddyWater contre des cibles israéliennes utilisent des dossiers dissimulés et des outils d’accès à distance.
Le groupe d’espions APT (Advanced Persistent Threat) connu sous le nom de MuddyWater, et dont on pense généralement qu’il est dirigé par le ministère iranien du Renseignement et de la Sécurité, a lancé une campagne contre des cibles du gouvernement israélien. Selon un rapport du Threat Lab de l’entreprise de cybersécurité Deep Instinct, le groupe utilise un service de partage de fichiers appelé Storyblok pour héberger un programme d’infection en plusieurs étapes destiné aux ordinateurs cibles. Le paquet d’infection se présente sous la forme d’une archive qui contient un raccourci LNK au bas d’une chaîne de dossiers. Quand il est ouvert, le raccourci active un exécutable à partir d’un dossier caché contenu dans l’archive, lequel installe un outil légitime d’administration à distance sur le système cible et permet au groupe MuddyWater d’espionner la machine.
Selon Deep Instinct, cette attaque est particulièrement intelligente, en raison de la couche supplémentaire de tromperie : l’exécutable malveillant ressemble à un dossier de fichiers, et non à un programme, et fait apparaître un véritable dossier Windows Explorer contenant une copie d’un véritable mémo du gouvernement israélien sur le contrôle des informations des médias sociaux en même temps qu’il installe le logiciel d’administration à distance. L’article publié par Deep Instinct sur son blog, indique que la campagne Storyblok peut se prolonger en une phase secondaire après l’infection. « Une fois la victime infectée, l’opérateur de MuddyWater se connecte à l’hôte compromis à l’aide de l’outil officiel d’administration à distance et commence à effectuer une reconnaissance de la cible », a expliqué l’entreprise. « Après la phase de reconnaissance, l’opérateur exécutera probablement un code PowerShell qui amènera l’hôte infecté à envoyer une balise à un serveur C2 personnalisé ».
Israël et d’autres pays attaqués
Cela fait des années que Deep Instinct suit l’évolution des tactiques du groupe MuddyWater, et ses activités menées contre des entreprises de télécommunications, des gouvernements, des entreprises de défense et des organisations énergétiques dans de nombreux pays, et pas seulement en Israël. On ne sait pas exactement comment l’attaque Storyblok actuelle se propage, mais le groupe a déjà utilisé par le passé des techniques de phishing ciblé contenant soit des documents Word avec des liens vers une charge utile, soit des liens directs. MuddyWater a également utilisé des pièces jointes HTML, plutôt que des liens directs, pour dissiper les craintes, car les archives et les exécutables présentent des risques de sécurité beaucoup plus évidents que de simples liens web. Le groupe serait actif depuis 2020. Le billet de blog de Deep Instinct fournit une longue liste d’indicateurs de compromission sous la forme de valeurs MD5, consultable ici.
Une campagne de malware utilise des paquets MSIX pour injecter le chargeur Ghostpulse, un dropper furtif capable d’éviter la détection par les scanners de la victime.
Les chercheurs d’Elastic Security Labs ont découvert que le format de packaging d’applications Windows MSIX servait de vecteur pour infecter les PC Windows et échapper à la détection en introduisant un chargeur de malware furtif baptisé Ghostpulse. Les développeurs utilisent couramment MSIX pour emballer, distribuer et installer leurs applications pour les utilisateurs de l’OS de Microsoft. Ce format est désormais le support de l’infection initiale afin de livrer le chargeur de logiciels malveillants. « Dans un scénario d’attaque courant, nous pensons que les utilisateurs sont dirigés vers le téléchargement de paquets MSIX malveillants par le biais de sites web compromis, de techniques d’optimisation du référencement (Search Engine Optimization, SEO) ou de publicité malveillante », ont déclaré les chercheurs dans un billet de blog.
« Les pirates diffusent le loader à l’aide de faux installeurs pour Chrome, Brave, Edge, Grammarly et WebEx, pour ne citer que ceux-là. Les paquets MSIX peuvent être installés via le Windows App Installer par simple « double clic », sans avoir à utiliser un outil de déploiement et de configuration comme PowerShell. « Cependant, le paquet MSIX malveillant doit comporter un certificat acheté ou signé pour mener à bien son offensive », ont ajouté les experts.
Infection initiale par chargement latéral de DLL
Selon eux, l’infection se déroule en plusieurs étapes, en commençant par un exécutable poseur. Le lancement du fichier MSIX ouvre une fenêtre invitant à accepter l’installation, qui aboutit finalement à un téléchargement furtif de Ghostpulse. Lors de la première étape, le programme d’installation télécharge un fichier TAR (Tape archiver), qui est un exécutable se faisant passer pour le service Oracle VM VirtualBox (VBoxSVC.exe), sauf qu’en réalité, il s’agit d’un binaire légitime, intégré à Notepad++ (gup.exe), vulnérable au chargement latéral ou sideloading, selon les chercheurs. « PowerShell exécute le binaire VBoxSVC.exe qui charge latéralement, à partir du répertoire actuel, la DLL malveillante libcurl.dll », ont expliqué les analystes. « En minimisant l’empreinte du code malveillant crypté sur le disque, le cybercriminel est en mesure d’échapper à l’antivirus basé sur les fichiers et à l’analyse ML ».
Ghospulse utilisé comme chargeur
« Ghostpulse utilise le processus Doppelgänging et agit comme un chargeur, tirant parti de la fonction de transactions NTFS pour injecter la charge utile finale dans un autre processus », expliquent encore les chercheurs dans le blog. Le logiciel malveillant final comprend divers voleurs d’informations, tels que SectopRAT, Rhadamanthys, Vidar, Lumma et NetSupport RAT. « L’objectif de la phase 3 (étape finale) de Ghostpulse est de charger et d’exécuter le payload dans un autre processus », observent-ils. « L’un des aspects intéressants de l’étape 3 est qu’elle écrase les instructions précédemment exécutées par d’autres instructions afin de rendre l’analyse difficile ». L’équipe d’Elastic Security Lab indique par ailleurs que Ghostpulse est également capable d’établir une persistance.
Un groupe de cybercriminels s’appuie sur une faille critique dans le gestionnaire de message ActiveMQ pour installer le ransomware HelloKitty. Une mise à jour de la solution corrigeant la vulnérabilité est disponible.
Des attaquants ont commencé à exploiter une vulnérabilité provoquant une exécution de code à distance (RCE) dans Apache ActiveMQ, un gestionnaire open source de message Java. La faille critique a été identifiée par les équipes de Rapid7 « dans deux environnements clients différents ». Et « dans les deux cas, l’attaquant a tenté de déployer des binaires de ransomware sur les systèmes cibles afin de demander une rançon aux victimes ».
Sur la base de la demande de rançon et d’autres détails de l’attaque, Rapid7 pense que les cybercriminels ont déployé le ransomware HelloKitty. Le code source de ce dernier a été divulgué sur des forums clandestins au début du mois.
Une faille dans la désérialisation Java
Le mois dernier, les développeurs d’ActiveMQ ont découvert une brèche critique dans la solution open source d’échange de messages Java. Pour mémoire, ce service prend en charge plusieurs protocoles de transmission pour transférer des messages et des données entre différentes applications et clients écrits dans différents langages de programmation. Il s’agit d’un intergiciel populaire utilisé dans le développement de solutions logicielles d’entreprise.
La vulnérabilité CVE-2023-46604 (corrigée le 25 octobre dernier) a été analysée par des chercheurs en sécurité et des PoC d’exploit ont été élaborés. « La faille peut permettre à un attaquant distant disposant d’un accès réseau à un broker d’exécuter des commandes shell arbitraires en manipulant les types de classe sérialisés dans le protocole OpenWire pour amener le broker à instancier n’importe quelle classe de chemin d’accès (classpath) ». Selon Rapid7, le bug provient d’une désérialisation non sécurisée. La sérialisation consiste à transformer un objet applicatif en un format de données pouvant être restauré ultérieurement. Ce procédé est utilisé pour sauvegarder des objets ou les envoyer dans le cadre de communications. La désérialisation est le processus inverse. La désérialisation Java est une catégorie de vulnérabilités à part entière qui a gagné en popularité ces dernières années, de nombreux projets étant affectés par de telles failles.
Une amélioration de HelloKitty ou un copycat
Apparu en 2020, le ransomware HelloKitty a été très médiatisé après l’attaque du studio de jeux vidéo CD Projekt Red (éditeur de Cyberpunk 2077) en février 2021. Le FBI avait alors émis un avis sur les indicateurs de compromissions pour les campagnes utilisant ce rançongiciel, également connu sous le nom de FiveHands. Mais au début octobre 2023, une archive contenant le code source complet du ransomware HelloKitty a été publiée sur un forum. Dans une note, l’auteur, qui pourrait être le créateur original, indiquait que le groupe travaillait sur un autre ransomware plus performant et que l’actuel était considéré comme dépassé.
Il est difficile de dire si les attaquants qui exploitent actuellement la CVE-2023-46604 font partie de la bande d’origine ou s’ils ont adopté le programme après sa publication. Les chercheurs de Rapid7 ont noté que les cybercriminels semblaient maladroits, échouant à plusieurs reprises à chiffrer des actifs dans l’une des attaques, ce qui laisserait à penser qu’ils sont encore en phase d’apprentissage. Les experts conseillent aux utilisateurs de mettre à jour le plus rapidement possible ActiveMQ comprenant le correctif.