La politique de cryptographie en tant que code ou Crypto Policy as Code (CPaC) est un principe très récent qui permet de respecter automatiquement les recommandations en matière de cryptographie. Cet article vise à concrétiser nos idées concernant la CPaC. Une représentation des politiques cryptographiques en JSON est proposée et utilisée à titre de base pour quelques expériences. L’objectif est de rendre le potentiel de la CPaC plus tangible et plus compréhensible, et ainsi d’inspirer certains lecteurs.

« Everything as Code »

L’approche Everything as Code (tout en tant que code) vise à exprimer tous les composants d’un système informatique (infrastructure, réseau, sécurité, pipelines de déploiement…) sous forme de code. Elle autorise un haut degré d’automatisation des processus et de la gestion. Elle nous offre un meilleur aperçu et nous permet de mieux anticiper et d’intervenir en cas de besoin. Il en résulte également une cohérence et une évolutivité accrues grâce à une moindre intervention humaine. Il nous semble non seulement utile, mais aussi nécessaire à terme d’adopter cette approche dans le cadre de la gouvernance cryptographique. 

Lorsque Smals Research a débuté l’étude du CPaC début 2025, il n’existait pratiquement aucune information à ce sujet. Depuis, le CPaC semble également avoir attiré l’attention de plusieurs entreprises, notamment Garantir.

Un premier aspect de la CPaC est l’expression des actifs cryptographiques (algorithmes, clés, certificats, hardware, bibliothèques…) sous forme de code. Cela permet de gérer et d’interroger automatiquement l’inventaire des actifs cryptographiques d’une organisation. Un tel inventaire est systématiquement recommandé dans le contexte de l’état de préparation quantique et de l’agilité cryptographique.

Le modèle CBOM (Cryptography Bill of Materials ou nomenclature de cryptographie) permet d’exprimer les actifs cryptographiques d’une organisation en code JSON. Bien qu’il soit encore très récent, nous pensons qu’il sera largement adopté dans les années futures. Nous prévoyons qu’à l’avenir, les services cloud, les bibliothèques, les systèmes d’exploitation et le hardware, entre autres, seront fournis avec une description de la cryptographie appliquée et supportée, exprimée selon le modèle CBOM. Une organisation pourra ensuite importer ces descriptions dans son inventaire cryptographique.

Eu égard à cette perspective, nous intégrons autant que possible nos propositions de CPaC dans le modèle CBOM. L’illustration ci-dessous est le résultat d’une analyse statique du code et montre dans le code CBOM que RSA-2048 est utilisé à trois endroits dans une application.  

« Crypto Policy as Code »

Smals dispose d’une politique cryptographique qui indique quels algorithmes et paramètres cryptographiques sont recommandés, lesquels sont sûrs bien que non recommandés, lesquels doivent être progressivement supprimés et lesquels ne sont pas sûrs. Actuellement, ces recommandations sont exprimées de manière classique, que seuls les humains peuvent facilement comprendre. Nous nous sommes demandé comment exprimer ces recommandations sous forme de code.

Penchons-nous sur AES-128-GCM. AES est le chiffre de bloc ; il chiffre ou déchiffre des blocs de 128 bits. Le nombre 128 dans AES-128-GCM fait référence à la longueur en bits de la clé utilisée. Grâce au mode GCM, il est également possible de chiffrer et déchiffrer de plus grandes quantités de données.

Dans la partie gauche de l’illustration ci-dessous, la description de l’AES-128-GCM est présentée selon le modèle CBOM. On y trouve notamment des informations sur le niveau de sécurité classique et le niveau de sécurité quantique. Dans la partie droite de l’illustration se trouve notre proposition de formulation des recommandations sous forme de code. Nous maximisons ainsi la compatibilité avec CBOM ; la structure, la nomenclature et les clés d’identification sont conservées. Dans le même temps, nous évitons la duplication des données que nous trouvons déjà dans la description CBOM.

Les recommandations se trouvent dans le bloc recommendation. Il contient au minimum le niveau de recommandation recommended, secure, phase-out ou insecure. En outre, ce bloc peut contenir des informations supplémentaires facultatives, telles que :

• la date à laquelle le mécanisme cryptographique doit disparaître progressivement ;
• la date de la dernière révision de la recommandation ;
• les conditions d’utilisation correcte du mécanisme cryptographique ;
• les remarques, par exemple sur les raisons pour lesquelles le mécanisme cryptographique n’est plus considéré comme sûr.

À titre expérimental, l’équipe Smals Research a déjà exprimé certaines recommandations cryptographiques sous forme de code, notamment les fonctions de hachage cryptographiques, le chiffrement symétrique, les message authentication codes (MAC), les key derivation functions (KDF) et TLS. Ces recommandations cryptographiques sont relativement simples et compatibles avec CBOM. De plus, un schéma JSON a été défini afin de valider l’exactitude de la syntaxe et de la structure de nos recommandations.

Dérogations sous forme de code

Idéalement, chaque partie qui sollicite nos services, notamment les hôpitaux, les pharmaciens et les CPAS, doit mettre à jour son logiciel en temps utile afin qu’il prenne en charge la cryptographie la plus récente et la plus sûre. Dans la pratique cependant, cette opération n’est pas toujours exécutée aussi rapidement et une dérogation à la politique cryptographique doit être autorisée exceptionnellement afin de ne pas compromettre les services essentiels aux citoyens.

L’illustration ci-dessous montre un exemple fictif d’une telle dérogation (deviation), où la structure proposée par Smals Research est suivie. Elle se compose de quatre blocs :

