Transcription

• Speaker #0

  Bonjour mamie, j'ai ramené un copain.

• Speaker #1

  Maintenant, on peut passer sur une partie délicieuse qui s'appelle 13 exigences essentielles. de cybersécurité, parce que c'est quand même le gros du truc. Il y a les très exigences cyber, j'ai fait un très joli picto, c'est vrai que je mettrais bien sûr en ligne pour ma grand-mère, et donc ça c'est très exigences cyber, c'est bleu, et ensuite il y a les exigences vulnérabilité qui sont rouges, ça fait bleu, rouge, comme ça j'arrive moi-même à me souvenir à peu près de ce que je dis. Et là, à un moment, il n'y a pas photo, il faut aller lire, Il faut aller lire le catalogue. Donc, en fait, ça ne se simplifie pas. Ça ne s'invente pas. Voilà. Donc, 13 exigences cyber. Alors, je vais les lister, sottement. La première, mise sur le marché. Donc, il est obligatoire de mettre sur le marché des produits conformes, agréés CE, marquages avec assistance. Ça, j'en parle même pas. Donc, mise sur le marché sans vulnérabilité exploitable connue. Exigence numéro une. C'est une révolution. C'est vrai que... On se demande pourquoi est-ce qu'on l'écrit. On se demande donc comment ça se passait avant. Je n'insiste pas. 2. Mise sur le marché obligatoire avec une configuration de sécurité par défaut.

• Speaker #0

  Alors ça, c'est intéressant parce que ça, c'est quand même un gros problème qu'on a en cybersécurité parce que souvent, entre guillemets, les softs sont installés par défaut avec des paramétrages qui ne sont pas sécure.

• Speaker #1

  Admin, admin !

• Speaker #0

  Oui, c'est un bon exemple. Mais alors, ça s'est même vu à une époque dans le cloud ou par défaut. il n'y a encore pas si longtemps que ça, quand on créait une VM sur le cloud, par défaut, elle avait une adresse IP publique. Si on n'avait rien demandé, c'est pratique.

• Speaker #1

  On va plus vite.

• Speaker #0

  Ça va plus vite, mais ce n'est pas forcément dans le sens de la cybersécurité.

• Speaker #1

  Voilà, donc exigence 2, les 13 exigences cyber. Exigence 3, les vulnérabilités éventuelles peuvent être corrigées par des mises à jour de sécurité. Parce qu'il y avait des firmwares, on disait, ah bah non, maintenant que le firmware est installé... On ne peut plus. Non, il y a une vue. C'est dommage, mais on ne peut plus rien pour vous. Bon, on apprécie. Quatre. Protection contre les excès non autorisés avec signalement de détection de... Pas mal, quand même. Et donc, je refais là aussi, sur les 13 exigences, il va falloir les faire ou alors écrire pourquoi on ne le fait pas. C'est-à-dire que c'est le catalogue. Alors ensuite, c'est toujours pareil. Ça va être de la sécurité par le risque. OK ? Donc, chacun assume sa responsabilité. Très bien. Donc, il faut faire. Mais si on ne fait pas, si on en justifie, l'autorité de contrôle peut dire « Ok, vous en avez justifié, mais c'est vrai ou ce n'est pas vrai ? » Parce que l'autorité de contrôle, après, via les vérifications... Bref, ok. Sinon, c'est trop facile. « Oh ben non, moi, c'est déjà fait. » Bon, super. Donc, les accès non autorisés. 4. Chiffrez les données au repos ou en transit.

• Speaker #0

  Ce, c'est un grand classique.

• Speaker #1

  ça méritait d'être écrit quand même. Voilà.

• Speaker #0

  Et encore, on a échappé au fameux article qu'on peut retrouver dans Dora, où on parle de chiffrement en données, à Trest, en transit. Ou en cours d'utilisation. En cours d'utilisation. Celle-là, je reste encore un peu perplexe sur la manière de pouvoir chiffrer des données en cours d'exécution. Parce que, mis à part avec le chiffrement homomorphique qui est... très beau sur le papier, ça marche sur le papier. Je ne l'ai pas encore vu trop souvent tourner, ce truc-là. Donc, oui, j'attends de voir comment on va pouvoir traiter cet aspect-là.

• Speaker #1

  Alors, il y a ta grand-mère qui vient de me passer un petit message. Elle voudrait du chiffrement homomorphique post-quantique. C'est des fois que ça marche. Je n'insiste pas, je ne lui réponds même pas. Je n'ai pas compris tous les mots. Je l'ai vu. J'ai vu une plaquette commerciale avec du chiffrement homomorphique post-quantique. D'accord. Non, mais comme quoi, tout arrive. j'attends de voir les perfs mais bon oui oui grave alors on était au 5 6 protéger l'intégrité des données des commandes des programmes et de la configuration contre toute manipulation ou modification non autorisée ok

• Speaker #0

  je la refais ou non c'est bon non ça ira on voit le concept grosso modo on peut pas altérer le programme bah simple on va dire ça comme ça voilà

• Speaker #1

  On pourra toujours faire de l'exécution de code arbitraire, mais il faudrait éviter que ce soit trop trivial. Moi, je le vois un peu comme ça. En 7, on a un concept qui nous vient en direct du RGPD. Je pense que tes auditeurs savent tout le mal que je pense de ce truc-là, de l'importance que ça a pris en tout cas. Minimisation des données obligatoires. Et ça, ce n'est quand même pas débile. C'est qu'on va arrêter de prendre tout. Est-ce que tu as besoin de géolocaliser en permanence un truc, un machin ? On avait de la jurisprudence en France sur les voitures de location qui étaient géolocalisées tous les 100 mètres. À un moment, on dit, écoutez, vous êtes gentils, mais c'est peut-être un peu excessif. Bref, principe numéro 7. Principe numéro 8. Protéger la disponibilité des fonctions essentielles et des fonctions de base. Voilà, donc il va falloir réfléchir. Qu'est-ce que c'est qu'une fonction essentielle et une fonction de base ? Je n'insiste pas. Attention, et puis on a été à 8. 9. Réduire les effets négatifs générés par les produits sur la disponibilité des services ou réseaux tiers.

• Speaker #0

  Ça veut dire ne pas avoir d'effet de bord en cas de problème ?

• Speaker #1

  Les réduire, les réduire. Alors, je ne sais pas. Bon. on va dire que ça va être un problème et qu'on va les réduire. Très bien. 10 sur 13. Les produits sont conçus, développés et fabriqués en limitant la surface d'attaque.

• Speaker #0

  Ça encore, c'est plutôt de bon sens.

• Speaker #1

  Ça fait de sens. Ça me va assez bien. 11. Plus problématique. Il va falloir trouver un moyen de limiter l'exploitation de failles. Alors là, c'est marqué faille. Ce n'est pas marqué vulne, c'est marqué faille. On ne sait pas. Moi, à mon avis, ils se sont juste un peu pris les pieds dans le tapis. Ils doivent vouloir dire Vuln, parce que Vuln est utilisé 787 fois dans le CERA. Donc, à mon avis, là, c'est juste, ils se sont un peu pris les pieds dans le tapis. Mais limiter l'exploitation potentielle de faille, si on a un peu segmenté les choses, je ne sais pas. Après, c'est plus à toi de nous dire. Moi, j'ai demandé à ma grand-mère, elle ne sait pas. Moi, je ne sais pas, là.

