Ivanti Blog: Sécurité

Il suffit de 48 heures à un cybercriminel pour exploiter une vulnérabilité. Pourquoi faut-il 43 jours pour la corriger ?

Wed, 16 Sep 2026 17:11:13 Z

Il n’est pas toujours possible de corriger les vulnérabilités aussi rapidement que les cybercriminels les exploitent, mais les chiffres récents montrent à quel point cet écart s’est creusé.

FortiGuard Labs estime que le délai entre la divulgation d’une vulnérabilité critique et son exploitation active a fortement diminué, pour s’établir entre 24 et 48 heures. À l’inverse, le rapport Data Breach Investigations Report 2026 de Verizon montre qu’il faut en médiane 43 jours aux organisations pour mener à bien la remédiation d’une vulnérabilité.

Comme le savent trop bien de nombreux dirigeants du secteur financier mondial, des dommages considérables peuvent survenir dans les jours et les semaines qui séparent l’exploitation d’une vulnérabilité du déploiement réussi d’un correctif.

Du point de vue des leaders du secteur, ces deux indicateurs évoluent dans la mauvaise direction. Il était autrefois courant que les cybercriminels aient besoin d’une semaine pour exploiter une vulnérabilité. Le processus d’application des correctifs était également plus rapide : le chiffre actuel de 43 jours est en hausse par rapport aux 32 jours enregistrés douze mois plus tôt.

Les cybercriminels vont de plus en plus vite.
L’application des correctifs ralentit.

Courir après les cybercriminels n’est pas la solution

Il peut sembler logique de continuer à courir après les cybercriminels en identifiant et en corrigeant de manière réactive autant de vulnérabilités que possible.

Mais ce n’est pas nécessairement la meilleure option.

Les établissements financiers du monde entier devraient plutôt envisager sérieusement de donner la priorité à une gestion proactive des correctifs. Plutôt que d’essayer de corriger le plus grand nombre possible de vulnérabilités, la priorisation consiste à corriger les bonnes vulnérabilités. Cela inclut des approches comme la gestion des vulnérabilités basée sur les risques, qui pose notamment les questions suivantes : quelles vulnérabilités présentent le risque le plus élevé pour l’entreprise ? Quel est le degré de criticité des actifs concernés ? Quelle est la probabilité qu’elles soient exploitées ? Quel serait l’impact opérationnel potentiel en cas d’exploitation ?

Ces questions peuvent aider à prioriser la réponse et permettre aux équipes IT et sécurité de travailler de manière plus stratégique. C’est particulièrement important compte tenu de la pression cyber croissante à laquelle les établissements financiers sont confrontés dans le monde, alors qu’ils gèrent des environnements IT de plus en plus complexes.

Mesurer les bons indicateurs

Selon un nouveau rapport sur l’état de la cybersécurité, 57 % des professionnels de la sécurité considèrent les vulnérabilités logicielles comme une menace élevée ou critique, tandis que seuls 27 % déclarent être très préparés. Cet écart de 30 points de pourcentage s’est creusé de 11 points en un an seulement.

Avant de pouvoir prioriser efficacement les correctifs, vous devez mesurer les bons indicateurs. Le rapport révèle que seules 51 % des entreprises utilisent un score d’exposition aux risques de cybersécurité ou un autre indice basé sur les risques. Les autres s’appuient sur des indicateurs de processus, tels que le délai moyen de remédiation (47 %) ou le pourcentage d’expositions corrigées (41 %) : des indicateurs de rapidité et de couverture qui renseignent peu sur l’amélioration réelle de la posture de risque. Une entreprise sur trois déclare rencontrer des difficultés à prioriser la remédiation des risques dans des domaines tels que la gestion des correctifs.

L’automatisation peut aider

Alors que les équipes IT et sécurité sont déjà fortement sollicitées, un changement opérationnel peut sembler être une complication supplémentaire plutôt qu’une aide. L’automatisation peut alléger une partie de cette charge, mais seulement si elle est correctement mise en œuvre. Le rapport sur l’état de la cybersécurité a révélé que 92 % des professionnels de la sécurité déclarent que l’automatisation réduit le délai moyen de réponse de leurs équipes. Pourtant, seuls 42 % utilisent l’IA pour la réponse aux vulnérabilités et leur remédiation.

L’automatisation peut permettre de mieux exploiter les informations déjà disponibles. Elle peut accélérer la prise de décision et la priorisation en fonction des risques propres à chaque entreprise. La tendance à la gestion des vulnérabilités basée sur les risques, soutenue par l’automatisation, est déjà visible dans bon nombre des plus grands établissements financiers mondiaux, et le reste du secteur devrait en tenir compte. Les cybercriminels ne deviennent pas moins ambitieux.

Patch Tuesday de septembre 2026

Tue, 08 Sep 2026 20:14:53 Z

Ce qui s’est passé depuis le Patch Tuesday d’août

Le mois a été particulièrement actif entre deux cycles. Depuis la publication de Microsoft du 11 août, cinq CVE Microsoft ont été confirmées comme exploitées en conditions réelles, et Google a publié un correctif Chrome d’urgence pour une sixième vulnérabilité zero-day de 2026. Rien de tout cela n’est théorique : les six figurent aujourd’hui dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, et deux sont attribuées à des acteurs étatiques. Avant d’aborder la publication d’aujourd’hui, voici ce que les équipes de défense devraient déjà avoir traité — ou faire remonter immédiatement si ce n’est pas le cas :

Microsoft — exploitation confirmée depuis la publication d’août, publication incluse :

CVE-2026-68820 — Windows Ancillary Function Driver for WinSock (afd.sys), élévation de privilèges. Important, CVSS 7.0. Une faille de type use-after-free permet à un attaquant authentifié localement de remporter une condition de concurrence et d’élever ses privilèges jusqu’à SYSTEM. Exploitation en conditions réelles confirmée dès la publication d’août ; Check Point Research associe l’exploitation active à la campagne Operation Dream Job du groupe Lazarus, avec le déploiement d’une nouvelle version du rootkit noyau FudModule. Correctif disponible : 11 août 2026 (ajoutée au KEV de la CISA le jour même de sa divulgation). Confirmez le déploiement si ce n’est pas déjà fait.
CVE-2026-33824 — Windows Internet Key Exchange (IKE) Service Extensions, exécution de code à distance. Critique, CVSS 9.8. Une vulnérabilité de type double-free, exploitable sous forme de ver et sans authentification. Correctif disponible : 14 avril 2026 — cette vulnérabilité est restée corrigée pendant plus de quatre mois avant que la CISA ne confirme son exploitation active et ne l’ajoute au KEV le 18 août 2026. Si elle n’est toujours pas traitée quelque part dans votre environnement, elle est exploitable en conditions réelles depuis plusieurs semaines, avec un correctif disponible dans la console de mise à jour depuis le printemps.
CVE-2026-55040 — Microsoft SharePoint Server, contournement de fonctionnalité de sécurité (authentification faible). Critique, CVSS 9.1. Correctif disponible : 14 juillet 2026 (Patch Tuesday de juillet). L’exploitation a commencé quelques heures après la publication de l’analyse technique publique de Rapid7 le 11 août ; ajoutée au KEV de la CISA le 18 août. Cette faille est également enchaînée avec CVE-2026-63520 (correctif disponible le 11 août 2026 — Patch Tuesday d’août) pour un contournement de l’authentification suivi d’une exécution de code à distance : les deux correctifs sont nécessaires pour fermer toute la chaîne.
CVE-2019-1068 — Microsoft SQL Server, exécution de code à distance. Correctif disponible : 9 juillet 2019. Réajoutée au catalogue KEV de la CISA le 26 août 2026 sur la base de nouvelles preuves d’exploitation active, bien qu’il s’agisse d’une CVE vieille de six ans. Un rappel qu’« ancien » ne signifie pas « peut être dépriorisé sans risque » : ce correctif est disponible depuis des années.
CVE-2026-62832 — Windows User Profile Service, élévation de privilèges. Important, CVSS 7.8. Divulguée publiquement avant la disponibilité du correctif pendant le cycle d’août et évaluée par Microsoft comme « exploitation plus probable ». Aucune exploitation confirmée et absente du catalogue KEV de la CISA à la date de rédaction ; aucune date de disponibilité de correctif KEV ne s’applique donc — elle est incluse ici compte tenu de l’évaluation de risque élevée.

Google Chrome — exploitation confirmée depuis le Patch Tuesday d’août :

CVE-2026-85046 — moteur JavaScript/WebAssembly Chrome V8, confusion de type. Sévérité élevée, CVSS 8.8. Un contenu web spécialement conçu peut déclencher une lecture/écriture arbitraire dans le bac à sable de Chrome, pouvant conduire à l’exécution de code. Google a confirmé qu’un exploit existait en conditions réelles au moment de la publication du correctif. Correctif disponible : 3 septembre 2026 (Chrome 152.0.7977.82/.83) — il s’agit de la sixième vulnérabilité zero-day de Chrome confirmée comme exploitée en 2026, et de la troisième ciblant spécifiquement V8. Ajoutée au KEV de la CISA : 4 septembre 2026, avec une échéance de remédiation FCEB fixée au 18 septembre. Microsoft Edge, Brave, Opera et Vivaldi héritent tous de la faille Chromium sous-jacente et nécessitent leurs propres mises à jour éditeur.

Si l’un des points ci-dessus reste en suspens dans votre environnement, traitez-le comme plus prioritaire que tout élément de la publication d’aujourd’hui : une exploitation confirmée l’emporte toujours sur le score CVSS.

Publication Microsoft du jour

Le Patch Tuesday de Microsoft de septembre 2026 corrige 973 CVE — l’une des plus importantes publications uniques de l’année — dont 119 classées Critiques et deux vulnérabilités zero-day, toutes deux confirmées comme exploitées en conditions réelles (CVE-2026-85880, CVE-2026-81963).

Vulnérabilités exploitées connues / zero-day (publication du jour)

CVE-2026-85880 — dépassement de tampon basé sur le tas dans Windows ALPC (Advanced Local Procedure Call), élévation de privilèges. Sévérité élevée, CVSS 7.8 / 6.8. Permet à un attaquant local autorisé disposant de faibles privilèges d’élever ses privilèges jusqu’à SYSTEM sans interaction utilisateur. Produits affectés : Windows 10, Windows 11, Windows Server 2012, Server 2012 R2, Server 2016, Server 2019, Server 2022 — soit, dans les faits, l’ensemble du parc Windows Server et postes de travail pris en charge. L’avis de Microsoft la répertorie comme exploitée en conditions réelles. Correctif disponible aujourd’hui, 8 septembre 2026.
CVE-2026-81963 — élévation de privilèges. CVSS 7.8 / 7.2. Produits affectés : Windows 11, Windows Server 2025. Une exploitation réussie pourrait permettre à un attaquant d’obtenir des privilèges SYSTEM. L’avis de Microsoft la répertorie comme exploitée en conditions réelles. Son rayon d’impact est nettement plus limité que celui de CVE-2026-85880 : seules les versions d’OS les plus récentes sont affectées. Les environnements encore sous Windows 10 ou d’anciennes versions de Server ne sont donc pas exposés à cette faille précise, même s’ils restent exposés à CVE-2026-85880 ci-dessus. Correctif disponible aujourd’hui, 8 septembre 2026.

Vulnérabilités tierces

Adobe : Adobe a publié 10 bulletins de sécurité entre le 7 et le 8 septembre 2026, corrigeant environ 161 CVE au total. Les mises à jour concernent : Experience Manager (APSB26-98), ColdFusion (APSB26-119), Photoshop (APSB26-130), Illustrator (APSB26-131), Animate (APSB26-132), Photoshop Mobile (APSB26-136), Commerce (APSB26-138 — un second bulletin Commerce de routine, distinct du correctif zero-day d’hier), Acrobat and Reader (APSB26-141) et Campaign Classic (APSB26-142). La vulnérabilité zero-day CVE-2026-75650 dans Adobe Commerce (APSB26-146, publiée le 7 septembre — exécution de code arbitraire sans authentification, déjà exploitée pour installer des portes dérobées dans des boutiques en ligne) reste l’élément le plus notable et devrait conserver sa propre mise en avant, séparée du lot de routine d’aujourd’hui.

Mozilla : Firefox 155, publié le 1er septembre, a corrigé 29 vulnérabilités, dont 13 classées critiques. Aucune preuve d’exploitation en conditions réelles pour l’une d’entre elles. Firefox pour iOS a été publié le 8 septembre et corrige une CVE classée de faible sévérité.

Chrome/Edge : Chrome 152.0.7977.82/.83 a corrigé 12 vulnérabilités au total dans la publication du 3 septembre 2026, notamment CVE-2026-85046, exploitée activement. Les mises à jour d’Edge, Brave, Opera et Vivaldi devraient suivre selon les calendriers propres à chaque éditeur.

Mise à jour de sécurité Ivanti de septembre 2026

Ivanti a divulgué 10 CVE concernant trois produits aujourd’hui, 8 septembre 2026 : Endpoint Manager Mobile (EPMM), Neurons for ITSM et Sentry. Ivanti indique ne disposer d’aucune preuve d’exploitation active de ces vulnérabilités avant leur divulgation.

Ivanti Neurons for ITSM a corrigé huit CVE. Les clients Cloud/SaaS étaient déjà protégés : Ivanti a appliqué le correctif à tous les environnements cloud le 9 août 2026. Les administrateurs sur site doivent appliquer dès maintenant le Security Patch de septembre 2026 correspondant à leur version via Ivanti License Server (ILS) ; la version sur site 2026.2 intégrera le correctif à sa sortie, le 21 septembre 2026.
Ivanti Endpoint Manager Mobile (EPMM) a corrigé une CVE. Sont affectées les versions 12.9.0.1 et antérieures, 12.8.0.3 et antérieures, ainsi que toutes les versions antérieures à 12.10.0.0. Corrigée dans les versions 12.10.0.0, 12.9.0.2 et 12.8.0.4.
Ivanti Sentry a corrigé une CVE. Sont affectées les versions R10.8.1, R10.7.2, R10.6.3 et antérieures. Corrigée dans les versions R10.8.2, R10.7.3 et R10.6.4. Également pertinent pour les déploiements Sentry gérés via EPMM et Neurons for MDM.

Liste des actions à mener pour les mises à jour de septembre

Corrigez immédiatement Adobe Commerce (CVE-2026-75650), car cette vulnérabilité fait actuellement l’objet d’une exploitation active, indépendamment du Patch Tuesday d’aujourd’hui.
Confirmez que les cinq CVE Microsoft et la CVE Chrome répertoriées dans la section « depuis août » ci-dessus sont corrigées dans votre environnement : elles sont antérieures à la publication d’aujourd’hui, mais restent les risques exploités en suspens les plus avérés.
Appliquez les correctifs immédiatement en raison de l’exploitation active : CVE-2026-85880 affecte l’ensemble du parc Windows (10, 11, Server 2012–2022) — priorisez-la à tous les niveaux. CVE-2026-81963 a une portée plus limitée (Windows 11 et Server 2025 uniquement), mais elle n’est pas moins urgente pour les environnements exécutant ces versions. Toutes deux sont des vulnérabilités zero-day confirmées comme exploitées dans la publication d’aujourd’hui et sont prioritaires sur le reste du lot Microsoft.
Déployez les mises à jour Windows OS + Office afin de corriger l’essentiel des 973 CVE restantes ; avec 119 vulnérabilités Critiques ce mois-ci, donnez la priorité aux systèmes exposés à Internet et aux postes utilisateurs.
Priorisez les mises à jour des navigateurs (Chrome, Firefox, Edge) selon un rythme hebdomadaire, quelle que soit leur sévérité.

Patch Tuesday d’août 2026

Tue, 11 Aug 2026 20:14:02 Z

Quelles que soient les opinions sur l’IA, il est clair que l’accélération de l’application des correctifs en fonction des vulnérabilités identifiées oblige le secteur de la gestion des correctifs à faire face à l’apocalypse des correctifs. La question clé est de savoir comment y faire face alors même que Microsoft recommande un délai de trois jours pour appliquer les correctifs afin de garder une longueur d’avance sur les menaces « accélérées par l’IA ». Le défi est que les grandes entreprises sont limitées par les exigences de test, de contrôle des changements et de compatibilité. Pour y répondre, il faut mettre en place un processus permettant de déployer les correctifs essentiels afin de réduire les risques en quelques jours, tout en conservant une approche rigoureuse pour le reste.

La première étape de ce nouveau processus consiste à comprendre que toutes les CVE ne se valent pas. Les correctifs doivent être triés afin d’identifier les CVE qui requièrent une attention immédiate, notamment celles liées à une exploitation ou à une divulgation connue, à des malwares connus, à la liste KEV de la CISA, ou encore à des vulnérabilités exposées à Internet ou ne nécessitant pas d’authentification, etc. Une fois ces CVE identifiées, vous pouvez établir une liste des correctifs à envisager immédiatement pour votre environnement. Mais vous devez rester rigoureux et garder à l’esprit que même les CVE présentant des scores CVSS élevés, si elles ne sont pas exploitées ou ne sont pas exposées à Internet, peuvent être traitées lors d’une deuxième vague de correctifs. Tout le reste peut être pris en charge dans la séquence normale de gestion des correctifs de votre organisation, qui peut intervenir dans un délai de deux à trois semaines. Cette répartition correspond globalement à la manière dont Ivanti Neurons gère l’application des correctifs, avec le cycle de correctifs zero-day qui respecte la norme Microsoft de trois jours, le cycle de correctifs prioritaires qui a lieu toutes les deux semaines, puis la maintenance régulière qui intervient environ toutes les trois semaines ou une fois par mois.

Le tri des correctifs n’est pas la seule étape de ce nouveau processus. Vous devez connaître votre environnement et comprendre votre exposition aux CVE triées. En vous appuyant sur votre connaissance du réseau, vous devez donner la priorité aux systèmes exposés à Internet et exploitables à distance. Les systèmes plus en profondeur dans votre environnement pourront peut-être être corrigés dans le cadre d’une deuxième vague plus large. N’oubliez pas de tenir compte de l’impact opérationnel et du risque de perturbation associés aux systèmes métier clés ; certains systèmes peuvent être plus sensibles à l’application de correctifs. Avec ces informations, vous devriez être en mesure de hiérarchiser et d’organiser les systèmes en groupes prioritaires pour l’application des correctifs. Vous pouvez désormais affecter les correctifs et les systèmes aux trois cycles de correctifs mentionnés précédemment. Mais attendez !

La dernière étape de ce processus consiste à définir une méthodologie de test, selon les besoins, avant le déploiement. L’expérience montre que la qualité des correctifs et l’impact de leur installation varient fortement selon de nombreux facteurs. En tant qu’organisation, vous seule pouvez décider du niveau de test requis. Parmi les questions à se poser : 1) combien de temps de test est disponible avant l’ouverture de notre prochaine fenêtre de maintenance ; 2) pouvons-nous maintenir une suite minimale de tests de validation rapide pour les systèmes critiques afin de ne pas intervenir à l’aveugle sur les systèmes en production ; 3) pouvons-nous identifier les systèmes moins sensibles aux correctifs et mettre en place un test de validation rapide en circuit accéléré pour réduire les délais ; 4) et bien d’autres encore. La méthodologie de test doit être alignée sur les cycles de correctifs proposés afin de prendre les décisions finales sur la vitesse d’exécution. Par exemple, pouvons-nous tester les derniers correctifs de système d’exploitation contenant des CVE zero-day destinés à des serveurs métier critiques, puis les déployer en trois jours ? Dans l’idéal, oui, c’est souhaitable, mais dans la réalité, les risques de sécurité par rapport aux risques opérationnels peuvent imposer un autre cycle de correctifs.

