Decizia 1873/24-iun-2024 privind poziţia care urmează să fie adoptată în numele Uniunii Europene în cadrul comitetului mixt constituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră, în ceea ce priveşte modificarea anexei II la acord şi a procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii

Acte UE

Jurnalul Oficial seria L

În vigoare
Versiune de la: 5 Iulie 2024
Decizia 1873/24-iun-2024 privind poziţia care urmează să fie adoptată în numele Uniunii Europene în cadrul comitetului mixt constituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră, în ceea ce priveşte modificarea anexei II la acord şi a procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii
Dată act: 24-iun-2024
Emitent: Consiliul Uniunii Europene
(Text cu relevanţă pentru SEE)
CONSILIUL UNIUNII EUROPENE,
având în vedere Tratatul privind funcţionarea Uniunii Europene, în special articolul 192 alineatul (1), coroborat cu articolul 218 alineatul (9),
având în vedere propunerea Comisiei Europene,
întrucât:
(1)Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră (1) (denumit în continuare "acordul") a fost semnat la 23 noiembrie 2017 în conformitate cu Decizia (UE) 2017/2240 a Consiliului (2).
(1)JO L 322, 7.12.2017, p. 3.
(2)Decizia (UE) 2017/2240 a Consiliului din 10 noiembrie 2017 privind semnarea, în numele Uniunii, şi aplicarea cu titlu provizoriu a Acordului dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră (JO L 322, 7.12.2017, p. 1).
(2)Acordul a fost încheiat prin Decizia (UE) 2018/219 a Consiliului (3) şi a intrat în vigoare la 1 ianuarie 2020.
(3)Decizia (UE) 2018/219 a Consiliului din 23 ianuarie 2018 privind încheierea Acordului dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră (JO L 43, 16.2.2018, p. 1).
(3)În temeiul articolului 12 alineatul (3) din acord, comitetul mixt poate adopta decizii care, de la data intrării lor în vigoare, sunt obligatorii pentru părţi.
(4)Articolul 13 alineatul (2) din acord prevede posibilitatea modificării de către Comitetul mixt a anexelor la acord.
(5)Articolul 3 alineatele (6) şi (7) prevăd că procedurile comune de funcţionare şi standardele tehnice de creare a legăturii intră în vigoare atunci când sunt adoptate printr-o decizie a comitetului mixt. Prin Deciziile sale nr. 1/2020 (4) şi nr. 2/2020 (5), comitetul mixt a adoptat procedurile comune de funcţionare şi, respectiv, standardele tehnice de creare a legăturii.
(4)Decizia nr. 1/2020 a Comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 5 noiembrie 2020 în ceea ce priveşte adoptarea unor procedee comune de funcţionare [2021/1033] (JO L 226, 25.6.2021, p. 2).
(5)Decizia nr. 2/2020 a comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 5 noiembrie 2020 privind modificarea anexelor I şi II la acord şi adoptarea standardelor tehnice de creare a legăturii (LTS) [2021/1034] (JO L 226, 25.6.2021, p. 16).
(6)Este oportun să se modifice anexa II la acord pentru a reflecta evoluţia legăturii dintre registre între schema UE de comercializare a certificatelor de emisii şi schema Elveţiei de comercializare a certificatelor de emisii şi pentru a raţionaliza dispoziţiile anexei II în lumina evoluţiilor tehnologice. Pentru a asigura coerenţa procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii cu anexa II, documentele respective ar trebui să fie de asemenea modificate.
(7)În cadrul celei de a şaptea reuniuni a comitetului mixt, sau mai devreme, prin intermediul procedurii scrise în temeiul articolului 8 alineatul (4) din Regulamentul de procedură al comitetului mixt (6), acesta adoptă o decizie privind modificarea anexei II la acord şi modificarea procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii.
(6)Decizia nr. 1/2019 a comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 25 ianuarie 2019 privind adoptarea regulamentului său de procedură şi Decizia (UE) 2018/1279 a Consiliului din 18 septembrie 2018 privind poziţia care urmează să fie adoptată în numele Uniunii Europene în cadrul comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră în ceea ce priveşte adoptarea regulamentului său de procedură (JO L 239, 24.9.2018, p. 8).
(8)Este oportun să se stabilească poziţia care urmează să fie adoptată în numele Uniunii în cadrul comitetului mixt, în ceea ce priveşte modificarea anexei II la acord şi modificarea procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii, întrucât decizia va avea caracter obligatoriu pentru Uniune.
(9)Prin urmare, poziţia Uniunii în cadrul comitetului mixt ar trebui să se bazeze pe proiectul de decizie ataşat,
ADOPTĂ PREZENTA DECIZIE:
-****-
Art. 1
Poziţia care urmează să fie adoptată în numele Uniunii în cadrul celei de-a şaptea reuniuni a comitetului mixt, sau mai devreme, prin intermediul procedurii scrise în temeiul articolului 8 alineatul (4) din Regulamentul de procedură al comitetului mixt, se bazează pe proiectul de decizie a comitetului mixt ataşat la prezenta decizie.
Art. 2
Prezenta decizie intră în vigoare la data adoptării.
-****-
Adoptată la Luxemburg, 24 iunie 2024.

Pentru Consiliu

Preşedintele

D. CLARINVAL

ANEXA I:DECIZIE nr. 1 A COMITETULUI MIXT INSTITUIT PRIN ACORDUL DINTRE UNIUNEA EUROPEANĂ ŞI CONFEDERAŢIA ELVEŢIANĂ PENTRU CREAREA UNEI LEGĂTURI ÎNTRE RESPECTIVELE LOR SCHEME DE COMERCIALIZARE A CERTIFICATELOR DE EMISII DE GAZE CU EFECT DE SERĂ din... privind modificarea anexei II la acord şi a procedeelor comune de funcţionare şi a standardelor tehnice de creare a legăturii
COMITETUL MIXT,
având în vedere Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră (1) (denumit în continuare "acordul"), în special articolul 9 şi articolul 13 alineatul (2),
(1)JO L 322, 7.12.2017, p. 3.
Întrucât:
(1)Decizia nr. 2/2019 a Comitetului mixt (2) a prevăzut o soluţie provizorie pentru operaţionalizarea legăturii dintre EU ETS şi ETS-ul Elveţiei.
(2)Decizia nr. 2/2019 a Comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 5 decembrie 2019 de modificare a anexelor I şi II la Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră [2020/1359] (JO L 314, 29.9.2020, p. 68).
(2)În cadrul celei de a treia reuniuni, Comitetul mixt a convenit asupra necesităţii de a analiza raportul cost-eficacitate al unei legături permanente între registrul Uniunii şi registrul elveţian.
(3)În cadrul celei de a cincea reuniuni, Comitetul mixt a convenit asupra raportului prezentat de grupul de lucru constituit prin Deciziile 1/2020 (3) şi 2/2020 (4) ale Comitetului mixt. În raportul respectiv grupul de lucru a analizat şi a recomandat o abordare pentru punerea în aplicare a legăturii permanente dintre registrul Uniunii şi registrul elveţian.
(3)Decizia nr. 1/2020 a Comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 5 noiembrie 2020 în ceea ce priveşte adoptarea unor procedee comune de funcţionare [2021/1033] (JO L 226, 25.6.2021, p. 2).
(4)Decizia nr. 2/2020 a comitetului mixt instituit prin Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 5 noiembrie 2020 privind modificarea anexelor I şi II la acord şi adoptarea standardelor tehnice de creare a legăturii (LTS) [2021/1034] (JO L 226, 25.6.2021, p. 16).
(4)Pentru a reflecta cerinţele tehnice ale legăturii permanente dintre registrul Uniunii şi registrul elveţian, precum şi pentru a raţionaliza dispoziţiile anexei II la acord în lumina evoluţiilor tehnologice, anexa II la acord ar trebui modificată.
(5)Pentru a asigura coerenţa procedeelor comune de funcţionare şi a standardelor tehnice de creare a unei legături cu anexa II la acord, documentele respective ar trebui, de asemenea, modificate,
ADOPTĂ PREZENTA DECIZIE:
Art. 1
(1)Anexa II la acord se înlocuieşte cu textul prevăzut în anexa I la prezenta decizie.
(2)Procedeele comune de funcţionare menţionate la articolul 3 alineatul (6) din acord sunt prevăzute în anexa II la prezenta decizie. Acestea înlocuiesc procedeele comune de funcţionare prevăzute în anexa la Decizia nr. 1/2020.
(3)Standardele tehnice de creare a legăturii menţionate la articolul 3 alineatul (7) din acord sunt stabilite în anexa III la prezenta decizie. Acestea înlocuiesc standardele tehnice de creare a legăturii prevăzute în anexa la Decizia nr. 2/2020.
Art. 2
Prezenta decizie intră în vigoare la data adoptării.
Adoptată la..., la...

Pentru Comitetul mixt

Secretarul pentru Uniunea Europeană

Preşedintele

Secretarul pentru Elveţia

ANEXA I1:
"- ANEXA II: STANDARDE TEHNICE DE CREARE A LEGĂTURII
Pentru a operaţionaliza legătura dintre EU ETS şi ETS-ul Elveţiei, în 2020 a fost pusă în aplicare o soluţie provizorie. Începând din 2023, legătura dintre cele două sisteme de comercializare a certificatelor de emisii se va transforma treptat într-o legătură permanentă între registre, a cărei implementare este preconizată a avea loc cel târziu în 2024, care va permite funcţionarea pieţelor legate în ceea ce priveşte beneficiile oferite de lichiditatea pieţei şi de executarea tranzacţiilor între cele două sisteme conectate într-un mod echivalent cu o piaţă formată din două sisteme şi care va permite participanţilor la piaţă să acţioneze ca şi cum ar fi pe o singură piaţă, sub rezerva unor dispoziţii de reglementare individuale ale părţilor.
Standardele tehnice de creare a legăturii (LTS) specifică:
- arhitectura legăturii de comunicare;
- comunicările dintre SSTL şi EUTL;
- securitatea transferului de date;
- lista funcţiilor (tranzacţii, reconciliere etc.);
- definiţia nivelului de transport;
- cerinţele referitoare la arhivarea datelor;
- aranjamentele operaţionale (serviciul de asistenţă, sprijinul);
- planul de activare a comunicării şi procedura de testare;
- procedura de testare a securităţii.
LTS precizează că administratorii trebuie să ia toate măsurile rezonabile pentru a se asigura că SSTL, EUTL şi legătura sunt operaţionale 24 de ore pe zi şi 7 zile pe săptămână şi că orice întreruperi ale funcţionării SSTL, a EUTL şi a legăturii sunt menţinute la un nivel minim.
LTS stabilesc cerinţe de securitate suplimentare pentru registrul elveţian, SSTL, registrul Uniunii şi EUTL şi sunt consemnate într-un «plan de gestionare a securităţii». LTS precizează în special că:
- dacă există suspiciunea că securitatea registrului elveţian, a SSTL, a registrului Uniunii sau a EUTL a fost compromisă, părţile se informează reciproc imediat şi suspendă legătura dintre SSTL şi EUTL;
- în caz de încălcare a securităţii, părţile se angajează să facă imediat schimb de informaţii. În măsura în care se cunosc detaliile tehnice, administratorul registrului elveţian şi administratorul central al Uniunii îşi transmit, în termen de 24 de ore după ce un incident de securitate este identificat drept o încălcare a securităţii, un raport în care este descris incidentul (data, cauza, impactul, soluţiile de remediere).
Procedura de testare a securităţii prevăzută în LTS se aplică înainte de stabilirea legăturii de comunicare dintre SSTL şi EUTL şi ori de câte ori este necesară o nouă versiune sau ediţie a SSTL sau a EUTL.
LTS prevăd două medii de testare în plus faţă de mediul de producţie: un mediu de testare pentru dezvoltator şi un mediu de acceptare.
Părţile prezintă dovezi, prin intermediul administratorului registrului elveţian şi al administratorului central al Uniunii, că a fost efectuată în precedentele 12 luni o evaluare independentă a securităţii sistemelor lor în conformitate cu cerinţele de securitate prevăzute în LTS. Toate noile ediţii importante de software sunt supuse, în conformitate cu cerinţele de securitate prevăzute în LTS, unor teste de securitate, în special testului de rezistenţă la intruziuni. Testul de rezistenţă la intruziuni nu se efectuează de către dezvoltatorul software-ului sau un subcontractant al acestuia."
ANEXA I2:PROCEDELE COMUNE DE FUNCŢIONARE ÎN TEMEIUL ARTICOLULUI 3 ALINEATUL (6) DIN ACORDUL DINTRE UNIUNEA EUROPEANĂ ŞI CONFEDERAŢIA ELVEŢIANĂ PENTRU CREAREA UNEI LEGĂTURI ÎNTRE RESPECTIVELE LOR SCHEME DE COMERCIALIZARE A CERTIFICATELOR DE EMISII DE GAZE CU EFECT DE SERĂ
Proceduri pentru legătura permanentă între registre
Cuprins

