SharePoint : la RCE de mai désormais exploitée activement

La CISA a signalé qu’une faille d’exécution de code à distance affectant Microsoft SharePoint, corrigée par Microsoft en mai, est désormais exploitée activement. Le point important n’est donc plus seulement l’existence d’un correctif, mais le changement de statut opérationnel de la vulnérabilité : une faiblesse déjà documentée et patchée bascule dans le champ de l’exploitation réelle, avec un niveau d’urgence nettement supérieur pour les équipes en charge des environnements SharePoint. La source initiale relayée ici est l’alerte reprise par BleepingComputer à partir de la communication de la CISA sur une faille RCE SharePoint désormais observée dans des attaques en conditions réelles.

Pour les organisations qui exploitent SharePoint, en particulier en environnement on-premises ou hybride, ce changement de contexte impose une réévaluation immédiate de l’exposition. Une vulnérabilité RCE sur un composant collaboratif central, souvent connecté à l’authentification d’entreprise, aux workflows documentaires et parfois à d’autres briques Microsoft, peut déboucher sur une compromission du serveur, l’exécution de charges arbitraires, le vol de données et un pivot vers le reste du système d’information. Dans les environnements fortement interconnectés, l’impact dépasse largement la seule plateforme documentaire.

À ce stade, l’alerte publique met surtout l’accent sur deux éléments factuels : la faille a déjà été corrigée par l’éditeur, et elle fait maintenant l’objet d’une exploitation active signalée par la CISA. Lorsqu’une vulnérabilité entre dans le catalogue des failles exploitées de la CISA, cela constitue en pratique un signal de priorisation fort pour les RSSI, les équipes d’exploitation et les administrateurs Microsoft. Même lorsqu’aucun détail d’exploitation complet n’est rendu public, l’existence d’attaques observées suffit à faire évoluer le niveau de risque.

Dans ce type de dossier, la difficulté opérationnelle tient souvent à un faux sentiment de sécurité : beaucoup d’équipes savent qu’un correctif existe, mais n’ont pas toujours vérifié son déploiement effectif sur l’ensemble des fermes SharePoint, des nœuds applicatifs, des serveurs de préproduction ou des environnements moins visibles. Les retards de patching, les fenêtres de maintenance restreintes, les dépendances applicatives et la complexité des fermes SharePoint contribuent fréquemment à laisser des surfaces exposées plus longtemps que prévu.

La communication officielle de Microsoft reste la référence première pour identifier précisément le ou les identifiants CVE concernés, les versions affectées et les packages de mise à jour à appliquer. La CISA, de son côté, sert ici de déclencheur de priorité en confirmant l’exploitation active. BleepingComputer a relayé cette évolution, mais les actions techniques doivent être pilotées à partir des bulletins Microsoft et des recommandations de l’éditeur. En l’absence d’éléments complets et vérifiés dans la source secondaire, il est préférable de ne pas sur-spécifier un score CVSS, un identifiant CVE unique ou une chaîne d’exploitation détaillée non confirmée.

Pour les équipes françaises, ce type d’alerte doit être traité avec la même rigueur qu’une vulnérabilité de périmètre exposée sur Internet. Les environnements hébergés chez OVH, Scaleway, o2switch ou dans des infrastructures internes ne sont pas protégés par défaut contre une faille applicative déjà exploitée si le composant SharePoint vulnérable reste accessible. La priorité immédiate est donc double : confirmer le niveau de patch réel, puis rechercher des indices de compromission sur les systèmes potentiellement exposés avant la mise à jour.

Versions affectées

La communication relayée par la CISA et BleepingComputer indique qu’il s’agit d’une faille Microsoft SharePoint corrigée en mai et désormais exploitée activement. En revanche, la source secondaire fournie ne détaille pas à elle seule l’inventaire complet des versions affectées et corrigées. Pour rester strictement factuel, il faut donc s’appuyer sur l’advisory Microsoft correspondant à la vulnérabilité visée par la CISA.

Les points certains à retenir sont les suivants :

• Produit concerné : Microsoft SharePoint.
• Nature de la faille : exécution de code à distance (Remote Code Execution).
• Statut : corrigée par Microsoft en mai, puis signalée comme activement exploitée par la CISA.
• Action attendue : identifier la version exacte de SharePoint déployée dans l’organisation et la comparer au bulletin de sécurité Microsoft associé.

