roche remote solutions privacy, security and connectivity€¦ · 3 1 purpose the purpose of this...

Roche Remote Solutions Privacy, Security and

Connectivity

Frequently Asked Questions for global users of Roche Remote Solutions

2

Table of Content

1 Purpose 32 FAQ on Remote Solutions Use Cases 32.1 Use case overview 32.2 Privacy Considerations 43 Technical FAQ for individual Remote Service products 83.1 Network settings required on the customer side 83.2 How should the customer LAN be protected? 83.3 Axeda ServiceLink and Axeda Agent / RVA 93.4 Laboratory Systems with built-in RVA gateway 123.5 cobas® link – hardware gateway 133.6 connect 2 – hardware gateway 174 Appendix A – Connectivity Checklist 195 Appendix B – Data transfer generated by Hitachi analyzers

and transferred to Roche via cobas® link 206 Appendix C – B2B VPN information 247 Appendix D – List of terms & definitions 26

3

1 Purpose

The purpose of this document is to describe the technical connectivity, privacy and security of Roche Remote Solutions. Organizational solutions for regulatory compliance mentioned in this document are suggestions only – local country organizations consulted by Remote Service are responsible for their own implementation.Protection of laboratory systems is not within the scope of Remote Solutions, but is the responsibility of the respective organizational unit that is in charge of developing and maintaining the respective laboratory system; details can be obtained from the respective laboratory system documentation.

2 FAQ on Remote Solutions Use Cases

2.1 Use case overview

What is Roche Remote Solutions?Remote Solutions is an integral part of the Roche service infrastructure to enable remote access capabilities, e.g. for remote user support and error analysis, and other use cases such as distribution of instructions for use and software from Roche to customer systems, and device data transfer and analytics. Remote service is a combination of hardware and software tools that enable a secure connection between any Roche business application and the devices installed on the premises of Roche’s customers.

Fire

wal

l

Fire

wal

l

RocheCustomer Support

AxedaServiceLink Firewall

InternetGlobal Access Servers Firewall Customer Laboratory

Use case overview:• Remote screen sharing and monitoring software (Axeda ServiceLink, TSN)• Customized Axeda agent (Roche Vanilla Agent), part of laboratory system software• cobas® link, hardware gateway placed in customer laboratory, for screen sharing plus data transfer

for electronic product information distribution / e-library and device data analytics.• connect 2 hardware gateway placed in customer laboratory, for screen sharing

What are the benefits of Roche Remote Solutions online capabilities compared to offline operation? Connecting a Roche system online via Remote Solutions will enable a wide range of benefits in comparison to operating the same system offline:

4

Online scenario enables higher uptime and reduced downtime • Proactive monitoring before problems occur:

Option to detect and repair potential issues before a part breaks, replacing emergency (disruptive) interventions for scheduled interventions

• When problems occur: Automatic notification sent to Roche Support Remote repair may be feasible Reduced time to repair Improved phone fix rate/first fix rate

Time savings and greater efficiency for Roche systems operated onlineBringing a system online will enable automatic update – no more physical software update CDs, no more printing of package inserts and user manuals required. Less time needed to “explain” problems to call center agents as the agents can see the instrument status or even the local screen on their own.

What are the main components of the Remote Solutions infrastructure?The Remote Solutions platform consists of both hardware and software client and server components:• The Axeda platform hosting is outsourced to the Axeda/PTC Corporation, a 3rd party company, and is subject

to regular security-related procedures of the Roche IT organization (e.g. penetration tests by independent consultants).

• Axeda Global Access Servers are required by the Axeda ServiceLink application to provide efficient screen sharing sessions world-wide. connect 2, Roche Vanilla Agent and cobas® link are Roche communication gateways.

• connect 2 and cobas® link consist of Roche-hardware, whereas the Roche Vanilla Agent is a software component integrated into Roche laboratory systems.

• Teleservice-Net is hosted with Roche in-house.• The Remote Service Data Warehouse (RSDW) is hosted with Roche in-house; it is an xml file repository for

short-term storage of laboratory system data (e.g. monitoring information) transferred from customer. This data is then made available to other Roche business applications.

RSDW is an xml file repository for short-term storage. Application consumers, e.g. business applications receiving data from RSDW, can consume the stored data.

2.2 Privacy Considerations

How does Roche protect customer privacy?A universal standard on processing personal data and contractual agreements with third parties adopted by all Roche companies has been established to provide preventive safeguards against infringement of privacy rights through inappropriate processing of personal data.

Roche has stated that compliance with data privacy laws while processing personal data is a corporate objective. As such, Roche is committed to respecting the personal rights and privacy of individuals. The Roche Directive on the Protection of Personal Data can be found at http://www.roche.com, keyword “directive protection personal data”.

http://www.roche.com

5

How is privacy assured during transmissions between the laboratory and the Remote Service infrastructure at Roche?For the connection between the remote system and the Axeda Enterprise infrastructure, privacy requirements are met by encryption mechanisms. In general, no unencrypted data may be exchanged:• Between the Enterprise systems and the remote system• Within the Remote Service Platform in the Roche Corporate Network and the Axeda On Demand Center• Between any 3rd party involved in the communication• In the network of the healthcare organization

Is privacy ensured during screen sharing sessions?A screen sharing session may be necessary to troubleshoot and restore a system to its full working condition. This usually occurs after a customer notifies the Roche call center about a problem or a Roche employee contacts the customer via phone after observing system behavior indicating non-compliance.During this screen sharing session it may be necessary to access the system screen with sample information, which may contain laboratory-specific comments related to a patient.Customers in countries where regulations do not consider incidental use concepts should avoid system access or transferring any comments related to patient identity from the LIS unless regulatory and respective data privacy requirements are met (e.g. patients consent).This also applies to specific requests for access to the system/LIS communication trace file.

