S 2.169 Developing a system management strategy

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Head of IT, 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 partial 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 on 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 strategy at the agency or company, the data 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 strategies 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 strategy must be defined for the field of system management or the company's or agency's existing security strategy 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 strategies in this sphere are to be considered particularly serious. 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 the management console is compromised), but also of an organisational nature.

Auditing, data protection officers and IT security management should become involved during the planning phase. After the management system is introduced, their duties in relation to the management system must be clear. Example: The data protection officer can pay attention to the observance of the data protection guidelines during the planning phase, for example monitoring which user information should or may be recorded as part of the system management process. After the system is introduced, the data protection 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 re-examined.

The following items 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 support 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.
    • Multiple management regions increase reliability, because, for example, in the event of the failure of one management region, the other regions can continue to be administered independently of the failed region.
    • 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: The 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 to forward 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: The 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).

Review questions:

• Were all objects to be administered by the system management system specified?
• Is a security policy specified that is to be used for the system management system?
• Does a security policy exist that covers the area of system management?
• Are there rules and procedures in case of security violation of network and system components?
• Is it checked that the system management strategy can be fully implemented using the possible system management products?