En résumé, seule une petite fraction des vulnérabilités divulguées est confirmée comme exploitée dans la nature. L’objectif est ici de tester et de déployer d’abord les correctifs qui concernent les systèmes présentant les risques les plus élevés, puis de progresser méthodiquement dans l’ensemble de votre environnement d’entreprise. Le processus doit avancer rapidement, car une nouvelle vague de mises à jour logicielles est déjà imminente dans l’apocalypse des correctifs.

Vulnérabilités Microsoft exploitées

Une vulnérabilité exploitée a été signalée ce mois-ci. CVE-2026-68820 est une vulnérabilité d’élévation de privilèges dans le pilote de fonction auxiliaire Windows pour WinSock, classée Important. Microsoft confirme qu’elle est exploitée dans la nature. Ce pilote a été une cible récurrente de failles d’élévation de privilèges locales tout au long de 2026, et des vulnérabilités antérieures dans ce composant ont permis à un attaquant autorisé d’exploiter une condition de concurrence pour obtenir des privilèges SYSTEM.

Vulnérabilités Microsoft divulguées publiquement

Deux vulnérabilités divulguées publiquement présentent un intérêt ce mois-ci. CVE-2026-62832 est une vulnérabilité d’élévation de privilèges dans le service de profil utilisateur Windows, classée Important. Il s’agit de la faille à l’origine de « LegacyHive », la preuve de concept non corrigée publiée par le chercheur Nightmare-Eclipse quelques heures seulement après le Patch Tuesday de juillet. Cette vulnérabilité permet à un utilisateur standard de contraindre le service de profil utilisateur à charger la ruche de registre d’un autre utilisateur, y compris celle d’un administrateur, afin d’obtenir un accès non autorisé aux données de registre Classes de cet utilisateur.

CVE-2026-72971 est une vulnérabilité de falsification dans le pilote de filtre FS d’isolation des conteneurs Windows (unionfs.sys), classée Important. Une divulgation publique avant la disponibilité d’un correctif signifie que du code d’exploitation pourrait suivre rapidement ; les organisations qui exécutent des conteneurs Windows, des agents de build ou une infrastructure CI sur des hôtes affectés doivent prioriser cette mise à jour de manière appropriée.

Avis de sécurité Ivanti

Ivanti a publié deux mises à jour de sécurité pour le mois d’août. Ces mises à jour concernent Ivanti Endpoint Manager et Ivanti Neurons for Mobile Device Management. Elles corrigent au total trois CVE. Vous trouverez davantage de détails et d’informations sur les mesures d’atténuation dans l’Avis de sécurité d’août.

Liste des actions à mener pour les mises à jour d’août

Vérifiez à nouveau vos appareils Apple afin de confirmer que les derniers correctifs du 6 août ont été déployés. De même, assurez-vous qu’Oracle Java et les autres applications Oracle ont bien été mis à jour à partir de la publication mensuelle des CPU. N’oubliez pas non plus qu’Oracle publie désormais des mises à jour de sécurité tous les mois.
La priorité ce mois-ci est d’appliquer les correctifs aux systèmes d’exploitation Windows. La vulnérabilité Winsock CVE-2026-68820 est exploitée dans la nature et affecte tous les systèmes d’exploitation, de Windows Server 2012 aux dernières versions de Windows 11 et Server 2025 : appliquez le correctif immédiatement. Ces mises à jour corrigeront également CVE-2026-62832, qui a été divulguée sans correctif officiel depuis plus d’un mois. Elle est corrigée dans la publication d’aujourd’hui ; traitez donc ces mises à jour de système d’exploitation comme une priorité.

Patch Tuesday de juillet 2026

Tue, 14 Jul 2026 21:28:13 Z

Veille du Patch Tuesday : ce qui a précédé juillet 2026

Adobe

Date de publication : 30 juin 2026 (APSB26-68 — ColdFusion ; bulletin publié le même jour pour Campaign Classic)

Nombre de CVE : 11 CVE dans ColdFusion, 1 dans Campaign Classic (12 au total)

La mise à jour ColdFusion d’Adobe a corrigé 11 vulnérabilités dans ColdFusion 2025 (Update 9 et versions antérieures) et ColdFusion 2023 (Update 20 et versions antérieures), dont sept avec un score CVSS de 10,0 :

Corrigées dans ColdFusion 2025 Update 10 et ColdFusion 2023 Update 21.

Point d’attention KEV : CVE-2026-48282 n’était pas signalée comme exploitée lors de sa publication, mais son exploitation a commencé environ deux heures après la publication d’un article technique public le 2 juillet. La CISA l’a ajoutée au catalogue KEV le 7 juillet, avec une échéance fédérale de remédiation fixée au 10 juillet — déjà dépassée. Toute instance ColdFusion exposée à Internet et encore non corrigée doit être traitée comme un incident actif, et non comme un simple élément de correctif de routine.

La CVE-2026-48286 de Campaign Classic (CVSS 10,0, autorisation incorrecte → exécution de code arbitraire) affecte les builds ACC v7 sur site 7.4.3 et antérieures. Les instances hébergées par Adobe avaient déjà été corrigées ; aucune exploitation n’a été signalée pour celle-ci.

Apple

Date de publication : 1er juillet 2026 (iOS/iPadOS 26.5.2, macOS Tahoe 26.5.2, Safari 26.5.2)

Nombre de CVE : 37 CVE (26 dans WebKit ; 11 dans le noyau, WebRTC, Web Extensions et d’autres composants)

Google Chrome

Dates de publication : 24 juin 2026 (Chrome 149.0.7827.197) et 8 juillet 2026 (Chrome 150.0.7871.114/.115) Nombre de CVE : 10 CVE (24 juin) + 27 CVE (8 juillet) = 37 CVE sur les deux versions

La mise à jour du 24 juin a corrigé 10 vulnérabilités, la plus sévère étant CVE-2026-13028 (CVSS 9,6, Critique) — une vulnérabilité use-after-free dans WebGL permettant une exécution de code à distance (RCE), en particulier sur Android.

La mise à jour du 8 juillet (Chrome 150) a corrigé 27 vulnérabilités supplémentaires : deux Critiques (CVE-2026-15112, CVE-2026-15129 — toutes deux de type use-after-free), 24 de sévérité Élevée (principalement des use-after-free dans Views, Extensions, Autofill, WebRTC et Codecs) et une Moyenne.

Point d’attention KEV : la précédente faille zero-day de Chrome, CVE-2026-11645 (lecture/écriture hors limites dans V8, exploitée activement), a été ajoutée au catalogue KEV de la CISA au titre de la BOD 26-04, avec une échéance au 23 juin — déjà dépassée au début de ce cycle. Aucune nouvelle CVE Chrome issue des publications du 24 juin ou du 8 juillet n’a été confirmée comme exploitée à ce jour.

Mozilla

Dates de publication : la version de sécurité la plus récente pour ordinateur était Firefox 152.0.4 (30 juin 2026, selon MFSA 2026-62) ; les MFSA suivantes (2026-64 à 2026-66) couvrent Thunderbird 140.12.1 et Firefox pour iOS 152.3/152.4 — des mises à jour mineures et uniquement mobiles

Nombre de CVE : aucun nouveau bulletin CVE Firefox/Thunderbird pour ordinateur dans la semaine précédant immédiatement le Patch Tuesday

Synthèse du Patch Tuesday

Le Patch Tuesday de Microsoft de juillet 2026 corrige ce mois-ci pas moins de 570 CVE, dont la majorité (509) sont classées Importantes, 58 Critiques et trois Modérées. Du point de vue de l’impact, les 249 élévations de privilèges et 143 exécutions de code à distance constituent l’essentiel des types d’impact, suivies de 102 divulgations d’informations. Deux CVE sont confirmées comme exploitées activement — une faille d’élévation de privilèges dans SharePoint (CVE-2026-56164) et une faille d’élévation de privilèges dans Active Directory Federation Services (CVE-2026-56155) — et une CVE, affectant Windows BitLocker (CVE-2026-50661), a été divulguée publiquement.

Adobe a publié 11 mises à jour corrigeant 88 CVE, dont 63 Critiques, 22 Importantes et trois Modérées. La répartition par impact comprend 51 vulnérabilités d’exécution de code arbitraire, 13 de contournement de fonctionnalité de sécurité, 12 d’escalade de privilèges, 7 de déni de service applicatif, trois de lecture arbitraire du système de fichiers et deux d’exposition de mémoire. Hormis la publication ColdFusion avant le Patch Tuesday, qui incluait un exploit connu, les 11 mises à jour du Patch Tuesday ne comprenaient aucun exploit connu ni divulgation publique.

Mozilla a publié Firefox 152.0.6, corrigeant deux CVE critiques. Du code d’exploitation divulgué publiquement est disponible pour les deux vulnérabilités (CVE-2026-15718 et CVE-2026-15719) ; toutefois, Mozilla n’a actuellement connaissance d’aucune exploitation active.

Google Chrome Desktop 150.0.7871.124/.125 a été publié pour Windows et Mac. Aucune CVE n’a été signalée lors de la publication, mais compte tenu du nombre considérable de vulnérabilités corrigées au cours du dernier mois et demi, il est préférable de s’assurer que toutes les installations Chrome utilisent la dernière version.

Vulnérabilités Microsoft exploitées

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Microsoft SharePoint Server (CVE-2026-56164). Cette vulnérabilité est classée Modérée par Microsoft et présente un score CVSS de 5,3, mais elle a été activement exploitée. Un attaquant non autorisé pourrait élever ses privilèges via un réseau. Le vecteur d’attaque de la CVE est le réseau, car elle est exploitable à distance depuis Internet. La complexité de l’attaque est également classée comme faible. Microsoft a fourni certains facteurs d’atténuation susceptibles d’aider à détecter une attaque éventuelle, mais une méthodologie de priorisation fondée sur les risques justifie de corriger cette vulnérabilité dès que possible.

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Active Directory Federation Services (CVE-2026-56155). Cette vulnérabilité est classée Importante et présente un score CVSS de 7,8, mais elle a été activement exploitée. Elle pourrait permettre à un attaquant d’élever localement ses privilèges afin d’obtenir des droits administrateur. Microsoft classe cette vulnérabilité comme Importante, mais une méthodologie de priorisation fondée sur les risques justifie de la corriger dès que possible.

Vulnérabilités Microsoft divulguées publiquement

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans Windows BitLocker (CVE-2026-50661). Cette vulnérabilité est classée Importante par Microsoft et présente un score CVSS de 6,1, mais elle a été divulguée publiquement. Une attaque réussie pourrait contourner la fonctionnalité BitLocker Device Encryption sur le périphérique de stockage système, permettant l’accès aux données chiffrées. Même si la maturité du code pour cette vulnérabilité est actuellement indiquée comme non démontrée, la divulgation signifie que des informations sont disponibles pour orienter un acteur malveillant vers une exploitation. Une approche de priorisation fondée sur les risques justifie de corriger cette vulnérabilité en priorité ce mois-ci.

Avis de sécurité Ivanti

Ivanti a publié une mise à jour de sécurité pour Ivanti Xtraction corrigeant deux CVE (une de sévérité Élevée et une de sévérité Moyenne). Vous trouverez plus de détails et d’informations sur les mesures d’atténuation dans l’avis de sécurité de juillet.

Liste des actions pour la mise à jour de juillet

Envisagez de passer à une approche de remédiation plus continue si ce n’est pas déjà fait. L’augmentation continue de la découverte des CVE et de la fréquence des mises à jour, due à la découverte des vulnérabilités accélérée par l’IA, va se poursuivre, et la pression réglementaire visant à corriger les expositions les plus à risque en quelques jours, voire quelques heures, deviendra la nouvelle norme.
Mettez à jour vos navigateurs ! Tous. À ce stade, ils suivent un rythme hebdomadaire, mais envisagez de vérifier et d’effectuer les mises à jour deux fois par semaine, voire quotidiennement, afin de réduire la fenêtre d’exploitation des vulnérabilités connues comme exploitées.
Corrigez ou atténuez les vulnérabilités connues comme exploitées dans Microsoft SharePoint (CVE-2026-56164), le système d’exploitation Windows (CVE-2026-56155), et Adobe ColdFusion (CVE-2026-48282) dès que possible.

Comment l’IA agentique permet une réponse autonome aux menaces à la vitesse de la machine

Mon, 29 Jun 2026 14:00:02 Z

Pourquoi 40 % des alertes reçues par les équipes de sécurité restent-elles aujourd’hui totalement non investiguées ? Ce n’est pas par manque d’attention, mais parce que les fenêtres d’attaque se raccourcissent, avec une prolifération technologique écrasante qui aggrave encore la situation.

Les équipes de sécurité actuelles évoluent dans un paysage de menaces marqué par l’escalade des attaques, des budgets plus contraints et une fatigue liée aux alertes toujours plus importante. Les organisations traitent en moyenne 960 alertes de sécurité par jour, et les grandes entreprises gèrent plus de 3 000 alertes quotidiennes au moyen d’environ 30 outils. Cela représente 36 000 menaces potentielles par mois susceptibles de passer entre les mailles du filet. L’asymétrie est implacable : les attaquants n’ont besoin que d’une seule compromission réussie, tandis que les défenseurs doivent avoir raison à chaque fois.

Cette faille critique pour les organisations est un problème d’architecture. Le plus grand défi de la réponse aux menaces n’est pas ce qui est détecté, mais ce qui se passe ensuite, une fois l’alerte déclenchée.

La bonne nouvelle ? L’IA agentique transforme cette architecture. Non pas en remplaçant les outils existants, mais en comblant l’écart opérationnel entre détection et action.

Le défi de la vitesse en sécurité

Les outils que vous avez déployés (SIEM, EDR, scanners de vulnérabilités, plateformes SOAR) sont excellents pour la détection. Ils font remonter les menaces, répertorient les risques et envoient les alertes. Mais la détection sans réponse efficace n’est qu’une documentation coûteuse. Le véritable goulot d’étranglement consiste à corriger les problèmes assez vite pour que cela compte, et non simplement à savoir ce qui ne va pas.

En savoir plus :Pourquoi la gestion traditionnelle des vulnérabilités ne résiste plus à la découverte pilotée par l’IA

Les opérations de sécurité traditionnelles suivent une séquence bien connue : une alerte se déclenche, un analyste enquête, une décision est prise, la remédiation est planifiée, le changement est approuvé… et ce n’est qu’ensuite que l’action est menée. Chaque étape a du sens prise isolément, mais ensemble, elles enferment les équipes dans une vitesse humaine alors que les menaces évoluent de manière autonome. Lorsque l’enquête est terminée, l’adversaire s’est déjà déplacé latéralement. Et lorsqu’un correctif est déployé, trois autres CVE critiques ont été divulguées.

L’écart temporel est saisissant. Selon le rapport Verizon Data Breach Investigations Report 2025, les organisations mettent un délai médian de 32 jours à remédier aux vulnérabilités des périphériques en périphérie, tandis que les acteurs malveillants exploitent ces mêmes vulnérabilités au moment de leur divulgation publique, voire avant, opérant de fait sur un calendrier de type zero-day. Et cet écart s’accélère : le rapport M-Trends 2026 de Mandiant révèle que le délai entre l’accès initial et le transfert à un groupe de menace secondaire est passé de plus de huit heures en 2022 à seulement 22 secondes en 2025.

Un modèle de sécurité efficace exige que la détection déclenche une action immédiate et intelligente. Les capacités existantes telles que l’évaluation des vulnérabilités , la gestion des terminaux , le déploiement de correctifs et les contrôles d’accès restent en place, mais fonctionnent plus rapidement et avec davantage d’autonomie. Il en résulte des opérations de sécurité qui s’exécutent à la vitesse de la machine plutôt qu’à la vitesse humaine.

À quoi ressemble réellement la sécurité agentique

En sécurité, l’IA agentique désigne des systèmes autonomes qui exécutent des workflows de sécurité de bout en bout. Ils passent de la détection à la décision puis à l’action, sans attendre une approbation manuelle à chaque étape.

L’IA agentique doit intervenir sur l’ensemble de la surface d’attaque, en coordonnant détection, décision et réponse comme un système unique.

Remédiation autonome des vulnérabilités

Lorsqu’une CVE critique est divulguée, les agents évaluent immédiatement l’exposition dans tout l’environnement. Ils hiérarchisent les risques en fonction de l’exploitabilité et du contexte métier, déploient les correctifs sur les terminaux affectés et vérifient la remédiation. Tout cela se produit avant même qu’un analyste n’ouvre un ticket. La supervision humaine reste en place, mais le délai créé par les transferts manuels est supprimé.

En savoir plus :Rapport sur la priorisation des correctifs basée sur les risques

Réponse intelligente aux menaces

Lorsqu’un terminal présente un comportement suspect, les agents corrèlent les signaux provenant de l’EDR, de la télémétrie réseau et de l’inventaire des actifs. Les appareils affectés sont isolés ; les sessions actives sont révoquées ; les preuves forensiques sont collectées et le SOC est alerté avec tout le contexte nécessaire. La menace est contenue avant de se propager, ce qui permet aux analystes d’enquêter sur un incident neutralisé plutôt que sur une compromission active.

Posture de conformité continue

Les agents surveillent en continu les terminaux et les serveurs afin de détecter toute dérive de configuration. Lorsqu’un appareil n’est plus conforme, par exemple si un pare-feu est désactivé, si le chiffrement est coupé ou si un logiciel non autorisé est installé, la remédiation intervient automatiquement. La configuration est corrigée ; l’événement est consigné et la conformité est vérifiée. La conformité devient un état permanent plutôt qu’un exercice trimestriel.

Atténuation des risques d’accès

Les agents détectent les schémas d’accès anormaux, notamment les géolocalisations inattendues, les tentatives d’élévation de privilèges et les accès inhabituels aux données. Les sessions suspectes sont interrompues ; l’authentification multifacteur est appliquée et l’accès est réduit jusqu’à la fin de la vérification. Les utilisateurs légitimes continuent de travailler tandis que les mouvements latéraux sont stoppés en temps réel.

Ces agents fonctionnent au sein de la pile de sécurité existante, notamment le SIEM, l’EDR, la gestion des vulnérabilités , les systèmes d’identité et la gestion des correctifs. Chaque outil devient plus rapide et plus efficace au sein d’un système coordonné. L’objectif n’est pas de remplacer les opérations de sécurité, mais de leur permettre d’évoluer à la vitesse à laquelle les adversaires opèrent déjà.

En savoir plus :Comment l’IA agentique transforme l’infrastructure et les opérations

De la détection à l’action : l’architecture de la vitesse

Le changement fondamental rendu possible par l’IA agentique est la prise de décision au point de détection. Plutôt que de séparer la détection de l’action, les workflows de sécurité sont conçus pour évaluer le risque et répondre immédiatement à mesure que les menaces émergent.

Lorsqu’une vulnérabilité critique est identifiée, l’agent ne crée pas un ticket à examiner plus tard. Il évalue les mêmes facteurs qu’un architecte sécurité prendrait en compte :

Le système est-il exposé à Internet ?
À quelles données accède-t-il ?
Existe-t-il un exploit connu en circulation ?
Quel est l’impact métier d’un correctif par rapport à un report ?

Cette décision est prise en millisecondes plutôt qu’en plusieurs jours. Et pour obtenir ce résultat, il faut plus que des scripts d’automatisation : il faut des systèmes capables de raisonner sur le contexte et les conséquences.