• Scope. La dérogation peut s’appliquer à un service entier ou à certains modules spécifiques de celui-ci.
• Approval. Nous trouvons ici la référence à l’approbation par le management, ainsi que la justification et la durée de la dérogation. 
• Assessment. Il s’agit de l’évaluation du risque. Une dérogation ne peut être approuvée qu’après une estimation préalable du risque, telle que décrite dans cette section.
• Allow. Cette section énumère les algorithmes ou suites cryptographiques autorisés. La structure de ce bloc provient directement du modèle CBOM.

Scripts expérimentaux

L’équipe Smals Research a rédigé plusieurs scripts afin d’illustrer la puissance de la CPaC. Les recommandations sous forme de code, les dérogations sous forme de code et/ou les descriptions CBOM constituent l’input.

Script 1 : configuration TLS

TLS (Transport Layer Security) est un protocole populaire de communication sécurisée entre deux parties. Avant d’échanger des données, les parties conviennent de la suite cryptographique (combinaison d’algorithmes) qu’elles utiliseront à cette fin. OpenSSL est un client TLS populaire.

Notre premier script génère la configuration OpenSSL relative à la cryptographie sur la base de la politique en tant que code et, le cas échéant, d’une déviation en tant que code. Le code produit, dont vous trouverez un exemple ci-dessous, peut ensuite être intégré dans openssl.cnf, qui est le fichier de configuration openSSL. La dernière ligne de notre exemple contient la liste des suites cryptographiques ; la dernière provient d’une dérogation, les autres sont sécurisées selon la politique cryptographique. L’ordre est important ici ; la dérogation a la priorité la plus faible.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

À terme, cela pourrait servir de base pour maintenir à jour de manière coordonnée la configuration cryptographique pour le TLS de milliers de machines. Bien évidemment, cela nécessite la mise en place des procédures pour éviter les erreurs.

Nous proposons que la politique et les déviations en tant que code soient gérées par un service central. La politique peut être accessible à l’ensemble de l’organisation, tandis que les déviations doivent être protégées par un contrôle d’accès strict.

Script 2 : génération d’un PDF

Pour la plupart des gens, un PDF bien structuré reste plus lisible qu’un fichier JSON. À partir de fichiers JSON, il n’est pas sorcier de générer de tels documents. C’est ce que réalisent nos deux scripts suivants.

Un PDF généré à titre expérimental contenant des recommandations de chiffrement symétrique peut être téléchargé ici. Il est parti du principe policy as code, mais il est fait également appel à CBOM pour enrichir le PDF ; les niveaux de sécurité classique et quantique en sont extraits.

Un deuxième fichier PDF généré à titre expérimental peut être téléchargé ici. Il contient des recommandations pour les suites cryptographiques TLS, complétées par des informations supplémentaires issues de la politique de cryptographie en tant que code. Un exemple de ce type d’informations est la date limite à laquelle une suite cryptographique peut être utilisée. Si un tel document était partagé avec les partenaires, cela leur permettrait d’anticiper en temps utile.

Script 3 : OPA policy verification

CPaC est un concept puissant. Les scripts précédents nous permettaient de générer des fichiers PDF et des configurations TLS. CPaC nous permet également de valider les artefacts existants, en vérifiant si un chiffrement sûr est utilisé.

OPA signifie Open Policy Agent. Il s’agit d’un moteur de politiques open source qui permet de séparer la logique applicative et les politiques. OPA permet aux organisations de centraliser leurs politiques et de les appliquer en temps réel. Différents services (Kubernetes, pipelines CI/CD, API gateways…) envoient des requêtes (queries) au format JSON au moteur de politiques afin de savoir si une action demandée par un client est autorisée. Sur la base d’une politique exprimée dans le langage Rego, le moteur de politiques indique au service si la requête doit recevoir une réponse positive ou négative. Par exemple, le moteur de politiques peut recevoir la requête d’une application demandant si une personne âgée de 15 ans est autorisée à utiliser l’application, alors que la politique stipule que l’âge minimum est de 18 ans. Le moteur de règles peut également être interrogé pour déterminer si une configuration réseau est conforme à la politique OPA. Par exemple, il peut exiger que les ports Telnet ne soient jamais ouverts.

Les services peuvent également poser des questions au moteur OPA concernant la cryptographie : la valeur donnée est-elle la valeur de hachage correcte (également appelée fingerprint ou digest) d’une charge utile donnée ? Une valeur est-elle le MAC correct pour une donnée d’entrée et une clé donnés ? Un certificat est-il signé par une autorité de confiance ? Un certificat utilise-t-il une courbe elliptique sécurisée ? …

Vous trouverez ci-dessous un exemple d’une telle requête et la politique correspondante. La politique stipule que la valeur de hachage de la charge utile est calculée à l’aide de la fonction de hachage (non sécurisée) MD5.

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Une organisation souhaitant mettre en place CPaC devra vérifier que ses politiques OPA existantes sont conformes à la dernière version de la politique cryptographique. Notre script final vérifie donc si la cryptographie utilisée dans la politique OPA est conforme à notre politique cryptographique centrale. En entrée est la crypto policy as code et une politique OPA. En sortie on obtient soit un message indiquant que la politique OPA est conforme, soit, comme dans le cas ci-dessus, un avertissement précisant également quel algorithme non sécurisé a été utilisé. À long terme, nous souhaitons également pouvoir déduire directement de notre CPaC les politiques OPA relatives à la cryptographie.

Conclusions

Cet article met en lumière le potentiel d’une approche everything as code pour stimuler la maturité cryptographique d’une organisation. À l’aide d’un certain nombre de scripts relativement simples, nous montrons comment une politique cryptographique centralisée, exprimée sous forme de code, peut soutenir une organisation dans divers domaines, de l’automatisation des processus à la création de documentation, en passant par la vérification de l’utilisation de la cryptographie appropriée, par exemple dans les politiques OPA.