1.

GLOSAR

9

2.

INTRODUCERE

9

2.1.

Domeniul de aplicare

10

2.2.

Destinatari

10

3.

ABORDARE ŞI STANDARDE

10

4.

GESTIONAREA INCIDENTELOR

11

4.1.

Identificarea şi înregistrarea incidentelor

11

4.2.

Clasificarea şi asistenţa iniţială

11

4.3.

Investigarea şi diagnosticarea

12

4.4.

Rezolvarea şi restabilirea sistemului

12

4.5.

Închiderea incidentului

12

5.

GESTIONAREA PROBLEMELOR

13

5.1.

Identificarea şi înregistrarea problemelor

13

5.2.

Ierarhizarea problemelor

13

5.3.

Investigarea şi diagnosticarea problemelor

13

5.4.

Rezoluţia

13

5.5.

Închiderea problemei

13

6.

SOLUŢIONAREA CERERILOR

13

6.1.

Iniţierea cererii

13

6.2.

Înregistrarea şi analiza cererilor

14

6.3.

Aprobarea cererilor

14

6.4.

Soluţionarea cererilor

14

6.5.

Transmiterea cererilor

14

6.6.

Verificarea procesului de soluţionare a cererii

14

6.7.

Închiderea cererii

14

7.

GESTIONAREA MODIFICĂRILOR

14

7.1.

Cererea de modificare

15

7.2.

Evaluarea şi planificarea modificărilor

15

7.3.

Aprobările modificărilor

15

7.4.

Implementarea modificărilor

15

8.

GESTIONAREA VERSIUNILOR

15

8.1.

Planificarea versiunii

15

8.2.

Conceperea şi testarea pachetului de versiuni

16

8.3.

Pregătirea implementării

16

8.4.

Readucerea versiunii la starea anterioară

16

8.5.

Evaluarea şi finalizarea versiunii

16

9.

GESTIONAREA INCIDENTELOR DE SECURITATE

17

9.1.

Clasificarea incidentelor de securitate a informaţiilor

17

9.2.

Gestionarea incidentelor de securitate a informaţiilor

17

9.3.

Identificarea incidentelor de securitate

17

9.4.

Analiza incidentelor de securitate

17

9.5.

Evaluarea gravităţii incidentelor de securitate, transmiterea şi raportarea acestora

17

9.6.

Raportarea răspunsurilor la incidentele de securitate

18

9.7.

Monitorizarea, consolidarea capacităţilor şi îmbunătăţirea continuă

18

10.

MANAGEMENTUL SECURITĂŢII INFORMAŢIILOR

18

10.1.

Identificarea informaţiilor sensibile

18

10.2.

Nivelurile de sensibilitate ale activelor informaţionale

18

10.3.

Desemnarea proprietarului activelor informaţionale

18

10.4.

Înregistrarea informaţiilor sensibile

19

10.5.

Gestionarea informaţiilor sensibile

19

10.6.

Gestionarea accesului

19

10.7.

Gestionarea certificatelor/cheilor

19

1.GLOSAR
Tabelul 1-1 Acronime şi definiţii

Acronim/termen

Definiţie

Autoritate de certificare (CA)

Entitatea care emite certificate digitale

CH

Confederaţia Elveţiană

ETS

Schema de comercializare a certificatelor de emisii

UE

Uniunea Europeană

IMT

Echipa de gestionare a incidentelor

Activ informaţional

O informaţie care prezintă valoare pentru o societate sau o organizaţie

IT

Instrucţiuni de securitate pentru program/proiect

ITIL

Bibliotecă pentru infrastructura tehnologiei informaţiei

ITSM

Gestionarea serviciilor IT

LTS

Standarde tehnice de creare a legăturii

Registrul

Un sistem de contabilizare a certificatelor emise în cadrul ETS, care ţine evidenţa drepturilor de proprietate asupra certificatelor deţinute în conturile electronice.

RFC

Cererea de modificare

SIL

Evidenţa informaţiilor sensibile

SR

Cerere de servicii

Wiki

Site web care permite utilizatorilor să facă schimb de informaţii şi de cunoştinţe prin adăugarea sau adaptarea conţinutului în mod direct prin intermediul unui browser web.

2.INTRODUCERE
Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 23 noiembrie 2017 (denumit în continuare "acordul") prevede recunoaşterea reciprocă a certificatelor de emisii care pot fi utilizate pentru asigurarea conformităţii în cadrul sistemului de comercializare a certificatelor de emisii (denumit în continuare "EU ETS") sau în cadrul sistemului Elveţiei de comercializare a certificatelor de emisii (denumit în continuare "ETS-ul Elveţiei"). În vederea activării legăturii dintre EU ETS şi ETS-ul Elveţiei, se va crea o legătură directă între Registrul de tranzacţii al Uniunii Europene (EUTL) din cadrul registrului Uniunii şi Registrul suplimentar de tranzacţii al Elveţiei (SSTL) din cadrul registrului elveţian, ceea ce va permite transferul dintr-un registru în altul al certificatelor de emisii emise în cadrul oricăruia dintre ETS-uri [articolul 3 alineatul (2) din acord]. Pentru a operaţionaliza legătura dintre EU ETS şi ETS-ul Elveţiei, în 2020 a fost pusă în aplicare o soluţie provizorie. Începând din 2023, legătura dintre cele două sisteme de comercializare a certificatelor de emisii se va transforma treptat într-o legătură permanentă între registre, a cărei implementare este preconizată a avea loc cel târziu în 2024, care va permite funcţionarea pieţelor legate în ceea ce priveşte beneficiile oferite de lichiditatea pieţei şi de executarea tranzacţiilor între cele două sisteme conectate într-un mod echivalent cu o piaţă formată din două sisteme şi care va permite participanţilor la piaţă să acţioneze ca şi cum ar fi pe o singură piaţă, sub rezerva unor dispoziţii de reglementare individuale ale părţilor (Anexa II la acord).
În temeiul articolului 3 alineatul (6) din acord, administratorul registrului elveţian şi administratorul central al Uniunii stabilesc procedeele comune de funcţionare pentru aspectele tehnice sau alte aspecte care sunt necesare pentru funcţionarea legăturii, ţinând cont de priorităţile din legislaţia naţională. Procedeele comune de funcţionare elaborate de administratori produc efecte după ce sunt adoptate prin decizia comitetului mixt.
Procedeele comune de funcţionare au fost adoptate de comitetul mixt prin Decizia nr. 1/2020. Procedeele comune de funcţionare actualizate, astfel cum sunt specificate în prezentul document, vor fi adoptate prin Decizia nr. 1/2024 a comitetului mixt. În conformitate cu prezenta decizie şi cu solicitările Comitetului mixt, administratorul registrului elveţian şi administratorul central al Uniunii au elaborat şi vor actualiza orientări tehnice suplimentare pentru activarea legăturii şi pentru a garanta că acestea sunt adaptate permanent la progresul tehnic şi la noile cerinţe privind siguranţa şi securitatea legăturii şi funcţionarea efectivă şi eficientă a acesteia.
2.1.Domeniul de aplicare
Prezentul document reprezintă înţelegerea comună dintre părţile la acord cu privire la stabilirea fundamentelor procedurale ale legăturii dintre registrele EU ETS şi ETS-ul Elveţiei. Acesta prezintă cerinţele procedurale generale în ceea ce priveşte operaţiunile, însă vor fi necesare unele orientări tehnice suplimentare pentru activarea legăturii.
Pentru funcţionarea corespunzătoare, legătura va necesita specificaţii tehnice pentru operaţionalizarea în continuare a acesteia. În temeiul articolului 3 alineatul (7) din acord, aceste aspecte sunt prezentate în detaliu în documentul privind standardele tehnice de creare a legăturii (LTS), care urmează să fie adoptat separat prin decizia comitetului mixt.
Obiectivul procedeelor comune de funcţionare este de a asigura prestarea efectivă şi eficientă a serviciilor IT asociate cu funcţionarea legăturii dintre registrele EU ETS şi ETS al Elveţiei, în special în ceea ce priveşte soluţionarea cererilor de servicii, rezolvarea cazurilor de întrerupere a serviciului, remedierea problemelor, precum şi îndeplinirea sarcinilor operaţionale de rutină în conformitate cu standardele internaţionale privind gestionarea serviciilor IT.
Pentru legătura permanentă între registre, vor fi necesare doar următoarele procedee comune de funcţionare, incluse în prezentul document:
- gestionarea incidentelor;
- gestionarea problemelor;
- soluţionarea cererilor;
- gestionarea modificărilor;
- gestionarea versiunilor;
- gestionarea incidentelor de securitate;
- managementul securităţii informaţiilor.
2.2.Destinatari
Beneficiarii vizaţi ai prezentelor procedee comune de funcţionare sunt echipele de asistenţă ale registrelor din UE şi Elveţia.
3.ABORDARE ŞI STANDARDE
Următorul principiu se aplică tuturor procedeelor comune de funcţionare:
- UE şi CH convin asupra definirii procedeelor comune de funcţionare pe baza ITIL (Biblioteca pentru infrastructura tehnologiei informaţiei, versiunea 4). Practicile specificate în acest standard sunt reutilizate şi adaptate necesităţilor specifice legăturii permanente între registre;
- Comunicarea şi coordonarea necesare pentru prelucrarea procedeelor comune de funcţionare dintre cele două părţi se realizează prin intermediul serviciilor de asistenţă ale registrelor din CH şi UE. Sarcinile sunt întotdeauna atribuite în cadrul unei singure părţi.
- În cazul unui dezacord cu privire la gestionarea unui procedeu comun de funcţionare, acesta va fi analizat şi soluţionat între cele două servicii de asistenţă. În cazul în care nu se poate ajunge la niciun acord, găsirea unei soluţii comune este transmisă la nivelul următor.

Niveluri de transmitere

UE

CH

Nivelul 1

Serviciul de asistenţă UE

Serviciul de asistenţă CH

Nivelul 2

Managerul pentru operaţiuni al UE

Managerul pentru aplicaţii din cadrul registrului CH

Nivelul 3

Comitetul mixt [care poate delega această responsabilitate în temeiul articolului 12 alineatul (5) din acord]

Nivelul 4

Comitetul mixt, în cazul delegării responsabilităţii de la nivelul 3

