Cartographie des systèmes d’information
La cartographie des systèmes d’information fait partie des prérequis à toute démarche de cybersécurité. Elle est indispensable en amont lors des analyses de risques, par exemple dans la méthode EBIOS Risk Manager ou le référentiel de l'ISACA sur les risques IT. La cartographie participe aussi fortement à l’efficacité du processus de réponse à incident. On reconnait cette bonne pratique dans de nombreux référentiels comme le NIST 800-53, le NIST CSF (dans la fonction identifier), la CCM pour la sécurité des environnements Cloud ou encore l’ISO 27002 qui préconise des mesures de sécurité en application du SMSI ISO 27001. Pour les entités qui doivent se conformer au standard PCI DSS, la cartographie fait partie de l’exigence 2.4 (maintenir un inventaire des composants du périmètre PCI DSS). L’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) insiste sur ce point, en particulier pour les opérateurs d’importance vitale. L’agence a récemment mis à jour son guide pour établir cette cartographie.
Utiliser l’existant
Les éléments qui existent déjà au sein d’une entité, à prendre en compte avant de démarrer un projet de cartographie sont les suivants :
- La CMDB (Configuration Management DataBase) est un référentiel d’éléments de configuration issu d’ITIL et très utilisé par les équipes d’infrastructure. Les éléments de configuration contenus dans la CMDB (les CI, Configuration Items) peuvent être composés de matériels, de services, d’applications. Dans un contexte d’évolution permanente du SI, l’objectif est de faciliter la prise de décision dans le processus de gestion des changements.
- Les projets d’urbanisation. Ils sont intéressants pour la sécurité car ils offrent une vue métier du système d’information, faisant le lien entre le business et les applications. Le référentiel TOGAF est souvent utilisé.
- Les stratégies de sécurité, s’appuyant par exemple sur le référentiel SABSA contiennent aussi des informations intéressantes pour démarrer le projet.
- Les outils des fournisseurs de Cloud public comme AWS Systems Manager ou Azure Automation.
Les différentes vues
L’ANSSI préconise les vues suivantes :
- Ecosystème: en fonction du périmètre retenu, les entités internes et externes, les partenaires.
- Métier: les processus des métiers et des fonctions supports, les points de contact, les informations et leurs besoins de sécurité.
- Applicative: les applications, les API, les bases de données et les flux.
- Administration: les zones, les serveurs Active Directory.
- Infrastructures logiques et physiques: réseau, passerelles, points d’accès Internet, connexions Cloud et partenaires, serveurs, services DNS et DHCP, sites, postes de travail, stockage...
Pour chaque vue, l’ANSSI propose une approche très pragmatique avec trois niveaux de granularité à sélectionner en fonction de sa maturité et de ses objectifs de sécurité. Par exemple, un OIV doit sélectionner un niveau de granularité d’au moins 2.
Autres exemples de référentiels
- NIST 1800-5 est un exemple d’inventaire et de gestion des actifs orienté sécurité pour les établissements financiers.
- FIPS 199 pour la catégorisation des systèmes d’information.
- NIST 800-37 : gestion des risques (voir en particulier le paragraphe 3.2 sur la catégorisation du système).
- BSI (Allemagne) – Standard 100-2.
- Les recommandations de l’agence britannique : gestion des assets.
Pour en savoir plus sur les 20 meilleures formations sur la sécurité des systèmes d’information, téléchargez gratuitement notre livre blanc ci-dessous :