À terme, nous souhaitons permettre l’accès aux informations sous forme de code via des API REST. Ainsi, les informations les plus récentes seront affichées clairement sur des tableaux de bord interactifs pour les utilisateurs autorisés. Les systèmes et applications pourront également accéder aux informations en temps réel via cette API REST. Idéalement, nous travaillerons avec une politique et un inventaire unifiés sous forme de code, la cryptographie n’étant qu’un aspect de ce système.

Dans un monde idéal, une politique de cryptographie en tant que code  pourrait être proposée par une organisation nationale ou européenne faisant autorité et pourrait être utilisée tant par le secteur public que par le secteur privé. Pour l’instant, cela reste une utopie. Au cours des prochaines années, nous pouvons nous attendre à une forte évolution dans ce domaine.

N’hésitez pas à nous contacter si vous souhaitez échanger vos idées avec nous à ce sujet !

Crypto Policy as Code (CPaC) is een erg jong principe dat ons in staat stelt aanbevelingen met betrekking tot cryptografie op een automatische wijze na te leven. Dit artikel maakt onze ideeën rond CPaC meer concreet. Een representatie van cryptografische policies in JSON wordt voorgesteld en gebruikt als basis voor enkele experimenten. Het doel is om het potentieel van CPaC tastbaarder en inzichtelijker te maken, en zo enkele lezers te inspireren.

Everything as Code

Everything as Code wil alle componenten in een IT systeem (infrastructuur, netwerk, veiligheid, deployment pipelines, …) uitdrukken als code. Het laat een hoge graad van automatisering toe van processen en beheer. Het geeft ons meer inzicht en laat ons toe beter te anticiperen en in te grijpen indien nodig. Bovendien resulteert het in een verhoogde consistentie en schaalbaarheid dankzij de verminderde menselijke interventie. Het lijkt ons niet enkel nuttig maar op termijn ook noodzakelijk om dit principe te omarmen in het kader van cryptographic governance. 

Het concept crypto policy as code is vrij nieuw. Toen Smals Research begin 2025 de studie startte was hier vrijwel niets over te vinden. Ondertussen blijkt het ook op de radar te staan van onder meer het bedrijf Garantir.

Een eerste aspect richting CPaC is het uitdrukken van de cryptografische assets (algoritmes, sleutels, certificaten, hardware, libraries, …) als code. Dit laat toe om om de inventaris met de cryptografische assets van een organisatie geautomatiseerd te beheren en te bevragen. Een dergelijke inventaris wordt systematisch aangeraden in de context van quantum readiness en crypto agility.

CBOM (Cryptograhy Bill of Materials) is een model om de cryptografische assets in een organisatie uit te drukken in JSON code. CBOM is vandaag nog erg nieuw, maar zal volgens onze inschatting in de komende jaren een brede adoptie kennen. We verwachten dat onder meer cloud diensten, libraries, besturingssystemen en hardware in de toekomst geleverd zullen worden samen met een beschrijving van de gebruikte en ondersteunde cryptografie, uitgedrukt volgens het CBOM model. Die beschrijvingen kan een organisatie vervolgens in zijn crypto inventaris importeren.

Omwille van deze verwachting enten we onze CPaC voorstellen zoveel als mogelijk op CBOM. Onderstaande figuur is het resultaat van een statische scan van code en toont in CBOM code dat RSA-2048 op drie locaties in een toepassing gebruikt wordt. 

Crypto Policy as Code

Smals beschikt over een cryptografische policy, die aangeeft welke cryptografische algoritmes en parameters aanbevolen zijn, welke veilig zijn, hoewel niet aanbevolen, welke uitgefaseerd dienen te worden en welke onveilig zijn. Momenteel wordt dit nog uitgedrukt op een klassieke manier die enkel door mensen vlot te interpreteren is. We stelden ons de vraag hoe dit als code uitgedrukt zou kunnen worden.

Laat ons even kijken naar AES-128-GCM. AES is het blokcijfer; het encrypteert of decrypteert blokken van 128 bits. Het getal 128 in AES-128-GCM verwijst naar de bitlengte van de sleutel die daarbij gebruikt wordt. Dankzij de modus GCM kunnen ook grotere hoeveelheden data geëncrypteerd en gedecrypteerd worden.

Links op onderstaande figuur wordt de beschrijving van AES-128-GCM getoond volgens het CBOM model. We vinden er informatie over onder meer het klassieke en kwantum veiligheidsniveau. Ons daarop entend, toont de figuur rechts ons voorstel om de aanbevelingen te formuleren als code. We maximaliseren daarbij de compatibiliteit met CBOM; de structuur, naamgeving en identificatielsleutels worden behouden. Tegelijkertijd vermijden we duplicatie van data die we reeds in de CBOM beschrijving vinden.

De aanbevelingen zitten vervat in het recommendation blok. Het bevat minimum het aanbevelingsniveau: recommended, secure, phase-out of insecure. Daarnaast kan dit blok extra, optionele, informatie bevatten, zoals:

• de uiterste datum waarop het cryptografische mechanisme uitgefaseerd dient te worden,
• de datum dat de aanbeveling laatst gereviseerd werd,
• voorwaarden voor correct gebruikt van het cryptografische mechanisme
• opmerkingen, vb. waarom het cryptografisch mechanisme niet langer als veilig beschouwd wordt.

Bij wijze van experiment heeft Smals Research reeds enkele cryptografische aanbevelingen uitgedrukt als code; met name cryptografische hashfuncties, symmetrische vercijfering, message authentication codes (MACs), key derivation functions (KDFs) en TLS. Deze cryptografische aanbevelingen zijn relatief eenvoudig en compatibel met CBOM. Bovendien werd een JSON schema gedefineerd om de correctheid van de syntax en structuur van onze aanbevelingen te valideren. 

