7.6 Remote Access


Remote access enables a user to log on from a local computer to a remote computer network and use its resources as if a direct LAN link existed. The services used here are known as Remote Access Service (RAS). RAS ensures that remote users can access the network resources.

In general, RAS is used in the following situations:

RAS offers a simple solution in such scenarios: the remote user establishes a connection with the corporate network e.g. over the telephone network using a modem. This direct connection can exist for as long as is necessary and can be viewed as a leased line which is only active on demand.

Figure: Remote Access to Resources

Establishment of a RAS connection generally requires three components as follows:

  1. A computer within the corporate network on which RAS software has been installed and which is ready to accept RAS connections. This is known as the RAS server or access server.
  1. A remote computer on which RAS software has been installed and which initiates the RAS connection. This is known as the RAS client.
  1. The communication medium over which the RAS connection is established. In most scenarios the RAS client uses a telecommunications network to establish the connection. The very minimum that is required, therefore, is a telephone line and a modem to go with it. Depending on the RAS architecture, different connection technologies can be used server-side.

RAS is implemented as a client/server architecture: the RAS client can be configured so that it automatically establishes the RAS connection when corporate network resources are required by dialling the phone number of the computer on which the RAS server software is installed. Alternatively, the RAS connection can be initiated manually by the user. Some operating systems, e.g. Windows NT, also allow the RAS to be activated immediately following system logon.

There are two basic ways of establishing a connection to the remote LAN (see Safeguard Selection of a suitable RAS system architecture):

  1. Direct dial-up to the access server, which in this case is part of the remote LAN;
  1. Dial-up to an access server of an Internet Service Provider (ISP) and access to the remote LAN over the Internet.

From the point of view of security, the following security objectives apply to RAS access:

  1. Access security. The remote user must be uniquely identified by the RAS system. The identity of the user must be established through an authentication mechanism every time that a connection is established to the local network. In the context of system access, additional control mechanisms must be employed to ensure that system access by remote users is properly controlled (e.g. restricting access to certain times or to permitted remote connection points only).
  1. Access control. Once the remote user has been authenticated, the system must be able to restrict the interactions of the user with the system. This requires that the authorisations and restrictions which have been specified for local network resources by authorised administrators are also enforced for remote users.
  1. Security of communications. Where local resources are accessed remotely, user data have also to be transmitted over the established RAS connection. In general the security requirements which apply in the local network with regard to protection of communications (confidentiality, integrity, authenticity) must also be implementable for data which is transmitted over RAS connections. However, protection of RAS communications is especially critical since communications can be transmitted using a number of communications media which cannot generally be assumed to be under the control of the operator of local network.
  1. Availability. Where remote access is used for mainstream business activities, the availability of RAS access is particularly important. The smooth flow of business processes may be impaired in the event of total failure of RAS access or if connections have insufficient bandwidth. This risk can be reduced to a certain extent through the use of alternative or redundant RAS connections. This applies especially where the Internet is used as the communications medium, as here there are generally no guarantees of either connection or bandwidth.

Threat Scenario

The client/server architecture of RAS systems means that both the RAS client and the RAS server are exposed to specific risks due to the type of operational environment and the manner of use.

At this point we advise against considering the dangers to the client and server completely separately since, for example, if a RAS client were to be compromised, the RAS server would automatically be endangered. Moreover it should be borne in mind that, for example in the Windows environment, every RAS client can also be operated as a RAS server, so that the threats which apply to RAS servers apply equally to a RAS client.

The following typical threats are assumed for the IT baseline protection of a RAS system:

