Conversation
-
« Le secret protège nos systèmes cyber. Il protège aussi nos erreurs »
sourceClémence Foufa — La confidentialité est normalement une protection. Pourquoi affirmez-vous qu’elle peut également devenir une faiblesse ?
Didier Bazalgette — Parce qu’elle peut protéger simultanément une information et une erreur. Dans les secteurs souverains comme dans la cybersécurité, la confidentialité est évidemment indispensable. Une organisation ne peut pas exposer ses vulnérabilités, ses capacités de détection, son architecture, ses sources ou ses intentions. Mais si elle protège indistinctement le cas réel, les hypothèses formulées pour l’expliquer et les méthodes employées pour les vérifier, elle risque de soustraire ses propres raisonnements à la contradiction.
Une hypothèse peut alors acquérir une autorité considérable parce qu’elle provient d’un cercle ayant accès à des informations protégées. Ceux qui se trouvent à l’extérieur ne peuvent pas la contester puisqu’ils ne connaissent pas les éléments sur lesquels elle repose. Ceux qui se trouvent à l’intérieur peuvent appartenir aux mêmes institutions, partager les mêmes représentations ou travailler depuis longtemps à partir des mêmes catégories.
La fermeture du circuit ne signifie donc pas que le raisonnement soit faux. Elle signifie que les conditions permettant d’identifier une erreur peuvent être insuffisantes.
Clémence Foufa — Ce problème est-il propre à la cybersécurité ?
Didier Bazalgette — Non. Il concerne plus largement la R&D souveraine et tous les domaines dans lesquels exposer complètement un problème peut déjà révéler une vulnérabilité, une capacité ou une intention. Il peut s’agir d’un système d’armes, d’une technologie critique, d’un dispositif de renseignement, d’une organisation de commandement, d’une doctrine ou d’un processus de décision.
La cyber rend toutefois cette difficulté immédiatement compréhensible. Lorsqu’une organisation découvre une faiblesse dans son système d’information, elle ne peut pas toujours transmettre son architecture, ses journaux techniques, ses dépendances, ses fournisseurs et ses moyens de détection à l’ensemble des spécialistes susceptibles de l’aider.
Or les compétences utiles sont aujourd’hui largement distribuées. Elles se trouvent dans les laboratoires, les entreprises, les administrations, les communautés techniques ou chez des spécialistes indépendants. L’organisation doit donc obtenir une contribution extérieure sans nécessairement livrer le cas qui justifie cette contribution.
Clémence Foufa — Comment avez-vous été confronté à cette difficulté ?
Didier Bazalgette — Cette question a traversé une grande partie de ma carrière. J’ai travaillé au sein de la Direction générale de l’armement et de l’Agence européenne de défense, avant d’exercer des responsabilités dans le domaine de l’innovation à l’Agence de l’innovation de défense.
Dans chacune de ces fonctions, j’ai retrouvé une même tension : les compétences nécessaires à la résolution d’un problème sont distribuées entre plusieurs institutions, plusieurs disciplines et parfois plusieurs pays, tandis que les informations permettant de comprendre complètement ce problème ne peuvent pas circuler avec la même liberté.
Un industriel peut maîtriser une technologie sans connaître toute la situation opérationnelle. Un chercheur peut disposer de la méthode nécessaire sans avoir accès aux données. Une administration peut comprendre l’enjeu stratégique sans posséder toutes les compétences scientifiques requises. Le travail d’innovation consiste alors moins à réunir mécaniquement ces acteurs qu’à construire entre eux un objet de coopération compatible avec les contraintes de chacun.
Clémence Foufa — Cette difficulté a-t-elle donné lieu à des expérimentations concrètes ?
Didier Bazalgette — Oui. Entre 2019 et 2023, plusieurs projets de modélisation et d’anticipation technologique ont été conduits au profit de l’Agence de l’innovation de défense. Ils ont mobilisé, selon les périodes et les objets, des compétences issues notamment de l’Inria, de l’École polytechnique, de l’ISAE et de l’ENSTA.
Nous disposions d’excellents scientifiques et ingénieurs. La difficulté ne consistait donc pas seulement à trouver des compétences. Elle consistait à leur fournir un objet de travail suffisamment fidèle au problème réel sans exposer l’ensemble de son contexte.
Jean Langlois-Berthelot intervenait comme consultant en raison de son expérience opérationnelle ainsi que de ses compétences techniques. Il fallait comprendre ce que le problème signifiait réellement pour les acteurs concernés, puis déterminer ce qui pouvait être formalisé, modélisé et transmis.
Clémence Foufa — Pourquoi cette double compétence était-elle importante ?
Didier Bazalgette — Parce qu’il ne suffisait pas de connaître les technologies concernées. Il fallait identifier les écarts entre la formulation institutionnelle d’un problème et son fonctionnement opérationnel, puis déterminer ce qui pouvait être abstrait sans perdre ce qui donnait au problème sa valeur.
Jean pouvait circuler entre plusieurs langages. Il comprenait celui des opérations, celui des ingénieurs et celui de la recherche. Son travail consistait notamment à rechercher le mécanisme situé derrière la demande immédiate. Quelles relations voulions-nous véritablement comprendre ? Quelles variables étaient importantes ? Quelles hypothèses provenaient du terrain et lesquelles étaient introduites par l’organisation ? Qu’est-ce qui pourrait invalider le raisonnement initial ?
Une traduction insuffisante produit soit un objet trop sensible pour circuler, soit une question tellement générale qu’elle ne permet plus de résoudre le problème initial.
Clémence Foufa — Comment fonctionnait votre complémentarité ?
Didier Bazalgette — Je garantissais la cohérence institutionnelle des projets, leur articulation avec les objectifs poursuivis et la mobilisation des partenaires scientifiques et techniques. Jean travaillait plus directement sur le passage de l’expérience opérationnelle à la formalisation.
Nous ne cherchions pas simplement à transmettre un besoin à un laboratoire. Nous construisions progressivement un objet intermédiaire. Cet objet devait conserver la structure du problème réel tout en permettant à des chercheurs et à des ingénieurs de travailler sans accéder à tout ce qui entourait son instanciation opérationnelle.
Cette construction exigeait des échanges constants. Il fallait vérifier qu’une abstraction ne détruisait pas le sens du problème, qu’une formulation scientifique ne déplaçait pas involontairement l’objet et qu’une solution techniquement satisfaisante conservait une utilité dans la situation réelle.
Clémence Foufa — Votre collaboration s’est-elle limitée aux projets conduits au profit de l’Agence de l’innovation de défense ?
Didier Bazalgette — Non. Elle s’est également prolongée dans l’enseignement. En 2023, nous avons notamment dispensé à Sciences Po, avec Hermance B., alors responsable des partenariats au GICAT, un cours en anglais intitulé « Intelligence in Europe: Challenges and Innovations ».
Ce cours permettait de mettre en relation les transformations du renseignement en Europe, les enjeux industriels et les nouvelles modalités d’innovation. Nous y retrouvions déjà une question centrale dans nos travaux : comment faire coopérer des acteurs issus de mondes différents autour de problèmes sensibles, sans réduire l’innovation à la simple circulation d’une technologie ou à l’expression administrative d’un besoin ?
Hermance B. apportait la perspective de l’écosystème industriel de défense. Jean apportait son expérience opérationnelle ainsi que ses compétences techniques. Pour ma part, je pouvais replacer ces questions dans les trajectoires institutionnelles et européennes que j’avais rencontrées à la DGA, à l’Agence européenne de défense puis à l’AID.
Cette expérience d’enseignement contribuait également à rendre la méthode transmissible. Une démarche qui ne fonctionne qu’entre quelques personnes se connaissant bien demeure fragile. Elle doit pouvoir être explicitée, enseignée et reprise dans d’autres contextes.
Clémence Foufa — Que signifie précisément « transformer un problème opérationnel » ?
Didier Bazalgette — Un problème opérationnel se présente rarement sous la forme d’une question scientifique propre. Il apparaît à travers un dysfonctionnement, une inquiétude, une capacité jugée insuffisante, une évolution technologique mal comprise ou un effet que l’organisation ne parvient pas à produire.
La première erreur serait de le transformer immédiatement en cahier des charges. On figerait alors une interprétation avant même d’avoir examiné le mécanisme qui produit la difficulté. La deuxième erreur serait d’en transmettre une version tellement expurgée que les chercheurs ne travailleraient plus sur le problème réel, mais sur un objet répondant à une autre fonction.
Transformer un problème opérationnel consiste donc à rechercher ce qui, dans la situation, peut devenir un objet de connaissance. Il faut identifier les relations importantes, les variables réellement déterminantes, les hypothèses introduites par l’organisation et les conditions susceptibles de les invalider. Une fois ce travail réalisé, il devient possible de construire un modèle sans reproduire intégralement le cas protégé.
Clémence Foufa — Que produisaient concrètement ces travaux ?
Didier Bazalgette — Deux travaux étaient réalisés. Une partie était transmise à des services opérationnels afin de répondre au problème dans son environnement réel. Une autre partie permettait de formaliser et de capitaliser la méthode dans un cadre scientifique ou académique, sans exposer le cas sensible.
Cette seconde production n’était pas une version dégradée ou devenue inutile. Elle ne répondait simplement pas à la situation opérationnelle précise. Elle restait utile à la recherche, à la compréhension des enjeux généraux et à la construction de méthodes susceptibles d’être reprises dans d’autres contextes.
La double production constituait ainsi le cœur de l’expérience. Le rendu spécialisé conservait la précision nécessaire aux services concernés. La production ouverte permettait de discuter les mécanismes, de transmettre la méthode et d’accumuler une connaissance sans révéler le cas dont elle provenait.
Clémence Foufa — Vous ne cherchiez donc pas à déclassifier les problèmes ?
Didier Bazalgette — Non. Déclassifier et abstraire sont deux opérations différentes. Déclassifier consiste à modifier le régime d’accès à une information. Abstraire consiste à séparer une instanciation particulière du mécanisme que l’on souhaite étudier.
Prenons une situation cyber générique. Une organisation soupçonne qu’une compromission de sa chaîne d’approvisionnement pourrait se propager à travers plusieurs dépendances logicielles. Le cas réel comprend son identité, son architecture, ses fournisseurs, ses composants, ses procédures, ses journaux et ses capacités de détection. Toutes ces informations n’ont pas vocation à circuler.
En revanche, certaines relations peuvent être abstraites : la structure des dépendances, la vitesse de propagation, les conditions de déclenchement, les délais de détection, l’effet d’une segmentation ou les conséquences de plusieurs politiques de mise à jour. Ces mécanismes peuvent être étudiés dans un modèle qui ne reproduit pas l’organisation réelle.
Le modèle ouvert n’a pas vocation à répondre directement à la situation opérationnelle précise. Il peut néanmoins conserver une réelle valeur pour la recherche, pour la compréhension d’un enjeu général et pour la comparaison de mécanismes similaires. Le rendu spécialisé traite le cas dans son environnement réel ; le modèle communicable rend certaines de ses structures discutables et cumulatives.
Clémence Foufa — Cette manière d’organiser la R&D confidentielle est-elle réellement nouvelle ?
Didier Bazalgette — Il faut être très prudent avec les revendications de nouveauté. Les architectures aujourd’hui parfois présentées comme des innovations récentes combinent souvent des mécanismes beaucoup plus anciens.
Le modèle linéaire de l’innovation est formalisé après 1945. Les grands programmes organisent des revues de phase dès les années 1960. Les modèles Stage-Gate structurent ces passages à partir des années 1980. David Teece décrit en 1986 le rôle des régimes d’appropriation et des actifs complémentaires.
La circulation contrôlée entre des organisations séparées est également ancienne. John Wolpert propose dès 2002 de recourir à des intermédiaires pour connecter des R&D sans exposer leurs informations confidentielles. Henry Chesbrough formalise l’innovation ouverte en 2003. InnovationXchange expérimente un modèle d’intermédiaire de confiance en 2004.
Le contenu de ce qui est parfois présenté aujourd’hui comme une approche nouvelle de l’innovation confidentielle était donc déjà théorisé aux États-Unis en 2002 et opérationnalisé au plus tard en 2004. Le vocabulaire peut changer. Le recours à un intermédiaire, à un pipeline protégé ou à un écosystème sélectionné ne constitue pas, en lui-même, une rupture méthodologique.
Clémence Foufa — Où se trouve alors la différence ?
Didier Bazalgette — Dans la question posée. Les architectures traditionnelles demandent principalement qui peut accéder au problème, comment importer une technologie et comment protéger les échanges.
Nous ajoutons une autre question : comment rendre les hypothèses vérifiables lorsque le cas qui les a produites ne peut pas être exposé ?
Une enclave fermée, un programme classifié, un intermédiaire de confiance ou un cercle élargi d’acteurs habilités peuvent protéger l’information. Ils ne garantissent pas que les hypothèses incorporées dans une solution puissent être comparées, rejouées et réfutées.
Faire entrer davantage de personnes dans un espace protégé ne suffit donc pas. Une communauté habilitée peut partager les mêmes présupposés que le commanditaire. Un industriel peut répondre avec précision à un besoin mal formulé. Un modèle peut produire le résultat attendu parce que ses règles ont été conçues à partir de ce résultat. La sécurité du circuit ne constitue pas automatiquement une architecture de preuve.
Clémence Foufa — Les CERT, les communautés de confiance ou les bug bounties privés ne répondent-ils pas déjà à cette difficulté ?
Didier Bazalgette — Ils en traitent une partie essentielle. Ils permettent de partager des informations sur des menaces, des incidents, des vulnérabilités ou des modes opératoires dans un cadre maîtrisé. Le bug bounty introduit également une contradiction extérieure en donnant à des chercheurs la possibilité de rechercher des vulnérabilités.
Mais ces dispositifs organisent principalement l’accès à un système, à une information ou à une surface de recherche. Ils ne construisent pas nécessairement un modèle explicite du mécanisme étudié.
Lorsque la question porte sur une compromission complexe, une chaîne de dépendances, un comportement organisationnel ou l’évolution d’une menace dans le temps, il faut pouvoir séparer les données du cas réel, les règles supposées, les paramètres retenus et les résultats obtenus. C’est cette séparation qui permet de déterminer si nous observons réellement le mécanisme annoncé ou si nous reproduisons simplement nos propres hypothèses.
The post « Le secret protège nos <strong>systèmes cyber</strong>. Il protège aussi nos erreurs » appeared first on INCYBER NEWS.