Summary

Basic SIEM requirements should be in place to create mature detections for a variety of log sources, including network logs, system logs, and application logs (including custom applications). This focuses on Security Operations and does not include the engineering side of SIEM management, e.g., licensing, hardware/cloud requirements, retention needs, etc.

Each component of the requirements listed above is essential to a strong detection and alerting program. Here, we’ll break down some basic requirements for a SIEM to build our or enhance a Detection and Alerting program.

1. Log ingestion, normalization, and custom fields
2. Creation of custom correlation rules based on indexed and custom fields and across different log sources
   1. Supports scheduled rule searches
   1. Includes an alert mechanism to notify on rule matches in real or near-real time
3. Data analytics, reporting, and dashboard capabilities
4. Capability to integrate with other security and automation tools
5. Threat intelligence components or integration
   User Behavior Analytics (UBA)

Log Ingestion, Normalization, and Custom Fields

Log ingestion is the most basic requirement of a SIEM because without logs, the SIEM provides no benefit. Logs need to be ingested from a variety of operating systems, application types, and API endpoints. Ingestion timing can be a real-time flow of events or a scheduled pull of events, such as every 15 minutes from an application. The smaller the time window a SIEM pulls events, the more immediate the detection, alerting, investigation, and response can be.

Ingestion alone is not enough; normalization of events from many log sources is critical. The SIEM needs to be able to parse, normalize, and index events after ingestion for common and custom field types.

Following are common field examples and are not a comprehensive list:

The creation of custom fields is essential to mature detections and analysis. Each organization has applications and use-cases that are unique, so a SIEM needs to be flexible enough to allow the engineers to customize parsed fields. The customization should either support a standard parsing format, such as comma separated, or allow for custom parsing profiles for event types/log sources.

As the SIEM ingests and parses events, indexing specific fields will aid both the rules engine and analysts running searches on the front end. It can lower the cost of searches from an I/O standpoint and will also increase the speed of the searches. Fields that should be indexed are those that will be used by the rules engine or in common analyst searches. Indexing every field in an event can overtax resources during ingestion. Ideally, the SIEM should allow for common field indexing as well as flexibility for added custom indexing by the security engineers.

Event Correlation and Rules Engine

A differentiator between a log collector and a SIEM is the ability to correlate events and alert on positive matches using a rules engine. Correlation is what allows alerting on behaviors that could be related to an attack. The rules engine allows for intelligence-based alerting based on more than one event type.

For near real-time alerting, events should be passed through a rules engine after ingestion for correlation. Some SIEMs support scheduled searches and alerting to reduce the overhead on the rules engine at event ingestion, which allows flexibility in deciding how often a rule should be run. This determination should be based on the fidelity of the rule and the expected response of the team receiving the alert.

Some SIEMs come with predefined rules for generic attacks but require tuning to reduce false positives in the environment. The predefined rules are a helpful guide for constructing custom rules using the platform. Understanding the capabilities for tuning existing rules and creating custom rules is an important step for Operations teams when evaluating a SIEM product.

Data Analytics, Reporting, and Dashboards

Complementing the rules engine, a reporting and analytics engine is a powerful resource in a SIEM that should be compared in any SIEM bake-off. A built-in, scheduled report can be used to give insight into activities of interest where custom reports can potentially be used for observing trends to spot anomalies and for security metrics.

Dashboards are the 'single pane of glass' for analysts using the SIEM and can be more than just graphs. Dashboards can be created for different types of investigations where many queries can be run from a single place, rapidly speeding up triage and Incident Response. Look for the ability that allows for shared and individual dashboards to be customized to fit different use cases and allow for custom queries.

Tool Integration

As organizations mature, the need for tools to be more integrated to better detect threats or enrich data from an alert becomes more important. Some SIEMs support integration with Vulnerability Management systems, Asset Management systems, Endpoint Detection and Response products, Data Loss and Prevention, and Automation and Orchestration tools.

When comparing SIEMs, consider how current tools can be used in concert with the SIEM to supply more context to alerts and make a note of the current out-of-the-box integrations, either with tools or by method. Additionally, ask the vendor about integrations on the roadmap that will be implemented in the short and medium-term.

Threat Intelligence

Each organization has specific definitions for Threat Intelligence, which can be utilized in a SIEM in multiple ways.

Threat Feed Alerting

Subscription-based atomic IOCs can result in alerts when traffic is identified to known-bad IP addresses, domains, hashes, etc. Some SIEMs have a broader integration with threat intelligence feeds, while others only integrate with specific feeds. It is necessary to understand the limitations if threat feeds are to be utilized.

Correlation and Enrichment

A threat feed may be used in correlation rules as one of the conditions in the rule. It may also be used as enrichment in alerts providing context of activity, depending on the threat feed. Threat feeds are almost always an additional subscription and can be costly. If the organization is already a subscriber, it is valuable to understand how the tools can be tied together.

User Behavior Analytics

User Behavior Analytics (UBA) can be used to baseline ‘normal’ user activity and detect anomalies in user behavior. This can be used to detect potential insider threats or potentially compromised accounts. UBA works best in an environment where the work activity is somewhat predictable. The ability to select groups of users for UBA in environments is a helpful feature if groups are known to have irregular work schedules.

This component requires care and attention to tune; it is not an out-of-the-box feature that yields immediate benefits. Typically, organizations will have dedicated resources responsible for tuning and monitoring UBA alerts after their Detection and Alerting function is running smoothly.

Conclusion

The needs of individual organizations differ, and the choice of which SIEM solution will work best for a company needs to be made based on the business requirements and the details outlined above. By understanding the essential elements of the organization, the process of evaluating the different SIEM options will be more straightforward.