Given the advance of SIEM technology, the use cases described in the first post of our SIEM Kung Fu series are very achievable. But with the advent of more packaged attack kits leveraged by better organized (and funded) adversaries, and the insider threat, you need to go well beyond what comes out of the [SIEM] box, and what can be deployed during a one-week PoC, to detect real advanced attacks.

So as we dig into more advanced use cases we will tackle how to optimize your SIEM to both a) detect advanced attacks and b) track user activity, to identify possible malicious insider behavior. There is significant overlap between these two use cases. Ultimately, in almost every successful attack, the adversary gains presence on the network and therefore is technically an insider. But let’s take adversaries out of play here, because in terms of detection, whether the actor is external or internal to your organization doesn’t matter. They want to get your stuff.

So we’ll break up the advanced use cases by target. It might be the application stack directly (from the outside), to establish a direct path to the data center, without requiring any lateral movement to achieve the mission. The other path is to compromise devices (typically through an employee), escalate privileges, and move laterally to achieve the mission. Both can be detected by a properly utilized SIEM.

Attacking Employees

The most prominent attack vector we see in practice today is the advanced attack, which is also known as an APT or a kill chain, among other terms. But regardless of what you call it, this is a process which involves an employee device being compromised, and then used as a launching point to systematically move deeper within an organization – to find, access, and exfiltrate critical information. Detecting this kind of attack requires looking for anomalous behavior at a variety of levels within the environment. Fortunately employees (and their devices) should be reasonably predictable in what they do, which resources they access, and their daily traffic patterns.

In a typical device-centric attack an adversary follows a predictable lifecycle: perform reconnaissance, send an exploit to the device, and escalate privileges, then use that device as a base for more reconnaissance, more exploits, and to burrow further into the environment. We have spent a lot of time on how threat detection needs to evolve and how to catch these attacks using network-based telemetry.

Leveraging your SIEM to find these attacks is similar; it involves understanding the trail the adversary leaves, the resulting data you can analyze, and patterns to look for. An attacker’s trail is based specifically on change. During any attack the adversary changes something on the device being attacked. Whether it’s the device configuration, creating new user accounts, increasing account privileges, or just unusual traffic flows, the SIEM has access to all this data to detect attacks.

Initial usage of SIEM technology was entirely dependent on infrastructure logs, such as those from network and security devices. That made sense because SIEM was initially deployed to stem the flow of alerts streaming in from firewalls, IDS, and other network security devices. But that offered a very limited view of activity and eventually become easy for adversaries to evade. So over the past decade many additional data sources have been integrated into the SIEM to provide a much broader view of your environment.

• Endpoint Telemetry: Endpoint detection has become very shiny in security circles. There is a ton of interest in doing forensics on endpoints, and if you are trying to figure out how the proverbial horse left the barn, endpoint telemetry is great. Another view is that devices are targeted in virtually every attack, so highly detailed data about exactly what’s happening on an endpoint is critical – not just to incident response, but also to detection. And this data (or the associated metadata) can be instrumental when watching for the kind of change that may indicate an active threat actor.
• Identity Information: Inevitably, once an adversary has presence in your environment, they will go after your identity infrastructure, because that is usually the path of least resistance for access to valuable data. So you need access to identity stores; watch for new account creation and new privilege entitlements, which are both likely to identify attacks in process.
• Network Flows: The next step in the attack is to move laterally within the environment, and move data around. This leaves a trail on the network that can be detected by tracking network flows. Of course full packet capture provides the same information and more granularity, with a greater demand for data collection and analytics.
• Threat Intelligence: Finally, you can leverage external threat data and IP reputation to pinpoint egress network traffic that may headed places you know are bad. Exfiltration now typically includes proprietary encryption, so you aren’t likely to catch the act through content analysis; instead you need to track where data is headed. You can also use threat intelligence indicators to watch for specific new attacks in your environment, as we have discussed ad nauseum in our threat intelligence and security monitoring research.

The key to using this data to find advanced attacks is to establish a profile of what’s normal within your environment, and then look for anomalous activity. We know anomaly detection has been under discussion in security circles for decades, but it is still one of the top ways to figure out when attackers are doing their thing in your environment. Of course keeping your baseline current and minimizing false positives are keys to making a SIEM useful for this use case. That requires ongoing effort and tuning. Of course no security monitoring tool just works – so go in with your eyes open regarding the amount of work required.

Multiple data points

Speaking of minimizing false positives, how can you do that? More SIEM projects fail due to alert exhaustion than for any other reason, so don’t rely on any single data point to produce a verdict that an alert is legitimate and demands investigation. Reduction of false positives is even more critical because of the skills gap which continues to flummox security professionals. Using a SIEM you can link together seemingly disconnected data sources to validate alerts and make sure the alarm is sounded only when it should be.

