ENASS Papers 2021

Nouvelles technologies, Cyber Risk

Créé le

10.11.2021

9. ACPR. Document de réflexion (final) « Le risque informatique » – janvier 2019

Ce texte résume les travaux de la consultation publique de 2018 sur le risque informatique. C’est probablement le texte le plus complet sur le sujet. Il pourrait constituer la base d’un manuel d’audit avant souscription d’une police « risque informatique », et doit donc être étudié par les souscripteurs de façon approfondie, notamment parce qu’il montre comment « l’ancrage » de ce risque dans le risque opérationnel est réalisé.

1. L’ACPR propose une définition extensive du cyber-risque : « risque de perte résultant d’une inadéquation ou d’une défaillance des processus d’organisation, de fonctionnement ou de sécurité du système d’information, entendu comme l’ensemble des équipements, systèmes ou réseaux, des logiciels et des données, ainsi que l’ensemble des moyens humains contribuant au traitement de l’information de l’institution » (entité, entreprise). Toutes les dimensions du risque sont ainsi couvertes.

La cybersécurité est définie par la BCE comme « les contrôles et normes d’organisation ainsi que les moyens (humains, techniques, etc.) utilisés pour protéger les éléments du système d’information et des réseaux de communication contre toutes attaques logiques, que celles-ci soient conduites par le biais de brèches de sécurité physiques ou logiques. Ces contrôles et mesures incluent la prévention, la détection et la réponse à toute activité informatique malicieuse, ou à toute négligence qui pourrait affecter la confidentialité, l’intégrité ou la disponibilité des systèmes et des données, de même que la traçabilité des opérations effectuées sur ce système et ces réseaux ».

2. L’organisation du Système d’Information (SI) et sa sécurité sont majeures. L’ACPR énumère les différentes étapes : les décisions de la direction générale et de l’AMSB ; la définition d’une stratégie informatique ; le pilotage budgétaire ; la définition des rôles et responsabilités de la fonction informatique ; la rationalisation du système d’information ; la maîtrise de l’externalisation ; le respect des lois et règlements (conformité RGPD/LCB-FT, etc.) ; la gestion des risques. Pour chacune de ces étapes, elle indique les risques ou les défauts qui doivent être relevés et évités : responsabilités mal définies, mauvaise connaissance des besoins métiers, manque de maîtrise de l’architecture, forte dépendance à l’égard de la sous-traitance, faiblesse de la cartographie des risques, failles dans le système des 3 niveaux de contrôle interne, notamment.

3. Le fonctionnement du SI recouvre 4 types de tâches : la gestion de l’exploitation, la gestion de la continuité d’exploitation, la gestion des changements (gestion de projets, des évolutions, des corrections), la qualité des données. Les points majeurs sont la détection et la gestion des erreurs, anomalies, incidents et problèmes, la bonne gestion de la continuité et l’identification des scénarios d’indisponibilité, la protection insuffisante et la faiblesse des tests, la qualité de la conduite des projets, la normalisation insuffisante des données, et l’insuffisance du contrôle de qualité des données.

4. Quant à la sécurité, l’ACPR donne la liste suivante des actions de sécurisation : la protection physique des installations, l’identification des actifs (logiciels, données), la protection logique des actifs (notamment contre les logiciels malveillants, la gestion des droits d’accès et la protection de la confidentialité des données, la sensibilisation à la sécurité), la détection des attaques (analyse des traces, détection des comportements anormaux des utilisateurs), qualité des dispositifs de gestion de crise (contingentement des attaques, défaillance dans les dispositifs de reprise des opérations).

Ce document mériterait une large publicité auprès des gestionnaires SI et Sécurité SI, et des assureurs qui développent des produits de garantie des risques cyber. S’il en était besoin, il illustre parfaitement l’utilité d’expertise avant souscription dans un domaine où la description (cartographie) des risques fait encore souvent défaut.

9. ACPR. Notice relative aux modalités de mise en œuvre des orientations de l’EIOPA (BOS 20-600) relative à la sécurité et la gouvernance des technologies de l’information – 18 juin 2021

Nous nous contenterons de résumer le texte de l’ACPR qui commente celui de l’EIOPA de la fin de l’année 2020 et qui compte 25 « orientations » (guidelines). Il s’agit de faire la liste des recommandations de l’ACPR pour la sécurité des systèmes d’information des assureurs.

On rappelle le principe de proportionnalité (c’est traditionnel).

Les préoccupations de risque cyber doivent être incluses dans la gouvernance et sont de la responsabilité de l’AMSB.

L’AMSB assume une stratégie « écrite » en matière d’informatique : on espère que c’était déjà le cas.

