We use Splunk Enterprise Security as our primary security event manager. We collect data from various log sources into our Splunk SIEM to build context around what is happening in our environment. We then use the capabilities of Splunk Enterprise Security and other tools to enrich this data and help us manage the data, events, and detections.
Splunk Enterprise Security helps us focus on security. It provides us with data and a number of pre-built learnings that allow us to view the content in very useful ways. We can apply filters to the data to get more value out of it. This is the primary use case for Splunk Enterprise Security: to help us analyze and leverage the content we have.
Monitoring multiple cloud environments can be relatively easy, but it depends on the vendors. There can be challenges, such as ensuring that all of the data is ingested and aligned correctly. This is because vendors, especially in the cloud, can change their log formats at any time. Additionally, some vendors may not provide the same log feeds in the cloud as they do with on-premises solutions. As a result, it is important to be aware of these potential challenges and to take steps to mitigate them.
Splunk Enterprise Security provides reasonable visibility into multiple environments by harnessing the power of Splunk and the data it ingests to unify and provide a consistent view.
Splunk Enterprise Security's threat detection can help our organization find unknown threats and anomalous user behavior. We are early adopters of the user behavior piece, so we are still working to normalize our data. Splunk is working with developers to ensure that they can intake our data. We use Windows Log Forwarding for a lot of our host-based logs. We are leveraging this with an on-premises GPO. The gathering mechanism is a little bit different than what Splunk has seen, but it is still within the realm of acceptable. We are working through this issue.
We have a few different STIX and TAXII feeds that are being processed by the Threat Intelligence Management feature. We are members of a few different organizations that provide these feeds, and we use them as needed. The feeds also feed into some of our security products.
Actionable intelligence provided by Threat Intelligence Management is valuable, but it is important to be aware of its limitations. Threat intelligence can help organizations to correlate and build context around security events, but it is important to remember that the information provided is often brittle and can change quickly. For example, an IP address that is associated with a threat actor today may be used by a legitimate user tomorrow. Additionally, some threat intelligence feeds may be contaminated with false positives, which can lead to false alarms. It is important to carefully evaluate the quality and reliability of the threat intelligence before taking any action. Organizations should also have a process in place to verify and validate any threat intelligence before using it to make security decisions.
Splunk Enterprise Security is a valuable tool for analyzing malicious activities and detecting breaches. I am glad we added it to our security stack. Previously, we ran for a year or so without it, and while we had some capabilities, we were truly missing out on some things by not having Enterprise Security. It definitely added value for us, and I would not go back to not having it. I think it has been a solid addition to our security posture.
Splunk Enterprise Security helps us detect threats faster, but the lion's share of the work is still in the process of customizing it to our needs. Taking enterprise security and modifying it to apply to our needs is where we see the biggest bang for the buck. From that perspective, it is probably better for us.
A lot of the prebuilt capabilities in Splunk Enterprise Security are extremely beneficial because they cover all the use cases. I think another important aspect is the consistency of their approach and how methodical they are. This is very helpful because it sets a structure for how we view our data and what we can leverage from it. This page clearly drives us to what is happening and what we need to do, and it has a workflow associated with it. This also helps to reinforce the process. When we deal with security issues, this can always be a challenge. We are dealing with a fire drill, and we need to be able to react. We don't want to make mistakes, and it is easy to do so if we are trying to wing it. However, the structure of this approach helps to reinforce that. I think this is another area that is beneficial in terms of the workflow and how it approaches what it does.
Splunk Enterprise Security helps us reduce the volume of alerts we receive. However, we still have to take action on a number of items. Splunk Enterprise Security helped us to do this by ensuring that our input data is accurate and reliable. We are still evolving and maturing in our use of Splunk Enterprise Security, and we believe that it will continue to help us to reduce the volume of alerts we receive and improve our security posture.
Splunk Enterprise Security helps speed up our security investigations to a degree. The workflow is improved, and when we encounter an incident, we can take ownership of it, manage it, dive into individual facets of it, run queries, and expand on them. It makes some items easier to access or understand.
The varied prebuilt feature is the most valuable because it ensures that we have complete coverage over all of the key questions. By seeing how others analyzed the data, we can develop new dashboards and approaches. It is always helpful to see how someone else used a tool to spark ideas about how we can enrich our items based on our specific needs. This feature covers a lot of our core general questions and is helpful, but it also allows us to see what someone who is really focused on this area has done and how we can tune and tweak it to our needs.
It is important to make sure that everything is built off of the threat models and all the underlying items within Splunk. This includes making sure that the log feeds are aligned correctly so that when we look at data and alarms, everything makes sense. Sometimes, I see alarms that are caused by data sources that have snuck in. For example, if my firewall says something about AV, it might get mapped into antivirus. This can happen because firewalls are multipurpose devices, and they can end up in models that aren't really applicable. Part of the problem is the infrastructure within Enterprise Security with how they group data types. For example, authentication data, firewall data, network data, and user-based data are all gathered in different ways. This can lead to confusion, especially when multifunction devices are involved. For example, if a firewall says that antivirus is not enabled, it might still detect something as if it was antivirus-related. This can blur the incidents and the information we have. It is important to identify items that creep in or issues that need to be cleaned. This will help us identify problem areas and their root causes more effectively and quickly. We can then clean up the data model, make sure the lines are correct, and get higher-quality alarms.
I have been using Splunk Enterprise Security for over a year. We have used Splunk as a security SIEM for at least three to four years.
We previously used free Splunk apps.
I believe that Splunk Enterprise Security is worth the price, but it is expensive. I am always trying to balance the need for security with the need to be cost-conscious.
I give Splunk Enterprise Security an eight out of ten.
Using a SIEM is not cheap, no matter how you slice it. So, the first question I would ask is, what are we trying to do with our SIEM? In my opinion, Splunk, including ES shines when we are willing to invest in learning and modifying our SIEM, our solution, and our environment to align it with what we do and how we do it. If we are willing to make that investment to contextualize the security and visibility, then Splunk is a tool that can help us do that. If we are looking for a turnkey solution, where we can just throw logs at something and then pull the arm of the slot machine and get things out, then Splunk is not necessarily the right tool for us. We can get there, but it will be a pricey slot machine. I think we will get the most value out of Splunk if we want to get things that are more contextual to us. We may need to enhance or build off of the Splunk dashboards that ES includes, and that will help us to create dashboards that are extremely relevant to our environment. If we are comfortable with creating Splunk queries, then we will have a lot of power at our fingertips.
To those looking into the solution, I would ask: What are they looking for? What are they willing to invest in? Do they want to understand queries? Do they want to build the knowledge around how to structure them? Are they willing to put in the effort to get the real power out of it, or are they expecting something to tell them what is going on? They need to realize that it is never going to be built for them at that point. So they are going to be getting something generic. They have to consider their specific situation, such as how many people they have on their team, etc. They should also probably take a good stock of what they are trying to log and how long they have to retain it. I have been very happy with our Splunk Cloud instances. They have been very reliable. I think it has been incredibly powerful for us. I think that is also another aspect of whether they are going to have their SIEM in their environment or outside of their environment. They need to think about some of these items. Obviously, Splunk can go either way. They have to make their decisions there. We have been very happy with our Splunk Cloud instance. So that's what's been really good for us. And, also, it takes some of the administrative aspects and puts them on somebody else. That's valuable for us too.