Modélisation de la criticité des actifs et cartographie des dépendances métier
Demander à chaque propriétaire d’application si son serveur est « critique » produit invariablement deux extrêmes : soit tout est déclaré vital par précaution, soit un composant d’infrastructure transverse (DNS interne, annuaire, passerelle) est sous-évalué faute de visibilité directe côté métier.
Les scores de risque mélangeaient la gravité technique des CVE et une note d’importance serveur saisie sans grille commune, rendant les arbitrages contestables en comité.
Séparation stricte du référentiel de criticité d’actif et adoption d’un questionnaire fermé fondé sur les critères DICP et l’héritage des dépendances techniques.
Classification stable, justifiable devant les métiers et réutilisable aussi bien pour la gestion des vulnérabilités que pour la réponse à incident.
Le point clé de cette modélisation a été la règle d’héritage de criticité : un serveur technique de soutien hérite automatiquement du palier minimal du processus métier le plus sensible qui en dépend sans redondance. Ainsi, un serveur de fédération SSO ou un relais interne ne peut plus être classé secondaire s’il conditionne l’accès aux applications vitales.