Patch management : stratégie réaliste pour Linux

Imaginez cette situation : vous êtes responsable d'un parc de serveurs Linux pour une entreprise de e-commerce. Un mardi matin, vous recevez une notification : une nouvelle CVE vient d'être publiée pour le noyau Linux. Score CVSS 9.1, élévation de privilèges, exploit public disponible.

Vous commencez à évaluer l'impact :

• Combien de serveurs sont concernés ? « Euh... il faut vérifier »
• Quelle version du noyau tourne en production ? « Ça dépend des serveurs »
• A-t-on un environnement de test pour valider le patch ? « Le staging est en retard de 6 mois sur la prod »
• Peut-on faire un rollback si le patch casse quelque chose ? « On n'a jamais testé »

Trois jours plus tard, après des nuits blanches, des tests improvisés et un déploiement stressant, vous avez patché 80% des serveurs. Les 20% restants ? « On verra la semaine prochaine, là on est trop fatigués. »

Vous venez de vivre un patch management de crise. Ce guide vous apprend à faire autrement.

Ce que vous allez apprendre

• Prioriser un correctif selon sa criticité, son exposition et l'existence d'un exploit
• Tester un correctif en préproduction avec un point de retour prêt
• Déployer progressivement, en canary ou en rolling update, et vérifier après coup
• Automatiser sans perdre la décision humaine, avec Ansible ou unattended-upgrades
• Mesurer le processus avec le MTTP et le taux de couverture

Qu'est-ce que le patch management ?

Un patch (correctif) est une modification publiée par un éditeur pour corriger un défaut d'un logiciel déjà installé, le plus souvent une faille de sécurité. Le patch management est l'organisation qui entoure ces correctifs : savoir qu'ils existent, décider lesquels appliquer en premier, les valider, les déployer et prouver qu'ils sont en place. La commande de mise à jour n'est qu'une étape de cette chaîne, et de loin la plus courte.

Au-delà de la simple mise à jour

Le patch management ne se limite pas à exécuter apt upgrade. C'est un processus complet qui va de la veille sur les vulnérabilités jusqu'à la vérification post-déploiement, en passant par l'évaluation des risques et la planification.

Composant	Ce qu'il couvre
Veille	Suivre les annonces CVE, bulletins éditeurs, advisories
Inventaire	Savoir ce qui tourne, où, dans quelle version
Évaluation	Prioriser selon la criticité et l'exposition
Test	Valider que le patch ne casse rien
Déploiement	Appliquer de façon contrôlée
Vérification	S'assurer que tout fonctionne après
Documentation	Garder une trace pour l'audit

Glissez pour voir

Les types de correctifs

Tous les patchs ne se valent pas. Comprendre leur nature aide à prioriser.

Type	Urgence	Exemples
Sécurité critique	Immédiate	CVE avec exploit public, CVSS ≥ 9.0
Sécurité haute	Sous 7 jours	CVE sans exploit, CVSS 7.0-8.9
Sécurité moyenne	Sous 30 jours	CVE difficile à exploiter, CVSS 4.0-6.9
Fonctionnel	Planifié	Bug fixes, améliorations
Performance	Planifié	Optimisations

Glissez pour voir

Pourquoi c'est difficile (et pourquoi c'est critique)

Si patcher se résumait à une commande, aucun parc ne serait en retard. La difficulté est organisationnelle : le correctif arrive à un moment que vous n'avez pas choisi, il touche des serveurs dont la disponibilité est engagée auprès de métiers, et il peut casser une application dont personne ne connaît plus les dépendances. Les trois sections qui suivent posent le compromis à arbitrer, la fenêtre d'exposition que crée l'attentisme, et les obstacles concrets à lever.

Le dilemme du patch management

Patcher vite expose à des risques de régression. Patcher tard expose à des risques de compromission. C'est un équilibre constant.

Patcher trop vite	Patcher trop tard
Régression applicative	Vulnérabilité exploitée
Downtime non planifié	Compromission système
Perte de confiance utilisateurs	Perte de données
Stress de l'équipe	Amende RGPD/conformité

Glissez pour voir

La fenêtre d'exposition

L'attaquant n'a pas besoin d'une faille inédite. Il exploite le plus souvent des vulnérabilités publiques, pour lesquelles un correctif existe déjà, sur des systèmes qui ne l'ont pas encore appliqué. Le temps qui sépare la publication du correctif de son déploiement sur votre parc est votre fenêtre d'exposition.

