Special Publication 800-46

Revision 1 (Draft) 

Guide to Enterprise Telework 

and Remote Access Security 

(Draft) 

Recommendations of the National Institute 

of Standards and Technology 

Karen Scarfone 

Paul Hoffman 

Murugiah Souppaya 
Guide to Enterprise Telework and Remote 

Access Security (Draft) 

Recommendations of the National 

Institute of Standards and Technology 

Karen Scarfone 

Paul Hoffman 

Murugiah Souppaya 

NIST Special Publication 800-46 

Revision 1 (Draft) 

C O M P U T E R S E C U R I T Y

Computer Security Division 

Information Technology Laboratory 

National Institute of Standards and Technology 

Gaithersburg, MD 20899-8930 

February 2009 

U.S. Department of Commerce 

Carlos M. Gutierrez, Secretary 

National Institute of Standards and Technology

Dr. Patrick D. Gallagher, Deputy Director 
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Reports on Computer Systems Technology 

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s 

measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of 

concept implementations, and technical analysis to advance the development and productive use of 

information technology. ITL’s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective security and privacy of 

sensitive unclassified information in Federal computer systems. This Special Publication 800-series 

reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative 

activities with industry, government, and academic organizations. 

Certain commercial entities, equipment, or materials may be identified in this 

document in order to describe an experimental procedure or concept adequately. 

Such identification is not intended to imply recommendation or endorsement by the 

National Institute of Standards and Technology, nor is it intended to imply that the 

entities, materials, or equipment are necessarily the best available for the purpose. 

National Institute of Standards and Technology Special Publication 800-46 Revision 1 (Draft) 

Natl. Inst. Stand. Technol. Spec. Publ. 800-46rev1, 41 pages (Feb. 2009) 

ii
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Acknowledgements 

The authors, Karen Scarfone of the National Institute of Standards and Technology (NIST), Paul Hoffman 

of the VPN Consortium, and Murugiah Souppaya of NIST, wish to thank their colleagues who reviewed 

drafts of this document and contributed to its technical content, particularly Tim Grance of NIST. The 

authors would also like to acknowledge that NIST Special Publication (SP) 800-114, User’s Guide to 

Securing External Devices for Telework and Remote Access, which was authored by Karen Scarfone and 

Murugiah Souppaya, was a major source of material for this publication. Additional acknowledgements 

will be added to the final version of the publication. 

iii
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Table of Contents 

Executive Summary..............................................................................................................ES-1

1. Introduction ......................................................................................................................1-1

1.1 Authority...................................................................................................................1-1

1.2 Purpose and Scope .................................................................................................1-1

1.3 Audience..................................................................................................................1-1

1.4 Document Structure .................................................................................................1-1

2. Overview of Enterprise Telework and Remote Access Security .................................2-1

2.1 Vulnerabilities, Threats, and Security Controls ........................................................2-1

2.2 Remote Access Methods .........................................................................................2-3

2.2.1 Tunneling......................................................................................................2-3

2.2.2 Portals ..........................................................................................................2-5

2.2.3 Remote Desktop Access ..............................................................................2-6

2.2.4 Direct Application Access .............................................................................2-8

3. Remote Access Solution Security..................................................................................3-1

3.1 Remote Access Server Security ..............................................................................3-1

3.2 Remote Access Server Placement ..........................................................................3-1

3.2.1 Intermediary Remote Access Servers ..........................................................3-2

3.2.2 Endpoint Remote Access Servers................................................................3-3

3.3 Remote Access Authentication, Authorization, and Access Control........................3-3

3.3.1 Authentication...............................................................................................3-3

3.3.2 Authorization.................................................................................................3-4

3.3.3 Access Control for Network Communications ..............................................3-5

3.3.4 Access Control for Applications....................................................................3-6

3.4 Remote Access Client Software Security ................................................................3-6

4. Telework Client Device Security.....................................................................................4-1

4.1 Securing Telework PCs ...........................................................................................4-2

4.2 Securing Telework Consumer Devices....................................................................4-3

4.3 Protecting Data on Telework Client Devices............................................................4-4

4.3.1 Encrypting Data at Rest................................................................................4-4

4.3.2 Using Virtual Machines.................................................................................4-5

4.3.3 Backing Up Data on Telework Devices ........................................................4-5

5. Security Considerations for the Telework and Remote Access Life Cycle................5-1

5.1 Initiation....................................................................................................................5-1

5.1.1 Permitted Forms of Remote Access.............................................................5-2

5.1.2 Restrictions on Telework Client Devices and Remote Access Levels..........5-2

5.1.3 Additional User Requirements......................................................................5-4

5.2 Planning and Design................................................................................................5-5

5.3 Implementation ........................................................................................................5-5

5.4 Operations and Maintenance...................................................................................5-6

5.5 Disposition ...............................................................................................................5-7

Appendix A— Glossary .......................................................................................................... A-1

iv
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Appendix B— Acronyms and Abbreviations ....................................................................... B-1

Appendix C— Resources ....................................................................................................... C-1

List of Figures 

Figure 2-1. Tunneling Architecture.............................................................................................2-4

Figure 2-2. Portal Architecture ...................................................................................................2-5

Figure 2-3. Remote Desktop Access Architecture .....................................................................2-6

Figure 2-4. Direct Application Access Architecture....................................................................2-8

v
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Executive Summary 

Many organizations’ employees and contractors use enterprise telework technologies to perform work 

from external locations. Most teleworkers use remote access technologies to interface with an 

organization’s non-public computing resources. The nature of telework and remote access technologies—

permitting access to protected resources from external networks and often external hosts as well—

generally places them at higher risk than similar technologies only accessed from inside the organization, 

as well as increasing the risk to the internal resources made available to teleworkers through remote 

access. 

All the components of telework and remote access solutions, including client devices, remote access 

servers, and internal resources accessed through remote access, should be secured against expected 

threats, as identified through threat models. Major security concerns include the lack of physical security 

controls, the use of unsecured networks, the connection of infected devices to internal networks, and the 

availability of internal resources to external hosts. This publication provides information on security 

considerations for several types of remote access solutions, and it makes recommendations for securing a 

variety of telework and remote access technologies. It also gives advice on creating telework security 

policies. 

To improve the security of their telework and remote access technologies, organizations should 

implement the following recommendations: 

Plan telework security policies and controls based on the assumption that external environments 

contain hostile threats. 

An organization should assume that external facilities, networks, and devices contain hostile threats that 

will attempt to gain access to the organization’s data and resources. Organizations should assume that 

telework client devices, which are used in a variety of external locations and are particularly prone to loss 

or theft, will be acquired by malicious parties who will attempt to recover sensitive data from them. 

Options for mitigating this type of threat include encrypting the device’s storage and not storing sensitive 

data on client devices. Organizations should also assume that communications on external networks, 

which are outside the organization’s control, are susceptible to eavesdropping, interception, and 

modification. This type of threat can be mitigated, but not eliminated, by using encryption technologies to 

protect the confidentiality and integrity of communications, as well as authenticating each of the 

endpoints to each other to verify their identities. Another important assumption is that telework client 

devices will become infected with malware; possible controls for this include using anti-malware 

technologies, using network access control solutions that verify the client’s security posture before 

granting access, and using a separate network at the organization’s facilities for telework client devices 

brought in for internal use. 

Develop a telework security policy that defines telework and remote access requirements. 

A telework security policy should define which forms of remote access the organization permits, which 

types of telework devices are permitted to use each form of remote access, and the type of access each 

type of teleworker is granted. It should also cover how the organization's remote access servers are 

administered and how policies in those servers are updated. 

As part of creating a telework security policy, an organization should make its own risk-based decisions 

about what levels of remote access should be permitted from which types of telework client devices. For 

example, an organization may choose to have tiered levels of remote access, such as allowing 

organization-owned personal computers (PC) to access many resources, teleworker-owned PCs to access 

ES-1 
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

a limited set of resources, and other PCs and types of devices (e.g., cell phones, personal digital assistants 

[PDA]) to access only one or two lower-risk resources, such as Web-based email. Having tiered levels of 

remote access allows an organization to limit the risk it incurs by permitting the most-controlled devices 

to have the most access and the least-controlled devices to have minimal access. 

There are many factors that organizations should consider when setting policy regarding levels of remote 

access to grant; examples include the sensitivity of the telework, the level of confidence in the telework 

client device’s security posture, the cost associated with telework devices, the locations from which 

telework is performed, and compliance with mandates and other policies. For telework situations that an 

organization determines are particularly high-risk, an organization may choose to specify additional 

security requirements. For example, high-risk telework might be permitted only from organization-issued 

and secured telework client devices that employ multi-factor authentication and storage encryption. 

Organizations may also choose to reduce risk by prohibiting telework and remote access involving 

particular types of information, such as highly sensitive personally identifiable information (PII). 

Ensure that remote access servers are secured effectively and are configured to enforce telework 

security policies. 

Remote access servers provide way for external hosts to gain access to internal resources, so their security 

is particularly important. In addition to permitting unauthorized access to resources, a compromised 

server could be used to eavesdrop on remote access communications and manipulate them, as well as to 

provide a “jumping off” point for attacking other hosts within the organization. It is particularly important 

for organizations to ensure that remote access servers are kept fully patched and that they can only be 

managed from trusted hosts by authorized administrators. Organizations should also carefully consider 

the network placement of remote access servers; in most cases, a server should be placed at an 

organization’s network perimeter so that it acts as a single point of entry to the network and enforces the 

telework security policy before any remote access traffic is permitted into the organization’s internal 

networks. 

Secure telework client devices against common threats and maintain their security regularly. 

There are many threats to telework client devices, including malware and device loss or theft. Generally, 

telework client devices should have the same local security controls as those used in the organization’s 

secure configuration baseline for its non-telework client devices deployed in the enterprise. Examples are 

applying operating system and application updates promptly, disabling unneeded services, and using 

antivirus software and a personal firewall. However, because threats are generally greater in external 

environments, additional security controls are recommended, and existing security controls may need to 

be adjusted. For example, if a personal firewall on a telework client device has a single policy for all 

environments, then it is likely to be too restrictive in some situations and not restrictive enough in others. 

Whenever possible, organizations should use personal firewalls capable of supporting multiple policies 

for their telework client devices and configure the firewalls properly for the enterprise environment and 

an external environment, at a minimum. 

Organizations should ensure that all types of telework client devices are secured, including PCs, cell 

phones, and PDAs. For devices other than PCs, security capabilities and the appropriate security actions 

vary widely by device type and specific products, so organizations should provide guidance to device 

administrators and users who are responsible for securing telework consumer devices on how they should 

secure them. 

ES-2 
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

1. Introduction 

1.1 Authority 

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its 

statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, 

Public Law 107-347. 

NIST is responsible for developing standards and guidelines, including minimum requirements, for 

providing adequate information security for all agency operations and assets; but such standards and 

guidelines shall not apply to national security systems. This guideline is consistent with the requirements 

of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency 

Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental 

information is provided in A-130, Appendix III. 

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental 

organizations on a voluntary basis and is not subject to copyright, though attribution is desired. 

Nothing in this document should be taken to contradict standards and guidelines made mandatory and 

binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these 

guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, 

Director of the OMB, or any other Federal official. 

1.2 Purpose and Scope 

The purpose of this publication is to assist organizations in mitigating the risks associated with the 

enterprise technologies used for telework, including remote access servers, telework client devices, and 

