Gurucul Next Gen SIEM Reviews

For the majority of our use cases on the firewall, we are looking at the Ria website and multiple denials on the firewall. We'll also look at some C&C communication being initiated from multiple systems. That is one use case we are looking at. 

We have integrated the perimeter and internal application firewalls, along with endpoint protection, through cloud API integration. We have also integrated the vulnerability analysis and SIEM solution through API.

Initially, we implemented the McAfee SIEM. It was useful mainly for analysis. We moved away from that one due to analysis fatigue, and we went into a managed service with the SolarWinds platform, which Atos purchased. Gurucul is a 50 to 60 percent improvement over our previous solutions. Previously, we relied on the provider to perform the cases, but now we can establish whether traffic is growing, alerts are created, and the tuning we have to do. That kind of sophistication gives us great comfort in terms of what we are doing.

We have a low-security network because of the new premium controls we have implemented. We have endpoint protection, network detection and response, and good firewalling and hardening. Because of that, our environment is a low-security SIEM, but whatever we detect helps us understand what is happening in our network and how users behave. It enables us to be aware of what is happening. 

Context-driven risk prioritization is critical because we are also in the tuning process. We want all the security intelligence from different devices to establish the proper context. Based on what we have integrated, we are getting better info based on context, but we are still working with them to improve.

Without Gurucul, integrated threat detection would take five hours. We would work around in the background and not identify the threat. However, we have integrated endpoint protection and network detection, enabling us to see the current threats. The dynamic threats are always identified, but collecting logs to identify the orchestration process and distributed threat wouldn't be possible without Gurucul. It has reduced our mean detection time by about 40 to 50 percent. Gurucul gives us a 360-degree view of each user and resource, reducing the time required to respond by 30 to 40 percent.

I like the amount of customization we can do with Gurucul. We can customize each solution and evaluate it. We can investigate the alerts that it creates and fine-tune them to ensure that whatever is reported has some risk. With the enrollment of the group pool supporting us, we drastically reduced the number of false positives in the sense of internal productivity, admin activity, and browsing users. We have been able to do tuning that contributes to the alert traffic.

Gurucul can ingest from any source, but in terms of Windows systems, their model requires an agent to be installed. We haven't gone through that implementation because we wanted an Active Directory integration. However, Gurucul wants an agent to be installed for Active Directory, and our IT doesn't want the agent to be installed, so we requested that they create a connector specifically for the Active Directory. 

We have integrated all the security monitoring devices and performed API integration with cloud-based management for protection. It also allows integrating all the systems where the agent is installed to collect data. Now, we must get full visibility from the endpoint perspective and the NDR at the perimeter. It can come out with detections that deviate from the established term. 

You can apply in-depth analytics to your Snowflake data lake. Data lake is now consolidating the logs, which is crucial. We can run queries to identify threats. The group can provide a timeline of events that are happening. Because of the consolidation, we can see all the information in one place, and our investigation has become a single data view.

Gurucul's data enrichment could be improved. As a security professional, I want to consolidate all these log sources and data to the user, entity, or resource. More advancements are required, especially in enriching security data or attack response. I would like to see more improvements there.

The documentation could also be better.  Every user and resource has a timeline that lists all the events so we can analyze that particular system and what is happening. We would like to have an option where we can only list the confirmed security threat-related activities for a particular user rather than all activities. This way, we can see what kind of risk is reported for this user and be able to monitor them better. 

We started the POC in November 2023, so we have been using Gurucul for almost four or five months.

The only issue we had was with the vendor who had disabled a rule for some reason, so we got an IT error from the Gurucul on the day it was implemented. It has been running without any issues since we fixed that. 

You can easily scale up Gurucul because it's a SaaS solution. You can configure any number of load sources, and there's no log size. It's based on your requirement because we have a license for 10 GB per day. You can negotiate the amount of log recording with them based on your size. 

I rate Gurucul support eight out of 10. When we send a request, they respond the same day. 

Positive

We previously used McAfee. The main aspects we evaluated were the price and the amount of customization. Gurucul is a simple solution but still sophisticated enough to provide that next-generation SIEM that utilizes the ML/AI capabilities to automate, ensuring the manual processes are reduced. The amount of functionality built intoGurucul favors a small to medium-sized enterprise.

