Analyse des risques de sécurité informatique – La Préparation

L’analyse des risques était, est et sera un des piliers de la gestion de la sécurité informatique. Les différentes réglementations qui sont en vigueur ou en cours d’élaboration mettent en avant la nécessité de conduire une analyse des risques. Comment faire ? Quelle méthode choisir ? Quels objectifs attendre ? Ce sont tous ces sujets que j’aborde dans cette série d’articles.

Préambule

Afin de vous aider un peu plus, je vais partager avec vous la méthode que j’utilise. À certains moments, je devrai faire des raccourcis, des simplifications. Mon objectif est de vous donner ce que j’aurais aimé recevoir lorsque j’ai débuté dans cette activité.

Je vous l’indique d’ores et déjà, n’hésitez pas à poser des questions, compléter mes propos ou apporter un éclairage différent, le tout directement dans les commentaires !

Il est souvent question de cybersécurité (cybersecurity pour les anglo-saxons) au lieu de « sécurité informatique ». À titre personnel, je limite l’usage des mots qui commencent par “cyber”. Selon moi, le terme “cyber” a trop tendance à limiter le champ de pensée au méchant hacker qui vous veut du mal. Les mots « Sécurité informatique » sont plus englobants et incluent plus naturellement l’ensemble des risques pesant sur votre périmètre.

Je vous présente dans cet article une méthode d’analyse des risques de sécurité informatique. L’article se veut complet dans la démarche sans développer toutes les notions abordées. Par la suite, d’autres articles pourront compléter celui-ci et ainsi boucler la démarche.

Quel sont les objectifs de ce « risk assessment » ?

Connais-toi toi-même

Socrate

C’est déjà un bel objectif ! Connaître ses risques. Objectif déjà intéressant que de disposer d’une méthode d’identification exhaustive de ses risques. Le risque des analyses de risques (!), c’est d’en avoir oubliés… D’où toute l’importance d’identifier un moyen fiable d’en faire le tour.

Ensuite, il s’agira de déterminer les moyens qui permettent de traiter ces risques. En plus, s’il était possible de mutualiser les moyens pour réduire plusieurs risques à la fois, ce serait tout de même mieux.

Hormis la mutualisation des efforts, l’analyse des risques doit permettre d’influencer la conception et l’architecture du projet.

En résumé, les objectifs sont les suivants :

• Un moyen d’analyser les risques de manière homogène et reproductible, quel que soit celui qui réalise cette analyse
• Identifier comment diminuer les coûts des contrôles à mettre en place
• Influencer l’architecture fonctionnelle et technique pour réduire les risques / mieux les maîtriser

Personnellement, en plus d’indiquer les objectifs à atteindre, je vous propose également une liste de ce dont il ne s’agit pas :

• Simplement documenter les risques pris et dédouaner l’analyste
• Rendre la méthode inapplicable par des non spécialistes
• Être fait en bout de chaîne des changements, quand rien ne peut plus être changé

Étape 0 : Quelle méthode d’analyse des risques de sécurité informatique adopter ?

Pour les analyses des risques de sécurité informatique, plusieurs méthodes existent, certains en ont fait leur sujet de Master. Pour ma part, j’ai pu expérimenter essentiellement deux méthodes et demi. EBIOS (juste avant la nouvelle version EBIOS Risk Manager) et une combinaison du Microsoft Threat Modelling et d’OCTAVE Allegro. Pourquoi deux et demi ? Pour le demi, c’est le Microsoft Threat Modelling qui n’a été utilisée que partiellement.

Dans ma situation, il me semblerait déplacé de vous faire une recommandation de méthode à ce stade. Ce que je compte faire en revanche, c’est développer celle que j’ai pu utiliser et vous laisser évaluer si celle-ci pourrait vous convenir.

Toutefois, je peux indiquer (et tenter de vous convaincre tout de même) que cette méthode est construite autour de la notion de valeur des données. A l’aune du « data is the new gold« , je la trouve particulièrement appropriée.

Il ne vous reste plus qu’à suivre le guide pour découvrir cette méthode d’analyse des risques de sécurité informatique.