remote access communications. The publication emphasizes the importance of securing sensitive 

information stored on telework devices and transmitted through remote access across external networks. 

This publication provides recommendations for creating telework-related policies and for selecting, 

implementing, and maintaining the necessary security controls for remote access servers and clients. 

1.3 Audience 

This publication is for security, system, and network engineers and administrators, as well as computer 

security program managers, who are responsible for the technical aspects of preparing, operating, and 

securing remote access solutions and telework client devices. The material in this publication is 

technically oriented, and it is assumed that readers have at least a basic understanding of remote access, 

networking, network security, and system security. 

1.4 Document Structure 

The remainder of this document is organized into the following sections: 

 Section 2 provides an overview of enterprise telework and remote access security. It discusses general 

vulnerabilities, threats, and common security controls against telework and remote access solutions. It 

also describes the high-level architectures of common remote access methods and the security 

characteristics of each architecture. 

1-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Section 3 presents recommendations for securing remote access solutions, including server security, 

server placement, and client software security. It also covers authentication, authorization, and access 

control for remote access solutions. 

 Recommendations for securing telework client devices and protecting data on them are presented in 

Section 4. 

 Section 5 discusses security throughout the telework and remote access life cycle. Examples of topics 

addressed in this section include telework security policy creation, design and implementation 

considerations, and operational processes that are particularly helpful for security. 

The document also contains appendices with supporting material. Appendices A and B contain a glossary 

and an acronym list, respectively. Appendix C lists resources that may be useful for gaining a better 

understanding of telework and remote access security. 

1-2
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

2. Overview of Enterprise Telework and Remote Access Security 

Many people telework (also known as telecommuting), which is the ability for an organization’s 

employees and contractors to perform work from locations other than the organization’s facilities. 

Teleworkers use various client devices, such as desktop and laptop computers, cell phones, and personal 

digital assistants (PDA), to read and send email, access Web sites, review and edit documents, and 

perform many other tasks. Most teleworkers use remote access, which is the ability for an organization’s 

users to access its non-public computing resources from locations other than the organization’s facilities. 

This section of the publication provides an overview of security concerns for enterprise telework and 

remote access technologies. It explains the primary vulnerabilities and threats specific to telework and 

remote access security, and recommends mitigation strategies for those threats. It also discusses the most 

commonly used types of remote access methods, examines their major vulnerabilities, and recommends 

security controls to mitigate threats. 

2.1 Vulnerabilities, Threats, and Security Controls 

Telework and remote access solutions typically need to support several security objectives. These can be 

accomplished through a combination of security features built into the remote access solutions and 

additional security controls applied to the telework client devices and other components of the remote 

access solution. The most common security objectives for telework and remote access technologies are as 

follows: 

 Confidentiality—ensure that remote access communications and stored user data cannot be read by 

unauthorized parties 

 Integrity—detect any intentional or unintentional changes to remote access communications that 

occur in transit 

 Availability—ensure that users can access resources through remote access whenever needed 

 Access Control—restrict the rights of devices or users to access resources through remote access.1

To achieve these objectives, all of the components of telework and remote access solutions, including 

client devices, remote access servers, and internal servers accessed through remote access, should be 

secured against a variety of threats. General security recommendations for any IT technology are 

provided in NIST Special Publication (SP) 800-53, Recommended Security Controls for Federal 

Information Systems.

2

 Specific recommendations for securing telework and remote access technologies 

are presented in this publication and are intended to supplement the controls specified in SP 800-53. 

Telework and remote access technologies often need additional protection because their nature generally 

places them at higher exposure to external threats than technologies only accessed from inside the 

organization. Before designing and deploying telework and remote access solutions, organizations should 

develop threat models for the remote access servers and the resources that are accessed through remote 

access. This will help organizations to identify security requirements and to design the remote access 

solution to incorporate the controls needed to meet the security requirements. Major security concerns for 

these technologies that would be included in most telework threat models are as follows: 

 

1

 This material is derived from NIST SP 800-97, Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i

