I am working with the cloud version of Splunk Enterprise Security.
Splunk has certain kinds of health issues that usually get reported. If the search query is lagging, we do check where the query is lagging. That is something that we have to refine. It's a hectic activity, which requires the workforce to understand the context because not every user with a simple understanding of Splunk will be able to do it. It requires understanding how the queries are running, how it is scheduled, and how it uses the resources.
Two sets of people work on it: the analyst from our side and those directly using resources from the client side, who work in their security department. They might have some precedence in the environment, which we might not have. We may face lagging of query and, sometimes, queuing of the query, even though we have run it. It will be the first query we are running, but it will be skewed since we don't have the precedence of running a query.
It will give precedence to other queries over ours. It's a thing that we have to manage. This usually doesn't happen with other SIEM tools. That is something where Splunk has to be less expensive or less maintenance. We are struggling because we only identify after the query has gone rogue to invest in it and spend more time resolving issues.
Until now, I haven't used the threat intelligence management feature or even the data model. I use the documentation provided by Splunk on different attacks, which we can view on their site. They already provide insight into attacks on Active Directory or AWS in their documentation library. That gives a good context of how I can search for the different kinds of attacks.
I'm also automating some of the reports on how I challenge threat intelligence. I'm also doing threat hunting in their environment for some of our clients. I'm trying to find any anomalies with the configuration in their environment, which they are unaware of.
Suppose someone gets a response from their environment regarding weak encryption or a configuration that provides certain privileges to certain users, like any query or command line. We find great visibility from their documentation side. We will need time to get acquainted with Splunk threat intelligence management.
Earlier, I started using Splunk Enterprise Security in 2021. I had a trial with Splunk Enterprise Security and contacted the Singapore team to understand the solution. I was working in a startup and wanted to integrate this solution. I was able to get a trial period for three months. I was able to deploy it on the whole server and learn about the Splunk query language. After the trial, we couldn't purchase Splunk as it's a costly tool.
I initiate use cases, analyze the logs, and implement new logs. Since Splunk supports add-ons specifically for different services, we have created plug-ins to integrate any new AWS logs. Implementation of logs also falls under our category. My main job is cybersecurity. I need to understand all the logs to create use cases that cannot be specifically created by a single person who only understands the injection. The context is important to create the use cases.
We use Splunk Enterprise Security to create visibility into the client's environment and research the threats or vulnerabilities inside their servers. We're trying to detect any vulnerabilities regularly by creating specific reports for our purposes for some exploitation, which can happen if you get certain kinds of privileges. Whenever something malicious happens, Splunk Enterprise Security will send us a report containing that specific activity's data.
I can create specific queries to get reports, which I have not observed in other tools. The same can be replicated for the dashboard or vice versa. Splunk already provides a library of use cases regarding attacks. Their website also has a great amount of documentation on how to search for different kinds of attacks in an environment using certain scripts.
It's very good for users to go through their documentation. Users need not purchase a second solution or outside inventory to get visibility about the kind of attacks they can see. That is something Splunk has already prepared for its clients or users.
Everything concerning Splunk Enterprise Security is quite different from other tools. Splunk Enterprise Security has features that are very different from other vendors. These features include viewing correlation or drill-down searches of specific use cases, mapping those comments, and closing any alerts triggering the incident review.
The solution gives us some visibility on the use cases directly. Query is one of the strongest things that Splunk has. With the respective data models, we can create queries running much faster than other environments.
Splunk Enterprise Security gives certain advantages of deploying and automating some of the things we usually do manually in other tools. One of the biggest advantages of the solution is that we can detect threats and vulnerabilities in the environment by creating certain dashboards that give visibility. We can create certain reports, giving us continuous activity reports of anything malicious. We can schedule it at a specific time and send it as a mail.
That gives Splunk a greater advantage of providing insight to the person trying to see any kind of threats or visibility. The solution is intuitive because it lets you choose how you want to be notified regarding any kind of threat. I can correlate from one index to another by correlating searches by stretching one of the fields from one index and then searching for that information in another index. That is not quite possible in other tools and is unique to Splunk Enterprise Security.
With Splunk, we can correlate between any kind of endpoint device, what IP they are mapping through, and search the firewall in the same query whether that IP was allowed or not. It's a very intuitive tool that allows us to create multiple complex queries to solve a problem in a single go rather than opening different instances of different devices and then comparing them manually.
We deploy all of our use cases and reports with respect to the MITRE ATT&CK framework. We write the tactics and techniques of the MITRE ATT&CK framework inside the use cases because there are fields we can fill in about the MITRE ATT&CK framework. It is very useful for us to monitor what kind of MITRE tactics and techniques we have already covered. For anything missing out, visibility is also great so that we can monitor all the users with respect to the MITRE ATT&CK framework.
In our organization, rather than using only the field change, which covers only some parts, we always deploy use cases with respect to the MITRE ATT&CK framework. We have assessed specific use cases for every environment, whether Windows or AWS. We cover certain default use cases, which we want to create in the environment for covering the MITRE so that those are crucial for discoverability whenever something triggers.
Those are also crucial whenever we want to see how much coverage we have according to one device, like Windows log, Linux log, or AWS or Azure environment. If there is any scope of vulnerability present, someone might be trying to attack AD, and the MITRE ATT&CK framework covers it. On the MITRE ATT&CK framework side, I can put a technique they're using for a threat that might be present for initiating the attack. That gives us great visibility of providing threats.
When we are filling out the MITRE ATT&CK framework, any person from cybersecurity will be directly able to copy-paste any technique onto their Google search. They will be able to know what kind of MITRE technique we are trying to cover and how the use case will help them. That can already be done from a use-case perspective. We don't have to go to the library to know how we deployed the use case. That can be done from every different alert.
There are glitches and notes, and it gives more context with respect to the sensing tool. The main field is the activity field, where jobs are there. The usability of that particular feature, where I can see which particular job they're running, gives context to us on how the query is being run in the back end and how they are scheduling it.
If I don't have certain admin privileges, I might not be able to schedule my query. It will certainly give precedence to the admin account, and if I want to see great visibility into the search I'm doing, it will take a certain time.
Only after a certain privilege query is being run will it give precedence to my query. That is something where the distribution of resources can be separate. A separate tool can also be created for giving certain privileges to temporary users so that they can run their queries to find any threats or vulnerabilities. Also, not every query for admin needs to be run at certain privileges. It can be asked during the time of deploying whether this query requires a certain precedence.
Splunk already has specific definitions for finding threats. It can be through a network or a signature. They already have different kinds of internal assessments of how we're deploying use cases and how Splunk understands it. The same can be given to users because sometimes when we try to search for any threats, it gives precedence to other things. Even though the tool is good, it takes time to give us visibility because of the involvement of so many resources.
On the admin side, if I have certain privileges and everything is running fine, I have great visibility on understanding the use cases and deploying correlation between two different indexes to find any threat. That is great because I don't have to manually create ten use cases, where I can create five and cover both the indexes from which I want to get a query. If I want to search a user's active directory for the kind of privileges they have, I can only create a single use case and cover both.
I don't have to search for it on different use cases manually. Splunk gives great visibility into the dependents of both indexes' coverage in one field. It gives much more context. I can get output from both indexes and correlate what has happened in the user's environment much more quickly rather than using other tools.
Compared to other tools, Splunk Enterprise Security has helped us reduce the volume of alerts and visibility of fine-tuning because it provides many different aspects. I can reduce the volume of alerts by helping users. If they have certain kinds of IPs or exceptions to the rule, I can create a macro. If they have a list of things, they can directly include another macro to make it an exception.
I can create a local file, which is a very good thing for them. They can provide insight on the local file, and I can create a specific query if they want insights on that particular local file whenever something is happening. This useful feature that Splunk provides allows users to have visibility because these are the things users might have done manually on other tools.
Since some dependencies or add-ons for visibility are already inside Splunk, it gives a lot of insight into threats. It reduces threats and gives more context to what we are trying to search for. It automatically gives us a report rather than manually checking for every other field.
Compared to other tools, Splunk Enterprise Security gives context into the raw logs, which are present in my environment, and also what are the fields I'm trying to see. It gives visibility rather than showing all the empty fields, usually presented in other tools, whenever I open any alert.
There are certain fields that are empty and others that are filled. With Splunk Enterprise Security, I can directly check which particular fields I want to see. I don't have to manually go through the whole logs page and select whatever field I'm trying to see. That is a feature in Splunk for investigation purposes.
The time taken by our analyst to resolve alerts compared to other solutions is less. Other tools provide all the available fields, and a person has to decide which field they require for a particular use case.
In Splunk, you can directly point out all the necessary fields required for a particular query you are trying to run. Then, the user can easily assess which particular field they want to investigate more. This great feature from Splunk gives an analyst less time to wait for the alert and more time to do an analysis.
The recent CrowdStrike report reported that the majority of the cyber attacks are from active directories and from the carelessness of users through phishing emails. Even though the visibility needs to be there in cyber security, organizations still usually use SIEM tools, which are much cheaper. For such cheaper tools, they have to hire many analysts, and every analyst has to be on the same page to understand the context of what is going on in their environment.
If they already have a small team, they can do this work easily in Splunk. An organization needs to understand how complex their environment is. If their environment needs a certain kind of visibility, they need to go for a tool that serves their purpose of providing insight rather than going for the cheapest solution. Also, it will be much more beneficial for their hiring purposes. Relatively fewer people will be required if they can closely monitor Splunk and create queries. If certain users have already used Splunk, it will be great for them to deploy the solution.
Splunk provides much more insight concerning the closeness of understanding everything going on in their environment. A certain group of people can get the context of what is working in their environment and how they're approaching it. This is less of a hassle in other tools where every use case will be deployed irrespective of dependency on one use case.
One field or one endpoint solution will be different from an authentication tool, and they won't be correlating as such. We will have to do that manually and search for any similar field manually. Whereas in Splunk Enterprise Security, you can deploy it at once. So, less workforce will be required for deploying, understanding, and giving context to the users working on the environment inside their organization.
Our US customer has more than 15,000 to 20,000 devices deployed since it's a hospital. They have ingestion of data from every side from where logs can be ingested. Every employee working in the environment will be interacting with the internal sources. So, we see logs in every device, including laptops, desktops, medical devices, firewalls, and mobile devices. Usually, doctors get updates and visibility on their mobile devices. These mobile devices should not be attacked as they are the ones where the user data or the patient's data is exchanged very informally.
They have deployed specifically Armis to get visibility onto their network communication, which is a very good tool. They have invested in automating the resources, creating visibility onto their environment, and blocking certain communication. They can create specific playbooks with respect to it. It has given them a much more context. The same thing is not necessarily happening with other clients because they have deployed very few devices.
So, there was no complexity in understanding the environment as such. For them, Splunk provides the same insight as any other tool. For them, it's not serving the same purpose. For them, the deployment of use cases is good and not that complex. Besides that, Splunk is not serving this client's purpose because they already have fewer resources deployed. For them, Splunk does not provide any visibility or context that could not have been filled out with any other SIEM application.
I will certainly say that Splunk Enterprise Security is a great tool if you have the context and patience to learn it. It can also serve a great purpose of understanding the environment much more clearly and easily than other tools. Users will have to compare the pros and cons if they can afford it because it will be expensive for any organization.
Overall, I rate Splunk Enterprise Security an eight out of ten.