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 the SentinelTrails audit log product 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 dedicated audit trail product 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.
SentinelTrails, for example, has a very flexible collector that can be configured to convert application-specific audit logs in various formats into a secure, cryptographically protected, centralized audit trail. And then it has a dashboard tailored to that audit trail, and not to the lowest common denominator of any log entry out there. The options that we present even drive the mindset of collecting a proper audit trail.
No tool solves all issues and unfortunately, tools that are claimed and perceived to do that distract security teams. “We have a SIEM” means for security almost as much as “we have a firewall” nowadays – yes, you have to have it, but that is just the beginning. Our customers are quite happy to see that they can augment their existing products with SentinelTrails, as we track events that have not been tracked before, and form a useful and secure audit trail based on them.