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 sys­tè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)

Cet article Homologation Sécurité et Agilité Numérique : c’est possible ! est apparu en premier sur RiskInsight.

Dans le contexte de la Loi de Programmation Militaire (LPM), l’homologation est une procédure obligatoire qui s’applique aux Opérateurs d’Importance Vitale (OIV). Elle permet de maîtriser les enjeux et le niveau de sécurité de chaque Système d’Information d’Importance Vitale (SIIV).

L’homologation est au cœur de la stratégie de mise en conformité LPM, car elle permet de décliner de manière concrète et opérationnelle les règles de la LPM tout en réduisant les risques de sécurité.

L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) a décrit dans un guide les grandes étapes de l’homologation. Ainsi les étapes majeures d’une homologation sont :

• La définition de la stratégie d’homologation (document de cadrage décrivant les détails de réalisation de l’homologation)
• La réalisation d’une analyse de risques sur le SIIV
• La conduite d’un audit d’homologation
• La décision d’homologation
• Le suivi a posteriori de l’homologation

Cette décision doit être prise par l’autorité d’homologation (AH), personne morale portant la responsabilité de l’homologation pour un SIIV. Elle est aidée par la commission d’homologation, groupe d’experts internes chargé de préparer la décision d’homologation.

Les informations nécessaires à la prise de décision sont regroupées dans le dossier d’homologation. Cela permet à la commission d’homologation d’attester la connaissance du niveau de sécurité et d’accepter les risques résiduels. In fine, la commission d’homologation atteste que le niveau de risque est maîtrisé.

Une démarche à éprouver au plus vite sur les SIIV existants

Rétro-homologation : comment homologuer les SIIV déjà en service ?

Dans le cadre d’un SIIV déjà existant, le paradigme de l’homologation est différent, même si les objectifs restent les mêmes. L’analyse de l’existant constitue le point de départ de l’homologation, et la réalisation d’un audit à blanc (ou l’utilisation d’un rapport d’audit précédent) sert d’accélérateur dans la collecte d’information et dans l’identification des risques.

A l’inverse, les mesures de sécurité devront être appliquées sur un historique parfois lourd à transformer. Des mesures compensatoires doivent dès lors être identifiées, priorisées et mises en œuvre

Cette homologation a posteriori, ou rétro-homologation, doit permettre au métier d’assurer une prise en compte exhaustive des risques, et de prioriser les actions pour réduire les risques à un niveau acceptable, en mobilisant les budgets adéquats.

Même s’il est important de définir une procédure d’homologation en capacité de traiter les nouveaux SIIV à venir, ce sont surtout les SIIV existants qui occupent les OIV à l’heure actuelle, et la rétro-homologation est prioritaire.

Adopter une approche projet test & learn

Afin de définir et déployer une procédure d’homologation sur son périmètre LPM, l’OIV peut définir un pilote initial, pour roder et perfectionner le processus, avant de l’industrialiser sur l’ensemble des SIIV.

L’objectif de cette phase pilote est de confronter la méthodologie à la réalité terrain, dans une optique de validation de la démarche et des étapes définies (procédures, interlocuteurs à solliciter, etc.). Cette approche fait ressortir les points de difficultés (SI d’administration, cloisonnement, patch management, …), et permet d’apporter un plan de remédiation concret et réalisable.

Le choix du SIIV pilote est primordial pour pouvoir anticiper les problématiques qui vont être rencontrées. Ainsi, il est préférable de choisir un SIIV pilote représentatif de l’ensemble des autres SIIV (taille moyenne, interactions limitées, etc.).

Démontrer la sécurité apportée par la LPM

Au sein des différents chantiers et projets engendrés par la LPM, celui de l’homologation permet de concrétiser le renforcement effectif de la sécurité. Non seulement en mettant en visibilité la sécurité de manière interne à un haut niveau (DG, autorité d’homologation) et de manière externe (ANSSI, État), mais également en mesurant la réduction des risques exigée (analyse de risques) et réalisée (audit).

