Ivanti Blog: Sécurité

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.

Pourquoi SELinux est essentiel à la sécurité des entreprises

Thu, 23 Oct 2025 14:03:35 Z

Lors de l’évaluation de produits de cybersécurité, il est facile de se concentrer sur des fonctionnalités visibles, telles que les tableaux de bord, les alertes et les intégrations. Mais la véritable robustesse se trouve souvent plus en profondeur, dans l’architecture elle-même. Security-Enhanced Linux (SELinux) est une capacité intégrée qui illustre des principes rigoureux de conception sécurisée.

Développé à l’origine par la National Security Agency (NSA) des États-Unis et mis à disposition de la communauté open source, SELinux est un cadre de contrôle d’accès obligatoire (MAC) intégré au noyau Linux. Il applique des règles strictes, pilotées par des politiques, qui régissent la façon dont les applications, les services et les utilisateurs interagissent avec les ressources système, constituant ainsi une défense puissante contre l’escalade de privilèges, les mouvements latéraux et les exploits zero-day.

Si le produit de cybersécurité que vous évaluez intègre SELinux, en particulier en mode enforcing, c’est un indicateur fort de maturité architecturale et de confinement proactif des menaces.

Qu’est-ce qui rend SELinux différent et plus efficace ?

SELinux associe à chaque processus et fichier un contexte de sécurité et utilise des politiques prédéfinies pour contrôler leurs interactions. Contrairement aux contrôles d’accès traditionnels qui reposent sur les autorisations des utilisateurs, SELinux applique des politiques de sécurité à tous les utilisateurs et processus, même à ceux disposant de privilèges root (administrateur).

C’est un point essentiel, car cela empêche les attaquants d’exploiter l’accès root pour se déplacer latéralement, exfiltrer des données ou désactiver les contrôles de sécurité. SELinux retire en quelque sorte à root son statut de « superpouvoir », en imposant des limites de sécurité définies par des politiques, et non par les privilèges.

Ainsi, même si un attaquant obtient un accès privilégié (c’est-à-dire root), SELinux peut l’empêcher d’exécuter des actions non autorisées qui s’écartent de la politique prédéfinie. Ce niveau de sécurité va au-delà de la détection pour couvrir la prévention au niveau du système d’exploitation.

Fonctionnement de SELinux

SELinux fonctionne selon plusieurs modes :

Désactivé : non actif, aucune application de la sécurité.
Permissif : consigne les violations, mais ne les bloque pas ; utile pour les tests.
Enforcing : bloque activement les actions non autorisées sur la base de la politique.
Application stricte : désigne le mode enforcing associé à une politique stricte appliquée par défaut.

Les produits qui exécutent SELinux en mode enforcing strict offrent une protection en temps réel des processus et des ressources du système. La surface d’attaque est réduite au minimum, ce qui rend les déplacements des attaquants dans le système beaucoup plus difficiles. Chaque utilisateur, service et démon est soumis à un contrôle d’accès obligatoire fondé sur le moindre privilège. L’application stricte est généralement utilisée dans les environnements à haute sécurité (par exemple, administration publique, finance, défense), où aucun processus n’est approuvé par défaut et où chaque interaction doit être explicitement autorisée par une politique.

Même si vous ne configurerez pas SELinux vous-même, il est utile de comprendre comment des fournisseurs comme Ivanti l’utilisent pour renforcer la sécurité de leurs produits :

1. Démarrage en mode permissif : nous commençons par observer le comportement du système sous les politiques SELinux, sans rien bloquer.

2. Tests approfondis : nous consignons les violations, identifions les opérations légitimes et affinons les politiques afin d’éviter les faux positifs.

3. Développement de politiques personnalisées : les politiques sont adaptées à l’architecture du produit et à ses cas d’utilisation.

4. Validation en laboratoire en mode enforcing : avant la publication, nous testons SELinux en modes enforcing et application stricte dans des conditions simulées proches du réel.

Ce processus garantit que SELinux renforce la sécurité sans perturber les fonctionnalités, et que les utilisateurs bénéficient d’une protection optimale sans compromis sur les performances. En outre, le processus décrit ci-dessus s’applique à chaque version : à mesure que le logiciel évolue vers de nouvelles versions, la politique SELinux doit être testée, ajustée et reprise pour chaque nouvelle version du produit logiciel.

Ce processus prend du temps et exige d’importantes ressources de développement pour être correctement exécuté. Seuls les fournisseurs de sécurité les plus engagés et les plus proactifs configurent SELinux avec une application stricte.

Exemple concret : déploiement d’Oracle Linux

Oracle Linux prend en charge SELinux en mode enforcing et est largement utilisé pour sécuriser les environnements de bases de données Oracle et les charges de travail sur Oracle Cloud Infrastructure. SELinux contribue à isoler les processus, à appliquer le principe du moindre privilège et à protéger les données sensibles contre les accès non autorisés, même dans des déploiements d’entreprise complexes.

Pour les acheteurs, cela signifie que les produits conçus sur Oracle Linux avec SELinux activé, notamment Ivanti Connect Secure, sont déjà renforcés contre de nombreuses catégories d’attaques. (Vous trouverez plus d’informations dans le guide officiel d’Oracle.)

Une technologie de sécurité qui crée de la valeur métier