Deploying Gurucul was straightforward. When we implemented McAfee, it took two to three months to configure each collector. With Gurucul, we just provided the collector's IP address and installed the connector in 15 minutes. Beyond that, we sent the logs to the IP of the specific device and put that IP address to get the log status. It works immediately. The total implementation time was about half an hour. 

It's simple to deploy. One fear I had was integrating different log sources. We assumed it would take a lot of time based on past experience. I requested a three-month POC, but we were up and running within a week.

We listed our scope and whatever we integrated with the previous solution. When we began deployment, we implemented the cloud solutions first because that was easy. Then, we did whatever IT involvement was required, such as the perimeter and application firewall. Once we implemented the monitoring and devices, we focused on the Active Directory and Oracle database.

The ROI on Gurucul is very high compared to the other solutions we have implemented. It's around a 60 percent improvement in the amount of value generated for the same amount of investment. 

We evaluated Microsoft Sentinel and other solutions like QRadar but decided to go with Gurucul because of the cost and ease of use. It had the right degree of customization for our use cases and tooling. 

I rate Gurucul Next-Gen SIEM eight out of 10. I would recommend Gurucul to anyone because it provides almost all the SIEM features offered by the leaders at a low cost. You can achieve the sophistication of leaders like Spunk.

We use Gurucul Next Gen SIEM as our security incident and event management system. We are sending logs from our Citrix Informatics platform, which is hosted in AWS, for continuous monitoring of events.

The organization is ISO 27001 certified, and continuous monitoring is one of the requirements for that certification. That is why we started using Gurucul Next Gen SIEM.

We are sending logs over a secure connection to Gurucul's SaaS offering. They perform the analysis and other tasks in their data center, and we consume the results as a SaaS. It is entirely possible to have an on-premises solution like this. I can think of a couple of ways to do it, but I have not bothered to examine them because we are currently a SaaS company and do not operate our own data center. In fact, our entire enterprise is run on SaaS and PaaS.

Gurucul uses a next-generation SIEM system, which is different from a traditional SIEM in several ways. In a traditional SIEM, we send our logs to a collection point database and write rules to tell the system what to do when it sees certain log types. For example, we might write a rule to create an alert when the system sees a log entry for a failed login attempt from an IP address in a country where we don't do business. This approach requires us to know in advance what types of events we want to be alerted to. In other words, we have to write a rule for every type of event that we think might be suspicious. This can be difficult and time-consuming, and it's impossible to anticipate every type of attack that a malicious actor might use. In contrast, a next-generation SIEM like Gurucul uses machine learning to analyze the log stream and establish a normal baseline of activity. This means that the system can identify anomalies, or events that fall outside of the normal baseline, even if it has never seen those events before. For example, if a user from Tokyo normally logs in at nine AM their time, the system will learn this pattern and add it to the normal baseline. If the user then tries to log in from a different IP address or at a different time of day, the system will generate an alert. This approach to security monitoring is much more effective than traditional SIEM because it doesn't require us to know in advance what types of attacks we want to be alerted to. The system will automatically alert us to any suspicious activity, even if it's something that we've never seen before.

Gurucul helps us find threats that we were unaware of. This visibility is like the difference between an invisible intruder and one we have in the spotlight. At the end of the day, we cannot defend against what we don't know. But what we do know, we can make choices about what to do with it. It's that simple. It's what we cannot see that we don't know is happening. A traditional SIEM cannot generate an alert for a zero-day attack, which is a new attack that we may be the first victim of. This is because it doesn't have a rule to say what this new attack looks like. There's no way to generate that rule. In a next-generation SIEM like Gurucul, which analyzes the log stream in real-time, we can see that we have a new event. A human being can then be alerted to this event and analyze it further to determine the attack surface and what the attack is designed to do. We can add threat feeds and other things to our SIEM so that the latest information is pushed into it and we can write new rules. But we're always behind the curve on this. Someone has to see the attack, recognize it, analyze it, write a report about it, and give it to a threat feed. The threat feed then has to distribute this information to all of its customers, who then have to ingest it and write rules for their SIEM. Meanwhile, the attack may have already happened. With a next-generation SIEM, because it's analyzing the stream in real-time, we get an alert for new attacks because that's what the system is designed to do. 

