Remote Access Good Practice Guideline

Programme NPFIT Document Record ID Key Sub-Prog / Project Infrastructure Security NPFIT-FNT-TO-IG-GPG-0021.10 Prog. Director Mark Ferrar Status Approved Owner James Wood Version 2.0 Author Mike Farrell Version Date 01/07/2009 Remote Access Good Practice Guideline Crown Copyright 2009

Amendment History: Version Date Amendment History 0.1 First draft for comment 0.2 26/10/2006 Second draft including comments from IG Security Team 0.3 16/03/2007 Third draft to place document in new template, update glossary and text. 0.4 10/08/2007 Draft for approval 0.5 20/11/2007 Final draft for approval 1.0 13/12/2007 Approved for release 1.1 30/04/2009 Document refreshed. Appendix B & C added 1.2 08/05/2009 Incorporating changes suggested by CfH Infrastructure Security Team 1.3 15/05/2009 Incorporating further changes suggested by CfH IST 2.0 01/07/2009 Incorporating minor changes suggested by Head of IT Security Forecast Changes: Anticipated Change When Annual Review June 2010 Reviewers: This document must be reviewed by the following: Name Signature Title / Responsibility Date Version Infrastructure Security Team Matt Ballinger Deployment Support Officer - Technology Office 1.1 1.2 Approvals: This document must be approved by the following: Name Signature Title / Responsibility Date Version James Wood Head of IT Security 2.0 Distribution: NHS Connecting for Health Infrastructure Security Website http://nww.connectingforhealth.nhs.uk/infrasec/gpg Crown Copyright 2009 Page 2 of 22

Document Status: This is a controlled document. Whilst this document may be printed, the electronic version maintained in FileCM is the controlled copy. Any printed copies of the document are not controlled. Related Documents: These documents will provide additional information. Ref no Doc Reference Number Title Version 1 NPFIT-SHR-QMS-PRP-0015 Glossary of Terms Consolidated.doc 13 2 NPFIT-FNT-TO-INFR-SEC-0001 Glossary of Security Terms 1 Glossary of Terms: List any new terms created in this document. Mail the NPO Quality Manager to have these included in the master glossary above [1]. Term Acronym Definition Crown Copyright 2009 Page 3 of 22

Contents 1 About this Document... 5 1.1 Purpose... 5 1.2 Audience... 5 1.3 Content... 5 1.4 Disclaimer... 6 2 Introduction... 7 2.1 Background... 7 3 Overview of Virtual Private Networks... 8 3.1 Secure VPN... 8 3.1.1 Internet Protocol Security (IPSec)... 8 3.1.2 Transport Layer Security (TLS) / Secure Sockets Layer (SSL)... 8 3.2 Trusted VPN... 9 4 Benefits of Virtual Private Networks... 10 5 Security Controls for Remote Access... 11 5.1 Authentication... 11 5.2 Factors of Authentication... 12 5.3 Common Methods of Authentication... 13 5.3.1 Security Tokens... 13 5.3.2 Digital Signatures... 13 5.3.3 Single Sign-on Software... 13 5.3.4 One-Time Passwords... 13 5.3.5 Time-Synchronised One-Time Passwords... 14 5.3.6 Smartcards... 14 5.4 Endpoint Security... 15 5.4.1 Personal Firewalls... 15 Appendix A. Guidance on VPN Technologies... 16 Appendix B. Gateway Brokered Remote Access... 18 B.1 Operation... 18 B.2 Security Considerations... 19 B.3 Risk Assessment... 20 Appendix C. Other Remote Desktop Solutions... 21 C.1 Security Considerations... 21 C.2 Risk Assessment... 22 Crown Copyright 2009 Page 4 of 22