Afwijkingen als code

Idealiter doet elke partij die op onze diensten beroep doet, waaronder ziekenhuizen, apothekers en OCMW’s, tijdig de update van hun software zodat die de meest recente en veiligste cryptografie ondersteunen. In de praktijk gebeurt dit niet steeds even snel en moet uitzonderlijk een afwijking van de crypto policy toegestaan worden, zodat de cruciale dienstverlening aan de burgers niet in het gedrang komt.

De onderstaande figuur toont een fictief voorbeeld van een dergelijke afwijking (deviation), waarbij de door Smals Research voorgestelde structuur gevolgd wordt. Het bestaat uit vier blokken:

• Scope. De afwijking kan van toepassing zijn op een volledige dienst, of op specifieke modules ervan.
• Approval. Hier vinden we de referentie naar de goedkeuring door het management, alsook de rechtvaardiging en het tijdsvenster van de afwijking. 
• Assessment. Dit is de beoordeling van het risico. Een afwijking kan enkel goedgekeurd worden mits een voorafgaande inschatting van het risico, wat beschreven wordt in deze sectie.
• Allow. Deze sectie geeft een opsomming van de toegestane algoritmes of cipher suites. De structuur van dit blok komt rechtstreeks uit het CBOM model.

Experimentele scripts

Smals Research schreef een aantal scripts om de kracht van CPaC te illusteren. De aanbevelingen als code, afwijkingen als code en/of CBOM beschrijvingen vormen daarbij de invoer.

Script 1: TLS configuratie

TLS (Transport Layer Security) is een een populair protocol voor veilige communicatie tussen twee partijen. Alvorens data met elkaar uit te wisselen, spreken de partijen samen af welke cipher suite (combinatie van algoritmes) ze daarbij zullen gebruiken. OpenSSL is een populaire TLS client.

Ons eerste script genereert op basis van de crypto policy as code en eventueel een deviation as code de OpenSSL configuratie m.b.t. cryptografie. De uitvoer, waarvan een voorbeeld hieronder, kan vervolgens geïntegreerd worden in openssl.cnf, wat het openSSL configuratiebestand is. De laatste lijn in ons voorbeeld bevat de lijst met cipher suites; de laatste komt uit een afwijking, de anderen zijn veilig volgens de crypto policy. De volgorde is hier van belang; de afwijking krijgt de laagste prioriteit.

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.3
CipherString = # Sets the ciphersuite list for TLSv1.2 and below to value. This list will be combined with any configured TLSv1.3 ciphersuites.
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_8_SHA256

Dit kan op termijn de basis vormen om op een gecoördineerde wijze de crypto configuratie voor TLS van duizenden machines geactualiseerd te houden. Uiteraard vereist dit de nodige procedures om fouten tegen te gaan.

Ons voorstel is om zowel de policy as code als de deviations as code door een centrale service te laten beheren. Daarbij kan de policy as code toegankelijk zijn binnen de gehele organisatie, terwijl de deviations as code beschermd dienen te worden door strikte toegangscontrole.

Script 2: PDF generatie

Voor de meeste mensen is een goed gestructureerde PDF nog steeds leesbaarder dan JSON. Vertrekkende van JSON bestanden is het geen heksenkunst om dergelijke documenten te genereren. Dit is wat onze volgende twee scripts realiseren.

Een experimenteel gegenereerde PDF met aanbevelingen voor symmetrische vercijfering is hier te downloaden. Er wordt vertrokken van policy as code, maar er wordt eveneens beroep gedaan op CBOM om de PDF verder te verrijken; zowel het klassieke als kwantumveiligheidsniveau zijn daaruit geëxtraheerd.

Een tweede experimenteel gegenereerde PDF bestand is hier te downloaden. Het bevat aanbevelingen voor TLS cipher suites, aangevuld met bijkomende informatie uit de crypto policy as code. Een voorbeeld van dergelijke informatie is de uiterlijke datum tot wanneer een cipher suite gebruikt mag worden. Indien een dergelijk document met partners gedeeld werd, zou dit hen toelaten tijdig te anticiperen.

Script 3. OPA policy verification

CPaC is een krachtig concept. Voorgaande scripts lieten ons toe om PDF bestanden en TLS configuraties te genereren. CPaC laat ook toe om bestaande artefacten te valideren; om na te gaan of veilige cryptografie gebruikt wordt.   

OPA staat voor Open Policy Agent. Het is een open source policy engine, wat toelaat een scheiding te maken tussen applicatie logica en policy. OPA stelt organisaties in staat policies te centraliseren en in real time af te dwingen. Verschillende services (Kubernetes, CI/CD pipelines, API gateways, …), sturen vragen (queries) in JSON formaat naar de policy engine om te weten of, bijvoorbeeld, een door een client gevraagde actie toegelaten is. Op basis van een policy, uitgedrukt in de taal Rego, laat de policy engine aan de service weten of de vraag positief of negatief beantwoord dient te worden. Zo kan de policy engine de vraag krijgen van een toepassing of iemand van 15 jaar de toepassing mag gebruiken, terwijl de policy bepaalt dat de minumleeftijd 18 jaar is. Of er kan gevraagd worden aan de policy engine of een netwerkconfiguratie in overeenstemming is met de OPA policy. Deze kan bijvoorbeeld eisen dat Telnet poorten nooit open mogen staan.

Services kunnen de OPA engine ook vragen stellen m.b.t. cryptografie: is de gegeven waarde de correcte hashwaarde (ook wel fingerprint of digest) van een gegeven payload? Is een waarde de correcte message authentication code (MAC) voor een gegeven input en sleutel? Is een certificaat ondertekend door een vertrouwde autoriteit? Gebruikt een certificaat een veilige elliptische kromme? …

