Sécuriser le système avant de l'homologuer

Le guide propose d'organiser le travail selon un modèle en trois lignes, que l'ANSSI décrit aussi dans son guide « Maîtrise du risque numérique, l'atout confiance » :

Idéalement, trois personnes différentes tiennent ces rôles. Le guide admet que les petites organisations les cumulent, avec des ressources internes ou externes ; l'essentiel est que chacun sache ce qu'il doit faire. Un tableau des responsabilités (de type RACI) aide à le formaliser. Une ligne supplémentaire peut s'ajouter lorsqu'un contrôle extérieur à l'organisation est exigé.

Le périmètre d'homologation rassemble tous les composants du système qui traitent l'information et dont l'autorité d'homologation a la responsabilité : matériels, logiciels et services, équipements d'échange, utilisateurs et administrateurs, lieux, et tout ce qui le fait fonctionner sous la maîtrise du responsable. Il doit être décrit sans ambiguïté, sur les plans technique, fonctionnel et des responsabilités, et si possible séparé du reste par des filtrages.

L'écosystème regroupe tout ce qui est relié au système sans faire partie du périmètre : systèmes connectés, interfaces de programmation, hébergeur, postes d'accès, locaux, administrateurs ou utilisateurs extérieurs. Le guide appelle chacun de ces éléments une brique. Les briques ne sont pas homologuées avec le système, mais leurs risques doivent être identifiés et traités, et chacune doit offrir des garanties à la hauteur des besoins du système : une homologation, une certification ou un contrat de service qui précise les engagements de chaque partie.

Le guide donne quelques règles de découpage. Plusieurs systèmes qui partagent une mission commune peuvent former un seul périmètre (on parle alors de périmètre capacitaire) ; à l'inverse, des services de nature différente, comme une messagerie, un partage de fichiers et une téléphonie, peuvent faire l'objet de trois homologations. Deux systèmes de niveaux de protection ou de classification différents demandent deux démarches distinctes.

La règle posée par le guide est simple : le périmètre d'homologation doit correspondre au périmètre de responsabilité. Pour le choix d'un hébergeur, voir notre article sur SecNumCloud et, pour la maîtrise des fournisseurs, la gestion des risques tiers.

Les mesures à appliquer viennent de plusieurs sources : les bonnes pratiques (le guide d'hygiène informatique de l'ANSSI en premier lieu), les référentiels et textes applicables, la politique de sécurité (PSSI) de l'organisation, le plan issu de l'analyse de risques, les résultats d'audit, les incidents passés et l'évolution de la menace. Le guide distingue les mesures communes à toute l'organisation (la sensibilisation des utilisateurs, par exemple) et les mesures propres au système (son dossier d'architecture).

Chaque mesure est classée appliquée, partiellement ou pas appliquée, ou non applicable, avec une justification. Une mesure peut être écartée si elle coûte plus cher que le risque qu'elle couvre, à condition de le justifier ; en revanche, toute mesure imposée par un texte et applicable doit être appliquée. Ce suivi, que le guide compare à la déclaration d'applicabilité d'ISO 27001, donne le taux de conformité du système, et des indicateurs de performance permettent de suivre son évolution.

La cartographie fait apparaître le périmètre d'homologation et sert à réagir vite en cas d'incident. Le guide recommande trois vues, du métier vers la technique : la vue métier (processus et informations principales, les valeurs métier d'EBIOS RM), la vue applicative (logiciels, services et flux entre eux) et la vue infrastructure (équipements et réseau). Elle peut s'enrichir des profils d'utilisateurs, des prestataires, des contrats et des lieux.

Trois règles pratiques : une seule cartographie par système, datée et tenue par une personne nommée ; une protection adaptée, car elle intéresse aussi les attaquants ; et une copie accessible même si le système est entièrement à l'arrêt. Notre article sur la cartographie du système d'information détaille la méthode de l'ANSSI.

Les procédures d'exploitation (incidents, changements, sauvegardes et restaurations, gestion des comptes) doivent être écrites, testées, appliquées et suivies par des indicateurs. Le guide demande en outre trois plans, rédigés par la première ligne et vérifiés par la deuxième :

Quand un correctif ne peut pas être appliqué, le guide demande de placer le composant vulnérable dans une bulle de confiance qui contient la menace. Le MCS peut être fusionné avec le MCO, et un plan commun à toute l'organisation suffit souvent : le dossier y renvoie au lieu de le recopier. Pour la résilience, notre guide de la continuité d'activité développe le bilan d'impact et le plan de reprise.

Avant la mise en service, les risques liés à l'emploi du système doivent être identifiés, traités et acceptés. Le guide demande une méthode validée par la politique de sécurité ou par l'autorité d'homologation ; EBIOS Risk Manager est obligatoire quand l'ANSSI est elle-même l'autorité, et fortement recommandée dans les autres cas. Surtout, il proportionne l'effort :

• système peu critique et peu exposé : une vérification de conformité au guide d'hygiène informatique et aux guides thématiques suffit ;
• système plus critique ou plus exposé : une analyse des principaux risques ;
• système critique et exposé : une analyse complète, qui étudie des scénarios d'attaque vraisemblables, en tenant compte de la menace intentionnelle.

L'analyse couvre le périmètre et les risques apportés par l'écosystème. Le plan de traitement qui en sort est intégré au plan d'action, et la vraisemblance des risques, qui évolue avec la menace, se surveille par des indicateurs de risque. Pour la méthode, voir notre guide EBIOS RM ou, pour une alternative, l'ISO 27005.

Une fois les mesures en place, des audits éprouvent la robustesse du système sur le périmètre défini. Le guide les veut menés par des auditeurs indépendants, avec un temps suffisant et la liberté de proposer leurs propres scénarios. Il distingue les audits de conformité, d'organisation, de configuration, d'architecture et les audits techniques, auxquels s'ajoutent selon le système les revues de code, les tests d'intrusion ou les programmes de prime aux bogues. Certains textes en imposent : nous les avons listés au chapitre 1.

La fréquence suit l'évolution des enjeux, de la menace et de l'avancement des corrections ; alterner les types d'audit d'une fois sur l'autre permet de couvrir davantage de failles. Notre article sur l'audit de cybersécurité présente les différents formats.

Toutes ces démarches produisent des actions : combler des écarts de conformité, traiter des risques, corriger des vulnérabilités relevées en audit, tirer les leçons d'incidents. Le guide demande de les rassembler dans un plan d'action unique, aux actions réalistes et utiles, que l'on peut formuler selon la règle SMART (spécifique, mesurable, atteignable, réaliste, limitée dans le temps). Chaque action a au minimum un propriétaire, une complexité, un délai et une date, et l'on traite d'abord les risques les plus graves et les plus vraisemblables.