Maintien en condition de sécurité (MCS) : définition et méthode

Un système d’information sécurisé le jour de sa mise en production ne l’est plus six mois plus tard. Les correctifs s’accumulent, des versions arrivent en fin de support, des configurations dérivent au fil des interventions. Le maintien en condition de sécurité, ou MCS, désigne l’ensemble des activités qui empêchent ce décrochage.

Qu’est-ce que le maintien en condition de sécurité ?

Le MCS regroupe les actions qui maintiennent le niveau de sécurité d’un système d’information dans le temps, une fois celui-ci en service. Il ne s’agit pas de déployer de nouvelles protections, mais de faire en sorte que celles déjà en place restent efficaces face à des menaces et à un parc qui évoluent tous les deux.

Concrètement, le MCS couvre la mise à jour des systèmes et des applications, le traitement des vulnérabilités publiées, le suivi des fins de support, le contrôle des configurations de sécurité, la revue des comptes et des droits, la journalisation, et la vérification que les sauvegardes se restaurent réellement.

Le terme vient du vocabulaire des grands systèmes publics et de la défense, où l’on distingue depuis longtemps le maintien en condition opérationnelle du maintien en condition de sécurité. Il s’est diffusé dans le secteur privé avec la montée des obligations réglementaires.

MCO et MCS : deux objectifs différents sur le même système

La confusion entre les deux est fréquente, et elle a des conséquences concrètes sur le contenu d’un contrat d’infogérance.

• Le maintien en condition opérationnelle (MCO) vise la disponibilité et la performance. Sa question est : le service fonctionne-t-il, et dans les temps promis ?
• Le maintien en condition de sécurité (MCS) vise la résistance aux attaques. Sa question est : le système reste-t-il difficile à compromettre, malgré les vulnérabilités découvertes depuis sa mise en service ?

Les deux se croisent souvent, mais pas toujours dans le même sens. Un serveur qui n’a pas été redémarré depuis huit mois affiche une disponibilité exemplaire au titre du MCO, tout en accumulant des correctifs non appliqués au titre du MCS. À l’inverse, une fenêtre de maintenance pour appliquer un correctif critique dégrade momentanément la disponibilité pour améliorer la sécurité.

C’est pourquoi un contrat qui ne parle que de GTI, de GTR et de taux de disponibilité ne dit rien du MCS. Ce sont deux engagements distincts, à formuler séparément. Si le sujet vous intéresse côté disponibilité, notre page sur le maintien d’infrastructure cloud hybride et on-premise détaille le versant MCO.

Ce que le MCS couvre concrètement

Les correctifs de sécurité. Systèmes d’exploitation, hyperviseurs, firmwares, navigateurs, applications métier, équipements réseau. Le poste de travail est souvent bien couvert, les équipements périphériques beaucoup moins.

Le traitement des vulnérabilités. Une CVE publiée n’est pas toujours corrigeable immédiatement. Le MCS impose de savoir si l’on est exposé, à quelle échéance le correctif sera disponible, et quelle mesure de contournement s’applique en attendant.

L’obsolescence. Windows 10, Exchange Server 2016 et Exchange Server 2019 sont sortis du support Microsoft le 14 octobre 2025. Un composant hors support ne reçoit plus de correctif de sécurité : aucune politique de mise à jour, aussi rigoureuse soit-elle, ne compense cela. Le suivi des fins de support fait donc partie intégrante du MCS.

Les configurations. Le durcissement appliqué à l’installation se dégrade au fil des dépannages, des exceptions accordées et des migrations. Le contrôle périodique des écarts par rapport au référentiel est un exercice distinct du patching, souvent oublié. Notre guide sur le durcissement des postes de travail Windows détaille la partie poste.

Les comptes et les droits. Comptes de départs non désactivés, comptes de service surprivilégiés, droits accordés pour un projet terminé depuis deux ans. La revue régulière relève du MCS, et s’appuie sur les outils de gestion des accès à privilèges.

La journalisation et la détection. Des journaux non collectés, ou collectés mais non exploités, laissent une compromission se dérouler sans témoin. Le MCS vérifie que la collecte fonctionne, sur les bons composants, et que quelqu’un regarde.

Les sauvegardes. Une sauvegarde qui s’exécute sans erreur n’est pas une sauvegarde restaurable. Le test de restauration est la seule preuve, et il a une date de péremption.

Ce que la réglementation attend

Le MCS n’est pas une bonne pratique optionnelle, c’est une attente formalisée dans deux textes de référence.

Le guide d’hygiène informatique de l’ANSSI (version 2.0, janvier 2017) consacre plusieurs de ses 42 mesures au sujet : la mesure 34 demande de définir une politique de mise à jour des composants du système d’information, la mesure 35 d’anticiper la fin de la maintenance des logiciels et systèmes et de limiter les adhérences logicielles, la mesure 36 d’activer et configurer les journaux des composants les plus importants, la mesure 37 de définir et appliquer une politique de sauvegarde des composants critiques.

La directive NIS2 range le sujet dans son article 21, qui liste les mesures minimales de gestion des risques. Le point e) vise la sécurité de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris le traitement et la divulgation des vulnérabilités. Autrement dit, le maintien en condition de sécurité y est nommé comme une obligation, pas comme une recommandation. Pour savoir si votre entreprise entre dans le périmètre, voir notre article NIS2 : directive, conformité et obligations.

