Modèle de politique de gestion des correctifs

Comment utiliser ce modèle :

Les commentaires destinés à faciliter la compréhension et l’utilisation de ce modèle de politique de gestion des correctifs seront placés entre crochets « […] », et le nom de l’« entreprise » sera indiqué comme [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 « YourCompanyName ».

Cette politique décrit une infrastructure et des besoins informatiques génériques. Elle peut être modifiée pour refléter l’infrastructure et les besoins informatiques d’une entreprise donnée.

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

Cet article est sponsorisé par Automox, qui propose l’application automatisée de correctifs et la gestion de la configuration des appareils Windows, MacOS et Linux, ainsi que d’applications tierces comme Chrome, Adobe et Slack. Lire le rapport d’

’

état des opérations IT en 2023 et voir ce qui

’

fonctionne et ce qui ne fonctionne pas

’

pour les équipes ITOP du monde entier.

Politique de gestion des correctifs de [eSecurity Planet (ou indiquez ici le nom de votre entreprise)]

1. Vue d’ensemble

Les fournisseurs publient régulièrement des mises à jour de fonctionnalités, corrigent les dysfonctionnements et fournissent des correctifs de sécurité afin d’améliorer les performances et d’éliminer les vulnérabilités de leurs produits. L’adoption rapide de ces mises à jour protège contre les menaces, améliore potentiellement l’expérience des utilisateurs et peut accroître la productivité de l’organisation.

Les ressources non corrigées exposent les utilisateurs, les données et les autres ressources de l’entreprise à un risque inacceptable. Cette politique de gestion des correctifs :

• Décrit les attentes, les exigences et les procédures de base nécessaires à la maintenance des systèmes et logiciels de [eSecurity Planet]
• 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 but de présenter au lecteur l’objectif de la politique et ce qu’il doit attendre de la suite du document. Une politique définit ce qui DOIT être fait, mais pas COMMENT cela doit être fait. Les responsables informatiques doivent disposer de la flexibilité nécessaire pour atteindre les objectifs avec leurs ressources, selon ce qu’ils jugent approprié.]

En savoir plus sur la politique de gestion des correctifs

2. Périmètre

Cette politique s’applique à toutes les ressources de [eSecurity Planet] qui se connectent au réseau de l’organisation, contribuent à sa mission ou hébergent ses données. L’organisation tiendra à jour et suivra une liste officielle des ressources relevant de cette politique, conformément à l’annexe I : Liste des ressources informatiques de notre modèle téléchargeable.

La gestion des correctifs repose sur des listes exactes des systèmes et logiciels existants à mettre à jour. Le périmètre doit être vérifié [conformément à la politique de gestion des actifs / chaque mois / chaque trimestre] afin de garantir que tous les actifs peuvent être évalués avec précision en vue de l’application des correctifs et des mises à jour.

[Il s’agit de la version la plus stricte du périmètre. Certaines organisations ne tentent pas de mettre à jour ou de surveiller les appareils de leurs employés connectés au réseau, ou ignorent les appareils de l’Internet des objets (IoT). Bien que cette pratique soit risquée, certaines organisations acceptent tacitement ces risques par souci de simplicité ou en raison de contraintes de ressources (budget, personnel informatique, temps, etc.).

Le périmètre doit définir ce qui fera l’objet d’une surveillance, de mises à jour et de l’application de correctifs. Si le service informatique ne corrige que les systèmes d’exploitation des serveurs et des terminaux, modifiez le périmètre en conséquence — et acceptez les risques liés aux systèmes non surveillés.]

3. Politique et procédures de gestion des correctifs

A. Autorité chargée de la gestion des correctifs

[Le directeur des systèmes d’information (CIO) de eSecurity Planet] est désigné comme l’autorité chargée de la gestion des correctifs. Il assume la responsabilité et l’autorité ultimes pour planifier, exécuter, autoriser ou déléguer toute section de cette 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 correctifs conserve la responsabilité ultime, il est admis que le [service informatique] exécute généralement ses plans afin de se conformer à la politique de gestion des correctifs. Dans le reste de cette politique, l’expression « service informatique » désigne l’autorité chargée de la gestion des correctifs, le [service informatique] et les représentants désignés.

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

• Le périmètre de la politique de gestion des correctifs
• La priorité d’application des correctifs
• Les tests et l’approbation des correctifs
• Toute interruption nécessaire à la maintenance lors de l’application des correctifs et des mises à jour
• Toute mesure d’atténuation ou exception nécessaire
• Les rapports de gestion des correctifs
• L’application de la politique

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

B. Acquisition des correctifs et des mises à jour

Le service informatique surveillera et analysera en permanence diverses sources afin d’obtenir des informations sur la publication de mises à jour et de correctifs pour tous les actifs relevant de cette politique. Ces sources peuvent notamment inclure les listes de diffusion de sécurité, les notifications des fournisseurs et les sites web.

Lorsqu’un correctif ou une mise à jour est disponible, le service informatique recherchera la source et en vérifiera la validité avant de télécharger la mise à jour. La méthode privilégiée consiste à obtenir les correctifs directement auprès du fournisseur source (l’entreprise ou l’organisation qui a développé la ressource concernée par la mise à jour) ou auprès d’un prestataire qui obtient les mises à jour directement auprès de ce fournisseur.

Les correctifs et mises à jour provenant d’autres sources doivent être examinés et testés attentivement avant leur introduction dans l’environnement de l’organisation.

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

C. Priorité d’application des correctifs

Plusieurs correctifs et mises à jour peuvent être disponibles simultanément. Si nécessaire, le service informatique déterminera la priorité des correctifs et des mises à jour et établira une hiérarchie fondée sur :

• Le score Common Vulnerability Scoring System (CVSS) de la vulnérabilité corrigée
• La valeur de risque de l’actif
• La probabilité d’exploitation

Le CVSS attribue aux vulnérabilités un score compris entre 1 et 10. Les niveaux de la version 3.0 du CVSS correspondent à :

• 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 scores n’indiquent pas la probabilité d’exploitation, mais donnent une indication du degré auquel un attaquant peut affecter un système ou de l’effort qui peut être nécessaire. La Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis tient à jour une liste des vulnérabilités connues comme étant exploitées qui peut être consultée pour vérifier l’existence d’une exploitation active.

[eSecurity Planet] utilise l’analyse des risques pour établir une évaluation des risques des systèmes internes, consignée et mise à jour dans un registre des risques sur une échelle de 1 (faible impact/valeur) à 10 (impact/valeur maximal). 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 de 1 (faible probabilité) à 10 (forte probabilité). L’addition de ces trois facteurs produit une valeur comprise entre 2 (faible priorité ou aucune action nécessaire) et 30 (action urgente nécessaire) pour l’application du correctif.

En cas d’externalisation auprès d’un prestataire ou d’utilisation d’un outil d’application de correctifs, certains correctifs seront appliqués automatiquement et aucune priorité ne sera peut-être nécessaire. Une priorité devra être définie pour les mises à jour et correctifs qui :

• Nécessitent l’arrêt d’une ressource pour maintenance
• Entrent en conflit avec d’autres correctifs et mises à jour
• Causent des problèmes avec d’autres systèmes ou processus métier

La file d’attente des correctifs manuels peut contenir des correctifs plus anciens et moins urgents. Les nouveaux correctifs publiés doivent remplacer les correctifs obsolètes dans la file. Le correctif de remplacement peut conserver la même priorité que l’ancien ou être repriorisé à la discrétion du service informatique.

[Cette section attribue une priorité afin de déterminer quels correctifs doivent être appliqués en premier dans le processus de gestion des correctifs. La pondération de la priorité selon le CVSS est généralement la méthode la plus courante, et certaines organisations l’utilisent exclusivement.

La valeur pour l’entreprise et la probabilité d’exploitation doivent également être prises en compte lors de la détermination de la priorité. Il faut toutefois veiller à ce que personne ne manipule le risque d’exploitation et la valeur de l’actif par simple commodité afin d’éviter de traiter la mise à jour.

Les services et outils de gestion des correctifs utiliseront probablement les valeurs CVSS, car elles sont tangibles et le service ou l’outil n’a généralement pas de visibilité sur la valeur des actifs pour l’organisation.

Cette section fait référence aux évaluations des risques et à un registre des risques. Les organisations de toute taille peuvent et devraient tenir un registre des risques. Celui-ci évalue la valeur d’une ressource et l’ampleur de l’impact potentiel sur l’organisation si cette ressource est altérée, compromise ou défaillante. Si aucun registre des risques n’est en place, l’organisation devra établir une estimation qualitative de la valeur de la ressource pour l’organisation.]

D. Calendrier d’application des correctifs et des mises à jour

En fonction de la note de priorité des correctifs, comprise entre 2 et 30, le service informatique devra appliquer le correctif :

• 24,0 – 30 : dans les [7] jours suivant la publication du correctif
• 18,0 – 23,9 : dans les [14] jours suivant la publication du correctif
• Correctifs de sécurité inférieurs à 18,0 : dans les [30] jours suivant leur publication

Les correctifs ne relevant pas de la sécurité (mises à niveau et corrections de bogues) doivent être appliqués selon un calendrier normal de maintenance, défini par les procédures d’exploitation relatives à la maintenance et à l’assistance des systèmes, sans toutefois dépasser [90] jours. Les correctifs et mises à jour de priorité inférieure peuvent être appliqués en même temps que des correctifs ou mises à jour de priorité supérieure, à la discrétion du service informatique.

Par exemple :

• Une correction de bogue logiciel non critique, notée 8,4, peut être installée simultanément avec d’autres corrections de vulnérabilités notées 25,3 et 28,0.
• La mise à niveau d’une fonctionnalité non critique d’un routeur, notée 15,4, peut être retardée, car le service informatique devra peut-être mettre à jour manuellement plus de 50 routeurs pour corriger une vulnérabilité de sécurité notée 13,0, et les mises à niveau ne peuvent pas être effectuées simultanément.

En pratique, les serveurs et les terminaux seront corrigés chaque mois, avec une application accélérée des correctifs pour les vulnérabilités critiques, en particulier lorsqu’une méthode d’attaque a été rendue publique. Les mises à jour de sécurité de tous les systèmes doivent être installées et les systèmes redémarrés (si nécessaire) dans les délais impartis.

[Le système de notation exact et le degré d’urgence relèveront de l’organisation. Le calendrier fondé sur la priorité doit garantir une action rapide concernant les correctifs et mises à jour les plus critiques des ressources les plus importantes. Le délai maximal de 90 jours pour appliquer les mises à niveau et les correctifs doit empêcher qu’un système ou logiciel soit négligé ou complètement ignoré, ou que les mises à jour s’accumulent.]

E. Directives d’application des correctifs

Une fois le correctif obtenu et sa priorité définie, les étapes suivantes doivent être suivies.

i. Test des correctifs

Pour les ressources à forte valeur, le service informatique peut décider de tester le correctif dans un environnement de test afin de détecter d’éventuelles perturbations de l’activité ou d’autres problèmes. Les correctifs qui échouent au test peuvent être exclus du processus d’application, à condition que le service informatique suive le processus d’exception et d’atténuation (voir le paragraphe 3.F ci-dessous).

[Les fournisseurs tiers et les services ou outils de gestion des correctifs testeront les correctifs dans des environnements génériques. Toutefois, des conséquences imprévues peuvent survenir dans certaines architectures informatiques ou certains systèmes dépendants.

Tester les correctifs 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. Toutes les organisations ne disposent pas des ressources nécessaires pour tester les correctifs, et tester les correctifs de ressources de faible valeur peut ne pas constituer une utilisation rentable du temps ou des ressources.]

ii. Préparation à la gestion des correctifs

Tous les correctifs ne seront pas appliqués avec succès ni sans problème. Dans certains cas, un correctif peut rendre un appareil inutilisable ou provoquer 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.

Au minimum] :

• 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

Pour les mises à jour de micrologiciels de systèmes critiques (routeurs, serveurs, etc.), un système de secours peut devoir être mis en place au cas où la mise à jour rendrait l’appareil d’origine inutilisable.

En cas d’échec d’une mise à jour, 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 devront être récupérés à partir d’une sauvegarde ou remplacés rapidement.

Le service informatique peut tenter plusieurs fois d’appliquer les correctifs et les mises à jour. Pour les correctifs ou mises à jour qui ne peuvent pas être appliqués correctement, le service informatique doit suivre le processus d’exception et d’atténuation ci-dessous.

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

iii. Gestion automatisée des correctifs et des mises à jour

De nombreux fournisseurs activent des procédures d’application automatisée des correctifs pour leurs applications. En outre, un certain nombre d’outils et de prestataires tiers peuvent aider au processus de gestion des correctifs.

Lorsque cela est pratique et possible, le service informatique doit utiliser des options appropriées pour automatiser le processus de gestion des correctifs. Les services automatisés peuvent alléger la charge potentielle du service informatique et permettre l’application rapide des correctifs dans tout l’environnement informatique, sans délai.

Le service informatique doit s’assurer que toute la préparation à la gestion des correctifs (voir la section 3.E.ii ci-dessus) a été menée à bien avant d’autoriser l’exécution de tout processus automatisé.

Il est admis que les micrologiciels, les équipements informatiques (routeurs, etc.) et les fournisseurs de logiciels peuvent nécessiter une application manuelle des correctifs et des mises à jour. Les fournisseurs et outils utilisés pour l’application automatisée des correctifs doivent indiquer explicitement ce qu’ils couvrent ou ne couvrent pas en matière d’application de correctifs et de mises à jour, et la liste des actifs doit préciser quels éléments nécessitent des mises à jour manuelles.

iv. Gestion manuelle des correctifs

Certains correctifs et mises à jour (notamment les micrologiciels) nécessiteront un processus manuel. Pour les mises à jour qui ne perturbent pas les processus métier, le service informatique peut appliquer le correctif à sa discrétion dans le délai imparti, compte tenu de l’urgence du correctif et de la mise à jour.

Certains correctifs peuvent nécessiter l’arrêt de systèmes métier critiques. Afin d’éviter toute perturbation excessive, ces fenêtres de maintenance doivent être planifiées et approuvées à l’avance par l’autorité chargée de la gestion des correctifs, de préférence avec l’accord des responsables métier concernés par la perturbation.

Pour obtenir l’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 et contenant les informations suivantes dans une demande de fenêtre de maintenance :

• Informations détaillées sur les systèmes concernés
• Informations détaillées sur l’urgence du correctif et le risque
• Fenêtre de maintenance souhaitée et au moins une autre fenêtre possible
• Informations détaillées sur les procédures de restauration en cas d’échec du correctif

Pour les correctifs d’urgence nécessaires en l’absence de l’autorité chargée de la gestion des correctifs, le prochain cadre disponible dans l’organigramme de l’organisation peut approuver la fenêtre de maintenance.

Si un correctif d’urgence doit être appliqué et qu’aucun cadre ne peut ou ne souhaite l’autoriser dans un délai raisonnable compte tenu de son urgence, le service informatique peut documenter ses efforts pour obtenir l’approbation et appliquer le correctif ou la mise à jour sans approbation officielle. Il est admis que des correctifs d’urgence et des interruptions de maintenance peuvent occasionnellement être nécessaires, mais le service informatique doit toujours réduire au minimum les perturbations.

[Cette partie formalisée du processus d’application des correctifs exige des responsables de leur mise en œuvre qu’ils demandent une fenêtre de maintenance lorsque la mise à jour logicielle entraînera une interruption pour les utilisateurs ou les systèmes en cours d’utilisation.]

v. Vérification et test des correctifs

Une fois le processus d’application des correctifs et des mises à jour terminé, le service informatique doit vérifier que les correctifs ont été appliqués avec succès, ou signaler et corriger ceux qui ont échoué. Il doit également vérifier que les vulnérabilités traitées par le correctif ont effectivement été atténuées ou éliminées.

Les vulnérabilités qui restent exposées doivent être traitées conformément aux exigences relatives aux exceptions et aux mesures d’atténuation (paragraphe 3.F ci-dessous).

F. Exceptions et mesures d’atténuation

Des exceptions peuvent survenir au cours du processus d’application des correctifs et des mises à jour. Ces exceptions seront classées comme suit :

1. Correctifs ayant échoué : correctifs et mises à jour qui ne s’installent pas correctement
2. Correctifs perturbateurs : correctifs et mises à jour qui entraîneront une perturbation inacceptable de l’activité s’ils sont installés
3. Correctifs inutiles : correctifs ou mises à jour non liés à la sécurité qui activent ou corrigent des fonctionnalités inutiles ou indésirables
4. Vulnérabilité non corrigée : certains actifs peuvent également présenter des vulnérabilités qui restent non corrigées par les fournisseurs pour diverses raisons (fin de vie, cessation d’activité du fournisseur, etc.)

Toutes les catégories doivent être consignées dans une liste d’exceptions. Les correctifs inutiles seront simplement consignés et vérifiés [trimestriellement] afin de s’assurer qu’ils restent inutiles.

Les correctifs ayant échoué, les correctifs perturbateurs et les vulnérabilités non corrigées nécessiteront des mesures d’atténuation. Le service informatique élaborera et proposera des mesures d’atténuation appropriées afin de limiter le risque et les dommages potentiels que la vulnérabilité non corrigée pourrait causer à l’organisation. Chaque plan d’atténuation doit être approuvé par l’autorité chargée de la gestion des correctifs et comprendre :

