Cet engouement invite les acteurs historiques et de nouvelles fintechs à se positionner sur le marché des services bancaires en ligne. De nombreuses solutions se déploient aujourd’hui à grande échelle, nécessitant une réglementation adaptée.

La DSP2 et les acteurs financiers

La DSP2, Directive sur les services de paiements 2, s’inscrit dans l’évolution des transactions électroniques. Elle est une nouvelle étape dans la normalisation des échanges financiers après la DSP1 et en parallèle des travaux OpenBanking au Royaume-Uni.

Avec l’évolution du nombre d’acteurs sur le marché, les solutions mises en œuvre pour l’authentification des utilisateurs et la sécurisation des opérations financières se multiplient. Ces solutions peuvent s’appuyer sur des moyens d’échange reconnus comme sécurisés (EBICS, SWIFT…) mais elles ne sont pas les plus aptes à répondre à un besoin de plus en plus important d’accès aux données en temps réel.

Le but de cette directive est d’apporter un cadre réglementaire aux banques et aux acteurs non-bancaires tout en favorisant la concurrence.

Pour cela, la directive circonscrit les prestations réalisées par les acteurs des services de paiements en trois services :

• Le Service d’Information sur les Comptes (« Account Information Service » ou AIS) consiste en l’affichage et l’agrégation des données de solde et des transactions des comptes de paiement.
• L’Initiation de Paiement (« Payment Initiation Service » ou PIS) consiste en la transmission d’un ordre de paiement pour le compte d’un payeur, à son établissement teneur de compte.
• L’Emission d’Instruments de Paiement (« Payment Issuer Instrument Service » ou PIIS) met à la disposition des utilisateurs des moyens de paiement.

Elle impose aux fournisseurs (« Provider ») de ces services un ensemble de règles et d’obligations à remplir. À la condition que ces règles soient appliquées, les AISP, PISP et PIISP auront la possibilité d’accéder gratuitement aux données sur les comptes de paiement de l’utilisateur dans leur établissement teneur de comptes (« Account Servicing Payment Service Provider » ou ASPSP).

Figure 1: Les services du périmètre de la DSP2

L’apport sécuritaire de la DSP2

Pour offrir la possibilité d’accéder aux données des établissements teneur de compte (les banques), la directive impose à ces dernières d’exposer de nouvelles interfaces répondant à un ensemble de mesures de sécurité et permettant la réalisation de ces services.

Figure 2: Exigences sécuritaires de la DSP2

Sous l’impulsion de plusieurs groupes de travail (en particulier le STET et le Berlin Group), la solution retenue est la construction d’API exposant les services des ASPSP, à l’aide des standards Open API adoptés par les géants du Web. En particulier, d’un point de vue sécurité, les standards retenus sont OAuth2 et OpenID Connect.

Identification et authentification des acteurs

En réponse au fonctionnement actuel des agrégateurs, une des mesures d’importance de la directive est l’obligation pour les acteurs bancaires de s’identifier et de s’authentifier entre eux pour réaliser toute opération liée aux comptes de paiement.

En effet, en l’absence d’interface adéquate, les agrégateurs fonctionnent actuellement par « web scraping » qui consiste à simuler la navigation d’un utilisateur sur sa banque en ligne, en rejouant ses secrets de connexion. Cette méthode comporte trois défauts principaux :

• L’agrégateur client n’est pas formellement identifié, empêchant l’établissement teneur de comptes de déterminer s’il s’agit d’un acteur légitime ou non ;
• Les secrets de connexion de l’utilisateur sont transmis et connus par un acteur tiers et ne sont pas gardés confidentiels par l’utilisateur ;
• La traçabilité des opérations n’est pas assurée car il est impossible d’établir la preuve d’origine d’une requête. Plus particulièrement, la granularité d’accès aux services utilisés et informations consultées par un acteur tiers n’est pas possible.

La directive (articles 66 et 67) oblige donc tous les acteurs, notamment AISP et PISP à s’identifier et s’authentifier pour consommer les services. Un consensus s’est établi autour de la réalisation d’une authentification mutuelle par certificat lors de l’établissement de toutes les communications entre un fournisseur de service (TPP) et un établissement teneur de compte (ASPSP).

