BIJLAGE

Koppelingstechnische normen (LTS) uit hoofde van artikel 3, lid 7, van de Overeenkomst tussen de Europese Unie en de Zwitserse Bondsstaat inzake de koppeling van hun regelingen voor de handel in broeikasgasemissierechten)

NORMEN VOOR VOORLOPIGE OPLOSSING

1.   Verklarende woordenlijst

Tabel 1-1

Bedrijfsacroniemen en definities

Acroniem/term	Definitie
Emissierecht	Een emissierecht om gedurende een bepaalde periode één ton kooldioxide-equivalent uit te stoten, dat alleen geldig is om te voldoen aan de vereisten van het EU-ETS of het ETS van Zwitserland
CH	Zwitserse Bondsstaat
CHU	Zwitserse algemene emissierechten (de term “CHU2” wordt gebruikt als afkorting voor de CHU-emissierechten voor de vastleggingsperiode 2)
CHUA	Emissierechten van de Zwitserse luchtvaart
GOP	Gemeenschappelijke operationele procedures die gezamenlijk door de partijen bij de overeenkomst zijn ontwikkeld om de koppeling tussen het EU-ETS en het ETS van Zwitserland te realiseren
ETR	Emissiehandelsregister
ETS	Emissiehandelssysteem/emissiehandelsregeling
EU	Europese Unie
EUA	Algemene emissierechten van de EU
EUAA	Luchtvaartemissierechten van de EU
EUCR	Geconsolideerd register van de Europese Unie
EUTL	Het EU-transactielogboek
Register	Een boekhoudsysteem voor emissierechten die zijn verleend in het kader van het ETS, waarin eigendom van rechten in elektronische accounts wordt bijgehouden
SSTL	Zwitsers aanvullend transactielogboek
Transactie	Een proces in een register waarbij een emissierecht van een rekening naar een andere rekening wordt overgedragen
Transactielogboek	Het transactielogboek bevat een register van elke voorgestelde transactie die van het ene register naar het andere wordt verzonden

Tabel 1-2

Technische acroniemen en definities

Acroniem	Definitie
Asymmetrische cryptografie	Maakt gebruik van publieke en private sleutels voor het versleutelen en ontsleutelen van gegevens
Certificeringsautoriteit (CA)	Entiteit die digitale certificaten uitgeeft
Cryptografische sleutel	Een stuk informatie dat de functionele output van een cryptografisch algoritme bepaalt
Ontsleuteling	Omgekeerd proces van versleuteling
Digitale handtekening	Een mathematische techniek die wordt gebruikt om de authenticiteit en integriteit van een bericht, software of een digitaal document te valideren
Versleuteling	Het omzetten van informatie of gegevens in een code, met name om ongeoorloofde toegang te voorkomen
Bestandopname	Het proces waarbij een bestand wordt gelezen
Firewall	Apparatuur of software voor netwerkbeveiliging die het inkomende en uitgaande netwerkverkeer monitort en controleert op basis van vooraf vastgestelde regels
Heartbeatmonitoring	Periodiek door hardware of software gegenereerd en bewaakt signaal om de normale werking aan te geven of om andere delen van een computersysteem te synchroniseren
IPSec	IP SECurity (IP-beveiliging). Netwerkprotocolsuite die de gegevenspakketten authenticeert en versleutelt om te zorgen voor een beveiligde, versleutelde communicatie tussen twee computers over een internetprotocolnetwerk
Penetratietest	Praktijk van het testen van een computersysteem, netwerk of webtoepassing om beveiligingskwetsbaarheden op te sporen die een aanvaller zou kunnen benutten
Afstemmingsproces	Proces om ervoor te zorgen dat twee reeksen gegevens met elkaar overeenstemmen
VPN	Virtueel particulier netwerk
XML	Extensible Mark-up Language. Biedt ontwerpers de mogelijkheid om hun eigen specifieke tags te creëren, waardoor de gegevens tussen de verschillende toepassingen en tussen de verschillende organisaties kunnen worden gedefinieerd, verzonden, gevalideerd en geïnterpreteerd

2.   Inleiding

De Overeenkomst tussen de Europese Unie en de Zwitserse Bondsstaat inzake de koppeling van hun regelingen voor de handel in broeikasgasemissierechten van 23 november 2017 (hierna “de overeenkomst” genoemd) voorziet in de wederzijdse erkenning van emissierechten die in het kader van het emissiehandelssysteem van de Europese Unie (“EU-ETS”) of het emissiehandelssysteem van Zwitserland (“ETS van Zwitserland”) kunnen worden gebruikt. Om de koppeling tussen het EU-ETS en het ETS van Zwitserland operationeel te maken, wordt een directe koppeling tussen het EU-transactielogboek (EUTL) van het register van de Unie en het Zwitserse aanvullende transactielogboek (SSTL) van het Zwitserse register tot stand gebracht, waardoor onder een van beide regelingen verleende emissierechten van het ene naar het andere ETS zullen kunnen worden overgedragen (artikel 3, lid 2, van de overeenkomst). Om de koppeling tussen het EU-ETS en het ETS van Zwitserland operationeel te maken, wordt tegen mei 2020 of zo spoedig mogelijk daarna in een voorlopige oplossing voorzien. De partijen werken samen om de voorlopige oplossing zo spoedig mogelijk door een permanente registerkoppeling te vervangen (bijlage II bij de overeenkomst).

