Track Events You Have Not Tracked Before

There are a lot of products that allow collecting data, aggregating it, and displaying it for security or monitoring purposes. That includes SIEMs (Security information and event management systems), UEBAs (User and entity behavior analytics), log collectors, and catch-all multi-purpose data platforms (like Splunk).

And when you check what sources of data they support, it looks impressive at first – logs from hundreds of different network devices, firewalls, antivirus software, etc. They also support native OS logs, MS exchange, database logs. And it is often assumed that having collected all of that, you have a good enough audit trail.

Unfortunately, the reality is quite different – our experience in integrating our SIEM and its SentinelTrails audit log module shows that regardless of which of the above solutions (or a combination of them) is being used, there are always important events that remain uncollected, for a variety of reasons. And these uncollected events are often important for the completeness of the audit trail. There are three main reasons for these events to be skipped:

• The event collection tool does not support it – even though hundreds of devices and products are supported, they are usually just syslog messages in the various syslog formats as well as simple text files. But most of the software in use is not off-the-shelf network and security solutions – it’s custom business software that has its own ways of storing the audit log – custom database tables, oddly formatted text files, even compressed or single-line text files (e.g. SAP’s security log). And often there’s no dropdown in the SIEM – it just doesn’t collect that data. Sometimes things are supported through proprietary plugins for off-the-shelf software, which complicate the maintenance of that software and may introduce issues of their own.
• Not realizing they are relevant – take a SQL Server change tracking/change data capture, for example. It is a good audit trail and yet it is very rarely collected even if it is supported by the tools. Not to mention application-specific logs that contain auditing information and are known only to the application vendor. And while you may say that it’s the fault of the security or ops team to miss these sources, we’d say mass collection tools like SIEMs introduce a “source fatigue” – you know you are already collecting millions of often useless logs from all sorts of network equipment, adding yet another text file to collect may seem irrelevant. And in the context of a SIEM it may very well be – the accounting software authentication logs stored in a quirky tab-separated format won’t tell you anything about network intrusion. But they are a very important part of the organization’s audit trail. Mass collection tool shift the focus from pure audit trail to “anything that writes to a text file or syslog” and thus obscure the importance of the audit trail. And that often means these dashboards are overlooked or ignored, as they contain too much irrelevant information
•  

Sometimes even events that are collected are not sufficient for a proper audit log, because the relevant fields (e.g. actor and action) were not extracted. You may have the full line, but not knowing the particular format of the log leaves you guessing which one is which. And sometimes it’s non-obvious. And not extracting the actor makes it impossible to correlate actions from the same actor in multiple systems.

This is why we at LogSentinel believe that a SIEM with the feature set allowing focus on the audit trail, or even a dedicated audit trail solution is required for a security and compliance conscious organization. Relying on a generic “gather all that we could listen to via half-baked syslog messages” will fail once you need to rely on the audit trail.