MCC : pourquoi le maintien en condition de confiance change tout à la maintenance applicative

Quand un système “marche”, il traite les requêtes, renvoie les bonnes réponses, ne tombe pas en erreur. C’est la définition opérationnelle de la maintenance applicative classique. Et c’est insuffisant.

Un système peut “marcher” parfaitement au sens fonctionnel, et simultanément :

• Être vulnérable à une CVE critique découverte il y a 3 mois
• Embarquer une dépendance dont la licence a changé et qui crée un risque juridique
• Avoir des logs qui ne permettent plus de reconstituer un incident
• Utiliser un algorithme de chiffrement déprécié qui sera cassé dans 2 ans
• Dériver progressivement de sa baseline de sécurité sans que personne ne s’en aperçoive

Le Maintien en Condition de Confiance (MCC) est la réponse à cette réalité : maintenir la sécurité, la conformité et la maîtrise d’un système dans le temps, pas seulement sa disponibilité.

La maintenance applicative classique et ses limites

La maintenance applicative couvre typiquement :

• La correction de bugs
• Les mises à jour fonctionnelles mineures
• La surveillance de la disponibilité et des performances
• Le support utilisateur

C’est nécessaire. Ce n’est pas suffisant pour des systèmes critiques dans des environnements réglementés ou à exposition cyber élevée.

Le problème fondamental : la maintenance classique est réactive. Elle répond à des événements visibles : une erreur, une plainte utilisateur, un crash. Elle ne voit pas les risques latents qui n’ont pas encore produit de symptôme.

Le paysage cyber a changé de façon fondamentale. Les cycles d’exploitation des vulnérabilités se sont compressés : entre la publication d’une CVE et les premiers exploits en production, les délais sont passés de semaines à jours, parfois heures. Une posture réactive sur la sécurité est structurellement en retard sur l’attaque.

Ce que le MCC couvre en plus

Veille et gestion des vulnérabilités

Toute dépendance logicielle est un vecteur de risque potentiel. Une bibliothèque parfaitement saine le mois dernier peut être compromise aujourd’hui (supply chain attack à la Log4Shell, à la xz-utils).

Le MCC inclut :

• SBOM (Software Bill of Materials) : inventaire exhaustif et à jour des composants du système : bibliothèques, frameworks, conteneurs, modules tiers
• Surveillance continue des CVE : corrélation automatisée entre le SBOM et les nouvelles vulnérabilités publiées (NVD, ANSSI, CERT-FR)
• Processus de remédiation priorisé : classification des vulnérabilités selon la criticité et l’exploitabilité réelle, plan d’application des correctifs avec SLA définis

La question n’est pas “avons-nous des vulnérabilités ?” (la réponse est toujours oui). La question est “lesquelles sont exploitables dans notre contexte, dans quel délai devons-nous les traiter, et comment ?”

Maintien en condition de conformité réglementaire

Un système peut être conforme RGPD au moment de son déploiement et ne plus l’être 18 mois plus tard si le contexte réglementaire a évolué.

Le MCC intègre une surveillance réglementaire adaptée au secteur : nouvelles lignes directrices CNIL, évolutions DORA, nouvelles exigences LCB-FT, mises à jour des référentiels ANSSI. À chaque évolution significative, un gap analysis évalue l’impact sur le système et déclenche si nécessaire un chantier de mise en conformité.

C’est particulièrement critique dans les secteurs financiers et de santé, où les exigences réglementaires évoluent fréquemment et où le coût de non-conformité est élevé (sanctions, perte d’agrément, risque réputationnel).

Surveillance de la dérive de sécurité

Les systèmes dérivent de leur baseline de sécurité au fil du temps, souvent de façon invisible :

• Un compte de service créé pour un projet ponctuel, jamais supprimé
• Un port ouvert pour un test, jamais refermé
• Des droits trop larges accordés lors d’un incident, jamais révisés
• Une configuration de sécurité modifiée pour débloquer une situation, jamais revertée

La remédiation de cette dérive requiert :