La réalisation de l’homologation permet de communiquer sur les risques réels, d’identifier, de sensibiliser et de responsabiliser les acteurs concernés (en particulier la Direction au travers du rôle de l’autorité d’homologation).

L’ensemble des actions de mise en conformité LPM est regroupé dans le dossier d’homologation, et porte une réalité pratique. On y retrouve notamment les constats de sécurité, les points bloquants et un aperçu du degré de complexité de la mise en conformité.

Le dossier d’homologation doit être à la disposition de l’ANSSI. À ce titre, il constitue la vitrine de l’OIV vis-à-vis de la l’ANSSI pour la LPM, et gagne à ne pas être bâclé ! Il doit démontrer les acquis de sécurité et la validation concrète des réponses théoriques de mise en conformité.

Assurer le maintien de la sécurité dans le temps

Créer une dynamique d’homologation

Une homologation ne s’arrête pas lorsque la décision d’homologation est prononcée et le système mis en production. Cette étape ne marque que le commencement du management des risques. Il s’agit par la suite d’animer, de mettre en visibilité et d’assurer un contrôle permanent de la sécurité. L’arrêté précise que l’homologation doit être renouvelée au minimum tous les 3 ans, où lors d’évolutions majeures sur le SIIV, qui remettent en cause le contexte sécurité du SIIV tel que décrit dans l’analyse de risques.

Pour les SIIV existants, il est donc nécessaire de mettre en place un processus pour contrôler et détecter les évolutions du contexte de sécurité du SIIV. Cela doit notamment s’appuyer sur une organisation, par exemple avec un acteur en charge de détecter et d’évaluer ces évolutions de contexte. Il peut notamment établir une liste d’événements déclencheurs (par exemple : changement d’exposition du SIIV, arrivée de prestataires, évolution fonctionnelle du SIIV, modification d’infrastructure ou de gestion opérationnelle) qui servira de base à l’évaluation du besoin de renouvellement.

La mise en place du comité de gouvernance de l’homologation permet d’assurer une animation du processus d’homologation. La mise à jour de la méthodologie d’Intégration de la Sécurité dans les Projets permet de capter les nouveaux projets, d’y appliquer le management des risques dès le début du projet et d’anticiper la mise en conformité d’un SIIV.

Poser un cadre clair et compréhensible pour les propriétaires applicatifs

Les propriétaires applicatifs représentent des acteurs clés dans le maintien de la sécurité et de l’homologation dans le temps. Non seulement car ils possèdent une bonne vision de leur SIIV, mais également car ils en perçoivent les évolutions. S’ils ont « peur » de la LPM, cela peut amener à une mauvaise implémentation de la sécurité. Au contraire, une bonne compréhension des enjeux de la LPM, de l’homologation et de l’amélioration continue est bénéfique pour la sécurité du SIIV.

Il est recommandé de prêter une attention particulière sur l’accompagnement et la sensibilisation des propriétaires applicatifs à la sécurité en général, et à l’homologation en particulier. Dans une démarche gagnant-gagnant, il faut embarquer et fédérer les propriétaires applicatifs pour bonifier la sécurité dans le temps.

L’homologation de sécurité, une démarche permettant d’approfondir la maîtrise des risques dans la durée

Au-delà de la contrainte réglementaire pure, la LPM doit être considérée comme un formidable accélérateur permettant d’approfondir la maitrise des risques au sein de l’Opérateur d’Importance Vitale, depuis les équipes opérationnelles, les propriétaires applicatifs et jusqu’à la Direction.

Après une première étape de mise à niveau et de mesures de réduction des risques sur les SIIV existants, l’enjeu de l’homologation est d’assurer le maintien dans le temps du niveau de sécurité sur le périmètre des SIIV. A ce titre, il est nécessaire d’animer dans le temps les différentes instances, afin de conserver la dynamique initiale.

Cet article L’homologation de sécurité, clé de voute de la mise en conformité LPM est apparu en premier sur RiskInsight.