Décision n° 2/2020 du comité mixte institué par l’accord entre l’Union européenne et la Confédération suisse sur le couplage de leurs systèmes d’échange de quotas d’émission de gaz à effet de serre du 5 novembre 2020 portant modification des annexes I et II de l’accord et adoption de normes techniques de couplage (NTC) [2021/1034]

ANNEXE

Normes techniques de couplage (NTC) établies conformément à l’article 3, paragraphe 7, de l’accord entre l’Union européenne et la Confédération suisse sur le couplage de leurs systèmes d’échange de quotas d’émission de gaz à effet de serre

NORMES RELATIVES À UNE SOLUTION PROVISOIRE

1. Glossaire

Tableau 1-1

Sigles et définitions «business»

Tableau 1-2

Sigles et définitions techniques

2. Introduction

L’accord entre l’Union européenne et la Confédération suisse sur le couplage de leurs systèmes d’échange de quotas d’émission de gaz à effet de serre du 23 novembre 2017 (ci-après l’«accord») prévoit la reconnaissance mutuelle des quotas d’émission qui peuvent être utilisés à des fins de conformité dans le cadre du système d’échange de quotas d’émission de l’Union (ci-après le «SEQE-UE») ou du système d’échange de quotas d’émission de la Suisse (ci-après le «SEQE Suisse»). Pour rendre opérationnel le couplage entre le SEQE-UE et le SEQE suisse, un lien direct sera établi entre le journal des transactions de l’Union européenne (EUTL) du registre de l’Union et le journal complémentaire des transactions suisse (SSTL) du registre suisse, ce qui permettra le transfert de registre à registre des quotas d’émission délivrés au titre de chaque SEQE (article 3, paragraphe 2, de l’accord). Afin de rendre opérationnel le couplage entre le SEQE de l’UE et le SEQE suisse, une solution provisoire doit être mise en place d’ici mai 2020 ou dès que possible après cette date. Les parties coopèrent pour remplacer dès que possible la solution provisoire par un couplage permanent des registres (annexe II de l’accord).

Conformément à l’article 3, paragraphe 7, de l’accord, l’administrateur du registre suisse et l’administrateur central du registre de l’Union élaborent des normes techniques de couplage (NTC) fondées sur les principes énoncés à l’annexe II, décrivant les exigences détaillées applicables à l’établissement d’une connexion fiable et sécurisée entre le SSTL et l’EUTL. Les NTC établies par les administrateurs prennent effet une fois qu’elles ont été adoptées par décision du comité mixte.

Les NTC décrites dans le présent document doivent être adoptées par le comité mixte en vertu de sa décision no 2/2020. Par la présente décision, le comité mixte charge l’administrateur du registre suisse et l’administrateur central de l’Union d’élaborer de nouvelles lignes directrices techniques visant à rendre opérationnel le couplage et de veiller à ce que ces lignes directrices soient constamment adaptées au progrès technique et aux nouvelles exigences en matière de sécurité et de sûreté du couplage, ainsi qu’à un fonctionnement efficace et efficient de celui-ci.

2.1. Champ d’application

Le présent document représente la conception commune des parties à l’accord en ce qui concerne l’établissement des bases techniques pour le couplage entre les registres du SEQE de l’UE et du SEQE suisse. Quoiqu’il jette les bases des spécifications techniques relatives aux exigences en matière d’architecture, de service et de sécurité, des orientations détaillées supplémentaires seront nécessaires afin de rendre le couplage opérationnel.

Afin d’assurer son fonctionnement adéquat, des processus et des procédures devront être mis en place. Conformément à l’article 3, paragraphe 6, de l’accord, ces aspects sont décrits en détail dans un document relatif aux procédures opérationnelles communes (POC) qui doit être adopté séparément par décision du comité mixte.

2.2. Destinataires

L’administrateur du registre suisse et l’administrateur central de l’Union sont destinataires du présent document.

3. Dispositions générales

3.1. Architecture du lien de communication

La présente section a pour objet la description de l’architecture générale pour la mise en œuvre du couplage entre le SEQE de l’UE et le SEQE suisse ainsi que des différentes composantes qui y participent.

La sécurité étant un élément essentiel pour la définition de l’architecture du couplage des registres, toutes les mesures ont été prises afin de disposer d’une architecture fiable. Alors que le couplage permanent des registres sera fondé sur des services internet, dans la solution provisoire, il sera plutôt fait appel à un mécanisme d’échange de fichiers.