• Une baseline de configuration documentée au déploiement initial
• Des scans de conformité réguliers qui comparent l’état courant à la baseline (CIS Benchmarks, STIG selon le contexte)
• Un processus de revue des droits et accès périodique (Privilege Access Review)

Revue des secrets et credentials

Les secrets (clés API, certificats, secrets de configuration) ont une durée de vie. Les certificats expirent. Les clés d’API non renouvelées peuvent être compromises.

Le MCC inclut :

• Inventaire des secrets avec dates d’expiration
• Rotation proactive avant expiration (pas en urgence le jour J)
• Détection des secrets hardcodés dans le code source (git-secrets, truffleHog)
• Surveillance des alertes de compromission des plateformes tierces (Have I Been Pwned APIs, alertes GitHub)

Maintien de l’auditabilité

Un système dont les logs ne permettent pas de reconstituer un incident est un système non auditable. Et un système non auditable n’est pas conforme aux exigences réglementaires de la plupart des secteurs sensibles.

Le MCC surveille :

• Intégrité des logs : les logs sont-ils complets, cohérents, non altérables ?
• Couverture des événements loggés : toutes les actions significatives sont-elles tracées ?
• Durée de rétention : les logs sont-ils conservés conformément aux obligations réglementaires ?
• Exploitabilité : en cas d’incident, peut-on reconstituer la chronologie en un temps raisonnable ?

Le MCC dans un système vieillissant

Le MCC prend une dimension particulière sur des systèmes legacy. Deux dynamiques s’accumulent :

La dette de sécurité : les systèmes anciens embarquent des composants dont le support de sécurité a expiré. Java 8 end-of-life, OpenSSL en version obsolète, des bibliothèques sans mainteneur actif. Chaque composant non maintenu est une surface d’attaque potentiellement non patchée.

La perte de maîtrise documentaire : sur un système de 10 ans d’âge, la documentation originale a souvent disparu, les développeurs initiaux sont partis, et personne ne sait exactement ce que fait tel module ou pourquoi telle configuration est ainsi. Cette perte de maîtrise rend toute intervention risquée.

Le MCC sur un système legacy commence donc souvent par un travail de reconstitution : cartographie des composants, reverse engineering des configurations, re-documentation des flux. C’est un investissement, mais c’est le prérequis à toute capacité de réaction rapide face à une vulnérabilité.

Comment le MCC s’organise

Un rythme de surveillance continu

Le MCC n’est pas un audit annuel. C’est une surveillance permanente avec des rythmes différenciés :

• Continu : surveillance des CVE, monitoring des logs, alertes de dérive de configuration
• Hebdomadaire : revue des alertes, statut des remédiations en cours
• Mensuel : rapport de santé sécurité, métriques clés (nombre de CVE ouvertes par criticité, délai de remédiation moyen)
• Trimestriel : revue des droits et accès, test de la procédure de réponse à incident
• Annuel : test de pénétration, revue complète de la baseline de sécurité

Des SLA de remédiation définis

La priorisation des vulnérabilités doit produire des engagements concrets :

Ces SLA sont des engagements contractuels dans un dispositif MCC sérieux.

Un reporting orienté décision

Le reporting MCC est destiné à des décideurs qui ne sont pas forcément techniques. Il doit répondre à trois questions :

• Où sommes-nous ? (posture de sécurité actuelle, comparée à la période précédente)
• Qu’est-ce qui a été traité ? (remédiations effectuées, conformité maintenue)
• Qu’est-ce qui reste à traiter ? (plan d’action, priorisation, ressources nécessaires)

Conclusion

La maintenance applicative garantit que votre système fonctionne. Le MCC garantit que votre système est digne de confiance, pour vos utilisateurs, pour vos régulateurs, et pour vous-même.

Dans un contexte où les cyberattaques ciblent spécifiquement les systèmes mal maintenus, où les régulateurs exigent des preuves de maîtrise continue, et où la perte de confiance d’un client ou d’un partenaire peut être irréversible, cette distinction n’est plus académique. Elle est opérationnelle.

Vos systèmes critiques ont-ils un dispositif de MCC à la hauteur de leur exposition ? Évaluons votre situation.