Patches mensuels Windows et macOS : SLA pratique pour 100 endpoints

Un parc non patché est une dette technique avec une date d'échéance inconnue

En 2024, la fenêtre médiane entre la publication d'un CVE critique et sa première exploitation active est tombée à moins de 5 jours selon les rapports du NCSC. Pour une PME romande opérant 100 endpoints sans SLA formalisé, chaque Patch Tuesday non traité sous 72 heures représente une exposition nette. La question n'est pas si un patch doit être appliqué, mais dans quel délai, par qui, et avec quelle preuve d'audit.

Pourquoi un SLA de patching — et non un simple calendrier

Un calendrier dit « on patche chaque deuxième mardi du mois ». Un SLA fixe un engagement contractuel interne : délai maximal d'application par criticité, taux de couverture minimal, procédure d'exception documentée, et indicateur de reporting. La différence est vérifiable en cas d'incident, d'audit ISO 27001 ou de demande de la PFPDT dans le cadre de la nLPD.

Ce que la nLPD impose indirectement

La nLPD (RS 235.1) n'impose pas de délai de patching explicite, mais son article 8 exige des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Un endpoint avec une vulnérabilité critique non corrigée depuis 30 jours constitue un manquement à ce principe. En cas de violation de données, l'absence de SLA documenté aggrave la responsabilité du responsable du traitement.

Ce que les CIS Benchmarks recommandent

Les CIS Benchmarks (contrôle 7 — Continuous Vulnerability Management) préconisent :

• Vulnérabilités CVSS ≥ 9.0 (critique) : correction sous 24 à 48 heures.
• Vulnérabilités CVSS 7.0–8.9 (haute) : correction sous 7 jours.
• Vulnérabilités CVSS 4.0–6.9 (moyenne) : correction sous 30 jours.
• Vulnérabilités CVSS < 4.0 (basse) : correction sous 90 jours ou lors du prochain cycle planifié.

Ces seuils constituent une base solide pour rédiger un SLA interne opposable à un auditeur ISO 27001 ou à un partenaire assureur cyber.

Architecture de patching pour 100 endpoints mixtes (Windows + macOS)

Segmentation du parc

Sur un parc de 100 endpoints typique d'une PME romande, on trouve généralement :

• 60 à 70 postes Windows 11 (23H2 ou 24H2) — gérés via Windows Autopilot + Microsoft Intune ou solution MDM équivalente.
• 25 à 35 Mac (macOS 14 Sonoma ou macOS 15 Sequoia) — enrôlés dans Apple Business Manager (ABM) avec profil de supervision activé.
• 5 à 10 appareils mobiles Android (MDM Android Enterprise) pour accès email et VPN.

Chaque catégorie suit un pipeline de patching distinct, avec ses propres délais de qualification.

Pipeline Windows : Patch Tuesday en 4 étapes

1. J+0 (Patch Tuesday) : import automatique des mises à jour dans Windows Update for Business ou WSUS. Le DSI ou le responsable endpoints reçoit une alerte automatisée.
2. J+1 à J+2 : qualification sur un groupe pilote de 5 à 10 machines (ring 0). On vérifie les régressions applicatives critiques (ERP, outils métier).
3. J+3 à J+7 : déploiement sur ring 1 (50 % du parc). Fenêtre de déploiement planifiée hors heures de bureau (22h00–05h00) pour éviter les interruptions.
4. J+8 à J+14 : déploiement ring 2 (parc complet). Les exceptions documentées (machines hors réseau, postes en production critique) basculent en patch manuel avec ticket ITSM.

Pipeline macOS : ABM + MDM supervisé

1. Publication Apple (variable) : les mises à jour de sécurité macOS ne suivent pas un calendrier fixe. Configurer une alerte sur le flux RSS officiel Apple Security Updates.
2. J+1 : test sur 3 à 5 Mac pilotes. Vérification de la compatibilité des outils métier (solutions de signature électronique, accès VPN EAP-TLS, agents de sécurité endpoint).
3. J+3 à J+7 : déploiement MDM supervisé avec notification utilisateur 24h en avance. Le profil MDM force le redémarrage dans une fenêtre définie si l'utilisateur diffère plus de 72h.
4. J+14 : vérification de conformité automatisée. Les Mac non conformes sont signalés au DSI avec blocage d'accès conditionnel si le score de risque dépasse un seuil défini.