- Fiecare parte poate stabili procedeele de funcţionare pentru propriul sistem de registre, ţinând cont de cerinţele şi interfeţele asociate cu prezentele procedee comune de funcţionare.
- Se utilizează un instrument de gestionare a serviciilor IT (ITSM) în vederea furnizării de asistenţă în ceea ce priveşte procedeele comune de funcţionare, în special gestionarea incidentelor, gestionarea problemelor şi soluţionarea cererilor, precum şi comunicarea între cele două părţi.
- În plus, este permis schimbul de informaţii prin e-mail.
- Ambele părţi se asigură că sunt respectate cerinţele privind securitatea informaţiilor, în conformitate cu Instrucţiunile de gestionare.
4.GESTIONAREA INCIDENTELOR
Obiectivul procesului de gestionare a incidentelor este de a readuce serviciile IT la un nivel normal cât mai repede posibil şi cu o perturbare minimă a activităţii în urma producerii unui incident.
În cadrul procesului de gestionare a incidentelor ar trebui, de asemenea, să se ţină o evidenţă a incidentelor în scopul raportării, care să fie integrată în alte procese pentru favorizarea unei îmbunătăţiri continue.
În general, procesul de gestionare a incidentelor cuprinde următoarele activităţi:
- identificarea şi înregistrarea incidentelor;
- clasificarea şi asistenţa iniţială;
- investigarea şi diagnosticarea;
- rezolvarea şi restabilirea sistemului;
- închiderea incidentului.
Pe parcursul ciclului de viaţă al unui incident, procesul de gestionare a incidentelor este responsabil pentru gestionarea permanentă a drepturilor de proprietate, pentru monitorizare, urmărire şi comunicare.
4.1.Identificarea şi înregistrarea incidentelor
Un incident poate fi identificat de un grup de asistenţă, prin intermediul unor instrumente de monitorizare automatizate sau de către personalul tehnic care asigură supravegherea de rutină.
Odată identificat, un incident trebuie înregistrat, fiindu-i atribuit un identificator unic care permite urmărirea şi monitorizarea corespunzătoare a acestuia. Identificatorul unic al unui incident este identificatorul atribuit în sistemul comun de tichete de către serviciul de asistenţă al părţii (fie UE, fie CH) care a semnalat incidentul şi trebuie utilizat în toate comunicările referitoare la respectivul incident.
Pentru toate incidentele, punctul de contact ar trebui să fie serviciul de asistenţă al părţii care a introdus tichetul.
4.2.Clasificarea şi asistenţa iniţială
Clasificarea incidentelor are ca scop înţelegerea şi identificarea sistemului şi/sau a serviciului afectat de un incident şi a măsurii în care este afectat acesta. Pentru a fi eficientă, clasificarea ar trebui să direcţioneze de prima dată soluţionarea incidentului către resursa corectă, pentru a accelera rezolvarea acestuia.
Faza de clasificare ar trebui să includă clasificarea şi ierarhizarea incidentului în funcţie de impactul şi de nivelul de urgenţă al acestuia, pentru a fi tratat în intervalul de timp stabilit în funcţie de priorităţi.
Dacă incidentul are un potenţial impact asupra confidenţialităţii sau integrităţii datelor sensibile şi/sau are un impact asupra disponibilităţii sistemului, este, de asemenea, declarat drept incident de securitate şi, ulterior, va fi gestionat conform procesului definit în capitolul "Gestionarea incidentelor de securitate" din prezentul document.
Dacă este posibil, serviciul de asistenţă care a introdus tichetul efectuează o diagnosticare iniţială. În acest scop, serviciul de asistenţă va analiza dacă incidentul reprezintă o eroare cunoscută. În caz afirmativ, calea de rezolvare sau soluţia alternativă este deja cunoscută şi documentată.
Dacă serviciul de asistenţă reuşeşte să rezolve incidentul, atunci va închide efectiv incidentul în această fază, întrucât scopul principal al procesului de gestionare a incidentelor a fost atins (şi anume restaurarea rapidă a serviciului pentru utilizatorul final). În caz contrar, serviciul de asistenţă va transmite incidentul grupului de rezolvare corespunzător pentru o investigare şi o diagnosticare suplimentare.
4.3.Investigarea şi diagnosticarea
Procesul de investigare şi diagnosticare a incidentelor se aplică atunci când un incident nu poate fi rezolvat de către serviciul de asistenţă în cadrul diagnosticării iniţiale şi, prin urmare, este transmis în mod corespunzător. Transmiterea incidentelor constituie o parte integrantă din procesul de investigare şi diagnosticare.
O practică comună în faza de investigare şi diagnosticare este încercarea de a recrea incidentul în condiţii controlate. Atunci când se efectuează investigarea şi diagnosticarea incidentului, este important să se înţeleagă ordinea corectă a evenimentelor care au cauzat incidentul.
Transmiterea reprezintă recunoaşterea faptului că un incident nu poate fi rezolvat la nivelul curent de asistenţă şi trebuie transmis unui grup de asistenţă de nivel superior sau celeilalte părţi. Transmiterea poate urma două căi: orizontală (funcţională) sau verticală (ierarhică).
Serviciul de asistenţă care a înregistrat şi a declanşat incidentul este responsabil pentru transmiterea acestuia către resursa corespunzătoare şi pentru urmărirea stadiului general şi atribuirea incidentului.
- Partea căreia i s-a atribuit incidentul este responsabilă pentru asigurarea efectuării în timp util a acţiunilor solicitate şi pentru furnizarea de feedbackuri propriului serviciu de asistenţă.
4.4.Rezolvarea şi restabilirea sistemului
Rezolvarea incidentului şi restabilirea sistemului se efectuează după înţelegerea în totalitate a acestuia. Găsirea unei soluţii de rezolvare a unui incident înseamnă că a fost identificată o modalitate de a remedia problema. Aplicarea soluţiei de rezolvare reprezintă faza de restabilire a sistemului.
După remedierea întreruperii serviciului de către resursele corespunzătoare, incidentul este redirecţionat către serviciul de asistenţă competent care a înregistrat incidentul şi serviciul respectiv confirmă, împreună cu iniţiatorul incidentului, că eroarea a fost remediată şi că incidentul poate fi închis. Elementele identificate în timpul procesării incidentului trebuie înregistrate pentru a fi utilizate ulterior.
Restabilirea sistemului poate fi efectuată de către personalul de asistenţă IT sau prin punerea la dispoziţia utilizatorului final a unui set de instrucţiuni care trebuie urmate.
4.5.Închiderea incidentului
Închiderea este ultima etapă a procesului de gestionare a incidentelor şi se efectuează la scurt timp după rezolvarea acestora.
Printre activităţile din lista de verificare care trebuie desfăşurate în faza de închidere, se evidenţiază următoarele:
- verificarea clasificării iniţiale care a fost atribuită incidentului;
- colectarea corespunzătoare a tuturor informaţiilor referitoare la incident;
- documentarea corespunzătoare a incidentului şi actualizarea bazei de informaţii;
- informarea corespunzătoare a fiecărei părţi interesate afectate în mod direct sau indirect de incident.
Un incident este închis în mod oficial după executarea fazei de închidere a incidentului de către serviciul de asistenţă şi după informarea în acest sens a celeilalte părţi.
Odată închis un incident, acesta nu mai este redeschis. Dacă un incident reapare într-un interval scurt de timp, incidentul iniţial nu este redeschis, ci trebuie înregistrat un nou incident.
Dacă incidentul este urmărit atât de serviciul de asistenţă al UE, cât şi de cel al CH, responsabilitatea închiderii finale a acestuia îi revine serviciului de asistenţă care a introdus tichetul.
5.GESTIONAREA PROBLEMELOR
Această procedură ar trebui urmată ori de câte ori este identificată o problemă şi se declanşează procesul de gestionare a problemelor. Procesul de gestionare a problemelor se axează pe îmbunătăţirea calităţii şi pe reducerea volumului de incidente semnalate. O problemă poate fi cauza unuia sau a mai multor incidente. Atunci când este raportat un incident, obiectivul procesului de gestionare a incidentelor este de a restabili serviciul cât mai repede posibil, ceea ce poate implica soluţii alternative. Atunci când se creează o problemă, obiectivul este de a investiga cauza principală a problemei pentru a identifica o modificare care să garanteze faptul că problema şi incidentele conexe nu vor mai apărea.
5.1.Identificarea şi înregistrarea problemelor
În funcţie de partea care a introdus tichetul, fie serviciul de asistenţă al UE, fie cel al CH va fi punctul de contact pentru aspectele legate de problema în cauză.
Identificatorul unic al unei probleme reprezintă identificatorul atribuit de echipa de gestionare a serviciilor IT (ITSM). Acesta trebuie utilizat în toate comunicările referitoare la respectiva problemă.
O problemă poate fi declanşată de un incident sau poate fi deschisă din proprie iniţiativă pentru a remedia problemele descoperite în cadrul sistemului în orice moment.
5.2.Ierarhizarea problemelor
Problemele pot fi clasificate în funcţie de gravitatea şi prioritatea acestora, în acelaşi mod ca incidentele, pentru a facilita urmărirea lor, luând în considerare impactul incidentelor asociate şi frecvenţa de apariţie a acestora.
5.3.Investigarea şi diagnosticarea problemelor
Fiecare parte poate semnala o problemă, iar serviciul de asistenţă al părţii iniţiatoare va fi responsabil pentru înregistrarea problemei, pentru atribuirea acesteia resursei corespunzătoare şi pentru monitorizarea stadiului general al problemei.
Grupul de rezolvare căruia i-a fost transmisă problema este responsabil pentru gestionarea în timp util a acesteia şi pentru comunicarea cu serviciul de asistenţă.
La cerere, ambele părţi sunt responsabile pentru asigurarea executării acţiunilor atribuite şi pentru transmiterea de feedbackuri propriului serviciu de asistenţă.
5.4.Rezoluţia
Grupul de rezolvare căruia i se atribuie problema este responsabil pentru soluţionarea acesteia şi pentru furnizarea de informaţii relevante propriului serviciu de asistenţă.
Elementele identificate în timpul procesării problemei trebuie înregistrate pentru a fi utilizate ulterior.
5.5.Închiderea problemei
O problemă este închisă oficial după soluţionarea sa prin implementarea modificării. Faza de închidere a problemei va fi executată de serviciul de asistenţă care a semnalat problema şi a informat în acest sens serviciul de asistenţă al celeilalte părţi.
6.SOLUŢIONAREA CERERILOR
Procesul de soluţionare a cererilor reprezintă gestionarea integrală a unei cereri vizând un serviciu nou sau existent din momentul înregistrării şi aprobării acesteia şi până la închiderea sa. Cererile de servicii sunt de obicei solicitări minore, predefinite, repetabile, frecvente, aprobate în prealabil şi procedurale.
Principalele etape care trebuie parcurse sunt enumerate mai jos.
6.1.Iniţierea cererii
Informaţiile cu privire la o cerere de servicii sunt transmise către serviciul de asistenţă al UE sau al CH prin e-mail, telefon sau prin instrumentul de gestionare a serviciilor IT (ITSM) sau prin orice alt canal de comunicare convenit.
6.2.Înregistrarea şi analiza cererilor
Pentru toate cererile de servicii, punctul de contact ar trebui să fie serviciul de asistenţă al UE sau al CH, în funcţie de partea care a transmis cererea de servicii. Respectivul serviciu de asistenţă va fi responsabil pentru înregistrarea şi analizarea cererii de servicii cu diligenţa corespunzătoare.
6.3.Aprobarea cererilor
Agentul din cadrul serviciului de asistenţă al părţii care a transmis cererea de servicii verifică dacă sunt necesare aprobări din partea celeilalte părţi şi, dacă este cazul, face demersurile necesare pentru obţinerea acestora. Dacă cererea de servicii nu este aprobată, serviciul de asistenţă actualizează şi închide tichetul.
6.4.Soluţionarea cererilor
Această etapă se referă la gestionarea efectivă şi eficientă a cererilor de servicii. Trebuie să se facă distincţie între următoarele cazuri:
- soluţionarea cererii de servicii afectează doar una dintre părţi. În acest caz, respectiva parte emite ordinele de lucru şi coordonează executarea acestora;
- soluţionarea cererii de servicii afectează atât UE, cât şi CH. În acest caz, serviciile de asistenţă emit ordine de lucru în sfera lor de responsabilitate. Derularea procesului de soluţionare cererii de servicii este coordonată de ambele servicii de asistenţă. Responsabilitatea generală îi revine serviciului de asistenţă care a primit şi a iniţiat cererea de servicii.
Când cererea de servicii a fost soluţionată, stadiul acesteia trebuie modificat în "Rezolvată".
6.5.Transmiterea cererilor
Serviciul de asistenţă poate transmite cererea de servicii nesoluţionată către resursa corespunzătoare (o terţă parte), dacă este necesar.
Transmiterile sunt efectuate către părţile terţe corespunzătoare, şi anume serviciul de asistenţă al UE va trebui să apeleze la serviciul de asistenţă al CH pentru transmiterea către o terţă parte a CH şi viceversa.
Terţa parte către care a fost transmisă cererea de servicii este responsabilă pentru gestionarea în timp util a cererii de servicii şi pentru comunicarea cu serviciul de asistenţă care a transmis cererea de servicii.
Serviciul de asistenţă care a înregistrat cererea de servicii este responsabil pentru monitorizarea stadiului general şi atribuirea unei cereri de servicii.
6.6.Verificarea procesului de soluţionare a cererii
Serviciul de asistenţă responsabil supune evidenţele privind cererea de servicii unui control al calităţii final înainte de închiderea cererii. Scopul este de a se asigura că cererea de servicii este efectiv prelucrată şi că toate informaţiile necesare pentru descrierea ciclului de viaţă al cererii sunt suficient de detaliate. În plus, elementele identificate în timpul prelucrării cererii trebuie înregistrate pentru a fi utilizate ulterior.
6.7.Închiderea cererii
Dacă părţile desemnate sunt de acord cu faptul că cererea de servicii a fost soluţionată şi solicitantul consideră cazul rezolvat, stadiul cererii devine "Închisă".
O cerere de servicii este oficial închisă după ce serviciul de asistenţă care a înregistrat cererea de servicii a executat faza de închidere a acesteia şi a informat în acest sens serviciul de asistenţă al celeilalte părţi.
7.GESTIONAREA MODIFICĂRILOR
Obiectivul acestui proces de a asigura faptul că sunt utilizate metode şi proceduri standardizate pentru o gestionare eficientă şi promptă a tuturor modificărilor legate de controlul infrastructurii IT, în scopul reducerii la minimum a numărului şi a impactului oricăror incidente conexe asupra serviciului. Modificări ale infrastructurii IT pot apărea reactiv ca răspuns la probleme sau cerinţe impuse din exterior, de exemplu, modificări legislative, sau proactiv, rezultate din încercarea de a îmbunătăţi eficienţa şi eficacitatea ori pentru a permite sau a reflecta iniţiative antreprenoriale.
Procesul de gestionare a modificărilor include diferite etape care surprind fiecare detaliu cu privire la o cerere de modificare în vederea monitorizării ulterioare. Aceste procese asigură faptul că modificarea este validată şi testată înainte de a fi implementată. Procesul de gestionare a versiunilor este responsabil pentru implementarea cu succes a acestora.
7.1.Cererea de modificare
O cerere de modificare (RFC) este prezentată echipei de gestionare a modificărilor, pentru validare şi aprobare. Pentru toate cererile de modificare, punctul de contact ar trebui să fie serviciul de asistenţă al UE sau al CH, în funcţie de partea care a transmis cererea. Respectivul serviciu de asistenţă va fi responsabil pentru înregistrarea şi analizarea cererii cu diligenţa corespunzătoare.
Cererile de modificare pot fi determinate de:
- un incident care a cauzat o modificare;
- o problemă existentă care are ca rezultat o modificare;
- un utilizator final care solicită o nouă modificare;
- o modificare ca urmare a întreţinerii continue;
- o modificare legislativă.
7.2.Evaluarea şi planificarea modificărilor
Această etapă implică activităţile de evaluare şi de planificare a modificărilor. Aceasta include activităţi de ierarhizare şi de planificare pentru a reduce la minimum riscul şi impactul.
Dacă implementarea cererii de modificare afectează atât UE, cât şi CH, partea care a înregistrat cererea de modificare verifică împreună cu cealaltă parte procesul de evaluare şi de planificare a modificărilor.
7.3.Aprobările modificărilor
Orice cerere de modificare înregistrată trebuie să fie aprobată de nivelul de transmitere competent.
7.4.Implementarea modificărilor
Implementarea modificărilor este operată în cadrul procesului de gestionare a versiunilor. Echipele de gestionare a versiunilor ale ambelor părţi urmează propriile procese care implică planificarea şi testarea. Revizuirea modificărilor se efectuează după ce modificarea a fost implementată. Pentru a asigura aplicarea modificărilor conform planului, procesul de gestionare a modificărilor este revizuit şi actualizat în mod constant, dacă este necesar.
8.GESTIONAREA VERSIUNILOR
O versiune reprezintă una sau mai multe modificări ale unui serviciu IT, incluse într-un plan de lansare a versiunii, care vor trebui autorizate, pregătite, concepute, testate şi implementate în acelaşi timp. O versiune poate reprezenta remedierea unor erori, o modificare a hardware-ului sau a altor componente, modificări ale software-ului, actualizări ale versiunilor de aplicaţii, modificări ale documentaţiei şi/sau ale unor procese. Conţinutul fiecărei versiuni este gestionat, testat şi implementat ca un tot unitar.
Procesul de gestionare a versiunilor vizează planificarea, conceperea, testarea şi validarea, precum şi asigurarea capacităţii de furnizare a serviciilor concepute, care să răspundă cerinţelor părţilor interesate şi să îndeplinească obiectivele propuse. Criteriile de acceptare pentru toate modificările aduse serviciului vor fi definite şi documentate pe parcursul etapei de coordonare a procesului de concepere şi vor fi furnizate echipelor de gestionare a versiunilor.
Versiunea va consta, în mod obişnuit, dintr-o serie de soluţionări de probleme şi de îmbunătăţiri aduse unui serviciu. Aceasta conţine software-ul nou sau modificat necesar şi orice hardware nou sau modificat necesar pentru implementarea modificărilor aprobate.
8.1.Planificarea versiunii
Prima etapă a procesului include alocarea modificărilor autorizate pachetelor de versiuni şi definirea domeniului de aplicare şi a conţinutului versiunilor. Pe baza acestor informaţii, în cadrul subprocesului de planificare a versiunilor se elaborează un calendar pentru conceperea, testarea şi implementarea versiunii.
În cadrul planificării ar trebui definite următoarele:
- domeniul de aplicare şi conţinutul versiunii;
- evaluarea riscurilor şi profilul de risc al versiunii;
- clienţii/utilizatorii afectaţi de versiune;
- echipa responsabilă pentru versiune;
- strategia de livrare şi de implementare;
- resursele alocate pentru versiune şi pentru implementarea acesteia.
Ambele părţi se informează reciproc cu privire la perioadele de planificare şi de întreţinere a versiunii. Dacă o versiune afectează atât UE, cât şi CH, acestea coordonează etapa de planificare şi definesc o perioadă comună pentru întreţinere.
8.2.Conceperea şi testarea pachetului de versiuni
Etapa de concepere şi de testare a procesului de gestionare a versiunilor stabileşte abordarea privind executarea versiunii sau a pachetului de versiuni şi menţinerea mediilor controlate înainte de modificarea producţiei, precum şi testarea tuturor modificărilor din toate mediile lansate.
Dacă o versiune afectează atât UE, cât şi CH, acestea coordonează planurile de livrare şi testele. Acestea includ următoarele aspecte:
- cum şi când vor fi livrate versiunile şi componentele serviciilor;
- care sunt timpii de livrare obişnuiţi; ce se întâmplă în cazul unei întârzieri;
- modul de monitorizare a progresului livrării şi de obţinere a confirmării;
- indicatori pentru monitorizarea şi stabilirea gradului de reuşită a efortului de implementare a versiunii;
- cazurile comune de testare a funcţionalităţilor şi a modificărilor relevante.
La finalul acestui subproces, toate componentele necesare ale versiunii sunt pregătite pentru faza de implementare concretă.
8.3.Pregătirea implementării
Subprocesul de pregătire asigură faptul că planurile de comunicare sunt corect definite, că notificările pot fi trimise tuturor părţilor interesate şi utilizatorilor finali afectaţi şi că versiunea este integrată în procesul de gestionare a modificărilor pentru a asigura faptul că toate modificările sunt efectuate într-un mod controlat şi sunt aprobate de forurile competente.
Dacă o versiune afectează atât UE, cât şi CH, acestea coordonează următoarele activităţi:
- înregistrarea cererii de modificare pentru programarea şi pregătirea implementării în mediul de producţie;
- crearea unui plan de implementare;
- abordarea revenirii la starea anterioară, astfel încât, în cazul unei probleme legate de implementare, să se poată reveni la starea anterioară;
- transmiterea de notificări tuturor părţilor relevante;
- solicitarea aprobării pentru implementarea versiunii de la nivelul de transmitere relevant.
8.4.Readucerea versiunii la starea anterioară
În cazul unei implementări nereuşite sau în cazul în care, pe parcursul testării, s-a constatat că implementarea a fost nereuşită sau nu a îndeplinit criteriile de acceptare/calitate convenite, echipele de gestionare a versiunii ale ambelor părţi vor trebui să readucă versiunea la starea anterioară. Toate părţile interesate relevante vor trebui informate, inclusiv utilizatorii finali afectaţi/vizaţi. În aşteptarea aprobării, procesul poate reporni în oricare dintre etapele anterioare.
8.5.Evaluarea şi finalizarea versiunii
În evaluarea implementării unei versiuni ar trebui incluse următoarele activităţi:
- înregistrarea feedbackurilor privind gradul de satisfacţie a clienţilor, a utilizatorilor şi legat de prestarea serviciilor în ceea ce priveşte implementarea versiunii (colectarea feedbackurilor şi luarea în considerare a acestora pentru îmbunătăţirea continuă a serviciului);
- analizarea tuturor criteriilor de calitate care nu au fost îndeplinite;
- verificarea că toate acţiunile, corecţiile şi modificările necesare au fost duse la bun sfârşit;
- asigurarea faptului că, la finalul implementării, nu există probleme legate de capabilităţi, resurse, capacitate sau performanţă;
- verificarea că orice problemă, eroare şi soluţie alternativă cunoscută este documentată şi acceptată de către client, utilizatorii finali, echipa de asistenţă operaţională şi de către alte părţi afectate;
- monitorizarea incidentelor şi a problemelor cauzate de implementare (asigurarea din timp a asistenţei necesare echipelor operaţionale în cazul în care versiunea a generat o creştere a volumului de lucru);
- actualizarea documentaţiei de asistenţă (şi anume, a documentelor cu informaţii tehnice);
- încredinţarea în mod oficial a implementării versiunii echipelor operaţionale din cadrul serviciilor;
- documentarea lecţiilor învăţate;
- preluarea documentului de sinteză privind versiunea de la echipele de punere în aplicare;
- închiderea oficială a implementării versiunii după verificarea înregistrării cererii de modificare.
9.GESTIONAREA INCIDENTELOR DE SECURITATE
Gestionarea incidentelor de securitate este un proces de gestionare a incidentelor de securitate pentru a permite comunicarea incidentelor părţilor interesate potenţial afectate, evaluarea şi ierarhizarea incidentelor şi răspunsul la incidente în vederea soluţionării oricărei încălcări reale, suspectate sau potenţiale a confidenţialităţii, a disponibilităţii sau a integrităţii activelor informaţionale sensibile.
9.1.Clasificarea incidentelor de securitate a informaţiilor
Toate incidentele care afectează legătura dintre registrul Uniunii şi registrul elveţian sunt analizate pentru a stabili o posibilă încălcare a confidenţialităţii, a integrităţii sau a disponibilităţii oricărei informaţii sensibile înregistrate în Evidenţa informaţiilor sensibile (SIL).
În acest caz, incidentul este caracterizat ca incident de securitate a informaţiilor, este înregistrat imediat în instrumentul de gestionare a serviciilor IT (ITSM) şi gestionat ca atare.
9.2.Gestionarea incidentelor de securitate a informaţiilor
Incidentele de securitate se află în responsabilitatea celui de al treilea nivel de transmitere, iar de rezolvarea acestora se va ocupa o echipă specială de gestionare a incidentelor (IMT).
IMT este responsabilă cu:
- efectuarea unei analize iniţiale, clasificarea şi evaluarea gradului de gravitate a incidentului;
- coordonarea acţiunilor între toate părţile interesate, inclusiv documentarea completă a analizei incidentului, a deciziilor luate pentru a rezolva incidentul şi a eventualelor puncte slabe identificate;
- în funcţie de gravitatea incidentului de securitate, transmiterea incidentului în timp util către nivelul corespunzător spre informare şi/sau pentru luarea unei decizii.
În cadrul procesului de management al securităţii informaţiilor, toate informaţiile referitoare la incidente sunt clasificate la cel mai înalt nivel de sensibilitate a informaţiilor, dar în orice caz nu la un nivel mai mic decât nivelul SENSITIVE: ETS.
În cazul unei investigări în curs şi/sau al unui punct slab care ar putea fi exploatat şi până la remedierea acestuia, informaţiile sunt clasificate drept SPECIAL HANDLING: ETS Critical.
9.3.Identificarea incidentelor de securitate
În funcţie de tipul de eveniment de securitate, responsabilul cu securitatea informaţiilor stabileşte organizaţiile competente care trebuie implicate şi care vor face parte din echipa de gestionare a incidentelor.
9.4.Analiza incidentelor de securitate
IMT asigură legătura cu toate organizaţiile implicate şi, după caz, cu membrii relevanţi ai echipelor acestora în vederea analizării incidentului. În cadrul analizei, se identifică amploarea pierderii confidenţialităţii, integrităţii sau disponibilităţii unui activ şi se evaluează consecinţele pentru toate organizaţiile afectate. În continuare, sunt definite măsurile iniţiale şi subsecvente pentru rezolvarea incidentului şi gestionarea impactului acestuia, inclusiv a impactului acestor măsuri asupra resurselor.
9.5.Evaluarea gravităţii incidentelor de securitate, transmiterea şi raportarea acestora
IMT evaluează gravitatea fiecărui incident de securitate nou după încadrarea acestuia ca incident de securitate şi ia imediat măsurile necesare în funcţie de gravitatea acestuia.
9.6.Raportarea răspunsurilor la incidentele de securitate
IMT include în raportul de răspuns la incidentele de securitate a informaţiilor rezultatele privind izolarea incidentului şi restabilirea sistemului. Raportul este transmis până la nivelul al treilea de transmitere prin intermediul unui e-mail securizat sau prin intermediul altor mijloace de comunicare securizate, acceptate de ambele părţi.
- Partea responsabilă analizează rezultatele privind izolarea incidentului şi restabilirea sistemului şi:
- reconectează registrul în cazul deconectării prealabile;
- transmite echipelor registrelor informări cu privire la incident;
- închide incidentul.
În raportul privind incidentele de securitate a informaţiilor, IMT ar trebui să includă - într-o manieră securizată - detalii relevante pentru a asigura înregistrarea coerentă şi comunicarea şi pentru a permite luarea unor măsuri prompte şi adecvate pentru izolarea incidentului. După finalizarea acestuia, IMT transmite în timp util raportul final privind incidentul de securitate a informaţiilor.
9.7.Monitorizarea, consolidarea capacităţilor şi îmbunătăţirea continuă
IMT va furniza rapoarte pentru toate incidentele de securitate până la nivelul al treilea de transmitere. Rapoartele vor fi utilizate la acest nivel de transmitere pentru a stabili următoarele:
- punctele slabe în ceea ce priveşte controalele de securitate şi/sau operaţiunile care trebuie consolidate;
- eventuala necesitate de ameliorare a acestei proceduri în vederea îmbunătăţirii eficacităţii răspunsului la incidente;
- oportunităţile de formare şi de consolidare a capacităţilor pentru a îmbunătăţi mai mult rezilienţa sistemelor registrelor în ceea ce priveşte securitatea informaţiilor, pentru a reduce riscul unor incidente viitoare şi pentru a reduce la minimum impactul acestora.
10.MANAGEMENTUL SECURITĂŢII INFORMAŢIILOR
Managementul securităţii informaţiilor vizează asigurarea confidenţialităţii, a integrităţii şi a disponibilităţii informaţiilor şi datelor clasificate, precum şi a serviciilor IT ale unei organizaţii. Pe lângă componentele tehnice, inclusiv conceperea şi testarea acestora (a se vedea LTS), sunt necesare următoarele procedee comune de funcţionare în vederea îndeplinirii cerinţelor de securitate pentru legătura permanentă între registre.
10.1.Identificarea informaţiilor sensibile
Nivelul de sensibilitate al unei informaţii este evaluat prin stabilirea nivelului impactului asupra activităţii (de exemplu, pierderi financiare, afectarea imaginii, încălcări ale legii etc.) pe care l-ar putea avea o încălcare a securităţii respectivelor informaţii.
Activele informaţionale sensibile sunt identificate pe baza impactului lor asupra legăturii.
Nivelul de sensibilitate al acestor informaţii este evaluat în funcţie de scala de sensibilitate aplicabilă pentru această legătură şi este prezentat în detaliu în secţiunea "Gestionarea incidentelor de securitate a informaţiilor" din prezentul document.
10.2.Nivelurile de sensibilitate ale activelor informaţionale
După identificarea sa, activul informaţional este clasificat aplicând următoarele reguli:
- identificarea cel puţin a unui nivel RIDICAT de confidenţialitate, integritate sau disponibilitate clasifică activul drept SPECIAL HANDLING: ETS Critical;
- identificarea cel puţin a unui nivel MEDIU de confidenţialitate, integritate sau disponibilitate clasifică activul drept SENSITIVE: ETS;
- identificarea cel puţin a unui nivel REDUS de confidenţialitate, integritate sau disponibilitate clasifică activul drept Marcajul EU: SENSITIVE: ETS Joint Procurement; Marcajul CH: LIMITED: ETS.
10.3.Desemnarea proprietarului activelor informaţionale
Toate activele informaţionale ar trebui să aibă un proprietar desemnat. Activele informaţionale ale ETS, care aparţin legăturii dintre EUTL şi SSTL sau se referă la aceasta ar trebui incluse într-o listă comună de inventariere a activelor, menţinută de ambele părţi. Activele informaţionale ale ETS din afara legăturii dintre EUTL şi SSTL ar trebui incluse într-o listă de inventariere a activelor, menţinută de partea corespunzătoare.
Dreptul de proprietate asupra fiecărui activ informaţional care aparţine legăturii dintre EUTL şi SSTL sau se referă la aceasta va fi convenit de către părţi. Proprietarul unui activ informaţional este responsabil pentru evaluarea nivelului de sensibilitate al acestuia.
Proprietarul ar trebui să aibă un nivel de responsabilitate corespunzător valorii activului (activelor) atribuit(e). Responsabilitatea proprietarului în ceea ce priveşte activul (activele), precum şi obligaţia acestuia de a menţine nivelul de confidenţialitate, integritate şi disponibilitate necesare ar trebui să fie convenite şi oficializate.
10.4.Înregistrarea informaţiilor sensibile
Toate informaţiile sensibile sunt înregistrate în Evidenţa informaţiilor sensibile (SIL).
Dacă este cazul, agregarea unor informaţii sensibile care ar putea avea un impact mai mare decât impactul unei singure informaţii trebuie luată în considerare şi înregistrată în SIL (de exemplu, un set de informaţii stocate în baza de date a sistemului).
SIL nu este statică. Ameninţările, vulnerabilităţile, probabilitatea sau consecinţele incidentelor de securitate legate de active se pot schimba fără nicio indicaţie şi pot fi introduse active noi în operarea sistemele registrelor.
Prin urmare, SIL trebuie revizuită periodic şi toate informaţiile noi considerate ca fiind sensibile trebuie înregistrate imediat în SIL.
SIL conţine cel puţin următoarele informaţii pentru fiecare înregistrare:
- descrierea informaţiilor;
- proprietarul informaţiilor;
- nivelul de sensibilitate;
- o menţiune care să indice dacă informaţiile includ date cu caracter personal;
- informaţii suplimentare, dacă este cazul.
10.5.Gestionarea informaţiilor sensibile
Atunci când sunt prelucrate în afara legăturii dintre registrul Uniunii şi registrul elveţian, informaţiile sensibile sunt gestionate în conformitate cu Instrucţiunile de gestionare.
Informaţiile sensibile prelucrate prin intermediul legăturii dintre registrul Uniunii şi registrul elveţian sunt gestionate de către părţi în conformitate cu cerinţele în materie de securitate.
10.6.Gestionarea accesului
Obiectivul procesului de management al accesului este de a acorda utilizatorilor autorizaţi dreptul de a utiliza un serviciu, împiedicând în acelaşi timp accesul utilizatorilor neautorizaţi. Managementul accesului este uneori denumit şi "managementul drepturilor" sau "managementul identităţii".
Pentru legătura permanentă între registre şi funcţionarea acesteia, ambele părţi au nevoie de acces la următoarele componente:
- Wiki: un mediu de colaborare pentru schimbul de informaţii comune, cum ar fi planificarea versiunilor;
- instrumentul de gestionare a serviciilor IT (ITSM) pentru gestionarea incidentelor şi a problemelor (a se vedea capitolul 3 "Abordare şi standarde");
- sistemul de schimb de mesaje: fiecare parte pune la dispoziţie un sistem securizat de transfer de mesaje pentru transmiterea mesajelor care conţin date privind tranzacţiile.
Administratorul registrului elveţian şi administratorul central al Uniunii se asigură că accesurile sunt actualizate şi funcţionează ca puncte de contact pentru părţile lor în cadrul activităţilor de management al accesului. Cererile de acces sunt gestionate conform procedurilor de soluţionare a cererilor.
10.7.Gestionarea certificatelor/cheilor
Fiecare parte răspunde de gestionarea propriilor certificate/chei (generare, înregistrare, stocare, instalare, utilizare, reînnoire, revocare, realizarea de copii de rezervă şi recuperarea certificatelor/cheilor). Conform standardelor tehnice de creare a legăturii (LTS), se utilizează numai certificate digitale emise de o autoritate de certificare (CA) acceptată de ambele părţi. Gestionarea şi stocarea certificatelor/cheilor trebuie să respecte dispoziţiile din Instrucţiunile de gestionare.
Orice revocare şi/sau reînnoire a certificatelor şi a cheilor este coordonată de ambele părţi. Aceasta se realizează conform procedurilor de soluţionare a cererilor.
Administratorul registrului elveţian şi administratorul central al Uniunii vor face schimb de certificate/chei prin mijloace de comunicare securizate în conformitate cu dispoziţiile din Instrucţiunile de gestionare.
Orice verificare a certificatelor/cheilor prin orice mijloc între părţi se va realiza în afara benzii.
ANEXA I3:STANDARDE TEHNICE DE CREARE A LEGĂTURII (LTS) ÎN TEMEIUL ARTICOLULUI 3 ALINEATUL (7) DIN ACORDUL DINTRE UNIUNEA EUROPEANĂ ŞI CONFEDERAŢIA ELVEŢIANĂ PENTRU CREAREA UNEI LEGĂTURI ÎNTRE RESPECTIVELE LOR SCHEME DE COMERCIALIZARE A CERTIFICATELOR DE EMISII DE GAZE CU EFECT DE SERĂ
Standarde pentru legătura permanentă între registre
Cuprins

