Les étapes

Ma base de travail : EBIOS RM (Expressions of Needs and Identification of Security Objectives – Risk Management), la méthodologie française de référence pour les analyses de risques, couplée à EGERIE, l’outil de pilotage et de suivi et reporting qui centralise tous les risques, les plans d’action et le suivi.

Concrètement, j’ai animé 5 ateliers EBIOS RM auprès de 2 à 3 clients différents pour identifier les risques informatiques de façon systématique. J’ai consigné chaque risque dans EGERIE avec son contexte, son impact (critique/fort/moyen/faible), et son porteur de risque. J’ai créé des plans de préconisations détaillés pour éliminer ou réduire chaque risque identifié. J’ai piloté des points réguliers avec les clients pour valider les choix techniques et négocier les priorités en fonction du budget. Et j’ai participé à la redéfinition du PASG (Plan d’Assurance Sécurité Gouvernance) – le document qui définit les normes de sécurité de toute l’entreprise.

La typologie des risques identifiés : 70% classique (HTTP non chiffré, absence de MFA, configurations faibles), 30% technique complexe. J’ai croisé des configurations faibles (protocoles non chiffrés, absence de MFA), une gestion insuffisante des accès (droits trop larges, absence d’audit), des chaînes d’approvisionnement fragiles (dépendance à des prestataires sans contrats de sécurité), et même de la fraude cyber potentielle liée à des failles d’authentification ou de logs mal configurés.

L’anecdote qui a marqué : Une vulnérabilité de concurrence sur la base de données. Durant une analyse de risque, je travaillais sur une base de données critique utilisée par plusieurs services simultanément. En creusant la documentation technique de la BDD, j’ai découvert une vulnérabilité de concurrence : si deux processus appelaient la même base de données en même temps et faisaient des modifications simultanées, on pouvait soutirer des informations sensibles (exfiltration de données via une situation de compétition), provoquer l’arrêt de la base de données ou seulement certaines valeurs, ou créer des états incohérents des données (corruption).

Le truc intéressant ? La solution existait déjà dans la documentation du fournisseur, mais le client ne la connaissait pas. J’ai recommandé l’implémentation d’un système de versioning des données – essentiellement, chaque modification crée une version de la donnée avec un horodatage et une empreinte (hash), ce qui permet de détecter les modifications simultanées et les rejeter/retry, d’avoir un audit complet (qui a modifié quoi et quand), de revenir en arrière (rollback) en cas d’anomalie.

C’est l’essence du métier de consultant : il ne s’agit pas de réinventer la roue mais avoir l’esprit critique suffisant pour creuser la doc, trouver ce qui existe, et l’adapter au contexte du client.

Les projets du client : Où les risques se matérialisent vraiment. J’avais un client principal pour lequel j’animais les analyses et je pilotais les plans d’action. Ce client avait deux gros projets en cours qui soulevaient des enjeux de sécurité majeurs.

Le premier était une migration de datacenter. Le client quittait son infrastructure physique actuelle pour migrer vers une nouvelle. Les risques étaient évidents : interruption de service non planifiée qui paralyse le service critique, perte de données lors de la migration (corruption, oubli de fichiers), incohérence entre l’ancien et le nouveau (défaut de synchronisation des données), et surtout des attaques qui profiteraient de la fenêtre de migration quand les défenses sont baissées et l’organisation chaotique. J’ai proposé une stratégie de migration par vagues avec points de synchronisation entre ancien et nouveau, des tests de restauration pour valider qu’on ne perd rien, et des équipes de sécurité dédiées pendant la fenêtre sensible.

Le second projet était encore plus sensible : mise en place d’une API externe. Le client voulait exposer une API aux partenaires externes. Ça veut dire authentification robuste (OAuth2, JWT bien signé, pas de secrets en dur), chiffrement en transit (TLS 1.3 minimum, zéro HTTP), gestion des clés API (rotation régulière, audit complet, traçabilité), limitation de trafic (rate limiting) et protection anti-DDoS (l’API devant résister aux montées en charge), et logging exhaustif des appels (qui appelle quoi, quand, d’où).

L’une de mes premières recommandations : chiffrer les échanges entre clients et API avec des algorithmes modernes (AES-256 en plus du TLS), et surtout logger chaque changement de clé API dans un système d’audit immuable (blockchain/ledger distribué ou simplement des logs centralisés non modifiables).

L’enjeu majeur que j’ai amené : Le chiffrement post-quantique. C’est là où j’ai vraiment déployé l’esprit critique. J’ai pris conscience d’un point fondamental : la majorité des algorithmes de chiffrement actuels (RSA, ECDSA, etc.) seront cassés dans 10 à 15 ans si les ordinateurs quantiques arrivent à maturité.

Le client n’en parlait pas. Personne n’en parlait vraiment. Mais avec une infrastructure aussi critique, la continuité de service dans 20 ans, c’est maintenant qu’on la prépare.

J’ai donc amené le sujet de façon proactive : « On chiffre les données avec RSA-2048 aujourd’hui, mais dans un futur proche, ce sera vulnérable face à un ordinateur quantique. Quelle est notre stratégie ? »

Le client (qui est une grosse entreprise) a compris immédiatement l’enjeu. Nous avons donc élaboré une roadmap vers le chiffrement post-quantique : Phase 1 en 2026, audit complet des algorithmes crypto utilisés actuellement. Phase 2 de 2026 à 2027, commencer par les données les plus sensibles (cryptage de secrets, clés maîtres) et migrer vers des algorithmes post-quantiques standardisés par le NIST (Kyber pour l’échange de clés, Dilithium pour la signature). Phase 3 de 2027 à 2028, étendre à toute l’infrastructure critique. Phase 4 à partir de 2028, évaluer l’évolution des standards et adapter.

Il ne s’agit pas d’une promesse à court terme, c’est une stratégie à long terme adaptée à la maturité des technologies et aux contraintes du client.