Renforcement de l’authentification de l’utilisateur

Elément récurrent dans la directive et au cœur de l’un des Regulatory Technical Standards (RTS) définis par l’ABE (Autorité Bancaire Européenne), l’authentification renforcée des utilisateurs est une des mesures structurantes de cette directive.

Aujourd’hui, les solutions s’appuient principalement sur l’utilisation d’un mot de passe (rejouable et sujet au phishing) et sur l’OTP SMS (présentant des risques d’interception) pour l’authentification renforcée. Ces deux méthodes sont très répandues mais présentent des failles de sécurité et sont parfois coûteuses. Les nouveaux services de paiement mobile permettent aussi une identification par l’adresse e-mail ou par le numéro de mobile, non connu de la banque.

Les RTS visent à sécuriser cette authentification de l’utilisateur par la définition d’une authentification renforcée (« Strong Customer Authentication » ou SCA) comme une authentification à deux facteurs indépendants, c’est-à-dire que la compromission de l’un n’entraîne pas la compromission du second. La directive impose que l’établissement teneur de compte fournisse les moyens de réaliser cette authentification renforcée, et que chacun des deux facteurs soit sécurisé sur toute la chaîne de transmission.

Les solutions envisagées pour répondre à ce besoin sont de plusieurs natures :

• Le mot de passe reste un facteur principal aujourd’hui, à condition d’être accompagné d’un second facteur pour l’authentification renforcée.
• Les solutions matérielles, plus sures, présentent l’inconvénient d’un coût supplémentaire : token d’authentification physique, clé ou dispositif FIDO U2F…
• Les solutions logicielles sur smartphone sont en développement constant : notification in-app, token d’authentification logicielle, biométrie à l’aide des capteurs de l’appareil, MobileConnect…

Le lien dynamique, « dynamic linking »

Dans le cas particulier des transactions de paiement, la directive impose qu’un code unique soit généré pour permettre aux acteurs de la transaction d’être, à tout moment du processus d’authentification et d’autorisation, en mesure de retrouver les caractéristiques de la transaction. En particulier, l’utilisateur doit être conscient, durant la totalité du processus, du montant et du bénéficiaire de la transaction qu’il autorise.

Cette mesure est similaire à ce qui est déjà réalisé dans certains cas de paiement en ligne. L’utilisateur est en effet notifié par SMS avec le code OTP correspondant à une transaction unique, de son montant et de l’origine de la demande. Elle généralise donc cet usage et l’impose en condition pour toute transaction de paiement.

Les exemptions à l’authentification forte

Dans la définition du besoin d’authentification forte et les exigences sur la « Strong Customer Authentication », la DSP2 essaie également de maintenir un équilibre avec l’ergonomie de la navigation pour les utilisateurs des services. Pour cela, elle prévoit des cas où les fournisseurs de services de paiement peuvent choisir d’exempter leurs utilisateurs de la réalisation d’une authentification forte.

Les conditions en place pour réaliser ces exemptions sont précisément décrites dans les RTS, notamment suivant les modes de paiement de l’utilisateur. Il est ensuite de la responsabilité des fournisseurs de service de paiement de déterminer, à l’aide d’un score de risque, si une exemption doit être appliquée ou non.

Conclusion

Dans un contexte de digitalisation des services financiers induit par la montée en puissance des fintechs, la Commission Européenne et l’ABE favorisent l’ouverture à la concurrence et donc l’intégration des nouveaux acteurs au sein de l’écosystème des services de paiement. La DSP2 pose un cadre clair pour la sécurisation des services et interconnexions entre acteurs historiques et fintechs. Dans l’état cependant, elle comporte des limitations qui réduisent la portée des mécanismes de sécurité mis en avant. Un prochain article détaillera la nature de ces limitations.

Cet article Sécurité des opérations financières en ligne en 2020 : Quels sont les apports de la DSP2 ? (1/2) est apparu en premier sur RiskInsight.

