SIEM Thing, Different Day

The uptake of Security Information and Event Management (SIEM) technology in large enterprises is nearly ubiquitous. Today, there are very few large companies without a SIEM, and in fact most find themselves with multiple SIEM implementations, gained through mergers/acquisitions or organizational fractures.

However, what is often less established is a plan to capitalize on SIEM technology, amazing since the SIEM solution has likely taken months to implement and has cost a fortune.

First of course the SIEM is attached to an existing 24×5 or 24×7 Security Operations Center (SOC). Difficulty? Even with a very large staff of 12 FTEs or more, there may be only two or three security engineers on duty at any given time, plus some callout escalation or Incident Response resources. But SIEMs in large enterprises literally collate billions of events per day. The SIEM can organize and categorize these into high and medium priority events, but there will almost certainly still be thousands or tens of thousands of records that need to be examined by the SOC engineering team every single day.

This is where an effective workflow from the SIEM becomes critical. If a SOC engineer only has the log and meta-data resources, he has to conduct a long examination of the high priority events, often involving guess work to jump from meta data to full fact. If he has to potentially examine hundreds of such events per day, and each is time-consuming, he will have no choice but to quickly disregard many. To maximize the value of what the SIEM has told him, he needs fast and precise forensics in two areas: hosts and network.

Host forensics primarily consists of continuous surveillance on employee workstations. Ultimately, most security events involve an ordinary user workstation being compromised and becoming a command-and-control beachhead for the attacker. An effective host-based surveillance system silently records all key host events like network session data, name lookups, registry changes, file executions, file writes and the like, whether or not they seem suspicious at the time.

The SOC engineer should be able to click on an event in the SIEM and link with context into the host solution to examine circumstances around the time of the SIEM record. If a suspicious log event is seen from the network proxy in the SIEM, the SOC engineer should need no more than a minute to see event data from the internal host around that time, this will help determine if the anomaly was a successful exploit and compromised the workstation.

But host surveillance solutions, while certainly required, are limited for a number of reasons:

1. Too large a variety of workstations. Older and very new OS releases often are not supported.
2. Users often insist on acquiring non-standard workstations (e.g. Mac in a Windows shop).
3. The prevalence of personal devices like phones and tablets.
4. Servers with a wide distribution of OS systems like various Linux flavors where the host surveillance won’t work at all, can’t handle the volume or itself adds too big a risk of an outage.
5. Flaws in the host surveillance itself can cause widespread outages under some conditions, therefore causing just as big a risk to the security team as an attacker!
6. Of course surveillance on compromised hosts will be found and neutered by sophisticated attackers. The host surveillance depends on the very resources it’s protecting.

This is where the network forensics workflow picks-up. Network data should be recorded in its entirety (at the Internet boundaries at a minimum), whether it seems “interesting” (associated with a security event) at the time or not. This data should be held for at least 24 hours to allow SOC engineers to obtain full network data for high priority SIEM events. This data complements the information from host-based surveillance which may itself have some details on network connections but will not include the full packet information. And of course in DMZ and server areas, there may be no host surveillance at all for the reasons mentioned above.

Similar to the host workflow, a SOC engineer should be able to click an event in the SIEM and within a minute get full packet information relating to the event. He can then determine if the session was stopped by the firewall/IPS/malware inline tools or was successfully opened and delivered a payload to the vulnerable hosts.

Most enterprises target seven to thirty days for network data retention, depending on network volumes. Often what SOC users want is fast, simple packet data relating to events they already have, rather than additional network analysis; common problem: the SOC and Incident Response team with a known incident waiting literally hours (or even overnight!) to get network data to corroborate what they are seeing because some analytics they seldom use are in the way.

Don’t leave your already over-burdened SOC teams without fast and efficient workflows to host and network data!

Article written by: Roger Harris, Senior Sales Engineer at Napatech.

TAGS

1. SIEM
2. open source
3. Splunk
4. network forensics