La solution technique est la suivante:

3.1.1. Échange de messages

La communication entre le registre de l’Union et le registre suisse reposera sur un mécanisme d’échange de messages par des canaux sécurisés. Chaque bout disposera de son propre référentiel de messages reçus.

Les deux parties conserveront un journal des messages reçus, ainsi que les détails relatifs au traitement.

Les erreurs ou un statut inattendu doivent être signalés, sous la forme d’alertes, et les équipes de support devraient prendre contact entre elles.

3.1.2. Message XML — Haut niveau de description

Un message XML contient l’un des éléments suivants:

Chaque message contient un en-tête comportant les éléments suivants:

3.1.3. Fenêtres d’ingestion

La solution provisoire repose sur des fenêtres prédéfinies destinées à l’ingestion qui sont suivies par une série d’événements nommés. Les demandes de transaction reçues via le lien ne seront ingérées qu’à intervalles prédéfinis. Les fenêtres d’ingestion incluent une validation technique, tant à l’entrée qu’à la sortie. En outre, des rapprochements peuvent être effectués quotidiennement et être déclenchés manuellement.

3.1.4. Flux des messages de transaction

Transactions sortantes

Cette section est présentée sous l’angle du SEQE source du transfert. Le diagramme de séquence ci-dessus décrit l’ensemble des flux spécifiques aux transactions sortantes.

Flux principal d’une «transaction normale» (les étapes sont indiquées dans le schéma ci-dessus):

Autre flux «Journal des transactions rejetées» [les étapes sont indiquées dans le schéma ci-dessus, à partir du point a)]:

Ensuite:

Autre flux «Rejet par le SEQE» [les étapes sont indiquées dans le schéma ci-dessus, à partir du point a)]:

Ensuite:

Transactions entrantes

Cette section est présentée sous l’angle du SEQE destinataire du transfert. Le flux de données est représenté dans le diagramme de séquence suivant:

Le diagramme illustre ce qui suit:

Protocole

Le cycle des messages de transaction ne comporte que deux messages:

Statut des transactions

3.2. Sécurité du transfert des données

Les données en transit sont protégées par quatre niveaux de sécurité:

3.2.1. Pare-feu et interconnexion des réseaux

Le lien est établi au moyen d’un réseau protégé par un pare-feu matériel. Le pare-feu est configuré selon des règles en vertu desquelles seuls les clients «enregistrés» peuvent se connecter au serveur VPN.

3.2.2. VPN (Réseau privé virtuel — Virtual Private Network)

Toutes les communications entre les parties sont protégées au moyen d’une technologie de transport sécurisé des données. Dans le cas d’un VPN, l’infrastructure devrait être basée sur un dispositif virtuel ou matériel. Les technologies VPN permettent de transporter les informations d’un point à un autre à travers un canal sécurisé («tunnel») créé sur un réseau comme l’Internet, ce qui protège l’ensemble des communications. Avant que le tunnel VPN ne soit créé, un certificat numérique est émis vers un point de terminaison du client potentiel, ce qui permet à ce dernier de faire la preuve de son identité au cours de la phase de négociation de la connexion. Chaque partie est responsable de l’installation du certificat à son point de terminaison VPN. Chaque terminaison du serveur VPN aura accès, au moyen de certificats numériques, à une autorité centrale pour les négociations portant sur ses identifiants d’authentification. Lors du processus de création du tunnel, le cryptage fait l’objet de négociations, ce qui garantit la protection de l’ensemble des communications transitant par le tunnel.

Les points de terminaison du client VPN doivent être configurés de manière à ce le tunnel reste ouvert en permanence, afin de permettre à tout moment une communication fiable, bidirectionnelle et en temps réel entre les parties.

Toute autre solution équivalente doit respecter les principes susmentionnés.

3.2.3. Mise en œuvre de l’IPsec

En cas de recours à une solution VPN, l’utilisation du protocole IPSec en vue de la mise en place de l’infrastructure VPN de liaison de site à site permettra l’authentification, l’intégrité et le cryptage des données de site à site. Les configurations VPN incluant des protocoles IPsec garantissent une authentification appropriée entre deux points de terminaison d’une connexion VPN. Les parties identifieront et authentifieront le client distant par l’intermédiaire de la connexion IPSec au moyen de certificats numériques fournis par une autorité de certification reconnue par l’autre bout.

