+OPS.1.1.5 Logging
---+OPS.1.1.5.G1. Insufficient Logging
---+OPS.1.1.5.G2. Incorrect Selection of Relevant Log Data
---+OPS.1.1.5.G3. Lack of Proper Time Synchronisation During Logging
---+OPS.1.1.5.G4. Poor Planning of Logging
---+OPS.1.1.5.G5. Loss of Confidentiality and Integrity in Log Data
---+OPS.1.1.5.G6. Incorrectly Configured Logging
---+OPS.1.1.5.G7. Failure of Log Data Sources
---+OPS.1.1.5.G8. Insufficient Logging Infrastructure Capacity
---+OPS.1.1.5.A1 Drawing Up a Security Policy for Logging [Process Owner] (B)
---+OPS.1.1.5.A3 Configuring Logging at the System and Network Level (B)
---+OPS.1.1.5.A4 Time Synchronisation of IT Systems (B)
---+OPS.1.1.5.A5 Complying with Legal Framework Conditions (B)
---+OPS.1.1.5.A6 Basic Structure of a Centralised Logging Infrastructure (S)
---+OPS.1.1.5.A8 Archiving of Log Data (S)
---+OPS.1.1.5.A9 Providing Log Data for Assessment (S)
---+OPS.1.1.5.A10 Access Protection for Log Data (S)
---+OPS.1.1.5.A11 Increasing the Scope of Logging (H)
---+OPS.1.1.5.A12 Encryption of Log Data (H)
---+OPS.1.1.5.A13 Highly Available Logging Infrastructure (H)

OPS.1.1.5 Logging

Introduction

To ensure reliable IT operations, IT systems and applications should automatically log all (or at least some specific) events that are relevant to operations and security and make them available for analysis. Logging is used in many organisations as a means of promptly identifying hardware and software problems and resource bottlenecks. However, security problems and attacks on network services can also be traced on the basis of log data. Through forensic examination, evidence can be secured from such data after an attack on IT systems or applications has come to light.

In each information domain, log data is locally generated by a multitude of IT systems and applications. To get a complete overview of a given information domain, the event logs generated by various IT systems and applications can be sent to a dedicated logging infrastructure for central storage. Only then can the log data be selected, filtered, and analysed systematically in one central location.

Objective

The aim of this module is to ensure the secure collection of all relevant data so that it can be stored and provided in a suitable form for evaluation. This in turn facilitates the logging of as many security-relevant events as possible.

Scoping and Modelling

OPS.1.1.5 Logging must be applied once to the entire information domain at hand.

This module only considers overarching aspects that are required for appropriate logging. Logging for specific IT systems or applications is not dealt with here; it is described in the relevant modules of the IT-Grundschutz Compendium.

In many operating systems or applications, logging functions are already present or can be integrated through additional products. To safeguard these functions and stored log data, the underlying operating systems must be protected. However, this is not covered in this module.

Operating-system-specific modules such as SYS.1.2.2 Windows Server 2012 must be implemented.

Before implementing logging of security-relevant events, it is important that the related responsibilities and competencies be clearly defined and assigned. Particular attention should be paid to the principle of separation of duties. This topic is also not part of this module; it is covered in module ORP.1 Organisation.

In addition, this module must be distinguished from the detection of security-relevant events (see DER.1 Detecting Security-Relevant Events) and responses to security incidents (DER.2.1 Security Incident Handling). At most, these aspects are only addressed in passing in the present module.

The evaluation of log data and the secure, unchangeable, and reproducible long-term storage of such information is also described elsewhere (see DER.1 Detecting Security-Relevant Events or OPS.1.2.2 Archiving).

Finally, specifications on how to handle personal data are described in module CON.2 Data Protection.

Useful Resources

The Federal Office for Information Security (BSI) regulates the logging and detection of security-relevant events in “Mindeststandard des BSI zur Protokollierung und Detektion von Cyber-Angriffen” [BSI Minimum Standard for Logging and Detection of Cyber Attacks].

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

The Information Security Forum (ISF) provides guidelines for logging in “The Standard of Good Practice for Information Security” (section TM1.2, "Security Event Logging").

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

1. Visão geral

Título Norma
OPS.1.1.5.A1 Drawing Up a Security Policy for Logging [Process Owner] (B)

Based on an organisation's general security policy, a specific security policy SHOULD be drawn up for logging. This security policy MUST transparently describe requirements and specifications on how logging is to be planned, set up, and securely operated. The security policy MUST specify what is to be logged, as well as how and where. Here, the type and scope of logging SHOULD be based on the protection needs of the information in question.

The security policy MUST be drawn up by the CISO together with the Process Owners. It MUST be known to all employees in charge of logging and be integral to their work. If the security policy is changed or deviations from its requirements are allowed, this MUST be coordinated with the CISO and documented. The correct implementation of this specific security policy MUST be regularly reviewed. The results of these reviews MUST be documented.

OPS.1.1.5.A3 Configuring Logging at the System and Network Level (B)

All security-relevant events pertaining to IT systems and applications MUST be logged. If the IT systems and applications defined as relevant in a logging policy have a logging function, it MUST be used. When setting up logging, the manufacturer specifications for the relevant IT systems or applications MUST be considered.

Spot checks MUST be carried out at appropriate intervals to ensure that logging is still functioning correctly. The intervals of these checks MUST be defined in the logging policy at hand.

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

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

The system time of all IT systems and applications that generate logs MUST always be synchronous. It MUST be ensured that the date and time formats of log files are uniform.

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

The regulations of the current laws on federal- and state-level data protection MUST be followed during logging (see CON.2 Data Protection).

Moreover, any personal rights and/or rights of co-determination of the Employee Representatives in question MUST be observed.

Compliance with any other relevant legal regulations MUST also be ensured.

Log data MUST be deleted in accordance with a specified process. Technical provisions MUST prevent log data being deleted or changed in an uncontrolled manner.

OPS.1.1.5.A6 Basic Structure of a Centralised Logging Infrastructure (S)

All security-relevant logging data SHOULD be stored in a central location. To this end, a central logging infrastructure (read: a log server system) SHOULD be designed and placed in a network segment created for this purpose (see NET.1.1 Network Architecture and Design).

In addition to security-relevant events (see OPS.1.1.5.A3 Configuring Logging at the System and Network Level), a central logging infrastructure SHOULD log general operational events that indicate errors.

The logging infrastructure SHOULD have sufficient capacity. The possibility of scaling up this infrastructure to support extended logging SHOULD be considered. To this end, sufficient technical, financial, and personnel resources SHOULD be available.

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

Log data SHOULD be archived. The relevant legal regulations SHOULD be taken into account in the process.

OPS.1.1.5.A9 Providing Log Data for Assessment (S)

Collected log data SHOULD be filtered, normalised, aggregated, and correlated. Log data processed in this way SHOULD be made available in a manner suitable for assessment.

Logging applications SHOULD have corresponding interfaces to programs capable of automatic data analysis.

It SHOULD be ensured that the evaluation of log data complies with the security requirements defined in the respective logging policy. Operational and internal agreements SHOULD also be taken into consideration when making log data available.

Log data SHOULD be stored unchanged in its original format.

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

It SHOULD be ensured that administrators who execute logging have no authorisation to modify or delete recorded log data.

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

If applications or IT systems require increased protection, more events SHOULD be logged so that security-relevant incidents can be traced as comprehensively as possible.

To ensure that log data can be evaluated in real time, it SHOULD be stored centrally at shorter intervals by the relevant IT systems and applications. Logging SHOULD enable assessment of the entire information domain in question. Applications and IT systems that do not allow for central logging SHOULD NOT be used in case of increased protection needs.

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

Log data SHOULD be encrypted for secure transfer. All saved logs SHOULD be digitally signed. Archived log data and log data stored outside the corresponding logging infrastructure SHOULD also always be stored in an encrypted manner.

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

A highly available logging infrastructure SHOULD be created.

1.1 Referências

1.2 Requisitos identificados

1.3 Regulamentos relacionados

2. Requisitos identificados

Requisitos
Fonte Requisito

3. Regulamentos relacionados

Regulamentos
Fonte Regulamentação

Pedidos ligados