Notation des risques tenant compte du contexte métier

Toutes les vulnérabilités critiques ne présentent pas le même degré d’urgence. Les agents évaluent ensemble l’exploitabilité, l’exposition et l’impact métier. Une vulnérabilité sur un serveur de test interne est traitée différemment de la même faille sur un système de production exposé aux clients. La priorisation se fait automatiquement, et sa justification est claire et défendable.

Seuils de réponse adaptatifs

Les agents apprennent des résultats au fil du temps. Lorsque certaines actions produisent régulièrement des faux positifs, les seuils s’ajustent. Lorsque de nouveaux schémas d’attaque apparaissent, la sensibilité augmente. Le système s’améliore à l’usage, au lieu de devenir plus fragile lorsque les conditions changent.

Escalade avec conservation du contexte

Lorsqu’un agent atteint la limite de son autonomie, l’escalade inclut le raisonnement, et pas seulement une alerte. Ce qui a été détecté, les signaux évalués, la raison pour laquelle la décision n’a pas pu être menée de manière autonome et l’action recommandée sont transmis à l’analyste. L’intervention humaine se concentre sur les décisions importantes, pas sur le triage.

Auditabilité intégrée

Chaque action est enregistrée avec tout son contexte, notamment le déclencheur, les données évaluées, la décision prise et le résultat. La conformité est intégrée directement au workflow au lieu d’être reconstituée a posteriori.

L’impact sur les équipes de sécurité est mesurable. L’enquête SANS Detection & Response Survey 2025 a révélé que 73 % des organisations citent les faux positifs comme leur principal défi en matière de détection, et que 76 % désignent la fatigue liée aux alertes comme une préoccupation majeure du SOC. Il ne s’agit pas seulement d’une question d’efficacité. Lorsque les analystes consacrent la majeure partie de leur temps à trier le bruit, les programmes de sécurité restent réactifs par conception.

Le résultat est une réalité opérationnelle différente. La détection mène à la résolution. Les alertes sont traitées au fur et à mesure qu’elles apparaissent au lieu de s’accumuler dans des files d’attente. Les équipes de sécurité passent moins de temps à répondre aux incidents d’hier et davantage à prévenir le prochain.

Ce qui change en pratique

Lorsque l’IA agentique est déployée dans des environnements de sécurité en production, son impact apparaît moins comme une série de réussites isolées que comme un changement structurel. Les équipes constatent des évolutions constantes dans la structuration des workflows, la rapidité de réduction des risques et l’allocation de l’effort humain.

1. Le délai d’action se réduit considérablement

Détection et réponse se fondent en un seul mouvement. Les vulnérabilités qui attendaient auparavant plusieurs jours pour être triées et planifiées sont évaluées, priorisées et corrigées automatiquement lorsque les seuils de risque sont atteints. Les menaces qui se déplaçaient auparavant latéralement pendant l’enquête sont contenues au point de détection. Le résultat mesurable est une durée de présence plus courte et une réduction plus rapide des risques, et pas seulement des alertes plus rapides.

2. La charge opérationnelle diminue

Les tâches de sécurité courantes qui mobilisaient auparavant le temps des analystes, comme la remédiation des dérives de conformité, la coordination des correctifs et les corrections d’accès, passent en exécution continue en arrière-plan. Le reporting devient un sous-produit des opérations normales plutôt qu’une course périodique. Les équipes de sécurité passent moins de temps à gérer des processus et davantage à exercer leur jugement.

3. La qualité de la réponse devient plus homogène

Lorsque les décisions sont prises à chaque fois à partir des mêmes éléments contextuels, le comportement de réponse se stabilise. Des risques similaires sont traités de manière similaire, quel que soit le moment où ils surviennent ou la personne d’astreinte. Cette cohérence réduit la variabilité, limite les erreurs humaines et rend les résultats plus faciles à expliquer aux auditeurs, aux dirigeants et aux régulateurs.

4. L’attention humaine se déplace vers des tâches à plus forte valeur ajoutée

Les analystes ne sont plus sollicités pour chaque alerte ou problème mineur de configuration. Ils interviennent lorsque l’escalade est justifiée et lorsque les décisions ont un impact matériel sur le risque métier. Il en résulte moins de fatigue liée aux alertes, moins de faux positifs et plus de temps consacré à la chasse aux menaces, l’analyse des incidents et l’amélioration stratégique.

L’impact métier de ce changement se reflète dans les données du secteur. Selon le rapport Cost of a Data Breach 2025 d’IBM, les organisations qui utilisent largement l’IA et l’automatisation ont économisé en moyenne 1,9 million de dollars par violation et réduit le cycle de vie d’une violation de quatre-vingts jours. Avec un cycle de vie moyen mondial des violations de 241 jours en 2025, au plus bas depuis neuf ans, même des améliorations progressives de la vitesse se traduisent par une réduction significative des risques et des coûts.

Le constat est constant. Les équipes de sécurité cessent de réagir aux arriérés et commencent à opérer au rythme de la menace elle-même.

Pourquoi avancer lentement constitue le plus grand risque

La prudence vis-à-vis de l’IA en sécurité est compréhensible. Les systèmes de sécurité touchent des infrastructures critiques. Les erreurs sont très visibles, et les conséquences d’un échec sont réelles. Attendre des cas d’usage plus clairs, une gouvernance plus solide et des contrôles éprouvés peut sembler être le choix responsable.

Le défi, c’est que l’environnement de risque sous-jacent a changé. Les attaquants opèrent déjà à la vitesse de la machine, tandis que la plupart des programmes de sécurité répondent encore à la vitesse humaine. Chaque semaine passée à retarder une autonomie significative élargit cet écart. L’exposition s’accumule silencieusement, non pas parce que la détection échoue, mais parce que l’action ne parvient pas à suivre le rythme.

La plupart des organisations disposent déjà des signaux nécessaires. Les systèmes SIEM, EDR, de gestion des vulnérabilités et de gestion des correctifs génèrent une détection et un contexte de haute qualité. La contrainte, c’est l’exécution. Les alertes s’empilent. Les tickets attendent. Les décisions stagnent. L’IA agentique répond à cette contrainte en réduisant la distance entre détection et réponse. Plus cette distance demeure, plus la posture de sécurité s’éloigne de la réalité des menaces modernes.

En pratique, la résistance à la sécurité agentique est plus souvent organisationnelle que technique. La responsabilité des résultats pilotés par l’IA peut être floue. Les incitations peuvent récompenser le respect des processus plutôt que la réduction des risques. Les équipes peuvent percevoir l’automatisation comme une menace pour leur pertinence plutôt que comme une extension de leurs capacités.

Sur le plan opérationnel, c’est plutôt l’inverse qui tend à se vérifier. À mesure que l’autonomie augmente, le travail des analystes devient plus ciblé et plus précieux. La chasse aux menaces, l’analyse des incidents, la recherche sur les adversaires et les efforts d’amélioration architecturale se développent. Le triage manuel, la coordination des correctifs et les investigations répétitives reculent. L’expertise humaine est appliquée là où le jugement compte le plus.

Les organisations qui retardent l’adoption de la sécurité agentique ne restent pas immobiles. Elles choisissent d’opérer avec un modèle de réponse incapable de suivre le rythme des attaques modernes. Avec le temps, ce décalage devient la principale source de risque.

La transition est en cours

Les opérations de sécurité s’éloignent des modèles réactifs dans lesquels la détection crée des arriérés, les alertes génèrent du travail et les délais de réponse s’étendent sur plusieurs jours. Les programmes les plus avancés se réorganisent autour d’une exécution proactive, où les systèmes détectent les conditions, évaluent les risques et agissent en continu. Les agents autonomes absorbent le volume et la variabilité. Les équipes humaines se concentrent sur la stratégie, l’investigation et l’amélioration.

Cette évolution reflète un changement dans la manière dont la sécurité moderne doit fonctionner. Les adversaires automatisent déjà la reconnaissance, le développement d’exploits et les mouvements latéraux. Les attaques progressent sans attendre que les tickets soient triés ou que les approbations soient planifiées. Les programmes de sécurité qui restent liés à des workflows à vitesse humaine peinent à combler cet écart.

Ce qui distingue les organisations les plus efficaces, c’est leur capacité à fonctionner différemment. Elles conçoivent leurs dispositifs pour l’exécution autant que pour la détection. Elles encadrent l’autonomie de manière délibérée. Elles mesurent les résultats plutôt que l’activité. Au fil du temps, ce modèle opérationnel renforce son avantage, car la réponse s’améliore à mesure que les systèmes apprennent et que les équipes se recentrent.

La question qui se pose aux responsables de la sécurité n’est plus de savoir si l’autonomie a sa place dans les opérations de sécurité. Elle est de savoir si leur organisation est prête à exécuter la sécurité au rythme qu’exige désormais l’environnement.

Prêt à combler l’écart de vitesse en sécurité ?

Découvrez comment Ivanti Neurons for ITSM permet de mettre en place des workflows de sécurité autonomes, de la détection à la résolution, avec rapidité et contrôle.

Patch Tuesday de juin 2026

Tue, 09 Jun 2026 21:27:02 Z

Source : graphique généré à l’aide de Claude (Anthropic) le 9 juin 2026, sur la base d’invites conçues par l’auteur et d’un jeu de données de Chris Goettl.

Vous avez peut-être déjà vu ou entendu une référence à la Patch Apocalypse ; si ce n’est pas le cas, vous trouverez plus de détails ici. Le graphique ci-dessus présente un échantillon de plusieurs applications de grands fournisseurs présentes dans nos environnements. Vous pouvez y voir, sur les douze derniers mois glissants, le nombre de CVE corrigées chaque mois dans ces applications. Avant février 2026, ce qui préoccupait le plus chaque mois était les mises à jour des systèmes d’exploitation : Microsoft, Apple, Android, les différentes distributions Linux, etc. C’était le socle autour duquel les entreprises organisaient leur maintenance mensuelle, en considérant le Patch Tuesday comme le point de départ de cette maintenance.

En observant les trois lignes pointillées du graphique, on constate que février a été le premier mois où la ligne bleue, représentant le système d’exploitation Microsoft Windows, a commencé à être concurrencée. C’était la première attribution de CVE découvertes par des outils d’IA. En avril, la deuxième ligne pointillée, nous avons assisté à l’annonce de Project Glasswing et à une forte hausse du nombre de CVE découvertes.

Avançons jusqu’au Patch Tuesday de juin : une ligne verte imposante apparaît à côté d’une ligne bleue tout aussi importante. Il s’agit de Google Chrome et de Microsoft Edge (Chromium), qui ont déjà publié deux mises à jour en juin, corrigeant au total plus de 500 CVE, dont un exploit zero-day (CVE-2026-11645). Aujourd’hui, nous sommes dans la Patch Apocalypse. La Patch Apocalypse, c’est maintenant.

L’objectif n’est pas d’employer une tactique alarmiste. Il s’agit de décrire le défi que de nombreuses organisations anticipaient déjà, mais que la nouvelle génération de LLM a considérablement accéléré au premier semestre 2026.

Les fournisseurs vont corriger davantage de CVE, à un rythme plus rapide et plus continu que tout ce que nous avons connu jusqu’à présent. Malheureusement, cela inclura également plus d’exploits zero-day et n-day qu’auparavant. Le délai entre la publication par un fournisseur et l’exploitation s’était déjà réduit à 5 jours selon les données de veille sur les menaces de 2023.

De nombreux fournisseurs reconnaissent la nécessité d’utiliser des outils d’IA dans leurs recherches en sécurité afin d’identifier et de corriger les failles de sécurité de leurs produits. Oracle a récemment annoncé l’intégration de la CSPU, ou mise à jour de sécurité mensuelle, dont juin constituera la deuxième occurrence dans cette nouvelle cadence de publication. Google Chrome était déjà passé à une cadence hebdomadaire en 2023. Mozilla publie généralement une à deux versions de sécurité par mois et suit désormais, lui aussi, une cadence presque hebdomadaire.

Ivanti observe une augmentation de 30 à 40 % du nombre de correctifs publiés chaque mois chez les fournisseurs pris en charge dans notre Patch Catalog, et nous nous attendons à ce que cette tendance continue de s’accélérer pendant un certain temps, jusqu’à atteindre un nouveau seuil stable. Mais nous pensons qu’il ne s’agit pas d’un pic : c’est la nouvelle normalité.

Nous revenons donc au Patch Tuesday de juin 2026, comme prévu, pour une mise à jour à date. Microsoft a corrigé 198 CVE, Google Chrome en a corrigé 74, dont l’exploit zero-day (CVE-2026-11645), et Adobe a corrigé 123 CVE au travers de 11 mises à jour.

À ce stade, je me sens un peu désensibilisé, mais il faut le souligner : il s’agit du plus grand nombre de CVE corrigées par Microsoft lors d’un seul Patch Tuesday. Le précédent record datait d’octobre 2025, avec 175 CVE corrigées. Cela semble presque anecdotique en comparaison du nombre de CVE corrigées par Chrome et Edge, soit 429, dans la mise à jour du 3 juin 2026 publiée la semaine précédente.

En élargissant la discussion au défi des publications continues : d’après le Patch Catalog d’Ivanti, un rapide décompte des mises à jour liées à la sécurité entre les Patch Tuesday de mai et de juin fait état de 89 mises à jour corrigeant 513 CVE (Chrome et Edge sont dédupliqués dans ce calcul). Ces mises à jour doivent être incluses dans votre prochaine maintenance si vous ne disposez pas aujourd’hui d’une approche de mise à jour continue.

Ces publications comprennent plusieurs versions pour tous les principaux navigateurs (Chrome, Firefox, Edge, Opera, etc.), des éditeurs et lecteurs PDF (Foxit, Adobe, Nitro), des outils de développement (Node.js, VSCodium, Docker), des utilitaires et applications courants (Notepad++, PuTTY, PyCharm, Wireshark, Splunk UF), des applications de productivité et de télécommunications (Teams, Zoom), entre autres.

Vulnérabilités Microsoft divulguées publiquement

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans Windows BitLocker (CVE-2026-50507). La vulnérabilité est classée comme importante par Microsoft et affiche un score CVSS v3.1 de 6,8, mais elle a été divulguée publiquement. La CVE indique un niveau de maturité du code d’exploitation de type preuve de concept, ce qui augmente le risque d’exploitation. Un attaquant disposant d’un accès physique pourrait exploiter cette vulnérabilité pour contourner une fonctionnalité de sécurité et accéder à des données chiffrées.

Microsoft a corrigé une vulnérabilité de déni de service dans HTTP.sys (CVE-2026-49160). La vulnérabilité est classée comme importante par Microsoft et affiche un score CVSS v3.1 de 7,5, mais elle a été divulguée publiquement. La CVE indique un niveau de maturité du code d’exploitation non prouvé, ce qui signifie qu’aucun exemple de code n’a été divulgué au moment de sa publication. Un attaquant non autorisé pourrait tirer parti d’une consommation non contrôlée des ressources dans HTTP/2 pour provoquer un déni de service sur un réseau.

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Windows Collaborative Translation Framework (CVE-2026-45586). La vulnérabilité est classée comme importante par Microsoft et affiche un score CVSS v3.1 de 7,8, mais elle a été divulguée publiquement. La CVE indique un niveau de maturité du code d’exploitation non prouvé, ce qui signifie qu’aucun exemple de code n’a été divulgué au moment de sa publication. Un attaquant exploitant avec succès cette vulnérabilité pourrait obtenir des privilèges SYSTEM sur le système cible.

Avis de sécurité Ivanti

Ivanti a publié deux mises à jour de sécurité pour juin. Ces mises à jour concernent Ivanti Endpoint Manager Mobile et Ivanti Sentry, et corrigent au total quatre CVE. Des informations complémentaires et des détails sur les mesures d’atténuation sont disponibles dans l’avis de sécurité de juin.

Vulnérabilités tierces

Adobe a publié 11 mises à jour corrigeant 123 CVE. Adobe a classé la mise à jour ColdFusion comme la plus prioritaire.

Google Chrome a corrigé 74 CVE dans la dernière mise à jour de Chrome, dont un exploit zero-day (CVE-2026-11645). Cette mise à jour intervient dans le sillage de la plus importante version de Chrome, publiée le 3 juin, qui corrigeait 429 CVE. Microsoft Edge doit également être mis à jour pour corriger ces CVE.

Liste des actions à mener pour les mises à jour de juin

Google Chrome et Microsoft Edge sont les principales priorités ce mois-ci, afin de corriger plus de 500 CVE corrigées au cours de la semaine écoulée, ainsi qu’un exploit zero-day (CVE-2026-11645).
La mise à jour du système d’exploitation Windows constitue la priorité suivante, car elle corrige plus de 110 CVE, selon l’édition.

Patch Tuesday de mai 2026

Tue, 12 May 2026 21:52:21 Z

Dans la continuité de Patch Apocalypse, nous observons déjà ce mois-ci des évolutions plus marquées dans les mises à jour de nombreux éditeurs.

Oracle a annoncé une nouvelle cadence de publication à partir de mai 2026 afin de répondre à l’accélération de la détection des vulnérabilités introduite par Mythos et d’autres modèles de sécurité fondés sur l’IA. Les mises à jour mensuelles Critical Security Patch Update (CSPU) viendront combler l’intervalle de deux mois entre les mises à jour trimestrielles Critical Patch Update (CPU).

Mozilla travaillait déjà avec des modèles d’IA avant Mythos ce qui a conduit à la résolution de 22 bugs ayant un impact sur la sécurité dans Firefox 148. Mozilla a annoncé poursuivre sa collaboration avec Anthropic afin d’appliquer une version préliminaire de Mythos à Firefox, et a publié Firefox 150, qui corrige 271 vulnérabilités identifiées lors de l’évaluation. Depuis la publication de Firefox 150.0.0, Mozilla a adopté une cadence hebdomadaire plus soutenue pour les mises à jour de sécurité, avec notamment la publication de Firefox 150.0.3 lors du Patch Tuesday de mai, corrigeant entre trois et cinq CVE dans chaque version.

Apple est un autre participant précoce au Project Glasswing et a récemment observé une hausse du nombre d’expositions corrigées. L’entreprise corrige généralement environ 20 CVE par mise à jour de sécurité iOS. Pour sa dernière mise à jour du 11 mai, le volume dépasse 70 CVE corrigées sur l’ensemble des 11 mises à jour Apple. Même si aucune vulnérabilité n’est activement exploitée, le nombre de mises à jour à gérer est important.

Microsoft a corrigé 118 CVE dans la mise à jour du Patch Tuesday du 12 mai 2026. Aucune vulnérabilité exploitée ou divulguée publiquement n’est signalée ce mois-ci, mais les mises à jour corrigent 16 CVE critiques, 105 importantes, 5 modérées et 1 faible. Office représente probablement le risque le plus élevé ce mois-ci, avec quatre vulnérabilités RCE critiques corrigées dans cette mise à jour, mais le système d’exploitation, comme d’habitude, compte également de nombreuses CVE corrigées.

Vulnérabilités tierces (jusqu’au Patch Tuesday inclus)

Adobe a corrigé 52 CVE dans sa mise à jour du Patch Tuesday, qui comprenait 10 bulletins. Adobe Commerce est clairement la priorité : il s’agit de la seule mise à jour de priorité deux ce mois-ci, avec 10 CVE critiques, dont deux avec un score CVSS de 8,7, ainsi que plusieurs vulnérabilités DoS ne nécessitant aucun privilège d’administration pour être exploitées.