Overeenkomstig artikel 3, lid 7, van de overeenkomst stellen de Zwitserse registeradministrateur en de centrale administrateur van de Unie op basis van de beginselen in bijlage II bij de overeenkomst koppelingstechnische normen vast waarin de gedetailleerde eisen voor het tot stand brengen van een robuuste en veilige verbinding tussen het SSTL en het EUTL worden beschreven. De door de administrateurs ontwikkelde koppelingstechnische normen treden in werking wanneer zij bij besluit van het Gemengd Comité zijn aangenomen.

De in dit document opgenomen LTS moeten door het Gemengd Comité bij Besluit nr. 2/2020 worden aangenomen. Overeenkomstig dat besluit verzoekt het Gemengd Comité de Zwitserse registeradministrateur en de centrale administrateur van de Unie om verdere technische richtsnoeren te ontwikkelen om de koppeling te realiseren en ervoor te zorgen dat deze voortdurend worden aangepast aan de technische vooruitgang en aan nieuwe eisen met betrekking tot de veiligheid en beveiliging van de verbinding en tot de doeltreffende en efficiënte werking ervan.

2.1.   Toepassingsgebied

Dit document omvat het akkoord tussen de partijen bij de overeenkomst over de totstandbrenging van de technische grondslag van de koppeling tussen de registers van het EU-ETS en het ETS van Zwitserland. Dit document vormt de basis voor de technische specificaties met betrekking tot eisen op het gebied van architectuur, dienstverlening en beveiliging, maar enkele verdere gedetailleerde richtsnoeren zijn nodig om de koppeling operationeel te maken.

Voor de goede werking van de koppeling zullen processen en procedures nodig zijn om de koppeling verder te realiseren. Overeenkomstig artikel 3, lid 6, van de overeenkomst worden deze kwesties in detail beschreven in een apart document betreffende gemeenschappelijke operationele procedures (GOP), dat afzonderlijk bij besluit van het Gemengd Comité moet worden aangenomen.

2.2.   Adressaten

Dit document is gericht tot de Zwitserse registeradministrateur en de centrale administrateur van de Unie.

3.   Algemene bepalingen

3.1.   Architectuur van de communicatiekoppeling

Het doel van dit hoofdstuk is een beschrijving te geven van de algemene architectuur van de realisering van de koppeling tussen het EU-ETS en het ETS van Zwitserland en de verschillende onderdelen ervan.

Beveiliging is een essentieel onderdeel van een robuuste architectuur van de registerkoppeling, en daartoe zijn alle nodige maatregelen genomen. Hoewel de geplande permanente registerkoppeling op webdiensten gebaseerd zal zijn, wordt voor de voorlopige oplossing een mechanisme voor het uitwisselen van bestanden gebruikt.

Voor de technische oplossing wordt gebruikgemaakt van:

—	een beveiligd protocol voor de uitwisseling van berichten;

—	XML-berichten;

—	op XML gebaseerde digitale ondertekening en versleuteling;

—	VPN-diensten of een gelijkwaardig beveiligd datatransportnetwerk.

3.1.1.   Uitwisseling van berichten

De communicatie tussen het EU-register en het Zwitserse register wordt gebaseerd op een mechanisme voor de uitwisseling van berichten via beveiligde kanalen. Elke partij bewaart de ontvangen berichten in een eigen register.

De partijen houden een logboek van de ontvangen berichten bij, alsmede van de gegevens betreffende de verwerking.

Fouten of een onverwachte status moeten als waarschuwing worden gemeld, waarna menselijk contact tussen de ondersteunende teams moet plaatsvinden.

Fouten en onverwachte gebeurtenissen worden behandeld met inachtneming van de in het kader van het incidentenbeheerproces van de GOP vastgestelde operationele procedures.

3.1.2.   XML-bericht — Beschrijving op hoog niveau

Een XML-bericht bevat een van de volgende elementen:

—	een of meer transactieverzoeken en/of een of meerdere transactieresponsen;

—	een actie/respons in verband met de afstemming;

—	een testbericht.

Elk bericht bevat een header met:

—	het ETS-systeem waarvan het afkomstig is;

—	een volgnummer.

3.1.3.   Opnamevensters

De voorlopige oplossing is gebaseerd op vooraf gedefinieerde opnamevensters die worden gevolgd door een reeks van benoemde gebeurtenissen (“named events”). Via de koppeling ontvangen transactieverzoeken worden uitsluitend tijdens van tevoren vastgestelde vensters opgenomen. Opnamevensters omvatten een technische validatie voor uitgaande en inkomende transacties. Daarnaast kunnen afstemmingen dagelijks worden uitgevoerd en manueel worden geactiveerd.

Wijzigingen in de frequentie en/of timing van een of meer van deze gebeurtenissen worden behandeld met inachtneming van de in het kader van de afhandeling van verzoeken van de GOP vastgestelde operationele procedures.

3.1.4.   Transactieberichtenstroom

Uitgaande transacties

Dit is een weergave vanuit het perspectief van het ETS dat de overdracht doet. Het bovenstaande schema toont alle specifieke uitgaande transactiestromen.

Hoofdstroom “Normale transactie” (met de in het schema aangegeven stappen):

a)	bij het ETS dat de overdracht doet, wordt het transactieverzoek van het register naar het transactielogboek verzonden zodra de bedrijfsvertraging voorbij is (24 uur vertraging, indien van toepassing);