Lorsque SELinux est intégré à une solution de cybersécurité, cette technologie apporte des avantages stratégiques alignés sur les priorités des entreprises.

Préparation aux audits et à la conformité : SELinux consigne chaque tentative d’accès, réussie ou refusée, créant ainsi une piste d’audit détaillée. L’application de SELinux et la piste d’audit contribuent à répondre aux exigences réglementaires telles que le durcissement CIS niveaux 1/2, STIG, NIST-800 et d’autres réglementations qui imposent le renforcement des systèmes.
Contrôle d’accès granulaire : des règles précises sont appliquées au niveau des processus, limitant l’accès même pour les utilisateurs root. Cela réduit le risque d’escalade de privilèges et de menaces internes, ce qui est particulièrement important dans les environnements contenant des données sensibles ou des rôles utilisateurs complexes.
Surface d’attaque réduite : SELinux isole les processus et applique l’accès selon le principe du moindre privilège, ce qui empêche les mouvements latéraux au sein du système. Cette stratégie de confinement est essentielle pour limiter le rayon d’impact d’une compromission. SELinux bloque les actions non autorisées au niveau du système d’exploitation, ce qui rend plus difficile l’exploitation des vulnérabilités par les attaquants, y compris les zero-days.
Assurance de niveau entreprise : les fournisseurs comme Ivanti qui utilisent SELinux dans leurs produits démontrent un engagement fort envers les bonnes pratiques de sécurité. Cette approche soutient la gestion des risques, renforce la confiance et différencie clairement la solution sur un marché concurrentiel.
Stabilité opérationnelle : lorsque les politiques sont correctement ajustées, SELinux fonctionne discrètement en arrière-plan, en appliquant la sécurité sans impact sur les performances, ce qui est idéal pour les environnements critiques où la disponibilité est essentielle.

Conclusion sur la valeur de SELinux

Les acheteurs qui évaluent des produits de cybersécurité doivent aller au-delà des fonctionnalités visibles et se demander ce qui protège le système en son cœur. SELinux fait partie de ces technologies intégrées en profondeur qui appliquent discrètement une protection réelle, en bloquant les actions non autorisées (même celles provenant d’utilisateurs privilégiés) et en contenant les menaces avant qu’elles ne se propagent.

Sa présence dans un produit est le signe d’une architecture renforcée, d’un confinement proactif des menaces et d’un fournisseur qui prend l’intégrité du système au sérieux. Vous ne le configurerez pas vous-même, mais vous en bénéficierez chaque fois qu’un exploit échouera à s’implanter.

L’engagement d’Ivanti en matière de sécurité

Ivanti a été l’une des premières entreprises à adhérer à l’engagement « Secure by Design » de la CISA en 2024. Dans le cadre de cette initiative, Ivanti a fortement investi dans le renforcement du produit Connect Secure, la modernisation de son système d’exploitation et l’intégration de la sécurité à chaque couche du développement.

Au cœur de la philosophie de développement d’Ivanti se trouve notre cycle de développement logiciel sécurisé (Secure Software Development Lifecycle, SSDLC), qui permet de mettre en œuvre les sept éléments clés de la conception logicielle sécurisée : Security as Code (SaC), Secure by Default, Least Privilege, Separation of Duties (SoD), Minimize Attack Surface Area (ASA), Complete Mediation et Failing Securely. Par ailleurs, Ivanti applique également son propre standard strict de développement d’applications sécurisées, qui impose la conformité aux normes OWASP Application Security Verification Standards (ASVS). Ensemble, ces cadres rigoureux garantissent que chaque fonctionnalité produit est conçue et implémentée avec la sécurité comme considération première, offrant aux clients des solutions qui répondent aux références les plus élevées du secteur.

Découverte de la surface d'attaque : Comment identifier la surface d'attaque de votre entreprise

Mon, 18 Aug 2025 09:54:55 Z

Contrôler sa surface d'attaque, c'est comme entretenir son gazon. Si on ne tond pas après la pluie, il grandit rapidement. Avec une surface d'attaque, la situation devient vite incontrôlable, avec une augmentation des cyber-risques. Même s’il est illusoire d’éradiquer totalement le risque — l’environnement de threat intelligence ne cessant d’évoluer — il est possible, et surtout impératif, de garder le risque à un niveau maîtrisé, en ligne avec l'appétence au risque de votre entreprise.

Pourquoi la découverte de la surface d'attaque est-elle si importante ?

Pour gérer les cyber-risques, il faut avant tout savoir où l’on va : cela passe par une identification précise de sa surface d’attaque. Cela implique de recenser ce qui peut servir de porte d’entrée ou d’attaque — qu’il s’agisse de postes client, de vulnérabilités et d'autres vecteurs d'attaque.

Les grandes références du secteur abondent en ce sens : la première fonction du NIST CSF (National Institute of Standards and Technology Cybersecurity Framework) version 1.1 est l'identification. Selon le NIST, les « activités liées à l'identification constituent les bases d'une utilisation efficace de ce cadre ». Même logique pour la liste Contrôles CIS v8, qui inclut les contrôles suivants :

Contrôle 1 — Inventaire et contrôle des actifs de l'entreprise
Contrôle 2— Inventaire et contrôle des actifs logiciels
Contrôle 7— Gestion continue des vulnérabilités