Gurucul helped us reduce our detection time. It will be even better for us soon. We are currently engaging with an additional virtual security operation center provider, which will give us much more staff to look at anomalies. They are giving us the data we need. As we add the additional team of people to this issue, our detection time will realistically be real-time. If there's an anomaly, there should be somebody paying attention to the anomaly alert in the SIEM and reacting to it in real-time as well.

Currently, our MTTR is half an hour. Once we have the expanded team in place, and if we start seeing alerts that indicate that our security may be compromised, having 24/7/365 security operations personnel monitoring the dashboard will mean that it will be their job to pay attention to this all day, every day. This will be as close to real-time monitoring as possible.

Gurucul Next Gen SIEM has a strong technical foundation. The customization of reporting rules, reporting configuration, and alerting configuration are good.

The user interface could be made simpler. The truth is that there is such a shortage of qualified security professionals that customers who are not paying for world-class SOC services may end up with less trained, less experienced staff looking at the alerts and reports. This can make it difficult for them to tweak the reporting engine to properly identify what they are discovering and report it to the customer. I'm not sure if this is as much a Gurucul issue as it is a problem with the staff using the tool. However, the simpler the interface and the easier it is to perform basic functions, the better. I don't think this is something that is ever truly complete. The whole purpose of product improvements and constant iteration and development is to address these kinds of issues.

I have been using Gurucul Next Gen SIEM for ten months.

Based on our own specific situation, we do not yet have all of our log streams flowing to Gurucul. The set of data that we are sending them is quite complex, and we still have work to do to get the complete stream to them. Therefore, I am not yet looking at this as a complete solution that can be measured against what I would say is normal for the production environment. This is simply because I do not yet know exactly what this will look like once we have all of the logs flowing to Gurucul. Once we do, we will need to do a significant amount of tuning work. Eventually, we will reach a steady state, but tuning never ends. There will always be another type of log that comes in, and this is why if we expect to configure an SIEM in X number of days or weeks and then never have to think about it again, we are looking at the wrong tool. That is simply not how this works.

The scalability issue is how many logs we are sending. The number can certainly fluctuate based on activity, but when we are a business-to-business provider of technical services, the more customers we have and the more we grow as a company, the more logs we will be sending to our SIEM, even of the exact same type. Right now, we are sending quite a bit, about 100 GB per day, and this could grow exponentially.

The modular methods used in the SaaS operating philosophy require an elastic environment to be able to scale, and Gurucul has an elastic environment. This means that it may cost us more to throw exponentially more logs at Gurucul, because this increases their costs as well, and we would have to cover that. However, at the end of the day, our ability to scale these things has more to do with the architectural design we have employed.

In an on-premises solution, we have to think about not only the amount of storage we are adding but also the amount of computing power we need to account for to deal with the additional number of logs. When we run a SaaS, such as AWS EC2, we have elastic computing, which means that we can scale automatically and even on demand.

If we have a heavy set of logs that come out in a period during one day, on that day when the logs are at their peak, in an elastic computing scenario in the cloud, we can add more resources to that system until the load is diminished, and then remove the additional resources programmatically when we don't need them anymore. Gurucul is running this type of infrastructure. It is a SaaS with elastic computing at its core.

The technical team I work with is led by our customer success manager. A number of technical people from different disciplines will get involved in conversations as necessary, but the response to this is very good. I can pick up the phone and have those people on a call within 10 to 15 minutes. They are dedicated to finding a solution and are quite patient with frustrated technical people like me when things aren't working. I may have even abused that privilege by trying to find solutions to things that turned out to be my own fault. My impression is that the technical team is fantastic. We are all pushing the envelope here. We are introducing new streams of different types to bring them logs. We are also introducing formatting issues where if we change from one type of log format or log stream, and then send a different type of log stream formatting, the same data from those two different types of streams will appear differently. And if we don't account for the formatting, then it doesn't work. I know from personal experience working with the guys at Gurucul that we have sent logs in two different formats. And it took us a while to figure out why. The same log from the same application, but the mechanism we moved the log with was different, and that changed something. So they worked through it with us, and now we're all smarter for having to do it.

