Today we are releasing Graylog v2.4.5 to fix a few bugs. We have also fixed an Elasticsearch credentials issue found by Defence Logic Limited - thanks for finding this and responsibly disclosing it.

In a world where IT infrastructure becomes more complex with each additional layer, knowing what is happening in your infrastructure becomes more complicated every day.

In my last post, I gave a high-level overview how to select a threat intelligence vendor and how to integrate indicators of compromise (IOCs) into your SIEM or log management environment. In this post, I will describe in detail how to use the Threat Intelligence plugin that ships with Graylog. I’ll start with the steps necessary to prepare your data, then explain how to activate the feature and how to configure it for use.

The news is full of stories about the talent shortage in IT, especially in IT security. This shortage has created pressure on organizations to grow IT operations and to do that securely, all while having too few staff. Many are turning to threat intelligence to give their security analysts the tools they need to evaluate threats quickly and effectively. Essentially offering “Intelligence as a Service,” these tools enable organizations to benefit from the research of others.

Data is exploding. The shift to digital business is driving a massive expansion in the volume of data that organizations produce, use, and store. It is also accelerating the velocity of data—that is, the data is changing more rapidly than ever before. Which in many ways is great—more data can bring more insight into customers, markets, and opportunities. But more data can also be a problem.

If you run the audit daemon on your Linux distribution you might notice that some of the most valuable information produced by auditd is not transmitted when you enable syslog forwarding to Graylog. By default, these messages are written to /var/log/audt/audit.log, which is written to file by the auditd process directly and not sent via syslog.