Évaluation du risque cyber des produits : pourquoi la plupart des analyses de sécurité sont-elles apparemment correctes, mais pratiquement inutiles ?

Dans l’écrasante majorité des entreprises technologiques, le processus connu sous le nom d’évaluation du risque cyber existe déjà. Il prend le plus souvent la forme d’un vaste tableau, d’une matrice complexe ou d’un tableur où dominent les valeurs « low », « medium » et « high ». Ce document contient une longue liste de menaces génériques, de brèves descriptions de vulnérabilités potentielles ainsi qu’un ensemble de mesures de contrôle standard. D’un point de vue formel, tout est conforme : le document est complet, signé par la direction et soigneusement archivé.

Le problème, c’est que, dans la pratique de l’ingénierie, ce document ne change absolument rien.

Il n’influence pas l’architecture de l’appareil en cours de conception. Il ne conditionne pas les décisions sur la manière de fournir les mises à jour. Il ne modifie pas le modèle de support après-vente et ne réévalue pas les relations avec les fournisseurs de composants. C’est un document correct du point de vue de la compliance, mais totalement indifférent à la cybersécurité réelle des produits. Ce n’est pourtant pas la conséquence d’un manque de compétences dans les équipes d’ingénierie ou de sécurité. Le problème vient d’un point de départ fondamentalement erroné.

La plupart des analyses de risque traditionnelles commencent par la question : « Quelles menaces peuvent survenir ? ». Or, la nouvelle approche réglementaire de l’Union européenne – clairement visible dans des textes tels que le Cyber Resilience Act (CRA), les directives médicales (MDR) ou le nouveau règlement machines 2023/1230 – impose une perspective totalement différente. Elle commence par la question :

Dans quelles conditions d’utilisation le produit peut-il devenir un vecteur de risque pour l’utilisateur, le système ou le marché – et le fabricant est-il en mesure de maîtriser ce risque tout au long de son cycle de vie ?

C’est un changement de paradigme fondamental. L’évaluation du risque cyber dans le contexte du produit n’est pas simplement une analyse supplémentaire des menaces visant l’infrastructure IT. Ce n’est pas non plus un test d’intrusion ni l’application mécanique des recommandations de la norme ISO 27001. Il s’agit d’une analyse approfondie de la capacité du produit lui-même, ainsi que de celle de son fabricant, à maintenir la sécurité dans le temps, dans un environnement opérationnel réel.

Vulnérabilité technique et risque produit – une distinction en cybersécurité

Pour que l’évaluation des risques cesse d’être un simple tableau administratif et devienne un outil de décision pour l’ingénierie, nous devons distinguer avec précision deux notions que le marché confond très souvent. Gardons à l’esprit : une vulnérabilité n’est pas un risque produit.

• La vulnérabilité technique est un défaut concret, identifiable, dans le logiciel, la configuration matérielle ou la conception elle-même. Il peut s’agir d’une validation de données incorrecte, d’une bibliothèque logicielle obsolète ou d’une faille dans le mécanisme d’authentification. Ces défauts sont répertoriés dans des bases telles que le système CVE (Common Vulnerabilities and Exposures). Cela reste toutefois une évaluation strictement technique.
• Le risque produit n’apparaît qu’au moment où la vulnérabilité évoquée (ou même son absence temporaire) est replacée dans la réalité, souvent brutale, de l’usage.

Ce contexte couvre de nombreuses variables : l’environnement de fonctionnement (réseau ouvert ou isolé), la manière dont le produit est intégré à d’autres systèmes, les comportements des utilisateurs, la disponibilité des mises à jour de sécurité (le « patch management ») ainsi que la capacité organisationnelle du fabricant à réagir aux incidents.

Un produit peut ne présenter aucune vulnérabilité connue le jour de son lancement et, malgré tout, générer un risque critique si son concepteur ne dispose pas de processus de support sur le long terme. Comprendre cette différence structure l’ensemble du travail d’ingénierie. C’est précisément sur cela que repose l’approche fondée sur le risque (risk-based approach). Les mesures de sécurité doivent être proportionnées à des scénarios d’abus prévisibles, et non à une liste abstraite trouvée sur internet.

Paradoxe des protections : quand la protection augmente le risque en IT et en OT

En conception de cybersécurité, on part souvent du principe que l’ajout d’un nouveau « cadenas » réduit toujours le risque. La pratique montre qu’il peut se produire exactement l’inverse. Une mesure déployée sans compréhension du contexte crée de nouveaux vecteurs de menace.

1. Authentification forte en environnement industriel (OT)

Imaginons le déploiement d’une authentification multifacteur (MFA) sur une machine industrielle. Du point de vue IT, c’est une démarche exemplaire, mais la cybersécurité en automatisme industriel relève d’une tout autre réalité. En environnement d’usine, l’équipement fonctionne 24/7 et les interventions de maintenance se font sous pression. Lorsque le réseau tombe, le technicien ne peut pas autoriser le jeton en ligne. La production s’arrête. Résultat ? Un client frustré désactive définitivement ce mécanisme, contournant totalement la protection. La mesure censée protéger a généré un risque opérationnel majeur.

2. Mises à jour automatiques dans les dispositifs médicaux (IoMT)

Le colmatage rapide des failles réduit l’exposition aux attaques, ce qui est la norme dans le monde IT. En revanche, dans le domaine des dispositifs médicaux, une mise à jour imposée en pleine procédure peut modifier le comportement du système ou rompre la communication avec le réseau hospitalier. Dans ce cas, une protection technologique crée un risque clinique et réglementaire critique (violation de la certification MDR).