Gestion des exceptions

Toute exception au SLA doit être documentée avec : identifiant endpoint, motif technique, responsable, date de revue, et plan de remédiation compensatoire (isolement réseau, surveillance renforcée). Sans cette documentation, l'exception devient une vulnérabilité non tracée.

Métriques SLA : ce que vous devez mesurer

Un SLA sans indicateur est une lettre d'intention. Voici les KPI minimaux pour un rapport mensuel :

Taux de couverture par sévérité

• Critique (CVSS ≥ 9.0) : objectif ≥ 98 % dans les 48h. Tout écart déclenche une alerte immédiate au RSSI.
• Haute (CVSS 7–8.9) : objectif ≥ 95 % sous 7 jours.
• Moyenne : objectif ≥ 90 % sous 30 jours.

Mean Time to Patch (MTTP)

Calculé endpoint par endpoint : date de publication CVE → date d'application confirmée. Un MTTP moyen supérieur à 15 jours sur des vulnérabilités hautes signale un dysfonctionnement du pipeline.

Taux d'exceptions non conformes

Nombre d'exceptions sans plan de remédiation / total d'exceptions. Objectif : 0 %. Chaque exception non documentée est un risque résiduel non assumé.

Rapport mensuel : destinataires et format

Le rapport mensuel doit aller au DSI, au RSSI (si distinct), et, dans les structures régulées (assurances, banques soumises à la FINMA), à la direction. Format recommandé : tableau de bord avec feux tricolores par catégorie, liste des exceptions actives, et tendance MTTP sur 3 mois.

Cas pratique : fiduciaire vaudoise, 85 endpoints

Contexte

Fiduciaire basée à Lausanne, 42 collaborateurs, 85 endpoints actifs : 55 postes Windows 11 23H2, 28 MacBook Pro (macOS 14.6), 2 serveurs Windows Server 2022 exclus du périmètre MDM. Le parc traite des données personnelles et fiscales de plusieurs centaines de clients — exposition nLPD directe. Avant la mise en place du SLA, le MTTP moyen était de 23 jours pour les vulnérabilités hautes. Aucun reporting formalisé n'existait.

Mise en place du SLA en 6 étapes

1. Inventaire et classification (J-30) : audit complet via outil MDM — version OS, version firmware, dernier patch appliqué, statut de chiffrement (BitLocker / FileVault). Export CSV de 85 lignes, nettoyage des doublons, 3 endpoints hors parc identifiés et réenrôlés.
2. Rédaction du SLA interne (J-20) : document d'une page, validé par le DSI et l'associé gérant. Seuils CIS Benchmarks adoptés sans modification. Clause d'exception : les postes en déplacement international de plus de 14 jours bénéficient d'un délai étendu à J+21 avec obligation de VPN forcé.
3. Configuration des rings de déploiement (J-15) : ring 0 (5 Mac + 5 PC — profils techniques), ring 1 (40 endpoints — collaborateurs standards), ring 2 (35 endpoints — associés et direction). Fenêtres de maintenance configurées : 22h30–05h30, lundi–vendredi.
4. Automatisation des alertes (J-10) : alerte email automatique au DSI à J+1 après chaque Patch Tuesday ou publication Apple avec CVSS ≥ 7.0. Ticket ITSM créé automatiquement, assigné au responsable endpoints.
5. Premier cycle pilote (J0) : Patch Tuesday de septembre 2024. 3 vulnérabilités hautes (CVE-2024-38189, CVE-2024-38141, CVE-2024-38193 — noyau Windows). Ring 0 patché en 26 heures. Ring 1 en 5 jours. Ring 2 en 11 jours. MTTP global : 8,4 jours. 2 exceptions documentées (PC sous ISO en déplacement).
6. Rapport J+30 : couverture critique 100 %, couverture haute 97,6 % (2 endpoints en exception documentée), MTTP moyen 8,4 jours vs objectif ≤ 10 jours. Résultat communiqué aux associés en 1 page. Coût opérationnel estimé du cycle : 6 heures DSI + 1 heure helpdesk = environ CHF 900 en coût interne (taux horaire chargé DSI CHF 120, helpdesk CHF 80).

