Elastic Security Reviews

We do not use monitoring due to the fact that we use Prometheus for monitoring. We don't use APM and so on. We use ELK only for logging.

The solution has very good logging functionality. 

The aggregation capability is quite useful. 

The solution is quite stable. The performance has been good.

The solution scales well.

The solution has gotten easier to deploy since the 2019 version.

Using ELK the first time there was a lack of security. We had to buy the paid version due to the fact that we needed to secure access to Kubernetes.

The problem with ELK is it's difficult to administer. When you have a problem, it can be very, very difficult to rebuild indexes. In fact, you have to monitor the stack and it's very, very difficult. Sometimes we lose indexes or we have nothing on the dashboard.

I've been using the solution for about two years at this point. It hasn't been an extremely long amount of time.

The solution is stable. It's reliable. There are no bugs or glitches. It doesn't crash or freeze.

The solution can scale. If a company needs to expand it, it can do so pretty easily.

We use the solution for quite a small team. Ten people work on it.

Due to the fact that we have a paid version of the product, technical support has been fine. We've been satisfied with the level of service provided to us. They are quite helpful and responsive.

Previously, we were on Datadog, Kubernetes Logs. It was not very easy to debug incidents and so on. If I had to compare, I'd say that Datadog is very easy to implement and it's such a fast solution.

The first time, it was very hard to deploy on Kubernetes. However, as we reached version seven, they are now an operator. Now it's very easy to deploy. We no longer have any issues.

The solution is a bit expensive. I don't know the pricing of Datadog, which is what we used to use, however, it's my understanding that it is very expensive also. 

We are a customer and an end-user. We do not have a business relationship with ELK.

The solution is deployed on Kubernetes in Azure.

I would advise other companies and users not to mix monitoring and logging. It's not the same purpose. Many people do monitoring by scanning logs. It's not a good idea. The good idea is to monitor separately. In case of incidents, you have to monitor metrics and logins for the root cause. It's important to separate this, and not treat them as the same thing.

I'd rate the solution at an eight out of ten.

This is a log aggregation tool and we are using it for security purposes.

There are 145 pre-built use cases, but we are still making some ourselves. One we built is an alarm for log deletion. For example, if a hacker tries to delete the log from a bank machine then it will raise an alarm immediately. A second use case is an alert for too many false login attempts, perhaps indicating a brute-force attack.

The most valuable feature is the speed, as it responds in a very short time. I think that the alerts are generated in less than a minute.

It is very easy to set up and doesn't take much time.

There are sensors called beats that have to be installed on all of the client machines, and there are seven or eight of them. As it is now, each beat needs to be configured separately, which can be quite hectic if my client has 1000+ machines. It would take a considerable period of time for us to complete the installation. They have begun working on this in the form of agents, which is a centralized management tool wherein all beats will be installed in a single stroke.

The training that is offered for Elastic is in need of improvement because there is no depth to it. It hardly takes 15 or 20 minutes to complete a training session that they say will take two hours to finish. Clearly, something is missing. If a new engineer wants to work with Elastic then it is really very hard for them to understand the technology. 

I have been using Elastic SIEM for two or three months.

This is a stable system and it has never crashed.

Elastic SIEM is definitely stable. We have just started working on it, so we have no more than perhaps 100 users at this point. At the same time, we are confident that it can be scaled up to any extent.

I am satisfied with the technical support.

The initial setup is easy. The length of time for deployment on a machine depends on the configuration that is required. If it uses all 145 use cases then it will take a long time. If on the other hand there are only a small set of use cases, it will be very quick. I would say that it takes no more than 30 minutes to install one.

I have personally worked with Splunk in the past, but here at this company, they only use Elastic. I believe that one of the major differences between these two is the pricing model. With Splunk, it depends on how much data we are ingesting. For us, it is approximately 500 GB per day. Elastic has a different pricing system that is ultimately cheaper.

One of the advantages of Splunk is that they offer extensive training that is free of cost.

My advice to anybody who is considering this product is that it is a very competitive tool that is very new in the market and the vendor is doing their best to improve services. I highly recommend it and suggest that people choose it without a second thought.

