You are likely using a log collector – Graylog, Splunk, Loggly, logstash, logz.io, scylar, CloudWatch logs, etc. And log collectors are absolutely mandatory for any deployment of more than one machine (though they are very useful even in that case). They collect all your logs in one place, allowing you to search, “tail”, define alerts.
The contents of the logs
The contents of the logs being collected vary, but in most cases include application logs, access logs, database logs, OS logs. Application logs are the main candidate for collecting, whereas database and OS logs are sometimes omitted. And application logs can be noisy – exceptions (due to bugs or intermittent failures e.g. because of temporary network degradation or aborted client requests), program flow messages (“initializing class X”, “entering loop”, “executing request with values x and y”), framework logs (e.g. your ORM or web framework may be reporting on its functioning).
Sometimes logs can contain personal data as well as credit card data. This is either discouraged or outright prohibited, but nevertheless it still happens. Access logs may also contain sensitive information if you are passing data as GET parameters – for example, our team recently discovered and reported a serious security issue with one big software provider that exposed sensitive personal data through access logs. And log collectors have ways to protect you from these mistakes by masking known formats of sensitive data (e.g. credit cards).
Log collectors can function with a special agent installed on each machine by listening to changes in particular file (or other data source), or be directly integrated into the application code, e.g. using a logging framework plugin. Of course, they could also work as syslog endpoints.
And here comes the question of compliance – with PCI-DSS, ISO 27001, PSD2, GDPR, HIPAA, and many more standards and regulations that require certain things to be logged and kept for a period of time. Normally, log collectors are seen as “good enough” for compliance, and since they are already needed for operational tasks (e.g. analyzing production issues), they are often used to “tick” the compliance boxes. In more security-conscious organizations, copies of the logs are distributed to different locations, but that’s as far as it gets.
The problem with that is simple to understand, but not simple to solve – you can’t prove to anyone, be it auditors, the court, or customers, that you haven’t tampered with the logs. System administrators can’t prove to management that they haven’t modified the logs either. There’s reliance on a set or procedures which wrongly leads to the assumption that logs are not modified.
And this is risky. As many security consultants point out – companies often don’t realize this is a problem until disaster strikes. Then they have no way to tell what has happened, or whether someone hasn’t cleared their traces. The audit trail is a primary source for digital forensics and having it unprotected is not exactly the best practice.
LogSentinel SIEM - the combination of information security and compliance
LogSentinel’s main product – the LogSentinel SIEM and more specifically, its Sentinel Trails module – provides a cryptographically sound solution to that problem, unlike typical log collectors. We have based our product on the many of the mechanisms underlying blockchain technology so that you can have tamper-evident audit trail. It can also be proven to not have been modified, to internal or external parties.
Note that we don’t aim to replace log collectors – they have their purpose for application monitoring and they are good for that. LogSentinel SIEM, on the other hand, collects the security portion of the logs and protects their integrity, thus complementing log collectors in large organizations. How to do that? We have integration packages for most popular log collectors, but the important bit is the option to filter the noise and focus on business-relevant logs. No auditor would care that you had an I/O exception while trying to write a file, or that the if-clause on line 452 has evaluated to “true”. But they will care if user John Smith has clicked the button “Delete document”, especially if the document used to contain important information.
This is another important aspect of LogSentinel SIEM complementing log collectors – it makes you actively think about the audit trail. The audit trail is not just a bunch of application and database logs. It is “who did what when”, and if you don’t store that information in logs or in the database, you don’t have a real audit trail. And yes, you may be storing the audit trail completely separate from your regular logs (e.g. in a database) – LogSentinel SIEM can be attached to that as well.
In conclusion, LogSentinel SIEM complements log collectors in order to provide security monitoring and a real audit trail. We don’t aim to replace log collectors, but to help you achieve higher levels of security and compliance, by plugging to your existing logging infrastructure. If you already have Splunk, Loggly, Logstash, or any other log collector, you can simply integrate us for improved security.
Request Demo today and see how LogSentinel SIEM works:
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