1.

GLOSAR

23

2.

INTRODUCERE

25

2.1.

Domeniul de aplicare

25

2.2.

Destinatari

25

3.

DISPOZIŢII GENERALE

25

3.1.

Arhitectura legăturii de comunicare

25

3.1.1.

Schimbul de mesaje

26

3.1.2.

Mesaj XML - Descriere de nivel înalt

26

3.1.3.

Ferestre de ingerare (Ingestion Windows)

26

3.1.4.

Fluxurile de mesaje privind tranzacţiile

27

3.2.

Securitatea transferurilor de date

29

3.2.1.

Firewall şi interconectarea între reţele

29

3.2.2.

Reţea virtuală privată (VPN)

29

3.2.3.

Implementarea IPSec

29

3.2.4.

Protocol de transfer securizat pentru schimburile de mesaje

30

3.2.5.

Criptare şi semnătură bazate pe XML

30

3.2.6.

Chei criptografice

30

3.3.

Lista funcţiilor în cadrul legăturii

30

3.3.1.

Tranzacţiile comerciale

30

3.3.2.

Protocolul reconcilierilor

31

3.3.3.

Mesaj test

31

3.4.

Cerinţe privind înregistrarea datelor

31

3.5.

Cerinţele operaţionale

32

4.

DISPOZIŢII PRIVIND DISPONIBILITATEA