Tout d’abord, fin septembre 2018 a été publié l’arrêté fixant les règles de sécurité et délais à respecter par les opérateurs de service essentiels (OSE) sur leurs SI essentiels (SIE).

Ensuite, le 9 novembre 2018 les dernières notifications ont été envoyées par l’ANSSI à une première vague d’Opérateurs de Services Essentiels, portant ainsi le nombre d’OSE à 122, chiffre qui sera amené à augmenter dans les mois et années à venir.

C’est donc l’occasion de décrypter la NIS dans sa déclinaison française, d’identifier les principales exigences émises par l’ANSSI et sous quels délais celles-ci devront être respectées par les OSE.

Des règles majoritairement inspirées de la LPM

La directive NIS demande à chaque Etat de définir et d’imposer le respect des bonnes pratiques de sécurité aux OSE et FSN. En France, c’est l’ANSSI qui a été responsable de cette définition, à l’instar de la LPM. Il est donc légitime de se demander dans quelle mesure les règles NIS sont alignées sur les règles LPM.

Des différences de forme sont tout d’abord à noter : les règles NIS sont au nombre de 23 réparties au sein de 4 chapitres (Gouvernance, Protection, Défense, Résilience), contre 20 pour la LPM sans chapitre particulier. Ensuite, ces règles ont été publiées au sein d’un unique arrêté trans-sectoriel, alors que la LPM avait mené à la publication d’un arrêté par secteur d’activité. Autre différence, les délais de mise en application des règles NIS sont communs à tous les secteurs et sont publics, là où les délais pour la LPM varient selon les secteurs et sont en diffusion restreinte.

Néanmoins, les règles NIS restent fortement inspirées (voire pour certaines intégralement reprises) des règles LPM : cartographie, configuration des composants, filtrage, comptes d’administration, SI d’administration, identification, droits d’accès, maintien en conditions de sécurité, journalisation, corrélation et analyse de journaux, réponse aux incidents de sécurité, traitement des alertes et également gestion de crise.

De nouvelles règles font leur apparition ; les règles relatives aux analyses de risques et aux audits de sécurité étaient en fait incorporées dans la règle LPM relative à l’homologation. La règle relative à la sécurité physique et environnementale est quant à elle une réelle nouveauté. De même, certaines règles existantes font l’objet de précisions sans pour autant apporter de modifications structurantes, notamment pour encadrer la façon de traiter certains cas particuliers (SIE exposé sur Internet, etc.).

Finalement, les principales différences portent sur l’assouplissement de certaines règles :

• Indicateurs : les trois thématiques retenues par les règles LPM sont maintenues par les règles NIS (maintien en conditions de sécurité, droits d’accès / authentification et administration des ressources), mais le nombre d’indicateurs total passe de 10 à 6.
• Détection : l’obligation d’utiliser des sondes qualifiées et opérées par un prestataire qualifié PDIS est remplacée par l’utilisation de sondes opérées conformément au référentiel PDIS, sans obligation de qualification
• De manière générale, les règles NIS n’imposent pas le recours à des prestataires dûment qualifiés PASSI (Prestataire d’Audit de la Sécurité des Systèmes d’Information), PDIS (Prestataire de Détection d’Incidents de Sécurité) ou PRIS (Prestataire de Réponse aux Incidents de Sécurité) mais recommandent de s’inspirer des bonnes pratiques que ces référentiels définissent.

Figure 1 : 80% de similarités entre les règles LPM et les règles NIS en France

Les règles NIS, malgré des différences de forme, sont donc globalement similaires à celles de la LPM, ce qui n’est pas surprenant puisqu’elles répondent au même objectif, celui de renforcer le niveau de sécurité des acteurs nationaux clés.

Un planning de mise en conformité ambitieux

Des actions concrètes à réaliser très rapidement

Les délais de mise en application sont publics. Concrètement, les premières actions attendues de chaque OSE après sa désignation sont les suivantes :

