Tips · 9 MIN READ · MATT PETERS, DAN WHALEN AND PETER SILBERMAN · SEP 22, 2020 · TAGS: MDR / SIEM / Tech tools
Updated July 5, 2023
Spin up a conversation about someone’s security operations and chances are the conversation will quickly move to their security information and event management (SIEM) tool.
A SIEM can play an important role in your security strategy.
But figuring out where it belongs (and what type of SIEM is best for you) depends on a few things.
So, where to begin?
We’ve pinpointed three steps that can help you figure out where a SIEM fits within your security program. This post walks you through each of these steps and we hope it will help you decide what makes the most sense for you, your team and your business.
Step 1: Figure out where you are on your SIEM journey
Working with different customers, we’ve seen most orgs fall into one of three different categories.
Which one are you?
Just getting started
Maybe you’re just starting to get serious about security or you reached an inflection point and are looking for a SIEM to take your security program to the next level. You’re optimistic about the prospects of a SIEM and how it can help address some of your pain points, whether that’s addressing visibility gaps or keeping your auditors happy!
As you explore all of the SIEM options out there, you’re pretty quickly realizing there are a ton of opportunities (especially around automation) but it’s also hard to get a handle on what factors should influence your decision. You may also be wondering: if it’s so easy to automate why isn’t everyone doing this successfully? You’re excited to bring in a SIEM and up level your team but you’re also wondering what pitfalls you should avoid and how to steer clear of a path that will end up costing too much and bogging down your team with low value work.
Doubling down
You’ve had a SIEM or two (or three) and know what it takes to keep it singing. You’ve learned through trial and error what works, what doesn’t and the level of investment (people and money) you need internally (or through third-party partners) to accomplish your use cases. You’ve also had time to really figure out what use cases matter to you. All of those flashy selling points you thought would be a great value add? You’ve come to terms with the fact that many of them aren’t for you. You know what you want of your SIEM and are looking to get the most you can with your existing investment – this could mean dedicating internal resources to managing your SIEM or looking outward for help.
Disillusioned skeptic
You aren’t sold on the tale that a SIEM can solve all of your security woes and you aren’t afraid to talk about it. How did you get here? It may have had something to do with your past experiences – you’ve tried to make a SIEM work in the past and have gotten burned. Maybe the product (or products) didn’t do what you wanted, or it ended up costing way more than you could justify.
Regardless, you now view your security program more holistically and don’t see a SIEM as the single source of truth. Sure, there are use cases where it makes sense (you may still have a SIEM kicking around in a corner for your application and OS logs) but you’re reluctant to hinge the success of your security program on a single solution. You prefer to rely on your various security products and services to get you the visibility and response capabilities you need to be successful.
Now that you’ve figured out where you are in the SIEM journey, it’s time to move on to the next step!
Step 2: Determine what use cases are most important to you
No matter where you are in your journey, it’s important to clarify (and often re-clarify) what you ‘re expecting your SIEM to do. You can make a SIEM do just about anything with enough effort (and consultants and money) and that’s exactly what many organizations have done.
Don’t know where to begin? Consider the following use cases and who (you or a third-party) you envision taking responsibility:
| Use Case | Description | Examples |
|---|---|---|
| Compliance and reporting | Do you have regulatory requirements for retaining certain types of data? A SIEM could help you aggregate all of this required data and make it easy to satisfy audit requirements. |
|
| Threat Detection | Depending on the maturity of your security program, you may have the need/desire to write your own detection rules. A SIEM can provide these capabilities, but also requires a definite investment in content management.
Consider if you want to invest in internal teams to write and maintain detection rules or whether you want to leverage security products or services to accomplish this use case. |
|
| Investigative support | A SIEM can be a powerful investigative tool if it’s fed with the right data and given the love and attention it needs. Using a SIEM for investigation is a very common use case, whether you’re investing in an internal team or partnering with a third party to respond to your alerts.
For this use case, consider how easy it is to add new log sources and how intuitive/fast searching that data is. An easy and fast search capability will empower your analysts to get to the bottom of an alert without unnecessary frustration. |
|
| Response Automation | Containing and remediating an incident can be challenging, especially in large enterprise environments. If this is a challenge for your organization, consider how you can apply technology to this problem. Some SIEM technologies have built in response capabilities or SOAR integrations that can help in this area.
As you explore these options, pay close attention to the level of effort required to configure these tools and make sure your investment will actually help solve your problem. Also consider who you want to be responsible for managing the tool (you vs third party). |
|
| Case Management | Who did what and when? As your security program matures, process becomes more important.
Once you have multiple analysts responsible for responding to alerts, knowing “who’s got it” and how issues were resolved helps you understand what’s happening across the environment. You can communicate that upwards to drive change. As you think about this use case, you’ll need to decide where you want incident management to occur – is it in your SIEM, a ticketing system or is a partner/third-party service responsible for managing alerts? |
|
Step 3: Know what type of SIEM you have (or want)
Finally, whether you have a SIEM or are going shopping for one, it’s important to first understand use cases. Once you identify your needs, you can figure out which SIEMs are best for you.
Traditional SIEM
Traditional SIEMs are typically large, multifunction applications. They tend to have highly structured data models (think SQL vs full text indexing) which enable certain types of use cases but make others more difficult. If given proper care, they can be very powerful but often aren’t very flexible to changing requirements over time.
Sample Vendors: QRadar, Arcsight, LogRhythm
What are they good at?
- Highly oppinated data models make querying data and writing detections easy (once you understand the data model)
- One “right” way to do things keeps things relatively simple (accessibility is often better)
- Often come with a lot of out of the box features for detection, compliance and reporting
- Strong incident management feature sets, are a good candidate for “single source of truth”
- Products have been around for a long time and are generally mature and stable
What are some common pain points?
- Hampered solutions (limited by opinionated data models/vendor’s way of doing things)
- For on-prem installations, management can be a significant investment, so you need to plan for that
- Slower to accommodate new use cases/features and can become “behind the times”
Search-based SIEM
Search-based SIEMs are essentially a log aggregation and search tool first with other features added on top of that core function. They have flexible data models and everything is driven by a search from rules to reporting and dashboards. But they often require a lot of expertise to satisfy certain use cases (like detection) – meaning you’ve got to live and breathe their search language to see value.
Sample Vendors: Splunk ES, Sumo Logic, Exabeam
What are they good at?
- Strong investigative support due to powerful search capabilities
- Flexible and accommodating for new use cases
- Often easier to manage (particularly for cloud-based/SaaS products)
What are some common pain points?
- Incident management feature sets often lag behind traditional SIEMs as they have a less structured data model
- Requires expertise to accomplish your use cases (you need to be an expert in their search language)
DIY SIEM
TL;DR – you’re starting from scratch.
DIY SIEM options are usually open source projects organizations invest in and build additional tooling around. These options offer a lot of flexibility and can be much more cost effective, however they require a significant investment in engineering and in-house security expertise to build out security use cases.
Sample Vendors: Elastic stack, OSSIM
What are they good at?
- Potential long-term cost savings (if you have significant in-house expertise to build and manage)
- Flexibility: You have complete control over the solution and can build out the use cases you need
What are some common pain points?
- Organizations often realize they’ve “bitten off more than they can chew” in terms of engineering and security expertise required to build and manage a DIY SIEM
- On-going operational cost of maintenance is on your internal team instead of a third party, which potentially distracts you from the things that are important to your business
- Open source options are often significantly limited in feature sets and deployment size
- May not be compatible with security services (if you ever choose to partner)
Augmented SIEM
Instead of sending all logs to your SIEM, what if you could mindfully decide which needed to be there and which might be better suited for direct API connection? We try to let our direct API connections shine, and let the SIEM provide real value for tech that doesn’t yet have a solid API, or detection engineering for org specific use cases.
Sample vendors: Expel
Why we like it:
- Our direct API connections allow for robust investigative leads for our SOC and, depending on compliance requirements, may eliminate the need for ingesting noisy log sources (like cloud providers AWS, Azure, or GCP)
- Analysts have the freedom to think deeply about detection engineering and work on tailored detections
- The SIEM becomes the backstop for direct integrations, allowing us to query the sources during investigations or create detection strategies layered on top of the SIEM
Things to watch out for:
- If you have compliance requirements related to log retention, you still may need to keep the SIEM in place, or you might consider offloading the logs to long-term, infrequent retention solutions like S3 Glacier (which could result in significant cost savings)
- Detection engineering comes with its own set of potential pitfalls, so make sure you’re testing and validating rules as part of the development process
No SIEM
Some organizations forgo a SIEM altogether. This may be an option in cases where your use cases can be satisfied with other existing tools or partnerships with third party services. For example, if you have no regulatory requirements and have limited log sources (perhaps a few SaaS applications) there may be no good reason to invest heavily in a SIEM if a third party like Expel can address your use cases directly!
Sample Vendors: Expel and other similar MSSP/MDRs/XDRs
What are the advantages of forgoing SIEM?
- One less security tool you have to pay for
- Reduced complexity and less responsibility
What are some reasons you might need a SIEM?
- Regulatory requirements
What’s your next step?
There’s a lot to consider as you think (or re-think) how a SIEM should fit into your security program. By identifying where you’re in your SIEM journey (and where you want to go), prioritizing use cases and choosing the right SIEM product, you can set your team up for long term success.
There’s likely no “one-size-fits-all” solution, but here are some common models we’ve seen:
SIEM model cheat sheet (steal me!)
Decentralized model
Some organizations do not have a significant need or desire to invest in a SIEM. These organizations may still have a SIEM off in a corner somewhere for a very specific purpose, but it is not central to their security program. Instead, security signal is often consumed directly from security products or from a third-party monitoring service like Expel.
Hybrid model
A SIEM can help layer additional capabilities on top of existing security controls. A hybrid approach (where a SIEM is used in combination with other security tools) can help deliver capabilities that are “best of both worlds.”As an example, many organizations choose to use their SIEM for investigation and compliance, but rely on their security products for detections and a ticketing system for incident management.
A service like Expel in this model can help by integrating with all of the various sources of signal directly while leveraging the capabilities of the SIEM to provide visibility across the environment.
Centralized model (single pane of glass)
In this model, the SIEM is the center of the organization’s security program. The organization is investing significantly in their SIEM and wants it to be the place where everything happens – from alerting to response and incident management. This model requires expertise, either internal or third party (like a co-managed SIEM service) to succeed.
It also requires that all security signals be routed through the SIEM for detection and response. This is an expensive but effective approach for large security teams that have the resources to go this route. Organizations considering this approach should consider their use cases carefully and ensure the long-term investment is worth it! In many cases, the same use cases can be accomplished with a hybrid approach at a lower cost.
Parting thoughts
We’ve seen all of these models work. Your decision depends on what makes sense for your business. The key to success is understanding what is important to you and what options you have in front of you. We’ve gone through this very process at Expel and hope this framework can work for you too!
Want to talk to someone before making a decision about your information security? Let’s chat.
