In the regular operation of our applications, a large number of events are triggered and actions are carried out by our users. If errors occur in the application or if a security-relevant incident (for example, hacker attack) has taken place, it is essential for a successful post-mortem analysis to be able to trace the events that have taken place. For this purpose, the applications must document and log events and user interactions (logging). Please note what exactly should be logged and what is not (for example, due to data protection regulations).
6.1 What are the threats facing us and our customers?
|Security Incident Analysis: Missing Information and Accountability
If a security incident has occurred or there has been manipulation of our users‘ data, we need detailed information about the events that have occurred and the procedures in our applications and systems.
If this information is not available, incidents cannot be reproduced afterwards and the attribution of manipulations to our systems by an attacker is not possible.
|Problems with Error Handling: Error in the Application not traceable
If errors occur in our applications and customers contact us, support and development teams depend on as much detailed information as possible to quickly identify the cause of the fault (Root Cause Analysis).
In the case of the error search, log entries (log data) are an important source of information and enables us to accelerate the analysis of the problem.
6.2 What should we consider during development?
For our applications, it should be possible to understand when and which actions were executed by which user. This is especially true for multi-client-enabled applications and SaaS services.
· Incorrect login attempts
· Administrative logins and activities
· Changes to user accounts and permissions
· Errors in session management
· Errors during input validation
· Erros within the application (e.g., exceptions)
· Write accesses to data within the application
· Shut down, start and restart of applications or systems
The log entries should have a uniform format and, if possible, contain further attributes which are important for a subsequent evaluation or automated evaluation by SIEM systems:
· Severity (e.g., Low, Medium, High, Critical, Security, Debug)
· Client ID
· User ID
· IP addresses, HTTP methods and requested URLs (incl. parameters)
|Data Privacy and Handling of Personal Data
In logging, the applicable data protection Patterns must of course be observed and their requirements implemented. As a Pattern, users of the application must also be informed about the extent of the collected data (display of a data protection hint).
Furthermore, sensitive and personal data should not be recorded. These include for example:
· Encryption keys
· Health data
· Financial data (e.g., bank details, credit card data)
If sensitive and personal data have to be recorded in exceptional cases and after clarification of the legal framework, a pseudonymisation or the use of cryptographically secure hash methods is recommended.
6.3 Further Information
|Best Practices (=pattern) for logging:
https://www.owasp.org/index.php/Logging_Cheat_SheetInformation about logging with Spring framework:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.htmlInformation about implementing logging with .NET:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/loggingExemple guide to implement logging with .NET: