Pattern 6: Think about the Appropriate Logging of Events

vPierre Sicherheit / Security, Software Development, WWW Leave a Comment

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?

Audit Trail

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.
At least the following events should be documented and tracked:

·      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

·      Timestamp

·      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:

·      Passwords

·      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:
https://msdn.microsoft.com/de-de/magazine/mt694089.aspx

https://www.gronau-it-cloud-computing.de/10-pattern-for-secure-software-development/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.