• Informations détaillées sur les systèmes concernés
• Informations détaillées sur l’urgence de la vulnérabilité non corrigée
• Informations détaillées sur la mesure d’atténuation et la manière dont elle traite la vulnérabilité non corrigée
• Fenêtre de déploiement souhaitée et au moins une autre fenêtre possible. Indiquer si des systèmes métier doivent être arrêtés pour mettre en œuvre la mesure d’atténuation.

La mesure d’atténuation et la liste des exceptions seront examinées [trimestriellement] afin de déterminer :

• Si des correctifs ont été publiés, de sorte que la mesure d’atténuation puisse être abandonnée
• Si des actifs doivent être ou ont été mis hors service ou remplacés, de sorte que la mesure d’atténuation puisse être abandonnée
• Si certaines mesures d’atténuation peuvent être améliorées de quelque manière que ce soit

L’autorité chargée de la gestion des correctifs doit approuver l’examen [trimestriel] de la mesure d’atténuation et de la liste des exceptions.

[Si un correctif ne peut pas être appliqué, une autre approche pour atténuer le risque doit être élaborée et approuvée par écrit. La plupart des organisations peuvent effectuer un examen trimestriel comme indiqué dans le présent document. Toutefois, les organisations de plus petite taille peuvent ne disposer que des ressources nécessaires à des examens semestriels ou annuels, tandis que les grandes organisations peuvent adopter une approche plus stricte et souhaiter effectuer des examens mensuels ou hebdomadaires.]

G. Rapports sur les correctifs et les mises à jour

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

• Date de la dernière analyse des actifs et nombre d’actifs suivis
• Pourcentage de systèmes couverts par la gestion automatisée des correctifs
• Pourcentage de systèmes faisant l’objet d’une surveillance de l’application des correctifs
• Nombre de correctifs publiés par les fournisseurs ou acquis par l’organisation au cours de la période
• Nombre de correctifs ayant échoué aux contrôles qualité au cours de la période
• Nombre de correctifs qui ne se sont pas installés correctement
• Nombre de correctifs ayant entraîné la création de tickets d’incident
• Nombre de mises en œuvre réussies de correctifs par rapport au nombre de correctifs ayant échoué
• Délai moyen écoulé entre la disponibilité d’un correctif et son déploiement, selon l’évaluation CSV et selon la catégorie de risque ou de valeur de l’actif
• Nombre d’exceptions ajoutées au rapport des exceptions
• Nombre total d’exceptions figurant dans le rapport des exceptions

[Le service informatique doit publier des rapports afin que l’organisation puisse vérifier que les procédures de gestion des correctifs sont correctement suivies et que les correctifs et les mises à jour sont appliqués en temps voulu. Des rapports réguliers peuvent éliminer 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 correctifs. Par exemple, le nombre de correctifs entraînant la création de tickets peut être utilisé pour déterminer si des tests supplémentaires des correctifs sont nécessaires ou si les tests actuels doivent être améliorés.

Les organisations plus matures peuvent également effectuer régulièrement des tests de vulnérabilité et des tests d’intrusion afin de vérifier que les correctifs ont été correctement installés. Ces rapports de test peuvent être ajoutés aux rapports réguliers sur les correctifs et les mises à jour.]

4. Contrôles et gestion des audits

Les dirigeants 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 correctifs. Les procédures documentées et éléments probants peuvent notamment comprendre :

• Demandes approuvées de fenêtres de maintenance
• Listes d’exceptions approuvées
• Journaux des mises à jour et des correctifs système pour toutes les grandes catégories de systèmes et d’utilitaires
• Les journaux doivent inclure l’identifiant du système, la date d’application du correctif, l’état du correctif, l’exception et le motif de l’exception
• Infrastructure démontrée prenant en charge la gestion des correctifs d’entreprise sur l’ensemble des systèmes, applications et appareils
• Rapports de gestion des correctifs

[Cette section reconnaît que les dirigeants et les auditeurs peuvent parfois avoir besoin de rapports ponctuels sur les processus de gestion des correctifs. Pour vérifier les rapports de gestion des correctifs, certains auditeurs peuvent également demander des journaux système confirmant la réussite des mises à jour du système ou des logiciels.]

5. Mise en application

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. 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é, en fonction de leur capacité à répondre aux attentes de cette politique.

L’incapacité régulière du service informatique à satisfaire aux exigences de la présente politique de gestion des correctifs 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 constituer des motifs de licenciement immédiat ou de mesures disciplinaires.

