S 2.500 Logging IT systems

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Security-relevant activities on information processing systems should be logged for many reasons. On the one hand, when logging is activated it can be used for early detection and elimination of potential vulnerabilities. On the other hand, logging can be used to detect violations against security specifications or to obtain more information about a security incident. For this, events which occur on the IT systems to be monitored are recorded.

Each organisation should define general rules as to how IT systems, networks, or applications must be logged. These rules must then be adapted to the specific systems and implemented accordingly. Different modules of the IT-Grundschutz catalogues about IT systems, networks, and applications contain more detailed information about the things to be considered when logging on the respective IT systems, for example in S 4.302 Logging for printers, copiers and all-in-one devices. The logging topic is described in detail in module S 5.22 Logging. The module deals with all specific threats and safeguards relevant in the fields of logging and monitoring regardless of the operating system used.

The time and effort required for drawing up and implementing such a process are considerable. Therefore, this module should first and foremost be implemented for larger information systems and if centralised logging is designed for an information system. For smaller, less complex information systems, implementing this safeguard is normally sufficient.

At first, a logging concept should be drawn up for the organisation. This concept defines how, where, and what is to be logged for which protection requirements. In general, each login using administrative rights should always trigger an entry to the log. The concept must also contain specifications as to what is to be done with the logged events, which is described in S 4.431 Selecting and processing relevant information for logging. Below, aspects that should be taken into consideration during the design phase are presented.

Centralised or local logging

Logging procedures aim at being able to comprehend significant changes to IT systems, networks, or applications in order to be able to maintain their security. Here, a differentiation between local and centralised logging can be made.

Within the framework of centralised logging, logged information generated by different IT systems is transmitted to a dedicated IT system and analysed there. This way, the events to be logged can be selected, filtered, and analysed at one location. Amongst other things, this provides the advantage of connecting and so being better able to detect security problems and attacks to different IT systems. The relevant aspects regarding the aforementioned are described in detail in S 3.90 General requirements for centralised logging.

Within the framework of local logging, the events to be considered remain on the IT systems they were generated on. There, the events are selected, filtered, and analysed. The alarm triggered when a certain event occurs is also triggered in a decentralised manner by the respective IT systems.

When planning the logging procedure, the decision as to whether occurring events are to be logged locally or in a centralised manner must be made for the different IT components. In general, using centralised logging is recommendable. However, centralised logging is not supported by all IT systems.

Planning the logging procedure

Figure: Logging steps

Depending on whether logging is performed locally or in a centralised manner, different steps may be required. These must be taken into consideration in the logging concept and include:

• identification of the IT systems
  
  It must be decided which IT systems, networks, or applications are to be taken into consideration within the logging concept. In general, the security-relevant events of all IT systems should be logged and analysed. Amongst other things, these include:
• clients, including mobile IT devices
• servers
• network switching elements (routers and switches)
• databases for important business processes
• telecommunication systems, and
• security gateways
  
  If logging is to be performed in a centralised manner, the IT systems to be logged must support this feature. For this, an agent or another application normally must be installed on the IT system to be logged. This application receives the events on the respective IT systems and sends the data directly to the centralised logging server.
• selection of security-relevant events
  
  As a matter of principle, all security-relevant incidents within an information system should be logged. For example, the following events must be considered specifically:
• denied access attempts to user IDs, e.g. caused by incorrectly entered passwords,
• blocked user IDs,
• user or administrator logins at unusual times,
• failure of or errors regarding the hardware,
• malfunctions or overload conditions of the applications, e.g. caused by insufficient memory capacity or cancelled important processes,
• data about network utilisation and overload,
• notifications or warnings of intrusion detection systems, as well as
• accesses to active network components (who logged in when?).
  
  The events to be logged overall depend on the protection requirements of the respective IT systems and must therefore be coordinated and specified within the organisation in advance, amongst other things.
• centralisation
  
  It is recommendable to summarise all logged data at one location. In the event of local logging, this may be individual directories so that the log files are stored to one location in a clear manner and can be found quickly. In the event of centralised logging, the occurred events should be transmitted to a centralised server using a secure channel and should be stored to a database afterwards.