Un référentiel public donne l'ordre de grandeur attendu. L'agence américaine CISA tient le catalogue KEV (Known Exploited Vulnerabilities), qui recense les vulnérabilités dont l'exploitation est avérée. Sa directive BOD 22-01 du 3 novembre 2021 impose aux agences fédérales de les corriger sous deux semaines, et sous six mois pour les CVE attribuées avant 2021. Même hors de ce cadre, une vulnérabilité présente dans le KEV est le signal le plus fiable pour passer un correctif en tête de file.

Ce qui complique les choses

Aucun de ces obstacles n'est technique au sens strict, et c'est ce qui les rend tenaces. Ils se traitent en amont, quand rien ne brûle : un inventaire fiable, un environnement de préproduction représentatif, des fenêtres de maintenance négociées à l'avance. Reporter ce travail revient à devoir l'improviser le jour où un correctif critique tombe.

Obstacle	Impact	Solution
Inventaire incomplet	On ne sait pas quoi patcher	CMDB à jour, scans réguliers
Environnement de test absent	On n'ose pas patcher	Investir dans le staging
Fenêtres de maintenance rares	Les patchs s'accumulent	Négocier des fenêtres plus fréquentes
Dépendances applicatives	Peur de casser l'application	Tests automatisés, canary
Legacy non supporté	Pas de patch disponible	Isolation, compensating controls

Glissez pour voir

Le cycle de gestion des patchs

Un bon processus de patch management suit un cycle régulier et prévisible.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Étape 1 : Surveiller, La veille continue

Ne pas attendre que les patchs vous tombent dessus. Mettez en place une veille proactive.

Sources officielles

Abonnez-vous aux canaux officiels de vos éditeurs :

Distribution	Source
RHEL/CentOS	Red Hat Security Advisories (RHSA)
Ubuntu	Ubuntu Security Notices (USN)
Debian	Debian Security Advisories (DSA)
SUSE	SUSE Security Advisories

Glissez pour voir

Ces bulletins contiennent les informations de criticité, les versions affectées et les correctifs disponibles.

CVE et NVD

Pour une vue d'ensemble :

• NVD (National Vulnerability Database) : base de référence
• CVE (Common Vulnerabilities and Exposures) : identifiants uniques
• CVSS (Common Vulnerability Scoring System) : scores de criticité

Outils pour automatiser :

# Vérifier les CVE sur vos packages installés
# Red Hat / CentOS
yum updateinfo list security

# Ubuntu / Debian
apt list --upgradable 2>/dev/null | grep -i security

Outils automatisés

Des outils scannent automatiquement vos systèmes :

Outil	Type	Ce qu'il fait
OpenSCAP	Open source	Scan de conformité et vulnérabilités
Trivy	Open source	Scan de vulnérabilités (conteneurs aussi)
Nessus	Commercial	Scanner de vulnérabilités complet
Qualys	Commercial	Plateforme de gestion des vulnérabilités
Lynis	Open source	Audit de sécurité Linux

Glissez pour voir

Exemple avec Trivy :

# Scanner un serveur pour les vulnérabilités
trivy rootfs --severity HIGH,CRITICAL /

Étape 2 : Évaluer, Prioriser intelligemment

Tous les patchs ne méritent pas la même urgence. Utilisez une matrice de priorisation.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Critères d'évaluation :

Critère	Questions à poser
CVSS	Quel est le score ? ≥ 9.0 = critique
Exposition	Le service est-il accessible depuis Internet ?
Exploit	Un exploit public existe-t-il ?
Impact	Que se passe-t-il si la vulnérabilité est exploitée ?
Compensations	Y a-t-il des mesures d'atténuation en place ?

Glissez pour voir

Exemple de priorisation :

CVE-2024-XXXX : OpenSSL RCE
├── CVSS : 9.8 (Critique)
├── Exposition : Serveurs web publics → HAUTE
├── Exploit : POC public disponible → URGENCE
├── Impact : Exécution de code arbitraire
└── DÉCISION : Patch sous 24h

Étape 3 : Tester, Valider avant de déployer

Ne jamais patcher en production sans test préalable. Jamais.

1. Environnement de test

   Maintenez un environnement staging qui reflète la production. Même OS, mêmes versions, mêmes configurations.

2. Appliquer le patch en staging

   # Snapshot avant patch (si VM)
   virsh snapshot-create-as serveur-staging pre-patch
   
   # Appliquer le patch
   apt update && apt upgrade -y paquet-concerné
   
   # Redémarrer si nécessaire
   needrestart -r a