En pratique, les équipes doivent établir sans délai une cartographie précise :

• instances SharePoint en production ;
• fermes secondaires et environnements de test ;
• serveurs publiés via reverse proxy ou directement exposés ;
• nœuds oubliés, serveurs de reprise, images VM anciennes et snapshots réactivables ;
• intégrations hybrides avec Microsoft 365 ou d’autres services internes.

La vérification doit être menée à partir des références officielles Microsoft, en recherchant le bulletin de sécurité publié en mai pour la faille RCE SharePoint mentionnée par la CISA. Selon les pratiques de l’éditeur, les informations utiles se trouvent généralement dans :

• la page du Microsoft Security Response Center ;
• le guide de mise à jour de sécurité Microsoft ;
• la documentation produit SharePoint listant les security updates applicables.

Dans les environnements où l’inventaire logiciel n’est pas totalement fiable, il est recommandé de vérifier localement la présence des mises à jour installées, l’état des binaires SharePoint et l’historique des correctifs Windows/SharePoint. Une simple hypothèse de conformité ne suffit pas, surtout quand une exploitation active est confirmée.

Exemples de points de contrôle utiles côté système :

• historique Windows Update ;
• correctifs installés via Get-HotFix lorsque cela est pertinent ;
• version de build SharePoint remontée par l’administration centrale ou les outils d’inventaire ;
• cohérence des versions entre tous les nœuds d’une même ferme.

Point de méthode : sur SharePoint, une ferme partiellement mise à jour peut laisser subsister un risque si un nœud vulnérable reste accessible, directement ou indirectement. La conformité doit être vérifiée serveur par serveur, pas seulement au niveau déclaratif du service.

Si votre organisation s’appuie sur un infogérant ou un hébergeur, il faut obtenir une confirmation explicite des versions corrigées déployées, de la date d’application du patch et du périmètre exact couvert. Dans les cas d’hébergement managé, une ambiguïté fréquente concerne la frontière de responsabilité entre l’infrastructure Windows, SharePoint lui-même et les composants annexes publiés en frontal.

Vecteur d'attaque

Une faille RCE sur SharePoint signifie qu’un attaquant peut, sous certaines conditions décrites par l’éditeur, provoquer l’exécution de code sur le serveur cible. Même sans divulguer de chaîne d’exploitation détaillée, la gravité opérationnelle est élevée pour plusieurs raisons structurelles propres à SharePoint.

D’abord, SharePoint est souvent positionné comme une application stratégique : portail intranet, GED, espace projet, workflow documentaire, publication de contenus, connecteur avec d’autres services Microsoft. Il concentre donc des données sensibles, des comptes de service à privilèges, des secrets applicatifs et des liens de confiance avec Active Directory, SQL Server, Exchange, Teams ou d’autres briques internes. Une exécution de code sur un serveur SharePoint n’est pas un incident isolé ; elle peut devenir le point d’entrée d’une compromission plus large.

Ensuite, les serveurs SharePoint sont fréquemment accessibles à distance, au moins pour les utilisateurs internes, parfois pour des partenaires ou des collaborateurs nomades via VPN, proxy applicatif ou publication web. Dès lors qu’une vulnérabilité est exploitable à distance, la surface d’attaque est potentiellement importante, surtout si des interfaces exposées répondent depuis Internet ou depuis des segments réseau peu cloisonnés.

Concrètement, l’impact peut se décliner en plusieurs scénarios réalistes :

Exécution de code sur le serveur applicatif

Le scénario central reste l’exécution de code arbitraire dans le contexte du service affecté. Selon les privilèges du processus compromis et la configuration de la machine, l’attaquant peut :

• déployer un web shell ;
• créer ou modifier des tâches planifiées ;
• installer une porte dérobée ;
• lancer des commandes système ;
• collecter des secrets présents sur le serveur.

Sur un hôte Windows, cela peut se traduire par l’apparition de processus inhabituels, l’écriture de fichiers dans des répertoires web ou temporaires, ou encore l’exécution de commandes via powershell.exe, cmd.exe, wscript.exe ou d’autres interpréteurs système.

Accès aux contenus et aux secrets applicatifs