Apple a publié le 11 mai des mises à jour pour ses plateformes, corrigeant entre 25 et 52 CVE selon la plateforme. Cette publication ne comprenait aucune vulnérabilité exploitée ou divulguée publiquement, mais son volume est nettement supérieur à la moyenne.

Google a publié Chrome 148 le 5 mai, corrigeant 127 CVE, dont trois classées critiques. Google suit depuis quelque temps une cadence hebdomadaire pour les mises à jour de Chrome, mais la mise à jour du 5 mai est bien plus importante que la moyenne pour Chrome (il s’agit peut-être du plus grand nombre de CVE corrigées dans une seule mise à jour). Une autre version de Chrome est attendue au moment du Patch Tuesday ou peu après.

Depuis la publication de Firefox 150, Mozilla suit un calendrier hebdomadaire régulier de publication pour Firefox. Mozilla a fait parler de lui avec les 271 CVE corrigées dans Firefox 150.0.0 et corrige depuis en moyenne trois à cinq CVE chaque semaine. La publication de Firefox 150.0.3 lors du Patch Tuesday est la dernière version en date ; elle corrige cinq CVE, toutes classées élevées.

Avis de sécurité Ivanti

Ivanti a publié quatre mises à jour de sécurité pour le Patch Tuesday de mai. Ces mises à jour concernent Ivanti Secure Access Client, Ivanti Xtraction, Ivanti Virtual Traffic Manager et Ivanti Endpoint Manager, et corrigent sept CVE. Vous trouverez davantage de détails et d’informations sur les mesures d’atténuation dans l’Avis de sécurité de mai.

Par ailleurs, Ivanti a publié le 7 mai une mise à jour de sécurité pour Ivanti Endpoint Manager Mobile (EPMM), qui corrige cinq CVE, dont CVE-2025-6973. Au moment de la divulgation, Ivanti avait connaissance d’une exploitation très limitée de CVE-2026-6973, qui nécessite une authentification administrateur pour réussir. Vous trouverez davantage de détails et d’informations sur les mesures d’atténuation dans l’Avis de mise à jour de sécurité EPMM de mai 2026.

Actions à mener pour les mises à jour de mai

La cadence des mises à jour tierces s’accélère. Veillez à prioriser des calendriers de mise à jour plus fréquents pour les applications critiques, telles que les navigateurs, les applications de productivité et les applications de télécommunications.
Microsoft et Apple ont tous deux publié des mises à jour pour pratiquement toutes les plateformes. Aucun exploit n’est signalé, mais de nombreuses vulnérabilités doivent être corrigées.

Nous sommes entrés dans l’apocalypse des correctifs. Ces trois excuses IT ne tiennent plus.

Wed, 29 Apr 2026 14:00:07 Z

Le 7 avril, Anthropic a annoncé que son modèle Claude Mythos Preview avait identifié de manière autonome des milliers de vulnérabilités zero-day de gravité élevée et critique dans tous les principaux systèmes d’exploitation et navigateurs Web. Plus de 99 % d’entre elles n’étaient pas corrigées le jour de leur divulgation.

Deux semaines plus tard, le 21 avril, Mozilla a déclaré avoir utilisé le même modèle pour trouver et corriger 271 vulnérabilités dans la dernière version de Firefox. Selon la propre évaluation de Mozilla : « Jusqu’à présent, nous n’avons trouvé aucune catégorie ni complexité de vulnérabilité que des humains peuvent trouver et que ce modèle ne peut pas trouver. »

Ces 271 vulnérabilités ne sont qu’une première vague. Chrome, Edge, Windows, macOS, Linux, FreeBSD : la faille d’exécution de code à distance vieille de 17 ans dans FreeBSD, divulguée par la red team d’Anthropic (CVE-2026-4747), donne un premier aperçu de ce qui nous attend. Tous les éditeurs relevant du projet Glasswing d’Anthropic sont en mesure de publier des correctifs à un rythme encore jamais vu dans le secteur. Tous ces correctifs deviennent des CVE publiques avec des correctifs disponibles, et finissent tous au même endroit : votre environnement.

Le récit autour du confinement présente également une faille. Le 21 avril, Bloomberg a rapporté qu’un groupe lié à Discord avait obtenu un accès non autorisé à Mythos via l’environnement d’un fournisseur tiers. Anthropic affirme que l’activité n’a pas dépassé le périmètre de ce fournisseur. Que des capacités similaires soient déjà ou non entre les mains d’attaquants, le délai dont disposent les défenseurs est plus court que ne le laissait entendre l’annonce du 7 avril.

Mythos est arrivé dans un monde qui évoluait déjà dans cette direction. Le rapport Global Threat Report 2026 de CrowdStrike a documenté une hausse de 89 % sur un an des attaques assistées par l’IA en 2025. Cette tendance existait déjà avant Mythos.

Appelons cela une apocalypse des correctifs. Une apocalypse opérationnelle très concrète, où le volume et la cadence des CVE publiques assorties de correctifs disponibles sont sur le point de dépasser la façon dont travaillent aujourd’hui la plupart des équipes IT et sécurité.

Le NIST ressent déjà les effets de l’apocalypse des correctifs. En avril, l’agence a annoncé une évolution majeure des opérations de la National Vulnerability Database (NVD) en réponse à une augmentation de 263 % des soumissions. Le NIST ne fournira plus d’enrichissement détaillé pour toutes les vulnérabilités soumises et réservera désormais ce travail aux vulnérabilités répondant à des critères de risque élevé, comme celles figurant dans le catalogue Known Exploited Vulnerabilities de la CISA ou celles affectant des logiciels gouvernementaux critiques. Le NIST s’appuiera sur les CVE Numbering Authorities (CNA), comme Ivanti, plutôt que de réaliser sa propre évaluation indépendante.

Depuis l’annonce, j’entends trois variantes de la même réponse chez les clients et mes pairs. Toutes trois sont les déclinaisons d’un programme conçu pour un monde plus lent.

« Nous avons un scanner de vulnérabilités »

Qualys, Rapid7 et Tenable font très bien la découverte de vulnérabilités. Les scanners détectent, signalent, évaluent et listent. Le déploiement, la vérification, la gestion des redémarrages et le retour arrière ne relèvent pas de leur périmètre. Ce travail doit tout de même être réalisé quelque part. Dans la plupart des programmes, il se fait dans un outil distinct, avec une équipe distincte, selon une cadence distincte.

Alors que la fenêtre d’exploitation se compte désormais en heures et que la file d’attente Glasswing s’apprête à doubler le backlog, un scanner qui produit 587 vulnérabilités critiques et transmet la liste à une équipe humaine devient un facteur de risque. L’approche pragmatique consiste à connecter le scanner que vous possédez déjà à un moteur de remédiation capable d’agir automatiquement sur ses résultats. Une plateforme de gestion autonome des terminaux (AEM), avec déploiement par anneaux et retour arrière, ainsi qu’une veille sur les vulnérabilités pour fournir un contexte fondé sur le risque aux décisions de remédiation efficaces, afin que la liste se réduise sans qu’un humain ait à prendre chaque décision.

« Nous faisons passer les approbations par notre système de tickets »

Puisque nous parlons de décisions humaines… Les longs processus d’approbation linéaires vont fortement ralentir la remédiation. Quand avez-vous dû décider pour la dernière fois si vous alliez déployer la dernière mise à jour d’un système d’exploitation ou d’un navigateur ?

Les organisations savent déjà qu’elles vont déployer ces mises à jour. Le processus d’approbation est souvent dû à des politiques internes complexes et à un manque d’alignement sur les résultats attendus en matière de sécurité. Résultat ? Un processus très linéaire qui implique le scanner de vulnérabilités mentionné plus haut, un analyste qui approuve ce que vous savez déjà devoir faire, des tickets envoyés aux responsables métier pour approbation et qui restent dans les boîtes de réception en attendant une réponse, et au final un temps précieux perdu sur une décision qui était, en substance, déjà bien comprise et n’avait pas besoin d’être prise.

L’évolution du marché vers la gestion de l’exposition aborde ce processus de manière très différente, en se concentrant sur la définition de l’appétence au risque de l’organisation et sur la surveillance de sa posture de risque. La prochaine fois qu’une mise à jour de l’OS Windows sera publiée, vous saurez déjà que vous allez la déployer, selon quel calendrier, et avec quels SLA et indicateurs de conformité vous mesurerez la réussite. Ce que vous voulez vraiment savoir, c’est :

1. Dois-je aller plus vite parce que la mise à jour inclut des vulnérabilités connues exploitées ?

2. La mise à jour a-t-elle un impact sur les opérations, ce qui nous oblige à ralentir (heureusement, la plateforme de gestion autonome des terminaux inclut le déploiement par anneaux avec retour arrière) ?

« Nous avons Intune »

Microsoft Intune présente ici deux limites de périmètre importantes.

Premièrement, il ne gère que les appareils qui y sont inscrits. Les endpoints non inscrits et non gérés — serveurs, ordinateurs portables de prestataires, shadow IT, appareils en périphérie négligés — échappent totalement à sa visibilité. En période d’augmentation du volume de vulnérabilités, ces angles morts se multiplient plus vite que les équipes ne peuvent les traiter manuellement.

Deuxièmement, si Intune simplifie le déploiement et la mise à jour des applications, sa couverture des applications tierces et la profondeur de sa priorisation sont plus limitées que ne l’imaginent la plupart des administrateurs. Intune peut vous indiquer ce qui n’est plus à jour, mais pas ce qui augmente réellement votre exposition — ce qui oblige les équipes à tout corriger de manière réactive, ou à se fier à des suppositions lorsque le temps manque.

La plupart des environnements d’entreprise ne sont pas exclusivement Windows, entièrement inscrits, ni limités à une petite pile applicative homogène. Lorsque les divulgations de vulnérabilités explosent, le routage des correctifs laisse des failles et se transforme en risque systémique.

Conservez Intune. Associez-le à une couche de découverte et de remédiation qui trouve les actifs qu’Intune ne voit pas, priorise les vulnérabilités les plus importantes et applique les correctifs en toute confiance sur les applications qu’Intune ne couvre pas.

Que faire face à cette situation

L’automatisation est le modèle opérationnel. Elle doit être intégrée au workflow.

Les praticiens connaissent ce principe depuis quelque temps. Il se manifeste à trois niveaux :

Triage continu. Les vulnérabilités connues exploitées peuvent suivre un parcours de réponse zero-day, en particulier dans les parties moins sécurisées de l’organisation, comme les systèmes des utilisateurs finaux. Au-delà, définissez des applications spécifiques, comme les navigateurs et les applications de télécommunication, à mettre à jour selon un parcours prioritaire contrôlé chaque semaine, voire chaque jour. Tout le reste peut attendre la prochaine fenêtre de maintenance régulière.
Déploiement par anneaux avec retour arrière automatisé. Anneau de test, anneau d’adopteurs précoces, production étendue, environnements critiques. La séquence est classique, et elle fonctionne pour la plupart des opérations de maintenance. Ce qui a changé, c’est que certaines mises à jour devront être accélérées pour s’inscrire dans la fenêtre d’exploitation, au lieu d’attendre votre maintenance mensuelle. L’anneau de test doit être automatisé et instrumenté : une checklist humaine ne peut pas aller aussi vite.
Vérification en boucle fermée. Le correctif n’est pas considéré comme déployé tant que son installation sur l’endpoint n’a pas été vérifiée, et la CVE n’est pas clôturée tant qu’une nouvelle analyse ne l’a pas confirmé. La plupart des équipes sautent cette étape, ce qui explique pourquoi les preuves de conformité deviennent une urgence la semaine précédant l’audit. C’est pourquoi nous avons lancé cette semaine la conformité continue dans notre plateforme : afin que les preuves de conformité soient produites en continu et automatiquement au fur et à mesure du déploiement des correctifs, l’automatisation prenant en charge les décisions de priorisation pour lesquelles la plupart des équipes n’ont pas de capacité disponible.

Les 271 vulnérabilités Firefox de Mozilla ne sont qu’un aperçu. Tous les grands éditeurs logiciels relevant de Glasswing sont sur le point de commencer à corriger davantage de vulnérabilités, à un rythme accéléré, tandis que les attaquants disposant de capacités du même ordre chercheront précisément ces ouvertures dès qu’ils auront accès à un modèle similaire. La course à l’armement qui en résultera autour de l’IA aura un effet direct sur le nombre et la fréquence des mises à jour que les organisations devront remédier, là encore à un rythme accéléré. C’est l’automatisation qui permet à un programme de tenir dans la durée. Les équipes qui s’en tiennent encore à une gestion des correctifs uniquement mensuelle s’exposent à une période difficile.

Si vous pilotez un programme IT ou sécurité, l’auto-évaluation mérite d’être faite dès maintenant. Prenez le dernier correctif critique que vous avez déployé. Mieux encore : si une zero-day était publiée un vendredi, seriez-vous capable d’y remédier avant lundi ? Mesurez le délai entre la publication de la CVE et l’installation vérifiée sur le dernier endpoint. Si ce délai se compte en semaines, l’apocalypse des correctifs vous rattrapera.

Souveraineté numérique et cloud souverain : protéger les données cloud de l’UE pour renforcer la résilience opérationnelle

Fri, 17 Apr 2026 12:30:01 Z

La protection traditionnelle des données reposait sur un principe simple : les données stockées dans le pays A sont protégées par les lois du pays A ; les données stockées dans le pays B sont protégées par les lois du pays B. Mais dans l’économie mondiale actuelle, l’endroit où vos données se trouvent physiquement ne détermine plus quels gouvernements peuvent exiger d’y accéder.

L’infrastructure cloud a introduit une nouvelle complexité juridictionnelle. L’emplacement physique des centres de données, la nationalité du siège social du fournisseur cloud et l’entité qui contrôle les opérations peuvent chacun donner lieu à des revendications juridictionnelles concurrentes, permettant potentiellement à plusieurs gouvernements d’exiger l’accès aux mêmes données.

Qu’est-ce que la souveraineté numérique ?

Ce défi porte un nom : la souveraineté numérique. La souveraineté numérique est le principe selon lequel les organisations conservent un contrôle complet sur leurs données dans le cadre juridique de leur juridiction d’origine. Cette idée est devenue une nécessité pour la résilience organisationnelle, alors que les entreprises évoluent dans un monde géopolitique plus fragmenté et où la confiance s’érode. Les organisations privées et publiques ont besoin d’un accès sécurisé à des plateformes basées dans le cloud, conformes aux exigences réglementaires locales et protégées contre les risques géopolitiques, connus ou inconnus, auxquels leur région est exposée.

Impact du CLOUD Act américain sur la résidence des données dans l’UE

Le CLOUD Act américain de 2018 (Clarifying Lawful Overseas Use of Data) a encore renforcé ces préoccupations pour les organisations de l’UE. Cette loi habilite les forces de l’ordre américaines à contraindre tout fournisseur cloud basé aux États-Unis à produire des données stockées n’importe où dans le monde, indépendamment de l’emplacement physique des données ou de la nationalité du client.

Le CLOUD Act américain et le Foreign Intelligence Surveillance Act (FISA) ont tous deux suscité des inquiétudes chez les entreprises de l’Union européenne. Avec ces deux politiques, les autorités américaines pourraient accéder aux données contenues dans les plateformes cloud de toute organisation dont le siège est situé aux États-Unis, même lorsque le centre de données cloud est situé dans un autre pays.

Pour les entreprises basées dans l’UE, l’utilisation d’outils basés aux États-Unis entraîne des obligations spécifiques au titre du RGPD car les données personnelles quittent l’UE. Et depuis l’invalidation du bouclier de protection des données UE–États-Unis (connue sous le nom de « Schrems II »), les entreprises de l’UE ont besoin d’autres protections. Les clauses contractuelles types (CCT) restent valides, mais elles sont conditionnelles et complexes, car elles nécessitent une évaluation au cas par cas.

Un cadre ultérieur de protection des données a depuis été introduit, mais la confiance sous-jacente entre les nations concernées reste limitée. Ces dynamiques ont accru la pression pour garantir la protection des données, d’où la nécessité de solutions de cloud souverain pour assurer la résilience opérationnelle.

Ivanti Neurons for MDM – Sovereign Edition : conçu pour la souveraineté cloud de l’UE

Pour nos partenaires et clients dans l’UE, Ivanti Neurons for MDM Sovereign Edition répond à ces exigences grâce à une architecture et à des opérations fondamentalement différentes. Située en Allemagne et exploitée de manière indépendante, cette solution a été conçue pour s’aligner sur le cadre de souveraineté cloud de la Commission européenne et a été évaluée par le très réputé cyberintelligence.institute, dont l’évaluation experte indique :

« L’Ivanti Sovereign Cloud démontre un haut niveau de contrôle européen dans les domaines du traitement des données, de la sécurité et de la gouvernance de la conformité. Dans sa configuration actuelle, l’Ivanti Sovereign Cloud atteint au minimum la certification SEAL 2, ce qui signifie que la souveraineté des données est garantie dans tous les domaines. En outre, l’Ivanti Sovereign Cloud satisfait aux exigences de la certification SEAL 3 dans de nombreux domaines pertinents, et atteint ainsi la résilience numérique. »

Vous pouvez consulter l’évaluation technique complète pour en savoir plus.

Atteindre la conformité en matière de souveraineté des données en toute confiance

Neurons for MDM – Sovereign Edition – EU offre aux entreprises européennes une base stratégique pour leur plateforme IT et de sécurité, fournie par un leader de confiance, tout en préservant les protections juridictionnelles locales nécessaires à la gestion des risques. Cela signifie que les entités publiques et privées peuvent poursuivre leur transformation numérique avec la certitude que leurs données cloud resteront sécurisées tandis que leurs opérations gagnent en résilience.

Prochaines étapes ? Lisez notre livre blanc, Le cloud souverain, une nécessité stratégique pour les organisations européennes, pour découvrir comment Ivanti Neurons for MDM Sovereign Edition obtient la certification SEAL 2 et va au-delà, tout en fournissant l’architecture de cloud souverain dont les organisations européennes ont besoin pour maintenir la souveraineté des données et permettre une transformation numérique sécurisée.

Patch Tuesday d’avril 2026

Tue, 14 Apr 2026 22:51:36 Z

La période précédant le Patch Tuesday a été riche en événements. Une vulnérabilité zero-day dans Google Chrome (CVE-2026-5281) a été corrigée le 1er avril, une vulnérabilité zero-day dans Adobe Acrobat Reader (CVE-2026-34621) en fin de journée le vendredi 10 avril, et plusieurs CVE plus anciennes ont été ajoutées hier à la liste KEV de la CISA (13 avril). Le tout dans un contexte où le secteur parle beaucoup d’Anthropic Mythos et du Project Glasswing.

Quel est le lien entre ces événements et Project Glasswing ? La plupart des discussions autour de Mythos se sont concentrées sur ses cas d’utilisation et leurs répercussions.

La détection de failles exploitables dans le code peut être un outil très utile lorsqu’elle est effectuée par l’éditeur qui écrit ce code avant sa publication. Toutefois, elle sera également utilisée par des chercheurs et des acteurs malveillants pour trouver des failles dans du code déjà publié, et c’est sur ce point que porte ma réflexion.

Considérez les effets en cascade d’un modèle de grande envergure comme Mythos et ce qu’il impliquera à court et à plus long terme pour les logiciels utilisés par les entreprises. À court terme, les grands acteurs utiliseront ce type de solution pour publier du code plus sécurisé. À mesure que les chercheurs et les acteurs malveillants adopteront des modèles d’IA plus robustes pour identifier des failles exploitables, cela se traduira par davantage de divulgations coordonnées (positif), d’exploits zero-day (négatif) et d’exploits n-day (négatif). Tout cela entraînera des mises à jour logicielles plus fréquentes et, surtout, plus urgentes.