1 About this Document 1.1 Purpose The purpose of this document is to address the major issues associated with creating and maintaining secure remote access networks connected to the New NHS Network (N3) or other network infrastructures, such as Community of Interest Networks (CoIN) partner networks, or the Internet. It is recommended that a full assessment of both threat and impact levels of potential security breaches, afforded by the provision of remote access to an organisation s networks and systems, be performed. This should incorporate partnering networks, including N3, in line with the electronic Government Interoperability Framework (e- GIF) recommendations. 1 The information contained in this document should be used as an informed assessment of technologies that support secure remote access. However it is the sole responsibility of network owners to ensure that any remote access solutions that they deploy are sufficiently secure to fully satisfy their own risk assessment. 1.2 Audience This document has been written for readers who have a good level of experience and familiarity with firewalls, switches, routers and secure networking practices. 1.3 Content This document comprises this following sections / topics: - Introduction Overview of Virtual Private Networks Secure VPN Benefits of Virtual Private Networks Security Controls for Remote Access Endpoint Security Guidance on VPN Technologies Gateway Brokered Remote Access Other Remote Desktop Solutions 1 See the GovTalk Schemas and Standards Website: http://www.govtalk.gov.uk/schemasstandards/egif.asp Crown Copyright 2009 Page 5 of 22

1.4 Disclaimer Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by National Health Service Connecting for Health (NHS CFH). The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment. It is important to note that a risk assessment is a prerequisite for the design of effective security countermeasures. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer. Crown Copyright 2009 Page 6 of 22

2 Introduction The information in this document covers all environments required to interact with the NHS Care Records Service (NCRS), including: - 1. Information on suitable measures and controls for the most secure solutions that are in conformance with the Information Governance Statement of Compliance (IGSoC). 2 2. Good practice guidance for the design and use of remote access networks within a network infrastructure, including: - The minimum standards for remote access security. The methods by which remote access authentication can be achieved AND The procedures and mechanisms for the control of remote access to other networks or Local Area Networks (LANs) in an NHS or other healthcare environment. 2.1 Background N3 is a private Wide Area Network (WAN) and access is therefore strictly limited to authorised endpoints. Any organisation wishing to connect to N3 is responsible for ensuring that their N3 connection does not compromise the security measures already in place within the WAN. N3 is a private network accommodating thousands of Personal Computers (PCs), servers, printers and other items of equipment, all acting as nodes or endpoints within the network. The confidentiality of sensitive information transmitted unencrypted within N3 is not assured. However all National Applications encrypt data using Transport Layer Security (TLS) or an equivalent security standard. It is therefore advisable that the appropriate measures are taken with Existing Systems to ensure that sensitive data is secure before connecting to N3. N3 faces numerous potential threats to security, possibly from inadequately protected partner networks, or connections to uncontrolled external networks such as the Internet. These threats are continually evolving in both strength and frequency. Therefore ongoing vigilance against these threats, and the maintenance of strict security standards, are essential to the continuing success of N3. 2 http://www.connectingforhealth.nhs.uk/systemsandservices/infogov/soc Crown Copyright 2009 Page 7 of 22

3 Overview of Virtual Private Networks A Virtual Private Network (VPN) is a logically private communications network often used within an organisation, or by several organisations to communicate confidentially over a publicly accessible physical network. VPN traffic can be carried over a public network infrastructure, such as the Internet, using standard protocols. Or over a service provider's private network, with a defined Service Level Agreement (SLA) between the VPN customer and the VPN service provider. Many implementations of VPN technology exist with varying levels of security, integrity and performance. The selection of appropriate products and techniques are directly related to the overall security and applicability required of the VPN. 3.1 Secure VPN A Secure VPN (SVPN) uses cryptographic tunnelling protocols to provide the necessary confidentiality, sender authentication and message integrity to achieve the intended level of privacy. The selection of suitable confidentiality and integrity techniques for the VPN ensures secure communications over unsecured networks. Secure VPN technologies may also be used to enhance security by acting as a security overlay within dedicated networking infrastructures. Such as management networks, or enterprise Wireless Local Area Networks (WLANs), which aim to provide a higher level of security than is currently available within WLAN protocols. The following protocols are used to operate Secure VPNs: - 3.1.1 Internet Protocol Security (IPSec) This protocol provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s) and put in place any cryptographic keys required to provide the requested services. IPSec is commonly used with IPv4 and is an integral part of the base protocol suite in IPv6. Suitable encryption and hashing algorithms for use with IPSec VPNs are detailed in the Approved Cryptographic Algorithms Good Practice Guideline (GPG). 3 3.1.2 Transport Layer Security (TLS) / Secure Sockets Layer (SSL) Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications over the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL and TLS, but the protocols remain substantially the same. 3 http://nww.connectingforhealth.nhs.uk/infrasec/gpg/ Crown Copyright 2009 Page 8 of 22

