Assureurs et maîtrise des risques

Retour d’Expérience

– (Cyber)sécurité –

| Introduction sur le contexte de la mission

L’accroissement des cyberattaques augmente les préoccupations liées au risque informatique au sein du secteur de l’assurance. Les activités métiers sont aujourd’hui dépendantes de Systèmes d’Information automatisés et les dommages informatiques ou au patrimoine informationnel de l’entreprise sont devenus des risques majeurs pour les activités de ces établissements. Les conséquences peuvent être majeures voire systémiques. Il est donc important de vérifier que votre assurance permet de vous couvrir face à ces risques. Il est important de bien lire les conditions de votre contrat pour connaitre l’étendue des garanties proposées par votre assurance.

Afin d’adresser cela, l’ACPR (Autorité de Contrôle Prudentiel et de Résolution, le superviseur français du secteur financier), qui agit dans le cadre du mécanisme européen de supervision unique bancaire a renforcé son action et ses contrôles dans le secteur de l’assurance.

La mission a été réalisée auprès d’un client grand compte de l’assurance présent à l’international. Le commanditaire était le CISO, rattaché à la Direction des risques opérationnels. La mission a porté sur l’établissement de la cartographie des risques IT et Cyber, l’appropriation et la déclinaison opérationnelle des facteurs de risques selon le cadre de référence de l’ACPR puis leurs déclinaisons en plan de contrôles de niveau 1 et 2 en vue d’une intégration in fine dans l’outil Enablon. Chaque contrôle du plan a ensuite fait l’objet d’une définition sur des critères précis que nous développerons dans la suite du document. Avec un enjeu fort de rendre ces contrôles opérationnels et bien documentés afin que les acteurs internationaux en charge de les renseigner ne puissent pas interpréter ou mal renseigner la preuve attendue, conformément aux actions prévues au contrat.

La suite du document s’attache à décrire ceci et nous illustrons notre propos pour certains facteurs de dangers, l’objectif n’étant pas d’être exhaustif mais d’apporter un éclairage factuel entre la théorie du référentiel (ACPR) et sa traduction opérationnelle.

| La maîtrise des risques : le cadre de référence

L’ACPR a défini le risque informatique de la façon suivante : Le « risque informatique » (ou « risque des technologies de l’information et de la communication – TIC », ou « risque du système d’information ») correspond au risque de perte résultant d’une organisation inadéquate, d’un défaut de fonctionnement, ou d’une insuffisante sécurité du système d’information, entendu comme l’ensemble des équipements systèmes et réseaux et des moyens humains destinés au traitement de données de l’institution. » Cette notion de risque est essentielle pour les compagnies d’assurance.

L’ACPR a également catégorisé le risque informatique en trois processus :

1. Organiser le Système d’Information (S.I) ;

2. Faire fonctionner le S.I ;

3. Sécuriser le S.I.

Pour chacun de ces processus, l’ACPR indique une série de facteurs de risque, élaborée sur deux niveaux, principaux et secondaires. Pour chaque facteur de risque, sont indiquées les principales mesures de réduction et de maîtrise des risques attendues. Ces mesures sont indicatives et il est bien évidemment nécessaire de se les approprier. Cette catégorisation permet aux assureurs d’élaborer ou de renforcer leur cartographie des risques. Elle permet également d’assurer une meilleure gestion des sinistres. Il est important de garantir la conformité. Nous proposons également des services d’audit.

| Qu’est-ce que la mutualisation des risques ?

La mutualisation des risques représente le principe fondamental sur lequel reposent les contrats d’assurance modernes. Ce mécanisme permet aux compagnies d’assurance de répartir les risques présents entre l’ensemble des assurés qui partagent des caractéristiques similaires. Concrètement, les cotisations versées par toutes les parties servent à indemniser ceux qui subissent un sinistre couvert par le contrat.

Par exemple, dans une assurance de responsabilité professionnelle, les risques liés à l’activité sont partagés entre tous les professionnels assurés. Les garanties prévues au contrat s’appliquent ainsi de manière équitable, créant un système où chaque assuré contribue à la protection collective tout en bénéficiant d’une couverture individuelle. Ce terme désigne donc un système solidaire permettant aux compagnies d’assurance d’offrir une protection financière optimale face aux aléas.

