====== Processus de Patching SANEF — Manuel vs Automatisé ======
**Référence :** Processus SECOPS — Équipe Patching SANEF\\
**Objectif :** Documenter le workflow de patching actuel (manuel) et quantifier le gain apporté par les outils d'automatisation (SQATM .exe + PatchCenter Web).
----
===== 1. Vue d'ensemble du processus =====
Le patching d'un serveur se déroule en **deux phases principales** étalées sur plusieurs jours :
^ Phase ^ Moment ^ Objectif ^ Livrable ^
| **1. Affectation** | Jeudi COMEP 14h00 | Répartition des serveurs | Liste par intervenant |
| **2. Préparation (pré-patching)** | Jeudi après-midi + Vendredi | Éligibilité + validation créneau | Créneau validé avec responsable |
| **3. Exécution (Jour J)** | Lundi → Jeudi (selon créneau) | Patching + vérifications | Serveur patché et validé |
| **4. Nettoyage** | Vendredi (J+3 typique) | Suppression snapshots + kernels | Serveurs propres |
**Règle de cadrage :** pas de patching le vendredi pour éviter un incident qui courrait tout le weekend.\\
Le vendredi est consacré aux **opérations hors patching** : finalisation pré-patching de la semaine suivante, suppression des anciens snapshots (des serveurs patchés en début de semaine), ménage kernels, iTop, météo.
----
===== 2. Phase 1 — Préparation (Jeudi après-midi + Vendredi) =====
==== 2.1 Affectation des serveurs ====
* **Jeudi 14h00 — COMEP** : répartition des serveurs à patcher entre les intervenants SECOPS
* Chaque intervenant reçoit sa liste pour la semaine suivante
* La phase de qualification démarre **immédiatement après le COMEP** (jeudi après-midi) et se poursuit **toute la journée de vendredi**
==== 2.2 Qualification de chaque serveur ====
Pour **chaque serveur** de la liste, l'intervenant effectue la séquence suivante (répartie sur jeudi après-midi et vendredi) :
^ # ^ Étape ^ Outil ^ Durée estimée ^
| 1 | Copier/coller nom serveur dans console Qualys | Qualys VMDR | 1 min |
| 2 | Cliquer sur le serveur → onglet Vulnérabilités | Qualys VMDR | 2 min |
| 3 | Visualiser et analyser les vulnérabilités | Qualys VMDR | 3-5 min |
| 4 | Lancer PuTTY, se connecter en SSH (clé) | PuTTY + clé | 1 min |
| 5 | Vérifier espace disque (''df -h'') | SSH | 1 min |
| 6 | Vérifier connexion satellite (''subscription-manager status'') | SSH | 1 min |
| 7 | Dry run check update (''yum check-update'') | SSH | 2-3 min |
| 8 | Vérifier accès vCenter (pour snapshot) | vSphere Web | 2 min |
| 9 | Vérifier backup Commvault (si physique) | Commvault | 2 min |
| 10 | Vérification Centreon (si production) | Centreon | 2 min |
| 11 | Si OK → marquer serveur éligible | - | 1 min |
| 12 | Contacter responsable + proposer créneaux (mail/Teams) | Mail / Teams | 5-10 min |
| 13 | Attendre validation du créneau (asynchrone) | - | variable |
**Durée cumulée par serveur : 20 à 30 minutes** de travail actif (hors attente validation asynchrone).\\
Pour un intervenant avec 20 serveurs à qualifier : **6h40 à 10h** par semaine sur la seule phase préparation.
----
===== 3. Phase 2 — Exécution (Jour J — Lundi à Jeudi) =====
Le **Jour J** d'un serveur tombe nécessairement entre **lundi et jeudi** (jamais le vendredi).\\
Cela laisse au moins 24h de recul avant le weekend pour détecter une régression post-patch.
==== 3.1 Séquence par serveur ====
^ # ^ Étape ^ Outil ^ Durée estimée ^
| 1 | Information début d'intervention (Teams) | Teams | 1 min |
| 2 | Connexion vCenter + prise de snapshot | vSphere Web | 3-5 min |
| 3 | Mise en maintenance Centreon (si prod) | Centreon | 2 min |
| 4 | Connexion SSH sur le serveur | PuTTY | 1 min |
| 5 | Snap pré-patch : services running + process + ports (''systemctl'', ''ss'') | SSH | 5 min |
| 6 | Lancer la mise à jour (''yum update -y'') | SSH | 5-15 min |
| 7 | Informer du reboot imminent (Teams) | Teams | 1 min |
| 8 | Reboot du serveur | SSH | 2-5 min |
| 9 | Attente + reconnexion | PuTTY | 3-5 min |
| 10 | Check post-patch : services + process + ports + Centreon | SSH + Centreon | 5-10 min |
| 11 | Demander validation au responsable applicatif | Mail / Teams | 5-15 min (attente) |
| 12 | Marquer le serveur comme patché (tableau de suivi) | Excel / outil | 2 min |
| 13 | Message fin d'intervention (Teams) | Teams | 1 min |
==== 3.2 Phase de nettoyage (le vendredi) ====
Le **vendredi** est consacré au nettoyage groupé de tous les serveurs patchés pendant la semaine (J+3 typique pour ceux patchés lundi/mardi) :
^ # ^ Étape ^ Outil ^ Durée estimée ^
| 14 | Suppression des **anciens snapshots vCenter** de tous les serveurs patchés la semaine | vSphere Web | 2 min/serveur |
| 15 | Suppression ancien kernel (''package-cleanup --oldkernels'') | SSH | 3 min/serveur |
Grouper le nettoyage le vendredi a deux avantages :
* **Recul suffisant** : on garde le snapshot au moins jusqu'au lendemain pour pouvoir rollback en cas d'anomalie détectée après coup
* **Contexte mental unique** : le patcheur traite tous ses snapshots d'un bloc au lieu d'y revenir serveur par serveur
**Durée cumulée par serveur (Jour J + J+3) : 40 à 70 minutes** de travail actif.\\
Pour 20 serveurs patchés dans la semaine : **13h à 23h** de charge intervenant sur l'exécution seule.
----
===== 4. Synthèse — Temps total par serveur (processus manuel) =====
^ Phase ^ Temps actif ^ Temps d'attente ^ Total ^
| Préparation (qualification + validation) | 20-30 min | 1-48h (async validation) | 20-30 min actif |
| Exécution Jour J | 35-65 min | - | 35-65 min |
| Nettoyage J+3 | 5 min | - | 5 min |
| **Total par serveur** | **60-100 min** | | **~1h15 en moyenne** |
----
===== 4.1 Réalité du temps patcheur =====
**Contraintes horaires du patcheur SECOPS :**
* Semaine de travail **Lundi → Vendredi**, **7 heures par jour** → **35 heures/semaine** au total
* **Pas de patching le vendredi** (pour éviter un weekend sous incident)
* **Lundi → Jeudi matin (28h)** : fenêtre d'exécution Jour J + fin de pré-patching entamé la semaine précédente
* **Jeudi après-midi (3,5h)** : COMEP + démarrage pré-patching de la semaine suivante
* **Vendredi (7h)** : finalisation pré-patching + suppression des snapshots des serveurs patchés la semaine + iTop / météo
* **Objectif par patcheur : 20 serveurs patchés par semaine**
=== Calcul de la charge théorique ===
^ Poste ^ Volume ^ Temps unitaire ^ Total hebdo ^
| Préparation 20 serveurs (jeudi PM + vendredi) | 20 | 20-30 min | **6h40 à 10h** |
| Exécution Jour J 20 serveurs (Lun-Jeu) | 20 | 35-65 min | **11h40 à 21h40** |
| Nettoyage snapshots/kernels (vendredi) | 20 | 5 min | **1h40** |
| **Total patching seul** | - | - | **20h à 33h** |
| **Budget hebdo total** | - | - | **35h** (dont 28h Lun-Jeu et 7h vendredi) |
**Répartition par fenêtre :**
^ Fenêtre ^ Capacité ^ Charge patching ^ Marge ^
| Lun → Jeu midi (28h) | Jour J des 20 serveurs | 12 à 22h | 6 à 16h |
| Jeu après-midi (3,5h) | COMEP + début pré-patching | 1,5 à 3h | 0,5 à 2h |
| Vendredi (7h) | Pré-patching + nettoyage + missions annexes | 4 à 7h (pré-patch + cleanup) | 0 à 3h pour iTop/météo |
Autrement dit, **le patching seul consomme 57 à 95% du temps disponible** d'un patcheur qui ne ferait que ça.
Or le patcheur doit **également** assurer d'autres missions :
=== Autres missions du patcheur ===
^ Mission ^ Fréquence ^ Charge estimée ^
| **Tickets iTop sécurisation serveur** | Permanent | 2-5 h/semaine |
| **Mise à jour agent Qualys** (ponctuelle) | Hebdomadaire | 1-3 h/semaine |
| **Mise à jour agent SentinelOne** | Hebdomadaire | 1-3 h/semaine |
| **Tour de garde — alertes SentinelOne / Defender** | Rotation | 3-6 h/semaine (sur garde) |
| **Météo sécurité** (veille + reporting hebdo) | Rotation | 2-4 h/semaine (sur météo) |
| **Total missions annexes** | - | **9 à 21 h/semaine** |
**Équation insoluble en mode manuel :**
* Temps disponible : **35h** (Lun-Ven x 7h)
* Temps patching (20 serveurs — prep + exec + cleanup) : **20-33h**
* Temps missions annexes : **9-21h**
* **Total charge : 29 à 54h/semaine**
Le patcheur est **structurellement en surcharge** dès qu'il cumule patching + garde + iTop.\\
Résultat : décalages de créneaux, vérifications raccourcies, dette sur les tickets iTop, épuisement.
**Conséquence sécurité directe — analyse des alertes SentinelOne & Defender**
Quand le patcheur est saturé par le patching manuel, il **n'a pas le temps d'analyser correctement** les alertes SentinelOne et Microsoft Defender pendant son tour de garde :
* Les alertes sont **triées en surface** (criticité apparente) au lieu d'être investiguées en profondeur
* Les **faux positifs** ne sont pas requalifiés → bruit qui cache les vrais incidents
* Les **vrais incidents** (ransomware, exfiltration, lateral movement) risquent d'être détectés **tardivement**
* L'**enrichissement de contexte** (corrélation process/réseau/user) n'est pas fait
* Les **règles de détection** ne sont pas affinées en retour d'expérience
**Coût potentiel d'une alerte ratée :** incident de sécurité majeur, fuite de données, indisponibilité — sans commune mesure avec le coût du patching manuel.
L'automatisation du patching par PatchCenter Web n'est donc pas seulement un gain de productivité : c'est une **mesure de sécurité directe** qui redonne au patcheur le temps d'exercer correctement son rôle d'analyste EDR pendant ses gardes.
=== Projection annuelle ===
Sur un parc de **~1165 serveurs** avec un cycle mensuel ciblant environ **200 serveurs/mois** (prod + prépro prioritaires) :
* **200 serveurs x 1h15 = 250 heures/mois**
* Soit l'équivalent de **1,5 à 2 ETP** consacrés aux gestes répétitifs de patching
* **Risque humain** : oubli de snapshot, oubli de Centreon, check post-patch incomplet, tableau de suivi non à jour, créneau non respecté
----
===== 5. Apport des outils d'automatisation =====
==== 5.1 SQATM .exe (déjà en production) ====
L'outil SANEF Qualys API Tags Management automatise la phase **qualification** :
^ Étape manuelle ^ Automatisé par SQATM ^ Gain ^
| Recherche Qualys + lecture des vulnérabilités | Décodeur + API Qualys | 5 min → 30 sec |
| Check SSH disque / satellite / dry-run | Audit global multi-serveurs | 5 min → 10 sec |
| Tagging automatique (ENV, OS, POS, EQT) | Tag Rules + décodeur nomenclature | 15 min → instantané |
| Identification exposition internet | Plan de patching + règles | 3 min → instantané |
**Gain estimé sur la phase préparation : 60-70%** (20 min → 6-7 min par serveur).
==== 5.2 PatchCenter Web (en cours de déploiement) ====
La plateforme web centralisera l'ensemble du workflow avec orchestration complète :
=== Automatisation de la préparation ===
* **Vue unifiée** des serveurs avec statut Qualys, OS, environnement, responsable, dernière patch
* **Audit global en arrière-plan** : SSH sur 100+ serveurs en parallèle, disque + satellite + dry-run en une passe
* **Identification correspondance prod ↔ hors-prod** automatique (signature hostname)
* **Workflow de validation** intégré : proposition de créneau + accord responsable tracé en base
* **Tags Qualys dynamiques** auto-appliqués (Tag Rules basées sur la nomenclature SANEF)
=== Automatisation du Jour J ===
* **Prise de snapshot vCenter** automatisée via API
* **Mise en maintenance Centreon** automatisée via API
* **Notifications Teams** générées automatiquement (début, reboot, fin)
* **Snap pré-patch / post-patch** scripté et archivé (services + process + ports)
* **Exécution yum update** en job asynchrone avec exclusions configurables par serveur
* **Reboot + attente reconnexion** gérés automatiquement
* **Détection des régressions** (service manquant post-reboot → alerte)
* **Tableau de suivi en temps réel** (plus de saisie Excel)
=== Automatisation du nettoyage ===
* **Liste des snapshots à supprimer J+3** avec rappel automatique
* **Nettoyage kernels obsolètes** en fin de job
=== Gouvernance ===
* **Validations prod ↔ hors-prod** bloquantes : impossibilité de patcher la prod sans validation du hors-prod correspondant
* **Historique complet** par serveur : qui a patché, quand, résultat, validation responsable
* **Audit log** exportable pour conformité
==== 5.3 Comparaison chiffrée ====
^ Étape ^ Manuel ^ SQATM .exe ^ PatchCenter Web ^
| Qualification serveur (prep) | 20-30 min | 6-10 min | 2-3 min |
| Snapshot + maintenance | 5-7 min | 5-7 min | 30 sec (automatique) |
| Snap pré/post-patch | 10-15 min | 10-15 min | 1 min (automatique) |
| Update + reboot + reconnexion | 10-25 min | 10-25 min | 10-25 min (compressible en parallèle) |
| Notifications + suivi | 5 min | 5 min | 0 (automatique) |
| Nettoyage J+3 | 5 min | 5 min | 1 min (automatique) |
| **Total par serveur** | **60-100 min** | **40-70 min** | **15-30 min** |
| **Gain vs manuel** | - | **30%** | **70-75%** |
**Projection sur 200 serveurs/mois :**
* **Manuel** : 250 h/mois (~1,5 à 2 ETP)
* **SQATM .exe** : 170 h/mois (~1 ETP, gain = 80h/mois)
* **PatchCenter Web** : 75 h/mois (~0,5 ETP, gain = 175h/mois)
----
==== 5.4 Impact hebdomadaire sur le patcheur (objectif 20 serveurs/semaine) ====
^ Scénario ^ Patching seul ^ Budget restant (sur 35h) ^ Missions annexes couvertes ? ^
| **Manuel** | 20h à 33h | +2h à +15h | Non — surcharge garantie en période de garde ou météo |
| **SQATM .exe** | 14h à 23h | +12h à +21h | Partiellement — tient si pas de garde ou pas de météo |
| **PatchCenter Web** | 5h à 10h | +25h à +30h | **Oui** — le patcheur peut assurer patching + garde + météo + iTop sans surcharge |
**Lecture :**\\
Avec PatchCenter Web, un patcheur qui traite ses 20 serveurs hebdomadaires libère **18 à 23 heures** par semaine pour :
* Absorber sereinement les tickets iTop de sécurisation
* Assurer le tour de garde SentinelOne / Defender sans décaler le patching
* Produire la météo sécurité hebdomadaire
* Traiter les MAJ d'agents Qualys / SentinelOne en masse
* Ou **augmenter la cadence** (25-30 serveurs/semaine) si besoin opérationnel
----
===== 6. Bénéfices qualitatifs (au-delà du temps) =====
^ Axe ^ Bénéfice PatchCenter Web ^
| **Fiabilité** | Plus d'oubli de snapshot, de maintenance Centreon ou de marquage de statut |
| **Traçabilité** | Historique complet par serveur, exportable pour audit |
| **Gouvernance** | Workflow de validation prod ↔ hors-prod bloquant |
| **Scalabilité** | 1 intervenant peut piloter 20+ serveurs en parallèle |
| **Onboarding** | Nouveau patcheur opérationnel en quelques jours (processus guidé) |
| **Qualité** | Snap pré/post standardisé → détection fiable des régressions |
| **Conformité** | Tags Qualys automatiques → reporting KPI sans retraitement |
| **Communication** | Notifications Teams standardisées → meilleure visibilité projet |
----
===== 7. Feuille de route =====
**Avancement actuel :**
* **SQATM .exe v2.0.0** : en production, utilisé pour le tagging et l'audit
* **PatchCenter Web** : développement actif
* Modules livrés : catalogue serveurs, correspondance prod/hors-prod, exclusions patchs, workflow validations, agents Qualys, déploiement agents
* Modules à finaliser : orchestration vCenter, orchestration Centreon, intégration Teams native, exécution patching end-to-end
* **Intégration iTop bidirectionnelle** : opérationnelle (synchronisation serveurs / applications / statuts)
* **Authentification LDAP AD SANEF** : prête (multi-profils : admin, coordinateur, opérateur, viewer)
----
===== 8. Conclusion =====
Le processus de patching manuel actuel est **efficace mais coûteux** : 60 à 100 minutes par serveur, avec un risque humain non négligeable sur les gestes répétitifs (snapshot, maintenance, suivi). La montée en charge progressive du parc et les exigences de conformité (Qualys, audit) rendent l'automatisation **incontournable**.
Avec un objectif de **20 serveurs patchés par patcheur et par semaine**, un budget horaire de **35h (Lun-Ven, 7h/jour — mais pas de patching le vendredi, dédié au pré-patching + nettoyage snapshots + missions annexes)**, et des missions annexes obligatoires (tickets iTop, MAJ agents Qualys/SentinelOne, tour de garde, météo) qui représentent **9 à 21 heures/semaine**, le mode manuel place structurellement le patcheur en surcharge.
Les outils en place et à venir apportent un gain **mesurable** :
* **SQATM .exe** divise par 1,5 le temps de préparation
* **PatchCenter Web** divise par 3 à 4 le temps global par serveur
* **PatchCenter Web** libère **25 à 30 heures/semaine** par patcheur, de quoi absorber sereinement les missions annexes **et** augmenter la cadence si nécessaire
L'investissement dans l'automatisation ne se résume pas à un gain de temps : il garantit la **fiabilité**, la **traçabilité**, la **scalabilité** du processus, et surtout la **soutenabilité** du métier de patcheur SECOPS à SANEF.
**Enjeu sécurité stratégique :** le temps libéré par l'automatisation permet au patcheur d'exercer correctement son rôle d'**analyste EDR** sur les alertes SentinelOne et Defender pendant ses gardes. En mode manuel, ces alertes sont traitées en surface faute de temps — un ransomware, une exfiltration ou un lateral movement peut passer inaperçu. Automatiser le patching, c'est donc aussi **renforcer directement la capacité de détection et de réponse aux incidents** de SANEF.
----
//— SANEF DSI / Sécurité Opérationnelle — Processus Patching & Automatisation — {date}//