Protection CUI : Gestion sécurisée des informations non classifiées contrôlées

Les informations non classifiées contrôlées (CUI) sont des informations sensibles mais non classifiées qui nécessitent des mesures de protection ou de diffusion selon la loi fédérale, les règlements ou la politique gouvernementale générale. Pour les agences fédérales et les contractants dans les secteurs de la défense, de l'énergie, de la santé et d'autres secteurs réglementés, l'obligation de gérer correctement les CUI entraîne d'importantes implications en matière de conformité et contractuelles.

Pourtant, de nombreuses organisations manquent encore des procédures, des contrôles système et de la visibilité nécessaires pour répondre aux exigences fédérales. Avec la mise en œuvre de CMMC Phase 1 en cours et le gouvernement qui se dirige vers des exigences plus uniformes pour la gestion des contractants via la règle FAR CUI, la conformité CUI n'est plus une aspiration. C'est un prérequis contractuel.

Les organisations qui ne peuvent pas démontrer des contrôles appropriés d’identification, de marquage, de protection et de diffusion pour CUI risquent des constats d’audit défavorables, des retards de contrat et une perte d’éligibilité pour les futures attributions.

Ce guide explique ce qu’est réellement le CUI, à quoi ressemblent les exigences de protection et comment élaborer une approche pratique pour le gérer en toute sécurité.

Qu'est-ce que les informations non classifiées contrôlées (CUI) ?

Les informations non classifiées contrôlées sont des informations créées ou détenues par le gouvernement fédéral, ou qu'une entité crée ou détient pour le compte du gouvernement, qui nécessitent des mesures de protection ou des contrôles de diffusion conformes aux lois, règlements et politiques gouvernementales applicables.

En tant que catégorie formelle d'information, CUI a été établie par Executive Order 13556 et codifiée dans 32 CFR Part 2002. Elle a remplacé un patchwork d’anciennes marques telles que FOUO, LES et SBU par un cadre unique et cohérent pour la protection des informations sensibles mais non classifiées au sein des agences fédérales et de leurs sous-traitants.

Un principe clé sous-tend l’ensemble du programme : seules les informations nécessitant une protection conformément à la loi fédérale, à un règlement ou à une politique gouvernementale générale peuvent être désignées comme CUI. Les agences ne peuvent pas créer des catégories CUI basées uniquement sur une préférence administrative.

CUI se divise en deux catégories de gestion :

• CUI de base est le paramètre par défaut. Il applique des normes uniformes du 32 CFR Partie 2002 à tout CUI sauf si le Registre CUI de la NARA annote spécifiquement une catégorie comme CUI Spécifié. Les marques de bannière ressemblent à CUI ou CUI//PRVCY.
• CUI Spécifié s'applique lorsque la loi ou le règlement autorisant contient des contrôles spécifiques de gestion qui diffèrent des valeurs par défaut de CUI Basic. Ces catégories portent un préfixe "SP-", comme CUI//SP-CTI.

La différence concerne la source des contrôles, pas le niveau de sensibilité ; CUI Basic comble les lacunes lorsque l'autorité spécifique est silencieuse.

Le NARA CUI Registry est la source faisant autorité, couvrant plus de 125 catégories. C’est là que les sous-traitants doivent se rendre pour déterminer la classification, le marquage et la gestion appropriés de tout CUI qu’ils rencontrent.

Exemples courants de CUI

Toutes les données sensibles ne sont pas des CUI ; elles doivent être liées à une autorité répertoriée dans le Registre CUI. Voici des exemples courants de CUI dans les principales catégories :

• Défense (CTI) : Les informations techniques contrôlées (CTI) comprennent les schémas techniques, les documents de conception système et le code source développés pour des applications militaires, marqués CUI//SP-CTI sous l'autorité de DFARS 252.204-7012.
• Contrôle des exportations : Les dessins techniques pour les articles de défense figurant sur la U.S. Munitions List et les données techniques soumises à une licence d'exportation sont couverts par les catégories de contrôle des exportations du registre CUI.
• Forces de l'ordre : Les informations sur les casiers judiciaires, les profils ADN et les données d'identification des informateurs figurent dans les catégories CUI liées aux forces de l'ordre.
• Confidentialité : Les numéros de sécurité sociale, numéros de comptes financiers, données biométriques et HIPAA couvertes par des informations de santé sont traitées dans les catégories CUI liées à la confidentialité/santé.
• Infrastructure critique : Les informations sur les vulnérabilités liées au terrorisme chimique, les informations sur les infrastructures énergétiques critiques et les informations sur les vulnérabilités des systèmes d'information apparaissent dans les catégories d'infrastructure critique.

Ces exemples sont représentatifs, non définitifs. Validez toujours la catégorie spécifique, l'autorité et les marquages requis dans le Registre CUI et le langage de votre contrat avant de définir les règles de gestion.