• Speaker #0

  effectivement ça peut par design qu'on peut éviter d'avoir ce genre de problème mais encore une fois limiter ça permet pas d'empêcher vraiment les choses donc bon à voir du risque

• Speaker #1

  12 alors là moi j'ai adoré enregistrer et surveiller les activités internes c'est le monitoring fichier log pour tout le monde il paraît que s'il y a des alertes qui se lèvent qui sont levées il paraît qu'il faut aller les voir moi je ne sais pas pourquoi je dis ça je ne sais pas et 13 sur 13 bon facile donner aux utilisateurs la possibilité de supprimer les données et les paramètres qu'ils ont introduit dans le machin genre un reset un factory reset ouais je ne sais pas je n'ai pas très bien compris l'utilité de ça mais voilà moi ce que je te propose c'est que déjà au niveau des 13 exigences cyber on s'arrête après il y a du détail il y en a de partout super maintenant nous allons passer agréablement aux huit exigences de gestion des vulnérabilités. Là, il n'y en a qu'huit. Pareil, recatalogue. Donc, exigence une. Recenser et documenter les vulnérabilités et les composants des produits, au moins les dépendances de niveau supérieur. Et ça, en fait, cette exigence-là, on va la retrouver dans la nomenclature des logiciels embarqués. Et en fait, il y a des concepts qu'on retrouve comme ça. Alors là, tu vois, dans tes exigences, c'est là. Puis après, dans la documentation, c'est dit là aussi. Puis dans les instructions, c'est aussi dit là. Et les trucs se renvoient les uns aux autres. Bon, donc c'est le numéro 1. Recenser et documenter les vulnes et les composants des produits de niveau supérieur. Voilà, pour garder l'idée au sens large. Deuxièmement, la deuxième exigence vulnérabilité. Corriger les vulnérabilités, notamment par des mises à jour de sécurité. Ah ! C'est important de le prévoir quand même. Des fois, il y a des fabricants, distributeurs, importateurs qui oublient de temps en temps. On ne sait pas pourquoi. Pas de nom.

• Speaker #0

  D'un autre côté, s'ils ne communiquent pas sur les vulnérabilités, il n'y a pas besoin de les corriger. C'est plus simple.

• Speaker #1

  C'est ce qui paraît. Il paraît même que c'est pour ça qu'on a eu en France la LPM 2023 où à un moment, on a dit que quand tout le monde le sait, soit vous divulguez... Soit c'est moi, l'Annecy, qui vais le faire en mettant votre nom et ça va clignoter et ça ne va pas bien se passer. Juste ça, le fameux Naïm Hanchem. Donc, je divulgue en ton nom et pour ton compte. Mais c'était que l'Annecy et que en France. Et je n'ai pas entendu beaucoup d'application de ce truc-là. Mais le simple fait de l'avoir dans son escarcelle en menace, apparemment, ça fonctionne très bien. Bref, revenons à nos huit exigences essentielles. Vulnérabilité. Il n'y a que des exigences essentielles. Donc, ça donne aussi, comme les secteurs hautement critiques, les autres secteurs critiques. Voilà, on met la barre très haut et on fait peur. Donc, 3. Test et examen de sécurité efficace, régulier. Ben, peut-être des pêtes d'aise. Moi, je ne sais pas. J'ai pensé à ça tout de suite.

• Speaker #0

  Je ne le sais pas. Oui, effectivement, il y a des pen-tests. Le problème, c'est sur le côté régulier parce qu'on ne va pas faire des pen-tests toutes les 5 minutes. Généralement, on va faire des pen-tests quand on aura une version majeure d'un soft qui va sortir. Mais on sait très bien que les versions majeures, assez rapidement, elles changent. Il y a le problème aussi du logiciel en tant que tel qui ne va peut-être pas bouger, mais son environnement d'exécution qui, lui, va bouger. Du coup, il y a un autre problème aussi avec ça. Peut-être que... On parle aussi de programmes de bug bounty, par exemple, qui pourra donner un petit peu plus de continuité sur la partie test, c'est possible. Mais effectivement, ça va être un vaste sujet.

• Speaker #1

  Mais donc, c'est test et examen de sécurité efficace. Pas du test bidon, parce que s'ils ne sont pas efficaces, on peut les faire régulièrement, on s'en fout. De toute façon, c'est écrit comme ça, mais c'est dans l'esprit, c'est ça qui est important. On passe au 4, 4 sur 8. Communiquer sur les vulnérabilités corrigées. Description, conséquences, gravité et informations claires et accessibles aidant les utilisateurs à y remédier. Là, c'est utilisateur, on voit bien le côté B2C. B2B, évidemment, mais là, dès qu'il y a le mot utilisateur, c'est instinctivement où on pense à ce côté B2C. Donc, ça veut dire tout le monde, entre nous soit dit. Quatre. Cinq. Alors ça, je ne développerai pas parce que ça, c'est vraiment un métier et Réna, là aussi, adorerait en parler. Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités. Ça, ça fait partie des impératifs qu'on va retrouver dans la documentation technique, dont pareil, je vous ferai juste le petit catalogue. Là, maintenant, c'est aller pour tout le monde, politique de divulgation coordonnée. Il faut arrêter de se voiler la face.

• Speaker #0

  Juste une petite question par rapport à ce point-là, parce que là, on parle de politique de divulgation coordonnée. Donc, a priori, c'est le producteur du soft qui va... communiquer auprès de ses tiers, entre guillemets, d'une virabilité qu'il a découvert, mais est-ce que la réglementation parle aussi de l'inverse, c'est-à-dire mettre une politique en place pour que de gentils hackers, on va dire ça comme ça, puissent communiquer auprès de l'entreprise ou du producteur suite à la découverte d'une virabilité ?

• Speaker #1

  Alors, dans le CRA de mémoire, ça n'est pas prévu, mais c'est prévu dans NIS 2, où il est dit que toute personne peut, même de manière anonyme, informer son autorité de contrôle d'une vulnérabilité, blablabla. Donc, a priori, ce serait déjà réglé via Nice 2, quand ça va être transposé pour de vrai, mais c'est prévu en dur dans Nice 2. Donc, ça va nécessairement finir dans les législations nationales. Et à mon avis, c'est là où on pourra dire, tiens, j'ai acheté ça, j'ai découvert ça, et moi, je te remonte moi particulier, moi entreprise d'ailleurs, parce que moi, j'ai des clients qui… remontent des vulnes, pas des clients professionnels, des entreprises qui remontent des vulnes critiques en général à l'ANSI. En général, ce n'est pas en dessous de 9. Souvent d'ailleurs, c'est 9, 8, 9, 9, 10, où là, on se fend soit du formulaire de déclaration en ligne d'ANSI, soit d'un coup de téléphone aux représentants sectoriels, géographiques, où là, il y a toujours quelqu'un qui connaît quelqu'un et le message passe en direct. Mais voilà. Mais a priori, dans le CRA, il n'y a rien de prévu. Parce qu'il n'y a pas besoin. En fait,

• Speaker #0

  c'est ça. Le mécanisme existe déjà.