De nombreuses organisations peinent actuellement à suivre le rythme des mises à jour prioritaires qui corrigent des vulnérabilités exploitées lorsqu’elles surviennent en dehors de leur maintenance mensuelle habituelle. Je pense que la plupart des organisations n’ont pas eu connaissance de l’exploit zero-day d’Adobe Acrobat avant la mise à jour KEV de la CISA hier. Cela signifie que les acteurs malveillants ont bénéficié de 2 à 3 jours supplémentaires pour exploiter CVE-2026-34621 avant que la plupart des organisations n’en soient informées, et beaucoup d’entre elles traiteront probablement cette mise à jour dans le cadre de leur maintenance régulière, qui commence aujourd’hui avec le Patch Tuesday.

Les mises à jour de sécurité des navigateurs sont hebdomadaires. De nombreuses autres applications que les utilisateurs emploient régulièrement publient des mises à jour selon un calendrier continu, et non à une date mensuelle fixe. Cela signifie que nombre des exploits ciblant les utilisateurs se produiront dans des logiciels publiés en dehors des calendriers de maintenance de la plupart des organisations, et cette fréquence est sur le point d’augmenter. Il est difficile de dire si cette hausse sera de 1,5 fois ou de 5 fois, mais soyez assurés qu’elle sera perceptible et aggravera un défi auquel la plupart des organisations sont déjà confrontées : la gestion rapide des correctifs.

C’est là qu’intervient la gestion de l’exposition. Il s’agit autant d’un changement d’état d’esprit et de maturité que d’une évolution technologique. Ce changement d’état d’esprit nous oblige à envisager un monde dans lequel nous devons prendre les décisions en amont et les surveiller. C’est ce que l’on appelle définir son appétence au risque et surveiller sa posture de risque. Effectuée efficacement, cette démarche fait gagner en maturité la réponse des organisations face aux risques et rend les activités de remédiation beaucoup plus claires.

L’évolution technologique exige que les technologies traditionnelles d’évaluation des vulnérabilités s’intègrent dans un écosystème plus large, où la visibilité des actifs ou le système de référence se combine avec des solutions d’évaluation des vulnérabilités et de renseignement sur les vulnérabilités afin d’affiner les décisions : agir plus immédiatement face à certains risques ou attendre les opérations de maintenance régulières. Le plus important est que cette pile technologique soit intégrée à votre plateforme AEM (Autonomous Endpoint Management), car c’est là que la remédiation s’effectue principalement et automatiquement.

Revenons maintenant à notre point Patch Tuesday habituel. Microsoft a corrigé 169 CVE ce mois-ci, ce qui constitue un ensemble de correctifs très important pour un Patch Tuesday. Le Patch Tuesday d’avril est le deuxième plus important jamais enregistré, derrière celui d’octobre 2025, qui avait corrigé 175 CVE. Il comprend un exploit zero-day (CVE-2026-3220) et une divulgation publique (CVE-2026-33825), répartis entre 8 vulnérabilités critiques, 156 importantes, 3 modérées et 1 faible.

La CVE zero-day se trouve dans Microsoft SharePoint et la divulgation publique concerne Microsoft Defender, ce qui fait de ces deux mises à jour les plus urgentes du mois, en plus des mises à jour Adobe Acrobat et Google Chrome publiées avant le Patch Tuesday.

Vulnérabilités Microsoft exploitées connues

Microsoft a corrigé une vulnérabilité d’usurpation de serveur dans Microsoft SharePoint (CVE-2026-32201). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 6,5, mais son exploitation active a été confirmée. Un attaquant qui parvient à exploiter cette vulnérabilité peut consulter des informations sensibles et modifier les informations divulguées. La vulnérabilité affecte SharePoint Server Subscription Edition, SharePoint Server 2019 et SharePoint Server 2016. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Vulnérabilités Microsoft divulguées publiquement

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Microsoft Defender (CVE-2026-33825). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 7,8, mais elle a été divulguée publiquement. La CVE indique que la maturité du code d’exploitation est de type preuve de concept, ce qui accroît son risque d’exploitation. Un attaquant pourrait utiliser cette vulnérabilité pour permettre à un attaquant autorisé d’élever ses privilèges au niveau SYSTEM sur la machine locale.

Avis de sécurité Ivanti

Ivanti a publié une mise à jour de sécurité pour avril. Cette mise à jour concerne Ivanti Neurons for ITSM et corrige deux CVE. Vous trouverez plus de détails et d’informations sur les mesures d’atténuation dans l’avis de sécurité d’avril.

Vulnérabilités tierces

Adobe a publié douze mises à jour ce mois-ci, dont onze lors du Patch Tuesday, ainsi que la mise à jour zero-day pour Acrobat publiée le vendredi 10 avril. 54 CVE ont été corrigées, réparties entre 39 critiques, 13 importantes et 2 modérées. APSB26-43 a corrigé l’exploit zero-day (CVE-2026-34621).

Liste des tâches pour les mises à jour d’avril

Adobe Acrobat (CVE-2026-34621) et Google Chrome (CVE-2026-5281) ont tous deux fait l’objet d’exploits zero-day avant le Patch Tuesday. Veillez à prioriser la remédiation de ces deux produits vers leur dernière version.
Microsoft SharePoint comprend un exploit zero-day (CVE-2026-32201) et doit être examiné en priorité, en particulier si vous rencontrez des difficultés connues de mise à jour dans vos environnements SharePoint.
La mise à jour du système d’exploitation Microsoft Windows de ce mois-ci corrige 133 CVE (selon l’édition) et inclut 4 CVE critiques. Cette mise à jour corrigera un nombre important de constats dans votre environnement.

Patch Tuesday de mars 2026

Tue, 10 Mar 2026 21:01:35 Z

Le Patch Tuesday de mars corrige 79 CVE, dont trois critiques et 76 importantes. Deux CVE ont été divulguées publiquement ce mois-ci, mais aucune n’est exploitée. Microsoft a également publié une mise à jour d’Edge corrigeant neuf CVE de Chrome. Les divulgations publiques comprennent une vulnérabilité de déni de service dans .NET et une vulnérabilité d’élévation de privilèges dans SQL Server. Dans les deux cas, la maturité du code d’exploitation est indiquée comme non prouvée, ce qui signifie que les divulgations ne comprenaient aucun exemple de code.

Adobe et Mozilla ont publié des mises à jour dans le cadre du Patch Tuesday de mars, notamment huit mises à jour d’Adobe corrigeant au total 80 CVE, dont 21 sont classées critiques. Mozilla Firefox 148.0.2 a été publié afin de corriger trois CVE de gravité élevée.

Vulnérabilité Microsoft divulguée publiquement

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans SQL Server (CVE-2026-21262). Cette vulnérabilité est classée importante par Microsoft et présente un score CVSS v3.1 de 8,8, mais elle a été divulguée publiquement. Un attaquant exploitant avec succès cette vulnérabilité pourrait obtenir des privilèges d’administrateur système SAL. La vulnérabilité affecte SQL Server 2016 et les éditions ultérieures.

Microsoft a corrigé une vulnérabilité de déni de service dans .NET (CVE-2026-26127). Cette vulnérabilité est classée importante par Microsoft et présente un score CVSS v3.1 de 7,5, mais elle a été divulguée publiquement. Un attaquant pourrait provoquer une lecture hors limites dans .NET, permettant à un attaquant non autorisé de provoquer un déni de service via un réseau. La vulnérabilité affecte .NET 9 et 10 sur Windows, Mac OS et Linux, ainsi que les packages NuGet 9 et 10.

Vulnérabilités de tiers

Adobe a publié huit mises à jour ce mois-ci, corrigeant au total 80 CVE, dont 21 sont classées critiques. Adobe Commerce est la priorité la plus élevée ce mois-ci, avec une note de priorité 2. Les autres produits affectés incluent Adobe Illustrator, Substance 3D Painter, Acrobat et Acrobat Reader, Premier Pro, Experience Manager, Substance 3D Stager et DNG SDK.

Mozilla a publié une mise à jour pour Firefox 148.0.2 corrigeant trois vulnérabilités de gravité élevée.

Liste des actions à effectuer pour les mises à jour de mars

Les mises à jour de l’OS Microsoft et d’Office permettront de corriger la majorité des CVE traitées ce mois-ci en seulement deux mises à jour.

Mozilla Firefox, Microsoft Edge et Google Chrome publient tous fréquemment des versions. Priorisez les mises à jour des navigateurs chaque semaine, voire chaque jour, afin de réduire les risques en continu avec un impact minimal.

Trusted Ownership : comment Ivanti Application Control va au-delà des listes d’autorisation

Wed, 25 Feb 2026 14:25:15 Z

Le contrôle des applications fait partie de ces sujets de sécurité sur lesquels de nombreuses personnes conservent d’anciennes idées reçues. Les listes d’autorisation traditionnelles semblent rassurantes, mais deviennent rapidement difficiles à maintenir. Les listes de blocage paraissent réactives et incomplètes. Et si des outils comme Microsoft AppLocker ont conduit beaucoup d’organisations à penser que les listes d’autorisation strictes étaient la référence, les attaques modernes ont démontré le contraire. Les attaquants s’appuient de plus en plus sur des outils légitimes et signés — utilisés dans le mauvais contexte — pour contourner entièrement les contrôles fondés sur des listes.

Ainsi, lorsque les organisations évaluent Ivanti Application Control ou Ivanti Neurons for App Control et découvrent Trusted Ownership, celui-ci peut d’abord ressembler à une liste de blocage, car des blocages explicites sont possibles. En réalité, Trusted Ownership est un modèle d’application des règles beaucoup plus large et bien plus léger sur le plan opérationnel, qui contrôle l’exécution selon l’origine, et pas seulement selon l’identité.

Au lieu de gérer des listes toujours plus nombreuses, il applique la sécurité en fonction de la personne ou du processus qui a placé le logiciel sur le système, en cohérence avec les pratiques modernes de distribution logicielle et les principes du zero trust. Il faut le comprendre non comme un autre mécanisme de liste, mais comme un modèle d’application des règles inspiré de la provenance, qui contrôle l’exécution selon l’origine, et pas seulement selon l’identité.

Ce changement de perspective conduit à une meilleure question pour le contrôle moderne des applications : non seulement ce qu’un fichier est, mais comment il est arrivé là.

Au-delà des listes : pourquoi le contrôle de provenance compte désormais

La question de savoir comment un fichier est arrivé sur le système est au cœur du contrôle de provenance. Au lieu de faire confiance aux fichiers uniquement sur la base de l’éditeur, du chemin ou du hachage, le contrôle de provenance évalue l’origine et le processus qui les ont introduits. Qui a écrit le fichier sur le disque ? Par quel mécanisme ? L’installation a-t-elle suivi un workflow IT contrôlé ? Cette évaluation fait passer le contrôle des applications d’une confiance accordée aux objets à une confiance accordée aux processus, créant ainsi une frontière de sécurité bien plus solide.

Dans Ivanti Application Control, le contrôle de provenance est mis en œuvre sous la forme de Trusted Ownership. Tout fichier placé par un propriétaire de confiance est autorisé ; tout élément introduit par un utilisateur est refusé par défaut. Cela s’applique de manière cohérente aux exécutables, DLL, programmes d’installation et scripts. Comme des identités telles que SYSTEM, TrustedInstaller et Administrators sont approuvées par défaut, les logiciels livrés via des canaux de déploiement standard comme MS Intune, MECM, Ivanti Endpoint Manager (EPM) ou d’autres outils d’entreprise s’exécutent immédiatement, sans maintenance des règles ni exceptions.

Cela marque une rupture fondamentale avec les listes d’autorisation classiques. Les règles AppLocker dépendent de définitions exactes d’éditeur, de chemin ou de hachage. AppLocker n’évalue pas l’origine de l’installation et ne fait pas automatiquement confiance à vos mécanismes de déploiement. Les logiciels livrés par Intune nécessitent toujours une règle d’autorisation préexistante, souvent fondée sur des paramètres par défaut larges qui autorisent les répertoires Program Files ou Windows.

Cette distinction est importante, car les attaques modernes détournent de plus en plus des outils légitimes dans des contextes inappropriés. Le contrôle de provenance neutralise une grande partie de ce risque en appliquant la confiance à la manière dont le logiciel arrive, et pas seulement à comment le logiciel arrive, et pas seulement à ce qu’il est. Il s’aligne sur les principes du zero trust, réduit l’exposition de la chaîne d’approvisionnement et limite fortement, par défaut, les possibilités d’abus de type Living off the Land (LotL).

Une fois l’importance de l’origine comprise, la question suivante devient : comment l’appliquer à grande échelle ?

La réponse : appliquer la provenance de manière cohérente à toutes les façons dont les logiciels s’exécutent et à toutes les façons dont ils sont livrés.

Au-delà des listes de blocage : une couverture étendue conçue pour le déploiement logiciel moderne

Le contrôle de provenance fait évoluer la sécurité des applications : il ne s’agit plus de gérer des listes interminables, mais de valider le processus par lequel le logiciel arrive sur le système. Une fois cette perspective adoptée, il devient clair que Trusted Ownership n’est pas une approche de type liste de blocage. C’est une frontière de confiance fondée sur l’origine, dont le fonctionnement diffère nettement des listes d’autorisation traditionnelles.

Une idée reçue courante consiste à penser que Trusted Ownership ressemble à une liste de blocage parce que les administrateurs ajoutent parfois des règles de refus ciblées pour des outils Windows bien connus. En pratique, ces règles de refus sont des mesures de renforcement défensif contre les techniques Living off the Land. Toute méthode sérieuse de contrôle des applications utilise ce type de restrictions ciblées. Le cœur de Trusted Ownership est l’inverse d’une liste de blocage. Les logiciels livrés via un processus contrôlé et approuvé sont autorisés par défaut, tandis que le contenu introduit par l’utilisateur est refusé par défaut.

Un facteur de différenciation plus important encore est la couverture. De nombreuses organisations qui s’appuient sur des listes d’autorisation classiques finissent par se concentrer presque exclusivement sur les fichiers exécutables. Elles évitent souvent d’appliquer le même niveau de contrôle aux DLL, scripts et packages MSI, car ces types de fichiers rendent la maintenance des règles beaucoup plus complexe. Cela crée des failles que les attaquants modernes exploitent fréquemment.

Trusted Ownership évite ces failles en appliquant le même contrôle fondé sur l’origine à l’ensemble de la chaîne d’exécution. Les exécutables, DLL, scripts, programmes d’installation MSI et composants associés sont évalués selon le même modèle de confiance. Comme la confiance est déterminée par l’entité qui a introduit le fichier, vous n’avez pas besoin de politiques distinctes pour chaque type de fichier. Un script dans le dossier Téléchargements, une DLL créée dans un répertoire de build temporaire ou un EXE exécuté depuis un profil utilisateur reçoivent tous le même traitement de refus par défaut lorsqu’ils proviennent d’un processus d’installation non contrôlé.

Ce modèle de confiance s’aligne également naturellement sur la façon dont les plateformes modernes de gestion des terminaux livrent les logiciels. Des solutions telles qu’Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager et des systèmes similaires installent généralement les applications en utilisant l’identité SYSTEM ou un autre compte de service approuvé.

Comme ces identités sont déjà des propriétaires de confiance, les logiciels déployés via ces canaux s’exécutent immédiatement, sans créer de règles d’autorisation, maintenir des chemins de fichiers ni mettre à jour des politiques. Ce n’est que lorsque vous utilisez volontairement d’autres comptes d’installation, comme des agents DevOps personnalisés ou des installations scriptées en contexte utilisateur, que vous devez identifier cette identité comme propriétaire de confiance.

Le résultat est un modèle offrant une couverture étendue et cohérente sur tous les types de fichiers pertinents. Il fonctionne de manière fluide avec les distributions logicielles modernes et évite la charge opérationnelle associée aux listes d’autorisation classiques, qui se concentrent principalement sur les fichiers exécutables.

Trusted Ownership place la confiance non pas dans des objets individuels, mais dans les processus contrôlés par lesquels les logiciels sont livrés, créant ainsi une approche plus évolutive et plus sûre du contrôle des applications.

Quelle place pour WDAC (App Control for Business) ?

Microsoft maintient deux technologies de contrôle des applications : AppLocker et App Control for Business (anciennement WDAC). Bien que les deux existent encore, Microsoft est clair quant à leurs rôles. AppLocker aide à empêcher les utilisateurs d’exécuter des applications non approuvées, mais ne répond pas aux critères de maintenance des fonctionnalités de sécurité modernes et est donc catégorisé comme un mécanisme de défense en profondeur plutôt que comme un contrôle de sécurité stratégique.

La trajectoire recommandée par Microsoft pour le contrôle des applications est App Control for Business, et l’éditeur indique explicitement qu’AppLocker est complet sur le plan fonctionnel et ne fait plus l’objet d’un développement actif, en dehors des mises à jour de sécurité essentielles. Cela signifie que toutes les nouvelles capacités sont livrées uniquement dans WDAC, et non dans AppLocker.

App Control for Business introduit le concept de Managed Installer. Celui-ci permet à Windows de faire automatiquement confiance aux applications installées via des plateformes de déploiement désignées, telles qu’Intune ou MECM. La confiance provient du canal de distribution plutôt que des fichiers individuels, ce qui réduit considérablement la maintenance des règles.

Cela s’aligne étroitement sur le modèle Trusted Ownership d’Ivanti Application Control. Les deux approches font confiance au logiciel en fonction du processus contrôlé qui l’a installé, plutôt que d’attributs de fichiers distincts. Toutefois, Trusted Ownership applique ce concept de manière plus simple et plus accessible sur le plan opérationnel. Ivanti fait confiance à des identités telles que SYSTEM et à des comptes de service désignés, sans exiger de couches de politiques complexes, de définitions XML ni d’expertise approfondie de WDAC.

Ivanti entend de nombreuses organisations expliquer qu’elles peinent à rendre WDAC opérationnel. Les politiques WDAC exigent une conception rigoureuse, de longs tests en mode audit, la gestion des exceptions de pilotes et de noyau, ainsi qu’une maintenance continue de plusieurs ensembles de politiques. Cela conduit souvent les organisations à associer WDAC à AppLocker pour couvrir à la fois l’application de règles de bas niveau et le contrôle quotidien de l’espace utilisateur, avec à la clé une charge administrative supplémentaire.

Ivanti Application Control offre une alternative unifiée. Grâce à Trusted Ownership, Trusted Vendors et à la validation des signatures numériques, il fournit un modèle de refus par défaut fondé sur la provenance, avec une couverture cohérente des exécutables, DLL, scripts et packages MSI.

Au lieu de maintenir deux plans de contrôle Microsoft aux périmètres différents, les organisations gèrent une politique unique et rationalisée qui applique la confiance en fonction de la manière dont le logiciel est introduit dans le système. Cela répond à de nombreux objectifs pratiques que les clients cherchent à atteindre avec un déploiement combinant WDAC et AppLocker, mais avec une complexité opérationnelle moindre et un modèle de confiance cohérent.

LOLBins et contrôle au niveau des arguments

Une fois cette large couverture établie, la question devient alors de savoir comment gérer les outils légitimes déjà présents sur chaque machine, que les attaquants aiment détourner.