• Dans un délai de 2 mois, identification du correspondant auprès de l’ANSSI et communication de ses coordonnées
• Dans un délai de 3 mois, identification des SIE (Systèmes d’Information Essentiels) et transmission de la liste à l’ANSSI. Si le premier réflexe est souvent de vouloir définir le périmètre le plus restreint possible, et ainsi limiter les impacts, il faut garder à l’esprit que l’application partielle de certaines règles peut devenir un véritable casse-tête en raison de l’imbrication des SIE avec le reste du SI.
• Dans un délai de 3 mois, mise en place du processus de traitement des alertes. Objectif : se mettre rapidement en capacité de recevoir les alertes de l’ANSSI et savoir réagir en conséquence.

2 ans pour se mettre en conformité et réaliser l’homologation la 3^ème année.

Pour l’ensemble des autres règles, les délais sont tout aussi précis et ambitieux :

Figure 2 : règles NIS, 2 ans pour se mettre en conformité et une année supplémentaire pour l’homologation

Conclusion

En synthèse, il est important pour les entreprises notifiées d’anticiper dès la phase de cadrage que la mise en conformité NIS va amener des chantiers avec des investissements financiers et humains parfois conséquents. Notamment, les chantiers qui traiteront du « SI Administration », de « l’Homologation », ou encore les chantiers d’urbanisme nécessaires pour le cloisonnement des SIE, etc.

Autant de sujets qui bénéficieront de la maturité du marché impulsée depuis plusieurs années entre autres par la LPM.

Cet article Directive européenne NIS : quelles mesures de sécurité pour les opérateurs de services essentiels en France ? est apparu en premier sur RiskInsight.

La France finalise les textes pour se mettre en conformité avec la directive européenne NIS (Network and Information Security), avec trois textes qui transposent la directive dans le droit national Français, et un quatrième qui sera publié sous peu.

Quels ont été les choix de transposition de la directive NIS dans le droit national Français ? Et quelles seront les entreprises soumises à cette nouvelle législation et les impacts pour celles-ci ?

La transposition dans le droit national français

Pour entrer en vigueur, chaque Etat membre de l’Union européenne doit transposer la directive NIS dans son droit national, avec une date butoir fixée au 09 mai 2018 : spécification des mesures de sécurité à mettre en place, définition des procédures de notification, sanctions applicables…

La France respecte globalement ce calendrier, avec trois textes qui définissent en grande partie les modalités d’application de la directive NIS sur son territoire national :

• La loi n° 2018-133 du 26 février 2018 qui présente les mesures de transposition de la directive NIS dans la législation nationale,
• Le décret n° 2018-384 du 23 mai 2018 qui détaille les modalités d’application des obligations législatives, et liste les secteurs, les types d’opérateur et les services essentiels concernés,
• L’arrêté du 13 juin 2018 qui fixe les modalités de déclarations des incidents de sécurité.

Pour que la transposition de la directive européenne dans la législation Française soit complète, un dernier arrêté fondamental va être publié, et viendra préciser les mesures de sécurité à mettre en œuvre par les opérateurs de services essentiels. Il fera écho à la lettre de mise en demeure par la commission européenne, qui avait jugé la France en retard sur l’exhaustivité de la transposition dans le droit national, tout comme 16 autres Etats membres.

OSE et FSN : deux grandes typologies d’acteurs concernés

La loi française rappelle les deux grandes typologies d’acteurs concernés par la directive européenne : les Opérateurs de Services Essentiels (OSE) et les Fournisseurs de Services Numériques (FSN).

Opérateurs de services essentiels : la France élargit la liste des secteurs concernés

Les OSE sont les entités qui délivrent des services essentiels au fonctionnement de la nation, notamment au travers de leur Système d’Information Essentiel (SIE). Le décret n° 2018-384 complète la liste de la directive, en y ajoutant les secteurs de l’assurance, de la logistique, des produits pharmaceutiques, des services sociaux (partie paiement des prestations), de l’éducation et de la restauration collective dans les environnements sensibles.

Liste des secteurs d’activités concernés pour les OSE

(L’icône  précise les secteurs ajoutés par la législation Française par rapport à la Directive NIS)

