Pourquoi les actifs de votre SMSI ne sont pas une copie de votre CMDB

Presque chaque organisation qui se lance dans un SMSI arrive au même point. Il existe déjà une CMDB avec des milliers d'éléments de configuration, soigneusement tenue par l'équipe d'exploitation, et la question s'impose d'elle-même. Reprenons-nous cette liste dans le SMSI ? La réponse est non. Qui le fait quand même se retrouve en une semaine avec un registre que personne n'entretient et une colonne de classification qui reste vide. Comprendre la différence entre les deux registres vous épargne des mois de travail. Pour les entités financières soumises à DORA, le tableau est plus nuancé, et nous y revenons séparément plus loin.

Un mot, deux significations

Dans l'informatique, le mot « actif » porte deux significations qui partagent par hasard le même terme.

Dans le monde de l'exploitation, celui d'ITIL et de l'ISO/IEC 20000, un élément de configuration est tout ce que vous devez connaître pour fournir et modifier un service : serveurs, machines virtuelles, composants réseau, licences et interfaces. Le registre existe pour maîtriser les changements, les incidents et la capacité. L'exhaustivité et l'actualité en sont les principales exigences de qualité.

Dans le monde de la sécurité, celui de l'ISO/IEC 27001 et des référentiels de l'ANSSI, un actif est quelque chose auquel appartient un propriétaire capable d'en décider. La mesure 5.9 demande un inventaire des informations et autres actifs associés, avec un propriétaire par entrée. Cette exigence de propriété n'a rien d'administratif, car sans propriétaire, personne ne peut accepter le risque résiduel.

Les deux registres répondent donc à des questions différentes. Votre CMDB répond à la question de ce que vous exploitez et de la manière dont tout s'articule. Votre registre SMSI répond à la question de ce que vous devez protéger, à quel niveau, et de qui en décide. Ce ne sont pas deux versions de la même liste, mais deux listes à des niveaux d'abstraction différents.

Les chercheurs l'ont signalé très tôt. Oppenheim, Stenson et Wilson ont montré dans leurs travaux sur l'information comme actif que l'information se comporte autrement qu'un actif classique : elle ne s'use pas, elle peut exister à plusieurs endroits à la fois, et elle tire sa valeur du contexte dans lequel elle est utilisée. Une logique d'inventaire comptable ou technique s'y prête mal.

Les quatre couches

Il est utile d'ordonner les actifs en quatre couches. Chaque couche a son propre type de propriétaire et son propre type de question.

1. Le processus métier, par exemple la paie, l'inscription des étudiants ou le traitement des commandes. Le propriétaire est le propriétaire du processus, et c'est lui qui peut dire combien de temps le processus peut s'arrêter avant qu'un dommage réel n'apparaisse.
2. L'information ou le jeu de données qui circule dans ce processus, comme les dossiers du personnel, les résultats d'examens ou les contrats clients. C'est ici que s'applique la cotation DIC (disponibilité, intégrité, confidentialité), et le propriétaire est le responsable de ces données.
3. L'application ou le service qui soutient le processus. Elle hérite sa classification de l'information la plus sensible qui y est traitée.
4. La technique sous-jacente : serveurs, stockage, composants réseau et interfaces. C'est le territoire de votre CMDB.

Un SMSI travaille sur les couches 1 à 3. Votre CMDB travaille sur la couche 4 et parfois sur la couche 3, car c'est là que les deux registres se rejoignent. C'est exactement à cette interface que vous créez le lien, et nulle part ailleurs.

La cotation DIC porte sur l'information, pas sur le matériel

Un serveur de base de données n'est pas confidentiel. Les données qu'il héberge le sont. Cela ressemble à un jeu de mots, mais c'est toute la différence entre une classification qui agit et une classification qui reste sur le papier.

La cotation de la disponibilité, de l'intégrité et de la confidentialité n'est pas une étiquette en soi, mais un interrupteur. Une classification n'a de sens que si quelque chose en découle. Pensez à des conséquences comme celles-ci :

