Wat als je systeembeheerders toegang zouden hebben tot je gevoelige data zonder dat je het weet? Confidential Computing biedt een oplossing: data isoleren, zelfs voor degenen die de infrastructuur beheren. Maar hoe?

Confidential Computing omvat een geheel van technologieën waarmee gevoelige data zodanig worden beschermd dat ze niet hoeven te worden ontsleuteld om te worden verwerkt. Hoewel sommige technologieën, zoals homomorfe versleuteling, nog steeds erg complex zijn om te implementeren, zijn Trusted Execution Environments (TEE’s) inmiddels zo ver ontwikkeld dat ze kunnen worden beschouwd als belangrijke technologie bij databescherming.

Het belangrijkste doel van TEE’s is om een buffer te vormen tegen de nieuwsgierigheid van de entiteiten die de infrastructuur beheren. Technische bescherming lost echter niet alles op. Extraterritoriale wetten [1-5] en het gebruik van eigen softwarelibrary’s die door sommige IT-infrastructuurproviders worden opgelegd, kunnen deze isolatie ondermijnen.

In deze en de volgende blogpost kijken we naar de mogelijkheid om TEE’s op onze eigen infrastructuur (on-premise) te gebruiken. Het doel is drieledig: gebruikmaken van de kracht van confidential computing om data te beschermen en nieuwe toepassingen mogelijk te maken, terwijl we een zekere controle behouden over de software- en hardwarestack, en zo het vertrouwen van onze klanten versterken.

Scheiding van rollen

Laten we beginnen met een overzicht van de verschillende spelers die betrokken zijn bij de implementatie van een toepassing op een IT-infrastructuur. Hun rollen moeten strikt gescheiden zijn om de integriteit van het systeem te garanderen.

• De infrastructure operator beheert de hardware en infrastructuur (computing, storage, network) en onderhoudt de beveiligde runtime-omgevingen. Hij beheert de firmware-updates en de toewijzing van middelen, maar zou geen toegang mogen hebben tot de data of de uitgevoerde workloads.
• De orchestration operator, die dezelfde kan zijn als de infrastructure operator, is verantwoordelijk voor het beheer van de serverclusters en de implementatie van de workloads. Hij configureert de benodigde middelen voor de toepassing en houdt toezicht op de bijbehorende diensten (logging, monitoring). Ook zijn rechten zouden strikt beperkt moeten blijven om elke vorm van inbreuk op de toepassing te voorkomen, terwijl de noodzakelijke orchestratie wel mogelijk blijft.
• De workload provider ontwerpt de specificaties van de toepassingen en kiest de juiste container images, waarbij hij de conformiteit en integriteit ervan garandeert. Hij moet aan de data owners (zie hieronder) laten zien dat de gebruikte code veilig is en de privacy respecteert, zonder direct toegang te geven tot gevoelige data.
• De container image provider bouwt, ondertekent en versleutelt de container images, zodat hun herkomst en veiligheid gegarandeerd zijn. Hij verstrekt de verificatie en decryptiesleutel. Zijn samenwerking met de toepassingsprovider is cruciaal om de softwareketen te garanderen en ervoor te zorgen dat de geïmplementeerde code precies dezelfde is als de geauditeerde code.
• Ten slotte bezit de data owner de data die door de toepassingen worden verwerkt en eist hij de vertrouwelijkheid en integriteit ervan. Hij vertrouwt op de code van de toepassing (de container) en de cryptografische bewijzen die door de microprocessor worden geleverd, waardoor infrastructure en orchestration operators buiten zijn vertrouwensbereik vallen. Hij kan extra controles opleggen om ervoor te zorgen dat zijn data niet zichtbaar zijn voor of gemanipuleerd worden door onbevoegde personen.

De relaties tussen deze spelers brengen specifieke uitdagingen met zich mee: de data owner moet bijvoorbeeld kunnen vertrouwen op de code van de containers (geleverd door de workload provider) om zijn data te verwerken, terwijl hij deze tegelijkertijd moet beschermen tegen andere spelers, zoals de infrastructure of orchestration operator. Met name de beheerders van deze operators mogen in geen geval toegang hebben tot de data die door de containers worden verwerkt.

Betrouwbare runtime-omgeving

Met TEE’s kan een technische barrière worden gecreëerd die het vertrouwen van de data owner in de toepassingscontainer versterkt. We hebben al uitvoerig uitgelegd hoe ze werken en wat hun voor- en nadelen zijn in een technisch rapport [6] en blogposts [7], [8]. Hier gaan we even de belangrijkste punten herhalen alvorens we de technologische keuzes voor een implementatie op onze onderzoeksinfrastructuur voorstellen.

Het goed functioneren van TEE’s hangt af van de hardware. Sommige moderne microprocessors maken het mogelijk om een deel van het RAM-geheugen dat is toegewezen aan een specifieke virtuele machine (VM) te reserveren en te versleutelen. Zo zal een beheerder van de hostmachine, zelfs met de hoogste privileges, alleen versleutelde data zien als hij dit geheugengebied probeert te inspecteren. Hoewel er aanvallen via side-channels bestaan (bijv. [9]), vereisen deze vanwege hun complexiteit doorgaans langdurige fysieke toegang en de toevoeging van kwaadaardige hardwarecomponenten, waardoor ze in de praktijk uiterst moeilijk uit te voeren zijn.

Opdat de data owner er zeker van kan zijn dat zijn toepassing in een veilige omgeving draait, gebruikt hij het certificeringsmechanisme. Dit proces genereert een cryptografische handtekening van de inhoud van het geheugen van de VM op het moment dat deze wordt opgestart. Deze handtekening wordt gecertificeerd door de fabrikant van de microprocessor.

Dit proces heeft zijn beperkingen, vooral als de infrastructure operator een buitenlandse onderneming is (bijvoorbeeld Amazon AWS, Google Cloud of Microsoft Azure) die zijn eigen libraries in de VM oplegt om bijvoorbeeld de juiste hardware-abstractielaag te bieden.

Dit heeft ons ertoe aangezet om dit soort hardware op onze eigen infrastructuur binnen het onderzoekslabo te testen, in afwachting van de mogelijkheid om dit op een dag op G-Cloud toe te passen. Het voordeel hiervan is dat een klant van SMALS een toepassingscontainer op een veilige manier kan gebruiken, zonder dat een beheerder van SMALS toegang heeft tot de inhoud van de container.

Maar het nut van TEE’s gaat verder dan alleen bescherming tegen beheerders. Het opent de deur naar andere toepassingen.

Use case

Een eerste voorbeeld is te vinden in de Europese infrastructuur voor digitale gezondheidsdiensten (eHDSI). Daar kunnen zorgverleners in het land waar de behandeling plaatsvindt de relevante gezondheidsdata van de patiënt opvragen in het land waar de patiënt is aangesloten. Technisch gezien wordt de aanvraag via de gateway van het nationale contactpunt voor gezondheidszorg (NCPeH) van het land waar de onverwachte gezondheidsgebeurtenis plaatsvindt, doorgestuurd naar het land waar de patiënt is aangesloten. De gevraagde info moet dan worden opgehaald uit de nationale infrastructuur van het land van aansluiting, vertaald naar het Engels en getranscodeerd (de gezondheidsdata worden omgezet van het nationale coderingssysteem naar het algemeen aanvaarde coderingssysteem, bijvoorbeeld van het FHIR– of KMEHR-formaat naar CDA), en vervolgens teruggestuurd en gepresenteerd worden aan de zorgverlener in het land van behandeling. Vanwege het gevoelige karakter van de data moeten deze van begin tot eind worden versleuteld, vanaf de gegevensbron op de infrastructuur van het land van aansluiting tot aan de zorgverlener in het land van behandeling. In de praktijk is dit nog niet mogelijk vanwege de grote verschillen tussen de Europese landen. Het zou echter op zijn minst mogelijk moeten zijn om te garanderen dat de data versleuteld en ontoegankelijk blijven voor alle gebruikers of beheerders tussen de bron van de data en de uitgang van de NCPeH-gateway. Een mogelijkheid is dan om TEE’s te gebruiken voor het vertalen en transcoderen van de data.

Een ander voorbeeld van het gebruik van TEE’s is de beveiligde samenwerking tussen entiteiten die hun ruwe data niet willen delen. In de onderwijs- en werkgelegenheidssector heeft een experiment van Bogdanov et al. in Estland [10] de kracht van confidential computertechnieken aangetoond. De auteurs van deze studie wilden achterhalen of werken naast een hogere opleiding ertoe leidt dat je je diploma niet op tijd behaalt – een vraag die vooral belangrijk is voor de sector van de informatie- en communicatietechnologie (ICT) in Estland. Om deze probleemstelling te beantwoorden zonder de privacy van persoonlijke data in gevaar te brengen, hebben de onderzoekers de onderwijsregisters van het ministerie van Onderwijs en Onderzoek gecombineerd met de data van de belastingdienst, dankzij een speciale techniek van confidential computing. Maar een simpelere variant met een TEE zou net zo goed hebben gewerkt voor de analyse, terwijl de fiscale vertrouwelijkheid en databescherming gewaarborgd bleven.

CoCo

Om TEE’s te gebruiken in onze eigen onderzoeksinfrastructuur bestaan er verschillende softwareoplossingen. We hebben gekozen voor het project “Confidential Containers (CoCo)“, waarvan de broncode vrij toegankelijk is. Dit project zorgt voor een goede isolatie van de toepassingscontainers en ondersteunt het certificeringsmechanisme op een transparante manier, terwijl de flexibiliteit van de implementatie en de compatibiliteit met het Kubernetes-platform waarop het is gebaseerd, behouden blijven. Elke Kubernetes-pod is geïsoleerd in een zeer lichte Confidential Virtual Machine, om te garanderen dat alleen geautoriseerde applicaties toegang hebben tot gevoelige gegevens.

CoCo’s bevatten naast de toepassing zelf enkele noodzakelijke softwarecomponenten. Deze maken het mogelijk om de uit te voeren containerimage te downloaden, de verificatie van de certificering te vergemakkelijken en bepaalde beveiligingsbeleidsregels toe te passen. Hun programmeerinterface is relatief klein, vooral vergeleken met een oplossing waarbij een hele Kubernetes-node in een Confidential Virtual Machine wordt geplaatst. Bovendien is de image van de guest-VM statisch en generiek voor alle workloads en zelfs platforms, waardoor het eenvoudiger is om veiligheidsgaranties te bieden. Tegelijkertijd is het makkelijk om dingen te delen tussen containers in dezelfde Kubernetes-pod. De naamruimte van het netwerk van de pod blijft bijvoorbeeld binnen de confidential VM, waardoor de containers daarin zonder extra kosten vertrouwelijk met elkaar kunnen communiceren.

CoCo is gebaseerd op Kata-containers, een ander open source-project, waarmee Kubernetes-pods kunnen worden uitgevoerd binnen zeer lichte Confidential Virtual Machines (zie Figuur 1). CoCo voegt echter twee cruciale componenten toe om vertrouwelijkheid en veiligheid te garanderen (zie Figuur 2).

• De eerste heeft te maken met het ophalen van containerimages: deze worden meestal gedownload door de Kubernetes-hoofdnode met behulp van een Container Runtime Interface (CRI) zoals “containerd”, waardoor de images via het bestandssysteem zichtbaar worden voor de hostmachine. Met CoCo worden de images binnen de Confidential Virtual Machine ontsleuteld en uitgepakt, vandaar de noodzaak van de bovengenoemde componenten.
• Het tweede onderdeel is het certificaat, dat, zoals we al hebben gezien, essentieel is voor het opzetten van een betrouwbare uitvoeringsomgeving. Om bijvoorbeeld een image te ontsleutelen, dient de guest de geheime ontsleutelingssleutel te kunnen verkrijgen, maar deze wordt alleen verstrekt als de guest zijn authenticiteit kan aantonen. Dit is de rol van twee componenten die steunen op een zogenaamd “Trustee”-systeem, dat buiten de virtuele machine staat en uit twee diensten bestaat: een certificeringsdienst om de vertrouwde runtime te valideren en een key mediation-dienst om de geheime middelen te leveren die de virtuele machine en de toepassing nodig hebben.

CoCo levert dus de basis voor het bouwen van confidential toepassingscontainers door het mogelijk te maken deze containers binnen confidential virtuel machines uit te voeren, waarbij de geëncrypteerde en ondertekende images van de containers, de verzegelde geheimen en andere kenmerken worden beheerd. Elke container of groep containers van dezelfde toepassing kan worden toegewezen aan een confidential virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de confidential VM op de host wordt als onbetrouwbaar beschouwd, inclusief de kubelet-tool, de runtime-interface van de containers en de kernel van het besturingssysteem van de host. De uitwisseling van informatie tussen vertrouwde en niet-vertrouwde contexten wordt streng gecontroleerd, met name via dynamische en configureerbare beveiligingsbeleidsregels. Ten slotte wordt de Kubernetes-orkestratie zelf als niet-vertrouwd beschouwd, waardoor de garanties met betrekking tot de planning of de volgorde van uitvoering van de workloads beperkt zijn, met uitzondering van de implementatie ervan in een geauthenticeerde enclave.

Conclusie