Force Majeure

  • T 1.1 Loss of personnel
  • T 1.2 Failure of the IT system
  • T 1.10 Failure of a wide area network
  • Organisational Shortcomings

  • T 2.2 Insufficient knowledge of requirements documents
  • T 2.16 Non-regulated change of users in the case of laptop PCs
  • T 2.19 Inadequate key management for encryption
  • T 2.37 Uncontrolled usage of communications lines
  • T 2.44 Incompatible active and passive network components
  • T 2.49 Lack of, or inadequate, training of teleworkers
  • T 2.64 Lack of or defective rules for the RAS system
  • Human Error

  • T 3.30 Unauthorised private use of telecommuting workstations
  • T 3.39 Improper administration of the RAS system
  • T 3.40 Inappropriate use of authentication services with remote access
  • T 3.41 Improper use of remote access services
  • T 3.42 Insecure configuration of RAS clients
  • T 3.43 Inappropriate handling of passwords
  • T 3.44 Carelessness in handling information
  • Technical Failure

  • T 4.35 Insecure cryptographic algorithms
  • T 4.40 Unsuitable fitting out of the RAS client operational environment
  • Deliberate Acts

  • T 5.7 Line tapping
  • T 5.8 Manipulation of lines
  • T 5.22 Theft of a mobile IT system
  • T 5.39 Infiltrating computer systems via communication cards
  • T 5.71 Loss of confidentiality of classified information
  • T 5.83 Compromising cryptographic keys
  • T 5.91 Disabling of RAS access security mechanisms
  • T 5.92 Use of the RAS client as RAS server
  • T 5.93 Permitting use of RAS components by third parties
  • Recommended Countermeasures (S)

    To implement IT baseline protection, selection of the required packages of safeguards ("modules"), as described in Sections 2.3 and 2.4, is recommended.

    A RAS system consists of several components which from the outset should be protected as individual components. Quite apart from the RAS functionality, these should be viewed as normal IT systems or network switching elements which need to be protected according to the suggestions made in the relevant safeguard modules. RAS servers are computers which are normally fully under the control of an organisation and perform the important task of controlling access to the internal network. The RAS functionality is generally superimposed on an operating system which in most cases offers additional services as well. Hence the security of RAS access also depends on there being no security weaknesses either at operating system or service level.

    As well as protecting the RAS system components, however, it is also necessary to draw up a RAS security policy which must be integrated into the existing security policy. At the same time as implementing existing security requirements, the RAS system requires that new, RAS-specific security rules are defined.

    A RAS system will generally be used in the environment of other systems which serve to control access to the internal network from outside. Examples of other systems with which a RAS system has to work are firewall systems and remote maintenance systems. For this reason, when implementing the RAS-specific safeguards, the safeguards from the relevant modules of the affected systems must also be considered. The modules which should be considered include:

    Secure RAS access depends on a series of safeguards being taken, starting at the design stage, and then moving on to procurement and operation. The steps involved here and the safeguards which should be considered at each of the steps are listed below.

    1. A RAS concept must be prepared up front, based on the security requirements for the existing IT systems and the requirements arising from the planned situations under which RAS will be used.
    1.1 To tailor the concept to the particular application, the requirements must be determined at the start. For this purpose a requirements analysis must be performed (see Performing a RAS requirements analysis).
    1.2 On the basis of the requirements thus determined, a RAS concept can then be defined (see Development of a RAS concept).
    1.3 To implement the concept, a RAS system architecture must be defined (see Selection of a suitable RAS system architecture), which is tailored to the organisation's RAS requirements and the RAS concept to be implemented.
    2. Before the RAS system can be procured, the requirements relating to the RAS product must be derived from the RAS concept and the choice of a suitable RAS product must be based on these (see Selection of a suitable RAS product).
    3. The security-relevant safeguards for the implementation of the RAS concept may be broken down into the following areas:
    3.1 definition of security guidelines for use of RAS (see Definition of a set of RAS security guidelines),
    3.2 installation and initial configuration (see Secure installation of the RAS system and Secure configuration of the RAS system), and
    3.3 the ongoing operation of the RAS system (see Secure operation of the RAS system).
      Typically, RAS servers and RAS clients must always be considered with RAS systems. As the users of a RAS system essentially contribute to its secure operation, they must be prepared for the use of RAS access and be instructed in the use of the RAS software. Here in particular their attention must be drawn to the dangers which exist when RAS access is used from home or on the road (see Training before actual use of a program and Education on IT security measures).
      Tunnel protocols are often used as a means of protecting RAS connections. These allow the establishment, building on an existing connection, of a communication channel between IT systems or networks which is sealed off through access control and encryption. Because this channel is sealed off from the outside world the term Virtual Private Network (VPN) is frequently employed (see Use of suitable tunnel protocols for RAS communication).

    The safeguards package for the "Remote Access" module is presented below.


  • S 1.29 (1) Adequate siting of an IT system (server)
  • Organisation

  • S 2.2 (2) Resource management
  • S 2.25 (1) Documentation on the system configuration
  • S 2.40 (2) Timely involvement of the staff/factory council
  • S 2.183 (1) Performing a RAS requirements analysis
  • S 2.184 (1) Development of a RAS concept
  • S 2.185 (1) Selection of a suitable RAS system architecture
  • S 2.186 (1) Selection of a suitable RAS product
  • S 2.187 (1) Definition of a set of RAS security guidelines
  • Personnel

  • S 3.4 (1) Training before actual use of a program
  • S 3.5 (1) Education on IT security measures
  • S 3.10 (1) Selection of a trustworthy administrator and his substitute
  • S 3.11 (1) Training of maintenance and administration staff
  • Hardware and software

  • S 4.110 (1) Secure installation of the RAS system
  • S 4.111 (1) Secure configuration of the RAS system
  • S 4.112 (1) Secure operation of the RAS system
  • S 4.113 (2) Use of an authentication server within RAS access
  • Communication

  • S 5.68 (2) Use of encryption procedures for network communications
  • S 5.76 (2) Use of suitable tunnel protocols for RAS communication
  • Contingency Planning

  • S 6.70 (2) Creation of a contingency plan for failure of the RAS system
  • S 6.71 (2) Data backup for a mobile IT system

  • © Copyright by Bundesamt für Sicherheit in der Informationstechnik 2000

    Last Update: Okober 2000