L’analyse de risques est un outil indispensable à une bonne hygiène informatique ; et ce, quel que soit le secteur d’activités, le type d’établissement (public ou privé) ou sa taille.
Une bonne vision des risques pesant sur un système d’information est une priorité pour protéger savoirs faire et actifs numériques.
Certaines fois, la réglementation vous oblige à effectuer ces analyses de risques. Citons par exemple :
- Le Règlement général sur la protection des données (RGPD) dans le cadre d’analyse d’impact ;
- Le Référentiel Général de Sécurité pour l’homologation des systèmes d’information ou des applicatifs gérés par des établissement publics ;
- Le Règlement européen Eidas ayant pour but d’augmenter la confiance dans les transactions électroniques au sein de l’UE, etc.
De la même façon, certaines certifications (1) nécessitent une analyse de risques pour pouvoir obtenir les agréments demandés.
Analyse de risques : notions générales
Une analyse de risques permet d’identifier les menaces qui pèsent sur les systèmes d’information, comme les risques liés à :
- La cybercriminalité (ransomware, phishing, etc.) ;
- La concurrence déloyale ;
- La corruption interne ;
- Des évènements naturels (inondation, incendie – cas du Datacenter d’OVH).
Un risque peut se calculer en termes de gravité et de vraisemblance.
- La gravité représente l’ampleur d’un risque c’est-à-dire ses impacts potentiels sur le système d’information.
- La vraisemblance d’un risque traduit sa possibilité de survenance.
Cette vraisemblance dépend essentiellement des :
- Vulnérabilités pesant sur le système d’information face aux menaces ;
- Capacités des sources de risques à les exploiter.
Les niveaux de gravité et de vraisemblance s’évaluent. La Cnil a donné pour cela l’échelle de valeur suivante accompagnée d’exemples concrets :
Le risques 4 concerne notamment l’atteinte à des données de santé, et encore une fois l’actualité nous le rappelle tristement avec toutes les cyberattaques qui ont lieu sur les SI d’hôpitaux et de laboratoires de santé qui ont causé le décès d’une personne en Allemagne (2).
Concernant la vraisemblance, l’échelle de valeur est la suivante :
Une vraisemblance 4 peut concerner par exemple une attaque informatique ayant utilisé la vulnérabilité d’une application non corrigée. Sans correctif apporté, les attaquants utiliseront de nouveau la faille.
Une autre vraisemblance 4 : un traitement de vidéosurveillance dans lequel les postes de supervision seraient accessibles ou visibles par tous les membres du personnel, voire aux visiteurs des locaux. Toutes les vidéos (données personnelles) seraient ainsi diffusées à d’autres personnes que le personnel en charge de la surveillance.
Identifier la source de risques
La Cnil évoque le fait d’identifier des « sources de risques ».
Lors d’une analyse de risques, il faut donc rechercher le fait générateur d’une atteinte au SI ou à l’application concernée.
Cela dépend beaucoup de l’environnement dans lequel évolue le responsable de traitement ; mais des grandes tendances sont communes à tous les secteurs.
Les sources de risques peuvent ainsi être humaines et internes à l’entreprise : salariés en poste, administrateurs informatiques, stagiaires, dirigeants, tiers autorisés, etc.
Elles peuvent aussi être non humaines : codes malveillants, eau, épidémie, feu, animaux, etc.
Elles peuvent également être externes à l’entreprise : pirates informatiques, concurrents, journalistes, visiteurs, sous -traitants, clients, etc.
Cette analyse de menaces doit s’accompagner de mesures de traitement du risque. Le but : l’éliminer ou pour le moins, en limiter les effets.
Méthodologie pour réaliser une analyse de risques
Il existe de nombreuses méthodes pour effectuer une analyse de risques, la méthode Ebios étant celle qui est recommandée par l’Anssi.
L’important au final est que la personne qui effectue l’analyse de risques puisse travailler de manière neutre et sans subir la pression de son propre environnement professionnel.
C’est la raison pour laquelle, il semble préférable de confier les analyses de risques à des cabinets ou à des sociétés d’audit externes au service responsable du traitement concerné.
Les étapes pour mener une analyse de risques sont les suivantes :
Étape 1 : effectuer les interviews des personnes concernées
Les personnes concernées peuvent être les dirigeants, le délégué à la protection des données, les équipes métiers, les équipes informatiques, les équipes d’info gérance, etc.
Le ton employé aura alors ici une importance primordiale. Il est ainsi nécessaire d’installer un climat de confiance avec la personne interviewée. L’entretien ne devra pas prendre une forme accusatoire si vous souhaitez obtenir des informations correctes.
Il s‘agira de bien comprendre les usages au sein de l’entreprise.
Ainsi, un bon analyste sera alerté par des équipes métiers qui voient leur propre équipe informatique comme une ressource inutile et qui préfèrent développer eux même leurs propres outils et ce, sans validation d’une équipe technique (c’est ce qu’on appelle le Shadow IT).
Étape 2 : rassembler la documentation
Il s’agit ici d’étudier toute la documentation de sécurité utilisée par le responsable de traitement ou son sous-traitant :
- PSSI, Plan assurance sécurité ;
- Charte informatique ;
- Politique de mot de passe, politique de sauvegarde et d’archivage des données ;
- Résultat des tests de sécurité effectués en interne ou en externe (test d’instruction, pentest, audit de code) ;
- PCA et PRA ;
- Politique de gestion des logs ;
- Accord de confidentialité ;
- Politique de sureté des locaux, etc.
Un document qu’il ne faut pas négliger est la cartographie précise des applications hébergées sur le SI, des flux de données qui naviguent entre elles et des DATACENTER utilisés par le responsable de traitement.
Ce document est important car il permet de détecter les zones vulnérables d’un SI et notamment celles ouvertes sur internet.
Si ce document n’existe pas, l’analyste pourra proposer au RT de l’aider à le construire à partir de nombreux outils de cartographie qui existent sur le net.
Étape 3 : dresser un état des mesures mises en œuvre par le responsable de traitement ou son sous-traitant
Il s’agira par exemple de décrire les mesures de sécurité appliquées comme la politique de mot de passe, la durée de conservation des logs, la durée de conservation des sauvegardes, le type de sauvegarde effectuée, les mesures de chiffrement, la protection des locaux, la sécurité des postes de travail et également les mesures organisationnelles telles que relation avec les tiers, gestion du personnel, etc.
Étape 4 : évaluer les risques
Vous pouvez partir pour cela des recommandations que vous avez effectuées, des tableaux d’échelle proposés par la Cnil ainsi que des différentes sources de risques que vous avez identifiées.
Par exemple, vous avez détecté qu’une seule et unique personne disposait d’un mot de passe pour accéder à une boite mail créée pour recueillir les alertes professionnelles des salariés. Il y a un risque important en cas d’indisponibilité de cette personne que les données soient rendues inaccessibles. La source de risques sera ici interne et le risques concernera la disponibilité des données.
Autre exemple, vous avez détecté que les collaborateurs étaient administrateurs de leur poste de travail. Il y a un risque qu’un logiciel malveillant soit installé par un collaborateur. Ce logiciel malveillant pourra avoir pour effet de chiffrer les données, soit du poste de travail, soit d’une partie du SI de l’entreprise. Il s’agit donc d’un risque sur l’intégrité des données.
De la même manière, vous avez détecté que les locaux du RT étaient situés dans une zone inondable et qu’aucune mesure de protection n’est prise pour protéger les baies des serveurs de ce risque naturel. À noter que si la dernière inondation de la région date de 1904, la vraisemblance du risque restera limitée.
L’ensemble de ces éléments devront être intégrés à un tableau récapitulatif et le mieux est de cartographier les différents risques sur un schéma facilement lisible pour toutes les personnes qui souhaiteraient accéder à ces informations : dirigeants, Cnil, Anssi, autorité d’homologation RGS, DPO.
Étape 5 : effectuer des recommandations pour améliorer le niveau de sécurité
Ces recommandations doivent être adaptées à l’environnement du responsable de traitement, par exemple il est inutile de recommander d’utiliser un antivirus comportemental (EDR) de dernière génération si le SI n’est composé que de quelques serveurs connectés entre eux.
Il est souvent recommandé de formaliser les usages des entreprises dans des documents écrits quand ils ne le sont pas. Par exemple, si une politique de mot de passe est appliquée sans être formalisée dans la PSSI ou dans un document propre.
L’ensemble des recommandations effectuées devront être formalisées dans un plan d’action et contribueront à faire baisser les risques quand elles seront appliquées.
Étape 6 : réévaluer les risques après applications des recommandations
Vous devez montrer comment les mesures que vous avez formalisé atténuent les risques.
Par exemple, vous avez recommandé l’interdiction pour les utilisateurs d’utiliser les ports USB, cela attenue automatiquement le risques de vraisemblance d’une attaque informatique.
De la même manière, vous avez recommandé de mettre en place une redondance des serveurs stockés dans une zone inondable vers un autre datacenter distant, vous avez atténué les risques d’atteinte à la disponibilité des données en cas d’inondation.
De manière générale, si une analyse de risques vient à identifier une gravité ou une vraisemblance d’un risque d’un niveau 3 ou 4 et ce malgré l’application des mesures de traitement, il est indispensable au responsable de traitement ou à son sous-traitant de corriger en priorité ce risque avant de mettre ou de remettre en production le traitement ou le SI concerné.
Dans le cas contraire, sa responsabilité civile ou même pénale pourrait être engagée.
Anthony Sitbon
Directeur du département Sécurité
Lexing Technologies
(1) ISO 27K, prestataire de confiance auprès de l’Anssi, etc.
(2) « Un mort après une cyberattaque contre un hôpital en Allemagne », Coralie Lemke, Science et Avenir, le 21.09.2020