Biens support – Citalid

Les biens support (actifs) représentent les éléments du système d’information et de l’organisation qui soutiennent l’activité et sur lesquels la posture de défense et les scénarios de risque s’appliquent.

Cas d’usage : Je souhaite lister les actifs principaux afin de rendre explicite le scope du périmètre et faciliter l’analyse et le suivi dans le temps.

Ajouter des biens support

Créer ou sélectionner des actifs (ex : annuaire, postes de travail, serveurs, applications critiques, ERP, messagerie).

Renseigner, lorsque disponible, des informations simples (criticité, périmètre couvert, commentaire)

À quoi cela sert

Les biens support permettent de :

clarifier ce qui est couvert (et ce qui ne l’est pas) par l’analyse.

faciliter la discussion avec les parties prenantes (IT, RSSI, métiers).

améliorer la compréhension des impacts potentiels des scénarios.

A quoi cela sert

Sans connexions, il n'y a pas de chemin d'attaque possible entre les biens supports,, donc pas de propagation de risque modélisable. Concrètement, si deux biens supports critiques ne sont pas reliés alors qu'ils le sont réellement dans le SI, alors :

l'algorithme ne pourra pas simuler qu'une attaque se propage de l'un vers l'autre,

la susceptibilité (et donc les pertes financières associées) sera sous-estimée pour le bien support cible, car aucun chemin d'attaque crédible ne "l'atteint" dans le modèle.

Bonnes pratiques

Commencer par une liste courte des actifs les plus critiques.

Enrichir progressivement au fil des cycles (revue trimestrielle, préparation comité de direction, etc.).

Rester à un niveau macro : un bien support représente une brique fonctionnelle ou technique du SI (ex : « ERP », « messagerie », « postes de travail »), pas chaque instance individuelle (pas un bien support par serveur ou par poste). L'objectif est la représentativité du scope, pas l'exhaustivité.

⚠️ Au-delà d'une vingtaine de biens support, certaines recommandations de sécurité peuvent être moins précises. Privilégier le regroupement d'actifs similaires plutôt que la multiplication de biens support unitaires.

Cas particulier : plusieurs périmètres (périmètre parent / périmètre enfant)

Si votre organisation utilise plusieurs périmètres organisés en hiérarchie (périmètre parent / périmètre(s) enfant(s) — voir Section 1 : Périmètres), il n'est pas nécessaire de recréer les mêmes biens support dans chaque périmètre enfant.

Depuis un périmètre enfant, vous pouvez faire hériter un ou plusieurs biens support de son périmètre parent, plutôt que de les recréer.

Cela permet de : éviter la duplication d'un actif partagé (ex : un ERP groupe utilisé par plusieurs filiales), garantir la cohérence de la donnée entre périmètres, et faire bénéficier le périmètre enfant des connexions et scénarios de risque déjà modélisés sur cet actif au niveau du parent.

Un bien support hérité reste identifiable comme tel dans les vues du périmètre enfant, pour le distinguer des biens support propres à ce périmètre.

Bonnes pratiques : hériter un bien support partagé entre plusieurs entités plutôt que de le dupliquer ; ne créer un bien support propre au périmètre enfant que lorsqu'il lui est réellement spécifique (ex : un serveur local à une filiale).

Ajouter des connexions

Une fois les biens support créés (propres ou hérités), ajouter des connexions entre eux afin de transformer cette liste d'actifs en chaîne de propagation. Vous pourrez définir, à la section 2, les points d'entrée et cibles de cette chaîne.

À quoi cela sert

Sans connexions, il n'y a pas de chemin d'attaque possible entre les biens support, donc pas de propagation de risque modélisable. Concrètement, si deux biens support critiques ne sont pas reliés alors qu'ils le sont réellement dans le SI, alors :

l'algorithme ne pourra pas simuler qu'une attaque se propage de l'un vers l'autre,

la susceptibilité (et donc les pertes financières associées) sera sous-estimée pour le bien support cible, car aucun chemin d'attaque crédible ne « l'atteint » dans le modèle.