The technical team is doing a good job, but we haven't tried everything yet. I'm satisfied so far, but there's more work coming, and it's hard to say how they'll react to new tasks. Other than being professional, courteous, and responsive, I can't predict their technical expertise on specific subjects.

Neutral

We also use Datadog, which we are combining with Gurucul to cover the entire universe of things we need to pay attention to. From a security perspective, Gurucul is particularly useful for detecting anonymous events, such as those related to the use of applications and the behavior of users and administrators who are making changes. If we could figure out what these events are, we could write a rule for Datadog to alert us to them, but we are not currently spending time on this.

The IT and infrastructure folks who are responsible for the performance of our product use Datadog for performance alerting, system issues, and other similar things. They are not specifically looking at security items, but rather at whether the application is healthy and the underlying infrastructure is behaving as expected. They are also monitoring for network connectivity issues and computing power problems, such as CPU overruns and out-of-memory errors.

We could theoretically use Gurucul for these tasks, but since the Datadog infrastructure is already well-matured for this type of data, we have no intention of replacing it.

Deployment was not straightforward, but that is not Gurucul's fault. Small companies often have difficulty finding the resources to complete projects like this. Gurucul has quickly and efficiently done its part once we have provided them with the necessary resources, specifically the logs. Without logs, there is no data for them to analyze, so their tool is useless. Our company is fast-growing and customer-focused, which often means that our technical staff is overwhelmed and unable to deliver the logs as quickly as they would like, especially when higher-priority customer-driven events occur.

The deployment itself could be done by a single person who has the privilege to send logs and configure the screening mechanisms to get the logs from our systems to theirs. Once the system is in place, the purpose of SIEM is continuous monitoring. Traditionally, the absolute minimum number of people needed to run a 24/7/365 security operations center is seven. This is just considering the number of hours in a week and the need to cover vacations and sick time. Beyond that, a SOC organization typically has a dozen people to allow for additional tasks beyond simply monitoring the dashboard.

This can be expensive, which is why many companies are moving to VSOC providers. VSOC providers specialize in providing security monitoring services to multiple customers. They have the expertise and resources to provide 24/7/365 monitoring and response. When we hire a VSOC provider, they become our partner in interpreting the alerts and anomalies generated by our SIEM system.

If a VSOC provider is not authorized to make certain decisions, they will wake us up in the middle of the night or reach out to us via telephone or text message. If a situation occurs that they do not have a scripted response to, we will work with them to figure out what we want them to do and update the documentation so that they have clear instructions in the future.

It is important to note that SIEM is not a set-it-and-forget-it solution. It requires regular adjustments and tuning to ensure that it is effective in detecting and responding to threats. The only time we can stop tuning our SIEM is when we are deploying a new one.

The pricing is exceptionally good. I have personally implemented several SIEM solutions that are significantly more expensive. I won't name the companies, but one particularly well-known and expensive company was recently acquired by another corporation. There are many other offerings from leading security providers, and virtually all of them are significantly more expensive than Gurucul's solution.

Gurucul Next Gen SIEM is a seven out of ten for me, while all other SIEMs are five or fewer. I'm a tough grader. I don't have enough time spent with Gurucul yet to give them a higher score, but I expect them to earn it. I believe in their technology and in the work we're doing together, so I'm confident that their score will improve. However, I'm not easy to please. I don't give A's unless they're earned. Gurucul hasn't had a chance to earn an A with me yet.

Gurucul has not yet provided us with context-driven risk prioritization, due to our implementation of it. We have a lot of work to do. With any SIEM, the first step is to discover what is happening, make decisions about what it all means, and then determine what actions to take. The primary goal of using a tool like Oracle is to get accurate information so we can continue that analysis and determine our reactions. In some cases, there are obvious reactions, such as if we detect a user logging in from a country they have never logged in from before, at the opposite side of the clock, and they are failing their password or two-factor authentication. This log event is essentially saying, "Pay attention to this!" These types of events generate their own priority because of the type of attack they represent. As we add discovered new events to a category, we can say that we want an alert whenever we see them again. And if we see a user doing a certain thing and failing their password, we can disable the account. We can create an automated reaction to an alert. The action itself is not taken by the Gurucul SIEM, but by a system that we can program using the Gurucul SIEM to send a message to either a human being to disable the account, or to send a command to an automated system, such as an IAM controlling system, to disable the account. All of this is possible, and it is an integration beyond just discovering the alert.