• Quelles mesures du socle de sécurité sont obligatoires et quelles mesures complémentaires s'y ajoutent.
• Quel délai de reprise et quelle perte de données maximale s'appliquent, c'est-à-dire le RTO et le RPO de votre analyse de continuité.
• Quel niveau d'exigence s'impose pour la gestion des accès, la journalisation et les durées de conservation.
• S'il faut une analyse de risques distincte ou une AIPD avant que le traitement puisse démarrer.

Si vous cotez à la couche 4, vous cotez du matériel, et aucun enjeu métier sensé ne peut être rattaché à du matériel. Un serveur n'a besoin d'un niveau de protection qu'à partir du moment où vous savez quelles informations il héberge.

La norme du gouvernement américain fonctionne exactement ainsi. FIPS 199 catégorise selon les trois mêmes propriétés que la cotation DIC, avec les niveaux faible, modéré et élevé, et applique le principe de la valeur la plus haute, connu en anglais sous le nom de high water mark. La catégorie d'un système est égale à la cotation la plus élevée de tous les types d'informations que le système traite. NIST SP 800-60 le détaille dans des tableaux qui relient les types d'informations aux catégories. C'est le même héritage que vous voyez courir de l'information vers l'application dans Kantyra.

Ce principe a aussi un revers qu'il faut connaître. Qui applique la valeur la plus haute sans discernement fait basculer des environnements entiers sous le régime le plus lourd parce qu'un seul jeu de données sensible y circule. C'est précisément la raison pour laquelle NIST laisse dans SP 800-53 la place d'ajuster le jeu de mesures, et pour laquelle la séparation des environnements revient souvent moins cher que de tout hisser au niveau le plus élevé. Si une seule application tire tout votre périmètre vers le niveau critique, la question n'est pas de savoir comment le financer, mais si cette application a sa place à cet endroit.

Prêtez également attention à l'effet d'agrégation. Des données isolées peuvent chacune obtenir une cotation basse, tandis que l'ensemble devient sensible. Une liste de simples codes postaux est anodine, mais la même liste reliée à un registre des absences ne l'est plus.

Ce que la recherche montre sur les classifications qui s'enlisent

La classification de l'information est l'un des rares sujets de la sécurité de l'information à avoir fait l'objet de recherches empiriques sérieuses, notamment des travaux suédois sur les organisations publiques. Les constats reviennent avec une constance frappante, et ils expliquent pourquoi tant de démarches de classification échouent.

Dans la pratique, les organisations classifient des systèmes au lieu d'informations, parce que les systèmes sont tangibles et figurent dans une liste. Le lien avec l'enjeu métier disparaît alors, et il ne reste qu'un inventaire technique. Les schémas de classification sont en outre souvent trop fins, avec trop de niveaux et trop de dimensions, si bien que les personnes censées les appliquer décrochent. Le travail finit alors quand même par être fait par le responsable de la sécurité ou le service informatique au lieu du propriétaire, et c'est justement cela qui mine l'intention, car une classification est un jugement sur l'enjeu métier et non sur la technique. Enfin, la classification est traitée comme un exercice ponctuel pour l'auditeur, alors que les processus et les flux de données changent chaque année.

Le fil rouge de ces constats est que la classification échoue dès qu'elle est découplée des personnes qui connaissent l'enjeu et des mesures qui en découlent. C'est du même coup la principale exigence de conception pour tout registre SMSI : chaque ligne doit avoir un propriétaire nommément désigné, et chaque cotation doit changer quelque chose, de façon démontrable, à ce qui doit être fait.

Cela rejoint aussi la manière dont la gouvernance est habituellement organisée. Le RSSI n'est pas le propriétaire du risque. Le propriétaire du processus ou du système porte le risque et accepte le risque résiduel, et la direction est responsable en dernier ressort. Une classification remplie par le service sécurité fige donc un jugement que ce service n'a pas qualité pour rendre.

Relier ou non à la CMDB

Le conseil pratique est de ne pas construire de synchronisation, mais bien de poser une référence. Il existe trois variantes, par ordre croissant de coût et de charge d'entretien.