Exigences clés pour la protection du CUI

Protéger la CUI ne se limite pas à verrouiller les fichiers. Cela inclut le marquage, la protection physique et numérique, ainsi que le contrôle de qui peut accéder et partager les informations. Chacune de ces zones comporte des exigences fédérales spécifiques, et une faille dans l'une d'elles peut compromettre l'ensemble de votre posture de conformité. Voici ce que vous devez bien gérer dans les trois piliers principaux de la protection.

Marquage et étiquetage des CUI

Des marquages incohérents sont l'une des façons les plus rapides d'échouer à une évaluation de conformité. Les marquages pilotent toute la chaîne de gestion du CUI : ils indiquent aux détenteurs autorisés qui peut accéder à l'information, comment elle peut être partagée et quelles protections s'appliquent.

Exemples de marquage standard :

• CUI de base sans catégorie : CUI
• CUI spécifié : CUI//SP-CTI
• CUI spécifié avec contrôle de diffusion : CUI//SP-SGI//FEDONLY

En pratique, des marquages précis sur les bannières ainsi qu'un étiquetage cohérent en aval (sujets des emails, en-têtes de fichiers, feuilles de couverture et dépôts) sont ce qui empêche la CUI de fuir vers des canaux non contrôlés.

Chaque document CUI doit inclure un indicateur de désignation identifiant l’agence de contrôle. Les directives recommandent également d’appliquer des marquages de bannière CUI dans les lignes d’objet et le corps des messages électroniques lorsque les courriels contiennent du CUI.

Environnements sécurisés et contrôlés

Les CUI doivent être traitées dans des environnements contrôlés avec des contrôles d'accès et des protections contre la visualisation ou l'écoute non autorisées.

NIST SP 800-171 Rev. 1 a établi la référence : la valeur d'impact sur la confidentialité pour CUI n'est pas inférieure à FIPS 199 modéré. Selon FIPS 199, modéré signifie que la perte de confidentialité « pourrait avoir un effet négatif sérieux sur les opérations organisationnelles, les actifs organisationnels ou les individus ».

Les organisations doivent décrire la limite de leur système CUI dans un Plan de Sécurité du Système (SSP), y compris l'environnement d'exploitation, la manière dont les exigences sont mises en œuvre, et les connexions avec d'autres systèmes.

Les exigences en matière de sécurité physique incluent la limitation de l'accès aux personnes autorisées, l'accompagnement des visiteurs, la tenue des journaux d'audit d'accès et la mise en œuvre de mesures de protection sur les sites de travail alternatifs.

Contrôle d'accès et contrôles de diffusion

L'accès à CUI suit un principe clair : seuls les utilisateurs autorisés ayant un besoin légitime de savoir et une formation appropriée peuvent y accéder.

NIST SP 800-171 Rev. 3 a renforcé la gestion des comptes pour exiger la définition des types de comptes autorisés, l'autorisation d'accès basée sur un besoin valide et une utilisation prévue, ainsi que la surveillance continue de l'utilisation des comptes système.

Conformément à 32 CFR 2002.16, la diffusion doit respecter les lois ayant établi la catégorie CUI, poursuivre un objectif gouvernemental légal et ne pas être restreinte par un contrôle de diffusion limitée autorisé.

Avant de partager des CUI avec des parties externes, vérifiez que le destinataire a un besoin légitime de savoir, comprend les exigences relatives aux CUI et peut protéger correctement les informations.

La formation est également importante ici. La règle FAR CUI de janvier 2025 établit que les contractants ne peuvent pas permettre à un employé de gérer des CUI à moins que cet employé n'ait suivi une formation appropriée, et les contractants doivent fournir une preuve de formation sur demande.

CUI et cadres de cybersécurité

Les obligations de protection CUI n'existent pas dans un vide. Elles s'inscrivent dans une pile en couches de cadres fédéraux de cybersécurité qui traduisent les exigences politiques en contrôles de sécurité spécifiques et auditable.

Comprendre comment ces cadres se connectent est essentiel pour construire un environnement conforme, surtout lorsque différents contrats font référence à différentes révisions ou bases de référence.

NIST SP 800-171 et CUI

NIST SP 800-171 traduit les obligations de protection CUI en exigences de sécurité spécifiques pour les systèmes non fédéraux. La version actuelle, Rev. 3, contient 97 exigences de sécurité réparties en 17 familles de contrôles. La Rev. 2 comptait 110 exigences réparties en 14 familles.

Les domaines clés qui affectent directement la gestion des CUI incluent :