En clair : on ne protège bien que ce que l’on connaît. Mais comment faire l’inventaire de tous nos actifs ?

Comment démarrer la découverte de ma surface d'attaque ?

Il s’agit d’adopter l’œil du hacker : quelles ressources seraient facilement exploitables ?

La surface d'attaque se décline en trois volets : la surface d'attaque numérique, la surface d'attaque physique et la surface d'attaque humaine. Ce blog se concentre sur le volet numérique, même s'il aborde aussi brièvement les deux autres volets.

Votre surface d'attaque numérique couvre l'ensemble des actifs IT traditionnels, à savoir le matériel (postes clients et serveurs, notamment) et les applications logicielles, ainsi que les actifs tournés vers Internet, comme les applications Web, les adresses IP, les noms de domaine, les certificats SSL et les services Cloud.

La première étape consiste à dresser l'inventaire des éléments de votre surface d'attaque numérique et à identifier les problèmes de visibilité. Une classification peut être établie comme suit :

Connus connus : les cyberactifs identifiés comme faisant partie de votre surface d’attaque.
Les inconnus connus : les cyberactifs identifiés comme appartenant à votre surface d’attaque, mais sur lesquels vous manquez de visibilité et/ou de contrôle.
Les inconnus non connus : les cyberactifs dont vous ne savez pas s’ils font ou non partie de votre surface d’attaque.
N/A : les cyberactifs pour lesquels vous êtes certain à 100 % qu’ils ne font pas partie de votre surface d'attaque.

Pour ne rien oublier, utilisez notre Checklist Surface d'attaque personnalisable.

Outils et approches pour découvrir et gérer votre surface d'attaque

Une fois la classification effectuée, l’étape suivante consiste à choisir des outils adaptés afin d’affiner votre visibilité et de lever les angles morts. L’objectif : transformer les inconnus (connus ou non) en actifs maîtrisés.

La « gestion de la surface d'attaque » inclut des solutions plus spécifiques : CAASM (Gestion de la surface d'attaque des cyberactifs), EASM (Gestion de la surface d'attaque externe) et DRPS (Services de protection contre les risques numériques). À partir des résultats de ces outils, vous pouvez identifier plus facilement les vulnérabilités. Certains proposent même des fonctions de priorisation et de remédiation, ce qui permet de réagir rapidement en cas de menace et de limiter les risques.

Cependant, les organisations ont eu besoin de découvrir et de gérer leur surface d’attaque numérique bien avant l’apparition des solutions ASM. À défaut de solutions ASM, de nombreuses entreprises ont adopté — et continuent d’utiliser — d’autres méthodes pour répondre à ce besoin.

Approche	Description	Atouts	Limites
Outils de découverte des actifs	Inventaire des actifs matériels et logiciels qui se connectent à votre réseau.	Largements déployés dans la plupart des entreprises. Mieux que les feuilles de calcul.	Comportent souvent des angles morts, comme le Shadow IT, les systèmes tiers et les applications métier.
BAS (Simulation de fuites de données et d'attaques)	Tests automatisés des vecteurs de menaces pour comprendre les vulnérabilités de sécurité et valider les contrôles de sécurité.	Génération de rapports sur les faiblesses de sécurité et priorisation de la remédiation basée sur les risques.	Traitent uniquement les attaques connues. Pas de remédiation.
CSPM (Gestion du niveau de sécurité du Cloud)	Suivi des changements de configurations Cloud.	Visibilité en temps réel sur les configurations Cloud.	Ne signalent pas quand les configurations cessent d'être conformes ni l'impact potentiel des menaces émergentes.
CMDB (Base de données de gestion des configurations)	Suivi des changements apportés aux systèmes.	Largement déployés dans les entreprises.	Ne signalent pas quand les configurations cessent d'être conformes ni l'impact potentiel des menaces émergentes.
Approche locale (manuelle)	Feuilles de calcul, scripts et processus manuels pour gérer la surface d'attaque.	Peu onéreux, voire gratuits (si l'on ne prend pas en compte les heures de travail des ingénieurs IT).	Chronophages et sujets aux erreurs. Ni évolutifs ni en temps réel.
ITAM (Gestion des actifs IT)	Suivi et surveillance du cycle de vie des actifs.	Largement déployés dans la plupart des entreprises. Mieux que les feuilles de calcul.	Traitent uniquement les actifs connus et gérés, en ignorant les actifs inconnus ou non gérés.
Tests d'intrusion (comme les outils de tests d'intrusion automatisés ou les tests d'intrusion en SaaS)	Simulation d'une cyberattaque en identifiant les vulnérabilités de votre réseau et de vos applications.	Exemples de postures de sécurité avec les priorités budgétaires associées.	Traitent uniquement la première phase de la chaîne de cyberdestruction : la reconnaissance. Des résultats ponctuels dont la qualité dépend de la compétence des testeurs qui réalisent la simulation.
Red Teaming	Image complète de la posture de cybersécurité de l'entreprise en mettant en scène une simulation de cyberattaque visant les réseaux, les applications, les protections physiques et les collaborateurs.	Va plus loin que les tests d'intrusion, en se concentrant sur les autres phases de la chaîne de cyberdestruction. Va aussi au-delà de la surface d'attaque numérique, en examinant les surfaces d'attaque physique et humaine.	Des résultats ponctuels dont la qualité dépend de la compétence des testeurs qui réalisent la simulation.
Intelligence des menaces (Threat Intelligence)	Informations sur les menaces et autres problèmes de cybersécurité.	Informations sur les menaces et les vulnérabilités.	S'adressent aux entreprises dont le niveau de maturité en sécurité est élevé, et ayant du personnel qualifié et d'importantes ressources.
Outils de gestion des vulnérabilités (comme les scanners)	Identification et gestion des vulnérabilités de votre infrastructure et de vos applications.	Déjà déployés dans la plupart des entreprises.	Aucune visibilité des actifs inconnus. Énormes quantités de données.

Même si ces outils ne disposent pas de toutes les fonctions et de tous les avantages d'une solution ASM dédiée, ils ont quand même leur place dans les pratiques IT et de sécurité d'une entreprise.

En fait, les outils CAASM ne fonctionnent pas sans les données des outils de découverte des actifs, d'ITAM, de gestion des vulnérabilités et/ou de gestion des correctifs. De même, l'EASM complète les services d'intelligence des menaces et de tests de sécurité répertoriés ci-dessus.

Comment identifier la surface d'attaque physique de mon entreprise ?

Le premier élément important de la surface d’attaque physique d’une organisation recoupe en partie la surface d’attaque numérique. Il s’agit de la surface d’attaque des postes client, qui regroupe tous les équipements connectés au réseau : ordinateurs de bureau, ordinateurs portables, périphériques mobiles et périphériques IoT. Les outils et les techniques servant à découvrir la surface d'attaque numérique sont également pertinents pour cette catégorie.

Le second élément majeur concerne les bureaux, les centres de données et les autres locaux de l’entreprise. Là encore, certaines techniques utilisées pour la surface d’attaque numérique sont applicables, notamment dans le cadre des tests d’intrusion physique réalisés lors des exercices de red teaming.

Comment identifier la surface d'attaque humaine de mon entreprise ?

L'identification de votre surface d'attaque humaine commence par l'examen de votre organigramme. Toute personne associée à votre entreprise et ayant accès à ses informations sensibles (ou étant en capacité d'empêcher d'autres personnes d'accéder à ces informations) fait partie de votre surface d'attaque humaine. Cela inclut vos collaborateurs (à plein temps et à temps partiel), les membres du conseil d'administration, les sous-traitants, les partenaires, les fournisseurs, les prestataires et éditeurs de logiciels, les intérimaires, etc.

