Modèle de politique de gestion des vulnérabilités

Comment utiliser ce modèle :

Les commentaires destinés à faciliter la compréhension et l’utilisation de ce modèle seront placés entre crochets « […] » et le « nom de l’entreprise » sera indiqué sous la forme [eSecurity Planet] dans tout le document. Lors de la conversion de ce modèle en politique opérationnelle, supprimez les sections entre crochets et remplacez « [eSecurity Planet] » par le nom de votre organisation.

Cette politique reflète une infrastructure et des besoins informatiques génériques. Elle peut être modifiée si nécessaire afin de refléter l’infrastructure et les besoins informatiques propres à une entreprise donnée.

Pour utiliser ce modèle, copiez-collez le texte du site web ou téléchargez le modèle Microsoft Word ci-dessous.

1. Vue d’ensemble

Les vulnérabilités de sécurité permettent aux attaquants de compromettre une ressource ou des données. Elles résultent de défauts des produits, de mauvaises configurations ou de lacunes dans les systèmes de sécurité et informatiques.

Les vulnérabilités se répartissent en deux catégories : non planifiées et planifiées. Les vulnérabilités non planifiées comprennent les vulnérabilités zero-day, les mauvaises configurations et autres erreurs de sécurité. Les vulnérabilités planifiées sont des vulnérabilités connues qui ne peuvent pas, ou ne seront pas, corrigées.

Cette politique de gestion des vulnérabilités définit les exigences applicables aux équipes informatiques et de sécurité de [eSecurity Planet] afin de protéger les ressources de l’entreprise contre les risques inacceptables liés aux vulnérabilités inconnues et connues. Cette politique de gestion des vulnérabilités :

• Présente les attentes, les exigences et les procédures de base pour :
• • l’identification des vulnérabilités
  • l’évaluation des vulnérabilités
  • l’atténuation des vulnérabilités
  • le suivi des vulnérabilités
• Définit les rapports permettant de vérifier la conformité à cette politique
• Prévoit des sanctions en cas de non-respect de cette politique

[Cette section a pour objectif de présenter au lecteur le but de la politique et ce qu’il trouvera plus loin dans le document. Une politique définit ce qui DOIT être fait, et non COMMENT cela doit être fait. Les responsables informatiques et de la sécurité doivent disposer de la souplesse nécessaire pour atteindre les objectifs avec leurs ressources, selon les modalités qu’ils jugent appropriées.]

2. Champ d’application

Cette politique s’applique à toutes les ressources de [eSecurity Planet] qui se connectent au réseau, assurent des connexions entre les ressources, assurent la sécurité des ressources, permettent à l’organisation de remplir sa mission ou hébergent les données de l’organisation. L’organisation tiendra à jour et suivra une liste officielle des ressources relevant du champ d’application de cette politique, comme défini dans l’annexe I : liste des ressources informatiques.

La gestion des vulnérabilités repose sur des listes exactes des systèmes, logiciels, connexions et dispositifs de sécurité existants. Le champ d’application doit être vérifié [conformément à la politique de gestion des actifs / tous les mois / tous les trimestres] afin de garantir que toutes les ressources puissent être évaluées avec précision et testées dans le cadre de l’identification des vulnérabilités.

Des analyses de vulnérabilités peuvent également devoir être effectuées sur des sites web et des applications qui ne sont pas détenus et gérés par d’autres services. Le service informatique devra vérifier la responsabilité de chaque application et site web afin de s’assurer qu’il n’existe aucune lacune dans la gestion des vulnérabilités.

Bien qu’essentielles à la gestion des vulnérabilités, la gestion des correctifs et la gestion des changements seront traitées séparément dans leurs propres politiques.

[Il s’agit d’une version générique du champ d’application, qui doit définir ce qui sera surveillé et testé dans le cadre de l’identification des vulnérabilités. Les organisations peuvent élargir ou restreindre ce champ selon leurs besoins dans l’annexe. Un champ plus large est toujours préférable pour maîtriser les risques, mais peut être plus coûteux.]

3. Politique et procédures de gestion des vulnérabilités

A. Autorité chargée de la gestion des vulnérabilités

[Le responsable de la sécurité des systèmes d’information (CISO) d’eSecurity Planet] est désigné comme l’autorité chargée de la gestion des vulnérabilités. Il assume la responsabilité et l’autorité ultimes pour planifier, exécuter, autoriser ou déléguer tout ou partie des sections de la présente politique et procédure de gestion des correctifs à des ressources internes ou à des outils ou fournisseurs tiers.

Bien que l’autorité chargée de la gestion des vulnérabilités conserve la responsabilité ultime, il est reconnu que le [service de sécurité informatique] exécutera généralement ses plans afin de se conformer à la politique de gestion des vulnérabilités. Dans le reste de cette politique, l’expression « service informatique » désigne l’autorité chargée de la gestion des vulnérabilités, le [service de sécurité informatique] et les représentants auxquels des responsabilités ont été déléguées.