Les entreprises incluent les SI dans leur système de gestion des risques : cartographie, identification et évaluation des risques, mesures de gestion de risque, « appétit et tolérance pour le risque ».

Les risques SI doivent être audités.

Il faut rédiger une politique écrite de sécurité de l’informatique.

L’ACPR souhaite la création d’un poste de responsable de la sécurité de l’information, indépendant et rendant compte à l’AMSB. Serait-ce l’émergence d’une 5e fonction clef dans le cadre du pilier 2 de Solvency II ?

L’Autorité liste précisément les divers points d’application de la « sécurité logique » (identité et accès des utilisateurs notamment), et la gestion des « droits d’accès » (notions de « besoin d’en connaître », d’accès privilégié et de surveillance, notion dite de « moindre privilège » et de « séparation des fonctions »).

Après un développement sur la « sécurité physique » des SI, elle énumère les actions sur les risques des opérations elles-mêmes : l’identification des vulnérabilités potentielles, la segmentation du réseau, la préservation de l’intégrité des données.

La surveillance de la sécurité s’exerce sur les « éléments internes ou externes » et, naturellement, sur les sous-traitants.

Cette surveillance est réalisée par des tests de sécurité qui doivent être récurrents.

Il importe d’assurer une formation et une sensibilisation de l’ensemble du personnel et de l’AMSB aux questions de sécurité informatique.

Trois points majeurs concernent la gestion des opérations : l’inventaire des actifs informatiques (à jour des évolutions de logiciels), les sauvegardes mises en place et, surtout, l’enregistrement des opérations critiques.

La gestion des incidents doit faire l’objet d’une procédure ou processus (écrit), visant à identifier, suivre, consigner et classer les incidents, définir les rôles et responsabilités et mettre en place une communication interne, et éventuellement externe, sur les incidents et les réponses apportées.

Il est recommandé d’organiser une direction de projet ad hoc pour les projets informatiques mis en œuvre.

Quant à l’acquisition et au développement de systèmes, l’ACPR indique notamment la nécessité de protéger les codes-source, de maintenir une maîtrise de la connaissance du système, de documenter les développements et de surveiller les logiciels acquis et gérés par les utilisateurs métiers sans l’aval de la direction informatique (situation assez fréquente).

Un processus de gestion des changements liés aux SI doit être écrit (conduite de projets).

L’AMSB est responsable de la continuité des activités et doit contrôler que celle-ci est prévue (plan de continuité d’activité).

Des scénarios peuvent être développés pour établir et mesurer l’impact des perturbations sur la continuité des activités.

La sécurité informatique doit donc être incluse dans les plans de continuité d’activités.

Les entreprises devraient définir des « plans de réponse et de rétablissement » dont l’ACPR détaille la composition, la documentation et la mise à jour.

Ces plans (PCA et plans de rétablissement) doivent être régulièrement testés et mis à jour (c’est trop rarement le cas).

La mise en place d’une communication de crise est indispensable (surtout en cas de vol de données et de risque de sanctions au titre du RGPD).

Enfin, l’ACPR rappelle les précautions à prendre en cas de sous-traitance, notamment des fonctions critiques ou importantes, comme la sécurité des services localisés dans le « cloud », et la vigilance à porter sur la rédaction des contrats de prestations de service.

En définitive, ces recommandations ne sont pas nécessairement novatrices, mais elles sont mieux écrites qu’implicites. Il n’est d’ailleurs pas certain qu’elles soient toutes appliquées. L’essentiel est la création d’une nouvelle fonction semi-indépendante de responsable de la sécurité informatique et l’incitation à une forte implication de l’AMSB dans la responsabilité de cette nouvelle fonction.

9. ACPR. Analyses et synthèses n° 117.2020 – Synthèse de l’enquête déclarative de 2019 sur la gestion de la sécurité des systèmes d’information des assureurs

Il s’agit ici de l’appréciation de la gestion par les assureurs de leur propre risque informatique, après une première enquête en 2015.

Ce bilan est en demi-teinte. Des progrès ont été effectués en matière de gouvernance du risque de cartographie, de définition d’une stratégie de sécurité informatique et de « politique écrite ». Les plans de continuité d’activité existent, les tests de scénario de crise sont effectués, mais il y manque des scénarios de cyberattaque.

L’analyse de la sous-traitance semble assurée, mais les solutions externes (Shadow IT, End User Computing) sont mal contrôlées.

