LOGINSTATISTICPERIODDAYS - Detailed description

Overview

Parameters:LOGINSTATISTICPERIODDAYS
Category: Login
Default value: 30
Product: eTASK.Login

What does this parameter do?

This parameter sets the retention period for login statistics in days. The system creates a data record in the database for every login attempt (successful or failed). The parameter controls how long these data records are retained before they are automatically deleted. If the value is 0, the data is not deleted and remains permanently in the database.

What is this parameter used for?

• Security monitoring by logging all login attempts to detect suspicious activity

• Forensic analysis of security incidents using historical login data

• Compliance and auditing to meet regulatory requirements for logging user logins

• Analysis of user behavior and login patterns to optimize system availability

Technical Details (for Administrators)

Format: Integer
Default value: 30

Valid values:

• 0 = No automatic deletion - permanent retention of login statistics

• 1 up to 999999 = Number of days after which login statistics records are deleted

Important notes:

• Data is collected automatically with every login attempt (successful or failed)

• Each record contains information such as timestamp, username, success/failure, browser information, and login method

• If the value is 0, login statistics are stored permanently

• Old records are purged via a time-controlled process in the system

• The retention period is calculated based on the creation time of the data record

Interaction with other parameters:

• KEEPLOGSDAYS: Controls the retention period for log files in the file system, while LOGINSTATISTICPERIODDAYS applies only to login data

When should you change this value?

Leave the value at 30 (default) if:

• Standard security and compliance requirements are sufficient

• There are no specific regulatory requirements

• Standard security analyses are performed within one month

Increase the value to 60–365 if:

• There are heightened security requirements in regulated industries (finance, healthcare)

• Legal or contractual compliance requirements mandate longer retention periods

• Security incidents are often detected only after a significant delay

• Detailed quarterly or annual reports on login activities are generated

• Forensic analyses regularly go back several months

Set value to 0 (permanent storage) if:

• The strictest audit requirements demand a complete history

• External compliance regulations do not allow for a time limit

• Manual or external archiving processes are in place

Set value to 7–14 if:

• Login statistics are primarily needed for current monitoring

• External SIEM systems already archive the data long-term

• GDPR data minimization is the highest priority

• A very high number of login events occur daily

Important Notes

1. GDPR compliance:
   The retention of login data containing personal information must be weighed against legitimate security interests. Document the legal basis for the selected retention period in your record of processing activities.

2. No retroactive adjustment
   A change to this parameter only affects future cleanup operations. Existing data outside the new retention period will be deleted during the next cleanup run.

3. Coordination with log files
   For a consistent audit strategy, this parameter should be coordinated with KEEPLOGSDAYS (retention of log files). Both parameters cover different aspects of logging.

Security

Does changing this parameter affect security?

Yes, this parameter has a direct impact on system security.

Positive aspects:

• Enables detection of attack attempts by logging failed login attempts

• Supports forensic analysis following security incidents

• Creates an audit trail for compliance documentation

• Helps identify brute-force attacks and suspicious login patterns

Note:

• Retention periods that are too short can destroy important evidence of security incidents

• Excessively long retention periods increase data protection risks due to unnecessary data storage

• If set to 0, personal data can remain in the database indefinitely

• Deleted statistics are no longer available for subsequent investigations

Data protection assessment:

• GDPR principle of storage limitation: Data should not be retained longer than necessary

• A balance between legitimate security interests and data protection is required

• Personal data in login statistics must be deleted after a reasonable period of time

• Documentation of the retention period in the record of processing activities is required

Recommendation: Choose a retention period of 30–90 days for standard environments. This provides sufficient time for security analyses. Avoid setting the value to 0, except for compelling compliance reasons. Ensure that the retention period aligns with your privacy policy.

Practical example

Initial situation: A medium-sized company with 500 employees uses eTASK with default settings. Following a GDPR audit, the data protection officer demands that retention periods for personal data be reduced to the absolute minimum. At the same time, following a security incident, IT security requires longer retention periods for login statistics for forensic analysis.

Conflict:

• LOGINSTATISTICPERIODDAYS = 30 (default)

• Data Protection Requires: Reduction to 14 days (data minimization)

• IT Security demands: Increase to 90 days (following an incident, it was determined that suspicious activity was not detected until 6 weeks later)

• Minimum compliance requirement: 30 days for internal audits

Decision: After weighing the interests, the company sets the value to 60 days.

Rationale:

• Experience shows that security incidents are detected within 4–6 weeks

• 60 days provide sufficient buffer for delayed analyses (vacation, illness)

• Justified under data protection law by a legitimate security interest

• Documented as "necessary for IT security and compliance" in the record of processing activities

• Balance between data minimization and security needs

After the change:

• Login statistics are automatically deleted after 60 days

• IT Security can access data for analysis for up to 2 months

• Data protection authorities accept the retention period as reasonable

• Monthly security reports can use complete data

• Compliance requirements are met

Result: The 60-day rule creates a workable compromise between the conflicting requirements. The company documents this decision transparently and reviews it annually as part of the data protection impact assessment.

Alternative scenarios:

Scenario A - Financial institution with strict regulations:

• LOGINSTATISTICPERIODDAYS set to 365

• BaFin requirements mandate one-year retention of all access logs

• Data protection takes a back seat to regulatory obligations

• Annual external audits verify complete login history

Scenario B – Startup with an external SIEM solution:

• LOGINSTATISTICPERIODDAYS set to 7

• Login data is transferred daily to an external Security Information and Event Management System

• SIEM system handles long-term storage and analysis

• Local database contains only the current week for operational purposes

Recommended setting

For standard installations:30(Days)

Reason:

• Strikes a balance between security monitoring and data protection

• Corresponds to typical response times for security incidents

• Meets standard compliance and data protection requirements

• Gives security teams sufficient time for analysis

Important: Never set the value to 0 in production environments unless you have a clear compliance requirement. If set to 0, you assume full responsibility for data protection compliance.

Tip: Monitor the actual use of historical data for security analysis during the first few weeks after a change. Adjust the value as needed. Document the selected retention period in your privacy policy and coordinate with your data protection officer.