• Speaker #1

  Voilà. Ensuite, la politique des divulgations coordonnées, 5 sur 8. 6 sur 8. Faciliter le partage d'informations sur les vulnérabilités potentielles, ainsi que des composants tiers. Favoriser. Faciliter.

• Speaker #0

  C'est un peu double tranchant parce que c'est toujours compliqué de parler des vulnérabilités parce que si on commence à parler des vulnérabilités, quelle est la limite entre parler d'une vulnérabilité, comment on s'est expliqué, comment on l'exploitait et un

• Speaker #1

  POC ou autre ce qui pourrait avoir un intérêt aussi pour retester que ça fonctionne correctement c'est un peu à mon avis il y a au moins une demi page là dessus dans le CRA voire deux considérants complets Merci. C'est juste l'overview. Donc là, on était à 6. 7 sur 8. Mécanisme de distribution sécurisée des mises à jour. Ça, c'est quand même pas mal.

• Speaker #0

  C'est quand même un peu le minimum.

• Speaker #1

  Oui, recenser, documenter les dépendances de niveau supérieur qu'il fait. Dans le process, ça paraît parfaitement légitime. Logique, je ne sais pas, mais légitime. il faut l'écrire pour qu'on puisse espérer que ce soit fait donc 7 sur 8 et 8 sur 8 alors ça doit être un résumé de ma main parce qu'il n'y a pas de guillemets diffusé dans les plus brefs délais et gratuitement les correctifs ou mises à jour de sécurité avec les informations pertinentes, gratuitement, dans les plus brefs délais. Voilà, ok. Ça, ce sont les huit exigences essentielles vulnérabilité. Et en fait, c'est un peu l'état de l'art, on a envie de dire, d'un truc qui est un minimum sécurisé. Oui,

• Speaker #0

  je pense qu'effectivement, c'est... Tout ce que tu as cité est quand même assez logique finalement. Il n'y a rien qui me choque dans la liste, effectivement. La problématique réside dans la mise en œuvre et surtout sur des mots qui ne sont pas forcément très déterministes en cybersécurité, genre par exemple « rapide » , c'est-à-dire quoi « rapide » ?

• Speaker #1

  Oui, dans les plus brefs délais. Les plus brefs délais,

• Speaker #0

  oui, c'est ça. Fascinant, mais toujours compliqué.

• Speaker #1

  Bon, les vulnes, je retrouverai les slides pour la signification des vulnes. C'est toujours pareil, c'est 24 heures, 72 heures et 14 jours. C'est plus 30 jours pour le rapport final. Sauf si le truc est toujours en cours, auquel cas, bon voilà. Enfin, on retrouve toujours les mêmes repères. Donc là, pareil. Sauf qu'aujourd'hui, l'autorité de contrôle qui va être chargée de distribuer les sanctions pécuniaires ou le retrait ou le rappel des produits, aujourd'hui, on ne sait pas. Et là, on a une option. Soit c'est la DGCCRF. en France. Direction générale, impression, concurrence, consommation, fraude, voilà. Parce qu'ils ont l'habitude d'aller constater la non-conformité des produits dans les supermarchés, dans les magasins, mais eux, en termes de cyber, je n'ai pas entendu dire que c'était des cadors. Bon, donc il va falloir les former. Puis de l'autre côté, si on dit c'est de la cyber, c'est l'Annecy, mais l'Annecy, ils ne vont pas aller au supermarché pour aller récupérer les brosses à dents connectées. pour aller regarder si la notice, elle est bien ou pas. Ce n'est pas leur mission. Ou alors, ils vont faire x14 en termes d'effectifs, de ressources humaines, de ressources tout court. Donc, on ne sait pas. C'est la grande année. Donc, nous attendons d'avoir... Alors, est-ce que ça va être une « task force » , une autorité ad hoc ? On pourrait l'appeler l'autorité CRA, avec du détachement, par exemple à Annecy, du détachement des GCCRF, du détachement autorité de la concurrence, je ne sais pas. Là, pour l'instant, c'est le flou absolu et complet en France. On n'en sait rien. Mais ça, c'était la partie facile du CERA. Et la partie qui est vraiment atroce, c'est qu'une fois qu'on sait tout ça, qu'est-ce qu'on doit faire pour de vrai ? Eh bien, il y a entre quatre et six procédures différentes qui s'appliquent en fonction de la... Non, il y en a quatre. Les procédures d'évaluation de conformité. Une fois qu'on a tout bien fait, on fait une attestation sur l'honneur, on crie « je le jure » , on ne crache pas par terre parce que ce n'est pas propre. Et puis, on met un marquage CE sur un logiciel, c'est bien connu. Mais ça reste un truc produit. Et là, on a des procédures d'évaluation de la conformité, du respect et du CERA. Et là, il y a un principe général qui est, pour tout le monde, rédaction d'une documentation technique en huit points. Ça, c'est le truc obligatoire. Et dans la documentation technique, il y a notamment les instructions utilisateurs. Nous verrons qu'ils ont 7 points. Bref. Et donc ça, c'est vraiment la procédure de droit commun. Pour tout le monde, c'est en réalité une auto-évaluation documentée de conformité. Donc, je fais mon dossier CRA avec tout ce qu'il faut mettre dedans et je vérifie que j'ai bien fait les 13 exigences machin et les 8 exigences bidule. Voilà. à cette procédure d'auto-évaluation, dont tout le monde sait que l'auto-évaluation, c'est bien, mais ça a ses limites, l'Union européenne, dans sa grande sagesse et sa complexité quand même, nous a prévu un régime d'exception, qui est un régime d'auto-évaluation contrôlé par un tiers, bien sûr, qui ne concerne que les produits importants classe 1 ou classe 2. j'aurais voulu l'inventer, j'y serais même pas arrivé ou les produits critiques, là il n'y en a que 3 là tu as un régime pour ces logiciels, donc on va voir la liste parce que c'est tout à fait saisissant ces logiciels eux ça va quand même être contrôlé par un tiers parce qu'à force de dire que mon produit est toujours conforme on va pas pouvoir contrôler tout le temps et tout le monde donc on va rentrer juste pour que vous ayez quand même aussi le jargon technique, donc la procédure d'auto-certification Merci. s'appelle le module A. A, la lettre A. Ensuite, nous avons, pour les niveaux supérieurs, nous avons le module B. qui s'additionne au module C. Donc, le module B, c'est avec un contrôleur agréé et un système de fabrication autocontrôlé. Donc, on est soit module A, soit module B plus module C, qui forme un tout, mais ça fait deux modules. Et sinon, ensuite, nous avons le module H. Donc, ça fait A, B, C, H. C'est extraordinaire. Je ne sais pas qui a pondé ça. Alors là, il y a un système de qualité contrôlée. Je ne sais pas très bien ce que ça veut dire. Et, et. Des fois qu'on s'ennuie, il y a un quatrième système qui s'appelle les schémas de certification cybersécurité UE. Et là, on a pris, après le CERA, on a pris une modification par un règlement de Bruxelles qui est allé modifier un règlement de Bruxelles de 2019, qui est le grand règlement chapeau, sur les grandes définitions, l'ENISA et les procédures de certification. Et donc, nous attendons en tremblant. de savoir ce que seront les schémas de certification EU. En clair, ce seront des checklists quasi obligatoires et extrêmement denses que si tu n'as pas fait tout ça, si ton produit, on exige qu'il y ait un schéma de certification EU que tu dois appliquer, ton produit, il est rejeté, il n'est pas conforme, il ne peut pas être commercialisé. Mais peut-être, peut-être que tu as la chance d'être dans la procédure module B avec contrôleur agréé, c'est ceux qui doivent être désignés au mois de juin 2026. et qui additionne à ça un processus de fabrication autocontrôlée. Donc ça, c'est le module B plus le module C. Je ne reparle pas du module H.

