Security, et al

Sometimes we get hung up on event monitoring and forget about the “I” in SIEM which stands for information. And that’s important because there are more sources of non-event security information that your SIEM should be ingesting and correlating with security events than ever before. There’s at least 4 categories of security information that you can leverage in your SIEM to do 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 you sift the wheat from the chaff in your security logs. Here’s one example. Let’s say you regularly import a list of all members of Administrator groups from Active Directory into your SIEM and call the list PrivliegedAccounts. Now, enhance any rules or reports looking for suspicious user activity by also comparing the user name in the event against the PrivilegedAccounts list. If there’s a match, then the already suspicious event becomes even more important since it involves a privileged user. But you also likely have certain control over privileged user sessions. The PrivilegedAccounts list helps you identify anyone (internal or external) bypassing those controls whether a malicious insider or an outside attacker 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 PrivilegedAccounts but was 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 which also have a bad reputation for cybercrime and espionage. Another popular way to leverage geocoding is to detect when a given user is apparently in 2 places at once which can indicate compromised credentials.
   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.

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 look at the free feeds available from ermergingthreats.net in this webinar sponsored by 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.

4. Internal threat intelligence.
   A. N. Ananth (EventTracker) 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 and threat intelligence from the security community and internal.

This article by Randy Smith was originally published by EventTracker

http://www.eventtracker.com/newsletters/enriching-event-log-monitoring-by-correlating-non-event-security-information/