I would rate this solution an eight out of ten.

The product has huge integration varieties available. 

The tool needs to integrate with legacy servers. Big companies can have legacy servers that may not always be updated. 

I have been working with the solution for the last eight months. 

The solution is scalable and flexible. My company has 20 users for the product. 

We had relied on in-house support initially. However, we understand now that there are a few areas where we need to have vendor support. So we have contacted a few different companies and contractors for it. In the beginning, it may be possible to do support in-house. However, if you have a lot of commercial production environment services, then it is very hard to do without vendor support. 

We decided to use the solution because it was a very promising tool and other alternatives had limitations. The tool has availability, data infrastructure, data uptime, etc. The solution is quite flexible in terms of cost. You don't need to buy a license for each and everything. Whenever you require a license, you can just buy it. I think these are the two main drivers. The product is quite open in terms of integration with machine learning which helps us with proactive monitoring. 

The product's initial setup is very easy. I think the most important point is how you design your infrastructure because the solution is quite open. So you have to design it based on the nature of the data. You also need to get a life cycle so that there is no load on the storage. The solution's flexibility depends on how you design it. 

The tool's pricing is flexible and comes at unit cost. You don't have to pay for everything. 

I would rate the product an eight out of ten. You should use the solution if you want to have a very detailed machine-learning artificial intelligence. However, for certain production licenses, you need to prepare. It is open to different configurations and can just fit according to your requirements. This is one of the solution's good parts. 

Basically, we are using this product for monitoring and for developing the processes for our company.

I like that there is a knowledge base. There's the possibility for technical people to develop this product and to know much more. However, they do not need additional certifications from the vendor side or to pay a lot of money for their courses and certifications. We don't need to rely on vendors. We can handle the product ourselves. 

It's open-source and free to use.

The solution isn't really recognized in the market. They need to do a better job when they are marketing the solution. We'd like customers to have more visibility of it, and we'd like them to see how secure and highly effective it is. There needs to be more brand awareness. 

We have faced some obstacles when handling the implementation process. 

There are no templates available when integrating with other products. We sometimes need to find some workarounds. 

We'd like to see some more artificial intelligence capabilities.

I've been using the solution for four and a half years. 

The solution is stable and reliable. We found the product to be very usable. There are no bugs or glitches, and it doesn't crash or freeze. 

The solution can scale. Integration with other products may be a bit difficult, yet it is doable. 

If we need assistance, we tend to use the community. There is always somebody in the world who can help us if we have a question. There are many people that can provide good tips and useful advice. Typically, many people have faced the same problems and they can help us solve things. 

I'm also aware of Curator. 

Compared to Curator, customer awareness isn't as strong. From the price perspective, this product is better, however, many customers don't want to change their own CM and their products if they already have something in place.

The initial setup wasn't overly complex or difficult. That said, it wasn't simple either. It's somewhat moderate in terms of implementation.

I'd rate the solution three out of five in terms of ease of setup. 

This is an open-source solution. It is free to use. 

For new customers, this is a perfect choice. For older customers, it's very difficult to change solutions.

I'd rate the solution eight out of ten.

We use Elastic Security to manage logs and time series data. More recently, we have used it for NetFlow data. 

We like Elastic Security because it's a REST API-based solution. That's the primary reason we use it. 

I would like more ways to manage permissions and restrict access to certain users. 

We started using Elastic Security four years ago. 

The setup is comparable to similar products. It isn't too easy or hard. We deployed it in-house. 

We tried Graylog and a few other things, but I found Elastic Security is easier to understand. There's a lot of documentation available, and their forums are great. Another advantage is greater scalability. 

I rate Elastic Security nine out of 10. 

ELK Stack is made up of Elasticsearch, Logstash, and Kibana. What we have is considered modified ELK Stack where instead of the Logstash we use Fluentd, but it serves the same purpose as basically a pipe to get the data into the Elasticsearch.

We primarily use the solution for everything you could think of from error detection to general logging and auditing, to security awareness.

Recently I started using some Kibana alerting, which is in the latest versions of Kibana. It's very helpful in general.