32

4.1.

Proiectarea disponibilităţii comunicaţiilor

32

4.2.

Planul de iniţializare, comunicare, reactivare şi testare

33

4.2.1.

Testele interne pentru infrastructura TIC

33

4.2.2.

Testele de comunicare

33

4.2.3.

Teste pentru întregul sistem (de la un capăt la celălalt capăt)

33

4.2.4.

Testele de securitate

33

4.3.

Mediile de acceptare/de testare

34

5.

DISPOZIŢII PRIVIND CONFIDENŢIALITATEA ŞI INTEGRITATEA

34

5.1.

Infrastructura de testare a securităţii

34

5.2.

Dispoziţii privind suspendarea şi reactivarea legăturii

35

5.3.

Dispoziţii privind încălcarea securităţii

35

5.4.

Orientări privind testarea securităţii

35

5.4.1.

Software

35

5.4.2.

Infrastructură

36

5.5.

Dispoziţii privind evaluarea riscurilor

36

1.GLOSAR
Tabelul 1-1 Acronime şi definiţii comerciale

Acronim/termen

Definiţie

Certificat

Dreptul de a emite o tonă de dioxid de carbon echivalent pe parcursul unei perioade specificate, care va fi valabil exclusiv în scopul respectării cerinţelor ETS ale fiecărei entităţi.

CH

Confederaţia Elveţiană.

CHU

Tipul de certificat pentru instalaţia staţionară, denumit şi CHU2 (cu referire la perioada de angajament 2 din Protocolul de la Kyoto), emis de Confederaţia Elveţiană.

CHUA

Certificat elveţian pentru aviaţie.

COP

Procedee comune de funcţionare. Procedee elaborate în comun pentru operaţionalizarea legăturii dintre EU ETS şi ETS-ul Elveţiei.

ETR

Registru de comercializare a certificatelor de emisii.

ETS

Schema de comercializare a certificatelor de emisii.

UE

Uniunea Europeană.

EUA

Certificat general al UE.

EUAA

Certificat pentru aviaţie al UE.

EUCR

Registrul consolidat al Uniunii Europene.

EUTL

Registrul de tranzacţii al Uniunii Europene.

Registrul

Un sistem de contabilizare a certificatelor emise în cadrul ETS, care ţine evidenţa drepturilor de proprietate asupra certificatelor deţinute în conturile electronice.

SSTL

Registrul suplimentar de tranzacţii al Elveţiei.

Operaţiune

Un proces în cadrul unui registru care include transferul unui certificat dintr-un cont în alt cont.

Sistem al unui registru de tranzacţii

Registrul de tranzacţii include o evidenţă a fiecărei tranzacţii propuse trimise de la un registru la celălalt.

Tabelul 1-2 Acronime şi definiţii tehnice

Acronim

Definiţie

Criptografie asimetrică

Utilizează chei publice şi private pentru criptarea şi decriptarea datelor.

Autoritate de certificare (CA)

Entitate care emite certificate digitale

Cheie criptografică

O informaţie care determină rezultatul funcţional al unui algoritm criptografic.

Decriptare

Proces opus criptării.

Semnătură digitală

O tehnică matematică utilizată pentru validarea autenticităţii şi integrităţii unui mesaj, software sau document digital.

Criptare

Procesul de conversie a informaţiilor sau a datelor într-un cod, în special pentru a împiedica accesul neautorizat.

Ingerare de fişiere

Procesul de citire a unui fişier.

Firewall

Aparat sau software de securitate în reţea care monitorizează şi controlează traficul de reţea de intrare şi de ieşire pe baza unor reguli prestabilite.

Monitorizarea ritmicităţii (heartbeat)

Semnal periodic generat şi monitorizat de hardware sau software pentru a indica funcţionarea normală sau pentru a sincroniza alte componente ale unui sistem informatic.

IPSec

IP SECurity. Suită de protocoale de reţea care autentifică şi criptează pachetele de date pentru a asigura o comunicare criptată securizată între două computere printr-o reţea de protocoale internet.