We use Datadog, a traditional SIEM, and Gurucul Next Gen SIEM. I have run and examined many SIEMs in my career. I think that everyone in the SIEM business hopes that they are not missing much, but we know that we are. For security professionals like me, this is a constant worry. This does not mean that I am snoozing all day and eating ice cream because I am tough. It does mean that we expect to have more complete information and better visibility and to pay closer attention to anomalies because they stand out. In a traditional SIEM, if we do not have a rule, the system cannot alert us. We do not receive an anomaly alert, or any alert at all. Without a rule, the event is simply stored in the database, and the traditional SIEM has no reason to tell us about something for which there is no rule. The idea here is that we are moving away from having to predict the future and write rules ahead of time in order to see everything that happens. We all know that this is impossible in a traditional SIEM. Instead, we are analyzing all of the events that come across and determining whether the system recognizes them as normal behavior or as anomalies. We then have to decide what to do with these anomalies. When we first implement a system like this, there is a significant amount of work involved in identifying the things that are not on our normal baseline. We need to see these anomalies and decide whether they belong in the normal baseline or whether they should remain in an alert state. This is essentially a binary choice: either the event is an alert abnormality or it is not. Even if it is brand new, it may simply be a new application that has been applied, a new user who has joined our organization, or a new two-factor authentication mechanism that we are using. All of these things will appear as anomalies because the log stream will be different. When we have the opportunity to look at these anomalies, we then decide what they mean for our organization. This is work, and there is no getting around it. But by doing this work, we know that we are not missing that one event that could cost us our jobs or the jobs of everyone in our firm, or that could lead to a public disaster. If MGM had a system like this running when the person who broke into their systems and launched the ransomware attack used an account belonging to a real employee, they could have seen the anomaly of the person using those credentials from somewhere outside of MGM. They could have quarantined the account and prevented it from doing anything, and they could have defended themselves against the attack. MGM is definitely running an SIEM, but if it is not an SIEM that can catch anomalies and is only reacting to rules that have been written ahead of time, then it would have missed this attack anyway.

When implementing Gurucul, our first priority is to be prepared to get our logs into the SIEM right away. This is the most important thing until the SIEM is working because there is nothing to tune until it is actually seeing our log streams, examining the traffic, and doing the analysis. Any preparation and scheduling we can do with Gurucul to successfully get our logs into their system is absolutely essential. Once we have the logs in the SIEM, it is difficult to say which company will have an easier time tuning their SIEM. It depends on the number of unique events. For example, if our company only does one type of business with a simple set of operations, and has only a few authentication and login points and administrative tasks, tuning the SIEM would be relatively straightforward and could be done in a matter of weeks. However, if we are running a more complex environment with an SIEM, such as a typical Windows enterprise with on-premises and cloud systems for every possible system, like, email, file storage, applications, etc., tuning will take time and scale depending on how many people we have to review those systems, analyze the data that comes through, and determine how to handle it in our documentation. Tuning a SIEM is like tuning a guitar or piano. With a guitar, we have six strings to tighten or loosen to get them to vibrate at the right frequency. With a piano, there are 88 keys with three strengths for each key. The more strings or keys we have, the longer it takes to tune the instrument.

Things to consider before implementing an SIEM are, Do we have a normal baseline for logins? For example, do our people all show up at 9 AM every day of the workweek, and do they all log on to the domain authentication system and eight applications between 9 AM and 5 PM? How complex is our application structure? The more complex it is, and the more unique things our people do by department and/or user, the less we can predict what their login activity will look like. The challenge of traditional SIEM is that traditional SIEM relies on parsing rules. This means that we need to be able to anticipate all of the different ways that our users might log in and interact with our applications in order to write effective rules. This is difficult, especially in complex environments with custom applications, and traditional SIEM is not good at detecting anomalies. Anomalies are events that deviate from our normal baseline activity. Traditional SIEM is typically configured to look for specific known threats, so it may miss anomalies that are not on its radar. The Benefits of next-gen SIEM are that next-gen SIEM can detect anomalies without the need for parsing rules. This means that it can be effective in complex environments with custom applications, and next-gen SIEM can be more effective at detecting novel threats. Novel threats are threats that have not been seen before. Next-gen SIEMs can use machine learning and other techniques to identify anomalies that may be indicative of novel threats. Next-gen SIEM is a better choice for complex environments with custom applications and is also better at detecting anomalies and novel threats.