Une fois sur le serveur, un attaquant peut chercher à accéder aux contenus SharePoint, aux paramètres de connexion, aux comptes de service et aux informations de configuration. Même si la faille n’accorde pas immédiatement des privilèges d’administration domaine, elle peut fournir assez d’accès pour préparer un mouvement latéral. Les secrets applicatifs, les comptes techniques et les connexions à d’autres systèmes sont des cibles prioritaires.

Pivot dans le système d’information

Le risque majeur, du point de vue d’un RSSI, est le pivot. Un serveur SharePoint compromis peut servir de relais vers :

• la base de données associée ;
• d’autres serveurs de la ferme ;
• des partages de fichiers ;
• des annuaires et services d’authentification ;
• des postes administrateurs qui se connectent à la plateforme.

Dans les environnements où les serveurs applicatifs disposent d’autorisations réseau larges, l’attaquant peut transformer une vulnérabilité applicative en point d’appui pour la reconnaissance interne, l’escalade de privilèges et l’extension de la compromission.

Persistance discrète

Les plateformes collaboratives constituent aussi de bonnes cibles pour la persistance. Un serveur SharePoint compromis peut héberger des artefacts difficiles à remarquer si l’organisation ne dispose pas d’une supervision applicative et système suffisamment granulaire. Des fichiers ajoutés dans des répertoires web, des scripts déclenchés périodiquement, des comptes techniques modifiés ou des services installés peuvent rester en place après un simple patch si aucune investigation post-compromission n’est menée.

Le changement de statut vers l’exploitation active est précisément ce qui rend la détection indispensable. Une organisation qui applique le correctif aujourd’hui mais qui a été compromise hier ne règle qu’une partie du problème : elle ferme la porte, mais ne traite pas nécessairement l’intrusion déjà réalisée.

Pourquoi la bascule vers l’exploitation active change la priorité

Tant qu’une faille reste théorique ou seulement démontrée en laboratoire, certaines équipes peuvent la placer derrière des urgences opérationnelles plus visibles. Lorsque la CISA confirme une exploitation active, la question n’est plus de savoir si la faille est intéressante pour des attaquants, mais si votre environnement a déjà été ciblé ou le sera à court terme.

Cette évolution doit conduire à revoir trois délais :

• délai d’identification des serveurs concernés ;
• délai de déploiement du correctif Microsoft ;
• délai d’investigation pour rechercher des traces d’exploitation antérieure.

Dans les organisations matures, ces trois chantiers doivent être lancés en parallèle. Attendre la fin du patching pour commencer la chasse aux IoC allonge inutilement la fenêtre de risque.

Impact

L’impact potentiel d’une RCE SharePoint exploitée activement est élevé, même en l’absence de détails publics complets sur les chaînes d’attaque observées. Les conséquences les plus probables se répartissent en quatre axes.

Compromission du serveur

Le premier effet est la perte d’intégrité du serveur SharePoint. L’attaquant peut altérer le système, déposer des outils, manipuler les journaux ou modifier la configuration. Si l’hôte joue un rôle central dans la ferme, la disponibilité du service peut aussi être touchée, volontairement ou non.

Atteinte à la confidentialité

SharePoint héberge souvent des documents RH, financiers, juridiques, techniques ou commerciaux. Une compromission peut exposer :

• des documents métiers ;
• des métadonnées de projets ;
• des listes internes ;
• des pièces jointes ;
• des informations d’authentification ou de configuration.

Pour les organisations soumises à des obligations réglementaires, cette dimension peut entraîner des notifications internes, des analyses d’impact et, selon les cas, des obligations vis-à-vis des autorités ou des partenaires.

Mouvement latéral et élévation du risque global

Une application collaborative compromise devient fréquemment un tremplin. Les comptes de service, les jetons, les secrets en mémoire, les connexions de confiance et les habitudes d’administration créent un contexte favorable au mouvement latéral. Un serveur SharePoint n’est pas seulement une cible ; c’est aussi une plateforme de rebond.

Déploiement d’outils post-exploitation

Lorsque l’exploitation active d’une faille est constatée dans la nature, il faut envisager l’utilisation d’outils post-exploitation classiques : scripts PowerShell, charges mémoire, web shells, tâches planifiées, comptes ajoutés localement, modifications IIS ou services persistants. Les détails varient selon les campagnes, mais la logique reste constante : stabiliser l’accès, échapper à la détection et préparer la suite des opérations.

Comment patcher

