Organigramme du processus de gestion des vulnérabilités (analyse jusqu'à la…

Modèle de diagramme de gestion des vulnérabilités : étendue et couverture de l'analyse, analyses authentifiées, triage et faux positifs, CVSS et évaluation des exploits, bandes SLA, vérification de nouvelle analyse, exceptions et…

Utiliser ce modèle

Qu'est-ce que le processus organigramme du processus de gestion des vulnérabilités (analyse jusqu'à la… ?

La gestion des vulnérabilités est le cycle opérationnel récurrent qui détecte les faiblesses connues dans un domaine, décide lesquelles d'entre elles sont importantes, les corrige et le prouve. Le déclencheur est un calendrier plutôt qu'un événement : une fenêtre d'analyse s'ouvre sur l'inventaire des actifs, et tout en aval dépend de l'exactitude de cet inventaire. Le graphique ci-dessous suit un cycle de bout en bout. La portée de l'analyse et la couverture des informations d'identification sont convenues avant que quoi que ce soit ne soit analysé, l'analyse authentifiée s'exécute, les avis du fournisseur arrivent avec la sortie du scanner, les résultats sont dédupliqués et confirmés, une évaluation combine la gravité avec l'exploitabilité et ce que l'actif contient réellement, une date limite et un propriétaire nommé sont attachés, une modification comporte le correctif, une nouvelle analyse ferme la découverte ou la rouvre, et le registre et les métriques sont ce que la direction examine avant l'ouverture de la fenêtre suivante.

C'est le programme, pas la solution. Ce qu'un propriétaire de système fait dans un seul ticket - valider les résultats par rapport à sa propre version, choisir entre un correctif, une mise à niveau, une modification de configuration et une mise hors service, le tester et le déployer - est le processus de correction des vulnérabilités, et il est suspendu à l'étape unique « Appliquer le correctif, la configuration ou le contrôle compensatoire » dessinée ici. Le correctif du fournisseur lui-même, avec son évaluation de l'applicabilité, ses tests hors production, son déploiement en anneau et sa restauration, constitue la gestion des correctifs, un cycle distinct que celui-ci consomme plutôt qu'il ne contient. Et le flux de travail complet des exceptions de sécurité (justification commerciale, contrôles compensatoires, niveau d'approbation qui suit l'évaluation du risque, une entrée dans le registre et un examen de renouvellement) se trouve derrière l'option « Exception approuvée avec une date d'expiration ? » décision plutôt qu’à l’intérieur d’elle. Garder ces limites visibles est ce qui empêche un graphique d’essayer d’en avoir trois. Considérez ce qui suit comme un point de départ à adapter en fonction de votre propre politique de sécurité, de vos obligations réglementaires et du jugement d'un praticien de la sécurité compétent.

Quatre décisions portent le processus. « Tous les actifs concernés peuvent être analysés ? » vient en premier parce que les échecs de couverture sont invisibles : un actif non analysé ne produit aucun résultat, et un tableau de bord propre et un domaine non analysé semblent identiques à ceux du rapport. « Exploitation connue ou gravité critique ? » C'est la répartition des priorités, et elle se situe dans la voie de l'analyste parce que les preuves d'exploitation leur appartiennent, tandis que la piste d'urgence qu'elle ouvre appartient à la direction de la sécurité, qui détient le pouvoir d'interrompre d'autres travaux. « Réparable dans le cadre du SLA ? » se situe délibérément dans la voie du propriétaire du système/des opérations informatiques plutôt que dans celle de l'analyste — la personne qui doit effectuer le changement est celle qui sait si la fenêtre existe — et sa branche négative conduit à une décision d'exception appartenant à la direction de la sécurité, car l'acceptation du risque est un acte de gestion plutôt qu'un acte d'ingénierie. « Une nouvelle analyse montre que les résultats sont fermés ? » remet le processus à l'analyste, de sorte que la clôture repose sur des preuves plutôt que sur quelqu'un qui marque un ticket comme étant terminé.

Ce que couvre cet organigramme

Dans ce modèle

  • Cinq couloirs (analyste de vulnérabilité, propriétaire du système/opérations informatiques, gestionnaire du changement, gestion de la sécurité et fournisseur) répartis en six phases : portée et découverte, analyse et réception, tri, priorisation et affectation, correction et vérification, rapport et examen.
  • Une porte de couverture avant toute analyse : « Tous les actifs concernés peuvent-ils être analysés ? » renvoie les informations d'identification manquantes et les agents non déployés pour correction, car un actif que le scanner ne peut pas authentifier ne rapporte presque rien et est toujours considéré comme analysé
  • Deux routes d'admission dans une seule file d'attente : la propre sortie du scanner et un avis du fournisseur arrivant à l'étape "Publier l'avis et la version corrigée", de sorte que quelque chose annoncé entre les fenêtres d'analyse ne reste pas sans propriétaire jusqu'au cycle suivant.
  • Une paire de triage, la plupart des graphiques se regroupent dans une seule case : « Recherche confirmée sur l'actif ? » achemine les résultats non confirmés vers « Supprimer comme faux positif avec preuve », un terminal fermé qui exige toujours une raison, une expiration et un approbateur
  • Notation et date limite en tant qu'actes distincts : « Score par CVSS, exploitabilité et valeur de l'actif » produit la notation « Exploité connue ou gravité critique ? » sépare le travail d'urgence du groupe de routine, et ce n'est qu'à ce moment-là qu'un propriétaire de réparation est nommé et responsable
  • Clôture sur preuve, avec deux boucles et une évasion : « Rescan montre que le résultat est fermé ? » rouvre tout ce qui est encore présent, « Réparable dans le cadre du SLA ? » conduit à « Exception approuvée avec une date d'expiration ? » et les résultats en retard s'intensifient avant que les mesures ne soient publiées.

Quand utiliser ce modèle

  • Vous écrivez ou réécrivez une norme de gestion des vulnérabilités et avez besoin d'une idée de qui analyse, qui évalue, qui corrige et qui accepte le risque résiduel.
  • Les résultats vieillissent au-delà de leurs délais et personne ne peut dire s'ils bloquent au triage, à l'affectation, à la fenêtre de changement ou à la nouvelle analyse.
  • Vous sélectionnez ou remplacez un scanner et souhaitez que le processus soit convenu avant la configuration des politiques d'analyse, des magasins d'informations d'identification, des groupes d'actifs et des bandes SLA.
  • Les opérations de sécurité et informatiques ne sont pas d'accord sur ce qui est considéré comme corrigé. La nouvelle analyse, l'itinéraire d'exception et le chemin d'escalade doivent donc être explicites et détenus.
  • Un auditeur ou un questionnaire de sécurité client a demandé une description documentée de la manière dont les vulnérabilités sont identifiées, évaluées, corrigées et vérifiées.

Comment cela fonctionne

  1. Renommez les voies selon vos rôles

    Remplacez l'analyste de vulnérabilité, le propriétaire du système/opérations informatiques, le gestionnaire des changements, la gestion de la sécurité et le fournisseur par les rôles que vous avez réellement. Dans une petite équipe, l'analyste et le propriétaire du système sont souvent la même personne. Fusionnez donc ces voies plutôt que de procéder à un transfert qui n'existe que sur papier. Même dans ce cas, gardez la gestion de la sécurité séparée, car les branches d'exception et d'escalade ont besoin d'une autorité qui n'est pas également celle qui répare.

  2. Écrivez votre étendue d'analyse et votre règle de couverture

    Indiquez quels actifs sont concernés, comment ils y parviennent à partir de l'inventaire ou de la CMDB, lesquels sont analysés avec des informations d'identification ou un agent et lesquels ne le sont pas, et à quelle fréquence chaque groupe est analysé. Notez les exclusions et qui peut en accorder une. La couverture est le nombre qui donne une signification à tous les autres nombres du programme, alors mettez-le sur le graphique plutôt que de le laisser dans un paramètre d'outil que personne ne lit.

  3. Définir la manière dont un résultat est noté

    Dites quelle échelle de gravité vous utilisez et d’où vient le score, puis dites ce que vous y ajoutez. Un score de gravité décrit l'impact technique ; les preuves d'exploitation et le contexte des actifs décrivent à quel point vous devriez vous en soucier cette semaine. Notez la combinaison que vous utilisez réellement, nommez ses entrées et enregistrez qui peut annuler une note et sur quelles preuves repose cette dérogation.

  4. Réglez les bandes SLA et démarrez l'horloge

    Inscrivez vos propres délais de remédiation sur le graphique et supprimez les espaces réservés. Convenez de chaque bande avec les propriétaires qui doivent la respecter et soyez explicite sur le début de l'horloge, car la date de détection, la date du ticket et la date de publication du fournisseur produisent des rapports de vieillissement très différents pour le même domaine. Indiquez ce que signifie la voie d'urgence dans la pratique et qui peut l'ouvrir.

  5. Accepter l'itinéraire d'exception et de remontée d'informations

    Décidez qui peut approuver une exception, quelles preuves l'accompagnent, la durée de vie la plus longue qu'elle peut avoir et quel contrôle compensatoire doit être exercé pendant qu'elle le fait. Ensuite, acceptez l'escalade pour tout retard sans exception : à qui est-il informé, à quel âge et que se passe-t-il si rien ne change après cela. Les deux itinéraires nécessitent une personne nommée plutôt qu’une boîte aux lettres partagée.

  6. Décider de ce qui prouve qu'une conclusion est close

    La clôture doit reposer sur une nouvelle analyse de l’actif concerné, et non sur un ticket marqué comme terminé. Notez quelle analyse le prouve, combien de temps elle s'exécute après un correctif et ce qui se passe lorsque la nouvelle analyse signale toujours le résultat. Enregistrez si un contrôle compensatoire clôture un résultat ou seulement le réduit, car ces deux conventions produisent des registres et des métriques très différents.

  7. Marchez contre une vraie découverte

    Prenez deux résultats du dernier cycle, un qui s'est terminé à temps et un qui est en retard ou s'est terminé à titre exceptionnel, et tracez les deux dans le graphique. Toute étape décrite par les gens qui n'est pas dessinée, et toute étape dessinée qui est discrètement ignorée dans la pratique, est une découverte qui mérite d'être prise en compte avant de publier le processus à quelqu'un d'autre.

Questions fréquentes

Quelles sont les étapes d’un processus de gestion des vulnérabilités ?

Un cycle d'analyse s'ouvre sur l'inventaire des actifs, et la portée et la couverture des informations d'identification sont définies avant que quoi que ce soit ne soit exécuté ; les actifs que le scanner ne peut pas atteindre sont corrigés et revérifiés. L'analyse authentifiée planifiée s'exécute et les avis des fournisseurs arrivant entre les analyses rejoignent la même file d'attente. Les résultats sont dédupliqués et enrichis de données d'exploitation, puis confirmés par rapport à l'actif, tout ce qui n'est pas confirmé étant supprimé comme faux positif avec ses preuves. Les résultats confirmés sont notés en fonction de la gravité, de l'exploitabilité et de la valeur de l'actif, acheminés vers une piste d'urgence ou une plage de délais standard, et attribués à un propriétaire de correctif nommé. Le propriétaire soit corrige dans le délai, via une fenêtre de modification si nécessaire, soit demande une exception avec une date d'expiration. Une nouvelle analyse confirme la fermeture ou rouvre le travail. Enfin, le registre est mis à jour, les constatations en retard sont remontées, les mesures de couverture, de vieillissement et de fermeture sont publiées et la direction examine la tendance avant le cycle suivant.

Quelle est la différence entre la gestion des vulnérabilités et la gestion des correctifs ?

La gestion des vulnérabilités est le cycle qui découvre les faiblesses d'un domaine, les évalue et les conduit à une clôture vérifiée, quel que soit le traitement qui s'avère être. La gestion des correctifs est l'un de ces traitements : le cycle opérationnel qui prend une version d'un fournisseur, évalue si elle s'applique, la teste, la planifie et la déploie. Les conseils du NIST sur la planification de la gestion des correctifs d'entreprise (SP 800-40 Révision 4) font le même point dans l'autre sens, présentant les correctifs comme une maintenance préventive et comme l'un des nombreux moyens de répondre au risque créé par une vulnérabilité logicielle. La conséquence pratique est qu'un programme de vulnérabilité mesuré uniquement par les correctifs installés sera sous-estimé, car les modifications de configuration, les mises à niveau, la mise hors service et les contrôles compensatoires sont également tous des résultats proches, et certains résultats n'ont aucun correctif à installer.

Un score CVSS est-il suffisant pour prioriser la remédiation ?

CVSS, maintenu par FIRST, obtient un score de gravité technique de 0,0 à 10,0, et ses bandes qualitatives dans la version 3.1 sont faibles de 0,1 à 3,9, moyennes de 4,0 à 6,9, élevées de 7,0 à 8,9 et critiques de 9,0 à 10,0. La version 4.0, publiée en 2023, conserve un score de base et ajoute des groupes de métriques explicites de menace et d'environnement. Ce que CVSS ne vous dit délibérément pas, c'est la probabilité d'une exploitation ou l'importance d'un actif donné pour vous. Les équipes ajoutent généralement deux autres signaux : un score de probabilité d'exploitation tel que l'EPSS, également de FIRST, qui estime la probabilité qu'une vulnérabilité soit exploitée dans la nature au cours des trente prochains jours et est recalculé quotidiennement, et des preuves d'exploitation réelle telles que le catalogue de vulnérabilités exploitées connues de CISA. Le contexte de l'actif est la troisième entrée et il n'appartient qu'à vous. C'est la raison pour laquelle ce graphique obtient un score, puis s'oriente vers la catégorie « Gravité connue ou critique ? » plutôt que de trier une liste par score.

À quelle fréquence les analyses de vulnérabilité doivent-elles être exécutées et à qui appartient le processus ?

Les cadres diffèrent, alors prenez la fréquence selon celle qui s'applique à vous plutôt que selon une règle générale. Le contrôle 8.8 de l'Annexe A ISO/IEC 27001:2022, gestion des vulnérabilités techniques, exige que des informations sur les vulnérabilités techniques des systèmes utilisés soient obtenues, que l'exposition soit évaluée et que des mesures appropriées soient prises, mais elle ne fixe aucun intervalle et laisse la cadence à votre évaluation des risques. La version 4 de PCI DSS est plus prescriptive pour les environnements de données des titulaires de cartes : des analyses de vulnérabilité internes au moins une fois tous les trois mois et après tout changement significatif, effectuées sous forme d'analyses authentifiées, avec des analyses externes par un fournisseur d'analyse agréé. De nombreuses organisations effectuent des analyses beaucoup plus souvent que le minimum, car le coût d'une autre analyse est faible. Concernant la propriété, la répartition habituelle est celle dessinée ici : la sécurité est propriétaire de la détection, de la notation et du reporting ; le propriétaire du système est propriétaire du correctif ; la direction est propriétaire des exceptions et des escalades. Un programme dans lequel la sécurité est également responsable des mesures correctives a tendance à stagner, car l'analyste n'a ni les droits de modification ni le risque opérationnel.

Quels enregistrements un processus de gestion des vulnérabilités doit-il produire ?

De quoi reconstituer n’importe quelle découverte un an plus tard sans ouvrir le scanner. En pratique, cela signifie une inscription au registre par découverte comportant le bien concerné, la date de détection, la qualification et ce qui l'a alimenté, le propriétaire attribué, le délai, le traitement choisi et la preuve de clôture. À côté se trouvent la configuration de l'analyse et les preuves de couverture, afin qu'un examinateur puisse déterminer ce qui était couvert et ce qui a été authentifié ; la liste de suppression, avec un motif et une date de révision pour chaque faux positif ; le registre des exceptions, avec justification, contrôle compensatoire, approbateur et expiration ; et la sortie de nouvelle analyse qui a clôturé chaque résultat. Le reporting constitue le dernier enregistrement : couverture, vieillissement par rapport aux tranches d'échéance et taux de clôture au fil du temps, ainsi que ce que la direction a décidé lorsque la tendance a évolué. Un examinateur testera généralement le registre par rapport au scanner plutôt que l'inverse, de sorte que les découvertes inexpliquées qui existent dans l'outil et non dans le registre sont les conclusions courantes.

Où ce processus s'inscrit

Dans la plupart des opérations, ce processus passe le relais à Organigramme du processus de gestion des correctifs (tester, approuver,….

Suit

Fait partie de

Fonctionnalités QueryChart pour ce processus

Utiliser ce modèle

Browse all Modèles de processus informatiques et ITSM