L’autorité chargée de la gestion des vulnérabilités vérifie et approuve également :

• le champ d’application de la politique de gestion des vulnérabilités
• la priorité des vulnérabilités
• les tests de vulnérabilité et d’intrusion
• toute période d’interruption nécessaire à la maintenance, aux changements ou aux mesures d’atténuation
• toute exception nécessaire
• les rapports de gestion des vulnérabilités
• les mesures coercitives

[Cette section définit les personnes qui doivent approuver le budget et gérer le processus de gestion des vulnérabilités. Il est préférable d’utiliser une fonction, car les personnes changent parfois et la politique ne devrait pas devoir être révisée à chaque changement de personnel.]

B. Identification des vulnérabilités

Le service informatique ne peut pas partir du principe que la sécurité est invulnérable. Des tests doivent être effectués pour vérifier que les ressources ont été installées, configurées, intégrées et sécurisées sans erreur ni lacune de sécurité. 

i. Détection active des vulnérabilités

Des analyses de vulnérabilités et des tests d’intrusion seront effectués [tous les trimestres] et après toute modification importante des ressources afin de détecter les vulnérabilités inconnues. Les systèmes à haut risque contenant des données de grande valeur ou revêtant une grande importance pour les opérations devront faire l’objet d’analyses [mensuelles].

Les analyses de vulnérabilités peuvent être automatisées et réalisées avec des outils commerciaux, à condition que ces outils puissent tester les vulnérabilités potentielles spécifiques associées à la ressource. Des analyses de vulnérabilités non authentifiées doivent être menées pour observer les systèmes du point de vue d’un pirate externe, et des analyses authentifiées doivent être menées pour observer les systèmes du point de vue d’un pirate disposant d’identifiants volés.

Des analyses spécifiques portant sur certaines vulnérabilités peuvent être nécessaires au cas par cas après la découverte de vulnérabilités précises ou de menaces zero-day. Elles doivent être effectuées en fonction des besoins et ne pas être limitées au calendrier d’analyse habituel.

ii. Surveillance des informations et des menaces

En plus des tests, le service informatique surveillera et analysera en continu diverses sources afin d’obtenir des informations sur la découverte de nouvelles méthodes d’attaque et de vulnérabilités affectant les ressources. Les mises à jour et les correctifs des ressources relèvent de la politique de gestion des correctifs, mais les vulnérabilités non corrigées doivent être traitées dans le cadre de la présente politique de gestion des vulnérabilités. Ces sources peuvent notamment inclure les listes de diffusion consacrées à la sécurité, les notifications des fournisseurs et les sites web.

iii. Systèmes tiers

L’organisation devra probablement intégrer certains points de terminaison et systèmes tiers, notamment :

• les systèmes de contrôle industriel loués (ascenseurs, systèmes de lutte contre l’incendie, etc.)
• les équipements opérationnels loués
• les équipements personnels (BYOD) apportés par les employés, consultants, clients et visiteurs
• l’infrastructure cloud surveillée et gérée conjointement par le fournisseur cloud et l’organisation

Les analyses de vulnérabilités doivent inclure tous les systèmes accessibles connectés à l’organisation et peuvent inclure ces systèmes tiers. Toutefois, les vulnérabilités détectées peuvent dépasser les capacités des ressources internes en matière de résolution. Des accords officiels conclus avec les partenaires de l’entreprise peuvent définir les responsabilités de chaque partie pour différents types de vulnérabilités.

Toutefois, indépendamment de la responsabilité officielle, le service informatique peut devoir préparer des mesures compensatoires pour atténuer les vulnérabilités. Par exemple, l’organisation doit effectuer une analyse continue à l’aide d’un contrôle d’accès au réseau ou de solutions équivalentes afin de détecter les points de terminaison vulnérables lorsqu’ils tentent de se connecter au réseau de l’organisation et de les mettre en quarantaine.

iv. Documentation

Le service informatique doit concevoir et documenter le programme d’identification des vulnérabilités en répertoriant toutes les analyses, tous les tests et toutes les sources surveillées pour obtenir des informations. Ce document doit être joint à la présente politique sous forme d’annexe et mis à jour si nécessaire. Les ressources les plus exposées de l’organisation doivent être répertoriées séparément, avec indication des tests effectués pour vérifier leur état.

[Bien que l’énumération des types d’outils d’analyse, des tests d’intrusion et des sources d’informations sur les menaces soit souvent suffisante, l’ajout d’un tableau des principales ressources fournit une protection supplémentaire. Certaines organisations effectuent des analyses superficielles à l’aide d’outils peu coûteux sans vérifier que ces outils testent réellement leurs systèmes les plus critiques.]

Lorsqu’une vulnérabilité est identifiée, le service informatique ouvre un ticket et la vulnérabilité est suivie dans une liste de suivi de la gestion des vulnérabilités.

[Cette section vise à imposer une vigilance constante et une détection rapide des mises à jour et des correctifs disponibles. Les bonnes pratiques recommandent de confier à des personnes précises la recherche, la localisation et la vérification de la source des mises à jour et des correctifs.]

