Overall, the solution is good.
The machine learning aspect of the solution has been great.
The deployment is not that complicated.
ELK is open-source, and it will give you the framework you need to build everything from scratch.
Overall, the solution is good.
The machine learning aspect of the solution has been great.
The deployment is not that complicated.
ELK is open-source, and it will give you the framework you need to build everything from scratch.
The SIEM modules in Logstash, need more improvement. In the future, the modules could be more advanced as right now there are only very basic modules.
We are facing an issue with the engineers. In the region, there are not many available. Only a few people might be available in our particular region, which is a problem.
There isn't really a very good user experience. You need a lot of training. There is an interface with limited options. You need to work with the coding and you need to work with the scripts. It's not simple. If you want to configure something, for example, you need to be a proper programmer.
It would ideal if they had a dashboard. Right now, the only way to see what you need to see is to go through all of the logs.
I've used the solution for one and a half years.
The stability of the solution is good. However, it depends on the configurations. If the solution is configured properly from the beginning, it will be stable. However, if the solution is not configured from beginning properly, it will not be. This is due to the fact that ELK Elasticsearch gives you the framework only, and the customizations depend on the guys who will be coming to configure everything for the company.
The scalability is good, however, there is a certain level of skill that is needed. Due to the lack of trained engineers in the area, this could be a challenge.
We've reached out to technical support in the past. We found that sometimes communication with them was difficult as there was a lack of understanding. This means that it takes a longer time to reach a resolution. However, in the end, when we have had issues, we were able to resolve them, even if it was a bit delayed.
I've also worked with LogRhythm and there is no comparison. LogRhythm is the best solution for me. The use cases are better and are readily available. In contrast, with ELK, we need to deploy a lot of things. We need to program people and we need skills and training. We need a lot of things. Even the LogRhythm training is easier than ELK. With ELK, you need to build the customization, rules, everything, from scratch. WithLogRhythm, you just have to enable features.
If a company wants some more specific detailed use cases, then ELK would be better than LogRhythm, however, for a generic use case, LogRhythm is better.
The initial setup is pretty simple and straightforward. It's not overly complex.
That said, it does require trained specialists, and there just aren't that many in our area.
Overall, I would rate the setup process at a two out of five.
The configuration must be done correctly, and that depends on who is configuring it. If the person configuring it, for example, only has an administrator background, he will configure the administrator stuff. If he has a security background, he will configure for security.
We are a partner.
I'd advise others considering the solution that ELK is a good solution, however, it requires skills and capability. You need to be properly trained with it to get the most out of it.
I would rate the solution at a five out of ten.
It is for our own infrastructure. We are trying to do ELK Stack for everything. We are trying to build our own monitoring solution. For now, we are using it as an alerting solution, and SIEM is going to be our destination.
Its flexibility is most valuable. We can have a number of scenarios, and we can get logs from anything. If we know how to use Logstash, we can tweak it in many ways. This makes the logging search on Elastic very easy.
With Kibana, we can make very beautiful dashboards the way we wanted. It makes sense for the business.
We are paying dearly for the guy who is working on the ELK Stack. That knowledge is quite rare and hard to come by. For difficulty and availability of resources, I would rate it a five out of 10.
We don't have any scalability problems as of now. We have less than 2,000 devices.
We have a contractor who is trying to develop and deploy the ELK Stack for us. He has requested a couple of servers, and we have given those to him. He asked for more RAM and storage for the service, and he will take time developing the custom Logstash scripts that we have asked for.
I find it better than Splunk in terms of cost-effectiveness. For cost-effectiveness, I would rate it a nine out of 10.
It is complex, but you just need to have patience and personnel to develop it. Unless you explore a technology, you won't know what are the pros and cons. I have not seen any cons as of now, but it has miles to go in terms of being equal to Splunk. It is a community-driven technology. So, it will get there.
I would rate this solution a seven out of 10.
There are around 150 pre-built use cases. One of the major use cases is when somebody tries to fiddle with logs, Elastic SIEM creates an alert because logs are the most critical things from the security aspect. For example, I have more than 1,000 terminals, which can be desktops, laptops, or any sort of servers. If somebody tries to delete Windows logs, Elastic SIEM immediately generates an alert indicating that somebody is trying to fiddle with the logs. Elastic SIEM sends me a pop-up message as well as an email.
It is very quick to react. I can set it to check anomalies or suspicious behavior every 30 seconds. It is very fast.
Elastic has a lot of beats, such as Winlogbeat and Filebeat. Beats are the agents that have to be installed on the terminals to send the data. When we install beats or Elastic agents on every terminal, they don't overload the terminals. In other SIEM solutions such as Splunk or QRadar, when beats or agents are installed on endpoints, they are very heavy for the terminals. They consume a lot of power of the terminals, whereas Elastic agents hardly consume any power and don't overload the terminals.
There should be a simulation environment to check whether my Elastic implementation is functioning perfectly fine. Other competitors provide a simulation environment so that I can simulate an IT attack and see how my solution is reacting or giving me alerts. I have not found any such feature in Elastic.
Other solutions have their own Android and iOS applications that I can install on my mobile so that I am continuously connected to the SIEM. This is something missing in Elastic. There is no mobile app.
Its documentation should be a bit better. I have to spend at least a couple of hours to find the solution for a simple thing. The documentation should be more precise and much better than what their counterparts are offering.
When we buy Elastic, training is not included for free with Elastic. We have to pay extra for the training. They should include training in the price.
It is, for sure, reliable.
It is highly scalable. We at least have two dozen people who are using it. Some people may be using only a part of it, and some may be fully involved in it.
We have plans to increase its usage. We are ready with a running full-fledged server, and we can even handle data for potential customers. We are definitely planning to widen its usage.
I have interacted with them. They are quite responsive, and they do respond within the SLA.
I was not there when the deployment was done, but based on what I have heard, it was complex because of the server deployment and cluster formation, and it took at least two months.
Its price is fine. Its licensing works on a yearly basis. We have to renew the license every year.
I also have a good experience with Darktrace. When we buy Darktrace, we get training free of cost, which is not there in Elastic. We have to pay extra for training. There is certainly room for improvement.
I was not in this company when this was chosen.
I would advise going for the latest version, but it may or may not be backward compatible. Nowadays, version 7.12 is the latest version, and I see that it is actually not compatible with the older versions.
I would rate Elastic SIEM a seven out of ten.
It is currently deployed as a single instance, but we are currently looking at clusters. We are using it for a logging solution. I'm a developer and act as a server engineer for DevOps Engineers. It's used by developers and mobile developers. It could be used by quite a few different teams.
It is quite comprehensive, and you're able to do a lot of tasks. It has dashboards and we're able to create a lot of search queries. It is not easy to use, but once you get the hang of it, then it provides good graphs and visuals such as these. The indexes allow you to get your results quickly. The filtering and log passing is the advantage of Logstash.
In terms of query resolution, error searching finding and production issues, we're able to find issues quicker. We don't need to manually obtain the logging reports. All bugs in code are quickly identified in the logs as they are in one centralized logging location.
We're using the open-source edition, for now, I think maybe they can allow their OLED plugin to be open source, as at the moment it is commercialised. We are planning to go into the production to use the enterprise edition, we just wanted to check how this one works first. I think maybe on the last exercise part, I think the index rotation can be improved. It's something that they need to work on. It can be complex on how the index, all the logs that have been ingested, the index rotation can be challenging, so if they can work on that. In terms of ingestion, I think they should look at incorporating all operating systems. It should be easy to collect logs from different sources without a workaround to push the logs into the system. For example, in AIX, there's no direct log shipper so you do need to do a bit of tweaking there.
We have been using ELK Logstash for three years or so. We believe we are using the latest version.
The solution is quite stable, although it does need a bit of maintenance, and because there is quite a lot of plugins that come with it. There's a lot of testing that is involved to ensure that nothing breaks.
The solution is scalable. So you're able to extend it and grow it. For example, you're able to put it in a cluster, so it is quite scalable.
I have used the technical support. Their forums are quite good in terms of response. There is quite a big community of forums, where you can get similar question or issues that others have experienced issues previously. Even then direct support is quite good. They also have regional support.
Logging solution previously, but mainly I've been using Graylog and ELK. Graylog gives you centralized logging. It's built for a logging solution, whereas ELK is designed and built for more big data. If you want to go in deeper into analytics, ELK gives you that flexibility and out of the box models. The two solutions are widely used by a lot of bigger clients in the industry and they've been tried and tested.
With ELK, installation is not really straightforward. There are about three applications to consider. It's quite intense in terms of set up, but once you've done the setup, then it's nice and smooth. The implementation took about 3 weeks, but that is because I was doing it in between other projects. We used an implementation plan. It was deployed to the development environment, then the Point of Concept (POC) environments. It was then deployed into the production environment.
We implemented the solution in-house. There were no third parties involved. For deployment and maintenance, we just need about two to three people and the role is known as maintenance and installation.
We're using the open-source solution, So there are no-cost implications on it, but we are planning to use it throughout the organization. So, we will soon adopt the open-source model and depending on if there is a need for enterprise then we'll go down the enterprise route. If you need a lasting solution, you do need to buy the license for the OLED plugin. The free version comes fully standard and has everything that you need. It is easy to deploy, easy to use, and you get everything you need to become operational with it, and have nothing further to pay unless you want the OLED plugin.
We also have Graylog, for Graylog we're using it in parallel for a similar solution. At the moment, we're basically just comparing the two and see which one is preferred.
Do a POC first. They should compare solutions and also look at different log formats they're trying to ingest. See how it really fits with the use case. This goes for ELK and Graylog. You can trial the enterprise version. In terms of lessons learned it does need some time and resources. It also needs adequate planning. You need to follow the documentation clearly and properly. I would give this solution 8 out of 10.
Elastic Security makes data communication easier.
The solution should generate an automatic product that integrates with ELK Stack to use artificial intelligence.
The solution is not expensive and costs around ten dollars a month.
The solution allows you to generate alerts. You can automatically detect and configure mail in some addresses and automatically identify the identity that you have in your system. This is important for confidentiality in order to control the risks in identifying the users. The solution also uses artificial intelligence to identify anyone using your system.
We use the solution to monitor the activities of the people in the organization to prevent attacks in a controlled environment. We use the tool to observe the behavior of attacks and how to mitigate them. Today, security is more important than people know. You need to know who has access to your network, repository, or cell phone.
Overall, I rate the solution ten out of ten.
We have different use cases. We implement it for the banking and healthcare sectors. It's the most useful for the e-commerce platforms that we deploy it for. The most important feature is Elasticsearch.
They also use it for security. Elastic Security has been deployed in the National Bank of Dubai. They are currently using Elastic Stack and they're also using the security version.
It's a good platform and the very best in the current market. We looked at the Forester report from December 2022 where it was said to be a leader.
There are many benefits. It provides log monitoring, synthetic monitoring, real user monitoring, and application performance monitoring.
These are the four main use cases that most organizations use it for. They want to know the downtime and the errors in the code. They acquire it through my company. It's mainly used by SMB-sized companies but not enterprise.
Elastic has one problem. In the past, Elastic Security was free. Now, they currently only offer the basic license or a certain period of time.
The platinum and enterprise level features aren't offered in the free version and most organizations use the free version. They don't pay for the paid features. That's a problem in the market from the Elastic side. They should have a way for everybody to be able to benefit from the premium features.
I have been using Elastic Security for one year.
I would rate Elastic Security a nine out of ten.
We are looking for the same tool on-premises that we can provide to our client as an MSSP. We're evaluating different types of tools in the market.
Although, we have a premium version, and I was checking the functions and features here.
We have some questions about the query language. So that also from this console and so that we can actually want to have a demonstration session where we can clarify this thing query to manage.
The interesting thing is about the dashboard. There are available widgets for the dashboards, along with specific features like different types of reports, such as a list of alerts. This helps to remind us which events are happening most often.
We are still evaluating the solution, but the dashboard is something good. And one more thing, it also has anomaly reports. I like that there is a report that is only based on anomaly-related activity.
One limitation of Elastic Security is that it does not have built-in workflows for all tasks. For example, if you need a workflow for compliance, you will need to create a custom workflow.
Sometimes, different types of clients require different workflows. And it absolutely varies from context to context. So that is often not available in [Elastic Security].
Additionally, the list of data sources that Elastic Security supports is limited. If you need to collect data from a system or application that is not on the list, you will need to develop a custom integration.
We have been evaluating it for the last two months.
It works fine on the few devices we have deployed this solution.
The scalability is good. It can be scaled easily in the production environment.
The initial setup is easy.
The pricing is fine. But the basic pricing should cover all the features you need. Elastic needs to add more features, which are available as subscription-based add-ons. So more features may need to be added.
Overall, I would rate the solution an eight out of ten. We are still evaluating Elastic Security, but we are interested in learning more about its capabilities.
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.
Our use case for Elastic Security is for log management and security information for the management team.
The most valuable feature is the scalability. We are in Indonesia, more engineers understand Elastic Security here. So it is easier to scale and also develop. In features, the discovery to query all the logs is very important to us. It is very easy, especially with the query function and the feature to generate alerts and create tools. Sometimes we use the alert security dashboard to monitor our clients.
I think because we are a cybersecurity company, the thing that can be improved is the prebuilt tools, especially quality. Compared to its competitor, they still have fewer prebuilt security rules. Elastic Security, in terms of generating alerts, cannot group the same products into one another. Even though the alerts are the same, they still generate them one by one. So, it is very noisy in our dashboard. I would like the Elastic Security admin to group all the same alarms into one alarm so that our dashboard is not noisy.
I have been working with Elastic Security for around one or two years in my current company.
I would rate the stability of the solution a seven out of ten and there are a lot of glitches.
Elastic Security has very good scalability.
I have had no direct communication with the support team but my technical team says that they are not helpful.
Neutral
The setup process is very complex if you are new to it. But if you already understand how Elastic Security works and how the architect works, I think it is quite simple.
The pricing is in the middle. I think it is not an expensive experience if we compare it with big names, for example, QRadar, and also Oxide. I think Elastic Security is quite cheap. I would rate the pricing of this solution a five out of ten.
I think they are doing a pretty good job in terms of the user interface and also the user experience. I think in terms of the basic features and also the user experience, it is enough for us to support our daily operations.
Overall, I would rate the solution a seven out of ten.
Elastic Security is very easy to adapt.
The tool should improve its scalability.
I have been working with the product for seven years.
The solution is stable.
Our DevOps uses the product regularly.
I would rate the solution a seven out of ten.