Enfin, le contrôle de la sécurité informatique (SSI) semble peu ou mal coordonné avec la politique générale de contrôle interne (les 3 niveaux de contrôle de l’ERM et de Solvency II). Il reste beaucoup à faire sur l’inventaire des « versions » des logiciels, la revue systématique des habilitations, et l’intégration de la sécurité informatique dans le contrôle des sous-traitants.

Les budgets restes modestes : la sécurité SI représente 5 à 7 % du total du budget des systèmes d’information.

9. Cyber Expert Group (CEG) – Proposition d’une classification commune des incidents informatiques – 6 avril 2021

Ce document remarquable a été rédigé par le CEG représentant les experts cyber des autorités de contrôle du Canada, de l’Union européenne, de France, d’Allemagne, d’Italie, du Japon, du Royaume-Uni et des États-Unis, sur la base d’une commande du G7 Finances de Chantilly en juillet 2019.

Les experts constatent la nécessité d’un reporting des « incidents » cyber aux autorités de contrôle. Or, les obligations actuelles sont insuffisantes, la diversité des réglementations, dans chaque pays, rend l’information peu utilisable (nomenclatures différentes des incidents). Les obligations de compte rendu portent sur les attaques réussies et non sur l’ensemble des incidents. Les obligations ne permettent pas d’obtenir une visibilité sur la sévérité des incidents. Une classification uniformisée de ces incidents est donc nécessaire.

• Les principes proposés pour cette « taxonomie » sont les suivants :

– elle doit couvrir tous les accidents de sécurité et de fonctionnement, y compris les passes et erreurs. On exclut donc un pré-classement différenciant « pannes » et « piratage » ;

– on distingue les « événements » (changement dans le fonctionnement des systèmes) et les « incidents » (qui compromettent, sans autorisation, la confidentialité, l’intégrité, la disponibilité de l’information ou du système informatique) ;

– on développe une « approche multidimensionnelle » ou une « approche multiple », en distinguant « l’incident », son « impact », son ampleur, sa gravité.

Le CEG s’appuie sur des taxonomies existantes pour en faire la synthèse et ne pas créer un outil trop spécifique.

• Le CEG propose une matrice multidimensionnelle fondée sur 4 piliers.

Pilier 1. Description de l’incident (de sécurité ou de fonctionnement) en renonçant à la distinction « malveillant » ou « non malveillant » :

– les incidents « malveillants » sont décrits selon les 12 tactiques identifiées par l’organisation américaine MITRE. Le CEG propose une simplification de ces techniques d’attaque en 8 chapitres : les attaques à partir du web, le phishing (vol de données à partir du compte du client), l’interruption de service, manipulations physiques (destruction, vol et pertes), vol d’informations (exfiltration de données), vol d’identité, rançongiciels, vol de données liées aux cryptomonnaies (cryptojacking) ;

– les incidents non malveillants sont classés en « accidentels » (erreur d’utilisation), « structurels » (incidents machines, contrôles au software), ou « environnementaux » (incendie, inondations, panne d’électricité, etc.)

Pilier 2. Les impacts de ces incidents sont classés en trois types :

– techniques : atteinte à la confidentialité, l’intégrité et la disponibilité des données ;

– professionnels : les impacts sur le business peuvent être financiers, de réputation, juridique et conformité, contractuel, ou atteindre aux objectifs de l’entreprise ;

– opérationnels : on croise l’existence de l’impact, le caractère critique ou non du service, l’ampleur de l’impact, et l’existence d’une interruption de service (critique ou non).

Pilier 3. L’amplitude de l’incident. La nomenclature prévoit 7 niveaux d’atteinte des systèmes d’information, de l’interface web (niveau 1) à l’atteinte à des systèmes critiques de sécurité (niveau 7).

Les éléments du Système d’information atteint sont classés en 5 rubriques : bases de données, système d’information, réseau, les « fournitures » et les outils (portables).

La liste des informations affectées par l’incident : inconnu, informations personnelles, informations commerciales ou industrielles, informations critiques/non critiques, accès aux codes d’authentification.

La liste des services affectés : comptes courants, produits d’épargne, assurance, etc.

La liste des entités affectées : banque, assurance, gestion de titres, conseillers financiers… mais aussi Agences de notation et sous-traitants (multiples).

Pilier 4. La gravité. La nomenclature propose trois critères sur la gravité de l’incident : le caractère significatif (nombre de clients affectés par exemple), la durée de l’incident (réelle ou prévue), la communication interne ou publique de l’incident.

La matrice globale de reporting des incidents est représentée page suivante.

Au total, ce document, s’il est adopté, devrait permettre une description très précise de l’historique des « sinistres » (ou des incidents) constatés, de toutes formes. C’est la base d’une démarche efficace de tarification. L’accueil réservé à cette démarche n’est pas connu des auteurs de cette chronique, mais on peut considérer que c’est un pas significatif vers la bonne gestion du risque cyber.

