Le Cyber Resilience Act sera prochainement publié. Au-delà du mot « résilience » quelque peu dévoyé dernièrement, une question demeure. Dans un monde où l’on est tous « l’utilisateur final de quelqu’un », qui est redevable de l’insécurité des produits numériques ? Comment convaincre leurs fabricants et vendeurs de nous protéger ?

Avez-vous entendu parler du Cyber Resilience Act ? Il s’agit d’un règlement européen consacrant la sécurité durant tout le cycle de vie des produits numériques. Le texte de la proposition par la Commission paraîtra dans les semaines à venir. Il est, toutefois, possible de baliser les éléments principaux à surveiller comme le lait sur le feu, aussi bien dans le texte de la proposition que dans les modifications à venir. Le règlement a une forte ambition en s’attaquant à des niveaux techniques assez complexes. Il serait dommage de réinventer la roue.

Pourquoi ce texte ?

La Commission déplore l’absence de garanties de sécurité suffisantes de la part des fabricants et des vendeurs de produits. De plus, elle constate qu’il y a peu de solutions adéquates face aux vulnérabilités touchant ces produits et ce, tout au long de leur cycle de vie. Quant à l’information fournie aux utilisateurs sur le niveau de sécurité, il n’y en a pas. L’analogie qui me vient est simple. Imaginez, au supermarché en faisant ses courses, acheter des produits frais sans liste d’ingrédients, sans mention des allergènes et sans date limite de consommation. Fantasque, non ?

Et pourtant. Le Cyber Resilience Act entend y apporter des réponses sous la forme d’exigences pour les parties prenantes de la chaîne de valeur des produits numériques. Les ambitions du texte sont donc de promouvoir davantage de sécurité et une meilleure transparence des niveaux de sécurité pour les utilisateurs. En gros, si vous savez faire, faites-le savoir. Les retombées attendues sont positives. Sur le volet économique d’une part, via le renforcement de la confiance en l’économie numérique, et sur le volet conformité d’autre part, à travers une réduction des coûts de conformité par l’harmonisation d’exigences au sein du Marché unique. Vu les enjeux, les attentes sont énormes : parlons-en pour préparer l’analyse et les réponses.

Les questions en suspens : périmètre, cycle de vie, vulnérabilités, …

Comme il n’y a pas de texte publié, il est délicat de faire une analyse approfondie. Je m’appuie donc sur les travaux préparatoires auxquels j’ai été conviée, l’analyse des questions et des réponses à la consultation publique et autres positions publiées.

Le périmètre d’abord. Le titre anticipé du Cyber Resilience Act est « Règlement relatif aux exigences horizontales en matière de cybersécurité pour les produits numériques et les services accessoires ». Les travaux préparatoires définissent ainsi les produits numériques comme « produits matériels et logiciels », et le « service accessoire » comme un service (numérique) dont l’absence empêcherait le produit matériel d’assurer ses fonctions.

Tout ceci est bel et bon. Mais on n’a pas les mêmes défis en termes de sécurité quand on pense à un objet connecté, à l’ensemble des composants embarqués et à son application mobile d’accompagnement. Certaines interventions lors des travaux préparatoires et autres réponses à consultation insistent lourdement sur l’exclusion de la partie « logiciels » du périmètre du texte pour ne préserver que le volet « matériel » et « composants embarqués ». D’autres sont allées bien plus loin, en analysant les définitions de « logiciel » dans différents textes européens, insistant sur une définition homogène afin de ne pas augmenter l’entropie réglementaire. Idem pour les catégories de produits. L’orientation est que des exigences spécifiques s’appliquent à des catégories de produits spécifiques. C’est sensé, sans qu’on sache de quelles catégories il s’agit : produits en B2B ou en B2C ? Quels niveaux de sécurité pour ces grandes catégories ? Et quid de la situation où un produit se retrouve dans les deux catégories ? Pensez drones, bracelets GPS, serrures et autres pots de fleurs connectés.

La notion de cycle de vie des produits numériques ensuite. Aussi, la Représentation permanente des Pays-Bas n’a-t-elle pas argumenté en faveur d’une couverture complète du cycle de vie, de la conception à la fin de vie. C’est logique, mais le diable est dans les détails : les spécificités du matériel et du logiciel diffèrent souvent. Or, nous n’avons pas de cadre clair et unifié de ce qu’est le cycle de vie d’un produit numérique à l’échelle européenne. Pas de cadre de conditions opérationnelles, pas de cadre de responsabilité. Cet aspect est essentiel : les produits B2B n’ont pas les mêmes interactions de responsabilité entre les utilisateurs/clients et les fabricants que les produits B2C. Et quand on prend la notion de fin de vie, le boxon devient total.

Au-delà de la nécessité de préciser ce qu’embrasse le cycle de vie, il importe de veiller à une harmonisation de l’existant en termes de normes, standards, bonnes pratiques de communautés tech, etc., à l’échelle nationale, européenne et internationale. C’est essentiel pour éviter l’entropie réglementaire et les effets de bord indésirés. À titre d’illustration, un fabricant européen exportant ses produits en Asie ou en Amérique du Nord pourrait se retrouver freiné par un texte trop exhaustif. A contrario, des fournisseurs non-UE indispensables à la chaîne de valeur pourraient se voir éloignés sans remplacement. Cette harmonisation doit inclure une adhérence avec le CyberAct, le règlement imposant des schémas de certification UE.

Dans la ligne droite de ces réflexions vient le questionnement sur l’encadrement des compromissions de données à caractère non-personnel. Il n’y a pas de tel cadre au niveau UE. La directive NIS 2 fournit des éléments pertinents mais seulement pour les entités couvertes. Comment gérer donc les responsabilités dans le cas de fuites de données stratégiques, en contexte transfrontalier le plus souvent ?

La grande question de la gestion des vulnérabilités enfin. Toujours une histoire de rôles et de responsabilités avec laquelle viennent des sujets tels que la coordination, les délais de remédiation et les coûts. Certaines interventions arguent ainsi pour que le texte n’impose pas de délai de remédiation, quelle que soit la criticité de la vulnérabilité, à la faveur d’une coordination trop complexe. Est-ce viable dans un monde où les offres d’identification de vulnérabilités fleurissent, mais où l’on marque des délais de remédiation toujours plus longs par absence de ressources ? Ces délais sont le pain béni des gangs de rançongiciel et autres cyberdélinquants qui ont délaissé les mails de phishing pour des vecteurs plus prometteurs tels que l’exploitation de vulnérabilités non-corrigées. Votre serviteure est partisane d’une obligation de remédiation raisonnable, comme déjà explicité dans les travaux autour des normes internationales de l’Appel de Paris. Cet engagement n’est pas nécessairement acceptable des utilisateurs : au niveau opérationnel, il implique des ressources toujours croissantes pour tenter de tenir la tête de l’eau.

La question reste entière. Dans un monde où on est tous l’utilisateur final de quelqu’un, qui est redevable de l’insécurité des produits numériques ? Comment convaincre leurs fabricants et vendeurs de nous protéger ? Des éléments de réponse dans le Cyber Resilience Act.

Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.
Restez informés en temps réel
S'inscrire à
la newsletter
En fournissant votre email vous acceptez de recevoir la newsletter de Incyber et vous avez pris connaissance de notre politique de confidentialité. Vous pourrez vous désinscrire à tout moment en cliquant sur le lien de désabonnement présent dans tous nos emails.