TeamSHATTER

Database Logging Basics For The Secure DBA

Building a secure system requires employing multiple processes, tools and techniques. This post will take a look at how to properly configure a file-based logging process.

 Logging is the process of collecting information that details what events took place on the system or what state the system is in. Logs are absolutely necessary to establish accountability, investigate system disruption, monitor for unauthorized activities, determine the extent of the damage inflicted as result of an attack, trace the source of the attack and prove your findings during prosecution. As a result, logging is one of the essential components in a proper computer security setup.

On most systems, configuration of logs is dictated by security policies with which the organization has to comply. Sometimes it is laws or industry regulations that dictate those policies and sometimes those policies are internal to an organization. Financial or medical industries and the military are among those which have government-enforced policies. Even if an organization doesn’t need to comply with anything, they should still implement logging in a proper way to protect their business.

While designing and configuring file-based logging on a system, there are a number of things that have to be taken into consideration:

1.         Restrict permission to read log files
2.         Restrict permission to change or delete log files
3.         Collect only necessary and relevant logs
4.         Use as little resources as possible
5.         Store log files at a dedicated and easy to find location
6.         Include logs in regular backups
7.         Store logs in multiple locations
8.         Start logging automatically after system starts
9.         Configure rollover of logs
10.       Have system in place to interpret logs
11.       Implement an automated tool to monitor audit data and report suspicious activities
12.       Review logs regularly

Restrict permission to read log files

Log files often contain sensitive data, such as configuration of the system, system resources or business transaction details. That information may be of interest to attackers. Strict access control policies should be implemented to allow only required individuals to have read access to the log files. In certain situations, it may be necessary to implement encryption in addition to access control. That would provide an extra layer of protection and safeguard data at rest.

Restrict permission to change or delete log files

Well configured log files should collect all necessary information to help resolve errors, monitor important events on the system, and if necessary, help to piece together events that took place earlier. It could contain sensitive information that should not be changed or removed.  

It is a common practice for attackers to try to remove all traces of their activities, to avoid being discovered for as long as possible. In pursuing that goal, attackers often try to remove or edit log files. Write and delete rights to log files should be restricted, allowing control only to administrators and security personnel.

Collect only necessary and relevant logs

While it is tempting to collect all of the generated information possible, this should be avoided. The flood of data will make it hard to find required information. With the ever-increasing amount of information passing through systems and therefore ever-increasing number of events taking place, systems can generate huge amounts of log data. The goal is to collect all the needed information and at the same time not to drown in data that is not important. This is done by carefully evaluating sensitive data, and important events on the system to be logged.

Use as little resources as possible

Logs are viewed as important only during unusual incidents. At all other times, they are considered, by most players in the system, unnecessary and resource consuming. In many situations, when collecting logs consumes too much disk space, too much CPU power or too much of other resources, it is getting downgraded or turned off completely. To keep users of the system happy and protect the system at the same time, log collection should be carefully configured and tweaked.

Store log files in a dedicated and easy to find location

Log files should be collected in a few dedicated, organized locations which are easy to find and easy to protect.  

While some systems by default store log files in multiple locations which are distributed throughout the system, it is recommended to configure logs to be collected in a few locations. Well organized, centralized log collection will speed up the process of finding and retrieving necessary information when it is required. A small number of locations that contain logs simplify the task of securing and maintaining them.

Include logs in regular backups

Logs should be stored for a specified amount of time after being collected. Time of preserving logs varies greatly depending on an organization’s internal policy and security policies with which they are required to comply.  

Backup log files should be protected and stored in the same way as other sensitive data backup is being protected and stored. That includes encrypting, writing on read-only media and storing it at remote location.

Store logs in multiple locations

While logs are being collected, they should be stored in multiple locations simultaneously. At least one copy of logs should be stored remotely. Storing logs remotely will prevent tampering with logs by privileged users of local system. This is one of the ways how local privileged users are being kept accountable.

Start logging automatically after system starts

Logging should be done continuously, starting from the moment system starts. It should not rely on the manual start because it requires constant human attention and is not reliable. If logging is configured to be started manually, the attacker could turn it off by restarting the system.

Configure rollover of logs

On some systems there is a limitation of the size of log files. That should be taken into consideration while configuring the system.

 There are few choices that are given to deal with that situation: the system can turn off logging, the system can be shut down, the new log file could be created or old log files could be overwritten. The acceptable solutions for this problem are to automatically create a new file when an old file is full or to turn off the system as soon as the size limit of logs is reached.

Actions specified above will help to make sure that logs are collected throughout the entire time when the system is running. It is not recommended to let the system run without logging while being active because during that time the system would not provide accountability.

Have system in place to interpret logs

Some logs are stored in a format that makes it hard for a person to read and interpret them. It is very beneficial to have a tool in place to simplify those tasks.

The amount of data collected in logs makes it extremely unpractical to review all of it manually, unless you are looking for something specific or know the system very well and can spot new patterns. The proper way to deal with that problem is to employ intelligent tools that can interpret and analyze logs, indicate association between entries and highlight the most important parts in them for further manual review.

Implement an automated tool to monitor audit data and report suspicious activities

Automated tools provide the fastest notification time, giving almost real-time alerts about suspicious activities. The sooner attempts to breach system security are identified, the better the chance that system can be effectively protected. Prompt identification of a successful attack would allow security personnel to lower the possible damage, increase the chances of identifying the attacker and preserve evidence.
           
Review logs regularly

Collecting logs and generating alerts will not prevent or identify an attack unless those logs and alerts are being examined. Constant review of results generated from automated tools, as well as scheduled manual review of logs have to be performed regularly to make sure that suspicious activities and patterns are not missed.

With each passing day, our reliance on technology increases, more sensitive data makes its way to digital format and the number of attacks that involve technology are rapidly growing. It is not acceptable any longer to ignore the possibility of cyber-attacks or to allow extended system downtime as result of unexplained and unreported errors. The price of that negligence could be dramatic, if not deadly for companies. In most situations, worst case scenarios can be avoided by paying adequate attention to proper logging and auditing.

Every company must have internal security policies that incorporate logging guidelines. Implementing points specified above will elevate accountability on the system, help resolve unusual errors, allow better auditing and also improve the way of identifying and responding to attacks.