Last updated at Mon, 28 Oct 2019 16:57:09 GMT

This post is the fifth in a series examining the roles of search and analytics in the incident-detection-to-response lifecycle. To read the first four, click here, here, here, and here.

While a lot of people may think it's a controversial topic, stating that a SIEM doesn't detect attacks is really just a clarification. SIEM security solutions are designed to aggregate, store, and provide access to your logs. Given these goals, it was only logical (and initially life-altering) to be able to build rules for alerting on any identifying text or patterns found in the data you have stored in one place. But enabling teams to build detection on top of their data is not the same as selling them the sort of detection they would get the first week they connect an antivirus [yes, seriously], IPS, or sandboxing solution. If you want effective detection from your SIEM, you have a lot of hiring and investment to do.

Spending your entire monitoring budget on a SIEM leads to a systemic problem

Budget planning is never enjoyable in an organization, but that's especially true when you're not seen as a revenue-generating department, as security is typically classified. Once your management team recognizes the need to invest more seriously in monitoring, it's critical they understand that just one SIEM product isn't going to solve all challenges. In fact, budget for just one SIEM solution is a worst case scenario. This is almost guaranteed to lead down a path where the security team views the SIEM as a failed investment and treats it as shelfware because the team is too small to get value from it, while the management team believes they have provided ample funds to start seeing results. This becomes a larger problem in subsequent budget planning, when new monitoring money is needed to obtain alternative, ready-to-use detection tools for the team. Due to improper expectations, those outside security fall into the sunk cost fallacy and instead demand any incremental funds go into the SIEM until it is made effective. They underestimate what this would take and are unwilling to accept the team's abandonment of the sizable purchase, so an under-funded team continues to be blamed for failing to make an off-the-shelf solution work with no incremental staff or software developers.


[Related Resource: [VIDEO] SIEM tools don't have to be hard, here's how.](https://www.rapid7.com/resources/videos/siem-tools-dont-have-to-be-hard.jsp)

Successful security teams have considered the SIEM solution a starting point

Nothing about my initial statement was meant to say SIEMs have no value for detection. Your security team needs a place to quickly access the organization's data. It needs a central place to investigate the alerts coming from the many security devices. It needs a place to build custom rules specific only to your organization. You just need to be prepared for the implementation effort, challenge of keeping all the necessary data flowing in consistently, and the staff necessary to both build effective detection and retire rules when they become ineffective. If you cannot meet these three criteria, you need to go with either a managed service or an alternative software solution.

Buying a SIEM and sending it data will not improve your detection. You need a team capable of translating the data output from your infrastructure into a common language the SIEM understands. You need a team capable of interpreting the out-of-the-box rules available in the SIEM and tuning them to your organization. You need a team capable of triaging and analyzing every alert to confirm incidents prior to having effective detection. You need a team who can learn the search query language and best ways to pivot across disparate data sets during investigations. You also need a team with the ability to manage hardware, architecture, and the "hot vs. cold" storage balance for your unique capabilities and needs.


Inflexibility has driven many to build complex, custom aggregation and stripped a lot of context to ease data normalization. If you can't feed your SIEM with data from a newer source or cannot build ingestion for a type of data you value, you've probably switched vendors or built some complex series of forwarders and connectors with a team dedicated to keeping them running. This can become a regular chore to not only manage, but re-architect, when more data sources inevitably come online as your business starts using more and more modern services, some of which will likely be in the cloud. Remaining successful requires creative mechanics who can fix anything with a little love, like my favorite mechanic in [still the best Mad Max movie] Road Warrior. In many of these cases, you and this ever-growing SIEM maintenance team need to identify the important fields (which you hopefully know) and normalize the logs yourselves to ensure they are searchable when it's important.

The team needs to build the value on top with custom code. Whether it is old school analytics (most people would call trend charts) or newer analytics (involving supervised machine learning and temporal behavioral analysis), a great deal of security expertise and historical analysis goes into the most reliable detection organizations have built on the data they happen to store in their SIEM. The resource-blessed security team is not operating with default SIEM detection, but rather using its data as source for their complex software, which looks for patterns, and strings together search queries to improve their chances and use the available search capabilities for the investigation. This doesn't mean your team is using the SIEM as a database. The best SIEM solutions out there just allow you to build this custom code on top of their data by providing software development kits. This works extremely well for these exceedingly rare well-staffed teams, but brings none of the effective detection back to the other 95% of businesses who purchase the same SIEM product.

Search and Analytics products should dramatically reduce the customization workload for your team

If you want to detect attacks without staffing a large team with software development skills, you need to seek alternative solutions. For your incident response team to start spending more time hunting and less time building and updating custom software, you need an analytics solution which automates as much of this detection and data enrichment as possible. So do these teams still need a SIEM today? No, but they do still need to satisfy a lot of the use cases:

  • They still need to collect and store the data in a centralized place.
  • They still need search the data (only hopefully with a faster response than today).
  • They still need to leverage this data for detection purposes.
  • They still need to build some alerts very specific to their organizations.
  • They still need a link between their many data sources and threat intelligence.

They just don't need a "SIEM solution" to meet these needs. You can combine a flexible machine data search solution and expansive security analytics solution to meet all of these needs. You should be looking for a single solution combining the two.

If you want to learn about detection without the need for custom code, check out an InsightIDR demo. If searching through machine data is your current need, you can start a free trial of Logentries here and search your data within seconds.