• Speaker #0

  Non.

• Speaker #1

  En plus,

• Speaker #0

  ils ont perdu entre-temps apparemment.

• Speaker #1

  Oui. Voilà. Juste pour donner une idée. En fait, la partie où il faut juste retenir deux secondes, c'est la partie contrôleur agréé. Donc, il y aura l'auto-évaluation réalisée, cas commun. Pour tout, tout le monde, tout. Les 13 exigences, les 8, la doc, le machin, le truc. Donc, ça va être audité par un contrôleur agréé qui va faire, un, un examen de la documentation technique, deux, un examen des preuves à l'appui de l'adéquation des solutions retenues. Je cite, ça ne m'embrasse pas. Et trois, des examens d'échantillons critiques.

• Speaker #0

  D'accord. En fin de compte, ça me fait penser un peu à Swift, parce que Swift a un peu un mécanisme similaire en fonction de l'usage que vous faites de Swift. Si vous êtes... entre guillemets, simple utilisateur du Swift, ou alors si vous revendez, entre guillemets, du Swift, si vous êtes Swift Bureau, par exemple, les contraintes ne sont pas les mêmes, et vous avez l'auto-certification, puisque grosso modo, c'est un audit que vous faites vous de votre côté, éventuellement supervisé par un tiers, et avec différents degrés de contrôle, jusqu'à voir des inspecteurs qui viennent chez vous pour vérifier si tout est effectivement conforme. Sachant qu'en réalité, les inspecteurs de SWIFT ne viennent jamais. Ils délèguent ça forcément à des contrôleurs locaux qui vont faire le boulot pour eux. Donc, j'ai l'impression que c'est un peu le même mécanisme qui est mis en œuvre là pour essayer que tout le monde ait un minimum de documentation et se mette un peu en conformité avec des contraintes plus ou moins changeantes en fonction du contexte.

• Speaker #1

  Tout ça étant bien sûr ce qu'il y a aujourd'hui de connu dans le CRA. Il faut bien intégrer que le CRA évoluera entièrement à la main de l'Union européenne sans repasser par la case parlement, directive, règlement. Non, ce ne sera que du. Alors, nous avons découvert grâce à Dora les règlements d'exécution, les REX et les règlements délégués, les RED. Voilà. Alors là, dans le CRA, il y en a un prévu toutes les trois pages. Si vous prenez 180 pages, tout est à la main. les listes, le détails. état et des évolutions. Tout, tout, tout est à la main de Bruxelles. La main de Bruxelles, de la commission de Bruxelles. Donc des fonctionnaires de Bruxelles qui pourront faire évoluer tout ça de manière quasi autonome. Donc ça va pas mal négocier avec l'écosystème, on sait comment ça se passe quand même aujourd'hui, parce que la commission, moi j'accuse pas Bruxelles d'autocratie, mais c'est juste qu'à un moment, si on veut que ça marche avec 27 états membres, il faut bien qu'il y ait quelqu'un qui fasse le job et qui prennent cette responsabilité. et après tout le monde peut attaquer les décisions de Bruxelles en justice, on est dans des états de droit voilà, mais c'est pour dire que tout ça n'est pas figé, d'ailleurs il y a déjà un premier règlement délégué ou d'exécution qui est en cours de rédaction pour appel public à commentaires sur les produits importants ou les produits critiques nous y venons dans un instant ou dans l'épisode 8 de ce podcast qui s'avère détaillé Un petit détour, juste pour lister ce qu'il va y avoir dans la documentation technique obligatoire. Donc le tronc commun, pour tout le monde, lequel peut être audité quand on est procédure module B plus C, ou module H, ou probablement les schémas de certification. Qu'est-ce qu'on va mettre dans la documentation technique ? Donc il y a huit points obligatoires. Donc, description générale du produit, logiciel connecté, dont les instructions pour l'utilisateur. Description de la conception, du développement, de la fabrication et des processus de gestion des vulnérabilités. Donc, je le redis là aussi, la documentation technique, elle sera interne à l'entreprise non publique, sauf si l'entreprise décide de la rendre publique. Je pense qu'on est tranquille pour un moment là-dessus. Et par contre, c'est full access de la part des autorités de contrôle. Donc en fait, ils arrivent, comme aujourd'hui le registre des traitements pour les entreprises pour l'ACNI, l'ACNI arrive, ils commencent par demander le registre. Voilà, c'est comme ça. Et là, ce sera pareil. Donc, description de la conception, du développement, de la fabrication et des processus de gestion des vulnes. 2 sur 8. 3 sur 8. Évaluation des risques cyber. Voilà, c'est là où on voit que, comme Dora, comme NIS2, on fait du risque. La politique de cybersécurité passe par une évaluation des risques de manière ultra classique. Produit par produit, service par service.

• Speaker #0

  Avec un point important quand même, parce que tu as tout à fait raison, dans l'approche effectivement on parle plus de risque d'abord, mais tu as quand même cité le contrôle des process de développement. Et ça c'est quelque chose d'assez important parce que parler des risques c'est une chose. Mais comment les mitiger ? Comment s'assurer que le process n'en crée pas des nouveaux ? Comment contrôler ce qu'on fait sur le fond ? Parce que c'est un peu la clé des cybersécurités. Ce n'est pas le tout d'être super bon pour corriger des vulnérabilités, mais c'est peut-être encore mieux de ne pas en créer. Du coup, il faut avoir quand même un petit peu de contrôle de ces process de développement, entre autres.

• Speaker #1

  Ça, c'est quand même assez nouveau,

• Speaker #0

  finalement.