C. Évaluation des vulnérabilités

Une fois les vulnérabilités identifiées, elles doivent être vérifiées et évaluées au regard du risque potentiel qu’elles représentent pour l’organisation. La vulnérabilité doit être vérifiée à l’aide d’outils indépendants et par un personnel différent de la ressource qui l’a détectée. Dans certains cas, une tentative active d’exploitation peut être nécessaire pour vérifier la vulnérabilité ou évaluer son risque.

La vulnérabilité sera évaluée selon les critères suivants :

• Le système commun de notation des vulnérabilités (CVSS) de la vulnérabilité (s’il est disponible)
• la probabilité que la vulnérabilité soit exploitée
• les vulnérabilités associées ou en cascade

Le CVSS attribue aux vulnérabilités une note comprise entre 1 et 10. Les niveaux de la version 3.0 du CVSS correspondent aux catégories suivantes :

• 9,0 – 10,0 = gravité critique
• 7,0 – 8,9 = gravité élevée
• 4,0 – 6,9 = gravité moyenne
• 0,1 – 3,9 = gravité faible
• 0,0 = aucune gravité (à titre informatif)

Ces notes n’indiquent pas la probabilité d’exploitation, mais donnent une idée de l’ampleur des effets qu’un attaquant peut avoir sur un système ou des efforts qui peuvent être nécessaires. La Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis tient à jour une liste des vulnérabilités connues comme exploitées à laquelle il est possible de se référer pour vérifier l’existence d’une exploitation active.

De même, le service informatique doit évaluer l’environnement actuel, l’architecture informatique actuelle et la nature de la vulnérabilité afin de déterminer la probabilité d’exploitation, qui doit également être évaluée sur une échelle allant de 1 (faible probabilité) à 10 (forte probabilité). Lorsque cela est possible, l’estimation de la probabilité d’exploitation doit intégrer les informations de renseignement sur les menaces concernant l’exploitation de vulnérabilités similaires afin d’étayer l’évaluation. L’addition de ces trois facteurs produira une valeur comprise entre 1 (faible priorité ou aucune action nécessaire) et 20 (action urgente nécessaire) pour l’atténuation de la vulnérabilité.

[De nombreuses organisations ne privilégient pas les classements numériques dans leurs processus. L’attribution de valeurs peut prendre du temps, notamment aux premières étapes de l’adoption. Toutefois, les valeurs numériques facilitent la communication du risque et de l’urgence en dehors du service informatique, ainsi que la production de rapports et la conformité.]

Lorsque la vulnérabilité expose d’autres vulnérabilités existantes ou nouvelles, ces vulnérabilités associées doivent être signalées. Les systèmes, logiciels et processus associés doivent également être indiqués pour la vulnérabilité.

Des formulations générales sont autorisées lorsque la liste des systèmes concernés est trop lourde, mais il convient d’être précis lorsque cela est possible.  Par exemple :

• Une vulnérabilité affectant le modèle de pare-feu utilisé dans tous les bureaux doit être décrite comme s’appliquant à « tous les bureaux, systèmes et processus de l’organisation »
• Une vulnérabilité affectant un routeur précis sur un segment réseau précis doit indiquer spécifiquement :
• • la plage d’adresses IP concernée
  • les personnes concernées (ex. : les utilisateurs du service financier de Porto)
  • les appareils concernés (ex. : le serveur financier, les équipements comptables, les PC du service financier, les imprimantes locales)
  • les processus ou systèmes concernés notables ou de grande valeur (ex. : systèmes comptables, comptes fournisseurs, comptes clients, etc.)

[Cette section présente les critères d’évaluation permettant d’estimer le risque potentiel pour l’organisation. Même si une vulnérabilité donnée affecte un système précis, elle doit être replacée dans le contexte des autres systèmes et processus concernés afin de déterminer son impact potentiel sur l’organisation.]

D. Priorité des vulnérabilités

Plusieurs vulnérabilités peuvent être identifiées lors des tests ou à l’annonce de vulnérabilités zero-day. Si nécessaire, le service informatique déterminera la priorité d’atténuation de ces vulnérabilités en les replaçant dans le contexte des autres vulnérabilités existantes, selon une hiérarchie fondée sur :

• la valeur évaluée de la vulnérabilité déterminée lors de l’évaluation des vulnérabilités (ci-dessus)
• la valeur d’évaluation du risque des ressources (données, systèmes, processus, etc.) affectées par la vulnérabilité au sein de l’organisation

Valeur d’évaluation du risque : [eSecurity Planet] utilise l’analyse des risques pour évaluer les systèmes internes. Cette évaluation est consignée et mise à jour dans un registre des risques sur une échelle allant de 1 (faible impact/valeur) à 10 (impact/valeur maximal). Toutefois, une vulnérabilité peut affecter plusieurs systèmes, logiciels ou processus ; la valeur du risque doit donc refléter le total de toutes les ressources exposées ou la valeur de risque exposé la plus élevée, selon la valeur la plus importante.

