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.