Les attaquants modernes évitent souvent d’utiliser des malwares traditionnels et s’appuient plutôt sur les outils déjà présents sur chaque appareil Windows. Ces outils Living off the Land (LOLBins) sont légitimes et nécessaires aux opérations courantes, ce qui les rend difficiles à bloquer sans nuire à la productivité. Les listes d’autorisation traditionnelles atteignent ici leurs limites : un blocage trop large perturbe les workflows, tandis qu’une autorisation trop large laisse des failles dangereuses.

Un modèle fondé sur la provenance, tel que Trusted Ownership, change cette dynamique. Même si un attaquant tente d’utiliser un outil intégré, le contenu qu’il essaie d’exécuter ne provient généralement pas d’un processus d’installation approuvé. Comme Ivanti évalue l’origine de ce contenu, la plupart des tentatives d’utilisation abusive échouent automatiquement. L’outil peut être légitime, mais le contenu qu’on lui demande d’exécuter ne l’est pas, et Trusted Ownership l’arrête avant son exécution.

Il est également important de comprendre non seulement quels outils s’exécutent, mais aussi ce qu’on leur demande de faire. De nombreux interpréteurs et environnements d’exécution, tels que PowerShell, Python ou Java, peuvent être parfaitement sûrs dans un contexte et risqués dans un autre. Une application métier peut s’appuyer sur Java pour lancer un processus spécifique et approuvé, tandis qu’un fichier JAR téléchargé par un utilisateur correspond à un scénario entièrement différent.

Ivanti gère cela au moyen d’une approche en couches. Un fichier JAR est d’abord évalué à l’aide de Trusted Ownership, qui le bloque immédiatement s’il a été introduit par un utilisateur plutôt que par un processus de déploiement contrôlé. Au-delà de cela, les administrateurs peuvent créer des règles d’autorisation simples qui précisent exactement quelles commandes Java sont permises, afin que seules les applications légitimes fondées sur Java s’exécutent, tandis que les tentatives de lancement de fichiers JAR non approuvés sont refusées discrètement.

Le même principe s’applique également à d’autres outils. Les politiques peuvent approuver le comportement exact dont votre organisation a besoin, tout en bloquant les activités qui sortent de ces limites. Cela évite les règles larges et fragiles, tout en maintenant la fluidité du travail quotidien.

Le résultat est une approche moderne et équilibrée. Trusted Ownership bloque par défaut le contenu non approuvé. Un renforcement ciblé s’aligne sur les bonnes pratiques gouvernementales et communautaires visant à réduire les abus de type Living off the Land, tandis que les contrôles tenant compte de l’intention garantissent que les processus légitimes continuent de fonctionner sans ouvrir de portes aux attaquants.

Cette approche s’aligne étroitement sur les recommandations actuelles des communautés et des organismes publics concernant l’atténuation des techniques Living off the Land. Des agences telles que la CISA, la NSA, le FBI et l’Australian Cyber Security Centre soulignent l’importance de réduire les possibilités offertes aux attaquants d’utiliser des outils intégrés, en contrôlant leur utilisation et en limitant le contenu non approuvé sur lequel ils agissent. Leurs recommandations conjointes mettent en évidence que les attaques LOTL reposent sur le détournement d’outils natifs et insistent sur la nécessité de contrôles qui limitent ces abus sans bloquer les processus système légitimes.

Le modèle d’Ivanti reflète ces recommandations. Trusted Ownership bloque automatiquement le contenu non approuvé sur lequel les attaquants s’appuient, tandis qu’un petit nombre de restrictions ciblées couvre le petit ensemble d’outils nécessitant une attention supplémentaire.

Trusted Ownership en action : scénarios concrets

Voici quelques exemples opérationnels illustrant le fonctionnement d’Ivanti Application Control et de Trusted Ownership en pratique.

Une application portable est copiée dans le profil utilisateur. Ivanti la bloque parce qu’elle appartient à l’utilisateur. AppLocker ne bloque que si des règles correspondantes existent. Sans les bonnes règles de chemin ou d’éditeur, le comportement peut varier.
Une pièce jointe à un e-mail lance un script PowerShell depuis le dossier Téléchargements. Ivanti le refuse en raison de la propriété utilisateur. AppLocker dépend des règles de script et, lors des événements de blocage, force PowerShell à passer en mode Constrained Language Mode, ce qui exécutera tout de même le script.
Détournement d’outils du système d’exploitation tels que rundll32 ou mshta. Les deux modèles nécessitent un renforcement ciblé par règles de refus. Ivanti l’associe au contrôle de provenance, ce qui réduit généralement le nombre d’exceptions nécessaires. AppLocker s’appuie sur des ensembles de refus organisés et nécessite des ajustements périodiques.
Une mise à jour fournisseur livre de nouveaux fichiers signés. Ivanti autorise la mise à jour lorsqu’elle arrive via le canal de déploiement approuvé, grâce à Trusted Ownership. AppLocker peut prendre cela en charge avec des règles d’éditeur, mais la réutilisation de signatures sur plusieurs produits ou des chemins d’installation inhabituels entraînent souvent une maintenance supplémentaire et une confiance plus large que prévu.
Un utilisateur télécharge un fichier JAR et essaie de l’exécuter avec Java. Ivanti bloque la tentative parce que le JAR a été introduit par l’utilisateur et échoue au contrôle Trusted Ownership. Si nécessaire, les administrateurs peuvent autoriser uniquement l’invocation approuvée exacte en faisant correspondre la ligne de commande complète. AppLocker ne peut pas faire correspondre les arguments et s’appuie sur des règles d’éditeur, de chemin ou de hachage.

Conclusion

Le contrôle de provenance fait passer le contrôle des applications d’un problème de gestion à un modèle de confiance. Au lieu de faire confiance à des fichiers individuels, il fait confiance au processus par lequel les logiciels arrivent sur un système, rendant la sécurité à la fois évolutive et exploitable.

Trusted Ownership s’inscrit pleinement dans cette approche. Il ne s’agit ni d’une liste de blocage ni d’une liste d’autorisation classique, mais d’un modèle dans lequel les logiciels arrivant via un processus IT contrôlé sont autorisés par défaut, tandis que tout ce qui se trouve en dehors de ce processus est refusé par défaut. En appliquant le contrôle à l’origine et à la propriété plutôt qu’à des fichiers définis au cas par cas, Ivanti Application Control et Ivanti Neurons for App Control s’alignent bien mieux sur les techniques d’attaque modernes et les pratiques actuelles de distribution logicielle.

Si vous continuez à considérer le contrôle des applications comme un exercice de gestion de listes, vous en ressentirez la charge administrative. Si vous le considérez comme une frontière de confiance, vous gagnez en évolutivité, en sécurité et en efficacité opérationnelle.

Comment les PDG souhaitent que les RSSI communiquent leur stratégie de gestion des risques de cybersécurité

Tue, 17 Feb 2026 13:00:01 Z

La plupart des PDG peuvent réciter leurs objectifs trimestriels et leur chiffre d’affaires à la décimale près, mais interrogez-les sur l’exposition au risque cyber de leur organisation, et les réponses deviennent plus vagues. Ce n’est pas que les PDG d’aujourd’hui ne se préoccupent pas de la sécurité — la cybersécurité figure parmi les principales préoccupations des conseils d’administration et des équipes dirigeantes. Le problème est plus profond : une rupture fondamentale dans la manière dont les risques de sécurité sont expliqués aux dirigeants métier, qui ne tient pas compte de leur impact sur les résultats de l’entreprise.

Le manque de compétences n’est pas la cause de la plupart des problèmes de communication entre RSSI et PDG. Ils découlent d’un problème bien connu : la malédiction du savoir. La malédiction du savoir est un défi courant dans lequel les experts — en l’occurrence les responsables de la sécurité — peuvent supposer que toutes les personnes présentes ont une compréhension de base des informations et de la terminologie techniques. Ils ne prennent donc pas le temps de reformuler les risques complexes en termes simples ni de les replacer dans un contexte concret.

Le Rapport 2026 sur l’état de la cybersécurité d’Ivanti souligne ce décalage. Près de six professionnels de la sécurité sur dix déclarent que leurs équipes ne sont que modérément efficaces pour communiquer l’exposition au risque à la direction exécutive.

Lorsque PDG et RSSI ne parlent pas le même langage, des vulnérabilités métier critiques peuvent être masquées par le jargon technique. Quand la communication se rompt, les organisations perdent du temps et de l’argent dans des investissements mal orientés, tandis que les lacunes de protection passent inaperçues jusqu’à ce qu’une violation impose la discussion.

Alors que le niveau des menaces augmente, les attaques reposant sur l’IA deviennent plus sophistiquées et les violations de données font chaque semaine la une de l’actualité. Les enjeux d’une communication claire entre les RSSI et la direction exécutive n’ont jamais été aussi élevés.

Pour comprendre pourquoi cet écart de communication persiste, nous devons examiner à la fois les défis fondamentaux et les indicateurs utilisés pour mesurer la réussite.

Pourquoi la communication sur le risque cyber échoue : la malédiction du savoir

Ce décalage entre PDG et RSSI n’est pas dû à un manque de données. C’est même l’inverse. Du point de vue du PDG, le problème n’est ni l’attention ni l’intention. Il réside plutôt dans le fait de voir des tableaux de bord, des métriques, des acronymes et des scores de gravité sans comprendre l’impact de ces résultats sur l’ensemble de l’entreprise.

Les responsables de la sécurité doivent partir du principe que de nombreuses personnes dans la salle ne comprennent pas les implications de termes comme les scores CVSS, les surfaces d’attaque et les vulnérabilités zero-day. Les PDG attendent davantage que des tableaux de bord remplis de métriques, d’acronymes et de scores de gravité.

Les briefings de cybersécurité doivent aller plus loin et montrer les implications financières, juridiques et réputationnelles de ces résultats pour l’entreprise. Un RSSI peut indiquer « 587 vulnérabilités critiques détectées ce mois-ci », alors que ce que le PDG doit réellement savoir, c’est : « Lesquelles menacent notre capacité à servir nos clients, et quel est notre plan pour y remédier ? »

Les KPI de cybersécurité qui comptent pour les PDG

Les KPI utiles relient clairement les efforts de gestion des vulnérabilités au risque métier. Toutefois, notre étude sur la cybersécurité montre que les KPI les plus utilisés par les équipes de sécurité ne reflètent pas le contexte du risque.

Aujourd’hui, seule la moitié des entreprises (51 %) suivent des scores d’exposition en cybersécurité ou d’autres indices fondés sur le risque. De nombreuses équipes de sécurité s’appuient encore sur des indicateurs de processus tels que le délai moyen de remédiation (47 %) ou le pourcentage d’expositions corrigées (41 %).

Des métriques comme le MTTR, la vitesse de déploiement des correctifs et le pourcentage de remédiation sont importantes pour les équipes de sécurité, mais elles mesurent l’efficacité opérationnelle, et non l’exposition métier ou l’impact financier potentiel. Pris isolément, ces indicateurs peuvent sembler rassurants tout en masquant la vraie question : gérons-nous efficacement notre risque ?

Ces métriques, axées sur la rapidité et la couverture, peuvent paraître positives en elles-mêmes, mais elles montrent peu si les efforts actuels de remédiation améliorent réellement la posture de risque. Ce qui compte moins, c’est la vitesse à laquelle les vulnérabilités sont corrigées et leur nombre. Ce qui compte davantage, c’est de savoir si les bons problèmes sont traités.

Une compréhension partagée entre les équipes de sécurité, le conseil d’administration et la direction exige d’ancrer des métriques opaques dans des enjeux réels. Pour les PDG, cela signifie s’aligner avec leur RSSI sur les risques les plus importants pour leur organisation spécifique — êtes-vous un établissement financier fréquemment confronté à des schémas de fraude sophistiqués, à des exigences strictes de conformité comme PCI-DSS et SOX, ainsi qu’à la menace constante de ransomwares ciblant les données financières des clients ? Êtes-vous un organisme de santé qui doit sécuriser un réseau croissant de dispositifs médicaux connectés tout en maintenant des normes de conformité rigoureuses pour protéger les données sensibles des patients ?

Illustrons la différence entre un briefing sécurité destiné aux dirigeants qui s’appuie uniquement sur des métriques techniques et un briefing qui ajoute du contexte et l’impact métier.

Ce que dit le RSSI :

« Nous avons découvert 11 000 vulnérabilités. »
« Le MTTR est passé de 25 à 15 jours. »
« Nous avons atteint un taux de remédiation de 88 % sur les CVE critiques. »

Ce que le PDG doit réellement savoir :

« Nous avons identifié dix vulnérabilités critiques susceptibles d’affecter les systèmes générateurs de revenus. »
« En cas d’attaque aujourd’hui, nous pouvons rétablir les opérations critiques en six heures, contre 48 heures l’an dernier. »
« Cette protection nous permet d’envisager une expansion dans l’UE sans risque de conformité supplémentaire. »

Construire un cadre d’appétence au risque au niveau exécutif

La communication avec les dirigeants repose sur des cadres partagés et un point de référence commun pour définir, mesurer et discuter le risque. Pour éliminer les incohérences et la confusion, toutes les parties prenantes doivent participer à la création et à l’application d’un cadre d’appétence au risque.

L’un des principaux objectifs de ces échanges est d’aider les dirigeants métier à comprendre que le but du programme de cybersécurité n’est pas d’être totalement « sans risque » — il est impossible pour une organisation moderne de le devenir. En d’autres termes, les PDG doivent être capables de distinguer leur appétence au risque de leur posture de risque.

1. Appétence au risque : le niveau de risque que leur entreprise est actuellement prête à tolérer pour atteindre ses objectifs globaux.

2. Posture de risque : la réalité de l’exposition actuelle au risque de l’organisation.

La plupart des organisations reconnaissent désormais la nécessité de formaliser le niveau de risque cyber qu’elles sont prêtes à accepter. L’étude d’Ivanti montre que plus de 80 % des organisations disposent d’un cadre d’appétence au risque documenté.

Cependant, moins de la moitié des organisations déclarent que ces cadres sont étroitement suivis dans les opérations quotidiennes. Lorsque les cadres existent sur le papier mais ne guident pas les décisions réelles, il est très probable que l’appétence au risque et la posture de risque de votre organisation ne soient pas alignées.

Comment la gestion de l’exposition comble l’écart de communication

La gestion de l’exposition est une approche fondée sur le risque qui identifie, hiérarchise et valide en continu l’étendue des menaces potentielles sur l’ensemble de la surface d’attaque. La pratique de la gestion de l’exposition aide à fédérer les responsables de la sécurité et les dirigeants autour d’une stratégie unique et complète, qui recentre la cybersécurité sur les risques critiques pour l’entreprise.

Au lieu de considérer toutes les vulnérabilités comme équivalentes, la gestion de l’exposition vise à identifier et à hiérarchiser les risques les plus élevés de l’organisation en se demandant :

Quelles expositions actuelles les acteurs de la menace exploitent-ils activement ?
Quels actifs doivent être priorisés en fonction des opérations métier actuelles ?
Quels actifs, s’ils étaient compromis, auraient le plus grand impact en termes d’atteinte à la réputation, aux clients ou sur le plan juridique ?

Le rapport d’étude d’Ivanti montre que près des deux tiers des organisations investissent désormais dans la gestion de l’exposition, et que la compréhension des dirigeants a progressé d’une année sur l’autre. Mais l’exécution reste en retrait : seule environ une organisation sur quatre juge excellente sa capacité à évaluer l’exposition au risque.

Pour combler cet écart et opérationnaliser efficacement la gestion de l’exposition, les RSSI doivent ancrer la communication avec les dirigeants autour de trois principes

1. Traduire les signaux techniques en contexte métier. Au lieu de rapporter le nombre de vulnérabilités, expliquez quelles expositions affectent les systèmes générateurs de revenus, les données client ou les environnements réglementés.

2. Prioriser les menaces émergentes selon leur impact, et non leur volume. Les dirigeants n’ont pas besoin de suivre chaque nouvelle technique d’attaque. Ils doivent comprendre quelles situations pourraient perturber matériellement l’activité et dans quelle mesure l’organisation est prête à y répondre.

3. Utiliser des scénarios, pas des feuilles de calcul. Des récits qui relient la cause, l’impact et le résultat, étayés par des données, aident les dirigeants à intégrer le risque et à prendre des décisions plus rapidement.

Cette approche fait évoluer votre stratégie d’atténuation des risques d’une défense réactive vers une prise de décision proactive.

La voie à suivre

Lorsque les dirigeants et les responsables de la sécurité parlent le même langage, la malédiction du savoir peut être levée et la cybersécurité devient un levier stratégique qui protège la valeur de l’entreprise, favorise la croissance et transforme la solidité de la sécurité en avantage concurrentiel.

La malédiction du savoir peut être levée — un indicateur traduit, une conversation axée sur le métier et une décision claire à la fois.

Patch Tuesday de février 2026

Tue, 10 Feb 2026 21:58:44 Z

Le Patch Tuesday de février inclut des mises à jour hors cycle récentes de Microsoft, publiées entre le 17 et le 29 janvier, comprenant plusieurs corrections de bugs et un correctif pour un exploit zero-day dans Microsoft Office. En outre, Microsoft a annoncé la désactivation progressive de NTLM avant la publication du Patch Tuesday de février 2026.

Pour la version du Patch Tuesday de février, Microsoft a corrigé 57 CVE uniques. Six CVE sont signalées comme exploitées, et trois d’entre elles ont également été divulguées publiquement. En ajoutant la vulnérabilité zero-day hors cycle (OOB), cela constitue un ensemble de CVE qui méritent une attention particulière.

Publications hors cycle de janvier

La première publication OOB, le 17 janvier, a corrigé un échec d’invite d’identifiants lors de tentatives de connexion à un bureau distant ou à une appliance distante. La deuxième série de mises à jour OOB a eu lieu les 24 et 26 janvier, corrigeant des plantages d’applications dans Outlook et OneDrive, ainsi que des problèmes de mise en veille prolongée et d’arrêt du système. Enfin, la troisième mise à jour OOB, le 26 janvier, concernait une vulnérabilité zero-day CVE-2026-21509, une vulnérabilité de contournement de fonctionnalité de sécurité dans Microsoft Office.

Microsoft prévoit la désactivation progressive de NTLM

Microsoft a publié son plan de désactivation progressive de New Technology LAN Manager (NTLM) dans les systèmes d’exploitation les plus récents, à partir de 2026 et au-delà. Le protocole d’authentification NTLM a été introduit en 1993 et a depuis été remplacé par les protocoles Kerberos, bien plus sécurisés. Toutefois, NTLM est resté la solution de repli lorsque Kerberos n’est pas disponible, malgré son obsolescence et la faiblesse de ses algorithmes.

La première phase introduit des audits supplémentaires afin d’identifier où NTLM peut encore être utilisé et de le remplacer lorsque cela est possible. Dès maintenant, Microsoft recommande d’utiliser l’audit NTLM avancé déjà disponible dans Server 2025, ainsi que dans Windows 11 24H2 et les versions ultérieures. La deuxième phase commencera avec les mises à jour majeures du système d’exploitation prévues plus tard cette année. Cette mise à jour traitera les « points de friction » ou obstacles en supprimant plusieurs scénarios de repli dans lesquels Kerberos revient à NTLM.

Enfin, lors de la troisième phase, NTLM sera désactivé par défaut. Le code sera toujours présent, mais vous devrez le réactiver explicitement en cas de nécessité absolue. Cette approche en trois phases se déroulera rapidement : planifiez donc correctement le remplacement de NTLM dans votre environnement afin de franchir une étape majeure en matière de sécurité. La phase « NTLM désactivé par défaut » interviendra avec la prochaine mise à jour majeure de Server.

