S 2.184 Development of a RAS concept

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Head of IT Section, Administrator

Establishment of a RAS system requires that a RAS concept is developed after the requirements analysis has been performed (see safeguard S 2.183 Performing a RAS requirements analysis) and prior to technical implementation of the system. Essentially the concept specifies what RAS system architecture should be chosen and what rules should apply to use of the RAS system for all those concerned. The concept can be roughly broken down into three sub-areas.

1. The organisational concept. This covers all matters which are of interest to the organisation in relation to the RAS system. Care should be taken to ensure that the RAS system is integrated into existing organisational processes so that their homogeneity and consistency are preserved.

2. The technical concept. This specifies the technical implementation of the RAS system. The technical concept should cover the requirements which have been identified during the requirements analysis and, as far as is implementable, it should accommodate all the access scenarios that will be necessary. With regard to technical planning, the existing technical situation must be considered in order to avoid any technical incompatibilities.

3. The security concept. This covers the security-relevant aspects of the RAS system. As security can generally only be assured through a combination of organisational and technical safeguards, the security concept should be specified separately and not just constitute a subsection within the organisational and technical concepts.

The essential questions which need to be answered in connection with each of the sub-areas are listed below. Depending on the particular situation, there may be a special, additional need for co-ordination that is tailored to the particular organisational and technical circumstances.

The organisational concept should address the following points:

• The various responsibilities for the RAS system should be specified (installation, administration, review, monitoring). Depending on the organisational structure, this will either require the responsibilities associated with existing roles to be extended or new roles to be created (see also safeguard S 2.1 Specification of responsibilities and of requirements documents for IT uses).

• Binding rules as to which users should be allowed remote access over the RAS system should be specified. It is recommended that different groups with different access authorisations should be defined for RAS access as well. The groups to which individual users may belong should be controlled through an appropriate requirements profile which determines what conditions must be satisfied in order to acquire membership of a group. These conditions might include necessity (teleworkers, staff working out in the field), length of service and approval from the line manager. Whether and how permissions for remote access should be restricted must in each case be decided within the organisation. Often equivalent rules will already exist, e.g. regarding permission for Internet access, which can then be adapted.

The access authorisations granted must be recorded as part of the RAS system documentation and must be updated in the event of changes.

• For fixed remote locations (e.g. telecommuting workstations) requirements which specify what conditions (e.g. in relation to security and technical equipment) the remote working place must satisfy in order to be allowed RAS connections from there to the local network. The concept can also provide for an initial review of the premises and subsequently for repeat reviews at periodic intervals, and specify how and by whom these reviews should be performed.

• Normally the locations of RAS clients are not under the control of the LAN operator and therefore also possess a particular threat potential. It is possible to limit the potential exposure to threats of stationary clients (for example as used in teleworking) through appropriate provisions, but it must be assumed that the degree of risk to which RAS clients are exposed is very high. Not every location which satisfies the technical preconditions for remote access connection is also suitable for this. Therefore rules must be drawn up which specify from which remote locations RAS connections may be established to the destination LAN. Depending on the planned operational scenario, however, it may be easier to draw up a negative list of locations which are particularly unsuitable. This could include, for example, hotel foyers, hotel business centres or train carriages.

• Procedures for RAS administration should be specified which determine how changes to the RAS configuration must be implemented. Since breaches of security relating to RAS access could potentially result in the entire LAN being compromised, changes to the RAS configuration must always follow a predefined procedure (for example: request, review of the planned configuration, implementation, review of the change implemented).

The technical concept should address the following points:

• The technical concept should specify the hardware and software components with which the RAS system is to be technically implemented. The components are only defined in terms of their functionality. Through a subsequent analysis of existing system components and of the new components available on the market, the elements in the concept can then be assigned to actual equipment and software components (see S 2.186 Selection of a suitable RAS product).

• All the possible points of access and the access protocols to be used over them must be specified.

• All the services and protocols which are permitted over the RAS link must be listed together with the resources which can be accessed over them.

• A decision must be made as to which subnets should or must be accessible over the RAS link (see also RAS security concept).

The RAS security concept should address the following points:

• A set of security guidelines covering RAS usage should be drawn up. These RAS security guidelines must be oriented to the existing organisation-wide security guidelines. As a general rule, permissions granted for access over the RAS system should be less far-reaching and checks should be tougher than with local access.

• The type and manner of user authentication and the mechanisms to be used for this purpose should be specified.

• All components involved in authentication should be recorded and their functions and interactions should be described.

• All components involved in access control should be recorded and their functions and interactions should be described. In this way it is possible to determine whether, for example, existing access control mechanisms can be configured in such a way that more restrictive settings automatically apply during remote access.

• As part of the security design, all points of RAS access to the local network must be recorded and the manner in which these access points are connected to the LAN must be specified (see also module 7.3 Firewalls).

• Proceeding on the basis of the current network structure, the security concept must analyse which subnets can be remotely accessed. For bus-based networks (e.g. ethernet) typically all the computers in the subnet in which the RAS access resides can be accessed. In this connection consideration should be given to the possibility of creating dedicated access networks from which only controlled access to the operational network is possible (e.g. with the aid of routers, packet filters or an internal firewall). The creation of access networks requires the purchase and maintenance of additional hardware and software (see also S 5.77 Creation of subnets).

• Organisational reporting channels must be planned so that in the event of a security incident a targeted and rapid response is possible. The technical concept should lay down appropriate mechanisms which enable the detection of security incidents and calling in of the responsible administrator who constitutes the initial point in the organisational reporting channel.

• Since remote access to a LAN poses special security risks because of the generally insecure environment in which RAS clients are used, every user who is to be allowed RAS access must be given special training. This training should ensure that users are made aware of the dangers and also instruct them in how to handle the technical devices and software.

• If any authentication tokens are to be used, users must be informed of the proper manner in which they should be handled.

• Again, the administrators must be given thorough training on the products used and they must also be made aware of all the potential security risks.

• The administrators must have sufficient time not only to operate the RAS systems but also to seek information on current security weaknesses and to learn how to use any new components.

• Existing rules regarding the separation of roles (e.g. administrator and internal auditor) should be transferred to the administration of the RAS system.

• Finally the requirements regarding the availability of RAS systems must be specified. Moreover, if necessary contingency solutions which can be used as an alternative in the event of failure of a RAS system should be provided.

The RAS requirements analysis and design will by its nature throw up specific requirements for the hardware and software components which should be used. These should be refined and made specific for procurement purposes, as described in safeguard S 2.186 Selection of a suitable RAS product.

Additional controls:

• Does a security concept governing the use of RAS exist?

• Are there any security guidelines covering RAS usage to which the users can orient themselves?

• Is there an authorisation concept for remote access?

• Are the safeguards contained in the RAS security concept regularly checked to ensure that they have been correctly implemented?