• Speaker #1

  Software, secure, development, lifecycle, SSDLC. Mais c'est cité dans Nice 2, développement sécurisé. Dans Dora, probablement, j'ai un peu oublié. Mais en fait, on va en arriver à ça. Parce que si on a un produit qui est conçu dès le départ pour être une passoire, le produit est conçu en dépit du bon sens et on passe son temps à patcher. OK, je peux t'envoyer des mises à jour de sécurité. Enfin, moi, j'utilise Signal quand même. Signal, c'est une mise à jour de sécurité tous les trois jours. Bon, on prend l'habitude de le faire. On a envie de dire à un moment, c'est quand même curieux. j'en veux pas à ce qu'il y a un mois que j'utilise beaucoup mais bon revenons à nos points obligatoires de la documentation technique qui nous passionnent déjà tous donc 3 évaluation des risques cyber 4 information sur la période d'assistance du produit alors là c'est simple en clair c'est minimum 5 ans voire en général minimum 10 ans donc ça veut dire viabilité du produit logiciel pensé sur au moins 5 voire 10 ans de base La période la plus longue des deux étant retenue, comme toujours dans les trucs de l'UE. Donc, à un moment, il va falloir… Ce n'est pas « tiens, je t'ai développé trois trucs, poum, je m'arrête, merci, au revoir » . Genre, les logiciels dont on nous annonce que le cycle va s'arrêter au bout d'un moment, il faudra peut-être faire des migrations. J'ai pensé à un identitaire américain assez connu qui commence par un W, mais je ne sais pas. Bref. Bon, le 5, c'est la liste des normes harmonisées, les normes appliquées. ou présentant des solutions adoptées, des trucs UE, certification, machin. Par contre, 6 sur 8, rapport des essais effectués, il va falloir mettre les rapports dans la documentation technique. Il va falloir dire, on a fait des tests, ça a marché, il va falloir l'écrire. En fait, il faut tout documenter. Après, on dit qu'on fait, on ne fait pas, on fait du risque, on fait très bien, mais on documente et on arrête les trucs bidons. Bref, le 7. Copie de la déclaration CE de conformité, c'est une attestation qu'on se fait à soi-même à peu de choses près. Huit, dans la documentation technique, la nomenclature des logiciels. La fameuse nomenclature des logiciels. J'essaie de retrouver les points de la documentation technique, les exigences. J'essaie juste de retrouver. Les instructions utilisateurs, il y en a plein, c'est compliqué. donc on va passer ce grand moment. Je cherche la nomenclature des logiciels que je ne retrouve pas. Attends, je fais juste un break parce qu'il faut que je te retrouve la nomenclature des logiciels parce que c'est quand même le truc. Et comme je n'ai pas fait ça de manière séquentielle, moi-même, pour que ça rentre, la liste des normes appliquées, la copie des nomenclatures des logiciels. Ah, voilà, je l'ai. Alors, la nomenclature des logiciels. Donc il y a une définition légale pour ça. Article 339 de Dora, c'est un document officiel contenant les détails et les relations avec la chaîne d'approvisionnement des différents composants

• Speaker #0

  logiciels utilisés dans la fabrication d'un produit CERA. Bah, jusque-là, ça surprend pas trop. Alors, donc, ça veut dire nomenclature obligatoire des logiciels embarqués, avec des détails dans les considérants de partout. Blablabla, j'en passe tellement, il y en a. Un acte d'exécution prévu par la commission de Bruxelles, et un deuxième pour les produits importants. qu'est-ce qu'on peut dire voilà qu'est-ce qu'il dit encore en fait il y en a de partout il y a la documentation utilisateur pareil il faut prévoir des trucs mais je pense que là maintenant le dernier truc qui est vraiment utile à retenir du CRA sans que Mamie s'endorme complètement c'est la liste des produits importants et la liste des produits critiques parce que c'est là où on comprend qu'il y a le tronc commun, entre guillemets, et puis il y a les produits importants et critiques. Alors, ne me demandez pas pourquoi il y a la classe 1 et la classe 2 dans les produits importants. Dans la classe 1, c'est les produits importants classe 1, donc c'est l'annexe 3 classe 1, 19 produits importants. Tu vas voir, on va les parcourir, il y en a qu'on comprend bien, c'est soit matériel, parce que c'est tourné matériel, soit c'est logiciel. Par exemple, 1 sur 19, système de gestion d'identité et système de gestion des accès privilégiés, dont lecteur d'authentification et de contrôle d'accès et lecteur biométrique. Donc là, on voit matériel, logiciel. Donc ça, c'est le 1. Le 2, les navigateurs autonomes et intégrés. Donc ça, c'est du pur logiciel. 3. Les gestionnaires de mots de passe. C'est du logiciel. En fait, on comprend encore mieux toute la philosophie du CRA quand on attaque la liste et qu'on voit qu'il y a des trucs. C'est du logiciel pur et dur. 4 sur 19. Logiciels qui recherchent, suppriment ou mettent en quarantaine des logiciels malveillants.

• Speaker #1

  Juste une question qui me vient à l'éclat, surtout pour les gestionnaires de mots de passe. T'as dit en introduction que... c'était des logiciels qui étaient connectés. Que dans la définition même du champ d'application du CRA, il fallait que dans le fonctionnement du logiciel, il y ait une connexion qui se fasse avec l'extérieur pour qu'on considère que ce soit un logiciel connecté. Là, on parle d'un logiciel de gestion de mot de passe. On peut parfaitement avoir un logiciel de gestion de mot de passe qui ne soit pas connecté.

• Speaker #0

  Oui, c'est vrai. Mais il est produit important.

• Speaker #1

  D'accord. En fait, quand c'est une espèce, on ne va pas dire d'entourloupe, mais... Un peu une liste arbitraire quand même de softs qui sont sans fait être un peu...

• Speaker #0

  C'est moi qui dis logiciel, connecté avec ou sans matériel. Mais en fait, c'est pour ça qu'il faut aller... Attends, le 5, produit avec logiciel, avec la fonction de VPN. C'est pareil, le VPN, il va servir à faire la connexion en lui-même. Le VPN, est-ce qu'il est connecté ? Pour moi, si c'est un client VPN, oui. Il va falloir qu'il soit connecté pour remplir le service. Mais la fonction VPN, or ils disent bien, avec la fonction de VPN. Donc, il y a plein de trucs qui sont connectés, sauf quelques trucs qui sont critiques pour le fonctionnement de l'ensemble, en fait. Je pense que c'est ça le fond de la philosophie. Mais je rappelle la définition, c'est des produits comportant des éléments numériques, quand même. C'est ça, la base de la définition. Et quand on va voir dans les annexes, on se dit que ça va vachement au-delà. En fait, c'est toute la partie, en fait, c'est l'infrastructure là aussi

• Speaker #1

  C'est ça, c'est les composants critiques d'un point de vue cybersécurité qui peuvent être...

• Speaker #0

  Important. Pas encore critiques. Parce qu'il y avait... La liste, donc là, on en est à... Donc VPN, on en est à 5 sur 19. Et les critiques arrivent. Système de gestion de la qualité. Ça, je ne sais pas ce que ça veut dire. Système de gestion de la qualité. Bon. Système de gestion des informations et des éléments de sécurité, entre parenthèses, SIEM. 8. Gestionnaire de démarrage 9. Infrastructure à clé publique et logiciel d'émission de certificats numériques Interface réseau physique et virtuel

• Speaker #1

  10 sur 19

• Speaker #0

  Système d'exploitation 11. Un OS voilà t'as un OS tu le mets dans du matériel Ton matériel est connecté, puis ton OS, déjà, lui, il est produit important. Donc, il va être soumis à la totale plus le contrôle du tiers, procédure module B plus C ou module H ou le CMN certification. Voilà. Donc, c'est pour ça que les listes, c'est vraiment ça. Donc, système d'exploitation. Ensuite, nous avons routeur modem. destinés à la connexion à l'Internet et commutateurs. Là, on est à 12 sur 19. 13 sur 19. Microprocesseurs dotés de fonctionnalités liées à la sécurité. Voilà, et on a le mot sécurité qui revient. C'est tout à fait ce que tu disais. Microcontrôleurs dotés de fonctionnalités liées à la sécurité. Il paraît que quand il n'y a pas un processeur, il y a des microcontrôleurs. Voilà, mais je n'ai pas bien compris, mais je suis d'accord. Ensuite, nous avons en 15 sur 19, nous avons les ASIC et les FPGA. Je le fais en version telle que ça écrit, donc des circuits intégrés spécifiques à l'application ASIC et réseau de portes programmables FPGA dotés de fonctionnalités liées à la sécurité.

