5 Things to Know When Choosing Open Source SIEM Tools

Security Information and Event Management (SIEM) tools focus on insights into IT environments and tracking records of all their operations. These IT environments can be application infrastructures, physical networks, and cloud networks. SIEM initially evolved from the log management discipline, which involved integrating security events with security information to collect, analyze, and report on activities in networks. SIEM tools accomplished this goal by analyzing logs and event data to provide threat identification, event association, and incident response.

In this decade of data explosion, the data an organization collects, stores, and manages is its most valuable possession. Because every data loss can have disastrous implications, R&D organizations have realized that implementing a SIEM tool to identify and alert on security incidents is critical. Different R&D organizations use different methodologies for choosing security management and security monitoring tools. Teams oft ask whether or not they ought to implement a managed SIEM system. A managed SIEM system provides an instant solution for the company’s security requirements, but it has functionality limitations. Their other option is an open source tool which can be developed into an adjustable solution that suits the company’s specific needs.

This article will examine open source SIEM options, presenting five important concepts to consider when implementing one.

Choosing an Open Source SIEM System

When building a company’s security agenda and establishing its standards, R&D teams need to know what the company’s primary asset is, what the threats to it are, and what possible attack vectors might exist. They should plan and build the security architecture and methodologies based on the protection of this asset. The security of more minor assets should integrate into the architecture and select security tools.

Once all of the security requirements are clear and planning starts, the next step is choosing an open source tool. In making their decisions, security and application architects should consider two elements of these tools: their architectures and capabilities.

On architecture, the SIEM tool should work within the environment and provide monitoring for the application components. For instance, many open source SIEM tools aren’t fully compatible with cloud environments. Consequently, they can’t work with modern applications.

Also keep in mind these tools’ capabilities and whether or not they meet the organization’s security requirements. Not all tools offer a complete package of log management, aggregation, data visualization, and incident response automation. That goes double for other features like third-party integrations or meeting compliance standards. While most tools come with some of these capabilities, some don’t even provide essential SIEM capabilities. Those might include event correlation or automatic threat intelligence updates (for proliferation, evolution, and resolution).

Once these aspects have been considered, there are five more points teams must keep in mind, as detailed below:

1. Total Cost of Ownership

Many software organizations choose to work with an open source tool for budgetary reasons. They believe that because they’re not paying for the tool and that there’s ‘no cost’ in implementing it. However, it’s a well-known fact that “open source” does not mean “free.” The need for code adjustments, continuous upgrades to newly released versions, deployment management, maintenance, and the preservation of code integrity can elevate the actual cost. This is true with the true cost of open source SIEM tools, as well as operational cost of OSS logging and monitoring metrics with open source tools. In fact, sometimes that cost can be higher than that of a commercial product or managed solution.

There can be great value to freeing up the security team from tasks like keeping the SIEM tool’s vulnerabilities knowledge base current, which can be easily done using tools that integrate the SIEM tool with big public CVE databases. If R&D doesn’t have to worry about the stability and scalability of both the SIEM tool and the application, development and maintenance effort can be saved during the crucial time just before the application’s release to production. It’s worth considering whether or not your organization is willing or able to take on full ownership of a SIEM tool, since it’s a complex mission with many recurring tasks.

2. Deployment and Operational Overhead

Building and maintaining a deployment pipeline for a SIEM tool is a labor-intensive process. In addition to building the code and deploying the tool—whether it’s container-based or a system service—DevOps must take into account the need to conduct a security review and test the new code.

The next step is to configure and integrate the tool in order for it to work. If the newly-deployed version of the SIEM doesn’t work properly, DevOps has to rollback changes to keep the production environment online. These are all basic steps that must be performed as part of the CI/CD process.

Infrastructure costs are another overhead expense associated with the use of SIEM tools. As with other software applications, a SIEM’s reliability comes from its capacity to scale automatically—horizontally and vertically—in order to handle high loads on a system. You have to monitor the monitors, as it were, for performance, for their own security, and to address issues as they arise. This is especially true for organizations with high traffic that require both strong compute resources and high storage availability for compliance with log history requirements.

3. Security Analytics and Behavioral Capabilities

According to Exabeam, “Security analytics is a proactive security approach that uses big data analytics and machine learning to gather, categorize, and analyze data collected from network devices to detect advanced threats.” Exabeam argues that security analytics is one of the most important services a SIEM tool should provide.

By the way, for more on this difference, read our Security Analytics vs. SIEM article. 

Not all open source SIEM tools provide security analytics. Furthermore, the ones that do won’t always include all the required analysis and segmentation abilities. Security teams must be aware of these limitations and be ready to do additional in-house development to fill the gaps.

4. Automation and Integration Possibilities

Incident management is a broad methodology giving R&D, DevOps, and security teams guidance for responding to a variety of events in production environments. Automating some incident response operations—like alerting, sharing incident information through collaboration tools, and performing initial responses—improves response time and, along with it, the credibility of the organization and company. It also saves human effort, avoids employee frustration, and increases everyone’s trust in the application’s stability.

Not all open source tools come with automation capabilities. Apache Metron, MozDef, and OSSec are some of the most well-known open source SIEM tools that lack this important capability. These tools require additional development to support response automation. In addition, not all open source tools that do have automation capabilities necessarily integrate with all other tools. This inflexibility can affect the tool’s response to events or prolong the time it takes to identify incidents.

5. Data Exploration and Analysis Possibilities

In a previous article, we discussed how important it is for a SIEM tool to be able to collect data from multiple systems and detect patterns in that data. Every SIEM tool should have this capacity for the security incident identification process to work smoothly. The issue with some open source SIEM tools is their fragile and incomplete integration with data sources. Either the tool doesn’t have all of the data nor see the full picture, or its analysis abilities are imperfect. That might leave an event unregistered as an incident.

Conclusion

The software industry is quickly becoming an open source community. Many tools are seeing full or at least partial release as open source products. They can also serve as application infrastructures, dependencies, or as parts of applications. Security tools are no different. However, it’s important to remember that security has different meanings and different requirements in different organizations. While open source security tools — especially SIEM tools — can provide solutions to some of an organization’s security needs, extra effort and planning is often necessary to ensure that the implementation of these tools will offer real value.