Everyday, IT operations generate a myriad of data in which much security-relevant information is hidden. However, it is impossible to extract any meaningful information from this flood of data manually. Security Information and Event Management (SIEM) systems therefore are designed to give administrators improved insights into the IT security status across an organization. This can only work if the people responsible for IT observe several important basic rules when designing the SIEM system and the sensor architecture. In this article, we introduce readers to the fundamental points to be considered when choosing a SIEM system and designing its interaction with data sources and downstream systems.

Well-organized monitoring does not just cover classic indicators such as availability, use levels, and service and system response times; it also reveals the current status quo in terms of IT security. An important precondition is that security-relevant logfile entries from applications and dedicated security components, such as Intrusion Detection Systems (IDSs), are centrally collated, correlated, and holistically evaluated. SIEM systems specialize in performing this task, and several open source and commercial tools have asserted themselves in this field.

Important Selection Criteria

As with other monitoring tools, functionality, scalability, and cost are the three obvious criteria for selecting a SIEM product. In terms of functionality, the products mainly differ in terms of features whose usefulness and necessity should be investigated within the context of your own application scenario. Unfortunately, this rule also applies to missing features: For example, pervasive support for IPv6 is still rare even nearing the end of 2015.

Scalability is typically measured as the number of security messages per second that the SIEM can field and process. Some open source and community editions have been deliberately reduced to a two-digit number of events per second (EPS) and are thus only suitable for smaller environments or for very selective deployment. For commercial products, which receive net flows from routers, six-digit EPS counts are not unknown, and they are often used as the basis for calculating license costs.

SIEM Architecture

Figure 1 shows the typical architecture of a SIEM system: It uses SIEM collectors to integrate a variety of data sources (e.g., servers, network components, management systems, firewalls, and IDSs) and converts their security messages into a uniform, SIEM-internal format. SIEM processors correlate these messages across all systems and evaluate them based on rules.

Figure 1: Architecture of a SIEM system with data sources and downstream systems.

Like most state-of-the-art products, the SIEM front end is web-based; administrators use it to configure the system and evaluate identified security issues interactively. Most SIEM systems manage these in a kind of ticket system, thus supporting drill-down views of the triggering messages from the data sources. Downstream systems can be actuated for alerts and automated responses. A scripting interface or an API, which will be more or less powerful depending on the product, lets administrators manage the SIEM data sets with their own code to complement interactive work with the SIEM system.

Tasks of SIEM Basic Configuration

The preconditions for this include, for example, populating the SIEM's internal asset management set – ideally by connecting the SIEM to an existing DCIM solution or configuration management system. The criticality of the individual systems and basic properties, such as the operating system and the position on the monitored network, can be derived from this. When an IDS reports an attack that exploits a current Windows vulnerability, the SIEM system can respond differently if the target happens to be a critical Windows server on the production network than if it were a Linux server in the test lab.

The overhead for creating this basic information is high, especially if the data cannot easily be imported from existing systems. As an alternative, many products include an automatic discovery function, but you should only use this if you can be sure of avoiding inconsistencies with other data sets. Inconsistencies can cause more overhead in production than you would save compared with some other kind of import or manual entry.

You will also want to define up front which users can work with the SIEM system and what authorizations they will have. Connections to central authentication instances, such as an LDAP server or Active Directory, are part of the standard feature set. Because drill-down options can reveal sensitive details from logfiles and IP packets, the need-to-know principle will drive many individual authorizations.

Many SIEM front ends give the user neat-looking dashboards with overviews and statistics, which are also likely to interest managers and decision makers. However, you will not want to confuse this user group with in-depth technical details and processing options. Because major retroactive changes to roles and authorizations can have unwanted side effects, it makes sense to experiment with the intended settings in a trial set up.