Le correctif existe déjà, ce qui simplifie la décision : il faut appliquer la mise à jour de sécurité Microsoft correspondant à la faille SharePoint signalée par la CISA comme activement exploitée. La difficulté n’est pas de savoir s’il faut patcher, mais de le faire rapidement, complètement et proprement sur tous les nœuds concernés.

Comme la source fournie ne détaille pas le numéro exact du correctif ni la matrice complète des versions, la procédure ci-dessous reste volontairement ancrée sur les bonnes pratiques vérifiables et sur la documentation officielle Microsoft.

1. Identifier le bulletin Microsoft exact

Commencez par retrouver l’advisory officiel Microsoft lié à la faille SharePoint mentionnée par la CISA. Les sources de référence sont :

• le Microsoft Security Response Center ;
• le Security Update Guide de Microsoft ;
• la documentation des mises à jour SharePoint.

À partir de cette référence, relevez :

• l’identifiant CVE ;
• les éditions SharePoint affectées ;
• la mise à jour de sécurité correspondante ;
• les prérequis éventuels ;
• les opérations post-installation nécessaires.

2. Sauvegarder et préparer la fenêtre de maintenance

Avant déploiement, vérifiez les sauvegardes applicatives et système, ainsi que la capacité de retour arrière compatible avec vos procédures internes. Sur SharePoint, les changements de patch niveau ferme doivent être préparés avec attention, notamment si des personnalisations ou intégrations tierces sont présentes.

3. Déployer les mises à jour Windows/SharePoint

Selon votre mode d’administration, la remédiation passera généralement par les mécanismes de mise à jour Microsoft ou par l’installation du package spécifique SharePoint fourni par l’éditeur. Exemples de commandes génériques utiles côté Windows pour inventorier ou déclencher les opérations d’administration, à adapter à votre procédure interne :

Get-HotFix

Cette commande PowerShell peut aider à vérifier les correctifs installés sur le serveur, même si la validation finale doit être faite par rapport au bulletin Microsoft et à la version SharePoint attendue.

wmic qfe list brief

Sur certains environnements, cet inventaire peut compléter la vérification des correctifs présents. Il ne remplace pas une validation applicative côté SharePoint.

Si votre organisation utilise des outils centralisés comme WSUS, Microsoft Endpoint Configuration Manager ou une chaîne de patch management équivalente, assurez-vous que le correctif SharePoint de mai a bien été approuvé, distribué et installé sur tous les serveurs concernés.

4. Finaliser la mise à jour SharePoint

Selon la version de SharePoint et la nature du correctif, des étapes complémentaires peuvent être nécessaires après installation, par exemple au niveau de la configuration de la ferme. Les équipes doivent suivre strictement la procédure éditeur. Dans un contexte SharePoint, il est courant de devoir vérifier l’état de la ferme après patch, la cohérence des nœuds et le bon fonctionnement des services applicatifs.

Des commandes d’administration SharePoint peuvent être utilisées pour contrôler l’état général, par exemple :

Get-SPFarm Get-SPServer

Ces commandes illustrent la nécessité de vérifier l’état de la ferme, mais la séquence exacte dépend de la version déployée et des consignes Microsoft. Il faut se référer à la documentation officielle du correctif pour éviter toute opération inadaptée.

5. Vérifier la version cible et tester les usages critiques

Une fois le patch appliqué :

• contrôlez la version de build remontée par SharePoint ;
• vérifiez que tous les nœuds affichent un niveau cohérent ;
• testez l’accès utilisateur ;
• testez les workflows et connecteurs critiques ;
• surveillez les journaux applicatifs et système pendant les heures qui suivent.

Le point essentiel n’est pas seulement l’installation du correctif, mais la confirmation que la version corrigée publiée par l’éditeur est effectivement active sur l’ensemble du périmètre exposé.

6. Si SharePoint est externalisé

Pour les environnements opérés par un tiers, demandez formellement :

• la référence du correctif appliqué ;
• la date et l’heure du déploiement ;
• la liste des serveurs couverts ;
• la confirmation des contrôles post-patch ;
• les éléments de recherche d’indices de compromission réalisés.

Dans un contrat d’infogérance, le patching seul ne suffit pas : il faut également clarifier qui mène l’investigation de compromission potentielle, qui conserve les journaux et qui pilote l’escalade en cas d’IoC positifs.

Détection