Test de rezistenţă la intruziuni

Practică de testare a unui sistem informatic, a unei reţele sau a unei aplicaţii web pentru a descoperi vulnerabilităţi de securitate pe care un atacator le-ar putea exploata.

Proces de reconciliere

Proces de asigurare a faptului că două seturi de înregistrări concordă.

VPN

Reţea virtuală privată.

XML

Limbaj de marcare extensibil. Permite proiectanţilor să îşi creeze propriile etichete personalizate, care să permită definirea, transmiterea, validarea şi interpretarea datelor între aplicaţii şi între organizaţii.

2.INTRODUCERE
Acordul dintre Uniunea Europeană şi Confederaţia Elveţiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 23 noiembrie 2017 (denumit în continuare "acordul") prevede recunoaşterea reciprocă a certificatelor de emisii care pot fi utilizate pentru asigurarea conformităţii în cadrul sistemului de comercializare a certificatelor de emisii (denumit în continuare "EU ETS") sau în cadrul sistemului Elveţiei de comercializare a certificatelor de emisii (denumit în continuare ETS-ul Elveţiei). În vederea activării legăturii dintre EU ETS şi ETS-ul Elveţiei, se va crea o legătură directă între Registrul de tranzacţii al Uniunii Europene (EUTL) din cadrul registrului Uniunii şi Registrul suplimentar de tranzacţii al Elveţiei (SSTL) din cadrul registrului elveţian, ceea ce va permite transferul dintr-un registru în altul al certificatelor de emisii emise în cadrul oricăruia dintre ETS-uri [articolul 3 alineatul (2) din acord]. Pentru a operaţionaliza legătura dintre EU ETS şi ETS-ul Elveţiei, în 2020 a fost pusă în aplicare o soluţie provizorie. Începând din 2023, legătura dintre cele două sisteme de comercializare a certificatelor de emisii se va transforma treptat într-o legătură permanentă între registre, a cărei implementare este preconizată a avea loc cel târziu în 2024, care va permite funcţionarea pieţelor legate în ceea ce priveşte beneficiile oferite de lichiditatea pieţei şi de executarea tranzacţiilor între cele două sisteme conectate într-un mod echivalent cu o piaţă formată din două sisteme şi care va permite participanţilor la piaţă să acţioneze ca şi cum ar fi pe o singură piaţă, sub rezerva unor dispoziţii de reglementare individuale ale părţilor (anexa II la acord).
În conformitate cu articolul 3 alineatul (7) din acord, administratorul registrului elveţian şi administratorul central al Uniunii stabilesc standardele tehnice de creare a legăturii (LTS) pe baza principiilor prevăzute în anexa II la acord, în care sunt descrise în detaliu cerinţele pentru stabilirea unei legături robuste şi securizate între SSTL şi EUTL. Standardele tehnice de creare a legăturii elaborate de administratori produc efecte după ce sunt adoptate printr-o decizie a comitetului mixt.
LTS a fost adoptată de comitetul mixt prin Decizia nr. 2/2020. Procedeele comune de funcţionare actualizate, astfel cum sunt specificate în prezentul document, vor fi adoptate prin Decizia nr. 1/2024 a comitetului mixt. În conformitate cu prezenta decizie şi cu solicitările Comitetului mixt, administratorul registrului elveţian şi administratorul central al Uniunii au elaborat şi vor actualiza orientări tehnice suplimentare pentru activarea legăturii şi pentru a garanta că acestea sunt adaptate permanent la progresul tehnic şi la noile cerinţe privind siguranţa şi securitatea legăturii şi funcţionarea efectivă şi eficientă a acesteia.
2.1.Domeniul de aplicare
Prezentul document reprezintă înţelegerea comună între părţile la acord cu privire la stabilirea fundamentelor tehnice ale legăturii dintre registrele EU ETS şi ETS-ul Elveţiei. Deşi documentul pune bazele specificaţiilor tehnice în ceea ce priveşte cerinţele privind arhitectura, serviciile şi securitatea, vor fi necesare unele orientări suplimentare detaliate pentru activarea legăturii.
Pentru funcţionarea sa corespunzătoare, legătura va necesita procese şi procedee pentru operaţionalizarea în continuare a acesteia. În conformitate cu articolul 3 alineatul (6) din acord, aceste aspecte sunt prezentate în detaliu într-un document separat privind procedeele comune de funcţionare, care urmează să fie adoptat separat prin decizia comitetului mixt.
2.2.Destinatari
Prezentul document se adresează administratorului registrului elveţian şi administratorului central al Uniunii.
3.DISPOZIŢII GENERALE
3.1.Arhitectura legăturii de comunicare
Scopul prezentei secţiuni este de a oferi o descriere a arhitecturii generale a activării legăturii dintre EU ETS şi ETS-ul Elveţiei şi a diferitelor componente implicate în aceasta.
Având în vedere faptul că securitatea reprezintă un element-cheie pentru definirea arhitecturii legăturii dintre registre, au fost luate toate măsurile pentru crearea unei arhitecturi robuste. Legătura permanentă între registre utilizează un mecanism de schimb de fişiere, ca implementare a unei conexiuni securizate Air Gap.
Soluţia tehnică utilizează:
- un protocol de transfer securizat pentru schimburile de mesaje;
- mesaje XML;
- semnătură digitală şi criptare bazate pe XML;
- VPN.
3.1.1.Schimbul de mesaje
Comunicarea dintre registrul Uniunii şi registrul elveţian se bazează pe un mecanism de schimb de mesaje prin intermediul unor canale securizate. Fiecare parte se bazează pe propriul sistem de colectare a mesajelor primite.
Ambele părţi ţin o evidenţă a mesajelor primite, împreună cu detaliile procesărilor.
Erorile sau situaţiile neaşteptate trebuie raportate, sub formă de alerte, şi ar trebui să aibă loc contactul uman între echipele de asistenţă.

Erorile şi evenimentele neaşteptate sunt gestionate conform procedeelor de funcţionare prevăzute în secţiunea privind procesul de gestionare a incidentelor din procedeele comune de funcţionare.

3.1.2.Mesaj XML - Descriere de nivel înalt
Un mesaj XML conţine unul dintre următoarele elemente:
- una sau mai multe cereri de tranzacţii şi/sau unul sau mai multe răspunsuri la tranzacţii;
- o operaţiune/un răspuns legat de reconciliere;
- un mesaj test.
Fiecare mesaj conţine un antet care include:
- sistemul ETS de origine;
- numărul de secvenţă.
3.1.3.Ferestre de ingerare (Ingestion Windows)
Legătura permanentă între registre se bazează pe ferestre de ingerare predefinite care sunt urmate de un set de evenimente cu nume. Cererile de tranzacţii primite prin intermediul legăturii vor fi ingerate numai la intervale predefinite. Ferestrele de ingerare includ o validare tehnică pentru tranzacţiile efectuate şi primite. În plus, reconcilierile pot fi derulate zilnic şi declanşate manual.

Modificările de frecvenţă şi/sau ale momentelor de desfăşurare ale oricăruia dintre aceste evenimente vor fi gestionate conform procedeelor de funcţionare prevăzute în secţiunea privind procesul de soluţionare a cererilor din procedeele comune de funcţionare.

3.1.4.Fluxurile de mesaje privind tranzacţiile
Tranzacţiile efectuate
Reflectă punctul de vedere al ETS-ului care efectuează transferul. Fluxul specific este prezentat în următoarea diagramă de secvenţă:
Fluxul principal prezintă următoarele etape (la fel ca în desenul de mai sus):
(a)În cadrul ETS-ului care efectuează transferul, cererea de tranzacţie este trimisă de la registru către registrul de tranzacţii, după încheierea tuturor întârzierilor comerciale (întârziere de 24 de ore, după caz).
(b)Registrul de tranzacţii validează cererea de tranzacţie.
(c)Cererea de tranzacţie este trimisă către ETS-ul de destinaţie.
(d)Răspunsul de acceptare este trimis către registrul din cadrul ETS-ului de origine.
(e)ETS-ul de destinaţie validează cererea de tranzacţie.
(f)ETS-ul de destinaţie retrimite răspunsul de acceptare către registrul de tranzacţii din cadrul ETS-ului de origine.
(g)Registrul de tranzacţii trimite răspunsul de acceptare către registru.
Flux alternativ "Respingerea registrului de tranzacţii" [astfel cum este indicat în desenul de mai sus, începând de la litera (a) din fluxul principal]:
a)În cadrul sistemului de origine, cererea de tranzacţie este trimisă de la registru către registrul de tranzacţii, după încheierea tuturor întârzierilor comerciale (întârziere de 24 de ore, după caz).
b)Registrul de tranzacţii nu validează cererea
c)Mesajul de respingere este trimis către registrul de origine.
Debit alternativ "Respingere ETS" [astfel cum este prezentat în desenul de mai sus, începând de la litera (d) în fluxul principal]:
(a)În cadrul ETS-ului de origine, cererea de tranzacţie este trimisă de la registru către registrul de tranzacţii, după încheierea tuturor întârzierilor comerciale (întârziere de 24 de ore, după caz).
(b)Registrul de tranzacţii validează tranzacţia.
(c)Cererea de tranzacţie este trimisă către ETS-ul de destinaţie.
(d)Mesajul de acceptare este trimis către registrul din cadrul ETS-ului de origine.
(e)Registrul de tranzacţii din cadrul ETS-ului de destinaţie nu validează tranzacţia.
(f)ETS-ul de destinaţie trimite răspunsul de refuz către registrul de tranzacţii din cadrul ETS-ului care a efectuat transferul.
(g)Registrul de tranzacţii trimite refuzul către registru.
Tranzacţiile primite
Aceasta reflectă punctul de vedere al ETS-ului de destinaţie. Fluxul specific este prezentat în următoarea diagramă de secvenţă:
În diagramă se indică următoarele:
1.Atunci când registrul de tranzacţii din cadrul ETS-ului de destinaţie validează cererea, acesta trimite mesajul de acceptare către ETS-ul care efectuează transferul şi mesajul "tranzacţie finalizată" către registrul din cadrul ETS-ului de destinaţie.
2.Atunci când o cerere primită este refuzată în registrul de tranzacţii de destinaţie şi este refuzată, cererea de tranzacţie nu este trimisă către registrul din cadrul ETS-ului de destinaţie.
Protocol
Ciclul mesajelor privind tranzacţiile implică doar două mesaje:
- ETS-ul care efectuează transferulŕ Propunerea de tranzacţie pentru ETS-ul de destinaţie;
- ETS-ul de destinaţie ŕ Răspunsul la tranzacţie pentru ETS-ul care efectuează transferul: Fie "Acceptată", fie "Respinsă" (inclusiv motivul respingerii).
- Acceptat: Tranzacţia este finalizată.
- Respinsă: Tranzacţia este încheiată.
Stadiul tranzacţiei
- În momentul trimiterii cererii, stadiul tranzacţiei va fi setat la "propusă" în cadrul ETS-ului care efectuează transferul.
- În momentul primirii cererii şi pe parcursul procesării acesteia, stadiul tranzacţiei va fi setat la "propusă" în cadrul ETS-ului de destinaţie.
- După procesarea cererii, stadiul tranzacţiei va fi setat la "finalizată"/"încheiată" în cadrul ETS-ului de destinaţie. ETS-ul de destinaţie va trimite apoi mesajul de acceptare/respingere corespunzător.
- După primirea şi procesarea mesajului de acceptare/respingere, stadiul tranzacţiei va fi setat la "finalizată"/"încheiată" în cadrul ETS-ului care efectuează transferul.
- În cazul în care nu se primeşte niciun răspuns, stadiul tranzacţiei va rămâne "propusă" în cadrul ETS-ului care efectuează transferul.
- Stadiul tranzacţiei în cadrul ETS-ului de destinaţie va fi setat ca "încheiată" dacă orice tranzacţie propusă rămâne în stadiul de "propusă" mai mult de 30 de minute.

Incidentele legate de tranzacţii vor fi gestionate cu respectarea procedeelor de funcţionare prevăzute în cadrul procesului de gestionare a incidentelor din procedeele comune de funcţionare.