Lorsque la note d’évaluation du risque, comprise entre 1 et 10, est combinée à la note d’évaluation de la vulnérabilité, comprise entre 1 et 20, le score de priorité de la vulnérabilité se situera entre 2 (aucune action nécessaire) et 30 (action immédiate requise). Cette priorisation aboutira généralement à plusieurs niveaux de vulnérabilités à traiter par le service informatique.

[Cette section attribue une priorité afin de déterminer quelles vulnérabilités doivent être traitées en premier dans le processus de gestion des vulnérabilités. Veillez à ce que personne ne manipule le risque d’exploitation et la valeur de la ressource par simple commodité, pour éviter de traiter la vulnérabilité ou privilégier des mesures d’atténuation à moindre risque qui perturbent moins les activités ou sont plus faciles à mettre en œuvre.

Cette section fait référence aux évaluations des risques et à un registre des risques. Les organisations de toutes tailles peuvent et devraient établir un registre des risques. Celui-ci évalue la valeur d’une ressource et l’ampleur de l’impact que subirait l’organisation si cette ressource était altérée, compromise ou défaillante.

Les risques directs et indirects doivent être pris en compte. Par exemple, une vulnérabilité dans la configuration du pare-feu d’un routeur Wi-Fi peut exposer des machines sous Windows 95 nécessaires au fonctionnement d’équipements de production. Le risque lié au routeur exposé inclut également celui des machines sous Windows 95 exposées, ainsi que le risque opérationnel ultérieur lié à la compromission des équipements de production.

En l’absence de registre des risques, l’organisation devra effectuer une estimation qualitative de la valeur de la ressource pour l’organisation.]

E. Directives d’atténuation des vulnérabilités

Une fois la vulnérabilité identifiée, évaluée et classée par ordre de priorité, la mesure d’atténuation destinée à y remédier doit être conçue, testée, préparée, planifiée, appliquée, vérifiée et testée.

i. Conception de l’atténuation des vulnérabilités

La sous-catégorie de la gestion des correctifs repose sur l’application de mesures d’atténuation ou de correctifs fournis par les éditeurs aux produits commerciaux ; elle est traitée de manière exhaustive dans la politique de gestion des correctifs. Une gestion plus large des vulnérabilités nécessitera davantage de personnalisation des paramètres, des ajustements de l’architecture informatique et l’installation d’outils ou de contrôles de sécurité supplémentaires.

Il existe souvent plusieurs façons d’atténuer directement ou indirectement une vulnérabilité. Dans de nombreux cas, l’élimination complète de la vulnérabilité sera impossible en raison du coût ou de la complexité de la mesure d’atténuation nécessaire.

Toutefois, le coût et la difficulté ne doivent pas servir d’excuse pour ignorer les vulnérabilités. Des mesures d’atténuation temporaires et partielles (ou mesures compensatoires) doivent être conçues, testées et appliquées dans un délai adapté au niveau de risque.

Les mesures d’atténuation courantes comprennent notamment :

• Déployer un contrôle de sécurité d’atténuation, tel qu’un nouvel outil de sécurité (pare-feu, etc.)
• Déployer des correctifs
• Ajouter l’authentification multifacteur aux contrôles de sécurité
• Mettre à niveau ou remplacer la ressource informatique vulnérable
• Isoler et protéger la ressource informatique vulnérable (segmentation réseau, désactivation de l’accès sans fil, etc.)
• Supprimer ou cesser d’utiliser la ressource informatique
• Déployer les modifications de configuration

Les mesures d’atténuation complexes peuvent nécessiter plusieurs mesures compensatoires ou plusieurs étapes. Pour les mesures d’atténuation plus complexes, des jalons doivent être définis afin de suivre l’avancement de la mise en œuvre.

Dans certains cas, l’atténuation nécessite la mise en œuvre de contrôles techniques qui affectent les utilisateurs, tels que l’authentification multifacteur (MFA). La formation à l’utilisation de ces outils doit être considérée comme faisant partie de la conception de l’atténuation, même s’il ne sera généralement pas nécessaire de l’achever dans le délai minimal prévu pour l’atténuation des vulnérabilités (voir ci-dessous).

ii. Tests de l’atténuation des vulnérabilités

Pour les ressources de grande valeur, le service informatique peut décider de tester l’atténuation dans un environnement de test afin de détecter d’éventuelles perturbations des activités ou autres problèmes. Toute mesure d’atténuation qui échoue au processus de test doit être repensée et testée à nouveau.

[Tester les mesures d’atténuation dans un environnement de test permet au service informatique de découvrir ces problèmes dans un environnement qui n’affectera pas les processus métier. Les organisations ne disposent pas toutes des ressources nécessaires pour effectuer des tests sur les ressources de faible valeur.]

iii. Préparation de l’atténuation des vulnérabilités