You can't beat the price as it is basically free. There are also a lot of features on offer.

We've found the initial setup to be quite straightforward.

The stability is excellent.

Sometimes, the solution isn't the easiest to use.

The solution probably doesn't have all of the advanced machine learning like some other SIEM providers have right now. It's something that could be improved upon.

I've been using the solution for three or four years at this point. It's been a while.

The stability of the solution has been excellent. There are no bugs or glitches. It doesn't crash or freeze. The reliability is very high.

I have no reason to believe this solution wouldn't scale well if a company needed it to. I see no limitations there.

That said, that's a speculative area for us right now. We haven't attempted to scale the product ourselves.

Obviously, Elasticsearch has to do all of its indexing upfront and that might be a scaling concern whereas something like Devo with its just-in-time indexing is pretty darned interesting.

On our end, mostly development staff and operations staff are using it right now. For our organization, everything is going to increase. We're just starting to ramp up usage now.

I've never dealt with technical support. I can't speak to how helpful or responsive they are.

The initial setup is not overly complex. It's pretty straightforward. A company shouldn't have any issues with the implementation process overall. Everything in AWS has gotten pretty straightforward.

The maintenance of the solution is minimal. It would only take one person to maintain it.

The price of the product is very good, as it is largely free. There isn't any operating cost. It's basically free software. I'm not aware of any enterprise versions that would cost more. Everything is an AWS service.

We're just customers and end-users. We don't have a business relationship with the company.

We're using the latest version of the solution.

The product in general has come very far. It's gotten a lot better over the years.

I'd recommend the solution to other organizations. I'd advise anyone to try it out.

Overall, I would rate it at an eight out of ten. We've largely been very pleased with the product.

We used this solution for gathering our application logs and analyzing application behavior.

This solution assists in tuning our applications.

This is one of the best open-source log management and log analyzer tools in the world.

The documentation for this solution is very important, and more needs to be developed. It was not as good as we expected, and because of that, we prefer to work on commercial solutions such as Splunk or ArcSight. If the documentation were improved and made more clear for beginners, or even professionals, then we would be more attracted to this solution.

As you gather more and more data, and the data continues to grow, I think it is difficult to handle, administer, and perform declustering.

I would like to see support for machine learning, where it can make predictions based on the data that it has learned from our environment.

In terms of stability, we have had many problems when dealing with big data.

There are six people who use this solution in our company.

I do not use the commercial version so I cannot comment on technical support. The open-source community is very important for this solution.

We used Splunk in parallel with this solution.

In my role as a Security Operations Center Analyst, I think that Splunk is more useful for me. This is because I do not work on analyzing application behavior. However, I help my colleagues with this task, using ELK Logstash, based on my experience with Splunk.

The initial setup of this solution was complex.

We have an enterprise structure and we cannot just install this solution, Logstash, and Kibana (the data visualization plugin for this solution), to have a good experience. For example, we had to set up the SQL database.

We now have nine Elasticsearch nodes in the company that all work together in a cluster. It is not simple, but rather, an enterprise structure.

We use the open-source version, so there is no charge for this solution.

The solution does not work as well as Splunk.

Our company uses Logstash for gathering the data, and Kibana for searching. The two are used together.

This is a solution that I recommend. It is the best open-source product for people working in SO, managing and analyzing logs.

I would rate this solution an eight out of ten.

We use Elastic Security for monitoring. Our client is a financial client, so we detect their infrastructure from that perspective. For example, if there is any unauthorized access to their financial systems, we need to know about that. We monitor all the instances they are using all the storage buckets they use, and then if they have exposed any APIs, we need to monitor those as well. They are using AWS Cloud, and we need to monitor their cloud services.

There is a lot of customizability in Elasticsearch. For example, I can use indices if I want to modify the fields or segregate the logs. I can also use different open-source tools. For example, a tool called ElastAlert can be used for detection on Elasticsearch. Even if you don't have Elastic SIEM, you can still use ElastAlert. Similarly, the APIs they provide are pretty flexible. We use those APIs in our automation to get notified in Slack.