L’IPsec garantit également l’intégrité des données pour l’ensemble des communications transitant par le tunnel VPN. Les paquets de données sont soumis à un processus de hachage et de signature utilisant les informations d’authentification déterminées par le VPN. La confidentialité des données est assurée de même par le cryptage IPSec.

3.2.4. Protocole de transfert sécurisé pour l’échange de messages

La solution provisoire repose sur de multiples couches de cryptage permettant l’échange sécurisé de données entre les parties. Les deux systèmes et leurs environnements respectifs sont interconnectés au niveau «réseau» au moyen de tunnels VPN ou de réseaux équivalents de transport sécurisé de données. Au niveau «application», les fichiers sont transférés au moyen d’un protocole de transfert sécurisé pour l’échange de messages.

3.2.5. Signature et cryptage XML

Dans les fichiers XML, la signature et le cryptage interviennent à deux niveaux. À chaque demande de transaction, la réponse de transaction et le message de rapprochement reçoivent chacun une signature numérique.

Dans un deuxième temps, chaque sous-élément de l’élément « message » est crypté séparément.

En outre, dans un troisième temps, pour garantir l’intégrité et la non-répudiation de l’ensemble du message, l’élément racine du message est signé numériquement. Il en résulte un haut niveau de protection des données embarquées XML. La mise en œuvre technique respecte les normes du World Wide Web Consortium.

Pour décrypter et vérifier le message, le même processus est suivi dans l’ordre inverse.

3.2.6. Clés cryptographiques

La cryptographie à clé publique sera utilisée pour le cryptage et la signature.

Dans le cas spécifique d’IPSec, un certificat numérique émis par une autorité de certification (AC) bénéficiant de la confiance des deux parties est utilisé. Après vérification de l’identité du titulaire du certificat, cette AC émet des certificats qui sont utilisés pour identifier formellement une organisation et établir des canaux sécurisés de communication des données entre les parties.

3.3. Liste des fonctions dans le cadre du couplage

Le couplage comprend les spécifications du système de transmission pour une série de fonctions qui mettent en œuvre les processus «business» découlant de l’accord. Le couplage intègre les spécifications en ce qui concerne le processus de rapprochement et les messages de test qui permettront la mise en œuvre d’un système de surveillance par signaux de présence.

3.3.1. Transactions «business»

D’un point de vue «business», dans le cadre du couplage, il est prévu quatre (4) types de demandes de transaction:

3.3.2. Protocole de rapprochement

Les rapprochements ne seront effectués qu’après fermeture des fenêtres relatives à l’ingestion, à la validation et au traitement des messages.

Les rapprochements font partie intégrante des mesures garantissant la sécurité et la cohérence du couplage. Les deux parties conviendront du calendrier exact du rapprochement avant d’établir formellement sa programmation. Un rapprochement peut être programmé quotidiennement si les deux parties en conviennent. Au moins un rapprochement programmé sera exécuté au minimum après chaque processus d’ingestion de données.

Dans tous les cas, chaque partie peut procéder à tout moment à des rapprochements manuels.

3.3.3. Message de test

Un message de test est prévu pour tester la communication de bout en bout. Ce message contient des données qui permettent de l’identifier en tant que message de test, et une réponse est envoyée par l’autre bout dès sa réception.

3.4. Normes applicables aux services internet

Les services internet ne seront pas utilisés dans le cadre de la solution provisoire. Il convient toutefois de signaler que le format des messages XML restera globalement inchangé. Lorsque le couplage permanent des registres sera mis en place, les services internet devraient permettre l’échange de messages XML en temps réel.

3.5. Définition spécifique des services internet

La présente section ne s’applique pas à la solution provisoire. Comme indiqué dans la section précédente, les services internet seront utilisés uniquement dans le cadre du futur couplage permanent des registres.

3.6. Exigences relatives à l’enregistrement des données

Afin de répondre au besoin des deux parties de préserver l’exactitude et la cohérence des informations, et afin de fournir des outils utilisables lors du processus de rapprochement pour éliminer les incohérences, quatre (4) types de journaux de données doivent être tenus par chacune des parties:

Toutes les données de ces journaux devront être conservées durant au moins trois (3) mois aux fins de la résolution de problèmes et leur conservation ultérieure à des fins d’audit dépendra du droit applicable à chaque bout. Les fichiers-journaux datant de plus de trois (3) mois peuvent être archivés dans un système informatique indépendant sécurisé, à la condition qu’ils puissent être retrouvés ou qu’on puisse y accéder dans un délai raisonnable.

Journaux des transactions

