En bref : la gestion des vulnérabilités dans les PME est un cycle léger et récurrent : connaître ses systèmes, suivre les alertes de façon ciblée, évaluer selon le risque, décider, mettre en œuvre et prouver. L'essentiel n'est pas d'avoir des outils coûteux, mais des responsabilités claires et une priorisation qui tient compte de l'accessibilité, des données et du contexte d'attaque. PHP2Shell est un bon exemple d'exercice, car toutes les étapes y apparaissent.
Des centaines d'alertes, peu de personnel
Chaque semaine, de nouvelles failles de sécurité sont publiées, dans les systèmes d'exploitation, les langages de programmation, les applications et les extensions. Un grand groupe dispose d'une équipe pour cela. Une PME a souvent un responsable informatique, un ou deux administrateurs et plusieurs prestataires externes. Personne ne peut lire chaque alerte, et ce n'est pas nécessaire.
Il faut un filtre : quelles alertes concernent nos systèmes, lesquelles sont urgentes et qui s'en occupe ? Sans ce filtre, l'une de ces deux choses se produit. Soit tout est ignoré jusqu'à ce qu'il arrive quelque chose, soit chaque alerte provoque l'agitation et la vraiment critique se noie dans le bruit.
Le cycle de la gestion des vulnérabilités
Un processus solide pour une PME se décrit en six étapes :
- Recenser ce qui tourne. Sans inventaire, pas de rapprochement possible. Quels sites, serveurs, versions de PHP et applications exploitez-vous, et où ? La manière d'y parvenir est expliquée dans Savoir ce qui tourne : l'inventaire de tous les sites et serveurs.
- Suivre les alertes. S'abonner à quelques sources fiables : les avertissements du BSI (office fédéral allemand de la sécurité des technologies de l'information), les alertes des éditeurs de vos logiciels, les pages de sécurité de votre distribution Linux, et pour PHP la page d'accueil de php.net.
- Évaluer. L'alerte nous concerne-t-elle ? Si oui, quelle est l'urgence ? Plus de détails ci-dessous.
- Décider. Corriger, sécuriser provisoirement, isoler le système ou assumer le risque en connaissance de cause. Qui a le droit de décider quoi ?
- Mettre en œuvre. Installer la mise à jour, appliquer une mesure transitoire, mandater un prestataire.
- Prouver et suivre. La faille est-elle vraiment fermée ? Quand la solution provisoire sera-t-elle remplacée ?
Le cycle recommence ensuite. De nouveaux systèmes s'ajoutent, d'anciens disparaissent et de nouvelles alertes paraissent.
Pour l'étape 2, une règle simple aide : mieux vaut lire régulièrement peu de sources que beaucoup de façon occasionnelle. Pour un environnement web de PME typique, les avertissements du CERT-Bund (le CERT du gouvernement allemand) auprès du BSI, les alertes de sécurité de la distribution Linux utilisée, les pages des éditeurs de CMS et de boutiques et la page d'accueil de php.net suffisent généralement. Définissez qui lit ces sources et mettez en place pour cela une boîte de réception commune ou un canal qui ne dépende pas d'une seule personne.
Un regard extérieur est un complément utile. Un scan de vulnérabilités régulier des systèmes accessibles publiquement montre si des logiciels obsolètes ou des services inutilement ouverts sont visibles. Il ne remplace ni l'inventaire ni les mises à jour, mais il révèle des systèmes qui ne figurent dans aucune liste.
Évaluer : ce qui passe en premier
Le score CVSS, une classification normalisée de la gravité, est un bon point de départ. Mais pour fixer l'ordre de traitement en interne, il ne suffit pas. Trois autres questions sont déterminantes :
| Question | Augmente l'urgence | Diminue l'urgence |
|---|---|---|
| Le système est-il joignable depuis Internet ? | site public, boutique, portail | uniquement en interne, derrière un VPN |
| Faut-il être authentifié pour exploiter la faille ? | non, sans authentification | oui, réservée aux administrateurs |
| Quelles données le système traite-t-il ? | données clients, paiements, accès | contenus publics sans comptes |
| Existe-t-il des rapports d'attaques ? | tentatives d'attaque signalées | aucune tentative connue |
| Existe-t-il une mesure transitoire ? | non | oui, avec efficacité démontrée |
PHP2Shell montre comment ces critères s'articulent. Les deux failles ont un score CVSS v4.0 de 9,2, permettent l'exécution de code sans authentification et touchent des serveurs web accessibles publiquement. Cloudflare et Patchstack ont fait état de tentatives d'attaque, selon les médias, et le BSI a classé la situation au niveau d'alerte 3. Les mesures transitoires de php.net n'offrent expressément aucune protection complète. Toutes les questions vont dans la même direction : agir immédiatement. Ce que le BSI a concrètement recommandé figure dans Ce que le BSI recommande pour PHP2Shell.
Décider et documenter
Toutes les failles ne peuvent pas être fermées sur-le-champ. Un ancien système tourne sous PHP 8.1, pour lequel il n'existe plus de mises à jour officielles (voir PHP 8.1 et antérieur : ce qui s'applique maintenant), une application métier ne supporte pas encore la mise à jour. Il faut alors une décision, et celle-ci ne relève pas uniquement de la technique.
Une bonne note de décision contient le système concerné, la faille, l'évaluation, l'option retenue, les mesures transitoires, la personne responsable et une date de nouvel examen. Si un risque est assumé en connaissance de cause, c'est la direction qui décide, pas l'administrateur seul. L'aide-mémoire OWASP sur la gestion des dépendances vulnérables recommande lui aussi d'ancrer expressément l'acceptation du risque au niveau de la direction.
Tenez une seule liste des vulnérabilités ouvertes, avec statut, responsable et échéance. Un tableau suffit. L'important est qu'elle soit relue régulièrement, par exemple lors de la réunion mensuelle avec la direction.
Ce que NIS2 et les prestataires ont à voir là-dedans
Pour les entreprises soumises à NIS2, le traitement des vulnérabilités fait partie des obligations de gestion des risques. Les détails sont décrits dans NIS2 et sécurité des serveurs web. Mais même sans obligation légale, un processus documenté est un atout, par exemple vis-à-vis des clients, des assureurs et de la propre direction.
De nombreuses étapes peuvent être externalisées, comme le suivi des alertes ou l'installation des mises à jour. En revanche, la décision sur les risques et la vue d'ensemble doivent rester en interne. Celui qui confie tout le cycle à un prestataire ne sait plus, le jour de la crise, quels systèmes il possède réellement. La manière d'organiser la mise en œuvre comme une routine est décrite dans Gestion des correctifs : un processus plutôt que les pompiers.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec vous l'inventaire de vos sites et serveurs, base de tout rapprochement.
- Nous suivons pour vos systèmes les alertes pertinentes et fournissons une évaluation en termes clairs, avec une recommandation.
- Nous préparons des notes de décision pour les cas où une mise à jour n'est pas possible immédiatement.
- Avec la surveillance de sécurité, nous vérifions en continu si des systèmes deviennent suspects tant qu'une faille reste ouverte.
Conclusion : la gestion des vulnérabilités dans les PME n'a pas besoin d'être lourde, mais elle doit être rigoureuse. Celui qui connaît ses systèmes, lit quelques bonnes sources et consigne ses décisions réagit vite et correctement à la prochaine alerte critique.
Questions fréquentes
Qu'est-ce que la gestion des vulnérabilités ?
Un processus récurrent par lequel une entreprise découvre les failles de sécurité de ses systèmes, les évalue, les corrige ou les accepte en connaissance de cause, et consigne le résultat. Il ne s'agit pas d'un outil, mais de responsabilités et de décisions.
Le score CVSS suffit-il pour établir les priorités ?
C'est un bon point de départ, mais cela ne suffit pas. Il faut aussi savoir si le système concerné est joignable depuis Internet, quelles données il traite et si des attaques ont déjà été observées. Une faille à score élevé sur un système de test interne peut attendre, pas celle de la boutique en ligne.
Une petite entreprise a-t-elle besoin d'un outil dédié ?
Pas au début. Une liste à jour des systèmes, des alertes de sécurité auxquelles on est abonné et un tableau des points ouverts suffisent. Les scanners de vulnérabilités deviennent utiles lorsque le nombre de systèmes augmente ou que des contrôles réguliers doivent être documentés.
Peut-on décider délibérément de ne pas corriger une faille ?
Oui, si le risque a été évalué, si la décision est prise par la direction compétente et consignée par écrit, idéalement avec des mesures transitoires et une date de nouvel examen.