How to build your SOC with Graylog

Graylog Central (peer support)
1

Hello All!

Please pardon me if this is a duplicate thread, but I am new to this community and new to Graylog.
I am starting a small project that aims to provide better visibility (from a security view point) and I want to use Graylog as the main tool for this. As mentioned I have had very little exposure so far to Graylog and to be honest I do not have too much exposure in general to other log repositories / SIEM solutions.

I would need help and guidance with the following:

  1. Defining the logs that should be send to Graylog - any advice on this?

  2. Defining the best use cases from a security view point that can be implemented - any advice?

  3. Putting the correlations is place - how do I do this? Any documentation that might help with this?

  4. Setting up alerting via e-mail or using a central dashboard to reflect the abnormalities - any documentation on how to approach this?

  5. Would you have any other suggestions on what else I should consider in the process of trying to build some SOC capabilities with Graylog?

Thank you for your help!

2

Hello && Welcome!!

A lot of what you are looking for can be found in Documentation and in the blogs pages. If you are going for a SOC and are getting serious about it, I would consider purchasing the full product to make sure things go smoothly!

3

I have a fairly solid experience with setting up SOCs centred around Graylog. As such, I’ll share a few thoughts below :

  1. Defining the logs that should be send to Graylog - any advice on this?

You should pull as many useful logs as possible from your environment, a good starting point is AD, Firewalls, Proxy systems, Windows Sysmon logs from servers and endpoints (consider Graylog’s Sidecar for this). The key here is to ensure the logs are parsed for relevant information like IP addresses and usernames, and that the fields where you store such information have coherent names. For instance, if you use “source_ip” as a field name for source IPs in Firewall logs, you should make sure the same field name is used across all other source IPs extracted from different log sources. Also, careful with log event volumetry, a limited amount of good/useful logs is better than terabytes of useless ones.

  1. Defining the best use cases from a security view point that can be implemented - any advice?

This is a broad question, but you can look at the Sigma project, which is an open source collection of threat detection use cases. If you have the time and the expertise, then I would recommend building your own use cases as Graylog Event Definitions progressively, and tuning down the false positives at the same rate.

  1. Putting the correlations is place - how do I do this? Any documentation that might help with this?

The correlation engine is a paid feature in Graylog. However, Graylog Open does come with enough power in its event definitions to cover most of the security use cases.

  1. Setting up alerting via e-mail or using a central dashboard to reflect the abnormalities - any documentation on how to approach this?

Both are feasible and well described in the Graylog documentation. For dashboards, you may search for existing Content Packs shared by the community, which you can import in your Graylog instance for inspiration.
Ideally, dashboards should serve two purposes :

  1. help identify thresholds for use case
  2. help analysts investigate alerts coming out of use cases
  1. Would you have any other suggestions on what else I should consider in the process of trying to build some SOC capabilities with Graylog?

Consider integrating Graylog with TheHive v4, which is an open source SOAR system that can help you better manage the alerts generated by Graylog, correlate and create cases. A word of caution though, TheHive 5 is no longer open source, and has a fairly limited free version.

Also, Recon Infosec have posted an awesome blog about Graylog pipelines and how they can be used to enrich logs and detect threats.

5 Likes
4

Thank you both for your input! :slight_smile:

5

I have nothing really to add to this. Sitting down beforehand and define field names to use across all streams is a big gain in the long run. I had this struggle once and do not want to fight it again.

Think about the resources to build up everything one by one. Don’t work on to many use cases the same time. Try to have little win-situations on the way while finishing one use case e. g.

My personal view is that content packs are of different quality. If the content pack is only available for an old Graylog version maybe take some inspiration out of it, but don’t rely on them as something fundamental of your setup.

6

I wanted to ad this post for Graylog Schema - It’s has good reference points for being consistent… particularly if you might move to the paid product in the future!

1 Like
7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.