Toutes les mesures d’atténuation ne seront pas appliquées avec succès ou sans problème. Dans certains cas, une mesure d’atténuation peut rendre un système inutilisable ou entraîner des problèmes en cascade sur d’autres systèmes ou logiciels informatiques. Pour se préparer à cette éventualité, le service informatique doit s’assurer que [la politique de reprise après sinistre a été exécutée avant le processus de gestion des correctifs.

À tout le moins] :

• Une sauvegarde complète du système a été effectuée avant l’application de la mise à jour
• Une sauvegarde complète des données a été effectuée avant l’application de la mise à jour

En cas d’échec d’une mesure d’atténuation perturbant les activités, le service informatique tentera de restaurer le système ou le logiciel à une version précédente afin de rétablir ses fonctionnalités. Les systèmes qui ne peuvent pas être restaurés à une version précédente devront être restaurés à partir d’une sauvegarde ou remplacés rapidement. Dans certains cas, la perturbation peut laisser le système intact et nécessiter des modifications du plan d’atténuation pour rétablir les activités. Ces modifications doivent être mises en œuvre aussi rapidement que possible afin de limiter la perturbation.

Le service informatique peut tenter à plusieurs reprises de mettre en œuvre les mesures d’atténuation. Pour les mesures d’atténuation qui ne peuvent pas être appliquées avec succès, le service informatique doit suivre le processus d’exception et d’atténuation ci-dessous.

[Cette section reconnaît que toutes les mesures d’atténuation ne fonctionnent pas comme prévu et que le service informatique doit se préparer à cette éventualité avant d’appliquer des correctifs, quels qu’ils soient. Nous recommandons de faire référence à une politique de reprise après sinistre établie, qui devrait détailler les systèmes de sauvegarde et de récupération ; toutefois, les organisations qui ne disposent pas d’une telle politique peuvent supprimer ce texte et exiger simplement que des sauvegardes soient effectuées.]

iv. Planification de l’atténuation des vulnérabilités

Selon le classement figurant dans la liste de gestion des vulnérabilités, le service informatique devra mettre en œuvre l’atténuation dans les délais suivants :

• 20+ : dans un délai de [5] jours ouvrés
• 14,0 – 20 : dans un délai de [10] jours ouvrés
• 8,0 – 13,9 : dans un délai de [30] jours ouvrés
• Vulnérabilités classées en dessous de 8,0 : dans un délai de [90] jours

[Le délai de traitement des vulnérabilités dépend du risque potentiel. Les banques, les hôpitaux et les autres organisations présentant un risque élevé et un impact potentiellement important pour l’organisation peuvent définir les niveaux supérieurs en heures (par exemple : 72 heures) plutôt qu’en jours.]

L’atténuation des vulnérabilités comprend les outils de sécurité, les ajustements des paramètres, les modifications de l’architecture informatique et les autres étapes nécessaires pour réduire le risque associé à une vulnérabilité découverte.

Les autres facteurs influant sur la priorité de la vulnérabilité comprennent :

• Mesures d’atténuation requises pour remédier à la vulnérabilité
• La capacité d’une mesure d’atténuation potentielle ou d’un contrôle de sécurité à remédier à plusieurs vulnérabilités.
• Perturbations potentielles des activités liées aux mesures d’atténuation requises

Les mesures d’atténuation requises pour remédier à la vulnérabilité peuvent aller de simples ajustements des ports du pare-feu à l’installation complexe de plusieurs nouveaux outils et contrôles de sécurité. En général, les solutions simples seront privilégiées en raison du coût de leur mise en œuvre et de leurs tests ; toutefois, l’atténuation doit réduire suffisamment le risque lié à la vulnérabilité exposée.

La complexité de la solution ne réduit pas l’urgence d’atténuer la vulnérabilité. Toutefois, si des mesures temporaires peuvent être appliquées pour réduire le risque initial, la priorité globale et le classement de la vulnérabilité peuvent être réévalués.

Une mesure d’atténuation potentielle ou un contrôle de sécurité qui remédie à plusieurs vulnérabilités peut être priorisé à la discrétion du service informatique, à condition que l’atténuation ne gêne pas le déploiement de mesures d’atténuation de vulnérabilités plus urgentes. L’efficacité est importante, mais elle ne prime pas sur les dommages potentiels liés aux risques exposés.

Des perturbations potentielles des activités peuvent survenir en raison des mesures d’atténuation requises. Dans la mesure du possible, les perturbations des activités doivent être évitées et réduites au minimum.

Pour éviter toute perturbation excessive, ces mesures d’atténuation perturbatrices nécessitent que des fenêtres de maintenance soient planifiées et approuvées à l’avance par l’autorité chargée de la gestion des vulnérabilités, de préférence avec l’accord des responsables métier concernés par la perturbation.

Pour obtenir cette approbation, le service informatique doit [émettre un ticket / remplir un formulaire / envoyer un e-mail] adressé à l’autorité chargée de la gestion des correctifs, contenant les informations suivantes dans une demande de fenêtre de maintenance :