Vulnérabilités Microsoft exploitées

Le 29 janvier, Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans Microsoft Office (CVE-2026-21509). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 7,8, mais son exploitation active a été confirmée. Un attaquant peut envoyer à un utilisateur un fichier Office malveillant et le convaincre de l’ouvrir afin d’exploiter la vulnérabilité. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Remote Desktop Services (CVE-2026-21533). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 7,8, mais son exploitation active a été confirmée. Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait obtenir des privilèges SYSTEM. La vulnérabilité affecte Windows 10 et les éditions ultérieures du système d’exploitation. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité d’élévation de privilèges dans Desktop Window Manager (CVE-2026-21519). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 7,8, mais son exploitation active a été confirmée. Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait obtenir des privilèges SYSTEM. La vulnérabilité affecte toutes les versions actuellement prises en charge et prises en charge via ESU du système d’exploitation Windows. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans MSHTML Framework (CVE-2026-21513). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 8,8, mais son exploitation active a été confirmée. Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait contourner une fonctionnalité de sécurité via un réseau. La vulnérabilité affecte Windows 10 et les éditions ultérieures du système d’exploitation. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans Windows Shell (CVE-2026-21510). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 8,8, mais son exploitation active a été confirmée. Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait contourner une fonctionnalité de sécurité via un réseau. La vulnérabilité affecte toutes les versions actuellement prises en charge et prises en charge via ESU du système d’exploitation Windows. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité dans Microsoft Word (CVE-2026-21514). La vulnérabilité est classée Important par Microsoft et présente un score CVSS v3.1 de 7,8, mais son exploitation active a été confirmée. Un attaquant peut contourner localement une fonctionnalité de sécurité en raison d’une dépendance à des entrées non fiables. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Microsoft a corrigé une vulnérabilité de déni de service dans Windows Remote Access Connection Manager (CVE-2026-21525). La vulnérabilité est classée Modéré par Microsoft et présente un score CVSS v3.1 de 6,2, mais son exploitation active a été confirmée. Un déréférencement de pointeur nul dans Windows Remote Access Connection Manager permet à un attaquant non autorisé de provoquer un déni de service localement. La vulnérabilité affecte toutes les versions actuellement prises en charge et prises en charge via ESU du système d’exploitation Windows. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité comme plus sévère que ne l’indiquent la classification de l’éditeur ou le score CVSS attribué.

Avis de sécurité Ivanti

Ivanti a publié une mise à jour de sécurité pour février. Cette mise à jour concerne Ivanti Endpoint Manager et corrige deux nouvelles CVE ainsi que 11 CVE de gravité moyenne qui avaient été divulguées fin 2025. Des informations plus détaillées sur les mesures d’atténuation sont disponibles dans l’avis de sécurité de février.

En outre, un avis de sécurité a été publié le 29 janvier pour Ivanti Endpoint Manager Mobile (EPMM), concernant un nombre limité de clients au moment de la divulgation. Ivanti invite vivement tous les clients utilisant le produit EPMM sur site à installer rapidement la mise à jour de sécurité. L’avis de sécurité, une analyse technique complémentaire et un script de détection d’exploitation codéveloppé avec le NCSC-NL sont disponibles dans l’avis de sécurité de janvier.

Vulnérabilités tierces

Adobe a publié neuf mises à jour ce mois-ci, corrigeant 43 CVE, dont 27 critiques. Les neuf mises à jour sont classées priorité 3 par Adobe.

Liste des tâches pour les mises à jour de février

Les mises à jour du système d’exploitation Windows et de Microsoft Office sont prioritaires ce mois-ci, car elles corrigent six nouveaux exploits zero-day et un exploit zero-day OOB.

Consultez l’annonce et la documentation de Microsoft sur la désactivation progressive de NTLM afin de commencer à planifier l’obsolescence et la désactivation de NTLM.

Gestion de l’exposition vs gestion des vulnérabilités : laquelle permet de réduire réellement les risques ?

Thu, 29 Jan 2026 13:00:01 Z

La gestion des vulnérabilités accompagne les organisations et le secteur de la cybersécurité depuis des années. Cette pratique éprouvée a aidé les entreprises à défendre leur surface d’attaque et à empêcher les acteurs malveillants d’exploiter les vulnérabilités.

Mais les technologies et les infrastructures IT ont évolué. La gestion des vulnérabilités ne suffit plus à répondre aux défis liés à cette évolution. Désormais, la gestion de l’exposition apporte une approche encore plus globale de la sécurité des terminaux, en couvrant les domaines où la gestion des vulnérabilités montre ses limites.

Examinons ces différences afin de vous aider à choisir la meilleure façon de protéger votre organisation.

Qu’est-ce que la gestion des vulnérabilités ?

La gestion des vulnérabilités est une pratique de cybersécurité qui consiste à identifier, évaluer, prioriser et corriger en continu et de manière proactive les vulnérabilités que les pirates peuvent utiliser pour s’infiltrer dans votre organisation.

Il est toutefois important de noter qu’il existe deux types de gestion des vulnérabilités :

Gestion des vulnérabilités traditionnelle	Gestion des vulnérabilités basée sur les risques
Consiste à tenter de corriger autant de vulnérabilités que possible. Cette approche entraîne souvent des efforts considérables et des attentes irréalistes en matière de réussite, tout en donnant un faux sentiment de sécurité.	Une pratique de gestion des vulnérabilités plus évoluée, qui prend en compte le risque dans la priorisation des vulnérabilités. Elle permet aux organisations de corriger les vulnérabilités critiques qui représentent une menace réelle, afin de les protéger contre les acteurs malveillants tout en garantissant une posture de sécurité solide et une gestion efficace des ressources.

Une approche de gestion des vulnérabilités basée sur les risques va au-delà de la gestion traditionnelle des vulnérabilités et offre à votre organisation les avantages suivants :

Surveille en continu les vulnérabilités pour une sécurité proactive.
Identifie les expositions activement exploitées.
Permet des actions de remédiation efficaces.
Réduit les risques.
Aide les organisations à atteindre la conformité.

Si la gestion des vulnérabilités basée sur les risques couvre de nombreux aspects, elle n’offre toujours pas l’approche globale de la cybersécurité dont les organisations ont besoin pour rester protégées. C’est là que la gestion de l’exposition intervient.

Qu’est-ce que la gestion de l’exposition ?

La gestion de l’exposition est une pratique de cybersécurité en pleine évolution qui offre une visibilité complète sur l’ensemble de votre surface d’attaque. Elle permet aux équipes IT et sécurité d’identifier précisément les zones où votre organisation peut être exposée, tout en intégrant la priorisation basée sur les risques, la remédiation et bien plus encore. La gestion de l’exposition vise à maintenir l’appétence au risque définie par l’organisation elle-même. Elle comprend donc quatre étapes :

Comme la gestion des vulnérabilités basée sur les risques, la gestion de l’exposition aide à prioriser les vulnérabilités et les expositions à traiter en premier selon le risque réel. Elle va toutefois plus loin en tenant compte de ce qui est le plus pertinent pour votre entreprise. Cette approche de cybersécurité garantit que les expositions les plus à risque sont corrigées de manière proactive, avant qu’elles ne puissent être exploitées par des attaquants.

Gestion de l’exposition vs gestion des vulnérabilités : quelle différence ?

La gestion de l’exposition représente l’évolution naturelle de la gestion traditionnelle des vulnérabilités. Alors que la gestion des vulnérabilités se concentre principalement sur l’identification et le traitement des faiblesses des serveurs et des terminaux, la gestion de l’exposition élargit ce périmètre en offrant une visibilité complète sur l’ensemble de la surface d’attaque.

Les principales différences sont les suivantes :

La gestion de l’exposition est conçue pour de nouveaux types d’actifs : les environnements IT modernes sont devenus de plus en plus complexes et incluent désormais des actifs tels que les applications Software-as-a-Service (SaaS), les appareils IoT, l’infrastructure cloud, etc. La gestion de l’exposition est conçue pour tenir compte de ces nouveaux types d’actifs, afin que les équipes IT et sécurité puissent identifier les risques où qu’ils se trouvent dans l’organisation. Ce faisant, la gestion de l’exposition offre une compréhension complète de tous les points d’entrée potentiels. Les organisations peuvent ainsi gérer et réduire les risques plus efficacement que jamais.
La gestion de l’exposition tient compte de la réalité et adopte une approche fondée sur l’appétence au risque : rappelons que la gestion des vulnérabilités est centrée sur l’application de correctifs. Si la gestion des vulnérabilités basée sur les risques fournit une priorisation des risques et une orchestration de la remédiation, elle ne reconnaît pas qu’il est irréaliste pour une organisation de corriger chaque vulnérabilité. L’appétence au risque désigne la mesure, définie par l’organisation elle-même, du niveau de risque qu’elle est prête à accepter. Il s’agit d’une approche nettement plus réaliste, qui fédère l’organisation autour de KPI communs afin de mesurer la réussite de manière cohérente entre les équipes.
La gestion de l’exposition va au-delà des CVE et du CVSS : la gestion des vulnérabilités se concentre principalement sur les vulnérabilités et expositions communes (CVE). Si les CVE constituent une priorité importante pour la plupart des organisations, elles ne sont pas les seuls catalyseurs que les acteurs malveillants peuvent utiliser pour nuire à votre organisation. Les pirates peuvent toujours exploiter les expositions suivantes, non couvertes par la gestion des vulnérabilités, pour s’infiltrer dans votre organisation :
Erreurs de configuration.
Problèmes de sécurité des applications.
Politiques des systèmes IT.
Contrôles des accès privilégiés.

Pour revenir à cette approche globale, la gestion de l’exposition couvre tous ces actifs modernes. En outre, la gestion des vulnérabilités s’appuie fortement sur le Common Vulnerability Scoring System (CVSS) pour prioriser la remédiation. Si le CVSS constitue une mesure solide de la sévérité, il n’offre pas de perspective efficace ajustée au risque.

Le risque est un facteur important à garder à l’esprit, car il prend en compte le fait qu’une vulnérabilité ait été exploitée, qu’elle soit liée à un ransomware ou à un malware, ou qu’elle soit actuellement en forte progression. Ne pas intégrer le risque crée un faux sentiment d’urgence avec le CVSS, ce qui conduit les équipes IT et sécurité à consacrer du temps et des ressources à des vulnérabilités qui ne sont pas réellement urgentes.

Comment protéger votre organisation

Maintenant que nous avons présenté les différences entre la gestion de l’exposition et la gestion des vulnérabilités, il est temps de tirer parti des avantages offerts par la gestion de l’exposition. Découvrez comment le portefeuille de gestion de l’exposition d’Ivanti peut renforcer vos équipes IT et sécurité.

Patch Tuesday de janvier 2026

Tue, 13 Jan 2026 21:52:53 Z

Nouvelle année, nouvelles mises à jour ! Nous vous retrouvons sur le blog Ivanti Patch Tuesday, où nous vous fournissons des informations essentielles pour optimiser vos activités de gestion de l’exposition.

Ce mois-ci, deux CVE Mozilla sont soupçonnées d’être exploitées et une CVE Microsoft a été exploitée.

Par ailleurs, Microsoft présente deux vulnérabilités divulguées publiquement qui devront être examinées afin de déterminer si votre organisation pourrait être affectée par les changements apportés par Microsoft.

Des mises à jour tierces supplémentaires d’Adobe sont également disponibles, et d’autres sont à prévoir de la part de Google et d’Oracle dans les prochains jours et jusqu’à la semaine prochaine ; elles devront être incluses dans votre maintenance mensuelle.

Autre bonne nouvelle : Microsoft a séparé la mise à jour Server 2025 dans une KB distincte ; sa taille n’est donc que de 1,9 Go, contre plus de 4 Go pour la mise à jour cumulative Windows 11 de ce mois-ci.

Vulnérabilité exploitée de Microsoft

Microsoft a corrigé une vulnérabilité de divulgation d’informations dans Desktop Window Manager (CVE-2026-20805). Microsoft classe cette vulnérabilité comme Important et lui attribue un score CVSS v3.1 de 5,5, mais son exploitation dans des conditions réelles a été confirmée. Cette exposition pourrait permettre de divulguer une adresse de section depuis un port ALPC distant correspondant à de la mémoire en mode utilisateur. La vulnérabilité affecte toutes les versions du système d’exploitation Windows actuellement prises en charge, y compris celles couvertes par les mises à jour de sécurité étendues. Une méthodologie de priorisation fondée sur les risques justifie de traiter cette vulnérabilité avec un niveau de gravité supérieur à la classification du fournisseur ou au score CVSS attribué.

Vulnérabilités divulguées publiquement par Microsoft

Microsoft a corrigé une vulnérabilité de contournement de fonctionnalité de sécurité liée à l’expiration de la certification Secure Boot (CVE-2026-21265). Microsoft classe cette vulnérabilité comme Important et lui attribue un score CVSS v3.1 de 6,4, mais elle a été divulguée publiquement. En plus de la mise à jour, le correctif fournit un avertissement concernant les certificats qui expireront en 2026, ainsi que des précisions sur les actions requises pour renouveler les certificats avant leur expiration. Il est recommandé de commencer à examiner les actions que votre organisation pourrait devoir entreprendre pour prévenir d’éventuels problèmes de maintenabilité et de sécurité à l’expiration des certificats.

Microsoft traite une vulnérabilité d’élévation de privilèges dans le pilote Windows Agere Soft Modem (CVE-2023-31096). L’identifiant CVE de la vulnérabilité a été attribué par MITRE en 2023. Elle est classée Important et présente un score CVSS v3.1 de 7,8. La CVE a été divulguée publiquement. La résolution de Microsoft consiste à supprimer les pilotes concernés du système d’exploitation Windows à partir de la mise à jour cumulative de janvier 2026. Microsoft recommande de supprimer toute dépendance existante à ce matériel.

Avis de sécurité Ivanti

Ivanti n’a publié aucun avis de sécurité ce mois-ci.

Vulnérabilités tierces

Mozilla a publié des mises à jour pour Firefox et Firefox ESR, corrigeant un total de 34 CVE. Les trois mises à jour ont un niveau d’impact Élevé. Deux CVE sont soupçonnées d’être exploitées (CVE-2026-0891 et CVE-2026-0892). Les deux sont corrigées dans Firefox 147 (MFSA2026-01), et la CVE-2026-0891 est corrigée dans Firefox ESR 140.7 (MFSA2026-03).
Des mises à jour de Google Chrome et de Microsoft Edge sont à prévoir cette semaine, en plus d’une vulnérabilité de gravité élevée dans Chrome WebView qui a été corrigée dans la mise à jour Chrome du 6 janvier (CVE-2026-0628).
Adobe a publié 11 mises à jour ce mois-ci, concernant DreamWeaver, InDesign, Illustrator, InCopy, Bridge, Substance 3D Modeler, Stager, Painter, Sampler et Designer, ainsi que ColdFusion. ColdFusion est en priorité 1. Toutes les autres sont en priorité 3, mais la plupart des mises à jour incluent des CVE critiques.
La publication du CPU trimestriel d’Oracle est prévue le 20 janvier ; préparez-vous donc à des mises à jour pour les solutions Oracle, notamment Java. Une fois la version Java publiée, attendez-vous à ce que tous les frameworks basés sur Java soient mis à jour au cours des prochaines semaines.

Liste des tâches pour les mises à jour de janvier

Les mises à jour des navigateurs sont prioritaires ce mois-ci. Mozilla a corrigé deux vulnérabilités zero-day soupçonnées d’être exploitées (CVE-2026-0891 et CVE-2026-0892), et Chrome a corrigé une CVE de gravité élevée (CVE-2026-0628).
La mise à jour du système d’exploitation Windows corrige ce mois-ci une vulnérabilité exploitée et deux vulnérabilités divulguées publiquement, faisant de la mise à jour du système d’exploitation Windows une priorité absolue ce mois-ci, au même titre que les mises à jour des navigateurs.
Examinez les échéances des certificats Secure Boot et l’utilisation des pilotes Agere Soft Modem afin d’éviter des problèmes de maintenabilité et de sécurité.

Détournement de DLL : Risques, exemples concrets et comment prévenir les attaques

Wed, 17 Dec 2025 14:00:02 Z

Il y a eu du bruit autour de CVE-2025-56383 (publié le 26 septembre 2025), une vulnérabilité de détournement dans Notepad++ v8.8.3 dans laquelle un fichier DLL peut être échangé pour exécuter du code malveillant.

La CVE a été contestée par plusieurs parties, mais nous ne sommes pas là pour commenter cela. Cependant, nous sommes là pour parler du détournement de DLL et discuter de la menace très réelle qu'il représente pour une organisation. Examinons ce qu'est le détournement de DLL et les mesures que vous pouvez prendre pour protéger vos DLL.

Ce qu'est le détournement de DLL et comment il se produit