What kind of patient information will be handled by Roche?Personal data generally does not contain individually identifiable medical information (patient name, ID, etc.) which would allow tracking back to and identifying a patient. During a screen sharing session, it may be necessary in rare cases to access the system screen with sample information, which may contain laboratory-specific comments related to a patient.

Can collected data be tracked to individual systems?Yes, all systems are equipped with individual serial numbers. In order to assign data to specific system types for subsequent analysis, it is essential to clearly identify the systems that generated the information.

How does Roche ensure the privacy of customer information?The data used for monitoring system performance does not contain individually identifiable medical information (patient name, ID, etc.). In addition, only data related to de-identified patient information is transferred from the system to the gateway (e.g. cobas® link). De-identification is performed by removing all comment fields related to a sample that could be used by the laboratory for storing patient information before the data leaves the system.

Who is authorized to access the Remote Service Platform systems?The Remote Service Platform systems are equipped with a user management system. Only authorized Roche users have access to these systems. Users accessing the application from a computer are always authenticated based on their Roche active directory credentials and must be in the Roche network. Access is given on a country level, e.g. people working for the Swiss Roche affiliate will only be able to access systems in Switzerland.For support purposes, employees working in Roche global functions are granted credentials to access data of all countries.

6

How does the customer know when a Roche user accesses cobas® link?The screen sharing application icon changes its color and logs are generated on the platform. The enterprise system generates an audit log for all remote access attempts. Remote access to cobas® link, RVA enabled system, or connect 2 does not require any end user confirmation.

How does the customer know when a Roche user accesses a gateway/system/instrument?This depends on the system/instrument configuration. For most systems, a local confirmation is necessary (pop-up window to be approved by customer), to allow screen sharing.

What happens with the instrument data collected?Data collected by Roche is used for subsequent analysis (e.g. system/test performance) and stored according to best business practices and in compliance with applicable laws and regulations.See “Data transferred between Laboratory and Roche” for details.

Where is the system information/data stored?In the context of the Remote Service Platform, Roche stores all information in secure datacenters in compliance with applicable laws and regulations. Data stored in external hosting centers is subject to the same regulations as data stored in Roche-hosted data centers.

The diagram and descriptions below depict different environments from where data can be collected and/or stored by Roche:

AxedaGlobal Access Servers

H

Axeda EnterpriseInfrastructure

G

Axeda On Demand Center

TSN Infrastructure

F

Remote ServiceData Warehouse

E

Roche User PC

D

Roche Diagnostics

connect 2(connectivity gateway)

C

cobas® link (connectivity gateway)

B

System

System

A

a

a

a

Laboratory/ Hospital

A) Depending on the system which generates the data, storage duration and archiving varies. B) The cobas® link can store backups (configuration information) generated by some system types. System

(Test-)Performance relevant information, alarm data and other information is forwarded to the Enterprise infrastructure on a daily basis (E, F).

C) The connect 2 gateway cannot store any system data. It is designed as a gateway for screen sharing only.

7

D) The Roche User PC does not receive, forward or store any system generated data. Data collected during screen sharing sessions may be transferred manually to the customer relationship management software for troubleshooting purposes.

E) Monitoring data collected by the gateway (e.g. cobas® link) is temporary stored in the Remote Service Data Warehouse (RSDW) according to business best practices.

F) Monitoring data collected by the gateway (e.g. cobas® link) is permanently stored in the TSN Infrastructure. G) Uploaded system information & files and management data is collected and stored in the Axeda Enterprise

system. H) The Global Access servers are not storing any data. They act as communication broker for screen sharing

sessions only.

Where are the Remote Solutions components located?Axeda Solution:The Axeda Enterprise system is physically located in the following locations in a shared hosting center, which is not part of the Roche network: • Enterprise Germany, Frankfurt• Disaster Enterprise Waltham, Massachusetts

The Global Access Servers are physically located at three different sites:• EMEA Germany, Frankfurt• NALA Waltham, Massachusetts• APAC China, Hong Kong

The hardware and software for Axeda is outsourced to the Axeda/PTC Corporation, which is a 3rd party company and hence, not part of Roche. The user interface (UI) of Axeda ServiceLink can be accessed by authorized Roche users via a leased line (between Roche network and PTC datacenter in Frankfurt). The customized Axeda agent on the instruments connects to the DMZ of the PTC datacenter in Frankfurt.

Roche server hardware:The Remote Service Data Warehouse and the TSN (TeleServiceNet) infrastructure are located within the Roche corporate network in Switzerland.

Roche gateways:Gateways such as cobas® link, connect 2 and RVA (customized Axeda Agent) are located at customer site.

8

3 Technical FAQ for individual Remote Service products

3.1 Network settings required on the customer side

DNS information is required for the service to function properly. The IP address of DNS servers is usually provided automatically by a customer’s DHCP server.If no DNS service is available, manual configuration via the systems host file is required.

Description IP Hostname Port Protocol

Domain Name Service customer specific

customer specific 53 TCP/DNS

Note: For Windows system, the host file is located at: C:\”windir”\system32\drivers\etc\hosts, where “windir” is the Windows installation folder.Please refer to “Appendix A – Connectivity Checklist”, listing the connectivity parameters that need to be agreed upon between customer and Roche

3.2 How should the customer LAN be protected?

It is the customer’s responsibility to ensure that the customer LAN is secure and protected (e.g. firewall, NAT firewall and physical access). The following security requirements should be met:1. Outgoing connections from Roche systems and gateways are allowed to the IP addresses requested by

Roche, using the specified ports and protocols; see IP address tables in the Axeda and TSN section.2. Customer network best security practices are highly recommended:

a. Use authorized network equipment including but not limited to the following: access points, routers, switches, cables, computers, and various network components

b. Only authorized personnel are allowed to administer and configure networking equipment c. Customer network access is logged and monitoredd. The customer network should be separated and protected from the Internet with at least one firewall or

