OPS.1.1.5 Logging

Description

Introduction

To ensure reliable IT Operations, IT systems and applications should log either all or at least selected operationally and security-relevant events — i.e. store them automatically and make them available for evaluation. Logging is used in many institutions to detect hardware and software problems as well as resource bottlenecks in a timely manner. Security problems and attacks on the operated network services can also be traced using log data. Such data can also be used to secure evidence through forensic investigations after an attack on IT systems or applications becomes known.

In every information domain, log data is generated locally by a large number of IT systems and applications. However, to obtain an overall picture of an information domain, logging events generated by different IT systems and applications can be sent to a dedicated logging infrastructure and stored there centrally. Only in this way can the log data be selected, filtered, and systematically evaluated at a central location.

Objective

The objective of this building block is to collect, store, and appropriately provide all relevant data securely so that as many security-relevant events as possible can be logged.

Scope and Modeling

The building block OPS.1.1.5 Logging is to be applied once to the entire information domain.

This building block addresses exclusively cross-cutting aspects that are required for appropriate logging. The logging of specific IT systems or applications is not addressed here but described in the respective building blocks of the IT-Grundschutz Compendium.

Many operating systems or applications already include logging functions, or these can be integrated there using additional products. To secure these functions and the stored log data, the underlying operating system must be protected. However, this is not part of this building block. For this purpose, the operating system-specific building blocks must be implemented, e.g. SYS.1.2.3 Windows Server.

Prior to logging security-relevant events, it is important that responsibilities and competencies are clearly defined and assigned. In particular, the principle of separation of functions should be observed. This topic is not part of this building block but is addressed in building block ORP.1 Organization.

This building block is also to be distinguished from the detection of security-relevant events (see DER.1 Detection of Security-Relevant Events) and the response to security incidents (see DER.2.1 Security Incident Response). Both aspects are not or only marginally addressed in this building block.

Also described elsewhere are the evaluation of log data and their long-term, secure, immutable, and reproducible storage (see DER.1 Detection of Security-Relevant Events or OPS.1.2.2 Archiving).

Requirements for handling personal data are described in building block CON.2 Data Protection.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block OPS.1.1.5 Logging.

Missing or Insufficient Logging

In an information domain, there are often IT systems or applications where logging was not activated in the default settings. Individual IT systems or applications can also sometimes not log at all. In both cases, important information can be lost and attacks cannot be detected in time. This is also possible when logging is used for individual IT systems or applications, but the log data is not consolidated at a central location. In information domains without central logging, it is difficult to ensure that the relevant log information from all IT systems and applications is retained and evaluated.

Furthermore, log data must contain meaningful information. Which events are logged depends, among other things, on the protection needs of the respective IT systems or applications. If this is disregarded — for example by relying only on default settings of IT systems or applications for logging — particularly relevant security events may not be logged. Attacks may therefore not be detected.

Incorrect Selection of Relevant Log Data

Log data often provides important information that helps to identify security incidents. A particular challenge is filtering out the relevant messages from the large quantity of various logging events. Many logging events are only informational in nature and distract from the truly important messages. If too many logging events are selected, the wealth of information is difficult to evaluate and requires a great deal of time.

Furthermore, logging events can be discarded or overwritten if the working memory or hard disk capacity of the IT system or logging infrastructure is insufficient. If too few or insufficiently relevant logging events are recorded as a result, security-critical incidents could go undetected.

Missing or Faulty Time Synchronization in Logging

If time is not synchronized on all IT systems in an information domain, the log data may not be able to be correlated with each other, or the correlation may lead to incorrect findings. The reason is that the different timestamps of events do not share a common basis. Missing time synchronization therefore makes it more difficult to evaluate collected log data, particularly when it is stored on a central log server. Furthermore, faulty or missing time synchronization can lead to logging not being usable for evidence collection.

Poor Planning in Logging

If logging is not sufficiently planned, this can lead to IT systems or applications not being monitored and security-relevant events therefore not being detected and appropriately handled. Data protection violations could also not be traced.

Loss of Confidentiality and Integrity of Log Data

Some IT systems in an information domain generate log data such as usernames, IP addresses, email addresses, and computer names that can be assigned to specific persons. Such information can be copied, intercepted, and manipulated if it is not transmitted encrypted and stored securely. This can lead to attackers accessing confidential information, or security incidents being deliberately concealed through manipulated log data. Similarly, if attackers obtain a large amount of log data, they can use this information to expose the internal structure of the information domain and thereby target their attacks more precisely.

Incorrectly Configured Logging

If logging in IT systems is incorrectly configured, important information is either recorded incorrectly or not at all. It can also happen that too much or incorrect information is logged. For example, personal data could be logged and stored without authorization. The institution could thereby violate legal requirements.

Through incorrectly configured logging, it is also possible for log data to be available in inconsistent or proprietary formats. This can make the logs difficult to evaluate and security incidents may go undetected.

Failure of Data Sources for Log Data

If IT systems in an information domain no longer deliver the necessary log data, security incidents can no longer be adequately detected. The causes of such failures of data sources can be errors in hardware and software or incorrectly administered IT systems. Particularly if it is not noticed that data sources have failed, this can lead to an incorrect picture of the institution’s security situation. This can allow attackers to remain undetected for a very long time and access institution-critical information or manipulate production systems.

Inadequately Dimensioned Logging Infrastructure

Due to complex information domains and diverse attack scenarios, requirements for logging are increasing, as very large amounts of log data must be stored and processed. Furthermore, it is common in the event of security incidents to increase the intensity of logging. If the logging infrastructure is not designed for this, it can happen that log data is stored incompletely. Security-relevant events can then no longer be evaluated or can only be inadequately evaluated, and security incidents go undetected.