• normalisation
  
  The summarised, different messages can be normalised for later analysis, since there is no uniform standard for format and transmission protocol. The different protocol formats such as Syslog, MS Eventlog, SNMP, Netflow, or IPFIX, for example, can be adapted to each other by means of normalisation. This way, the different data formats are converted to a uniform format and can be analysed subsequently.
• filtering
  
  Appropriately filtering the logged data allows for discarding and excluding data irrelevant to the respective purpose from the further processing procedure as early as possible. The informative content is separated from the security-relevant messages, which is followed by further steps.
• aggregation
  
  Within the framework of aggregation, the logged events with redundant content can be summarised to become one record. Often, identical log messages are generated several times by the same IT system, which is why it is often sufficient to only process the first event. If redundant events occur, the number of occurred events should be stored in order to be able to determine subsequently how often the identical log messages occurred.
• categorisation and prioritisation
  
  The logged events can be categorised and prioritised especially within the framework of centralised logging. This way, the information contained in the message can be refined even more.
• correlation
  
  Within an information system, the different IT systems such as security gateways, servers, and clients only have a limited view of their respective function. In order to remedy this problem, the corresponding logged data may be correlated. For example, the security gateway logged data and the router log entries can be correlated.
• analysis and control
  
  Possible security gaps, manipulation attempts, and irregularities can only be detected if the logged events are analysed and controlled at regular intervals. Along with the security events and errors, an analysis also provides information about the current utilisation.
  
  Logging security-relevant events is only effective as a security safeguard if the logged data is evaluated by an auditor at regular intervals, i.e. by a person not administrating the respective systems. If it is not possible either for technical or personnel reasons to staff the role of an independent auditor of log files, they can also be evaluated by an administrator. If possible, this should not be the administrator responsible for operating the respective systems, because otherwise the administrative activities would be difficult to monitor.
  
  If comprehensive log files must be analysed at regular intervals, it makes sense to use analysis tools such as graphical user interfaces or report generators. These tools should allow analysis criteria to be selected and highlight especially critical entries (e.g. repeated failed attempts to log-on).
  
  More detailed information on analysis can be found in S 2.64 Checking the log files.
• alarm
  
  If certain events previously defined as being critical occur or if thresholds are exceeded, an alarm should be triggered via email or SMS, for example. In order to trigger the alarms in a reasonable manner, it is important to reduce the number of false alarms. For this, the thresholds must be configured realistically and adapted to the circumstances of the information system.
• archiving
  
  It must be examined which legal or contractual retention periods are applicable to log files. A minimum retention time may be specified in order to guarantee the ability to trace all activities, and a deletion requirement may apply due to data protection regulations (see also S 2.110 Data protection guidelines for logging procedures). If logged data is archived, the recommendations of S 1.12 Archiving must be taken into consideration.

Confidentiality and integrity of the logged events

Some data sources generate log messages allowing for specific allocation to a person. Therefore, it should be guaranteed that only authorised persons may read the logged events. It should not be possible either that logged events can be deleted or changed subsequently by unauthorised persons. This must only be done by persons logged in with an auditor role, for example. If technically feasible, the administrator roles should not be able to delete or change data either.

Therefore, any access by unauthorised persons must be prevented by means of the corresponding file system rights. The events should also be protected even during the transmission of logged data in the event of centralised logging, for example by means of encryption or by transmitting the data using a separate administration network (out-of-band management). This way, the protection of the integrity and confidentiality of the log messages during transmission is increased as well.

In the event of higher protection requirements it must be checked whether the logged events are written to a WORM medium ("Write Once Read Many"). These data media can only be written once so that any subsequent changes to written data media are impossible.

Time synchronisation

In order to be able to detect attacks to IT systems, networks, and applications or their malfunctions, the same time should be configured on all IT systems and virtual instances. A centralised time server must be used in order to ensure that all systems have the same time even if the information system is large. This server provides the central time interval using the Network Time Protocol (NTP), for example (see S 4.227 Use of a local NTP server for time synchronisation). Any further systems within the information system can synchronise using this time interval.

Review questions:

• Is there a concept for the logging procedure?
• Are the logged events protected against unauthorised access?