9. Commission européenne – Proposition de création d’une unité conjointe de cybersécurité (2021/0166). 23 juin 2021

La Communication de la Commission et du Haut représentant pour les Affaires étrangères et la politique de sécurité ne présente pas d’intérêt. Elle réaffirme l’importance de la sécurité informatique pour l’Europe et la nécessité de construire une capacité opérationnelle pour prévenir, détecter et répliquer aux attaques, tout en avançant vers un cyberespace global et ouvert.

La Commission propose surtout de créer une unité conjointe pour prévenir les incidents de cybersécurité, entre le 30 juin 2022 et juin 2023. Il est malheureusement probable que cette bureaucratie construite entre la Commission et le « ministère des Affaires étrangères » de l’Union ne fasse pas vraiment progresser le sujet du cyber-risque et cultive la rédaction de Rapports sur la stratégie de cybersécurité de l’Union.

À noter aussi la création d’une Agence de l’Union européenne pour la cybersécurité qui devrait assurer le secrétariat général de l’Union conjointe.

Les assureurs ont peu à attendre de cette « comitologie ».

9. Rapport du Comité consultatif d’experts de l’EIOPA sur l’éthique digitale dans l’assurance. 17 juin 2021 – Principe de gouvernance de l’intelligence artificielle

L’intérêt de ce texte est moins dans son contenu que dans la démarche qu’il préfigure. Il s’agit clairement d’engager un processus de création d’une réglementation de l’utilisation de l’intelligence artificielle dans l’assurance, sous couleur (ou dans le cadre) d’une démarche « éthique ». L’EIOPA ne manque pas de rappeler que la démarche de ce groupe d’experts s’inscrit dans la continuité (en prenant en compte la spécificité de l’assurance) des travaux d’un autre groupe d’experts sur l’IA de « haut niveau », réuni par la Commission. Un nouveau champ s’ouvre donc à l’activité régulatrice.

1. Le rapport note la multiplicité des utilisations de l’intelligence artificielle (IA) dans l’assurance : la conception des produits, la tarification, la souscription, la distribution, la gestion des contrats, la prévention, la gestion des sinistres, le provisionnement, la détection et la gestion de la fraude. Il tente de faire la liste des questions « éthiques » (morales ?) que soulève l’utilisation des instruments de l’IA : la diminution (disparition ?) de l’asymétrie d’information, le risque d’exclusion du fait de la réduction des mutualités de risques liée à la forte segmentation des tarifs, les conflits avec le Règlement général sur la protection des données (ne faut-il pas le réformer ?), l’ajustement du rythme de mise en place de réglementations sur le rythme du progrès technologique, l’application du principe de précaution, et la question du consentement éclairé du client à l’usage de ces données.

Les experts suggèrent donc d’introduire deux nouveaux concepts : des produits « ethically aligned » (conformes à l’éthique) et l’introduction de la Responsabilité digitale dans la responsabilité sociale d’entreprise. Donc, une extension de la RSE ou ESG à l’intelligence artificielle : l’assurance sera non seulement « verte » mais « éthique ».

2. Le rapport met en avant 6 principes éthiques qui doivent gouverner l’emploi de l’IA dans l’avenir (selon les experts).

• La proportionnalité. Elle consiste à étudier l’impact de l’utilisation de l’IA sur les consommateurs (discrimination) et l’entreprise (réputation), et donc la gravité de celui-ci, avant de déterminer les utilisations (ou non) de l’IA dans un processus donné. C’est donner une nouvelle dimension au principe de proportionnalité sans cesse mis en avant dans la réglementation prudentielle avec, il est vrai, peu d’effet.

• La loyauté (fairness) et la non discrimination

Il s’agit de créer des systèmes IA qui « équilibrent les intérêts de toutes les parties prenantes » et de mettre en place une « gouvernance de l’IA » à cette fin. Les experts font la liste des produits d’assurance qu’ils jugent « sensibles » en matière d’inclusion financière (l’auto, la multi-habitation, la santé, la R.C. générale – ? – la vie, la retraite et les accidents de travail). Ils identifient les situations de vulnérabilité des personnes (âge, situation familiale, conditions de santé) à la discrimination/exclusion. Ils rappellent que la collecte et le traitement de données doivent être appropriés à leur usage et que cet usage doit pouvoir être justifié au client. L’IA doit, si l’on comprend bien, se conformer au RGPD. Cela pose évidemment la question de l’usage des réseaux sociaux et, plus généralement, des mégadonnées (Big Data). Il faut donc que les clients, qui ne veulent pas communiquer des données personnelles, puissent bénéficier d’une assurance à un prix acceptable (ce qui est à peu près contraire à la Directive sur la distribution de l’assurance). Il faut introduire des principes de limitation de la « manipulation » et des « incitations excessives » des clients en direction de certains produits. Les experts souhaitent aussi introduire des critères de non-discrimination dans la conception des produits, mais le texte se révèle sur ce point particulièrement tortueux.

