Change proposal CP-eHealthDSI-017 on TESTA - Tervise- ja heaolu infosüsteemide keskus

Failid

Sisu (failidest)

MEMORANDUM OF UNDERSTANDING between The European Union and the [FULL NAME OF THE NATIONAL ADMINISTRATION] on the quality and security requirements related to the connection to the TESTA-ng network set up under the ISA programme The European Union (hereinafter referred to as "the Union"), represented by the European Commission (hereinafter referred to as "the Commission"), which is represented for the purposes of the signature of this memorandum by Mr. Philippe Van Damme, Director C, Directorate-General for Informatics, Of the one part, and The [FULL NAME OF THE NATIONAL ADMINISTRATION] (hereinafter referred to as "SHORT NAME OF THE NATIONAL ADMINISTRATION"), which is represented for the purposes of the signature of this memorandum by [INSERT TITLE AND NAME], [INSERT FUNCTION], Of the other part, Whereas: 1. The ISA² programme is the follow-up programme to ISA, which ran from 2010-2015. The ISA² programme will run from 1 January 2016 until 31 December 2020 by Decision 2015/2240 of the European Parliament and of the Council of 25 November 2015 with the objectives to develop, maintain and promote a holistic approach to interoperability; to facilitate efficient and effective electronic cross-border or cross-sector interaction between European public administrations on the one hand, and between European public administrations and businesses and citizens on the other; to identify, create and operate interoperability solutions supporting the implementation of Union policies and activities; and to facilitate the re-use of interoperability solutions by European public administrations. 2. TESTA-ng (Trans-European Services for Telematics between Administrations – new generation) is a project developed in the form of a network service on the basis of article 3 of Decision No 922/2009/EC, in order to support the development of projects of common interest in the framework of Decision No 922/2009/EC and to provide a secure and reliable communication platform for the exchange of data between public administrations; 3. TESTA-ng is the successor of the “sTESTA” (Secure Trans-European Network Services for Telematics between Administrations) network service, established under the IDABC programme which came to an end on 31/12/2009 and which was succeeded by the ISA programme; 4. The objective of TESTA-ng is to deliver a secured, highly available and extendable, communication services for the benefit of the public administrations in Europe. 5. In this context, TESTA-ng provides a secured telecommunications infrastructure called the EuroDomain. Each competent administration is connected to the EuroDomain as a Local Domain; 6. Each Local Domain allows administrations to use a sectoral application, provided in the framework of trans-European communications between administrations and accessible through the EuroDomain; these administrations represent the TESTA-ng user community; 7. TESTA-ng is a secure and reliable communication infrastructure that interconnects networks of different administrations. It concerns Institutions, Bodies, Offices and Agencies established on the basis of the Treaty, the Administrations of the Member States or organisations acting on their behalf, the candidate countries, the EEA countries and international organisations. To guarantee the same overall service level between these competent administrations, a common understanding regarding the quality of services is required. 8. Agreement between the Commission and each competent administration might allow the definition of the minimum requirements on an appropriate level of quality and security for the TESTA-ng user community. 9. TESTA-ng is compliant with the relevant European legislation and standards for the protection of personnel data. 1 HAVE AGREED AS FOLLOWS: 1. This Memorandum of Understanding (MoU) establishes a co-operative working framework with the aim of making EuroDomain and Local Domains available to the TESTA-ng user community at a minimum mutually agreed quality and security level. Therefore, it is required that each party undertakes the necessary actions to inform its client administrations of their responsibilities in the context of this MoU. 2. The Commission will provide an infrastructure consisting of: a) the EuroDomain (between the Institutions, Bodies, Offices and Agencies established on the basis of the Treaty, the Administrations of the Member States, the candidate countries and the EEA countries) AND b) the Service and Operation Centre, providing helpdesk and support services to all connected sites AND 1 Directive 95/46/EC of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data; Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) - Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009 amending Directive 2002/22/EC on universal service and users’ rights relating to electronic communications networks and services, Directive 2002/58/EC concerning the processing of personal data and the protection of privacy in the electronic communications sector and Regulation (EC) No 2006/2004 on cooperation between national authorities responsible for the enforcement of consumer protection laws Regulation (EC) No 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data. [Page | 2] c) the central service domain CSD, providing central services like DNS, Mail Relay, Secured Mail, Web Cooperation Services, Secured FTP, NTP, time Stamping, PKI and portal services to all connected sites AND d) one TESTA-ng network access point per Member State - the Local Domain Connection Point (LDCP). The LDCP will be hosted by the competent Administration, according to specifications in Annexes I, II and III and applying the principles for the use of TESTA-ng by non-community projects described in Annex IV. Only infrastructure for the exchange of unclassified information is provided. 3. The [SHORT NAME OF THE NATIONAL ADMINISTRATION]: a) will provide an infrastructure ensuring access to the EuroDomain of the TESTA-ng user community for which it is responsible; b) will host the LDCP in accordance with Annex I; c) will apply all appropriate security measures in accordance with Annex III and will impose on any supported TESTA-ng users any conditions and sanctions necessary to protect the network; d) will provide the services detailed in Annex II in respect of the minimum quality and security requirements specified in Annex III; e) will designate an administrative contact person, a technical contact person and a security officer for all matters between the [SHORT NAME OF THE NATIONAL ADMINISTRATION] and the Commission related to the provision and functioning of the LDCP and communicate the details to the Commission as specified in Annex V; 4. Both the Commission and the [SHORT NAME OF THE NATIONAL ADMINISTRATION] a) will configure their respective part of the telecommunication infrastructure (hereinafter “domain”) so that the TESTA-ng user community may exchange information securely, reliably and efficiently; to this end, the Commission and the [SHORT NAME OF THE NATIONAL ADMINISTRATION] will apply and share minimum quality and security requirements as specified in Annexes I, II, III, IV and V and will inform one another in case of a higher available quality and security level; b) will take measures in order to facilitate the interoperability between the EuroDomain and the Local Domain; c) will provide a single point of contact for all questions related to the execution of this MoU and will communicate full details in Annex II and Annex V; d) will take all organisational, physical and logical security measures to maintain their domain in accordance with the security measures specified in Annex III; [Page | 3] e) will take all necessary security measures to avoid compromising the smooth operational functioning of the other’s domain; f) will communicate to one another any relevant information about concerns, plans, changes related to their domain and applicable physical access procedures; g) will consult one another to take into account new needs of the TESTA-ng user community or new technology and ensure the efficiency of the services referred in Annex II, adapting the capacity of their domain; h) will provide support services as referred to in Annex II related to any technical problem occurring in the execution of this MoU. i) will maintain a risk management plan related to their area of responsibility. 5. The following annexes form an integral part of this Memorandum of Understanding  Annex I: Infrastructure.  Annex II: Services.  Annex III: Security.  Annex IV: Applicable principles for the use of TESTA-ng by non community projects.  Annex V: Contact information.  Annex VI: Track file of non-Community projects using TESTA-ng.  Annex VII: Applicable processes and Quality Management. 6. This Memorandum of Understanding shall be applicable for the duration of the TESTA-ng network. SIGNATURES For the [SHORT NAME OF THE For the Commission, NATIONAL ADMINISTRATION] [TITLE AND NAME] Mr. Philippe VAN DAMME, [FUNTION] Director of Directorate C Directorate-General for Informatics, signature: _______________________ signature:_____________________ Done at ………………, on …………………. Done at ………... on …………………… In duplicate in English. [Page | 4] [Page | 5] Annex I Infrastructure 1 LDCP IDENTIFICATION This annex addresses the hardware and network infrastructure, hosted by the [SHORT NAME OF THE COMPETENT ADMINISTRATION] which forms the LDCP (Local Domain Connection Point). It describes the components, mutual responsibilities and related procedures. In case the LCDP is outsourced, the [SHORT NAME OF THE COMPETENT ADMINISTRATION] remains responsible to ensure the correct implementation of this MoU. The reference code to identify the LDCP is LDCP site reference: TAP Identification Number # It is located at [LCDP address, building, floor, room] 2 LDCP ARCHITECTURE AND ENVIRONMENT 2.1 Architecture elements The schema below aims at describing the components of the LDCP. Note: This schematic presentation must match the Local Domain connection at the moment of signature of the MoU. Remark: The integral TAP documentation has been provided together with the TAP. Option Single Site (Non Resilient TAP) Figure 1: Single Site (Non Resilient TAP) Page 2 of 25 2.2 Environmental conditions The minimum environmental conditions for the installation of a TESTA-ng TAP (Turnkey Access Point) in the LDCP are: Item Minimum condition Rack footprint including open door Rack footprint: 60x90 [cm] Space required for each door: +/- 60cm Rack height 200cm (42U) Rack weight After installation: < 250kg Power consumption Two independent power supplies secured with 20A fuses. If 20A is not available indicate which amperage is: [to be completed] The temperature, hygrometry, general conditions (dust) must be compatible with the normal use of the proposed equipment Telephone Communication infrastructure If mobile phone communications are not permitted or impossible in the TESTA-ng TAP room, a telephone must be made available in that room with international calls allowed. 3 RESPECTIVE RESPONSIBILITIES 3.1 Commission’s responsibilities The Commission provides all the architecture components and the communication links (cf section 2.1). 3.2 Administration’s responsibilities It is the responsibility of the [SHORT NAME OF THE COMPETENT ADMINISTRATION] to provide: – sufficient space in an appropriate secure room, – an adequate power supply, – a climate control system if appropriate, – a physical access control system, – a fire/smoke detection system, Page 3 of 25 – all cabling between the supplied TESTA-ng TAP rack and the Telco’s equipment, – telephone communication infrastructure if appropriate, – process descriptions defining the gain of physical and logical access for technicians to premises/buildings/rooms, – description of the transport tracks through premises/buildings for racks (ramps, stairs, elevators, doors, etc. ), – contact partners for shipment companies and technicians, – routs of telecommunication cables through premises/buildings from the entry point to the rack space. 4 RELATED PROCEDURES 4.1 Equipment ownership The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] remain the owners of their respective equipment. 4.2 Equipment maintenance and repair The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] are responsible for the maintenance and repair of their own equipment and for informing one another of any detected malfunction. 4.3 Access to equipment [Detailed description of procedure for obtaining physical access to the LDCP to be provided by the SHORT NAME OF THE COMPETENT ADMINISTRATION] 4.4 Equipment management The equipment owner is responsible for its configuration, monitoring, security and capacity planning. However, physical security and environmental standards have to be assured by the [SHORT NAME OF THE COMPETENT ADMINISTRATION]. Any modification in the domain of the Commission or of the [SHORT NAME OF THE COMPETENT ADMINISTRATION] that may have an impact on the other’s domain, must be described, announced and confirmed when implemented. The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree not to perform any kind of tests such as availability or performance testing, vulnerability scans or intrusions into the other’s domain without prior authorisation of the other party. Neither the Commission nor the [SHORT NAME OF THE COMPETENT ADMINISTRATION] will interfere with the other’s equipment, including Page 4 of 25 connecting or disconnecting cables, unless specifically instructed by an authorised agent of the other party unless in the case of an emergency. Any such emergency intervention must be immediately reported to the Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION]. No equipment supplied by the Commission may be moved or reconfigured by the [SHORT NAME OF THE COMPETENT ADMINISTRATION] or their agents. The [SHORT NAME OF THE COMPETENT ADMINISTRATION] will take reasonable steps to protect Commission equipment from damage by local technical interventions. Any such damage must be immediately reported to the Commission. Page 5 of 25 Annex II Services This annex relates to the TESTA-ng services provided by the Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] in order to guarantee a smooth cooperation. It describes the services, availability, service levels, responsibilities, procedures and support. 5 SERVICE PROVISION UNDER THE RESPONSIBILITY OF THE COMMISSION 5.1 Central Domain Services: – DNS: Each service provided by an individual Local Domain for use by another Local Domain will obtain a TESTA-ng registered IP address. This will be entered in the global Domain Name Server to facilitate the look-up of a TESTA-ng URL to obtain the corresponding IP address. – Mail Relay: A mail relay service in order to provide a secure way to exchange emails between different Local Domains connected to the EuroDomain. – Secured Mail: A messaging platform designed for TESTA-ng to exchange in a closed network without any connection to the Internet. – Web Cooperation Services: a web cooperation service that combines audio, video, and web conferencing in a single solution. This solution offers attendee roles such as hosts, alternate hosts, delegates, and attendees. – NTP: The NTP server is a Stratum 1 Time server using the TimeSync utility based on Network Time Protocol (NTP) to synchronize the time over the network. The time signal transmitted by the National Time Authority is the most precise time available, accurate to 1 second in 1,000,000 years. – Time Stamping: An independent time stamping service to sectorial applications in order to provide verifiable evidence of the date and time of an electronic transaction. – Secured FTP The FTP service allows TESTA-ng users to exchange and share documents and other files via a common shared disk space. This central generic FTP service is located on the TESTA-ng central platform and is only accessible from the TESTA-ng network with no interconnection with the public Internet. Access to the service is controlled via user identifier and password. – Web Portal: The TESTA-ng Portal is a web-based application that acts as a central information point for the TESTA-ng community whereby users are restricted to views of data within the web portal on a need to know basis. It contains access to documents and information that are disseminated on the sectorial applications and set of services that are accessible over the TESTA-ng network itself including configuration and network performance reports. Page 6 of 25 – PKI: a dedicated Public Key Infrastructure (PKI) for cross-border use in projects involving the trusted exchange of information between Member States and EU Institutions. A number of standard PKI services including the issuing of X.509v3 certificates via registration authorities – and for the authentication of individuals and/or machines is available. The PKI service will be located at the TESTA-ng central platform to issue certificates for: Encryption / Authentication / Digital signature / Identification / Time stamping. – Complementary services: The complementary services assist the continuous evolution of the TESTA-ng service. An initial set of complementary services is available within the TESTA-ng Service Catalogue. 5.2 Support 5.2.1 Monitoring The Commission will monitor – in real time - the performance of all the service components of its TESTA-ng services (availability of equipment, communication links and central generic services) and will produce monthly statistics and keep records. This information will be made available on the TESTA-ng portal. 5.2.2 Helpdesk The Commission will provide support in English via the SOC Helpdesk 24/7 via phone, mail and Web Portal. Note that only authorised callers (based on the site contact list on the web portal) are allowed to log an incident or retrieve status information. ITEM SPECIFICATION Name of Support facility SOC Helpdesk Description of the Services All TESTA-ng services Service hours 24 hours a day, 365 days a year Contact telephone number See Annex V. Contact email address Two mailboxes are available: one is reachable over the internet : See Annex V. The other is part of the dedicated e-mail services part of the TESTA-ng Central Domain Services offering: See Annex V. Other contact details As part of the web portal, the authorised people will be granted access to the ticketing systems’ web interface: See Annex V. Page 7 of 25 The [SHORT NAME OF THE COMPETENT ADMINISTRATION] is responsible for responding to users of its Local Domain who are not authorised to contact directly the central support of the Commission. Only issues concerning the EuroDomain, interconnections with the Local Domain or the Domain of another competent administration may be addressed to the Commission central support and these approaches must be made by the previously designated and authorised contacts at the [SHORT NAME OF THE COMPETENT ADMINISTRATION]'s support facility. 5.2.3 Service Availability The following contractual Service Level Agreements are in place between the Commission and the service provider. - “Adherence to Requirements” (SQI_ATR) = shows the TESTA-ng requirements implementation rate and it measures how close the accepted TESTA-ng is from the initial TESTA-ng. - “Adherence to the planning SLA” (SQI_ATP) = measure the slippage of the duration of a Work Package compared with the duration initially planned and agreed. - Service Support Indicators o SQI_RTSx (with x = 1, 2, 3 and 5) = to measure the average of the delay in the response time for Px incidents. o SQI_SRT - to calculate the average slippage by the SOC staff when it has to disseminate security patches / releases into TESTA-ng production environment. o SQI_SCU = to measures the average slippage in installing new security configurations. o SQI_RCTx (with x = 1, 2, 3 and 5) = to measure the average time to close Priority x Problems. o SQI_CITx (with x = 1, 2, 3 and 5) = to measure the average time to implement Priority x RfCs (once approved by the authorized parties). - “Availability of the services SLA” (SQI_xxxA) o SQI_xxxA where xxx is the Acronym of the Service (FTP, NTP, SMTP, DNS, WP, etc) = to measure the availability of the Services to the user. Whereas the limit is 99.85% (= more or less one hour per month). - ”Network Performance Indicator (NPI)” (SQI_NPI). - “Quality of Classes of Services”. o SQI_QoS_RTDx,SQI_QoS_PLx, SQI_QoS_JitRT Where x maybe „1“, “2“, “RT“ or„APP“ (proposed Classes of Service) to measure Page 8 of 25 the TESTA-ng End to End traffic quality of the related Class of Service based on IPSLA/RPM. The below table summarises the applicable SQIs: Incident Classification: Priority (Calculation weight) 1 - Extensive P1 P1 P2 P5 Impact Widespread (9) (29) (24) (19) (9) 2 - Significant P1 P2 P3 P5 Large (5) (25) (20) (15) (5) 3 – Moderate P2 P2 P3 P5 Limited (3) (23) (18) (13) (3) 4 - Minor P2 P3 P3 P5 Localized (0) (20) (15) (10) (0) 1-Critical 2-High 3-Medium 4-Low (20) (15) (10) (0) Urgency Priority Weight = Impact Weight + Urgency Weight Page 9 of 25 Priority Explanation Examples (Range) P1  Service is completely unusable and Complete service outage (more than 70% of site users Critical there is no workaround available to affected) keep the business function running Access Links/ IP Service: (e.g. by using paper instead of IT for  Complete failure of the site access incl. (instable) a period of time) backup (if available)  All or the main majority of active Hardware/Software (TAP): users are unable to use the service  Complete failure of the hardware or soft- ware/application Security Incident:  Successful intrusion on any system  Lost connectivity from the SOC to TESTA-ng services P2  Service is widely unavailable Massive service impact (between 40 to 70% of site High  There’s a high risk of total users affected) breakdown imminent Access Links/ IP Service:  A high percentage of the active users  Massive impact on performance or response times, are unable to use the service also if backup is active (e.g. backup bandwidth is smaller than regular bandwidth) Hardware/Software (TAP)  Massive impact of performance or response times (e.g. due to partial failure of hardware or software/application) Security Incident:  Port scanning on the firewalls targeting the critical servers (DNS, mail relay…)  Attempts of intrusion on critical servers P3  Function of the service is partly Moderate impact on service (between 10 to 40% of site Medium unavailable users affected)  Service is available but its Access Links/ IP Service: performance is reduced  Small period of time (minutes) with performance  A small number of active users are restrictions of the service. Operations of applications unable to use the service is possible, no service outage.  Redundancy or backup is fully operational, operation of applications is possible.  Redundancy or Backup does run completely (e.g. Backup replaces regular line completely, or vice versa)  Announced maintenance without objection by the customer Hardware/Software (TAP)  Minor impact of performance or response times  Announced maintenance without objection by the customer Security Incident:  Attempts to ‘zone transfer’ from the DNS  Spoof alert traffic on firewalls P5  Some component of a service Minor impact on service (less than 10% of site users Low dropped out having a small impact affected) or without impacting the function Access Links/ IP Service: Page 10 of 25 Priority Explanation Examples (Range) for the concrete business  A fully redundant component (e.g. storage for web  Some users are unable to use or service) broke down, which has no impact at all to partially use the service the end user of the service The delay in the response time for Px incidents is described in below table: Key event Target time frames Priority 1 Priority 2 Priority 3 Priority 5 Response time 5min 15min 1h 2h (Incident assignment accepted) The time to close Px Problems is described in below table: Average time to close Priority x Problems SQI Attributes SQI Attribute Description SQI ID: SQI_RCTx (with x = 1, 2, 3 and 5) SQI Description: These SQI measure the average time to close Priority x Problems Calculation formula: SQI_RCTx = Average (time to close PxProblems) Target: P1 = 4; P2 = 8; P3 = 16; P5 = 48 hours Applicability Period: TESTA NG operations period Key event Target time frames Priority 1 Priority 2 Priority 3 Priority 5 Time to close Priority x Problems 4hours 8hours 16hours 24hours 5.2.4 Planned Maintenance The availability targets above exclude the time necessary to execute the maintenance tasks provided that these are announced in due time and performed during the defined maintenance window. This maintenance window is defined as outside normal business hours or at the weekend. Any specific maintenance must be announced at least 10 days in advance. 5.2.5 Business Continuity Insurance The Commission will ensure Business Continuity Plans in compliance with the ISO 22301 International Standard and Business Continuity Institute Good Practice Guidelines, addressing the provision of alternative staff, accommodation and equipment to facilitate the continuity of the TESTA-ng Dedicated Services. Page 11 of 25 6 SERVICE PROVISION UNDER THE RESPONSIBILITY OF THE SHORT NAME OF THE COMPETENT ADMINISTRATION 6.1 Support The support facility (helpdesk) of the [SHORT NAME OF THE COMPETENT ADMINISTRATION] is responsible for providing first line of support for users on their Local Domain and they are the contact for the central TESTA-ng helpdesk. Note that the EuroDomain central helpdesk is only authorised to accept calls from recognised TESTA-ng coordinators, Local Domain Administration helpdesks, Project Officers and designated people from the Commission. Users must follow their local help procedures. This information (and any subsequent changes) must be provided to all users and to the Commission. If requested this information may be published on the TESTA-ng central services Portal which is accessible to all users. ITEM SPECIFICATION To be published on TESTA-ng Portal Name of Support facility See Annex V. See Annex V. Description of the Services See Annex V. See Annex V. Required user references See Annex V. See Annex V. Service hours See Annex V. See Annex V. Contact telephone number See Annex V. See Annex V. Contact email address See Annex V. See Annex V. Other contact details See Annex V. See Annex V. Page 12 of 25 Annex III Security The Commission intends to implement a TESTA-ng secured infrastructure for the exchange of non-classified information. The implementation of the classified network to exchange classified information “RESTREINT UE” according to article 2 of the Council Decision 2001/264/EC1 of 19 March 2001 adopting the Council’s security regulations as last amended by Commission Decision 2005/952/EC2 is not covered by the current TESTA-ng implementation. This annex addresses in general the minimum organisational, procedural, physical and logical security measures that must be put in place. Detailed information with regard to the security accreditation falls under the responsibility of the Security Accreditation Panel and is therefore not included in this MoU. Details about the roles and responsibilities of the involved administrations are detailed here below. 1 ORGANISATION The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree to: – Designate a responsible entity for the security management in their respective domain, communicate their contact information and ensure its availability to react to security threats; – Assume the responsibility for the security of their respective domains; – Ensure that the personnel having access to classified information fulfil the corresponding criteria of clearance. The [SHORT NAME OF THE COMPETENT ADMINISTRATION] agrees to: – Inform the administrations and agencies connected to the Local Domain about their responsibilities and measures to take in relation to security. 2 PROCEDURE The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree to put in place all appropriate measures and procedures on their respective domains to maintain the agreed minimum security requirements 1 OJ L 101, 11.4.2001, p1 2 OJ L 346, 29.12.2005, p18 Page 13 of 25 and facilitate the communication between the designated responsible entities of each domain. NOTE: No specific methodology is imposed; all procedures can be based on local procedures already in place. The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree to inform of the specific procedures in place at the Local Domain level related to the connection to the EuroDomain. These are:  A Risk Assessment procedure to: – identify and estimate potential threats related to the system;  An Audit and Review procedure to: – Check the correspondence between the implemented security measures and the security policy in application in their respective domains; – Control on a regular basis the integrity of system files, security parameters and granted authorisations; – Monitor log files to detect security breaches and intrusions. These log files must indicate the administrations which access the EuroDomain through their Local Domain, when they access it and be kept for 3 months; – Implement changes to avoid discovered security weaknesses following the Change Control procedure; – Authorise the performance of independent audits and reviews on the security measures at least once a year  A Change Control procedure that allows to: – Document and measure the impact of a change before its implementation; – Keep the other administrations informed of any changes that can affect the communication with and/or the security of the other administrations’ domains;  A Maintenance and Repair procedure to: – specify the rules and conditions to follow when maintenance and/or repair of equipment should be performed;  A Security Incident procedure to: – Define the reporting and escalation scheme; – Inform without delay the other administrations of any security breach that can have an adverse effect on the security of the other administrations; Page 14 of 25 – Define a disciplinary process to deal with security breaches. 3 PHYSICAL SECURITY Apart from the environmental conditions as specified within Annex I, the Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree that the following measures will be taken for the facilities hosting related to TESTA-ng equipment:  Enforce physical security to establish distinctive security perimeters and allowing detection of breaches;  Control access to these facilities and maintain a visitor register for tracing purposes;  Ensure that external people that are granted access to these premises are escorted by duly authorised staff of their respective organisation;  Ensure that equipment cannot be added, replaced or removed without prior authorisation of the designated responsible bodies. 4 DATA AND ACCESS SECURITY The Commission and the [SHORT NAME OF THE COMPETENT ADMINISTRATION] agree to apply logical controls. These controls are:  Control access to and from other network(s) interconnected to their respective Domain;  Ensure that people who are able to access the EuroDomain have been identified and authenticated.  Review the authorisation rights related to the access to the EuroDomain on their respective domains;  Handle the exchanged information across their respective domains in accordance with their classification level;  Keep the integrity of the transmitted information throughout their domains;  Ensure that the systems in use within their respective domains are kept up-to-date according to the vendor specifications (e.g. implementation of recommended patches);  Avoid compromising the domain of one another by malicious attacks coming from their respective domains;  Block unauthorised access to their respective domains. Page 15 of 25 5 BREACHES OF SECURITY AGREEMENT In the event that the Commission or the [SHORT NAME OF THE COMPETENT ADMINISTRATION] substantially deviates from the principles and concepts defined in this document for quality or security, the other party may take steps to protect its domain, including the severing of connections, until the issues have been resolved. If, in the view of [SHORT NAME OF THE COMPETENT ADMINISTRATION], a user connected via the Local Domain poses a risk to the quality or security of the network, the [SHORT NAME OF THE COMPETENT ADMINISTRATION] should take steps to protect its domain, including the severing of connections, until the issues have been resolved. The Commission shall put in place a policy in order to authenticate remote access, log it and protect the fixed network from any increased security risk from such access, as well as the system to implement this policy. 6 SECURITY LEVEL CLASSIFICATIONS For information, the following table sets out the EU security classifications and the corresponding national and other security classifications as defined by Commission Decision 2001/844/EC, ECSC, Euratom of 29 November 20013 and as last amended by Commission Decision 2006/548/EC, Euratom4. There are four official security classifications of the European Commission which are now invariable in all linguistic versions (i.e. not translated) and always appear in capital letters in quotes in the following form:  "RESTREINT UE",  "CONFIDENTIEL UE",  "SECRET UE",  "TRES SECRET UE/EU TOP SECRET". 3 OJ L 317, 3.12.2001, p.1 4 OJ L 215, 5.8.2006, p.38 Page 16 of 25 Annex IV APPLICABLE PRINCIPLES FOR THE USE OF TESTA-ng BY NON-COMMUNITY PROJECTS 1 PRINCIPLES A non-Community project is a project leading to information exchanges between administrations or to eGovernment services at a European level but whose legal basis is not or not directly deriving from a Community legal act. The use of the TESTA-ng network in the context of a non-Community project by Member States administrations or organisations acting on their behalf or international organisations can be envisaged in the legal framework of the ISA² programme Decision 2015/2240 under the following conditions that: (1) the Community budget shall not bear any extra cost because of the use of TESTA-ng by non-Community activities; (2) the aim of TESTA-ng, i.e. the delivery of reliable and secure data exchange services, shall not be compromised in the process. Consequently: – If extra costs are associated to the use of TESTA-ng by a non-Community project, such costs should be carried by the Member States and international organisations participating to the project. – ISA² can refuse a request to use TESTA-ng when there is a risk that such usage endangers the reliability or security of the network. ISA², after consultation of all relevant Community services, may also refuse the use of TESTA-ng to projects that are not in line with existing or proposed Community policies. 2 PRACTICAL MECHANISM Far a given non-Community project for which the use of the TESTA-ng network is considered, the participating Member State or international organisation submits a formal request to the Commission (ISA²). Assuming that the Commission allows the use of the TESTA-ng network infrastructure to this non-Community project, two technical situations must be distinguished: (1) One new direct connection to TESTA-ng is required by a national authority or international organisation taking part in the non-Community project, in which case the installation and recurring costs for this new connection are integrally and directly covered by the national authority or international organisation requiring it. Page 17 of 25 (2) A national authority or an international organisation taking part in the non- Community project wants to make use of an existing default connection to TESTA-ng paid by the Community budget (e.g. the TESTA-ng connection onto the national network). Two sub-cases can be distinguished: (a) The added non-Community project traffic neither requires an increase in bandwidth of the connection nor the addition of new networking equipments: as long as this is the case, no change in the costs charged by the network contractor to the Commission occurs, hence there is no impact on the Community budget and no financial participation from the national authority or international organisation is required. (b) The added non-Community traffic requires either an increase in bandwidth of the connection or the addition of new networking equipment: these changes will be reflected by an increase of the costs charged by the network contractor to the Commission. A financial participation based on the payment of a fixed amount from the national authority or international organisation is then necessary to avoid impact on Community budget: this amount will correspond to the cost increase generated over a year. The situation will be reconsidered on a yearly basis. The relevant financial procedures will be applicable when the payment of a financial participation is necessary. The fixed amount will be calculated according to the formula described below: P( y)  12  M ()  M () Where: - P(y) is the yearly fixed amount to be contributed - M (+) is the monthly cost of the connection after upgrade - M (-) is the monthly cost of the connection before upgrade As the case may be, an Annex VI to the Memorandum of Understanding will keep track of the non-Community projects moving or leaving the TESTA-ng network, the necessity of a financial participation and the corresponding fixed amount. Page 18 of 25 Annex V Contact information 1 TESTA-NG SOC HELPDESK Email#1: [email protected] Email#2 : [email protected] Phone: +49 69/426 965 3027 InterimWeb Portal : https://demo.portal.testa.eu Final Web Portal : https://portal.testa.eu 2 COMMISSION TESTA-NG PROJECT MANAGER Aldo Grech Email: [email protected] Phone: +32 2 297 39 94 3 COMMISSION TESTA-NG SECURITY OFFICER Pieter Wellens Email: [email protected] Phone: +32 2 299 29 88 Fax: +32 2 299 02 86 4 NATIONAL TESTA-NG COORDINATOR [to be completed] 5 TESTA-NG LDCP ADMINISTRATIVE CONTACT [to be completed] 6 TESTA-NG LDCP TECHNICAL CONTACT [to be completed] 7 TESTA-NG LDCP SECURITY OFFICER This person will also be the Local Registration Authority for the PKI services. Page 19 of 25 [to be completed] 8 LDCP TECHNICAL HELPDESK [to be completed] 9 LDCP SUPPORT HELPDESK (IF DIFFERENT THAN ITEM 8) ITEM SPECIFICATION To be published on TESTA-ng Portal Name of Support facility [to be completed] YES/NO Description of the Services [to be completed] YES/NO Required user references [to be completed] YES/NO Service hours [to be completed] YES/NO Contact telephone number [to be completed] YES/NO Contact email address [to be completed] YES/NO Other contact details [to be completed] YES/NO 7 LDCP CRISIS CONTACT [to be completed] Page 20 of 25 Annex VI Track file of non Community projects using TESTA-ng At the moment there are no community projects using TESTA-ng. Page 21 of 25 Annex VII APPLICABLE PROCESSES AND QUALITY MANAGEMENT 1. INTRODUCTION This annex provides a high level overview of all the documentation available within the TESTA Services environment, all based on ITIL V3. A copy of these processes can be requested to [email protected] . If any deviation to these processes is required, it will be documented in annex to the concerned process. 2. PROCESSES The following processes - in line with the contractual Service Level Agreements mentioned in Annex I – section 1.2.3. - are in place between the Commission and the service provider and are documented in the table below: Processes TESTA-ng Documents Incident Management D031-IncMgmtDes (HLD) D227-IncMgmt (LLD) Problem Management D037-ProbMgmtDesign (HLD) D233-ProbmMngt (LLD) Change Management D028-ChangeMgmtDesign ( HLD) D357-StandardChMLLD ( LLD) D229-ChMLLD ( LLD) T011-ChangeMgmtRfCTemplate D078-Change Catalogue Configuration Management D417-SOCITSMHLD D425-SOCITSMLLD D340-CMDB-Design D100-ConfigMgmt-HLD D339-Configuration-LLD I131-ConfigurationManagementWI I438-CustomerTAP-CMDB-Import Template(ITE) Release Management D079-RelMgmtDes-HLD D231-RelMgmt-LLD Service Level Management D045-SLMDesign-HLD D335-DIGIT-SLMLLD Security Management D010-SecurityManagementDesign + Information Security Management processes (2.1) Continuous Improvement D048-CSIDesign-HLD Management D338-WI-CSIDesign-LLD D419-ContinuousImprovementProcess-LLD D334-CSITrackingsheet Page 22 of 25 Processes TESTA-ng Documents Availability Management D047-AvaMgmtDes-HLD D337 AvaMngt-LLD Capacity Management D046-DIGITCapMan-HLD D336 CapManWI-LLD IT Service Continuity D217-ITSCManagementDesign-HLD Management D219-ITSCManagement-LLD Central Domain Services - D1037-CDSHLDServiceProcess-HLD Service Management D1093-CDSLLD-Mail Relay D1092-CDSLLD-FTP D1091-CDSLLD-DNS I114-CDSWI-NTP I040-CDSWI-Mail_Relay I053-CDSWI-FTP I037-CDSWI-DNS T017-CDS Service_FTP_ChangeRequest_form T015-CDS_Service_DNS_ChangeRequest_form T016-CDS_Service_Mail_Relay_ChangeRequest_form 2.1 INFORMATION SECURITY MANAGEMENT PROCESSES Processes TESTA-ng Documents 05_Security_policy D010-SecurityMgmtDesign D011-InfoSecPolicy D239-SOCSecurityTest/AuditPlan 06_Organization_of_information_security D012-OrganisationInformationSecurityPolicy D058-DataClassification&LabellingPolicy 07_Asset_management D051-AssetManagementSecurityPolicy D157-SecuredAssetDisposalProcedure D088-SecuredAssetDisposalPolicy 08_Human_resources_security D014-HumanResourcesSecurityPolicy 09_Physical_and_environmental_security D018-PhysicalEnvironmentalSecurityPolicy D025-PatchingPolicy D027-SystemHardeningPolicy D084-ModMedExpPol D085-MobilemediaUsagePolicy D144-LSEPhysicalSecuritySystemTecnicaDesign (IDS) D146-SOCIDSystemAwarenessTraining D147-LSEDataCenterAlarmsHandling D148-SOCKeyHandlingProcedure D149-SOCAlarmIncidentResponse D150-AlarmProcedure D151-SecurityGuards-instructions D152-SOCEvacuationProcedure D154-SOCDieselGeneratorAccessProcedures D155-SOCPermanentMediaExceptionList D159-SOCSafeAndKeyHandlingPolicyTrainingPolicy D160-SOCPhysicalZoneAccessPolicy Page 23 of 25 Processes TESTA-ng Documents 10_Communications_and_operations_man D056-CommunicationOperationsManagementSecurityPolicy agement D059-DIGITIntPrevDetPol D168-OffSiteStorage Policy 10_Communications_and_operations_man D064-SecCrypto USB & CardManagementPolicy agement/Crypto_operation D169-Crypto solution MgmtPlatformProcedures D170-MonthlyCardsReviewReport (cryptographic cards) D172-CryptoTransportationProcedure D173-SOCCryptocardInventoryStandard D174-CryptocardNamingConventionStandard D175-CryptocardRecordOfMovementStandard D177-SecCryptoCardRequestProcedure D178-CryptoMgtSystemsReviewWorkInstructions D180AddUserAccountOncryptoMgmtSystemworkinstructions D181-HowToConfigureAndWriteCryptoUSB 10_Communications_and_operations_man D066-SOCFirewallPolicy agement/Crypto_operationNetwork_contr D223-FWTrafficLogs/rule base monthly review ol_FW D225-IntPrevDetSOCOperating procedures D182-SOCJuniperMgtstation work instructions 10_Communications_and_operations_man D068-AntivirusPolicy agement/Security_controls D117-PatchingProcedureMSWindowsProd D119-LinuxHardeningProcess D164-Windows hardening D167-PatchingProcedureOracle D318-HPPatchingProcedure D120-PatchingProcedurelinux 10_Communications_and_operations_man D083-SafeAccessPolicy agement/Segregation_of_duties D090-SegregationofDutiesOverview (Policy) D183-LSESecurityManagementSystemPolicy D185 SOCSecurityOfficerManagementCycle 11_Access_control D015-AccessControlPolicy D061-PasswordPolicy D179-SOC Data Transfer procedures and WI D187-SEGofDutiesRoleSystemMap D188-SEGofDutiesServerandRolesMapping D188-SEGofDutyAccessControlMatrix D191-RackAccessProcedures D193-EmergencyOpeningRack&TAPS D195-SOC&LSEAccessControlProcedures 12_Information_systems_acquisitions_dev D055-SysAcqMainPol elopment__and_maintenance D077-RiskManagementPolicy D131ThreatsRepository D132-RiskRepository D200-VulnerabilityDashboard D201-SecuritySystemsOverview D202-FWVulnerabilityManagementProcess 13_Information_security_ D057-InformationSecurityIncidentManagementPolicy incident_management D133-ManagementOfSecurityIncidentsprocedures 14_Business_continuity_management D075-BusinessContinuityManagementPolicy D206-BusinessContinuityPlan D211-BCMBusinessImpactAnalysis D134-BCM-BIAIntroWS D204-DIGITSecurityRolesResponsibilities D205-TESTABCMIntroduction & training D207-RiskManagementTrainingDocument D208-BCMSOCHumanResourcePlan D209-BCMBronzeteamRolesandResponsibilities D210-TESTABCMEscalationMatrix D212-BCMExercisePlanningExecution D213-BCMRiskAssessment Page 24 of 25 Processes TESTA-ng Documents D214-CoreManagementCrisisManagementPlan D215-LOCAL_DRP(data centers,SOC,CSD)Technical Design D216-BCM_ContactDetails 15_Compliance D096-InformationSecurityCompliancePolicy D107-AcceptableUsePolicy 3. SLA PARAMETERS AND REPORTING MANAGEMENT The SLA parameters and reporting management aspects are covered in the Service Level Management and Reporting processes. In line with the contractual Service Level Agreements mentioned in Annex I – section 1.2.3. – the following reports are in place between the Commission and the service provider – they can be accessible via a Web Portal, in a secured area only accessible for authorised individuals. Reports Documents Service Daily Reporting The Daily Report is to give information about the TESTA-ng (SDR) network availability and performance by providing average and peak RTD (round trip delay)and PLR (packet loss) values by measuring RTD and PLR on the links between various TESTA- ng TAPs and the monitoring infrastructure. If voice and/or video services are requested average and peak jitter values must also be reported. (TESTA-ng_Daily_DIGIT/DGHome_YYYY/MM/DD.pptx) Service Weekly Service Weekly Report focuses on the weekly activities of the Reporting (SWR) SOC and includes the following aspects: – Incidents week ww/yyyy – Problems week ww/yyyy – RfCs follow-up on Week ww/yyyy (Weekly-Report_DIGIT_CWxx_201x.pptx) Service Monthly The SMR is a monthly report presenting in details the TESTA Reporting (SMR) NG activities and achievements including statistics about these activities compared with the applicable SLA. (TESTA-ng-D443-SMRTMM201X-YYYYMMDD.docx) Monthly Management The Dashboard is a synthetic presentation of the TESTA NG Dashboard monthly activities described in more details in the Service Monthly Report (TESTA-ng-D444-DIGITDashboardMMYY.pptx) Ad-hoc Report The Ad-hoc Report is used to urgently report findings and solutions related to important issues / incidents being processed on a fast track which short-cuts the normal reporting cycle. Page 25 of 25 EUROPEAN COMMISSION DIRECTORATE-GENERAL FOR HEALTH AND FOOD SAFETY Resource management and better regulation Information systems Brussels, June 13th, 2017 HB NOTE TO EHOMB MANDATORY USE OF TESTA-NG FOR E-HEALTH DSI Following the security assessment of the current proposal for the e-Health DSI set up, it has been decided to advance with the technical feasibility study on moving the exchange procedure to the TESTA-ng Network. As a result, it has now been proven that the use of the TESTA-ng network is technically feasible. Taking into account the sensitivity of the data involved, this is now considered a mandatory technical change to be made to the e-Health DSI infrastructure. Without TESTA-ng, the security of the most sensitive data (on the scale of the European Data Protection) cannot be guaranteed. More importantly, a Member State NCP connected via TESTA-ng, is the most efficient way of assuring that the network security requirements are correctly implemented and auditable in a controlled manner. In addition, Member States can trust that the national requirements and the European requirements are correctly implemented. TESTA-ng has an auditing service that can assure ISO 27001 compliance. The CEF programme strongly endorses and supports the use of TESTA-ng and funds many of the implementations. This decision might, but doesn't have to, cause a delay in the delivery and deployment of the eHealth DSI. However, in terms of risk management, and proper IT management, the only way to proceed forward with this project is to deploy the eHealth DSI over the TESTA-ng infrastructure, hence this decision. The eHDSI Solution Provider proposes the eHOMB to adopt this change request and communicated to eHDSI Countries as soon as possible. eHDSI Solution Provider. DG SANTE/A4 – Herman BRAND Annexes (4): I - Rationale for move to TESTA-ng II - Comparison of Topologies III - State of Play TESTA-ng connectivity for EU countries IV - Reference Documents 1 ANNEX I – RATIONALE FOR MOVE TO TESTA-NG. In the past months we have been increasingly concerned about the eHDSI feasibility and security aspects of the private OpenVPN "over the Internet" solution promoted by the previous studies of epSOS & EXPAND and pursued as a de facto solution during the eHDSI project. The solution still under development relies on the infrastructure of the open Internet and on each Member State to build services around this infrastructure. The current release has undergone lenient testing with a number of relaxations while excluding authorised certificates and VPN services, and having still open security vulnerabilities [R03]. A more rigorous security testing with more than three interconnected countries and with the full solution deployed has not been yet performed, increasing our concerns of security risks such as private/medical data theft, denial of service attacks and hijacking sessions. All this in view of the highly sensitive data in terms of confidentiality and integrity classification [R02] From a security and service point of view this OpenVPN solution may result to high impacting business and operational risks. With this solution each MS is responsible for managing every operational and security aspect around the OpenVPN itself while each of the MS has to trust and rely on all MS that infrastructure and underlying software is kept updated and secure. This again increases the complexity in keeping secure the communications and increases on the MS the operational burden. For the above reasons we engaged with the TESTA-ng Solution Provider for investigating the option to move the eHealth national contact points (eHNCP's) to the TESTA-ng VPN infrastructure and service network instead. The TESTA-ng network is a proven, operational and secure infrastructure with guaranteed service and performance levels. The infrastructure and security provisions can ensure protection, if required, up to a confidentiality level of "Restreint EU". Currently it supports EU institutions, agencies and their bodies, through secured connectivity exchange of data and interoperability for more than 100 applications, many of which require a high level of security for high sensitive and critical data. During the cooperation of Unit A4 and the TESTA-ng team on the Proof of Concept, we managed to reduce significantly the complexity of the OpenVPN envisaged solution in comparison to the use of the TESTA-ng. In addition, besides the compliance achieved with the eHealth security requirements and security policies, simplifications for the MS mean simpler certificate management, existing service and security procedures, and minimum effort for audit and testing compliance. From the actual implementation status of the countries, we see that almost half of them withdraw their application of joining the pre-operational network this year while mentioning readiness delays. Few countries already expressed their satisfaction to move to TESTA-ng as it is a more stable, easier to maintain, secure and reliable solution. It is true that the readiness requirements require a high effort for preparing robust services, organisational structures and information security provisions around the infrastructure till the end of this summer for the first wave countries wishing to be operational in 2018. 2 TESTA-ng is a fitting solution due to the service and security compliance with the eHDSI audit readiness criteria. TESTA-ng covers fully the ITILv3 best practice model and the international information security standard ISO 27001 whereas the national implementations struggle already to put in place part of the aforementioned standards requirements. Finally, by using TESTA-ng both DG SANTE and the Member States show their commitment towards the European wide efforts for rationalisation, cost-effectiveness and interoperability of systems and infrastructure under the ISA² program. We have been challenged to compare a mature, proven, secure and reliable platform with a solution that is currently under-construction. Unless there is no commitment and validation by Member States of a successful, fully proven implementation of the necessary interoperability structures, services and security, we do not see any technical impediment in promoting the move to the TESTA-ng solution at this moment. 3 ANNEX II COMPARISON OF TOPOLOGIES NCPVPN - TESTA 4 5 6 ANNEXE III STATE OF PLAY TESTA-NG CONNECTIVITY FOR EU COUNTRIES The current state of play of OpenNCP's connected to TESTA-ng (either directly or via their national network) On a total of 27 Locations in 26 countries: o 14 locations connected to their respective National Networks (implicitly to TESTA) o 6 locations not yet connected to their respective National Networks (implicitly to TESTA) but possible (mainly national administrative/technical processes). - Priority 1 countries: Luxembourg / Sweden - Priority 2 countries: Belgium (2 locations) / Latvia / Poland o 1 location not connected - Priority 1 country: Germany (due to private entity Gematik being identified as NCPeH) o 6 locations for which no address was received - Priority 1 countries: Cyprus / Estonia / Greece / Italy / Switzerland - Priority 2 country: Netherlands This would mean that - at this stage of the investigation (without considering the 6 addresses of the Priority 1 countries that are not known to us) - and unless there is a change in Germany of the selected entity (or a special authorisation from the participating ministries (BMG/BMI) to authorise them access to their National Administrative Network) - a TESTA budget would need to be foreseen to implement a dedicated TESTA Access point for Germany. Commission européenne/Europese Commissie, 1049 Bruxelles/Brussel, BELGIQUE/BELGIË - Tel. +32 22991111 ANNEXE IV REFERENCE DOCUMENTS (4 DOCUMENTS) Available on request: [R01] D3.4.2 Common components specification [R03] EC TESTAng MoU Annex VII Applicable Processes and Quality Management Highly sensitive documents, for which a request for access with justification will have to be examined by the EC services. [R02] KER3-STR-DG_SANTE_01-RISK_ANALYSIS, Version 1.03, Approval Date: 29/09/2015 [R04] OpenVPN Common Vulnerabilities and Exposures study, openvpnCVE.docx --- End of document --- 8 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA Proof of Concept (PoC) Instruction Guide for the National Network – [MS] (TESTA PoC Instruction Guide - eHDSI - V18_20170703 – [MS]) 1. INTRODUCTION The European Commission DG SANTE together with DIGIT is currently seeking synergies to investigate the possibility to connect the National Contact Points for eHealth (NCPeH) to the TESTA network infrastructure deployed in the National Administrations. The possibility of connecting the NCPeH in each country using TESTA raises a set of questions spanning from legal to technical matters. As a result, a Proof of Concept (PoC) exercise, with a very restrict group of countries, is proposed to clearly identify the most prominent questions and possible solutions. This initial step might be followed by other phases (to be determined later on), namely by extending the number of countries involved. In order to make this PoC to run smoothly, it is recommended an initial conference call with your Country Experts (NCPeH and TESTA) and DIGIT technical colleagues. This call will be organised during the following weeks. Should you have any comments or questions, please address them to the DIGIT TESTA functional email address ([email protected]), copy to SANTE-EHEALTH- [email protected] and [email protected]. 2. OBJECTIVE OF THE POC (Test 1) The objective of the PoC is to evaluate the connectivity between the National Contact Points for eHealth (NCPeH) t[MS] ough the TESTA network. This test will require slight configuration in order to route the traffic from one network to another and it will be fully conducted under the supervision of DG SANTE and DIGIT. (Test 2) In the PoC the NCPeH shall use the new Central Configuration Service (SMP) and Central Terminology Service, to identify and resolve any possible issues (e.g. certificates handling). This PoC will use a test environment and will simulate eHealth traffic from the National eHealth Infrastructure Agency only and will not impact the daily operational services and production traffic of the National Contact Points for eHealth (NCPeH). European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 1 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA 3. ROUTING CONFIGURATION The following scheme & table provide additional details on IP / host names / certificates and workflows (see also the step by step configuration diagram in ANNEX 1 document and the Certificates Flow Diagram in ANNEX 2). The scheme below depicts the situation as-is. The following scheme illustrates what is intended to be tested. European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 2 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA Asset Protocol DNS name/ Business Identifiers Private IP @ TESTA IP @ See separate See separate file file NCP (A & B) http / https ncp.[MS].ehealth.testa.eu NCP Portal -- National Infrastructure component, requires access to the NCP services. SMP Editor http / https NCP component NCP NCP TSAM-Sync http / https NCP component, requires access to NCP NCP Terminology Server API SMP http / https smp-cert-auth-test.publisher.ehealth.testa.eu Registration End-Point SMP http / https smp-test.publisher.ehealth.testa.eu Operation End-Point Terminology http webgate.acceptance.ec.testa.eu/ehealth- Server Portal term-portal/ Terminology http webgate.acceptance.ec.testa.eu/ehealth- Server API term-server Flows Source Destination Protocols Comments/Remarks SMP Registration NCP (SMP SMP Server https Editor) SMP Operation NCP SMP Server https NCP to NCP NCP B NCP A (in a https different country) Terminology NCP (TSAM- Terminology Server https Sync[MS] Sync) API onisation Terminology Desktop in Terminology Server https Limitation: only Server Portal country A Portal accessible for desktop computers connected to TESTA. European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 3 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA 4. TASKS The following tasks should be followed: Actions Owner Comments Requested Elapsed Time 1 Ensure to track - in a specific file - all changes that will be TESTA 15/05/2017 to 19/06/2017 introduced for this PoC. This is key to ensure proper fallback SPOC and avoid any disruption of services. 2 Routing configuration Route to be configured (if not existing) between NCPeH firewall TESTA IP xxx and TESTA TAP 62.62.0.0/17 (see above third diagram). SPOC In case Natting is used inside your Member States, the corresponding NCPeH firewall IP address facing TESTA should be communicated to DIGIT. 3 Firewalls configuration Rules to be configured in the National Network firewall(s) facing TESTA TESTA TAP and Firewall facing NCPeH 'Trust Zone 1” (if SPOC different). See above table in section 3 for technical details. 3.1 Request NCPeH Certificates by preparing the CRF attaching the NCPeH See CRF form attached European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 4 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA Actions Owner Comments Requested Elapsed Time CSR and submit to TESTA Team 4 TEST 1 to be performed 4.1 Test the Path between NCPeH to the TESTA Portal: NCPeH See below outcome. 15-05-2017 to 19-06-2017 - 62.62.69.1 and 62.62.70.1 - https://demo.portal.testa.eu - nslookup/dig to local DNS server and try to resolve demo.portal.testa.eu (A record) TEST 2 to be performed 4.2 Test connectivity with Configuration Services NCPeH - Prerequisite: certificates 03/07/2017 to 10/07/2017 - Registration Operation (upload country A info) - prepare SMP file in OPenNCP Gateway ([MS] NCP) - Please consult the NCP manual: https://ec.europa.eu/cefdigital /wiki/x/pyCtAg - register the NCP in the SMP file ([MS] NCP) European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 5 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA Actions Owner Comments Requested Elapsed Time - provide credentials of [MS] to SMP server (DG SANTE) 4.3 Test connectivity with Terminology Server Portal (e.g. login, NCPeH Prerequisite: 03/07/2017 to 10/07/2017 download and upload files) - Requires CTS credentials - Publish MTC to unblock test 4.4. via the Portal (NCP [MS] ) - Acceptance environment needs to be updated (DG SANTE) 4.4 Test connectivity between the NCPeH and Central Terminology NCPeH Prerequisite: Requires CTS 03/07/2017 to 10/07/2017 Services (sync terminologies repository) credentials Configure the NCP with credentials for acceptance environment (NCP [MS] ) 4.5 Test NCPeH to NCPeH connectivity Requires NCPeH identifier 10/07/2017 to 14/07/2017 Requires certificates - Operations (seek for other countries info) Open the FW rules to the - Establish connection with other NCP (network ping) other NCPeH TESTA IP European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 6 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA Actions Owner Comments Requested Elapsed Time addresses (or to the full subnet) 4.6 Test NCPeH to NCPeH workflow – Patient Identification (XCPD) Requires certificates 10/07/2017 to 14/07/2017 5 Provide test output (Ping, Telnet 443) – see chapter 5. 6 Removal of PoC configuration and revert to initial setup 7 Test Closure SANTE / 31/07/2017 DIGIT 8 PoC outcome SANTE / 31/07/2017 DIGIT 5. TEST RESULTS Please insert the screenshot in this section (or in separate file) of the test results with regards to TEST 1 (Ping or Telnet Port) and TEST 2: TEST 1: 1) Connect to 62.62.69.1 and 62.62.70.1  [MS] Evidence  Provide evidence here. European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 7 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA 2) Connect to https://demo.portal.testa.eu  [MS] Evidence  Provide evidence here. 3) nslookup/dig to local DNS server and try to resolve demo.portal.testa.eu (A record)  [MS] Evidence  Provide evidence here. TEST 2:  Test 4.2: Test connectivity with Configuration Services o Success Criteria:  Login in OpenNCP Gateway and prepare [MS] SMP File  Sign [MS] SMP File with signature certificate  Upload SMP file to SMP server o [MS] Evidence  Provide evidence here.  Test 4.3: Test connectivity with Terminology Server Portal (e.g. login, download and upload files) o Success Criteria:  Login as translator: download and upload translations (screenshot successful upload)  Login as National Responsible: Publish MTC (print screen of PDF 1st page) European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 8 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA o [MS] Evidence  Provide evidence here.  Test 4.4: Test connectivity between the NCPeH and Central Terminology Services (sync terminologies repository) o Success Criteria:  Authenticate your NCPeH (TSAM-Sync) in CTS API.  Download [MS] MTC (published by National responsible) o [MS] Evidence  Provide evidence here.  Test 4.5: Test NCPeH to NCPeH connectivity o Success Criteria:  Download [MS] configuration information  Use that information to configure the OpenNCP  Establish connectivity with [MS] NCPeH (network ping) o [MS] Evidence  Provide evidence here.  Test 4.6: Test NCPeH to NCPeH workflow – Patient Identification (XCPD) o Success Criteria:  Provide XCPD request and response messages , as well as audit log. o [MS] Evidence  Provide evidence here. European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 9 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 10 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Directorate D – Trans-European Services DIGIT D3 – TESTA 6. CONTACTS DURING THE POC Name Mail DG/Service Role Sophie Devleeschouwer [email protected] EC DIGIT TESTA-ng Stakeholder Manager Quentin Van Vyve [email protected] EC DIGIT/ASSIST TESTA-ng Technical Consultant Michel Vandekerckhove [email protected] EC DIGIT/ASSIST TESTA-ng Technical Consultant Thierry Laurent [email protected] EC DIGIT/ASSIST TESTA-ng Security Consultant Jean-Marie MISZTELA [email protected] DG SANTE Project Officer Yacoubou WAOLANY [email protected]; DG SANTE Technical Expert Panagiota.PARONI [email protected] DG SANTE Technical Expert Licinio Kustra Mano [email protected] DG SANTE Project Manager Igor Ljubi igor.ljubi@hzzo.[MS] NCPeH ([MS] ) Croatian Health Insurance Fund, Technical Services Division (HZZO) Božo Zeba Bozo.Zeba@uprava.[MS] TESTA TAP ([MS] NN [MS] ) Mladen Kobilšek mladen.kobilsek@fina.[MS] TESTA TAP ([MS] NN [MS] –FINA(Financijska agencija) European Commission, B-1049 Brussels - Belgium. Telephone: (32-2) 299 11 11. Page 11 eHealth DSI – Change Proposal (CP) form Instructions This is the template to propose change s to eHealth DSI Specifications documents. The C hange Proposal provides the description of what must be done (for changed or newly implemented services) . CPs should be submitted to the eHealth DSI Change Manager until a tool will be put in place to follow the Change Proposal Status and they will be managed according to eHealth DSI Change P roposal Procedure . Tracking information: Change Proposal ID : CP- eHealthDSI -0 17 Change Proposal Status : In Registration Date of last update: 2017-0 7 - 2 5 Person assigned: [email protected] Version of Change Propo s al : 0. 9 Change Proposal Summary information: Change eHDSI connecti vity channel from IPSec VPN to TESTA Submitter’s Name(s) and e-mail address(es): eHDSI Solution Provider Submission Date: 2017-0 7 - 25 Component(s) or Configuration item(s) to be changed : NCPeH to NCPeH VPN connections , as well as connection with Central Services Actor(s) affected: NCPeH (Deploying Countries) Specifications/documentation impacted: Specifications, Certificates Profiles, Audit Framework, Test Framework, Operations Plan Change estimated impact (minor, major) : Major Reason/Business justification for the Change Proposal: Following the security assessment of the e-Health DSI set up, it has been decided to advance with the technical feasibility study on moving the exchange procedure to the TESTA-ng Network. The TESTA-ng Network (Trans-European Services for Telematics between Administrations – new generation), as described in the following documents (MoU and annexes), is a, communication platform to exchange electronic data and provides a secure and reliable telecommunications service layer and infrastructure. The technical feasibility study (announced beforehand) includes a technical Proof of Concept ( PoC ) that is already in progress. Current findings of the PoC demonstrate that the use of TESTA-ng network is technically feasible ( confirmation of connection from NCPeH infrastructure to TESTA sites, and confirmation of connecting NCPeH to Central Services) . Final results of the PoC are expected by July 28, 2017. Detailed information about the Proof of Concept can be found in the following document: Taking into account the sensitivity of the data involved, this is now considered a mandatory technical change to be made to the e-Health DSI infrastructure. More importantly, a Member State NCP connected via TESTA-ng, is the most efficient way of assuring that the network security requirements are correctly implemented , monitored and controlled and auditable. In addition, Member States can trust that the national requirements and the European requirements are correctly implemented. TESTA-ng implements security controls and services that are compliant with ISO 27001/27002 and ITIL best practices respectively . The CEF programme strongly endorses and supports the use of TESTA-ng and funds many of the implementations. This decision will cause a delay in the delivery and deployment of the eHealth DSI (namely by postponing the go live from Feb. to Jun. 2018) . Overall deployment should be adjusted to accommodate any impacts resulting from this decision and other constraints faced by eHDSI (e.g. Audit Framework implementation) . However, in terms of risk management, and proper IT management, the only way to proceed forward with this project is to deploy the eHealth DSI over the TESTA-ng infrastructure, hence this decision. Further rationale available in the following info note, presented to eHMSEG and eHOMB during June 2017. Cha nge Proposal Document history : Version Date Person Short descrip tion of changes V0.1 2017-06-20 eHDSI Solution Provider Initial version based on eHOMB and eHMSEG note V0.2 2017-06-21 eHDSI Solution Provider Added "What needs to be changed" V0.3 2017- 07 -04 eHDSI Solution Provider Organisational and financial impacts V0.4 2017- 07 -05 eHDSI Solution Provider Update on TESTA existing locations V0.5 2017- 07 -05 eHDSI Solution Provider Updated PoC status Updated "Certificates profile" impact Updated "Deployment guide " impact Updated "Overall Deployment" V0.6 2017- 07 -05 eHDSI Solution Provider Study proposal for NCPeH not connected to the country National Network and by that not able to reach TESTA Additional documents on TESTA (MoU and SLA) V0.7 2017-07- 19 eHDSI Solution Provider Text consolidation improvements following eHMSEG TESTA TF kick-off meeting V0.8 2017-07-24 eHDSI Solution Provider Text consolidation with feedback received from eHMSEG TESTA TF V0.9 2017-07-25 Christophe DUMONT Check the CP and Assign the Change Proposal ID ASSESSMENT (as foreseen in the 2 nd step of the eHDSI CP procedure) Author Assessment Recommended actions Followed-up actions (by Change Manager) WHAT NEED S TO BE CHANGED Specifications Materials Audit trail Profiles : Remove the reference to the IPSec in the "2.3.6 Non Repudiation Evidence" chapter Interoper ability specification : Replace the reference to the VPN in the "6.3 eHealth DSI trusted Node Infrastructure & Message Transportation" chapter Establish the principle of all connectivity (between NCPeH or with Central Services) must happen under TESTA enabled connectivity . (An exception should be considered regarding the Central Terminology Service portal, for sake of usability and accessibility) Mes saging Profile : Replace the reference to the VPN in the "1.1 eHealth DSI Secure Messaging Infrastructure" chapter Remove the reference to IPSec as standard in the "1.2 Messaging and Transportation Standard Stack" chapter Remove the "3.1 IPSec Configuration" chapter NCPEH Comp onents specification : Review the introduction of the "4. eHealth DSI Communication and Messaging Infrastructure" chapter to remove the reference to VPN Remove the "4.1.1 IPSec Configuration" chapter Remove the reference to VPN in the xml examples Remove the reference to IPSec as standard in the "4.1 Audit Trail Implementation" chapter Section II – security Services : Re place the "5.5.2.1 IPSec (Network Layer Security" chapter by the TESTA-ng solution Replace the IPSec by TESTA-ng in the "5.6 Evaluation of the Alternatives" chapter or remove the chapter because alternatives don't have to be part of the Specifications Replace the VPN by TESTA-ng in the "5.8 Option Presentation" chapter Review security requirements regarding NCPeH infrastructure and TESTA infrastructure Review security requirements regarding NCPeH infrastructure towards the Health Portal provided by each country to end users (health professionals) Review Trust-Zones description and requirements Replace references to TLS 1.0, as TLS 1.2 should be used. Review chapters 5.5.2.3 SOAP Message Security and 5.5.2.4 Application Layer Security as they refer to standards not used in the actual implementation Service Location and Capability Lookup : Re place the reference to the VPN in the "3.1.5 NCP Provider Identification" chapter Replace the reference to the VPN and IPSec in the "3.1.6 NCP Provider Identification" chapter Remove the "4.1.1VPN Gateway Status Information" chapter Central Terminologies Service s Add the clarification that access (for users and NCPeH) will only be available under TESTA connected network nodes. This measure may have special impact on the Users (National Terminology Experts) requirements when accessing the Central terminology Services for semantic related operations (e.g. download MVC, upload translations, and publish MTC). Relaxation of this security measure should be considered, namely by adopting measures that promote usability (easier access from users) and keeping at same time reasonably security measures that may avoid major threats. System Architecture specification : Replace the "6.5.5 IPSec VPN network Layer" chapter by the TESTA-ng solution Remove the reference to the IPSec disseminated in the document X.509 Certificate Profile : Remove the IPSec certificate profile in the intro of the "3 eHealth DSI Certificate Profiles" chapter Remove the "3.3 Certificate Profile: IPSec Certificates" chapter Update the TLS and Signature (e-Seal) certificates specifications Audit F ramework Update the audit Checklists, namely in what concerns to the IT security controls Test Framework Update the CERTIFICATES validator Add a relaxation for September 2017 PAT: not need to use of TESTA or VPN connections Add a next test event in December 2017, specifically to test TESTA connectivity. Deployment Guide Remove the V P N Client and VPN Server Certificates info from the table of the "3.3.1 Certif i cates" chapter Add "move to TESTA" chapter providing instruction and guidelines on all the organisational and technical aspects to have in consideration while performing this change (at Country level) , namely how to securely connect national infrastructure in both directions from NCP eH . The content of this chapter should also be available in eHDSI operations wiki. Add clarifications/requirements regarding the Acceptance, Pre-Production Testing and Operation environments In case eHDSI X509 certificates are issued centrally by EC, the procedure must be clearly described in this document. eHDSI Service Catalogue, Delivery and Overall Deployment ) Adjust TEST and AUD I T procedures to accommodate the introduction of TESTA with blocking planned testing sessions . Post pone the Go Live deadline (for Wave 1) from Feb-2018 to May-2018. Analyse how the Go Live Procedure defined by eHN JA (JAseHN) can be applied and candidate new timings. Understand if there is any impact on Wave 2 Go Live date and, as consequence, Wave 2 artefacts Release Candidate and Operation Ready release dates. LEGAL IMPACT From a legal point a view there are a set of aspects that require further clarification and confirmation, namely: How to apply the possible requirement of segregated communication channels regarding high sensitivity data (e.g. clinical data, between NCPeH) from configuration data (e.g. configuration and terminology, between NCPeH and Central Services). Confirm that TESTA agreement/MoU and network nodes do note constrain, in any way, the type of content or users that may rely on this network infrastructure for cross border exchange of clinical data. Confirm that no further legal provisions are needed taking in consider ation the eHDSI Agreement and the General Data Protection Regulation, related with the usage of TESTA network ORGANISATIONAL IMPACT From an organisational point of view, the move to TESTA implies the establishment of a relation between the NCPeH (entity and infrastructure) and the country national competent responsible for hosting the national TESTA -ng infrastructure. Meaning that, the NCPeH must establish (if not already present) a connection with the national authority responsible for the national TESTA -ng infrastructure and operate according to the defined requirements, specifications and procedures as they are defined in the TESTA-ng MoU and the accompanying Annexes . This protocol is a national activity (i.e. Generic Service) meaning that the NCPeH Deploying Country has full autonomy to precede with this liaison activity without requir ing further intervention from the eHDSI Core Services. FINAN C IAL IMPACT The move from IPSec VPNs to TESTA may also entail financial impact in certain eHDSI Deploying Countries where a new connection set-up will be necessary . The following table aims at depicting the possible budget which may occure in underlying certain situations . Impact / Scenario a) NCPeH connected to country National Administration network b) NCPeH hosted by Third Party not connected to Country National Administration network SET UP (pay only once) No costs ( regarding TESTA per se ) But network configuration HR effort should be foreseen Charge will vary from 72.000,00 € to 90.000,00 € according to country Network configuration HR effort should be foreseen OPERATION (monthly fee) To be agreed with TESTA National Competent Authority Charge will vary from 2.000,00 € to 6.000,00 € according to country C ore Services budget should be assessed whether it can be reinforced and re-distributed toward the new TESTA infrastructure and reducing this way the financial burden and complexity from the previous NCPeH connection solution. CURRENT SITUATION IN eHDSI Countries In the scope of the Proof of Concept an assessment is being conducted regarding the eHDSI Countries situation. The current (2017-07- 24 ) outcomes of this assessment are the following: On a total of 27 Locations (NCPeH responsible entity site) in 26 countries: Locations connected to their respective National Networks (implicitly to TESTA) Locations not yet connected to their respective National Networks (implicitly to TESTA) but possible (mainly national administrative/technical processes) Locations not connected locations for which no address was received Priority 1 Portugal Finland Czech Republic Croatia Malta Hungary Ireland Austria Cyprus France Luxembourg Sweden Switzerland Germany (due to private entity Gematik being identified as NCPeH) Estonia Greece Italy Priority 2 Spain Romania Bulgaria Slovakia Slovenia Belgium (2 locations) Latvia Poland Netherlands TOTAL 1 4 locations 8 locations 1 location 4 locations This would mean that - at this stage of the investigation (without considering the 3 addresses of the Priority 1 countries that are not known to eHDSI ) – the situation in Germany requires further study and impact analysis. A study should be conducted in order to fully understand the impact and alternatives in countries where the NCPeH l ocation is not connected to their respective National Networks and, by that, not able to reach the TESTA -ng access point directly.

Allikas: Tervise- ja heaolu infosüsteemide keskus dokumendiregister →