But what does that look like in practice? You need to make sure a variety of conditions are matched before an alert fires. And increase the urgency of an alert according to the number of conditions triggered. This simplified example illustrates what you can do with the SIEM you likely already have.

1. Look for device changes: If a device suddenly registers a bunch of new system files installed, and you aren’t in the middle of a patch cycle, there may be something going on. Is that enough to pull the alarm? Probably not yet.
2. Track identity: Next you’ll see a bunch of new accounts appear on the device, and then the domain controller targeted for compromise. Once the domain controller falls, it’s pretty much game over, because the adversary can then set up new accounts and change entitlements; so tracking the identify infrastructure is essential.
3. Look for internal reconnaissance: Finally you’ll see the compromised device scanning everything else on the network, both so the attacker can gain his/her bearings, and also for additional devices to compromise. Traffic on internal network segments should be pretty predictable, so variations from typical traffic flows usually indicate something funky.

But do any of these data points alone indicate an attack? Probably not. But if you see multiple indicators at the same time, odds are that’s not great for you.

Modern SIEMs come with a variety of rules or policies to look for common attack patterns. They are helpful for getting started, and increasing use of data analytics will help you refine your thresholds for alerts, increasing accuracy and reducing false alarms.

Application Stack Attacks

We alluded to this above, but to us an “application stack attack” is not just a cute rhyme, but how a sophisticated adversary takes advantage of weaknesses within an application or another part of an application stack, to gain a foothold in your environment to access data of interest. There are a number of application stack data sources you can pump into a SIEM to look for attacks on the application. These include:

• Machine Data: The first step in monitoring applications is to instrument it to generate “machine data”. This could be information on different transaction types or login failures, search activity, or almost anything that can be compromised by an attacker. Determining how and where to instrument an application involves threat modeling the application to make sure the necessary hooks are built into the app. The good news is that as more and more applications move to SaaS environments, a lot of this instrumentation is there from the start. But with SaaS you get what you get, and don’t have much influence on which information is available.
• APIs: Applications are increasingly composed of a variety of components, residing in a variety of different places (both inside and outside your environment), so watching API traffic has become key. We have researched API security, so refer back to that paper for specifics about authentication and authorizing specific API calls. You will want to track API usage and activity to profile normal activity for the application, and then start looking for anomalies.
• Database Tier: This last part of the application stack is where the valuable stuff lives. Once an attacker has presence in the database tier, it is usually trivial to access other database tables and reach the stuff they are looking for. So ingest any database activity logs or monitors available, and watch for triggers.

Each application is unique (like a snowflake!) so you won’t be able to get prebuilt rules and policies from your SIEM provider. You need to look at each application to monitor and profile it, building rules and tuning thresholds for the specific application. This is why most organizations don’t monitor their applications to any significant degree… And also why they miss attacks which don’t involve traditional malware or obvious attack patterns.

Developer Resistance

Collecting sufficient machine data from applications isn’t something most developers are excited about. Applications have historically not been built with instrumentation in mind, and retrofitting instrumentation into an app is more delicate plumbing than designing cool new features. We all know how much developers love to update plumbing. You may need to call for senior management air cover, in the form of a mandate, to get the instrumentation you need into the application. You can only request air support a limited number of times, so make sure the application is sufficiently important first.

More good news: as new applications are deployed using modern development techniques (including DevOps and Continuous Deployment), security is increasingly being built into the stack at a fundamental level. Once the right instrumentation is in the stack, you can stop fighting to retrofit it.

Purpose-built Tools

You are likely to be approached by a variety of new security companies, offering security analytics products better at finding advanced attacks. Do you need yet another tool? Shouldn’t you be able to do this within your SIEM?

The answer is: it depends. Analytics platforms built around a specific use case, like APT or the insider threat, are optimized for a very specific problem. The vendor should know what data is required, where to get it, and how to tune their analytics engine to solve the specific problem. A more general-purpose SIEM cannot be as tuned to solve that specific problem. Your vendor can certainly provide some guidance, and maybe even some pre-packaged correlation rules, but more work will still be required to configure the use case and tune the tool.

On the other hand a security analytics platform is not designed around a SIEM’s other uses. It cannot help you prepare for an audit by generating reports pertinent to the assessment. It won’t offer much in the way of forensics and investigation. These analytics tools just weren’t built to do that, so you’ll still need your SIEM – which means you’ll have two (or more) products for security monitoring; with all the associated purchase, maintenance, and operational costs.

Now that you understand a bit more about how to use a SIEM to address advanced use cases, you need to be able to use your newfound SIEM Kung Fu consistently and systematically. So it’s time to revisit your process in order to factor in the requirements for these advanced use cases. We’ll discuss that in our next post.