Parce que l’exploitation active est confirmée par la CISA, la détection doit être traitée comme une priorité au même niveau que le patching. L’objectif est de répondre à deux questions :

• des serveurs SharePoint vulnérables sont-ils encore exposés ?
• une exploitation a-t-elle déjà eu lieu avant l’application du correctif ?

Sans publier d’IoC non confirmés, on peut lister des axes d’investigation robustes et immédiatement exploitables par les équipes SOC, CERT internes ou administrateurs Windows/SharePoint.

Journaux web et IIS

Les journaux IIS sont une source centrale pour repérer :

• des requêtes inhabituelles vers des endpoints SharePoint ;
• des séquences répétées depuis une même adresse IP ;
• des pics d’erreurs 500, 401, 403 ou 404 autour de chemins applicatifs sensibles ;
• des chaînes anormales dans les paramètres d’URL ou les en-têtes HTTP.

Exemples de champs à examiner :

• cs-uri-stem ;
• cs-uri-query ;
• c-ip ;
• cs(User-Agent) ;
• sc-status ;
• time-taken.

Des requêtes vers des chemins SharePoint rarement utilisés, des paramètres encodés de façon atypique, des rafales d’accès très rapprochés ou des user-agents incohérents avec vos usages habituels peuvent justifier une investigation plus poussée.

Événements Windows et PowerShell

Une RCE réussie peut déclencher des artefacts côté système. Les équipes doivent examiner :

• créations de processus anormales ;
• lancements de powershell.exe par des processus IIS ou SharePoint ;
• usage de cmd.exe, cscript.exe, wscript.exe, mshta.exe ;
• tâches planifiées nouvellement créées ;
• services ajoutés ou modifiés ;
• événements de connexion inhabituels sur le serveur.

Si la journalisation avancée est activée, recherchez des lignes de commande suspectes, des téléchargements distants, des commandes d’inventaire système ou des accès à des répertoires web applicatifs.

Fichiers et répertoires à surveiller

Il faut inspecter les répertoires susceptibles d’héberger des artefacts de persistance ou des dépôts temporaires :

• répertoires web IIS ;
• répertoires applicatifs SharePoint ;
• C:\inetpub\wwwroot\ ;
• répertoires temporaires système ;
• emplacements de scripts ou d’extensions inattendus.

Les signaux utiles incluent :

• fichiers récemment créés en dehors des cycles de déploiement normaux ;
• extensions inhabituelles ;
• fichiers ASPX inconnus ;
• scripts ou binaires dont la signature et la provenance ne sont pas établies.

Comptes et privilèges

Vérifiez :

• les comptes locaux ajoutés récemment ;
• les changements de groupes administrateurs ;
• les comptes de service modifiés ;
• les nouvelles délégations ou autorisations sur la ferme.

Une compromission applicative peut rester discrète tout en s’accompagnant d’ajustements de privilèges destinés à faciliter la persistance.

Trafic réseau sortant

Un serveur SharePoint n’a généralement pas vocation à initier n’importe quel trafic vers Internet. Des connexions sortantes inhabituelles peuvent révéler :

• un téléchargement de charge utile ;
• une communication de commande et contrôle ;
• une exfiltration ;
• une phase de reconnaissance ou de rebond.

Surveillez en particulier :

• destinations nouvelles ;
• ports non attendus ;
• communications chiffrées vers des hôtes inconnus ;
• pics de trafic hors horaires normaux.

Exemples de contrôles immédiats

Quelques vérifications rapides peuvent aider à prioriser l’analyse :

Get-ChildItem -Recurse C:\inetpub\wwwroot\ | Sort-Object LastWriteTime -Descending | Select-Object FullName, LastWriteTime -First 50

Cette commande PowerShell permet d’identifier rapidement les fichiers récemment modifiés dans l’arborescence web IIS. Elle ne prouve pas une compromission, mais peut faire ressortir des artefacts inattendus.

Get-ScheduledTask | Sort-Object TaskPath, TaskName

Utile pour lister les tâches planifiées et repérer des entrées anormales, surtout si elles ont été créées en dehors des procédures d’administration habituelles.

Get-WinEvent -LogName Security -MaxEvents 200

Permet un premier aperçu des événements de sécurité récents, à compléter par des filtres adaptés à votre politique de journalisation.