by Sheila Frankel, Bernard Eydt, Les Owens, and Karen Scarfone (http://csrc.nist.gov/publications/PubsSPs.html). 2

 These recommendations are linked to three security categories—low, moderate, and high—based on the potential impact of 

a security breach involving a particular system, as defined in Federal Information Processing Standard (FIPS) 199, 

Standards for Security Categorization of Federal Information and Information Systems. 

2-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Lack of Physical Security Controls. Telework client devices are used in a variety of locations 

outside the organization’s control, such as employees’ homes, coffee shops, hotels, and conferences. 

The mobile nature of these devices makes them likely to be lost or stolen, which places the data on 

the devices at increased risk of compromise. When planning telework security policies and controls, 

organizations should assume that client devices will be acquired by malicious parties who will 

attempt to recover sensitive data from the devices. The primary mitigation strategies are either to 

encrypt the client device’s storage so that sensitive data cannot be recovered from it by unauthorized 

parties, or to not store sensitive data on client devices.

 Unsecured Networks. Because nearly all remote access occurs over the Internet, organizations 

normally have no control over the security of the external networks used by telework clients. 

Communications systems used for remote access include telephone modems, broadband networks 

such as Digital Subscriber Line (DSL) and cable, and wireless mechanisms such as IEEE 802.11, 

WiMAX, and cellular networks.3

 These communications systems are susceptible to eavesdropping, 

which places sensitive information transmitted during remote access at risk of compromise. Man-inthe-middle (MITM) attacks may also be performed to intercept and modify communications. 

Organizations should plan their remote access security on the assumption that the networks between 

the telework client device and the organization, including teleworkers’ home networks, cannot be 

trusted. Risk from use of unsecured networks can be mitigated, but not eliminated, by using 

encryption technologies to protect the confidentiality and integrity of communications, as well as 

using mutual authentication to verify the identities of both endpoints. 

 Infected Devices on Internal Networks. Telework client devices, particularly laptops, are often used 

on external networks and then brought into the organization and attached directly to the 

organization’s internal networks. If a client device is infected with malware, this malware may spread 

throughout the organization once the client device is connected to the internal network. Organizations 

should assume that client devices will become infected and plan their security controls accordingly. In 

addition to using appropriate anti-malware technologies from the organization’s secure configuration 

baseline, such as using antivirus software on client devices, organizations should consider the use of 

network access control (NAC) solutions that verify the security posture of a client device before 

allowing it to use an internal network. Organizations should also consider using a separate network 

for telework client devices, instead of permitting them to directly connect to the internal network. 

 External Access to Internal Resources. Remote access provides hosts on external networks with 

access to internal resources, such as servers. If these internal resources were not previously accessible 

from external networks, making them available via remote access will expose them to external threats 

and significantly increase the likelihood that they will be compromised. Organizations should 

carefully consider the balance between the benefits of providing remote access to additional resources 

and the potential impact of a compromise of those resources. Organizations should ensure that any 

internal resources they choose to make available through remote access are hardened appropriately 

against external threats and that access to the resources is limited to the minimum necessary through 

firewalling and other access control mechanisms. 

The rest of this section describes remote access technologies and discusses security considerations for 

each, focusing on the elements described above. 

 

3

 Because of this assumption of lack of security of the network connection, this publication does not address leased lines, dialup modems, or other communications mechanisms that can be secured at the data link layer. If an organization uses a data 

link mechanism that adds security, the type of security described in this document would be on top of that data link security, 

but would not interact with it. 

2-2
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

2.2 Remote Access Methods 

Organizations have many options for providing remote access to their computing resources. For the 

purposes of this publication, the remote access methods most commonly used for teleworkers have been 

divided into four categories based on their high-level architectures: tunneling, portals, remote desktop 

access, and direct application access. The remote access methods in all four categories have some features 

in common: 

 They are all dependent on the physical security of the client devices. 

 They can use multiple types of server and user authentication. This flexibility allows some remote 

access methods to work with an organization’s existing authentication mechanisms, such as 

passwords or certificates. Some remote access methods have standardized authentication 

mechanisms, while others use implementation-specific mechanisms. 

 They can use cryptography to protect the data flowing between the telework client device and the 

organization from being viewed by others. This cryptographic protection is inherent in VPNs and 

cryptographic tunneling in general, and it is an option in most remote desktop access and direct 

application access systems. 

 They can allow teleworkers to store data on their client devices. For example, most tunnel, portal, and 

remote desktop access systems offer features for copying files from computers inside the organization 

to the teleworker's client device. This allows the teleworker to work with the data locally, such as in a 

locally installed word processor. Some applications that can be reached through direct application 

access also allow transmitting files to the teleworker. Data may also be stored on client devices 

inadvertently, such as through operating system page files or Web browser caches. It is important that 

all data sent to the teleworker through remote access be covered by the organization's data 

distribution and data retention policies. 

Sections 3 and 4 provide more details on remote access authentication, communications encryption, and 

client data security. 

Additional information on the four categories of remote access methods is provided below. When 

planning a remote access solution, organizations should carefully consider the security implications of the 

remote access methods in each category, in addition to how well each method may meet operational 

requirements. The figures in this section show some of the operational and security properties of the four 

categories of remote access methods. In the figures, the blue pipe is the cryptographically-protected 

communications that originate with the teleworker’s device. The dotted vertical line shows the perimeter 

of the organization’s network; everything to the left of the dotted line represents the Internet, while to the 

right of the dotted line is the internal network. 

2.2.1 Tunneling 

Many remote access methods offer a secure communications tunnel through which information can be 

transmitted between networks, including public networks such as the Internet. Tunnels are typically 

established through virtual private network (VPN) technologies. Once a VPN tunnel has been established 

between a teleworker’s client device and the organization’s VPN gateway, the teleworker can access 

many of the organization’s computing resources through the tunnel. To use a VPN, users must either have 

the appropriate VPN software on their client devices or be on a network that has a VPN gateway system 

on it. In Figure 2-1, a VPN client is installed on each of the client devices, and there is a single VPN 

gateway that runs the VPN server software. The pipe represents a secure remote access connection 

(tunnel) between a client device and the VPN gateway. Through this tunnel, application client software 

2-3
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

(e.g., email client, word processor, web browser, database client) installed on the client device 

communicates with application server software residing on servers within the organization.4

 The VPN 

gateway can take care of user authentication, access control, and other security functions for teleworkers. 

Figure 2-1. Tunneling Architecture 

Tunnels use cryptography to protect the confidentiality and integrity of the transmitted information 

between the client device and the VPN gateway. Tunnels can also authenticate users, provide access 

control (such as restricting which protocols may be transmitted or which internal hosts may be reached 

through remote access), and perform other security functions related to use of the tunnel. However, 

although remote access methods based on tunneling protect the communications between the client device 

and the VPN gateway, they do not provide any protection for the communications between the VPN 

gateway and internal resources. Also, in tunneling solutions, the application client software and data 

resides on the client device, so they are not protected by the tunneling solution and should be protected by 

other means. 

The types of VPNs most commonly used for teleworkers are Internet Protocol Security (IPsec) VPNs and 

Secure Sockets Layer (SSL) tunnel VPNs.5

 Tunneling may also be achieved by using Secure Shell (SSH), 

although this is less commonly used and is often considered more difficult to configure and maintain than 

IPsec or SSL tunnel VPNs. All three forms of tunneling mentioned in this section can protect many 

protocols at once. More information on IPsec VPNs and SSL tunnel VPNs are available from NIST SP 

800-77, Guide to IPsec VPNs and NIST SP 800-113, Guide to SSL VPNs, respectively.6

Many communication encryption protocols can be expanded into tunneling protocols in the same way that 

SSL is used for SSL VPNs. For example, some systems use the SSH protocol to create tunnels, although 

the method for doing so is not yet standardized. In general, standardized tunneling protocols can be 

configured to have the same cryptographic strength and to use the same (or functionally similar) 

mechanism for authenticating the two parties to each other. Different tunneling systems can tunnel 

various protocols; for example, IPsec has standardized extensions that allow it to tunnel Layer 2 protocols 

such as the Point-to-Point Protocol (PPP) and Multiprotocol Label Switching (MPLS). In general, almost 

any communication encryption protocol can be made to tunnel almost any layer. 

 

4

 This architecture, with the VPN gateway and the application servers being on separate hosts, is the most commonly used 

tunneling solution for remote access. However, the VPN gateway and the application servers could be on a single host. 5

 Another, more commonly used form of SSL VPNs uses a portal architecture. Section 2.2.2 discusses SSL portal VPNs. An 

SSL tunnel VPN generally uses a plug-in installed within a Web browser that supports tunneling within an SSL connection. 6

 These NIST SPs, as well as all others in the 800-series, are available at http://csrc.nist.gov/publications/PubsSPs.html. 

2-4
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

The VPN gateway can control access to the parts of the network and the types of access that the 

teleworker gets after authentication. For example, a VPN might allow a particular user to only have 

access to one subnet of the organization's network, or to only run particular applications on certain servers 

on the protected network. In this way, even though the cryptographic tunnel ends at the VPN gateway, the 

gateway can add additional routing to the teleworker's traffic to only allow access to some parts of the 

internal network. 

VPNs are usually established and managed by VPN gateway devices owned and managed by the 

organization being protected. In some cases, organizations outsource their VPNs to trusted third parties. 

Such a third party might simply manage the VPN gateway that is owned by the organization, but other 

third parties offer services where they own and control the VPN gateway. In the latter case, the 

organization should evaluate the security of the proposed solution and ensure it will support the 

organization's security policy. 

2.2.2 Portals 

Another category of remote access solutions involves portals. A portal is a server that offers access to one 

or more applications through a single centralized interface. A teleworker uses a portal client on a telework 

client device to access the portal. Most portals are web-based—for them, the portal client is a regular web 

browser. Figure 2-2 shows the basic portal solution architecture. The application client software is 

installed on the portal server, and it communicates with application server software on servers within the 

organization. The portal server communicates securely with the portal client as needed; the exact nature 

of this depends on the type of portal solution in use, as discussed below. 

Figure 2-2. Portal Architecture 

In terms of security, portals have most of the same characteristics as tunnels: portals protect information 

between client devices and the portal, and they can provide authentication, access control, and other 

security services. However, there is an important difference between tunnels and portals—the location of 

the application client software and associated data. In a tunnel, the software and data are on the client 

device; in a portal, they are on the portal server. A portal server transfers data to the client device as 

rendered desktop screen images or web pages, but data is typically stored on the client device much more 

temporarily than data for a tunneled solution is. Having the application client software centralized gives 

an organization more control over how the software is secured as opposed to more distributed remote 

access solutions. Portals limit the access a teleworker has to particular application clients running on the 

portal itself. Those applications further limit the access the teleworker has to the servers inside the 

network. 

2-5
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

There are a few types of portal solutions commonly used for remote access. A web-based portal provides 

a user with access to multiple web-based applications from a single portal web site. An SSL portal VPN is 

a common form of web-based portal. Another type of portal solution is terminal server access, which 

gives each teleworker access to a separate standard virtual desktop. The terminal server simulates the look 

and feel of a desktop operating system and provides access to applications. Terminal server access 

requires the teleworker either to install a special terminal server client application on the client device or 

to use a Web-based interface, often with a browser plug-in or other additional software provided by the 

organization. Another similar remote access method, called virtual desktop access, involves the user 

connecting to a system that contains virtual images of standardized, non-simulated operating systems and 

desktops. When the teleworker is finished with a remote access session, the virtual image is discarded so 

that the next user will have a clean virtual desktop. 

The mechanism for providing an interface to the teleworker varies among portals. For example, terminal 

server access and virtual desktop access present a standardized virtual desktop to the teleworker, while 

SSL portal VPNs present each application through a web page. The nature of this interface is important 

because it relates to the storage, temporary or permanent, of data. For many portals, the user interface is 

virtual, and after the user session is over, that instance of the interface is essentially destroyed and a clean 

version of the interface used for the next session. Some portals, such as SSL portal VPNs, can be 

configured to establish a secure virtual machine on the client device, restrict all remote access data to 

reside within that virtual machine, and then securely destroy the virtual machine instance and all the data 

that existed within it when the session ends. This helps to ensure that sensitive information does not 

inadvertently become stored on a telework client device, where it could possibly be recovered by a future 

compromise. 

2.2.3 Remote Desktop Access 

A remote desktop access solution gives a teleworker the ability to remotely control a particular desktop 

computer at the organization, most often the user’s own computer at the organization’s office, from a 

telework client device. The teleworker has keyboard and mouse control over the remote computer and 

sees that computer’s screen on the local telework client device’s screen. Remote desktop access allows 

the user to access all of the applications, data, and other resources that are normally available from their 

computer in the office. Figure 2-3 shows the basic remote desktop access architecture. A remote desktop 

access client program is installed on each telework client device, and it connects directly with the 

teleworker’s corresponding internal workstation on the organization’s internal network. 

Figure 2-3. Remote Desktop Access Architecture 

2-6
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

There are two major style of remote desktop access: direct between the telework client and the internal 

workstation, and indirect through a trusted intermediate system. However, direct access is often not 

possible because it is prevented by many firewalls. For example, if the internal workstation is behind a 

firewall performing network address translation (NAT), the telework client device cannot initiate contact 

with it unless either the NAT allows such contact7

 or the internal workstation initiates communications 

with the external telework client device (e.g., periodically checking with the client device to see if it 

wants to connect). 

Indirect remote desktop access is performed through an intermediate server. This server is sometimes part 

of the organization's firewall, but is more often run by a trusted commercial or free third-party service 

outside the organization's network perimeter. Usually there are separate connections between the telework 

client device and the service provider, and between the service provider and the internal workstation, with 

the intermediate server handling the unencrypted communications between connections. The security of 

this intermediate server is very important, because it is responsible for properly authenticating teleworkers 

and preventing unencrypted traffic from being accessed by unauthorized parties. Also, if the 

organization’s security policy requires particular kinds of authentication (such as the two-factor 

authentication required by federal agencies), the intermediate server must support this authentication in 

both directions. Before implementing an indirect remote desktop access solution, an organization should 

evaluate the security provided by the service provider, especially possible threats involving the 

intermediate server and the potential impact of those threats. The organization can then identify 

compensating controls to mitigate the threats, such as applying a second level of communications 

encryption at the application layer, and determine under what circumstances the intermediate system may 

be used, such as for low-risk activities. 

The remote desktop access software protects the confidentiality and integrity of the remote access 

communications and also authenticates the user to ensure that no one else connects to the internal 

workstation. However, because this involves end-to-end encryption of the communications across the 

organization’s perimeter, the contents of the communication are hidden from the network security 

controls at the perimeter, such as firewalls and intrusion detection systems. For many organizations, the 

increased risk caused by this is not worth the benefits, and direct connections from external client devices 

to internal workstations are prohibited. 

Another serious security issue with remote desktop access software is that it is decentralized; instead of 

the organization having to secure a single VPN gateway server or portal server, the organization instead 

has to secure each internal workstation that may be accessed through remote desktop access. Because 

these internal workstations can be accessed from the Internet, either directly or indirectly, they generally 

need to be secured nearly as rigorously as full-fledged remote access servers, yet such workstations were 

usually not designed with that degree of security in mind. Applying compensating controls for each 

workstation to raise its security to an acceptable level often involves a significant amount of time and 

resources, as well as acquisition of additional security controls. Also, authentication solutions such as 

two-factor authentication capabilities may need to be deployed to each internal workstation using remote 

desktop access. 

Generally, remote desktop access solutions should only be used for exceptional cases after a careful 

analysis of the security risks. The other types of remote access solutions described in this section offer 

superior security capabilities. 

 

7

 This can be accomplished using a “pinhole” scheme that requires particular ports to be allocated to each workstation. 

2-7
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

2.2.4 Direct Application Access 

Remote access can be accomplished without using remote access software. A teleworker can access an 

individual application directly, with the application providing its own security (communications 

encryption, user authentication, etc.) Figure 2-4 shows the high-level architecture for direct application 

access. The application client software installed on the telework client device initiates a connection with a 

server, which is typically located at the organization’s perimeter (e.g., on a DMZ). 

Figure 2-4. Direct Application Access Architecture 

One of the most common examples of direct application access is web-based access to email, also known 

as webmail. The teleworker runs a web browser and connects to a web server that provides email access. 

The web server runs HTTP over SSL (HTTPS) to protect the communications, and the webmail 

application on the server authenticates the teleworker before granting access to the teleworker’s email. 

For cases such as webmail that use a ubiquitous application client (e.g., a web browser), direct application 

access provides a highly flexible remote access solution that can be used from nearly any client device. 

For the same reasons discussed in Section 2.2.3, the direct application access architecture is generally 

only acceptable if the servers being accessed by the teleworkers are located on the organization’s network 

perimeter, and not internal networks. Servers on the perimeter are directly accessible from the Internet, so 

they must be well-secured to reduce the likelihood of compromise. Many organizations choose to provide 

direct application access to only a few lower-risk applications that are widely used, such as email, and use 

tunnel or portal methods to provide access to other applications, particularly those that would be at too 

much risk if they were directly accessible from the Internet. 

2-8
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

3. Remote Access Solution Security 

This section presents recommendations for securing remote access solutions. It focuses on remote access 

server security and server placement. It also discusses authentication, authorization, and access control. 

Recommendations for securing remote access client software are presented in this section, while 

recommendations for telework client device security are presented in Section 4. 

3.1 Remote Access Server Security 

Because remote access servers, such as VPN gateways and portal servers, provide ways for external hosts 

to gain access to internal resources, their security is particularly important. In addition to permitting 

unauthorized access to resources, a compromised server could be used to eavesdrop on remote access 

communications and manipulate them, as well as a “jumping off” point for attacking other hosts within 

the organization. Recommendations for general server security are available from NIST SP 800-123, 

Guide to General Server Security. It is particularly important to ensure that remote access servers are kept 

fully patched and that they can only be managed from trusted hosts by authorized administrators. 

VPN gateways and portals can run many services and applications, such as firewalls, antivirus software, 

and intrusion detection software. Organizations should carefully consider the security of any solutions 

involve running a remote access server on the same host as other services and applications. Such solutions 

may offer benefits, such as equipment cost savings, but a compromise of any one of the services or 

applications could permit an attacker to compromise the entire remote access server. Placing the remote 

access server on a separate, dedicated host reduces the likelihood of a remote access server compromise 

and limits its potential impact. Using a separate host may also be advisable if the remote access server is 

likely to place other services and applications at significantly increased risk. 

The security of stored data is another important consideration for remote access server security. For portal 

servers that may temporarily store sensitive user data, wiping such data from the server as soon as it is no 

longer needed can reduce the potential impact of a compromise of the server. The need to wipe sensitive 

data from remote access servers should be determined based on a risk assessment. 

3.2 Remote Access Server Placement 

Major factors organizations should consider when determining where to place a remote access server 

include the following: 

 Device Performance. Remote access services can be computationally intensive, primarily because of 

encryption and decryption. Providing remote access services from a device that also provides other 

services may put too high of a load on the server during peak usage, causing service disruptions. 

 Traffic Examination. Because the contents of encrypted remote access communications cannot be 

examined by network firewalls, intrusion detection systems, and other network security devices, it is 

generally recommended that the remote access architecture be designed so that unencrypted 

communications can be examined by the appropriate network and/or host-based security controls. 

 Traffic Not Protected by the Remote Access Solution. Organizations should carefully consider the 

threats against network traffic that is not protected by the remote access solution, such as traffic 

passed between a remote access server and internal resources. 

 NAT. The use of NAT can cause operational problems for some remote access solutions. For 

example, any remote access system that requires the teleworker to connect directly to a host inside the 

network, such as a remote desktop system or a VPN with its public endpoint inside the network, 

3-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

cannot work with a NAT without special configuration that may or may not work. NATs also prevent 

the use of applications that require addresses not to change (e.g., embed addresses in the application 

content). 

Organizations should carefully consider the placement of their remote access servers. Some remote access 

servers, such as VPN gateways, generally act as intermediaries between telework devices and the 

organization’s internal computing resources. Other hosts providing remote access services, such as direct 

application access and remote desktop access solutions, are true endpoints for remote access 

communications. Both categories of remote access servers are discussed below. 

Remote access servers are usually placed at an organization's network perimeter. Such placement is 

common because the organizational security policies most often apply to the entire network of an 

organization. Even if a particular security policy applies to one sub-network of the organization, most 

remote access servers can restrict access to sub-networks and therefore can be placed at the organization's 

perimeter. In some network layouts, it is better to put a remote access server inside the perimeter, at the 

boundary of a sub-network. The rest of this section describes when such a network layout might be 

appropriate. 

3.2.1 Intermediary Remote Access Servers 

Intermediate remote access servers connect external hosts to internal resources, so they should usually be 

placed at the network perimeter. The server acts as a single point of entry to the network from the 

perimeter and enforces the telework security policy. If remote access is needed to a particular subnetwork within the organization, there are generally two options: place the remote access server at the 

edge of the sub-network—where the sub-network joins the full network—or place it at the perimeter of 

the full network and use additional mechanisms to restrict the teleworkers to only be able to access the 

specified sub-network. The value of placing the remote access server at the network perimeter versus the 

sub-network perimeter differs for the four types of remote access methods: 

 Tunneling servers usually give administrators sufficient control over the internal resources to which a 

teleworker has access that there is little advantage to setting up a tunneling server at the edge of a subnetwork, as opposed to the network perimeter. 

 Portal servers run the application client software on the servers themselves. Placing them at the 

network perimeter has a similar effect as placing them at the edge of a sub-network because the 

remote access user is only running applications on the portal server, not on servers inside the network. 

 Remote desktop access does not involve servers, so there is no issue with server placement. 

 Direct application access servers run the application server software on the servers themselves. 

Placing them at the network perimeter has a similar effect as placing them at the edge of a subnetwork because the remote access user is only running applications on the direct application access 

server, not on servers inside the network. 

Thus, the only types of remote access servers that may be appropriate to place at the sub-network 

perimeter are portal servers and direct application access servers, but even in those two cases, it is often 

better to run those on the organization’s perimeter so that the organization’s firewall can control access to 

these servers for all workers, not just teleworkers. Further, to simplify management of the network and 

the network’s security policy, running all remote access servers at the network perimeter is also advisable. 

Therefore, organizations should place remote access servers at the network perimeter instead of the subnetwork perimeter unless there are compelling reasons to do otherwise. 

3-2
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

If a network has a firewall at the perimeter, remote access servers on that network should be immediately 

adjacent to, or in the same physical device as, the firewall so as to not circumvent the firewall’s security 

policy. In the case that the two devices are the same, there is of course no question about the placement of 

the remote access server. However, if the remote access server is a different device than the firewall, the 

network planner must decide where to place the remote access server. If the firewall has a DMZ 

associated with it, that is likely to be the best location for the server, otherwise the server should be 

outside the firewall if the network topology allows for it. Both of these placements provide logical 

separation between the remote access server and the internal networks. To reduce the potential impact of 

a compromise of the remote access server, organizations should restrict communications between the 

server and internal networks. The server should only be able to initiate communications with the internal 

hosts and services specifically authorized for remote access usage, and only the appropriate internal hosts 

(e.g., trusted hosts used to administrate the remote access server) should be able to initiate 

communications with the remote access server. 

If the remote access gateway must be placed inside the firewall, the firewall’s security policy needs to be 

adjusted to allow the traffic from teleworkers (and only teleworkers) to get to the remote access gateway. 

This is often difficult to maintain and error-prone. Also, because all remote access communications 

should be encrypted, as discussed in Section 4, network security controls would be unable to monitor the 

contents of the communications. Therefore, this solution should be avoided. 

3.2.2 

3.3.1 Authentication 

Endpoint Remote Access Servers 

Endpoint remote access servers should be placed on the organization’s DMZ whenever possible. This 

allows a perimeter firewall to limit access to the servers from both external and internal hosts, and avoids 

the security issues discussed in Section 2.2.3 involved in allowing external traffic to pass directly into the 

internal network. Implementations of remote desktop access solutions usually rely on internal 

workstations to provide remote access services, so the use of such solutions is not generally 

recommended. 

3.3 Remote Access Authentication, Authorization, and Access Control 

Most of the computing resources used through remote access are available only to an organization’s users, 

and often only a subset of those users. To ensure that access is restricted properly, remote access servers 

should authenticate each teleworker before granting any access to the organization’s resources, and then 

use authorization technologies to ensure that only the necessary resources can be used. Authentication can 

also be used to confirm the legitimacy of telework client devices and remote access servers. Access 

control technologies are also needed to restrict access to network communications and applications. This 

section provides additional details on remote access authentication, authorization, and access control. 

There are many ways to authenticate remote access users, such as with passwords, digital certificates, or 

hardware authentication tokens. If passwords are the only form of authentication for a remote access 

solution, then generally the remote access solution’s authentication mechanism should be different from 

the organization’s other authentication mechanisms, such as email or domain passwords, unless direct 

application access is being used. Having different passwords reduces the impact that a compromise of 

remote access credentials would have on other information resources, and vice versa, and it is particularly 

important if users are entering passwords into telework devices not controlled by the organization. 

3-3
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

However, having different passwords for remote access and other systems is often not enforceable8

, and it 

should be assumed that some users will use the same passwords for both. Organizations with higher 

security needs or with concerns about the security of passwords should consider using authentication that 

does not rely solely on passwords, such as multifactor authentication. 

Federal agencies are required to “allow remote access only with two-factor authentication where one of 

the factors is provided by a device separate from the computer gaining access”, according to OMB 

Memorandum 07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable 

Information.

9

 Such two-factor authentication currently tends to be implemented through the use of a 

cryptographic token and a password, because other authentication methods are often not available on 

telework client devices. For example, most mobile devices do not have biometric capabilities, smart card 

readers, or other additional authentication capabilities. This is particularly true for client devices not 

issued by the organization. 

Many organizations require teleworkers to reauthenticate periodically during long remote access sessions, 

such as after each 8 hours of a session or after 30 minutes of idle time. This helps organizations confirm 

that the person using remote access is authorized to do so. OMB M-07-16 requires Federal agencies to 

“use a ‘time-out’ function for remote access and mobile devices requiring user re-authentication after 

thirty minutes of inactivity”.10 Remote access servers vary in their support for authentication methods and 

session timeouts, so additional mechanisms may be needed to implement and enforce these policies. 

Additional information on the types of user authentication methods appropriate for remote access can be 

found in NIST SP 800-63, Electronic Authentication Guideline.

11 

Whenever feasible, organizations should implement mutual authentication, so that a remote access user 

can verify the legitimacy of a remote access server before providing authentication credentials to it. An 

example is verifying a digital certificate presented by the remote access server to ensure that the server is 

controlled by the organization. Some remote access methods, such as IPsec and SSL VPN technologies, 

include mandatory server authentication during the setup of the secure communications channel. Server 

authentication is most important for remote access methods where a user is manually establishing the 

remote access connection, such as typing a URL into a Web browser. Section 3.4 presents additional 

information on this. 

3.3.2 Authorization 

 

After verifying the identity of a remote access user, organizations may choose to perform checks 

involving the telework client device to determine which internal resources the user should be permitted to 

access. The most common way of implementing this is having the remote access server perform “health 

checks” on the teleworker's client device. These health checks require software on the user’s system that 

is controlled by the remote access server to verify compliance with certain requirements from the 

organization’s secure configuration baseline, such as the user’s antivirus software being up-to-date, the 

operating system being fully patched, and the user’s system being owned and controlled by the 

organization. Some remote access solutions can also determine if the device has been secured by the 

organization and what type of device it is (e.g., desktop/laptop, PDA, video game system). Based on the 

results of these checks, the organization can determine whether the device should be permitted to use 

8

 In some cases, it can be enforced by using a centralized password management system for both the remote access passwords 

and the other systems’ passwords. Many centralized password management systems can ensure that the same password is 

not used for two different systems. 9

 OMB M-07-16 is available at http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf. 10 NIST SP 800-53 Revision 2 also has a security control for this, Access Control 11 (AC-11), Session Lock. 11 A new version of SP 800-63 is currently being developed. A draft version is available for review from 

http://csrc.nist.gov/publications/PubsDrafts.html. 

3-4
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

remote access and what level of access should be granted. If the user has acceptable authorization 

credentials but the client device does not pass the health check, the user and device may be granted 

limited access to the internal network, no network access at all, or access to a quarantine network so that 

the security deficiencies can be fixed. This form of authorization is part of what is now referred to as 

network access control (NAC). 

NAC is a security policy enforcement mechanism, not a true security protection mechanism. The 

mechanisms used to accomplish NAC are still changing as products mature. Many health checks are 

performed in ways that can be trivially circumvented by malware, so organizations should not rely on 

NAC to stop determined attackers from gaining network access. However, organizations should use NAC 

whenever feasible to detect major security policy violations in telework client devices and to prevent 

teleworkers from inadvertently using the wrong device for telework. 

For organizations that want to restrict or prohibit remote access by telework devices on non-home 

external networks, having organization-controlled security devices on home networks may be particularly 

helpful. An example of such a policy is allowing access to a particular Web server from anywhere, but 

disallowing access to a sensitive resource from all locations other than authorized home networks. Some 

organizations choose to do this because external networks, such as those at hotels, airport lounges, and 

coffee shops, may have more prevalent and serious threats than home networks. Such policies can be 

implemented effectively if the organization has a security device deployed on the home network, but 

otherwise are often impractical. Home network IP addresses often change, unless a teleworker has a fixed 

IP address,12 and teleworkers are usually unaware of their address changing or what the new address is. 

Maintaining a list of permitted IP address may take significant resources. Also, errors in the list and 

failures to update it promptly may prevent teleworkers from using resources that they are authorized to 

access. An alternative strategy is to prompt users to report their location when signing into a remote 

access system; because this information cannot be verified, organizations should not rely on it for security 

purposes. 

3.3.3 

 

Access Control for Network Communications 

A major component of controlling access to network communications is the use of cryptography. At a 

minimum, any sensitive information passing over the Internet, wireless networks, and other untrusted 

networks should have its confidentiality and integrity preserved through use of cryptography. Federal 

agencies are required to use cryptographic algorithms that are NIST-approved and contained in FIPSvalidated modules. The FIPS 140 specification, Security Requirements for Cryptographic Modules, 

defines how cryptographic modules are validated.13 It is important to note that for a remote access system 

to be considered compliant to FIPS 140, both sides of the interaction must have passed FIPS 140 

validation. Many remote access systems, such as SSL VPNs, support the use of remote access client 

software from other vendors, so there may be two or more distinct validation certificates for a particular 

remote access system. 

Some remote access methods, such as IPsec and SSL VPNs, often inherently include NIST-approved 

mechanisms for encrypting communications and verifying their integrity. Other remote access methods 

may use TLS or other NIST-approved cryptographic mechanisms to provide protection. Remote access 

methods that do not offer NIST-approved mechanisms for protecting the confidentiality and integrity of 

communications should have additional NIST-approved protection applied, such as tunneling the remote 

access method’s communications within a VPN or running the communications over TLS. Remote access 

methods that offer both NIST-approved and non-NIST-approved cryptographic mechanisms should 

12 Many Internet service providers (ISP) that provide home access do not allow users to have a fixed IP address, and most ISPs 

that do permit fixed IP addresses charge a monthly fee for this service. 13 The current version of FIPS 140 is 140-2. It is available from http://csrc.nist.gov/publications/PubsFIPS.html. 

3-5
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

disable the use of all non-approved cryptographic mechanisms if possible. All remote access methods 

should conform to the key strength requirements listed in NIST SP 800-56A, Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography. 

Access control for network communications may also involve determining which traffic should be 

protected. Some remote access solutions offer options for this; for example, many VPN clients have a 

feature called split tunneling which, if enabled, will tunnel all communications involving the 

organization’s internal resources through the VPN, thus protecting them, but will exclude all other 

communications from going through the tunnel. Split tunneling increases efficiency for communications 

and reduces load on the remote access solution, but it also prevents the organization from examining 

much of the teleworkers’ network traffic and from protecting the confidentiality and integrity of that 

traffic. For teleworkers using VPNs on untrusted networks, particularly higher-risk networks such as 

wireless hotspots, organizations should consider disabling split tunneling capabilities so that attackers 

cannot eavesdrop on any of the teleworkers’ network communications. 

For their teleworkers’ home networks, some organizations provide VPN gateways, firewall appliances, or 

other security devices that are configured to enforce the organization’s security policies. This gives 

organizations greater control over telework security but may also involve significant costs in purchasing, 

deploying, managing, and maintaining the security devices. Also, because most home networks used for 

telework are also used for other purposes, the security policies could interfere with other use of the home 

network if not designed properly. Another drawback is that the security devices, if stolen by or otherwise 

acquired by an attacker, could grant an attacker easy access to the organization’s systems if the 

organization’s remote access solution authenticates the security device only and not the remote access 

user. Therefore, when such security devices are used, both the device and the user should be authenticated 

by the organization. 

3.3.4 Access Control for Applications 

Different types of remote access architectures offer different levels of granularity for application access 

control. Tunnels often have a mechanism for an administrator to specify which ports on which hosts the 

teleworker has access to; this can limit access so that only specific applications can be used. Portals, by 

their nature, limit the teleworker to applications run on the portal server. Similarly, direct application 

access limits the teleworker to a specific application on a single server. Remote desktop access can only 

provide access control to applications by combining its policies with the access control restrictions that 

are in place on the internal workstations. 

Putting limits put on which applications teleworkers can access does not necessarily prevent teleworkers 

from affecting other resources, because the applications being run may have access to other network 

resources. For example, a web server that the teleworker accesses may cause lookups on database servers, 

data retrieval from file servers, and other actions involving additional servers. Thus, the policy of limiting 

a teleworker to particular applications should be considered in light of what other applications and hosts 

those applications can interact with. 

3.4 Remote Access Client Software Security 

Another important element of remote access solution security is the security configuration of remote 

access client software. Many remote access clients have security features and settings that can be 

remotely managed by a system administrator. Such management is particularly important for client 

software that has complex security settings. For example, many users have difficulty with manually 

setting IPsec configurations or authentication options for remote desktop access. If the client has remote 

management capabilities, an administrator can view its configuration, reconfigure it, and possibly lock the 

3-6
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

configuration. Locking ensures that security settings are not inadvertently or intentionally altered, which 

could reduce remote access security. However, there is no standardization for remote management 

capabilities or interfaces, and many remote access systems do not have remote management features for 

their client software. 

Organizations should carefully plan how remote access client software security will be maintained and 

managed before selecting and deploying a remote access solution. More broadly, organizations should 

also plan how the telework client devices that they provide to teleworkers will be managed and supported, 

such as a help desk agent remotely accessing a device to perform troubleshooting of operational problems 

reported by a teleworker. If not properly secured, remote management capabilities can be misused by 

attackers to compromise telework client devices and use them to gain access to an organization’s internal 

resources. Therefore, organizations should ensure that remote management is properly secured, 

particularly encrypting network communications and performing mutual authentication of endpoints. 

Organizations should also consider the “thickness” of remote access client software. A remote access 

client is considered thick if it is configured so that the organization has nearly complete control over the 

remote access environment. For example, many VPN clients can be configured to be very thick, such as 

tunneling all network communications from the client device to the organization’s network, using the 

organization’s DNS services instead of the local network’s DNS services, and hard-coding the IP address 

of the VPN gateway instead of relying on local name resolution of the DNS server’s name. However, 

many VPN clients can also be configured to be thin, which means that the organization has considerably 

less control over the remote access environment. A thin VPN client might rely on local network services 

and permit communications not involving the organization’s internal resources to be passed unprotected 

across public networks. Some types of remote access solutions, such as portals, remote desktop access, 

and direct application access, have inherently thin remote access clients. 

Thin remote access clients are generally more flexible and efficient than thick clients, but they also cause 

a greater risk of error and compromise—for example, a user could mistype a portal server’s URL in a web 

browser and reach a fraudulent web site. Thick clients help ensure that clients are communicating with 

legitimate remote access servers and other resources. Organizations with higher security needs or with 

particularly high risks against their remote access communications should use thick remote access clients 

whenever possible to reduce the risk of compromise. 

3-7
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

4. Telework Client Device Security 

Telework client devices can be divided into two general categories: 

 Personal computers (PC), which are desktop and laptop computers running standard PC operating 

systems (OS), such as Windows Vista, Windows XP, Linux/Unix, and Mac OS X. PCs can be used 

for any of the remote access methods described in this section. 

 Consumer devices, which are small, usually mobile computers. Examples of consumer devices are 

networking-capable PDAs, cell phones, and video game systems. Consumer devices are most often 

used for web-based remote access, such as web-based portals or direct access to web-based 

applications, but consumer devices are increasingly supporting other forms of remote access as well. 

The difference between PCs and consumer devices is decreasing. Some current consumer devices run 

standard PC OSs, but these are often not intended for users to access directly. Also, consumer devices are 

increasingly offering more functionality previously provided only by PCs. 

Where applicable, the rest of this publication provides recommendations specific to PCs or consumer 

devices. Another set of categories used in the recommendations is the party that is responsible for the 

security of the client device. These categories are as follows: 

 Organization. Client devices in this category are usually acquired, configured, and managed by the 

organization. These devices can be used for any of the organization’s remote access methods. 

 Teleworker. These client devices are owned by the teleworker, who is ultimately responsible for 

securing them and maintaining their security. These devices are usually capable of using many or all 

of the organization’s remote access methods, if permitted. 

 Third party. These client devices are owned, configured, and secured by third parties, such as kiosk 

computers at hotels, and PCs or consumer devices owned by friends and family. Remote access 

options for third party-secured devices are typically quite limited because users cannot or should not 

install software onto them, and even advanced teleworkers cannot force most third-party devices to 

implement even rudimentary security precautions. 

In today’s computing environment, there are many threats to telework client devices. These threats are 

posed by people with many different motivations, including causing mischief and disruption, and 

committing identity theft and other forms of fraud. The primary threat against most telework client 

devices is malware, including viruses, worms, malicious mobile code, Trojan horses, rootkits, and 

spyware. Malware threats can infect client devices through many means, including email, Web sites, file 

downloads and file sharing, peer-to-peer software, and instant messaging. The use of unauthorized 

removable media, such as flash drives, is an increasingly common transmission mechanism for malware. 

Another common threat against telework client devices is loss or theft of the device. Someone with 

physical access to a device has many options for attempting to view the information stored on it. An 

attacker with physical access can also add malware to a device that gives them access to data accessed 

from or entered into the device, such as users’ passwords typed into a laptop keyboard. 

Permitting teleworkers to remotely access an organization’s computing resources gives attackers 

additional opportunities to breach the organization’s security. When a client device uses remote access, it 

is essentially an extension of the organization’s own network. Therefore, if the device is not secured 

properly, it poses additional risk not only to the information that the teleworker accesses, but also to the 

organization’s other systems and networks. Therefore, telework client devices should be secured properly 

and have their security maintained regularly. 

4-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Generally, telework client devices should have the same local security controls as other client devices in 

the enterprise—OS and application security updates applied promptly, unneeded services disabled, 

antivirus software and a personal firewall enabled and kept up-to-date, etc. However, because of the 

threats that client devices face in external environments, additional security controls are recommended, 

and some security controls may need to be adjusted to work effectively in telework environments. This 

section discusses recommendations for securing telework client devices and the data that they contain. 

Organizations should be responsible for securing their own telework client devices and should also 

require their users to implement and maintain appropriate, often similar, levels of security for personallyowned client devices that they use for telework. The mechanisms for securing organization-owned and 

personally-owned telework client devices are similar, but some of the security controls might not be 

feasible for teleworkers to implement on their own. See NIST SP 800-114, User’s Guide to Securing 

External Devices for Telework and Remote Access, for recommendations for users securing their own 

telework client devices. Section 5 contains additional discussion of the feasibility of relying on users to 

establish and maintain the security of devices. 

4.1 Securing Telework PCs 

One of the most important security measures for a telework PC is having a properly configured personal 

firewall installed and enabled. Personal firewalls are needed to stop network-based threats in many 

environments. If a personal firewall has a single policy for all environments, then it is likely to be too 

restrictive at times, such as when on the organization’s internal network, and not restrictive enough at 

other times, such as when on a third-party external wireless network. So personal firewalls capable of 

supporting multiple policies should be used whenever possible and configured properly for the enterprise 

environment and an external environment, at a minimum. 

Many firewalls require the user to manually select the appropriate policy or environment from a list, but 

some personal firewalls can be configured to “auto-sense” the network they are on and choose a security 

policy based on that information. Although auto-sensing helps to automate the security process, it may 

not always work correctly and could apply the wrong policy at times, making the computer insecure or 

blocking needed functionality. Thus, organizations that want to use auto-sensing features should test them 

thoroughly before relying on them, as well as educating users on how they work and how users can 

override them if the wrong policy has been selected. Auto-sensing features should only be used if they 

notify the teleworker what environment the feature thinks the user is in so that the user can override it if 

the auto-sensing feature has misidentified the environment. 

Another important consideration for telework PCs is applying OS and application security updates.14 For 

personally-owned telework PCs, this generally involves configuring the OS and applications to 

automatically contact the vendors’ online services frequently to check for updates and download and 

install them. Determining how to configure organization-controlled telework PCs to acquire updates can 

be significantly more complicated. An organization might wish to use a centralized patch management 

system for all its PCs, but if telework PCs rely on such a system, they may not receive updates promptly 

if they are configured to get updates only from the organization’s centralized patch management system. 

For example, a user might connect a telework PC to an external network but not establish a remote access 

connection to the organization. The PC may be exposed to threats that could exploit its unpatched 

vulnerabilities, and patches would not be available until some time after the user established a remote 

access session. Another potential problem with keeping software updated is that remote access sessions 

 

14 Generally, the most important applications to keep up-to-date are those that are used for security (e.g., antivirus software,

personal firewalls) or remote access, and those that are network-capable and frequent vectors for exploits, such as Web 

browsers, email clients, and instant messaging clients. 

4-2
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

may be brief, particularly if the teleworker is on travel. This might preclude larger updates from being 

downloaded if the software performing the updates does not permit updates to be downloaded in pieces. 

Organizations should carefully consider these issues when planning how their telework PCs will be kept 

current with OS and application updates. Organizations should also encourage users to fully update their 

telework PCs before taking them on travel or to other third-party environments, which are generally more 

likely to contain new threats than home networks. 

Other security measures that are particularly important for telework include the following: 

 Have a separate user account with limited privileges for each person that will use the telework PC. 

Teleworkers should use their limited privilege accounts for regular work and use a separate 

administrative account only for tasks that require administrator-level access, such as some software 

updates. This reduces the likelihood of an attacker gaining administrator-level access to the PC. 

 Enforce session locking, which prevents access to the PC after it has been idle for a period of time 

(such as 15 minutes) or permits the user to lock a session upon demand. After a session is locked, 

access to the PC can only be restored through authentication. Session locking is often part of screensaver software. This prevents an attacker within physical proximity of a PC from easily gaining 

access to the current session. However, it does not thwart an attacker who steals a PC or has access to 

it for an extended period of time; session locking can be circumvented through various techniques. 

In cases where organizations are concerned about risk from inadequate telework PC security, particularly 

from PCs that are not organization-controlled or are otherwise at higher risk of compromise, 

organizations may want to consider different security controls in addition to or instead of those described 

above. For example, some vendors offer solutions that provide a bootable OS on read-only removable 

media with pre-configured remote access client software. A user can insert this media into a PC and 

reboot the computer; this bypasses the PC’s OS, which may be compromised, and loads the known-good 

OS and remote access client software from the removable media. In most cases, these solutions can be 

configured to prevent users from storing files on the local hard drive, saving files to removable media, 

and otherwise transferring information from the known-good OS to another location. Bootable OS 

solutions make the logical security of the telework PC much less important, although they do not prevent 

all compromises (for example, vulnerabilities in the removable media’s OS could be exploited, or 

malicious code may be present in the PC’s BIOS, firmware, or hardware). Another caveat with these 

solutions is that they require the PC to support booting the removable media before the hard drive, which 

may require the user to reconfigure the PC’s BIOS settings. 

Another option is to provide teleworkers with flash drives that are specifically configured for telework 

use. These drives hold organization-approved applications that are executed from a read-only portion of 

the drives, which protects them from unauthorized modification. Temporary files from these applications 

are stored in another portion of the flash drives, which reduces the likelihood of data leakage onto the PC. 

4.2 Securing Telework Consumer Devices 

Many organization-controlled telework consumer devices can have their security managed centrally, at 

least to some degree. However, many devices, including those not controlled by the organization, will 

need to be secured manually. Security capabilities and appropriate actions vary widely by device type and 

specific products, so organizations should provide guidance to device administrators and users who are 

responsible for securing telework consumer devices on how they should secure them. 

NIST SP 800-124, Guidelines on Cell Phone and PDA Security, recommends safeguards for the most 

common types of telework consumer devices. The following are examples of these safeguards: 

4-3
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Limit the networking capabilities of consumer devices. This is particularly important for devices that 

have multiple wireless capabilities; the teleworker might not even know that some wireless protocols 

are exposing the device to access by attackers. 

 For devices that face significant malware threats, run antivirus programs (and antispyware programs, 

if antivirus software does not offer robust antispyware capabilities). Devices that connect to the 

Internet may even have personal firewalls; these should be enabled to prevent attacks and 

unauthorized access. 

 Determine if the device manufacturer provides updates and patches; if so, ensure that they are applied 

promptly to protect the device from attacks against known vulnerabilities. 

Given the similarity between the functions of consumer devices, particularly as they become more 

advanced, and PCs, organizations should strongly consider treating them similar to, or the same as, PCs. 

This means that organizational policies for PCs may simply be extended to consumer devices; if the two 

policies are kept separate, the policy documents should heavily cross-reference each other. 

4.3 Protecting Data on Telework Client Devices 

Telework usually involves creating and editing work-related information such as email, word processing 

documents, and spreadsheets. Because that data is important, it should be treated like other important 

assets of the organization. Two things an organization can do to protect data on telework devices are to 

secure it on the telework device and to periodically back it up to a location controlled by the organization. 

More information on this is provided in Sections 4.3.1 through 4.3.3. Organizations can also choose not to 

allow the organization’s information to be stored on telework devices, but to instead store it centrally at 

the organization. 

Sensitive information, such as certain types of personally identifiable information (PII) (e.g., personnel 

records, medical records, financial records), that is stored on or sent to or from telework devices needs to 

be protected so that malicious parties cannot access or alter it. An unauthorized release of sensitive 

information could damage the public’s trust in an organization, jeopardize the organization’s mission, or 

harm individuals if their personal information has been released. 

4.3.1 Encrypting Data at Rest 

All telework devices, regardless of their size or location, can be stolen. Some thieves may want to read 

the contents of the data on the device, and quite possibly use that data for criminal purposes. To prevent 

this, an organization should have a policy of encrypting all sensitive data when it is at rest on the device 

and on removable media used by the device. The creation and use of keys for encrypting the data should 

follow the same policies that an organization has for other cryptographic keys. 

There are many methods for protecting data at rest, and they mostly depend on the type of device or 

removable media that is being protected. Some operating systems have their own data encryption 

mechanisms, and there are also numerous third-party applications that provide similar capabilities. See 

NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices, for more 

information on encrypting storage on client devices and removable media. Generally, when technologies 

such as full disk encryption are being used to protect data at rest, teleworkers should shut down their 

telework devices instead of placing them into sleep mode when the devices will not be used for an 

extended time or when the teleworker will not be with the device. This helps ensure that the data at rest is 

protected by the storage encryption technology. 

4-4
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

4.3.2 

4.3.3 

 

Using Virtual Machines 

If an organization has direct control over a telework device, the organization can enforce its policies for 

remote access, updating, etc. For other telework devices, such as PCs personally owned by teleworkers, 

the organization has a limited ability to enforce security policies. A method for controlling the 

environment in which a teleworker operates is to run a virtual machine (VM) on the telework PC. A user 

runs a vm image in the virtual machine environment; this image acts just like a full computer with an 

operating system and application software. 

To use VM images to enforce telework policy, the organization distributes a VM image that is configured 

to be fully compliant with all relevant security policies. The teleworker runs the VM image on the 

telework computer. When the image needs to be updated, the organization distributes a new image to its 

teleworkers. Using a VM to support telework security works well as long as the telework computer itself 

does not have any malware that will attack the VM. Because the VM runs within the host OS, any 

compromise within the host operating system could affect the security of the VM and the VM image. 

VM disks act just like the disks on a regular computer, so organizations should have policies for telework 

data that is stored in a VM image. VM images can be encrypted on the telework computer when they are 

not in use and only decrypted after the user provides proper authentication just before booting an image. 

If VM images are encrypted, an unauthorized person that gets access to the telework device will not be 

able to read the data stored in the VM image. Similarly, a VM image can have multiple disks within it, 

and some of those can be encrypted; if the teleworker stores their data on an encrypted disk within the 

VM, it will be just as if the data were stored on an encrypted disk directly on the telework computer. 

Organizations should consider encrypting all VM images used for telework to reduce the risk of 

compromise. This can be accomplished through the use of full disk encryption, file encryption, or other 

means.15 For high-risk situations, particularly involving access to highly sensitive information, 

organizations should encrypt each individual VM image used for telework and may also want to provide a 

second layer of protection through full disk encryption. 

Backing Up Data on Telework Devices 

Most organizations have policies for backing up data on a regular basis. Such a backup policy should 

cover data on telework PCs and, if relevant and feasible, consumer devices. However, such a policy may 

need different provisions for backups performed at the organization’s facilities versus external locations. 

If the data to be backed up contains sensitive information or needs its confidentiality protected for other 

reasons, there are additional security considerations if that backup is performed at an external location. 

If data is being backed up remotely—from the telework device to a system at the organization—then the 

communications carrying that data should be encrypted and have their integrity verified. This is discussed 

in more detail in Section 3.3.3. If data is being backed up locally—to removable media such as CD-R 

disks or USB flash drives, for example—the backup should be protected at least as well as the original 

data is. For example, if the original data is encrypted, then the data in the backup should be encrypted as 

well. If the original data is encrypted in a portable form, such as through virtual disk encryption or an 

encrypted VM image, then it may be sufficient to copy that encrypted entity onto the backup media. 

However, for non-portable forms of storage encryption, such as full disk encryption, the data would need 

to be decrypted on the telework device and then encrypted for storage on the backup media. 

15 NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices, explains these options. 

4-5
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

5. Security Considerations for the Telework and Remote Access Life Cycle 

This section brings together the concepts presented in the previous sections of the guide and explains how 

they should be incorporated throughout the entire life cycle of telework and remote access solutions, 

involving everything from policy to operations. This section references a five-phase life cycle model to 

help organizations determine at what point in their telework and remote access deployments a 

recommendation may be relevant. This model is based on one introduced in NIST SP 800-64, Security 

Considerations in the Information System Development Life Cycle. Organizations may follow a project 

management methodology or life cycle model that does not directly map to the phases in the model 

presented here, but the types of tasks in the methodology and their sequencing are probably similar. The 

phases of the life cycle are as follows: 

 Phase 1: Initiation. This phase includes the tasks that an organization should perform before it starts 

to design a telework or remote access solution. These include identifying needs for telework and 

remote access, providing an overall vision for how telework and remote access solutions would 

support the mission of the organization, creating a high-level strategy for implementing telework and 

remote access solutions, developing telework and remote access policy, and specifying business and 

functional requirements for the solution. 

 Phase 2: Planning and Design. In this phase, personnel specify the technical characteristics of the 

telework or remote access solution and related components. These include the authentication 

methods; the cryptographic mechanisms used to protect communications; and firewalls and other 

mechanisms used to control access to networks and resources on those networks. The types of 

telework clients to be used also need to be considered, since they can affect the desired security 

policies. Care must be taken to ensure that the security policy can be employed and enforced by all 

clients. At the end of this phase, solution components are procured. 

 Phase 3: Implementation. In this phase, equipment is configured to meet operational and security 

requirements, installed and tested as a prototype, and then activated on a production network. 

Implementation includes altering the configuration of other security controls and technologies, such 

as security event logging, network management, and authentication server integration. 

 Phase 4: Operations and Maintenance. This phase includes security-related tasks that an 

organization should perform on an ongoing basis once the telework or remote access solution is 

operational, including log review and attack detection. 

 Phase 5: Disposition. This phase encompasses tasks that occur when a remote access solution or its 

components are being retired, including preserving information to meet legal requirements, sanitizing 

media, and disposing of equipment properly.16

This section highlights security considerations of particular interest for telework and remote access 

solutions. These considerations are not intended to be comprehensive, nor is there any implication that 

security elements not listed here are unimportant or unnecessary. 

5.1 Initiation 

The initiation phase involves many preparatory actions, such as identifying current and future needs, and 

specifying requirements for performance, functionality, and security. A critical part of the initiation phase 

is the development of a telework security policy. The section lists elements that a telework security policy 

should contain and, where relevant, describes some of the factors that should be considered when making 

 

16 The life cycle information presented in this introduction is derived from Section 8 of NIST SP 800-97. 

5-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

the decisions behind each element. A telework security policy should define which forms of remote 

access the organization permits, which types of telework devices are permitted to use each form of remote 

access, and the type of access each type of teleworker is granted. It should also cover how the 

organization's remote access servers are administered and how policies in those servers are updated. 

In addition to the considerations described in this section for telework security policies, organizations 

should also consider how other security policies may be affected by telework. For example, an 

organization may require that certain types of locked-out user accounts be unlocked only in person, but 

this may not be viable for teleworkers who are on travel or on long-term assignments in external 

locations. Other security policies should be adjusted as needed to take telework into consideration. 

5.1.1 

5.1.2 

Permitted Forms of Remote Access 

One of the first decisions to make when creating a telework security policy is which types of remote 

access solutions will be permitted. Each type of solution has its strengths and weaknesses, and the 

usefulness of each will depend on many factors within the organization. Some of those factors include: 

 Existing remote access used by the organization, such as remote control systems used by IT staff 

 Software already installed on telework devices that can be used for remote access 

 Capabilities available in firewalls that are already installed at the edge of the organization's network. 

The policy for which types of remote access are permitted for telework should be closely tied to the 

organization's overall security policy. If one of the forms of remote access under consideration cannot be 

secured in a fashion that is required by the organization's security policy, such as using approved 

cryptographic algorithms to protect sensitive data, then that form of remote access should not be used by 

the organization. The overall security policy should take priority when creating a telework security policy. 

Restrictions on Telework Client Devices and Remote Access Levels 

A telework security policy can limit the types of client devices that teleworkers are allowed to use. For a 

variety of reasons, including security policies and technology limitations, organizations often limit which 

types of devices can be used for remote access. For example, an organization might permit only 

organization-owned PCs to be used. Some organizations have tiered levels of access, such as allowing 

organization-owned PCs to access many resources, teleworker-owned PCs to access a limited set of 

resources, and consumer devices and third-party PCs to access only one or two resources, such as Webbased email. This allows an organization to limit the risk it incurs by permitting the most-controlled 

devices to have the most access and the least-controlled devices to have minimal access. 

Each organization should make its own risk-based decisions about what levels of remote access should be 

permitted from which types of devices. Factors that organizations should consider when setting telework 

security policy for this include the following: 

 Sensitivity of telework. Some telework involves access to sensitive information or resources, while 

other telework does not. Organizations may have more restrictive requirements for telework involving 

sensitive information, such as permitting only organization-controlled telework devices to be used.

 The level of confidence in security policy compliance. Meeting many of an organization’s security 

requirements can typically be ensured only if the organization controls the configuration of the 

telework devices. For personally owned devices, some requirements can be verified by automated 

security health checks conducted by the remote access server on devices attempting to connect, but 

5-2
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

other requirements cannot be verified by the organization by automated means. Making users aware 

of their responsibilities can help to improve security on personally owned telework devices, but will 

not result in the same degree of security policy compliance as mandatory security controls enforced 

on organization-controlled telework devices. Even the most conscientious users may fail to properly 

maintain the security of their personally owned devices at all times because of the technical 

complexity or effort involved or their lack of awareness of new threats. 

 Cost. Costs associated with telework devices will vary based on policy decisions. The primary direct 

cost is issuing telework devices and client software to teleworkers. There are also indirect costs in 

maintaining telework devices and in providing technical support for teleworkers. Another 

consideration related to cost is telework frequency and duration; an organization might justify 

purchasing telework devices for individuals who telework regularly (e.g., one day per week from 

home, frequent business travel), but not purchasing telework devices for individuals who telework 

only occasionally for short durations, such as quickly checking email from home a few evenings a 

month. 

 Telework location. Risks will generally be higher for devices used in a variety of locations than in 

just a home environment. Also, as discussed in Section 3.3, in some cases the organization can 

determine the teleworker’s location (i.e., identify whether the device is on an authorized home 

network), in which case policies could be enforced based on location. 

 Technical limitations. Certain types of devices may be needed for particular telework needs, such as 

running specialized programs locally. Also, if an organization has a single type of remote access 

server, and that server can only allow connections through a custom client that is installed on the 

telework device, then only the types of devices that can support the client are allowed. 

 Compliance with mandates and other policies. Organizations may need to comply with teleworkrelated requirements from mandates and other sources, such as a Federal department issuing policy 

requirements to its member agencies. An example of a possible requirement is restrictions on 

performing telework in certain foreign countries. 

Organizations may choose to specify additional security requirements that are tied to factors such as the 

sensitivity of telework. Many organizations require more stringent security controls for telework 

situations that are particularly high-risk. Security requirements that may be particularly helpful for such 

situations include the following: 

 Permit high-risk telework only from organization-issued and secured telework devices. 

 Require the use of multi-factor authentication for access to the telework device and to remote access 

solutions. 

 Use storage encryption on the telework device, at a minimum to protect all sensitive information. 

Multiple levels of encryption may be needed. For example, full disk encryption may be needed to 

mitigate an attacker who gains physical access to the device; at the same time, virtual disk encryption 

or file/folder encryption may be needed to mitigate an attacker who gains logical access to the device 

(i.e., access after full disk encryption authentication has occurred and the data on the hard drive is 

being decrypted automatically as needed). Removable media containing telework data should also be 

encrypted. 

 Migrate high-risk resources to servers that assume responsibility for protecting them. For example, a 

teleworker could connect to a terminal server that holds sensitive data that the teleworker needs to 

access. 

5-3
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Store and access only the minimum data necessary. Some organizations issue “loaner” devices that 

are completely wiped before and after the high-risk telework is performed. Only the data and 

authorized applications needed for the telework are loaded onto the loaner device. The pre-use wiping 

ensures that the device is clean before any telework is conducted, and the post-use wiping ensures that 

no telework data remains that could be accessed in the future. 

In high-risk situations, organizations may also choose to reduce risk by prohibiting telework and remote 

access involving particular types of information, such as highly sensitive personally identifiable 

information (PII).17

Every year, there are many changes in telework device capabilities, the security controls available to 

organizations, the types of threats made to different types of devices, and so on. Therefore, organizations 

should periodically reassess their policies for telework devices and consider changing which types of 

client devices are permitted and what levels of access they may be granted. Organizations should also be 

aware of the emergence of new types of remote access solutions and of major changes to existing remote 

access technologies, and ensure that the organization’s policies are updated accordingly as needed. 

5.1.3 

 

Additional User Requirements 

Organizations often have additional security considerations for telework that, while helpful in mitigating 

threats, cannot be directly enforced by the organization. Organizations should educate users on the 

importance of these additional security measures and define teleworkers’ responsibilities for 

implementing these measures in policy and telework agreements. 

One example of a possible security consideration is phone services. Depending on the sensitivity of 

telework communications, telephone security may be a consideration. Corded phones using traditional 

wired telephone networks cannot be intercepted without physical connections, so they are sufficiently 

secure for typical telework. Cordless phones using traditional wired telephone networks should employ 

spread spectrum technology to scramble transmissions, thus reducing the risk of eavesdropping within 

physical proximity (usually a few hundred yards at most). Digital cell phones should be acceptable for 

typical telework.18 Communications carried over voice over IP (VoIP) services should not be considered 

secure unless some form of encryption is used; however, many VoIP services now provide strong 

encryption, which should be used to protect sensitive and proprietary information. 

Another possible security consideration involves wireless personal area networks (WPAN), which are 

small-scale wireless networks that require no infrastructure to operate. Examples of WPAN technologies 

are using a wireless keyboard or mouse with a computer, printing wirelessly, synchronizing a PDA with a 

computer, and allowing a wireless headset or earpiece to be used with a cell phone. The two most 

commonly used types of WPAN technologies are Bluetooth and infrared. For devices within proximity of 

threats, teleworkers should disable these technologies when not in use to prevent misuse by unauthorized 

parties. 

Additional information on these security considerations is available from NIST SP 800-114, User’s Guide 

to Securing External Devices for Telework and Remote Access, and NIST SP 800-121, Guide to Bluetooth 

Security. 

17 For more information on protecting PII, see draft NIST SP 800-122, Guide to Protecting the Confidentiality of Personally 

Identifiable Information (PII). 18 Analog cell phone communications can be intercepted by individuals with scanning equipment, so their use should be 

avoided when discussing sensitive or proprietary information. However, nearly all analog cell phone networks have been 

retired. 

5-4
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

5.2 Planning and Design 

Once the organization has established a telework security policy, identified telework and remote access 

needs, and completed other preparatory activities, the next step is to determine which types of telework or 

remote access technologies should be used and to design a solution to deploy. There are many 

considerations for designing a solution, most of which are generally applicable to any IT technology. This 

section focuses on the technical security considerations that are most important for designing telework 

and remote access solutions. Major considerations include the following:19

 Architecture. Designing the architecture includes the placement of the remote access server and the 

selection of remote access client software (if needed). 

 Authentication. Authentication involves selecting a remote access authentication method, as 

described in Section 3, and determining how its client/user and server components should be 

implemented, including procedures for issuing and resetting authenticators and for provisioning users 

and client devices with authenticators. 

 Cryptography. Decisions related to cryptography include selecting the algorithms for encryption and 

integrity protection of remote access communications, and setting the key strength for algorithms that 

support multiple key lengths. 

 Access Control. This involves determining which types of remote access communications should be 

permitted and denied. Section 3 provides additional information on access control capabilities. 

 Endpoint Security. Endpoint security decisions involve determining how remote access servers and 

telework client devices should be secured, as described in Sections 3 and 4, respectively. 

The security aspects of the telework and remote access solution design should be documented in the 

system security plan. The organization should also consider how incidents involving the telework and 

remote access solutions should be handled and document those plans as well.20

5.3 Implementation 

After the remote access solution has been designed, the next step is to implement and test a prototype of 

the design, before putting the solution into production. Aspects of the solution that should be evaluated 

include the following: 21

 Connectivity. Users can establish and maintain remote access connections. Users can connect to all 

of the resources that they are permitted to and cannot connect to any other resources. 

 Protection. Each traffic flow is protected in accordance with the established requirements. This 

includes flows between the telework client device and the remote access server, and between the 

remote access server and internal resources. Protection should be verified by means such as 

monitoring network traffic or checking traffic logs. 

 Authentication. Authentication is required and cannot be readily compromised or circumvented. 

Performing robust testing of authentication is important to reduce the risk of attackers accessing 

protected internal resources. 

 

19 These considerations are based on material from Section 4 of NIST SP 800-77, Guide to IPsec VPNs, by Sheila Frankel, 

Karen (Kent) Scarfone, Ryan Lewkowski, Angela Orebaugh, Ronald Ritchey, and Steven Sharma. 20 For more information on incident handling, see NIST SP 800-61 Revision 1, Computer Security Incident Handling Guide. 21 These considerations are based on material from Section 4 of NIST SP 800-77, Guide to IPsec VPNs. 

5-5
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Applications. The remote access solution does not interfere with the use of software applications that 

are permitted to be used through remote access, nor does it disrupt the operation of telework client 

devices (for example, a VPN client conflicting with a host-based firewall). 

 Management. Administrators can configure and manage the solution effectively and securely. This 

includes all components, including remote access servers, authentication services, and client software. 

The ease of deployment and configuration is particularly important, such as having fully automated 

client configuration versus administrators manually configuring each client. Another concern is the 

ability of users to alter remote access client settings, which could weaken remote access security. 

 Logging. The remote access solution logs security events in accordance with the organization’s 

policies. Some remote access solutions provide more granular logging capabilities than others—for 

example, logging usage of individual applications versus only connections to particular hosts—so in 

some cases it may be necessary to rely on the resources used through remote access to perform 

portions of the logging that the remote access server cannot perform. 

 Performance. The solution provides adequate performance during normal and peak usage. It is 

important to consider not only the performance of the primary remote access components, but also 

that of intermediate devices, such as routers and firewalls. Encrypted traffic often consumes more 

processing power than unencrypted traffic, so it may cause bottlenecks. In many cases, the best way 

to test the performance under load of a prototype is to use simulated traffic generators on a live test 

network to mimic the actual characteristics of expected traffic as closely as possible. Testing should 

incorporate a variety of applications that will be used with remote access. 

 Security of the Implementation. The remote access implementation itself may contain 

vulnerabilities and weaknesses that attackers could exploit. Organizations with high security needs 

may choose to perform extensive vulnerability assessments against the remote access components. At 

a minimum, all components should be updated with the latest patches and configured following sound 

security practices. 

 Default Settings. Implementers should carefully review the default values for each remote access 

setting and alter the settings as necessary to support security requirements. Implementers should also 

ensure that the remote access solution does not unexpectedly “fall back” to default settings for 

interoperability or other reasons. 

5.4 Operations and Maintenance 

Operational processes that are particularly helpful for maintaining telework and remote access security, 

and thus should be performed regularly, include the following:22

 Checking for upgrades and patches to the remote access software components, and acquiring, testing, 

and deploying the updates 

 Ensuring that each remote access infrastructure component (servers, gateways, authentication servers, 

etc.) has its clock synched to a common time source so that its timestamps will match those generated 

by other systems 

 Reconfiguring access control features as needed based on factors such as policy changes, technology 

changes, audit findings, and new security needs 

 

22 Portions of the information on operations and maintenance were derived from Sections 5.4 and 5.5 of NIST SP 800-92, 

Guide to Computer Security Log Management by Karen (Kent) Scarfone and Murugiah Souppaya. 

5-6
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

 Documenting anomalies detected within the remote access infrastructure. Such anomalies might 

indicate malicious activity or deviations from policy and procedures. Anomalies should be reported to 

other systems’ administrators as appropriate. 

Organizations should also periodically perform assessments to confirm that the organization’s remote 

access policies, processes, and procedures are being followed properly. Assessment activities may be 

passive, such as reviewing logs, or active, such as performing vulnerability scans and penetration testing. 

More information on technical assessments for telework and remote access is available from NIST SP 

800-115, Technical Guide to Information Security Testing and Assessment. 

5.5 Disposition 

Before a telework client device or remote access server permanently leaves an organization (such as when 

a leased server’s lease expires or when an obsolete PC is being recycled), the organization should remove 

any sensitive data from the host. Data may also need to be wiped if an organization provides “loaner” 

devices to teleworkers, particularly for travel. The task of scrubbing all sensitive data from storage 

devices such as hard drives and memory cards is often surprisingly difficult because of all the places 

where such data resides. See NIST SP 800-88, Guidelines for Media Sanitization, for additional 

information and recommendations on removing data from telework and remote access devices. Note that 

sensitive data is often found in places other than just the user’s data area; for example, software that runs 

under Microsoft Windows often stores possibly-sensitive data in the Windows registry. An organization 

should strongly consider erasing all storage devices completely. 

5-7
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Appendix A—Glossary 

Selected terms used in the publication are defined below. 

Consumer Device: A small, usually mobile computer that does not run a standard PC OS or that runs a 

standard PC OS but does not permit users to access it directly. Examples of consumer devices are 

networking-capable personal digital assistants (PDA), cell phones, and video game systems. 

Direct Application Access: A high-level remote access architecture that allows teleworkers to access an 

individual application directly, without using remote access software. 

Personal Computer: A desktop or laptop computer running a standard PC operating system (e.g., 

Windows Vista, Windows XP, Linux/UNIX, and Mac OS X). 

Portal: A high-level remote access architecture that is based on a server that offers teleworkers access to 

one or more applications through a single, centralized interface. 

Remote Access: The ability for an organization’s users to access its non-public computing resources from 

locations other than the organization’s facilities. 

Remote Desktop Access: A high-level remote access architecture that gives a teleworker the ability to 

remotely control a particular desktop computer at the organization, most often the user’s own computer at 

the organization’s office, from a telework client device. 

Remote System Control: Remotely using a computer at an organization from a telework computer. 

Session Locking: A feature that permits a user to lock a session upon demand or locks the session after it 

has been idle for a preset period of time. 

Split Tunneling: A VPN client feature that tunnels all communications involving the organization’s 

internal resources through the VPN, thus protecting them, and excludes all other communications from 

going through the tunnel. 

Telecommuting: See “Telework.” 

Telework: The ability for an organization’s employees and contractors to perform work from locations 

other than the organization’s facilities. 

Telework Client Device: A PC or consumer device used by a teleworker for performing telework. 

Tunneling: A high-level remote access architecture that provides a secure tunnel between a telework 

client device and a tunneling server through which application traffic may pass. 

Virtual Private Network (VPN): A virtual network, built on top of existing physical networks, that 

provides a secure communications tunnel for data and other information transmitted between networks. 

A-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Appendix B—Acronyms and Abbreviations 

Selected acronyms and abbreviations used in this publication are defined below. 

DMZ Demilitarized Zone 

DNS Domain Name System 

DSL Digital Subscriber Line 

FIPS Federal Information Processing Standard 

FISMA Federal Information Security Management Act 

HTTP Hypertext Transfer Protocol 

HTTPS Hypertext Transfer Protocol over SSL 

IEEE Institute of Electrical and Electronics Engineers, Inc. 

IP Internet Protocol 

IPsec Internet Protocol Security 

ISP Internet Service Provider 

IT Information Technology 

ITL Information Technology Laboratory 

MITM Man-in-the-Middle 

MPLS Multiprotocol Label Switching 

NAC Network Access Control 

NAT Network Address Translation 

NIST National Institute of Standards and Technology 

OMB Office of Management and Budget 

OS Operating System 

PC Personal Computer 

PDA Personal Digital Assistant 

PII Personally Identifiable Information 

PPP Point-to-Point Protocol 

SP Special Publication 

SSH Secure Shell 

SSL Secure Sockets Layer 

TLS Transport Layer Security 

URL Uniform Resource Locator 

USB Universal Serial Bus 

VM Virtual Machine 

VoIP Voice over Internet Protocol 

VPN Virtual Private Network 

WiMAX Worldwide Interoperability for Microwave Access 

WPAN Wireless Personal Area Network 

B-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Appendix C—Resources 

The lists below provide examples of resources that may be helpful in better understanding telework and 

remote access security. 

Telework Security Resource Sites 

Site Name URL 

Home Network Security http://www.us-cert.gov/reading_room/home-network-security/ 

Information for New and Home Users http://www.cert.org/homeusers/ 

Interagency Telework Site http://www.telework.gov/ 

Security at Home http://www.microsoft.com/protect/default.mspx 

Stay Safe Online http://www.staysafeonline.info/ 

Telework Security-Related Documents 

Document Title URL 

NIST SP 800-40 Version 2.0, Creating a 

Patch and Vulnerability Management 

Program 

http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf 

NIST SP 800-48 Revision 1, Guide to 

Securing Legacy IEEE 802.11 Wireless 

Networks 

http://csrc.nist.gov/publications/nistpubs/800-48-rev1/SP800-48r1.pdf 

NIST SP 800-52, Guidelines for the 

Selection and Use of Transport Layer 

Security (TLS) Implementations 

http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf 

NIST SP 800-53 Revision 2, 

Recommended Security Controls for 

Federal Information Systems 

http://csrc.nist.gov/publications/nistpubs/800-53-Rev2/sp800-53-rev2-

final.pdf 

NIST SP 800-53 Revision 3 (Draft), 

Recommended Security Controls for 

Federal Information Systems and 

Organizations

http://csrc.nist.gov/publications/PubsSPs.html 

NIST SP 800-55 Revision 1, 

Performance Measurement Guide for 

Information Security 

http://csrc.nist.gov/publications/nistpubs/800-55-Rev1/SP800-55-

rev1.pdf 

NIST SP 800-58, Security Considerations 

for Voice Over IP Systems 

http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf 

NIST SP 800-63 Version 1.0.2, Electronic 

Authentication Guidelines 

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf 

NIST SP 800-63-1 (Draft), Electronic 

Authentication Guidelines 

http://csrc.nist.gov/publications/PubsSPs.html 

NIST SP 800-68 Revision 1, Guide to 

Securing Microsoft Windows XP Systems 

for IT Professionals 

http://csrc.nist.gov/itsec/download_WinXP.html 

NIST SP 800-69, Guidance for Securing 

Microsoft Windows XP Home Edition

http://csrc.nist.gov/itsec/guidance_WinXP_Home.html 

NIST SP 800-77, Guide to IPsec VPNs http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf 

C-1
GUIDE TO ENTERPRISE TELEWORK AND REMOTE ACCESS SECURITY (DRAFT) 

Document Title URL 

NIST SP 800-83, Guide to Malware 

Incident Prevention and Handling 

http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf 

NIST SP 800-97, Establishing Wireless 

Robust Security Networks: A Guide to 

IEEE 802.11i 

http://csrc.nist.gov/publications/nistpubs/800-97/SP800-97.pdf 

NIST SP 800-111, Guide to Storage 

Encryption Technologies for End User 

Devices 

http://csrc.nist.gov/publications/nistpubs/800-111/SP800-111.pdf 

NIST SP 800-113, Guide to SSL VPNs http://csrc.nist.gov/publications/nistpubs/800-113/SP800-113.pdf 

NIST SP 800-114, User’s Guide to 

Securing External Devices for Telework 

and Remote Access 

http://csrc.nist.gov/publications/nistpubs/800-114/SP800-114.pdf 

NIST SP 800-115, Technical Guide to 

Information Security Testing and 

Assessment 

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf 

NIST SP 800-121, Guide to Bluetooth 

Security 

http://csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf 

NIST SP 800-123, Guide to General 

Server Security 

http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf 

NIST SP 800-124, Guidelines on Cell 

Phone and PDA Security 

http://csrc.nist.gov/publications/nistpubs/800-124/SP800-124.pdf 

Using Wireless Technology Securely http://www.us-cert.gov/reading_room/Wireless-Security.pdf 

C-2