3. Tests de validation

   • L'application démarre-t-elle ?
   • Les services répondent-ils ?
   • Les tests automatisés passent-ils ?
   • Les performances sont-elles stables ?

4. Période d'observation

   Laissez tourner quelques heures (ou jours selon l'urgence) avant de valider pour la production.

Étape 4 : Planifier, Communiquer et coordonner

Un patch non communiqué est un risque d'incident.

Élément	Contenu
Fenêtre	Date, heure de début, durée estimée
Périmètre	Serveurs concernés, services impactés
Risques	Possibilité de downtime, rollback prévu
Responsables	Qui déploie, qui valide, qui est de garde
Communication	Qui prévenir, par quel canal

Glissez pour voir

Template de notification :

MAINTENANCE PLANIFIÉE - Patch sécurité OpenSSL

Date : Samedi 15/02/2025 de 02h00 à 04h00
Serveurs : web-prod-01 à web-prod-10
Impact : Interruption possible de 5 minutes par serveur
Rollback : Snapshot pré-patch, temps estimé 10 minutes

Responsable : équipe-ops@example.com
Escalation : astreinte-n1@example.com

Étape 5 : Déployer, De façon contrôlée

Plusieurs stratégies de déploiement existent. Choisissez selon le risque.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Déploiement canary

Commencez par un petit groupe de serveurs, observez, puis élargissez.

# Phase 1 : 10% des serveurs (canary)
ansible-playbook patch.yml -l canary_group

# Observation pendant 2h...

# Phase 2 : 50% des serveurs
ansible-playbook patch.yml -l group_a

# Observation pendant 4h...

# Phase 3 : reste des serveurs
ansible-playbook patch.yml -l group_b

Avantage : si problème, seul un petit groupe est impacté.

Rolling update

Patcher les serveurs un par un, en maintenant le service disponible.

# Avec Ansible
ansible-playbook patch.yml --serial 1

# Ou avec un load balancer
for server in $(cat servers.txt); do
  echo "Patching $server..."
  # Retirer du LB
  lb-ctl remove $server
  # Patcher
  ssh $server "apt update && apt upgrade -y"
  # Valider
  ssh $server "systemctl status application"
  # Remettre dans le LB
  lb-ctl add $server
done

Avantage : zéro downtime si bien orchestré.

Blue-Green

Préparer un environnement patché complet, puis basculer le trafic.

1. Environnement Blue (actuel) : reçoit le trafic
2. Environnement Green (nouveau) : patché et validé
3. Bascule du trafic vers Green
4. Blue devient le rollback

Avantage : rollback instantané (rebascule vers Blue).

Étape 6 : Vérifier, S'assurer que tout fonctionne

Le déploiement n'est pas terminé tant que la vérification n'est pas faite.

# Vérifier que le patch est appliqué
dpkg -l | grep paquet-concerné
rpm -qa | grep paquet-concerné

# Vérifier que les services tournent
systemctl status service-critique

# Vérifier les logs d'erreur
journalctl -p err -n 50 --no-pager

# Tester l'application
curl -I https://mon-service.example.com/health

Checklist post-déploiement :

• Version du package correcte
• Services démarrés et healthy
• Pas d'erreurs dans les logs
• Monitoring vert
• Tests applicatifs OK
• Performance stable

Étape 7 : Documenter, Pour l'audit et l'historique

Chaque patch appliqué doit être tracé.

Information	Exemple
Date/heure	2025-02-15 02:15 UTC
CVE/Advisory	CVE-2024-XXXX, RHSA-2025:0123
Serveurs	web-prod-01 à web-prod-10
Version avant	openssl-1.1.1k-1
Version après	openssl-1.1.1k-2
Responsable	alice@ops
Résultat	Succès, aucun rollback
Observations	RAS

Glissez pour voir

Cette documentation sert pour :

• Les audits de conformité (PCI-DSS, ISO 27001)
• L'analyse post-incident
• La planification future

La procédure elle-même, commandes et critères de retour arrière, gagne à vivre dans un runbook plutôt que dans la mémoire de celui qui patche. Et un correctif appliqué à la main sur un seul serveur crée un écart avec ses voisins : c'est l'objet de la leçon sur les états de référence et la dérive.

Automatisation du patch management

Passé une dizaine de serveurs, la connexion manuelle machine par machine devient la première cause de retard et d'oubli. L'automatisation ne consiste pas à tout patcher sans contrôle : elle industrialise les étapes répétitives, la collecte de l'inventaire, l'application du correctif, le redémarrage conditionnel et la vérification post-déploiement, tout en gardant la décision humaine sur le déclenchement.

Outils d'automatisation par écosystème

Deux familles cohabitent. Les outils sans agent comme Ansible se connectent en SSH au moment où vous le décidez, sans rien installer sur les serveurs. Les plateformes à agent comme Satellite ou Landscape maintiennent un état permanent et publient des rapports de conformité en continu. Le choix dépend moins des fonctionnalités que de votre capacité à exploiter un composant supplémentaire sur chaque machine.

Outil	Environnement	Capacités
Ansible	Tout Linux	Playbooks de patch, rolling updates
Puppet	Tout Linux	Gestion de configuration + patch
Satellite	RHEL	Gestion complète du cycle de vie
Landscape	Ubuntu	Gestion centralisée des patchs
WSUS	Windows	Mise à jour centralisée
Uyuni	Multi-distro	Alternative open source à Satellite, issue de Spacewalk (projet arrêté en 2020)

Glissez pour voir

Alternative sans code : Rudder

Si votre équipe n'est pas à l'aise avec Ansible et ses playbooks, Rudder propose une approche différente : une interface web graphique pour définir vos politiques de patch sans écrire de code. Cette approche de la gestion de patch par campagnes planifiées et progressives est détaillée dans le cas d'usage patch management de Rudder.

Rudder installe un agent sur chaque serveur qui vérifie l'état toutes les 5 minutes et corrige automatiquement les écarts. Il génère aussi des rapports de conformité exploitables pour les audits (CIS, PCI-DSS, ANSSI).

→ Découvrir Rudder

Exemple de playbook Ansible

Ce playbook traduit en code les étapes de déploiement décrites plus haut. Trois éléments méritent l'attention : serial limite le nombre de serveurs traités simultanément, ce qui produit un déploiement progressif au lieu d'un traitement massif ; les pre_tasks créent le point de retour et sortent la machine du répartiteur de charge avant toute modification ; le fichier /var/run/reboot-required, créé par Debian et Ubuntu, déclenche le redémarrage uniquement quand il est réellement nécessaire. Les post_tasks ne remettent le serveur en service qu'après vérification des services critiques.

---
- name: Patch sécurité - Déploiement contrôlé
  hosts: production
  serial: "{{ serial_count | default(1) }}"
  become: yes

  pre_tasks:
    - name: Créer snapshot (si VM)
      community.vmware.vmware_guest_snapshot:
        name: "pre-patch-{{ ansible_date_time.date }}"
        state: present
      delegate_to: localhost
      when: is_vm | default(false)

    - name: Retirer du load balancer
      community.general.haproxy:
        state: disabled
        backend: "{{ lb_backend }}"
        host: "{{ inventory_hostname }}"
      delegate_to: "{{ lb_host }}"
      when: lb_backend is defined

  tasks:
    - name: Mettre à jour le cache des packages
      apt:
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Appliquer les mises à jour disponibles
      apt:
        upgrade: safe
        update_cache: no
      register: patch_result
      when: ansible_os_family == "Debian"

    - name: Vérifier si redémarrage nécessaire
      stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Redémarrer si nécessaire
      reboot:
        reboot_timeout: 300
      when: reboot_required.stat.exists

  post_tasks:
    - name: Vérifier les services critiques
      service:
        name: "{{ item }}"
        state: started
      loop: "{{ critical_services | default(['sshd']) }}"

    - name: Test de santé applicatif
      uri:
        url: "{{ health_check_url }}"
        status_code: 200
      when: health_check_url is defined

    - name: Remettre dans le load balancer
      community.general.haproxy:
        state: enabled
        backend: "{{ lb_backend }}"
        host: "{{ inventory_hostname }}"
      delegate_to: "{{ lb_host }}"
      when: lb_backend is defined

Mises à jour automatiques : oui ou non ?

La mise à jour entièrement automatique supprime le délai de réaction, mais aussi la possibilité de tester. Le compromis praticable consiste à la réserver aux dépôts de sécurité et à exclure les composants dont une régression serait bloquante, typiquement le noyau et les moteurs de bases de données. Ces deux-là restent traités manuellement, avec fenêtre planifiée et point de retour.

Automatique sans validation	Automatique avec validation
❌ Production critique	✅ Environnements de dev
❌ Applications sensibles	✅ Serveurs non critiques
❌ Systèmes réglementés	✅ Avec rollback automatique

Glissez pour voir

Configuration prudente avec unattended-upgrades (Ubuntu) :

/etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // Pas les mises à jour standards
};

