S 6.70 Creation of a contingency plan for failure of the RAS system

Initiation responsibility: Head of IT Section, IT Security Management Team

Implementation responsibility: Administrator

Depending on the availability requirements, failure or non-availability of RAS connections could be extremely serious. However, there are a large number of potential sources of failure so that it is often difficult to establish the exact cause. As well as failure of the connection infrastructure (see on this point also T 1.10 Failure of a wide area network), RAS clients and the RAS server, plus the network switching elements used for the connection (see also T 4.31 Failure or malfunction of a network component), are naturally additional potential points of failure in a RAS system.

If a component of the RAS system (client, server, network switching elements) fails, the result could be that important data and information cannot be exchanged and that work routines are interrupted until the connection is re-established or alternative solutions have been found.

If the RAS system fails, the linking of external computers (e.g. individual telecommuting workstations or entire LANs of branch offices) can no longer be assured so that, for example, it is possible that data can no longer be exchanged. Depending on the operational scenario, this can lead to significant impairment of IT operations. Contingency planning and the creation of a contingency plan for the partial (e.g. failure of the authentication server) or total failure of the RAS system are therefore extremely important.

In the context of contingency planning for the RAS system, the general safeguards contained in module 3.3 Contingency planning concept are relevant. The following safeguards should also be considered:

• S 6.18 Provision of redundant lines

• S 6.31 Procedural rules following a loss of system integrity

• S 6.37 Documenting data backup procedures

• S 6.54 Procedures in case of a loss of network integrity

These safeguards should be made more specific to the components and data which reside in the RAS system environment and implemented.

In particular, the contingency plan should cover the following aspects:

• What specific faults, damage and consequential damage will occur upon failure of a RAS connection?

• For which RAS connections must high availability be guaranteed?

• How quickly can the failure of a RAS system be determined?

• Can faults in the telecommunications networks used for connections (e.g. connection problems, problems with the transmission of call numbers, problems with the connection of closed user groups) be detected quickly as such or are they communicated to the responsible administrator?

• How quickly can a RAS connection be restored (by replacement of equipment, restarting the system)?

• Which component failures require that the RAS system is shut down even though technically RAS connections can still be established (e.g. failure of logging, encryption of communications or of the authentication server)?

For remote users, an emergency call number should be available so that they can notify the responsible persons promptly of any RAS problems. Moreover, the RAS system should be permanently monitored at critical periods (e.g. office hours, periods in which data is primarily exchanged by RAS).

Suitable procedures should be developed for individual damage scenarios in the form of contingency documentation. All the data that is necessary to resolve an emergency should be included in this documentation and presented in such a way that deputising staff can also work with it. The contingency documentation should also contain information on alternative connection paths, e.g. alternative telecommunications providers or alternative transmission media.

Depending on the availability requirements for the RAS system, it may be necessary to hold replacement equipment in reserve so that faulty items can be replaced immediately. To ensure that the RAS system can be started up again after equipment replacement or a system crash, the contingency documentation must contain a recovery plan. If necessary, it may even be necessary for it to be possible to replace certain components while the system is running. Such a hot swap must be supported by the components used.

Depending on the RAS system, the consistency of data being transmitted by RAS during a system crash cannot be assured. After every failure the integrity of this data should therefore be checked and a problem analysis should be carried out in order to avoid repetitions as far as possible.

In certain situations it can be necessary to operate the RAS system with limited functionality or performance. In this case a corresponding fallback configuration must be activated (see also S 4.111 Secure configuration of the RAS system). This enables the security of the RAS system (access security, communication security) to be maintained even during restricted operation.