On Internally-sourced Threat Intelligence

At the very top of the very top of the pyramid, practically in upper stratosphere, sit organizations that produce their own threat intelligence (TI), sourced from local artifacts and their own intelligence gathering activities.

In my view, this “internal TI” label applies to four types of activities:

1. Local team collects technical TI all over the Internet (from outside of the organization’s perimeter)

2. Local team collects non-technical TI (from the outside)

3. Local team creates better TI by refining received data with local context and local analysis (such as finding hidden relationships between threat profiles or enriching TI data)

4. Local team sourcing TI from locally discovered artifacts (from the inside)

The first two items are similar to what was discussed in my blog post on TI sources since they are close to what commercial TI providers do for their clients. The third is related to a discussion in my post on TI fusion. Thus, in this post, we will look at locally sourced TI, the ultimate in home cooked, organic, locally grown juicy TI, that is actually good for you – if you can afford it.

But first, we have a small issues of definitions (don’t we always?). I keep pondering the question of where TI begins and monitoring/IR (and continuous IR) ends. Frankly, this is a hard one, and I am not entirely happy with the answer I came to: if it is primarily focused on directly protecting the environment (such as to alert about the intrusion), it is monitoring. And if it is primarily focused on learning about the threats and expanding your knowledge base about actors, it is internal TI. Clearly, an activity can easily be both…

So, locally sourced TI may come from locally caught malware (static analysis, reversing, executing/detonating in sandboxes, etc). It may come from local disk/memory images collected during an incident investigation. In some organization, local TI may come from locally deployed honeypots. Sometimes, it may come from artifacts discovered on partner vendor/customer/networks. Also, it may also come from processing locally sourced monitoring data, but this is the area where security monitoring, incident response and threat intelligence truly fuse into one security visibility and analysis bundle. And it is actually a good thing since what matters is that these tasks are done, not that they are properly classified…

Specific internal TI activities may include:

• Detailed analysis of locally caught malware, looking for ways to detect it in the future, possible connections to other malware and past incidents, relating to threat actor profiles, etc
• Detailed analysis of disk images, memory images for indicator extraction and learning about the attacker behavior while on your network
• Compiling and expanding threat actor profiles based on local data, such as logs, packet captures, malware, incident data, local honeypots, etc
• Detailed analysis of artifacts shared by other organizations
• Fusing local data with shared data (see TI fusion post for details) to produce more durable threat intelligence and extract new intelligence from existing data.

To summarize, a lot of the material discussed herein should NOT be tried by many less enlightened organizations. Admittedly, it can be very useful, but IT IS HARD WORK!

P.S. Extensive local TI activities usually require a TI management platform (TIMP?) of some kind. My research path has led me into the dark woods of defining the requirements for such platforms…. Next blog post?

Posts related to this research project:

• Delving into Threat Actor Profiles
• On Threat Intelligence Sources
• How to Make Better Threat Intelligence Out of Threat Intelligence Data?
• On Threat Intelligence Use Cases
• On Broad Types of Threat Intelligence
• Threat Intelligence is NOT Signatures!
• The Conundrum of Two Intelligences!
• On Comparing Threat Intelligence Feeds