Unattended-Upgrade::Package-Blacklist {
    "linux-";  // Pas de mise à jour kernel automatique
    "mysql-";  // Pas de mise à jour BDD automatique
};

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

// Redémarrage automatique seulement si nécessaire, à 3h du matin
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Anti-patterns et bonnes pratiques

Les incidents liés aux correctifs se répètent d'une organisation à l'autre avec une constance remarquable. Les reconnaître à l'avance coûte moins cher que de les vivre : la plupart viennent d'un raccourci pris sous la pression du calendrier, pas d'une méconnaissance technique.

Les 10 erreurs les plus courantes

Un anti-pattern est une pratique répandue parce qu'elle paraît efficace à court terme, alors qu'elle aggrave le problème qu'elle prétend régler. Repérez dans ce tableau ceux qui décrivent votre organisation actuelle : ils indiquent l'ordre dans lequel investir. Le dernier, la recherche de responsable après incident, conditionne tous les autres, car une équipe qui craint la sanction cesse de remonter les problèmes.

Anti-pattern	Pourquoi c'est dangereux	Bonne pratique
Patcher en prod sans tester	Risque de régression	Toujours tester en staging
Ignorer les patchs « pas critiques »	Ils s'accumulent	Fenêtres régulières pour tous
Pas de rollback prévu	Coincé si problème	Snapshot ou blue-green
Patch le vendredi soir	Personne pour réagir	Patch en début de semaine
Inventaire manuel	Toujours obsolète	Automatiser avec CMDB/scans
Attendre la « fenêtre parfaite »	Elle n'existe pas	Négocier des fenêtres régulières
Tout patcher d'un coup	Blast radius maximum	Déploiement progressif
Oublier de documenter	Audit impossible	Documentation automatique
Ne pas monitorer après	Problèmes non détectés	Surveillance renforcée 24h
Blâmer si incident	Équipe qui cache les problèmes	Culture blameless