These protocols can be used either for tunnelling the entire network stack, such as in the OpenVPN software product, 4 or for securing what is essentially a web proxy to provide an application portal. Some vendors offer a TLS/SSL VPN solution which also incorporates the ability to tunnel any host network traffic in a similar manner to IPSec. Solutions that provide an application portal via TLS/SSL are not capable of providing a VPN in the strict sense of the term, as they provide a virtual network interface rather than tunnelling traffic from the standard network interface. Suitable encryption and hashing algorithms for use with TLS/SSL VPNs are detailed in the Approved Cryptographic Algorithms GPG. 5 Point-to-Point Tunnelling Protocol (PPTP) this protocol was developed jointly by a number of companies, including Microsoft. It utilises the Rivest Cipher 4 (RC4) stream cipher to provide encryption services, and, whilst providing a basic level of security, the protocol is not cryptographically strong and should be avoided. Some Internet Service Providers (ISPs) offer managed Secure VPN services for business customers, who require the security and flexibility of a VPN, but prefer not to undertake the administration and support of their own VPN infrastructure. The N3 Service Provider (N3SP) currently offers a managed VPN service for NHS organisations. 6 3.2 Trusted VPN Trusted VPNs do not use cryptographic tunnelling, and instead rely on the security of a single service provider network to protect traffic. The Multi-Protocol Label Switching (MPLS) protocol is commonly used to build trusted VPNs. Other protocols for trusted VPNs include: Layer 2 Forwarding (L2F), developed by Cisco. Layer 2 Tunnelling Protocol (L2TP) Layer 2 Tunneling Protocol version 3 (L2TPv3). This document focuses mainly on techniques for providing Remote Access using Secure VPN technology. Other types of VPN are covered in the Site to Site VPN 5 GPG. 4 http://openvpn.net 5 http://nww.connectingforhealth.nhs.uk/infrasec/gpg/ 6 http://n3.nhs.uk/productsandservices/flexibleworking/ Crown Copyright 2009 Page 9 of 22

4 Benefits of Virtual Private Networks The use of a VPN can offer many benefits to an organisation, including: - Extension of connectivity over a larger geographic area. Reduced travel costs and transit time for remote users. Support for telecommuting and teleworkers. Provision of global networking opportunities. Improved security for standard point-to-point links which do not offer native encryption. Reduced operational costs when compared with a traditional WAN architecture. Simplified network topology in certain scenarios. Compatibility between broadband and enterprise networks through use of a common transport. Faster return on investment than traditional carrier leased or owned WAN connections. Scalability. Particularly when used with a Public Key Infrastructure (PKI). Whilst a VPN can securely connect remote endpoints, it introduces additional security risks that should be considered. Crown Copyright 2009 Page 10 of 22

5 Security Controls for Remote Access In order to maintain the security and integrity of sensitive data, e.g. Patient Identifiable Data, it is necessary to employ a defence-in-depth approach. This is particularly important when enabling remote access to clinical systems. Controls should be applied at each point where data interacts with the network. It is important that additional controls are applied to remote access clients in order to ensure they are adequately protected. Such clients may be installed on either organisation-owned equipment or the user s personal computer. The decision about which client to use is determined by the security policy of the organisation. It is acknowledged that further risks are introduced by allowing users to connect their own equipment to a remote access VPN. Some organisations may choose to arrange for an employee's home to have two separate WAN connections. One for working on the employer's sensitive data, and the other for all other uses. Access-Control Lists (ACLs) should be in place to restrict access to the target network by remote VPN users. The access privileges should only allow the user to perform the tasks necessary for their role. The rule of least privilege 7 should be applied to ensure that only the required permissions are granted to remote users. The logging and auditing services of all systems within the network should be evaluated. These functions may require modification to ensure that the level of auditing and logging reflects the increased threat level presented by the provision of remote access into the private network. Organisations shall be mindful that any single breach or failure of security could result in the overall compromise of the privacy and security of the network. 5.1 Authentication It is considered best practice for strong authentication to be used when controlling access to a Remote Access VPN. Single factor mechanisms such as usernames and passwords are weak and should not be used for remote access authentication. All Remote Access VPNs should utilise two-factor authentication as a minimum standard. 7 The rule of Least Privilege requires that access is provided only to the people who need it, and under the appropriate context. Crown Copyright 2009 Page 11 of 22