• Speaker #1

  En fin de compte, dès que quelque chose, matériel, logiciel, est de près ou de loin lié à la sécurité, ça tombe dedans.

• Speaker #0

  Donc, ça va être... tu fais ton bazar et en plus tu te fais contrôler par un tiers. 16 sur 19. Assistant virtuel polyvalent pour maison intelligente. On se demande qui ça vise. Ensuite, nous avons les trois derniers, c'est assez rapide. Produits domestiques intelligents dotés de fonctions de sécurité, notamment serrure, caméra de sécurité, système de surveillance pour bébés et système d'alarme. Je cite.

• Speaker #2

  Ça,

• Speaker #0

  c'est 17. 18. Jouets connectés. Et 19, produits portables personnels destinés à être mis sur un corps humain à des fins de surveillance de la santé. Ou produits portables personnels destinés à être utilisés par et pour des enfants, avec des exceptions sur des directives qui existent déjà et des règlements de 2017 et de machin et truc. Voilà. Ça, c'est les produits importants classe 1. Et ce qui est bien... quand on s'intéresse au CRA, c'est que pour les produits importants classe 1, ce qu'il faut faire, c'est le module A, donc c'est contrôle interne, toute la procédure d'autocertification, plus module B, contrôlé par un tiers, plus module C, fabrication autocontrôlée. Ça, c'est les produits importants classe 1. Car la procédure n'est pas la même pour la liste des produits importants classe 2. Et il n'y en a que 4, mais les 4 méritent d'être cités. Nous avons d'abord, donc là on est, heureusement que j'ai des stars, sinon je n'y arriverais pas, parce que c'est infernal. Donc là, nous sommes dans la classe 2 des produits importants, il y en a 4. Premier sur les 4, hyperviseur et système d'exécution de conteneurs prenant en charge l'exécution virtualisée de systèmes d'exploitation et d'environnement similaires.

• Speaker #1

  Bon, ça c'est les ESX et puis... Tout ce qui est Kubernetes, entre autres. Tout ce qui fait tourner l'infrastructure d'une entreprise.

• Speaker #0

  Les hyperviseurs. Deux sur quatre. Par feu, système de détection et de prévention des intrusions.

• Speaker #1

  Ok.

• Speaker #0

  Et alors là, on a trois ou quatre, enfin, trois et quatre, ces microprocesseurs résistants aux manipulations. Au départ, dans la première version, c'était marqué inviolable. C'est temper resistant, en anglais. Bon, alors, inviolable, ils ont arrêté parce que rien n'est inviolable. Donc, c'est devenu résistant aux manipulations. Donc, c'est microprocesseur et on a pareil pour microcontrôleur. Que l'on trouve dans la classe 1, microprocesseur, microcontrôleur. Mais les microprocesseurs et les microcontrôleurs en eux-mêmes sont des produits importants classe 2. Et donc, quand on est produit important classe 2, alors là, c'est l'enfer. Parce qu'on a le choix. Enfin, c'est l'enfer quand on a le choix. Donc, on fait soit option 1. C'est pour ça que ça en laisse naïve et des mémos, ce n'est pas possible. Alors, on est bien sur les produits importants classe 2, donc les quatre produits importants classe 2. Soit on fait contrôle interne plus module B avec contrôleur agréé plus module C, fabrication autocontrôlée. Soit on fait contrôle interne, toujours le cas commun, la doc, le machin, et on fait un système de qualité approuvée. selon le module H. Ou alors, troisième option, on fait son contrôle interne et on va appliquer un schéma de certification UE, mais uniquement à partir du niveau substantiel. Car tous les schémas de certification UE qui existent depuis ADAS, c'est toujours niveau simple, niveau substantiel et niveau qualifié étatique. Niveau substantiel, c'est niveau entreprise. C'est là où les Allemands poussent beaucoup. toujours quand il y a ces discussions européennes pour qu'il y ait un truc qui soit adoptable par le business sérieux, le B2B machin et le niveau ça c'est les allemands en général qui poussent beaucoup à ça et nous les français souvent s'accrochent beaucoup au niveau régalien le niveau plus plus le niveau 3, niveau 1, l'email tout pourri, niveau 2, c'est un peu signé, et niveau 3, c'est signé de manière très forte. Donc, substantiel, qualifié. Là, il faudrait que ce soit au moins du substantiel. Là, nous étions, je le répète, Mamie vient de partir. Elle a cliqué la porte, elle est partie. Et pourtant, le meilleur arrive. Alors, bien sûr, la commission adopte des actes d'exécution au plus tard le 11 décembre 2025. sur les catégories, la description technique des classes 1 et 2, figurant à l'annexe 3, produits importants. Et puis, ah oui, projet de Rex, CRA, publié le 6 février 2025. Donc, voilà, ça arrive. Bien sûr, une fois qu'on dit à tout le monde faites votre autocertification, documentez, machin, ça, ça va être, je ne sais pas moi, 70%, je dis n'importe quoi des produits. Et puis, on voit bien que dès que ça va être important ou critique, là... Là, l'Union européenne va s'agiter parce que c'est le cœur qui permet de faire fonctionner le reste. Comme tu l'as dit, c'est les fonctions de sécurité. Et maintenant, il nous reste un dernier truc à voir. Ce sont les produits critiques. Avant de partir, Mamie m'a dit, mais qui sont donc les produits critiques ? Ils sont trois. Alors, les produits critiques. Le premier est assez évasif. Ça s'appelle les dispositifs matériels avec boîtier de sécurité. Voilà, ça manque un peu de détails. Mais c'est critique. Donc, on sent qu'on ne va pas rigoler. Dès qu'on met le mot critique, on sent que ça ne rigole pas. Donc, ça, c'est le premier. Alors, le deuxième, il paraît que c'est un truc qui nous vient d'Allemagne. Alors, je cite. Certificat passerelle pour compteur intelligent au sein des systèmes intelligents de mesure et autres dispositifs à des fins de sécurité avancées, y compris pour un traitement cryptographique sécurisé.

• Speaker #1

  Oh, vache.

• Speaker #0

  Moi, je propose qu'on passe directement au 3, qui se comprend beaucoup mieux. Donc, 3 produits critiques. Le 3, carte à puce ou dispositif similaire, y compris des éléments sécurisés.

• Speaker #1

  Je pense qu'en réalité, ils font référence à tous les équipements qu'on utilise pour accélérer le chiffrement, par exemple, puisqu'on va utiliser, par exemple, des boîtiers qui sont câblés pour gérer, par exemple, du chiffrement plus rapidement. Et ça va accélérer, par exemple. le HTTPS entre autres, ou alors pour y rendre plus transparent le chiffrement de certaines données, des choses comme ça, ou dans certains cas. Je pense que ce sont ces équipements-là qui sont visés, parce qu'effectivement, ce sont des équipements qui sont très critiques dans le monde de la cyber, évidemment. Par contre, il y a quand même un absent, alors je ne sais pas si c'est volontaire ou pas, ce n'est pas directement lié à des composants de... entre guillemets de cybersécurité, mais il parle beaucoup des processeurs, des microcontrôleurs, mais il ne parle pas des GPU. Et pourtant, les GPU, c'est quelque chose qui devient de plus en plus important avec l'IA, et c'est étonnant que ça ne fasse pas partie de la liste, parce que je n'ai pas l'impression que ce soit réglementé. Ben,

