En bref : ISO 27001 et TISAX touchent les serveurs web surtout par trois exigences : les vulnérabilités doivent être détectées et traitées, les prestataires tels que les hébergeurs et les agences doivent être pilotés, et les incidents de sécurité nécessitent une procédure réglée. Une situation comme PHP2Shell est un test pratique pour tout SMSI. Celui qui documente de façon traçable l'évaluation, le correctif et le redémarrage dispose d'une bonne base pour le prochain audit. Un certificat ou un label ne remplace pas le correctif.
Ce que sont ISO 27001 et TISAX, en deux paragraphes
ISO/IEC 27001 décrit les exigences d'un système de management de la sécurité de l'information, en abrégé SMSI. Il s'agit d'un cycle ordonné : évaluer les risques, définir des mesures, les mettre en œuvre, contrôler et améliorer. L'édition actuelle de 2022 contient dans son annexe A un catalogue de 93 mesures en quatre thèmes. Lesquelles s'appliquent, l'entreprise le décide sur la base de son évaluation des risques et le consigne dans la déclaration d'applicabilité.
TISAX est le mécanisme d'évaluation et d'échange répandu dans l'industrie automobile. Il est piloté par l'ENX Association ; sa base est le catalogue d'exigences ISA, que l'ENX maintient et que le VDA publie. Des prestataires d'audit indépendants réalisent une évaluation dont l'étendue dépend du besoin de protection et va de contrôles documentaires à des visites sur site. Selon l'ENX, les résultats sont attribués sous forme de labels, valables trois ans, et ne sont partagés via le portail ENX qu'avec des partenaires choisis.
ISO 27001 sur le serveur web : quelles exigences s'appliquent ?
Dans le SMSI, un serveur web est rarement un chapitre à part. Il apparaît à plusieurs endroits, et c'est précisément là que naissent les lacunes. L'aperçu suivant classe de façon générale les principaux thèmes. Il ne remplace pas un regard sur votre propre déclaration d'applicabilité.
| Thème dans le SMSI | Ce que cela signifie pour le serveur web | Preuve utile à l'audit |
|---|---|---|
| Inventaire des actifs | Chaque site, chaque serveur, chaque version de PHP est recensé | Liste à jour avec exploitant, version, responsable |
| Gestion des vulnérabilités techniques | Des alertes comme PHP2Shell sont évaluées et traitées | Ticket avec évaluation, décision, date du correctif |
| Relations avec les fournisseurs | L'hébergeur et l'agence ont des obligations de sécurité claires | Contrat, répartition des tâches, confirmation écrite de l'état des correctifs |
| Journalisation et surveillance | Les journaux du serveur web sont conservés et analysés | Règle de conservation, exemple d'analyse |
| Gestion des incidents | Un soupçon est signalé, évalué et clos | Registre des incidents, retour d'expérience |
| Gestion de la configuration | Les paramètres de PHP et du serveur web sont définis | Configuration cible et contrôle des écarts |
Avec TISAX, des thèmes comparables s'appliquent, car le catalogue ISA est harmonisé avec d'autres normes importantes. En outre, certains objectifs d'évaluation, par exemple la protection des prototypes, exigent un soin particulier pour les systèmes par lesquels des partenaires échangent des données. Il peut aussi s'agir de portails basés sur PHP.
PHP2Shell comme test pratique du SMSI
Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles. Un SMSI qui fonctionne devrait, dans cette situation, déclencher une chaîne que l'on pourra prouver plus tard.
- Réception : qui a reçu l'alerte, quand, et où est-elle enregistrée ?
- Évaluation : quels systèmes sont concernés ? Cela suppose un inventaire à jour, voir Savoir ce qui tourne.
- Décision : correctif, mesure transitoire ou mise hors ligne temporaire, avec justification et nom de la personne qui décide.
- Mise en œuvre : état du paquet, redémarrage de tous les processus PHP, contrôle. Pour les rétroportages de la distribution, c'est le journal des modifications du paquet qui compte, pas le numéro de version affiché ; comment le prouver est montré dans Vérifier correctement la version de PHP et l'état des correctifs.
- Fournisseurs : confirmation écrite de l'hébergeur que le correctif a été installé et le redémarrage effectué.
- Contrôle ultérieur : recherche de signes de compromission depuis le 17/10/2026, car un correctif n'annule pas les intrusions antérieures.
La manière de transformer cette chaîne ponctuelle en procédure durable est décrite dans La gestion des vulnérabilités dans les PME et La gestion des correctifs comme processus.
Faiblesses fréquentes de la documentation
En pratique, la preuve échoue rarement pour des raisons techniques, mais à cause de lacunes dans la chaîne. Typique : un site qu'un service métier exploite avec une agence et qui manque à l'inventaire. Tout aussi fréquents : des contrats d'hébergement sans indication sur la rapidité d'installation des mises à jour de sécurité et sur l'information éventuelle des clients.
Un autre classique : le ticket de correctif est clos, mais personne n'a redémarré les processus PHP. Formellement, le point est réglé, techniquement l'ancien code continue de tourner. Une bonne preuve contient donc non seulement « mise à jour installée », mais aussi le redémarrage et un contrôle ensuite.
Cela devient aussi difficile pour les systèmes qu'on ne peut pas corriger immédiatement, par exemple une application sous PHP 8.1. Un SMSI n'exige pas de miracles ici, mais une décision délibérée : quelles mesures transitoires s'appliquent, qui a accepté le risque résiduel et pour quand la migration est-elle prévue ? Une acceptation écrite du risque avec date d'expiration vaut bien mieux, lors d'un audit, qu'un ancien système qui continue de tourner en silence. Les journaux sont tout aussi importants. Après PHP2Shell, la presse spécialisée et des auteurs spécialisés ont conseillé de conserver les journaux du serveur à partir du 20/10/2026. Il faut avoir clarifié avant le prochain incident, et non pendant, si votre règle de conservation le permet et si les journaux se trouvent chez l'hébergeur ou chez vous.
Si votre entreprise relève en outre de NIS2, ces exigences se renforcent. Les grandes lignes figurent dans NIS2 et sécurité des serveurs web. Il s'agit d'une information générale, pas d'un conseil juridique.
Un certificat ou un label décrit l'état d'un système de management au moment de l'audit. Il ne protège aucun serveur individuel contre une nouvelle faille. L'essentiel est que la procédure fonctionne réellement en situation de crise.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons vos serveurs web et installations PHP de façon à ce qu'ils s'intègrent à l'inventaire de votre SMSI.
- Nous appliquons les correctifs et documentons avec notre service de correctifs PHP : état du paquet, redémarrage, contrôle, avec dates et justificatifs.
- Nous formulons les questions à l'hébergeur et aux agences et évaluons leurs réponses pour votre gestion des fournisseurs.
- Nous fournissons à votre responsable SMSI les faits techniques. L'évaluation dans le système de management et l'audit restent de votre côté et de celui de votre organisme d'évaluation.
Conclusion
ISO 27001 et TISAX n'exigent pas un serveur web précis, mais une gestion traçable de celui-ci. PHP2Shell montre si l'inventaire, le traitement des vulnérabilités et le pilotage des fournisseurs fonctionnent ensemble. Celui qui prouve proprement la chaîne réception, évaluation, correctif, redémarrage et contrôle ultérieur n'a pas seulement l'audit, mais surtout son serveur bien en main.
Questions fréquentes
Le site web de l'entreprise relève-t-il du périmètre d'une ISO 27001 ?
Cela dépend de la façon dont votre entreprise a défini le périmètre. Si le site traite des données clients, est relié à des systèmes internes ou est exploité par un prestataire, tout plaide pour l'inclure ou au moins pour le saisir via la gestion des fournisseurs.
TISAX est-il un certificat ?
L'ENX Association parle d'une évaluation par des prestataires d'audit indépendants, dont les résultats sont attribués sous forme de labels TISAX. Selon l'ENX, les labels sont valables trois ans et sont partagés de manière ciblée avec des partenaires via le portail ENX ; ils ne sont pas publics.
Dois-je informer mon auditrice après PHP2Shell ?
Il n'existe pas d'obligation générale à cet égard. Votre SMSI devrait toutefois documenter la manière dont vous avez évalué et traité la vulnérabilité. Ces documents sont typiquement examinés lors du prochain audit.
Quelle version de l'ISO 27001 est actuelle ?
La référence est l'édition ISO/IEC 27001:2022. Son annexe A classe les mesures en quatre thèmes : organisationnel, lié aux personnes, physique et technologique.