• Détails concernant les systèmes concernés
• Détails concernant l’urgence de la vulnérabilité et le risque
• Fenêtre de maintenance souhaitée et au moins une autre fenêtre possible
• Détails concernant les procédures de restauration en cas d’échec de l’atténuation

Pour les mesures d’atténuation à mettre en œuvre en l’absence de l’autorité chargée de la gestion des vulnérabilités, le responsable exécutif disponible suivant dans l’organigramme peut approuver la fenêtre de maintenance.

Si une mesure d’atténuation d’urgence doit être appliquée et qu’aucun responsable exécutif ne peut autoriser ou proposer une autre fenêtre de maintenance raisonnable dans le délai requis compte tenu de l’urgence de la vulnérabilité, le service informatique peut intervenir dans les conditions suivantes :

• Efforts documentés pour obtenir l’approbation
• Informer les parties prenantes concernées qui ne sont pas des responsables exécutifs (clients, employés, etc.) de la fenêtre de maintenance
• Procéder à l’atténuation sans approbation officielle

Il est reconnu que des mesures d’atténuation d’urgence et des perturbations liées à la maintenance peuvent parfois être nécessaires, mais le service informatique doit toujours réduire les perturbations au minimum.

[Cette partie formalisée du processus d’application des correctifs exige que les responsables de la mise en œuvre de l’atténuation demandent une fenêtre de maintenance lorsque la mise à jour logicielle entraînera une interruption de service pour les utilisateurs ou les systèmes en cours d’utilisation. Toutefois, elle donne également la priorité à la sécurité plutôt qu’aux activités lorsque les responsables opérationnels ne peuvent pas ou ne veulent pas autoriser raisonnablement une interruption de service.

Le système de classement exact et le degré d’urgence relèveront de l’organisation. Le calendrier fondé sur la priorité doit garantir une action rapide sur les correctifs et les mises à jour les plus critiques des ressources les plus critiques. Le délai maximal de 30 jours pour appliquer les mesures d’atténuation doit empêcher qu’un système ou un logiciel soit négligé ou totalement oublié, ou que les mises à jour s’accumulent.]

v. Application de l’atténuation des vulnérabilités

L’atténuation des vulnérabilités nécessitera généralement un processus manuel. Le service informatique est censé obtenir et mobiliser suffisamment de ressources pour mettre correctement en place l’atténuation dans le délai prévu. Lorsque cela est nécessaire, il peut faire appel à une expertise externe pour mettre en œuvre des mesures d’atténuation à grande échelle ou concernant des ressources à haut risque.

[Cette partie formalisée du processus d’application des correctifs exige que les responsables de la mise en œuvre de l’atténuation la réalisent dans les délais, même si cela peut nécessiter le recrutement de ressources supplémentaires. Cette formulation donne à la sécurité une priorité supérieure au contrôle budgétaire ; elle devra donc éventuellement être adaptée aux besoins de l’organisation.]

vi. Vérification et tests de l’atténuation des vulnérabilités

Une fois l’application de l’atténuation terminée, le service informatique doit vérifier que celle-ci fonctionne comme prévu et réduit le risque comme prévu. Les tests d’intrusion et les analyses de vulnérabilités doivent être répétés afin de vérifier la réussite de l’opération ou d’identifier et de signaler les mesures d’atténuation ayant échoué. Les vulnérabilités qui restent exposées doivent être traitées conformément aux exigences du suivi des mesures d’atténuation et des exceptions (paragraphe 3.F ci-dessous).

F. Suivi des mesures d’atténuation et exceptions

Les mesures d’atténuation ne permettent pas toujours de résoudre les vulnérabilités. Dans de nombreux cas, les mesures compensatoires mises en place pour atténuer une vulnérabilité la protègent derrière des couches de sécurité supplémentaires sans traiter directement la vulnérabilité.

Toutes les vulnérabilités non résolues et les mesures d’atténuation associées continueront d’être suivies et surveillées afin de détecter d’éventuelles vulnérabilités futures dans la liste de suivi de la gestion des vulnérabilités. Les vulnérabilités atténuées doivent être réexaminées [tous les trimestres] afin de déterminer si des mesures d’atténuation plus efficaces pourraient être déployées pour gagner du temps, réduire les frais de maintenance ou diminuer davantage le risque.

Pour l’application de correctifs ou la maintenance, tout système défaillant, perturbateur ou non corrigé constitue une exception qui doit être traitée comme une vulnérabilité au titre de la présente politique. Toutefois, la plupart des vulnérabilités défaillantes ou perturbatrices ne resteront pas des exceptions. Les mesures d’atténuation ayant échoué ou provoqué des perturbations seront remaniées et réintroduites dans le processus de gestion des vulnérabilités afin d’être résolues. Dans de rares cas, la combinaison d’une vulnérabilité à faible risque et du coût élevé des mesures compensatoires peut conduire l’organisation à accepter le risque lié à cette vulnérabilité. Ces exceptions devront être suivies et signalées dans la liste des vulnérabilités.