Le Red Teaming, pratique visant à identifier les éléments des surfaces d'attaque numérique et physique, peut aussi servir à identifier un composant majeur de la surface d'attaque humaine : la sensibilité des collaborateurs à l'ingénierie sociale.

En parallèle, l’analyse des affectations de droits et des accès réels reste indispensable pour ne pas se laisser surprendre par des privilèges mal accordés ou des comptes dormants.

J'ai identifié la surface d'attaque de mon entreprise. Et maintenant ?

La découverte de votre surface d'attaque n'est que la première étape vers votre objectif final : la remédiation des vulnérabilités qui présentent le plus de risque pour votre entreprise. Ce processus s'inscrit dans la gestion de l'exposition.

Comme nous l'avons dit, la découverte de la surface d'attaque est l'une des bases de votre stratégie de sécurité : vous ne pouvez pas protéger ce dont vous ignorez l'existence. La gestion de l'exposition intègre un autre pilier essentiel : la détermination de votre appétence au risque. Elle définit le niveau de risque que votre entreprise est prête à accepter pour atteindre ses objectifs. (Vous pouvez vous inspirer de ce modèle personnalisable.)

Maintenant que vous avez géré ces deux aspects fondamentaux, vous pouvez évaluer les vulnérabilités détectées dans votre surface d'attaque. Vous déterminez ainsi l'importance du danger qu'elles représentent pour votre entreprise, et si cela entre dans les limites de votre appétence au risque (ce processus est traité en détail dans notre guide Évaluer objectivement le cyber-risque).

Les vulnérabilités hors du champ de votre appétence au risque doivent être remédiées en priorité, ce qui vous permet de concentrer vos efforts de remédiation là où ils auront le plus d’impact.

Que signifie vraiment la cybersécurité proactive ? Mesures pour protéger votre organisation

Mon, 04 Aug 2025 19:26:10 Z

Le rapport 2025 d’Ivanti sur l’état de la cybersécurité a mis en évidence un constat sans grande surprise : les organisations font état d’un écart de préparation important (c’est-à-dire l’écart entre le niveau de menace perçu et leur degré de préparation) pour chaque vecteur de menace et chaque vulnérabilité sur lesquels nous les avons interrogées.

Si les équipes de sécurité consacrent à juste titre des ressources au renforcement de leur résilience afin de pouvoir répondre rapidement aux attaques et s’en remettre, combler ces écarts de préparation exige des mesures de cybersécurité proactive.

Cybersécurité réactive ou proactive : quelle est la différence ?

La cybersécurité proactive désigne les actions menées avant une cyberattaque pour améliorer votre posture de sécurité et réduire votre surface d’attaque ; la cybersécurité réactive intervient lorsqu’une attaque a déjà compromis vos systèmes, afin de la contenir et de minimiser les dommages qu’elle peut causer.

