Un vendredi sur deux

Cyber Resilience Act

Présentation

Suite à différents échanges, j’ai entendu parler de NIS2, DORA et CRA sans forcément avoir de connaissances approfondies sur le sujet. L’objectif du jour est d’essayer de remédier à cela en écoutant/lisant quelques documents sur ces réglementations. Je sens que cela va être passionnant…

IMPORTANT : CONSULTEZ UN JURISTE !

Il s’agit de prises de notes effectuées au fil de mes lectures, écoutes ou visionnages. Certaines écoutes ont été réalisées pendant un footing :). Je ne suis pas juriste et j’ai du mal avec ce genre de sujets.
Pour les plus motivés : Règlements en français. Le lien provient d’une page de l’ANSSI.

Écoute / Lecture

Écoute de AtoutDSI

  • Lien(s) :
    • L’article : ici;
  • Notes :
    • NIS2
      • Présentation
        • Directive V2 de NIS1
        • Couvre 35 secteurs d’activités ==> 16 000 entreprises concernées
        • Au 16/01/2025 : non appliqué en France (pas encore transposé)
        • Si l’entreprise n’est pas essentielle, et que son chiffre d’affaires est < 10 millions d’euros et qu’elle compte < 250 salariés => pas concernée
      • Mise en place
        • Passer en revue les éléments existants : charte de sécurité, PSSI, classification des incidents, mesures face aux vulnérabilités, traçabilité, etc.
        • Point important (valable aussi dans DORA) : Quelle est votre capacité à reporter les exigences auprès de vos sous-traitants ? Est-ce reporté dans vos contrats ?
          • Exemple : remontée des incidents/vulnérabilités en moins de 24 heures
      • Pour une entreprise, il faut étudier le niveau de criticité associé au prestataire :
        • En cas d’attaque (cyber) du prestataire, l’entreprise peut-elle continuer son activité ?
      • Sanctions
        • Reprend le principe du RGPD avec une notion de minimum et de % du CA mondial (élevé dans tous les cas)
        • Risque de suppression de certification…
    • DORA
      • Présentation
        • Applicable depuis le 17/01/2025
        • C’est un règlement, donc application directe (pas de transposition)
        • Sectoriel : Assurance/Bancaire (21 typologies ciblées)
        • Surcouche de NIS2
        • Normalement, les entreprises ont dû commencer à travailler avec leurs prestataires
      • Impacts
        • Clauses de réversibilité, d’audit, de résiliation
          • Exemple : dans le secteur bancaire, les entreprises peuvent réaliser des audits illimités
        • RH : Mise à jour des contrats de travail, formation à la cybersécurité
      • Le client peut demander des PENTEST à son prestataire (à négocier)
      • Sanctions
        • Pas forcément spécifiques à DORA, mais risque de sanctions pénales contre les dirigeants
      • Implémentation de NIS2 pour le domaine financier
    • CRA
      • Présentation
        • Sorti en 2024, applicable en 2025
        • L’intervenant parle d’application aux matériels embarquant du logiciel :
          • Montres connectées, frigos, mais aussi VPN, etc.
        • Il faut déterminer le rôle dans la vie du produit :
          • Fabricant
          • Distributeur
          • Importateur
      • Notes
        • Début 2025 : pas l’urgence, mais fin 2025/début 2026
        • Lister les prestataires…

Conférence CNLL

  • Lien(s) :
  • Notes :
    • Focus sur l’open source, particulièrement impacté,
      • Le CRA responsabilise le « Fabricant », qui doit assumer les problèmes de cybersécurité. Quel impact pour un modèle où la licence indique que le produit est livré « tel quel » ?
    • L’Europe revient à ses fondamentaux : réguler le marché européen
    • Concerne tout logiciel ou matériel mis sur le marché européen dès qu’il interagit avec d’autres matériels ou un réseau
      • Même une mise à jour
    • Acteurs
      • Fabricant : construit ou réalise sous sa marque
        • Doit prouver qu’il a tout fait pour prévenir les failles de sécurité
      • Distributeur : fournit le produit au consommateur
        • Les administrations doivent intégrer dans leurs marchés toutes les mesures pour vérifier que chacun a bien fait son travail
    • Obligation : réaliser un SBOM
      • À valider, mais ce serait seulement sur le premier niveau de dépendance


Crédits : CNLL ici

La cybersécurité expliquée à ma grand-mère

Podcast écouté en faisant un footing

  • Liens :
    • Partie 1 : 1/2
    • Partie 2 : 2/2
      • Écoute partielle…
  • Notes :
    • Fabricant = Créateur de logiciel avec ou sans matériel connecté à un réseau (interne ou externe)
    • Est concerné par le CRA : tout logiciel connecté ou matériel avec des logiciels connectés, à destination B2B ou B2C
    • Le Fabricant est responsable des dommages et intérêts
    • Il semble que cela s’applique aussi aux logiciels internes d’une société

Cyber Resilience Act : 21 mois pour préparer vos chaînes DevSecOps

