Ce que vous ne connaissez pas, vous ne pouvez pas le protéger.

Non. Il fournit des constats dans les limites de son périmètre. Le code, les systèmes hors ligne et les composants inaccessibles nécessitent d'autres méthodes de collecte.

Une SBOM décrit les composants logiciels. Une CBOM y ajoute une vue ciblée sur les composants et dépendances cryptographiques pertinents pour la planification de la migration.

Quel chiffrement utilisent vos applications, et qui peut le modifier ? Nous recensons les dépendances cryptographiques et les rattachons à vos systèmes et responsables. L'inventaire constitue une base vérifiable pour la planification à venir.

Définir le périmètre d'analyse et les méthodes de collecte autorisées Recenser les protocoles, certificats, bibliothèques et usages des clés Regrouper les résultats des scans, de l'analyse de code et des exports système Signaler les dépendances et les zones non examinées Préparer la mise à jour continue de l'inventaire et un export exploitable par machine

Inventaire cryptographique avec origine et couverture Vue d'ensemble des dépendances par application Procédure de mise à jour de la CBOM

Un scan réseau détecte les services accessibles, mais pas l'ensemble de la cryptographie d'une organisation. Nous combinons des méthodes de collecte autorisées : points de terminaison, inventaires de certificats, bibliothèques, configuration et entretiens avec les responsables système. Les signatures hors ligne, les appareils mobiles et les composants embarqués peuvent également être pertinents. Les résultats distinguent l'usage observé des capacités simplement installées. Chaque constat reçoit une source et une date, afin que les décisions ultérieures ne reposent pas sur des hypothèses floues.

Une Cryptography Bill of Materials, ou CBOM, décrit les composants cryptographiques et leurs relations sous une forme exploitable par machine. L'élément déterminant est le rattachement à la finalité d'usage : un certificat peut protéger une connexion ou sécuriser une signature vérifiable à long terme. Nous recensons les propriétaires, la possibilité de modification et les dépendances vis-à-vis des fabricants. Les systèmes inaccessibles ou non examinés restent visibles comme des lacunes. Un vaste export de données sans cette mise en contexte ne constituerait pas une base de décision solide.

Les modifications apportées aux bibliothèques, aux certificats et à la configuration doivent alimenter la mise à jour continue. Des responsables et des déclencheurs de mise à jour sont définis à cet effet. Lors de la recette, nous vérifions des échantillons par rapport aux systèmes réels et documentons le périmètre d'examen atteint. Les scans en production ne sont réalisés que dans le cadre validé et en tenant compte des composants sensibles.

Nous recensons où vos applications et infrastructures utilisent des procédés cryptographiques. Le résultat relie les occurrences techniques à leur signification métier, aux responsabilités et à la voie par laquelle un changement est possible, s'il l'est.

Les occurrences sont associées à des systèmes, des usages et des responsables. Les zones inconnues et les limites du relevé restent visibles. Les changements apportés au parc peuvent être répercutés dans l'inventaire.

Exemple : une organisation connaît ses certificats web, mais pas la bibliothèque de signature d'un système d'archivage. L'état des lieux relie les deux à la conservation des données et à la responsabilité du fabricant. On voit ainsi que la dépendance liée à l'archivage nécessite un délai de préparation plus long que le prochain remplacement d'un serveur web.

Outre les certificats TLS, nous examinons les bibliothèques, les procédés de signature, les dépôts de clés et les fonctions intégrées dans les produits. L'analyse du code source, le contrôle de configuration et le relevé technique peuvent se compléter. Aucun outil isolé ne voit toutes les dépendances ; nous documentons donc explicitement la couverture et les zones d'incertitude restantes. Chaque occurrence est associée à un système et à une équipe responsable. Les éléments importants sont l'algorithme, l'usage, le composant support et les données protégées. Une liste d'algorithmes sans leur finalité d'utilisation n'est que d'une aide limitée pour la priorisation ultérieure.

Nous distinguons les logiciels développés en interne des produits qui ne peuvent être modifiés que par des mises à jour du fabricant. Nous recensons également les équipements à cycle de vie long et les partenaires de communication externes. La question n'est pas seulement de savoir ce qui est utilisé aujourd'hui, mais aussi qui peut engager et valider une migration. L'inventaire est doté d'un processus de mise à jour. Les nouveaux logiciels et les changements significatifs doivent être enregistrés, afin que l'état des lieux ne devienne pas obsolète après quelques mois seulement. Pour les systèmes inaccessibles, nous consignons les preuves en attente et des questions concrètes à adresser aux fournisseurs, plutôt que d'interpréter un manque de visibilité comme une absence de cryptographie.

Inventaire cryptographique et besoin de protection DSI, sécurité de l'information, responsables d'applications, spécialiste en cryptographie d'OTOKO® CBOM, besoin de protection et durée de vie des données par système, analyse des écarts par rapport à BSI TR-02102

Feuille de route, algorithmes cibles, phases de transition Architecture, sécurité de l'information, exploitation de la PKI, achats Feuille de route de migration, politique cryptographique, architecture cible pour la PKI et les HSM, modèle d'exploitation