S 2.169 Developing a system management strategy

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Head of IT Section, Administrator

Administrators have to carry out regular administration work on the components in a network. The duties to be performed range from setting up new users to installing new software; the distributed nature of the software requires the installation of part software on each individual computer (workflow system, document management system, etc.). In large organisations merely setting up a new user who is supposed to be able to log on at all computers to which he or she has access means a great deal of administrative work, because if the computers are run in stand-alone operation each one has to be configured accordingly. Today's network-capable operating systems (such as Unix, Windows NT or Novell) therefore include mechanisms that are intended to reduce the amount of administrative work (for example central user administration). However, if the administration of all hardware and software components in a local network is to be performed in a uniform manner at all levels (in both technical and organisational terms), technical aids in the form of management systems must be employed, but whether or not they are used successfully is also dependent on the management strategy that is to be drawn up. The specifications and rules imposed by the management strategy are then put into practice by system administration with the aid of the management software. Each management strategy must be adapted to the needs of the respective company or agency on a case-by-case basis. This entails working through the following steps.

Determining the objects to be administered by the management system

After the inventory has been taken (see S 2.168 IT system analysis before the introduction of a system management system) it must be established which areas of the IT system are to be administered by the management system that is to be procured:

• Which computers and other hardware are to be incorporated in the management system?

• Which software is to be included?

• Which users and/or user groups are to be included?

Determining the security guidelines to be applied in the management system

In addition to these decisions, existing regulations and methods also have to be incorporated into the system. For example, the established security policy at the agency or company, the privacy protection guidelines and the guidelines on the introduction of new software have to be brought into the management concept because the regulations currently in force also have to be observed and implemented when a management system is put in place. Rules also have to be adopted on the use of the management system itself, or the validity of existing rules has to be examined, and where necessary they must be adapted before being applied. This applies in the following fields, in particular:

• Access rights to management information

• Documentation of the management system

• Drafting or adjustment of emergency plans to deal with the failure of the management system or individual components

The response to violations of security policies in the field of system management should also be determined in advance. In much the same way as in other fields of IT, a security policy must be defined for the field of system management or the company's or agency's existing security policy must be applied to the field of system management. As a management system interacts with important network and system components and administers and monitors their operation, violations of the security policies in this sphere are to be viewed particularly seriously. In particular, provisions and procedures must be defined which will be deployed in the event of any such security violation. These are on the one hand technical (for example assigning new passwords for all users after compromising of the management console), but also of an organisational nature.

Auditing, data privacy officers and IT security management should become involved during the planning phase. After the management system is introduced, the duties incumbent upon them in relation to the management system must be clear. Example: the data privacy officer can pay attention to the observance of the privacy protection guidelines during the planning phase, for example monitoring which user information is intended to be or allowed to be recorded as part of the system management process. After the system is introduced, the privacy officer must also be in a position to check the observance of the guidelines. Much the same applies to the areas of responsibility of the auditor and the IT security officer.

Determining the boundary conditions for selecting the management system product

The introduction of a system management system calls for extensive and careful planning. Parts of the system management strategy are also dependent on whether or not they can be implemented with a specific product. Consequently the drafting of the management strategy and the selection (or preselection) of a product must be reexamined.

The following points should be taken into consideration when drawing up the system management strategy:

• Is more than one management domain needed? If so: how are they to be formed? Management domains allow the components of the administered system to be divided into groups. The individual groups can be administered separately from each other. Breaking a system down into various management domains is not obligatory for small or medium-sized systems, but it does encourage structured system management. For large systems, dividing the system into various management domains is generally a necessity. The planning of the management regions is dependent on a number of factors:

• Network topology

For medium-sized systems, in particular, it makes sense to divide the system into management domains in accordance with the actual network topology (especially if there are no differences in areas of responsibility, for example).

• Organisational responsibilities within the company or agency

The organisational structure can be emulated by the management system, giving rise to domains such as "Accounting", "Programming", "Production Division" or "Software Development Division", for example.

Security-related factors which have an effect on management policy can also result in the creation of multiple management regions. This is the case in particular when management tasks for certain organisational units need to be delegated, without the local administrator being given access rights to the management functions for the components outside his or her sphere of responsibility.

• Existing infrastructure

Examples of factors to be examined include the geographical distribution of branches or the spatial distribution of work teams across the storeys of a building.

• Safety considerations

• Multiple management regions may be necessary if the management product supports different encryption mechanisms for each region but normally only one mechanism can actually be used per region. If different mechanisms are indeed used between individual management components, multiple management regions are necessary. Example: The system being administered comprises several database servers with sensitive data and the associated clients, which do not store data themselves. The management console should always communicate with the servers using strong encryption, because the databases are also administered via the management system. Communication with the clients, on the other hand, should be only weakly encrypted, for performance reasons. In this case it is normally necessary to create two management regions: one region containing the servers and a second region containing the clients.

• The number of computers to be administered per management region also has an influence. Most products give recommendations as to the number of computers that can be administered by the management server of one region. A figure of 200 computers per server is not unusual, however.

• What types of computer should be used as management servers? There can generally be expected to be performance losses as the number of clients connected to one management server increases. This must be taken into consideration when planning.

• What physical arrangement must the management servers have, and where will they be installed? The location of a server has an influence on, for example, how computers that are to be administered by the server are connected to it via the network. On some platforms, for example, there are minimum requirements for the communications bandwidth between the server and clients (e.g. TME 10 does not support the linking of clients via lines rated lower than 14.4 kbps). This has direct consequences on the possible management system configuration, and may make it necessary to purchase new computers or expand network connections.

• Are gateways or proxies necessary, which allow hierarchically structured management and/or connection to products from third parties?

• Some systems distinguish between what they refer to as managed nodes and endpoints. Both of these are workstations, but they differ in terms of the way they are integrated into the management system: endpoints, for example, in contrast with managed nodes, do not maintain a local database of their own with management information, nor can they be used for forwarding management information to other computers. It has to be decided which machines are to be incorporated into the management system as managed nodes and which are to be administered merely as endpoints. Generally speaking, most workstations should be included as endpoints.

The management strategy drawn up in this way necessarily brings with it a series of demands on the management product that is to be purchased. Specific product selection can be made by weighting the requirements. The management strategy must then be examined to determine whether it can be implemented in full with the available range of functions. It may be necessary to reformulate the strategy in certain areas as a result. Example: product selection reveals that the system that supports strong encryption unfortunately does not allow the delegation of administration tasks to subadministrators. The management strategy has to be adapted as a result (assuming the weighting of the requirements is correct).