5.2 Factors of Authentication The three most commonly recognised factors are: - 'Something you know', such as a password or Personal Identification Number (PIN). 'Something you have', such as a Smartcard or hardware token. 'Something you are', such as a fingerprint, a retinal pattern or other biometric identifier. In addition, there are a number of other factors that can be used: - Cyber-metric authentication, such as only allowing access from a computer that meets a particular set of criteria. The authentication factor is often derived from the combination of unique hardware and/or software and certificates installed Location-based authentication, such as only allowing a particular system to connect from a specific network or campus or only allowing privileged access from specific terminals. This practice has been common for some time in the maintenance of Firewalls and other network infrastructure Time-based authentication, such as only allowing access from certain accounts, or to specific services, during normal working hours Read only access Size-based authorisation, such as only allowing a specific financial transaction to be for a specified exact amount. This could apply to the provision of contract cleaning or contract meals services Pre-authorised transactions. For example, where an NHS Organisation is ordering pharmaceutical supplies, and the pharmaceutical company would reject orders for any stock items not pre-agreed with the organisation. The cyber-metric, location-based and time-based authentication methods are often utilised to complement existing two-factor security controls for Remote Access VPNs. Many network vendors offer support for time, location and system state parameters within the VPN device configurations. Systems that support Network Admission Control (NAC) or Network Access Protection (NAP) can use a number of criteria to measure compliance with a set of rules or policies before granting access to a remote access VPN. Crown Copyright 2009 Page 12 of 22

5.3 Common Methods of Authentication 5.3.1 Security Tokens A security token may be a physical device that an authorised user of computer services is given to aid in authentication. A security token can take the form of a hardware token, authentication token, cryptographic token or a software token. Hardware tokens are typically small enough to be carried in a pocket and are often designed to attach to the user's keychain. Some may store cryptographic keys, such as a digital signature, or biometric data (such as a fingerprint). Some designs feature tamper resistant packaging, others may include a small keypad to allow the entry of a PIN. 5.3.2 Digital Signatures For a digital signature to be as trusted like a regular hand-written signature, the digital signature must be made with a private key known only to the person authorised to make the signature. Tokens that allow secure on-board generation and storage of private keys enable secure digital signatures, and can also be used for user authentication, as the private key also serves as a proof of the user s identity. Where tokens are used to identify the user, all tokens must have some kind of number that is unique. Tokens with no on-board keyboard or another user interface cannot be used in some signing scenarios. The Electronic Signatures Regulations 2002 8 and the EU Digital Signature Directive 9 documentation should be consulted to determine the definition of a digital or electronic signature. 5.3.3 Single Sign-on Software Some types of single sign-on solutions, such as Enterprise Single Sign-On (E-SSO), use the token to store software that allows for seamless authentication and password filling. If the passwords are stored on the token, users need not remember them, and therefore can select more secure passwords, or have more secure passwords assigned. Other methods allow the creation of a session token, which demonstrates a user s right to access a service or application based on their initial authentication, rather than storing a series of passwords and credentials. 5.3.4 One-Time Passwords One-Time Passwords (OTPs) change after each login, or change in accordance with a pre-set time interval. In their simplest form OTPs may be generated by an authentication system and distributed to users as a list of passwords, which may be used in the given order to access resources along with other credentials. 8 http://www.opsi.gov.uk/si/si2002/20020318.htm 9 http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:31999l0093:en:html Crown Copyright 2009 Page 13 of 22

