Comment une gouvernance fragmentée met en danger les données contrôlées

La plupart des sous-traitants de la défense ne disposent pas d’une seule politique de gouvernance des données. Ils en ont plusieurs : une pour les systèmes de programmes, une autre pour les e-mails, une différente encore pour le partage de fichiers, et souvent aucune politique cohérente pour le canal le plus récent, les outils d’ingénierie assistés par l’IA. Chaque politique a été élaborée par une équipe différente, à une période différente, selon des exigences distinctes. Individuellement, chacune semble raisonnable. Ensemble, elles laissent des failles que personne n’a conçues volontairement et que peu de personnes peuvent identifier.

Ces failles ne restent pas théoriques bien longtemps. Les informations CUI classées comme sensibles dans un dossier protégé peuvent circuler librement en pièce jointe d’un e-mail dès qu’un utilisateur la transfère, car la politique du dossier ne suit pas le fichier en dehors de celui-ci. Un jeu de données bloqué pour le partage externe dans un système peut sortir via une intégration que personne n’a pensé à couvrir. Cet article explique pourquoi gérer chaque canal séparément garantit l’existence de ces failles pour les sous-traitants de la défense, et ce qu’il faut réellement faire pour les combler.

Résumé exécutif

La gouvernance des données chez les sous-traitants de la défense, construite canal par canal, aboutit inévitablement à une protection incohérente, car chaque outil a été conçu et configuré indépendamment, souvent par des équipes différentes pour résoudre des problèmes immédiats distincts. Le résultat n’est pas une série de risques acceptables séparément. Il s’agit d’un risque global équivalent au canal le plus faible, puisque les informations CUI circulent régulièrement entre eux et qu’une politique qui s’arrête à la frontière d’un canal n’offre plus aucune protection une fois la donnée franchie. Pour les responsables de la sécurité des programmes, cela signifie qu’un audit canal par canal ne permet pas de détecter ce risque. Il faut auditer ce qui arrive à un fichier contrôlé spécifique lorsqu’il passe d’un canal à l’autre.

Résumé des points clés

1. Une gouvernance fragmentée signifie qu’un même fichier contrôlé peut être protégé sur un canal et non protégé sur un autre. Une règle de classification ou d’accès appliquée dans un système accompagne rarement la donnée lorsqu’elle circule ailleurs.
2. Les pièces jointes sont l’endroit le plus courant où une politique cesse silencieusement de s’appliquer. Un fichier soigneusement gouverné dans un dossier protégé peut être joint à un e-mail et envoyé sans que les restrictions du dossier ne s’appliquent.
3. Chaque canal supplémentaire est un endroit où une faille de politique peut se cacher. Les systèmes de programmes, les e-mails, le partage de fichiers et désormais les outils d’ingénierie IA nécessitent chacun une couverture, et une faille dans l’un d’eux suffit.
4. La classification doit être une propriété de la donnée, et non du système où elle se trouve. Un tag ne protège les informations CUI de façon cohérente que s’il persiste lors du passage de la donnée entre les canaux.
5. Un moteur de politique unique couvrant tous les canaux comble la faille que les outils par canal ne peuvent pas traiter. L’application des règles doit être évaluée de la même manière quel que soit le canal par lequel la donnée circule.

Pourquoi la gouvernance par canal était la norme et pourquoi elle ne convient pas aux sous-traitants

La plupart des sous-traitants ont adopté une gouvernance fragmentée à la suite d’une série de décisions individuelles logiques, et non d’une seule mauvaise décision. Une plateforme de partage de fichiers a été choisie et sécurisée, puis l’e-mail a été choisi et sécurisé séparément, chaque projet ayant son propre budget, son responsable et sa définition de la réussite.

Chaque outil gère son propre canal, pas l’ensemble du parcours de la donnée

Les contrôles d’accès d’une plateforme de partage de fichiers déterminent qui peut ouvrir, télécharger ou partager un fichier sur cette plateforme. Ils n’ont aucune visibilité ni autorité sur ce qui se passe une fois que le fichier quitte la plateforme en pièce jointe d’un e-mail, est copié dans un autre système ou récupéré via une intégration. Chaque outil a été conçu pour bien gérer son propre canal. Aucun n’a été conçu pour suivre la donnée une fois sortie.

