Lorsqu'un système d'information militaire doit transférer des données d'un réseau SECRET vers un réseau NON CLASSIFIÉ — ou d'un environnement compartimenté TOP SECRET vers un réseau de partenaires de coalition — il ne peut pas simplement acheminer le trafic via un pare-feu standard. La barrière de classification n'est pas un problème de contrôle d'accès résolu par la politique réseau. C'est un problème d'intégrité du contenu : l'information elle-même peut porter des marquages, des compartiments ou des éléments de données incorporés qui ne doivent pas quitter l'enclave à classification plus élevée. Le mécanisme conçu pour résoudre ce problème est la solution interdomaines (CDS), et en concevoir une correctement exige de comprendre l'architecture des filtres, la logique de filtrage par contenu, les normes de marquage et un processus d'accréditation gouvernementale qui prend généralement plus de temps que l'application qu'il protège.

Cet article explique le fonctionnement interne des filtres CDS — le modèle de moniteur de référence qui sous-tend chaque produit approuvé, la logique des règles de filtrage qui met en œuvre l'application des marquages CAPCO, les techniques d'inspection spécifiques aux protocoles pour les pipelines XML et SMTP, ainsi que le parcours d'accréditation NSA qui détermine si un déploiement est légalement autorisé à opérer. Il s'adresse aux ingénieurs et aux responsables de programme qui ont besoin de comprendre les contraintes avant de s'engager dans une architecture.

Qu'est-ce qu'une solution interdomaines et quand est-elle requise

Une solution interdomaines est un produit ou un système qui applique une politique de sécurité lorsque des données se déplacent entre des réseaux accrédités à différents niveaux de classification ou avec des contrôles d'accès incompatibles. Le terme couvre les diodes de données matérielles, les filtres bidirectionnels à base logicielle, et les combinaisons des deux. Ce qui distingue un CDS d'une passerelle réseau ordinaire, c'est qu'il opère au niveau de la couche contenu, et non de la couche paquets — il inspecte les charges utiles, lit les marquages de classification, applique des règles de filtrage structurées et prend une décision d'autorisation ou de rejet pour chaque élément de données individuellement.

Un CDS est obligatoire lorsque deux conditions sont simultanément remplies : le réseau source détient des informations à un niveau de classification supérieur à ce que le réseau de destination est accrédité à recevoir, et l'exigence opérationnelle est de transférer une partie — mais pas la totalité — de ces informations vers le réseau inférieur. Si rien ne doit jamais passer du niveau élevé au niveau bas, l'isolation physique (un entrefer) est moins coûteuse et plus sûre. Si tout ce qui se trouve sur le côté élevé peut passer du côté bas, les réseaux doivent être fusionnés ou le réseau de destination doit être réaccrédité. C'est le cas du transfert sélectif qui nécessite un CDS.

Les scénarios courants qui imposent un CDS dans les programmes de défense comprennent : le transfert de données de piste assainies d'une image opérationnelle commune (COP) SECRET vers un affichage partenaire de coalition NON CLASSIFIÉ ; la publication de produits de renseignement diffusables depuis un environnement d'analyse TS/SCI vers un réseau de diffusion SECRET ; l'alimentation de données de capteurs depuis une plateforme de collecte classifiée vers une archive non classifiée pour une conservation à long terme ; et la connexion d'un réseau national de renseignement à un réseau combiné accrédité par l'OTAN où les schémas de classification diffèrent. Dans chaque cas, le CDS est le mécanisme d'application des limites — et son accréditation est ce qui donne à l'autorité de connexion la confiance que la frontière est correctement appliquée.

L'alternative à un CDS dans certains scénarios limités est la revue manuelle : un examinateur humain lit le document, détermine qu'il peut être diffusé, puis resaisit ou rédige à nouveau le contenu sur le réseau inférieur. C'est la « solution » interdomaines d'origine et elle reste utilisée pour les transferts à faible volume et haute sensibilité où le filtrage automatisé ne peut être fiable pour détecter tout contenu sensible. Les produits CDS automatisés ne sont appropriés que lorsque le contenu est suffisamment structuré (XML marqué, SMTP avec en-têtes de classification, formats de messages bien définis) pour qu'un filtre puisse appliquer la politique de manière fiable sans jugement humain pour chaque transfert. Les textes non structurés — évaluations narratives, rapports d'analyse, estimations du commandant — nécessitent souvent encore une revue humaine avant la diffusion, même lorsqu'un filtre CDS est présent pour le transfert technique.

