> For the complete documentation index, see [llms.txt](https://docs.medcrypt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.medcrypt.com/fr/references/cybersecurity-terminology.md). # Terminologie de la cybersécurité | Terme | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CA | Autorité de certification. Organisation qui délivre un certificat. | | CEP | Profil de l’environnement du composant. Il comprend des caractéristiques telles que l’impact maximal du composant, son exposition ou non à la surface d’attaque, l’existence d’un flux de données vers le composant (et la nature de ces données), etc. | | CeQ | Notre système qualité intégrant la cybersécurité est une offre de service de Medcrypt. | | CISA KEV | Vulnérabilités exploitées répertoriées par la Cybersecurity & Infrastructure Security Agency | | COTS | Logiciel commercial prêt à l’emploi. Il s’agit d’un produit logiciel ou matériel prêt à l’emploi, disponible dans le commerce et que le grand public peut acheter, obtenir sous licence ou louer. On parle aussi de logiciel prêt à l’emploi. Consultez la définition correspondante dans ce tableau pour en savoir plus. | | CNA | Autorité de numérotation des CVE, telle que Microsoft. | | CPE |

Common Platform Enumeration.


Les vulnérabilités peuvent être identifiées à l’aide de trois champs : CPE, PURL et SWID. Helm prend en charge CPE et PURL.

Le NIST définit CPE comme un système de nommage structuré pour les systèmes informatiques, les logiciels et les packages. Il repose sur la syntaxe générique des identifiants de ressources uniformes (URI) et comprend un format de nom formel, une méthode permettant de vérifier les noms par rapport à un système, ainsi qu’un format de description permettant d’associer du texte et des tests à un nom. La spécification CPE a été conçue pour les systèmes d’exploitation, les applications et les périphériques matériels. Elle est maintenue par le NVD.

Il est recommandé d’utiliser CPE pour identifier une application cliente ou serveur, un micrologiciel ou un système d’exploitation.


| | CQI | Amélioration continue de la qualité | | CSAF | Le Common Security Advisory Framework est une norme d’avis de sécurité lisibles par machine, élaborée par le comité technique OASIS Open CSAF. | | CSR | Demande de signature de certificat | | CycloneDX |

Ces informations s’appuient sur la spécification CycloneDX et les informations relatives aux cas d’utilisation.

CycloneDX est un format SBOM lisible par machine qui décrit les types de composants suivants : applications, conteneurs, appareils, bibliothèques, fichiers, micrologiciels, infrastructures logicielles et systèmes d’exploitation. Il décrit également les services. Helm prend en charge CycloneDX.

| | CWE | Énumération des faiblesses des composants | | EPSS | Modèle qui tente de prédire la fréquence à laquelle une vulnérabilité pourrait être exploitée dans la pratique. | | HDO | Organisation de soins de santé, par exemple un groupe de médecins qui exercent ensemble. | | HSM | Module de sécurité matériel. Un HSM est un ordinateur spécialisé et « de confiance » qui effectue diverses opérations cryptographiques, telles que la gestion et l’échange de clés, ainsi que le chiffrement et le déchiffrement. | | NTIA | Administration nationale des télécommunications et de l’information | | OSS | Logiciel open source. La FDA veut s’assurer que vous savez quels composants sont COTS ou OSS. OSS et SOUP sont souvent utilisés à tort comme des termes interchangeables. Si vous utilisez des composants OSS, vous devrez fournir à la FDA des documents attestant qu’ils sont activement maintenus. S’ils ne le sont pas ou s’ils sont en fin de vie (EOL), vous devrez fournir des informations sur les mesures prises pour atténuer les vulnérabilités de ces composants. | | OTS |

Logiciel prêt à l’emploi.

Ces informations sont tirées des recommandations de la FDA intitulées «Utilisation de logiciels prêts à l’emploi dans les dispositifs médicaux».

À mesure que le matériel informatique à usage général se répand, les logiciels OTS sont de plus en plus utilisés dans les dispositifs médicaux. Toutefois, ils ne sont pas nécessairement adaptés à un usage spécifique dans un dispositif médical. En tant que fabricant de dispositifs médicaux (MDM), vous renoncez à la maîtrise du cycle de vie des logiciels OTS, mais restez responsable du fonctionnement sûr et efficace de votre dispositif.

Que dois-je documenter ?

Cela dépendra de votre dispositif médical et des conséquences d’une défaillance du logiciel OTS sur la sécurité du patient, de l’opérateur ou d’une personne à proximité. Vous devrez effectuer une analyse des risques afin de déterminer le niveau de détail de la documentation à fournir à la FDA et le degré de maîtrise du cycle de vie nécessaire, en fonction de l’augmentation de la gravité des préjudices liés aux logiciels OTA.


| | PKI |

L’infrastructure à clés publiques permet des communications chiffrées sécurisées et une authentification mutuelle entre appareils, services et utilisateurs. Grâce aux certificats numériques et à l’utilisation de clés publiques, chaque « objet » connecté peut être associé à des entités telles que des personnes et des organisations. Ces certificats établissent une chaîne de confiance entre l’appareil connecté et l’autorité de certification qui les a délivrés.

Pour que la PKI fonctionne, une paire de clés cryptographiques générée de manière aléatoire doit être créée pour chaque appareil fabriqué. Cette paire de clés doit être provisionnée dans la racine de confiance (RoT) du microcontrôleur. La clé privée doit être protégée par la RoT matérielle, tandis que la clé publique est conservée dans un certificat ; ces deux éléments sont provisionnés pendant la fabrication. Le certificat est signé par une autorité de certification, ce qui permet d’authentifier l’identité.

Ainsi, l’identité n’est pas un identifiant unique ni un identifiant universel unique (UUID) : elle repose sur la manière dont l’appareil ou un autre composant est identifié au moyen d’une paire de clés générée de manière aléatoire. La clé publique est fournie sous la forme d’un certificat signé (authentifié) par une autorité de certification de confiance. La clé privée sert à prouver l’identité.

| | PURL |

Les vulnérabilités peuvent être identifiées à l’aide de trois champs : CPE, PURL et SWID. Helm prend en charge CPE et PURL.


Le standard Package URL (PURL) uniformise la représentation des métadonnées des paquets logiciels afin qu’ils puissent être localisés de manière universelle, quels que soient leur fournisseur, leur projet ou leur écosystème. PURL vise à standardiser les méthodes existantes permettant d’identifier et de localiser de manière fiable les paquets logiciels. Il s’agit d’une chaîne URL utilisée pour identifier et localiser un paquet logiciel de manière largement universelle et uniforme dans différents langages de programmation, gestionnaires de paquets, conventions de empaquetage, outils, API et bases de données.

| | QMS | Système de management de la qualité. Il s’agit d’un système structuré qui documente les processus, les procédures et les responsabilités afin de fournir en continu des produits et services de haute qualité répondant aux exigences réglementaires et aux attentes des clients. Il vise à établir un cadre qui améliore la communication, la collaboration et la cohérence au sein de votre entreprise, tout en réduisant le gaspillage et en favorisant une culture d’amélioration continue. | | QSR | Réglementations relatives au système qualité | | RA | Autorité d’enregistrement | | RDP | Remote Desktop Protocol. Permet aux utilisateurs de se connecter à distance à un autre ordinateur ou appareil et de le contrôler. | | RoT | Racine de confiance | | SBOM | Nomenclature des logiciels. Elle recense tous les éléments de votre chaîne d’approvisionnement logicielle, notamment les composants, les licences, les droits d’auteur et les références de sécurité. | | SMB | Server Message Block est utilisé par les ordinateurs Windows pour le partage de fichiers, de ports et d’imprimantes, ainsi que pour d’autres services réseau. Si ces protocoles ne sont pas correctement sécurisés, un attaquant pourrait accéder à un réseau et causer des dommages importants. | | SOUP |

Software of Unknown (or Uncertain) Pedigree (or Provenance) est un terme souvent utilisé dans le contexte des systèmes critiques pour la sécurité, comme les logiciels médicaux. SOUP désigne un logiciel qui n’a pas été développé selon un processus ou une méthodologie de développement logiciel connus, ou dont les propriétés liées à la sécurité sont inconnues ou inexistantes.


| | SPDX |

Software Package Data Exchange. SPDX est une norme ouverte internationale de Linux qui permet de communiquer les informations d’une SBOM, notamment la provenance, les licences, la sécurité et d’autres informations connexes. Elle fournit une SBOM lisible par machine ainsi qu’une version lisible par l’humain, permettant de partager des données essentielles sur votre écosystème logiciel et d’améliorer la transparence et l’atténuation des risques de cybersécurité.

SPDX est reconnue comme la norme ouverte internationale pour les artefacts liés à la sécurité, à la conformité des licences et aux autres éléments de la chaîne d’approvisionnement logicielle, sous la désignation ISO/IEC 5962:2021.

Helm ne prend pas encore en charge SPDX, mais sa prise en charge est actuellement en cours de conception.

| | SSVC |

Classification des vulnérabilités adaptée aux parties prenantes. Ce cadre s’inspire du document de la CISA intitulé Stakeholder-Specific Vulnerability Categorization.

Cette méthodologie d’analyse des vulnérabilités tient compte de leur état d’exploitation, de leurs répercussions sur la sécurité et de la prévalence du produit concerné dans un système donné.

La CISA utilise son propre arbre de décision SSVC pour classer les vulnérabilités pertinentes selon quatre décisions possibles :

Ces décisions reposent sur les valeurs suivantes : état d’exploitation, impact technique, caractère automatisable, prévalence dans les missions et impact sur le bien-être public.


| | SWID |

Software ID (SWID), tel que défini dans ISO/IEC 19770-2:2015 est principalement utilisé pour identifier les logiciels installés.


Les vulnérabilités peuvent être identifiées à l’aide de trois champs : CPE, PURL et SWID. Helm prend en charge CPE et PURL. Helm ne prend pas encore en charge SWID.


Il est recommandé d’utiliser SWID pour un conteneur (tout comme PURL, pris en charge), un micrologiciel (tout comme CPE, pris en charge), une bibliothèque ou un framework (hors package), un système d’exploitation (tout comme CPE) et un package de système d’exploitation (tout comme PURL).

| | TQM | Management de la qualité totale. Cette approche met l’accent sur la qualité dans l’ensemble de votre entreprise, de la conception à la satisfaction des clients. | | UUID | Identifiant universellement unique lisible par la plupart des microcontrôleurs disponibles aujourd’hui. Il ne s’agit pas d’une identité, mais uniquement d’un identifiant. Consultez la définition de PKI pour en savoir plus. | | V\&V | [Vérification et validation](/fr/references/cybersecurity-best-practices/cybersecurity-verification-and-validation-v-and-v.md) Les méthodes de vérification et de validation permettent de s’assurer qu’un produit, un service ou un système respecte les exigences et les spécifications, et qu’il remplit l’objectif prévu. La V\&V est essentielle à un système de management de la qualité (tel que l’ISO 9000). | | VEX |

Vulnerability Exploitability eXchange. Il s’agit de l’avis de sécurité qu’un fournisseur communique au sujet de son analyse d’une vulnérabilité particulière dans le contexte de son logiciel. Les clients des fournisseurs, tels que les hôpitaux, doivent savoir si cette vulnérabilité a une incidence sur l’utilisation du dispositif. Helm n’utilise pas les conventions de statut VEX, mais leur prise en charge est actuellement en cours de conception.

Un VEX fournit des informations complémentaires indiquant si un produit est affecté par une vulnérabilité spécifique dans une dépendance. Si tel est le cas, il recommande des mesures correctives. Par exemple, une vulnérabilité dans une dépendance en amont n’est probablement pas exploitable dans le produit final si le code concerné n’est pas chargé par l’ordinateur ou si d’autres protections en ligne sont présentes dans le logiciel. Les fournisseurs de dépendances publient un VEX pour indiquer le statut d’une vulnérabilité dans des produits spécifiques. Ces statuts sont les suivants :

Les VEX sont lisibles par machine. Les utilisateurs peuvent donc intégrer les données de dépendances des SBOM aux informations sur l’état des vulnérabilités fournies par les VEX afin d’obtenir une vue à jour de cet état. Ils peuvent ainsi adopter une approche beaucoup plus ciblée pour repérer et corriger les vulnérabilités de leurs logiciels.

Un VEX peut couvrir plusieurs vulnérabilités dans un produit ou dans plusieurs produits.

Ces éléments sont définis par CSAF et peuvent fournir des informations telles que les mesures correctives, les solutions de contournement, les redémarrages ou interruptions de service nécessaires, les scores et les risques communiqués par les fournisseurs, les intégrateurs de systèmes et les opérateurs.

| | VLCDB | Base de données sur le cycle de vie des vulnérabilités | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.medcrypt.com/fr/references/cybersecurity-terminology.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.