3.2.Securitatea transferurilor de date
Datele aflate în tranzit vor face obiectul a patru niveluri de securitate:
1.Controlul accesului la reţea: firewall şi nivelul de interconectare între reţele.
2.Criptarea la nivelul de transport: VPN.
3.Criptarea la nivelul sesiunilor: protocol de transfer securizat pentru schimburile de mesaje.
4.Criptarea la nivelul aplicaţiilor: semnătură şi criptare a conţinutului bazate pe XML.
3.2.1.Firewall şi interconectarea între reţele
Legătura este stabilită prin intermediul unei reţele protejate de un firewall pe bază de hardware. Firewall-ul este configurat cu reguli potrivit cărora doar clienţii "înregistraţi" să se poată conecta la serverul VPN.
3.2.2.Reţea virtuală privată (VPN)
Toate comunicările dintre părţi sunt protejate cu ajutorul unei tehnologii cu reţea virtuală privată (VPN). Tehnologiile VPN oferă posibilitatea "transportului" dintr-un punct în altul printr-o reţea precum internetul, protejând toate comunicaţiile. Înainte de crearea tunelului VPN, un certificat digital este transmis către punctul final al unui potenţial client, permiţând clientului să furnizeze dovada identităţii pe parcursul negocierii legăturii. Fiecare parte este responsabilă pentru instalarea certificatului în propriul punct final VPN. Utilizând certificate digitale, fiecare server VPN final va accesa o autoritate centrală pentru a negocia acreditările de autentificare. Pe parcursul procesului de creare a tunelului, se negociază criptarea, asigurând protejarea tuturor comunicaţiilor efectuate prin intermediul tunelului.
Punctele finale VPN ale clienţilor sunt configurate pentru a menţine în permanenţă tunelul VPN, pentru a permite în orice moment o comunicare fiabilă, bidirecţională şi în timp real între părţi.
În general, Uniunea Europeană utilizează serviciile transeuropene securizate de telematică între administraţii (STESTA) ca reţea privată bazată pe IP. Prin urmare, această reţea este adecvată şi pentru legătura permanentă între registre.
3.2.3.Implementarea IPSec
Utilizarea protocolului IPSec pentru formarea infrastructurii VPN site-to-site va asigura autentificarea site-to-site, integritatea datelor şi criptarea acestora. Configuraţiile VPN care includ protocoale IPSec asigură o autentificare corectă între două puncte finale în cazul unei conexiuni VPN. Părţile vor identifica şi autentifica clientul de la distanţă prin conexiunea IPSec utilizând un certificat digital emis de o autoritate de certificare recunoscută de cealaltă parte.
Protocolul IPSec asigură, de asemenea, integritatea datelor pentru toate comunicaţiile efectuate prin intermediul tunelului VPN. Pachetele de date sunt trunchiate şi semnate utilizând informaţiile de autentificare stabilite prin VPN. Confidenţialitatea datelor este asigurată şi prin activarea criptării IPSec.
3.2.4.Protocol de transfer securizat pentru schimburile de mesaje
Legătura permanentă între registre se bazează pe mai multe niveluri de criptare pentru schimbul securizat de date între părţi. Ambele sisteme şi mediile lor diferite sunt interconectate la nivelul reţelei prin intermediul unor tuneluri VPN. La nivel de aplicaţie, fişierele sunt transferate cu ajutorul unui protocol de transfer securizat pentru schimburile de mesaje la nivel de sesiune.
3.2.5.Criptare şi semnătură bazate pe XML
În fişierele XML, semnarea şi criptarea se realizează la două niveluri. Fiecare cerere de tranzacţie, răspuns la o tranzacţie şi mesaj de reconciliere se semnează digital, în mod individual.
Într-o a doua etapă, fiecare subelement al elementului "mesaj" este criptat individual.
În plus, ca o a treia etapă şi pentru a asigura integritatea şi non-repudierea întregului mesaj, mesajul elementului rădăcină este semnat digital. Acesta conduce la un nivel ridicat de protecţie pentru datele încorporate în format XML. Implementarea tehnică respectă standardele consorţiului World Wide Web.
Pentru a decripta şi a verifica mesajul, procesul este efectuat în ordine inversă.
3.2.6.Chei criptografice
Criptografia cu chei publice va fi utilizată pentru criptare şi semnare.
Pentru cazul specific al IPSec, se va utiliza un certificat digital emis de o autoritate de certificare (CA) acceptată de ambele părţi. Respectiva autoritate de certificare verifică identitatea deţinătorului certificatului şi emite certificate care sunt utilizate pentru a identifica pozitiv o organizaţie şi a configura canale de comunicaţii de date securizate între părţi.

Cheile criptografice sunt utilizate pentru semnarea şi criptarea canalelor de comunicare şi a fişierelor de date. Certificatele publice sunt schimbate digital de către părţi prin intermediul unor canale securizate şi sunt verificate pe un canal de comunicare diferit de cel principal. Această procedură este o parte integrantă a procesului de management al securităţii informaţiilor prevăzut în procedeele comune de funcţionare.

3.3.Lista funcţiilor în cadrul legăturii
Legătura specifică sistemul de transmisie pentru o serie de funcţii care implementează procesele comerciale prevăzute în acord. Legătura include, de asemenea, specificaţia pentru procesul de reconciliere şi pentru mesajele test care vor permite implementarea unei monitorizări a ritmicităţii.
3.3.1.Tranzacţiile comerciale
Din perspectivă comercială, legătura include patru (4) tipuri de cereri de tranzacţii:
- Transfer extern:
- După activarea legăturii între ETS-uri, certificatele UE şi CH sunt fungibile şi, prin urmare, complet transferabile, între părţi.
- Un transfer efectuat prin intermediul legăturii va implica un cont de transfer pe un ETS şi un cont de achiziţie pe celălalt ETS.
- transferul poate include orice cantitate din cele patru (4) tipuri de certificate:
- Certificate generale elveţiene (CHU)
- Certificate pentru aviaţie elveţiene (CHUA)
- Certificate generale ale UE (EUA)
- Certificate pentru aviaţie al UE (EUAA)
- Alocare internaţională:
Operatorii de aeronave administraţi de un ETS cu obligaţii în celălalt ETS şi îndreptăţiţi să primească certificate gratuite de la cel de-al doilea ETS, vor primi certificate pentru aviaţie gratuite de la cel de-al doilea ETS prin intermediul tranzacţiei de certificate internaţionale.
- Revocarea unei alocări internaţionale:
Această tranzacţie se va realiza în cazul în care certificatele gratuite alocate unui operator de aeronave deţinut de celălalt ETS trebuie revocate în totalitate.
- Returnarea unei alocări în exces:
Similar cu revocarea, dar în cazul în care alocarea nu trebuie să fie revocată în totalitate şi numai certificatele supraalocate trebuie returnate ETS-ului care le-a alocat.
3.3.2.Protocolul reconcilierilor
Reconcilierile vor avea loc numai după închiderea ferestrei pentru ingerarea, validarea şi procesarea mesajelor.
Reconcilierile sunt o parte integrantă a măsurilor privind securitatea şi coerenţa legăturii. Ambele părţi vor conveni asupra momentului exact al reconcilierii înainte de elaborarea oricărui calendar. O reconciliere zilnică programată se poate realiza doar cu acordul ambelor părţi. Cel puţin o reconciliere programată va fi executată în orice caz după efectuarea operaţiunii de ingerare.
În orice caz, oricare dintre părţi poate să iniţieze în orice moment reconcilieri manuale.

Modificările momentelor de desfăşurare şi ale frecvenţei reconcilierii programate vor fi gestionate conform procedeelor de funcţionare prevăzute în secţiunea privind procesul de soluţionare a cererilor din procedeele comune de funcţionare.

