RAS products differ as to the range of functions provided, the security mechanisms offered, ease of operation and cost-effectiveness. Moreover there are differences in the hardware and software components in the operational environment which they require for smooth operation.
Before a RAS product is purchased, a list of requirements against which the products available on the market can be evaluated should therefore be drawn up. An informed purchase decision which will ensure that the product purchased satisfies the requirements when put into operation can then be made on the basis of the evaluation.
A RAS system generally consists of several hardware and software components so that, strictly speaking, one should not really talk about a RAS product as if it were a single entity. Initially a rough distinction can be made between LAN-side and client-side components. The specific components which have to be purchased depend on the chosen RAS system architecture. Thus, in the simplest case, for example, a Windows-based PC and a laptop, each of which is fitted with an ISDN card (see also S 2.106 Purchase of suitable ISDN cards), can function as RAS server and client and use the Windows NT Remote Access Service. On the other hand, large organisations often operate many RAS connections concurrently for different operational purposes. Solutions here generally require special IT systems (hardware and software) which are specifically designed for use as RAS servers.
The list below provides a rough summary of the possible general evaluation criteria, but does not claim to be exhaustive and can be extended to include other general requirements. In addition to the criteria listed here, further specific requirements which result from the planned actual operational scenarios must be identified as part of the RAS requirements analysis (see safeguard S 2.183 Performing a RAS requirements analysis).
| 1 |
General criteria |
| 1.1 |
Performance and scalability |
| |
- Can the system satisfy the performance requirements?
|
| |
- Can transparent load balancing or data compression be configured for the system?
|
| |
- Can the system be designed in such a way that it can cope with future growth requirements (e.g. through modular system structure, simple integration of new RAS servers, no separate user administration for new RAS connections)?
|
| 1.2 |
Maintainability |
| |
- Is the product simple to maintain?
|
| |
- Does the vendor offer regular software updates?
|
| |
- It is possible to conclude maintenance contracts for the product?
|
| |
- Can maximum response times for problem resolution be defined in the maintenance contract?
|
| |
- Does the vendor offer a competent technical customer service (call centre, hotline etc.) which can provide immediate assistance in the event of problems?
|
| 1.3 |
- Reliability / operational reliability
|
| |
- How reliable and fail-safe is the product?
|
| |
- Does the vendor offer high availability solutions?
|
| |
- Is it possible to use the product in continuous operations?
|
| 1.4 |
User-friendliness |
| |
- Is the product simple to install, configure and use? Does the product meet the relevant ergonomic regulations?
|
| |
- Is the user interface, especially that of the RAS client, designed so that even inexperienced users can work with it without having to accept reduced security (e.g. through the provision of context-sensitive help, on-line documentation, step-by-step guidance with comprehensible explanations, "wizards", detailed error messages)?
|
| |
- Is it possible to configure use of the RAS client in such a way that as far as possible users do not have to bother with technical details? Is security still guaranteed if this is the case?
|
| 1.5 |
Costs |
| |
- How much do the hardware and software cost to purchase?
|
| |
- What are the expected ongoing costs of the hardware and software (maintenance, operation, support)?
|
| |
- What are the expected ongoing staff costs (RAS administrator / internal auditor)?
|
| |
- Do additional software or hardware components need to be purchased (e.g. dial-in server, server for additional authentication services)?
|
| |
- How much will it cost to train the staff and administrators who will be using the RAS product?
|
| 2. |
Operation |
| 2.1 |
Installation and initial operation |
| |
- Do the RAS system's default settings ensure that the RAS will be securely configured after installation?
|
| |
- Can installation of the RAS client software be automated with predefined configuration parameters?
|
| |
- Is it feasible for less technically-minded staff to install the RAS client software?
|
| |
- Can important configuration parameters be protected against modification by users?
|
| |
- Does the product work with commonly available hardware and software (operating systems, plug-in cards, drivers)?
|
| |
- Is the RAS system compatible with commonly used system management systems?
|
| 2.2 |
Error handling |
| |
- Is the security of RAS connections also assured after a critical failure or error (e.g. by preventing any further connections after abnormal termination)?
|
| |
- Can the system behaviour be reconfigured after a critical failure or error? For example, is it possible to configure the system so that after a critical error it is automatically rebooted or the Administrator is informed?
|
| 2.3 |
Administration |
| |
- Does the documentation delivered with the product contain a full description of all the technical and administrative details?
|
| |
- Can the administrative functions be accessed via a graphical user interface which is intuitive to use? Are the administrative functions designed so that attention is drawn to any incorrect, insecure or inconsistent configurations settings or these are prevented?
|
| |
- Do the administrative functions permit both command line data input and entry via a graphical user interface?
|
| |
- Is access to the administrative functions protected through adequate access control, e.g. using password entry, implementation of a role concept (Administrator, Internal Auditor), two-person rule?
|
| 2.4 |
Logging |
| |
- Does the product offer logging facilities?
|
| |
- Is it possible to configure the amount of detail logged? Is all the relevant data captured by the logging?
|
| |
- Do the logging facilities allow data to be captured in different categories (e.g. by connection, user, protocol, service)?
|
| |
- Are there constraints on who may access the logged data?
|
| |
- Does the product allow the logged data to be stored not only locally but also on remote computers (central logging)? Are different data transmission methods offered for remote storage, so that external logging systems can also be used (e.g. syslog)? Can the logged data be transmitted securely?
|
| |
- Does the product offer a component enabling analysis of the logged data?
|
| |
- Is the logging mechanism compatible with the system management system used (transmission format, transmission protocol)?
|
| |
- Does the product offer facilities enabling the administrator to be informed or suitable protective measures (rejecting the RAS client, blocking of user accounts) to be automatically implemented in the event of certain predefined events occurring (e.g. denial of access, several successive unsuccessful attempts at authentication)?
|
| |
- Can logging be performed in such a way that the data privacy protection regulations can be satisfied?
|
| 2.5 |
Communication and data transmission |
| |
- On the LAN side, does the server software support all the network technologies that are used locally (e.g. ethernet, Token Ring, ATM)?
|
| |
- On the WAN side, do the client and server software support all the access technologies which will be used (e.g. ISDN, mobile phone, analogue telephone line, X.25)?
|
| |
- Does the RAS server allow several RAS clients to dial in at the same time?
|
| |
- Does the RAS product support different protocols for remote access over telecommunications networks (e.g. PPP, SLIP)?
|
| |
- Does the RAS product support different service protocols for remote access (e.g. TCP/IP, NetBEUI, XPC, DECnet)?
|
| |
- Are tunnel protocols (e.g. PPTP, L2F, IPSec) supported for Internet-based access?
|
| |
- Depending on the access technology used, does the RAS product allow the use of additional, technology-dependent mechanisms (e.g. channel bundling for ISDN, callback of the RAS client by the RAS server)?
|
| 2.6 |
Security: communication, authentication and access |
| |
- Does the product allow secure data transmission?
|
| |
- Does the product allow the use of alternative security mechanisms (IPv4 mechanisms, IPSec)?
|
| |
- Is communication protected using standard mechanisms? In particular, all the cryptographic algorithms used should be established and state-of-the-art. The product should comply with current standards.
|
| |
- Does the product architecture allow subsequent installation of new security mechanisms?
|
| |
- Are remote users granted access to the local network only after successful authentication?
|
| |
- Does the system allow remote users to be authenticated using several authentication mechanisms (e.g. user name and password, Challenge-Response, Calling Line Identification - CLI)?
|
| |
- Is the system architecture designed in such a way that new authentication mechanisms can be subsequently integrated?
|
| |
- Does the RAS system allow the use of one or more commonly used external authentication services (e.g. SecureID, RADIUS, TACACS+)?
|
| |
- Is it possible to integrate additional external authentication services?
|
| |
- Does the RAS system transmit the information necessary for access control of access to data in the local network (user ID, security ID) to the local access control mechanisms?
|
Once all the requirements for the product to be purchased have been documented, the products available on the market must be thoroughly researched to establish to what extent they satisfy these requirements. It is likely that not every product will satisfy all the requirements at the same time or equally well. Therefore each requirement should be weighted in a manner which reflects the importance of satisfying it. Similarly, the extent to which a given requirement is satisfied by a single product can be broken down into several stages. On the basis of the product evaluation performed (against the catalogue of requirements which has been drawn up) an informed purchasing decision can then be made.
