Assureurs et maîtrise des risques

Retour d’Expérience

– (Cyber)sécurité –

| Introduction sur le contexte de la mission

L’accroissement des cyberattaques accroit 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.

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.

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.

La suite du document s’attache à décrire ceci et nous illustrons notre propos pour certains facteurs de risques, 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 l’information de l’institution. »

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

• Organiser le Système d’Information (S.I) ;
• Faire fonctionner le S.I ;
• 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.

| 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. 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.

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 risque 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 Cyber tel qu’un ransomware par exemple. De mon point de vue, la réponse est bien évidemment oui.

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 données 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 données 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 »

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 embarque notamment la gestion des identités et des accès, la protection des systèmes et données en DIC ainsi que des activités opérationnelles de sécurité telles que la gestion des correctifs de sécurité. La gestion des correctifs que l’on aurait aussi pu voir figurer dans le processus précédent « Faire fonctionner le SI » en ce sens que cette activité doit être adressée par les acteurs 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 et analyse de risques ne figure pas dans ce facteur ni n’est clairement mise en exergue dans un autre processus ce qui de mon point de vue est un manque.

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é 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érente et résiduelle. 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 mise en œuvre des nouveaux contrôles.

3) Contrôles et plan de contrôles

La maîtrise du risque 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.

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 ».

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 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 gros challenges a été de définir la preuve adéquate attendue au regard du degré de couverture à l’international et des responsabilités du siège versus d’une région ou d’un pays. En effet, certaines activités sont centralisées depuis le siège, comme pour la gestion et l’exploitation des Datacenters alors que d’autres sont régionales ou locales. De plus, il a fallu choisir la portée du périmètre du contrôle au niveau siège, région ou pays.

En conclusion, la mission a été complète et riche puisqu’elle a permis d’adresser l’ensemble des enjeux risque et conformité, IT et Cyber de l’entreprise.