b)	het transactielogboek valideert het transactieverzoek;

c)	het verzoek om een transactie wordt naar het ETS van bestemming verzonden;

d)	de acceptatierespons wordt naar het register van het ETS van oorsprong verzonden;

e)	het ETS van bestemming valideert het transactieverzoek;

f)	het ETS van bestemming stuurt de acceptatierespons terug naar het transactielogboek van het ETS van oorsprong;

g)	het transactielogboek stuurt de acceptatierespons naar het register.

Alternatieve stroom “Afwijzing door transactielogboek” (met de in het schema aangegeven stappen, beginnend bij a)):

a)	in het ETS van oorsprong wordt het transactieverzoek van het register naar het transactielogboek verzonden zodra de bedrijfsvertraging voorbij is (24 uur vertraging, indien van toepassing).

Gevolgd door:

b)	het transactielogboek valideert het verzoek niet;

c)	het afwijzingsbericht wordt verzonden naar het register van oorsprong.

Alternatieve stroom “Afwijzing door ETS” (met de in het schema aangegeven stappen, beginnend bij a)):

a)	in het ETS van oorsprong wordt het transactieverzoek van het register naar het transactielogboek verzonden zodra de bedrijfsvertraging voorbij is (24 uur vertraging, indien van toepassing);

b)	het transactielogboek valideert de transactie;

c)	het verzoek om een transactie wordt naar het ETS van bestemming verzonden;

d)	de acceptatierespons wordt naar het register van het ETS van oorsprong verzonden.

Gevolgd door:

e)	het transactielogboek van het verwervende ETS valideert de transactie niet;

f)	het verwervende ETS stuurt de afwijzingsrespons naar het transactielogboek van het overdragende ETS;

g)	het transactielogboek stuurt de afwijzing naar het register.

Inkomende transacties

Dit is een weergave vanuit het perspectief van het verwervende ETS. De specifieke stroom wordt weergegeven in het volgende schema:

Het schema toont:

1.	wanneer het transactielogboek van het verwervende ETS het verzoek valideert, stuurt het de acceptatierespons naar het overdragende ETS en een bericht “transactie voltooid” naar het register van het verwervende ETS;

2.	wanneer een inkomend verzoek binnenkomt op het verwervende transactielogboek en wordt geweigerd, wordt het transactieverzoek niet naar het register van het verwervende ETS gestuurd.

Protocol

De transactieberichtencyclus omvat slechts twee berichten:

—	overdragend ETS verwervend ETS: transactievoorstel;

—	verwervend ETS overdragend ETS: transactierespons: acceptatie of afwijzing (met vermelding van de reden voor afwijzing): — acceptatie: de transactie is voltooid; — afwijzing: de transactie is beëindigd.

Transactiestatus

—	De transactiestatus van het overdragende ETS wordt veranderd in “voorgesteld” wanneer het verzoek wordt verzonden.

—	De transactiestatus van het verwervende ETS wordt veranderd in “voorgesteld” wanneer het verzoek wordt ontvangen en wordt behandeld.

—	De transactiestatus van het verwervende ETS wordt veranderd in “voltooid”/”beëindigd” nadat het voorstel is verwerkt. Het verwervende ETS stuurt vervolgens het bijbehorende bericht van acceptatie/afwijzing.

—	De transactiestatus van het overdragende ETS wordt veranderd in “voltooid”/“beëindigd” nadat het bericht van acceptatie/afwijzing is ontvangen en verwerkt.

—	In het overdragende ETS blijft de transactiestatus “voorgesteld” indien geen respons wordt ontvangen.

—	Het verwervende ETS geeft elke transactie die langer dan 30 minuten op “voorgesteld” staat, de status “beëindigd”.

Incidenten in verband met transacties worden behandeld met inachtneming van de in het kader van het incidentenbeheerproces van de GOP vastgestelde operationele procedures.

3.2.   Beveiliging van gegevensoverdracht

Verstuurde gegevens worden onderworpen aan vier beveiligingsniveaus:

1.	controle van de toegang tot het netwerk: firewall en netwerkinterconnectie;

2.	versleuteling tijdens het vervoer: VPN of gelijkwaardig beveiligd datatransportnetwerk;

3.	versleuteling tijdens sessie: overdrachtprotocol voor beveiligde uitwisseling van berichten;

4.	versleuteling op niveau van de toepassing: XML-inhoudversleuteling en -ondertekening.

3.2.1.   Firewall en netwerkinterconnectie

De koppeling wordt tot stand gebracht over een netwerk dat wordt beschermd door een op hardware gebaseerde firewall. De firewall moet zodanig worden geconfigureerd dat alleen “geregistreerde” clients verbindingen met de VPN-server kunnen maken.

3.2.2.   Virtueel particulier netwerk (VPN)

Alle communicatie tussen de partijen wordt beschermd door middel van een beveiligde technologie voor dataverkeer. In het geval van een virtueel particulier netwerk (VPN) moet de infrastructuur gebaseerd zijn op hardware of virtuele appliances. VPN-technologieën bieden de mogelijkheid om via een netwerk zoals het internet van de ene plaats naar de andere te “tunnelen”, waarbij alle communicatie wordt beschermd. Voorafgaand aan het opzetten van de VPN-tunnel wordt een digitaal certificaat afgegeven aan het eindpunt van een mogelijke client, zodat de client bij het verbinden een bewijs van identiteit kan overleggen. Elke partij is verantwoordelijk voor de installatie van het certificaat in het eigen VPN-eindpunt. Door gebruik te maken van digitale certificaten krijgt elke VPN-server toegang tot een centrale autoriteit voor het uitwisselen van authenticatiegegevens. Bij het opzetten van de tunnel wordt versleuteling uitgevoerd, zodat alle communicatie via de tunnel wordt beschermd.