Dans un SOC, ces contrôles doivent être corrélés avec les logs proxy, EDR, pare-feu et annuaires. L’enjeu est d’identifier si un comportement suspect sur SharePoint s’inscrit dans une séquence plus large : authentifications anormales, connexions administratives inhabituelles, trafic sortant vers des destinations rares, ou modifications de comptes.

Mitigation

Le correctif Microsoft reste la mesure de remédiation prioritaire. Si vous ne pouvez pas patcher immédiatement, des mesures temporaires peuvent réduire l’exposition, sans remplacer la mise à jour.

• Réduire l’exposition réseau : limitez l’accès aux seules sources nécessaires, désactivez toute publication Internet non indispensable, et renforcez les filtrages en frontal.
• Restreindre l’administration : interdisez les connexions d’administration depuis des postes non maîtrisés et appliquez un cloisonnement réseau strict autour des serveurs SharePoint.
• Renforcer la surveillance : augmentez temporairement la rétention et le niveau d’analyse des logs IIS, Windows, EDR et proxy.
• Contrôler les comptes de service : vérifiez leurs privilèges, leur rotation de secrets et leur périmètre d’accès.
• Mettre en place une chasse proactive : recherchez des artefacts de web shell, de scripts et de tâches planifiées inhabituelles.

Dans les environnements les plus sensibles, si le patch ne peut pas être appliqué dans des délais acceptables, il faut envisager des mesures plus fortes, y compris une restriction temporaire de service ou une désactivation partielle des accès externes. Cette décision relève d’un arbitrage métier, mais l’exploitation active confirmée par la CISA change le niveau d’acceptation du risque.

Pour les organisations qui disposent d’un WAF ou d’un reverse proxy applicatif, il peut être utile d’activer une journalisation plus verbeuse et des règles de détection adaptées aux comportements anormaux visant SharePoint. Cela ne garantit pas le blocage d’une exploitation, mais peut améliorer la visibilité et raccourcir le temps de détection.

Perspective écosystème et retour d’expérience

Ce type d’alerte illustre un schéma désormais classique : une faille critique est corrigée, mais l’effort de patching n’est pas homogène dans l’écosystème, puis les attaquants industrialisent l’exploitation contre les organisations les plus lentes à réagir. La valeur opérationnelle de l’annonce CISA est précisément de rappeler qu’une vulnérabilité patchée n’est pas une vulnérabilité résolue tant que le déploiement réel n’est pas confirmé partout.

Pour les équipes M365 et on-prem, la leçon est particulièrement importante. Les environnements hybrides créent souvent une illusion de modernisation généralisée, alors qu’une partie des services collaboratifs reste hébergée sur des serveurs internes ou externalisés à l’ancienne. SharePoint on-prem demeure un composant sensible, avec des contraintes de maintenance parfois plus lourdes que d’autres applications web. C’est précisément ce qui peut allonger les délais de correction.

La bonne pratique stratégique consiste à traiter les serveurs SharePoint exposés comme des actifs de priorité haute, au même titre qu’un VPN, une passerelle d’authentification ou un frontal de messagerie. Cela implique :

• un inventaire fiable ;
• des délais de patching contractualisés ;
• une supervision renforcée ;
• des exercices réguliers de revue de compromission ;
• une segmentation réseau adaptée ;
• une revue des privilèges des comptes techniques.

Les organisations françaises peuvent utilement surveiller les communications du CERT-FR lorsqu’un risque de campagne large ou d’exploitation active touche des composants fortement déployés en entreprise. Même lorsqu’aucune alerte nationale spécifique n’est encore publiée, la combinaison correctif disponible + exploitation active confirmée par la CISA suffit à justifier une mobilisation immédiate.

La source officielle à privilégier pour les actions techniques reste l’advisory Microsoft correspondant, complété par l’alerte de la CISA sur l’exploitation active. La reprise par BleepingComputer joue ici un rôle de diffusion et de contextualisation, mais la remédiation doit être pilotée à partir des références éditeur et des procédures internes de gestion de crise et de patching.

En pratique, la séquence la plus défendable est simple : identifier toutes les instances SharePoint, confirmer la version corrigée publiée par l’éditeur sur chaque nœud, rechercher des indices de compromission antérieure, puis durcir l’exposition et la supervision. Pour aller plus loin sur l’hygiène de durcissement, la réduction de surface d’attaque et l’organisation du patch management, voir aussi les ressources de la catégorie /categorie/pratiques.