Le détournement de DLL (également connu sous le nom d'attaque de préchargement de DLL) est une vulnérabilité de sécurité dans laquelle un fichier Dynamic Link Library (DLL) légitime et de confiance dans une application Windows est remplacé par un fichier malveillant.

Cette méthode exploite la façon dont les applications chargent les fichiers DLL, qui contiennent du code et des données utilisés par plusieurs programmes. En chargeant une DLL malveillante, un acteur de menace peut exécuter son propre code avec les mêmes privilèges que l'application légitime, conduisant à une escalade de privilèges, à la persistance et à l'évasion des défenses.

Lorsqu'un programme démarre, il doit souvent charger diverses DLL pour effectuer des fonctions spécifiques, généralement à partir de répertoires système de confiance. Cependant, si une application n'est pas prudente quant à l'endroit où elle recherche ces DLL, elle pourrait charger une DLL malveillante à partir d'un emplacement non sécurisé ou prévisible (c'est-à-dire le répertoire de travail actuel ou un partage réseau). Cela peut se produire si l'application ne spécifie pas le chemin complet vers la DLL ou si elle recherche la DLL dans un répertoire accessible ou modifiable par un attaquant.

Bien que ce type d'attaque ne soit pas nouveau, il reste efficace en raison de sa simplicité. Et bien que ce problème spécifique concerne les applications Windows, il est important de noter que des vulnérabilités similaires peuvent affecter d'autres systèmes d'exploitation (comme Linux et macOS, qui utilisent le chargement dynamique pour les bibliothèques partagées).

Le détournement de DLL introduit plusieurs risques de sécurité, notamment :

Vol de données : La DLL malveillante peut intercepter et voler des données sensibles, telles que des mots de passe ou des informations personnelles.
Systèmes compromis : L'attaquant peut prendre le contrôle du système, conduisant potentiellement à d'autres attaques ou à l'installation de logiciels malveillants supplémentaires.
Malware : La DLL malveillante peut servir de canal pour propager des logiciels malveillants, infectant d'autres parties du système ou du réseau.

Une DLL peut être détournée de plusieurs manières différentes ; voici quelques-unes des techniques les plus courantes :

Ordre de recherche DLL non sécurisé : Les attaquants placent des DLL malveillantes dans des répertoires recherchés avant l'emplacement de la DLL légitime.
Manipulation de chemin relatif : Des DLL malveillantes sont chargées lorsque les applications utilisent des chemins relatifs.
Redirection de DLL : Des techniques telles que la manipulation de chemin redirigent le processus de chargement de DLL.
Autorisations faibles : Les attaquants remplacent les DLL légitimes par des DLL malveillantes dans des répertoires avec des autorisations faibles.
Détournement de DLL fantôme : Les attaquants exploitent les applications chargeant des DLL inexistantes en plaçant des DLL malveillantes avec le même nom dans les répertoires recherchés.

Ces vulnérabilités potentielles soulignent l'importance des pratiques de codage sécurisées et de la gestion des autorisations de répertoire en matière de prévention de cette forme d'attaque.

Comment prévenir le détournement de DLL et protéger vos DLL

Bien que le détournement de DLL reste une menace, il existe des bonnes pratiques que vous pouvez suivre et mettre en œuvre pour réduire votre risque et créer un environnement informatique plus sûr et plus sécurisé.

Chargement DLL sécurisé :

Utiliser des chemins complets : Spécifiez toujours le chemin complet vers la DLL lors du chargement. Cela garantit que l'application charge la DLL à partir d'un emplacement de confiance (et non à partir d'un répertoire non sécurisé).
Définir le chemin de recherche sécurisé : Utilisez la fonction SetDllDirectory dans Windows pour ajouter des répertoires de confiance au chemin de recherche et exclure ceux qui ne sont pas sécurisés. Cela peut aider à empêcher l'application de charger des DLL à partir d'emplacements inattendus.

Vérifications d'intégrité des fichiers :

Signatures numériques : Assurez-vous que les DLL sont signées avec une signature numérique et vérifiez la signature avant de charger la DLL. Cela peut aider à confirmer que la DLL n'a pas été altérée.
Vérification du hash : Utilisez des fonctions de hachage cryptographiques pour vérifier l'intégrité des fichiers DLL. Si le hash de la DLL ne correspond pas à la valeur attendue, le fichier a peut-être été modifié.

Autorisations utilisateur :

Principe du moindre privilège : Exécutez les applications avec le minimum de privilèges nécessaires. Cela limite les dommages potentiels d'un détournement de DLL, car le code malveillant aura moins d'autorisations pour exécuter des actions nuisibles.
Contrôle de compte d'utilisateur (UAC) : Activez UAC sur les systèmes Windows pour demander aux utilisateurs l'autorisation avant d'exécuter des applications avec des privilèges élevés. Cela peut aider à empêcher les modifications non autorisées des fichiers système.

Application Control et gestion des privilèges :

Applications connues et de confiance : Application Control garantit que seules les applications connues et de confiance peuvent être lancées, éliminant le risque d'introduction d'applications non autorisées.
Contrôle des privilèges : Une gestion efficace des privilèges est cruciale pour prévenir le détournement de DLL. En vous assurant que les applications disposent des droits et privilèges corrects pour se lancer, vous limitez la capacité des utilisateurs non autorisés à introduire des fichiers malveillants. Ce contrôle agit comme une barrière clé, restreignant l'accès dont un attaquant a besoin pour exploiter le mécanisme de recherche de DLL et renforçant ainsi la sécurité de votre environnement.

Logiciels de sécurité :

Antivirus et anti-malware : Utilisez des logiciels antivirus et anti-malware réputés pour détecter et empêcher le chargement de DLL malveillantes. Ces outils peuvent analyser les fichiers et comportements malveillants connus.
Systèmes de détection d'intrusion (IDS) : Mettez en œuvre des IDS pour surveiller les activités inhabituelles, telles que les modifications inattendues des fichiers DLL ou les tentatives de chargement de DLL à partir d'emplacements non sécurisés.

Gestion des patchs :

Maintenir les logiciels à jour : Mettez régulièrement à jour les applications et les systèmes d'exploitation avec les derniers correctifs de sécurité. De nombreuses vulnérabilités de détournement de DLL sont corrigées via des mises à jour, restez donc à jour pour vous protéger contre les menaces connues.
Correction automatisée : Utilisez un outil de gestion automatisée des patchs pour vous assurer que tous les systèmes sont maintenus à jour sans intervention manuelle. Cela réduit la fenêtre d'opportunité pour les attaquants d'exploiter des vulnérabilités connues, y compris celles qui pourraient être utilisées pour le détournement de DLL. Cette approche proactive aide à maintenir l'intégrité de vos applications et systèmes d'exploitation, rendant beaucoup plus difficile pour les attaquants d'injecter des DLL malveillantes.

En mettant en œuvre ces bonnes pratiques, vous pouvez réduire considérablement le risque de détournement de DLL et améliorer la sécurité globale de vos applications et systèmes.

Combinez les bons outils et tactiques pour prévenir les détournements de DLL

Le détournement de DLL est une forme d'attaque persistante depuis des années, prouvant qu'elle est toujours efficace et continuera donc d'être un problème pour les organisations.

Préparez votre organisation pour l'avenir en utilisant les bonnes pratiques mentionnées ci-dessus combinées à des solutions éprouvées comme Ivanti Neurons for App Control pour aider à protéger vos DLL. Des capacités comme Trusted Ownership détectent et refusent l'exécution d'une DLL détournée en s'assurant que la propriété des éléments correspond à votre liste approuvée de propriétaires de confiance.

Et maintenez vos applications à jour pour limiter l'exposition aux vulnérabilités connues. Éliminez le risque d'erreur humaine en automatisant les correctifs avec Ivanti Neurons for Patch Management, garantissant que les systèmes sont automatiquement mis à jour et sécurisés.

ITAM : votre première ligne de défense inattendue contre les cybermenaces

Tue, 16 Dec 2025 14:00:02 Z

Lorsque l’on parle de cybersécurité, on pense souvent aux pare-feux, aux systèmes de détection d’intrusion ou à la protection des terminaux de dernière génération. Pourtant, sous ces boucliers sophistiqués se trouve un socle essentiel (et souvent méconnu) : une gestion robuste des actifs IT (ITAM).

Pour les DSI qui accompagnent des entreprises de taille intermédiaire et de grands groupes dans un paysage numérique de plus en plus périlleux, l’ITAM apporte non seulement une visibilité opérationnelle, mais aussi une première ligne de défense puissante contre les cybermenaces.

Nous verrons ci-dessous comment une démarche ITAM complète apporte une visibilité essentielle sur l’environnement technologique de votre organisation, renforce vos défenses face à l’évolution des cybermenaces, soutient la conformité réglementaire et accélère les opérations de sécurité. Découvrez comment faire de l’ITAM un pilier de votre stratégie peut contribuer à prévenir des violations coûteuses et à bâtir une véritable cyberrésilience.

Les cyberattaques mondiales ont augmenté de 30 % sur un an, et les attaques par ransomware représentent désormais en moyenne 20 à 25 incidents majeurs par jour.

Pourquoi l’ITAM est essentiel : les défis de cybersécurité commencent par un manque de visibilité

Les cybermenaces exploitent presque toujours les faiblesses que les organisations ne voient pas. Shadow IT, appareils obsolètes, logiciels non autorisés et points d’accès non approuvés sont autant de vulnérabilités invisibles qui échappent aux dispositifs de sécurité traditionnels. Un inventaire complet des actifs n’est pas qu’une bonne pratique de gestion : c’est le point de départ d’une gestion efficace des cyberrisques.

Malgré 90 % des organisations affirmant disposer de solides capacités de détection, 57 % ont tout de même subi des incidents de sécurité majeurs en raison d’un manque de visibilité complète.

Prenons cet exemple : dans le Data Breach Investigations Report 2023, Verizon indiquait qu’une part importante des incidents d’intrusion provenait d’actifs négligés : des serveurs n’avaient pas été corrigés parce qu’ils avaient été oubliés, des terminaux avaient été provisionnés sans visibilité sur leur cycle de vie, etc.

Dans ce contexte, l’ITAM constitue un système d’alerte précoce d’une valeur inestimable. En fournissant une cartographie en temps réel, mise à jour en continu, de tous les actifs matériels, logiciels et cloud, il permet aux responsables IT d’identifier les risques avant les attaquants.

Les avantages de l’ITAM pour la cyberrésilience

Nous verrons ci-dessous comment les différents avantages d’un ITAM robuste se traduisent par une posture de sécurité renforcée pour votre organisation.

La gestion du cycle de vie élimine les maillons faibles

Les actifs ne présentent pas des risques uniquement au moment de leur acquisition. Le cycle de vie (de l’intégration, la maintenance et la mise à jour jusqu’au retrait final) multiplie les occasions de mauvaise gestion susceptibles d’ouvrir des portes aux cyberadversaires. Systèmes obsolètes sans support éditeur, logiciels en fin de vie exécutant encore des applications critiques, appareils mis hors service sans effacement des données : ces situations sont courantes dans les environnements complexes.

45 % des organisations manquent de confiance dans leur capacité à connaître toutes les applications utilisées, créant ainsi des angles morts exploités par les attaquants.

Un ITAM robuste garantit que chaque actif est suivi, évalué régulièrement et mis hors service de manière sécurisée, ce qui limite aussi bien les expositions accidentelles que les attaques sophistiquées ciblant les infrastructures héritées.

La conformité réglementaire démontre la maîtrise et évite les sanctions

Les DSI évoluent de plus en plus dans des environnements réglementaires qui exigent une maîtrise démontrable des actifs IT. Des référentiels tels que NIST, ISO 27001 et le RGPD mettent tous l’accent sur la visibilité des actifs comme condition préalable à un contrôle efficace des données sensibles et des infrastructures critiques. Une pratique ITAM mature répond directement à ces exigences en fournissant la documentation et la supervision démontrable nécessaires aux audits et aux demandes réglementaires.

Plus de 80 % des violations sont liées à des lacunes dans la gestion de la surface d’attaque, dues à des actifs exposés sur Internet et vulnérables ainsi qu’à de mauvaises pratiques d’inventaire des actifs.

Par exemple, dans le cadre du RGPD, la capacité à identifier et corriger rapidement les actifs vulnérables qui traitent des données personnelles n’est pas seulement une bonne pratique de sécurité : c’est une obligation légale.

Le partenariat ITAM-sécurité : bien plus qu’un simple suivi d’inventaire

Un véritable ITAM ne se limite pas à tenir des listes. La gestion intégrée des actifs alimente directement les outils d’opérations de sécurité en contexte. Les scanners de vulnérabilités s’appuient sur des inventaires précis pour détecter les expositions. La réponse aux incidents dépend de la capacité à savoir précisément quels systèmes sont concernés. L’application des politiques de sécurité repose sur une compréhension claire des rôles et des relations entre les actifs.

À titre d’exemple, une institution financière a vu son temps de réponse aux incidents réduit de moitié après avoir intégré les données ITAM à sa plateforme SIEM, permettant aux équipes de sécurité d’identifier immédiatement les actifs touchés et de les isoler lors d’une violation. La valeur apportée est ici mesurable et reproductible.

Une cyberdéfense résiliente repose sur une gestion robuste des actifs

L’IT Asset Management n’est pas une simple question d’hygiène opérationnelle. C’est un composant essentiel d’une stratégie de cybersécurité proactive et résiliente. Pour les DSI, investir dans une solution ITAM robuste peut faire toute la différence entre une sécurité de façade et une véritable réduction des risques.

Si vous souhaitez découvrir comment notre solution ITAM peut renforcer la posture de sécurité de votre organisation dès ses fondations, contactez notre équipe dès aujourd’hui et faites le premier pas vers une véritable cyberrésilience.

L’IA fantôme transforme-t-elle discrètement la posture de sécurité de votre environnement de travail ?

Mon, 15 Dec 2025 14:00:01 Z

Les outils d’IA ont connu une progression fulgurante sur le lieu de travail. Ce qui relevait autrefois de fonctions technologiques très spécialisées est désormais courant : le rapport Technology at Work 2025 d’Ivanti a révélé que 42 % des employés de bureau déclarent utiliser des outils d’IA générative, comme ChatGPT, au travail, soit 16 points de plus que l’année précédente.

Le revers de la médaille ? Ces gains de productivité se font en dehors des circuits officiels. Parmi les personnes ayant déclaré utiliser des outils d’IA générative, 46 % indiquent qu’une partie, voire la totalité, des outils qu’elles utilisent ne sont pas fournis par leur employeur. Et un salarié sur trois garde secrets vis-à-vis de son employeur les outils de productivité reposant sur l’IA qu’il utilise.

Les outils d’IA générative peuvent démultiplier la productivité. Mais ils représentent aussi un risque pour la sécurité des données, en particulier lorsqu’ils sont utilisés sans supervision de l’employeur.

Qu’est-ce que l’IA fantôme ?

L’utilisation non autorisée de l’IA n’est qu’une autre forme de shadow IT, c’est-à-dire l’utilisation de technologies sans l’approbation de l’IT.

Les risques introduits par l’IA fantôme sont similaires à ceux du shadow IT, avec toutefois une préoccupation supplémentaire : le volume considérable de données propriétaires dont l’IA générative a besoin pour être efficace. Les outils d’IA générative gratuits, ainsi que certains outils payants, peuvent utiliser les données d’une organisation ou les recherches de ses employés pour entraîner leur modèle, ce qui accroît le risque de fuite de données et de non-conformité.

La révélation récente selon laquelle les conversations ChatGPT partagées étaient explorables par les moteurs de recherche (même si OpenAI a rapidement fait marche arrière) devrait servir de signal d’alarme : sans contrôles appropriés, des tiers peuvent utiliser vos données d’une manière que vous n’approuvez pas. Certains outils gratuits, dont ChatGPT, peuvent être configurés pour respecter les politiques de sécurité, mais cela devient tout simplement impossible lorsque les employés les utilisent de façon dissimulée.

Les outils gratuits comme ChatGPT ne sont pas le seul risque d’IA fantôme. Une source inattendue se trouve en réalité dans les logiciels existants. Avec la course à l’ajout de fonctionnalités d’IA, des outils qui avaient peut-être été approuvés par l’IT auparavant peuvent désormais présenter de nouveaux risques. Et si les équipes de sécurité de l’information n’identifient pas et n’évaluent pas ces nouvelles fonctionnalités, celles-ci contournent de fait les processus de gestion des risques tiers.

Pourquoi une approche de l’IA axée en priorité sur les risques est essentielle

Qu’il s’agisse d’IA générative ou d’autres outils, le shadow IT résulte de l’absence d’un moyen défini et raisonnable de tester des outils ou de mener le travail à bien. Étant donné que l’IA n’est pas près de disparaître, les entreprises doivent aborder son adoption de manière proactive, car interdire les outils ne signifie pas que les employés ne tenteront pas de les utiliser pour gagner en productivité et faciliter leur travail.

Je consacre la majeure partie de mon temps à l’évaluation des risques, y compris ceux que posent les outils d’IA. Souvent, nous devons évaluer le risque au regard d’une opportunité d’améliorer l’activité : dans ce cas, les gains de productivité des employés et les effets indirects, comme la satisfaction des collaborateurs ou le fait de disposer de temps pour travailler sur des projets plus stratégiques.

En résumé, nous devons nous poser la question suivante : existe-t-il un moyen d’introduire les outils demandés par les employés et d’en tirer les bénéfices, tout en maintenant le risque à un niveau acceptable ?

C’est là qu’une approche axée en priorité sur les risques entre en jeu. Une approche de l’adoption de l’IA axée en priorité sur les risques se concentre sur les données qui doivent être intégrées à l’IA et sur la manière dont le tiers les traite. Cette approche est similaire à la gestion des risques fournisseurs : elle permet aux organisations d’utiliser des pratiques et processus établis, tout en les adaptant aux questions propres à l’IA.

Les principales questions à se poser sont les suivantes :

Nos données seront-elles utilisées pour entraîner le modèle d’IA ?
Pendant combien de temps nos données sont-elles conservées ?
Quelles protections existent pour réduire le risque d’exposition de nos données ?
Qui détient les droits sur la propriété intellectuelle générée à l’aide de l’IA ?

Limiter la prolifération des outils d’IA est un élément essentiel de ce travail. À mesure que davantage de fournisseurs proposent des outils d’IA spécialisés, et que vous intégrez plus de fournisseurs tout en donnant à leurs outils d’IA l’accès à vos données, votre risque augmente. Cela vaut également pour les outils existants qui introduisent soudainement l’IA sans modification de coût ni de contrat, ce qui complique la tenue d’un inventaire précis des outils d’IA.

Adopter un cadre de gouvernance de l’IA chez Ivanti

Chez Ivanti, nous luttons contre l’IA fantôme grâce à une approche axée en priorité sur les risques qui repose de bout en bout sur l’engagement des collaborateurs.

Faire sortir l’utilisation de l’IA de l’ombre

Même si nous n’encouragerions jamais l’IA fantôme, les employés qui y ont recours disposent de connaissances précieuses à partager sur la manière d’intégrer l’IA aux workflows. Ainsi, plutôt que d’interdire toute utilisation de l’IA, nous devons nous assurer que les employés disposent d’un parcours clair pour demander des outils d’IA à utiliser au travail et qu’il existe régulièrement des occasions de dialogue ouvert.

Favoriser un dialogue ouvert met les employés à l’aise pour discuter des outils qui les aident à réussir et signifie, au bout du compte, qu’ils les utiliseront, ou utiliseront des outils équivalents, en toute sécurité. Cela permet aux employés de devenir des partenaires actifs dans l’élaboration d’une gouvernance appropriée, plutôt que de chercher à contourner les restrictions.

Une approche mesurée de la mise en œuvre et de l’adoption de l’IA

Une fois qu’un outil est approuvé, il est important de veiller à sa bonne mise en œuvre et de comprendre à quelles données vous lui avez donné accès. C’est particulièrement important au regard des risques de gouvernance des données et de sécurité que les outils d’IA générative font peser sur les organisations. En examinant l’IA sous l’angle de la gouvernance des données, il est possible de traiter de nombreux aspects du risque lié à l’IA.

Chez Ivanti, nous adoptons une approche mesurée : nous dédions une équipe à la réalisation de tests contrôlés d’outils d’IA générative avec d’autres équipes. Nous mettons ensuite en place des boucles de retour d’information, et l’adoption se déploie progressivement afin d’éviter toute perturbation.

Mettre en place une boucle de retour d’information pour les outils d’IA

Nous devons nous poser régulièrement les questions suivantes :

Comment les employés d’Ivanti utilisent-ils l’IA ?
L’apprécient-ils ?
Quels retours ont-ils à partager ?
Comment pouvons-nous améliorer l’outil ?

Cette conversation continue garantit que nous utilisons l’IA de manière responsable tout en répondant aux besoins de productivité des employés.

Il ne s’agit pas de suivre la tendance de l’IA à tout prix. Il s’agit de savoir si cela en vaut la peine, pour l’entreprise comme pour les personnes qui l’utilisent. L’IA fantôme stimule la productivité d’une seule personne. Mais si l’on prend cette productivité et qu’on l’étend, on obtient une amélioration significative pour l’ensemble de l’entreprise.

Lutter de manière proactive contre l’IA fantôme

Le fil conducteur est le suivant : même si l’IA, et en particulier l’IA fantôme, présente de nouveaux risques préoccupants, elle est là pour durer. Les employés qui utilisent l’IA en dehors des canaux officiels ne sont pas mal intentionnés ; ils cherchent plutôt à apporter de la valeur à l’entreprise, même s’ils ne s’y prennent pas de la bonne manière.

Une approche proactive de l’adoption de l’IA axée en priorité sur les risques reconnaît cette réalité. Au lieu d’interdictions réactives qui ne font qu’encourager les contournements, nous devons impliquer les employés afin de comprendre les problèmes qu’ils cherchent à résoudre avec l’IA, pour pouvoir leur proposer des options sûres qui répondent à nos exigences en matière de sécurité et de confidentialité des données.