Pour les programmes qui doivent traiter non seulement le mécanisme de transfert mais la posture de sécurité globale de l'environnement classifié, l'architecture zéro confiance pour les logiciels de défense fournit le cadre de contrôle d'accès environnant dans lequel un CDS s'intègre.

Architectures des filtres CDS

Quatre schémas architecturaux couvrent la majorité des déploiements CDS. Chacun échange assurance sécuritaire, complexité opérationnelle et capacité contre les autres.

Diode de données matérielle. Un dispositif physique utilisant l'isolation optique ou électrique qui garantit un flux de données unidirectionnel au niveau matériel. Les électrons — et par extension les signaux — ne peuvent pas voyager dans la direction bloquée. Une diode entre un réseau classifié et un réseau non classifié garantit que même si le logiciel du côté bas est entièrement compromis, aucun signal du côté bas ne peut atteindre le côté élevé. La limitation est stricte : le protocole applicatif doit tolérer un flux unidirectionnel. Le mécanisme d'acquittement du TCP échoue sur une diode ; le streaming UDP, syslog et la réplication de fichiers via des protocoles personnalisés fonctionnent. Les diodes conviennent aux exports en bloc unidirectionnels — streaming de capteurs, réplication de journaux, distribution vidéo — où le côté élevé n'a jamais besoin de confirmation de livraison.

Filtre bidirectionnel avec processus proxy séparés. L'architecture la plus courante pour les applications nécessitant des protocoles requête-réponse. Le filtre exécute un processus proxy côté élevé et un processus proxy côté bas sans espace d'adressage partagé, système de fichiers partagé ou communication interprocessus directe entre eux. Le seul chemin du niveau élevé au niveau bas — et du niveau bas au niveau élevé — passe par le noyau du filtre, qui applique la politique de sécurité pour chaque transfert. L'application du côté élevé se connecte au proxy côté élevé ; l'application du côté bas se connecte au proxy côté bas. Du point de vue du réseau, chaque côté ne voit que son propre proxy. Le noyau du filtre est le moniteur de référence — un composant petit, formellement spécifié et évalué indépendamment dont la seule fonction est d'appliquer la politique de transfert.

Filtre de contenu. Un filtre dont le mécanisme d'application principal est l'inspection du contenu — analyse de la charge utile, extraction des marquages de classification, correspondance avec les règles de filtrage, et passage, rejet ou assainissement du contenu avant transfert. Les filtres de contenu implémentent le vocabulaire de marquage CAPCO comme langage de politique. Ils conviennent lorsque les données transférées sont structurées et bien marquées, et lorsque la politique exige un passage sélectif plutôt qu'un blocage total. La plupart des filtres bidirectionnels modernes incluent un filtre de contenu comme première étape après la séparation bidirectionnelle.