router.e. The customer LAN should use IP addresses in the private IP range or IP addresses owned by the

customer.If any of the above requirements are not met, Roche laboratory systems and gateways should not be connected to the customer LAN.

Note: Some Roche gateways such as cobas® link or connect 2 are designed to be connected directly to the Internet or a DMZ, independent from a customer LAN, via 3G connectivity.Some laboratory systems have additional connectivity requirements (e.g. connection to LIS or to a network printer) which may require additional firewalls or connections. These connections and information on mandatory firewall use are specific for each Roche analyzer model and are explained in the respective manual; hence this is not covered here.

9

How should the Customer WiFi network be protected?It is the customer’s responsibility to ensure that the customer wireless LAN is secure and protected (e.g. firewall, NAT firewall). The following security requirements should be met:1. It is strongly recommended to use WPA2 with a strong password as wireless encryption 2. Use of any wireless node as wireless hotspot is not recommended3. Use best practices for wireless protected access 4. In case other devices are sharing the customer WiFi, they should be properly protected as well

In case any of the above requirements are not met, Roche laboratory systems and gateways should not be connected to the customer wireless LAN.

3.3 Axeda ServiceLink and Axeda Agent / RVA

Axeda Connectivity Diagram Steps to establish a screen sharing session:Customer calls the country’s support desk to report an issue or to ask for support. A Roche Service Representative (RSR) connects to the Roche network. RSR logs into Axeda ServiceLink, brings up the instrument in question, and initiates a screen sharing session. The secure (encrypted) session to the instrument is established as follows: 1. The Roche Vanilla Agent residing on the laboratory system initiates an outbound call to the Global Access

Server (GAS) on port 4432. A connection between the RSR PC and the Global Access Server (GAS) is established on port 4433. The Global Access Server links these 2 connections in order to establish a secure (encrypted) tunnel

Encrypted AXEDA Tunnel

Roche User

Roche Vanilla Agent connecting to Global Access Server

Roche user connecting to Global Access Server

cobas® link (hardwaregateway)

System #1

System #n

FortiGate firewall(recommended)

a

Global AccessServers

1 2

3

Which Axeda software establishes connectivity to the Roche Corporate Network?The following components establish connectivity to the Axeda platform: • Customized Axeda Agent software which is an integrated part of the connect 2 and cobas® link hardware

gateway• Customized Axeda agent is also available as software gateway installed on the laboratory system computer

10

Which IP addresses, ports and protocols are required to establish connectivity to Axeda?The following communication protocols are required for Axeda:For the communication between the components involved in the Axeda solution (Gateway, GAS, Enterprise and Roche user PC) the following are used:• HTTPS protocol with Encrypted payload. The Axeda Gateway Agent initiates all communication between

devices and the Enterprise Server. • It sends XML-formatted data to the Enterprise Server through HTTP POSTs. After receiving a message, the

Enterprise Server can reply to the agent with SOAP-formatted data. This response message can contain commands for the agent.

The following IP addresses and ports must be accessible from the customer’s infrastructure to ensure that the Axeda solution can operate as expected:


Axeda On Demand Center (ODC) infrastructure

Axeda Enterprise ODC 62.209.44.11 remoteservice.roche.com 443 TCP/SSL

Axeda DR Enterprise ODC 209.202.167.21 remoteservice-dr.roche.com 443 TCP/SSL

Axeda GAS1 ODC (EMEA) 62.209.44.21 remoteservice-gas1.roche.com 443 TCP/SSL


Axeda GAS3 ODC (NALA) 209.202.167.19 remoteservice-gas3.roche.com 443 TCP/SSL


Axeda GAS5 ODC (APAC) 120.136.45.231 remoteservice-gas5.roche.com 443 TCP/SSL


Axeda settings in case of a proxyThe customized Axeda Agent (part of Roche Vanilla Agent) is proxy aware. HTTP and SOCKS proxy incl. authentication with username and password is supported. If there is a Proxy Server in place at the customer site, the Axeda solution needs outgoing connectivity to the proxy server, only. All traffic is directly redirected from the Roche Vanilla Agent to the customer’s proxy. While establishing the connection, the Roche Vanilla agent informs the proxy about the final destination. This behavior is valid for any type of Axeda installation. The following picture shows a schematic example for a proxy installation:

Proxy Servermy.proxy.com:8080

Connections to:Roche Axeda SystemsPort 443 / SSL

a

a

System

System

FortiGate 40Cfirewall (recommended)

connect 2

11

Protection of the Roche and Axeda enterprise infrastructureThe section below provides questions and answers regarding user access and the audit trail of the Roche/Axeda enterprise infrastructure. General protection (e.g. network protection) of the infrastructure is not part of this documentation.

How is user access to the Axeda enterprise application controlled?Access to the Axeda application is controlled by the Roche active directory authentication and role-based authorization in the Remote Service database. Access to the Axeda application is limited to Roche employees or designated 3rd parties contracted by Roche in certain countries.

Roles in the Axeda application:• Remote access user • Manage device role to register new devices• Country visibility role• Global visibility role

Are the actions performed on the enterprise infrastructure audited?Regular reports of the remote access sessions audit trail may be supplied to the healthcare organization on request.The access rights of the authorized person can be traced over time.

For remote access with Axeda, the following information is stored in Axeda ServiceLink:• Roche user ID• Date/time of the session start and end• Remotely accessed system (e.g. cobas® link and system/instrument serial number)• Type of the session, PCAnywhere, Axeda Desktop Server• Session status, etc.

How is the security of the Axeda On Demand Centers ensured?Axeda follows best practices for security and complies with Roche guidelines, the product is certified. Details can be found on http://www.ptc.com/axeda/product/security.

Axeda itself holds the following certifications:• ISO27001 and are working toward SOC 2 Type 2.

They have FedRAMP, but not for the Boston or Frankfurt datacenter.

