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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Infrastructure
Security Team
Version
1.1
Matt Ballinger
Deployment Support Officer Technology Office
1.2
Approvals:
This document must be approved by the following:
Name
Signature
James Wood
Title / Responsibility
Head of IT Security
Date
Version
2.0
Distribution:
NHS Connecting for Health Infrastructure Security Website
http://nww.connectingforhealth.nhs.uk/infrasec/gpg
© Crown Copyright 2009
Page 2 of 22
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
© Crown Copyright 2009
Definition
Page 3 of 22
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
Contents
1
2
About this Document ...........................................................................................5
1.1
Purpose .........................................................................................................5
1.2
Audience .......................................................................................................5
1.3
Content ..........................................................................................................5
1.4
Disclaimer ......................................................................................................6
Introduction..........................................................................................................7
2.1
3
Background ...................................................................................................7
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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’ (eGIF) 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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
GPG.5
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
Appendix A. Guidance on VPN Technologies
VPN type
Proponents
IPSec




Constraints
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.
© Crown Copyright 2009
Remarks
Typically requires a client Recommended
software installation. Not all Non-trivial to implement and maintain
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.
Page 16 of 22
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
VPN type
Proponents
TLS/ SSL




01/07/2009 / Approved / 2.0
Constraints
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


© Crown Copyright 2009
Remarks
Only supports TCP services Recommended
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.
Page 17 of 22
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
Appendix B.
01/07/2009 / Approved / 2.0
Gateway Brokered Remote Access
NHS CFH does not endorse any security product or service. The CommunicationsElectronics 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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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)
and the ability to link into RSA SecurID16 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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0

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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
Appendix C.
01/07/2009 / Approved / 2.0
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
Remote Access – Good Practice Guideline
NPFIT-FNT-TO-IG-GPG-0021.10
01/07/2009 / Approved / 2.0
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