Ces deux approches ne s’excluent absolument pas. La sécurité proactive réduit les risques, mais ne les élimine pas. Le terme « réactive » peut avoir une connotation légèrement négative, mais les capacités qui vous permettent de répondre à une attaque, même lorsque vous avez considérablement réduit votre exposition aux risques, restent essentielles.

Exemples de mesures de cybersécurité proactive

La sécurité proactive est une philosophie, pas un plan prêt à l’emploi. Elle repose sur l’idée que prendre des mesures pour minimiser l’exposition bien avant qu’un risque ne se matérialise est la meilleure façon d’utiliser le temps et les ressources consacrés à la sécurité.

Cela étant, vous pouvez développer des capacités spécifiques pour adopter cette philosophie, notamment (mais certainement pas uniquement) l’analyse des vulnérabilités, la gestion de la surface d’attaque, la gestion des vulnérabilités, la validation des expositions, la gestion des correctifs, la gestion des configurations et la formation des utilisateurs.

Gestion de la surface d’attaque

La gestion de la surface d’attaque vise à comprendre l’ensemble des points d’entrée d’une organisation — numériques, physiques ou humains — que des pirates peuvent utiliser pour accéder à son environnement IT.

La surface d’attaque comprend les appareils (connus et inconnus), mais l’environnement ne se limite pas aux appareils. Les applications, les logiciels, les comptes de réseaux sociaux ainsi que les autres espaces ou actifs numériques utilisés par des personnes associées à l’entreprise en font également partie.

À lire également :Checklist de la surface d’attaque

Analyse des vulnérabilités

L’analyse des vulnérabilités correspond exactement à ce que son nom indique : des scanners spécialisés évaluent les réseaux et les actifs IT afin d’identifier les vulnérabilités exploitables, puis les signalent aux équipes de sécurité pour qu’elles les traitent. Comme il existe des milliers de vulnérabilités connues (et que de nouvelles apparaissent chaque jour), l’analyse des vulnérabilités est d’autant plus efficace lorsqu’elle est automatisée.

Les analyses externes des vulnérabilités examinent un réseau depuis l’extérieur, en cherchant à identifier les moyens par lesquels un pirate pourrait y pénétrer. Les analyses internes adoptent le point de vue d’une personne qui a déjà réussi à s’introduire dans le réseau et des vulnérabilités qu’elle pourrait exploiter de l’intérieur.

Gestion des vulnérabilités

L’analyse des vulnérabilités et la gestion de la surface d’attaque alimentent le cycle plus long et plus complet de gestion des vulnérabilités. Il s’agit d’un processus continu dans lequel les vulnérabilités sont identifiées et classées selon un certain niveau de priorité, avant que les équipes ne déterminent la meilleure façon de les résoudre.

Une approche courante de la gestion des vulnérabilités consiste à établir les priorités en fonction de la gravité, mais cette approche peut surestimer certaines vulnérabilités tout en en négligeant d’autres. Ajouter le contexte de la menace — cette vulnérabilité est-elle activement exploitée ? — et le contexte du risque — quel serait l’impact de l’exploitation de cette vulnérabilité pour mon organisation ? — permet d’obtenir une vision plus claire de la priorité réelle.

Validation des expositions

La validation des expositions teste la faisabilité d’une attaque et la robustesse de vos contre-mesures en exécutant des scénarios d’attaque. Cette approche est également appelée sécurité offensive. Les deux méthodes les plus courantes sont les tests d’intrusion et le red teaming.

Tests d’intrusion (ou pen tests) : des hackers éthiques tentent de pirater votre système, puis fournissent un retour sur ce qui a bien fonctionné et sur les domaines à améliorer. Les pen tests peuvent également être réalisés à l’aide d’outils automatisés.
Red teaming : comme les pen tests, cette approche consiste à faire réaliser par des hackers éthiques une cyberattaque planifiée dans le but de découvrir où vos défenses peuvent être améliorées. Le red teaming est une simulation fondée sur un scénario, tandis que les pen tests visent à rechercher autant de vulnérabilités différentes que possible.

La validation adversariale des expositions, ou AEV, émerge également comme pratique, en utilisant des logiciels pour réaliser en continu et de manière autonome des simulations d’attaque afin de démontrer l’existence d’expositions.

Gestion des correctifs

Une fois les vulnérabilités identifiées grâce à la gestion de la surface d’attaque et à l’analyse des vulnérabilités, hiérarchisées grâce à la gestion des vulnérabilités, puis validées grâce à la validation des expositions, la question devient : comment réagir ?La gestion des correctifs est l’un des moyens de répondre aux vulnérabilités et de les corriger, en particulier les vulnérabilités logicielles pour lesquelles des correctifs existent.

La gestion des correctifs se prête particulièrement bien à l’automatisation, notamment lorsqu’elle est associée à une gestion des vulnérabilités basée sur les risques. Les workflows qui passent automatiquement de la détection à la prise de décision, puis au déploiement, réduisent le délai moyen de remédiation et minimisent les erreurs humaines.

La gestion des correctifs présente toutefois un angle mort important : le shadow IT. Sans inventaire précis des logiciels utilisés par les employés, il est impossible de faire respecter la conformité des correctifs. C’est pourquoi la composante de découverte de la gestion de la surface d’attaque est si essentielle.

Gestion des configurations