Modèle de moniteur de référence. Le principe de sécurité fondamental que toutes les architectures mettent en œuvre. Un moniteur de référence est un composant qui : arbitre chaque demande d'accès entre un sujet (l'émetteur) et un objet (l'élément de données transféré) ; est toujours invoqué (aucun transfert ne le contourne) ; est résistant à la falsification (il ne peut être modifié ou désactivé par l'un ou l'autre côté) ; et est suffisamment petit pour être formellement vérifié. Dans les termes CDS, le moniteur de référence est le noyau du filtre — et ses propriétés de résistance à la falsification et de médiation complète sont ce que les évaluateurs vérifient pendant le processus d'accréditation. Un produit CDS qui permet à des transferts de contourner le noyau du filtre dans quelque condition que ce soit — mode de maintenance, repli en charge élevée, état d'erreur — échoue à l'exigence du moniteur de référence et ne peut être accrédité pour les frontières de réseaux classifiés.

Le diagramme suivant montre l'architecture de filtre bidirectionnel avec processus proxy séparés :

  ┌──────────────────────┐          ┌──────────────────────┐
  │  SECRET Network       │          │  UNCLASSIFIED Network │
  │  (High Side)          │          │  (Low Side)           │
  │                       │          │                       │
  │  ┌─────────────────┐  │          │  ┌─────────────────┐  │
  │  │  C2 Application │  │          │  │  COP Display    │  │
  │  └────────┬────────┘  │          │  └────────▲────────┘  │
  │           │            │          │           │            │
  │  ┌────────▼────────┐  │          │  ┌────────┴────────┐  │
  │  │  High-Side Proxy│  │          │  │ Low-Side Proxy  │  │
  └──┴────────┬────────┴──┘          └──┴────────▲────────┴──┘
              │                                   │
              │         ┌─────────────────┐       │
              └────────►│  Guard Kernel   ├───────┘
                        │  (Reference     │
                        │   Monitor)      │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Filter    │  │
                        │  │ Rules     │  │
                        │  │ (CAPCO)   │  │
                        │  └───────────┘  │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Audit Log │  │
                        │  │ (Signed)  │  │
                        │  └───────────┘  │
                        └─────────────────┘
                        Physical separation
                        of proxy processes
                        No shared memory/FS

Filtrage par contenu : ce que les filtres inspectent

Le filtrage par contenu est le mécanisme qui donne aux filtres CDS leur capacité de passage sélectif. Au lieu de tout bloquer ou de tout laisser passer, un filtre de contenu lit les données, extrait les champs pertinents pour la sécurité, applique des règles de politique et prend une décision d'autorisation/rejet/assainissement par message.

Analyse des marquages CAPCO. Le fondement du filtrage par contenu dans les systèmes classifiés américains est la norme de marquage CAPCO, qui définit un vocabulaire contrôlé de jetons apparaissant dans les bannières de classification, les marques de portion et les champs de métadonnées structurées. L'analyseur CAPCO d'un filtre lit l'élément de métadonnées de classification de chaque message entrant et extrait les jetons composants. Pour un message marqué SECRET//SI//REL TO USA,GBR, l'analyseur produit : niveau de classification = SECRET ; compartiment SCI = SI ; contrôle de diffusion = REL TO ; diffusabilité = USA, GBR. Chaque jeton est ensuite vérifié par rapport à la matrice de politique pour le réseau de destination. Si la destination n'est pas accréditée pour le compartiment SI, le transfert est rejeté. Si la destination est accréditée pour le contenu REL TO GBR, le transfert est autorisé — mais le filtre vérifie quand même si un autre champ dans le corps du message porte un marquage plus élevé que celui revendiqué par le marquage au niveau du document.

Application des compartiments sensibles. L'application des compartiments SCI exige que le filtre reconnaisse l'ensemble complet des jetons de compartiment définis dans le guide de classification applicable. Les compartiments les plus courants dans les systèmes américains sont SI (Signals Intelligence), TK (Talent Keyhole, imagerie spatiale), HCS (Humint Control System) et G (Gamma, sous-compartiment de SI). Chacun doit être vérifié individuellement par rapport à l'accréditation de compartiment de l'enclave de destination. Un réseau de destination accrédité pour SI mais pas pour TK ne doit pas recevoir de messages portant le marquage TK — même si le niveau de classification au niveau du document est dans la plage autorisée.

Application des marques de portion. Un document classifié contient souvent des paragraphes, sections ou éléments de données avec différents niveaux de sensibilité. CAPCO exige que chaque portion porte son propre marquage. Un filtre appliquant les marques de portion doit analyser non seulement la bannière au niveau du document mais aussi chaque balise (S//SI) ou (U//FOUO) au niveau du paragraphe et prendre une décision de politique distincte pour chacune. L'assainissement — suppression des portions qui échouent à la politique tout en transmettant le reste — est plus complexe qu'un rejet global mais est opérationnellement essentiel pour les documents à contenu mixte.

Suppression des pièces jointes. Les messages SMTP et les charges utiles HTTP multipart portent fréquemment des pièces jointes que le filtre doit inspecter indépendamment du corps du message. Chaque partie de pièce jointe est analysée séparément : le type de contenu MIME détermine l'analyseur à utiliser, la pièce jointe est inspectée pour les métadonnées de classification intégrées (propriétés du document PDF, propriétés personnalisées Word, champs EXIF d'image), et la politique est appliquée à chaque pièce jointe individuellement. Les pièces jointes dans des formats que le filtre ne peut pas analyser — formats binaires non reconnus, archives chiffrées — sont rejetées par défaut, jamais transmises sans inspection.

L'interaction entre l'application des marquages CAPCO au niveau de la couche CDS et le modèle de données sous-jacent est décrite en détail dans l'article sur la fusion de données militaires expliquée, qui couvre la propagation de la classification dans une base de données de piste multi-sources. Pour les environnements OTAN, la liaison entre les marquages équivalents CAPCO et la norme d'étiquetage de confidentialité OTAN est couverte dans la référence d'implémentation d'étiquetage STANAG 4774/4778.

Formats de données et protocoles pris en charge par les produits CDS modernes

Un filtre CDS n'est utile qu'en proportion de sa prise en charge des formats réellement utilisés par votre application. L'analyseur du filtre doit comprendre le format suffisamment en profondeur pour extraire les champs de classification et inspecter le contenu — une inspection superficielle des en-têtes n'est pas suffisante.

Format / Protocole Emplacement du champ de classification Usage militaire typique Complexité d'inspection du filtre
XML (IC-ISM / UCORE) Attributs d'espace de noms sur l'élément racine et chaque portion classifiée Messages de piste, produits de renseignement, rapports NiemXML Élevée — évaluation XPath complète avec connaissance du schéma
JSON avec métadonnées ISM Champ ism:classification de premier niveau ou objets de marquage intégrés Charges utiles d'API REST, microservices C2 modernes Moyenne — dépendante du schéma, inspection récursive nécessaire
SMTP / MIME En-tête X-Classification: + bannière du corps + marquage par pièce jointe Diffusion de produits de renseignement, distribution de SITREP Élevée — analyse MIME récursive, détection du type de pièce jointe
HTTP/HTTPS (REST) En-tête personnalisé + corps de la charge utile Appels API entre services classifiés et non classifiés Moyenne — terminaison TLS + réinspection du contenu requise
MTF (Message Text Format) Champ CLASSIFICATION dans l'ensemble d'en-têtes du message Messagerie militaire OTAN/héritée, USMTF, ADatP-3 Moyenne — format à champs fixes, analyse bien spécifiée
PDF / Documents Office Propriétés de document personnalisées, métadonnées XMP, texte de bannière dans le corps Produits de renseignement finalisés, ordres, plans Très élevée — objets intégrés, macros, suppression de métadonnées requise
Vidéo (RTP/RTSP) En-têtes de métadonnées de flux (si présents) ; texte de superposition au niveau trame Liaison descendante vidéo ISR, flux UAV Très élevée — nécessite généralement diode + proxy vidéo dédié

Pour les messages militaires à base XML, les règles de filtrage sont exprimées en XPath. Une règle qui rejette tout message portant un jeton de compartiment TK ressemble à :

<!-- Guard filter rule: reject if TK compartment is present -->
<FilterRule id="REJ-TK-001" action="REJECT">
  <Description>Reject messages carrying Talent Keyhole (TK) compartment</Description>
  <Condition>
    <XPathExpression>
      //*[contains(
        translate(
          @ism:SCIcontrols,
          'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
          'abcdefghijklmnopqrstuvwxyz'
        ),
        'tk'
      )]
    </XPathExpression>
  </Condition>
  <AuditMessage>Transfer rejected: TK compartment detected in payload</AuditMessage>