The good news about having a SaaS provider is that there is not much maintenance required on my side. However, if I send them new log sources, I will trigger some of the things that they have to do. For example, if I give Gurucul all of the applications I want them to monitor 24/7, and six months later, I have a new application, and we're going to send the logs from that one, they will have to do some maintenance. The logs from applications versus systems of the same type are significantly different. For example, if everything ran on a Windows server, then all of the events from the Windows server would be the same because they're a Windows server. However, in an application like a cartoon application, what the user does by calling shapes and colors and drawing and all of the things that we would do to make a cartoon are going to be significantly different than an accounting application. And so the log streams from those two things aren't from an application perspective and are not going to look the same at all. And so every time we introduce change, there's maintenance to do. For both sides, one is that the log stream from that particular application has to be analyzed to make sure that the language being used is understood. And that the mechanism to transport that language and log from the system we're monitoring into the SIEM service is successful.

At the end of the day, the difference between traditional rule-based SIEM and next-gen SIEM is the difference between signature-based antivirus and XDR. Back in the day when we were scanning files for known viruses, we could find some viruses because they were identified by an easy-to-understand hash that was applied to virus files. When the bad guys started adding characters to a known virus file and therefore changing the signature or hash, we could not discover those viruses anymore. This is because the thing we are expecting isn't there anymore. As malware has evolved, we now have polymorphic files. But most of those are simply a way to get our machine in contact with a command and control system that will then download whatever malware the attackers are trying to give us. So the analogy here is that the old style of signature-based antivirus isn't catching anything anymore because no one is sending something that we can have a signature for. It doesn't mean we're not getting malware. We're just not getting it that way, and that tool is no longer going to help us. If we compare that to SIEM, our use of a product depends on us knowing what is going to happen in the future. SIEMs are kind of crazy at this point. They simply cannot perform in the same way as a system that is designed to look at the stream of logs and analyze it to determine the difference between our normal baseline and an anomaly. If we think of this as being the same way as a signature, our normal baseline would be things we know about and have a signature for. All of the anomalies are things that we haven't seen before and can't possibly have a signature for. So the fact that Gurucul can discover those things and a traditional SIEM cannot is the difference between the types of products. There are other companies that are working on this, no question. There are a whole bunch of large companies that have lots of money to spend on research and development, and the proliferation of AI and language models, etc., is going to make this a crowded field soon. I believe that the difference that Gurucul has going for it stems from its CEO and founder, who is an expert in user behavior environments and has been responsible for a lot of the early development of this field. If we look at the science of examining the behavior of a user and understanding how to assign a definition to what we see a user doing, we see that this is at the core of what we are doing with SIEM. It is the ability to analyze an event and determine what it needs by doing an analysis rather than writing a rule. Gurucul has a huge advantage being first to market. I believe that there will be a crowded field in this relatively soon, but when we are first to market, we have the advantage of learning all of the challenges of doing analysis on these types of long streams. That advantage will continue sometime into the future as well.

We use Gurucul Next Gen SIEM for Security and monitoring against Cyber threats.

Our organization handles a significant amount of sensitive data, and in the current cyber landscape, protecting this data from theft is paramount. While firewalls and other security products are essential, they all have limitations. This is where Gurucul Next Gen SIEM comes in. Firewalls safeguard us against malicious websites and IPs, but hackers sometimes find ways to bypass these protections. This is where SIEM tools come into play. SIEM tools allow us to integrate critical devices for monitoring purposes. Organizations provide us with links to integrate with their SIEM, and logs are then routed through the SIEM. This is where the SOC analyst and team come in. They analyze the logs to identify incidents, block malicious IPs or URLs, and take action against suspicious user activity. SIEM tools can also detect malicious activities within the organization, whether initiated by employees or external actors and take preventive measures.