• Speaker #0

  voilà. Alors, en fait, je vais botter en touche, d'abord, j'en sais absolument rien, évidemment, j'ai des limites à ma capacité de mentir. La seule bonne nouvelle, je suis en train de voir qu'à l'article 8, point 1 du CRA, il est dit que la Commission européenne est habilitée à adopter des actes délégués pour compléter le CIR afin de déterminer quels produits dont la fonctionnalité de base figure à l'annexe 4 produits critiques, doivent être tenus d'obtenir un certificat de cybersécurité européen au minimum au niveau d'assurance substantielle. Alors ça, c'est l'article 8.1 et l'article 8.2 nous précise en plus C'est l'article 8 de 2. La commission est habilité à adopter des actes délégués pour ajouter et retirer des catégories de produits critiques. Ce qui était déjà prévu pour les produits importants de classe 1, pour les produits importants de classe 2, y compris ce qu'il faut mettre dedans, la liste, etc. En fait, voilà, c'est bienvenue dans le cerf. Qu'est-ce qu'on peut dire de plus ?

• Speaker #1

  Eh bien, ma foi, pas grand-chose. Ce que je comprends, c'est que... Tous les fournisseurs de produits de sécurité ou de composants de sécurité, que ce soit des firewalls ou autres, les fabricants de CM, etc., vont devoir largement montrer patte blanche, ce qui n'est pas plus mal en matière de cybersécurité. Ce serait quand même dommage d'avoir des failles justement sur les équipements qui sont censés nous protéger. Mais au-delà de ça, aussi une grande prise de conscience pour tous les fournisseurs européens de logiciels, puisqu'ils vont devoir... clairement démontrer leur capacité à gérer les aspects de cybersécurité dans les produits qu'ils vont fournir. Tu citais le SDLC par exemple. mais aussi tous les processus qui permettent de mettre en production des outils qui sont sécurisés. Et puis il y a aussi le build of material, le fait de pouvoir tracer depuis le fournisseur jusqu'au produit fini, l'entièreté de la chaîne d'approvisionnement et pouvoir identifier tous les composants. Ça, effectivement, c'est quelque chose d'assez nouveau. Enfin, en tout cas, dans certains cas, évidemment, certaines entreprises le maîtrisent déjà, mais c'est... quand même pas le commun des mortels, entre guillemets, qui est capable de gérer ça, on va dire, à top de box.

• Speaker #0

  Moi, ce que je tiens pour conclusion, c'est que d'abord, il va falloir agir de manière extrêmement professionnelle et que les très petits éditeurs, dès qu'on veut faire du mode SaaS, machin, j'ai un de mes clients qui me dit, non, mais moi, mon logiciel était on-prem, et puis maintenant, je l'ai transformé en SaaS, mais c'est mon logiciel on-prem. Oui, oui, il y a un logiciel en mode SaaS. on peut partir d'une version on-prem sûrement, mais de toute façon il est nécessairement adapté pour fonctionner en mode SaaS sinon on claquerait tous des doigts et on le ferait tous tout de suite, donc dès que j'ai les portées et puis dès qu'il va être on-prem et qu'il va être connecté quelque part dans le réseau d'entreprise, boum il va tomber aussi, donc ce qui veut dire quand même qu'il va y avoir mécaniquement alors dans un délai que je ne maîtrise pas parce que c'est bien de dire que ça s'applique oui comme d'oral le 15 janvier 17 janvier, ok on met des abacs pour commencer à pousser tout le monde. C'est sûr que le temps que tout le monde se mette au carré, si on prend l'exemple de Dora, on sait que les mutuelles, notamment, surtout en France, je parlerais bien de ce que je connais, les autorités de contrôle ont compris que c'était une catastrophe nationale. Les mutuelles qui n'y comprennent rien, qui n'ont pas un radis ou qui ne veulent pas mettre un radis dedans et qui découvrent que Dora va peut-être exister aujourd'hui. Bref, là, ça va être pareil pour le Serra. Donc, ça va quand même écluser un certain nombre d'éditeurs qui faisaient des petits produits comme ça, qui partaient bloup, bloup, bloup. et puis et puis tout le système des... On ne veut pas particulièrement aux Chinois avec leur caméra vidéo, mais connectés. On voit bien quand même que les boîtes nettes, ça allait jusque-là. Donc à un moment, soit on met une barrière à l'entrée avec des normes techniques qu'il va falloir faire contrôler. Dès que ça va être de la fonction de sécurité, on va imposer un contrôle par un prestataire qui va falloir payer. Et je sais que là, les prestataires sont en train de... Ceux qui voient des contrôleurs, entre guillemets, ce ne sont pas des organismes agréés, ce sont un nom dans le serre. À un moment, c'est un langage administratif qui est dur à suivre. Mais là, les laboratoires de contrôle sont en train de se mettre en ordre de bataille. Déjà, c'est comme ça qu'on arrive à avoir un peu des informations sur ce que dit l'ENISA, ce que pense l'ENISA et ce que veut l'ENISA. Et d'ailleurs, on assiste aujourd'hui, que ce soit via NIS2 ou via le CERA, on assiste à une montée en puissance phénoménale de l'ENISA qui va devenir vraiment la coordinatrice. Et puis, on voit avec le problème du... des CVE aux Etats-Unis où tout d'un coup Trump a dit qu'il coupait les crédits moins de 24 heures après les crédits intervenus pour un an derrière on est en train de reparler de la fameuse EUVD EU Vulnerability Database qui va être organisée enfin qui est en train d'ailleurs elle est en version bêta, elle est accessible en ligne et bien peut-être qu'on va avoir aussi les vulnes qui vont toucher les produits CRA dans une seule et même base de données géante Voilà, et il est temps que l'Union européenne se réveille, donc ça veut dire du budget pour l'ENISA, ça veut dire qu'à un moment il va falloir faire des infrastructures de remontée de data pour l'ENISA, et de redescente, parce que c'est bien que l'ENISA ait de la data, mais il faut la partager avec les opérateurs concernés, le besoin d'en connaître, patati patata. Donc là il y a un travail de fond, on est parti pour, objectivement, on est parti pour des années, jusqu'à ce que l'UE fasse son système à elle. et qu'elle contrôle ce qui arrive sur son territoire. Je rappelle, mine de rien, que le marché européen, on est 450 millions. Et nous, les 450 millions d'Européens, on a le plus haut niveau de vie rapporté par habitant. Les Américains, ils ne sont que 330 millions. Ils parlent la même langue, ils ont un super territoire très étendu. Mais en termes de pouvoir consommateur, ils sont moins importants que nous. Les Russes, on n'en parle même pas, à part faire la guerre, ils ne savent rien faire. Et tricher aussi. Bref. Il y a les Chinois, effectivement, ils sont très nombreux. On parle d'un milliard trois d'habitants, dont 700 millions auraient dépassé un niveau de vie entre guillemets acceptable pour les standards européens. Mais on reste le plus gros marché, aujourd'hui le plus mature au monde, c'est l'Europe. Donc soit l'Europe s'empare de ce problème des vulnes, parce qu'on voit que les Chinois, c'est quand même de notoriété publique depuis bien 15 ans, c'est espionnage à volonté, cyber-espionnage. C'est l'exploitation des vunes. Eux, c'était surtout pour faire de l'espionnage. Secrets industriels, patati patata. Prépositionnement, bien sûr. Donc, on voit bien que si du... Et moi, c'est un discours qui est très militant de mon côté, je ne m'en cache pas. Si l'UE ne s'agite pas un peu pour nous protéger, nous les pros, et nous les consommateurs, dans ce réservoir d'une immense richesse, en réalité, on va finir par se faire trouver et par mourir. Donc la réponse de l'UE, c'est le module A, et le module B et le module C, et le module H et les schémas de certification. Et comme on est des États de droit, il faut tout écrire. Et quand on fait des directives, Ce n'est pas assez détaillé. Tout le monde nous casse les pieds. C'est Nice 2. Et puis, dès que c'est extrêmement détaillé, c'est le CRA. Et là, tout le monde a envie de mourir. Mais comme on est 27 avec 17 langues et que c'est un peu technique, ça donne le CRA.