Bien que la mutualisation des risques soit une stratégie efficace, il est important de noter que les SCPI ne sont pas à l’abri des risques liés à la cybersécurité. Les données des investisseurs et des locataires peuvent être compromises en cas de cyberattaque, ce qui peut entraîner des pertes financières et une atteinte à la réputation de la SCPI. Il est donc essentiel de choisir une SCPI qui prend au sérieux la cybersécurité et qui met en place des mesures de protection adéquates.

| La mission

1. Appropriation et déclinaison des processus et facteurs de risques

Les facteurs de risques ont fait l’objet d’un mapping avec les règles internes définies par le Groupe à partir du NIST (référentiel en usage pour notre client). Puis chacun des facteurs a été décliné en « situation de risques » pour coller au plus près de la réalité de l’entreprise suscitant parfois de long débats entre CISO et DSI sur ce qu’il fallait mesurer et comment le mesurer entre points forts ou points faibles de l’entreprise et ce que l’entreprise souhaitait mettre en exergue pour faire évoluer son niveau de maturité ou pas. Lors de cette occasion, nous avons partagé notre perspective et nos recommandations afin d’optimiser la prévention et de garantir la protection des informations sensibles de l’entreprise. Il est important de prendre en compte le besoin exprimé par l’entreprise pour atteindre un niveau élevé de sécurité. Nous avons bien évidemment à cette occasion apporté notre vision et nos conseils.

a)  Le processus « Organiser le Système d’Information »

Le processus « Organiser le SI » est découpé en huit facteurs de risques.

Pour bien comprendre le découpage en facteurs de risques principaux et secondaires, prenons l’exemple du facteur « Décisions de la Direction Générale » qui se traduit en facteur de risques principal par « Implication insuffisante des instances dirigeantes » puis en facteurs secondaires suivants :

• Mauvaise perception des enjeux ;

• Décisions inappropriées ;

• Pilotage insuffisant.

Pour ce facteur, la perception des enjeux est liée notamment à l’appétence aux risques (Risk Appetite) des membres du Comex. Il est donc primordial en début de démarche de les interviewer pour évaluer cela et orienter la suite des travaux. Dans notre cas, nous avons été surpris par un très bon niveau de sensibilisation aux risques d’entreprise des membres du Comex qui connaissent bien leurs enjeux et leurs risques. Il est cependant de notre obligation de choisir les outils et les méthodes appropriés pour garantir une analyse complète et approfondie, afin de garantir la sécurité du système d’information de l’entreprise. Ce travail doit être mené avec rigueur pour un résultat probant. Il est important de noter que l’implication de la direction doit être limitée dans le temps pour ne pas interférer avec le travail des équipes techniques, mais doit être suffisamment présente pour prendre les décisions nécessaires.

Le facteur « Stratégie IT » vise quant à lui à un bon alignement avec la stratégie Métier. On peut donc l’illustrer par rapport à l’existence d’une feuille de route ou d’un schéma Directeur IT et/ou Cyber aligné avec les enjeux métiers de l’entreprise. Pour notre mission, un programme majeur de transformation digitale venait également percuter l’ensemble. Le responsable du programme a également été interviewé à cette occasion.

Pour le facteur « Définir les rôles » le sujet est celui de la Gouvernance. Dans notre cas, notre client était organisé en 3 lignes de défense. La première ligne prise en charge par l’IT, en l’occurrence la DSI, la seconde par la Direction des risques opérationnels à laquelle notre CISO était rattaché et enfin la troisième prise en charge par la direction de l’audit et du contrôle interne. Le sujet a également couvert celui des responsabilités distribuées sur le terrain dans un contexte international avec des directions régions et pays. Certaines plaques, pays étant peu représentés à certains endroits géographiques compte tenu d’une activité faiblement développée, se pose la question de la représentation de la fonction risques et/ou sécurité et de la part de temps consacrée à la sécurité. Certaines activités étant donc attribuées à hauteur de 40 à 60% selon le pays ou la plaque considérée. Dans ces conditions et dans un contexte de rationalisation des coûts et de transformation digitale avec une stratégie de recentrage des activités IT, à partir de quel critère, peut-on considérer que le temps consacré à la SSI est suffisant et que l’organisation actuelle ne fait pas courir un risque à l’entreprise ? Question pas facile…