[La plupart des organisations peuvent effectuer un examen trimestriel comme indiqué dans ce document. Toutefois, les organisations plus petites peuvent ne disposer de ressources que pour des examens semestriels ou annuels, tandis que les grandes organisations peuvent adopter une approche plus stricte et souhaiter effectuer des examens mensuels ou hebdomadaires pour les systèmes à haut risque ou de grande valeur.]

G. Rapports sur la gestion des vulnérabilités

Le service informatique publiera des rapports [mensuels] sur l’application des correctifs et les mises à jour. Les rapports doivent inclure :

• Date(s) de la ou des dernières analyses des ressources et nombre de ressources suivies
• Pourcentage de systèmes effectivement testés à la recherche de vulnérabilités, ainsi que types d’analyses de vulnérabilités et de tests d’intrusion utilisés lors des tests actifs
• Nombre de vulnérabilités détectées lors des analyses
• Nombre de vulnérabilités corrigées au moyen de mesures d’atténuation, classées selon :
• • le risque de la vulnérabilité
  • la priorité globale
  • le délai de résolution (en résumé et en détail)
• L’analyse de vulnérabilités ou le test d’intrusion effectué pour chaque mesure d’atténuation afin d’en vérifier la mise en œuvre correcte (indiquer « en attente » si les tests sont toujours en cours)
• Nombre de vulnérabilités restantes non atténuées
• Délai moyen écoulé entre la détection et l’atténuation d’une vulnérabilité, par catégorie de risque et de valeur de la ressource
• Nombre d’exceptions de vulnérabilités ajoutées au rapport des exceptions
• Nombre total de vulnérabilités et de mesures d’atténuation figurant dans la liste de suivi des vulnérabilités

[Le service informatique doit publier des rapports afin que l’organisation puisse vérifier que les procédures de gestion des vulnérabilités sont correctement suivies et que les mesures d’atténuation sont mises en œuvre dans les délais. Des rapports réguliers peuvent éviter la nécessité de rapports spéciaux à des fins de conformité.

Les données du rapport doivent également servir à améliorer le processus de gestion des vulnérabilités. Par exemple, le nombre de mesures d’atténuation de vulnérabilités donnant lieu à des tickets d’assistance peut permettre de déterminer si des tests supplémentaires sont nécessaires avant le déploiement.]

4. Contrôles et gestion des audits

Les responsables et les auditeurs de [eSecurity Planet] peuvent demander à tout moment les procédures documentées et les éléments probants relatifs aux pratiques de gestion des vulnérabilités. Les exemples de procédures documentées et d’éléments probants comprennent :

• Demandes de fenêtres de maintenance approuvées
• Listes d’exceptions approuvées
• Exports complets ou partiels de la liste ou du système de suivi de la gestion des vulnérabilités
• Copies complètes ou partielles des analyses de vulnérabilités et des tests d’intrusion réalisés pour découvrir les vulnérabilités ou vérifier les mesures d’atténuation
• Rapports sur la gestion des vulnérabilités

[Cette section reconnaît que les responsables et les auditeurs peuvent avoir occasionnellement besoin de rapports hors calendrier sur les processus de gestion des vulnérabilités. Pour vérifier les rapports de gestion des vulnérabilités, certains auditeurs peuvent également exiger des journaux système confirmant la réussite des mises à jour du système ou des logiciels.]

5. Application de la politique

Les employés reconnus coupables d’une violation délibérée de la politique peuvent faire l’objet de mesures disciplinaires pouvant aller jusqu’au licenciement inclus. Les performances professionnelles des membres du service informatique chargés de l’exécution de cette politique seront évaluées en partie ou en totalité selon leur capacité à satisfaire aux exigences de cette politique.

L’incapacité régulière du service informatique à respecter les exigences de la présente politique de gestion des vulnérabilités peut être considérée comme une négligence et entraîner des mesures disciplinaires. La falsification de rapports ou une négligence grave dans l’exécution peuvent justifier un licenciement immédiat ou des mesures disciplinaires.

[Pour être efficaces, les politiques doivent prévoir des sanctions en cas de non-respect. Ce document suppose que les organisations qui ne respectent pas les normes de mise à jour par manque de ressources ne tiendront pas leur service informatique pour responsable lorsqu’il est surchargé de travail ou débordé. Les organisations qui imposent des attentes déraisonnables connaîtront probablement un fort renouvellement du personnel informatique et auront des difficultés à conserver des employés expérimentés ou compétents.]

6. Diffusion

La présente politique doit être diffusée à tous les responsables de [eSecurity Planet] et aux membres du service informatique chargés de l’assistance et de la gestion de la politique de gestion des correctifs.

[Toute personne appelée à travailler sur la gestion des correctifs (membres du service informatique) ou susceptible d’être concernée par la politique (au minimum les responsables, mais éventuellement d’autres employés concernés) doit recevoir la présente politique. Les employés chargés de son exécution peuvent devoir accuser officiellement réception du document.]

7. Version de la politique