3. Fermeture des interfaces dans les équipements grand public (IoT)

Le fabricant supprime physiquement les ports de diagnostic locaux d’un appareil de maison intelligente afin de compliquer l’accès aux hackers. En pratique, les services agréés commencent à diagnostiquer les pannes via des interfaces instables en contournant le chiffrement, et les utilisateurs avancés installent massivement des logiciels modifiés (custom firmware). Résultat : le fabricant perd totalement le contrôle de son propre écosystème.

Une véritable analyse des risques cyber pose la question suivante : « Comment la stabilité, l’utilisabilité et la sécurité de l’ensemble de l’écosystème vont-elles évoluer après l’ajout de ce mécanisme précis ? ».

Les 5 erreurs les plus fréquentes dans l’analyse des risques des produits technologiques

En évaluant les processus d’entreprises qui mettent sur le marché de l’électronique et des logiciels, les experts en cybersécurité constatent des schémas récurrents.

1. Transposer le modèle IT des grandes entreprises au monde des produits. Un produit n’est pas une salle serveurs. Il fonctionne dans un environnement inconnu, souvent hors ligne, configuré par des non-spécialistes. Appliquer des outils IT à l’analyse d’un produit conduit à ignorer des enjeux clés : le cycle de vie de l’appareil et l’absence de mises à jour imposées.
2. Analyser des menaces abstraites au lieu de scénarios réels. Remplir un tableau avec des formules comme « accès non autorisé » n’a aucune valeur analytique. L’analyse doit s’appuyer sur du concret : Qui ? Par quelle interface ? Dans quel but ? Avec quelles conséquences ?
3. Ignorer le cycle de vie du produit (End-of-Life). L’analyse des risques concerne généralement le moment du lancement. Or, le risque augmente avec le temps : les bibliothèques open source vieillissent et les fournisseurs de composants arrêtent le support. Sans prise en compte du modèle de maintenance, l’analyse est faussée.
4. Travailler en silo, à distance de l’équipe de conception (R&D). Traiter l’évaluation des risques comme une checklist avant audit est une voie directe vers la catastrophe. Les résultats doivent revenir vers les ingénieurs sous forme d’exigences d’architecture fermes (Secure by Design).
5. Fétichiser la technologie au détriment des procédures. Les entreprises investissent des fortunes dans une cryptographie avancée, mais ne savent pas qui, dans l’organisation, est responsable de publier un correctif de sécurité (patch) après le signalement d’une faille par un chercheur (Vulnerability Disclosure Program).

Comment réaliser une analyse conforme au Cyber Resilience Act ? 7 étapes d’ingénierie

L’évaluation des risques cyber doit cesser d’être une charge bureaucratique. Vous trouverez ci-dessous un modèle opérationnel orienté marché, aligné sur l’approche de l’Union européenne (notamment les exigences du CRA).

1. Définissez les limites du produit. Un produit ne se résume pas au matériel. Il inclut aussi l’application mobile, le cloud, les serveurs OTA et les interfaces API.
2. Décrivez la réalité brute de l’environnement d’utilisation. Ne décrivez pas un environnement de laboratoire. Répondez aux questions sur la connectivité réelle à Internet, les compétences des utilisateurs et les possibilités d’accès physique à l’appareil.
3. Identifiez les scénarios d’abus (Threat Modeling). Écartez les listes génériques. Appuyez-vous sur des méthodes et outils d’ingénierie éprouvés d’estimation des risques pour vous concentrer sur des vecteurs d’attaque précis, adaptés à votre secteur.
4. Quantifiez les conséquences non financières. Évaluez le risque d’arrêt de production, les menaces pour la santé ou la violation d’obligations réglementaires.
5. Posez la question de la maîtrise. En tant que fabricant, êtes-vous en mesure de prévenir, détecter et réagir rapidement au scénario d’abus identifié ?
6. Concevez des mécanismes de protection proportionnés. Les décisions relatives au chiffrement ou à la séparation réseau doivent découler directement des réponses apportées aux étapes précédentes.
7. Concevez le processus de maintenance (Lifecycle). Documentez la politique de fourniture des correctifs de sécurité, la durée de support et les canaux de communication avec le client.

Conclusion : que doit-il rester d’une évaluation des risques rigoureuse ?

L’aboutissement d’une évaluation des risques de cybersécurité d’un produit correctement menée ne devrait jamais être un poème dense destiné à l’auditeur. Ce travail doit produire des livrables tangibles : une cartographie claire des limites du système, des décisions d’architecture fermes en R&D, un budget validé pour la politique de mise à jour, ainsi qu’une traçabilité d’audit cohérente démontrant la conformité aux directives de l’Union européenne.

Une organisation technologiquement mature ne demande plus : « Sommes-nous sûrs à 100 % ? ». Elle demande plutôt : « Où, précisément, sommes-nous exposés et savons-nous gérer cela dans le temps ? ».

Votre produit est-il prêt pour les nouvelles réglementations ?

La sécurité est un processus, pas un certificat ponctuel. Si vous ne voulez pas que l’évaluation des risques dans votre entreprise se limite à de la « paperasse », il vaut mieux adopter une démarche proactive. Découvrez comment préparer concrètement votre produit au Cyber Resilience Act (CRA) en 2026-2027, avant la publication des normes harmonisées officielles.