For the Boston datacenter:• ISO27001• SSAE16 SOC 1 Type 2• SSAE16 SOC 2 Type 2

For the Frankfurt datacenter:• ISO9001, 14001, 18001, 27001, 50001• SSAE16 SOC 1 type II• ISAE3402

Processes between Axeda and Roche are defined to ensure that security measures are in place.Roche performs security assessments (incl. vendor audit) of the hosting infrastructure.

http://www.ptc.com/axeda/product/security

12

What is the Axeda server patching policy? Who is responsible for the Axeda server security?The Axeda hosting center is in charge of maintaining their servers according industry standards, and Roche regularly checks for applicable security updates in collaboration with Axeda / PTC. Updates are tested before deployment to ensure proper functionality.

How is it ensured the Axeda Agent is not used on a non-Roche system? The agent needs to have a Roche root certificate to be able to connect to Axeda ServiceLink. Furthermore, the device has to be registered on Axeda ServiceLink by an authorized Roche user.

SSL handshake requirementsDuring the establishment of the secured connection between the Roche Vanilla agent and the Enterprise system, an SSL handshake is performed. During this handshake, the client and the server agree on an encryption standard and exchange certificates.

The platform enforces the following cipher suite for Roche Vanilla Agents 2.0 and 2.1: Cipher Spec: “TLS_RSA_WITH_AES_128_CBC_SHA”.The customer infrastructure must be configured to allow Hello packages including responses.

CertificatesCertificates are necessary for the SSL handshake. The Roche Remote platform Axeda ServiceLink is based on Roche certificates. These certificates can be obtained publicly from the Roche Certificate Authority from: http://certinfo.roche.com/

Prevention systems such as firewalls, proxies or content filters may not allow communication until these certificates are manually loaded as trusted certificates into these systems.

3.4 Laboratory Systems with built-in RVA gateway

A Roche laboratory system can be the destination of remote sessions by an RSR, and can be the source or destination for data transfer. The remote client software RVA can also be directly integrated into the laboratory system; in this case, no hardware gateway such as cobas® link or connect 2 are required.

Protection of Roche Vanilla Agent (RVA)The section below provides further details about the Roche Vanilla Agent. The protection of laboratory systems in which the Roche Vanilla Agent is installed is not part of this documentation and Remote Service is not responsible for their protection.

How is network access to the Roche Vanilla Agent protected?Protection of systems hosting the Roche Vanilla Agent is not within the scope of the RVA.Details can be obtained from the respective system/instrument documentation.

How is user access to the Roche Vanilla Agent protected?The RVA is a separate component designed to be installed on qualified Roche systems, and user access is not within the scope of the RVA. The user access to RVA is part of the system on which the RVA is installed. Access can be restricted, e.g. by Windows user login. Remote access is controlled via role-based access privileges to the Axeda ServiceLink application.

http://certinfo.roche.com

13

Is the Roche Vanilla Agent protected against viruses and worms, and malware in general?The RVA is a separate component designed to be installed on qualified Roche systems, which are able to handle malware protection with appropriate measures. Antivirus protection is not within the scope of the RVA. In case of security findings, the RVA can be updated remotely. Antivirus protection is within the scope of the Roche Instrument team where the RVA was installed. See sections “Protection of cobas® link” and “Protection of connect 2”.

How frequently is the Roche Vanilla Agent updated?Roche will update the Roche Vanilla Agent only if necessary, based on Axeda updates and risk ratings; hence there is no fixed update schedule.

How are security patches being handled for RVA? Remote Service regularly checks for applicable security updates. Updates are tested before deployment to ensure proper functionality.As the RVA is a separate component designed to be installed on qualified Roche systems, security patching of the underlying system is not within the scope of the RVA. In case of security findings, the RVA can be updated remotely.

How is the security of the Roche Vanilla Agent tested?Roche is using standard Axeda client components (Axeda Agent, Axeda Gateway, UltraVNC) for the Roche Vanilla Agent.Axeda is VeriSign security certified; details can be obtained from the Axeda website.

Are user actions performed with the Roche Vanilla Agent being logged?Remote screen sharing activities using an RVA is logged in Axeda ServiceLink, server side.

3.5 cobas® link – hardware gateway

Protection of cobas® linkThe section below provides further details about cobas® link. Protection of laboratory systems connected to cobas® link is not part of this documentation and Remote Service is not responsible for their protection. Physical protection of cobas® link must be ensured by the customer.

How is network access to cobas® link protected?cobas® link has some hardening mechanisms in place. For instance, it has a security-relevant configuration applied to the BIOS, account groups/policies, system components and interfaces.cobas® link is protected using security policies of the operating system. On the network interface towards Roche, only IPs, ports & protocols required for the communication by the Remote Service applications are authorized. It is recommended not to use the wireless interface on cobas® link because the security policies of the operating system fail to provide the required security controls. Furthermore it is recommended to exclusively operate cobas® link in a secure customer network environment.As an additional hardware, a FortiGate firewall is recommended if no customer firewall is in place. It is also recommended for enhanced protection even if there is a customer firewall placed in between.

14

How is user access to cobas® link protected?cobas® link has defined special user classes for specific use cases. The local administrator login password is distributed only to selected, specially authorized employees of Roche Diagnostics.Dedicated users for the customer are predefined. The password can be chosen and changed by the customer at any time.Remote access is controlled via role-based access privileges to the Axeda ServiceLink and the Remote Service Remote Help Desk application.

Is cobas® link protected against viruses and worms (malware in general)?Every cobas® link is equipped with antivirus software and an automatic update of the virus signature files is performed regularly.

Is the software on cobas® link regularly updated?Roche updates the operating system and related software components with the current security patches published by the corresponding vendors (Microsoft, etc.), if necessary on a periodic schedule.Distribution of virus definitions is performed using the Symantec Live Update functionality on a regular basis. Due to the additional testing performed, virus definition deployment is delayed up to two weeks, yet immediate emergency deployment is possible.

