S 2.214 Concept of IT operations

Initiation responsibility: Top Management, Head of IT, IT Security Officer

Implementation responsibility: IT Security Officer, Head of IT

In order to be able to guarantee proper and secure IT operations, a comprehensive concept is essential. Procedures and requirements for the use of IT systems and IT products in the various parts of the organisation should exist. These should be well harmonised and reflect the security objectives of the government agency or company.

Guidelines for IT procedures and IT security principles

All organisational units involved in IT planning and IT operation must agree on a set of basic IT security principles which are to be applied to all areas (e.g. requirements regarding passwords). The subject of authentication and the granting of rights must be fully covered (see S 2.220 Guidelines for access control).

Responsibilities for the operation of all IT components must be clearly specified. These include the appointment of administrators and contact persons for the users (see also S 2.79 Determining responsibilities in the area of standard software).

Every purchase of new IT components should be preceded by preparation of a proper plan as to how these will be used. This should include the subject of their integration into the existing information system and the effects of this on existing security mechanisms which may need to be modified (see S 2.216 Approval procedure for IT components).

In addition to the process of ordering IT equipment, it must also be covered how the IT components delivered are to be handled (see S 2.90 Checking delivery). Before any new hardware components or new software are used, it must be tested (see S 4.65 Testing of new hardware and software).

Every installation of IT components must comply with the basic IT security objectives of the government agency or company and be based on controlled procedures. Depending on the particular IT component concerned and its security requirements, access rules, user rights and other security-related settings must be configured. In general, every IT installation should be clearly documented (see S 2.87 Installation and configuration of standard software).

In order to be able to provide the required resources at any time, the capacity requirements for operation of the IT systems and IT applications must be examined. It should be assessed regularly whether the existing capacities are still enough for the existing or planned business processes and applications.

Guidelines for secure IT operation

In order to be able to maintain security of all IT systems in ongoing operations, a number of factors must be considered. Therefore all the tasks that are necessary for maintaining proper and secure operations must be written down and clearly assigned. The following aspects must be covered here, among others:

• Information processing must be continuously documented in all its phases, all applications and all systems (see S 2.219 Continuous documentation of information processing).
• Access to all IT systems should be protected, e.g. through passwords.
• The functions of those IT components which should not or are not allowed to be used must be blocked if possible (see also S 4.95 Minimal operating system).
• The logging files must be checked at regular intervals for anomalies (such as the execution of functions that are not supposed to be used).
• If possible, the IT systems should be integrity tested at intervals so that any unauthorised changes can be discovered as early as possible. This applies in particular to configuration data.
• For all IT systems suitable procedures for data backup should be employed.
• Adherence to the security safeguards must be checked at regular intervals (see S 2.199 Maintaining information security).

Standard solutions for hardware and software components used

The larger an organisation is, the more important it is to use standard components for IT equipment and IT operations where possible. This affects both hardware components, such as routers, printers and graphics cards, and also software products such as operating systems, word processing programs and tools. Otherwise there is a danger that the entire system ceases to be possible to administer due to interoperability problems and burgeoning complexity.

In-house standards for hardware and software components should therefore be specified and documented and these should be followed during procurement. This will enable tried and tested solutions to be used and interoperability and compatibility problems to be avoided as far as possible. Moreover, this will have the effect of reducing the administrative effort and the amount of expert knowledge required. In many cases the costs of storing consumables can be lowered as well. When combined with framework agreements or quantity discounts, it is often possible to make additional financial savings as well.

Due to the rapid pace of technical developments in the area of information processing, in-house standards for IT components must be updated regularly. This generally results in a mixture of different "generations" of in-house standards being necessary. Hence when revising the in-house standards it is important to check that the new and old IT components and/or products are compatible and can be used together.

One particularly important application for in-house standards is PC workstations. Here in-house standards should be drawn up both for the hardware components of the PCs, such as processors, internal memory, graphics cards etc., and also for the installed software and its configuration. Otherwise, due to the multitude of possible ways in which a PC can be configured, there is a danger that the PC workstations used could become unwieldy, making administration no longer possible. Medium-sized government agencies and companies in which compulsory in-house standards have not be laid down find the maintenance alone of the necessary hardware drivers for operating systems no longer manageable. In-house standards for PC workstations also facilitate the use of system management products.

Note: When defining in-house standards for hardware and software components it is important not just to consider the most popular products on the market. Rather, selection should be oriented towards the functional requirements and the (IT) security requirements. A "monoculture", i.e. in which a single product has a stranglehold on the market, can even lead to security problems, for in such a case any software weaknesses that exist in the product will be particularly widespread and can therefore, if exploited, cause huge cumulative damage. Computer viruses, Trojan horses and other threats from wilful action are often directed at products that are in widespread use.

Conventions for name, address and number spaces

Within an organisation generally a variety of different name and number spaces co-exist. Especially popular are ones which are used outside of the government agency or company, for example, e-mail addresses, DNS names, telephone numbers and designations of organisational units. But even purely internal naming conventions, such as inventory numbers, IP addresses and identity pass numbers, often play an important role for the organisation and IT management.

For information processing to flow smoothly and to ensure that the IT assets used can be properly administered, it is necessary that an organisation-wide concept is developed for the name and number spaces used. When designing this, the following aspects should be considered:

• As few different name and number spaces should be used and maintained in parallel as possible.
• The concept must cover the issue, revocation, blocking of names and numbers when required as well as the interaction of the individual name and number spaces.
• Names and numbers which are only required for parts of an organisation (organisational units, subnets, properties etc.) should if possible be derived from general, organisation-wide name or number spaces.

• The structure of the name and number spaces used should be as simple and general as possible and be without unnecessary exceptions, even if this means that the designations have to be longer (e.g. more digits). Otherwise there is a danger that the designations could be misinterpreted or that it might not be possible for them to be processed by products that are widely used.

• At the design stage it is important to take into account the growth that is expected to occur in the medium term which will have to be accommodated by the name and number spaces. Generous reserves must be provided. It is often time-consuming and expensive to expand name and number spaces afterwards or to migrate to larger name or number spaces.

• If it is possible for conflicts, i.e. the multiple issue of the same identifier or the same number, to occur through the general issue system, then it must be determined in the concept how such conflicts are to be resolved. An important example is the convention first name.last name for e-mail addresses. Here it must be specified in the concept which addresses should be given as alternatives where two or more employees in the organisation have the same first and last names.

Interface definitions for the interaction of components

Information processing generally entails a number of small processing steps which are supported by suitable hardware or software components. The transfer of data between these components normally involves files, databases or networks.

To be able to ensure smooth IT operations it is therefore necessary to clearly define the interfaces through which the individual components will interact. All interface definitions that are not obvious from the components used should be documented.

Important aspects of interface definitions between IT components include file and data formats and network protocols. In order to be able to exchange individual components as smoothly as possible when required (protection of investment) and resort to tried and tested solutions, standard formats and standard protocols, such as EDI, XML and HTTP, should be used as far as possible.

All changes to interface definitions between the IT components used must be documented and checked to see what effects they have on the security of the information system. If necessary the security concept should be supplemented or modified accordingly.

Review questions:

• Are basic security principles defined together with all units involved in IT planning and IT operation?
• Do documented in-house standards for hardware and software exist?
• Are aspects of compatibility with older hardware and software taken into account when revising the in-house standards?
• Does an organisation-wide concept for the name and number spaces used exist?
• Does the organisation-wide concept for name and number spaces used have sufficient reserves for future growth?
• Do documented interface definitions for the IT components used exist?
• Are the responsibilities for operation of all IT components defined?
• Are standard formats and standard protocols used for interfaces as far as possible?