Quelques points communs entre les différentes méthodes d’analyse des risques de sécurité informatique

Premier point commun : La grille d’évaluation

Quelle que soit la méthode, votre objectif restera le même : évaluer les risques. Pour cela, il vous faudra une grille d’évaluation. Ce point, au moins, est commun à toutes les méthodes !

Cette grille d’évaluation des risques se compose des éléments suivants :

• Un type d’impact (Financier, Concurrentiel, Social, Opérationnel / Perte d’activité, Sécurité des personnes, Juridique, Image/Réputation ou encore Environnemental)
• Une échelle d’évaluation pour chaque type d’impact
• Une échelle de probabilité de réalisation

Et c’est à ce moment qu’apparaît le moment le plus important pour la vie des gestionnaires de risques :

Alors, ta grille d’analyse est en 3×3, 4×4 ou 5×5 ?

Non, moi je suis un original, elle est en 4×5 !

Deuxième point commun : Sans l’échelle, la grille n’est rien

Comme l’œuf et la poule, est-ce la grille qui fait l’échelle d’évaluation, ou l’inverse ? Je ne saurais vous dire.

In fine, les deux éléments les plus importants sont :

1. Déterminer l’échelle d’évaluation pour chaque type d’impact
2. Déterminer la stratégie de traitement d’un risque

La première fois que vous faites l’exercice, cela vous donnera un sentiment étrange de comparer un nombre de blessés potentiel avec un risque de perte financière.

Il s’agira de déterminer les seuils qui vont permettre de noter un risque de 1 à 5 (si votre grille d’impact à 5 choix). Finalement, plus vous aurez de choix, plus vous devrez être précis dans votre évaluation.

Last but not least : La stratégie de traitement des risques

Pour chaque « case » de votre grille, vous devrez déterminer ce que vous ferez des risques se trouvant là.

C’est ce qu’on nomme la stratégie de traitement. Et c’est à ce moment que se détermine la fameuse « appétence au risque ». En langage commun, cela signifie que l’organe décisionnaire doit définir des critères de traitement.

A chacune des situations, les décideurs doivent déterminer si un risque peut :

• être accepté (on ne peut/veut rien faire de plus)
• doit être réduit (c’est inacceptable, il faut prendre des mesures)
• peut ou doit être transféré (alors, monsieur l’assureur ?)
• peut ou doit être évité (et si on revendait cette activité risqué au concurrent ?)

Avec ces éléments en main, l’analyse des risques peut alors débuter. Sans ces éléments, tout le reste du travail serait inutile.

Étape 1 : Les ingrédients d’une bonne analyse des risques de sécurité informatique

À l’étape précédente, nous avons vu qu’un système d’évaluation et de traitement des risques sont des prérequis. Pour faire l’analogie avec une bonne recette de cuisine, je viens de décrire la cuisine elle-même avec quelques équipements minimaux (four, réfrigérateur, plaque de cuisson, évier, couteaux, etc.). D’habitude, dans une recette, on ne vous les décrit pas !

Ici, on va voir les véritables ingrédients pour conduire une bonne analyse des risques.

Ingrédient n°1 : Les données

La méthode que je vous propose de suivre s’appuie sur les véritables biens à protéger : les données. Une application, un réseau, un système d’information ne sont là que pour manipuler des données.

D’ailleurs, un règlement européen a été voté afin de régir le traitement apporté à une nature de données particulière : les données personnelles. Si vous ne l’avez pas reconnu, j’évoque le si célèbre Règlement Général sur la Protection des Données.

Comme prescrit dans la norme ISO 27001, vous devez avoir établi votre inventaire des données (Data Assets Invetory). Cette étape est clé. C’est un enjeu crucial de la suite de l’analyse des risques.

Comment identifier les données ?

Le terme « données » est tellement générique et tellement utilisé qu’il génère beaucoup de confusion dans les esprits. Il ne s’agit pas ici de récupérer toutes les fichiers Excel, documents et bases de données afin de classer les attributs. Il faut penser à travers les processus métier.