Le présent règlement s’applique aux *produits comportant des éléments numériques** mis à disposition sur le marché dont l’utilisation prévue ou raisonnablement prévisible comprend une connexion directe ou indirecte, logique ou physique, à un dispositif ou à un réseau

  • Notes :
    • Intro
      • Part du texte (courageux)
      • Techniquement, les annexes (trouvées plus haut en parlent bien)
    • Objectifs : Marquage CE / Traçabilité
    • Timeline
      • 10/10/2024 : entrée en vigueur
      • 08/2026 : Déclaration obligatoire des vulnérabilités
      • 11/2027 : Implémentation totale exigée
    • Application
      • Traduction : logiciels distribués à un tiers (seul ou embarqué) non isolé, appli mobile, commercial (OSS exclu selon certaines règles)
        • Commercial : ne veut pas dire payant, mais qui génère de l’argent
        • C’est HYPER LARGE
      • Exemple donné : VLC ! Le développeur de VLC n’est pas impacté, mais quelqu’un qui déploie VLC dans une BOX l’est
      • Ce règlement vient compléter ce qui n’était pas déjà réglementé
      • Le plus strict s’applique
    • Build
      • Il faut contrôler les packages, mais aussi les éléments qui aident à construire
      • buildinfo.org ?
      • Il faut tout tracer et tout contrôler…
      • Passer par des sources repo privés ? Ou avoir un endroit centralisé A5Sys ?
      • TUF: The Update Framework
    • À retenir
      • Périmètre : Logiciels commerciaux distribués avec connectivité, appli mobile
      • Gestion par catégorie

Le texte du règlement

SPOILER : je ne l’ai pas lu. J’ai fait mon fainéant 2025 et j’ai confié le PDF à NotebookLM dont je voulais tester la fonctionnalité podcast (c’est plus que bluffant…).

  • Lien(s) :
  • Notes :
    • Périmètre
      • Tous les produits matériels ou logiciels qui peuvent se connecter d’une manière ou d’une autre à un réseau ou à un autre matériel
    • Volonté de protection de l’OSS
    • La sécurité est « par design », sécurisée par défaut pendant tout le cycle de vie (même après la vente)
      • 5 ans minimum, mais peut couvrir plus si besoin
    • Communication dès qu’on a des infos (24h pour une alerte précoce)
      • 72h pour plus d’infos

Après l’écoute

Liste des exigences

  • Sources :
  • En matière de cybersécurité (Source : Annexe I, Partie 1) :
    • Être mis à disposition sur le marché sans vulnérabilité exploitable connue
    • Être mis à disposition sur le marché avec une configuration sécurisée par défaut
    • Être conçus de façon à ce que 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 activées par défaut, mais faciles à désactiver, par la communication aux utilisateurs des mises à jour disponibles et par la possibilité de les différer temporairement
      • Garantir que les vulnérabilités peuvent être corrigées par des mises à jour de sécurité
      • Plus le droit de dire : « Ah bah non, désolé, on ne peut pas mettre à jour le firmware… »
    • Assurer la protection contre les accès non autorisés au moyen de mécanismes de contrôle appropriés
    • Protéger la confidentialité des données stockées, transmises ou traitées de toute autre manière, à caractère personnel ou autres
    • 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
    • Ne traiter que des données, personnelles ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire
      • Cela semble rejoindre le principe du RGPD
    • 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
      • Diviser pour mieux régner…
    • 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
    • Être conçus, développés et fabriqués de manière à limiter les surfaces d’attaque, y compris les interfaces externes
    • Ê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
    • 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, tout en laissant à l’utilisateur la possibilité de désactiver le mécanisme
    • Donner aux utilisateurs la possibilité de supprimer facilement, en toute sécurité et de manière permanente toutes les données et tous les paramètres et, lorsque ces données peuvent être transférées vers d’autres produits ou systèmes, veiller à ce que cela puisse se faire de manière sécurisée
  • Gestion des vulnérabilités (Source : Annexe I, Partie 2) s’appliquent aux fabricants :
    • Recenser et documenter 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
    • Gérer et corriger 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é ; lorsque cela est techniquement possible, de nouvelles mises à jour de sécurité sont fournies séparément des mises à jour de fonctionnalité
    • Soumettre régulièrement les produits comportant des éléments numériques à des tests et examens de sécurité efficaces
    • Dès la publication d’une mise à jour de sécurité, communiquer 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é, les conséquences de ces vulnérabilités, leur gravité et des informations claires et accessibles aidant les utilisateurs à y remédier ; dans des cas dûment justifiés, lorsque les fabricants considèrent que les risques pour la sécurité liés à la publication l’emportent sur les avantages en matière de sécurité, ils peuvent retarder la publication des informations relatives à une vulnérabilité corrigée jusqu’à ce que les utilisateurs aient eu la possibilité d’appliquer le correctif adapté
    • Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités
    • Prendre 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
    • Prévoir 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 et, le cas échéant, automatiser les mises à jour de sécurité
    • Veiller à 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, sauf accord contraire entre un fabricant et un utilisateur professionnel en ce qui concerne un produit sur mesure comportant des éléments numériques, gratuitement et accompagnés de messages consultatifs fournissant aux utilisateurs les informations pertinentes, y compris sur les éventuelles mesures à prendre

Catégories de produits

  • Non critique :
    • Pas de gain en cas d’attaque sur un autre système, pas critique
    • Auto-évalué
  • Critique :
    • Exemple : jouet pour enfants (car filme les enfants)
    • Nécessite une évaluation externe

Hors périmètre

Extrait : « The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying software or hardware products with a digital component. »

  • Ce qui est déjà couvert par autre chose de plus strict
  • Les logiciels internes : Pour la même raison, le projet de CRA ne concernera pas non plus les logiciels développés en interne tels que les systèmes de dossiers de santé électroniques
  • Les logiciels SaaS : ici et ici
    • AMHA : ne va pas durer… (le navigateur…)

SBOM / SPDX / CycloneDX

Liens :

Divers

Liens parcourus rapidement (trop) :