I’ve seen this problem discussed in a very few amount of places, and let this serve as a warning that what I’m going to discuss here is very niche and definitely not applicable to very many people nor very many security teams out there. But, I believe it’s a problem that many cutting edge security teams are deliberating, and to be honest, it doesn’t really seem like anyone really has the answer yet. Or, if there really is an “answer”. The discussion is centered around the SIEM, specifically the possibility of a Split-SIEM architecture (I guess this is what to call it?). But what exactly is this? Is it a good idea? Why or why not? I’ve found that it really just, well… depends. It depends on what it is you and your team are trying to accomplish. So, let’s jump into it and see why.
The idea of the split-SIEM is to move away from the traditional SIEM architecture. This is where security teams can package their data ingestion, normalization, management, retention, threat analysis, detections, threat hunting, and investigations all under a single roof. This, of course, comes with benefits of reduced friction in security operations, investigations, analytics, exploration, and alerting. And while these may all be good enough reasons to stick with a centralized approach, what does the alluring split-SIEM architecture bring to the table?
The split-SIEM approach provides you foremost with flexibility. It gives you the option to choose products that specialize in different services. Or, if you’re lucky enough to have a technically talented team, the option of building out home-grown, customized products to your environment. With the traditional SIEM architecture, you’re really at the mercy of the vendor you choose - their pricing model, the maturity of their product, their data storage packaging. This can be good or bad depending on the budget, talent, and bandwidth of your team. It could be difficult to figure how to get the most out of your tool of choice, and can also lead to vendor lock later down the road. So, it really does just depend on what you are trying to accomplish, and with those things in mind, what you can accomplish.
One thing I’ve taken away from my career so far, is that it’s generally a good idea to take a step back and take a look at the problem you’re facing from a holistic, top-down perspective before marching to any conclusions. Take the time to think about and consider all the options, put something formal in place to draft requirements, and plan the project with those requirements in mind. This helps to look at the problem from a logical perspective, rather than making an emotional, in the moment decision. Instead of looking at different vendors, getting wowed by the bells and whistles, and pulling the trigger on the sexiest product you see - look at it from a logical perspective. What makes the most sense to build a long-term solution to your short-term problems?
In deciding what architectural decision is right for you, start by laying out your overall goal - what is it you want to accomplish? For this scenario, it’s likely to protect your organization. Next, break that down into more verbose objectives. This is really where it starts to get into the “it depends” territory, and where it will differ from organization to organization. How important is real time analysis to you? How important is it to have an as-code architecture? Take the time to define your objectives, and follow that up by defining the strategies you’ll use to achieve those objectives. What are the main problems you have right now that you want to solve? What do you need to get there? Again, really an “it depends” scenario for you and your team. These strategies trickle down from your high level requirements and allow you to begin drafting out some technical requirements. Look towards the future to figure out what makes the most sense for your team now, and plan for what the organization is striving towards later. Is your organization a high growth company where scaling the team is on the horizon? Or are you certain that you’ll only ever need out-of-the-box security controls in place and will never have the resources to go the more technical/customized route? Since this, again, highly depends on the organization, make sure to take the time to deliberate your requirements to make the best decision for you.
As I’ve thought more and more about this complex scenario, I’ve compiled my thoughts about each approach.
The Traditional SIEM Architecture
In the Traditional Approach, the main benefit I see is convenience - everything is bundled into one package for you. Generally, these solutions will come with native ingestion options, documentation to the problems you may face, and support from the vendor to help achieve your use cases. Not only this, but investigation complexity will be at its lowest in this solution due to the simpler architecture. This means no need to learn where all the logs are sitting, and in turn, no need for multiple query languages. This is also, arguably (heavy emphasis on arguably), the more scalable approach for your organization from a complexity standpoint. It allows your team to onboard new employees easier and gives more flexibility to hire SME’s (Subject Matter Experts) for the specific tool you choose. Out of the box, you can immediately begin focusing on maturing your SIEM product - threat hunting and building out custom detections, automations, and processes. All of this sounds great right? Of course, but it also comes at a cost - literally cost. Centralizing everything can be heavy on the wallet, especially as your organization scales. Not to mention, the inevitable vendor lock. As mentioned before, you essentially become at the mercy of the vendor you choose because as your scale your SIEM, it becomes a massive PITA (if you know, you know) to transition to a new vendor.
The Split SIEM Architecture
The Split Architecture is definitely the more interesting of the two approaches due to the variability in how you can approach it. You can really make the SIEM and your Security Operations team what you want it to be here. First, it allows you to choose the best-in-business for whatever service you find most important to you. Is the DataLake your preferred approach to storing data? Do you want to keep logs native to their place of origin? It allows immense customizability of your environment, and if you have the technical prowess to pull of each of these pieces, this can be done in a completely tailored way to your organization. However, this is likely to come with a lot of problems to solve - a major one in my eyes being investigation complexity. This split approach is going to mean logs can be living in multiple places, and needing to learn a plethora of query languages may be the result of that. These days, every vendor seems to want to make their own spin-off query language, meaning every team member will need to understand how each of the different systems work and how to proficiently navigate the data. This can lead to investigations becoming overly complex, and if your team isn’t ready for it, an incident could take longer to triage than it should - leaving the company vulnerable for longer at the most critical of times. Another issue that will come up is data engineering - how do you want to solve the data ingestion, partitioning, and indexing problems that are likely to come up? Maybe the DataLake is the right move for your team, allowing you to become independent of a SIEM vendor since now you own your own data. But do you purchase a DataLake service, or do you take on the task of maintaining your own? While the DataLake can be the more cost effective option for your team, is your team technical enough to handle this? Or even better, do you want to allocate the resources or even hire an SME to handle this? Building out this split approach is going to take time to mature, especially if you decide to go the route of building custom pieces in different places. But even though it may have many benefits once it’s complete, it’s much more difficult to hit the ground running. And how long will it take to get your custom pieces into a place where you can trust the fate of the company on them? There’s quite a lot to consider with the Split Architecture approach, but with some creativity, I believe this can be a viable option for teams out there with the talent and bandwidth to pull it off.
Conclusion: It Depends...
As you can see, there are arguments for both architectural decisions. It goes to show that it really does just… depend. What’s right for you? I really can’t answer that, there isn’t going to be a one-size fits all answer. But, in my humble opinion, if you are not a highly technical team that is willing to get down into the weeds or a very small team that is unprepared to do some creative problem solving, then the traditional architecture is likely the best approach for you. And don’t get me wrong, this solution can still fill all of your requirements just fine, and it does for so many organizations out there already. But, if you are a highly technical team that has the bandwidth, the split-SIEM is something you may consider. The creative and flexible approach can truly allow you to get the most out of all your data and products. But, that still doesn’t mean the traditional approach isn’t right for you.
This is one of the topics that I’ve been thinking about with my current team, and a holistic view of how we’re approaching the problem. It has taken some creativity and out-of-the-box thinking as there’s really a lot to consider in the search for the “right” answer. But, it really just… depends.
Thanks again for joining us in the Cybersec Cafe to learn about the emerging concept of the split-SIEM architecture. Subscribe to continue to stay tuned about cutting-edge technology in the cybersecurity space, and stay-tuned to more exciting things being brewed in the Cybersec Cafe!
Comments