Souvent considérée comme une contrainte de plus imposée aux services maîtrises d’œuvre et aux bénéficiaires d’un produit numérique, l’homologation sécurité (RGS) peut au contraire ajouter de la valeur à ce dernier, et ce pour toutes les parties prenantes.
En tant que responsables de produits homologués cette année, nous souhaitions partager notre expérience de cette démarche, et peut-être lever quelques inquiétudes que pourraient avoir les chefs de produits candidats à l’homologation...
Tout produit numérique de l’Etat, a fortiori s’il est ou sera accessible depuis Internet, doit faire l’objet d’une démarche d’homologation sécurité. En 2023, 4 homologations de produits sous la responsabilité de la sous-direction Méthodes et Services de Plateforme du pôle ministériel Ecologie ont été prononcées, notamment :
- WSO2 (chef de produit : Gabor Jager) en janvier ;
- SPOTE (chef de produit : Gilles Fournel) en mai ;
- GitLab (chef de produit : Didier Richard) en septembre.
Séminaire MSP, 6 octobre 2023.
De gauche à droite : Jean-Philippe Papillon, sous-directeur, Gilles Fournel, Gabor Jager, Didier Richard.
Comme d’autres responsables produit seront amenés à s’engager dans une telle démarche, voire y sont déjà confrontés, nous nous sommes proposés de vous faire partager ici nos expériences en la matière, en espérant que cette mise en commun vous sera utile ! :)
La définition du périmètre de l’homologation : l’élément essentiel
Premier constat, partagé entre nous et conforté par les échanges que nous avons pu avoir avec nos collègues en galère sur le sujet : bien définir dès le départ le périmètre de l’homologation.
Nos produits numériques évoluent dans des écosystèmes complexes, on peut vite se perdre dans le labyrinthe des interconnexions et se retrouver à devoir analyser un pan entier du SI ministériel ! Quant on peut s’appuyer sur une cartographie (voir à ce sujet l’offre GUSI) ou simplement le schéma des flux du dossier d’architecture technique, cela aide grandement...
Il nous a semblé aussi important de bien distinguer notre produit des modules tiers sur lesquels il peut s’appuyer, de même pour le socle infrastructure.
En clair : en tant que chef de produit, le périmètre de mon homologation ne peut être constitué que d’éléments sur lesquels j’estime avoir un niveau de maîtrise suffisant.
Ainsi, par exemple pour la plateforme SPOTE, nous avons exclu du périmètre la brique d’authentification Cerbere (qui elle-même a fait l’objet d’une homologation d’ailleurs), ainsi que le socle PaaS sur lequel s’appuie l’applicatif.
Il nous semble également très important de faire part de ce périmètre aux parties prenantes intervenant dans le processus d’homologation, à commencer bien entendu par l’Autorité d’Homologation (AH), dont nous parlerons plus en détails par la suite. Se lancer dans cette démarche implique une charge de travail non négligeable, alors clarifier le périmètre dès le départ fait gagner beaucoup de temps par la suite, croyez-nous !
Anticiper les étapes de validation
Le processus d’homologation dépend du SI concerné, en fonction des enjeux qu’il porte :
Cela suppose des étapes de validation qui vont solliciter des acteurs externes (Département Sécurité et Gestion de Crise au moment de l’évaluation des besoins de sécurité, les Affaires Juridiques lors de l’inscription au registre des traitements, l’Autorité d’Homologation bien sûr...), lesquels ne sont pas nécessairement disponibles au moment voulu (expérience vécue). Il peut être judicieux de définir un calendrier d’homologation en bloquant les dates correspondant aux jalons de validation suffisamment à l’avance dans les agendas des personnes concernées !
L’Autorité d’Homologation, ça n’est pas seulement un coup de tampon !
Rappelons tout d’abord que l’autorité d’homologation n’est pas une entité abstraite, c’est une personne physique disposant des habilitations suffisantes pour prononcer une homologation, en ce qui nous concernait il s’agissait de notre sous-directeur. Comme il est écrit dans le "Guide d’homologation de sécurité" de l’ANSSI, l’autorité d’homologation doit pouvoir
prendre une décision éclairée sur la base de ce dossier [d’homologation, ndlr], qui doit apporter des réponses pertinentes à l’ensemble des questions qu’elle se pose
.
Autrement dit, le dossier que l’on va rédiger doit être suffisamment clair et complet pour que l’AH puisse exercer son rôle. De ce fait, le plus simple, et cela nous a bien aidé, c’est de caler avec cette même autorité la structure de ce dossier dès le démarrage, lors d’une réunion de cadrage (lorsque c’est possible), on évitera ainsi d’en faire trop, ou de faire du hors sujet...
Les enjeux de la documentation
J’ai défini mon périmètre, calé mon calendrier, c’est bon, je peux me lancer ! Euh oui, mais sur quels documents vais-je m’appuyer ?
Le Département Sécurité et Gestion de Crise a produit un kit très complet, actualisé récemment, avec des modèles de documents en fonction de la typologie des SI (à enjeu fort, modéré, faible, nouveau ou existant...)
accéder aux ressources homologation de DSGC (RIE uniquement).
Cette documentation est complétée, au sein de la sous-direction Méthodes et services de plateforme, par des ressources, de l’outillage, permettant d’aller plus loin en matière d’analyse technique du SI, très pertinents notamment pour les produits numériques de type application web.
En quoi la démarche peut-elle être utile ?
Commençons par rappeler que l’homologation, ce n’est pas qu’un sujet technique, bien au contraire !
C’est une bonne occasion, enfin c’est un avis que nous partageons ici, de prendre un peu de hauteur par rapport à notre produit, de s’intéresser à la façon dont il interagit avec son environnement, par quoi il s’alimente et ce qu’il fournit en sortie, si l’organisation que nous avons mise en place ou envisagée est suffisante, à améliorer, qu’il s’agisse du processus de maintenance évolutive ou d’escalade sur incident. Evaluer le niveau d’enjeu du SI ne peut se faire que si on croise les exigences techniques et les aspects métier, qu’il s’agisse de la nature des données qu’il traite (à caractère personnel ou sensible par exemple) ou de l’impact sur les utilisateurs en cas d’altération ou de dégradation du service. En bref, l’homologation, ça se fait aussi avec l’équipe produit au sens large !
Au-delà de la fierté qu’on peut ressentir à la sortie de la commission d’homologation (parce que, mine de rien, il y a du travail derrière un dossier d’homologation !), cette expérience a eu des effets concrets pour nos trois produits : mise à jour ou complétude de la documentation technique ou procédurale pour WSO2 ou SPOTE, chantier de développement pour adapter le code applicatif de SPOTE en vue d’implémenter une stratégie de sécurité du contenu (CSP), ou enrichissement par Didier des ressources (modèle de documents) pour accompagner les prochains chefs de produit...
Enfin, le fait d’avoir un produit homologué est un gage de qualité supplémentaire, parce que c’est un produit maîtrisé, élément important pour nos utilisateurs actuels, mais aussi pour ceux que l’on est susceptibles d’embarquer.
Ce n’est pas non plus un blanc-seing pour des années, à l’instar de la maintenance (corrective ou de sécurité) du produit, il faut maintenir l’attention sur les risques identifiés, voire à identifier car les technologies évoluent, les composants techniques vieillissent et les pratiques et organisations doivent s’adapter aux nouveaux contextes et besoins !
Didier, Gabor et Gilles