Requirements

The following are the specific requirements of building block OPS.1.1.5 Logging. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

The IT-Grundschutz Compendium additionally defines further roles. They should be staffed insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

OPS.1.1.5.A1 Creation of a Security Policy for Logging (B) [Specialist Responsible Persons]

Based on the institution’s general security policy, a specific security policy for logging MUST be created. This security policy MUST describe in a traceable manner the requirements and specifications for how logging is to be planned, established, and securely operated. The specific security policy MUST regulate how, where, and what is to be logged. The type and extent of logging SHOULD be oriented toward the protection needs of the information.

The specific security policy MUST be created by the ISO together with the specialist responsible persons. It MUST be known to all employees responsible for logging and be fundamental to their work. If the specific security policy is changed or if there is a deviation from requirements, this MUST be coordinated with the ISO and documented. It MUST be regularly checked whether the specific security policy is still correctly implemented. The results of the review MUST be documented.

OPS.1.1.5.A2 DISCONTINUED (B)

This requirement has been discontinued.

OPS.1.1.5.A3 Configuration of Logging at System and Network Level (B)

All security-relevant events from IT systems and applications MUST be logged. If the IT systems and applications defined as relevant in the logging policy have a logging function, it MUST be used. When logging is set up, the manufacturer’s specifications for the respective IT systems or applications MUST be observed.

At appropriate intervals, it MUST be checked by sampling whether logging is still functioning correctly. The checking intervals MUST be defined in the logging policy.

If operational and security-relevant events cannot be logged on an IT system, additional IT systems for logging (e.g. of events at the network level) MUST be integrated.

OPS.1.1.5.A4 Time Synchronization of IT Systems (B)

The system time of all logging IT systems and applications MUST always be synchronized. It MUST be ensured that the date and time format of the log files is uniform.

OPS.1.1.5.A5 Compliance with Legal Framework Conditions (B)

During logging, the provisions from the current laws on federal and state data protection MUST be observed (see CON.2 Data Protection).

Furthermore, any personal rights or co-determination rights of employee representatives MUST be respected.

It MUST also be ensured that all other relevant legal provisions are observed.

Log data MUST be deleted in accordance with a defined process. It MUST be technically prevented that log data is deleted or modified in an uncontrolled manner.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

OPS.1.1.5.A6 Establishment of a Central Logging Infrastructure (S)

All collected security-relevant log data SHOULD be stored at a central location. For this purpose, a central logging infrastructure in the form of a log server cluster SHOULD be set up and placed in a specially established network segment (see NET.1.1 Network Architecture and Design).

In addition to security-relevant events (see OPS.1.1.5.A3 Configuration of Logging at System and Network Level), a central logging infrastructure SHOULD also log general operational events that indicate an error.

The logging infrastructure SHOULD be adequately dimensioned. The possibility of scaling in the sense of extended logging SHOULD be taken into account. Sufficient technical, financial, and personnel resources SHOULD be available for this purpose.

OPS.1.1.5.A7 DISCONTINUED (S)

This requirement has been discontinued.

OPS.1.1.5.A8 Archiving of Log Data (S)

Log data SHOULD be archived. The legally prescribed regulations SHOULD be taken into account.

OPS.1.1.5.A9 Provision of Log Data for Evaluation (S)

The collected log data SHOULD be filtered, normalized, aggregated, and correlated. The log data processed in this way SHOULD be made appropriately available so that it can be evaluated.

To enable automated evaluation of the data, the logging applications SHOULD have appropriate interfaces for the evaluation programs.

It SHOULD be ensured that the security requirements defined in the logging policy are complied with when evaluating log data. Even when data is made available, operational and internal agreements SHOULD be taken into account.

The log data SHOULD additionally be retained in its original, unmodified form.

OPS.1.1.5.A10 Access Protection for Log Data (S)

It SHOULD be ensured that the executing administrators themselves have no authorization to modify or delete the recorded log data.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

OPS.1.1.5.A11 Increasing the Scope of Logging (H)

For applications or IT systems with high protection needs, more events SHOULD generally be logged so that security-relevant incidents are traceable as completely as possible.

To enable real-time evaluation of the log data, it SHOULD be stored centrally from the logging IT systems and applications at shorter time intervals. Logging SHOULD enable evaluation across the entire information domain. Applications and IT systems with which central logging is not possible SHOULD NOT be used in the case of high protection needs.

OPS.1.1.5.A12 Encryption of Log Data (H)

To securely transmit log data, it SHOULD be encrypted. All stored logs SHOULD be digitally signed. Archived log data stored outside the logging infrastructure SHOULD also always be stored encrypted.

OPS.1.1.5.A13 Highly Available Logging Infrastructure (H)

A highly available logging infrastructure SHOULD be established.

Additional Information

Good to Know

The Federal Office for Information Security (BSI) regulates logging and detection of security-relevant events (SRE) in its minimum standard “Minimum Standard of the BSI for Logging and Detection of Cyber Attacks.” The minimum standards are to be implemented by the bodies of the federal administration named in § 8 Para. 1 Sentence 1 BSIG.

The International Organization for Standardization (ISO) provides requirements for logging in ISO/IEC 27001:2013, Chapter A.12.4 “Logging and Monitoring.”

The Information Security Forum (ISF) provides requirements for logging in its standard “The Standard of Good Practice for Information Security,” Chapter TM1.2 - Security Event Logging.

The National Institute of Standards and Technology (NIST) describes in its Special Publication 800-92 “Guide to Computer Security Log Management” how logging can be used securely.