La gestion des configurations, comme la gestion des correctifs, est un moyen de répondre aux vulnérabilités identifiées — dans ce cas, les vulnérabilités qui concernent les appareils eux-mêmes plutôt que les logiciels qui y sont exécutés. La configuration désigne les mesures de cybersécurité proactive définies au niveau de l’appareil, comme l’application de l’authentification multifacteur ou du chiffrement. Si ces mesures peuvent être appliquées individuellement par l’utilisateur final, elles sont plus efficacement imposées à l’aide d’un logiciel de gestion des terminaux.

Là encore, comme pour la gestion des correctifs, le shadow IT complique la situation. Les appareils inconnus et non gérés peuvent ne pas respecter les normes de sécurité de votre organisation — et il est impossible de le savoir. Comme pour la gestion des correctifs, la composante de découverte de la gestion de la surface d’attaque est essentielle. En identifiant des appareils auparavant inconnus et en les intégrant à la gestion, les équipes IT peuvent faire respecter la conformité.

Formation des utilisateurs

Votre surface d’attaque n’est pas uniquement numérique : elle comporte également une dimension humaine. Le phishing et d’autres formes d’ingénierie sociale exploitent les vulnérabilités humaines, souvent en les combinant à des expositions numériques (vulnérabilités logicielles, mauvaises configurations, etc.) pour lancer une attaque. Former les employés contribue à minimiser les expositions, tout comme la remédiation des vulnérabilités numériques.

Obtenir l’adhésion aux mesures de cybersécurité proactive

Obtenir l’adhésion aux mesures de cybersécurité proactive est, à certains égards, plus difficile que pour les mesures de cybersécurité réactive. La menace ne s’est pas encore matérialisée, il est donc plus difficile pour les parties prenantes hors sécurité de comprendre les compromis nécessaires, comme des interruptions temporaires de l’activité ou d’autres éléments susceptibles de freiner la productivité, au moins à court terme. La formation des utilisateurs prend du temps dans des emplois du temps déjà chargés. Le déploiement de correctifs peut mettre des applications hors ligne ou nécessiter du dépannage.

Pour obtenir et conserver l’adhésion à ce type de mesures, les équipes de sécurité doivent veiller à minimiser les perturbations que la remédiation peut entraîner (par exemple, en utilisant un déploiement par anneaux, qui déploie les mises à jour logicielles dans des « anneaux » de plus en plus larges, en identifiant les problèmes et en les corrigeant à chaque étape, avant d’étendre le déploiement à l’ensemble des utilisateurs).

Un exercice d’évaluation des risques peut également aider à rendre concrète, pour les autres parties prenantes, une menace qui ne s’est pas encore matérialisée. Une mesure objective de votre exposition et du coût des risques associés — en particulier si vous pouvez quantifier cette exposition en termes financiers — peut faire la différence entre une acceptation à contrecœur et un véritable soutien à la sécurité proactive.

À lire également :Évaluer objectivement le cyber-risque : guide des évaluations des risques fondées sur les données

Pourquoi la cybersécurité proactive est importante

Une stratégie de cybersécurité proactive n’est pas incompatible avec la sécurité réactive : une organisation saine dispose de capacités solides pour traiter les risques avant et après leur matérialisation. Mais les actions préventives amélioreront votre posture de risque et rendront les situations où un risque se matérialise moins fréquentes et plus espacées. Les mesures de cybersécurité proactive, comme la gestion de la surface d’attaque, l’application de correctifs, des configurations adaptées et la sensibilisation des utilisateurs, constituent des investissements évidents dans la sécurité à long terme de votre organisation.

Ignorer les attaques sur la chaîne logicielle peut coûter très cher

Mon, 05 May 2025 12:34:43 Z

Le rapport d'Ivanti sur l'état de la cybersécurité en 2025 révèle que seulement 1/3 des entreprises sont protégées contre les menaces sur la chaîne logicielle. Les pirates ciblent de plus en plus les dépendances aux tiers, transformant progressivement la chaîne logicielle en maillon faible.

Le risque croissant d'attaques sur la chaîne logicielle

Les surfaces d'attaque ne cessent de s'étendre, à toute vitesse, et l'un des vecteurs clés de cette expansion est la chaîne logicielle. Les entreprises modernes dépendent d'un grand nombre d'applications, d'outils et de dépendances logicielles dans leur infrastructure technologique. D'après un rapport de BetterCloud, en 2024, une entreprise utilise en moyenne 112 applications SaaS. Et cet enchevêtrement ne cesse de se compliquer. En moyenne, chaque application comporte 150 dépendances (dont 90 % sont indirectes), qui correspondent à l'immense majorité des vulnérabilités.

Les acteurs de la menace qui visent les dépendances aux tiers se sont multipliés ces dernières années : en 2024, 75 % des chaînes logicielles ont subi une attaque. Ces menaces sur la chaîne logicielle sont aussi plus sophistiquées, car les assaillants traquent la moindre faiblesse dans le code d'un fournisseur. Pour autant, les équipes de sécurité peinent à valider comme il se doit tous leurs composants logiciels.

Les études d'Ivanti montrent que, même si 84 % des dirigeants d'entreprise affirment que la surveillance de la chaîne logicielle est « très importante », presque la moitié (48 %) n'ont toujours pas identifié les composants les plus vulnérables de leur propre chaîne. Ce manquement à leur devoir de vigilance expose les entreprises à de graves risques financiers et réputationnels.