</FilterRule>

<!-- Sanitization rule: strip SI-marked portion elements before forwarding -->
<FilterRule id="SAN-SI-001" action="SANITIZE">
  <Description>Strip SI-marked portions from otherwise-releasable documents</Description>
  <Condition>
    <XPathExpression>//*[@ism:SCIcontrols='SI']</XPathExpression>
  </Condition>
  <SanitizeAction>REMOVE_ELEMENT</SanitizeAction>
  <AuditMessage>Sanitized: SI-marked element removed from document</AuditMessage>
</FilterRule>

Approbation et processus d'accréditation NSA

Un filtre CDS protégeant une connexion entre deux réseaux classifiés du gouvernement américain doit être approuvé par NSA/CSS avant d'opérer. Il n'existe pas de voie dérogatoire pour l'urgence opérationnelle — déployer un CDS non approuvé est un incident de sécurité à signaler. Comprendre le processus d'accréditation et son calendrier est un prérequis pour tout programme qui inclut une frontière classifiée.

Liste de produits évalués NSA/CSS (EPL). La NSA évalue les produits CDS et publie les résultats sur la liste de produits évalués (EPL). Une inscription sur l'EPL certifie qu'une version spécifique d'un produit, dans une configuration spécifique, implémente correctement le modèle de moniteur de référence et résiste aux classes d'attaques que les évaluateurs ont testées. L'inscription sur l'EPL spécifie le modèle matériel exact et la version du firmware, la version logicielle et les options de configuration qui ont été évaluées. Dévier de la configuration évaluée — même appliquer un correctif de système d'exploitation qui ne faisait pas partie de la référence évaluée — nécessite une réévaluation ou une autorisation de dérogation. Les programmes doivent suivre quelle version EPL correspond à leur filtre déployé et maintenir cette correspondance tout au long de la vie opérationnelle du filtre.

