After making the case for threat intelligence (TI), and combining it with some ideas about how security monitoring (SM) is evolving – based both on customer needs and technology evolution – there is clear value in integrating TI into your SM efforts. But all that stuff is still conceptual. How can you actually apply this integrated process to shorten the window between compromise and detection? How can you get a quick win for the integration of TI and SM to build some momentum for your efforts? Finally, how do you ensure you can turn that quick win into sustainable leverage, producing increased accuracy and better prioritization of alerts from the SM platform?

Let’s say you work for a big retailer with thousands of stores. You do tens of millions of transactions a month, and have credit card data for tens of millions of customers. Your organization is a high-profile target, so you have spent a bunch on security controls. Part of being a large Tier 1 merchant, at least from a PCI-DSS standpoint, is that the assessors are there pretty much every quarter. You can play the compensating control fandango to a point (and you do), but senior management understands the need to avoid becoming the latest object lesson on data breaches. So you get a bunch of resources and spend a bunch of money, with the clear responsibility to make sure private data remains private.

But this is also the real world, and your organization is a big company. They have technology assets all over the place and employees come and go, especially around the holidays. They all have access to the corporate network, and no matter how much time you spend educating those folks they will make mistakes. This long preamble is just to illustrate that you get it. Your odds of keeping attackers out range between nil and less than nil. So security monitoring will be a key aspect of your plan to detect attackers. The good news is that you already aggregate a bunch of log data, mostly because you need to (thanks, PCI!). You can build on this foundation and use TI to start looking for attack patterns and other suspicious activity that others have seen to give you early warning of imminent attacks.

Low Hanging Fruit

With any new technology project you want to show value quickly and then parlay it into sustainable advantage. So let’s focus on obvious stuff that can yield the quick win you need. There are a couple areas to look at, but the path of least resistance tends to be finding devices that are already compromised and remediating them quickly. A couple fairly reliable TI sources can yield this kind of information quickly, as detailed earlier in this series.

Once you identify the suspicious device, as discussed in The TI + SM Process, you need to collect more detailed data from it. Optimally you get deep endpoint (or server) telemetry including all file activity, registry and other configuration values, and a forensic capture of the device. To provide a full view of what’s going on you also want to capture the network traffic to and from it. Armed with that kind of information you can search for specific malware indicators and other clear manifestations of attack.

Baselines

At this point you have likely found some devices with issues, and acted decisively to remediate the issues and contain the damage. Once the actively compromised stuff is dealt with you can get a little more strategic about what to look for. Since you have been collecting data for a while (thanks again, PCI!), you can now build what should be a reasonable baseline of normal activity for these devices. Of course you will remove the data from compromised devices, and you will then be able to set alerts on activity that is not normal. That’s Security Monitoring 201 – not really novel.

In this scenario you can accrue a lot of extra value by integrating TI into the process, by analyzing activity around devices that are no longer acting normal. You don’t have the smoking gun of seeing a device participating in a botnet, or sending traffic to known bad sites, but it isn’t acting normally so it warrants attention. Of course a lot of current malware isn’t easy to find, but you can leverage TI to look for emerging attacks.

Let’s make this a little more tangible by going back to our example of the very large retailer. As with most big companies, you have a bunch of externally facing devices that serve up a variety of things to customers. Not all of them have access to mission critical data (unless you screw up your network segmentation), so they may not get much scrutiny or monitoring focus. But you can still track traffic in and out of them to see if or when they start acting strangely.

If you see an externally facing web server start sending traffic to a bunch of other devices within its network segment, that is probably suspicious. Normally, they only send traffic across the internal network to the application server farm that provides the data for their applications. Communicating with other internal hosts is not normal, so you start pulling some additional telemetry from the devices and capturing their traffic.

What integrating TI enables you to do with that now-suspicious device is to search for indicators and other behavior patterns you weren’t looking for. Any security monitoring platform is limited to looking for things you tell it to look for. With TI integrated you could identify traffic heading to an emerging botnet. Maybe you will be able to find new files and/or folders associated with a little-known malware kit. Since you haven’t seen this stuff before, you don’t know to look for it. But your TI provider is much more likely to see it, and they can tip your system what to look for.

Without TI, when you identify a suspicious device, you are basically back to shooting in the dark. You have a device acting strangely, but you don’t know why. You can reset the device to your gold standard, but that might not solve the problem, and you are much less likely to learn how to avoid the compromise next time. In this scenario TI helps you confirm the attack faster because you know what you’re looking for.

Adding Adversary Analysis

As we continue to add sophistication to the TI you integrate into the SM process, you can next look to integrate adversary-specific data. Back on our retailer example, you know credit card data is the most valuable stuff you have, and it will make a certain class of adversaries target your organization. Like everyone else they have traits and patterns that can be profiled. They tend to use certain types of malware and a handful of botnets, which enables you to look specifically for them more proactively.

In this scenario your TI provider can provide specific information about these actors. More sophisticated TI offerings add customized scoring metrics (based on kinds of devices and/or threat actors) that give you another attribute for prioritizing alerts. If you know you are likely to be targeted by organized crime faction X (CFX), and you find an alert of a common attack from CFX, you can make that alert a top priority. This makes TI more valuable operationally.

Even without specific intel ‘scores’, being able to look at information about specific actors lets you turn the tables, if only a little bit. You can proactively look for the attacks commonly associated with those actors and identify issues before the compromised device starts behaving egregiously.

Sustainable Wins

Regardless of the depth of Threat Intelligence integrated into your security monitoring process, you can get a quick win by having humans mine security data looking for TI indicators manually. It’s not particularly efficient, but it’s certainly possible, and they way most early TI offerings provided value. But that’s not good enough. To achieve the true potential of integrating TI and SM, you need to remove humans from the process – at least the front end. This automation has 3 facets:

1. Integration of Machine Data: You can’t use the cool automated capabilities of any security monitoring platform if you can’t get the data into it. So the first step in automating the process is to feed the data into the system using either the monitoring platform’s API or a common data format such as STIX. It is too early to know the ultimate data format winner, so be sure your TI process/provider can pump data into your monitoring platform.
2. TI-based Alerts: Manually configuring rules and alerts based on TI doesn’t scale. So start looking for indicators immediately once the TI feeds new indicators into the monitoring platform. Of course this can consume significant compute resources and may throw a bunch of alerts – at least until you tune the system – so you may consider a different type or priority of TI-generated alert to cut down false positives. But of course getting a bunch of alerts don’t mean they aren’t valid – which is why prioritization, as discussed above, is key.
3. TI Efficiency Reports: Finally, you will want to be able to pull reports about the number of alerts generated from each TI source without hurting your brain crafting complicated reports. First of all, this kind of report shows value from the TI investment – especially if you can show how the TI identified an attack earlier than you would have detected it otherwise. Secondly, you will be able to compare and contrast TI providers based on actual results if you use multiple vendors. The ability to optimize your TI spending is useful.

Finally, we need to acknowledge the difficulty of finding sufficient carbon-based resources to keep pace with the number and sophistication of attacks. Fortunately TI can make a huge difference by increasing the accuracy of alerts, and prioritizing alerts more effectively – to help your staff verify, investigate, and remediate the most dangerous attacks.

And with that we wrap up our Leveraging Threat Intelligence in Security Monitoring series. We believe the updated process documented in the research will make a significant difference in helping you keep pace with attackers in a very dynamic environment. We will keep comments open until early next week, so if you have thoughts of suggestions on any of these posts, please fire away.