How are security patches handled?Remote Service is regularly checking for applicable security updates for cobas® link.Updates are tested before deployment to ensure proper functionality.

How is the security of cobas® link tested?In the event of major product changes, cobas® link has undergone several penetration tests by independent 3rd party companies. The scope of these penetration tests has covered the entire Remote Service infrastructure.

Which software on cobas® link establishes connectivity to Roche network?The following two software components on cobas link establish connections:• Customized Axeda Agent software, which is an integrated part of cobas® link hardware gateway.• Roche Connectivity Layer (RCL) software, which is the gateway software that is specific for cobas® link

15

What is the Roche Connectivity Layer and Teleservice-Net? The Roche Connectivity Layer solution is available for the cobas® link only.

The communication pathway assumes fixed connection between the laboratory intranet and Internet. This communication pathway may be used for bi-directional data transfer between the RCL software and the TSN infrastructure. The communication is originated from the cobas® link. The Symantec Antivirus Endpoint Protection LiveUpdate initiates a connection from the cobas® link to keep the virus definitions up to date. This is performed using the already existing LAN connection.

Lab connected via LAN / Internet Roche Diagnostics

TeleServiceDB & AppServers

Communication is originated in this direction.

Fire

wal

l

Fire

wal

l

Ente

rpris

e Sy

stem

s

Cust

omer

fire

wal

l

Lab

Intra

net

cobas® link (connectivitygateway)

InternetInstrument

Instrument

FortiGate 40Cfirewall(recommended)

DMZConnectivity

What is Teleservice-Net?Teleservice-Net distributes the e-library packages and patches to cobas® link. TSN DMZ collects data gathered from Hitachi instruments and uploaded by cobas links located in the customer network, and forwards that data to other Roche business applications; refer to “Appendix B – Data Transfer generated by Hitachi analyzers and transferred to Roche via cobas link” for further details on the included data.

How is user access to the TSN application controlled?Access to the TSN application is controlled by the Roche active directory authentication and role-based authorization within the TSN database. Access to the TSN application is limited to Roche employees or designated 3rd parties contracted by Roche in certain countries.

Roles in the TSN application:• Country User• Country Registration Manager• Global User• Global Registration Manager

Certificate checksSince cobas® link has several Roche certificates installed, the operating system automatically connects to certinfo.roche.com on port 80 and 443 to verify revocation information.

cobas® link specific requirements• cobas® link is supporting any type of IP-Address: DHCP or fixed.• cobas® link is configured as a workgroup PC. (Domain membership is not supported).

16

Which IP addresses, ports and protocols are required to establish connectivity from cobas® link to TSN and Axeda? Communication protocols and IP addresses required for Teleservice-NetFor the communication between cobas® link and Teleservice-DMZ Connectivity Server, the following protocols are used. This connection is specific for the RCL software running on cobas® link.

• HTTP/BITS with encrypted payload (for download): If BITS is blocked, allback to pure HTTP is performed. This service is for e-library and patches download.

• HTTP/SOAP with encrypted payload (for upload): This service is for monitoring data upload.• HTTP with signed payload (for download): This service is for virus definition download.

HTTP Tunnel/Web Tunnel.

Use case: The “Web Tunnel” uses the HTTP protocol with secure payload for data transfer in both directions (Lab <> Roche). It means the payload consists of encrypted, signed and compressed data. The data is in form of SOAP objects based on the XML definition proprietary for Roche/Hitachi content.

Symantec Endpoint Protection virus definitions are digitally signed by Symantec and transferred unencrypted via HTTP. Antivirus malware definitions are tested by Remote Service and deployed afterwards to cobas® links worldwide in regular weekly to bi-weekly intervals. Immediate emergency deployment is possible.

The following IP addresses and ports must be accessible from the customer’s infrastructure to ensure that the Roche Connectivity Layer (RCL) can operate as expected:

For e-Library data using Teleservice-Net:In order the Roche Connectivity Layer (RCL) is operating as expected, the following requirements must be met by the customer’s infrastructure.


TeleService DMZ 196.3.50.39 teleservice.roche.com 80 TCP/HTTP

TeleService DMZ 196.3.50.39 teleservice.roche.com 443 TCP/SSL

Content Filter requirementsThe RCL software is transporting encrypted data via port 80. Content filter must not block this communication in order the system works as expected.Proxies can be configured for Web-Tunnel (HTTP) connections.The following is also required to ensure operation of the RCL:• HTTP request/answer with binary payload• HTTP/SOAP for data upload (ZIP/XML files)• HTTP/BITS for data download (ZIP/EXE/TXT files)• HTTP downloads for Symantec antivirus definition updates (m25/m30/7z/x01/irn/ZIP files)

TSN connectivity settings in case of a proxyThe RCL software on cobas® link is proxy-aware and can be configured to connect to the TSN DMZ via a proxy.

17

Communication protocols and IP addresses required for Axeda:For the communication between the components involved in the Axeda solution (Gateway, GAS, Enterprise and Roche user PC) the following are used:• HTTPS protocol with encrypted payload. The Axeda Gateway Agent initiates all communication between














3.6 connect 2 – hardware gateway

Protection of connect 2The section below provides questions and answers about connect 2. The protection of systems connected to connect 2 is not part of this documentation and Remote Service is not responsible for their protection. Physical protection of connect 2 must be ensured by the customer.

How is network access to connect 2 protected?connect 2 contains a tailored Linux and password protected BIOS (i.e. it has a security-relevant configuration of BIOS, system components & interfaces.)connect 2 is protected against unauthorized network access using Linux port filtering. On the network interface towards Roche, only IPs, ports & protocols that are required by the Remote Service applications for communication are authorized.

How is user access to connect 2 protected?connect 2 requires a valid Roche certificate to access its Web Interface.connect 2 only allows for Web Interface access via SSL (encrypted).Remote access is controlled via role-based access privileges to the Axeda ServiceLink application.

