Found an interesting blog post on configuring Graylog to detect threats. Hopefully the next posts they publish will do some follow up for actual threat detection and alerts: this first post is focused on normalizing data. This is an important part of initial configuration, as Graylog takes log files from various sources and they might be formatted in slightly different ways. As the example they use, when you start filtering data for something like a source IP address, you don’t want each log source to have its own naming convention (was that “src_ip” or “source_ip”?).
I’ve used Graylog a bit as part of a Blue Team Village CTF that was part of DEFCON 28. For a CTF event, everything tends to be pre-configured so you can use the tool as it’s intended, but I know that in some organizations, configuration and maintenance can be an obstacle. Making sure that fancy new appliance/application is sending data to your log aggregator is one thing, making sure you can actually use that data during an investigation is another.
Here’s a video by Recon InfoSec on their OpenSOC.io challenge, which covers basic use of Graylog, as well as Moloch:
I also found another good writeup of this challenge that goes beyond just use of Graylog, but also into what was needed to solve the various challenges posed by this OpenSOC CTF.
While the open source version of Graylog doesn’t have all the bells and whistles of the enterprise version, it’s still worth taking a look at as a basic SIEM solution.