5.3.5 Time-Synchronised One-Time Passwords A time-synchronised one-time password continuously changes at a set time interval, e.g. once per minute. A method of synchronisation must exist between a client token and the authentication server. For disconnected tokens this time-synchronisation is performed before the token is distributed to the client, whereas other token types perform the synchronisation when the token is inserted into an input device. Some vendor specific time-synchronised OTP solutions require the use of a PIN that is known to the user, and is entered with the password at the time of authentication. This allows the system to offer two factors of authentication something you have and something you know. Other systems, as offered by RSA 10 and other vendors, support software tokens. Software tokens can be installed on any machine and are protected by the user s password. The security level of software tokens is less than that of hardware ones, as various attacks focus on the user, such as installation of key logging software that can record the user s password. However the attacker must have access to the exact software token that is installed on the users' machine. Only the authentic token has the correct seed which enables it to generate valid OTPs. In cases where this risk is acceptable, software tokens can be a cost effective and simple method of improving security. 5.3.6 Smartcards Smart cards are relatively inexpensive in comparison to other tokens. In addition to authentication mechanisms and PKI functions, smartcards may also be used to store physical access credentials, electronic currency, and can include branding or photographs to act as a company pass or ID. 10 RSA algorithm invented by Ronald L. Rivest, Adi Shamir, and Leonard Adleman in 1977 and released into the public domain in 2000. See http://www.rsa.com Crown Copyright 2009 Page 14 of 22

5.4 Endpoint Security Endpoint security is an important component of any remote access solution. The network is effectively extended out to each endpoint. Therefore the security measures implemented at each endpoint should be aligned with those of other corporate systems. It is recommended that all endpoints utilise up-to-date Anti-Virus and firewall software as a baseline, with additional services, such as Intrusion Prevention Systems (IPSs) and Anti-Malware/Spyware 11 software. 5.4.1 Personal Firewalls A personal firewall will provide local machine protection against inbound malicious code that uses the network to enter the machine. Once malicious software has penetrated a machine, a common mechanism for propagation is to use outbound network traffic to other machines on the same network. Personal firewalls can help block some non-standard network port access, and can be configured so that only specific applications can use specific network ports. This helps to prevent the spread of malicious code. Best practice requires the use of centralised enterprise firewall management and administration, therefore requiring minimal user interaction or technical knowledge. Microsoft provides a basic personal firewall with Windows XP, and a more comprehensive implementation with Vista. Microsoft's personal firewall provides protection for inbound traffic only (in the case of XP), and protection for both inbound and outbound traffic (in the case of Vista). In both cases it can be centrally managed using granular group policies. For laptops or other mobile systems that are frequently outside the corporate firewall, the use of a bidirectional personal firewall is good practice. Note that although some personal firewalls are free, they normally require a subscription following a trial period. Note also that, depending on local security policies, personal firewalls may need to be installed and configured by the organisation s local IT department. 11 See http://nww.connectingforhealth.nhs.uk/infrasec/gpg/ Crown Copyright 2009 Page 15 of 22

Appendix A. Guidance on VPN Technologies VPN type Proponents Constraints Remarks IPSec All IP types and services are supported. E.g. ICMP, VoIP, Net8 (called SQL*Net prior to Oracle8), Citrix ICA Same technology base works in client-to-site, site-to-site, and client-to-client IPSec client provides an opportunity to embed other security features (e.g. personal firewall, configuration verification, etc.) VPN gateways are typically integrated with firewall functions for access control, content screening, attack protection, and other security controls. Typically requires a client software installation. Not all required client operating systems may be supported Connectivity can be adversely affected by firewalls or other devices between the client and gateway (e.g. firewall or NAT devices). Interoperability between one vendor s IPSec clients and another vendor s IPSec servers/gateways is typically difficult. Recommended Non-trivial to implement and maintain Crown Copyright 2009 Page 16 of 22