Glissez pour voir

Le cas particulier des systèmes legacy

Certains systèmes ne peuvent pas être patchés (fin de support, contraintes métier). Que faire ?

1. Isoler

   Placez le système dans un VLAN dédié avec des règles firewall strictes. Limitez les flux au strict nécessaire.

2. Durcir

   Appliquez toutes les mesures de sécurité possibles : désactivation des services inutiles, configuration restrictive.

3. Surveiller

   Monitoring renforcé : détection d'intrusion (HIDS), analyse des logs, alertes sur comportements anormaux.

4. Planifier le remplacement

   Un système legacy est une bombe à retardement. Documentez le plan de migration et obtenez un budget.

5. Accepter le risque formellement

   Si le système reste, faites valider le risque par la direction. Par écrit.

Métriques de patch management

Sans mesure, la question « sommes-nous à jour ? » n'a pas de réponse vérifiable, et le sujet retombe au premier arbitrage de priorité. Quelques indicateurs suffisent, à condition qu'ils soient produits automatiquement à partir de l'inventaire et non ressaisis à la main.

KPIs à suivre

Un KPI (indicateur clé de performance) n'a d'intérêt que si un objectif chiffré lui est associé et qu'un écart déclenche une action. Le MTTP est le plus parlant des cinq : il mesure le temps réel entre la publication d'une vulnérabilité et son traitement sur votre parc, donc la durée pendant laquelle vous êtes attaquable. Le taux de rollback, lui, contrôle la qualité de vos tests : un taux qui grimpe signale une préproduction qui ne ressemble plus à la production.

Métrique	Ce qu'elle mesure	Objectif
MTTP (Mean Time To Patch)	Délai entre publication CVE et patch appliqué	Critique < 72h, Haute < 7j
Taux de couverture	% de systèmes à jour	> 95%
Patchs en retard	Nombre de patchs non appliqués dans les délais	0
Taux de rollback	% de patchs nécessitant un retour arrière	< 5%
Incidents liés au patch	Nombre d'incidents causés par un patch	0 idéalement

Glissez pour voir

Dashboard de suivi

Ces indicateurs se lisent ensemble, pas isolément. Un taux de couverture élevé accompagné de correctifs critiques en attente signale un parc à jour sur l'accessoire et en retard sur l'essentiel. À l'inverse, un MTTP court associé à beaucoup de retours arrière révèle un déploiement précipité. Le tableau de bord sert d'abord à repérer ces contradictions, ensuite à communiquer vers la direction.

