La première échéance prévue par le règlement « Cyber Resilience Act » est entrée en vigueur la semaine dernière. Le règlement «Cyber Resilience Act » (CRA) est la nouvelle réglementation européenne qui définit les exigences minimales en matière de cybersécurité pour tous les produits comportant des éléments numériques, y compris leurs composants (matériel et logiciel). Il s'applique à toute personne mettant des produits sur le marché de l'Union européenne, et pas uniquement aux entreprises qui y sont implantées.
L'ensemble des exigences n'entrera en vigueur qu'à la fin de l'année prochaine. Tous les produits comportant des éléments numériques vendus dans l'Union européenne devront se conformer aux exigences de sécurité de la CRA d'ici le 11 décembre 2027. Nous avons abordé plus en détail la CRA dans notre premier article de blog consacré à ce sujet.
Je suis de près l'évolution de cette réglementation depuis trois ans. Maintenant que la plateforme unique de déclaration (SRP) est opérationnelle, je souhaite vous faire part de mes premières impressions et dissiper certains idées reçues concernant la manière dont vous devez vous conformer aux exigences de l'ARC, afin que vous puissiez aller de l'avant en toute confiance.
Utilisation de la nouvelle plateforme unique de déclaration de l'ARC
Depuis le 11 septembre, les entreprises sont légalement tenues de signaler aux autorités de l'UE toute vulnérabilité activement exploitée ou tout incident grave dans les 24 heures suivant leur prise de connaissance. Vous pouvez effectuer cette déclaration via la nouvelle plateforme unique de signalement (SRP).
Le rapport initial (après 24 heures) est suivi d'une notification dans un délai de 72 heures, contenant des informations sur la menace et les mesures d'atténuation. Les organisations doivent soumettre un rapport final dans les 14 jours suivant la mise à disposition d'un correctif pour les vulnérabilités exploitées, ou dans un délai d'un mois à compter de la notification dans les 72 heures pour les incidents graves.
Pour l'instant, les seuls champs obligatoires du rapport initial sont les suivants :
- Type (vulnérabilité ou incident)
- Titre
- Résumé
- Nom du fabricant
- États membres dans lesquels le produit est disponible
- Nom du produit
- Version
Dans la rubrique « Produit », on vous demande également, de manière facultative, le type de produit (classification) et, bien sûr, vous pouvez ajouter plusieurs produits. Et voilà !
Le système de signalement volontaire sera mis en place lors d'une phase ultérieure ; il permettra à toute personne de signaler des vulnérabilités sans encourir de conséquences juridiques. En attendant, veuillez utiliser la plateforme uniquement pour les notifications obligatoires.
Vous trouverez ces informations et bien d'autres encore dans le manuel SRP de l'ARC.
Cyber Resilience Act démystifier les idées reçues
Chez Aikido Security, nous recevons de nombreuses questions concernant l'ARC et ses obligations en matière de déclaration d'incidents. Je vais ci-dessous apporter des précisions sur certaines des idées reçues les plus courantes que j'ai pu entendre.
Mythe n° 1 : nous devons signaler à l'ENISA toutes les vulnérabilités que nous détectons
Vous n'êtes en réalité pas tenu de signaler toutes les vulnérabilités que vous découvrez dans votre produit (bonne nouvelle !). Les seules vulnérabilités que vous devez signaler sont celles qui font l'objet d'une exploitation active à des fins malveillantes au sein de votre produit, ou celles liées à un incident grave affectant la sécurité de votre produit.
Ainsi, si vous découvrez une vulnérabilité dans votre produit, mais que vous ne disposez d’aucune preuve ni d’aucun indice indiquant qu’elle a été exploitée, vous n’êtes pas tenu de la signaler. En revanche, si vous apprenez qu’elle a été exploitée par un acteur malveillant, vous devrez la signaler. Je vous recommande donc de hiérarchiser les vulnérabilités en fonction de leur exploitabilité afin d’éviter qu’elles ne deviennent à l’avenir des événements devant être signalés.
Mythe n° 2 : le rapport final doit être remis dans les 14 jours suivant la découverte de la vulnérabilité
Ce n'est pas vrai. En réalité, les directives prévoient que le rapport final (concernant les vulnérabilités exploitées) ne doit être remis que 14 jours après la mise en place des mesures correctives. Beaucoup de gens interprètent cela comme un délai de 14 jours à compter de la date à laquelle ils ont découvert la vulnérabilité, puis paniquent face à une échéance qui n'existe pas. Cela vous laisse davantage de temps, car deux semaines, ce n'est pas réaliste pour certains produits !
Voici la chronologie complète :
- Dans les 24 heures, envoyez une alerte précoce. (« Il s'est passé quelque chose »)
- Au bout de 72 heures, envoyez une notification de vulnérabilité. (« Voici ce qui s'est passé. »)
- 14 jours après la publication d'un correctif pour les failles activement exploitées, envoyez le rapport final. (« Voici comment nous avons résolu le problème. »)
- Un mois après le délai de notification de 72 heures prévu pour les incidents graves, envoyez le rapport final. (« Voici comment nous avons géré l'incident. »)
Mythe n° 3 : Il suffit de signaler la vulnérabilité à l'ENISA, et le tour est joué
Malheureusement, ce n’est qu’une étape. En vertu de la CRA, vous devez effectivement signaler l’incident directement à la Plateforme unique de signalement (SRP), à laquelle ont accès à la fois votre CSIRT local et l’ENISA. Cependant, vous devez également informer les utilisateurs concernés par un incident des mesures correctives qu’ils peuvent mettre en œuvre pour atténuer l’impact de cette vulnérabilité. Selon la nature de l’incident, vous devrez peut-être informer l’ensemble de vos utilisateurs.
Mythe n° 4 : Nous devons nous inscrire sur la plateforme unique de déclaration maintenant qu’elle est opérationnelle
Non, vous n'avez rien à faire pour l'instant si vous n'avez rien à signaler. J'étais un peu dans le flou au début, mais le manuel d'utilisation m'a éclairé : l'ENISA recommande en effet aux entreprises de ne pas procéder à l'enregistrement préalable pour le moment.
Je craignais un peu que, si vous ne vous pré-enregistriez pas, vous deviez attendre la validation du CSIRT en cas d'urgence. Heureusement, ce n'est pas un problème. Un représentant autorisé (AR) peut envoyer des notifications même si la validation est encore en attente. La plateforme accepte jusqu'à 20 soumissions de la part d'utilisateurs non validés, ce qui permet à un maximum de 20 personnes d'une même entreprise de s'inscrire pour signaler des incidents.
Premières impressions et perspectives d'avenir
Mes premières impressions concernant le programme SRP de la CRA sont globalement positives. La vérification de mon compte en tant que véritable employé d’ Aikido (l’« association des représentants désignés ») a pris trois jours ouvrés au CSIRT belge. Cette vérification permet d’éviter que des trolls ne s’approprient le nom de votre entreprise avant vous.
La plateforme a connu quelques problèmes de déploiement le 11, mais tout était de nouveau opérationnel en quelques heures. Une fois la configuration effectuée, vous recevez une notification par e-mail dès que votre association est validée. Elle prend également en charge l’authentification par clé d’accès, mais je vous recommande vivement de configurer quelques appareils de secours pour éviter de vous retrouver bloqué.
À l'avenir, ce sont les normes harmonisées à venir qu'il faudra vraiment surveiller de près, car elles définissent les règles techniques concrètes permettant de fabriquer des produits conformes. Vous aurez tout intérêt à vous plonger dans ces projets dès que possible. Si vous ne le faites pas, vous risquez de concevoir des produits non conformes, ce qui entraînera par la suite des modifications coûteuses.
Ne manquez pas de vous pencher attentivement sur la norme EN 40000-1-1 (qui définit la terminologie) et la norme EN 40000-1-3 (qui établit les règles relatives à la gestion et à la divulgation des vulnérabilités). En vous familiarisant dès maintenant avec ces normes, vous prendrez une longueur d'avance considérable sur vos concurrents !
L'avenir de la Cyber Resilience Act
Cette échéance de septembre n'était qu'une première étape. Tous les produits comportant des éléments numériques vendus dans l'UE devront se conformer à l'ensemble des exigences de sécurité de la CRA d'ici le 11 décembre 2027. À compter de cette date, les produits non conformes ne pourront tout simplement plus être mis sur le marché européen, ce qui entraînera une perte directe de chiffre d'affaires pour les entreprises qui ne se seront pas préparées.
Pour les consommateurs, un étiquetage clair vous permettra de connaître la durée de la prise en charge et les caractéristiques de sécurité avant d'acheter un produit. Les produits devront également être sécurisés par défaut dès leur sortie de l'emballage et bénéficier de mises à jour gratuites garanties pendant au moins cinq ans.
Cela a pour effet secondaire de permettre à l’UE d’utiliser désormais l’ensemble des rapports de vulnérabilité pour développer l’EUVD (base de données européenne sur les vulnérabilités). Cela pourrait combler le vide laissé par la NVD du NIST, qui croule sous un retard colossal et a annoncé qu’elle ne procéderait plus à l’évaluation ni à l’enrichissement de chaque soumission CVE. Personnellement, je pense que cela est également lié au sentiment de plus en plus répandu selon lequel l’UE devrait devenir plus indépendante sur le plan technologique. Grâce aux données fournies par la CRA, l’UE a l’opportunité de créer sa propre base de données. À mesure que les soumissions se multiplieront, nous verrons si l’UE parvient à atteindre ces objectifs.
Pour l'instant, nous allons suivre de près l'évolution de ces systèmes et vous tenir informés des derniers développements.
Comment « Aikido » vous aide à respecter vos obligations envers l'ARC
Bien qu’aucun outil ne puisse se charger à votre place de vos déclarations à la CRA, nous surveillons le catalogue des vulnérabilités connues pour faire l’objet d’exploits (KEV) de la CISA. Cela signifie que le filtre « Exploit Status » (Statut d’exploitation) de votre flux « Aikido » ne sélectionne que les vulnérabilités pour lesquelles un exploit est connu dans la nature, et ce sont celles-là qui sont les plus susceptibles de provoquer un incident. Cela vous permet de les hiérarchiser et d’éviter les événements soumis à déclaration. Vous pouvez également consulter le score de gravité d'une vulnérabilité pour voir si la mention « activement exploitée dans la nature » figure parmi les facteurs contributifs. C'est un indicateur précoce qui vous permet de vérifier si vous avez été ciblé intentionnellement et si des obligations de déclaration s'appliquent.
Utilisez l'outil « CVE analyse de l’exploitabilité » pour découvrir comment une vulnérabilité CVE pourrait concrètement être exploitée dans votre base de code. Cet outil est utile pour établir des priorités et, si vous décidez finalement de signaler la vulnérabilité, pour décrire la nature technique de l'exploitation aux autorités de régulation et aux utilisateurs.
Même si l'ACR peut donner l'impression d'imposer davantage d'obligations à gérer, cela ne doit pas pour autant devenir un fardeau. Découvrez comment Aikido peut vous aider à respecter les exigences de l'ACR.
Vous pouvez également prendre rendez-vous par téléphone avec nous, et nous serons ravis de vous aider.