Pourquoi le MCS décroche, même dans des entreprises bien équipées

L’inventaire est le premier point de rupture. On ne met pas à jour ce que l’on ne sait pas posséder, et l’inventaire réel diffère presque toujours de l’inventaire documenté, en particulier sur les machines virtuelles et les équipements réseau.

Vient ensuite la fenêtre de maintenance. Dans une PME sans redondance, appliquer un correctif suppose d’interrompre un service, donc d’obtenir un créneau et un accord métier. Faute d’arbitrage clair, le correctif attend.

Enfin, les dépendances applicatives. Une application métier certifiée sur une seule version de runtime bloque la mise à jour de tout le serveur qui l’héberge. Le MCS impose alors de traiter le sujet à la racine, par une isolation ou une migration, et non de repousser indéfiniment.

Mettre en place un MCS qui tient

1. Inventorier. Actifs, versions, dates de fin de support, criticité métier. Sans cette base, tout le reste est déclaratif.
2. Classer. Tous les composants ne méritent pas le même effort. Un serveur exposé sur internet et un poste de test ne suivent pas le même rythme.
3. Écrire la politique de mise à jour. Délais cibles selon la criticité de la vulnérabilité, responsable désigné, fenêtres validées avec les métiers, procédure de retour arrière.
4. Organiser la veille. Suivre les publications de vulnérabilités qui concernent votre parc réel, pas la totalité de l’actualité cyber.
5. Contrôler les écarts. Comparer périodiquement les configurations en production au référentiel de durcissement.
6. Tester les restaurations. À intervalle fixe, sur un périmètre tournant, avec un compte rendu écrit.
7. Mesurer. Taux de conformité du parc, délai moyen d’application des correctifs critiques, nombre de composants hors support, âge de la dernière restauration testée.

Un audit de sécurité donne la photo de départ. Le MCS, lui, est ce qui empêche cette photo de se dégrader une fois les recommandations appliquées.

Internaliser ou externaliser son MCS

Le MCS est une activité récurrente, à faible visibilité et à forte conséquence. C’est précisément le profil des tâches qui glissent quand l’équipe interne absorbe les urgences du quotidien.

L’internalisation se défend quand l’équipe est dimensionnée pour absorber la charge de veille et de patching sans arbitrage permanent, et quand le parc est homogène. L’externalisation se justifie quand la couverture doit dépasser les heures ouvrées, quand la détection suppose des analystes disponibles en continu, ou quand la démonstration de conformité doit être produite pour un tiers, assureur, client grand compte ou autorité.

Chez IT Systèmes, le MCS s’appuie sur la sécurité d’infrastructure pour la gestion des correctifs et des vulnérabilités, sur la supervision pour la détection des dérives, et sur notre SOC français pour la surveillance continue, l’investigation et la remédiation par des analystes. C’est la même chaîne, du correctif appliqué à l’incident traité.

Questions fréquentes

Que veut dire MCS en informatique ?

MCS signifie maintien en condition de sécurité. Le terme désigne l’ensemble des activités qui maintiennent dans la durée le niveau de sécurité d’un système d’information en service : correctifs, traitement des vulnérabilités, suivi des fins de support, contrôle des configurations, revue des droits, journalisation et tests de restauration.

Quelle différence entre MCO et MCS ?

Le MCO, maintien en condition opérationnelle, porte sur la disponibilité et la performance du service. Le MCS porte sur sa résistance aux attaques. Un système peut être parfaitement disponible et très vulnérable, ce qui explique qu’un engagement de disponibilité ne vaut pas engagement de sécurité.

Le MCS est-il obligatoire ?

Il l’est pour les entités régulées par la directive NIS2, dont l’article 21 cite la sécurité de la maintenance des systèmes et le traitement des vulnérabilités parmi les mesures minimales. Pour les autres entreprises, il relève des bonnes pratiques, notamment des mesures 34 à 37 du guide d’hygiène informatique de l’ANSSI, et il conditionne souvent la couverture d’une assurance cyber ou l’entrée au référencement d’un grand donneur d’ordre.

À quelle fréquence appliquer les correctifs de sécurité ?

Il n’existe pas de fréquence unique. La pratique consiste à fixer des délais cibles par niveau de criticité, par exemple un traitement en urgence pour une vulnérabilité critique exploitée activement sur un composant exposé, et un rythme mensuel pour le reste du parc. L’essentiel est que ces délais soient écrits, connus et mesurés.

Que faire d’un logiciel qui n’est plus supporté ?

Trois options seulement : migrer vers une version supportée, isoler le composant du reste du réseau en attendant sa migration, ou accepter formellement le risque avec la direction. Maintenir un composant hors support sans mesure compensatoire ni décision écrite est le scénario qui se retourne le plus souvent contre l’entreprise après un incident.

Peut-on confier le MCS à son infogéreur ?

Oui, à condition que le contrat le dise explicitement. Beaucoup de contrats d’infogérance couvrent la disponibilité sans détailler le périmètre de sécurité. Vérifiez ce qui est inclus : liste des composants patchés, délais d’application, gestion des fins de support, tests de restauration, et reporting associé.

Le MCS de votre parc n’a pas été revu depuis longtemps ? Parlons-en.

‍

‍