La désignation des OSE sera effectuée par arrêtés du Premier Ministre d’ici novembre 2018, en lien avec les OSE, les Ministères concernés et l’ANSSI. La liste des OSE sera par la suite régulièrement actualisée, à minima tous les deux ans.

Fournisseurs de services numériques : la France veille à la bonne désignation des représentants

Les FSN sont les entités qui fournissent directement des services en ligne, de type sites d’e-commerce, moteurs de recherche ou services cloud, notamment utilisés par les OSE. Les Etats membres n’ont pas vocation à dresser la liste des FSN à l’échelle de leur territoire, mais la France pose pour autant un cadre en indiquant que les entreprises qui emploient moins de cinquante salariés et dont le chiffre d’affaire annuel n’excède pas 10 millions d’euros ne sont pas concernées.

Liste des secteurs d’activités concernés pour les FSN

En complément de la directive NIS, la France inscrit dans sa loi n° 2018-133 (Chapitre III, article 11) qu’un FSN établi hors de l’Union Européenne, qui offre ses services sur le territoire national et qui n’a désigné aucun représentant dans un autre Etat membre de l’Union européenne, procède à la désignation d’un représentant établi sur le territoire national auprès de l’ANSSI. La France se positionne ainsi en gardienne de la bonne application de la directive NIS en ce qui concerne les FSN, dans la mesure où un FSN qui tarderait à désigner un représentant en Europe serait donc légalement contraint de le faire en France.

Les exclusions : ne pas cumuler les exigences légales

Afin de ne pas surcharger de législations les acteurs déjà soumis à des règlementations plus contraignantes, la loi mentionne dans ses articles 2 et 5 la liste d’exclusions suivante :

• Les OSE ou les FSN soumis à des exigences sectorielles au moins aussi contraignantes que la présente législation, en particulier les OIV (Opérateurs d’Importance Vitale) sur leur SIIV (Système d’Information d’Importance Vitale) car déjà soumis aux exigences apportées par la Loi de Programmation Militaire,
• Les opérateurs de réseaux ou de services de communications électroniques, notamment car déjà soumis aux exigences du code des postes et des communications électroniques,
• Les prestataires de services de confiance soumis aux exigences du règlement eIDAS sur l’identification électroniques et les transactions électroniques.

Une législation plus stricte pour les OSE que pour les FSN

Le droit national Français traite des mêmes thématiques pour les OSE et les FSN, mais dans une approche différente : même si une base commune est définie, les OSE devront respecter une liste précise de mesures de sécurité, tandis que les FSN seront sur une approche par les risques (précisée par le règlement UE- 2018/151 du 30 janvier 2018), restant libres de prendre les mesures techniques et organisationnelles qu’ils jugent appropriées et proportionnées, et seront plutôt gérés à l’échelle européenne.

Une base commune d’obligations à respecter…

En premier lieu, l’identification d’un représentant de l’entreprise, qui sera le point de contact unique de l’ANSSI pour traiter les réceptions et les transmissions d’information,

Ensuite, la déclaration des réseaux et des systèmes d’information nécessaires à la fourniture du services essentiels / numériques, y compris ceux dont l’exploitation est confiée à des tiers. Au-delà d’un simple inventaire ou cartographie des actifs, les enjeux seront :

• De lister les éléments nécessaires à la délivrance des services essentiels / numériques, afin de ne pas imposer les mesures de sécurité sur un périmètre trop étendu de l’entreprise,
• D’exiger la mise en application de la règlementation sur les systèmes opérés par les tiers, en leur communiquant les mesures à implémenter, en révisant les contrats de sous-traitance, voir en auditant leur conformité.

Puis la déclaration des incidents de sécurité sans délai auprès de l’ANSSI (qu’il est conseillé de formaliser dans un processus), lorsqu’ils sont susceptibles d’avoir un impact significatif sur le service, en terme du nombre d’utilisateur impactés, de la zone géographique touchée, de la durée de l’incident… L’ANSSI pourra alors épauler l’entreprise sur le traitement de l’incident, notamment en activant le réseau des CSIRT.