Retour sur investissement estimé

La fiduciaire avait souscrit une cyberassurance avec franchise de CHF 25 000 et prime annuelle de CHF 4 800. La mise en conformité SLA (documentée, avec MTTP < 10 jours) a permis de renégocier la prime à CHF 3 600 lors du renouvellement annuel — soit CHF 1 200 d'économie annuelle pour un coût de mise en place estimé à CHF 2 500 (temps interne + ajustements MDM). Retour à l'équilibre en 25 mois, sans compter la réduction du risque d'incident.

Récapitulatif opérationnel

• Définir les seuils SLA par criticité CVSS — adopter les seuils CIS Benchmarks comme base (48h critique, 7j haute, 30j moyenne, 90j basse) et les formaliser dans un document validé par la direction.
• Segmenter le parc en rings — minimum 2 rings (pilote + production), idéalement 3. Ring 0 : 5–10 % du parc, profils techniques. Jamais déployer en masse sans qualification préalable.
• Automatiser les alertes de publication — flux RSS Apple Security, alertes Microsoft Security Response Center, alerte NCSC pour les CVE critiques. Délai entre publication et premier ticket : ≤ 4 heures.
• Documenter chaque exception — identifiant endpoint, motif, responsable nommé, date de revue maximale, mesure compensatoire. Zéro exception non tracée.
• Mesurer le MTTP mensuellement — calculé par endpoint et agrégé par sévérité. Tendance sur 3 mois obligatoire dans le rapport de direction.
• Vérifier la conformité post-déploiement — scan de conformité MDM à J+14 minimum. Les endpoints non conformes déclenchent une alerte et, selon la politique, un accès conditionnel restreint.
• Intégrer le SLA dans le plan de réponse aux incidents — en cas d'exploitation active d'une CVE (alerte NCSC), le SLA passe en mode dégradé : patch critique en 4 heures, isolation préventive des endpoints non patchés.
• Revoir le SLA annuellement — à chaque renouvellement de cyberassurance et après tout incident de sécurité, même mineur.
• Conserver les preuves d'application — logs MDM horodatés, exportables au format CSV ou JSON, conservés 12 mois minimum pour audit nLPD ou ISO 27001.
• Aligner avec le NIST CSF — le SLA de patching couvre les fonctions Identify (inventaire), Protect (hardening) et Detect (conformité). Le documenter comme tel simplifie les audits cadre NIST Cybersecurity Framework.

SynGuard accompagne les PME romandes dans la mise en place de ces pipelines de patching sur des parcs mixtes Windows et macOS, avec reporting MDM intégré et documentation SLA prête pour audit.

Sources

• nLPD — Loi fédérale sur la protection des données (RS 235.1), fedlex.admin.ch — texte consolidé de la nouvelle loi suisse sur la protection des données, en vigueur depuis le 01.09.2023.
• Centre national pour la cybersécurité (NCSC), ncsc.admin.ch — alertes techniques, conseils aux PME, signalement d'incidents.
• CIS Benchmarks, cisecurity.org — référentiels de configuration sécurisée et contrôles de gestion des vulnérabilités (contrôle 7).
• NIST Cybersecurity Framework (CSF), nist.gov — cadre de référence pour la gestion du risque cybersécurité, fonctions Identify / Protect / Detect.
• Préposé fédéral à la protection des données et à la transparence (PFPDT), edoeb.admin.ch — autorité suisse de contrôle nLPD, recommandations sur les mesures techniques appropriées.