In ons voorbeeld wordt een JSON bestand bestaande uit een payload en een verwachte hashwaarde (expected_digest) naar de policy engine gestuurd. De OPA policy bepaalt dat de policy engine de hash van de payload opnieuw berekent en dat het resultaat moet overeenkomen met de ontvangen verwachte hashwaarde. De vierde lijn van de OPA policy hieronder bepaalt dat de hashfunctie die daarbij gebruikt dient te worden het (onveilige) MD5 is.  

Input by service to policy engine
{
  "payload": {
    "user": "alice",
    "action": "read",
    "resource": "/api/users"
  },
  "expected_digest": "ea99819f665c10c744cbbf8da651c37a"
}

OPA Policy (in Rego) applied by the policy engine 
package crypto_digest_verification
payload_json := json.marshal(input.payload)
computed_digest := crypto.md5(payload_json)
digest_valid := computed_digest == input.expected_digest

Een organisatie die CPaC wil introduceren zal moeten nagaan of de bestaande OPA policies compliant zijn met de meest recente versie van de cryptografische policy. Ons laatste script gaat daarom na of de cryptografie die in de OPA policy gebruikt wordt, in overeenstemming is met onze centrale crypto policy (CPaC). De invoer is de crypto policy as code (CPaC) en een OPA policy. De output is ofwel een bericht dat de OPA policy compliant is, ofwel – zoals in bovenstaand geval – een waarschuwing, die ook aangeeft welk onveilig algoritme gebruikt werd. Op termijn willen we ook OPA policies m.b.t. cryptografie direct kunnen afleiden uit onze CPaC.  

Conclusies

Dit artikel werpt een licht op het potentieel van een everything as code benadering om de cryptografische maturiteit van een organisatie een boost te geven. Met behulp van een aantal relatief eenvoudige scripts tonen we aan hoe een centraal beheerde crypto policy, uitgedrukt als code, een organisatie op diverse vlakken kan ondersteunen, gaande van het automatiseren van processen, het creëren van documentatie en het nagaan of de correcte cryptografie gebruikt wordt, zoals in OPA policies.

Op termijn evolueren we hopelijk naar een ontsluiting van de as code informatie via REST API’s. Op basis daarvan wordt de meest actule informatie overzichtelijk in interactieve dashboards aan geautoriseerde gebruikers getoond. Ook systemen en toepassingen kunnen in real-time informatie bekomen via deze REST API. Idealiter wordt gewerkt met een eengemaakte policy as code en een eengemaakte inventaris as code, waarin cryptografie slechts één van de aspecten is. 

In een ideale wereld wordt de crypto policy as code aangeboden door een nationale of Europese gezaghebbende organisatie en kunnen zowel de publieke als private sector hier gebruik van maken. Dit is voorlopig nog toekomstmuziek. In de komende jaren mogen we ons wellicht aan een sterke evolutie verwachten in dit domein.

Aarzel niet ons te contacteren indien u hierover met ons van gedachten wilt wisselen!

Automatisering is een belangrijk wapen om het Mattheus-effect tegen te gaan. Het automatisch toekennen van bepaalde voordelen aan de hand van objectieve criteria zorgt idealiter voor een gelijke behandeling van alle burgers ongeacht stand en rang. Daarnaast zorgt automatisering ook voor tijdswinst, minder papier, en lagere kosten op lange termijn. Veel projecten waar Smals bij betrokken is, dragen daar aanzienlijk toe bij: ze besparen de overheid, burgers en bedrijven jaarlijks miljarden euro’s, om niet te zeggen tonnen papier, inkt en postzegels.

We schreven al uitvoerig over de talloze randvoorwaarden die opduiken als men Artificiële Intelligentie correct wil inzetten ([1], [2], [3], [4], [5], [6]), maar ook een gewone procesautomatisering, zelfs digitalisering, is niet zomaar vrijblijvend, en al zeker niet bij overheden. Automatisering is niet gelijk aan artificiële intelligentie, maar men geeft nog steeds een deel van de controle uit handen aan een machine. Naast winsten in snelheid en kostprijs, kan dat ook allerlei beperkingen introduceren. Door de schaalvergroting loopt het, als het fout loopt, ook ineens heel erg fout. Reden genoeg om reeds vanaf de planningsfase nauwgezet aandacht te besteden aan de bredere effecten van een automatiseringsproject.

Wil een geautomatiseerd proces goed werken, dan is het belangrijk dat het actief en “als een goede huisvader” wordt beheerd. Permanente monitoring is nodig zodat problemen snel gedetecteerd en opgelost kunnen worden. Manueel ingrijpen moet mogelijk blijven, het moet duidelijk zijn wie waarvoor verantwoordelijk is, en alles moet mee evolueren wanneer nodig. In het Engels wordt dat al eens aangeduid met (corporate) “governance“, vrij vertaald “deugdelijk bestuur”. Het is een vaag begrip, maar in dit artikel hoop ik het belang ervan te kunnen illustreren aan de hand van enkele spraakmakende voorbeelden uit het buitenland.