Les journaux des transactions sont mis en œuvre dans les sous-systèmes EUTL et SSTL.

Plus précisément, les journaux des transactions enregistreront chacune des transactions proposées à l’autre SEQE. Chaque enregistrement contient l’ensemble des champs relatif au contenu de la transaction ainsi qu’au résultat qui s’ensuit (la réponse envoyée par le SEQE qui reçoit la demande). Les journaux des transactions enregistreront également les transactions entrantes et la réponse envoyée au SEQE source du transfert.

Journaux des rapprochements

Le journal des rapprochements enregistre chacun des messages de rapprochement échangés entre les parties, notamment l’identifiant, l’horodatage et le résultat du rapprochement: statut du rapprochement «Pass» (réussite) ou «Discrepancies» (divergences). Dans le cadre de la solution provisoire, les messages de rapprochement font partie intégrante des messages échangés.

Les deux parties consignent chaque demande et sa réponse dans le journal des rapprochements. Bien que les informations contenues dans le journal des rapprochements ne soient pas directement partagées dans le cadre du processus de rapprochement proprement dit, il peut s’avérer nécessaire d’avoir accès à ces informations pour supprimer les incohérences.

Archive de messages

Les deux parties sont tenues d’archiver une copie des données échangées (les fichiers XML), envoyées et reçues, ainsi que l’information indiquant si le format de ces messages XML est correct ou non.

La principale raison d’être de l’archivage est l’audit, le but étant de disposer de preuves de ce qui a été envoyé et reçu par les deux parties. À cette fin, les certificats doivent également être archivés avec les fichiers correspondants.

Ces fichiers fourniront également des informations supplémentaires aux fins de la résolution de problèmes.

Journaux des audits internes

Ces journaux sont définis et utilisés par chaque partie séparément.

3.7. Prescriptions opérationnelles

L’échange de données entre les deux systèmes n’est pas totalement autonome dans le cadre de la solution provisoire: des opérateurs et des procédures sont nécessaires à la mise en œuvre du couplage.

4. Dispositions permettant de garantir la disponibilité

4.1. Conception garantissant la disponibilité de la communication

Fondamentalement, l’architecture de la solution provisoire consiste en une infrastructure et un logiciel TIC qui permettent la communication entre le SEQE suisse et le SEQE de l’UE. Garantir des niveaux élevés de disponibilité, d’intégrité et de confidentialité pour ce flux de données est dès lors un aspect essentiel qui doit être pris en compte dans la conception de la solution provisoire et du couplage permanent des registres. Étant donné qu’il s’agit d’un projet dans lequel l’infrastructure TIC, le logiciel sur mesure et les processus jouent un rôle essentiel, il doit être tenu compte de ces trois éléments pour concevoir un système résilient.

Résilience de l’infrastructure TIC

Le chapitre « Dispositions générales» du présent document détaille les blocs de construction de l’architecture. En ce qui concerne l’infrastructure TIC, dans le cadre du couplage provisoire, un réseau VPN résilient (ou équivalent) est mis en place et crée des tunnels de communication sécurisés par l’intermédiaire desquels les messages peuvent être échangés de manière sécurisée. D’autres éléments d’infrastructure sont configurés en haute disponibilité et/ou disposent de mécanismes de secours.

Résilience des logiciels sur mesure

Les modules logiciels sur mesure permettent de renforcer la résilience car ils tentent, pendant une durée donnée, de rétablir la communication avec l’autre bout lorsque, pour une raison quelconque, ce service n’est pas disponible.

Résilience des services

Dans le cadre de la solution provisoire, les échanges de données entre les parties ont lieu dans des plages horaires prédéfinies tout au long de l’année. Certaines des étapes requises pour les échanges de données préprogrammés exigent l’intervention manuelle des opérateurs du système et/ou des administrateurs des registres. Afin de prendre en compte cet aspect et d’accroître la disponibilité et le succès des échanges:

4.2. Plan d’initialisation, de communication, de réactivation et de test

L’ensemble des différents éléments intervenant dans l’architecture de la solution provisoire doivent être soumis avec succès à des tests individuels et collectifs afin de vérifier que les niveaux «infrastructure TIC» et «système d’information» de la plateforme sont prêts. Ces tests opérationnels sont une condition préalable et impérative chaque fois que la solution provisoire doit passer du statut «suspendu» («suspended») au statut «opérationnel» sur la plateforme.