De VPN-eindpunten van de clients zijn zodanig geconfigureerd dat de VPN-tunnel permanent in stand wordt gehouden, zodat te allen tijde betrouwbare communicatie in realtime en in beide richtingen tussen de partijen mogelijk is.

Elke andere gelijkwaardige oplossing moet voldoen aan bovengenoemde beginselen.

3.2.3.   Uitvoering van IPSec

Indien een VPN-oplossing wordt gebruikt, zal het gebruik van het IPSec-protocol om de site-to-site VPN-infrastructuur te vormen, zorgen voor site-to-site authenticatie, de integriteit van de gegevens en gegevensversleuteling. IPSec-VPN-configuraties zorgen voor de juiste authenticatie tussen twee eindpunten in een VPN-verbinding. De partijen identificeren en authenticeren de client op afstand via de IPSec-verbinding door middel van digitale certificaten die worden verstrekt door een door het andere einde erkende certificeringsautoriteit.

IPSec waarborgt ook de integriteit van alle communicatie via de VPN-tunnel. Gegevenspakketten worden gehashed en ondertekend door middel van de authenticatie-informatie die door het VPN is ingevoerd. De vertrouwelijkheid van de gegevens wordt ook gewaarborgd door IPSec-versleuteling mogelijk te maken.

3.2.4.   Overdrachtprotocol voor beveiligde uitwisseling van berichten

De voorlopige oplossing berust op meerdere versleutelingslagen voor de beveiligde uitwisseling van gegevens tussen de partijen. Beide systemen en hun verschillende omgevingen zijn op het niveau van het netwerk met elkaar verbonden door middel van VPN-tunnels of gelijkwaardige beveiligde datatransportnetwerken. Op het niveau van de applicatie worden de bestanden overgedragen met behulp van een overdrachtprotocol voor de beveiligde uitwisseling van berichten op het niveau van de sessie.

3.2.5.   XML-versleuteling en -ondertekening

In XML-bestanden vindt ondertekening en versleuteling plaats op twee niveaus. Elk(e) transactieverzoek, transactierespons en afstemmingsbericht wordt afzonderlijk digitaal ondertekend.

In een tweede stap wordt elk subelement van het “bericht”-element afzonderlijk versleuteld.

Als derde stap en om de integriteit en onweerlegbaarheid van het volledige bericht te waarborgen, wordt het kernelementbericht digitaal ondertekend. Dit resulteert in een hoog niveau van bescherming voor de in XML ingebedde gegevens. Bij de technische uitvoering worden de normen van het World Wide Web Consortium in acht genomen.

Voor het ontsleutelen en verifiëren van het bericht wordt het proces in omgekeerde volgorde uitgevoerd.

3.2.6.   Cryptografische sleutels

Voor versleuteling en ondertekening wordt gebruik gemaakt van een openbare cryptografische sleutel.

Voor IPSec worden alleen digitale certificaten gebruikt die zijn afgegeven door een door beide partijen vertrouwde certificeringsautoriteit (CA). Deze CA is verantwoordelijk voor de controle van de identiteit van de houder van het certificaat en voor de afgifte van certificaten die worden gebruikt om een organisatie te identificeren en beveiligde kanalen voor datacommunicatie tussen de partijen te op te zetten.

Cryptografische sleutels worden gebruikt voor het ondertekenen en versleutelen van communicatiekanalen en gegevensbestanden. De openbare certificaten worden door de partijen digitaal uitgewisseld door middel van beveiligde kanalen en geverifieerd buiten de band. Deze procedure maakt integraal deel uit van het proces informatiebeveiligingsbeheer van de GOP.

3.3.   Lijst van functies in het kader van de koppeling

De koppeling specificeert het transmissiesysteem voor een reeks functies die de uit de overeenkomst voortvloeiende bedrijfsprocessen uitvoeren. De koppeling bevat eveneens de specificatie voor het afstemmingsproces en voor de testberichten die de uitvoering van heartbeatmonitoring mogelijk maken.

3.3.1.   Zakelijke transacties

Vanuit het bedrijfsperspectief behandelt de koppeling vier (4) soorten transactieverzoeken:

—

externe overdracht: — na de inwerkingtreding van de ETS-koppeling zijn EU- en CH-emissierechten fungibel, en dus volledig overdraagbaar tussen de partijen; — bij een overdracht via de koppeling zijn een overdragende rekening op het ene ETS en een verwervende rekening op het andere ETS betrokken; — de overdracht kan een of meer van de vier (4) soorten emissierechten omvatten: — Zwitserse algemene emissierechten (CHU); — Zwitserse luchtvaartemissierechten (CHUA); — algemene EU-emissierechten (EUA); — EU-luchtvaartemissierechten (EUAA);

—

internationale toewijzing: vliegtuigexploitanten die door het ene ETS worden geadministreerd met verplichtingen onder het andere ETS en recht hebben op kosteloze emissierechten van dat tweede ETS, ontvangen kosteloze luchtvaartemissierechten van het tweede ETS via de internationale toewijzingstransactie;

