EN
Cyberbasics — Épisode 3 : Retours d'expérience choisis sur l'analyse de risque
Cet article est le troisième épisode de la série cyberbasics, dédiée aux fondamentaux de la sécurité logicielle. Il fait suite à l'article Analyse de risque et vise à le compléter par des retours d'expérience terrain.
Exemples concrets de décisions stratégiques nées de l'analyse de risque
Il me tient à coeur d'être concret et pragmatique lorsque j'essaie de faire de la sensibilisation à la cybersécurité, aussi, dans cet épisode, je vous propose quelques retours d'expérience qui ont contribué à me faire comprendre la valeur de l'analyse de risque. À noter que je resterai volontairement flou sur le contexte.
Si vous n'êtes pas familier avec l'analyse de risque dans le contexte informatique, je vous conseille la lecture de l'article Analyse de risque en préambule.
Le produit qui voulait, inutilement, être hautement disponible
Dans le contexte d'une startup qui développe un produit disons "de monitoring d'activité" pour des grands groupes industriels, l'analyse de risque nous a amenés à identifier l'événement redouté suivant :
les données de monitoring récoltées par la solution fuitent et permettent à un concurrent d'extrapoler l'activité exacte d'une usine.
Celles et ceux qui connaissent un peu le milieu industriel savent que ce genre d'espionnage est pris très au sérieux, en particulier en France.
On essaie alors d'évaluer le risque de fuite lié au logiciel qui permet la collecte d'information d'activité d'une usine et, quand on creuse, on tombe rapidement sur plein de cas inquiétants :
- base de données en clair
- logs non chiffrés
- communications TLS pas toujours très strictes
Un grand classique, je suis certain que beaucoup se reconnaîtront dans cet exemple.
La conséquence de cette évaluation : un niveau de risque non acceptable pour les clients de la solution de monitoring. Le bilan est simple : on doit absolument implémenter du chiffrement des données, en transit (communication HTTPS) et au repos (base de données, fichiers de logs et de configuration). À noter que sur le chiffrement mémoire on a passé notre tour, car le rapport bénéfice/risque n'était pas favorable, ce qui est souvent le cas et qui est un sujet qui mériterait un article ou une conférence à lui tout seul.
Se pose alors la difficile question de combiner "protection des données", avec beaucoup de chiffrement de la gestion de clé complexe avec une contrainte de haute disponibilité. Cette contrainte de haute dispo n'est pas clairement justifiée et, on le comprendra plus tard, venait de "template d'architecture" (ou bonnes pratiques populaires pour ceux qui préfèrent).
Se pose alors un problème d'architecture : comment gérer des clés de chiffrement et un mécanisme de haute disponibilité sécurisé ? Celles et ceux qui auront essayé de résoudre ce problème sauront vous dire que la solution est toujours chère, en ingénierie et en infrastructure. Mais ! Il s'avère que dans ce cas précis les données de monitoring ne sont collectées, en moyenne, qu'une fois par semaine. Cette fréquence vient de standards industriels et peut être prise comme hypothèse forte. La conséquence directe sur notre architecture est simple : tout mécanisme de haute disponibilité est superflu, il va créer de la complexité accidentelle (et quelle complexité !) et rendra plus difficile la protection des données.
En conclusion, nous avons opté pour une architecture simple et monolitique, avec une paire de clé de chiffrement unique et donc plus simple à gérer, ainsi que des indications de développement claires :
"à la moindre erreur ou suspicion de problème de sécurité : on arrête le logiciel en mode "fail safe", on chiffre tout, et on lève une alerte".
En plus d'être simple à implémenter, cette solution est plus facile à expliquer, auditer et c'est une force pour convaincre les clients méfiants.
Dans ce cas précis, l'analyse de risque nous a permis de lever un biais de conception (i.e. le faux besoin de haute disponibilité) et d'implémenter une solution simple, réalisable avec des moyens cohérents pour une équipe modeste.
Sécuriser des bons au porteur ou des valeurs bancaires
J'ai eu la chance de bosser sur un projet pour une ETI qui gère des bons au porteur (comprendre des codes qui permettent d'avoir des bons d'achat sur des sites marchands). L'idée du bon au porteur c'est que si une personne possède le code, elle peut dépenser l'argent ! Là où le problème devient intéressant, c'est que pour faire de la marge commerciale, ces codes sont négociés pour des gros volumes et achetés par milliers pour des montants qui peuvent atteindre des sommes à 6 ou 7 chiffres.
On a donc des transactions, pour lesquelles on doit injecter dans notre système, des milliers de bons d'achat, pour une valeur totale conséquente. Sans rentrer dans le détail, je vous laisse imaginer comment sécuriser la transaction et vous comprendrez rapidement qu'on est parti sur quelque chose de très complexe, étant donné le risque financier associé à une fuite de la totalité des bons.
La problématique majeure c'est que lors de la transaction entre le marchand et notre système, si un attaquant réussit à avoir accès au lot de bons, il a gagné ! Une simple lecture ou copie des informations suffit à gagner l'argent que ça représente. Et ce problème nous a donné des maux de tête, car ce genre de scénario est très difficile à mitiger de manière efficace.
Mais c'est alors, que lors d'une session d'analyse de risque avec une des fondatrices de l'ETI, nous avons appris que cette transaction était sécurisée en amont par le marchand. Typiquement, si un incident ou un doute sur la confidentialité du lot de bons apparaissait, il suffisait de passer un coup de téléphone au marchand pour qu'il annule tout le lot de bons d'achat avec, en bonus, la possibilité de le regénérer très facilement.
Ce que ça signifiait pour nous, c'est que notre problème se réduisait à de la détection d'anomalie (i.e. détecter qu'un attaquant a pu lire les informations) plutôt qu'à de la protection, sur le long terme, d'information sensible. Cette option du coup de téléphone, dont nous n'avions pas connaissance au démarrage du projet (on sait tous que les spécifications d'un produit sont par nature incomplètes) venait de nous simplifier grandement l'architecture du logiciel à construire !
La fondatrice de medtech qui renonçait à la souveraineté logicielle
Il est courant que de nombreuses structures, de toute taille, imposent des contraintes de souveraineté strictes dans leur cahier des charges, puis les abandonnent lorsqu'elles comprennent le coût associé.
Dans ce dernier exemple, je pense à une fondatrice d'une entreprise de type medtech (medical tech), qui voulait développer une application de suivi de santé personnalisé. Les données de santé étant très sensibles, il n'était pas question d'utiliser des solutions logicielles non souveraines pour son projet.
Nous avons alors étudié les solutions pour lui fournir une infrastructure Cloud souveraine. Problème : les estimations budgétaires de notre étude dépassaient, de loin, le budget de la startupeuse. Nous avons alors réalisé une analyse de risque rapide et honnête ayant pour objectif de mesurer ce que coûterait une infrastructure capable de se protéger de l'espionnage américain.
On en arrive rapidement à dresser la liste des services dont il faudrait se passer : Google Workspace, PC sous Microsoft, infrastructure hyperscaleur, Mac de la fondatrice, ... Le coût d'une telle infrastructure informatique est clairement prohibitif pour cette startup et mettrait en péril sa survie. Le risque économique à respecter la contrainte de souveraineté est trop important, la contrainte est trop coûteuse à respecter. On part finalement sur un hyperscaleur, c'est le seul moyen de respecter le budget de la cliente.
Note pour les puristes : non, nous n'avons violé aucune règle européenne sur ce projet :) Il ne s'agissait pas de données médicales et nous avons respecté un environnement conforme à la certification HDS.
Ce qu'on retient
Ces trois exemples partagent une même structure : la solution évidente en début de projet n'était pas la bonne, et c'est l'analyse de risque qui a permis de s'en rendre compte.
Dans le premier cas, elle a révélé un faux besoin — la haute disponibilité — et conduit à une architecture plus simple à sécuriser.
Dans le second, elle a mis en lumière une information manquante dans les spécifications — la capacité du marchand à annuler les codes — qui a transformé un problème insoluble en problème gérable.
Dans le troisième, elle a objectivé le coût réel d'une contrainte jusqu'alors abstraite, permettant de prendre une décision éclairée et assumée : accepter un risque.
L'analyse de risque, c'est avant tout un exercice de lucidité. Elle ne produit pas toujours des plans d'action complexes — parfois elle produit des simplifications, des recadrages, ou des acceptations assumées. Dans tous les cas, elle produit de la clarté là où il y avait de l'ambiguïté.
Et c'est précisément pour ça qu'elle vaut la peine d'être pratiquée, même imparfaitement, même rapidement.
Cet article fait partie de la série cyberbasics, destinée aux développeuses et développeurs et aux petites structures qui souhaitent construire une posture de sécurité solide et pragmatique.