Initiative Raise the Bar (RTB). Suite à une série d'incidents dans lesquels des filtres mal conçus ont permis à des données de passer de manière incorrecte, NSA/CSS a émis les exigences Raise the Bar pour les produits CDS. RTB impose la séparation matérielle des chemins de traitement côté élevé et côté bas, la documentation formelle de chaque règle de filtrage et de sa justification sécuritaire, des journaux d'audit signés cryptographiquement (de sorte que la falsification des journaux soit détectable), la vérification indépendante par un tiers de la logique du filtre, et une procédure de correction définie incluant une re-vérification après les modifications pertinentes pour la sécurité. Les produits conformes RTB sont répertoriés sur l'EPL avec une désignation RTB explicite. Les produits non RTB peuvent encore figurer sur d'anciennes listes EPL mais ne peuvent plus être nouvellement approuvés pour les frontières de réseaux classifiés du gouvernement américain.

Liste de produits approuvés pour les capacités unifiées DISA (UC APL). Pour les programmes DoD, l'inscription sur la liste UC APL de DISA est requise en plus de l'EPL NSA. L'évaluation UC APL se concentre sur l'interopérabilité avec l'infrastructure réseau DoD et la conformité aux guides de mise en œuvre technique de sécurité (STIGs) du DoD. Un produit peut être sur l'EPL NSA mais pas sur l'UC APL, ou vice versa — les deux sont requis pour la plupart des déploiements de réseaux classifiés DoD. Vérifiez les deux listes lors de l'évaluation des produits CDS candidats.

Autorisation d'opérer (ATO) spécifique au site. Même avec un produit EPL/UC APL, chaque déploiement nécessite une ATO spécifique au site qui couvre : la configuration matérielle et logicielle spécifique déployée ; la topologie réseau et la sécurité physique de l'installation du filtre ; l'ensemble de règles de filtrage et sa relation avec les politiques de classification des réseaux connectés ; les procédures de surveillance continue ; et le processus de gestion des correctifs et de contrôle des modifications de configuration. Le dossier ATO est examiné par le responsable de l'autorisation (AO) pour les systèmes des deux côtés de la frontière. Pour les connexions entre réseaux appartenant à différentes agences, un accord bilatéral entre les deux AO est requis avant que l'ATO puisse être accordée. Délai : 6 à 18 mois pour un produit déjà sur l'EPL dans une configuration non compliquée.

Schémas d'intégration pour les pipelines C2 et ISR

L'intégration d'un filtre CDS dans un pipeline C2 ou ISR opérationnel nécessite de réfléchir à la fois à l'architecture du flux de données et aux contraintes de performance que le filtre introduit.