Le facteur de « Maitrise de l’externalisation » est regardé, à juste titre, de près par le régulateur de l’ACPR. Force est de constater que dans ce domaine, des attaques récentes ont montré que les attaques dites de type « Supply Chain » se sont multipliées ces derniers mois. Comme celles menées sur Airbus via des sous –traitants. Selon le journal Le Monde et l’AFP, pas moins de quatre attaques informatiques majeures ont touché des sous-traitants d’Airbus au cours des 12 derniers mois, explique l’AFP en citant des « sources sécuritaires ». Dans un contexte de recours massif au Cloud, cela prend toute sa dimension. D’ailleurs le règlement EIOPA, adresse ce sujet de la relation et des obligations respectives entre un client et son fournisseur dans un contexte Cloud. Ceci rebondit évidemment sur notre facteur conformité « Respect des lois et règlements ». A ce titre nous avons dû largement lors de la mission compléter le cadre d’exigences contractuelles et règlementaires en définissant :

• Un plan d’Assurance sécurité fournisseurs par cas d’usages associé à une grille d’analyse des réponses fournisseurs incluant les exigences et les preuves requises ainsi que les exigences et preuves relatives aux données à caractère personnel ;

• En définissant un guide des clauses Cybersécurité pour la contractualisation intégrant les exigences EIOPA (Cloud) ;

• En définissant une politique de sécurité achats intégrant un mapping des règles Groupe au regard du NIST et en les complétant/ précisant pour les spécificités du procurement.

b)  Le processus « Faire fonctionner le SI »

Le processus « Faire fonctionner le SI » est au cœur des activités de la DSI.Pour le facteur « Gestion de la continuité d’exploitation », nous avons été confrontés à une différence d’appréciation entre le DSI et le CISO. Pour le DSI, la gestion de la continuité d’exploitation était satisfaisante et ne présentait pas de danger puisque les résultats des tests de bascule et de reprise biannuels étaient systématiquement bons et répondaient à la demande (actuelle) de la Direction Générale. De son côté, le CISO argumentait que ces tests étaient réalisés sur un scénario non cyber et qu’ils devraient l’être. Et là, on reboucle avec la notion de Risk Appetite et de vision de la Direction Générale qui doit décider si la continuité d’exploitation doit être développée/mise à jour pour être en capacité de se préparer et de répondre à un incident de type Cyber tel qu’un ransomware par exemple. De mon point de vue, la réponse est bien évidemment oui. Il est important de bien comprendre que la loi impose certaines obligations en matière de continuité d’activité. Il faut donc garantir que les mesures mises en place sont suffisantes pour couvrir ce type d’incident et pour garantir la reprise de l’activité dans les meilleurs délais. Il est donc essentiel de ne pas se limiter à des tests classiques et d’intégrer des scénarios de crise cyber dans les plans de continuité. La direction doit prendre ses responsabilités et définir clairement les limites de son acceptation du danger.

Pour le facteur « Gestion des changements » et pour ceux ayant pratiqué ITIL, on voit directement ici le parallèle entre les deux puisque ce facteur adresse la gestion des changements, la gestion des problèmes et les niveaux de services. Côté client, la DSI avait retenu ce référentiel ITIL pour organiser ses activités ce qui a simplifié le rapprochement des facteurs de risques secondaires avec la réalité du terrain.

Le facteur Qualité des éléments aurait pu être intégré au processus précédent « Organiser le Système d’Information » tant il revêt aujourd’hui une importance grandissante pour les entreprises s’orientant vers une stratégie Data Centric dont l’origine est forcément un besoin métiers. Dans notre cas, ce sujet était pris en charge par le CDO, l’organisation étant doté d’un Chief Data Officer. Par ailleurs, la qualité des éléments est un sujet à part entière pour laquelle les critères sont un peu différents de la sécurité des données même s’il peut y avoir des recoupements avec des sujets comme l’inventaire et la classification des données/ des actifs. A noter que de plus en plus d’entreprises se dotent d’un CDO et s’orientent sur une stratégie Data Centric.

c)  Le processus « sécuriser le SI »

Le processus « Faire fonctionner le SI » est au cœur des activités de la DSI.

