S 5.22 Logging
Description
Logging as part of the operation of IT-systems constitutes the manual or automatic generation of records allowing for the following questions to be answered: "Who accessed and/or performed what, when, using which resources?" These records should also indicate system states: "Who had which access rights for which period of time?" For reliable IT operations, security-critical events in the information system should be logged. Logging procedures aim at being able to comprehend significant changes to IT systems and applications in order to be able to comprehend their security. Logging is used in many information systems in order to be able to promptly identify hardware and software problems and resource bottlenecks. However, security problems and attacks to the operated services can also be comprehended on the basis of logged data.
Logging can be performed locally or in a centralised manner. In order to get a complete overview of the information system, a centralised logging server can be used which merges, analyses, and monitors the different logged data. This way, attacks performed on several systems can be identified by means of analysing and correlating data.
Some typical application examples for centralised logging include:
- collection of messages of the security gateways regarding blocked connection attempts
- central venue for warnings if bulk memory quotas are exceeded
- archive for forensic investigations after an attack to IT systems became known
The module deals with all specific threats and safeguards relevant for appropriate logging and monitoring in an information system regardless of the operating systems 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 and less complex information systems, it may be sufficient just to implement S 2.500 Logging IT systems under certain circumstances.
Threat scenario
The following typical threats are taken into consideration for IT-Grundschutz during logging:
Force Majeure
| T 1.2 | Failure of the IT system |
Organisational Shortcomings
| T 2.1 | Lack of, or insufficient, rules |
| T 2.4 | Insufficient monitoring of security safeguards |
| T 2.7 | Unauthorised use of rights |
| T 2.22 | Lack of or insufficient evaluation of auditing data |
| T 2.61 | Unauthorised collection of person-related data |
| T 2.67 | Incorrect administration of site and data access rights |
| T 2.160 | Lack of or insufficient logging |
| T 2.161 | Loss of confidentiality and integrity regarding logged data |
Human Error
| T 3.3 | Non-compliance with IT security measures |
| T 3.9 | Improper IT system administration |
| T 3.38 | Errors in configuration and operation |
| T 3.114 | Incorrect administration during logging |
| T 3.115 | Incorrect selection of relevant logged data |
| T 3.116 | Lack of time synchronisation during log analysis |
Technical Failure
| T 4.89 | Lack of or insufficient alarm concept during logging |
Deliberate Acts
| T 5.20 | Misuse of administrator rights |
| T 5.71 | Loss of confidentiality of classified information |
| T 5.85 | Loss of integrity of information that should be protected |
| T 5.143 | Man-in-the-middle attack |
| T 5.176 | Compromising the logged data transmission during centralised logging |
Method recommendation
In order to be able to guarantee the security of the information system under consideration, other modules selected based on the results of the IT-Grundschutz modelling process must be implemented in addition to this module.
The logging services used can be both already integrated in an operating system and offered in separate software components. In order to protect the logging service and the stored logged data, the security of the underlying operating system must be guaranteed. However, this is not covered in this module. For this, the operating system-specific tier 3 modules must be implemented, first and foremost S 3.1 General server and S 3.1 General client.
A series of safeguards must be implemented for successful logging, starting with the design and purchasing phases and continuing through to the operation of the components. The steps to be followed in this case as well as the safeguards to be taken into consideration in the respective steps are listed in the following.
Planning and design
In order to implement a logging function in an information system, it must be planned how this function is structured technically and organisationally (see S 2.499 Planning the logging procedure and S 2.500 Logging IT systems). The questions of how a security concept can be drawn up (see S 2.497 Creating a security concept for logging) and how the access rights to logging services and logged data are assigned (see S 2.8 Assignment of access rights) are also part of the planning phase.
For centralised logging, it must be considered how the centralised logging server can be integrated into the network infrastructure of the information system (see S 2.499 Planning the logging procedure and S 3.90 General requirements for centralised logging).
Implementation
The administrators responsible must be trained regarding the corresponding methods, particularly regarding secure operation of a centralised logging server. This is described in S 3.89 Training on the administration of the logging function. Furthermore, an alarm being generated immediately in the event of security incidents is decisive for effective operation of an IT early warning. In this, it must be defined who is notified when and how notification is performed and which routes the alarms should use (see S 6.151 Alarm concept for the logging function).
Operation
The collected logged information may be analysed locally or on a centralised logging server (see S 4.430 Analysing the logged data). In the event of a centralised analysis, the logged information must be transmitted to the centralised server using the network. In this, the communication between the involved IT systems must be secured sufficiently (see S 5.171 Secure communication with a centralised logging server). Before the logged data can be analysed efficiently, it must first be prepared accordingly (see S 4.431 Selecting and processing relevant information for logging).
Disposal
If hard disks of logging servers are disposed of or deleted, it must be ensured that confidential and personal data is deleted completely. More detailed information can be found in safeguard S 2.496 Orderly withdrawal of a logging server from operation.
Contingency Planning
Within the framework of contingency planning, contingency plans should be drawn up for the relevant threat scenarios (see S 6.96 Contingency planning for a server).
The bundle of security safeguards for logging is presented in the following.
Planning and design
| S 2.1 | (A) | Specification of responsibilities and provisions |
| S 2.497 | (A) | S 2.497 Creating a security concept for logging |
| S 2.499 | (A) | Planning the logging procedures |
| S 2.500 | (A) | Logging IT systems |
| S 3.90 | (W) | General requirements for centralised logging |
| S 5.66 | (B) | Use of TSL/SSL |
| S 5.68 | (Z) | Use of encryption procedures for network communications |
Implementation
| S 2.498 | (C) | Handling warnings and error messages |
| S 3.10 | (A) | Selection of a trustworthy administrator and his substitute |
| S 3.89 | (A) | Training on the administration of the logging function |
| S 6.151 | (A) | Alarm concept for the logging function |
Operation
| S 2.8 | (A) | Assignment of access rights |
| S 2.64 | (A) | Checking the log files |
| S 2.110 | (A) | Data protection guidelines for logging procedures |
| S 4.225 | (Z) | Use of a logging server on a security gateway |
| S 4.227 | (C) | Use of a local NTP server for time synchronisation |
| S 4.430 | (A) | Analysing the logged data |
| S 4.431 | (A) | Selecting and processing relevant information for logging |
| S 5.9 | (B) | Logging on the server |
| S 5.171 | (A) | Secure communication with a centralised logging server |
| S 5.172 | (A) | Secure time synchronisation for centralised logging |
Disposal
| S 2.167 | (B) | Selecting suitable methods for deleting or destroying data |
| S 2.496 | (A) | Orderly withdrawal of a logging server from operation |
Contingency Planning
| S 6.96 | (A) | Contingency planning for a server |