Comment gérer les incidents dans le SMSI ?
PHP2Shell : qui décide dans votre SMSI quand une faille critique tombe ?
Résumé
PHP2Shell n’est pas d’abord un problème technique. C’est un test de votre SMSI. Deux failles PHP, CVE-2026-109618 et CVE-2026-109619, notées 9.2, permettent d’exécuter du code à distance sans authentification. Les correctifs sont sortis le 21 octobre 2026. Une tentative d’exploitation avait été vue dès le 17.
La règle : la DSI corrige, le RSSI qualifie, la direction décide. Tout ce qui ne sera pas corrigé à temps est un risque que quelqu’un doit accepter, par écrit.
Si vos critères existaient avant la faille, vous déroulez. Sinon, vous improvisez, et l’auditeur le verra.
Les 6 décisions qu’une faille critique impose
| Décision | Qui décide | Preuve attendue par l’auditeur |
|---|---|---|
| Qualifier la faille comme critique pour l’organisme | Le RSSI, à partir de la veille | Fiche de veille datée, critères de criticité écrits dans la politique (5.7) |
| Mobiliser des ressources hors planning | La direction | Arbitrage écrit : astreinte, prestataire, budget (5.1, 7.1) |
| Laisser un serveur non corrigé dans le délai | Le propriétaire du risque, validé par la direction | Acceptation du risque résiduel dans le PTR (6.1.3) |
| Exiger une réponse des fournisseurs | Le RSSI ou les achats, mandatés par la direction | Demandes et réponses écrites, clauses contractuelles (5.19 à 5.22) |
| Qualifier en incident et notifier | La direction, sur avis du RSSI | Registre des incidents, décision de notification NIS2 |
| Tirer les leçons | La direction, en revue | Compte-rendu de revue de direction, actions suivies (9.3, 10.2) |
Les 3 erreurs terrain
1. « C’est un sujet pour la DSI. »
En audit, on entend souvent que la faille a été « gérée par l’IT ». La veille (5.7) a fait son travail, la remontée non. La direction n’a rien vu passer. Or la norme place la direction en responsable du SMSI (5.1), et NIS2 la rend comptable des mesures de gestion des risques (article 20). On délègue la correction. On ne délègue pas la décision sur le risque qui reste. Une direction qui découvre la faille dans le rapport d’audit n’a pas gouverné, elle a été informée.
2. « On n’avait pas de procédure, on a fait au mieux. »
Ce qu’on voit souvent : une équipe réactive, des serveurs corrigés en trois jours, et aucun document qui dise si trois jours, c’était bien. C’est une mauvaise lecture de la norme. Vos critères d’acceptation des risques doivent exister avant l’événement (6.1.2), et votre gestion des vulnérabilités doit fixer des délais de traitement (8.8). Sans délai écrit, impossible de dire si vous étiez en retard. Fixez-le dans la politique et faites-le valider par la direction. Un délai fixé après la crise n’est pas un délai.
3. « L’hébergeur nous a dit que c’était fait. »
Un appel, une réponse rassurante, et le sujet est clos. C’est une idée reçue de croire que ça suffit. Vos fournisseurs restent dans votre périmètre de risques (5.19 à 5.22). Il vous faut une réponse écrite, avec la version de PHP et la date de correction. Et au prochain renouvellement, inscrivez dans le contrat un délai de correction des failles critiques et une obligation de vous prévenir. NIS2 vous demandera de toute façon de maîtriser votre chaîne d’approvisionnement.
Comment trancher en pratique ?
- Ma politique fixe-t-elle un délai de correction pour une faille critique exposée sur Internet ?
Si non, la direction le fixe aujourd’hui, par écrit. Si oui, on l’applique et on mesure l’écart. - Puis-je corriger tous les serveurs touchés dans ce délai ?
Si oui, on trace et on ferme. Si non, le propriétaire du risque propose isolement ou acceptation, et la direction signe. - Mes fournisseurs qui hébergent du PHP ont-ils répondu par écrit ?
Si non, relance formelle et risque inscrit au registre fournisseurs. Si oui, on archive la réponse. - Ai-je trouvé des traces d’exploitation depuis le 17 octobre ?
Si oui, c’est un incident, et la direction décide de la notification. Si non, c’est une vulnérabilité traitée. - Suis-je entité essentielle ou importante au sens de NIS2 ?
Si oui, la direction doit pouvoir prouver qu’elle a été informée et qu’elle a validé. Si non, la preuve reste attendue par l’auditeur 27001.
Quoi retenir ?
L’auditeur ne lira pas vos tickets de correction en premier. Il lira les décisions : qui a qualifié, qui a arbitré, qui a accepté le risque restant. Ce qui le rassure, c’est une signature de la direction sur chaque serveur qu’on n’a pas pu corriger. Poser ces règles avant la prochaine faille, c’est le travail d’un Lead Implementer ISO 27001. Une faille sans décision est une faille de gouvernance.
FAQ
Le RSSI peut-il accepter seul le risque d’un serveur PHP non corrigé après PHP2Shell ?
Non. L’acceptation des risques résiduels revient aux propriétaires des risques (6.1.3), et la direction l’assume.
PHP2Shell doit-elle être présentée en revue de direction ?
Oui. Elle entre dans les changements d’enjeux externes et dans les résultats de traitement des risques que la revue doit examiner (9.3).
La norme 27001 impose-t-elle un délai pour corriger une faille critique comme PHP2Shell ?
Non. C’est à vous de le fixer dans votre politique, puis de prouver que vous le tenez, en mettant à jour votre analyse de risques.
Faut-il notifier PHP2Shell au titre de NIS2 ?
Non, pas la vulnérabilité seule. La notification ne se pose que si une exploitation provoque un incident important : alerte précoce sous 24 h, notification sous 72 h.
Sources des faits techniques : Help Net Security, SecurityWeek, watchTowr FAQ. Les faits sur la faille évoluent encore.
Prêt à aller plus loin ?
Découvrez notre formation certifiante ISO 27001 Lead Implementer pour maîtriser la mise en place d'un SMSI de bout en bout et préparer sereinement votre certification.
💡 Soutenez notre travail et restez à la pointe !
Les moteurs de recherche évoluent avec l'IA. Pour être certain(e) de toujours retrouver nos recommandations d'experts en priorité dans vos recherches, définissez-nous comme Source de Confiance.
En un clic, c'est une action rapide qui nous aide énormément à nous faire connaître ! Et si cette ressource vous a été utile, n'hésitez pas à la partager autour de vous pour faire grandir la communauté.
Ajouter comme source préférée