Les appareils équipés de systèmes d’exploitation, de logiciels et de micrologiciels qui ne respectent pas les exigences en matière de correctifs doivent être empêchés d’accéder aux ressources essentielles par leur valeur ou leur fonction et leur accès doit être limité à la DMZ ou à des sections de réseau isolées.

[Pour que les politiques soient efficaces, des sanctions doivent être prévues en cas de non-conformité. Bien que cela soit brièvement mentionné ici, une politique de sécurité réseau doit déterminer explicitement comment et à quoi les appareils non conformes peuvent accéder au sein de l’organisation.

Le présent document part du principe que les organisations qui ne respectent pas la norme de mise à jour par manque de ressources ne tiendront pas leur service informatique pour responsable lorsqu’il est surchargé ou débordé. Les organisations qui imposent des attentes déraisonnables connaîtront probablement un taux élevé de rotation du personnel informatique et auront des difficultés à retenir des collaborateurs expérimentés ou compétents.]

6. Diffusion

La présente politique doit être diffusée à tous les dirigeants de [eSecurity Planet] et aux membres du service informatique chargés de la prise en charge et de la gestion de la politique de gestion des correctifs.

[Toute personne amenée à travailler sur la gestion des correctifs (membres du service informatique) ou concernée par la politique (au minimum les dirigeants, mais éventuellement aussi d’autres employés concernés) doit recevoir cette politique. Les employés chargés de son exécution peuvent être tenus d’en accuser formellement réception.]

7. Version de la politique

Version 1,0

Date d’approbation : 15/11/2022

Description : première version de la politique

[Cette section peut également prendre la forme d’un 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 : ____________________________________________

[PDG ou autre dirigeant concerné]

[La signature de l’autorité chargée de la gestion des correctifs atteste que les exigences de la politique sont reconnues et constitue de fait un engagement à les respecter. La signature du PDG ou d’un autre dirigeant atteste que la politique répond aux besoins de l’organisation. Le dirigeant qui signe doit être suffisamment haut placé pour que sa signature incite les autres services à respecter la politique.]

Annexe

I. Liste des actifs informatiques

[Conformément à la politique de gestion des actifs,] la liste des actifs 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 (BYOD), les équipements loués disposant d’un accès, les équipements des sous-traitants, etc.

Les ressources figurant sur la liste des actifs comprennent notamment :

• Équipements réseau
• • Pare-feu (ainsi que les logiciels, micrologiciels et fonctionnalités de sécurité installés qui nécessitent 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), ainsi que les logiciels et micrologiciels installés
• • Téléphones voix sur IP (VoIP)
  • Caméras de sécurité
  • Téléviseurs connectés en Wi-Fi
  • Imprimantes Wi-Fi
  • Imprimantes réseau
  • Réseaux de baies de stockage (SAN)
  • Appareils à commande vocale (Amazon Alexa, etc.)
  • [Moniteurs cardiaques et autres appareils médicaux]
  • Systèmes de panneaux solaires
  • Lecteurs de badges de sécurité pour 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 actifs doit inclure :

• Type d’actif (serveur, PC, logiciel, routeur, etc.)
• Propriétaire désigné de l’appareil (s’il s’agit d’une ressource partagée, le responsable du service concerné est le propriétaire désigné de fait)
• Version du système d’exploitation principal, du micrologiciel ou du logiciel
  [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 logicielle automatique, par un outil tiers ou par un prestataire de services tiers ?
• Dernière mise à jour
• Mise à jour réussie (O/N)
• Appareils associés (p. ex. 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 actifs, les responsables de service doivent informer le service informatique du déploiement de nouveaux actifs (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 actifs reste à jour et de détecter les appareils ou logiciels non autorisés.

La liste actuelle des actifs est stockée ici :

[Indiquer la base de données des actifs, la feuille de calcul Excel, outil de gestion des actifs ici.
Remarque : l’utilisation d’une feuille de calcul Excel peut la rendre vulnérable à une corruption ou à des modifications accidentelles ou intentionnelles. Une feuille de calcul Google dont les versions sont géré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 actifs. L’élaboration de cette politique et d’un exemple de liste des actifs sort du cadre du présent document type.

Les appareils BYOD ne doivent pas être suivis dans une liste des actifs. La maintenance des appareils BYOD doit être assurée au moyen de fonctionnalités ou d’outils de contrôle d’accès réseau qui vérifient que les appareils respectent des profils de sécurité minimaux acceptés.]