According to OpenLogic’s “State of Open Source” report, 96% of surveyed organizations use open-source solutions (OSS). Such solutions can be found in every segment of the IT market — including infosec tools. And they’re often recommended for building SIEM systems.
At first glance, OSS seems like a great choice. A SIEM system’s primary function is systematic telemetry collection and correlation, which you can set up using well-known data storage and processing tools. Just gather all your data with Logstash, hook up Elasticsearch, build the visualizations you need in Kibana — and you’re good to go! A quick search will even get you ready-made open-source SIEM solutions (often built on the same components). With SIEMs, adapting both data collection and processing to your organization’s specific needs is always key, and a custom OSS system offers endless possibilities for that. Besides, the license cost is zero. However, the success of this endeavor hinges on your development team, your organization’s specifics, how long your organization is willing to wait for results, and how much it’s ready to invest in ongoing support.
Time is money
A key question — one whose importance is consistently underestimated — is how long it’ll take before your company’s SIEM not only goes live but actually starts delivering real value. Gartner data shows that even a fully-featured, ready-made SIEM takes an average of six months to fully implement — with one in ten companies spending a year on it. And if you’re building your own SIEM or adapting an OSS, you should expect that timeline to double or triple. When budgeting, multiply that time by your developers’ hourly rates. It’s also hard to imagine a full-fledged SIEM being by a single talented individual — your company will need to maintain an entire team.
A common psychological pitfall is being misled by how fast a prototype comes together. You can deploy a ready-made OSS in a test environment in just a few days, but bringing it up to production quality can take many months — even years.
Skill shortages
An SIEM needs to collect, index, and analyze thousands of events per second. Designing a high-load system, or even adapting an existing one, requires specialized and in-demand skills. Beyond just developers, the project would need highly skilled IT administrators, DevOps engineers, analysts, and even dashboard designers.
Another kind of shortage that SIEM builders have to overcome is the lack of hands-on experience needed to write effective normalization rules, correlation logic, and other content that comes out of the box in commercial SIEM solutions. Of course, even that out-of-the-box content requires significant adjustments, but bringing it up to your organization’s standards is both faster and easier.
Compliance
For many companies, having an SIEM system is a regulatory requirement. Those who build an SIEM themselves or implement an OSS solution have to put in considerable effort to achieve compliance. They need to map their SIEM’s capabilities to regulatory requirements on their own — unlike the users of commercial systems, which often come with a built-in certification process and all the necessary tools for compliance.
Sometimes, management might want to implement an SIEM just to “tick a box”, aiming to minimize the expense. But since PCI DSS, GDPR, and other local regulatory frameworks focus on the actual breadth and depth of SIEM implementation — not just its mere existence — a token SIEM system implemented just for show would fail to pass any audit.
Compliance isn’t something you can consider only at the time of implementation. If, during self-managed maintenance and operation, any components of your solution stop receiving updates and reach end-of-life, your chances of passing a security audit would plummet.
Vendor lock-in vs. employee dependence
The second most important reason for organizations to consider an open-source solution has always been flexibility in adapting it to their specific needs, along with avoiding reliance on a software vendor’s development roadmap and licensing decisions.
Both of these are compelling arguments, and in large organizations they can sometimes outweigh other factors. However, it’s crucial to make this choice with a clear understanding of its pros and cons:
- OSS SIEMs can be simpler to adjust for unique data inputs.
- With an OSS SIEM, you maintain complete control over how data is stored and processed.
- The cost of scaling an OSS SIEM primarily consists of prices for additional hardware and the development of required features.
- Both the initial setup and ongoing evolution of an OSS SIEM demand seasoned professionals who are well-versed in both development practices and SOC realities. If the team members who best understand the system leave the company or change roles, the system’s evolution might come to a halt. What’s worse, it gradually becomes less functional.
- While the upfront implementation cost of an OSS SIEM might be lower due to the absence of license fees, this difference often erodes during the maintenance phase. This is because of the continuous, additional expense of qualified staff dedicated solely to SIEM development. Over the long term, the total cost of ownership (TCO) for an OSS SIEM often turns out to be higher.
Content quality
The relevance of detection and response content is a key factor in an SIEM’s effectiveness. For commercial solutions, updates to correlation rules, playbooks, and threat intelligence feeds are typically provided as part of a subscription. They’re developed by large teams of researchers, undergo thorough testing, and generally require minimal effort from your in-house security team to implement. With an OSS SIEM, you’re on your own when it comes to updates: you need to search community forums, GitHub repositories, and free feeds yourself. The rules then require detailed vetting and adaptation to your specific infrastructure, and the risk of false positives ends up being higher. As a result, implementing updates in an open-source SIEM demands significantly more effort from your internal team.
The elephant in the room: hardware
To launch an SIEM, you need to acquire or lease hardware, and depending on the system’s architecture, this expense can vary dramatically. It doesn’t really matter much whether the system is an open-source or proprietary commercial solution. However, when implementing an open-source SIEM on your own, there’s a greater risk of making sub-optimal architectural decisions. In the long run, this translates into persistently high operational costs.
We cover the topic of evaluating SIEM hardware needs in detail in a separate post.
The final tally
While the idea of a fully customizable and adaptable platform with zero licensing fees is highly appealing, there is a significant risk that such a project would demand far more time and effort from your internal development team than an off-the-shelf commercial solution. It may also hinder your ability to quickly adopt new innovations and shift your security team’s focus from developing detection logic and response scenarios to dealing primarily with operational issues. This is why a managed, expert-supported, and well-integrated commercial solution often aligns more closely with a typical organization’s goals of effective risk reduction and predictable budgeting.
Commercial SIEMs enable your team to leverage pre-built rules, playbooks, and telemetry parsers, allowing it to focus on organization-specific projects — such as threat hunting or improving visibility in cloud infrastructure — instead of reinventing and refining basic SIEM features, or struggling to pass regulatory audits with a homegrown system.