Elastic Security Reviews

We are using Elastic Security as part of the Elastic Search component. The solution provides us with security, such as threat protection.

The most valuable features of Elastic Security are it is open-source and provides a high level of security.

Elastic Security could improve the documentation. It would help if they were more simple and clean.

I have used Elastic Security for approximately two years.

We have one person using this solution.

I have used the community support for Elastic Security. Sometimes the support is helpful and sometimes it is not.

I have used other similar solutions in the past.

The initial setup of Elastic Security is straightforward. However, the documentation could improve. The deployment can be done in approximately 15 minutes.

I have seen a return on investment using this solution.

The solution can take up to 20 minutes to maintain when needed.

I rate Elastic Security a seven out of ten.

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.

In my previous organization, I used this for central log management, increasing developer productivity.

Elasticsearch Indexing and the Visualize tools of Kibana.

Authentication is not a default in Kibana. We need to have another tool to have authentication and authorization. These two should be part of Kibana.

No issues with stability.

We had issues with scalability. Logstash was not scaling and aggregation was getting delayed. We moved to Fluentd making our stack from ELK to EFK.

We were using the open source version. Community support is good.

Complex. We needed to analyze multiple factors, like benchmarking, performance of Logstash.

I rate it at eight out of 10. It is scalable (if used properly), durable, and performance tested.

If you are good to spend money, Splunk is way better for log management. There might be other use cases where you may need ELK.

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.

Elastic Security is usually used to deliver and analyze logs for security teams. Some common use cases include search and analytics of log data from the system and sending it to other components. We are using features like point security and detection of gathering data.

The most valuable thing is that this solution is widely used for work management and research. It's easy to jump into the security use case with the same technology. Also, it's valuable from an operational point of view as you have the same knowledge of how to operate it, how to work management, search, and security instance.

The important part is that it's free of charge usage. For our use case, it's enough, and it's for a good cost because the basic level of the solution is free.

In terms of improvement, there could be more automation in responding to and evaluating detections. Additionally, there could be some sort of intelligent database checking for better effects. Overall, I think there could be more automation.

I have been using Elastic Security for four years now. When it started because we were working with Endgame before it merged with Elastic.

I rate the stability an eight out of ten because it depends on the design and how well you monitor it.

I would rate the scalability a ten out of ten; it is a very scalable solution. We work with enterprise-level companies.

The customer support is good. You have support from all project stages, beginning with the architecture. And after you roll out the solution, you have dedicated technical staff for the project.

Positive

The initial setup depends on what you were expecting, but since we have experience with it and know what it's good for, it's an eight out of ten. The initial deployment typically takes about a day. Then there's an initial stage of the project to integrate some of the client's specific requirements, which can take additional time depending on the complexity of their environment.

When it comes to maintenance, it depends on the project, and sometimes one person can support all roles.

Usually, it's enough to have one engineer with deep technical knowledge of the operating system and the deployment and configuration of the system. The other role is an analytical role with project management and coordination skills to communicate with customers and drive delivery.

We implement Elastic Security in our customer's environment. We are like a consulting company. Depending on their preference, the initial deployment could be on their internal cloud, on-premises, or on hardware visualization. The advantage of this solution is that it can be deployed anywhere, including public clouds, private clouds, on-premises, bare metal, and even on Kubernetes.

The deployment takes a few days, and in the initial stage of projects, it could take two months with some integrations to the system, setting some rules, and so on. But it also depends on our customers and how familiar they are with it and what they want.

Usually, we start with a small installation with a bit fewer sources, install the initial setup, and gather information from selected systems such as legacy systems, infrastructure systems, custom applications, and so on running in the customer environment. Then we show how our solution behaves, how it grows, and what is the expected volume of data. We plan the next iterations to extend the hardware deployment. As users start using the platform and become familiar with it, they can set their requirements for implementing iterations. Then we shape the infrastructure and implement some rules, detections, machine learning, and other features.

We prefer to move forward very fast with no big analytics because customers usually don't know what is happening in their systems, and with this approach, we are showing them what they need to focus on.

I would say you don't spend too much time evaluating and comparing it with other products. Just start with it because you can begin for free and gain knowledge. It's the best approach.

It's also a good idea to run it next to other solutions, like Splunk or QRadar, or something else, and compare how you can use this platform. We have also done some migration projects from these platforms to Elastic Security. Initially, some expectations were that it could not be as good for the price because it's free or cheaper, but surprisingly, we found it valuable and easy to use.

Overall, I rate it a seven out of ten because some features are still missing. However, it's a developing platform and technology that is a good investment for the future. Every release adds new features, and the platform fits future requests and changing IT landscapes, like cloud environments. There are no limits, and it's an open platform that can serve all needs.

