The foundations of accountability

In general, we can say that if someone pays attention to IT security, he or she is already familiar with the topic of logging and applies it as well; preparing to trace a possible data protection or information security incident. With the appearance of the European Union’s General Data Protection Regulation (GDPR), logging became even more significant, since the Regulation brought the super principle of accountability with itself, the compliance of which is ensured by logging into the IT system.

It can be concluded that we can take a big step by logging our IT systems based on a 10-point criteria system, to ensure that our IT security works properly in terms of accountability. It’s crucial that we know what our goal is and what conditions we want to meet. We have to see from which system or systems we want to collect logs, and of course, how we can do that in accordance with the law.

By operating logging based on a 10-point criteria system, we can take a big step forward in making our IT systems work properly in terms of accountability.

The 10 key points of logging

First, we need a logging policy, which covers the following:

• goals,
• scope,
• roles,
• leadership responsibilities,
• coordination between organizational units
• compliance,
• an agenda on how to facilitate the implementation of the logging policy’s procedures and control measures related to it

If the organization’s size and type do not require a separate policy or procedure, naturally, we can write our logging requirements into our IT Security Policy.

Events to log

Here, we briefly advise you to log what is required in the logging policy. First, we have to determine at what levels we want to do this. 

The following list may serve as a good base:

• operation system level,
• database manager level,
• application level,
• active network system level,
• the level of devices ensuring network security

Regarding events to be logged, this list can be of help to place our scope on what to log exactly.

Events to log on operation system level:

• successful logins and logouts (who, when)
• unsuccessful logins and logouts (who, when)
• creation, modification, and deletion of critical system files
• changes affecting the authorization system (creation and modification of authorization groups, creation and modification of new users and their possible assignment to new groups)
• changes in settings relating to operation system level logging, the beginning and the end of logging
• the creation, modification, or deletion of configuration settings in the operation system or in the applications installed on it
• the launching of access-providing applications and their circumstances

Events to log in database managers:

• successful logins and logouts in and out of the application (who, when)
• similarly, unsuccessful logins (who, when)
• the launching, stopping, or restarting of the database or its significant functions
• changes in the database (who, what, when, from what to what)
• changes affecting the authorization system (creation and modification of authorization groups, creation and modification of new users and their possible assignment to new groups)
• any changes related to database manager logging, the beginning and the end of logging

Events to log on application level

• successful logins and logouts in the application (who, when)
• similarly with unsuccessful ones (who, when)
• the launchings of parts of the applications (who, when, what) and unsuccessful launches
• changes affecting the authorization system (creation and modification of authorization groups, creation and modification of new users and their possible assignment to new groups)
• any changes related to application logging, the beginning and end of logging
• Here, data protection is a key factor – access and modification of personal data must be logged

Events to log on active network system level

• logins and logouts in and out from the configuration system
• unsuccessful login attempts into the configuration system
• configuration changes
• unsuccessful attempts to change the configuration

Events to log on network security devices

• logins and logouts in and out from the configuration system
• logins and logouts in and out from the security system
• unsuccessful login attempts into the configuration system
• configuration changes
• unsuccessful attempts to change the configuration

We can state that in the case of firewalls and IPS/IDS systems, we must pay particular attention to logging; we must do daily checkups in order to filter and handle information security incidents.

Contents of daily logs

It’s important to set our IT system logging requirements in a way that it collects enough information to see what events have occurred and from what or where they came. They must be eligible for later reconstruction of the events. 

Required space to store logs

We need to allocate sufficient storage space to store logs. We need to configure logging in such a way that we prevent the storage space from filling up.

Handling of logging errors

In the case of logging errors; or when our storage capacity is reaching its limits, the system must send a message to the system administrator, in order for us to respond to it.

Monitoring and analysis of logs, preparing reports

We have to review our logs regularly (daily or every 2 days) to look for signs indicating inappropriate or unusual activities. Unusual activities must be analyzed and sent to the relevant manager.

We need a notification chain in order to appropriately and quickly handle anomalies found in logs. We can log so many activities if we don’t review them regularly, it’s all in vain. If our budget lets us, we should implement a logging system with appropriate support; if it doesn’t, we need human resources to analyze logs – it greatly pays off in the future. Incidents that are otherwise unseen without log analysis can be easily filtered out and potential damage can be reduced.

Timestamps

Our IT systems must provide timestamps to generate log entries. Internal system clocks must be synchronized at every activity serving data requests.

Reservation of log entries

We need to determine how long we have to keep our log files (5 or 8 years) with particular attention to GDPR and other legislative requirements.

Summary

Of course, this blog article wasn’t written for those who want to set the logging of a financial organization up, but for those who want to lay down the foundations of logging and accountability at a small business. It’s worth considering all the checkpoints in the lists. With this, we can take serious steps to raise our cyber security to a higher level.

If we can be of help in establishing data protection compliance, or in reviewing your service or product, contact us!