Seeing Eye

Using the Right Data Sources

Connecting the actual SIEM data sources follows two similar goals that build on one another. For one thing, the security messages of the maximum possible relevant systems should be collected at a central point. This reduces the overhead on each individual system when searching through logfiles for security-relevant entries, for example. Moreover, you will want cross-system correlation to be able to detect and understand more complex attack patterns, whose individual components could be lost in the background noise on the individual systems.

You have various options for transferring the data from the individual sources to the SIEM system – from configuring the SIEM system as a central logging server, through installing SIEM agent software on the source systems, to regularly polling entire logfiles with some help from secure copy or SFTP. Each SIEM system comes with support for widespread logfile formats out of the box. Logfile entries with any other formatting will necessitate an additional parser configuration, which can be created using a simple rule-based language or regular expressions, depending on the SIEM vendor.

Data sources are typically cascaded hierarchically in the connection to the SIEM system: For example, if you already have a centralized logging server that several servers and services use, only the logging server is connected to the SIEM system rather than each individual server. If, for example, you need to evaluate malware found on workplace PCs and other clients, it makes more sense to connect the central antivirus management server to the SIEM system than to connect each individual client.

Independent of the limits set for evaluating the data volume, when you introduce a SIEM solution you need to consider which data sources actually make sense. As a general rule, you should only integrate sources whose messages can be evaluated automatically through analysis and correlation rules or that are regularly of interest when you check and process security incidents manually. For SIEM products by vendors of network equipment in particular, the typical feature set includes the ability to feed in net flow information from IP routers in addition to various logfiles from servers, network components, and security components.

Some vendors combine their SIEM systems with deep packet inspection-capable IDSs and can thus handle Layer 7 evaluations. The benefit here is the integration of various security functions in a common user interface. For example, if you notice – from communication with a known command-and-control server on the Internet – that a system is compromised and infected with malware, you can quickly identify any other unusual communication targets the machine has had.

In addition to more passive actions like receiving or polling security messages from the data sources, many SIEM systems also include active mechanisms for information acquisition – or a least you can retrofit these as modules. The spectrum ranges from relatively simple port scanners like Nmap up to complete vulnerability management solutions in which the monitored systems can be periodically, or at the push of a button, checked through scanning with tools such as OpenVAS. The findings you gain here will not just help with investigating reported security incidents, they are also stored in the SIEM's internal asset database and can be referenced for analyses and correlations later on – in particular for prioritizing the assessment of alerts.

A Neat GUI Is Not Everything

The application focus of today's SIEM products is interactive evaluation of identified security problems. SIEM products differ greatly in terms of their control philosophy and the technologies used to design the user interface (Figure 2). Intuitive and efficient handling of the SIEM GUI is thus typically an important acceptance criterion for a SIEM product – unresponsive web interfaces or the lack of support for right-clicking – can quickly become productivity killers.

Figure 2: Typical SIEM dashboard view with a focus on monitored signatures.

In addition to processing security incidents, a main aspect of daily work with the SIEM system is ongoing optimization of the rulesets, with a view to avoiding unnecessary messages and false positives and thus allowing the security team to focus on the genuinely important cases (Figure 3). This means that you want in-depth information, the ability to find similar cases, and the ability to trace precisely why the message was thrown at all, based on analysis and correlation rules, in the SIEM GUI. In acute cases, in which you can monitor ongoing attacks, the latency with which new messages can be viewed in the SIEM GUI will also be critical. More or less real-time-capable SIEM systems have advantages over products that only process incoming data in batches at predefined intervals.

Figure 3: View of a SIEM dashboard with the sources and targets of security incidents.

Automation Simplifies the Daily Grind

Administrators often lack the time to check the SIEM GUI regularly and proactively to see whether important new messages have arrived. SIEM systems thus typically provide a configurable escalation system that, for example, sends regular email to remind the administrator that important messages have not been processed. Another important feature is the ability to define exception rules to specify which types of incidents or affected systems should not generate alarms, thereby avoiding a flood of email.

Because the response to many security incidents will be very similar, it makes sense to automate at least the non-critical ones. Although some SIEM products (e.g., various monitoring systems) primarily serve as data sinks, others offer the ability to trigger arbitrary scripts and programs to which the individual parameters of the incident are passed or made accessible via a programming interface.

For example, if a PC on your network exhibits characteristic malware communication behavior, that PC could be blocked – in addition to alerting the responsible administrator – by a script at the Internet uplink firewall or directly at the switch port of the office in question, thus avoiding more serious damage. As with any automated response, you must make sure that an attacker cannot misuse this response to cause even more damage (e.g., through a denial-of-service attack).