Quant aux applications du principe de loyauté, on relève la recommandation de réduire l’impact sur les taux de primes de certains facteurs de scoring (credit scoring, revenu, niveau d’éducation), notamment sur les populations dites « vulnérables » ou « protégées ». Plus généralement, il s’agit de s’assurer qu’il y a corrélation entre le prix du risque et la sinistralité, qu’il existe un lien de causalité entre eux et que celui-ci est conforme aux réglementations anti-discrimination. Il s’agit sans doute des célèbres « corrélations faibles » que détectent les data scientists et le deep learning. Les experts souhaitent aussi lutter contre les pratiques de price optimisation qui consistent à mesurer non le prix actuariel du risque mais les taux de prime que les clients sont prêts à payer. Ils souhaitent donc surveiller les modèles d’étude de prix du marché, les modèles de prévision des résiliations, les mesures de lifetime value des clients, les recherches d’élasticité prix des produits et les informations de comparaison de prix proposées aux clients. C’est une large part du marketing moderne qui serait ainsi mise sous surveillance éthique.

Quant à la gestion des sinistres, les experts s’inquiètent de recherches sur la « disposition du client à accepter » (rapidement) des transactions avec l’assureur, et veulent imposer, dans la gestion de fraude (toujours présente dans les textes sur l’intelligence artificielle) une intervention humaine pour compléter la démarche informatique.

• La transparence et l’explicabilité. Les experts veulent développer l’explication aux clients des facteurs de définition du prix, mais aussi aux auditeurs et aux autorités de contrôle : ils proposent une liste exhaustive de ces explications. Bien entendu, il faut éviter que les algorithmes soient des boîtes noires, et les expliquer (belle naïveté) voire obtenir une compréhension de l’algorithme. Quant aux diverses utilisations (souscription, tarification, gestion des sinistres, détection de la fraude), il s’agit d’éviter les pratiques de ventes croisées, et de garantir une intervention humaine. On craint l’expertise entièrement automatique.

• L’intervention humaine. Outre ce qui est déjà recommandé ci-dessus, les experts veulent une implication forte du management et sa responsabilisation. Ils font une liste considérable des personnels à impliquer : l’AMSB, la fonction compliance, le contrôle des risques, l’audit, etc. Ils recommandent la création d’un comité d’éthique IA-Data dans l’entreprise comprenant à peu près tout l’État-major, et notamment les spécialistes des systèmes d’information, un IA « officer » (un de plus !) et les ressources humaines.

Quant à l’intervention humaine dans les processus de gestion, elle est partout nécessaire sauf, curieusement, dans la tarification et la souscription (alors qu’ils attirent l’attention sur les catégories vulnérables de clients).

• La gouvernance des données et la conservation de celles-ci.

Les experts n’apportent rien de nouveau : ils réclament le respect du RGPD, l’attention donnée à la qualité des données, notamment celles achetées auprès de fournisseurs extérieurs, la sécurité des données et l’écriture des spécificités techniques des algorithmes qu’il faut accompagner d’un document sur la vérification éthique de ces algorithmes. Tout cela doit évidemment être précieusement conservé.

• La solidité et la performance des systèmes d’information

Dans ce domaine, les recommandations sont traditionnelles : bonne gestion des données, sécurité des systèmes informatiques, contrôle des sous-traitants. Tout cela n’a que peu de lien avec les préoccupations éthiques, ou se trouve déjà contenu dans les dispositions du RGPD.

Tout cela n’augure rien de bon pour la simplification administrative des métiers de l’assurance. Faute de pouvoir contrer l’avancée de l’IA dans la gestion des assureurs, les autorités de contrôle se préparent à construire une réglementation des processus de gestion qui, sur la base de préoccupations d’« éthique », vont accroître les pouvoirs de contrôle des autorités nationales et restreindre l’automatisation ou, à défaut, développer les processus de contrôle et de reporting des entreprises. L’EIOPA a déjà entrepris, par ailleurs, d’esquisser les grandes lignes d’une réglementation d’emploi des mégadonnées.

À retrouver dans la revue
Banque et Stratégie Nº407