Pensez à votre organisation en termes de fournisseur et consommateur de données. Qui est responsable si telle ou telle information est fausse / indisponible ou diffusée aux mauvaises personnes ? (si vous répondez l’IT, c’est une mauvaise réponse !).

Selon la maturité de votre entreprise, vous disposerez d’une modélisation de vos processus métier ou non. À travers l’analyse de vos processus, vous pourrez identifier l’inventaire des données ainsi que leur propriétaire (=accountable).

Voici quelques exemples de données que toutes les entreprises ont :

• Données RH (>>A ne pas confondre avec données personnelles !)
  • Salaires
  • Organigramme
• Données financières
  • Factures
  • Commandes
• Données juridiques
  • Contrats
  • Litiges

Ainsi, vous savez que c’est le ou la DRH qui émet les besoins en sécurité des données RH (en termes de confidentialité, d’intégrité et de disponibilité).

Le sujet des données personnelles est un sujet transversal en terme de conformité. Dans les factures, les contrats et évidemment dans les fiches de salaire il y a des données personnelles. Le Data Protection Officer (DPO) ou délégué à la protection des données doit s’assurer que chaque propriétaire intègre les exigences applicables pour ce sous-ensemble.

Que faire de cet inventaire ?

Pendant que vous construisez cet inventaire, il faut collecter les besoins en sécurité de ces données. C’est le fameux CIA – Confidentiality, Integrity, Availability – ou DIC – Disponibilité, Intégrité, Confidentialité.

Ce sont les propriétaires de ces données qui émettent leurs exigences. C’est également un excellent moment pour collecter les besoins relatifs à la continuité. Cela permet de discuter du RPO – Recovery Point Objective (en français : Perte de Données Maximale Autorisée – PDMA) et du RTO – Recovery Time Objective (en français : Durée Maximale d’Interruption Admissible – DMIA).

Par la suite, l’inventaire des données et leurs besoins en sécurité sera votre point référence pour toutes les analyses de risques.

Ingrédient n°2 : Les systèmes et les flux

A ce stade de l’analyse des risques, il s’agit d’identifier les systèmes qui sont impliqués « par îlot ». Et surtout, les données qui sont stockées par système et celles qui transitent entre systèmes.

C’est la nature des données qui transitent qui vont ensuite permettre de déterminer les besoins de sécurité de chacun des systèmes. L’objectif est de choisir le meilleur compromis entre les efforts à déployer et les réels besoins de sécurité.

Tous les systèmes n’ont pas besoin d’un niveau de sécurisation de niveau militaire !

Prenons un exemple où un système stocke toutes les données des arrivées et des départs des trains. Ce sont déjà des données en accès libre !

• Open data de la NRN (Canada)
• Open data de la SNCB (Belgique)
• Open data de la SNCF (France)
• Open data des CFF (Suisse)

Est-ce que l’une de ces données a besoin d’être protégée au niveau de la confidentialité ? Ou encore de la disponibilité ? Ok pour l’intégrité… mais on pourrait se défendre avec des clauses contractuelles d’utilisation du service.

Ainsi, une analyse des risques doit permettre d’identifier les risques majeurs, et selon l’appétence au risque, les rendre acceptables/acceptés.

Ingrédient n°3 : Les liens avec le hors périmètre

Dans la modélisation des systèmes et des flux, à un moment donné, des interactions auront lieu avec d’autres composants/acteurs.

Par exemple, vous aurez des données qui seront produites (prestations facturables) ou consommées (état des stocks). Vous pourrez ainsi déterminer les risques/les besoins de sécurité de ces interfaces.

Autre exemple, le besoin de maintenance à distance va faire apparaître d’autres risques. De là, vous pourrez déterminer les exigences à placer dans les contrats du mainteneur.

Et après ?

Je vous propose de continuer cette analyse des risques de sécurité informatique dans un prochain article. Je mettrai celui-ci à jour avec le lien vers la suite.

En attendant, n’hésitez pas à commenter cet article ou à poser des questions.