Le Certificate of Networthiness, souvent appelé CoN, a longtemps représenté le passage obligé pour tout logiciel destiné aux réseaux de l’U.S. Army. Son objectif était simple : empêcher qu’un outil insuffisamment vérifié fragilise les infrastructures militaires, expose des données opérationnelles ou provoque des incompatibilités techniques. Mais le paysage cyber a changé. Les mises à jour sont plus fréquentes, les attaques évoluent vite et un feu vert obtenu à un instant donné ne garantit plus la sécurité d’un environnement plusieurs mois après.
La logique actuelle s’appuie donc sur le Risk Management Framework, ou RMF, et sur des approches comme Assess Only. L’enjeu n’est plus seulement de faire valider une version logicielle avant son déploiement. Il faut démontrer, documenter et surveiller la maîtrise des risques pendant toute la durée de vie du produit. Pour un éditeur, un prestataire ou un responsable IT, ce virage transforme la conformité en véritable discipline opérationnelle : inventaire précis, configurations durcies, preuves dans eMASS, suivi des vulnérabilités et arbitrages clairs selon le niveau de criticité.
En bref
- Le CoN historique contrôlait l’acceptation des logiciels sur les réseaux de l’armée américaine.
- Le RMF remplace la validation figée par une gestion des risques documentée et suivie dans le temps.
- Assess Only peut convenir à des solutions à impact limité, mais ne remplace pas une ATO complète pour les environnements critiques.
- Les STIG et eMASS structurent respectivement le durcissement technique et la collecte des preuves.
- La conformité durable repose sur un inventaire fiable, des scans réguliers et une responsabilité partagée entre produit, sécurité et exploitation.
| Peu de temps ? Voici l’essentiel : |
|---|
| Le Certificate of Networthiness appartient à un ancien modèle de contrôle préalable des logiciels Army. |
| Le RMF demande de relier les risques, les contrôles de sécurité, les preuves et les décisions d’autorisation. |
| Les STIG servent à sécuriser les configurations ; eMASS sert à centraliser les éléments de conformité. |
| La meilleure stratégie consiste à préparer les preuves dès la conception, pas à la veille d’un audit. |
Certificate of Networthiness : rĂ´le historique et logique de contrĂ´le des logiciels Army
Le Certificate of Networthiness a été conçu comme un filtre de confiance pour les applications appelées à fonctionner sur les réseaux de l’U.S. Army. Pendant des années, la question centrale était la suivante : ce logiciel peut-il être installé sans compromettre la disponibilité, l’intégrité ou la confidentialité de l’environnement militaire ? Le NETCOM, l’organe chargé d’une partie essentielle des opérations réseau de l’Armée de terre américaine, encadrait ce processus afin d’éviter qu’une application non maîtrisée ne devienne une porte d’entrée pour un attaquant.
Ce mécanisme répondait à une réalité très concrète. Un logiciel ne se limite jamais à son interface visible. Il peut installer des services en arrière-plan, utiliser des bibliothèques anciennes, demander des privilèges élevés ou ouvrir des connexions sortantes. Dans un environnement commercial, ces éléments peuvent déjà générer des incidents coûteux. Sur une infrastructure de défense, ils peuvent perturber une mission, dégrader une chaîne de communication ou faciliter l’exfiltration d’informations tactiques.
Pourquoi le CoN était une barrière utile avant le déploiement
Le modèle CoN reposait sur une idée forte : mieux vaut empêcher un problème d’entrer sur le réseau que tenter de le réparer une fois installé. Les équipes soumettaient des éléments techniques sur le logiciel, sa version, ses dépendances et ses conditions de fonctionnement. L’évaluation cherchait notamment à identifier les incompatibilités avec les systèmes existants, les faiblesses de configuration et les risques liés aux droits attribués aux utilisateurs.
Imagine une entreprise fictive, Orion Field Systems, qui développe un outil de planification logistique. Son produit semble anodin : il aide les équipes à suivre des stocks et des mouvements de matériel. Pourtant, une analyse révèle que l’application conserve des mots de passe dans un fichier local, désactive une fonction de journalisation pour gagner en performance et utilise une composante non mise à jour. Sans contrôle préalable, ces trois détails peuvent créer une vulnérabilité exploitable. Le CoN imposait précisément ce réflexe de vérification avant l’ouverture des accès.
Cette discipline rappelle une pratique que connaissent bien les entrepreneurs lorsqu’ils structurent leur activité : un document, un outil ou une automatisation ne devient pas fiable parce qu’il semble pratique. Il le devient lorsqu’il a été testé, cadré et intégré dans un processus solide. De la même manière qu’une attestation de vigilance URSSAF permet de vérifier une situation administrative avant une collaboration, le CoN servait à réduire un risque avant l’intégration d’un logiciel dans un écosystème sensible.
Les risques que le Certificate of Networthiness cherchait à réduire
Le premier risque est l’espionnage. Une application compromise peut collecter des informations, transmettre des métadonnées ou donner accès à une machine interne. Le deuxième concerne la stabilité : une dépendance mal maîtrisée peut provoquer un conflit avec un autre composant, ralentir un serveur ou interrompre un service essentiel. Enfin, une faiblesse qui paraît mineure peut devenir grave lorsqu’elle se combine à une mauvaise gestion des comptes ou à un correctif absent.
- Portes dérobées : accès cachés permettant à un tiers de contrôler l’application ou le système hôte.
- Services inutiles : fonctions actives sans nécessité métier, qui augmentent inutilement la surface d’attaque.
- Dépendances vulnérables : bibliothèques anciennes dont les correctifs de sécurité ne sont plus appliqués.
- Privilèges excessifs : comptes ou processus capables d’exécuter des actions au-delà de leur besoin réel.
- Configurations incohérentes : différences entre serveurs qui compliquent les investigations et créent des angles morts.
Le CoN avait aussi une limite évidente : une validation ponctuelle ne fige pas les menaces. Une application jugée acceptable lors de son examen peut devenir problématique après une mise à jour, la découverte d’une faille ou un changement d’architecture. C’est cette faiblesse structurelle qui explique la bascule vers une logique de gestion continue. Le CoN a posé les bases d’une hygiène de sécurité ; le RMF transforme cette hygiène en cycle de pilotage durable.
Transition du Certificate of Networthiness vers le Risk Management Framework RMF
Le passage du CoN au Risk Management Framework ne correspond pas à un simple changement de vocabulaire. Il marque une évolution profonde de la manière dont les organisations fédérales et le Department of Defense évaluent leurs systèmes. Le CoN était largement associé à une autorisation centrée sur le produit et la compatibilité réseau. Le RMF, lui, relie la technologie à son contexte d’usage, aux données traitées, aux menaces identifiées et aux impacts possibles sur la mission.
Depuis l’abandon officiel du processus Army CoN en juillet 2018, l’orientation est claire : les équipes doivent s’appuyer sur des cadres harmonisés avec les pratiques fédérales, notamment celles inspirées des publications NIST comme SP 800-53. En 2026, cette logique reste centrale. La conformité n’est pas considérée comme un dossier que l’on archive après une signature ; elle devient un ensemble de décisions vivantes, alimentées par les scans, les changements de configuration et l’évolution de la menace.
Les Ă©tapes RMF qui donnent du sens aux contrĂ´les
Le RMF structure la démarche pour éviter deux erreurs fréquentes : appliquer des contrôles au hasard et produire des documents qui ne prouvent rien. La première étape consiste à préparer l’organisation et le système. Cela signifie définir le périmètre, les responsables, les actifs concernés et la mission soutenue. Une application de consultation interne n’exige pas le même niveau d’analyse qu’une plateforme connectée à une fonction de commandement.
Vient ensuite la catégorisation. Les équipes évaluent l’effet potentiel d’une atteinte à la confidentialité, à l’intégrité ou à la disponibilité. Si l’outil héberge seulement des ressources non sensibles et fonctionne dans un environnement isolé, l’impact peut rester limité. À l’inverse, une solution qui manipule des données opérationnelles ou qui dialogue avec des systèmes critiques exige une prudence maximale. Cette étape évite de traiter chaque outil comme s’il présentait le même niveau de risque.
Les contrôles sont alors sélectionnés et mis en œuvre. Le principe est pragmatique : le dispositif de sécurité doit être proportionné, mais jamais superficiel. Une équipe ne gagne rien à empiler des mesures qu’elle ne sait pas exploiter. En revanche, elle doit être capable de démontrer pourquoi chaque choix est pertinent, comment il est appliqué et comment elle vérifiera sa continuité. Les contrôles peuvent concerner l’authentification, la journalisation, la gestion des correctifs, le chiffrement, les sauvegardes ou la séparation des privilèges.
| Élément évalué | Approche Assess Only | Approche ATO complète |
|---|---|---|
| Données manipulées | Informations non sensibles ou limitées | Données sensibles, réglementées ou critiques |
| Impact métier | Conséquences faibles et réversibles | Conséquences fortes sur la mission ou les opérations |
| Connexion réseau | Environnement maîtrisé ou périphérique | Interconnexion avec le cœur des réseaux DoD |
| Niveau de preuve | Évaluation ciblée selon le périmètre | Dossier de sécurité complet et autorisation formelle |
| Surveillance | Suivi adapté au risque | Surveillance continue renforcée |
Assess Only : une simplification qui ne doit pas devenir un raccourci
Le processus Assess Only peut accélérer l’évaluation de logiciels dont le niveau de risque est faible et dont les usages sont bien délimités. C’est utile pour éviter de mobiliser une procédure lourde sur chaque petit outil de support. Toutefois, cette voie ne signifie pas « absence de contrôle ». Elle suppose au contraire que le périmètre soit clair, que l’application ne traite pas de données critiques et que son exposition soit réellement limitée.
Pour Orion Field Systems, le choix dépendrait de l’usage réel. Si sa solution est uniquement installée sur un réseau isolé pour gérer un catalogue non sensible, Assess Only peut être envisageable. Si elle échange des données avec une infrastructure centrale ou participe à une fonction tactique, une ATO complète devient nécessaire. Le bon réflexe consiste à qualifier le risque avant de chercher la procédure la plus rapide. Un processus allégé n’est pertinent que lorsque le risque est effectivement allégé.
STIG, eMASS et matrice de traçabilité : les outils RMF qui sécurisent les preuves
Le RMF devient difficile à piloter lorsqu’il reste abstrait. Pour passer des principes aux résultats, les organisations s’appuient sur des outils et des référentiels qui rendent les contrôles vérifiables. Les Security Technical Implementation Guides, connus sous le nom de STIG, apportent des règles de configuration détaillées. eMASS, de son côté, sert à organiser les preuves, suivre les écarts et faciliter les échanges avec les évaluateurs. Ensemble, ils évitent que la conformité dépende d’un tableur dispersé ou de la mémoire d’un seul administrateur.
Les STIG sont publiés par la DISA, la Defense Information Systems Agency. Ils décrivent comment durcir des systèmes d’exploitation, des bases de données, des équipements réseau ou certaines applications. Un STIG ne se contente pas de recommander « plus de sécurité ». Il peut préciser quel protocole désactiver, quelle politique de mot de passe appliquer, quel niveau de journalisation conserver ou quelles fonctions doivent être désactivées par défaut.
Appliquer les STIG sans bloquer la mission
Le piège consiste à voir le durcissement comme une liste de cases à cocher. Une règle de sécurité peut avoir des conséquences fonctionnelles. Désactiver un service peut casser une intégration. Renforcer une politique d’accès peut empêcher un processus automatisé de fonctionner. C’est pourquoi l’application des STIG doit être testée dans un environnement de préproduction, documentée, puis vérifiée après déploiement.
Orion Field Systems peut, par exemple, lancer un scan de conformité sur son serveur de test. Le rapport indique que plusieurs services ne sont pas requis, que les paramètres de chiffrement doivent être renforcés et qu’un compte technique dispose de droits excessifs. L’équipe corrige ces points, teste l’outil métier, puis conserve les résultats. Ce cycle est plus efficace qu’une correction précipitée en production, où chaque incident entraîne des coûts, des délais et une perte de confiance.
- Désactiver les services non indispensables afin de limiter les chemins d’attaque disponibles.
- Renforcer l’authentification avec des mots de passe robustes, une gestion des comptes et des accès adaptés au rôle.
- Chiffrer les communications pour empêcher l’interception ou l’altération des données en transit.
- Limiter les privilèges administrateur afin qu’un compte compromis ne puisse pas étendre immédiatement son impact.
- Conserver les journaux utiles pour détecter un incident, comprendre sa portée et prouver les actions menées.
eMASS : centraliser les éléments de conformité et les écarts
eMASS n’est pas une simple plateforme documentaire. C’est l’espace dans lequel les preuves peuvent être reliées à un système, à un contrôle et à une décision. Les rapports de scans, les plans de correction, les procédures, les captures de configuration et les résultats d’évaluation y trouvent une place structurée. Cette centralisation réduit les pertes d’information et limite les allers-retours inutiles avec les évaluateurs.
Une pratique efficace consiste à utiliser une matrice de traçabilité. Chaque exigence est associée à un contrôle, un responsable, une source de preuve, une fréquence de vérification et un statut. Au lieu de dire « le chiffrement est traité », l’équipe peut montrer quel paramètre a été configuré, quel scan le confirme, qui valide la mesure et à quelle date la vérification devra être renouvelée. C’est cette précision qui transforme une affirmation en élément d’audit exploitable.
La logique est proche de celle d’une entreprise qui veut fiabiliser son pilotage financier : sans outils et sans traces, les décisions reposent sur des approximations. Un logiciel de devis et de facture bien paramétré permet de retrouver une transaction, une validation et un historique ; eMASS joue un rôle comparable pour le suivi des éléments de sécurité, avec un niveau d’exigence adapté aux systèmes concernés.
Le bénéfice n’est pas seulement administratif. Une documentation maintenue permet de savoir rapidement où se trouve une faiblesse, quelle mesure compense un écart et qui doit agir. Les STIG sécurisent les configurations ; eMASS rend cette sécurité démontrable, pilotable et durable.
Préparer un dossier RMF solide pour une application, un système ou une plateforme PIT
Un dossier RMF ne se construit pas efficacement à la veille d’une revue. Lorsqu’une équipe attend le dernier moment, elle découvre souvent qu’elle ne connaît pas exactement ses actifs, que les responsabilités sont floues ou que les preuves techniques ont disparu. La bonne approche consiste à intégrer la conformité dès le cadrage produit. Cela ne ralentit pas le projet : cela évite les blocages coûteux au moment où le logiciel doit réellement être utilisé.
Le premier travail consiste à distinguer la nature de l’objet évalué. Une application commerciale standard, un système métier interne, une plateforme informatique de terrain ou une technologie opérationnelle ne présentent pas la même exposition. Les Platform IT, souvent désignées par PIT, peuvent inclure des environnements techniques spécifiques, par exemple un système de contrôle de bâtiment ou un équipement spécialisé. Leur fonctionnement, leur maintenance et leur impact potentiel demandent une lecture adaptée.
Qualifier le système avant de collectionner les documents
Beaucoup de dossiers échouent parce que les documents ne racontent pas la même histoire. L’architecture décrit un serveur qui n’existe plus, l’inventaire oublie une base de données et le plan de sécurité prévoit une journalisation que personne ne contrôle. Pour éviter cela, commence par définir une fiche d’identité claire : nom du système, objectif métier, propriétaires, utilisateurs, données traitées, connexions, dépendances et niveau de criticité.
Dans le cas d’Orion Field Systems, le dossier doit préciser si l’application fonctionne seule ou si elle communique avec un annuaire, une API externe, une base de données centrale ou un environnement de terrain. Chaque échange constitue un point à examiner. Une simple interface d’export peut devenir sensible si elle permet de récupérer des données sans contrôle d’accès robuste. Il ne s’agit pas de dramatiser chaque fonctionnalité, mais de regarder le système comme un ensemble cohérent.
| Document ou preuve | Utilité dans le dossier RMF | Responsable conseillé |
|---|---|---|
| Inventaire des actifs | Identifier logiciels, serveurs, interfaces et dépendances | Responsable technique |
| Description d’architecture | Comprendre les flux, les zones réseau et les points d’exposition | Architecte système |
| Résultats de scans | Mesurer les écarts par rapport aux exigences et prioriser les corrections | Équipe cybersécurité |
| Plan d’action et jalons | Suivre les vulnérabilités non corrigées et leurs échéances | Propriétaire système |
| Procédures d’exploitation | Prouver que les mesures sont appliquées au quotidien | Équipe opérations |
Construire une responsabilité partagée plutôt qu’un goulot d’étranglement
La conformité échoue quand elle est confiée à une seule personne. Un responsable sécurité ne peut pas connaître seul le comportement exact du produit, les priorités de la mission et les changements d’infrastructure. Le développeur, l’administrateur système, le chef de produit et le propriétaire métier doivent chacun apporter une partie de la réponse. La clé consiste à attribuer clairement les actions et à fixer une cadence réaliste.
Par exemple, le développeur traite les défauts du code et les dépendances. L’administrateur applique les configurations approuvées. Le responsable sécurité interprète les résultats de scan et gère les preuves. Le propriétaire métier arbitre les priorités lorsqu’une correction risque de perturber l’usage. Cette répartition évite l’impasse classique : tout le monde pense que quelqu’un d’autre s’occupe du problème.
Les indépendants et petites équipes y trouveront une leçon utile : la rigueur ne dépend pas de la taille de l’organisation. Une activité bien structurée sait qui valide quoi, où sont stockés les documents et comment une modification est tracée. Cette capacité à rendre le travail visible est aussi ce qui aide à booster les performances d’une organisation sans sacrifier le contrôle. Un dossier RMF solide est d’abord le reflet d’un système réellement maîtrisé, pas une pile de fichiers produite pour l’audit.
Surveillance continue RMF : maintenir l’autorisation et réduire les risques dans le temps
Une fois l’autorisation accordée, le travail ne s’arrête pas. C’est précisément le changement majeur apporté par le RMF : la sécurité doit rester alignée avec la réalité technique. Un correctif est publié, une dépendance évolue, un serveur est remplacé, une interface est ajoutée ou une nouvelle menace apparaît. Chacun de ces événements peut modifier le niveau de risque. La surveillance continue sert à détecter ces évolutions avant qu’elles ne deviennent un incident.
Le terme peut sembler intimidant, mais l’objectif est très concret. Il s’agit de savoir à tout moment quels actifs existent, quelle version ils utilisent, quels écarts sont ouverts et qui travaille sur leur correction. Une organisation ne peut pas protéger ce qu’elle ne voit pas. Un logiciel oublié, installé sur une machine secondaire, reste une cible potentielle ; une vulnérabilité connue mais non suivie peut transformer une dette technique en crise opérationnelle.
Mettre en place une cadence de contrôle réaliste
La cadence doit être adaptée à la criticité du système et aux exigences applicables. Certains environnements nécessitent des contrôles très fréquents, notamment lorsqu’ils sont exposés ou soutiennent une mission essentielle. D’autres peuvent fonctionner avec une revue plus espacée, à condition que les changements soient rigoureusement enregistrés. L’erreur serait de choisir une fréquence arbitraire qui produit des rapports sans déclencher d’action.
Pour Orion Field Systems, une routine simple peut fonctionner : revue mensuelle des résultats de vulnérabilité, contrôle après chaque mise à jour importante, vérification des comptes à privilèges, actualisation de l’inventaire et suivi des plans de correction. Lorsqu’un écart ne peut pas être résolu immédiatement, il doit être documenté. L’équipe définit alors une échéance, une mesure compensatoire et un responsable. Ignorer un défaut n’est jamais une stratégie ; l’assumer, le réduire et le suivre est une démarche de gestion des risques.
- Détecter : lancer les scans, examiner les alertes et identifier les modifications de l’environnement.
- Qualifier : déterminer l’impact réel de chaque écart sur les données, les utilisateurs et la mission.
- Corriger : appliquer un patch, modifier une configuration ou retirer un composant devenu inutile.
- Documenter : déposer les preuves, mettre à jour le plan d’action et expliquer les décisions prises.
- Vérifier : contrôler que la correction fonctionne sans créer de nouvelle fragilité.
Faire de la conformité un avantage de pilotage
Une surveillance bien conduite apporte plus qu’une réponse aux obligations. Elle donne une vision concrète de l’état du parc, des priorités techniques et des responsabilités. Les équipes peuvent repérer les composants les plus instables, prévoir les besoins de maintenance et éviter les interruptions causées par des mises à jour improvisées. Dans les environnements complexes, cette visibilité devient un véritable avantage opérationnel.
Il faut également préparer les changements majeurs avec méthode. L’ajout d’une nouvelle fonction, une migration d’hébergement ou l’ouverture d’un flux réseau ne doit pas être traité comme une formalité. Chaque changement doit déclencher une analyse d’impact : quelles données sont concernées, quels contrôles doivent être revus, quels tests seront réalisés et quelles preuves seront ajoutées à eMASS ? Cette discipline protège autant la mission que les équipes, car elle évite les décisions prises dans l’urgence.
Le basculement du Certificate of Networthiness vers le RMF Assess Only et les parcours d’autorisation associés montre une évolution claire : la confiance ne se décrète plus une fois pour toutes. Elle se construit, se vérifie et s’entretient. La conformité la plus efficace est celle qui devient une habitude de gestion, au même titre que la qualité, la disponibilité ou la continuité d’activité.
Le Certificate of Networthiness est-il encore requis en 2026 ?
Le processus historique Army CoN a été abandonné au profit de démarches alignées sur le Risk Management Framework. Selon la nature du système et son niveau de risque, les organisations suivent désormais des parcours tels qu’Assess Only ou une autorisation complète de type ATO.
Quelle est la différence entre Assess Only et une ATO complète ?
Assess Only vise des cas à impact limité, généralement pour des solutions ne manipulant pas de données sensibles et dont l’exposition reste maîtrisée. Une ATO complète est requise lorsque le système soutient une mission critique, traite des informations sensibles ou est fortement interconnecté aux réseaux DoD.
À quoi servent les STIG dans une démarche RMF ?
Les STIG fournissent des règles techniques de durcissement pour les systèmes, logiciels et équipements. Ils permettent de configurer les environnements selon des exigences de sécurité précises, puis de vérifier ces configurations avec des outils de scan et des preuves documentées.
Pourquoi utiliser eMASS pour suivre la conformité ?
eMASS centralise les contrôles, les preuves, les vulnérabilités, les plans d’action et les jalons. Cette centralisation facilite les revues, réduit les pertes d’information et permet de montrer clairement l’état de sécurité d’un système.
Comment éviter qu’un dossier RMF bloque un projet logiciel ?
Il faut intégrer l’inventaire, la catégorisation, les tests de sécurité et la collecte des preuves dès le début du projet. Une responsabilité partagée entre produit, technique, exploitation et cybersécurité évite de reconstruire les informations dans l’urgence avant l’évaluation.