We really like that it integrates into the overall ELK Stack, and we're using that as our theme. We were looking for a product compatible with that. We like the detailed investigation features of the platform as you're able to get a lot of detail as to what's going on on the host when you do investigations. We like the quarantine feature.

We chose the product based on the ability to scan for malware using a malware behavioral model as opposed to just a traditional hash-based antivirus. Therefore, it's not as intensive. We have a lot of satellite communications, and it's not as intensive since we don't require updates to calm down on a regular basis for updated DAT files for hashes on a regular basis. We only have to update quarterly against the new malware model. It's also a lot less impactful from a performance perspective on a machine.

It's a pretty solid product. It's pretty easy to use as it's not a full endpoint protection suite. We're actually dependent on using Windows Defender for a firewall and traditional antivirus when it's required. It could use maybe a little more on the Linux side. Now that the product line is getting picked up by Elastic, they're going to continue to build out and make the Linux feature set more robust. However, I would say that right now the Linux feature set is a little limited.

I've been using the solution for about a year.

Stability is very good. It's a very stable product. We haven't had any issues with stability at all.

For what we use it for, scalability has been great. Our environments tend to be smaller. We're only talking about 200 to 1,000 systems. Therefore, I don't know that I could speak to a real large scale since that's not our implementation level.

We are kind of in an interesting use case as we're not actually using it on a day-to-day basis. We are a production house, and we shift suites out to customers to use. As far as what the user feedback is on a regular basis, we don't really see a ton of that unless we kind of go out and hunt for it.

We're using the Microsoft Defender product. It's just what's embedded inside of the operating system. It's not the full Defender for Endpoint. It's just Windows and antivirus.

The Endgame itself is extremely straightforward to set up and you just filled out the ISO and you follow a couple of wizards you're done. It's very easy. I would say the ELK Stack is a little more complicated, however, that's due to the way we implement PKI in our environment. The product in itself is fairly straightforward to implement. It's our choice of certificate implementation that's making it a little more complicated.

We targeted it to be able to be maintained by one person. In a lot of cases, our scenario is that we only have one person available to maintain the product. It's very easy to maintain. There's not a ton going on. In a scene, you always have to have somebody watching the log of traffic if you want it to be effective. However, outside of that, there's no extreme maintenance associated with the product.

I do not know approximately how much it costs per month or per year. I'm not the one who makes the purchases.

We are just customers. 

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

My clients use this solution for security purposes and SIEM and log management.

The most valuable features of the solution are the prevention methods and the incident alerts. 

There is room for improvement in the Kibana dashboard and in the asset management for the program.

I've been working with Elastic Security for almost two years now.

The solution is stable if you don't touch it too much. Meaning, it's technically stable, but if there is a period of downtime, you will face quite a big hiccup in getting it running again and stabilized.

The scalability of Elastic is amazing. 

I would say the technical support isn't really good or bad. On a scale of one to ten, I would give it a five. 

Neutral

The setup can sometimes be quite complex for the backend team. It all depends on the client's environment, so we have to be flexible.

My company provides a team for deployment, which usually consists of at least three or four engineers. Deployment generally takes six months to one year.

I would say that, on average, a good ROI can be seen within one and a half to two years after deploying Elastic Security. 

Licensing for the solution is available as a one-year or three-year plan, and all of the features are included.

I would rate this solution as a seven out of ten.

Documentation is very good, so implementation is fine.

Email notification should be done the same way as Logentries does it. Because of the notification issue we moved to Logentries, as it provides a simple way to get notification whenever a server encounters an error or something unexpected happens (which we have defined using Regex).

We set up a cron job to delete old logs so that we wouldn't hit a disk space issue. Such a feature should be available in the UI, where old logs can be deleted automatically. (Don’t know if this feature is already there).

No issues with stability.

Not really, but we did set up a cron job to delete old logs so that we wouldn't hit a disk space issue.

ELK documentation is very good, so never needed to contact technical support.

We used Logentries, but because it is open-source we moved to ELK as a part of cost-cutting strategy and evaluation of ELK. But the lack of a notification feature caused us to go back to Logentries.

Slightly complex, especially when you are configuring machines which are on a separate IP rather than on a single machine. In my case Elasticsearch, Kibana, and Logstash were on different machines. Along with that, we added a proxy server (nginx) ahead of the Kibana server. We used the proxy server for user authentication so that only known users should be able to access the Kibana dashboard. ELK didn’t have a free version for user authentication and that made us go for the alternative. We have, in total, four machines.

I give it a seven out of 10. They don't provide user authentication and authorisation features (Shield) as a part of their open-source version.