Attaques courantes sur la chaîne logicielle

D'après Gartner, 45 % des entreprises subiront une attaque sur leur chaîne logicielle d'ici 2025, dont les plus courantes comprennent notamment :

Les attaques sur le serveur en amont, les plus communes, consistent à cibler un système placé en amont des utilisateurs, comme un référentiel de code, et à y injecter une charge malveillante ou un malware. Ce dernier se répand alors vers les utilisateurs en aval, par exemple par une simple mise à jour logicielle.
Les attaques en milieu de flux se rapportent aux incidents où les agresseurs compromettent des systèmes intermédiaires, comme des outils de développement logiciel, au lieu de la base de code d'origine.
Les attaques de substitution ou la confusion de dépendance tentent de tromper un développeur ou un système afin qu'il télécharge une dépendance logicielle infectée depuis une source externe. Classiquement, le nom de ce logiciel malveillant ressemble à celui d'une bibliothèque interne approuvée. La version malfaisante est souvent intégrée au build logiciel à la place de la dépendance légitime.
Les attaques par certificat de signature de code se produisent lorsqu'un pirate injecte un logiciel malveillant dans les certificats numériques de signature de code censés valider la sécurité et l'authenticité des logiciels. Ces attaques se déclenchent lorsque l'acteur de la menace compromet l'environnement de développement par ingénierie sociale ou toute autre tactique.
Les attaques sur l'infrastructure CI/CD visent les pipelines de développement automatisés en y introduisant des malwares, par exemple en clonant des référentiels GitHub authentiques à des fins malveillantes.

Exemples récents d'attaques sur la chaîne logicielle

Il n'y a pas à chercher bien loin dans l'actualité pour y trouver des exemples concrets arrivés au point critique. Certains cas d'attaques sur la chaîne logicielle ont retenu l'attention du monde entier ces dernières années.

Attaque par ingénierie sociale sur Okta
- En octobre 2023, Okta, fournisseur de services de gestion des identités et des accès, a subi une grave fuite de données liée à son système de service client. L'attaque a été rendue possible suite à des opérations d'ingénierie sociale réussies ciblant les centres de support IT de quatre de ses clients. Les cybercriminels ont utilisé ces informations d'authentification d'administration pour lancer plusieurs attaques en aval. Résultat : ils ont pu accéder frauduleusement aux données des milliers de clients Okta, notamment 1Password, BeyondTrust et Cloudflare.
Attaque par ransomware sur Kaseya
- En juillet 2021, des pirates ont exploité six vulnérabilités Zero Day de l'outil de gestion à distance Kaseya. Ils s'en sont servis pour distribuer une charge malveillante de ransomware au travers d'une mise à jour logicielle qui a infecté des centaines de MSP (fournisseurs de services gérés) et leurs clients. Cette attaque a entraîné le blocage de près de 2 000 entreprises dans le monde et a fait les gros titres lorsque les assaillants ont réclamé une rançon énorme de 70 millions de dollars (qui n'a jamais été payée).
Attaque sur l'infrastructure CI/CD Codecov
- En janvier 2021, des acteurs malveillants ont infiltré l'outil très répandu de test de code Codecov, utilisé alors par plus de 29 000 clients. Ils ont obtenu un accès non autorisé au script Bash de mise en ligne du code de Codecov et y ont introduit un code malveillant, que les clients de Codecov ont ensuite utilisé dans leurs pipelines CI/CD. Codecov n'a pas détecté ni signalé cette attaque avant avril 2021. Les malfaiteurs ont donc potentiellement eu accès aux données sensibles des systèmes de milliers de clients pendant des mois.
- Chacune de ces attaques sur la chaîne logicielle a provoqué des dommages en cascade à grande échelle, à la fois chez le fournisseur visé, chez des milliers de ses clients et au-delà.

Les graves préjudices des attaques sur la chaîne logicielle

Il ne faut pas sous-estimer l'ampleur des dommages d'une attaque sur la chaîne logicielle. Chacune des attaques citées a entraîné des dommages financiers et réputationnels importants et a conduit de nombreuses entreprises à repenser leur approche de la sécurité fournisseur.

Impact financier

Cybersecurity Ventures prévoit que le coût annuel mondial des attaques sur la chaîne logicielle des entreprises va atteindre l'énorme somme de 138 milliards de dollars d'ici 2031 (contre 60 milliards en 2025). Les pertes sont diverses : perte d'exploitation, coûts de remédiation et frais juridiques, et les amendes éventuelles pour non-conformité. Après sa fuite de données de 2023, Okta a vu le cours de ses actions chuter de 11 %. Après une autre fuite de données majeure en 2022, l'entreprise a ensuite été poursuivie en justice par ses actionnaires, à qui elle a dû payer 60 millions de dollars.

Impact opérationnel