VPN type Proponents Constraints Remarks TLS/ SSL SSL integrated with all leading Web browsers. Popular applications such as mail clients/servers (e.g. Microsoft Outlook and Eudora ) support SSL. Operates transparently across NAT, proxy, and most firewalls. Web plug-in may provide network-level connectivity over SSL for client/server applications Only supports TCP services natively over SSL. Typically only web (HTTP) or email (POP3, IMAP, SMTP) over SSL. SSL typically requires more processing resources from the gateway than IPSec No native software installed in clientless scenarios. Limited ability to push security software to the endpoint (e.g., personal firewall, integrity checking, etc.). Web plug-ins may have limited application support, or require administrator privileges on the PC to operate. Not normally used for site-tosite VPNs, because of their temporary nature. So if IPSec is used for site-to-site, then different technologies must be used for a remote access VPN, versus site-to-site VPNs. Recommended Crown Copyright 2009 Page 17 of 22

Appendix B. Gateway Brokered Remote Access NHS CFH does not endorse any security product or service. The Communications- Electronics Security Group (CESG) scheme, known as the 'CESG Claims Tested Mark' (CCTM), 12 is endorsed however. Because of the interest within the NHS around gateway brokered remote access products, this appendix has been added to this document. Examples of this type of remote access are the LogMeIn 13 and GoToMyPC 14 families of products. Both provide remote access to computers over the Internet, and are sold in a number of different product types that have differing features and prices, depending on the number of features and the type of access desired. Unlike other remote access solutions, products such as LogMeIn and GoToMyPC do not require local firewall modifications, as there are no incoming ports to be opened. Instead each product works through SSL tunnelling. B.1 Operation For a typical application, where a user wishes to access a host machine (within the N3 network) from home over the Internet, this type of remote access solution operates as follows: - The user initiates a persistent Transmission Control Protocol (TCP) connection over SSL from the host machine, through the N3 National Gateway over the Internet to the solution provider s broker. With the first half of the SSL tunnel locked in place, the user then goes home and completes the second half of the tunnel by connecting from his/her home (client) PC to the same broker. The complete tunnel is then re-negotiated between the client and the host, providing a secure end-to-end connection via the solution provider s gateway communications device. 12 More information on this scheme, and a list of the vendors and products awarded the CCT Mark can be found at: http://www.cctmark.gov.uk 13 https://secure.logmein.com 14 http://www.gotomypc.com/uk Crown Copyright 2009 Page 18 of 22

B.2 Security Considerations By default, access to clients and hosts can be gained via username/e-mail and password combination, and no form of password strength is enforced by the solution provider. There is therefore a reliance on the user choosing 'good passwords' 15 for use with the system. LogMeIn Free for instance does not contain the additional authentication controls available with LogMeIn Pro, such as One-Time Passwords (OTPs) 16 and the ability to link into RSA SecurID for two-factor authentication. As with all public facing implementations of SSL, the user is required to make good security decisions about the validity of a presented certificate. If a selfsigned certificate is presented (as may be the case with a Man-In-The-Middle attack) the user has to understand the warnings presented and therefore to choose whether to accept the certificate or not. Of course if not accepting the certificate means 'no access to the system', it is highly likely that the user will choose to accept the certificate. Because to date these products have not been submitted for CCT Mark testing, there is no obvious means of independently verifying vendor claims or understanding security mechanisms such as: - o When connecting from the client to the host machine, the Windows username and password of that machine are requested. This request is not made by the Windows authentication system but by the solution provider s software on the host system. It is not clear how these credentials are stored by the client software and what happens to them once they are no longer needed. o The vendor claims that once the client has completed the connection to the broker, the complete tunnel is re-negotiated between the client and the host, albeit via the solution provider s gateway, thus providing a completely secure connection. For a typical application as described in section B.1 above, where an NHS organisation user wishes to access a host machine for the purpose of accessing local services, the host machine must be left switched on. This in itself may contravene local security policy if the machine is left on overnight. For a typical application as described in section B.1 above, where an NHS organisation user wishes to access a host machine for the purpose of accessing services on N3, it should be noted that this will contravene the NHS CFH requirement that only an approved service (such as an N3 catalogue service) can be used for a connection originated from an external network (such as the Internet) that is onwardly linked to N3. 15 See Password Policy for Non-Spine Connected Applications GPG, at http://nww.connectingforhealth.nhs.uk/infrasec/gpg/ 16 http://www.rsa.com Crown Copyright 2009 Page 19 of 22