• Speaker #1

  Oui, mais il va falloir en passer par là, je pense.

• Speaker #0

  Au bout de 50 ans, il était temps. Je veux dire, l'industrie du médicament. Aujourd'hui, imaginons qu'on fabrique des médicaments et qu'on ne les teste pas avant. On ne va pas empoisonner un continent entier. Les avions qui tombent, il y en a très peu. On voit Boeing qui a quand même des problèmes depuis quelques temps, maintenant réguliers, cycliques. Nous, les Européens, c'est marrant, nos avions, il y en a qui tombent. Il y en a quand même très peu. Et je crois que le côté connecté des avions, j'ai bien compris, ça freine à fond. Parce que si on commence à connecter des avions… ça va être un vrai problème ou alors on segmente bien il y a des câblages qui partent il y avait un film qui était très intéressant pour ça c'était Boîte Noire avec le jeune qui a l'impression qu'il devient complètement parano à la fin et en fait il y a toute une histoire justement de bricolage d'un logiciel mal testé ok, on voit que c'est catastrophique puis il y a la série que je suis en train de regarder en ce moment qui est Cyber Attack sur Netflix, bon ça parle pas trop de technique Cyber Attack Mais on voit que tout d'un coup, les infrastructures qui lâchent les unes après les autres, on voit qu'il faut peut-être s'en soucier. Donc, la partie infra, c'est une isle de Dora. Et puis, la partie matérielle et logiciel, tu l'as dit très justement, logiciel de sécurité, soit logiciel connecté, soit logiciel de sécurité ou des éléments de sécurité. On va réglementer, on va surveiller à minima. Je rappelle quand même l'exigence numéro une dans les 13 exigences essentielles cyber. c'est que dedans, il n'y ait pas une vulnérabilité qui soit déjà massivement exploitée. Non, mais... Après la base. Mais voilà. Alors, il y a des trucs extrêmement techniques, développement, sécurisation, et puis il y a des trucs tellement de base, on a envie de dire, mais comment est-ce qu'on en est à commencer par ça ? Bon, il fallait l'écrire, il faut l'écrire. C'est écrit.

• Speaker #1

  Et voilà. Écoute, Marc-Antoine, encore un très grand merci d'avoir participé à ce podcast. J'espère que... Les auditeurs auront apprécié toutes ces informations. Et j'espère que pour ceux qui se sentent concernés, ils auront un petit peu d'avance en tout cas sur ce sujet, ô combien important qu'est le CR1. Et je pense qu'on est effectivement assez nombreux quand même à tout doucement s'en préoccuper, parce que mine de rien, le temps avance. Et tu as très bien dit, il y a quand même tout un ensemble de choses à réaliser et l'anticipation est quelque chose de primordial. Voilà, le mot de la fin peut-être Marc-Antoine ?

• Speaker #0

  Le mot de la fin c'est qu'aujourd'hui, là on est en train de découvrir le CERA, et tout le monde se dit mais qu'est-ce que je vais devoir faire et qu'est-ce que je vais devoir écrire ? Et moi sur mon aspect juriste je me dis bon là-dessus il n'y a pas grand-chose à faire, et je vois déjà, parce que j'ai eu une demande déjà qui est arrivée, je le guettais mais elle est arrivée juste bien, c'est dans les contrats B2B, c'est vraiment toi tu es éditeur de solutions de sécurité, annexe 1, 3,8, procédure H, machin, et bien Tu vas me mettre dans une annexe à moi, tu vas me résumer. Tu vois les 13 exigences et les 8 exigences, machin. Là, tu vas me les résumer. Tu auras fait ta doc et tout. Mais on ne va pas annexer la doc au contrat. Donc, on va faire un bel avenant, on va prendre les points essentiels, puis tu vas me dire ce que tu n'as pas fait et tu vas me dire ce que tu as fait. Et là, ça y est, j'ai eu la première demande d'un avenant CERA spécial B2B. Genre, tu veux me fourguer ça ? Eh bien, tu vas m'écrire que ça, ça, ça, éventuellement avec une roadmap parce qu'on n'est jamais qu'au mois de... Au mois d'avril 2025, je suis obligé de regarder mon agenda pour me souvenir de l'année, tellement je n'arrête plus avec tous ces textes. Et il va y avoir une montée de la partie vraiment purement B2B, parce que quand on est une banque ou une institution financière et qu'on va avoir des produits de sécurité, on va faire écrire à l'éditeur ou au prestataire que tu fais bien ça, tu fais bien ça, tu fais bien ça. Voilà, parce que ça, ça va s'intégrer dans mon infra, dont moi, moi, entité financière, je suis responsable. vis-à-vis de mes clients et redevables vis-à-vis des autorités de contrôle. Donc, il va y en avoir pour tout le monde. Ça va être un régal. Voilà, la barrette.

• Speaker #1

  Parfait. écoute voilà c'était le mot de la fin bon courage à vous si vous devez traiter le CAA mais avec un peu d'organisation de méthode tout se passera bien je mettrai bien sûr toutes les slides de

• Speaker #0

  cette synthèse quand tu publieras ton épisode il y aura la synthèse vraiment qui sera en ligne et après tout le détail j'en suis déjà au moins à 10 épisodes très détaillés en BD avec les considérants et tout n'hésitez pas vraiment c'est en libre accès allez-y C'est très, très détaillé. Vraiment, allez-y. N'hésitez pas. Et puis, allez lire sur le site de l'Union européenne, le CERA. Commencez toujours par les articles, terminez par les considérants. Garde le meilleur pour la fin.

• Speaker #1

  Très bien. Écoute, merci pour ton conseil. Et comme je le dis souvent, pour certains, la cybersécurité est un enjeu de vie ou de mort. c'est bien plus ça avec ça