Le Certificate of Networthiness (CoN) a longtemps été le sésame pour connecter un système aux réseaux militaires américains. Depuis le 1er octobre 2016, le CoN a été remplacé par l’Authority to Operate (ATO) dans le cadre de la transition vers le Risk Management Framework (RMF) du NIST. Malgré ce changement de terminologie, le principe reste identique : tout système destiné à opérer sur un réseau classifié ou sensible doit prouver sa conformité cybersécurité avant d’être autorisé en production.
Or, cette preuve se construit bien avant la mise en série.
A lire également : Pourquoi les drones sont interdits : règles et sanctions à connaître!
Networthiness et RMF : ce que recouvre l’autorisation d’exploitation réseau
Le terme « networthiness » désigne la capacité d’un équipement ou d’un logiciel à fonctionner sur un réseau sans en compromettre la sécurité, la disponibilité ou l’intégrité. L’US Army utilisait le CoN comme certificat formel. Avec l’adoption du RMF, ce processus s’inscrit désormais dans un cadre plus large, partagé avec l’US Air Force, la Navy et les programmes OTAN.
L’ATO exige une documentation structurée : inventaire des composants logiciels, cartographie des flux réseau, gestion des comptes et des privilèges, journalisation des événements. Ces éléments ne se greffent pas après coup sur un produit fini. Ils conditionnent l’architecture même du système.
A lire également : Protéger son 1to1 Webmail : les bonnes pratiques à adopter
Parler encore de « Certificate of Networthiness » sans évoquer cette évolution réglementaire revient à travailler avec un référentiel obsolète. Les programmes d’acquisition récents, qu’ils soient DoD ou OTAN, exigent que les preuves de networthiness soient intégrées dès les phases de prototypage.
Prototype et cybersécurité : pourquoi la validation réseau commence en amont
La logique traditionnelle du développement produit place la certification en fin de cycle, juste avant la mise en production. Pour les systèmes connectés destinés à des environnements militaires ou critiques, cette approche génère des retards mesurables.
Les guides d’acquisition DoD et OTAN sont explicites sur ce point : les exigences de networthiness doivent être testées sur des « production representative test articles », c’est-à-dire des prototypes représentatifs des conditions opérationnelles réelles. Quand cette validation n’intervient qu’au stade de la présérie, elle retarde l’Initial Operational Test and Evaluation (IOT&E), ce qui repousse mécaniquement l’entrée en production.
Ce que le prototype doit déjà démontrer
Un prototype destiné à obtenir une autorisation d’exploitation réseau ne peut pas se contenter de valider des fonctions métier. Il doit aussi prouver que l’architecture réseau et logicielle respecte les contrôles de sécurité du RMF.
- La gestion des comptes et des droits d’accès doit être implémentée dès le premier prototype fonctionnel, pas simulée ou contournée par des accès administrateur génériques.
- La journalisation des événements (logs) doit être active et conforme aux formats attendus par les outils de supervision du réseau cible.
- L’inventaire des composants logiciels (SBOM, Software Bill of Materials) doit être documenté, car il est systématiquement audité lors du processus d’ATO.
- Les flux réseau doivent être cartographiés et justifiés, port par port, protocole par protocole.
Ignorer ces exigences au stade du prototype, c’est accumuler une dette technique qui se paie en mois de retard lors de la phase d’autorisation.
Réduction des « cyber surprises » : les retours terrain des programmes DoD
Les retours d’expérience des programmes logiciels du Department of Defense depuis l’adoption du RMF pointent une tendance nette. Les équipes produit qui font certifier les éléments de sécurité dès le prototype réduisent significativement ce que les praticiens appellent les « cyber surprises » lors du processus d’autorisation d’exploitation.
Une « cyber surprise », c’est la découverte tardive d’une non-conformité qui bloque l’ATO. Un composant open source non répertorié dans le SBOM. Un flux réseau non documenté. Un mécanisme de journalisation incompatible avec l’infrastructure de supervision. Chacun de ces points, anodin au stade du prototype, devient un obstacle majeur quand le système est prêt pour la production.
Intégrer la certification réseau dès le prototype transforme la cybersécurité en contrainte de conception plutôt qu’en obstacle de dernière minute. Les équipes qui adoptent cette approche constatent que les audits d’ATO se déroulent sans blocage, parce que les preuves de conformité existent depuis les premières itérations.
Stratégie d’intégration précoce du Certificate of Networthiness dans le cycle produit
Sur les programmes matériels complexes (défense, aéronautique, systèmes embarqués), la question n’est pas de savoir si la networthiness sera exigée, mais quand l’équipe projet commence à s’en occuper. Les données disponibles ne permettent pas de quantifier précisément le gain de temps, mais les retours terrain convergent : plus l’intégration est précoce, plus la transition vers la production est fluide.
Ce qui change concrètement dans l’organisation projet
Traiter la networthiness dès le prototype implique des choix d’organisation inhabituels pour beaucoup d’équipes de développement.
- Un spécialiste RMF ou cybersécurité rejoint le projet dès la phase de conception, pas au moment de la présérie. Son rôle est de traduire les contrôles de sécurité en spécifications techniques intégrables dans l’architecture.
- Le SBOM est maintenu comme un livrable vivant, mis à jour à chaque itération du prototype, et non reconstitué rétroactivement avant l’audit.
- Les tests de sécurité réseau font partie du plan de validation du prototype, au même titre que les tests fonctionnels ou de performance.
Cette approche a un coût initial plus élevé en termes de coordination. En revanche, elle évite les boucles de correction tardives qui, sur certains programmes, repoussent la mise en production de plusieurs mois.
Limites et zones grises
Les retours terrain divergent sur un point : le niveau de fidélité réseau nécessaire au stade du prototype. Certains programmes réussissent leur ATO en testant sur des réseaux de laboratoire représentatifs. D’autres constatent que seuls les tests en environnement opérationnel réel produisent des résultats exploitables pour l’autorisation finale.
La question reste ouverte, et dépend largement de la criticité du système et du réseau cible. Ce qui ne fait pas débat, en revanche, c’est le principe : attendre la présérie pour aborder la networthiness revient à ignorer une contrainte structurante du produit.
Le passage du CoN à l’ATO a formalisé ce qui était déjà une bonne pratique sur les programmes les mieux gérés. Pour les équipes qui démarrent un nouveau système connecté destiné à un environnement réseau contrôlé, la première question à poser n’est pas « quand certifier », mais « comment concevoir le prototype pour que la certification soit déjà en cours ».