Dans la variante la plus simple, vous consignez dans votre SMSI, pour chaque application, le numéro de CI issu de la CMDB dans un simple champ. Un auditeur peut suivre cette référence, vous n'avez besoin d'aucune technique et vous avez terminé en un après-midi. Pour la plupart des organisations, cela suffit.

Dans la deuxième variante, vous réalisez un import ponctuel d'un sous-ensemble. Vous exportez de la CMDB uniquement les éléments de configuration de type application ou service métier, et vous les utilisez comme liste de départ. Ensuite, vous entretenez les deux registres séparément, car ils évoluent pour des raisons différentes.

La troisième variante est un couplage périodique, et il n'a de sens que si votre CMDB est manifestement à jour et si chaque élément de configuration comporte un propriétaire clair. Dans la plupart des organisations, ce n'est pas le cas, et vous importez alors surtout de la pollution.

Plus important que la technique est le sens de la circulation, car elle va dans les deux directions. Vers le bas descend la classification. Si une application obtient une cotation élevée en disponibilité, les serveurs qui la portent doivent recevoir le régime de sauvegarde, de correctifs et de surveillance correspondant, et c'est la raison même pour laquelle vous posez le lien. Vers le haut remontent les faits techniques : quels composants portent cette application, où ils se trouvent et quel est leur état de correctifs. La première direction est celle qui a de la valeur, car votre classification pilote alors l'exploitation au lieu de rester un exercice sur papier.

Ces trois variantes suffisent aux organisations qui travaillent à partir de l'ISO/IEC 27001 ou de NIS2. Si vous relevez de DORA, la première variante est trop légère, et nous l'expliquons dans la section suivante.

Quatre cadres, un seul sujet

La logique en couches tient bon à travers les différents cadres, mais l'axe selon lequel vous classifiez diffère d'un cadre à l'autre. C'est exactement là que les choses déraillent souvent, car les organisations construisent alors trois registres côte à côte alors que le sujet est le même.

Les trois premières lignes traitent du même sujet, seulement à travers un prisme juridique différent. La quatrième ligne traite d'autre chose.

NIS2 s'attache au service

NIS2 travaille au niveau du service. Que vous releviez ou non de la directive dépend de votre secteur et du service que vous fournissez, et non de vos systèmes. Le devoir de vigilance demande des mesures appropriées et proportionnées sur la base d'une évaluation des risques, la gestion des actifs et la politique d'accès figurant en toutes lettres parmi les catégories de mesures de l'article 21. La transposition française ajoute ses propres précisions ; vérifiez donc l'état actuel de la réglementation nationale.

Le mot « proportionné » fait ici tout le travail. Vous ne pouvez justifier la proportionnalité que si vous savez quel enjeu métier se cache derrière un système, et c'est précisément ce qu'une cotation DIC consigne. Sans classification, vous n'avez aucune réponse défendable à la question de savoir pourquoi vous avez équipé tel système d'un second site de repli et tel autre non. L'obligation de notification fonctionne de la même manière, car le seuil dépend des conséquences pour votre prestation de service, et vous les évaluez au niveau du processus.

Le volet gouvernance renforce le point sur la propriété. La direction doit approuver les mesures et superviser leur mise en œuvre, et elle en répond. Une classification que le service sécurité a remplie lui-même fige alors un jugement que la direction devrait porter.

DORA exige les deux registres à la fois

DORA est l'exception à la thèse qui ouvre cet article, et cela vaut la peine d'être précis.

Qui lit l'article 8 voit, aux paragraphes 4 et 6, quelque chose qui est fonctionnellement de la simple gestion de configuration. Vous devez identifier tous les actifs informationnels et actifs de TIC, y compris ceux situés sur des sites distants, ainsi que les ressources réseau et les équipements, et vous devez cartographier la configuration ainsi que les liens et interdépendances, et tenir ces inventaires à jour. C'est nettement plus concret que l'ISO/IEC 27001, car la mesure 5.9 ne dit rien des configurations ni des dépendances. Qui en conclut que DORA prescrit avant tout une CMDB tient donc un argument.