Lors d'une attaque sur la chaîne logicielle, des milliers de clients peuvent subir des perturbations ou l'arrêt de leurs systèmes, ce qui stoppe les opérations critiques et provoque des retards qui affectent ensuite d'autres fournisseurs. Citons deux exemples parmi les établissements touchés par les conséquences de l'attaque Kaseya. En Suède, un grand distributeur alimentaire a été contraint de fermer 800 magasins pendant un week-end entier et les chemins de fer nationaux ont aussi subi des perturbations. À l'autre bout du monde, 11 écoles et plus de 100 crèches en Nouvelle-Zélande ont également dû cesser toute opération en ligne et revenir au papier et crayon jusqu'à ce que l'incident soit résolu.

Perte de réputation

Un préjudice réputationnel public peut nuire à la confiance des clients et des actionnaires envers l'entreprise. La fidélité des fournisseurs et des clients, fruit d'années de travail, peut s'écorner. En mars 2023, le logiciel leader des communications d'entreprise 3CX a été compromis lorsque des pirates ont injecté un code malveillant dans l'application. Les données sensibles de plus de 600 000 clients ont été potentiellement exposées et l'entreprise a subi des mois durant l'attention négative des médias et des critiques publiques.

Où s'arrête la responsabilité ? Dette technique et responsabilité partagée

Les menaces sur la chaîne logicielle devraient se multiplier et s'aggraver. Il est donc impératif pour les entreprises de définir clairement les responsabilités et d'appliquer strictement les meilleures pratiques de sécurité à leurs fournisseurs tiers et à la sécurité de leur chaîne logicielle.

Qui est responsable de la sécurité des logiciels ?

Actuellement, de nombreuses entreprises n'ont aucun processus strict ni standardisé pour évaluer la sécurité des fournisseurs tiers. En outre, de nombreux clients et fournisseurs divergent sur l'entité responsable de la gestion de la sécurité des logiciels tiers.

Le rapport sur l'état de la cybersécurité en 2025 s'appuie sur des entreprises présentant différents niveaux de maturité en cybersécurité. Nous avons utilisé les résultats pour développer notre échelle de maturité de la cybersécurité. Cette échelle s'étend des entreprises les moins matures (niveaux 1 et 2) à celles disposant des capacités les plus avancées (niveau 4).

Cette étude fait ressortir que les entreprises les moins matures sont le plus souvent convaincues que le fournisseur de logiciel est seul responsable de la cybersécurité. Cependant, les entreprises les mieux préparées à la cybersécurité sont d'avis que les responsabilités sont partagées entre le fournisseur de logiciels et le client.

Comment se protéger des menaces sur la chaîne logicielle

La sécurité de la chaîne logicielle constitue un pilier essentiel d'une stratégie de cybersécurité exhaustive et proactive.

Pour renforcer la chaîne logicielle et la protéger des attaques, les entreprises doivent traiter tous les fournisseurs et composants tiers comme une extension de leur surface d'attaque globale. Nous vous proposons ici nos principales recommandations pour mieux prévenir les attaques sur la chaîne logicielle, et mieux détecter et traiter les menaces qui la visent.

1. Gestion rigoureuse des fournisseurs et évaluation des risques

Exercez votre devoir de vigilance avant de choisir un fournisseur de logiciels. Privilégiez ceux qui respectent les normes industrielles et ont publié leur stratégie de divulgation des vulnérabilités. Pour limiter les risques, le client et le fournisseur doivent réaliser régulièrement des audits, faire des revues de code et des évaluations proactives.

Notre étude montre que plus une entreprise est avancée en matière de cybersécurité, plus elle est susceptible d'exercer son devoir de vigilance dans l'évaluation de la cybersécurité de ses fournisseurs tiers. Elle va notamment :

Incorporer des questionnaires d'évaluation de la sécurité (SAQ) dans son évaluation.
Tenir compte des certifications de sécurité du fournisseur, comme ISO 27001 et SOC 2.
Passer en revue les normes de conformité propres au secteur.
S'assurer que le fournisseur dispose de plans et de processus de réponse aux incidents pour gérer les failles de sécurité.
Demander une nomenclature logicielle (SBOM) pour mieux comprendre les composants Open Source et tiers utilisés dans ses logiciels.

2. Surveillance en continu et remédiation proactive sur toutes les dépendances

Le secret, c'est d'utiliser des outils et processus automatisés de détection des menaces pour surveiller et évaluer tous vos composants logiciels. On oublie souvent les dépendances – surtout dans les composants logiciels Open Source –, qui représentent un risque majeur de vulnérabilités si elles ne sont pas régulièrement surveillées et mises à jour.

Les outils IA et d'automatisation peuvent fournir des informations en temps réel sur les périphériques, les applications et les performances réseau afin de remonter les problèmes potentiels. Les solutions de remédiation automatisée et d'autoréparation constituent des méthodes efficaces pour résoudre ces remontées pratiquement sans aucune intervention humaine.

3. Échanges réguliers avec les fournisseurs tiers

Le partage des responsabilités en matière de sécurité de la chaîne logicielle repose sur des échanges fréquents et ouverts entre les clients et les fournisseurs tiers. Les équipes Sécurité et IT doivent rester informées des mises à jour logicielles, des correctifs apportés aux vulnérabilités connues et de toute menace de sécurité émergente.

En savoir plus sur la sécurité de la chaîne logicielle

Vous voulez en savoir plus ? Lisez notre Rapport sur l'état de la cybersécurité en 2025 pour obtenir des conseils éclairés sur les menaces de cybersécurité les plus pressantes aujourd'hui et sur les stratégies de gestion proactive des risques.