Is connect 2 protected against viruses and worms (malware in general)?Yes, connect 2 is protected against viruses and worms (malware in general) by highly secured interfaces. The risk of infection on connect 2 is mitigated by a tailored Linux and a write-protected system partition. connect 2 does not include any CD/DVD or USB access.

18

Is the software on connect 2 regularly updated?Roche updates the operating system and related software components periodically with the current security patches published by the corresponding vendors if necessary.The regular process of distribution of the patches is automatic. However, in certain cases it may be manually performed remotely or locally.

How are security patches handled?Remote Service regularly checks for applicable security updates. Updates are tested before deployment to ensure proper functionality.

How is the security of connect 2 tested?Roche conducts penetration tests for connect 2 periodically, i.e. in the event of major product changes. The scope of the penetration test was related to the connect 2 device as such.

Is a notification generated when a Roche user accesses connect 2?No. connect 2 is not – and cannot be – equipped with any screen to display remote actions. connect 2 does not have any video output connector.

How secure is mobile connectivity (3G) for connect 2?The mobile network may use additional encryption algorithms to protect the data traffic. For maximum security, both the operator and the mobile terminal (modem) should implement the latest standards.

How secure is wireless connectivity (WiFi) for connect 2?connect 2 implements WEP and WPA-PSK. It is recommended to use WPA-PSK.

Which IP addresses, ports and protocols are required to establish connectivity from connect 2 to Axeda? Communication protocols and IP addresses required for Axeda:For the communication between the components involved in the Axeda solution (Gateway, GAS, Enterprise and Roche user PC) the following are used:• HTTPS protocol with Encrypted payload. The Axeda Gateway Agent initiates all communication between














19

4 Appendix A – Connectivity Checklist

The pre-requisites listed below need to be met by the customer IT infrastructure, and need to be discussed and approved prior to the installation of a Roche analyzer that includes a remote connectivity gateway to be connected online.

The Axeda Tunnel ensures secure connectivity between the gateway in the laboratory and the Axeda Enterprise servers located in the Axeda On Demand Center (ODC). For transfer in both directions, the data is encrypted between the tunnel services on the gateway in the Lab and the corresponding tunnel services.

Basic requirements for Axeda

IP Hostname Port62.209.44.11 remoteservice.roche.com 443209.202.167.21 remoteservice-dr.roche.com 44362.209.44.21 remoteservice-gas1.roche.com 44362.209.44.22 remoteservice-gas2.roche.com 443209.202.167.19 remoteservice-gas3.roche.com 443209.202.167.20 remoteservice-gas4.roche.com 443120.136.45.231 remoteservice-gas5.roche.com 443120.136.45.230 remoteservice-gas6.roche.com 443

Basic requirements for RCLNote: Only for cobas® link

IP Hostname Port196.3.50.39 teleservice.roche.com 443196.3.50.39 teleservice.roche.com 80

For the communication between cobas® link and Remote Service infrastructure (DMZ Connectivity Server) the following protocols are used.

HTTP/BITS with encrypted payload (for download): If BITS is blocked fall back to pure HTTP is performed. This service is for e-Library and patches download.

HTTP/SOAP with encrypted payload (for upload): This service is for monitoring data upload. HTTP with signed payload (for download): This service is for virus definition download.

Connectivity possibilitiesIP-Address: Proxy-Server Settings:

Retrieve IP automatically (DHCP) No Proxy-Server for internet connection Use following IP address: Internet connection via Proxy:

IP-Address Proxy-Address Subnet mask Proxy-Port Standard gateway

DNS-Server Address: Proxy/Firewall Authentication: Retrieve DNS automatically No authentication for Internet-Access needed Use following DNS-Server Address: Internet-Access via following authentication:

Preferred DNS-Server User ID Alternative DNS-Server Password Domain B2B VPN:

No B2B VPN needed Request for B2B VPN

20

5 Appendix B – Data transfer generated by Hitachi analyzers and transferred to Roche via cobas® link

Data transferred between Laboratory and RocheOnly the cobas® link is capable of transferring e-library and performance relevant data between the laboratory and Roche. Details are described in the following chapters.In general uploaded data (e.g. calibration results, power up time, test counters, alarms) do not contain patient identifying information and do not contain sample results or patient names. In rare cases it can happen that a sample ID becomes part of an alarm or error message. (e.g. if an special character like “ñ” in patient name causes an unhandled issue).

Remark: The connect 2 and Roche Vanilla Agent do offer the capability for screen sharing and transmit system management data (e.g. host name or configured IP-address). In addition, the agent also provides file transfer capabilities.

What kind of data is transferred from Roche to cobas® link/systems?For some classes of Roche systems (e.g. cobas® 6000 and cobas® 8000) binary data will be transferred from Roche to the laboratory system. The e-barcode (System Readable Data) is binary data related to the chemistry (reagents, controls, calibrators) accompanied by some information for routing transferred to the cobas® link and after release by the system’s user it is transferred to the system. The activation (installation of the binary data on the system) requires an explicit approval from the system’s user. Human Readable Data – documents in PDF format – will be transferred from Roche to the cobas® link to be used by the laboratory user. These are usually documents accompanying the chemistry data (e-Package Insert) or any type of customer letter.The software upgrades/patches of the cobas® link and antivirus definitions will also be transferred from Roche to the cobas® link and automatically installed.

What kind of data is transferred from systems to Roche via cobas® link?The table below summarizes the data transferred from a customer laboratory with Roche systems to Roche. The table uses examples based on Roche/Hitachi systems and the data may vary for other system families.

Data group Examples of Data Elements

Description

Instrument Definition

necessary and informative data for registration of the given instrument; must be included for each data originator referenced in the file

Lab Identifier unique identifier for a lab; takes the format of a URL with {lab name}. [{custom identifier}.] {country code}