Le schéma COP SECRET vers NON CLASSIFIÉ. L'intégration la plus courante est un pipeline de publication-abonnement où un courtier SECRET alimente des mises à jour de piste classifiées, et un filtre CDS s'abonne au courtier SECRET, inspecte chaque mise à jour et re-publie des mises à jour assainies vers un courtier NON CLASSIFIÉ auquel les partenaires de coalition ou les consommateurs du côté bas s'abonnent. Le filtre dans cette architecture agit comme un abonné filtrant du côté élevé et un producteur publiant du côté bas — jamais comme un routeur de passage direct. Cela garantit qu'aucune connexion directe n'existe entre les deux courtiers.

SECRET Network                     UNCLASSIFIED Network
─────────────                      ────────────────────

┌─────────────┐   track updates   ┌─────────────────────────────┐
│ SECRET      │ ─────────────────►│     CDS Guard               │
│ Message     │                   │                             │
│ Broker      │                   │  High-Side     Low-Side     │
│             │                   │  Subscriber    Publisher    │
│             │                   │      │              │       │
│             │                   │      ▼              │       │
│             │                   │  CAPCO Filter       │       │
│             │                   │  SI/TK/HCS check    │       │
│             │                   │  Sanitize/Reject     │       │
│             │                   │      │              │       │
│             │                   │      └──────────────►       │
└─────────────┘                   └─────────────────────────────┘
                                               │
                                               ▼ sanitized updates
                                   ┌───────────────────┐
                                   │ UNCLASSIFIED      │
                                   │ Message Broker    │
                                   └─────────┬─────────┘
                                             │
                                             ▼
                                   ┌───────────────────┐
                                   │ Coalition COP /   │
                                   │ UNCLASSIFIED      │
                                   │ Display           │
                                   └───────────────────┘

Planification de la latence. Un filtre CDS introduit une latence de traitement pour chaque message qu'il inspecte. Pour les petits messages XML de mise à jour de piste (moins de 4 Ko), les filtres commerciaux ajoutent généralement 50 à 200 millisecondes de latence d'inspection. Pour les grands messages portant des pièces jointes binaires ou nécessitant l'assainissement de plusieurs portions, la latence peut atteindre 500 millisecondes à 2 secondes. Pour les documents PDF ou les messages MIME complexes, le traitement peut prendre plusieurs secondes. Cela doit être pris en compte dans le taux de rafraîchissement de la COP et le SLA pour la diffusion des produits de renseignement. Les performances nominales des filtres sont publiées dans la documentation EPL — vérifiez que les performances nominales à la taille et à la complexité des messages de votre application sont suffisantes avant de vous engager sur un produit.

Chemins de données des capteurs ISR. Pour les capteurs ISR opérant au niveau classifié qui doivent alimenter des consommateurs à classification inférieure, le chemin de données implique généralement une étape de traitement classifiée qui produit des produits dérivés assainis, qui traversent ensuite la frontière CDS. Les données brutes de capteurs (imagerie pleine fidélité, interceptions SIGINT brutes) ne doivent jamais être conçues pour passer par un filtre CDS — la classification des données ISR brutes est généralement bien au-dessus de ce que le côté bas peut recevoir, et le filtrage par contenu des données brutes de capteurs est peu fiable. Le schéma de conception est : traiter au niveau de classification des données, produire des produits dérivés dépouillés des indicateurs de source sensibles, et ne transférer que les produits dérivés à travers le filtre.

Sécurité opérationnelle des déploiements CDS

Un filtre CDS est une cible de haute valeur précisément parce que le compromettre équivaut à éliminer la frontière classifiée. Les contrôles de sécurité opérationnelle autour d'un filtre déployé doivent être proportionnels à ce risque.

Sécurité physique. Le matériel du filtre doit être installé dans un emplacement physiquement sécurisé — une salle d'équipement verrouillée avec entrée contrôlée et journalisation des accès. La connexion réseau côté élevé et le matériel du filtre doivent se trouver dans le périmètre de sécurité physique du réseau à classification plus élevée. La falsification du filtre — insertion d'un dispositif de canal caché sur la connexion réseau, remplacement du firmware — est une menace réelle que les contrôles physiques adressent.