Ce n'en est pourtant pas une, et le règlement le précise lui-même dans ses définitions. DORA distingue l'actif de TIC, c'est-à-dire un actif logiciel ou matériel dans les systèmes de réseau et d'information, de l'actif informationnel, c'est-à-dire un ensemble d'informations qui mérite d'être protégé. C'est exactement la séparation entre les couches décrite plus haut, et le législateur l'a ancrée dans les définitions au lieu de tout mettre dans le même panier.

Le paragraphe 1 n'est d'ailleurs pas une question d'inventaire. Il y est écrit que vous devez identifier, classifier et documenter les fonctions métier soutenues par les TIC, avec les rôles et responsabilités, et avec les actifs informationnels et actifs de TIC qui soutiennent ces fonctions, chaque fois en relation avec le risque lié aux TIC. Une CMDB moyenne ne fournit pas cela, car il y manque ce qui suit :

• On y trouve tout au plus un administrateur technique, et non un propriétaire capable d'accepter le risque résiduel.
• Le lien entre un composant et la fonction métier qu'il soutient fait défaut, et avec lui la raison pour laquelle ce composant compte.
• Le jugement sur la criticité n'en découle pas, car ce jugement procède de la fonction métier et non de la technique.
• Il n'existe pas de revue périodique dans laquelle quelqu'un confirme que la classification tient toujours, alors que DORA demande une actualisation et une évaluation des risques à chaque changement majeur.
• Les systèmes hérités et la dépendance envers les prestataires tiers de services TIC ne reçoivent aucune attention particulière, alors que l'article 8 leur consacre des paragraphes distincts.

La formulation exacte est donc que DORA ne demande ni une CMDB ni un registre d'actifs classique, mais la combinaison des deux avec un lien démontrable entre eux. Une CMDB seule est trop technique et il lui manque la fonction, le propriétaire et la criticité. Un registre classique seul est trop abstrait et il lui manque la configuration et les dépendances. Les normes techniques de réglementation qui accompagnent le règlement précisent ce que l'inventaire doit contenir pour chaque actif.

Concrètement, cela signifie pour les entités financières qu'un simple champ de référence avec le numéro de CI ne suffit pas. Il vous faut un lien entretenu dans lequel la criticité se transmet du haut vers le bas jusqu'aux composants techniques et dans lequel les dépendances restent visibles. Comptez en outre sur un troisième registre qui n'a rien à voir avec les deux premiers, à savoir le registre d'informations sur les accords contractuels avec les prestataires de services TIC. Il obéit à un modèle de données imposé avec des gabarits fixes et part à l'autorité de surveillance ; qui tente de le faire entrer dans le même tableau que ses actifs se retrouve coincé.

Un registre, plusieurs attributs

Le résultat pratique est que vous tenez un seul registre au niveau des processus et de l'information, avec, sur la même ligne, un attribut propre à chaque cadre. Un processus reçoit donc une cotation DIC, à côté un attribut indiquant s'il compte sous NIS2 comme service essentiel ou important, et pour les entités financières un attribut indiquant s'il s'agit d'une fonction critique ou importante.

Ne déduisez pas ces attributs automatiquement les uns des autres. Une cotation élevée en confidentialité ne fait pas encore d'un élément une fonction critique sous DORA, et une fonction critique n'a pas besoin d'une cotation élevée en confidentialité. Ce sont des qualifications juridiques avec leurs propres critères, et un logiciel qui les recopie automatiquement de l'une vers l'autre produit une image fausse qui a seulement l'air soignée.

Quelle taille pour le registre

Un registre SMSI praticable compte, dans la plupart des organisations, entre cinquante et cent actifs. Si vous êtes à des milliers de lignes, vous avez copié votre CMDB.

Le test par ligne est simple. Existe-t-il une personne nommément désignée capable d'accepter le risque résiduel pour cet actif ? Et la classification que vous lui attachez change-t-elle quelque chose aux mesures ? Si vous répondez non à l'une des deux questions, la ligne a sa place dans votre CMDB et non dans votre SMSI.

