La Commission européenne a dans sa ligne de mire les vendeurs et les vendeurs de technologies. Les consommateurs et les entreprises sont confrontés depuis trop longtemps à des logiciels et du matériel mal conçus, mal conçus et mal entretenus. Elle affirme que l’économie de la cybercriminalité est la principale bénéficiaire de ces échecs, dont la valeur, selon la commission, s’élevait à 5.5 4.7 milliards d’euros (2021 milliards de livres sterling) en XNUMX. L’ampleur du défi est énorme. Le nombre de nouvelles vulnérabilités logicielles rapporté par le gouvernement américain en 2022, a augmenté d’un quart par an pour atteindre 25,096 XNUMX – encore un autre record.
La réponse de l’UE est la Cyber Resilience Act (CRA). Bien qu'il soit encore en cours de finalisation, certains ont fait valoir que ses dispositions menacent la communauté open source et pourraient même rendre le monde numérique moins sûr.
Qu'y a-t-il dans l'ARC ?
L’ARC vise à protéger les consommateurs et les entreprises qui achètent des produits comportant une « composante numérique ». Il cherche à s'adresser deux défis majeurs :
- Les mauvaises mesures de cybersécurité intégrées à de nombreux produits, notamment les logiciels et les appareils connectés comme les babyphones intelligents, et/ou les mises à jour inadéquates des logiciels et des appareils.
- L’absence d’une « marque cerf-volant » à l’échelle du secteur qui pourrait aider les acheteurs de technologies à mieux comprendre quels produits sont sécurisés et comment les configurer en toute sécurité.
Dans cet esprit, le Objectifs de l’ARC à:
- Harmoniser les règles dans tout le bloc pour les fabricants et les détaillants développant/vendant des produits numériques
- Énumérer un ensemble strict d'exigences de cybersécurité « régissant la planification, la conception, le développement et la maintenance » de ces produits
- Obliger les fabricants/revendeurs concernés à assurer une obligation de diligence pendant tout le cycle de vie des produits numériques
- Déployer un nouveau marquage CE indiquant que les produits sont conformes à la CRA, incitant ainsi les fabricants et les détaillants à donner la priorité à la sécurité et permettant aux acheteurs informatiques de prendre des décisions plus éclairées.
Qu'est-ce qui est couvert et qu'est-ce qui est requis ?
Tel qu'il est, La législation « s’appliquera à tous les produits connectés directement ou indirectement à un autre appareil ou réseau, à l’exception d’exclusions spécifiées telles que les logiciels ou services open source déjà couverts par les règles existantes, ce qui est le cas des dispositifs médicaux, de l’aviation et de l’automobile ».
Ces produits sont répartis en trois catégories :
Valeur par défaut: Les produits à faible risque comme les jouets et réfrigérateurs intelligents, les jeux vidéo et autres logiciels et appareils couramment utilisés, qui, selon la commission, couvrent 90 % du marché. Les entreprises seront tenues de procéder à une auto-évaluation pour garantir qu'un produit répond aux normes de sécurité pertinentes.
Classe I: Produits à haut risque, notamment gestion des identités et des accès logiciel; navigateurs ; gestionnaires de mots de passe ; outils de détection de logiciels malveillants ; produits utilisant des VPN ; outils de configuration, de surveillance et de gestion des ressources de gestion de réseau ; systèmes de gestion des informations et des événements de sécurité (SIEM) ; outils de gestion des correctifs ; logiciels de gestion d'appareils et d'applications mobiles; logiciels d'accès à distance; microcontrôleurs; systèmes d'exploitation; pare-feu ; routeurs et modems ; équipement de contrôle industriel; et tout IoT industriel non couvert par la classe II.
Classe II: Produits à risque encore plus élevé que la classe I. Comprend certains systèmes d'exploitation ; pare-feu ; microcontrôleurs; routeurs et modems industriels ; commutateurs; cartes à puce et lecteurs; éléments sécurisés ; modules de sécurité matérielle; compteurs intelligents ; détection d'intrusion; composants de détection et d'actionneur de robot ; et les appareils IIoT utilisés par les entités décrites dans NIS 2.
Lorsque les mêmes types de produits sont répertoriés dans les classes I et II, le niveau correct sera décidé en fonction de facteurs de risque, par exemple si un produit fonctionne dans des environnements sensibles NIS 2, s'exécute avec un accès privilégié, est utilisé pour traiter des informations personnelles, contient une vulnérabilité. qui pourrait toucher une « pluralité » de personnes ; ou si cela a déjà provoqué des effets indésirables.
L'annexe I décrit les exigences de sécurité pour les fabricants de produits numériques. Ils devraient:
- Être conçu, développé et produit pour assurer un niveau de sécurité « approprié »
- Être livré exempt de vulnérabilités exploitables connues
- Être livré avec une configuration sécurisée par défaut
- Assurer la protection contre les accès non autorisés
- Protéger la confidentialité et l’intégrité des données personnelles et autres
- Traitez uniquement le minimum de données nécessaire
- Protégez la disponibilité des fonctions essentielles, par exemple contre les attaques DDoS
- Être conçu, développé et réalisé pour limiter les surfaces d’attaque et réduire l’impact des incidents
- Surveiller l'activité interne pour fournir des informations pertinentes liées à la sécurité
L'Annexe I fournit également une longue liste d'exigences en matière de gestion des vulnérabilités, notamment que les fabricants doivent documenter, traiter et corriger les vulnérabilités sans délai, tester régulièrement la sécurité des produits et divulguer publiquement les informations sur les bogues qu'ils corrigent. L'ARC exige également que les développeurs appliquent des politiques de divulgation des vulnérabilités, partagent des informations sur les bogues, fournissent un moyen de distribuer les mises à jour de sécurité, et ce, sans délai et gratuitement.
Exigences de déclaration et de conformité
Alors que les fabricants de la classe par défaut peuvent effectivement auto-évaluer si un produit est prêt à être commercialisé, ceux de la classe I doivent se soumettre à une évaluation de conformité par un tiers ou appliquer des normes harmonisées. Ils pourraient également appliquer les systèmes européens de certification de cybersécurité à leurs produits. Ceux de la classe II doivent passer par une évaluation de conformité par un tiers.
L'ARC exige également que les fabricants informent l'agence de sécurité ENISA dans les 24 heures suivant la prise de conscience d'une vulnérabilité ou d'un incident de sécurité activement exploité. De la même manière, les importateurs et les distributeurs doivent informer sans délai les fabricants de tout nouveau bug et éventuellement les autorités nationales de surveillance du marché en cas de risques graves.
Un SMSI pourrait-il aider les fabricants ?
Avec des pénalités de non-conformité fixées à 15 millions d'euros ou 2.5 % du chiffre d'affaires annuel, toutes les organisations concernées doivent réfléchir à la manière dont elles s'adaptent au nouveau régime. David Dumont, partenaire de Hunton Andrews Kurth, raconte ISMS.en ligne que les organisations de certains secteurs, comme les fabricants de dispositifs médicaux IoT, peuvent déjà avoir une longueur d'avance en raison des exigences réglementaires existantes. Sa collègue associée du cabinet d'avocats, Sarah Pearce, ajoute que les organisations se conforment pleinement aux GDPR, qui exige « des contrôles de sécurité robustes ainsi que des politiques et procédures connexes », devrait considérer que la conformité à l'ARC est « réalisable avec des ajustements limités ».
Cependant, tout n’est peut-être pas simple.
"Le respect de conditions strictes pour l'introduction et le maintien de produits numériques sur le marché européen peut entraîner des coûts supplémentaires", prévient Dumont. « De tels coûts de conformité supplémentaires pourraient rendre plus difficile la compétitivité des petites et moyennes entreprises sur le marché numérique et entraver le progrès technologique. »
C'est là qu'un Système de gestion de la sécurité de l'information (ISMS) pourrait aider en prenant en charge la conformité à la norme ISO 27001 et les contrôles, politiques et procédures robustes imposés par le RGPD cités par Pearce.
« Il existe un chevauchement entre les normes européennes et internationales existantes en matière de cybersécurité, telles que la norme ISO 27001, et certaines des principales exigences en matière de cybersécurité de l'ARC », explique Dumont. « Les entreprises qui adhèrent à ces normes existantes pourront en tirer parti lorsqu’elles s’attaqueront à la conformité avec l’ARC. »
Quels sont les problèmes potentiels ?
Certains ont salué la tentative de la commission d'améliorer la sécurité et la transparence de base entre les produits technologiques. John Smith, directeur technique de Veracode EMEA, le décrit comme un « texte législatif historique ».
« Cela apporte non seulement plus de transparence dans un domaine souvent opaque, mais encourage également les éditeurs de logiciels, les fabricants et les détaillants à renforcer la cybersécurité des produits qu'ils vendent, tout en aidant les acheteurs à sélectionner facilement des produits robustes », ajoute-t-il. « Espérons que cela incitera les organisations à aller au-delà des exigences obligatoires et à accorder une plus grande priorité à la sécurité. »
Cependant, d’autres ont de sérieuses inquiétudes. Groupe de défense des droits à but non lucratif Electronic Frontier Foundation souligne deux implications potentiellement graves si l’ARC est adoptée sous sa forme actuelle :
Open source: Tout développeur open source sollicitant des dons ou facturant des services de support pour son logiciel est responsable des dommages si son « produit » contient un bug qui se retrouve dans d'autres produits. Compte tenu de la nature complexe et interconnectée du système open source chaîne d'approvisionnement de logiciels, cela pourrait avoir un effet dissuasif sur l’industrie et forcer les promoteurs à abandonner complètement la région.
Divulgation de vulnérabilité : Premièrement, le délai très court (24 heures) pour signaler de nouvelles vulnérabilités à l'ENISA pourrait encourager des solutions rapides mais « superficielles » qui ne s'attaquent pas à la cause profonde des problèmes. Deuxièmement, l'ENISA rend compte aux équipes de réponse aux incidents de sécurité informatique (CSIRT) des États membres et aux autorités de surveillance du marché. L'EFF craint que les pirates gouvernementaux puissent exploiter ces informations de vulnérabilité et/ou les divulguer à la communauté de la cybercriminalité.
Malheureusement, il ne semble pas que les législateurs tiennent compte de ces préoccupations.
"Avec l'augmentation indéniable des cyberattaques ces dernières années, avec un impact économique et sociétal énorme, la nécessité d'une intervention gouvernementale est claire et l'emporte sans doute sur ces préoccupations", conclut Pearce.
