« L’homologation de sécurité est un acte formel par lequel l’autorité responsable d’un système engage sa responsabilité en matière de gestion du risque »[1]. Au-delà d’être obligatoire dans certains cas définis par la réglementation[2], l’homologation est un réel message aux utilisateurs et au top management : la sécurité est bien une préoccupation majeure et une véritable attention y est portée. Et l’Agile représente une opportunité pour la sécurité, en permettant une réduction incrémentale du risque.
Cette méthode a bouleversé les façons de travailler des équipes produits et des équipes SSI, mais il ne va pas s’agir de « juste » adapter l’homologation RGS du cycle en V à l’Agile, mais bien de proposer une solution adéquate pour répondre à l’objectif de l’homologation : « trouver un équilibre entre le risque acceptable et les coûts de sécurisation, puis faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire[3] ».
Une solution : l’homologation provisoire et l’homologation ferme
Comme l’a déclaré un célèbre expert Sécurité Agile de Wavestone : « l’Agile et les homologations, c’est pas sorcier ». Sans nier les débats d’experts et les difficultés, l’approche reste assez simple à expliquer. Face à des équipes qui doivent livrer plus vite et mettre en production en continu, il faut que les niveaux de risques et donc l’homologation suivent le rythme.
Que doit prendre en compte l’homologation ?
Comme toute homologation traditionnelle, il s’agit de présenter le niveau de risque à une Autorité d’homologation, qui acte le fait que ce niveau est acceptable au regard des critères SSI de l’organisation (nombre d’EUS présentes sur le projet par exemple, pourcentage des règles de base de la PSSI ou règles d’hygiène appliqué pour un périmètre donné, etc.) et prend la responsabilité des éventuels risques résiduels.
Par exemple, un projet à ses débuts, qui souhaite mettre à disposition quelques fonctionnalités à peu d’utilisateur, présentera un niveau de risques moindre, dû à sa faible exposition, malgré un périmètre peut-être encore peu sécurisé. Une homologation provisoire (d’une durée de quelques mois par exemple) peut être prononcée pour permettre l’expérimentation, à renouveler lorsque certains critères de renouvellement (définis à l’avance) sont atteints.
Figure 1 – Exposition au risque résiduel d’un produit
Tiré du Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)
Pour un projet en rythme de croisière, accessible à son public cible avec toutes les fonctionnalités attendues, une homologation ferme (3 ans par exemple) est prononcée. Les critères de renouvellement, menant à la prononciation d’une nouvelle homologation sont également définis à l’avance.
Quand renouveler une homologation ?
Bien que les critères de renouvellement soient très contextuels, voici des pistes de réflexion (en volume et degré d’exploitation du projet).
Pour l’homologation temporaire, elle est valide jusqu’à ce que des critères de renouvellement soient identifiés :
- De nouvelles fonctionnalités critiques sont ajoutées (à définir par le projet),
- Un nouveau palier de nombre d’utilisateurs est franchi (défini à l’avance, en fonction des risques associés),
- De nouvelles données à caractères personnel doivent être intégrées et traitées par le projet,
- De nouvelles fonctionnalités liées à des paiements doivent être implémentées,
- Un nouveau palier de volume de transaction est dépassé,
- Et bien sûr quand la date limite de l’homologation est atteinte.
Pour l’homologation ferme, la validité de l’homologation est plus longue, sur hypothèse que moins de changement seront apportés au projet. Cependant, et toujours dans une optique d’amélioration continue, la vérification des niveaux de sécurité sera réitérée à intervalles réguliers (tous les 3 ans par exemple).
Quels éléments de preuve doivent apporter les squads ?
Les squads doivent normalement être en mesure de présenter différents éléments de preuve à l’Autorité d’homologation/responsable de l’homologation. Les Evil User Stories (EUS) font office de risques, avec leur priorisation qui donne un élément de compréhension sur leur gravité. Nous avions détaillé dans un article précédent la manière de mener à bien ces ateliers d’analyse des risques en Agile. Un extrait du backlog peut apporter la preuve que les EUS principales ont bien été traitées et que les EUS résiduelles sont connues (et par extension, doivent être acceptées par l’Autorité d’homologation).
Le Passeport Sécurité (détaillé dans notre article sur la transformation Agile) est également un moyen pertinent de suivre les niveaux de sécurité d’un projet.
Les rapports des outils de revue de code et de scan de vulnérabilité peuvent également être utilisés (pour les squad ayant intégré le DevSecOps et possédant également les outils adéquats).
Si l’équipe X-team existe (voir notre article sur les nouveaux rôles SSI dans l’Agile et l’organisation associée) ou si une équipe d’audit externe a pu les réaliser, les rapports de test d’intrusion sont également présentés.
Tout autre document existant et nécessaire peut également être présenté (document d’architecture par exemple, réglementation applicable…).
Pour l’homologation temporaire, ces éléments de preuve ne doivent pas forcément faire l’objet d’un « dossier » hors-sol ; il faut surtout s’assurer qu’ils existent bien et sont accessibles aux acteurs de l’homologation (Autorité d’homologation ou son délégué, équipe SSI…).
Qui sont les acteurs du processus ?
Pendant tout le développement du produit, le Security Champion (cf. la définition dans cet article) est garant de la bonne mise en œuvre de l’évaluation des risques via les ateliers d’identification des Evil User Stories et des Security Stories associés. De manière assez naturelle, l’équipe SSI est actrice du processus d’homologation, via l’expertise apportée aux équipes, notamment lors de ces ateliers.
Le Product Owner est responsable de la bonne création et mise à jour des éléments de preuve nécessaire à l’homologation. Il s’assure également que l’équipe SSI est bien tenue informée du bon déroulement de l’homologation et qu’elle est sollicitée si besoin.
L’Autorité d’homologation est, comme toujours, un responsable métier (par exemple le Business Owner) capable d’accepter les risques résiduels et de valider les niveaux de sécurité des produits. Cependant, et toujours dans une optique d’amélioration des temps de traitement, la signature d’une homologation temporaire pourra être déléguée au Product Owner, en tant qu’émanation du métier, pour peu que les critères nécessaires à la validité de l’homologation soient bien respectés. Dans les cas où le projet ferait porter un risque à d’autres métiers ou à d’autres systèmes, la responsabilité de l’homologation devra être portée en transverse, par un N+1 commun. Si aucun compromis n’est trouvé, c’est le Directeur des Systèmes d’Information (DSI), dans son rôle de garant du maintien en conditions opérationnelles des SI, qui assumera la responsabilité.
Ainsi, l’homologation conserve toute son importance, et notamment dans le cadre de la méthodologie Agile qui fait évoluer la manière de travailler des équipes produit. Les équipes SSI doivent profiter de ces évolutions pour se (re)projeter dans ces équipes (à travers le Security Champion et à travers la formation des équipes à la sécurité) et ainsi œuvrer à la réduction incrémentale du risque.
Plus d’articles à venir sur la Sécurité dans l’Agile, restez à l’écoute !
[1] Guide ANSSI : Agilité et Sécurité Numériques, octobre 2018 (lien vers le guide)
[2] Pour les administrations : décret n°2010-112 du 2 février 2010, modalités du Référentiel général de sécurité (RGS). Pour tout produit traitant d’informations relevant du secret de la Défense nationale : l’Instruction générale interministérielle 1300. Pour les opérateurs d’importance vitale : volet cyber de la LPM (loi n° 2013-1168 du 18 décembre 2013 – article 22), pour le renforcement de la sécurité des systèmes d’information critiques qu’ils exploitent, mené dans le cadre d’une démarche d’homologation.
[3] Guide ANSSI : L’homologation de sécurité en neuf étapes simples, août 2014 (lien vers le guide)