—	terugdraaiing van de internationale toewijzing: deze transactie vindt plaats in het geval dat de kosteloze toewijzing van emissierechten aan een vliegtuigexploitant door het andere ETS geheel moet worden teruggedraaid;

—	teruggave van overtollige toewijzing: vergelijkbaar met terugdraaiing, maar de toewijzing hoeft niet geheel te worden teruggedraaid, en alleen de teveel toegewezen emissierechten moeten worden teruggegeven aan het toewijzende ETS.

3.3.2.   Afstemmingsprotocol

Afstemmingen vinden pas plaats nadat de vensters voor de opname, validering en verwerking van berichten gesloten zijn.

Afstemmingen maken integraal deel uit van de beveiligings- en consistentiemaatregelen van de koppeling. De partijen moeten het exacte tijdstip van de afstemming overeenkomen alvorens een tijdschema op te stellen. Een dagelijks geplande afstemming kan plaatsvinden indien beide partijen daarmee instemmen. Na elke opname van berichten wordt echter ten minste één geplande afstemming uitgevoerd.

In elk geval kan elke partij te allen tijde handmatige afstemmingen initiëren.

Wijzigingen in de frequentie en timing van de geplande afstemming worden behandeld met inachtneming van de in het kader van de afhandeling van verzoeken van de GOP vastgestelde operationele procedures.

3.3.3.   Testbericht

Om het communicatietraject te testen, wordt gezorgd voor een testbericht. Het bericht bevat gegevens waarmee dat bericht als test wordt herkend, en wordt na ontvangst door de andere partij beantwoord.

3.4.   Normen voor webdiensten

Webdiensten zullen in de voorlopige oplossing niet worden gebruikt. Er zij echter op gewezen dat de vorm en het formaat van de XML-berichten in grote mate ongewijzigd zullen blijven. Met de toekomstige invoering van de permanente registerkoppeling moeten de webdiensten de uitwisseling van XML-berichten in real-time mogelijk maken.

3.5.   Specifieke definitie van webdiensten

Dit hoofdstuk is niet van toepassing op de voorlopige oplossing. Zoals vermeld in het vorige hoofdstuk, zullen de webdiensten alleen worden gebruikt in de toekomstige permanente registerkoppeling.

3.6.   Vereisten voor gegevensregistratie

Om te beantwoorden aan de behoefte van beide partijen aan het bijhouden van accurate en consistente informatie en te voorzien in instrumenten voor het gebruik in het afstemmingsproces om inconsistenties weg te nemen, worden door beide partijen vier (4) soorten gegevensregisters bijgehouden:

—	transactielogboeken,

—	afstemmingslogboeken,

—	berichtarchieven,

—	logboeken van interne controle.

Alle gegevens in deze logbestanden worden ten minste gedurende drie (3) maanden bewaard ten behoeve van het oplossen van problemen, en de verdere bewaring ervan voor controledoeleinden hangt af van het voor elke partij toepasselijke recht. Logbestanden ouder dan drie (3) maanden kunnen worden gearchiveerd in een beveiligde locatie in een onafhankelijk IT-systeem, op voorwaarde dat zij binnen een redelijke termijn kunnen worden opgevraagd of geconsulteerd.

Transactielogboeken

De subsystemen van het EUTL en het SSTL bevatten transactielogboeken.

De transactielogboeken bevatten een registratie van elke voorgestelde transactie die naar het andere ETS wordt verzonden. Elke registratie bevat alle gegevensvelden van de transactie en de daaropvolgende uitkomst ervan (de respons van het ontvangende ETS). In de transactielogboeken wordt eveneens een register bijgehouden voor inkomende transacties alsmede voor de naar het ETS van oorsprong gestuurde respons.

Afstemmingslogboeken

Het afstemmingslogboek bevat een registratie van elk afstemmingsbericht dat tussen de partijen wordt uitgewisseld, met inbegrip van de afstemmingsidentificatiecode, het tijdstempel en het resultaat van de afstemming: de afstemmingsstatus “Pass” of “Discrepancies”. Afstemmingsberichten maken in de voorlopige oplossing integraal deel uit van de uitgewisselde berichten.

Beide partijen registreren elk verzoek en de respons daarop in het afstemmingslogboek. Hoewel de informatie in het afstemmingslogboek tijdens de afstemming niet rechtstreeks wordt gedeeld, kan de toegang tot deze informatie noodzakelijk zijn om inconsistenties weg te nemen.

Archivering van berichten

Beide partijen moeten een kopie van de uitgewisselde (zowel verzonden als ontvangen) gegevens (de XML-bestanden) archiveren, met een vermelding of de XML-berichten in het juiste formaat waren verstuurd of niet.

Het belangrijkste doel van het archief is om in het kader van controles te kunnen bewijzen wat naar de andere partij is verzonden en wat van de andere partij is ontvangen. Daartoe moeten behalve de dossiers ook de desbetreffende certificaten worden gearchiveerd.

Deze dossiers zullen ook aanvullende informatie opleveren voor het oplossen van problemen.

Logboeken van interne controle

Deze logboeken worden door elke partij afzonderlijk gedefinieerd en gebruikt.

3.7.   Operationele vereisten

De uitwisseling van gegevens tussen beide systemen is in de voorlopige oplossing niet volledig autonoom; dit betekent dat exploitanten en procedures moeten worden ingeschakeld om de koppeling operationeel te maken.