Instrument Identifier unique identifier for an instrument; takes the format of a URL with {serial number}. {instrument type}. {lab identifier}

Instrument Registrator instrument registration data

Instrument Details informative data for the given instrument

Custom Record record wrapper for custom fields

Accumulated Data monitoring data that accumulate with time (like counters, logs, etc.) for the given instrument


Counters collection of counter entries

Logs collection of log entries

21


Description

Benchmarking

Instrument Identifier instrument unique identifier; takes the format of a URL with {serial number}. {instrument type}. {lab identifier}

Module Identifier relative identifier for a module belonging to the instrument in context (use default module, if data originates from the instrument in context)

Sub module Identifier relative identifier for a sub module belonging to the module in context (use default sub module, if data originates from the module in context)

Binary Files wrapper for files in any format that are internally stored in base64




Binary File container for a base64 encoded binary

Instrument Calibration

instrument calibration and adjustment data for the given instrument


Blank Cell Elecsys module blank cell data

Instrument Check instrument check data for the given instrument


Photometer Unit Check C-modular photometer check results for the given sub module

Assay Performance Test

Elecsys module assay performance test

System Volume Check Elecsys module system volume check

Instrument Configuration

instrument configuration listings for the given instrument


Photo Interruptor HMCONT

Clinical chemistry module photo interruptor data

Photo Interruptor LON Clinical chemistry module photo interruptor data

Probe Adjustment Clinical chemistry module probe adjustment settings

Test Assignment Clinical chemistry module test assignments

Adjustment Elecsys module hardware adjustment data

Application Parameter Elecsys module application parameter settings

Application Sample Type Info

Elecsys module application parameter settings

Assay Parameter BTS Elecsys module barcode transfer sheet application parameters

Carry Over Evasion Elecsys module carry over evasion

Clot Adjustment Elecsys module clot adjustment

Instrument Factor Elecsys module instrument factors

PMT Adjustment Elecsys module photometric test adjustments

PreSetting TS Elecsys module TS pre-settings

Reagent MBC Assay Elecsys module reagent MBC assay

22


Description

Reagent MBC BlankCell

Elecsys module reagent MBC

Reagent MBC Calib Elecsys module reagent MBC

Reagent MBC Control Elecsys module reagent MBC

Reagent MBC Dil Elecsys module reagent MBC

Reagent Test No Elecsys module reagent test no

Ref Blank Cell Calibra-tion Name

Elecsys module reference data

Ref Calibration Info Elecsys module reference data

Ref Diluent Info Elecsys module reference data

Ref Diluent Name Elecsys module reference data

Ref Determination Number

Elecsys module reference data

Ref Result Message Elecsys module reference data

Test Assignment Elecsys module test assignments

…more fields reserved …more fields reserved

Inventory

Instrument Identifier instrument unique identifier; takes the format of a URL with {serial number}. {instrument type}. {lab identifier}



Notification immediate notification data, e.g. alerts, status changes, etc. for the given sub module




Event Message single occurrence of an event message (alarm, warning, etc.) with the specified properties

Status Change operation status change

Test Calibration result parameters for test calibrations for the given instrument


Immuno Test Calibration

calibration result for immunology tests

ISE Test Calibration calibration results for ISE tests

PM Test Calibration calibration results for photometric tests

Test Results QC sample and anonymized patient sample results




23


Description

Sample sample and QC sample (control) information – fields where patient related information may be stored are anonymized by the instrument – transferred information related to the patient: age, sex and internal instrument identifier – no patient identifying information.

Result test results (regular sample and QC)

Instrument factor Instrument factor settings are transferred from the analyzer to the cobas® link within one hour after update.




Factor a a = slope

Factor b b = offset

Instrument factor “Compensated Test” is transferred via Instrument Back up file from the instrument to the cobas® link data station




Formula Defined on analyzer

24

6 Appendix C – B2B VPN information

Roche service offering for B2B VPN for Remote Service componentsB2B (Business to Business) connections are based on IPSec. B2B VPN is an industry standard for inter-company collaboration over Internet. Note: This section describes the service offered by the Roche IT organization (Global IT Infrastructure & Solutions (GIS) – Group IT)

Roche provides the option to establish a B2B VPN connection based on IPSec between customer site and Roche to act as a carrier. A dedicated VPN infrastructure is available at Roche IT premises for this dedicated purpose.

B2B VPN connections enable connectivity between agreed IP-addresses and ports on both sides of the connection. Security controls to ensure this agreed connectivity are enforced by Roche but can also be enforced by the customer.

Traffic going through the VPN will exit the VPN depending on the use case:• The Axeda Agent traffic will be forwarded from the Roche network to the Axeda On Demand Center via a

second B2B VPN. Screen sharing traffic will be forwarded from the Roche network to the Axeda Global Access Servers via the Internet.

• Since the RCL / TSN enterprise systems are hosted internally at Roche internal, no traffic forwarding is required and the traffic stays inside the Roche network.

Roche accepts B2B connections to state-of-the-art products of leading vendors such as CISCO, Nokia, Checkpoint, and others. B2B VPN configuration parameters, such as negotiation mode, encryption algorithm, hash algorithm, are to be confirmed with the Global IT Infrastructure & Solutions (GIS) within Group IT organization.

Note: Since the Axeda solution is based on a globally distributed architecture, B2B VPN implementation can adversely affect the performance of Axeda screen sharing sessions. B2B VPN is not required from a security perspective, because all Axeda traffic is fully encrypted.

Steps to set up a new B2B VPN • Customer provides the local Remote Service subject matter expert in the Roche sales organization with the B2B

VPN configuration parameters and vendor of the customers B2B VPN solution• Local Remote Service SME approaches Global IT Infrastructure & Solutions (GIS) within Roche Group IT

