Sometimes we get hung up on event monitoring and forget about the “I” in SIEM which stands for information. Not forgetting Information is important because there are many sources of non-event security information that your SIEM should be ingesting and correlating with security events more than ever before. There’s at least 4 categories of security information that you can leverage in your SIEM to provide better analysis of security events:

1. Identify information from your directory (e.g. Active Directory)

Your directory has a wealth of identify information that can help sift the wheat from the chaff in your security logs. For example, let’s say you regularly import a list of all the members of Administrator groups from Active Directory into your SIEM and call the list Privileged Accounts. Now, enhance any rules or reports looking for suspicious user activity by also comparing the user name in the event against the Privileged Accounts list. If there’s a match, then the already suspicious event becomes even more important since it involves a privileged user. In many cases you’re likely to have certain control over privileged user sessions. The Privileged Accounts list helps you identify anyone bypassing those controls whether a malicious inside or outside outside attacker is ignorant of your controls. Perhaps you require all administrators to go through a clean and hardened “jump box”. You can setup a rule to identify logon sessions where the username is in Privileged Accounts but not initiated from the jump box.

2. Environmental information (both internal and global)

A global example of environment information is geocoding. Perhaps there are certain countries that you do not do business with due to their bad reputation for cybercrime and espionage. Another popular way to leverage geocoding is to detect when a given user is apparently in two places at once which can indicate compromised credentials.

3. Threat intelligence feeds available from security organizations

There’s a growing array of threat intelligence feeds ranging from community-based free feeds to those commercially produced and available for a fee. These feeds range from lists of IP addresses linked to command and control networks, botnets and compromised hosts to network indicators of compromise and malware signatures. We recently looked at the free feeds available from emergingthreats.net in our most recent webinar with EventTracker. Correlating event logs from all levels of your network to threat intelligence can help you identify compromised systems and persistent attackers much earlier in the process.

But you can also leverage organization specific (i.e. internal) environment information. For instance, perhaps all of your administrators’ workstations fall within a certain range of IP addresses. Use this information in a rule examining logon attempts to your jump box or other hardened infrastructure systems (such as the management network interface on ESXi and HyperV systems) and alert when you see attempts to access these systems from non-administrators. (As always, the real world may be a little more complicated. Case in point: you may also need to factor in logon attempts through whatever means administrators use for remote access.)

4. Internal threat intelligence
EventTracker CEO, A. N. Ananth coined this term to describe information that you can compile from your own network and systems using similar techniques as outside threat intelligence organizations. There’s no arguing the “crowd-sourced” value of external threat intelligence but such information is missing a key aspect that is addressed by internal threat intelligence. External threat intelligence tend to be “black lists” of “known bad” data. On the other hand, internal threat intelligence usually take the form of “white lists” of “known good” data. White lists tend to be much smaller, more effective and easier to tune and maintain. For instance if your SIEM can determine from past history that server A normally only communicates with 10 other hosts – that is very valuable to know – especially if your SIEM can alert you when it sees that host suddenly start sending gigabytes of data to an entirely new host on an unusual port.

The bottom line is that your SIEM needs as much data (both event and non-event) as possible and it needs to be effective at correlating it into valuable situational intelligence. Don’t stop at logs. Look for other kinds of security information from your directory, the local and global environment, threat intelligence from the security community and from the internal.