4.   Beschikbaarheidsbepalingen

4.1.   Ontwerp voor de beschikbaarheid van de communicatie

De architectuur voor de voorlopige oplossing is een ICT-infrastructuur en software die de communicatie tussen het ETS van Zwitserland en het EU-ETS mogelijk maakt. Het waarborgen van een hoog niveau van beschikbaarheid, integriteit en vertrouwelijkheid van deze gegevensstroom is dan ook een essentieel aspect dat moet worden meegenomen bij het ontwerp van de voorlopige oplossing en de permanente registerkoppeling. Aangezien de ICT-infrastructuur, de op maat gemaakte software en de processen een integrale rol in dit project spelen, moeten alle drie de elementen in aanmerking worden genomen om een bestendig systeem te ontwerpen.

Bestendigheid van de ICT-infrastructuur

In het hoofdstuk betreffende algemene bepalingen van dit document worden de bouwblokken van de architectuur beschreven. Wat de ICT-infrastructuur betreft, wordt in de voorlopige koppeling een veerkrachtig VPN-netwerk (of gelijkwaardig netwerk) opgezet dat veilige communicatietunnels creëert waarin beveiligde berichtenuitwisseling kan plaatsvinden. Andere elementen worden geconfigureerd voor een hoge beschikbaarheidsgraad en/of maken gebruik van terugvalmechanismen.

Bestendigheid van op maat gemaakte software

De op maat gemaakte softwaremodules vergroten de bestendigheid door de communicatie met de andere partij gedurende een bepaalde periode te trachten te herstellen indien die om welke reden dan ook niet beschikbaar is.

Bestendigheid van de dienst

De gegevensuitwisseling tussen de partijen gebeurt in de voorlopige oplossing op vooraf bepaalde tijdstippen, het hele jaar door. Sommige van de stappen die vereist zijn in vooraf geplande gegevensuitwisseling vereisen handmatige tussenkomst van systeembeheerders en/of registeradministrateurs. Rekening houdend met dit aspect en met het oog op het vergroten van de beschikbaarheid en het succes van de uitwisselingen, worden de volgende maatregelen getroffen:

—	de operationele procedures voorzien in significante tijdvensters voor de uitvoering van elke stap;

—	de softwaremodules voor de voorlopige oplossing passen asynchrone communicatie toe;

—	in het kader van het automatische afstemmingsproces zal aan beide zijden worden vastgesteld of er problemen zijn geweest bij de opname van gegevensbestanden;

—

de monitoringprocessen (ICT-infrastructuren en op maat gemaakte softwaremodules) worden in overweging genomen bij incidentbeheerprocedures en activeren deze (zoals gedefinieerd in de gemeenschappelijke operationele procedures). Deze procedures, die gericht zijn op het verkorten van de tijd die nodig is om de normale werking te herstellen na incidenten, zijn essentieel om een hoge beschikbaarheidsgraad te waarborgen.

4.2.   Initialisatie, communicatie, heractivering en testplan

Alle verschillende elementen van de architectuur van de voorlopige oplossing moeten een reeks individuele en collectieve tests doorstaan om te bevestigen dat het platform klaar is wat de ICT-infrastructuur en het informatiesysteem betreft. Deze operationele tests zijn een verplichte voorwaarde telkens wanneer het platform de voorlopige oplossing doet overgaan van de status “buiten werking” naar de operationele status.

De activering van de operationele status van de koppeling vereist vervolgens de succesvolle uitvoering van een vooraf bepaald testplan. Dit bevestigt dat elk register eerst een reeks interne tests heeft uitgevoerd, gevolgd door een validering van de eind-tot-eindconnectiviteit voordat een begin wordt gemaakt met de indiening van productietransacties tussen beide partijen.

In het testplan moeten de algemene teststrategie en details over de testinfrastructuur worden vermeld. Voor elk element in elk testblok moet het testplan met name het volgende omvatten:

—	de testcriteria en -instrumenten;

—	de rollen die betrokken moeten zijn bij de uitvoering van de test;

—	de verwachte resultaten (positief en negatief);

—	het testschema;

—	de voorschriften voor het registreren van de testresultaten;

—	documentatie over het oplossen van problemen;

—	bepalingen inzake escalatie.

Als proces kunnen de activeringstests voor de operationele status worden opgesplitst in vier (4) conceptuele blokken of fasen:

4.2.1.   Interne tests van de ICT-infrastructuur

Deze tests moeten door beide partijen aan elk einde afzonderlijk worden uitgevoerd en/of gecontroleerd.

Elk onderdeel van de ICT-infrastructuur aan elk einde wordt afzonderlijk getest. Dit omvat elk afzonderlijk onderdeel van de infrastructuur. Deze tests kunnen automatisch of manueel worden uitgevoerd, maar controleren of elk element van de infrastructuur operationeel is.

4.2.2.   Communicatietests

Deze tests worden afzonderlijk door een van de partijen in gang gezet en voor de afsluiting van de tests is de medewerking van de andere partij vereist.

Zodra individuele elementen operationeel zijn, moeten de communicatiekanalen tussen de beide registers worden getest. Daartoe controleert elke partij of de toegang tot het internet werkt, de VPN-tunnels (of een gelijkwaardig beveiligd transportnetwerk) zijn opgezet, en de IP-verbinding tussen de partijen werkt. De bereikbaarheid van de lokale infrastructuurelementen en die op afstand, alsmede de IP-connectiviteit, moeten aan het andere einde worden bevestigd.

4.2.3.   Volledige systeemtest (eind-tot-eind)

Deze tests moeten aan beide einden worden uitgevoerd en de resultaten moeten met de andere partij worden gedeeld.

Zodra de communicatiekanalen en elk afzonderlijk onderdeel van beide registers zijn getest, moet elk einde een reeks gesimuleerde transacties en afstemming daarvan voorbereiden die representatief zijn voor alle functies die binnen de koppeling moeten worden uitgevoerd.

4.2.4.   Beveiligingstests

Deze tests moeten worden uitgevoerd en/of worden geactiveerd door beide partijen aan elk einde en zoals beschreven in hoofdstukken 5.4 (“Richtsnoeren voor het testen van de beveiliging”) en 5.5 (“Bepalingen inzake risicobeoordeling”).

Pas nadat elk van de vier fasen/blokken met voorspelbare resultaten zijn voltooid, kan aan de voorlopige koppeling de operationele status worden toegekend.

Testmiddelen

Elke partij hanteert specifieke testmiddelen (specifieke ICT-infrastructuursoftware en -hardware) en ontwikkelt testfuncties in hun respectieve systemen ter ondersteuning van de handmatige en doorlopende validatie van het platform. Handmatige individuele of coöperatieve testprocedures kunnen te allen tijde door registeradministrateurs worden uitgevoerd. Activering van de operationele status is van nature een handmatig proces.

Er is eveneens voor gezorgd dat het platform op gezette tijden automatische controles uitvoert. Deze controles zijn erop gericht de beschikbaarheid van het platform te vergroten door potentiële problemen met de infrastructuur of software in een vroeg stadium op te sporen. Dit platformmonitoringplan bestaat uit twee elementen:

—	toezicht op ICT-infrastructuren: aan beide einden wordt de infrastructuur gemonitord door de aanbieders van de ICT-diensten. De automatische tests hebben betrekking op de verschillende infrastructuurelementen en de beschikbaarheid van de communicatiekanalen;

—

monitoring van de toepassing: bij de softwaremodules van de voorlopige koppeling wordt het communicatiesysteem gemonitord op het niveau van de applicatie (manueel en/of met regelmatige tussenpozen), waarbij de eind-tot-eindbeschikbaarheid van de koppeling wordt getest door een deel van de transacties over de verbinding te simuleren.

4.3.   Acceptatie-/testomgevingen

De architectuur van het EU-register en het Zwitserse register bestaat uit de volgende drie omgevingen:

—	productie (PROD): deze omgeving bevat de daadwerkelijke gegevens en verwerkt daadwerkelijke transacties;

—	acceptatie (ACC): deze omgeving bevat niet-echte of geanonimiseerde, representatieve gegevens. Het is de omgeving waar systeembeheerders van beide partijen nieuwe releases valideren;

—	test (TEST): deze omgeving bevat niet-echte of geanonimiseerde, representatieve gegevens. Deze omgeving is beperkt tot registeradministrateurs en is bedoeld voor het uitvoeren van integratietests door beide partijen.

Met uitzondering van het VPN (of een gelijkwaardig netwerk) zijn de drie omgevingen volledig onafhankelijk van elkaar, dat wil zeggen dat hardware, software, databanken, virtuele omgevingen, IP-adressen en poorten onafhankelijk van elkaar worden opgezet en functioneren.

Wat de indeling van het VPN betreft, wordt dit in twee verschillende omgevingen opgezet, een voor PROD en een andere, onafhankelijke voor ACC en TEST.

5.   Bepalingen inzake vertrouwelijkheid en integriteit

Beveiligingsmechanismen en -procedures vereisen een methode met twee personen (vierogenprincipe) voor verrichtingen die plaatsvinden in de koppeling tussen het EU-register en het Zwitserse register. De methode met twee personen is overal waar dat nodig is van toepassing. Zij is echter mogelijk niet op alle stappen die door registeradministrateurs worden ondernomen van toepassing.

De beveiligingseisen worden in overweging genomen en behandeld in het beveiligingsbeheerplan, dat ook processen omvat die verband houden met de behandeling van beveiligingsincidenten als gevolg van een eventuele inbreuk op de beveiliging. Het operationele deel van deze processen wordt beschreven in de GOP.

5.1.   Infrastructuur voor beveiligingstests

Elke partij verbindt zich ertoe een beveiligingstestinfrastructuur op te zetten (door gebruik te maken van de gemeenschappelijke reeks van software en hardware die wordt gebruikt bij de opsporing van kwetsbaarheden in de ontwikkelings- en operationele fase):

—	die gescheiden is van de productieomgeving;

—	waar de beveiliging wordt geanalyseerd door een team dat onafhankelijk is van de ontwikkeling en de werking van het systeem.

Elke partij verbindt zich ertoe zowel statische als dynamische analyses uit te voeren.

In het geval van een dynamische analyse (zoals penetratietests) verbinden beide partijen zich ertoe de beoordelingen te beperken tot de test- en acceptatieomgevingen (zoals gedefinieerd in hoofdstuk 4.3 (“Acceptatie-/testomgevingen”)). Uitzonderingen op dit beleid moeten door beide partijen worden goedgekeurd.

Alvorens in de productieomgeving te worden uitgerold, moet de beveiliging van elke softwaremodule van de koppeling (zoals gedefinieerd in hoofdstuk 3.1 (“Architectuur van de communicatieverbinding”)) worden getest.

De testinfrastructuur moet zowel op het niveau van het netwerk als op het niveau van de infrastructuur gescheiden zijn van de productie-infrastructuur. De beveiligingstests die nodig zijn om na te gaan of aan de beveiligingsvoorschriften is voldaan, worden uitgevoerd binnen de testinfrastructuur.

5.2.   Onderbreking van de koppeling en bepalingen betreffende heractivering

Indien het vermoeden bestaat dat de veiligheid van het Zwitserse register, het SSTL, het EU-register of het EUTL in het gedrang is gekomen, moet de ene partij de andere daarvan onverwijld in kennis stellen en de koppeling tussen het SSTL en het EUTL onderbreken.

De procedures voor het delen van informatie, voor het nemen van een besluit tot onderbreking en voor het nemen van een besluit tot heractivering, maken deel uit van het proces voor de afhandeling van verzoeken van de GOP.

Onderbreking

Onderbreking van de registerkoppeling overeenkomstig bijlage II bij de overeenkomst kan plaatsvinden om:

—	administratieve redenen (bijvoorbeeld onderhoud), en dus gepland;

—	veiligheidsoverwegingen (of storingen in de IT-infrastructuur), en dus niet gepland.

In noodgevallen stelt de ene partij de andere in kennis en onderbreekt zij de registerkoppeling unilateraal.

Indien wordt besloten de registerkoppeling te onderbreken, zorgt elke partij ervoor dat de koppeling op netwerkniveau wordt onderbroken (door inkomende en uitgaande verbindingen geheel of gedeeltelijk te blokkeren).

Het besluit tot al dan niet geplande onderbreking van de registerkoppeling wordt genomen volgens de procedure voor wijzigingsbeheer of beveiligingsincidentbeheer van de GOP.

Heractivering van de communicatie

Een besluit tot heractivering van de registerkoppeling zal worden genomen op de wijze zoals uiteengezet in de GOP en in geen geval voordat de procedures voor het testen van de beveiliging met succes zijn afgerond, zoals beschreven in hoofdstukken 5.4 (“Richtsnoeren voor veiligheidstests”) en 4.2 (“Initialisatie, communicatie, heractivering, en testplan”).

5.3.   Bepalingen inzake beveiligingsinbreuk

Een beveiligingsinbreuk wordt beschouwd als een beveiligingsincident met gevolgen voor de vertrouwelijkheid en integriteit van alle gevoelige informatie en/of de beschikbaarheid van het systeem dat die informatie verwerkt.

Gevoelige informatie wordt in de lijst van gevoelige informatie vermeld en kan in het systeem of in enig gerelateerd onderdeel van het systeem worden verwerkt.

Informatie die rechtstreeks verband houdt met de beveiligingsinbreuk wordt als gevoelig beschouwd, met de vermelding “ETS CRITICAL” aangemerkt en behandeld volgens de desbetreffende instructies, tenzij anders is bepaald.

Elke beveiligingsinbreuk wordt behandeld volgens het hoofdstuk betreffende beveiligingsincidentbeheer van de GOP.

5.4.   Richtsnoeren voor het testen van de beveiliging

5.4.1.   Software

Beveiligingstests, in voorkomend geval met inbegrip van penetratietests, worden ten minste op alle nieuwe belangrijke softwarereleases uitgevoerd volgens de in de LTS vastgestelde beveiligingseisen om de beveiliging van de verbinding en de daaraan verbonden risico’s te beoordelen.

Indien in de afgelopen twaalf maanden geen belangrijke release is uitgekomen, wordt een beveiligingstest verricht op het huidige systeem, rekening houdend met de ontwikkelingen in de cyberdreiging die zich in de voorgaande twaalf maanden hebben voorgedaan.

De beveiligingstest van de registerkoppeling wordt uitgevoerd in de acceptatieomgeving en, indien vereist, in de productieomgeving en met de coördinatie en wederzijdse toestemming van beide partijen.

Bij het testen van webapplicaties worden internationale open normen, zoals die welke zijn ontwikkeld door het Open Web Application Security Project (OWASP), in acht genomen.

5.4.2.   Infrastructuur

De infrastructuur ter ondersteuning van het productiesysteem wordt regelmatig (ten minste eens per maand) gecontroleerd op kwetsbaarheden, en vastgestelde kwetsbaarheden worden hersteld. De tests worden uitgevoerd volgens de in hoofdstuk 5.4.1 beschreven methode, waarbij gebruik wordt gemaakt van een actueel register van kwetsbaarheden.

5.5.   Bepalingen inzake risicobeoordeling

Indien de penetratietest van toepassing is, moet deze worden opgenomen in de beveiligingstest.

Elke partij kan voor de uitvoering van de beveiligingstests een beroep doen op een gespecialiseerde externe onderneming, mits deze onderneming:

—	beschikt over de vaardigheden en ervaring op het gebied van dergelijke beveiligingstests;

—	niet rechtstreeks is verbonden aan de ontwikkelaar en/of zijn contractant, niet betrokken is bij de ontwikkeling van de software van de koppeling en geen onderaannemer is van de ontwikkelaar;

—	een geheimhoudingsovereenkomst heeft ondertekend om de resultaten vertrouwelijk te houden en deze te behandelen op het niveau “ETS CRITICAL”, overeenkomstig de instructies voor behandeling.