Information Security Breaches? - Security Event Sources to Blame

Feeling insecure about your security system? Even a state-of-the-art SIEM application may not reflect what’s actually happening in your network. Sometimes, the root of such malfunctions lies in the domain of event sources, namely in log sources and event data quality issues.

The following article gives an insider view of SIEM challenges from the perspective of IBM Security QRadar SIEM (however, it’s applicable to any other SIEM system).

Keep vigil over your log sources

The following sections list the types of problems that may happen to log sources and cause considerable trouble.

Unidentified or incorrectly identified log sources

Every SIEM system normalizes the data collected from log sources according to the single set of event attributes, such as time, user, operation, IP and so on. The range of these attributes in the out-of-the box solution is limited. Nowadays, a lot of applications, especially business ones, are not supported by QRadar. When it receives logs from some source but can’t detect what type of logs it is receiving, it can lead to missing potential threats. In such cases cybersecurity companies install custom LSX (Log Source Extension)/uDSM (Universal DSM).

Inactive log sources

There are cases when log sources are deactivated manually, for example, if an admin turns off audit by mistake or if driven by malicious motives. Hence, at some point of time the SIEM system won’t get any data from the device. For this reason, SIEM systems track manipulations with audit switching.

Sometimes, a drop in the number of active log sources may also indicate that some devices have just dropped off the network or got switched off.

Disabled log sources

This malfunction is human-dependent and can’t happen without the security administrator’s interference.

QRadar has a list of log sources on the admin panel. On the one hand, log sources can be detected automatically if a network device sends data to QRadar (a passive variant). On the other hand, administrators can configure it manually. QRadar initiates connection to a target system and then receives necessary data (an active variant). Log sources can be disabled for various reasons: malicious behavior, such as human mistake, the administrator’s evil intentions; or a normal process, when a certain device is no longer relevant. As opposed to the case with inactive log sources, the administrator disables them in QRadar, not in a target system.

Deleted log sources

Once deleted, a log source can’t be restored. If a source that triggers data sending was deleted, QRadar can trace and indicate this. This information is useful to see if any critical log sources are missing. If we delete a source that was added to QRadar manually, it will vanish without a trace unless QLEAN is installed.

It should be mentioned that the most common malicious reasons of deactivating, disabling or deleting log sources are spying, quick financial gain and stealing intellectual property.

Protocol configuration errors

A source protocol configuration may be stopping events from being collected. With active data collection, QRadar requires a correct user name and password, and if the administrator fails to provide the correct credentials, the log source falls into the error state. Therefore, it’s essential to ensure that all log sources are correctly set up, that is by verifying authentication fields, file paths, database names for JDBC (Java Database Connectivity protocol) and ensuring that the SIEM system can communicate with remote servers.

Modified log sources

In the normal course of work, log sources are not expected to be modified, thus every modification is suspicious and should be audited. A log source stops getting messages in case of a typo in an IP address. Unfortunately, a lot of IT administrators don’t have well-defined baselines on normal activities in the network, which makes it hard to detect abnormal ones. Verizon Data Breach Investigations Report recommends to pay close attention to proper control over network changes for data breach prevention.

Log data quality well in hand

Another set of problems to focus on is event data quality, namely unsupported and unreceived events.

Unsupported events

When the event name parsed in the event message does not match any of the mappings known to QRadar, the QRadar event viewer will show them in the “unknown” category, which turns the event into nothing but a dummy weight. Similarly to the case with unidentified log sources, custom LSX/uDSM help to address the challenge, allowing to extend the parsing routines in your SIEM.

Unreceived events

This problem may occur in case of insufficient licensing of a SIEM system. Your current version may consider certain event types out of the license scope, consequently the number of supported events won’t correspond to the total number of events.

The same may happen when SIEM is adjusted to track only successful system entries, thus the number of "seen" events will be less than that of the supported ones. The latter event types can actually be enabled for your device and are important from the security standpoint.

Something to keep in mind

Spying, financial gain and stealing intellectual property are only a few motives behind security offenses. If overlooked or neglected, the wrong configuration of log sources and events may be the culprits of security breaches. The only way to ensure a solid security protection of your entire network including log sources and events is to check SIEM implementation health regularly, for instance, with the help of QLEAN for QRadar.