As we wrap up this series on SIEM Kung Fu, we have discussed SIEM Fundamentals and some advanced use cases to push your SIEM beyond its rather limited out-of-the-box capabilities. To make the technology more useful over time, you should revisit your SIEM operation process.

Many failed SIEM projects over the past 10 years have not been technology failures. More stumble over a lack of understanding of the amount of time and resources needed to get value from the SIEM in early deployments and over time, the amount of effort required to keep them current and tuned. So a large part of SIEM Kung Fu is just making sure you have the people and process in place to leverage the technology effectively and sustainably.

Getting Started

As a matter of practice you should be focused on getting quick value out of any new technology investment, and SIEM is no exception. Even if you have had the technology in place for years, it’s useful to take a fresh look at the implementation to see if you missed any low-hanging fruit that’s there for the taking. Let’s assume you already have the system up and running, are aggregating log and event sources (including things like vulnerability data and network flows), and have already implemented some out-of-the-box policies. You already have the system in place – you are just underutilizing it.

Adversaries

For a fresh look at SIEM we recommend you start with adversaries. We described adversary analysis in detail in the CISO’s Guide to Advanced Attackers (PDF). Start by determining who is most likely to attempt to compromise your environment. Defining a likely attacker mission. Then profile potential adversaries to determine the groups most likely to attack you. At that point you can get a feel for the most likely Tactics, Techniques, and Procedures (TTPs) for adversaries to use. This information typically comes from a threat intelligence service, although some information sharing groups can also offer technical indicators to focus on.

Armed with these indicators you engage your SIEM to search for them. This is a form of hunting, which we will detail later in this post, and you may well find evidence of active threat actors in your environment. This isn’t a great outcome for your organization, but it does prove the value of security monitoring.

At that point you can triage the alerts you have received from SIEM searches to figure out whether you are dealing with false positives or a full-blown incident. We suggest you start with the attacks of your most likely adversaries, among the millions of indicators you can search for. And odds are you’ll find lots of things, if you search for anything and everything. By initially focusing on adversaries you are restricting your search to the attack patterns most likely to be used against you.

Two Tracks

Once you have picked the low-hanging fruit from adversary analysis, focus shifts toward putting advanced use cases into a systematic process that is consistent and repeatable. Let’s break up the world into two main categories of SIEM operations to describe the different usage models: reactive and proactive.

Reactive

Reactive usage of SIEM should be familiar because that’s how most security teams function. It’s the alert/triage/respond cycle. The SIEM fires an alert, your tier 1 analyst figure out whether it’s legitimate, and then you figure out how to respond – typically via escalation to tier 2. You can do a lot to refine this process as well, so even if you are reacting you can do it more efficiently. Here are a few tips:

1. Leverage Threat Intel: As we described above under adversary analysis, and in our previous post, you can benefit from the misfortune of others by integrating threat intelligence into your SIEM searches. If you see evidence of a recent attack pattern (provided by threat intel) within your environment, you can get ahead of it. We described this in our Leveraging Threat Intel in Security Monitoring paper. Use it – it works.
2. User Behavioral Analytics (UBA): You can also figure out the relative severity of a situation by tracking the attack to user activity. This involves monitoring activity (and establishing the baselines/profiles described in our last post) not just by device, but also aggregating data and profiling activity for individuals. For example, instead of just monitoring the CEO’s computer, tablet, and smartphone independently, you can look at all three devices to establish a broader profile of the CEO’s activity. Then if you see any of her devices acting outside that baseline, that would trigger an alert you can triage/investigate.
   1. Insider Threat: You can also optimize some of your SIEM rules around insiders. During many attacks an adversary eventually gains a foothold in your environment and becomes an insider. You can optimize your SIEM rules to look for activity specifically targeting things you know would be valuable to insiders, such as sensitive data (both structured and unstructured). UBA is also useful here because you are profiling an insider and can watch for them doing strange reconnaisance, or possibly moving an uncharacteristially large amount of data.
   2. Threat Modeling: Yes, advanced SIEM users still work through the process of looking at specific, high-value technology assets and figuring out the best ways to compromise them. This is predominately used in the “external stack attack” use case described last post. By analyzing the ways to break an application (or technology stack), SOC analysts can build SIEM rules from those attack patterns, to detect evidence an asset is being targeted.

Keep in mind that you need to consistently look at your SIEM ruleset, add new attack patterns/use cases, and prune rules that are no longer relevant. The size of your ruleset correlates to the performance and responsiveness of your SIEM, so you need to balance looking for everything (and crushing the system) against your chance of missing something.

This is a key part of the ongoing maintenance required to keep your SIEM relevant and valuable. Whether you get new rules from a threat intelligence vendor, drinking buddies, or conferences, new rules require time to refine thresholds and determine relevance to your organization. So we reiterate that SIEM is not a “set it and forget it” technology – no security analytics tool is. Anyone telling you different is selling you a bill of goods.

Proactive

Before we dive into the concept of proactivity we need to spend a minute on our soapbox about the general idea of “getting ahead of the threat.” We (still) don’t believe you can get ahead of threats or detect zero-day attacks, or any other such security marketing nonsense. What you can do is shorten the window between when you are attacked and when you know about it. So that’s the main objective of SIEM Kung Fu: to shorten this window by whatever means you can.

The reactive approach is to set SIEM rules to fire alerts based on certain conditions, and then react to them. The proactive approach is to task a human with trying to find situations where attacks are happening, which wouldn’t trigger an alert. These folks like to be called hunters, which sounds much better than “SOC analyst”.

Why wouldn’t the SIEM alert have fired already? Maybe the attack is just beginning. Maybe the adversary is just doing recon and mostly hiding to evade detection. Whatever the cause, the rules you set in the SIEM haven’t triggered yet, and a skilled human may be able to find evidence of the attack before your monitoring tools.

The hunter’s tool set is more about threat intel, effective search and analytics, and a lot of instinct for what attackers will do, than a flexible SIEM rules engine. For example a hunter might see that a recent business partnership your company announced has irritated factions in Eastern Europe. So the hunter does a little research and finds a new method of compromising a recent version of Windows by gaining kernel access and then replacing system files in use by attackers in that region. Then the hunter searches to see whether egress traffic is headed to known C&C channels used by those groups, and also searches your endpoint telemetry for instances where that system file was changed recently. Of course you could set a rule to look for this activity moving forward, but the hunter is able to mine existing security data for that set of conditions to see if an attack has already happened.

As another example a hunter might go to a security conference and learn about a new technique to overflow memory. After playing around with it in your lab, the hunter knows what to look for on each endpoint. Then a search can be initiated for that activity, even though there hasn’t been evidence of that technique being used in the wild yet. Hunters have great leeway to follow their instincts, and SIEM tools need to offer flexible (and fast) enough search to find strings and pull on them.

SIEM Kung Fu for hunters is about giving them the platform to do their job. They are skilled professionals, with their own tools for when they really want to dig into a device or attack. But a SIEM can be very useful for helping them narrow their focus to devices that require more investigation and provide a means to analyze patterns of activity that could yield clues to which threats are active.

Whether you are implementing a set of SIEM rules to react to attacks or giving a set of hunters the ability to identify potential compromises in your environment, your security monitoring platform can be leveraged to enable faster detection and triage. And when you are racing an active adversary, time is not your friend.

With that, we wrap up our SIEM Kung Fu series. We will assemble these posts into a paper over the next week, so if you have any comments or feedback about the research, let us know in the comments, via the Tweeter (@securosis) or via email.