3 étapes pour réaliser une analyse de risque flash pertinente + template
Chaque projet numérique doit être accompagné d'un point de vue cybersécurité. Première étape la fameuse analyse de risques. Je vous propose dans cet article mon retour sur l'usage d'une version flash.
L’analyse de risques cybersécurité est un grand classique lorsque l’on parle cybersécurité. Cette analyse peut être faite au niveau d’une organisation. Dans ce cadre, elle va permettre, en particulier, de prioriser le déploiement des mesures de sécurité et optimiser les dépenses.
L’analyse de risque cyber est parfois vue comme trop longue à obtenir et beaucoup trop complexe par les équipes des DSI.
Je partage ce constat, nos fichiers Excel, construis sur des référentiels type EBIOS-RM sont lourds, complexes à mettre en œuvre.
Je vous propose ici de vous partager la façon dont je réalise des analyses de risques flash. Celles-ci ont vocation à pouvoir être réalisées rapidement et en ressortir un premier résultat rapidement.
Je souhaite détailler ce sujet suite à un de mes post LinkedIn. En effet, j’offrais mon template me permettant de réaliser ces analyses aux personnes commentant ma publication. La publication a reçu plus de 1 030 commentaires, cet article me permet désormais d’approfondir le sujet.
Pour ceux étant passé à côté du template 👇
Disclaimer
Ces analyses de risque flash ne seraient remplacer les classiques analyses de risques complexes type EBIOS, qui peuvent être justifiés sur d’énormes projets, ou justifiés par des contraintes réglementaires ou contractuelles.
Pourquoi une analyse de risques
Il est toujours bon de rappeler l’intérêt d’une analyse de risques. Bien que s’agissant d’une démarche qui me parait indispensable voir obligatoire, il faut que les résultats de l’analyse soient utiles aux bénéficiaires. C’est à dire le chef de projet numérique et le responsable métier.
Que vise l’analyse de risques cybersécurité dans le cadre d’un projet ?
Selon moi, il vise à identifier les nouveaux risques apporter par l’évolution du système d’information. Que ce soit à travers l’ajout de composants numériques ou au remplacement de solutions.
Une analyse de risques, dans quel but ?
Les résultats de cette analyse doivent permettre de mettre en œuvre les mesures de sécurité indispensables. Cette analyse de risques permet de justifier les moyens financiers mis dans un projet.
La prise de contexte
L’analyse de risques doit permettre l’identification des risques cybersécurité apportés.
Dans ce contexte, il parait indispensable de comprendre le spectre du projet afin de proposer des mesures :
La raison du projet
Pourquoi de l’argent est investi pour le mener à bien ?
Quels sont les résultats attendus ?
Il y a donc, une prise de contexte métiers et une prise de contexte technique à réaliser pour garantir l’intérêt de l’analyse de risque.
La prise de contexte métier
Elle vise à échanger avec le bénéficiaire du projet, à savoir le client interne. C’est une étape importante et critique. Elle permet en particulier de s’aligner avec les besoins métiers et de faire en sorte que les mesures de sécurité ne viennent pas bloquer des usages numériques nouveaux ou non soupçonnés.
En tout cas, c’est ma façon de voir les choses, la cybersécurité en soutient du numérique, en soutient des métiers. Cette étape permet également de sensibiliser aux questions de la cybersécurité et potentiellement justifier des coûts associés.
La prise de contexte technique
Elle est souvent plus simple car elle concerne des personnes parlant le même langage : l’IT. Le challenge dans cette partie est d’obtenir le fameux schéma de l’implémentation de la solution.
Au début j’utilisais la technique, pas de bras pas de chocolat. Soit dans notre cas, pas d’archi ➡️ pas d’analyse ➡️ pas de mise en production. Mais avec les années, j’ai appris à mettre de l’eau dans mon vin, et propose désormais de l’aide à la réalisation des schémas d’architectures.
Dans tous les cas, je fais une synthèse des prises de contexte, j’évite les classiques 42 champs à renseigner, souvent utiles, mais trop lourds dans le mode voulu.
Les risques et leurs priorisation
L’étape suivante est de lister les risques en matière de cybersécurité apporter par le projet. C’est ma partie préférée, celle où en tant qu’expert, je me mets à imaginer les pires scenarii. Cela fait du bien de temps en temps de refaire fonctionner son côté machiavélique et imaginer les pires finalités.
Pour accélérer le processus, au lieu de rentrer dans une méthodologie classiques avec menaces, bien supports etc, je reprends l’analyse de risques de l’organisation dans sa globalité et la décline à l’échelle du projet. C’est important de traiter chacun des risques, même si l’impact et la probabilité sont faibles. Au moins cela aura été traité. J’ajoute les risques spécifiques connues des projets équivalents dans d’autres organisations.
Enfin, c’est à l’étape de priorisation des risques. Pour chacun des risques, nous avons une note sur 4 pour l’impact et la probabilité. Voici ma technique :
Je créé une colonne rating (impact x probabilité).
Je classe ensuite en décroissant les risques.
Le calcul du rating peut être adapté en fonction de règles internes ou de volontés du client. L’idée est de toujours pouvoir justifier le classement des risques.
Les mesures de sécurité
Dernière étape : le travail de proposition de mesures de sécurité. Cette partie en particulier nécessite la présence indispensable d’un expert cybersécurité. Les mesures de sécurité à proposer sont de deux types, techniques et organisationnelles.
En fonction des organisations, les mesures de sécurité peuvent être compensées soit par l’organisationnel soit par la technique. Si vous prenez un ingénieur, il va vous proposer essentiellement des mesures techniques.
Il est important de contextualiser les mesures de sécurité en fonction de l’organisation. Trop souvent, je vois des mesures de sécurité basiques et non adaptées. Il est important de pouvoir proposer des mesures qui ont la capacité d’être réellement mise en œuvre et adapter au tech landscape déjà en place dans l’organisation.
Pour ma part, j’essaye de reprendre le modèle “user story” pour rédiger la mesure de sécurité, modèle utilisé dans le monde du développement pour formaliser la demande aux équipes développement.
Un point auquel il faut faire tout particulièrement attention dans cette partie : ne surtout pas ce censurer. J’ai vu de nombreux clients demander à effacer certaines mesures car ils n’ont pas les solutions conseillées. Je pense en particulier au fait de relier au SOC.
Pour moi les mesures de sécurité proposées sont un peu comme une ordonnance venant d’un médecin. Si le patient refuse d’appliquer une partie ou toutes les mesures, c’est un autre sujet. C’est à ce moment là qu’intervient le concept de dérogation ou de risk exception que je vous propose de partager dans un prochain article.
Vous avez un projet Cybersécurité ?
Prenez rendez-vous grâce au lien et échangeons sur vos sujets à venir