Gurucul Next Gen SIEM offers a wide range of predefined connectors that enable seamless data ingestion from diverse sources. With over 163 connectors available, Gurucul's flexibility extends to even the latest tools. If a new tool is released and a connector is not yet available, Gurucul's development team will promptly create and integrate the necessary connector. Additionally, Gurucul provides connectors for Azure and AWS, along with a comprehensive list of enterprise-level applications and servers. This ensures that connectors are readily available for a vast array of devices and platforms. In the absence of a predefined connector, Gurucul's commitment to adaptability guarantees prompt development and integration.

Gurucul helps us identify threats that we might not be aware of. It provides additional visibility through alerts and models. We can configure scenarios to customize the system's behavior. Based on these scenarios, we can tailor use cases to specific threats. For instance, we can configure a use case to detect botnet attacks against IoT devices. Since most IoT device attacks are carried out using botnets, this use case would alert us whenever a potential attack is detected. This would allow our SOC analysts to investigate and take appropriate action.

Gurucul's context-driven risk prioritization allows us to establish thresholds upon initial integration. For critical devices, we can define the desired risk score, enabling analytics to prioritize accordingly.

Without Gurucul, we will be unable to effectively detect and mitigate potential risks. This lack of visibility will make it challenging to identify and respond to emerging threats, leaving our systems and data vulnerable. In today's rapidly evolving cyber landscape, new threats emerge constantly, creating a growing pool of potential dangers. Without the protection offered by Gurucul, our systems are susceptible to attacks that could compromise sensitive information and damage our devices.

Our MTTD has been reduced. We have a script that runs on the backend and whatever data comes in the ML, the use cases run and it detects and pops up alerts for any issues detected. The solution will detect 90 percent of the issues automatically with only 10 percent for our SOC team to deal with.

Gurucul Next Gen SIEM is great for employees who want to start as SOC analysts, So it is good for those entering the domain of cybersecurity. This tool will help clear the basics.

Gurucul Next Gen SIEM is easy to understand, unlike some SIEMs that can be overly complex. While there are essential tools that require technical expertise, Gurucul Next Gen SIEM stands out for its user-friendliness, making it accessible to business users.

Initially, we were experiencing log delays. These issues have been resolved with the latest version. However, there are a few things that could be improved. If these are addressed, it would be a great tool.

When it comes to use cases, we would appreciate it if Gurucul could assign a unique alarm ID to each threat. This would make it easier for us to track and investigate threats over time. For example, if a botnet attack is detected and more suspicious traffic is observed an hour later, the system should create a new alarm ID for the second event, allowing us to clearly distinguish between the two incidents.

I would like Gurucul to identify the use cases that have already been reviewed by someone when detection occurs.

The technical support has room for improvement. They don't offer telephonic support.

I have been using Gurucul Next Gen SIEM for over one year.

Gurucul Next Gen SIEM is a stable solution.

Gurucul Next Gen SIEM is a scalable solution.

The technical support does not offer telephone assistance, which I think is essential. When technical support asks us what we have done, what procedures we have followed, and what buttons we have clicked, it can be frustrating. These basic questions seem unnecessary, especially when experienced individuals are involved and the issue requires urgent attention. Instead of resolving the issue promptly, technical support often asks irrelevant questions, which can be exasperating.

Neutral

Previously, we used IBM Security QRadar for one of our clients before migrating to Gurucul. At that time, we did not have our own SOC team, as we do now.

We are now monitoring Gurucul for our clients.

The initial deployment was straightforward. We had clear release notes to follow, which facilitated the process. The entire deployment was completed within a month. Three individuals from the vendor's side and two from our team were involved in the deployment process.

Based on the tool itself, the pricing is good.

I would rate Gurucul Next Gen SIEM seven out of ten. There are certain use cases where threats are not visible.

We have a team of six that use the solution.

Gurucul Next Gen SIEM is user-friendly for any SOC team.

Gurucul requires regular maintenance, such as model tuning and detection configuration. This includes updating IoCs and IP addresses daily. These updates can be filtered or applied selectively to specific components as needed for maintenance purposes.