L’activation du statut opérationnel du lien exige donc qu’un plan de test prédéfini ait été exécuté avec succès, ce qui permet de s’assurer qu’un ensemble de tests en interne ont été exécutés au préalable pour chaque registre et que la connectivité a été validée de bout en bout avant de commencer à soumettre des transactions en production entre les deux parties.

Le plan de test devrait mentionner la stratégie de test globale et comporter des détails relatifs à l’infrastructure de test. En particulier, pour chacun des éléments de chaque bloc de test, il faut disposer des éléments suivants:

Le processus des tests d’activation du statut opérationnel pourrait être subdivisé en quatre (4) blocs ou phases conceptuels:

4.2.1. Test des infrastructures TIC en interne

Il est prévu que ces tests soient réalisés et/ou vérifiés par chacune des parties à chaque bout.

Chaque élément de l’infrastructure TIC à chaque bout doit être testé séparément. Cette prescription vaut pour chaque composante de l’infrastructure. Ces tests peuvent être exécutés automatiquement ou manuellement mais ils doivent permettre de confirmer que chaque élément de l’infrastructure est opérationnel.

4.2.2. Tests de communication

Ces tests sont amorcés individuellement par l’une ou l’autre des parties et leur achèvement doit se faire en coopération avec l’autre bout.

Une fois que chacun des différents éléments est opérationnel, les canaux de communication entre les deux registres doivent être mis à l’essai également. À cette fin, chaque partie vérifie que l’accès à Internet fonctionne, que les tunnels VPN (ou du réseau de transport sécurisé équivalent) sont mis en place et qu’une connectivité IP de site à site est établie. L’accessibilité des éléments d’infrastructure locaux et distants et la connectivité IP devraient ensuite être confirmées à l’autre bout.

4.2.3. Tests du système complet (de bout en bout)

Il est prévu que ces tests soient exécutés à chaque bout et que les résultats soient communiqués à l’autre partie.

Une fois que les canaux de communication et chacune des composantes des deux registres ont été testés, une série de transactions et de rapprochements simulés, représentatifs de l’ensemble des fonctions à mettre en œuvre dans le cadre du lien, est préparée à chaque bout.

4.2.4. Tests de sécurité

Ces tests sont censés être effectués et/ou déclenchés par les deux parties à chaque bout, selon les instructions figurant dans les sections 5.4 «Lignes directrices en matière de tests de sécurité» et 5.5 «Dispositions en matière d’évaluation des risques».

Ce n’est qu’après que les quatre phases/blocs se sont conclus par un résultat prévisible que le lien provisoire peut être considéré comme opérationnel.

Ressources destinées aux tests

Chaque partie s’appuie sur des ressources spécifiques destinées aux tests (logiciels et matériels spécifiques aux infrastructures TIC) et développe des fonctions de test à intégrer dans son propre système afin de soutenir la validation manuelle et continue de la plateforme. Des procédures de test manuelles, entreprises séparément par chacune des parties ou en coopération, peuvent être exécutées à tout moment par les administrateurs des registres. L’activation du statut opérationnel est un processus manuel en lui-même.

Il est également prévu que la plateforme effectue des contrôles automatiques à intervalles réguliers. Ces contrôles visent à accroître la disponibilité de la plateforme par la détection précoce d’éventuels problèmes au niveau de l’infrastructure ou au niveau logiciel. Ce plan de surveillance de la plateforme est constitué de deux éléments:

4.3. Environnements de validation/de test

L’architecture du registre de l’Union et du registre suisse comprend les trois environnements suivants:

Exception faite du VPN (ou du réseau équivalent), les trois environnements sont totalement indépendamment les uns des autres, ce qui signifie que le matériel, les logiciels, les bases de données, les environnements virtuels, les adresses IP et les ports sont configurés de manière indépendante les uns des autres et fonctionnent indépendamment également.

Quant au VPN, il en existe deux configurations, prévues pour deux environnements différents: une pour l’environnement PROD et une autre pour ACC et TEST.

5. Dispositions relatives à la confidentialité et à l’intégrité

Les mécanismes et les procédures de sécurité prévoient l’application du principe du double regard pour les opérations effectuées dans le cadre du couplage du registre de l’Union et du registre suisse. Le principe du double regard s’applique chaque fois que nécessaire, mais il pourrait ne pas s’appliquer à toutes les actions entreprises par les administrateurs des registres.

Les exigences en matière de sécurité sont prises en compte et abordées dans le plan de gestion de la sécurité, qui inclut également des processus liés au traitement des incidents de sécurité à la suite d’éventuelles failles de sécurité. La partie opérationnelle de ces processus est décrite dans les POC.