Et enfin, l’obligation de se soumettre à des contrôles du respect des obligations ci-dessus, et qui devront faire l’objet de conventions et de rapports formalisés. Le 1^er ministre indiquera si ces contrôles seront effectués par l’ANSSI ou l’un des prestataires de services qualifiés PASSI (dans ce dernier cas, l’entreprise choisira le prestataire sur la liste qui lui sera communiquée).

… Mais des obligations complémentaires structurantes pour les OSE.

Contrairement à la liberté laissée aux FSN sur la manière de sécuriser leur services numériques, les OSE devront mettre en œuvre une démarche de sécurisation de leur SIE selon 4 grands principes imposés, qui seront bientôt détaillés par le futur arrêté :

• Gouvernance de la sécurité, via l’élaboration de politique de sécurité et d’homologation du SIE,
• Protection des SIE, avec la sécurité de l’architecture, de l’administration et des accès au SI,
• Défense des SIE, avec la détection et le traitement des incidents de sécurité,
• Résilience des SIE, notamment au travers de la gestion de crise.

Les opérations de contrôle pourront être déclenchées sans condition par le 1^er ministre pour les OSE, alors qu’elles ne seront menées chez les FSN que si le 1^er ministre est informé du non-respect d’une des obligations qui leur incombent.

Quels impacts financiers associés cette législation ?

Tout d’abord, la législation précise clairement que les OSE et les FSN devront financer leurs différentes actions de mise en conformité, mais également les contrôles demandés par l’ANSSI.

Ensuite, en cas de manquement à leurs obligations, les dirigeants des OSE et des FSN pourront écoper d’amendes, avec des montants supérieurs pour les OSE par rapport aux FSN :

L’ordre de grandeur et le principe des amendes sont quant à eux plus proches de ceux apportés par la Loi de Programmation Militaire que ceux du Règlement Général sur la Protection des Données (RGPD).

Quelles sont les prochaines étapes ?

La publication de l’arrêté qui précisera les règles de sécurité pour les OSE, indispensable pour compléter la transposition de la directive NIS dans le droit national Français. Il permettra de jauger le niveau de sécurisation souhaité par l’état Français, et d’en déduire l’effort de mise en conformité des SIE.

D’ici au mois de novembre, la désignation progressive des OSE, qui auront alors :

• Deux mois pour communiquer les coordonnées de leur représentant à l’ANSSI,
• Trois mois pour formaliser et transmettre la liste et la description des réseaux et systèmes d’information pour lesquels l’existence d’incidents pourrait gravement affecter la continuité des services essentiels au fonctionnement de la société ou de l’économie.

Pour les FSN, la désignation d’un représentant, avec deux cas possibles :

• Si le siège se situe en Union Européenne, déclaration auprès de l’autorité de l’Etat où se situe le siège,
• Si le siège se situe hors de l’Union Européenne, déclaration auprès d’une autorité d’un Etat membre où le FSN exerce son activité.

Les acteurs concernés par la directive NIS sont consultés en France et en Europe depuis plus d’un an et sont informés de leur potentielle désignation. Ils ne seront donc pas surpris le moment venu. Ces derniers peuvent d’ores et déjà lancer les premières actions de mise en conformité : identification du périmètre concerné, inventaire des réseaux et système d’information qui le composent, formalisation du processus de déclaration des incidents de sécurité aux autorités.

Des modalités de mise en œuvre qui restent à préciser aux niveaux national et local

Une fois que le dernier arrêté concernant les mesures de sécurité pour les OSE sera publié, le cadre législatif et règlementaire Français posera des bases claires d’application de la directive NIS, par ailleurs cohérentes avec les différentes règlementations déjà en place sur le sujet.

En revanche, des questions restent à trancher au niveau européen pour faciliter la gestion des acteurs transfrontaliers : rattachement d’un OSE à plusieurs Etats membres ? Désignation d’une autorité de référence ? Communications et hiérarchie entre autorités nationales ?… Autant d’enjeux à adresser rapidement par le groupe de coopération dédié à NIS, en place depuis février 2017.

Cet article Directive européenne NIS : quelle transposition dans le droit français et quel impact pour les entreprises ? est apparu en premier sur RiskInsight.