Checklists opérationnelles

Les deux listes suivantes se parcourent au moment de l'opération, y compris en urgence. Leur intérêt n'est pas de rappeler ce que vous savez déjà, mais d'empêcher qu'une étape saute sous la pression : c'est presque toujours le point de retour ou la communication qui passent à la trappe quand le correctif est annoncé comme critique.

Checklist « Avant de patcher »

Les six points se valident dans l'ordre : chacun conditionne le suivant, et le déploiement ne démarre que si tous sont cochés.

1. Inventaire vérifié

   Je sais exactement quels serveurs sont concernés par ce patch.

2. Criticité évaluée

   J'ai analysé le CVSS, l'exposition et l'existence d'exploits.

3. Test réalisé

   Le patch a été validé en staging sans régression.

4. Rollback préparé

   Snapshot créé, procédure de rollback documentée et testée.

5. Fenêtre planifiée

   Date communiquée, équipes informées, astreinte prévenue.

6. Monitoring prêt

   Dashboards ouverts, alertes configurées pour la période post-patch.

Checklist « Après le patch »

L'opération n'est pas terminée quand la commande de mise à jour se termine sans erreur. Une régression se manifeste rarement dans la minute qui suit : elle apparaît au premier pic de charge, au premier redémarrage de service, ou lors d'un traitement planifié la nuit. D'où la période d'observation en dernier point, qui n'est pas une formalité.

1. Patch appliqué confirmé

   Version vérifiée sur tous les serveurs concernés.

2. Services fonctionnels

   Tous les services critiques démarrés et en bonne santé.

3. Tests passés

   Tests automatisés et manuels validés.

4. Monitoring vert

   Pas d'alerte, métriques stables.

5. Documentation mise à jour

   Ticket fermé, CMDB à jour, rapport d'exécution enregistré.

6. Période d'observation

   Surveillance renforcée pendant 24-48h.

À retenir

1. Patcher est un processus, pas un événement

   La veille, l'évaluation, le test, le déploiement et la vérification forment un cycle continu. Ne sautez aucune étape.

2. Priorisez par le risque réel

   CVSS seul ne suffit pas. Combinez criticité, exposition et existence d'exploits pour décider de l'urgence.

3. Testez toujours avant la production

   Un environnement de staging qui reflète la prod est un investissement, pas un luxe. Il vous sauvera.

4. Préparez le rollback avant de patcher

   La question n'est pas « si » un patch causera un problème, mais « quand ». Soyez prêt.

5. Automatisez ce qui peut l'être

   Veille, inventaire, déploiement, vérification. L'automatisation réduit les erreurs et accélère le cycle.

6. Documentez pour l'audit et pour vous

   Chaque patch appliqué doit être tracé. Votre futur vous (ou l'auditeur) vous remerciera.

7. Mesurez pour progresser

   MTTP, taux de couverture, incidents. Ce qui se mesure s'améliore.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Références externes

Ces documents servent à deux choses : justifier vos délais de traitement auprès d'un auditeur, et alimenter la veille au quotidien. Les premiers définissent ce qu'un processus de correctifs doit contenir, les derniers publient les vulnérabilités elles-mêmes.

Standards et frameworks

Ces référentiels sont ceux que citent les auditeurs de conformité ; le NIST SP 800-40 est le plus détaillé sur le processus lui-même.

• NIST SP 800-40, Guide to Enterprise Patch Management Planning
• CIS Controls, Control 7 : Continuous Vulnerability Management
• ISO 27001, contrôle 8.8 de l'annexe A (version 2022, ex-A.12.6) : Management of technical vulnerabilities
• PCI-DSS, exigence 6.3.3 en v4.0 (6.2 en v3.2.1) : correctifs de sécurité

Guides pratiques

Documentation opérationnelle, à consulter selon la distribution que vous exploitez plutôt que dans l'ordre.

• Red Hat Patch Management Guide, Documentation Satellite
• Ubuntu Security Guide, USN et bonnes pratiques
• SANS Patch Management, Best Practices for Patch Management

Bases de données de vulnérabilités

Sources primaires à interroger avec un identifiant CVE ; le calculateur CVSS permet de recalculer un score en tenant compte de votre contexte d'exposition, souvent différent du score publié.

• NVD, National Vulnerability Database
• CVE, Common Vulnerabilities and Exposures
• CVSS Calculator, Calcul de score CVSS

×

📖 Voir la documentation →