Confidential containers maken deel uit van een algemene beveiligingsaanpak, waarbij certificering, verificatie van images en best practices in de softwaretoeleveringsketen worden gecombineerd. Ze maken het mogelijk om use cases eenvoudiger te verwerken dan geavanceerde cryptografie (confidential collaboration, private set intersection, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van confidential containers minder veilig is, maar in de praktijk zal deze waarschijnlijk volstaan in een on-premise omgeving, des te meer omdat het veel aspecten vereenvoudigt zodra het eenmaal is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van confidential CoCo’s.

Referenties

[1]        C. Bômont, “Strategic Brief no.70 – 2024 – Extension of the FISA Law European ‘digital sovereignty’ far from American concerns – IRSEM”, Institut de Recherche Stratégique de l’Ecole Militaire. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, “Europeans, forget the US Cloud Act… worry about FISA instead (!)”. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        Paul Kunert, “Microsoft exec admits it ‘cannot guarantee’ data sovereignty”. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[4]        M. Rochefort, “Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française”, clubic.com. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[5]        D. Deridder, “Understanding Sovereignty: Who Rules your Cloud?”, Dirk Deridder. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[6]        F. A. P. Petitcolas, “Informatique confidentielle – État de l’art”, Smals Research, jul. 2023. [Online]. Beschikbaar op: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, “Outils pour l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, en J. V. Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing”, gepresenteerd bij 47th IEEE Symposium on Security and Privacy (S&P), mei 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, en R. Talviste, “Students and taxes: a Privacy-preserving study using secure computation”, Proc. Priv. Enhancing Technol., vol. 2016, nr. 3, pp. 117-135, jul. 2016, doi: 10.1515/popets-2016-0019.

Et si vos administrateurs système pouvaient accéder à vos données sensibles sans que vous le sachiez ? L’informatique confidentielle propose une solution : isoler les données, même de ceux qui gèrent l’infrastructure. Mais comment ?

L’informatique confidentielle regroupe un ensemble de technologies permettant de protéger les données sensibles de telle sorte qu’il n’est pas nécessaire de les déchiffrer pour les traiter. Alors que certaines, comme le chiffrement homomorphe, sont encore très complexes à mettre en œuvre, les environnements d’exécution de confiance (EEC aussi appelés « trusted execution environment (TEE) » en anglais) ont atteint une bonne maturité, permettant de les considérer comme des composants importants dans la protection des données.

L’objectif premier des EEC est de dresser un rempart contre la curiosité des entités contrôlant l’infrastructure. Toutefois la protection technique ne résout pas tout. Les lois extraterritoriales [1-5] et l’usage de bibliothèques logicielles propriétaires imposées par certains fournisseurs d’infrastructure informatique peuvent fragiliser cette isolation.

Dans cet article et le suivant, nous nous penchons sur la possibilité de déployer des EEC sur notre propre infrastructure (on-premise). L’objectif est triple : bénéficier de la puissance de l’informatique confidentielle pour protéger les données et permettre de nouveaux cas d’usage, tout en gardant un certain contrôle sur la pile logicielle et matérielle, et ainsi renforcer la confiance de nos clients.

Séparation des rôles

Commençons par rappeler les différents acteurs qui interviennent lors du déploiement d’une application sur une infrastructure informatique. Leurs rôles doivent être hermétiquement séparés pour garantir l’intégrité du système.

• L’opérateur d’infrastructure gère le matériel et les infrastructures (calcul, stockage, réseau), incluant la maintenance des environnements d’exécution de confiance. Il contrôle les mises à jour des micrologiciels et l’allocation des ressources, mais ne devrait pas pouvoir accéder aux données ou aux charges de travail exécutées.
• L’opérateur d’orchestration, qui peut être le même que l’opérateur d’infrastructure, est responsable de la gestion des grappes de serveurs et du déploiement des charges de travail. Il configure les ressources nécessaires aux applications et supervise les services associés (journalisation, surveillance). Ses privilèges devraient aussi être strictement limités afin d’éviter toute intrusion dans l’application, tout en permettant l’orchestration essentielle.
• Le fournisseur de la charge de travail conçoit les spécifications des applications et choisit les images de conteneurs adaptées, en garantissant leur conformité et leur intégrité. Il doit prouver aux propriétaires de données (voir ci-dessous) que le code utilisé est sécurisé et respectueux de la confidentialité, sans pour autant accéder directement aux données sensibles.
• Le fournisseur d’images de conteneurs construit, signe et chiffre les images conteneurs, assurant leur provenance et leur sécurité. Il fournit les clés de vérification et de déchiffrement. Sa collaboration avec le fournisseur de l’application est cruciale pour garantir la chaîne d’approvisionnement logicielle et assurer que le code déployé est exactement celui qui a été audité.
• Enfin, le propriétaire des données détient les données traitées par les applications et exige leur confidentialité et leur intégrité. Il accorde sa confiance au code de l’application (le conteneur) et aux preuves cryptographiques fournies par le microprocesseur, excluant de fait les opérateurs d’infrastructure et d’orchestration de son périmètre de confiance. Il peut imposer des vérifications supplémentaires pour s’assurer que ses données ne sont ni visibles ni manipulées par des personnes non autorisées.

Les relations entre ces acteurs soulèvent des enjeux spécifiques : le propriétaire des données, par exemple, doit pouvoir faire confiance au code des conteneurs (fournis par le fournisseur de la charge de travail) pour traiter ses données, tout en protégeant celles-ci contre les autres acteurs comme l’opérateur d’infrastructure ou l’opérateur d’orchestration. Notamment les administrateurs de ces opérateurs ne devraient en aucun cas pouvoir avoir accès aux données traitées par les conteneurs.

Environnement d’exécution de confiance

Les EEC permettent de créer une barrière technique renforçant la confiance du propriétaire des données dans le conteneur applicatif. Nous avons déjà expliqué en détail leur fonctionnement ainsi que leurs avantages et inconvénients dans un rapport technique [6] et des articles de blogues [7], [8]. Dans cette section nous en rappelons les points clés avant de présenter des choix technologiques pour une mise en œuvre sur notre infrastructure de recherche.

Le bon fonctionnement des EEC réside dans le matériel. Certains micro-processeurs modernes permettent de réserver et de chiffrer une portion de la mémoire vive (RAM) dédiée à une machine virtuelle (VM) spécifique. Ainsi, un administrateur de la machine hôte, même avec les privilèges les plus élevés, ne verra que des données chiffrées s’il tente d’inspecter cette zone mémoire. Bien que des attaques par canaux auxiliaires existent (e.g., [9]), leur complexité nécessite généralement un accès physique prolongé et l’ajout de composants matériels malveillants, ce qui les rend extrêmement difficiles à exécuter.

Pour que le propriétaire des données soit certain que son application s’exécute dans un environnement sain, il utilise le mécanisme d’attestation. Ce processus génère une signature cryptographique du contenu de la mémoire de la VM au moment de son lancement. Cette signature est certifiée par le fabricant du micro-processeur.

Ce processus a des limites notamment dans le cas où l’opérateur d’infrastructure est une société étrangère (e.g., Amazon AWS, Google Cloud ou Microsoft Azure) qui impose ses bibliothèques propriétaires dans la VM afin, par exemple, de fournir la bonne couche d’abstraction matérielle.

Cela nous a conduit à vouloir tester ce type de technologie dans notre laboratoire de recherche sur notre propre matériel, anticipant la possibilité de le faire un jour sur G-Cloud. L’intérêt est de permettre à un client de SMALS de faire fonctionner un conteneur applicatif de manière sécurisée, sans qu’un administrateur de SMALS puisse accéder au contenu du conteneur.

Mais l’utilité des EEC dépasse la simple protection contre les administrateurs. Elle ouvre la voie à d’autres cas d’usage.

Cas d’usage

Un premier exemple se trouve dans le cadre de l’infrastructure européenne de services numériques de santé en ligne (eHDSI). Là, les professionnels de santé d’un pays de traitement peuvent demander les données de santé pertinentes du patient au pays d’affiliation de celui-ci. D’un point de vue technique, la demande est transmise par la passerelle du point de contact national pour la santé (NCPeH) du pays où l’événement de santé imprévu se produit, au pays d’affiliation. Les informations demandées doivent ensuite être récupérées auprès de l’infrastructure nationale du pays d’affiliation, traduites en anglais et transcodées (les données de santé sont transformées du système de codification national vers le système de codification communément accepté, par exemple du format FHIR ou KMEHR vers CDA), puis renvoyées et présentées au professionnel de santé du pays de traitement. Compte tenu du caractère sensible des données, les données devraient être chiffrées de bout en bout, depuis la source de données sur l’infrastructure du pays d’affiliation jusqu’au prestataire de soins de santé dans le pays de traitement. Dans la pratique, cela n’est pas encore possible en raison des différences importantes entre les pays européens. Cependant, il devrait être possible, au minimum, de garantir que les données restent chiffrées et inaccessibles à tout utilisateur ou administrateur entre la source des données et la sortie de la passerelle NCPeH. Une possibilité consiste alors à utiliser des EEC pour effectuer la traduction et le transcodage des données.

Un autre exemple d’utilisation des EEC est la collaboration sécurisée entre entités ne souhaitant pas partager leurs données brutes. Dans le secteur de l’éducation et de l’emploi, une expérience menée par Bogdanov et al en Estonie [10] a montré la puissance des techniques d’informatique confidentielle. Les auteurs de cette étude ont cherché à déterminer si le fait de travailler pendant les études supérieures était corrélé à un échec d’obtention du diplôme dans les délais impartis – une question particulièrement cruciale pour le secteur des technologies de l’information et de la communication en Estonie. Pour répondre à cette problématique sans compromettre la confidentialité des données personnelles, les chercheurs ont combiné les registres d’éducation du ministère de l’Éducation et de la Recherche avec les données de paiements d’impôts du Conseil des taxes et des douanes, grâce à une technique particulière d’informatique confidentielle. Mais une variante plus simple avec un EEC eût été tout aussi efficace pour l’analyse tout en respectant le secret fiscal et la protection des données.

CoCo

Plusieurs solutions logicielles sont disponibles pour mettre à profit les EEC sur notre propre infrastructure de recherche. Nous avons choisi d’utiliser le projet « Confidential Containers (CoCo) » dont le code source est ouvert. Il permet en effet une bonne isolation des conteneurs applicatifs et prend en charge le mécanisme d’attestation de manière transparente, tout en préservant la flexibilité de déploiement et la compatibilité avec la plateforme Kubernetes sur laquelle il s’appuie. Chaque capsule Kubernetes est isolée dans une machine virtuelle confidentielle très légère, de manière à garantir que seules les applications autorisées peuvent accéder aux données sensibles.

Les conteneurs CoCo contiennent quelques composants logiciels nécessaires en plus de l’application elle-même. Ceux-ci permettent de télécharger l’image du conteneur à exécuter, de faciliter la vérification de l’attestation et d’appliquer certaines politiques de sécurité. Leur interface de programmation est relativement petite, notamment par rapport à une solution où tout un nœud Kubernetes serait mis à l’intérieur d’une machine virtuelle confidentielle. En outre, l’image de la machine virtuelle invitée est statique et générique sur toutes les charges de travail et même les plateformes, permettant ainsi d’assurer plus simplement des garanties de sécurité. En même temps, le partage entre les conteneurs dans la même capsule Kubernetes est aisé. Par exemple, l’espace de noms du réseau de la capsule ne quitte pas la machine virtuelle confidentielle, autorisant ainsi les conteneurs qu’elle contient à communiquer de manière confidentielle sans coût supplémentaire.

CoCo s’appuie sur les conteneurs Kata, un autre projet de logiciel libre, qui permet de faire fonctionner des capsules Kubernetes à l’intérieur de machines virtuelles confidentielles très légères (voir Figure 1). CoCo ajoute cependant deux composants cruciaux afin d’assurer confidentialité et sécurité (voir Figure 2).

• Le premier concerne la récupération des images des conteneurs : celles-ci sont habituellement téléchargées par le nœud principal Kubernetes avec l’aide d’une interface d’exécution de conteneur (CRI) comme « containerd, » exposant ainsi les images à la machine hôte à travers le système de fichiers. Avec CoCo, les images sont déchiffrées, et décompactées à l’intérieur de la machine virtuelle confidentielle, d’où la nécessité des composants susmentionnés.
• Le second est l’attestation qui est, comme nous l’avons déjà vu, indispensable à l’établissement d’un environnement d’exécution de confiance. Par exemple, afin de déchiffrer une image, l’invité doit pouvoir obtenir la clé secrète de déchiffrement, mais celle-ci n’est fournie que si l’invité peut prouver son authenticité. C’est le rôle de deux composants qui s’appuient sur un système appelé « Trustee, » extérieur à la machine virtuelle et composé de deux services : un service d’attestation permettant de valider la base d’exécution de confiance et un service de médiation de clés permettant de fournir les ressources secrètes nécessaires à la machine virtuelle et à l’application.

CoCo fournit donc les bases pour construire des conteneurs applicatifs confidentiels en permettant d’exécuter ces conteneurs à l’intérieur de machines virtuelles confidentielles, gérant les images chiffrées et signées des conteneurs, les secrets scellés, et d’autres caractéristiques. Chaque conteneur ou groupe de conteneurs de la même application peut être assigné à une machine virtuelle confidentielle, incluant non seulement la charge de travail, mais aussi des processus permettant à l’application d’appeler certains services de sécurité.

Tout ce qui se trouve en dehors de la machine virtuelle confidentielle sur l’hôte est considéré comme non fiable, y compris l’outil kubelet, l’interface d’exécution de conteneurs et le noyau du système d’exploitation de l’hôte. Les échanges d’informations entre les contextes de confiance et non fiables sont strictement contrôlés, notamment via des politiques de sécurité dynamiques et configurables. Enfin, l’orchestration Kubernetes elle-même est considérée comme non fiable, limitant les garanties sur le planning ou l’ordre d’exécution des charges de travail, à l’exception de leur déploiement dans une enclave authentifiée.

Conclusion

Les conteneurs confidentiels s’inscrivent dans une démarche globale de sécurité, combinant attestation, vérification des images et bonnes pratiques de la chaîne d’approvisionnement logicielle. Ils permettent de traiter des cas d’usage plus simplement que la cryptographie avancée (collaboration confidentielle, intersection privée d’ensemble, pseudonymisation avancée, etc.). Certes les puristes argueront qu’une solution basée sur des conteneurs confidentiels est moins sûre, mais dans la pratique, elle sera probablement suffisante dans un cadre « on-premise », d’autant plus qu’elle simplifie beaucoup d’aspect une fois qu’elle est mise en place.

Dans l’article suivant, nous entrerons plus en détails dans l’installation et l’utilisation des conteneurs confidentiels CoCo.

Références

[1]        C. Bômont, « Strategic Brief no.70 – 2024 – Extension of the FISA Law European “digital sovereignty” far from American concerns – IRSEM », Institut de Recherche Stratégique de l’Ecole Militaire. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, « Europeans, forget the US Cloud Act… worry about FISA instead (!) ». Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        M. Rochefort, « Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française », clubic.com. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[4]        D. Deridder, « Understanding Sovereignty: Who Rules your Cloud? », Dirk Deridder. Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[5]        P. Kunert, « Microsoft exec admits it “cannot guarantee” data sovereignty », The Register. Consulté le: 28 juillet 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[6]        F. A. P. Petitcolas, « Informatique confidentielle – État de l’art », Smals Research, juill. 2023. [En ligne]. Disponible sur: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, « Introduction à l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, « Outils pour l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, et J. V. Bulck, « Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing », présenté à 47th IEEE Symposium on Security and Privacy (S&P), mai 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, et R. Talviste, « Students and taxes: a Privacy-preserving study using secure computation », Proc. Priv. Enhancing Technol., vol. 2016, n^o 3, p. 117‑135, juill. 2016, doi: 10.1515/popets-2016-0019.

Cet article fait suite à une première partie qui s’est penchée sur la sécurité du code généré par les outils d’IA générative (IAGén). Dans cette seconde partie, nous considérons la tâche de détecter des vulnérabilités dans du code existant et comment l’IAGén pourrait peut-être aider.

Les vulnérabilités de sécurité dans le code sont un problème récurrent affectant la plupart des logiciels et ayant un impact sur l’intégrité, la confidentialité et la disponibilité. L’utilisation de certains langages de programmation connus pour être moins susceptibles que d’autres à des problèmes classiques est recommandée (par exemple Rust plutôt que C). L’examen du code par d’autres programmeurs experts est aussi une méthode largement répandue. Mais l’IAGén pourrait-elle faciliter la tâche ?

Recherche de vulnérabilités

Il existe plusieurs façons de rechercher des vulnérabilités à partir du code ou du binaire et ce, de manière automatique ou manuelle, statique ou dynamique, et systématique ou exploratoire. En 2022, dans une étude très détaillée, Elder et al. [1] ont comparé plusieurs de ces méthodes sur une application d’ampleur dans le domaine médical : OpenMRS. Celle-ci contient près de 4 millions de lignes de code Java et JavaScript. Les auteurs font plusieurs recommandations en fonction des objectifs recherchés et des ressources (expertise, temps, équipement) disponibles et confirment une étude plus ancienne : chaque méthode de détection de vulnérabilité trouve des vulnérabilités qui n’ont pas été trouvées par d’autres méthodes. Cependant, dans leur expérimentation, la méthode manuelle exploratoire par tests d’intrusion a permis de trouver les vulnérabilités les plus dangereuses.

IAGén et analyse statique

Le Tableau 1 compare deux approches d’analyse de code : l’analyse statique (classique) et une analyse utilisant une IAGén. Selon certaines études, l’IAGén aurait commencé à montrer quelques avantages par rapport aux outils d’analyse statiques classiques.

Tableau 1 – Aperçu des principales différences et similitudes entre deux approches d’analyse du code : analyse statique et analyse avec IAGén (d’après [2]).

Par exemple, Noever [2] a étudié la performance de certaines IAGén pour identifier et rectifier des vulnérabilités dans des logiciels. Son étude portait sur divers dépôts de GitHub et comparait les IAGén avec des outils d’analyse statique. L’auteur a utilisé la requête (« prompt » en anglais) suivante :

“Act as the world’s greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.”

Les tests de l’auteur utilisent le cycle suivant pour une base de code donnée :

• Utiliser un outil d’analyse statique pour évaluer le nombre et le niveau de gravité des vulnérabilités ;
• Demander à l’IAGén d’identifier les vulnérabilités ;
• Demander à l’IAGén de corriger les vulnérabilités trouvées ;
• Utiliser l’outil d’analyse statique sur le code corrigé et comparer le nombre et le niveau de gravité des vulnérabilités trouvées.

Les résultats de l’auteur sont plutôt positifs sur la base de code choisie : l’IAGén a permis de réduire de manière significative le nombre de vulnérabilités très graves.

Performance de l’IAGén

Cependant, même les meilleurs outils utilisant l’IA pour la détection de défauts ont une précision inférieure à 70 % selon CodeXGLUE. Une étude de Steenhoek [3] rapporte que les modèles de pointe n’ont obtenu qu’une précision équilibrée de 54,5 %¹ dans leur évaluation de la détection des vulnérabilités, même pour les modèles pré-entraînés sur de grandes quantités de code source. En d’autres termes, « tous les modèles et toutes les requêtes ont donné des résultats proches de ceux des réponses aléatoires aux devinettes. » Les auteurs expliquent cela par la difficulté qu’ont les IAGén à raisonner sur la sémantique du code. Cette difficulté de raisonnement ne se limite d’ailleurs pas au code [3].

Nous avions déjà pu remarquer quelque chose de similaire lors de nos propres tests sur une base de code avec des vulnérabilités de type CWE connues : le nombre de faux-positifs² était souvent aussi important que le nombre de vrai-positifs³ lorsque nous avons demandé à différents modèles (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) d’indiquer si un fichier de code contenait des vulnérabilités potentielles. Même en envoyant une base de code entière nos résultats n’ont pas été plus concluants. En effet, Llama permet de fournir un contexte très large (10 millions de symboles), et après lui avoir fourni l’entièreté de WebGoat – un logiciel spécialement écrit avec des vulnérabilités – aucune vulnérabilité significative n’a été identifiée !

Dans une étude plus récente et plus systématique, Ullah et al. [4] montrent – en utilisant 8 modèles et 17 méthodes de requête sur 228 exemples de code – que les IAGén fournissent des réponses non déterministes, un raisonnement incorrect et infidèle, et qu’elles sont peu performantes dans des scénarios du « monde réel ». Plus grave, l’étude confirme aussi un manque de robustesse lors de la détection de vulnérabilités potentielles. De nombreuses études avaient déjà souligné que les techniques d’apprentissage automatique manquaient de robustesse aux transformations de code préservant la sémantique comme le renommage d’identifiants, l’insertion de déclarations non exécutées ou encore le remplacement de code par du code équivalent [5]. Sans grande surprise, les méthodes d’amplifications permettant à un modèle d’apprendre ce type de transformations, ne permettent d’augmenter la robustesse que pour les transformations spécifiques auxquelles le modèle a été entrainé [5].

Dans un autre exemple, plus anecdotique, Heelan [6] discute de la capacité de ChatGPT-o3 à trouver la vulnérabilité CVE-2025-37778 dans le noyau de Linux. Outre le fait que la requête envoyée par l’auteur à l’IAGén était très précise (extrait de code soigneusement sélectionné, instructions détaillées), l’IAGén n’a trouvé la vulnérabilité que 8 fois sur 100 (la même requête a été envoyée 100 fois, et seulement 8 fois l’IAGén a trouvé la vulnérabilité). Dans un autre exemple l’auteur décrit comment, par hasard, l’IAGén lui a permis de découvrir une nouvelle vulnérabilité ; là encore il a envoyé cent fois sa requête à ChatGPT et, dans une seule réponse, il a trouvé un élément le mettant sur la voie. C’est sans compter le coût environnemental et financier de l’exercice et surtout le fait que la nouvelle vulnérabilité est liée sémantiquement à la précédente.

Dès lors, on ne s’étonnera pas que l’expérience de plusieurs projets de logiciels libres tend à montrer que les bogues découverts avec l’aide de l’IAGén ont en réalité peu de valeur [7], [8].

Intégration de l’IAGén dans l’analyse statique

Afin d’améliorer la détection de vulnérabilités par une IAGén dans un échantillon de code, Yue Li et al. [9] suggèrent de rassembler le plus d’informations contextuelles possibles (p. ex., liste de dépendances et informations spécifiques à un type de vulnérabilité recherché). C’est ce qui est mis en pratique dans l’outil IRIS de Ziyang Li et al. [10].

IRIS combine l’IAGén avec l’analyse statique pour détecter les vulnérabilités de sécurité dans les logiciels tout en essayant de réduire le taux de faux positifs. Cet outil suit un processus systématique de détection des failles de sécurité :

1. Extraction de candidats potentiels pour être des sources ou des récepteurs contaminés dans les interfaces de programmation externes et internes grâce à un outil d’analyse statique.
2. Interrogation d’une IAGén pour étiqueter en tant que source ou puit (fonction vulnérable) spécifique à une classe de vulnérabilité⁴, les interfaces candidates.
3. Les sources et les puits étiquetés sont transformés en spécifications qui peuvent être introduites dans CodeQL afin d’effectuer une analyse des souillures (les variables entachées par des entrées de l’utilisateur et pouvant atteindre un puit) spécifique à une classe de vulnérabilité. Cette étape génère un ensemble de chemins de code vulnérables (ou alertes) dans le projet.
4. Enfin l’IAGén est utilisée pour réduire le nombre de faux-positifs signalés par l’analyse statique de CodeQL tout en fournissant une explication.

Nos tests de l’outil IRIS-v1⁵, sur la base de code WebGoat avec les modèles Codegen25-7b-instruct, qwen2.5-coder-7b et GPT-4 ont pu confirmer une réduction d’environ 18 % du nombre de vulnérabilités potentielles détectées, mais ce, au prix d’un grand nombre d’appels au modèle d’IAGen (1130 appels par type de CWE testé, pour une base de 259 fichiers Java).

Cet outil encore expérimental montre néanmoins une tendance plus générale de l’introduction de l’IAGén dans les outils de détection existants. C’est le cas, par exemple, de DeepCode, d’ETH Zurich, récemment intégré dans le logiciel Snyk. Il a pour ambition de permettre aux programmeurs de trouver rapidement des vulnérabilités dans leur code. Mais la convergence d’outils d’IAGén examinant du code généré par d’autres outils d’IAGén, crée des boucles de rétroaction qui pourraient s’avérer dangereuses [11].

Conclusion et recommandations

Même si quelques études ont montré que les IAGén peuvent résoudre des problèmes simples de correction de vulnérabilités (par exemple, des fuites de mémoire), on constate qu’ils rencontrent des difficultés à résoudre des défauts complexes. La plupart des études que nous avons rencontrées montrent aussi des performances incohérentes et une tendance générale à des taux élevés de faux-positifs, dans la détection des failles de sécurité, confirmant nos propres tests. Les meilleures performances de détection semblent être atteintes sur les vulnérabilités pour lesquelles les IAGén ont été entraînées. Ces observations sont confirmées par une étude systématique et extensive de Basic et Giaretta [12].

Par conséquent, avant de pouvoir utiliser l’IAGén pour la détection de vulnérabilité dans le code, il faudra attendre que des progrès importants soient faits. Pour le moment, il faut prendre conscience des limites actuelles de ces outils. Outre celles mentionnées précédemment, quelle que soit la méthode retenue, de nombreux appels à l’IAGén peuvent s’avérer être très coûteux (ou très lents s’ils sont exécutés localement sans matériel adéquat). De plus il manque encore une méthodologie scientifique solide permettant de comparer efficacement différents outils d’analyse et de mesurer l’apport objectif de l’IAGén.

Chez SMALS, par exemple, une initiative issue du fruit d’une collaboration (groupe de travail « SAST⁶ ») entre l’équipe de développement des applications & projets et celle de recherche travaille sur la performance des outils d’analyse statique et l’apport possible de l’IAGén.

Enfin, on note que CodeQL est repris par beaucoup d’études comme une base de référence pour la comparaison de l’efficacité des modèles d’IAGén à détecter des vulnérabilités. Cela n’est pas étonnant car des outils comme celui-ci ont fait leur preuve. Alors avant de se lancer tête baissée dans l’utilisation de l’IAGén pour améliorer la sécurité du code, il est probablement plus sage d’intégrer progressivement dans les indispensables revues de code habituelles, des outils d’analyse statique ou dynamique. Nul doute qu’une IAGén sera intégrée à ces outils au moment opportun.

Références

[1] S. Elder et al., « Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application », 2 août 2022, arXiv: arXiv:2208.01595. doi: 10.48550/arXiv.2208.01595.

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[3] P. Shojaee, I. Mirzadeh, K. Alizadeh, M. Horton, S. Bengio, et M. Farajtabar, « The illusion of thinking: Understanding the strengths and limitations of reasoning models via the lens of problem complexity », [En ligne]. Disponible sur: https://arxiv.org/abs/2506.06941

[4] S. Ullah, M. Han, S. Pujar, H. Pearce, A. Coskun, et G. Stringhini, « LLMs cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks », 24 juillet 2024, arXiv: arXiv:2312.12575. doi: 10.48550/arXiv.2312.12575.

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[6] S. Heelan, « How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation », Sean Heelan’s Blog. Consulté le: 12 juin 2025. [En ligne]. Disponible sur: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/

[7] T. Claburn, « AI-assisted bug reports make developers bear cost of cleanup », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

[8] C. Jones, « Curl takes action against time-wasting AI bug reports », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ Les auteurs préfèrent le score de précision équilibrée (« balanced accuracy ») au score classique F1 afin de mieux prémunir des biais potentiels du modèle évalué. Il est défini comme :

² Code déclaré contenant une vulnérabilité alors qu’il n’en contient pas.

³ Code correctement déclaré comme contenant une vulnérabilité.

⁴ Actuellement, IRIS ne prend en charge que les CWE suivants : CWE-022 (Traversée de chemin), CWE-078 (injection de commande du système d’exploitation), CWE-079 (Script inter-site) et CWE-094 (injection de code).

⁵ La version 2 a été publiée après l’écriture de cet article.

⁶ « Static application security testing »

Dit artikel is het vervolg op een eerste deel dat zich toespitste op de veiligheid van code die gegenereerd werd door generatieve AI-tools (GenAI). In het tweede deel nemen we de taak onder de loep om kwetsbaarheden in bestaande code op te sporen en zien we hoe GenAI daarbij zou kunnen helpen.

Kwetsbaarheden in code zijn een terugkerend probleem dat de meeste software treft en een impact heeft op integriteit, vertrouwelijkheid en beschikbaarheid. Er wordt aangeraden om bepaalde programmeertalen te gebruiken waarvan bekend is dat ze minder gevoelig zijn voor klassieke problemen dan andere (bijv. Rust in plaats van C). Code review door andere expertprogrammeurs is ook een veelgebruikte methode. Maar zou GenAI de taak kunnen vergemakkelijken?

Zoeken naar kwetsbaarheden

Er zijn verschillende manieren om kwetsbaarheden in code of binaire bestanden op te sporen, zowel automatisch als handmatig, statisch of dynamisch, en systematisch of verkennend. In 2022 hebben Elder et al. [1] in een zeer gedetailleerde studie verschillende van deze methoden vergeleken op een grootschalige toepassing in de medische sector: OpenMRS. Deze bevat bijna 4 miljoen regels Java- en JavaScript-code. De auteurs doen verschillende aanbevelingen op basis van de beoogde doelstellingen en de beschikbare middelen (expertise, tijd, apparatuur) en bevestigen een eerdere studie: elke methode voor het opsporen van kwetsbaarheden vindt kwetsbaarheden die met andere methoden niet zijn gevonden. In hun experiment bleek echter de handmatige verkennende methode met penetratietests de gevaarlijkste kwetsbaarheden op te sporen.

GenAI en statische analyse

Tabel 1 vergelijkt twee benaderingen van code-analyse: statische (klassieke) en een analyse die GenAI gebruikt. Volgens bepaalde studies zou GenAI enkele voordelen beginnen te vertonen ten opzichte van klassieke statische analysetools.

Tabel 1 – Overzicht van de belangrijkste verschillen en overeenkomsten tussen twee benaderingen van codeanalyse: statische analyse en analyse met GenAI (naar [2]).

Noever [2] heeft bijvoorbeeld de prestaties van bepaalde GenAI onderzocht om kwetsbaarheden in software te identificeren en te verhelpen. Zijn onderzoek had betrekking op verschillende GitHub-repository’s en vergeleek GenAI met statische analysetools. De auteur gebruikte de volgende prompt:

“Act as the world’s greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.”

De tests van de auteur gebruiken de volgende cyclus voor een bepaalde codebase:

• Gebruik een statische analysetool om het aantal en de ernst van de kwetsbaarheden te beoordelen;
• Vraag GenAI om de kwetsbaarheden te identificeren;
• Vraag GenAI om de gevonden kwetsbaarheden te corrigeren;
• Gebruik de statische analysetool op de gecorrigeerde code en vergelijk het aantal en de ernst van de gevonden kwetsbaarheden.

De resultaten van de auteur zijn vrij positief op basis van de gekozen codebase: GenAI heeft het aantal zeer ernstige kwetsbaarheden aanzienlijk verminderd.

Performantie van GenAI

Maar zelfs de beste tools die AI gebruiken voor foutdetectie hebben volgens CodeXGLUE een nauwkeurigheid van minder dan 70%. Een studie van Steenhoek [3] meldt dat de meest geavanceerde modellen slechts een gemiddelde nauwkeurigheid van 54,5%¹ behaalden bij het opsporen van kwetsbaarheden, zelfs voor modellen die vooraf waren getraind op grote hoeveelheden broncode. Met andere woorden: “alle modellen en alle prompts leverden resultaten op die dicht in de buurt kwamen van willekeurige antwoorden op raadsels”. De auteurs verklaren dit door de moeilijkheid die GenAI heeft om te redeneren over de semantiek van code. Deze moeilijkheid om te redeneren beperkt zich overigens niet tot code [3].

We hadden al iets soortgelijks opgemerkt tijdens onze eigen tests op een codebase met bekende CWE-kwetsbaarheden: het aantal valse positieven² was vaak even groot als het aantal echte positieven³ toen we verschillende modellen verzochten (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) om aan te geven of een codebestand potentiële kwetsbaarheden bevatte. Zelfs toen we een volledige codebase verstuurden, waren onze resultaten niet overtuigender. Llama biedt namelijk een zeer grote context (10 miljoen symbolen) en nadat we het de volledige WebGoat – een speciaal geschreven softwareprogramma met kwetsbaarheden – hadden aangeleverd, werd er geen enkele significante kwetsbaarheid geïdentificeerd!

In een recentere en systematischere studie tonen Ullah et al. [4] aan – aan de hand van 8 modellen en 17 promptmethoden op 228 codevoorbeelden – dat GenAI niet-deterministische antwoorden en onjuiste en onbetrouwbare redeneringen geeft en slecht presteert in ‘realistische’ scenario’s. Erger nog, het onderzoek bevestigt ook een gebrek aan robuustheid bij het opsporen van potentiële kwetsbaarheden. Talrijke studies hadden al aangetoond dat machine learning-technieken niet robuust genoeg zijn tegen semantiekbehoudende codetransformaties, zoals het hernoemen van identifiers, het invoegen van niet-uitgevoerde declaraties of het vervangen van code door gelijkwaardige code [5]. Het is dan ook niet verwonderlijk dat amplificatiemethoden waarmee een model dit soort transformaties kan leren, alleen de robuustheid verhogen voor de specifieke transformaties waarop het model is getraind [5].

In een ander, meer anekdotisch voorbeeld bespreekt Heelan [6] het vermogen van ChatGPT-o3 om de kwetsbaarheid CVE-2025-37778 in de Linux-kernel te vinden. Afgezien van het feit dat de prompt die de auteur naar GenAI stuurde zeer nauwkeurig was (zorgvuldig geselecteerde codefragmenten, gedetailleerde instructies), vond GenAI de kwetsbaarheid slechts 8 van de 100 keer (dezelfde prompt werd 100 keer verzonden en slechts 8 keer vond GenAI de kwetsbaarheid). In een ander voorbeeld beschrijft de auteur hoe hij door toeval met behulp van GenAI een nieuwe kwetsbaarheid ontdekte; ook hier stuurde hij zijn verzoek honderd keer naar ChatGPT en vond hij in één antwoord een aanwijzing die hem op het spoor zette. Daarbij komen nog de milieukosten en financiële kosten van deze operatie en vooral het feit dat de nieuwe kwetsbaarheid semantisch verband houdt met de vorige.

Het is dan ook niet verwonderlijk dat de ervaring met verschillende vrije softwareprojecten aantoont dat bugs die met behulp van GenAI worden ontdekt, in werkelijkheid weinig waarde hebben [7], [8].

Integratie van GenAI in statische analyse

Om de detectie van kwetsbaarheden door GenAI in een codefragment te verbeteren, stellen Yue Li et al. [9] voor om zoveel mogelijk contextuele informatie te verzamelen (bijv. lijst van afhankelijkheden en specifieke informatie over een bepaald type kwetsbaarheid). Dit wordt in de praktijk gebracht in de IRIS-tool van Ziyang Li et al. [10].

IRIS combineert GenAI met statische analyse om beveiligingskwetsbaarheden in software op te sporen en tegelijkertijd het aantal valse positieven te verminderen. Deze tool volgt een systematisch proces voor het opsporen van beveiligingslekken:

1. Extractie van potentiële kandidaten voor besmette bronnen of ontvangers in externe en interne programmeerinterfaces met behulp van een statische analysetool.
2. Vragen aan een GenAI om de kandidaat-interfaces te labelen als bron of put (“sink”, kwetsbare functie) die specifiek is voor een bepaalde klasse van kwetsbaarheden⁴.
3. De gelabelde bronnen en putten worden omgezet in specificaties die in CodeQL kunnen worden ingevoerd om een analyse uit te voeren van smears (variabelen die door gebruikersinvoer zijn besmet en een put kunnen bereiken) die specifiek zijn voor een klasse van kwetsbaarheden. Deze stap genereert een reeks kwetsbare codepaden (of waarschuwingen) in het project.
4. Ten slotte wordt GenAI gebruikt om het aantal valse positieven dat door de statische analyse van CodeQL wordt gemeld te verminderen en tegelijkertijd een verklaring te geven.

Onze tests van de IRIS-v1-tool⁵, op basis van WebGoat-code met de modellen Codegen25-7b-instruct, qwen2.5-coder-7b en GPT-4, hebben een vermindering aangetoond van ongeveer 18% van het aantal gedetecteerde potentiële kwetsbaarheden, maar dit ging ten koste van een groot aantal oproepen aan het GenAI-model (1130 oproepen per getest CWE-type, voor een basis van 259 Java-bestanden).

Deze nog experimentele tool toont niettemin een meer algemene trend aan om GenAI te integreren in bestaande detectietools. Dit is bijvoorbeeld het geval bij DeepCode van ETH Zürich, dat onlangs is geïntegreerd in de Snyk-software. Het is bedoeld om programmeurs in staat te stellen snel kwetsbaarheden in hun code op te sporen. Maar de convergentie van GenAI -tools die code onderzoeken die door andere GenAI-tools is gegenereerd, creëert feedbackloops die gevaarlijk kunnen zijn[11].

Conclusie en aanbevelingen

Hoewel enkele studies hebben aangetoond dat GenAI eenvoudige problemen met kwetsbaarheden (bijvoorbeeld geheugenlekken) kan oplossen, blijkt dat het systeem moeite heeft met complexe fouten. De meeste studies die we hebben gevonden, tonen ook inconsistente prestaties en een algemene neiging tot hoge percentages valse positieven bij het opsporen van beveiligingslekken, wat door onze eigen tests bevestigd wordt. De beste detectieprestaties lijken te worden bereikt voor kwetsbaarheden waarvoor GenAI is getraind. Deze bevindingen worden bevestigd door een systematische en uitgebreide studie van Basic en Giaretta [12].

Voordat GenAI kan worden gebruikt voor het opsporen van kwetsbaarheden in code, moet er dus nog aanzienlijke vooruitgang worden geboekt. Voorlopig moeten we ons bewust zijn van de huidige beperkingen van deze tools. Naast de eerder genoemde beperkingen kan het, ongeacht de gekozen methode, erg duur zijn om GenAI veelvuldig te gebruiken (of erg traag als het lokaal wordt uitgevoerd zonder de juiste apparatuur). Bovendien ontbreekt het nog aan een solide wetenschappelijke methodologie om verschillende analysetools effectief te vergelijken en de objectieve bijdrage van GenAI te meten.

Bij SMALS is bijvoorbeeld een initiatief ontstaan ​​uit een samenwerking (werkgroep “SAST”⁶) tussen het team voor toepassings- en projectontwikkeling en het onderzoeksteam. Er wordt gewerkt aan de prestaties van statische analysetools en de mogelijke bijdrage van GenAI.

Ten slotte merken we op dat CodeQL in veel studies wordt genoemd als referentiepunt voor het vergelijken van de doeltreffendheid van GenAI-modellen bij het opsporen van kwetsbaarheden. Dat is niet verwonderlijk, aangezien tools zoals deze hun nut hebben bewezen. Voordat we ons halsoverkop op GenAI storten om de codeveiligheid te verbeteren, is het waarschijnlijk verstandiger om statische of dynamische analysetools geleidelijk te integreren in de gebruikelijke essentiële codebeoordelingen. Ongetwijfeld zal GenAI op een gepast moment in deze tools worden geïntegreerd.

Referenties

[1] S. Elder et al., « Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application », 2 août 2022, arXiv: arXiv:2208.01595. doi: 10.48550/arXiv.2208.01595.

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[3] P. Shojaee, I. Mirzadeh, K. Alizadeh, M. Horton, S. Bengio, et M. Farajtabar, « The illusion of thinking: Understanding the strengths and limitations of reasoning models via the lens of problem complexity », [En ligne]. Disponible sur: https://arxiv.org/abs/2506.06941

[4] S. Ullah, M. Han, S. Pujar, H. Pearce, A. Coskun, et G. Stringhini, « LLMs cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks », 24 juillet 2024, arXiv: arXiv:2312.12575. doi: 10.48550/arXiv.2312.12575.

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[6] S. Heelan, « How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation », Sean Heelan’s Blog. Consulté le: 12 juin 2025. [En ligne]. Disponible sur: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/

[7] T. Claburn, « AI-assisted bug reports make developers bear cost of cleanup », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

[8] C. Jones, « Curl takes action against time-wasting AI bug reports », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ De auteurs geven de voorkeur aan de ‘balanced accuracy’-score boven de klassieke F1-score om beter te kunnen waken over mogelijke vertekeningen in het geëvalueerde model. Deze wordt als volgt gedefinieerd:

² Code die als kwetsbaar wordt aangemerkt, terwijl dat niet het geval is.

³ Code die correct als kwetsbaar wordt aangemerkt.

⁴ Momenteel ondersteunt IRIS alleen de volgende CWE‘s: CWE-022 (path traversal), CWE-078 (injectie van besturingssysteemopdrachten), CWE-079 (cross-site scripting) en CWE-094 (code-injectie).

⁵ Versie 2 werd gepubliceerd na het schrijven van dit artikel.

⁶ “Static application security testing”

La communication intense autour de l’intelligence artificielle générative (IAGén) et l’augmentation de son utilisation – au moins en phase de test – que cela soit par peur de rater quelque chose ou pour apporter une réelle valeur ajoutée, conduit à se poser la question de son utilité dans beaucoup de domaines, et, pourquoi pas, afin d’améliorer la sécurité du code. En particulier, l’IAGén permet-elle d’écrire du code informatique plus sécurisé ? Peut-elle aider à détecter des vulnérabilités dans du code existant ?

Dans cette première partie nous apporterons des éléments de réponse à la première question. Nous traiterons la seconde question dans un autre article.

Aspects humains

Commençons par considérer l’aspect humain du recours à l’utilisation de l’IAGén. Dans une analyse détaillée, dont je recommande vivement la lecture, Simkute et al. [1] expliquent les raisons pouvant conduire à une perte de productivité des programmeurs ayant recours à l’IAGén. Les chercheurs citent notamment : un glissement du rôle des programmeurs de la production à l’évaluation, une restructuration inutile des flux de travail, des interruptions, et une tendance de l’IAGén à rendre les tâches faciles plus faciles et les tâches difficiles plus difficiles. On s’étonne alors moins des résultats d’une étude de Perry et al. [2], de l’université de Stanford. Ceux-ci montrent que les participants ayant accès à un assistant basé sur un modèle d’IA écrivent un code significativement moins sécurisé que ceux sans accès. Pire, les participants avec un accès à l’assistant étaient plus enclins à croire qu’ils écrivaient du code sécurisé, que ceux sans l’assistant. Cette observation de Perry et al. est corroborée par le travail de Klemmer et al. [3] : l’équipe de chercheurs a interrogé des programmeurs professionnels, et bien que ces derniers se méfient des suggestions des assistants d’IA, il apparait qu’ils surestiment aussi leur propre capacité à examiner les suggestions de ces assistants. L’adoption d’assistants impose donc la mise en place de pratiques de revue de code et d’analyse statique systématiques [4].

Fiabilité des propositions

Considérant maintenant la qualité des suggestions de l’IAGén, bien que celle-ci produise en général du code fonctionnellement correct, elle introduit également des problèmes de sécurité [5], [6]. Khoury et al. [7] ont montré à travers plusieurs exemples que ChatGPT 3.5 génère souvent du code qui présente des problèmes de sécurité : seuls 5 des 21 cas d’utilisation que les auteurs ont étudiés étaient initialement sécurisés. ChatGPT 3.5 n’a été en mesure de produire du code sécurisé que dans 7 autres cas, et ce, seulement après que les auteurs lui ont explicitement demandé de corriger le code.

Plus récemment, Sivana et al. [8] concluaient leurs expérimentations en soulignant que ChatGPT, en tant que plateforme, générait plus de vulnérabilités de type CWE que le site StackOverflow. Indépendamment, Fu et al. [9] ont montré à travers plusieurs centaines d’échantillons de codes générés par Co-Pilot et trouvés sur GitHub, qu’environ un tiers contient des vulnérabilités communes répertoriées par l’organisme MITRE (certaines faisant partie des 25 plus importantes). Les auteurs recommandent donc aux programmeurs de suivre les meilleures pratiques d’utilisation des outils de génération de code et de toujours vérifier les suggestions de code générées. Des résultats similaires avaient déjà été trouvés par Pearce et al. [10] deux ans plus tôt.

On pourrait multiplier les références à des résultats similaires. C’est ce qu’ont fait Basic et Giaretta [11] dans une étude systématique extensive de la littérature académique sur les IAGén et la sécurité du code informatique. Les modèles concernés sont divers et incluent notamment ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet et Gemini Pro. Les auteurs confirment que plusieurs vulnérabilités clés, telles que les injections SQL et les dépassements de mémoire tampon, peuvent être trouvées dans le code généré par les IAGén. Ils signalent aussi que les risques d’empoisonnement des données d’entraînement peuvent non seulement conduire à une génération de code non sécurisé, mais aussi compromettre la détection des vulnérabilités.

Empoisonnement de l’IA

L’empoisonnement d’un modèle génératif de complétion de code consiste à compromettre l’intégrité de ce modèle en intégrant des échantillons de code malicieux dans les données d’entrainement du modèle. Les attaques par porte dérobée, quant à elles, tentent de dissimuler des déclencheurs à l’intérieur du réseau neuronal profond du modèle pendant la phase d’apprentissage, provoquant la génération de résultats choisis par l’adversaire.

Malgré des progrès importants des modèles de complétion de code, ceux-ci restent vulnérables à ce type d’attaques comme l’ont montré Yan et al. [12] avec CodeBreaker. Pour leur attaque, il n’est pas nécessaire de compromettre un modèle massif pré-entrainé comme BERT ou GPT. En effet ces modèles sont souvent utilisés comme fondation que les victimes règlent finement pour des tâches particulières en utilisant des données spécifiques souvent disponibles publiquement. Il suffit donc alors à l’adversaire de compromettre ces données de réglage fin, ou de téléverser son propre ensemble de données polluées générées avec CodeBreaker. Le code empoisonné généré après l’utilisation de CodeBreaker n’est pas détectable avec des outils de détection de vulnérabilités basés sur des analyses statiques traditionnelles ou des IAGén.

Même si ce type d’attaques est peu probable il pose la question de la provenance de l’outil d’IAGén utilisé et s’inscrit dans la problématique inhérente à l’IAGén actuelle d’obtenir des modèles à la fois sécurisés et exactes [13].

Importance de la requête

Tout n’est pas si noir cependant et il faut souligner l’importance du choix des incitations (« prompt » en anglais) données à l’IAGén afin d’éviter la génération de code avec des faiblesses potentielles. Götz et al. [14] montrent qu’alors que 65% du code initialement généré par divers outils d’IAGén est considéré comme non sécurisé par un ingénieur qualifié, ces mêmes outils génèrent du code sécurisé lorsqu’ils sont guidés manuellement. Les auteurs concluent qu’une expertise technique, en particulier dans le domaine de la sécurité est requise pour générer du code sécurisé en utilisant des assistants de codage.

Afin d’obtenir les meilleurs résultats possibles il faut donc que la requête envoyée à l’IAGén soit à la fois précise et clairement interprétable par le modèle. Autrement-dit, le programmeur a tout intérêt à se plier aux exigences de la machine et fournir avec le plus de détails possibles, non seulement la tâche que le modèle doit exécuter, mais aussi le contexte qui décrit cette tâche, ainsi que les données d’entrée et les données de sortie attendues. Cela peut se faire en seule fois ou sous forme de chaîne de pensée suivant un raisonnement particulier.

Il n’existe cependant pas de méthode idéale, mais Bruni et al. [15] donnent plusieurs exemples simples d’amélioration des incitations. Selon leurs expérimentations la méthode la plus efficace est, après une première requête, de demander à l’IAGén de revoir le code qu’elle a déjà suggéré pour des vulnérabilités potentielles, et enfin de proposer des corrections. Par exemple :

• Requête 1 : Génère du code Java pour …
• Requête 2 : Examine le code suivant et trouve les problèmes de sécurité : <réponse fournie à la requête 1>
• Requête 3 : À partir des problèmes suivants : <problèmes signalés par la requête 2>, améliore le code suivant : <réponse fournie à la requête 1>

Cette façon de faire suppose bien évidemment que l’IAGén est capable de détecter des vulnérabilités, mais comme nous le verrons dans l’article suivant ce n’est pas encore le cas aujourd’hui.

Outils spécialisés

Nous pouvons néanmoins nous attendre à l’arrivée de nouveaux outils qui pourraient permettre aux programmeurs d’éviter les écueils de sécurité créés par l’IAGén.

Par exemple l’outil SafeCoder d’ETH Zurich [16] propose un cadre permettant d’améliorer la sécurité du code généré par une IAGén sans sacrifier la fonctionnalité de ce code. L’outil combine le réglage standard des instructions avec un réglage fin – spécifique à la sécurité, en utilisant des exemples de code sûrs et non-sûrs. Pour créer un ensemble de données de qualité, les auteurs ont mis en place un processus automatisé qui extrait les corrections de vulnérabilités vérifiées à partir des modifications de code enregistrées sur GitHub à l’aide d’un filtrage heuristique et d’une analyse statique basée sur l’outil CodeQL. Les résultats montrent que SafeCoder améliore la sécurité du code d’environ 30 % tout en conservant son utilité dans des étalons tels que HumanEval et MMLU. Les auteurs admettent cependant que l’outil n’améliore pas la sécurité de code contenant des vulnérabilités pour lesquelles il n’a pas été entrainé.

En attendant, une façon de procéder pourrait être de combiner un outil d’analyse statique « classique » avec une IAGén en demandant d’abord à l’IAGén de générer le code souhaité, puis en utilisant l’outil d’analyse statique pour analyser ce code. En cas de problème identifié par l’outil, si la correction n’est pas évidente, on peut demander à l’IAGén de modifier celui-ci en indiquant à celle-ci l’erreur précédemment identifiée. On peut recommencer la boucle jusqu’à ce qu’aucun problème ne soit identifié par l’outil d’analyse. Bien évidemment cette procédure fastidieuse pourrait être automatisée dans un cycle de développement logiciel habituel..

Conclusion

La première partie de cet article était dédiée à l’impact de l’IAGén sur la qualité du code en termes de sécurité. En l’état actuel des choses, force est de constater que malgré la capacité étonnante des outils d’IAGén à générer du code informatique, ce code peut souvent présenter des problèmes de sécurité – et ce quelque-soit le modèle choisi. Il convient donc d’être très vigilent avant d’utiliser du code généré par des outils d’IAGén. De plus, même si les IAGén peuvent faciliter certaines tâches de programmation, il n’en reste pas moins qu’elles ne portent pas la responsabilité des conséquences potentiellement négatives de leur « travail », responsabilité qui échoit au programmeur et à son employeur.

Les compétences et connaissances en matière de sécurité des programmeurs – dont la tâche évoluera progressivement de créateur de code à contrôleur de code – restent un atout essentiel. L’arrivée de l’IAGén dans le cycle de développement est peut-être une bonne occasion de renforcer la collaboration entre les équipes de sécurité et de développement en établissant (ou renforçant) des groupes de travail dans lesquels sont alignés des objectifs communs afin d’améliorer la sécurité.

Dans la seconde partie nous nous focaliserons sur l’utilisation de l’IAGén pour la détection de vulnérabilités dans le code.

Références

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking prompt engineering rechniques for secure code generation with GPT models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

De uitgebreide communicatie rond generatieve artificiële intelligentie (GenAI) en het toenemende gebruik ervan – althans in de testfase – uit angst om iets te missen of om een echte meerwaarde te bieden, roept de vraag op of het in veel domeinen nuttig is, en waarom niet, om de veiligheid van code te verbeteren. Meer bepaald: kan GenAI worden gebruikt om veiligere computercode te schrijven? Kan het helpen bij het opsporen van kwetsbaarheden in bestaande code?

In dit eerste deel geven we een antwoord op de eerste vraag. De tweede vraag komt in een ander artikel aan bod.

Menselijke aspecten

Laten we beginnen met het menselijke aspect van het gebruik van GenAI. In een gedetailleerde analyse, die ik ten zeerste aanbeveel, leggen Simkute et al. [1] de redenen uit die kunnen leiden tot een productiviteitsverlies van programmeurs die een beroep doen op GenAI. Onderzoekers hebben het onder andere over: een verglijding van de programmeurrol van productie naar evaluatie, een onnuttige herstructurering van werkstromen, onderbrekingen en de neiging van GenAI om makkelijke taken nog gemakkelijker en moeilijke taken nog moeilijker te maken. De resultaten van een studie van Perry et al. [2], van Stanford University verbazen ons dan minder. Deze tonen aan dat deelnemers die toegang hebben tot een codeerassistent op basis van een AI-model aanzienlijk minder veilige code schrijven dan deelnemers zonder toegang. Erger nog, deelnemers met toegang tot de assistent geloofden vaker dat ze veilige code schreven dan deelnemers zonder toegang. Deze observatie van Perry et al. wordt bevestigd door het werk van Klemmer et al. [3]: het onderzoeksteam ondervroeg professionele programmeurs, en hoewel zij wantrouwig staan tegenover suggesties van AI-codeerassistenten, blijkt dat zij ook hun eigen vermogen om de suggesties van deze codeerassistenten te beoordelen overschatten. Het gebruik van codeerassistenten vereist daarom de implementatie van systematische codecontrole en statische analyse [4].

Betrouwbaarheid van de voorstellen

Wat betreft de kwaliteit van de suggesties van GenAI: hoewel het over het algemeen functioneel correcte code oplevert, introduceert het ook veiligheidsproblemen [5], [6]. Khoury et al. [7] hebben met behulp van meerdere voorbeelden aangetoond dat ChatGPT 3.5 vaak code genereert die voor veiligheidsproblemen kan zorgen : slechts 5 van de 21 use cases die de auteurs bestudeerd hebben waren aanvankelijk beveiligd. ChatGPT 3.5 was in staat om beveiligde code aan te maken voor slechts 7 gevallen en dit was pas mogelijk nadat de auteurs expliciet vroegen om de code te verbeteren.

Meer recentelijk concludeerden Sivana et al. [8] dat ChatGPT als platform meer CWE-kwetsbaarheden genereerde dan de website StackOverflow. Onafhankelijk daarvan hebben Fu et al. [9] aan de hand van honderden door Copilot gegenereerde codevoorbeelden die op GitHub zijn gevonden, aangetoond dat ongeveer een derde daarvan veelvoorkomende kwetsbaarheden bevat die door de organisatie MITRE zijn geïnventariseerd (waarvan sommige tot de 25 belangrijkste behoren). De auteurs raden programmeurs daarom aan om de beste praktijken voor het gebruik van codegeneratietools te volgen en de gegenereerde codesuggesties altijd te controleren. Soortgelijke resultaten waren al gevonden door Pearce et al. [10] twee jaar eerder.

Er zijn nog veel meer voorbeelden van soortgelijke resultaten. Dat hebben Basic en Giaretta [11] gedaan in een uitgebreide systematische studie van de academische literatuur over GenAI en de veiligheid van computercode. De betrokken modellen zijn divers en omvatten onder meer ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet en Gemini Pro. De auteurs bevestigen dat verschillende belangrijke kwetsbaarheden, zoals SQL-injecties en bufferoverflows, kunnen worden aangetroffen in de code die door GenAI wordt gegenereerd. Ze wijzen er ook op dat het risico van vergiftiging van trainingsgegevens niet alleen kan leiden tot het genereren van onveilige code, maar ook de detectie van kwetsbaarheden in gevaar kan brengen.

Vergiftiging van AI

Het vergiftigen van een generatief model voor codeaanvulling bestaat uit het compromitteren van de integriteit van dit model door kwaadaardige codevoorbeelden in de trainingsgegevens van het model te integreren. Backdoor-aanvallen proberen tijdens de trainingsfase triggers te verbergen in het diepe neurale netwerk van het model, waardoor resultaten worden gegenereerd die door de tegenstander zijn gekozen.

Ondanks aanzienlijke vooruitgang op het gebied van codeaanvullingsmodellen blijven deze kwetsbaar voor dit soort aanvallen, zoals Yan et al. [12] met CodeBreaker hebben aangetoond. Voor hun aanval is het niet nodig om een vooraf getraind groot model zoals BERT of GPT te compromitteren. Deze modellen worden namelijk vaak gebruikt als basis die slachtoffers nauwkeurig afstemmen op specifieke taken met behulp van specifieke gegevens die vaak openbaar beschikbaar zijn. De tegenstander hoeft dus alleen maar deze finetuning data te compromitteren of zijn eigen set vervuilde data, gegenereerd met CodeBreaker, te uploaden. De vergiftigde code die na gebruik van CodeBreaker wordt gegenereerd, is niet detecteerbaar met kwetsbaarheidsdetectietools op basis van traditionele statische analyses of GenAI.

Hoewel dit soort aanvallen onwaarschijnlijk is, rijst de vraag waar de gebruikte GenAI-tool vandaan komt en past dit in de problematiek die inherent is aan de huidige GenAI om zowel veilige als nauwkeurige modellen te verkrijgen [13].

Belang van de prompt

Het is echter niet allemaal kommer en kwel en het belang van de keuze van de prompts die aan GenAI worden gegeven om het genereren van code met potentiële zwakke punten te voorkomen, moet worden benadrukt. Götz et al. [14] tonen aan dat, terwijl 65% van de code die oorspronkelijk door verschillende GenAI-tools werd gegenereerd, door een gekwalificeerde ingenieur als onveilig wordt beschouwd, dezelfde tools veilige code genereren wanneer ze handmatig worden aangestuurd. De auteurs concluderen dat technische expertise, met name op het gebied van beveiliging, vereist is om veilige code te genereren met behulp van code AI-codeerassistenten.

Om de best mogelijke resultaten te verkrijgen, moet de prompt die aan GenAI wordt gegeven zowel nauwkeurig als duidelijk interpreteerbaar zijn voor het model. Met andere woorden: de programmeur heeft er alle belang bij om zich aan de eisen van de machine te houden en zo gedetailleerd mogelijk niet alleen de taak die het model moet uitvoeren, maar ook de context waarin deze taak plaatsvindt en de verwachte invoer- en uitvoergegevens te specificeren. Dit kan in één keer gebeuren of in de vorm van een chain-of-thoughts volgens een bepaalde redenering.

Er bestaat echter geen ideale methode, maar Bruni et al. [15] geven verschillende eenvoudige voorbeelden van verbetering van prompts. Volgens hun experimenten is de meest effectieve methode om, na een eerste prompt, GenAI te vragen de code die het al heeft voorgesteld op mogelijke kwetsbaarheden te herzien en vervolgens correcties voor te stellen. Bijvoorbeeld:

• Prompt 1: genereer Java-code voor …
• Prompt 2: analyseer de volgende code en vind de beveiligingsproblemen: <antwoord op prompt 1>
• Prompt 3: op basis van de volgende problemen: <problemen gemeld door prompt 2>, verbeter de volgende code: <antwoord gegeven op prompt 1>

Deze werkwijze veronderstelt uiteraard dat GenAI in staat is om kwetsbaarheden op te sporen, maar zoals we in het volgende artikel zullen zien, is dat vandaag nog niet het geval.

Gespecialiseerde tools

We kunnen echter nieuwe tools verwachten die programmeurs in staat zullen stellen om de veiligheidsrisico’s van GenAI te vermijden.

Zo biedt de tool SafeCoder van ETH Zürich [16] een kader om de veiligheid van door GenAI gegenereerde code te verbeteren zonder de functionaliteit van die code in het gedrang te brengen. De tool combineert de standaardinstellingen van instructies met een veiligheidsgerichte finetuning aan de hand van veilige en onveilige codevoorbeelden. Om een dataset van hoge kwaliteit te creëren, hebben de auteurs een geautomatiseerd proces opgezet dat geverifieerde kwetsbaarheidscorrecties uit de op GitHub geregistreerde codewijzigingen haalt met behulp van heuristische filtering en statische analyse op basis van de CodeQL-tool. De resultaten tonen aan dat SafeCoder de codeveiligheid met ongeveer 30% verbetert, terwijl de bruikbaarheid in benchmarks zoals HumanEval en MMLU behouden blijft. De auteurs geven echter toe dat de tool de veiligheid van code met kwetsbaarheden waarvoor hij niet is getraind, niet verbetert.

In de tussentijd kan een manier zijn om een traditionele statische analyse te combineren met GenAI door eerst de GenAI te vragen de gewenste code te genereren en vervolgens de statische analyse te gebruiken om deze code te analyseren. Als de tool een probleem identificeert en de correctie niet voor de hand ligt, kan men de GenAI vragen om de code aan te passen, waarbij de eerder geïdentificeerde fout wordt aangegeven. De lus kan worden herhaald totdat er geen probleem meer wordt geïdentificeerd door het analyse tool. Natuurlijk kan deze omslachtige procedure worden geautomatiseerd in een normale softwareontwikkelingscyclus.

Conclusie

Het eerste deel van dit artikel ging over de impact van GenAI op de kwaliteit van code in termen van beveiliging. In de huidige situatie moet worden vastgesteld dat, ondanks het verbazingwekkende vermogen van GenAI-tools om computercode te genereren, deze code vaak veiligheidsproblemen kan opleveren, ongeacht het gekozen model. Het is daarom raadzaam om zeer waakzaam te zijn vooraleer we code gebruiken die door GenAI-tools is gegenereerd. Bovendien kunnen GenAI-tools bepaalde programmeertaken vergemakkelijken, maar dat neemt niet weg dat zij niet verantwoordelijk zijn voor de mogelijke negatieve gevolgen van hun “werk”. Die verantwoordelijkheid ligt bij de programmeur en zijn werkgever.

De vaardigheden en kennis op het gebied van veiligheid van programmeurs – wier taak geleidelijk zal evolueren van codeschrijver naar codecontroleur – blijven een essentiële troef. De komst van GenAI in de ontwikkelcyclus is misschien een goede gelegenheid om de samenwerking tussen beveiligings- en ontwikkelingsteams te versterken door werkgroepen op te richten (of te versterken) waarin gemeenschappelijke doelstellingen worden afgestemd om de beveiliging te verbeteren.

In het tweede deel zullen we ons concentreren op het gebruik van GenAI voor het opsporen van kwetsbaarheden in code.

Referenties

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking Prompt Engineering Techniques for Secure Code Generation with GPT Models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

(NL) CodeQL is een statische code analyse tool gebaseerd op tientallen jaren onderzoek door een team aan de Universiteit van Oxford. Het kan worden gebruikt om applicaties automatisch te scannen op complexe kwetsbaarheden en bugs en om programmeurs te helpen bij het handmatig controleren van code.

Le classement en niveaux de sensibilité des données est le pivot sur lequel repose l’ensemble du système de sécurité des données ultérieur. L’objectif d’un système de classement de données est donc d’identifier clairement les informations qui doivent être protégées pour des raisons de sécurité et de fournir des directives adéquates en matière de classement afin que les informations qui n’ont pas besoin d’une telle protection ne soient pas inutilement classées par un système hiérarchique du secret. Une fois les données correctement classées une étiquette de confidentialité peut leur être apposée.

Dans un précédent article nous avons vu des techniques permettant de protéger des objets de données sensibles, notamment grâce à un étiquetage permettant de décider si ces objets peuvent être transmis ou pas d’un système informatique à un autre. Comme nous l’avons noté, il existe deux manières principales d’assigner une étiquette de confidentialité à un objet :

• Évaluer le contenu même de l’objet de données afin de déterminer les attributs de confidentialité.
• Baser les propriétés de confidentialité sur l’origine de l’information présente dans l’objet de données.

Malheureusement ce type de solutions ne répond pas à la question de savoir si les objets ont été étiquetés correctement ou pas, par l’utilisateur ou par le service ayant initié le transfert^1,2.

Afin de mitiger les risques, une technique fréquente est de scanner les données transférées pour la présence de certains mots-clés considérés comme pouvant indiquer du contenu classifié selon des niveaux de confidentialité (p. ex., niveaux de classification, lieux, nom de projets, acronymes de projets, termes techniques, etc.). Une telle technique impose la mise à jour fréquente de la liste des mots-clés et le résultat dépend fortement de la qualité de la liste. C’est un travail laborieux et d’autant plus difficile dans un contexte où sont interconnectés plusieurs systèmes informatiques d’organisations différentes, voire de pays différents.

Alors, est-il possible d’évaluer de manière automatique la présence de données classifiées au sein d’autres données échangées entre deux systèmes informatiques, afin de s’assurer que la politique de sécurité appliquée aux données n’est pas violée ?

Détection simple

Les systèmes de prévention de perte ou fuite de données (« Data leakage prevention (DLP) » ou « Data loss prevention (DLP) ») analysent les flux de données et appliquent des politiques afin de préserver les données sensibles en cours d’utilisation (actions sur les terminaux), en mouvement (trafic réseau), et au repos (stockage de données). En 2015 plus d’une douzaine d’entreprises promouvaient déjà leurs solutions techniques. En 2023, Chugh et al. [1] en répertoriaient plus d’une trentaine. La sélection n’est pas chose facile car, comme le faisaient remarquer Gugelmann et al. [2], les entreprises concernées sont assez réluctantes pour divulguer des informations sur le fonctionnement de leurs produits. Par ailleurs les modèles de menaces ne sont pas toujours clairement définis et varient d’un vendeur à l’autre.

Néanmoins, on peut citer plusieurs méthodes d’analyse des données [3] fréquemment utilisées dont :

• Règles d’expressions régulières : celles-ci supposent des scenarios basés sur des environnements très contrôlés (règles pour détecter des destinataires de courriels erronés ou non nécessaires, règles pour reconnaître des numéros de cartes de crédit, des numéros de passeport, etc.).
• Détection d’empreintes : il s’agit de la recherche de correspondances exactes entre les éléments d’une base de données à inspecter et des éléments fournis pour l’analyse (mots-clés, numéros d’identification spécifiques, etc.).
• Correspondance de fichiers : comparaison des valeurs de hachage cryptographique des fichiers analysés avec une liste donnée.
• Analyse statistique : voir ci-dessous.

Analyses statistiques

L’analyse se révèle plus complexe lorsque l’on considère des documents entiers et non plus certains éléments. Dès 2008, Kassidy-Clark [4] suggérait l’idée d’utiliser des techniques d’apprentissage automatique afin d’automatiser le processus d’assignation de protection appropriée aux données en fonction de leur sensibilité, afin notamment de s’affranchir des limites de la classification manuelle en terme de vitesse et de cohérence. En 2010, dans une approche plus pratique, Brown et al. [5] évaluaient l’efficacité des techniques de traitement du langage naturel statistique et d’apprentissage automatique pour attribuer automatiquement une classification de confidentialité à un document non structuré. En utilisant une approche traditionnelle d’apprentissage automatique les auteurs pouvaient obtenir une précision de classification de 80%.

Kongsgård et al. [6] ont proposé un cadre permettant de sécuriser et d’automatiser l’étiquetage des données afin d’offrir un équilibre entre justesse des étiquettes de confidentialité et flexibilité du système. L’idée est de déduire un grand nombre d’attributs³ à partir de l’objet lui-même, des circonstances de l’étiquetage, du sujet pour qui l’objet est étiqueté ainsi que de l’environnent dont est issu l’objet. Ces attributs sont ensuite utilisés pour déterminer l’étiquette de confidentialité à appliquer en fonction d’une politique donnée. Ce cadre peut aussi être utilisé pour suggérer à un utilisateur quelles étiquettes appliquer.

En 2017 des chercheurs de l’Agence des communications et de l’information de l’OTAN ont proposé un processus automatisé pouvant offrir une aide importante à l’examen manuel des documents [7]. Il consiste à fournir un pré-étiquetage automatisé des documents, accompagné d’une évaluation des niveaux de confiance concernant les étiquettes identifiées avant contrôle manuel par un opérateur. Après évaluation de différents outils disponibles dans le domaine public, les auteurs concluent que même si les résultats de la classification automatique ne sont pas suffisamment précis (bien en dessous de 100% d’exactitude) pour les documents de l’OTAN, leur utilisation apporte un soutien non négligeable au personnel concerné.

La même année, Alzhrani et al. [8] utilisent les télégrammes diplomatiques disponibles sur WikiLeaks (dont le niveau de sensibilité est connu) afin de construire des algorithmes de classification automatique et de détecter des comportements malveillants d’employés. La classification est effectuée au niveau des paragraphes de chaque document. En effet, les auteurs font remarquer que quelques caractéristiques peu fréquentes peuvent impacter la classification d’un document entier vers un plus haut niveau de classification et qu’il est erroné de supposer que toutes les portions d’un même document appartiennent au même niveau de sécurité.

Enfin, Frayling et al. [9] affirment que la classification automatique de textes en fonction de leur sensibilité est difficile. En effet la sensibilité est souvent due à une bonne connaissance contextuelle qui doit être déduite du texte. Ils donnent l’exemple du simple nom d’une entité qui, en lui-même, n’est peut-être pas sensible, mais le devient lorsque le rôle de l’entité est connu (p. ex., « Marc Dubois » et « espion »). Un expert humain peut déduire les sensibilités latentes grâce à ses connaissances du domaine dont il est question, mais les classificateurs textuels automatiques (entrainés ou pas sur des données contextualisées) ont d’importantes limites.

Malgré des progrès significatifs, les méthodes statistiques permettant de déterminer de manière automatique le niveau de sensibilité d’un objet de données, ne sont pas encore suffisamment fiables, mais cela n’empêche pas leur utilisation sous forme de recommandation. C’est par exemple ce que propose l’une des sociétés importantes du domaine.

Exemple d’application pratique

Récemment achetée par Airbus⁴, la société allemande Infodas est accréditée par l’Union Européenne, le Gouvernement allemand, et l’OTAN au niveau « secret ». Sa famille de dispositifs de sécurité matériels appelée « Secure Domain Transition (SDoT) » permet de connecter des systèmes de différents niveaux de classification. Seules les données autorisées à quitter un domaine de niveau de classification élevé peuvent le faire. Les produits SDoT utilisent des filtres (p. ex. expression régulières) pour les données structurées ou des étiquettes de confidentialité qui sont liées cryptographiquement à n’importe quel objet de données.

En particulier l’appareil d’étiquetage « SDoT Labelling Service⁵ » prend en charge la classification des données sensibles et la vérification des étiquettes (de type XML liées cryptographiquement aux objets protégés). Le service d’étiquetage, disponible sous forme de machine virtuelle ou sous forme d’appareil, permet l’étiquetage des données, compatible avec les accords de normalisation STANAG 4774 et 4778 de l’OTAN (voir article précédent) et peut être intégré aux applications standards de bureautique. L’étiquetage, qui peut être appliqué à tous les documents textuels ainsi qu’aux documents papier numérisés, n’est pas automatique mais des suggestions sont faites à un opérateur qui prend la décision finale.

Conclusions

La protection de données dont le niveau de sensibilité est bien défini, est un problème relativement bien compris pour lequel des techniques standardisées offrent des solutions efficaces. En revanche, malgré des progrès importants pour prévenir les fuites de données, l’évaluation automatique du niveau de sensibilité explicite ou latente des données, reste encore limitée. La recherche scientifique est peu développée et la plupart des outils proposent des mécanismes fondés sur des règles d’expressions régulières. Certains ajoutent des méthodes statistiques – apprentissage automatique, voire « d’intelligence artificielle » – afin de faciliter la tâche du personnel en charge de la classification, mais l’exercice reste en grande partie manuel.

Références bibliographiques

[1]     R. Chugh et A. Bales, « Market guide for data loss prevention », Gartner, G00776480, sept. 2023.

[2]     D. Gugelmann, P. Studerus, V. Lenders, et B. Ager, « Can content-based data loss prevention solutions prevent data leakage in Web traffic? », 2015.

[3]     R. Mogull, « Understanding and selecting a data loss prevention solution », SANS Institute, 2007.

[4]     K. P. Clark, « Automated security classification », Vrije Universiteit, Amsterdam, 2008.

[5]     J. D. Brown et D. Charlebois, « Security Classification Using Automated Learning (SCALE): Optimizing Statistical Natural Language Processing Techniques to Assign Security Labels to Unstructured Text », Defence R&D Canada, Technical Memorandum TM 2010-215, déc. 2010.

[6]     K. W. Kongsgård, N. A. Nordbotten, et S. Fauskanger, « Policy-based labelling: A flexible framework for trusted data labelling », in 2015 International Conference on Military Communications and Information Systems (ICMCIS), Cracow, Poland: IEEE, mai 2015, p. 1‑10. doi: 10.1109/ICMCIS.2015.7158708

[7]     M. Richter et K. Wrona, « Devil in the details: Assessing automated confidentiality classifiers in context of NATO documents », in Proceedings of the First Italian Conference on Cybersecurity (ITASEC17), Venice, Italy, janv. 2017.

[8]     K. Alzhrani, E. M. Rudd, C. E. Chow, et T. E. Boult, « Automated U.S. diplomatic cables security classification: Topic model pruning vs. classification based on clusters », 7 mars 2017, arXiv: arXiv:1703.02248. Consulté le: 2 août 2024. [En ligne]. Disponible sur: http://arxiv.org/abs/1703.02248

[9]     E. Frayling, C. Macdonald, G. McDonald, et I. Ounis, « Using entities in knowledge graph hierarchies to classify sensitive information », in Experimental IR
Meets Multilinguality, Multimodality, and Interaction, A. Barrón-Cedeño, G. Da San Martino, M. Degli Esposti, F. Sebastiani, C. Macdonald, G. Pasi, A. Hanbury, M. Potthast, G. Faggioli, et N. Ferro, Éd., in Lecture Notes in Computer Science, vol. 13390. Bologna, Italy: Springer International Publishing, sept. 2022, p. 125‑132. doi: 10.1007/978-3-031-13643-6_10

Notes

¹   C’est particulièrement le cas si des plateformes courantes (p. ex. Windows) sont utilisées fréquemment.

²   Le volume des objets à étiqueter pouvant être important (p. ex., données de capteurs), et le format de ceux-ci pouvant être incompatible avec un contrôle humain, il n’est pas réaliste d’espérer que chaque étiquetage puisse faire l’objet d’une vérification par un utilisateur.

³   Dans leur système, des modules de collection d’attributs ont accès en lecture seule à l’objet ainsi qu’aux attributs déjà renvoyés par d’autres modules. Ces modules peuvent contrôler le contenu pour certains mots-clés, fournir des attributs sur le sujet demandant accès, etc.

⁴   https://www.airbus.com/en/newsroom/press-releases/2024-03-airbus-to-acquire-infodas-and-strengthen-its-cybersecurity

⁵   https://www.infodas.com/en/products/sdot_cross_domain_solutions/labelling-service-data-classification/

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

De classificering in gevoeligheidsniveaus van gegevens is de hoeksteen waarop het hele latere gegevensbeveiligingssysteem rust. Het doel van een classificeringssysteem voor gegevens is dan ook om duidelijk vast te stellen welke informatie om veiligheidsredenen moet worden beschermd en om passende classificeringsrichtlijnen op te stellen, zodat informatie die deze bescherming niet nodig heeft niet onnodig wordt geclassificeerd door een hiërarchisch systeem van geheimhouding. Zodra de gegevens correct geclassificeerd zijn kan een vertrouwelijkheidslabel aangebracht worden.

In een vorig artikel zagen we de technieken waarmee gevoelige data-objects beschermd kunnen worden, namelijk dankzij labeling waarmee beslist kan worden of deze objects al dan niet van het ene informaticasysteem naar het andere kunnen overgemaakt worden. Zoals we al opmerkten bestaan er twee belangrijke manieren om een vertrouwelijkheidslabel toe te kennen aan een object.

• De inhoud van het data-object zelf evalueren om de vertrouwelijkheidsattributen te bepalen.
• De vertrouwelijkheidskenmerken baseren op de oorsprong van de informatie in het data-object.

Spijtig genoeg geeft dit type oplossingen geen antwoord op de vraag of de objecten al dan niet correct gelabeld zijn, door de gebruiker of door de dienst die de overdracht heeft geïnitieerd^1,2.

Om de risico’s te beperken, is een veelgebruikte techniek om de overgedragen gegevens te scannen op de aanwezigheid van bepaalde trefwoorden die geacht worden inhoud aan te duiden die geclassificeerd is volgens vertrouwelijkheidsniveaus (bv. classificatieniveaus, locaties, projectnamen, projectafkortingen, technische termen, enz.). Een dergelijke techniek vereist het regelmatig bijwerken van de trefwoordenlijst en het resultaat is sterk afhankelijk van de kwaliteit van die lijst. Dit is arbeidsintensief werk, en des te moeilijker in een context waarin meerdere IT-systemen van verschillende organisaties of zelfs verschillende landen met elkaar verbonden zijn.

Is het dus mogelijk om automatisch de aanwezigheid van geclassificeerde gegevens te evalueren binnen andere gegevens die worden uitgewisseld tussen twee IT-systemen, om ervoor te zorgen dat het beveiligingsbeleid dat wordt toegepast op de gegevens niet wordt geschonden?

Eenvoudige opsporing

Systemen om gegevensverlies of lekken te voorkomen (“Data leakage prevention (DLP)” of “Data loss prevention (DLP)”) analyseren de gegevensstromen en passen de policy’s toe om de gevoelige gegevens tijdens het gebruik (handelingen op terminals), in beweging (netwerkverkeer), en in rust (gegevensopslag) te vrijwaren. In 2015 promootten al meer dan een dozijn ondernemingen hun technische oplossingen. In 2023 toonden Chugh et al. [1] er al een dertigtal. De selectie was niet gemakkelijk omdat, zoals Gygelmann et al. [2] opmerkten, de betrokken ondernemingen terughoudend zijn om informatie te verspreiden over de werking van hun producten. De dreigingsmodellen zijn overigens niet altijd duidelijk omlijnd en variëren van de ene verkoper tot de andere.

We kunnen echter meerdere methodes voor gegevensanalyse [3] aanhalen die vaak gebruikt worden:

• Regels voor reguliere expressie: scenario’s die gebaseerd zijn op sterk gecontroleerde omgevingen (regels om onjuiste of onnodige e-mailontvangers te detecteren, regels om creditcardnummers, paspoortnummers, etc. te herkennen).
• Fingerprint detection: een zoekopdracht naar exacte overeenkomsten tussen elementen in een database die moet worden geïnspecteerd en elementen die zijn verstrekt voor analyse (trefwoorden, specifieke identificatienummers, enz.).
• Matching van bestanden: vergelijking van de cryptografische hashwaarden van de geanalyseerde bestanden met een bepaalde lijst.
• Statistische analyse: zie hieronder.

Statistische analyses

De analyse blijkt complexer te zijn wanneer we volledige documenten overwegen en niet langer bepaalde elementen. Al in 2008 opperde Kassidy-Clark [4] het idee om technieken voor machinaal leren te gebruiken om het proces van het toewijzen van de juiste bescherming aan gegevens op basis van hun gevoeligheid te automatiseren, met name om af te stappen van de beperkingen van handmatige classificatie op het gebied van snelheid en consistentie. In 2010 evalueerden Brown et al., met een meer praktische aanpak, [5] de effectiviteit van statistische natuurlijke taalverwerking en machinelearning-technieken voor het automatisch toekennen van een vertrouwelijkheidsclassificatie aan een ongestructureerd document. Met behulp van een traditionele machinelearning-benadering waren de auteurs in staat om een classificatienauwkeurigheid van 80% te bereiken.

Kongsgård et al. [6] hebben een kader voorgesteld om het labelen van gegevens te beveiligen en te automatiseren om een balans te vinden tussen de nauwkeurigheid van vertrouwelijkheidslabels en de flexibiliteit van het systeem. Het idee is om een groot aantal attributen³ af te leiden uit het object zelf, de omstandigheden van de labeling, het subject voor wie het object gelabeld is en de omgeving waaruit het object afkomstig is. Deze attributen worden vervolgens gebruikt om te bepalen welk vertrouwelijkheidslabel moet worden toegepast volgens een bepaald beleid. Dit kader kan ook worden gebruikt om aan een gebruiker voor te stellen welke labels toe te passen.

In 2017 stelden onderzoekers van het NAVO Communications and Information Agency een geautomatiseerd proces voor dat een aanzienlijke ondersteuning zou kunnen bieden voor het handmatig beoordelen van documenten [7]. Het bestaat uit een geautomatiseerde pre-labeling van documenten, met een evaluatie van de betrouwbaarheidsniveaus van de geïdentificeerde labels vóór een handmatige controle door een operator. Na evaluatie van verschillende tools die in het publieke domein beschikbaar zijn, concluderen de auteurs dat zelfs als de resultaten van automatische classificatie niet voldoende accuraat zijn (ver onder 100% accuraatheid) voor NATO-documenten het gebruik ervan een aanzienlijke ondersteuning biedt aan het betrokken personeel.

In hetzelfde jaar gebruikten Alzhrani et al. [8] diplomatieke telegrammen die beschikbaar zijn op WikiLeaks (waarvan het gevoeligheidsniveau bekend is) om de automatische classificatiealgoritmes aan te maken en kwaadwillige gedragingen van werknemers op te sporen. Classificatie wordt uitgevoerd op paragraafniveau van elk document. In feite wijzen de auteurs erop dat een paar weinig voorkomende kenmerken een invloed kunnen hebben op de classificatie van een volledig document naar een hoger classificatieniveau, en dat het verkeerd is om aan te nemen dat alle delen van hetzelfde document tot hetzelfde beveiligingsniveau behoren.

Tot slot bevestigen Frayling et al. [9] dat het automatisch classificeren van teksten op basis van hun gevoeligheid moeilijk is. Gevoeligheid is vaak het gevolg van een goede contextuele kennis die uit de tekst moet worden afgeleid. Ze geven het voorbeeld van de eenvoudige naam van een entiteit die op zichzelf misschien niet gevoelig is, maar dat wel wordt als de rol van de entiteit bekend is (bv. “Jan Peeters” en “spion”). Een menselijke expert kan latente gevoeligheden afleiden op basis van zijn kennis van het domein in kwestie, maar automatische tekstclassificeerders (al dan niet getraind op gecontextualiseerde gegevens) hebben aanzienlijke beperkingen.

Ondanks aanzienlijke vooruitgang zijn statistische methoden voor het automatisch bepalen van het gevoeligheidsniveau van een data-object nog niet voldoende betrouwbaar, maar dit belet niet dat ze kunnen worden gebruikt in de vorm van aanbevelingen. Dit is bijvoorbeeld wat een van de toonaangevende bedrijven op dit gebied voorstelt.

Voorbeeld van praktische toepassing

Het Duitse bedrijf Infodas is onlangs overgenomen door Airbus⁴ en is geaccrediteerd door de Europese Unie, de Duitse overheid en de NAVO wat betreft “secrecy”. De familie hardwarebeveiligingsapparaten ervan, genaamd Secure Domain Transition (SDoT), maakt het mogelijk om systemen met verschillende classificatieniveaus met elkaar te verbinden. Alleen gegevens die een domein met een hoog classificeringsniveau mogen verlaten, kunnen dat doen. SDoT-producten gebruiken filters (bv. reguliere expressies) voor gestructureerde gegevens of vertrouwelijkheidslabels die cryptografisch gekoppeld zijn aan elk data-object.

De SDoT Labelling Service⁵ ondersteunt met name de classificatie van gevoelige gegevens en de verificatie van labels (XML-tags die cryptografisch zijn gekoppeld aan beschermde objecten). De labeling-service, beschikbaar als virtuele machine of als appliance, maakt het mogelijk om gegevens te labelen, is compatibel met de NAVO-standaardisatieovereenkomsten STANAG 4774 en 4778 (zie vorig artikel) en kan worden geïntegreerd in standaard kantoorautomatiseringstoepassingen. Het labelen, dat kan worden toegepast op alle tekstdocumenten en gescande papieren documenten, gebeurt niet automatisch, maar er worden suggesties gedaan aan een operator die de uiteindelijke beslissing neemt.

Conclusies

Het beschermen van gegevens met een goed omlijnd gevoeligheidsniveau is een relatief goed begrepen probleem waarvoor gestandaardiseerde technieken effectieve oplossingen bieden. Ondanks de aanzienlijke vooruitgang in het voorkomen van datalekken, is de automatische evaluatie van de expliciete of latente gevoeligheid van gegevens nog steeds beperkt. Wetenschappelijk onderzoek is nog niet zover gevorderd en de meeste tools bieden mechanismen op basis van reguliere expressieregels. Sommige voegen statistische methoden toe – machine learning of zelfs “artificiële intelligentie” – om de taak van de medewerkers die verantwoordelijk zijn voor de classificatie te vergemakkelijken, maar de oefening blijft grotendeels handmatig.

Bibliografische referenties

[1]   R. Chugh en A. Bales, ‘Market guide for data loss prevention’, Gartner, G00776480, sep. 2023.

[2]   D. Gugelmann, P. Studerus, V. Lenders, en B. Ager, ‘Can content-based data loss prevention solutions prevent data leakage in Web traffic?’, 2015.

[3]   R. Mogull, ‘Understanding and selecting a data loss prevention solution’, SANS Institute, 2007.

[4]   K. P. Clark, ‘Automated security classification’, Vrije Universiteit, Amsterdam, 2008.

[5]   J. D. Brown en D. Charlebois, ‘Security Classification Using Automated Learning (SCALE): Optimizing Statistical Natural Language Processing Techniques to Assign Security Labels to Unstructured Text’, Defence R&D Canada, Technical Memorandum TM 2010-215, dec. 2010.

[6]   K. W. Kongsgård, N. A. Nordbotten, en S. Fauskanger, ‘Policy-based labelling: A flexible framework for trusted data labelling’, in 2015 International Conference on Military Communications and Information Systems (ICMCIS), Cracow, Poland: IEEE, mei 2015, pp. 1-10. doi: 10.1109/ICMCIS.2015.7158708

[7]   M. Richter en K. Wrona, ‘Devil in the details: Assessing automated confidentiality classifiers in context of NATO documents’, in Proceedings of the First Italian Conference on Cybersecurity (ITASEC17), Venice, Italy, jan. 2017.

[8]   K. Alzhrani, E. M. Rudd, C. E. Chow, en T. E. Boult, ‘Automated U.S. diplomatic cables security classification: Topic model pruning vs. classification based on clusters’, 7 maart 2017, arXiv: arXiv:1703.02248. Geraadpleegd: 2 augustus 2024. [Online]. Beschikbaar op: http://arxiv.org/abs/1703.02248

[9]   E. Frayling, C. Macdonald, G. McDonald, en I. Ounis, ‘Using entities in knowledge graph hierarchies to classify sensitive information’, in Experimental IR Meets Multilinguality, Multimodality, and Interaction, A. Barrón-Cedeño, G. Da San Martino, M. Degli Esposti, F. Sebastiani, C. Macdonald, G. Pasi, A. Hanbury, M. Potthast, G. Faggioli, en N. Ferro, Red., in Lecture Notes in Computer Science, vol. 13390. Bologna, Italy: Springer International Publishing, sep. 2022, pp. 125-132. doi: 10.1007/978-3-031-13643-6_10

 Noten

¹   Dat is in het bijzonder het geval wanneer de huidige platformen (bv. Windows) frequent gebruikt worden.

²   Aangezien de hoeveelheid te labelen objecten groot kan zijn (bijv. sensorgegevens) en het formaat van deze objecten incompatibel kan zijn met menselijke controle, is het onrealistisch om te verwachten dat elk label door een gebruiker kan worden gecontroleerd.

³ In hun systeem hebben modules voor attributenverzameling toegang in read-only-modus tot het object en tot attributen die al door andere modules zijn teruggestuurd. Deze modules kunnen de inhoud controleren voor bepaalde sleutelwoorden, attributen verstrekken over het onderwerp dat om toegang vraagt, enz.

⁴   https://www.airbus.com/en/newsroom/press-releases/2024-03-airbus-to-acquire-infodas-and-strengthen-its-cybersecurity

⁵   https://www.infodas.com/en/products/sdot_cross_domain_solutions/labelling-service-data-classification/

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Oorzaken van datalekken en veiligheidsincidenten zijn onder andere het per ongeluk delen of verkeerd gebruiken van gevoelige gegevens door een bediende of onderaannemer, of opzettelijke diefstal van gegevens door een kwaadwillige insider voor persoonlijk gebruik. Spijtig genoeg zijn veel gebruikelijke methodes en aanpakken niet ontworpen tegen dergelijke schendingen door gebruikers die a priori betrouwbaar lijken. De efficiëntste technieken zijn nog steeds voorbehouden aan zeer specifieke sectoren.

Het probleem bestaat echter al langer. In bepaalde kritische domeinen zoals de staatsveiligheid is het een gekend probleem. Sinds de jaren 70 inspireerde het model Bell-LaPadula¹ de compartimentering van informaticasystemen in geïsoleerde beveiligingsdomeinen. Een organisatie kan bijvoorbeeld fysiek gescheiden systemen invoeren: een verbonden met internet voor gegevens zonder specifiek vertrouwelijkheidsniveau en een voor elke van de vertrouwelijkheidsniveaus van de organisatie zoals “beperkt”, “vertrouwelijk” of “geheim”. Daarbovenop komen vaak klassieke mechanismes zoals het gebruik van vercijferde bestandssystemen, de blokkering – of zelfs verwijdering – van USB-poorten, de beperking van copy/pasten in software, maar ook de controle van alle gegevens die circuleren op het informaticanetwerk zodat gevoelige of vertrouwelijke gegevens kunnen opgespoord worden.

Om gegevens van een niveau naar een ander over te brengen kan deze organisatie een beroep doen op gespecialiseerde IT gateways bij de bescherming van de gegevens. Deze veronderstellen dat elk gegeven, alsook de gebruiker of de dienst van het domein dat deze gegevens verstuurt, eerst wordt gekoppeld aan een vertrouwelijkheidslabel waarmee beslist wordt of de gegevens al dan niet doorgestuurd kunnen worden. Informatiebescherming gebeurt met andere woorden op het vlak van de data-objecten zelf in plaats van op het vlak van domeinen die aangemaakt werden met gescheiden informaticanetwerken (die soms ontoegankelijk zijn en leiden tot stoelendansen).

Vertrouwelijkheidslabels

De vertrouwelijkheidslabels zijn een manier om verschillende beveiligingskenmerken² te linken aan een specifiek object. Deze vertrouwelijkheidslabels kunnen eender welke nuttige informatie bevatten om beslissingen te nemen op het vlak van veiligheid en worden a priori beschouwd als correct wanneer een veiligheidsbeslissing zich daarop baseert. Er bestaan twee belangrijke manieren om een vertrouwelijkheidslabel toe te kennen aan een data-object:

• De veiligheidseigenschappen baseren op de oorsprong van de informatie aanwezig in het data-object. Dat is de eenvoudigste methode op voorwaarde dat de oorsprong van de informatie traceerbaar is.
• De eigenlijke inhoud van het data-object evalueren om de beveiligingskenmerken te bepalen. In een volgend artikel bekijken we hoe deze toewijzing min of meer automatisch kan verlopen.

Het gebruik van vertrouwelijkheidslabels heeft verschillende beperkingen. Bij de onderlinge verbinding van twee systemen op verschillende veiligheidsniveaus moet er rekening gehouden worden met het risico op verkeerde labeling van de objecten (bv. gebruikersfout, misbruikt of gecompromitteerd systeem, enz.). Bovendien:

• Weerspiegelt een vertrouwelijkheidslabel de beschermingsvereisten en de voorwaarden voor vrijgave van een object bij de creatie van dit label. De update van deze laatste vereist manuele handelingen die strikte beheersprocessen moeten volgen.
• De labeling volgt niet altijd correct de objecten, zelfs binnen eenzelfde organisatie.
• Omwille van subjectieve interpretaties van het veiligheidsbeleid kunnen de auteurs van de objecten verschillende vertrouwelijkheidslabels plakken op objecten met gelijkaardige inhoud. Dit kan leiden tot situaties waarin sterk gelijkende gegevens verschillende beveiligingsniveaus kunnen hebben.

De labeling van de informatie leidt dus tot minstens twee belangrijke uitdagingen. De eerste betreft het bestaan van een syntaxis en een gemeenschappelijke interpretatie van de labels – dit wil zeggen tussen de systemen die informatie willen uitwisselen. De andere is de definitie van een mechanisme waarmee deze labels verbonden kunnen worden aan de objecten waarbij de integriteit van deze link verzekerd wordt.

Gestandaardiseerd mechanisme

In 2010 heeft de onderzoeksgroep voor domeinoverschrijdende veiligheidsoplossingen van de Organisatie voor Wetenschap en Technologie van de NAVO een voorstel gepubliceerd voor XLM-specificatie voor labeling en verbinding van metagegevens. Dit werk werd later verwerkt in twee “standardisation agreements” of “STANAG”.

Het eerste standardisation agreement “STANAG 4774 – Confidentiality Metadata Label Syntax” [1] is een XML-schema dat gebruikt kan worden om een vertrouwelijkheidslabel weer te geven en om machtigingen van de entity’s te beschrijven. Het voorziet formaten en een gemeenschappelijke XML-gebaseerde syntaxis voor veiligheidspolicy’s en vertrouwelijkheidsmetadata. Het kan toegepast worden tussen entity’s die bestuurd worden door verschillende, identieke policy’s of zonder veiligheidspolicy. Om de interoperabiliteit tussen verschillende systemen te verzekeren bestaan er profielen voor verschillende objecttypes: SOAP, REST, Office Open XML, enz.

In het kader van deze standardisation agreement werd de syntaxis van de vertrouwelijkheidslabels ontworpen om gebruikt te worden zodat een of meerdere elementen van metadata bepaald kunnen worden aangezien deze elementen op hun beurt verbonden worden aan de data-objecten. De vertrouwelijkheidslabels kunnen drie soorten metadata specificeren:

• vertrouwelijkheidslabel door de auteur toegekend aan de informatie.
• vertrouwelijkheidslabel in een verschillende policy die vergelijkbaar is met het vertrouwelijkheidslabel van de auteur.
• vertrouwelijkheidslabel verbonden aan de beschrijvende metadata van het beveiligde object.

Het tweede standardisation agreement “STANAG 4778 – Metadata Binding Mechanism” [2] is een XML-schema dat gebruikt kan worden om willekeurige metadata (ook metadata die de syntaxis van het vertrouwelijkheidslabel gebruiken) te verbinden aan de data-objecten tijdens hun levenscyclus en doorheen verschillende organisaties. De link tussen de metadata en het object zorgt er bijvoorbeeld voor dat de oorsprong van de gegevens bewezen, hun integriteit en authenticiteit gecontroleerd, hun vertrouwelijkheid en informatiebescherming verzekerd, een controleketen opgezet en informatiedeling vergemakkelijkt kan worden. Deze manier van veiligheidsdata en -metadata met elkaar te verbinden doet denken aan de methoden voor het beheer van digitale beperkingen die gebruikt worden om onder andere digitale auteursrechtelijke werken te beschermen.

De STANAG-norm 4778 laat verschillende aanpakken toe:

• Losse verbinding: de metadata worden opgeslagen in een aparte structuur van het data-object, en de twee worden aan elkaar gekoppeld via een referentie.
• Integration: de verbinding wordt geïntegreerd in het data-object en de verbinding bevat een referentie naar het data-object.
• Encapsulation: het data-object en de metadata worden ingekapseld in de verbinding en weergegeven door een nieuw samengesteld data-object.

Aangezien een data-object samengesteld kan zijn (bv.: een document met meerdere hoofdstukken en paragrafen) en elk subelement zijn eigen metadata kan hebben, geeft de STANAG-norm 4778 na te leven regels om de metadata van een samengesteld object goed te interpreteren.

De norm definieert tot slot de syntaxis en de semantiek van het verbindingsmechanisme tussen metadata en data-objecten. Verbindingsprofielen beschrijven hoe het verbindingsmechanisme van de metadata toegepast moet worden op gegevensformaten en specifieke protocollen (bv.: Microsoft Word-documenten, JPEG-afbeeldingen), maar de norm laat niet toe datastromen zoals video’s en audiostreams te verwerken.

Merk tot slot op dat de verbinding bepaald door de norm niet sterk is en dat er een digitale handtekening toegevoegd moet worden die de data-objecten en metadata dekt, bijvoorbeeld door de W3C-aanbeveling “XML Signature Syntax and Processing te gebruiken”.

Conclusies

De toepassing van vertrouwelijkheidslabels zoals die bepaald worden in de STANAG-normen 4474 en 4778 is een belangrijk element bij de invoering van een datagecentraliseerde veiligheidsstrategie. Het gebruik van deze labels in een attribuut-gebaseerd toegangscontrolesysteem (bv.: die XACML-policy’s gebruiken) biedt een dynamische en contextuele toegangscontrole waardoor organisaties een uiterst flexibele en efficiënte naleving van de reglementering kunnen bekomen.

Er bestaan veel overwegingen wat betreft de invoering van dergelijke systemen en in het bijzonder de evaluatie van de gevoeligheid van de gegevens waar de labeling van afhangt. Daar komen we op terug in een volgend artikel.

Bibliografische referenties

[1]        Confidentiality metadata label syntax, NATO standard ADat-4774, Edition A Version 1, NATO Standardisation Office (NSO), 20 december 2017.

[2]        Metadata binding mechanism, NATO standard ADatP-4778, Edition A Version 1, NATO Standardisation Office (NSO), 26 oktober 2018.

Noten

¹   Een model ontwikkeld in de jaren 70 om het meerlagig veiligheidsbeleid te formaliseren van de defensieafdeling van de Verenigde Staten. Het model wordt gekenmerkt door het aforisme “naar boven schrijven, naar beneden lezen” (het omgekeerde is verboden).

²   De kenmerken zijn paren van het type (sleutel, waarde) die gelinkt kunnen worden aan eender welke entiteit: data-object, gebruiker, omgeving, enz.

Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.