Version 1.0
Date d’approbation : 5/12/2023
Description : première version de la politique

[Cette section peut également être transformée en historique des versions de la politique, avec un tableau des versions et approbations précédentes.]

8. Signatures

Approuvé par : ____________________________________________
[Signature de l’autorité chargée de la gestion des correctifs]

Approuvé par : ____________________________________________
[Directeur général ou autre responsable exécutif compétent]

[La signature de l’autorité chargée de la gestion des correctifs confirme qu’elle reconnaît les exigences de la politique et constitue de fait un engagement à les respecter. La signature du directeur général ou d’un autre responsable exécutif confirme que la politique répond aux besoins de l’organisation. Le responsable exécutif qui signe doit occuper un poste suffisamment élevé pour que sa signature incite les autres services à respecter la politique.]

Annexe

I. Liste des ressources informatiques

[Conformément à la politique de gestion des ressources,] la liste des ressources de l’organisation doit couvrir tous les systèmes, logiciels, micrologiciels et appareils de l’organisation. Elle peut également inclure des appareils qui ne sont pas sous le contrôle de l’organisation, mais qui sont connectés au réseau, tels que les appareils personnels utilisés à des fins professionnelles (BYOD), les équipements loués disposant d’un accès, les équipements des prestataires, etc.

Les exemples de ressources figurant dans la liste comprennent notamment :

• Équipements réseau
• • Pare-feu (ainsi que les logiciels, micrologiciels et fonctionnalités de sécurité installés nécessitant des mises à jour)
  • Commutateurs réseau (ainsi que les logiciels et micrologiciels installés)
  • Routeurs (ainsi que les logiciels et micrologiciels installés)
• Serveurs (sites web, hôtes d’applications, plateformes de virtualisation, etc.) et système d’exploitation installé
• Système d’exploitation installé, logiciels installés, micrologiciels
• • Postes de travail
  • Tablettes
  • Ordinateurs portables
  • Appareils cellulaires
• Internet des objets (IoT) et logiciels et micrologiciels installés
• • Voix sur IP (VoIP)
  • Caméras de sécurité
  • Téléviseurs connectés au Wi-Fi
  • Imprimantes Wi-Fi
  • Imprimantes réseau
  • Réseaux de stockage (SAN)
  • Appareils à commande vocale (Amazon Alexa, etc.)
  • [Moniteurs cardiaques et autres dispositifs médicaux]
  • Systèmes de panneaux solaires
  • Lecteurs de badges de sécurité des portes
• Technologies opérationnelles (OT), infrastructures connectées et logiciels ou micrologiciels installés
• • Convoyeur connecté à la 5G
  • Équipements CVC connectés

La liste des ressources doit inclure :

• Type de ressource (serveur, PC, logiciel, routeur, etc.)
• Propriétaire attribué à l’appareil (s’il s’agit d’une ressource partagée, le responsable du service concerné est de fait le propriétaire attribué)
• Système d’exploitation, micrologiciel ou version du logiciel principal
  [Remarque : le suivi et la maintenance de versions précises peuvent être utiles, mais contraignants pour les organisations qui utilisent un système de suivi manuel.]
• Mise à jour manuelle ou automatique ?
• Mise à jour effectuée par le service informatique, par une mise à jour automatique du logiciel, par un outil tiers ou par un prestataire de services tiers ?
• Dernière mise à jour
• Mise à jour réussie (O/N)
• Appareils associés (c’est-à-dire, pour le logiciel Adobe Acrobat : installé sur l’appareil associé : PC4362)

Bien que le [service informatique] soit responsable de la tenue de la liste des ressources, les responsables de service doivent informer le service informatique du déploiement de nouvelles ressources (appareils, logiciels installés, etc.). Les appareils ou logiciels déployés sans en informer le service informatique seront considérés comme des appareils non autorisés et pourront être bloqués et supprimés.

Le [service informatique] effectuera des analyses [continues/mensuelles/quotidiennes/trimestrielles] de l’environnement informatique afin de vérifier que la liste des ressources reste à jour et de détecter les appareils ou logiciels non autorisés.

La liste actuelle des ressources est stockée :

[Répertoriez la base de données des ressources, le tableur Excel, le outil de gestion des ressources ici.
Remarque : l’utilisation d’un tableur Excel peut le rendre vulnérable à des altérations ou modifications accidentelles ou intentionnelles. Une feuille de calcul Google dont les versions sont contrôlées, ou un fichier Excel stocké dans OneDrive ou Sharepoint, constituerait une meilleure option.

Les organisations doivent élaborer et tenir à jour une politique de gestion des ressources. L’élaboration de cette politique et d’un exemple de liste des ressources dépasse le cadre du présent document. Les appareils BYOD ne doivent pas être suivis dans une liste de ressources. La maintenance des appareils BYOD doit être assurée à l’aide de fonctionnalités ou d’outils de contrôle d’accès au réseau qui vérifient que les appareils disposent de profils de sécurité acceptables au minimum.]