Threat Intelligence: Humans turning data into actionable intelligence

SAN FRANCISCO – Yesterday, Salted Hash looked at various issues within the threat intelligence industry. Today, we’ll revisit the topic and dig a bit deeper by talking with an analyst about how they turn data into intelligence.

In the weeks leading up to the RSA conference, we watched countless sales and conference videos, and spoke to a number of security practitioners about how they use threat intelligence.

While many of the practitioners couldn’t comment on the record due to company policy, they did share some of their pain. Most of the complaints about what passes as threat intelligence these days is that it’s flat data with a narrow focus. Sometimes, the data is useful, most of the time, it isn’t.

As discussed yesterday, raw data, such as a list of signatures and IP addresses, isn’t intelligence if it hasn’t been validated or if it’s missing context. Most of the experts consulted agreed that it takes a human, one who knows the needs of the business, to look at the flat data and make a judgement call.

Example:

A data feed detailing a domain that’s related to CryptoLocker and associated IPs doesn’t explain how the risk can be mitigated, and it doesn’t help the organization determine how to act. It doesn’t help them determine what changes, if any, need to be made. In short, such a feed or intelligence report isn’t actionable. Yet, this is exactly what some vendors will sell – a simple unprocessed data feed.

“At most you can block C2 and look for the traffic to Darknet sites in your telemetry to try and see if anyone has been infected, which by then is too late, but at least you can react. [That is, assuming] you have a SIEM or talented and dedicated resources for incident response and investigations,” commented one practitioner when asked about the example.

The ultimate goal for any organization looking at threat intelligence solutions is to obtain actionable intelligence from the vendor’s offerings. Again, it’s only actionable after it’s been evaluated and validated; otherwise, it’s just raw information.

On a basic level, an organization will want to know:

• Who is attacking? Why are they attacking? How are they attacking?
• Have they attacked any competitors?
• Have they attacked business partners or is there an increased pattern of attacks against the industry?
• What are their capabilities and methods?
• What are the common tools and tactics used by these attackers?

As you can imagine, there is a feed or data stream that can provide bits and pieces of information to address all of those questions. But again, that won’t help. There’s no context, and without it, you can’t put this information to work.

The long-term value threat intelligence has to an organization is the ability to drive change.

Validated threat intelligence (or data with proper context) should change behaviors, whether that behavior is how the SOC prioritizes and responds to alerts; how users evaluate and react to Phishing emails; or how decision makers and executives invest in a security program or prioritize long-term security projects. In some cases, threat intelligence will help IR teams with improved detection and response times, which is always a solid bonus.

An analyst’s tale:

Salted Hash recently spoke to a security practitioner in the finance sector about their experiences with threat intelligence and how it impacts their operation. They’ve asked to remain anonymous to protect their company and clients, we’ll call this person Jane.

When it comes data feeds and dealing with a vast amount of information from a number of sources, the big question is whether or not an organization can successfully manage the data, Jane said, and whether or not it’s getting the customized data needed.

[Note: The conversation we had with Jane started after we asked for opinions on Webroot’s blog post earlier last month about threat intelligence.]

“Right now, my finance organization mostly leverages Splunk, pulling generic blacklists and open source intelligence feeds for correlation purposes against addresses our perimeter devices log, honeypots, and FS-ISAC bulletins,” Jane said.

As an analyst, Jane reviews specific FS-ISAC data for finance related Phishing, credential theft, and fraud-related data to share with her team and C-Level risk executives. If it’s warranted, they will sometimes share Phishing or fraud indicators with FS-ISAC.

“At one point we looked at unified threat-sharing tools, with both paid and open source support. We stood up a Soltra server from FS-ISAC in its early incarnation (without paid support), but that required a lot of database knowledge to manage. [We] had early issues over time that required more cross-team intervention to troubleshoot than we had manpower to support,” Jane said.

“We’ve been a bit shy to throw money at any one solution given that our current process works at our current scale. We did demo several paid offerings/appliances that looked promising, notably Vorstack. However, due to budgetary refocusing we decided what we had in place was sufficient for the volume of data/threat surface we deal with.”

So what’s the workflow look like?

Most of Jane’s security appliances already respond/block/alert based on vendor-provided indicator feeds. However, where social engineering and human interaction creates risk, Jane’s team will share this information with the staff.

For example, alerting HR to resume-themed campaigns. But human-triage happens only when necessary she said, as they “find alert fatigue to be a factor when we’ve provide non-security-centric teams with too much data to parse for themselves.”

So how much data is too much when it comes to alerts?

“Right now, we’re only looking for threats that specifically target finance groups, i.e. data related to known fraud activities, finance-facing DDoS threats, Phishing / credential harvesting, C-Level whaling attempts, specific watering-hole attacks of a finance nature,” Jane explained.

Political activity-based threats are monitored and trended as well, in case there’s actor overlap, but typically, brute-force attack IP’s are noisy by nature, and Jane’s company deals with them though their firewall, IDS and load-balancing vendors’ blacklists, as well as with other heuristics / traffic behavior detection mechanisms that are in place.

“For example, data about government-facing watering-hole attacks, Anonymous campaigns, etc. doesn’t really impact us as much as Phishing-vectored banking Trojans, Anonymous’ occasional finance campaigns we’ll here about in advance as they target larger finance entities.”

Adding some additional context, Jane said that what’s been valuable about FS-ISAC is the description of the Social Engineering lures, fraud tactics and the “ruse” styles of particular campaigns that come with advisories. Such details help her team prepare training for staff, via our internal Phishing exercises, and general aware training.

Correlation of raw data is only so helpful, Jane added. If her organization gets intelligence that helps them understand the ruse, or style of the attack, they can generally predict what a variant will look like, and brief incident response teams and affected staff who might be likely targets. The indicators are helpful, but not essential if her team understands the behavior or goal of the attacks more than the static data.

“It’s been said before but there’s heaps of intelligence out there, what business actually needs is actionable intelligence, which is of course much different than raw intelligence data about say, every brute force attack that touched a business 24 hours ago, by that time our appliances have already ingested the fresh blacklists,” Jane said.

“I think each sector has its own niche needs, and the ‘firehose of data’ most threat intelligence providers offer requires space management and manpower to vet, and to narrow it all down to what really matters to us, and what we should act on.”