There is a lot to like in Splunk 4.3 for security use cases, but three items should be of particular interest to security professionals.
Sparklines – Adding Time to Tables for Reporting
I use tables of information in several of the security reports I create. Usually I’ll want to track a particular type of event and include the number of times it happens along with an average over a period of time. This allows me to benchmark a particular threshold and use that as the impetus for an investigation. For example:
I want to track the number of successful accesses against assets where critical data is stored over a twenty-four hour period by user. My table will contain the name of the asset, the identity of the user the number of times it was accessed, and the average number of times it was accessed over the time period. This will allow me to watch for numbers of access attempts I consider excessive for follow-up. Sparklines, a new 4.3 feature, added for each server listed in my table can reflect when over the time period accesses occurred. When I mouse over the peaks in the Sparkline gives me a count at an approximate point in time. As you can see below, most of the accesses occurred in the last 3-4 hours.
So what kinds of conclusions I can draw from Sparklines? In a table, I’m able to increase the information density to visually convey the rhythm of the accesses over a given time period. I can see whether all the accesses occurred all at once or approximately the same time every day in the time period. If they occur with too much rhythmic regularity I might conclude that some automated process is logging in. If I’m tracking access attempts to key business assets and they they occurred from multiple hosts at the approximately the same time it would certainly be worth investigating.
Real-time Backfill for Real-time Views
When you specify monitoring a real-time search in a time-bound sliding window, Splunk takes that amount of time to accumulate data. For example, if your sliding window is 5 minutes, you will not start to see data until after the first 5 minutes have passed. You can override this behavior so that Splunk backfills the initial window with historical data before running in the normal real-time search mode.
For the security professional this means no gaps in visualizations or analysis of security relevant machine data. Real-time and historic data are seamlessly combines into a single view with no gap. Real-time backfill ensures that real-time dashboards seeded with data on actual visualizations and statistical metrics over time periods are accurate from the start.
Easing into IPv6
Splunk now natively supports IPv6. Splunk’s IPv6 support includes the ability to accept, identify, and extract IPv6 addresses in machine log data. IPv6 is supported for distributed search, single sign-on (SSO) and access for Splunk’s web interface. This makes it easy to support and troubleshoot migrations from IPv4 to IPv6.
For the security professional the key difference between these two protocols is that IPsec is ‘built-in’ to IPv6 and can be optionally ‘bolted-on’ to IPv4. This meant for IPv4 extra configuration to add security this version of the protocol. A complete implementation of IPv6 can mean end-to-end connective integrity eliminating the need for network address translation (NAT). For network intruders IPv6 reconnaissance is different from IPv4 reconnaissance. The ping sweep or port scan, when used to enumerate the hosts on a subnet, is much more difficult to complete in an IPv6 network. “A network that ordinarily required only the sending of 256 probes now requires sending more than 18 quintillion probes to cover an entire subnet.” This makes this style of reconnaissance much more difficult and time consuming.
For more IPsec implementation information please see RFC 2401 (http://tools.ietf.org/html/rfc2401#page-1-6)