Sous DORA, cette règle empirique continue de valoir pour les couches supérieures, mais l'inventaire complet des actifs de TIC s'y ajoute, et il est par définition plus volumineux. La différence est que vous gardez les deux séparés et que vous les reliez, au lieu de les fondre en une seule liste.

En sept étapes

1. Commencez par les processus métier et non par les systèmes, et limitez le nombre aux processus qui comptent vraiment.
2. Désignez pour chaque processus le propriétaire, et consignez ce nom avant d'aller plus loin.
3. Recensez pour chaque processus les informations qui y circulent, et cotez-les en disponibilité, intégrité et confidentialité.
4. Reliez les applications à ces informations et laissez la classification s'hériter du jeu de données le plus sensible.
5. Consignez pour chaque application la référence vers l'élément de configuration dans votre CMDB, sans reprendre les données techniques. Si vous relevez de DORA, posez un lien entretenu vers les composants sous-jacents et leurs dépendances.
6. Traduisez la classification en exigences concrètes, c'est-à-dire en mesures, délais de reprise et durées de conservation, et transmettez-les à l'exploitation.
7. Révisez la cotation chaque année et à chaque changement significatif, et faites confirmer cette révision par le propriétaire.

Pour une partie des organisations, cet ordre n'est d'ailleurs pas un libre choix. NIS2 comme DORA exigent que vos mesures soient proportionnées au risque, et vous ne pouvez étayer cette proportion que si vous savez quel enjeu métier se trouve derrière un système. Un inventaire technique seul ne fournit pas cette justification, et une classification sans lien vers la technique ne fournit pas de mise en œuvre démontrable. Il vous faut les deux, mais sous la forme de deux registres que vous reliez.

Sources

Sources normatives, à consulter directement :

• ISO/IEC 27001:2022, mesures 5.9 (inventaire des informations et autres actifs associés), 5.10, 5.12 (classification des informations) et 5.13 (marquage des informations), avec les explications de l'ISO/IEC 27002:2022.
• Directive (UE) 2022/2555 (NIS2), en particulier les mesures de gestion des risques de l'article 21, les obligations de gouvernance de l'article 20 et les obligations de notification de l'article 23. Vérifiez l'état actuel de la transposition française avant de vous en prévaloir.
• Règlement (UE) 2022/2554 (DORA), article 3 pour les définitions de l'actif de TIC et de l'actif informationnel, et article 8 pour l'identification, la classification et la documentation des fonctions métier et des actifs. Reprenez littéralement les définitions de l'article 3 lorsque vous rédigez une politique interne à ce sujet, et appuyez-vous sur les normes techniques de réglementation du règlement pour les exigences relatives à l'inventaire.
• ISO/IEC 20000-1 et la pratique ITIL 4 de gestion de la configuration des services, pour la signification de l'élément de configuration et de la CMDB.
• FIPS 199 (2004) pour la catégorisation selon la confidentialité, l'intégrité et la disponibilité et pour le principe de la valeur la plus haute, avec son développement dans NIST SP 800-60.
• NIST SP 800-53 rév. 5, mesure CM-8 sur l'inventaire des composants système, qui montre clairement que l'inventaire technique est autre chose que la catégorisation.
• NIST Cybersecurity Framework 2.0, catégorie ID.AM, où la priorisation des actifs sur la base de la classification et de la criticité figure explicitement.
• CIS Controls v8, mesures 1 et 2 pour l'inventaire des équipements et des logiciels, et mesure 3.7 pour le schéma de classification des données.

Littérature de recherche :

• Oppenheim, Stenson et Wilson, « The attributes of information as an asset » (New Library World, 2001) et la série en trois volets « Studies on Information as an Asset » (Journal of Information Science, 2003–2004), sur les raisons pour lesquelles l'information se comporte autrement qu'un actif classique.
• Erik Bergström et ses collègues (université de Skövde et Jönköping University) sur la classification de l'information dans le secteur public suédois, notamment « Developing an information classification method » (Information & Computer Security, 2021) et « An information classification model for public sector organizations in Sweden » (Information & Computer Security, 2022), avec des constats sur les schémas trop complexes, la classification par la mauvaise fonction et l'absence de lien vers les mesures.