• Contrôle d'accès : gestion des comptes, moindre privilège, séparation des tâches, contrôle du flux d'informations
• Audit et responsabilité : journaux d'audit capturant le type d'événement, le moment, la source, le résultat et l'identité ; conservation conforme aux exigences de l'organisation et du contrat
• Réponse aux incidents : capacité opérationnelle de gestion, suivi et test à la fréquence définie par l'organisation
• Protection des supports : assainissement avant élimination, protection cryptographique pendant le transport

Pris ensemble, ces domaines définissent les contrôles opérationnels quotidiens que les auditeurs recherchent lorsqu'ils évaluent si la gestion des CUI est réellement appliquée, et pas seulement documentée.

Niveaux d'impact FIPS 199 et CUI

La cascade de conformité fonctionne ainsi : FIPS 199 catégorise les niveaux d’impact, FIPS 200 définit les exigences minimales de sécurité, et la sélection des contrôles est tirée des référentiels de contrôle de sécurité NIST. Ces référentiels sont ensuite adaptés dans NIST SP 800-171 pour les organisations non fédérales traitant des CUI.

Les implications pratiques sont importantes :

• Hébergement cloud : Pour les systèmes CUI dans les environnements cloud, FedRAMP Moderate est largement considéré comme la base minimale appropriée pour les systèmes d'information à impact modéré.
• Chiffrement : Les modules cryptographiques doivent être validés FIPS 140-2, pas seulement utiliser des algorithmes approuvés par FIPS. Les directives CMVP du NIST notent également que la cryptographie non validée est considérée comme ne fournissant aucune protection.
• Protections réseau : La base modérée couvre le contrôle d'accès, la protection des frontières, la séparation du réseau, la confidentialité et l'intégrité des transmissions, ainsi que la surveillance du réseau.

Pour les CUI associés à des programmes critiques ou des High Value Assets, le NIST SP 800-172 fournit des exigences de sécurité renforcées, mais celles-ci ne s'appliquent que lorsqu'elles sont explicitement désignées dans le langage du contrat.

Bonnes pratiques pour gérer les CUI en toute sécurité

Les meilleures pratiques suivantes traduisent les obligations de conformité CUI en étapes concrètes que votre équipe peut mettre en œuvre, depuis la découverte initiale des données jusqu’à la gouvernance des accès, le chiffrement et la réponse aux incidents.

1. Identifier et classer précisément le CUI

Seules les agences fédérales peuvent désigner les informations comme CUI. Lorsque les entrepreneurs rencontrent un CUI potentiellement non marqué, ils doivent le signaler à l’agent contractant pour une détermination officielle, et ne pas le marquer eux-mêmes. La règle FAR CUI exige de signaler la découverte d’un CUI potentiel dans les huit heures.

Commencez par une revue contrat par contrat. Cartographiez les catégories CUI spécifiées dans chaque contrat par rapport à vos flux d'informations réels. Les échecs courants de délimitation incluent :

• Systèmes manquants : négligeant les systèmes qui traitent les CUI en dehors de votre environnement principal
• Angles morts des tiers : ne pas prendre en compte les prestataires qui manipulent les CUI pour votre compte
• Shadow IT : en oubliant les outils de collaboration et les services cloud, où la CUI peut se retrouver

La formation est tout aussi importante et doit se dérouler à trois niveaux :

• Sensibilisation universelle : pour toute personne susceptible de rencontrer des CUI
• Formation spécifique au rôle : pour les employés qui manipulent régulièrement des CUI
• Formation technique avancée : pour les administrateurs système gérant des environnements CUI

Cet investissement dans la formation est crucial car le facteur humain reste une vulnérabilité majeure ; selon le Netwrix 2024 Hybrid Security Trends Report, 47 % des professionnels IT citent les erreurs et la négligence des employés comme un défi majeur en matière de sécurité.

Le défi de la découverte est tout aussi répandu ; une enquête de 2025 SANS Attack Surface Management (ASM) Survey parrainée par Netwrix a révélé que seulement 28 % des organisations estiment que leurs plateformes ASM identifient efficacement les fichiers sensibles, tandis que 41 % supplémentaires déclarent qu'elles le font seulement partiellement.

C’est là que les outils font une réelle différence. Par exemple, First National Bank Minnesota a utilisé Netwrix Auditor et Netwrix Data Classification pour découvrir, classer et déplacer des données sensibles vers des emplacements sécurisés, et a terminé une reconstruction d’Active Directory en 3 semaines au lieu de 6 mois.

2. Gérer l'accès au niveau de l'objet

Les autorisations au niveau des dossiers et des sites ne sont pas assez granulaires pour le CUI. NIST SP 800-171 reconnaît que les mécanismes d'application des accès peuvent être mis en œuvre au niveau des applications et des services pour renforcer la protection du CUI.

Le contrôle d'accès basé sur les attributs (ABAC), tel que défini dans le NIST SP 800-162, évalue les attributs de l'utilisateur, des données et de l'environnement par rapport aux règles de politique définies à chaque demande d'accès. L'avantage pour le CUI est le moindre privilège dynamique :