Les politiques sont rarement harmonisées entre les canaux après coup

Une fois que chaque canal dispose de son propre outil de gouvernance et de ses propres administrateurs, harmoniser les politiques entre eux devient un projet sans propriétaire. Cela suppose de comparer des ensembles de règles rédigés dans des langages différents, appliqués par des systèmes différents, couvrant des catégories de données contrôlées qui se recoupent sans être identiques. En pratique, cette harmonisation n’a quasiment jamais lieu de façon globale.

Où la faille se manifeste concrètement pour les sous-traitants de la défense

Le risque théorique d’une gouvernance fragmentée devient concret à des points précis et prévisibles, lorsque les informations CUI franchissent la frontière d’un canal.

Le problème des pièces jointes

Un fichier stocké dans un dossier soigneusement gouverné et à accès restreint n’est, du point de vue de la plupart des systèmes de messagerie, qu’un fichier qu’un utilisateur a choisi de joindre. Les règles d’accès du dossier, les paramètres de conservation et les restrictions de partage ne suivent pas le fichier dans l’e-mail. Une fois joint et envoyé, le fichier est alors soumis à la politique propre du système de messagerie, généralement beaucoup moins stricte.

Le problème des intégrations et des outils d’ingénierie IA

Les sous-traitants connectent en permanence des systèmes entre eux, via des intégrations et, de plus en plus, des outils d’ingénierie IA qui lisent et synthétisent des données techniques pour le compte d’un ingénieur. Chaque intégration constitue un canal potentiel pour le transfert de données contrôlées, géré par sa propre configuration d’accès, souvent minimale, plutôt que par la politique de données du sous-traitant.

Pourquoi la classification doit suivre la donnée

Pour combler ces failles, il faut changer d’approche : au lieu de demander à chaque canal d’appliquer sa propre version d’une politique, il faut évaluer la politique de la même manière quel que soit le canal où se trouve la donnée.

Tags et classification comme propriétés portables

Lorsqu’un fichier est tagué comme CUI dès son entrée dans un système, cette classification doit le suivre dans tous les environnements qu’il traverse, afin que la même restriction s’applique de façon cohérente et ne soit pas réinitialisée selon le canal.

L’application des règles doit couvrir la transition, pas seulement chaque côté

Le moment le plus risqué pour un fichier contrôlé est la transition entre les canaux, et non son stockage dans l’un ou l’autre. Une gouvernance qui applique bien les règles dans une plateforme de partage de fichiers et dans un système de messagerie, mais qui ne prévoit rien pour l’action précise de joindre un fichier de l’un à l’autre, ne comble pas la faille.

Auditer la fragmentation plutôt que canal par canal

Le changement de perspective pour une fonction sécurité de programme consiste à ne plus se demander séparément « notre plateforme de partage de fichiers est-elle sécurisée » et « notre système de messagerie est-il sécurisé », mais à s’intéresser à ce qui arrive à un fichier contrôlé spécifique lorsqu’il passe de l’un à l’autre, puis au suivant.

Comment un plan de contrôle des données comble la faille entre les canaux

Combler la fragmentation ne nécessite pas de remplacer tous les outils spécifiques à chaque canal sur lesquels un sous-traitant s’appuie déjà. Il s’agit d’ajouter une couche de gouvernance qui surplombe l’ensemble, appliquant la même politique à la même donnée, quel que soit le canal par lequel elle circule.

Le Data Control Plane de Kiteworks applique un ensemble unique de règles zero-trust à tous les canaux par lesquels transitent les données sensibles, y compris l’e-mail, le partage de fichiers, les API et les agents IA. La classification appliquée automatiquement à l’entrée dans le système suit la donnée, de sorte que la même restriction qui protège un fichier CUI dans un dossier protégé s’applique à nouveau dès qu’un utilisateur tente de le joindre à un e-mail ou de le transférer via une intégration. Chaque décision d’application, sur chaque canal, est enregistrée dans un journal d’audit inviolable et sans limitation qui alimente directement les outils SIEM.

Les sous-traitants qui souhaitent localiser précisément leurs propres failles entre canaux peuvent réserver une démo personnalisée pour comparer l’application d’une politique unique sur tous les canaux à leur approche actuelle, canal par canal.