5.1. Infrastructure destinée aux tests de sécurité

Chaque partie s’engage à mettre en place une infrastructure destinée aux tests de sécurité (au moyen de l’ensemble commun de logiciels et de matériel utilisés pour détecter les vulnérabilités lors des phases de développement et d’exploitation):

Chaque partie s’engage à effectuer des analyses statiques et dynamiques.

Dans le cas d’une analyse dynamique (comme des tests d’intrusion), les deux parties s’engagent à limiter d’ordinaire les évaluations aux environnements de test et de validation (tels que définis dans la section 4.3 «Environnements de validation/de test»). Ce principe admet des exceptions qui doivent faire l’objet d’une approbation par les deux parties.

Avant d’être déployé dans l’environnement de production, chaque module logiciel du lien (tel que défini dans la section 3.1 «Architecture du lien de communication») doit faire l’objet d’un test de sécurité.

L’infrastructure de test doit être séparée de l’infrastructures de production tant au niveau «réseau» qu’au niveau «infrastructure». Les tests de sécurité requis pour vérifier le respect des exigences de sécurité sont réalisés au sein de l’infrastructure de test.

5.2. Dispositions relatives à la suspension et à la réactivation du lien

En cas de suspicion d’atteinte à la sécurité du registre suisse, du SSTL, du registre de l’Union ou de l’EUTL, l’une ou l’autre partie en informe l’autre et suspend immédiatement le lien entre le SSTL et l’EUTL.

Suspensions

La suspension du couplage des registres conformément à l’annexe II de l’accord peut advenir pour les raisons suivantes:

En cas d’urgence, chaque partie informera l’autre partie et suspendra unilatéralement le couplage des registres.

S’il est décidé de suspendre le couplage des registres, chaque partie veillera alors à ce que le lien soit interrompu au niveau «réseau» (par le blocage des connexions entrantes et sortantes, en tout ou en partie).

Réactivation de la communication

La décision de réactivation du couplage sera prise de la façon décrite dans les POC et, en tout état de cause, pas avant que les procédures de test de sécurité n’aient été exécutées avec succès, comme indiqué dans les sections 5.4 «Lignes directrices en matière de tests de sécurité» et 4.2 «Plan d’initialisation, de communication, de réactivation et de test».

5.3. Dispositions relatives aux failles de sécurité

Une faille de sécurité est considérée comme un incident de sécurité susceptible de porter atteinte à la confidentialité et à l’intégrité d’informations sensibles et/ou à la disponibilité du système qui les traite.

Les informations sensibles sont recensées sur la liste des informations sensibles et peuvent être traitées dans le système ou dans toute partie y afférente.

Sauf indication contraire, les informations directement liées à la faille de sécurité seront considérées comme sensibles, marquées «SEQE CRITIQUE» et traitées conformément aux instructions de traitement.

5.4. Lignes directrices relatives aux tests de sécurité

5.4.1. Logiciels

Les tests de sécurité, notamment, le cas échéant, les tests d’intrusion, doivent être exécutés au minimum pour toute nouvelle mise en production majeure du logiciel, conformément aux exigences de sécurité établies dans les NTC aux fins de l’évaluation de la sécurité du couplage ainsi que des risques correspondants.

Si aucune mise en production majeure n’est intervenue aux cours des 12 derniers mois, un test de sécurité doit être exécuté sur le système en place en tenant compte de l’évolution des menaces informatiques survenue au cours des 12 derniers mois.

Les tests de sécurité du couplage des registres doivent être effectués dans l’environnement de validation et, si nécessaire, dans l’environnement de production, en coordination avec les deux parties et avec leur accord mutuel.

Les tests des applications internet respecteront les normes ouvertes internationales telles que celles établies par l’OWASP (Open Web Application Security Project).

5.4.2. Infrastructure

Les infrastructures qui prennent en charge le système de production doivent être régulièrement scrutées (au moins une fois par mois) en vue de détecter d’éventuelles vulnérabilités, auxquelles il conviendra de remédier. Les tests sont menés conformément à la une base de données actualisée relative aux vulnérabilités.

5.5. Dispositions en matière d’évaluation des risques

Si des tests d’intrusion doivent être effectués, ils doivent être inclus dans les tests de sécurité.

Chaque partie peut confier à une société spécialisée la réalisation des tests de sécurité, à condition que la société en question: