Welcome to our three-part series, “Go from Reactive to Fully Proactive with Graylog.” This series is designed to help you handle the expanding volume and complexity of log data. Today, many people find themselves working in a reactive mode. Our goal is to walk you through how to become fully proactive, allowing you to reclaim time in your day.
Hello, I’m Jeff Darrington, Senior Technical Marketing Manager at Graylog. Welcome to this first session in the series, “Go from Reactive to Fully Proactive with Graylog.” In this first session, we’ll explore how to go from basic searches to setting up alerts and notifications. We’ll start with identifying a problem or issue in your network and discuss how to augment alerts with correlations to remove the noise and ensure that you only receive alerts that require immediate action.
At Graylog, everything starts with search. It’s the first step in asking questions and exploring data. When an issue arises—whether it’s a network problem, user account concerns, or even help desk tickets—search is where you begin. You might be part of IT operations monitoring network performance, security operations monitoring threats, or DevOps keeping an eye on application performance. Regardless of your role, search is the starting point.
From there, we’ll refine the search results to create alerts that are relevant to your needs. For instance, you can take an alert and elevate it into a correlation alert, making it more mature, methodical, and valuable for the on-call teams or a 24/7 SOC team to act upon.
Let’s dive into an example: monitoring user accounts for failed login attempts. We’ll use Windows event code 4625, which logs failed login attempts. After running a search, you’ll likely see a list of failed logins. The goal here is to narrow down the results and get actionable insights by creating a widget that aggregates this data.
To do this, we’ll create a widget and add various fields like event code, event source, username, and timestamp. This provides a clearer picture of when and where failed logins are happening. We can then save this search for future use and even share it with team members through various methods like instant messaging, Slack, or email.
Next, we’ll move beyond basic searches and explore the power of dashboards. These dashboards can be customized and parameterized for further investigations. For example, we could create a drill-down investigation dashboard that allows users to filter by usernames to see patterns over time.
After narrowing down potential login issues, we’ll set up event definitions for successful and failed logins. For instance, you could create a rule that triggers when there are five or more failed login attempts within a minute, or when a successful login follows a series of failed attempts. These events can then be correlated to detect brute-force attacks and other malicious activities.
We’ll set up notifications for these events using Slack, Discord, or even custom scripts. For example, by creating a Slack webhook, we can send notifications when potential brute-force attacks are detected.
In summary, we’ve taken a simple search, built alerts, created event correlations, and set up notifications. By following these steps, you’ve moved from a reactive approach to a fully proactive monitoring system within Graylog.
Thank you for joining this first session in our series. Let’s move on to the Q&A.
