NOUS CONTACTER
[INDISEC #02] Indicateurs – Patch Management

Préambule

La série #INDISEC est un ensemble d’articles dédiés à la production d’indicateurs SSI.  Ce chapitre traite des éléments à surveiller dans le processus de patch management.

Le chapitre final se verra agrémenté d’un tableau de bord au format Excel, formalisant tous les points étudiés dans la série. Vous pourrez l’exploiter tout de suite !

Objectifs

Nous nous sommes penchés sur quelques indicateurs clés que nous considérons comme incontournables pour un(e) RSSI, un(e) correspondant(e) sécurité ou toute personne travaillant dans la sécurité opérationnelle. Que vous soyez déjà outillé(e) en tableaux de bords – parfois contraints par le groupe ou une autorité de contrôle – ou que vous partiez d’une feuille blanche, voici quelques retours d’expérience que nous souhaitions vous partager.

Chapitre 2 : Indicateurs liés à la gestion des correctifs de sécurité

Le patch, une question d’hygiène, mais pas que.

Attaquons-nous à un sujet fondamental de la sécurité des systèmes d’information : le patch management. Il est dérisoire aujourd’hui de s’atteler à renforcer la sécurité d’un système ou d’une application si les briques constitutives dudit système ne sont pas fiables. Cette fiabilité passe notamment à travers une bonne hygiène informatique, dans laquelle nous allons étudier une brique majeure : la gestion des correctifs de sécurité.

Note : la notion de patch management inclut les correctifs de sécurité mais aussi des évolutions fonctionnelles. Nous mélangerons ici les deux notions par facilité de langage, nous concentrant principalement sur les aspects sécurité.

Quels sont les risques associés ?

Ne pas patcher ses machines, c’est s’exposer à de graves dangers. Le niveau de ces risques est bien entendu dépendant du domaine d’activité de votre activité métier et votre dépendance fonctionnelle à l’IT.

Toutefois, rares sont les entreprises qui peuvent assurer leur activité sans l’outil informatique et à ce titre, une lacune dans la manière de gérer l’application des correctifs de sécurité induit des risques de niveaux élevés touchants à la disponibilité, l’intégrité et la confidentialité de leur patrimoine informationnel.

Rappelons-nous des conséquences pour les entreprises ayant subi les attaques de WannaCry, Not Petya ou plus récemment l’exploitation de la vulnérabilité critique de Log4J pour ne citer qu’elles. Dans tous les cas de figure, l’exploitation d’une faille de sécurité au travers de l’exécution d’une macro par un utilisateur non averti, par une application ou un système non mis à jour, les conséquences sont de natures certes multiples, mais l’impact lui est très certainement élevé. !

A noter enfin qu’indépendamment de votre secteur d’activité, les lacunes en matière de patch management peuvent vous mettre en risque vis-à-vis de la réglementation européenne et/ou française (RGPD, DORA, LPM, NIS…).

Source : Panorama de la Cybermenace, 2022 – https://www.cert.ssi.gouv.fr/uploads/CERTFR-2023-CTI-001.pdf

 Ce qu’il faut faire

Le patch management consiste à mettre à jour les systèmes et les applicatifs afin de s’assurer que ces derniers soient exempts de vulnérabilités connues.

Catégoriser

Doit-on appliquer tous les correctifs de sécurité ? A priori oui, mais pas de la même manière en fonction de la criticité des vulnérabilités, de l’exposition du système ou de l’application, de la complexité de mise à jour (adhérences applicatives), etc.

Pour gagner en efficacité, il faut :

  • Catégoriser ses applicatifs et ses socles techniques (postes de travail, serveurs de production exposés Internet, serveurs de préproduction, backoffice …) ;
    • Effectuer le cas échéant des sous catégories : certains serveurs de production sont plus critiques que d’autres au regard notamment de leurs besoins en disponibilité : on se permettra de passer plus rapidement certains patchs sur des machines moins critiques.
  • Définir des objectifs d’application des correctifs en fonction de la criticité des vulnérabilités.

Ordonnancer l’application des correctifs

Les vulnérabilités les plus critiques doivent faire l’objet d’une correction rapide, les vulnérabilités de criticité moyenne doivent suivre un processus de qualification avant déploiement. Enfin, dans certains cas, les vulnérabilités de criticité faible peuvent être déployées plus tardivement ou faire l’objet de dérogations et ne pas être corrigées.

Vous devrez définir des délais et vous y conformer !

Exemple :

  • Critiques : quelques heures ou jours
  • Moyennes : quelques jours ou semaines
  • Faible : quelques semaines/mois

Cet exemple est donné à titre indicatif et ce sera à vous de définir précisément ces durées, si ce n’est déjà fait dans une politique associée.

Cas de l’obsolescence des socles techniques

Pour finir, il est nécessaire d’identifier et d’anticiper l’obsolescence des socles techniques. En effet, les OS ou les applications trop anciennes ne sont plus maintenus par les éditeurs, et très souvent les correctifs de sécurité ne sont plus proposés. Toutefois les vulnérabilités de ces socles sont toujours publiées et peuvent par conséquent être exploitées pour compromettre votre système d’information.

vieux ordinateurs

Quels indicateurs pour le patch management ?

Afin de mesurer l’efficacité du processus de patch management, il s’agit dans un premier de temps de définir des indicateurs quantitatifs permettant le suivi des vulnérabilités corrigées :

  • % de vulnérabilités hautes et critiques corrigées (il va de soit que l’objectif est de 100%)
  • % de vulnérabilités moyennes et basses corrigées :
    • Sur les systèmes exposés à des réseaux externes (Internet, partenaires, clients …) ;
    • Sur les systèmes backoffice ;
    • Sur les postes de travail ;
    • Sur tout autre périmètre pertinente pour vous !

Note : l’objectif de %, appelé seuil, sera à définir en fonction des catégories de systèmes et votre analyse de risques.

Il conviendra également de construire des indicateurs permettant de s’assurer que les objectifs du processus de patch mangement  sont atteints :

  • Ecart de durée d’application des correctifs par rapport aux objectifs du processus de patch management. Cet indicateur permet de mesurer l’efficacité du processus et/ou son adéquation avec les contraintes opérationnelles de l’entreprise.
  • Liste des socles obsolètes (l’objectif est de ne pas en avoir, dans tous les cas de voir leur quantité à la baisse)
  • Liste des socles arrivant en fin de support éditeur. Cet indicateur doit permettre d’anticiper les travaux de mise à jour ou de changement des socles systèmes et applicatifs.

Exemple

Indicateur Patch Management

Exemple de tableau de bord avec un relevé de déploiement de patchs via WSUS : il s’agira de faire attention au nombre total de machines. En effet, plus le nombre est faible, plus les écarts peuvent être importants en termes de pourcentage !

Note importante :  sur certains applicatifs type WSUS il sera important de distinguer pour chaque patchs :

  • Ceux qui se sont déployés sans problèmes : c’est le résultat souhaité ;
  • Ceux qui attendent un démarrage de la machine : il s’agira de catégoriser correctement pour éviter des redémarrages non souhaités (serveurs de production) ;
  • Ceux qui n’ont pas réussi à se déployer (échec) : il sera certainement nécessaire de mener des investigations supplémentaires ou des interventions de proximité ;
  • Ceux qui sont en attente de déploiement  : il s’agira de comprendre pourquoi la mise à jour n’a pas débuté.

En résumé

Le patch management est un processus clé d’une bonne hygiène sécurité du système d’information. Il doit toutefois s’appuyer sur d’autres processus pour fonctionner de manière efficiente, notamment sur la gestion des actifs, la veille sécurité, la gestion des risques, la gestion des changements, la veille juridique.
Même si vous avez une gestion des correctifs de sécurité efficace, il est recommandé de mettre en œuvre des outils de détection et de réaction des logiciels malveillants (virus, vers …) sur vos serveurs, vos stockages de données et vos liens réseau. En effet, ces derniers peuvent détecter l’exploitation de vulnérabilité pour lesquelles les éditeurs ne proposent pas de solution corrective à l’heure de l’attaque.

Fin du chapitre mais pas de la série !

Notre dossier sur les indicateurs SSI n’est pas terminé, retrouvez nos autres conseils dans nos billets de blogs (L’actualité de Kedros cybersécurité).

Cette série fera l’objet d’un modèle de tableau de bord, livré au dernier épisode !

Suivez nous si vous voulez connaitre la suite !