Pour le facteur « Gestion de la continuité d’exploitation », nous avons été confrontés à une différence d’appréciation entre le DSI et le CISO. Pour le DSI, la gestion de la continuité d’exploitation était satisfaisante et ne présentait pas de danger puisque les résultats des tests de bascule et de reprise biannuels étaient systématiquement bons et répondaient à la demande (actuelle) de la Direction Générale. De son côté, le CISO argumentait que ces tests étaient réalisés sur un scénario non cyber et qu’ils devraient l’être. Et là, on reboucle avec la notion de Risk Appetite et de vision de la Direction Générale qui doit décider si la continuité d’exploitation doit être développée/mise à jour pour être en capacité de se préparer et de répondre à un incident de type Cyber tel qu’un ransomware par exemple. De mon point de vue, la réponse est bien évidemment oui. Il est important de bien comprendre que la loi impose certaines obligations en matière de continuité d’activité. Il faut donc garantir que les mesures mises en place sont suffisantes pour couvrir ce type d’incident et pour garantir la reprise de l’activité dans les meilleurs délais. Il est donc essentiel de ne pas se limiter à des tests classiques et d’intégrer des scénarios de crise cyber dans les plans de continuité. La direction doit prendre ses responsabilités et définir clairement les limites de son acceptation du danger.

Pour le facteur « Gestion des changements » et pour ceux ayant pratiqué ITIL, on voit directement ici le parallèle entre les deux puisque ce facteur adresse la gestion des changements, la gestion des problèmes et les niveaux de services. Côté client, la DSI avait retenu ce référentiel ITIL pour organiser ses activités ce qui a simplifié le rapprochement des facteurs de risques secondaires avec la réalité du terrain.

Le facteur Qualité des éléments aurait pu être intégré au processus précédent « Organiser le Système d’Information » tant il revêt aujourd’hui une importance grandissante pour les entreprises s’orientant vers une stratégie Data Centric dont l’origine est forcément un besoin métiers. Dans notre cas, ce sujet était pris en charge par le CDO, l’organisation étant doté d’un Chief Data Officer. Par ailleurs, la qualité des éléments est un sujet à part entière pour laquelle les critères sont un peu différents de la sécurité des données même s’il peut y avoir des recoupements avec des sujets comme l’inventaire et la classification des données/ des actifs. A noter que de plus en plus d’entreprises se dotent d’un CDO et s’orientent sur une stratégie Data Centric.

c)  Le processus « sécuriser le SI »

Source ACPR

On peut remarquer que le processus « Sécuriser le SI » est plutôt organisé selon la logique des 5 piliers du NIST Framework (Identify, Protect, Detect, Respond, Recover).

La « Protection logique des actifs » est un facteur large qui englobe notamment la gestion des identités et des accès, la protection des systèmes et des données, ainsi que les activités opérationnelles de sécurité, telles que la gestion des correctifs de sécurité. Cette dernière, on aurait pu aussi la voir figurer dans le processus précédent « Faire fonctionner le SI », car cette activité doit être adressée par les professionnels de la DSI. La revue de sécurité au sens des audits techniques figure également dans ce facteur.

Plus largement, l’intégration de la sécurité dans les projets, au sens ISP (Intégration de la Sécurité dès la conception) et analyse de risques, ne figure pas dans ce facteur et n’est pas clairement mise en exergue dans un autre processus, ce qui, de mon point de vue, est un manque. Il est essentiel d’assurer que la sécurité soit prise en compte dès la conception de tout nouveau projet.

De plus, une protection efficace doit être assurée contre tout type de sinistre, qu’il s’agisse de pertes de renseignements, d’interruptions de service ou d’attaques cybernétiques.

Pour le facteur « Détection des attaques », nous avons investigué sur la capacité actuelle du SOC externalisé à faire face à une attaque cyber pour lequel le CISO souhaitait une mesure. Sur le « papier », les tableaux de bord et niveaux de services semblaient satisfaisants et respectés. Lorsque nous avons demandé au fournisseur de fournir ses « use cases » et que nous les avons comparés au référentiel du Mitr@ttack le constat a été beaucoup plus mitigé, le degré de couverture étant plutôt assez faible au regard des 12 « Enterprise tactics » du Mitre. Plutôt que de remettre en cause le fournisseur, il s’agit là encore d’une décision d’entreprise de statuer sur un budget versus des risques et dans ce cas précis des menaces Cyber à détecter. Ces constats ont-ils menés à une révision du périmètre de couverture des systèmes et applications monitorées et contrôlées je ne le sais pas mais je l’espère.

2) Etablissement de la cartographie des risques

Conformément à la réglementation, vous devez définir une cartographie des risques inhérents et résiduels métiers, IT et Cyber, et procéder à une évaluation régulière des risques, mais aussi à des mesures de maîtrise et de suivi des risques. L’ACPR demande également à ce que « la cartographie des processus et des risques, idéalement informatisée pour en faciliter la mise à jour, la consolidation et l’exploitation, s’accompagne de la définition de mesures de réduction des risques, qu’elles soient organisationnelles, techniques ou reposent sur des contrôles. Un dispositif de contrôle permanent comportant deux niveaux indépendants de contrôles est destiné à éviter des situations de risque ».

La cartographie des risques a été menée en mode « quick wins », en réunissant les acteurs de l’entreprise au sein d’ateliers afin de se prononcer sur la catégorisation des risques inhérents et résiduels. Celle-ci a fait l’objet de pas mal de débats entre les acteurs de l’entreprise pour savoir si ceux-ci devaient être basés sur la réalité actuelle ou sur la cible après la mise en œuvre des nouveaux contrôles. Il est important d’évaluer les risques de manière professionnelle pour s’assurer qu’ils sont bien identifiés et pris en compte.

Il est crucial de mettre en place les mesures nécessaires pour couvrir ces risques, qu’il s’agisse de mesures techniques, organisationnelles ou de contrôle. L’objectif principal est de couvrir l’ensemble des risques identifiés et d’assurer la sécurité du système d’information de l’entreprise

3) Contrôles et plan de contrôles

La maîtrise du problème informatique est aujourd’hui interdépendante et intégrée avec la démarche de contrôle et de maîtrise des risques opérationnels pilotée par la fonction de gestion des risques opérationnels. Il est important de bien comprendre ce terme.

L’ACPR apporte également une définition de la Cybersécurité comme étant « l’ensemble des contrôles et des mesures d’organisation ainsi que des 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 visant des éléments du système d’information, et affectant potentiellement 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 ces systèmes et réseaux ». Il est crucial d’évaluer et de proposer des solutions pour couvrir ces risques.

L’un des principes que nous avons retenu pour la mission, pour plus de pragmatisme, et compte tenu de la capacité faible de l’entreprise a supporté et maintenir un plan de contrôles trop large, faute de ressources suffisante, a été de partir du postulat suivant : un KPI pouvait remplacer un contrôle ou un contrôle un KPI. En effet, nous avons travaillé en parallèle sur la définition d’un tableau de bord Comex donc orienté par les risques et l’entreprise ne pouvait maintenir un double référentiel indicateur de performances (« KPI/KRI » au titre du tableau de bord) d’une part et contrôle (assimilable à un Key Risk Indicator (KRI)) d’autre part. Au global, 25 contrôles ou indicateurs ont été définis. Dans certains cas, la définition d’un indicateur était plus appropriée pour permettre une mesure pluri annuelle alors que les contrôles ont été systématiquement définis comme annuels. Dans d’autres, et compte tenu de l’importance du sujet, nous avons défini pour une même situation de risques à la fois un indicateur et un contrôle.

Pour le plan de contrôles, il a fallu, d’une part se conformer aux exigences principal de l’ACPR et d’autre part anticiper une intégration dans l’outil Enablon qui comportait également quelques contraintes.

Chaque fiche a défini :

• Le risque ;

• La situation de risque ;

• Le contrôle niveau 1 et 2 selon le principe L2 over L1 (ce qui signifie que le contrôle de niveau 2 consistait à contrôler les résultats et preuves du niveau 1) ;

• Son degré de couverture (Siège, Régions, Pays) ;

• La preuve précise attendue ;

• Avec ou sans échantillon ;

• Qualitative ou quantitative ;

• Les responsabilités de niveau 1 ;

• Les responsabilités de niveau 2.

Le contrôle de premier niveau est assuré par les opérationnels de la 1ère ligne de défense et le contrôle de deuxième niveau est réalisé par des équipes indépendantes de la fonction informatique. La périodicité des contrôles est annuelle.

L’un des défis majeurs a résidé dans la définition des éléments de preuve requis, compte tenu de l’étendue internationale de l’organisation et de la répartition des responsabilités entre le siège, les régions et les pays. En effet, certaines activités, telles que la gestion et l’exploitation des centres de d’informations, sont centralisées au siège, tandis que d’autres sont gérées à l’échelle régionale ou locale. Il a donc fallu déterminer avec précision le périmètre du contrôle, en choisissant le niveau d’intervention le plus pertinent : siège, région ou pays.

Face à cette complexité, nous avons apporté notre expertise en formulant des recommandations visant à optimiser la prévention et à garantir la sécurité des informations sensibles de l’entreprise.