Another good thing about Elasticsearch is that it provides extensive flexibility regarding search. The filters are pretty amazing. You can know, search whatever you want.

There are a lot of things that could be improved. For example, if I talk about Sentinel, the automation of the server component is very cool. But when it comes to Elastic, I don't see that. I think we need to come up with other solutions to make it possible to automate the response. This is easier in Azure Sentinel.

Then if I come to integration, for example, there is a product from IBM called QRadar. They provide a very managed way to manage your integrated log sources. For example, you will get a list in one pane where you can segregate logs based on their log type. For example, it could be based on Windows or Linux. Even within them, you can segregate them based on their application. You can tag them. But in Elasticsearch, you will get all of these in one place, in a raw form which is not very presentable. You cannot visualize those log sources pretty well. Although you can visualize logs pretty well through dashboards and graphs, when it comes to integrated devices, management for those devices is missing. And wherever I use Elasticsearch, it takes a lot of time to reload or load. It is very time-consuming.

I've worked with this solution for more than seven years.

Stability is a tough question with Elastic Security. Some of my clients have found this solution pretty stable, but two or three clients have a lot of real-time data, and it has been a pain in the neck while dealing with Elasticsearch because it takes a lot of time to load. Even if my client has increased their resources like RAM and storage, they might still put that into a load-balancing infrastructure without scaling enabled. The stability depends on how well you deploy it from the start. For example, if your design is good, and you have implemented it as it should be deployed, then you will not face those complications. But if you have deployed it wrong and don't have a completely planned architecture. After that, it is not easy to correct those mistakes because it has already been deployed and integrated, and now there's no time to fix those errors in the architecture.

It depends, but the solution is overall reliable.

The solution is scalable. But again, it depends on the deployment. If you're deploying it in an auto-scaling infrastructure, it will automatically scale as per the demand. For example, if it's a service on AWS, they provide Elasticsearch but call it OpenSearch. If you use that, it will automatically scale as per the demand, and you will only be paying for the resources you use. But if you are deploying it on-prem, it's only as scalable as the infrastructure.

Three of my customers are using the solution currently.

The initial setup is straightforward. But since I've been using it for seven years, I could be comfortable with the solution, so I'm saying it's straightforward. However, my team, including new people, found that the documentation was not complex. They find it easy to understand and deploy the solution.

The time it takes to deploy the solution depends on the kind of resources you will utilize. For a basic deployment, I don't think it should take more than one day. Also, consider that if you face any error, you must troubleshoot, even basic errors. It should not take more than one day. I'm only talking about basic deployment, not integration, fine-tuning, or configuration.

The steps taken during the deployment process depend on various factors. If you're deploying the cluster base, you must deploy Elasticsearch and Logstash. If you're using it, you can even deploy Wazuh, and on top of it, Kibana which would be used for all your graphical user interfaces. If it is an all-in-one deployment, the steps taken are simple. Just a bunch of commands from the documentation you can see. But if it is a cluster deployment, it's different. If it's on a cloud, you have to deploy different instances for each server, like Logstash, Elasticsearch, and Kibana. But if you're using the solution on the cloud, you will use different instances. Or, if you're going to deploy a cluster on-prem, you might want different servers or VMs.

I am a security engineer and I have a team of security engineers. We are an MSSP that provides security services to different clients. For example, a customer might need us to monitor their infrastructure, so they'd provide us access to their SIEM and monitoring tools. Similarly, one of our clients in UAE approached us to monitor their infrastructure, and I learned that they are using Elastic Security as an SIEM. I wanted to ensure that my team and I were comfortable using this solution to get clients to use this product.

I rate Elasticsearch a six-point five out of ten.

To anyone planning on choosing Elasticsearch, I advise you to know your infrastructure first and then plan how many instances you'll need. Consider how the number of devices and your business will grow, and plan accordingly. Then, deploy the solution according to the best practices. Once deployed, make sure you organize your integrations so that the solution is easy to manage in the long run because when you have more than 200,000 or 300,000 log sources feeding logs into your ELK, it will be very tough to manage.