Furthermore if the accessed services in question require Smartcard authentication, and the user s smartcard is left unattended in a Smartcard reader connected to the host machine, this will contravene the Registration Authority (RA) form RA01 Part A. 17 The applicable section entitled... By signing the declaration set out in the RA01 Short Form, I, the applicant:... Because of the likelihood that the solution provider s gateway is outside the United Kingdom (UK), it opens up the possibility that data protection may be subject to another country s laws (not the Data Protection Act 1998). B.3 Risk Assessment Approval of security products and services for local use is the responsibility of the relevant NHS organisation, and any risk assessment should take note of the security concerns in section B.2 above. Each NHS organisation is likely to have different IT infrastructure and business needs. For this reason each business owner should perform their own risk management regarding the use of specific security products or services, including that of remote access. NHS CFH National Applications and the N3 network must not be impacted or put at risk as a result of any local IT solutions. Because of the risk of unauthorised disclosure of sensitive data from a security solution that has been implemented locally, each business owner should perform a Business Impact Assessment (BIA), to balance the risk and impact of such an occurrence against the cost of any appropriate technological controls required to enhance security. It is always wise to back up such BIAs with a good threat/vulnerability risk assessment. A risk assessment is a prerequisite for the design of effective security countermeasures, and when completed correctly enables the NHS organisation to demonstrate that a methodical process has been undertaken, as well as describe the rationale behind any decisions made. 17 http://nww.connectingforhealth.nhs.uk/registrationauthorities/practical-essentials/forms/registrationauthority-forms Crown Copyright 2009 Page 20 of 22

Appendix C. Other Remote Desktop Solutions There are a number of remote desktop solutions that operate similarly, from a networking point of view. E.g. pcanywhere, 18 Microsoft s Remote Desktop (Terminal Services). 19 They work differently to gateway brokered remote access products, in that the remote connection is direct between the client and host, with no intermediate gateway. If used within the same local network, security concerns can be minimised. However if used for remote connections over N3 or the Internet, the security concerns detailed in section C.1 below should be noted. C.1 Security Considerations Invariably username and password only are used for authentication, rather than two-factor authentication as required by approved NHS VPN services. For a typical application, where an NHS organisation user wishes to remotely access a host machine for the purpose of accessing local services, the host machine must be left switched on. As in the case of gateway brokered remote access, this in itself may contravene local security policy if the machine is left on overnight. Like LogMeIn, for a typical application where an NHS organisation user wishes to access a host machine for the purpose of accessing services on N3, it should be noted that this will contravene the NHS CFH requirement that only an approved service (such as an N3 catalogue service) can be used for a connection originated from an external network (such as the Internet) that is onwardly linked to N3. If the accessed services in question require Smartcard authentication, and the user s smartcard is left unattended in a Smartcard reader connected to the host machine, this will contravene the Registration Authority (RA) form RA01 Part A. 20 The applicable section entitled... By signing the declaration set out in the RA01 Short Form, I, the applicant:... 18 http://www.symantec.com/en/uk/business/pcanywhere 19 http://www.microsoft.com 20 http://nww.connectingforhealth.nhs.uk/registrationauthorities/practical-essentials/forms/registrationauthority-forms Crown Copyright 2009 Page 21 of 22

C.2 Risk Assessment Approval of security products and services for local use is the responsibility of the relevant NHS organisation, and any risk assessment should take note of the security concerns in section C.1 above. Each NHS organisation is likely to have different IT infrastructure and business needs. For this reason each business owner should perform their own risk management regarding the use of specific security products or services, including that of remote access. NHS CFH National Applications and the N3 network must not be impacted or put at risk as a result of any local IT solutions. Because of the risk of unauthorised disclosure of sensitive data from a security solution that has been implemented locally, each business owner should perform a Business Impact Assessment (BIA), to balance the risk and impact of such an occurrence against the cost of any appropriate technological controls required to enhance security. It is always wise to back up such BIAs with a good threat/vulnerability risk assessment. A risk assessment is a prerequisite for the design of effective security countermeasures, and when completed correctly enables the NHS organisation to demonstrate that a methodical process has been undertaken, as well as describe the rationale behind any decisions made. Crown Copyright 2009 Page 22 of 22