• Changements de rôle : lorsque la mission assignée à quelqu'un change, son accès au CUI dont il n'a plus besoin est automatiquement révoqué via les attributs de sujet mis à jour
• Modifications de classification : lorsque la classification des données change, les restrictions d’accès s’ajustent pour tous les utilisateurs concernés sans reconfiguration manuelle

3. Chiffrez la CUI en transit et au repos

NIST SP 800-171 exige le chiffrement des CUI transmises ou stockées en dehors des environnements contrôlés. Dans les environnements protégés, d’autres mesures de sécurité peuvent satisfaire à l’exigence, mais toute CUI quittant cette limite doit être chiffrée

L'exigence critique est que les modules de chiffrement doivent être validés FIPS 140-2, avec les numéros de certificat documentés. Utiliser simplement AES-256 ne suffit pas si le module spécifique n'a pas passé le programme de validation des modules cryptographiques du NIST.

La gestion des clés mérite une attention égale, elle doit donc être considérée comme une infrastructure fondamentale, et non comme une réflexion secondaire.

4. Surveiller, enregistrer et répondre aux incidents

NIST SP 800-171 exige des enregistrements d’audit capturant le type d’événement, le moment, le lieu, la source, le résultat et l’identité associée. Les actions des utilisateurs individuels doivent être traçables de manière unique, et la conservation des enregistrements d’audit doit être conforme aux exigences définies par l’organisation et le contrat.

Dans la gestion des incidents, les délais se resserrent. Différentes obligations de déclaration s'appliquent selon votre secteur :

• Règle FAR CUI : une fenêtre de huit heures pour signaler les incidents suspects ou confirmés de CUI
• DFARS 252.204-7012: Les contractants du DoD rapportent via DIBNet
• CIRCIA: les entités d'infrastructure critique signalent à CISA dans les 72 heures

Respecter ces délais nécessite des capacités médico-légales et des procédures d'enquête préétablies, pas seulement la détection.

La corrélation des données d'activité avec les autorisations d'accès porte ses fruits ici. Dans le monde réel, même un pic suspect dans les modifications de fichiers peut devenir une course de plusieurs jours si votre équipe doit reconstituer les réponses à partir de journaux déconnectés.

Comment Netwrix aide les organisations à protéger les CUI

Aucun processus ou liste de contrôle unique ne permet de garantir la conformité CUI du jour au lendemain. Le défi pour les sous-traitants est de relier les points entre la découverte des données, la gouvernance des accès et la préparation à l’audit, sans assembler des outils déconnectés qui laissent des lacunes qu’un évaluateur pourrait trouver.

Si votre environnement fonctionne sur une infrastructure Microsoft avec un mélange de serveurs de fichiers sur site, Active Directory et Microsoft 365, vous avez besoin d'une plateforme qui couvre tout cela depuis un seul endroit.

La plateforme 1Secure offre une découverte automatisée à travers les systèmes de fichiers, bases de données, plateformes de collaboration et stockage cloud, afin que vous puissiez trouver les données pertinentes pour le CUI avant un évaluateur.

Il peut mettre en quarantaine des fichiers sensibles dans des emplacements non sécurisés, les déplacer vers des zones sécurisées, supprimer les permissions excessives et intégrer des étiquettes de classification dans les fichiers, transformant des semaines d'inventaire manuel en un processus automatisé et répétable.

Mais la découverte seule ne suffit pas. La question plus difficile est : qui peut accéder à ces données, cet accès est-il approprié, et pouvez-vous le prouver ? La plateforme 1Secure rapporte des objets de données sensibles surexposés, des structures de permissions détaillées sur le contenu classifié, et l’activité liée aux fichiers et dossiers sensibles.

Cela signifie que vous pouvez identifier où se trouve le CUI avec des autorisations excessives et remédier avant que cela ne devienne une constatation d’audit.

Netwrix Endpoint Protector étend cette couverture au niveau des points de terminaison, empêchant les CUI de quitter les environnements contrôlés via des canaux non autorisés. Il bloque les transferts vers des périphériques USB non approuvés, surveille et contrôle les téléchargements via les navigateurs, les clients de messagerie et les applications de stockage cloud. Il applique également le chiffrement sur les supports amovibles approuvés, répondant directement aux risques d'exfiltration que les exigences de gestion des CUI sont conçues pour prévenir.

Les rapports de conformité préconçus montrent qui a accédé aux données, ce qui a changé et quand, tandis que la recherche interactive vous aide à répondre aux questions des auditeurs en quelques minutes plutôt qu’en plusieurs jours.

Demandez une démo de Netwrix pour voir comment une plateforme vous aide à découvrir, protéger et prouver la conformité pour CUI dans votre environnement hybride.