3.3.3.Mesaj test
Un mesaj test este prevăzut pentru a testa comunicarea de la un capăt la celălalt capăt. Mesajul va conţine date care vor identifica mesajul drept test şi va primi un răspuns după primirea sa la celălalt capăt.
3.4.Cerinţe privind înregistrarea datelor
Pentru a răspunde nevoii ambelor părţi de a păstra informaţii corecte şi coerente şi de a furniza instrumente care să fie utilizate în cadrul procesului de reconciliere pentru remedierea neconcordanţelor, sunt păstrate patru (4) tipuri de evidenţe de date de către ambele părţi:
- registrele de tranzacţii;
- registrele de reconcilieri;
- arhiva de mesaje;
- registrele de evidenţă a auditurilor interne.
Toate datele din registrele respective sunt păstrate pentru o perioadă de cel puţin trei (3) luni în scopul efectuării operaţiunilor de depanare, iar păstrarea lor ulterioară va depinde de legislaţia privind efectuarea auditurilor, aplicabilă la fiecare capăt. Fişierele-jurnal mai vechi de trei (3) luni pot fi arhivate într-o locaţie securizată într-un sistem IT independent atât timp cât acestea pot fi preluate sau accesate într-o perioadă rezonabilă.
Registrele de tranzacţii
Subsistemele EUTL şi SSTL sunt implementări ale registrelor de tranzacţii.
Mai exact, registrele de tranzacţii vor ţine o evidenţă a fiecărei tranzacţii propuse trimise celuilalt ETS. Fiecare evidenţă include toate câmpurile conţinutului tranzacţiei şi rezultatul ulterior al tranzacţiei (răspunsul ETS-ului de destinaţie). Registrele de tranzacţii vor ţine şi o evidenţă a tranzacţiilor efectuate, precum şi răspunsul trimis ETS-ului de origine.
Registrele de reconcilieri
Registrul de reconcilieri include o evidenţă a fiecărui mesaj de reconciliere transmis între cele două părţi, inclusiv ID-ul reconcilierii, marcajul temporal şi rezultatul reconcilierii: Stadiul reconcilierii "Reuşită" sau "Discrepanţe". În cadrul legăturii permanente între registre, mesajele de reconciliere fac parte integrantă din mesajele schimbate şi, prin urmare, sunt stocate astfel cum se descrie în secţiunea "Arhiva de mesaje".
Ambele părţi înregistrează fiecare cerere şi răspunsul aferent în Registrul de reconcilieri. Cu toate că informaţiile din Registrul de reconcilieri nu sunt partajate în mod direct ca parte a reconcilierii în sine, poate fi necesar accesul la respectivele informaţii pentru a remedia neconcordanţele.
Arhiva de mesaje
Ambele părţi au obligaţia de a arhiva o copie a datelor partajate (fişierele XML), trimise şi primite, indiferent dacă respectivele date sau mesajele XML au fost corecte în formatul lor sau nu.
Scopul principal al arhivării este de a avea dovada mesajelor trimise celeilalte părţi şi primite de la cealaltă parte, pe care să o prezinte în cursul unui audit. În acest scop, împreună cu fişierele, trebuie să fie arhivate şi certificatele aferente.
Fişierele respective vor oferi, de asemenea, informaţii suplimentare pentru operaţiunile de depanare.
Registrele de evidenţă a auditurilor interne
Aceste registre sunt definite şi utilizate individual de către fiecare parte.
3.5.Cerinţele operaţionale
Schimbul de date între cele două sisteme nu este complet autonom în cadrul legăturii permanente între registre, ceea ce înseamnă că este nevoie de operatori şi de proceduri pentru activarea legăturii. Mai multe roluri şi instrumente sunt detaliate în acest scop în cadrul acestui proces.
4.DISPOZIŢII PRIVIND DISPONIBILITATEA
4.1.Proiectarea disponibilităţii comunicaţiilor
Arhitectura legăturii permanente între registre este în esenţă o infrastructură şi un software TIC care permite comunicarea între ETS-ul Elveţiei şi EU ETS. Prin urmare, asigurarea unor niveluri ridicate de disponibilitate, integritate şi confidenţialitate a acestui flux de date devine un aspect esenţial de luat în considerare pentru proiectarea legăturii permanente între registre. Fiind un proiect în care infrastructura TIC, software-ul personalizat şi procesele joacă un rol fundamental, toate cele trei elemente trebuie luate în considerare pentru proiectarea unui sistem rezilient.
Rezilienţa infrastructurii TIC
În capitolul privind dispoziţiile generale din prezentul document sunt descrise în detaliu elementele constitutive ale arhitecturii. În ceea ce priveşte infrastructura TIC, legătura permanentă între registre instituie o reţea VPN rezilientă care creează tuneluri de comunicare securizate prin intermediul cărora se pot realiza schimburi de mesaje securizate. Alte elemente de infrastructură sunt configurate cu un grad ridicat de disponibilitate şi/sau se bazează pe mecanisme de rezervă.
Rezilienţa software-ului personalizat
Modulele software personalizate dezvoltate îmbunătăţesc rezilienţa prin reluarea comunicării cu celălalt capăt pentru o anumită perioadă, în cazul în care aceasta nu este disponibilă din anumite motive.
Rezilienţa serviciilor
În legătura permanentă între registre, schimburile de date dintre părţi au loc la intervale predefinite. Unele dintre etapele necesare pentru schimburile de date programate în prealabil necesită intervenţia manuală a operatorilor sistemului şi/sau a administratorilor registrelor. Luând în considerare acest aspect şi pentru a spori gradul de disponibilitate şi de reuşită a schimburilor:
- Procedeele de funcţionare prevăd intervale orare pentru efectuarea fiecărei etape.
- Modulele software pentru legătura permanentă între registre implementează o comunicare asincronă.
- Procesul de reconciliere automată va detecta dacă au existat probleme în ingerarea fişierelor de date la fiecare dintre capete.
- Procesele de monitorizare (infrastructura TIC şi modulele software personalizate) sunt luate în considerare şi declanşează procedeele de gestionare a incidentelor (astfel cum sunt definite în documentul referitor la procedeele comune de funcţionare). Procedeele care vizează reducerea timpului pentru restabilirea funcţionării normale în urma unor incidente sunt esenţiale pentru asigurarea unor niveluri ridicate de disponibilitate.
4.2.Planul de iniţializare, comunicare, reactivare şi testare
Toate elementele diferite implicate în arhitectura legăturii permanente între registre fac obiectul unei serii de teste individuale şi colective în vederea confirmării faptului că platforma este pregătită la nivelul infrastructurii TIC şi a sistemului de informaţii. Aceste teste de funcţionare reprezintă o condiţie obligatorie de fiecare dată când platforma tranzitează legătura permanentă între registre de la stadiul de "suspendată" la stadiul de "funcţională".
Activarea stadiului funcţional al legăturii necesită apoi executarea cu succes a unui plan de testare predefinit. Acesta confirmă faptul că fiecare registru a efectuat mai întâi un set de teste interne, urmat de validarea conectivităţii între utilizatorii finali înainte de a începe tranzacţiile de producţie între cele două părţi.
În planul de testare ar trebui să se menţioneze strategia generală de testare şi detalii privind infrastructura de testare. Planul de testare ar trebui să includă, în special, pentru fiecare element al fiecărui bloc de testare:
- criteriile şi instrumentele de testare;
- rolurile atribuite pentru efectuarea testului;
- rezultatele scontate (pozitive şi negative);
- calendarul testelor;
- înregistrarea cerinţelor privind rezultatele testelor;
- documentaţia referitoare la operaţiunile de depanare;
- dispoziţii privind escaladările.
Ca proces, testele de activare a stadiului funcţional pot fi împărţite în patru (4) blocuri sau faze conceptuale:
4.2.1.Testele interne pentru infrastructura TIC
Testele respective trebuie efectuate şi/sau verificate individual de către administratorii registrelor la fiecare capăt.
Fiecare element al infrastructurii TIC de la fiecare capăt este testat individual. Acestea includ fiecare componentă a infrastructurii. Aceste teste pot fi executate automat sau manual, însă trebuie să verifice funcţionalitatea fiecărui element al infrastructurii.
4.2.2.Testele de comunicare
Testele respective sunt declanşate individual de către fiecare parte şi pentru finalizarea lor este necesară cooperarea celuilalt capăt.
Atunci când fiecare element în parte este funcţional, trebuie testate canalele de comunicare între cele două registre. În acest scop, fiecare parte verifică dacă accesul la internet funcţionează, dacă tunelurile VPN sunt stabilite şi dacă există conectivitate IP site-to-site. Accesibilitatea elementelor de infrastructură locale şi la distanţă şi conectivitatea IP ar trebui apoi confirmate la celălalt capăt.
4.2.3.Teste pentru întregul sistem (de la un capăt la celălalt capăt)
Aceste teste trebuie executate la fiecare capăt, iar rezultatele sunt partajate cu cealaltă parte.
După ce au fost testate canalele de comunicare şi fiecare componentă a ambelor registre, fiecare capăt va pregăti o serie de simulări de tranzacţii şi de reconcilieri, reprezentative pentru toate funcţiile care urmează să fie implementate în cadrul legăturii.
4.2.4.Testele de securitate
Aceste teste trebuie efectuate şi/sau declanşate de administratorii registrelor la fiecare capăt şi conform specificaţiilor prevăzute în secţiunile 5.4, "Orientări privind testarea securităţii", şi 5.5, "Dispoziţii privind evaluarea riscurilor".
Numai după ce fiecare dintre cele patru faze/blocuri s-a încheiat cu rezultatele scontate, registrul permanent poate fi considerat funcţional.
Resurse de testare
Fiecare parte se bazează pe resurse de testare specifice (software şi hardware specifice infrastructurii TIC) şi dezvoltă funcţii de testare în sistemele lor corespunzătoare pentru a susţine validarea manuală şi continuă a platformei. Procedurile de testare manuale individuale sau cooperative pot fi executate în orice moment de către administratorii registrelor. Activarea stadiului de funcţionare este un proces manual în sine.
Se prevede, de asemenea, ca platforma să efectueze verificări automate la intervale regulate. Aceste verificări vizează creşterea disponibilităţii platformei prin detectarea din timp a potenţialelor probleme legate de infrastructură sau de software. Acest plan de monitorizare a platformei este alcătuit din două elemente:
- Monitorizarea infrastructurilor TIC: la ambele capete, infrastructura va fi monitorizată de furnizorii de servicii de infrastructură TIC. Testele automate vor acoperi diferitele elemente de infrastructură şi disponibilitatea canalelor de comunicare.
- Monitorizarea aplicaţiilor: modulele software pentru crearea registrului permanent vor implementa monitorizarea comunicării în cadrul sistemului la nivel de aplicaţie (manual şi/sau la intervale regulate), care va testa disponibilitatea de la un capăt la altul a legăturii prin simularea unora dintre tranzacţiile efectuate în cadrul legăturii.
4.3.Mediile de acceptare/de testare
Arhitectura registrului Uniunii şi a registrului Elveţiei constă în următoarele trei medii:
- Producţie (PROD): Acest mediu deţine datele reale şi procesează tranzacţii reale.
- Acceptare (ACC): Acest mediu conţine date reprezentative nereale sau anonimizate. Este mediul în care operatorii de sistem ale ambelor părţi validează noile versiuni.
- Test (TEST): Acest mediu conţine date reprezentative nereale sau anonimizate. Acest mediu este limitat la administratorii registrelor şi menit să fie utilizat pentru a efectua teste de integrare de către ambele părţi.
Cu excepţia VPN, cele trei medii sunt complet independente unele de altele; cu alte cuvinte, hardware-ul, software-ul, bazele de date, mediile virtuale, adresele IP şi porturile sunt configurate şi funcţionează independent unele de altele.
În ceea ce priveşte configuraţia VPN, comunicarea dintre cele trei medii trebuie să fie complet independentă, ceea ce este asigurat prin utilizarea STESTA.
5.DISPOZIŢII PRIVIND CONFIDENŢIALITATEA ŞI INTEGRITATEA
Mecanismele şi procedurile de securitate prevăd o metodă pentru două persoane (principiul "celor patru ochi") pentru operaţiunile desfăşurate în cadrul legăturii dintre registrul Uniunii şi registrul elveţian. Metoda pentru două persoane se aplică ori de câte ori este necesar. Cu toate acestea, nu se poate aplica tuturor etapelor parcurse de administratorii registrelor.
Cerinţele de securitate sunt luate în considerare şi abordate în planul de gestionare a securităţii, care include, de asemenea, procese legate de gestionarea incidentelor de securitate ca urmare a unei eventuale încălcări a securităţii. Partea operaţională a acestor procese este descrisă în procedeele comune de funcţionare.
5.1.Infrastructura de testare a securităţii
Fiecare parte se angajează să creeze o infrastructură de testare a securităţii (prin utilizarea software-ului şi hardware-ului comune utilizate pentru detectarea vulnerabilităţilor în fazele de dezvoltare şi de funcţionare):
- separat de mediul de producţie;
- în cazul în care securitatea este analizată de o echipă independentă de echipa de dezvoltare şi operare a sistemului.
Fiecare parte se angajează să efectueze atât analize statice, cât şi analize dinamice.
În cazul unei analize dinamice (cum ar fi testul de rezistenţă la intruziuni), ambele părţi se angajează să restricţioneze evaluările în mod obişnuit la mediile de testare şi de acceptare (astfel cum sunt definite în secţiunea 4.3, "Medii de acceptare/de testare"). Excepţiile de la această politică fac obiectul aprobării de către ambele părţi.
Înainte de implementarea în mediul de producţie, se testează securitatea fiecărui modul software al legăturii (astfel cum este definit în secţiunea 3.4, "Arhitectura legăturii de comunicare").
Infrastructura de testare trebuie să fie separată de cea de producţie, atât la nivel de reţea, cât şi la nivel de infrastructură. Infrastructura de testare este cea în care se efectuează testele de securitate necesare pentru a verifica respectarea cerinţelor de securitate.
5.2.Dispoziţii privind suspendarea şi reactivarea legăturii
Atunci când există suspiciunea că securitatea registrului elveţian, a SSTL, a registrului Uniunii sau a EUTL a fost compromisă, fiecare parte o informează imediat pe cealaltă şi suspendă legătura dintre SSTL şi EUTL;

Procedurile privind schimbul de informaţii, pentru o decizie de suspendare şi pentru o decizie de reactivare fac parte din procesul de soluţionare a cererilor prevăzut în procedeele comune de funcţionare.

Suspendări
Suspendarea legăturii între registre în conformitate cu anexa II la acord se poate produce în următoarele situaţii:
- Din motive administrative (de exemplu întreţinere), care sunt planificate;
- Din motive de securitate (sau defecţiuni ale infrastructurii IT), care sunt neplanificate.
În caz de urgenţă, oricare dintre părţi va informa cealaltă parte şi va suspenda unilateral legătura între registre.
Dacă se ia decizia de a suspenda legătura între registre, atunci fiecare parte se va asigura că legătura este întreruptă la nivel de reţea (prin blocarea părţilor sau a tuturor conexiunilor de intrare şi de ieşire).

Decizia de suspendare a legăturii între registre, indiferent dacă este planificată sau neplanificată, se va lua în conformitate cu procedura de gestionare a modificărilor sau de gestionare a incidentelor de securitate prevăzută în procedeele comune de funcţionare.

Reactivarea comunicării
O decizie de reactivare a legăturii între registre va fi luată în modul prezentat în detaliu în procedeele comune de funcţionare şi, în orice caz, înainte de finalizarea cu succes a procedurilor de testare a securităţii, astfel cum sunt prezentate în detaliu în secţiunile 5.4, "Orientări privind testările de securitate", şi 4.2, "Planul de iniţializare, comunicare, reactivare şi testare".
5.3.Dispoziţii privind încălcarea securităţii
O încălcare a securităţii este considerată un incident de securitate care afectează confidenţialitatea şi integritatea oricăror informaţii sensibile şi/sau disponibilitatea sistemului care le gestionează.
Informaţiile sensibile sunt menţionate în Evidenţa informaţiilor sensibile şi pot fi gestionate în cadrul sistemului sau în cadrul oricărei componente conexe a sistemului.
Informaţiile direct legate de încălcarea securităţii vor fi considerate sensibile, marcate cu menţiunea "SPECIAL HANDLING: ETS critical " şi gestionat în conformitate cu instrucţiunile de gestionare, cu excepţia cazului în care se specifică altfel.

Fiecare încălcare a securităţii va fi gestionată în conformitate cu secţiunea "Gestionarea incidentelor de securitate" din procedeele comune de funcţionare.

5.4.Orientări privind testarea securităţii
5.4.1.Software
Testarea securităţii, inclusiv testul de rezistenţă la intruziuni, dacă este cazul, se efectuează cel puţin pe toate noile versiuni importante ale software-ului, în conformitate cu cerinţele de securitate prevăzute în standardele tehnice de creare a legăturii, pentru a evalua securitatea legăturii şi riscurile aferente.
Dacă în ultimele 12 luni nu s-a produs nicio versiune importantă, se efectuează testul de securitate în sistemul curent, luând în considerare evoluţia ameninţărilor cibernetice din cursul ultimelor 12 luni.
Testarea securităţii legăturii între registre se efectuează în mediul de acceptare şi, dacă este necesar, în mediul de producţie şi cu coordonarea şi acordul reciproc ale ambelor părţi.
Testarea aplicaţiilor web va respecta standardele internaţionale deschise, cum ar fi cele elaborare de fundaţia Open Web Application Security Project (OWASP).
5.4.2.Infrastructură
Infrastructura care susţine sistemul de producţie este scanată în mod regulat împotriva vulnerabilităţilor (cel puţin o dată pe lună), iar vulnerabilităţile detectate sunt remediate pe baza aceluiaşi principiu definit în secţiunea precedentă, utilizând o bază de date actualizată a vulnerabilităţilor.
5.5.Dispoziţii privind evaluarea riscurilor
Dacă testul de rezistenţă la intruziuni este aplicabil, acesta trebuie inclus în testarea securităţii.
Fiecare parte poate contracta o societate specializată pentru efectuarea testelor de securitate, cu condiţia ca respectiva societate:
- să aibă competenţele şi experienţa necesare pentru efectuarea unor astfel de teste de securitate;
- să nu raporteze direct dezvoltatorului şi/sau contractantului său, să nu fie implicată în dezvoltarea software-ului legăturii şi nici să nu fie subcontractant al dezvoltatorului;
- să fi semnat un acord de confidenţialitate pentru păstrarea confidenţialităţii rezultatelor şi pentru gestionarea acestora la nivelul "SPECIAL HANDLING: ETS Critical " în conformitate cu instrucţiunile de gestionare.
Publicat în Jurnalul Oficial seria L din data de 5 iulie 2024