(afbeelding: “corporate governance”, (c) Asmi-corporatereporting.com, 2017, Licensed CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

Wat kan er zoal misgaan?

Frankrijk

De Franse Caisse des Allocations Familiale (CAF) nam in 2021 een nieuw systeem in gebruik voor de berekening van huisvestingstoelagen. Helaas was het systeem niet volledig compatibel met een ander systeem voor de registratie van sommige arbeidsprestaties, nodig om de hoogte van die uitkering te bepalen. Als gevolg kregen minstens 120.000 mensen een foutieve schuldvordering in de bus, automatisch aangemaakt, voor zogezegd teveel ontvangen uitkeringen. De toevloed aan reacties, en alle correcties die vaak manueel aangebracht moesten worden, zorgden voor veel extra werklast bij de dienst die al met veel vertragingen te kampen had, wat op zijn beurt aanleiding gaf tot stakingen. Negen maanden later wachtten nog steeds 32.000 mensen op de correctie van hun dossier.

Verenigd Koninkrijk

Het Verenigd Koninkrijk heeft geen rijksregister zoals België. Mensen moeten hun identiteit op een andere manier bewijzen: met een rijbewijs, bankrekening, telefooncontract of een internationaal paspoort. Dat zorgt al voor een eerste probleem, omdat net de meest kwetsbaren die het meeste belang hebben bij die diensten, door hun kleinere administratieve/digitale voetafdruk niet geauthenticeerd geraken. Daarnaast is identiteitsfraude een groot probleem.

Universal Credit is een geautomatiseerd sociaal vangnet voor de laagste inkomens, dat bestaat uit de fusie van 6 aparte uitkeringen. Hun doel om de zaken te vereenvoudigen hebben ze echter ook doorgetrokken in de berekeningswijze: die neemt enkel het inkomen van een vorige maand in rekening. Dat zorgt voor grote problemen bij mensen die onregelmatig betaald krijgen, of wanneer loon plots vervroegd uitbetaald wordt omwille van feestdagen: zij hebben in sommige maanden plots een hoger inkomen, in andere maanden geen, en krijgen daardoor heel erg fluctuerende uitkeringen. Het perverse effect daarvan is dat twee mensen met dezelfde job, gezinssamenstelling en jaarinkomen, toch verschillende uitkeringen kunnen krijgen, enkel en alleen omdat hun salaris op een ander moment wordt uitbetaald.

Een rechtszaak daarover werd door de Britse overheid verloren. Het maken van de opgedragen aanpassingen zal de kost van het geplaagde systeem, nu reeds lopend in de miljarden pond, alleen nog maar verder doen toenemen. Let wel dat het probleem hier niet zozeer bij de automatisering ligt, wel bij het ontwerp: de regering had expliciet besloten tot deze berekeningswijze, omdat ze gemakkelijker en efficiënter te implementeren was.

(afbeelding: Wordmark for Universal Credit, (c) UK Government, licensed under the Open Government Licence version 1.0 (OGL v1.0).

Australië

In Australië deed de RoboDebt affaire veel stof opwaaien. Frauduleus betaalde uitkeringen terugvorderen deden ze al langer, maar in 2015 maakten ze een cruciale verandering: het verifiëren van een “match” tussen de databanken sociale zekerheid (DHS) en financiën (ATO), werd geautomatiseerd. Dat nam effectief een stap van menselijke controle in de ketting weg. Het hoofddoel was om elke “match” op te volgen, daar waar ze vroeger slechts de meest flagrante inbreuken konden najagen omwille van het manuele werk. Dat leidde in het eerste jaar al tot een 40 keer hoger volume.

Helaas was niet elke “match” ook terecht. De uitkeringen werden immers in perioden van 14 dagen toegekend, terwijl de belastingdienst gegevens had per fiscaal jaar. Bij gebrek aan inkomstengegevens per 14 dagen werd een gemiddelde van het jaarinkomen toegepast, maar net zoals in het voorbeeld van UK, leidde dat tot ongewenste neveneffecten, en moesten burgers plots schulden gaan terugbetalen die ze nooit gemaakt hadden. In 2019 werd het systeem door de rechtbank onwettelijk verklaard, en in 2021 moest de overheid een schikking ter waarde van $1.8 miljard Australische dollar treffen met de bijna 500.000 gedupeerden. Ook hier lag de fout bij de wetgever, die niet voldoende had nagedacht over de aannames en mogelijke neveneffecten bij het opstellen van de berekeningswijze van het systeem.

USA

In de Verenigde Staten doken problemen op bij de automatisering van RAI. Dit Resident Assessment Instrument is een lange vragenlijst voor zwaar zorgbehoevenden. Aan de hand van het resultaat wordt o.a. berekend op hoeveel thuiszorg iemand een beroep mag doen. Ook in België wordt een variant ervan gebruikt die BelRAI heet. Het automatiseren daarvan moet heel omzichtig gebeuren. Als bijvoorbeeld de vraag of iemand voetproblemen heeft beantwoord wordt met “nee”, kan dat zijn omdat die gezond is, maar even goed omdat die geamputeerde voeten heeft – en die laatste behoeft uiteraard meer zorg.

In Arkansas liep het fout bij onderaannemers die een verkeerde versie van de vragenlijst hadden gebruikt, en daarnaast bepaalde ziektebeelden, zoals hersenverlamming, niet correct hadden verwerkt. Pas tijdens de rechtszaak werd duidelijk waar de fouten precies lagen, o.a. doordat de rechter verplichtte om de resultaten eens manueel na te rekenen. Het systeem bleek dermate complex, en de code werd zodanig afgeschermd, dat ook de bevoegde ambtenaren niet in staat waren geweest om de fout te ontdekken. Zo was het voor eindgebruikers nooit duidelijk waarom de evaluatie tot een bepaald resultaat leidde, wat het op zijn beurt erg moeilijk maakte een evaluatie aan te vechten of te overreden. Het gebruik van RAI op zich werd door de rechtbank wel als wettig beschouwd.

India

India heeft hetzelfde probleem als het Verenigd Koninkrijk, nl. dat het lange tijd geen eengemaakt burgerregister had en dat andere systemen (rijbewijzen, stembiljetten, geboorteaktes) onderling incompatibel zijn. Het bijhouden van gegevens op kaartjes en papieren is er ook geen sinecure voor de armeren en ongeletterden onder hun bevolking. In een ambitieus programma om iedere Indiër een sociaal identiteitsnummer te geven (zoals onze vroegere SIS-kaart), startte India het Aadhaar project, dat ook biometrische authenticatie op basis van de vingerafdruk omvat.

(afbeelding: “A sample of Aadhaar card”, by Pagelmp, licensed under the Creative Commons Attribution-Share Alike 4.0 International license. Source Wikimedia Commons.)

De praktijk blijkt echter weerbarstiger. Er zijn technologische vereisten om het te kunnen toepassen: een vingerafdruklezer en een stabiele internetverbinding. Bovendien zijn de vingerafdrukken niet altijd meer herkenbaar bij wie een leven lang handenarbeid heeft verricht. Ook fouten bij de manuele data-entry, wat tijd en geld kost om te laten corrigeren, zorgen voor problemen. Er duiken dan ook veel rapporten op van grote aantallen kwetsbaren die de toegang tot sociale diensten, onderwijs, vergunningen, kindergeld of voedselrantsoenen wordt ontzegd omdat ze door de mazen van het Aadhaar-systeem vallen.

Nederland

In Nederland viel de regering over de toeslagenaffaire. Vele duizenden gezinnen kwamen in grote problemen door onterechte beschuldigingen van subsidiefraude. De affaire is complex, maar aan de basis ligt de opsporingsdienst voor belastingfraude die zich danig heeft vergaloppeerd. Het probleem lag hier o.a. bij een gebrekkige training en validatie van een machine-learning model, dat een risicoclassificatie moest geven aan dossiers en daarbij zonder veel nadenken steunde op parameters zoals nationaliteit, die erg gevoelig zijn voor discriminatie. Daarnaast was de inhoud van verschillende onderliggende databanken, o.a. de Fraude Signalerings Voorziening, onoordeelkundig verzameld: een telefoontje naar de belastingdienst kon voldoende zijn om erin opgenomen te zijn als potentieel fraudeur. De opsporingsdienst vertrouwde echter quasi blindelings op de gegevens en risicoscores, en gebruikte ze als rechtvaardiging om drastisch te werk te gaan bij terugvorderingen, weigeringen van afbetalingsplannen, enz. Daarbij ontbrak het aan een richtinggevend kader van bovenaf, interne monitoring of audit, en mogelijkheden tot aantekenen van beroep. De databank werd op basis van inbreuken op de privacywetgeving stopgezet en de belastingdienst kreeg een stevige boete.

Conclusie

De bovenstaande verhalen hebben meestal 1 ding gemeen: alles gaat goed totdat op een bepaald moment ergens een bocht teveel wordt afgesneden zonder dat er tijdig wordt ingegrepen. Dat moet ons niet tegenhouden om te automatiseren, want er zijn ook duidelijke voordelen: voor de overheid qua schaalbaarheid, voor de burger o.a. door vermindering van administratie. Met dit artikel willen we vooral aandacht vestigen op de noodzaak om daarbij voldoende te investeren in planning en opvolging, om een goede grip te houden. Dat omvat ook een realistische blik, aandacht voor user experience en duidelijke adoptie van waarden en principes (transparantie, accountability, …).

Het grote verschil tussen een ambtenaar in persoon en een geautomatiseerd systeem, is dat een ambtenaar aanpassingen kan maken en verfijningen kan toebrengen nog voordat een beslissing genomen wordt, terwijl een algoritme enkel maar gecorrigeerd kan worden nadat het al een beslissing heeft gemaakt. Dat laatste veroorzaakt frustratie en een nood aan ingrijpen achteraf. Er is een risico dat bepaalde doelgroepen onevenredig het slachtoffer zijn van zulke fouten. Ook kan bij de gebruikers van geautomatiseerde systemen, een zekere verblinding, laksheid, of neiging tot het afschuiven van verantwoordelijkheid ontstaan: “de computer zegt het dus het zal wel zo zijn”. Er moeten dus toegankelijke procedures zijn om beroep aan te tekenen tegen een beslissing en correcties moeten eenvoudig doorgevoerd kunnen worden.

Daarnaast blijft het altijd mogelijk dat programmeurs de regels onvolledig of foutief inbrengen in een programma, of dat ze andere interpretaties en aannames hanteren dan de regelgevers. Er is dus nood aan een zekere waakzaamheid, transparantie en inspraak in het hele implementatieproces, zeg maar “project governance“. Ook de uitvoerende ambtenaren moeten blijven begrijpen wat er gebeurt en waarom. Daarbij hoort ook een goede methode om feedback te verwerken die vanop de werkvloer aangebracht wordt.

Er bestaat vooralsnog geen vaste manier om compliance of governance ontegensprekelijk te garanderen. Het zijn nog steeds vage begrippen, en ook nogal wat wetgeving blijft vaag: zo staat het woord “redelijk” maar liefst 38 keer in de GDPR, en het woord “passend” zelfs 125 keer, zonder verdere specificatie van wat we daar nu concreet onder moeten verstaan. In de VS worden basisregels voor bedrijfsbeheer opgelegd door de Sarbanes-Oxley Act. In België bestaan er de Code Lippens voor beursgenoteerde, en Code Buysse voor niet-beursgenoteerde ondernemingen. Ondertussen wordt in Europa verder gewerkt aan o.a. een Data Governance Act om een kader te scheppen voor verantwoord (her)gebruik van gegevens.

Deze en andere regulatorische raamwerken zijn misschien niet perfect sluitend. Ze adopteren, eventueel certifiëren, en regelmatig eraan toetsen, zorgt op korte termijn wel voor extra overhead en kosten, maar het legt de lat ook hoger en kan zo op lange termijn veel zorgen voorkomen. Het is ook meestal goede reclame. Uit alle aangehaalde voorbeelden blijkt natuurlijk ook dat daarvoor de nodige wil moet bestaan bij, en middelen ter beschikking gesteld moeten worden door, de bevoegde beleidsmakers.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Confronté à la nécessité de mettre en place un dispositif de monitoring pour un projet de développement Web très interactif, je me suis évidemment d’abord intéressé aux solutions classiques telles que PingDom en SAAS ou la solution bien connue Selenium.

PingDom est évidemment intéressant, sinon même devenu incontournable, pour monitorer la présence d’un site Web.
Il a donc été utilisé pour monitorer quelques urls racines. La page publique est particulièrement utile pour informer les utilisateurs du statut du site.

Selenium a très vite montré ses limites dès lors que le code html du site devient un peu compliqué : difficultés d’enregistrement des scripts ou adaptations manuelles nombreuses deviennent nécessaires.

Selenium ayant déçu, la question s’est donc posée du bien fondé d’un développement spécifique pour balayer régulièrement des parties du site (selon des scénarios multiples) en prenant  des logs sur :
– les temps de réponse par lien activé ;
– les erreurs éventuelles (lien vers un site tiers devenu inopérant par exemple, ou erreur sur une action relative à un contrôle).

Le principe d’un développement spécifique retenu il fallait choisir un outil, le plus productif possible et capable de répondre à la volonté de vraiment traduire l’expérience utilisateur (entendez par là qui permette de mesurer le temps de réponse du rendu dans le browser et pas seulement de réaliser des gets de pages web vers le file system). Autre contrainte : permettre à un non-informaticien d’établir les fichiers d’instructions (fichiers des liens à visiter et contrôles de formulaires à activer).

Mes recherches m’ont conduit à opter pour l’open source AutoIt, découvert à l’adresse www.autoitscript.com/site/autoit/

Cet outil est en fait un langage et un framework d’automatisation sous Windows. Sa syntaxe est celle du VBA (Visual Basic for Application) avec des variables non typées de  type  Variant.

De nombreux éditeurs peuvent être utilisés, dont l’open source Scite qui a fait l’objet d’une déclinaison spécifique pour AutoIt (Scite4AutoIt).

La richesse fonctionnelle de l’outil est impressionnante (plusieurs centaines de fonctions). De nombreuses librairies UDF (User Defined Library) sont disponibles, dont celle relative à la manipulation d’Internet Explorer, élément  qui m’a fait retenir l’outil pour le besoin de monitoring de sites Web.

Les différents forums (En, Us, Fr, De et autres) sont très actifs et riches en conseils, UDFs et codes exemples.

Il nous a ainsi été possible de trouver des librairies pour interfacer le robot avec SQLite (“mini” base de données relationnelle livrée sous la forme d’une dll), Excel (pour construire les graphiques nécessaires),  PowerPoint (pour y stocker des copies écrans),  Skype (pour éventuellement envoyer des sms), Word, les protocoles FTP et SMTP, … Des UDFs existent dans les forums pour  interagir avec SQL Server, MySQL, … De nombreux petits “utilitaires” sont aussi disponibles, par exemple pour prendre des images de parties d’écran qui seront ensuite utilisée pour localiser les zones correspondantes et y simuler un clic souris (option utile lorsque les autres approches échouent).

Le développement principal consiste en un robot de monitoring finalement générique et donc entièrement paramétrable, permettant non seulement d’activer des liens mais aussi d’agir sur des contrôles (radiobox, checkbox, listbox, …). Une syntaxe ad hoc (et simple) a été developpée à cet effet, utilisée dans les fichiers de commandes.

Une seconde partie est destinée à exploiter la prise de logs effectuée par le robot (chargement dans une db [SQLite], détermination des dépassements, calculs de moyenne, graphiques). La visualisation des données et la gestion de la db sont effectués à l’aide de l’outil gratuit SQLite Expert Personal. Les échanges de SQLite vers Excel, la construction des graphiques dans Excel et leur envoi vers un serveur FTP sont pilotés par les scripts AutoIt.

Le projet impliquant des équipes offshore, le dispositif suivant a été développé. Les développeurs peuvent poster un gmail avec un mot clé. Un script déclenché à intervalles réguliers, détecte via un feed atom l’arrivée de ce mail, simule un login avec une carte eID, parcourt les écrans voulus, en prend des copies sous la forme de slides PowerPoint et retourne le .ppt en attachment dans un mail. La motivation  à l’origine de ce développement : les développeurs offshore n’ont pas accès à une carte eID belge. Ceci pourrait être envisagé dans l’environnement d’acceptation (finalement supprimé une fois l’intégration avec la plate-forme eHealth implémentée et testée) mais est de toutes façons exclu pour les ultimes tests dans l’environnement de production (question de droits d’accès à des données personnelles strictement confidentielles).
Le dispositif mis en place leur permet donc de procéder à de premiers tests sans attendre la disponibilité de “l’autre côté de la planète”.

Fort de ce succès nous envisageons aussi utiliser l’outil pour automatiser des opérations d’établissement de rapports s’appuyant sur des sources multiples (fichiers Excel, bases de données, écrans Web, …) dans un cadre plus général que celui du projet mentionné ici.

Hormis quelques limites dans la gestion des erreurs sur quelques composants COM dans de rares cas de figure (mais qui n’ont jamais empêché un fonctionnement correct – donc l’obtention du résultat voulu), la fiabilité de l’outil n’a pas été prise en défaut et de façon générale toutes les librairies utilisées se sont avérées efficaces.

Un outil à découvrir pour qui estime pouvoir exploiter des gisements de productivité en termes de Windows automation et Web automation.

Comparé à des équivalents  commerciaux, AutoIt s’est révélé une alternative parfaitement crédible vu sa qualité, sa richesse fonctionnelle, sa facilité d’apprentissage  et le dynamisme de ses forums.