Les exigences de l'ARC sont documentées dans l'Annexe I du règlement. Les équipes de test doivent savoir comment appliquer ces contrôles aux systèmes de test. Le règlement européen sur la cyberrésilience est largement documenté dans une série de publications disponibles sur european-cyber-resilience-act.com/. La législation est décrite dans 57 articles. Bonne nouvelle : les exigences techniques sont principalement décrites dans l'Annexe I.
Les exigences de l'ARC de l’UE sont principalement définies à l'Annexe I. Il existe également quatre documents annexes supplémentaires :
Le Centre commun de recherche (CCR) de l’UE et l’Agence de l'Union européenne pour la cybersécurité (ENISA) ont publié un document décrivant la mise en correspondance des exigences de l’ARC par rapport aux normes industrielles existantes, notamment la norme IEC 62443. Ce document (accessible gratuitement sur enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping) constitue un guide utile pour les entreprises ayant déjà adopté une de ces normes.
L'Annexe I est divisée en deux sections. La section 1 porte sur les propriétés des produits et la section 2 porte la manière dont un fournisseur doit gérer l’identification de vulnérabilités.
(1) Les produits comportant des éléments numériques sont conçus, développés et fabriqués de manière à garantir un niveau de cybersécurité approprié en fonction des risques.
(2) Les produits comportant des éléments numériques doivent être mis à disposition sur le marché sans vulnérabilité exploitable connue ;
(3) Sur la base de l’évaluation des risques de cybersécurité visée à l’article 10, paragraphe 2, les produits comportant des éléments numériques doivent, le cas échéant :
a) être mis à disposition sur le marché avec une configuration de sécurité par défaut, y compris la possibilité de réinitialiser le produit à son état d’origine ;
b) assurer la protection contre les accès non autorisés par des mécanismes de contrôle appropriés, y compris, mais sans s’y limiter, par des systèmes d’authentification, d’identité ou de gestion des accès et signaler tout accès non autorisé ;
(c) protéger la confidentialité des données stockées, transmises ou traitées de toute autre manière, à caractère personnel ou autres, par exemple en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes de pointe et par d’autres moyens techniques ;
(d) protéger l’intégrité des données stockées, transmises ou traitées de toute autre manière, à caractère personnel ou autres, des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l’utilisateur et signaler les corruptions ;
e) ne traiter que les données, à caractère personnel ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité prévue du produit comportant des éléments numériques (minimisation des données) ;
f) protéger la disponibilité des fonctions essentielles et de base, notamment après un incident, y compris par des mesures de résilience et d’atténuation face aux attaques par déni de service ;
g) réduire au maximum les répercussions négatives générées par les produits eux-mêmes ou par les appareils connectés sur la disponibilité des services fournis par d’autres dispositifs ou réseaux ;
h) être conçus, développés et fabriqués de manière à limiter les surfaces d’attaque, y compris les interfaces externes ;
(i) être conçus, développés et fabriqués de manière à réduire les répercussions d’un incident, en utilisant des mécanismes et des techniques appropriés de limitation de l’exploitation de failles ;
j) fournir des informations relatives à la sécurité en enregistrant et en surveillant les activités internes pertinentes, y compris l’accès ou la modification des données, des services ou des fonctions ;
(k) être conçus de façon à ce leurs vulnérabilités puissent être corrigées par des mises à jour de sécurité, y compris, le cas échéant, par des mises à jour automatiques de sécurité régulières et par la communication aux utilisateurs des mises à jour disponibles.
Si vous développez un système de test soumis à ces exigences, vous devrez adopter un processus de développement qui répond à la première exigence. Il existe plusieurs frameworks de développement de sécurité, notamment le processus SDL (Microsoft Secure Development Lifecycle) et le US Government Secure Software Development Framework documenté dans le Cadre NIST 800-218. Bien qu’ils ne soient pas développés pour des systèmes de test ou des produits comme LabVIEW ou TestStand, ils contiennent des principes généraux qui s’appliquent à l’ensemble des développements de système. Vous pouvez les utiliser pour créer un processus conforme aux exigences de l'ARC pour votre équipe.
En planifiant les caractéristiques de votre système de test, vous devrez tenir compte des exigences supplémentaires de l’ARC. Vous devrez planifier le contrôle de l’accès au système de test, tant par les utilisateurs que par les systèmes externes. Vous devrez identifier les données devant être protégées par cryptage, ainsi que les modalités du cryptage. Vous devrez développer des défenses contre les attaques. Vous devrez documenter l'activité dans des journaux d'audit. Enfin, vous devrez planifier les mises à jour de sécurité des composants du système.
Ce travail entraînera une charge supplémentaire pour votre équipe de développement, et vous devez examiner attentivement les coûts supplémentaires au cours des phases de planification de projet. Rapprochez-vous de votre client pour bien comprendre les options de sécurité et identifier les responsabilités concernant les mises à jour de sécurité du système après son déploiement.
Remarque importante : la sécurité doit être pensée au niveau du système. À eux seuls, les composants ne permettront pas de répondre à toutes ces exigences. Mais combinés avec d’autres composantes, ces écarts pourront être protégés afin de démontrer la sécurité totale du système.
Enfin, ne sous-estimez pas l’importance d’une documentation de sécurité exhaustive, ni le travail que cela requiert. Pensez à documenter la manière dont votre système répond aux exigences de l'ARC. Et prévoyez d’inclure la documentation liée à la restauration d’une configuration sécurisée de base : il s’agira d’une ressource critique en cas d’attaque entraînant la désactivation du système. De plus, cela permettra de s’assurer que les paramétrages système ne sont pas trop éloignés de cette configuration sécurisée.
Les fabricants des produits comportant des éléments numériques :
(1) recensent et documentent les vulnérabilités et les composants des produits, notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ;
(2) gèrent et corrigent sans retard les vulnérabilités qui touchent les produits comportant des éléments numériques, y compris par des mises à jour de sécurité ;
(3) soumettent régulièrement les produits comportant des éléments numériques à des tests et examens de sécurité efficaces ;
(4) dès la publication d’une mise à jour de sécurité, communiquent sur les vulnérabilités corrigées, en publiant notamment une description des vulnérabilités, des informations permettant aux utilisateurs d’identifier le produit comportant des éléments numériques concernés, les conséquences de ces vulnérabilités, leur gravité et des informations claires et accessibles aidant les utilisateurs à y remédier ;
(5) mettent en place et appliquent une politique de divulgation coordonnée des vulnérabilités ;
(6) prennent des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles de leurs produits comportant des éléments numériques ainsi que des composants tiers contenus dans ces produits, y compris en fournissant une adresse de contact pour le signalement des vulnérabilités découvertes dans les produits concernés ;
(7) prévoient des mécanismes de distribution sécurisée des mises à jour pour les produits comportant des éléments numériques afin de garantir que les vulnérabilités soient corrigées ou atténuées rapidement ;
(8) veillent à ce que, lorsque des correctifs ou des mises à jour de sécurité sont disponibles pour remédier à des problèmes de sécurité constatés, ils soient diffusés sans retard et gratuitement, et accompagnées de messages consultatifs fournissant aux utilisateurs les informations pertinentes, y compris sur les éventuelles mesures à prendre.
Vous devrez peut-être inclure une SBOM dans votre documentation système. Une SBOM répertorie tous les composants logiciels du système. Lors d’attaques récentes, les entreprises se sont lancées en urgence dans une recherche aux composants afin d’identifier les systèmes qui embarquaient les logiciels susceptibles d’être attaqués. Les SBOM permettent aux entreprises de tenir un inventaire des logiciels, de comparer cet inventaire aux problèmes signalés et de gérer les systèmes concernés.
La multiplication des SBOM permettra aux utilisateurs finaux de déterminer plus facilement les vulnérabilités de leurs systèmes. Les fournisseurs devront fournir fournir des mises à jour de sécurité plus fréquemment. L'ARC exige que des mises à jour soit fournies pendant cinq ans après la mise à disposition d'un produit ou d'un système. Votre équipe doit anticiper ce niveau de support.
Dans l’ensemble, les exigences de l’ARC amélioreront les défenses de sécurité des systèmes de test. Mais elles augmenteront également la charge de travail des développeurs système ainsi que leurs attentes envers des fournisseurs tels que NI.
Découvrez comment NI fournit les ressources permettant à votre équipe de répondre à ces attentes.