Gestion hors bande. L'interface de gestion du filtre doit être sur un réseau physique dédié séparé des réseaux opérationnels côté élevé et côté bas. Le trafic de gestion — modifications de configuration, mises à jour logicielles, récupération des journaux — qui transite par l'un ou l'autre réseau opérationnel crée un vecteur de canal caché. Les postes de travail de gestion doivent être situés dans le périmètre de sécurité de classification plus élevée et accrédités en conséquence.

Intégrité des journaux et détection de falsification. Les journaux d'audit CDS sont la preuve principale que la frontière a été correctement appliquée. Les journaux doivent être protégés cryptographiquement — chaque enregistrement de journal comprend un HMAC sur le contenu de l'enregistrement et le hachage de l'enregistrement précédent (une chaîne de hachage). Cela rend l'insertion, la suppression ou la modification de tout enregistrement détectable lors de la vérification de la chaîne. Les journaux doivent être écrits sur un système sur lequel ni le réseau côté élevé ni le réseau côté bas ne peuvent écrire ou supprimer — un serveur de journaux dédié accessible uniquement à l'administrateur de sécurité via le réseau de gestion hors bande. La revue des journaux doit être une activité active et quotidienne : les anomalies de rejet, les volumes inhabituels de messages ou les violations répétées de politique par le même émetteur sont des indicateurs de sondage ou d'attaque.

Contrôle des modifications de configuration. Chaque modification de l'ensemble de règles de filtrage — ajout d'une règle, modification d'une condition, suppression d'une règle — doit passer par un processus de modification documenté qui comprend : une demande de modification écrite avec justification sécuritaire ; revue indépendante par un second officier de sécurité ; exécution des tests sur l'échantillon de trafic représentatif ; et audit post-modification des premières 24 heures de décisions de production pour vérifier que la règle se comporte comme prévu. Les modifications qui n'ont pas suivi ce processus ne doivent pas être appliquées aux configurations de filtres en production. Un gel permanent des modifications doit s'appliquer pendant les périodes opérationnelles à tempo élevé lorsqu'une erreur de configuration du filtre serait la plus dommageable.

Gestion des correctifs. Les correctifs de sécurité pour le système d'exploitation et l'application du filtre nécessitent une gestion soigneuse. Appliquer un correctif qui ne fait pas partie de la configuration évaluée peut invalider l'ATO — et ne pas appliquer les correctifs de sécurité crée des vulnérabilités exploitables. La procédure est : recevoir et évaluer le correctif ; déterminer s'il affecte la référence de configuration évaluée ; si c'est le cas, consulter le fournisseur EPL et obtenir une autorisation de dérogation d'évaluation ou planifier une réévaluation ; tester le correctif dans un environnement de filtre isolé qui reproduit la production ; appliquer en production pendant une fenêtre de maintenance planifiée avec brève interruption de service ; vérifier que le comportement des règles de filtrage est inchangé après l'application du correctif.

Tests de l'équipe rouge. Des tests de pénétration annuels de l'installation CDS doivent être une exigence du plan de sécurité. Le périmètre du test doit inclure : tentatives d'extraction de contenu classifié via l'interface côté bas en utilisant des attaques par injection de format et d'encodage ; tentatives d'exploitation de canaux cachés via des canaux temporels, de stockage et de niveau protocole ; tentatives d'accès à l'interface de gestion du filtre depuis les réseaux opérationnels ; et scénarios de falsification physique tentés. Les résultats des tests de l'équipe rouge alimentent directement le rapport de surveillance continue et peuvent déclencher des modifications de configuration ou une réévaluation.

Point clé : Le mode de défaillance opérationnelle le plus courant dans les déploiements CDS n'est pas une lacune dans les règles de filtrage — c'est la dérive de configuration. Un filtre déployé et accrédité dans une configuration définie s'écarte progressivement de cette configuration via des correctifs non autorisés, des modifications de règles ad hoc et des substitutions de composants matériels. Après 18 mois d'opération sans audit de configuration formel, la plupart des filtres fonctionnent dans une configuration qui n'a jamais été évaluée. Intégrez les audits de configuration dans le calendrier opérationnel dès le début.