organization to make a B2B VPN• Once the B2B VPN has been configured, the local SME will pass the specifications from Roche Group IT

organization to the customer IT department. • During and after initial setup, the local SME will facilitate any support and troubleshooting activities between

customer IT and Roche Group IT organization, and must be kept informed on any changes or service disruptions.

25

The following IP addresses and host names are to be used in case of B2B VPN connection.

For all Axeda Devices:

Description NAT IP for B2BVPN

Hostname for VPN Port Protocol










In additional for RCL on cobas® link

Description NAT IP for B2BVPN

Hostname for VPN Port Protocol

TeleService DMZ 162.132.161.140 teleservicevpn.roche.com 80 TCP/HTTP

TeleService DMZ 162.132.161.140 teleservicevpn.roche.com 443 TCP/SSL

Note: For Windows system, the host file is located at: C:\”windir”\system32\drivers\etc\hosts.Where “windir” is the Windows installation folder.

26

7 Appendix D – List of terms & definitionsAbbreviation Long form Description

Affiliate Roche country organization

Electronic product information distribution

Part of the Remote Service applications – automated transfer of data between Roche and systems at the at customer site. A related term is > cobas® e-library

Axeda Asset An Axeda asset is any instrument or system with Axeda client software installed and connected to Axeda Enterprise.Comment: ‘Asset’ is an Axeda synonym for ‘device’, introduced with version 6 of Axeda Enterprise. The terms ‘asset’ and ‘device’ can be used interchangeably, but in the Axeda domain, ‘asset’ is the preferred term.

Axeda Desktop Server Software component by Axeda to establish screen sharing sessions. It is a custom implementation of UltraVNC. The component runs on the Axeda assets, e.g. Roche instruments.

Axeda Desktop Viewer 3rd party software for screen sharing. Special implementation of Ultra-VNC. It is the screen sharing client for Axeda Desktop Server.

Axeda Device An Axeda device is any instrument or system with Axeda client software installed; such a device has the ability to remotely communicate to Axeda Enterprise.Comment: The term device has been replaced by Axeda in Axeda Enter-prise version 6. The terms ‘asset’ and ‘device’ can be used interchange-ably, but in the Axeda domain, ‘asset’ is the preferred term.

Axeda Enterprise Server

The backend of Axeda ServiceLink. This application server collects, stores, and serves data generated by Axeda Agents. It provides applica-tions that are used to screen share, monitor and troubleshoot devices.

Axeda Gateway Agent An Axeda software component running on the client side – it is the counterpart of Axeda ServiceLink on the server side. Axeda Gateway Agent is the off-the-shelf version, whereas Roche Vanilla Agent is the tailored version for Roche.

Axeda Managed Asset A managed asset is any Roche system or instrument connected to a gateway device (RVA). A managed device must have a unique identifier that consists of a managed device model (e.g. c6000, GSJunior, c4000) and a unique serial number within that model. "Asset" is an Axeda synonym for "device". The terms are used interchangeably.

Axeda ServiceLink ServiceLink is the frontend web application of Axeda Enterprise Server. The user can manage and remote connect to the remote assets from ServiceLink.

Axeda On Demand Center

Axeda On Demand Center refers to the hosting site for Roche’s Axeda solution.

B2B VPN Business-to-business virtual private network

A virtual private network (VPN) is a virtualized extension of a private network across a public network, such as the Internet. B2B refers to a connection between two business corporations.

cobas® e-library Repository on cobas® link, containing assay, accompanied and QC documents, customer letters, and instrument-readable data for the analyzers. It is either updated automatically using network connectivity or by installation of an e-library CD at regular intervals.

cobas® e-library CD A complete e-library data set stored on a CD. Teleservice-Net provides on a regular basis country-specific CD images of the current, complete e-library data set to be stored on a cobas® link. The image can be used to produce e-library CDs locally. The cobas® e-library CD is used in cases where no Internet connection is available.

27

Abbreviation Long form Description

cobas® link cobas® link is a gateway system custom-made by Roche Diagnostics, providing a secure remote connection for data transfer between the customer network and the Roche Corporate Network. It supports several use cases, such as screen sharing, download & display of cobas® e-library data, upload of monitoring data, and serves as destination for the backup

Laboratory system In context of Remote services, a Roche laboratory system can be the destination of remote sessions by an RSR, and can be the source or destination for data transfer.Refer to > Axeda Managed Asset and > RVA

Network topology The network topology is the description of the physical or logical arrangement of different elements (links, nodes, etc.) of a computer network. The physical topology describes the placement of the various elements of the network, while the logical topology illustrates the data flow within the network.

RSDW Remote Service Data Warehouse

RSDW is an xml file repository for short-term storage. Application Consumers, e.g. business applications receiving data from RSDW, can consume the stored data.

RCN Roche Corporate Network

The Roche network communication systems including components (incl. end user devices) used by LANs, WANs, WLANs, VoIP and analog tele-phony, videoconferencing, dial-up solutions, connections to the Internet and other non-Roche networks, etc.

RSR Roche Service Representative

RVA Roche Vanilla Agent Extended version of the Axeda Agent. RVA provides “out-of-the-box” remote services, tailored for the needs of Roche Diagnostics, such as Data Distribution Client for file up- and download

SME Subject Matter Expert In each Roche affiliate organization a Remote Service SME is established to act as specialist for customer connectivity matters

SEP Symantec Endpoint Protection

Antivirus tool used on cobas® link

TSN Teleservice-Net Teleservice-Net collects and represents data gathered from Hitachi instruments and uploaded by cobas® links located in the customer net-work. Teleservice-Net distributes the e-library packages to the laboratory systems.

Published byRoche Diagnostics International LtdCH-6343 RotkreuzSwitzerland

© 2017

All trademarks mentioned enjoy legal protection.

www.roche.com

roche remote solutions privacy, security and connectivity€¦ · 3 1 purpose the purpose of this...

Documents