Blog post

On Internally-sourced Threat Intelligence

By Anton Chuvakin | March 20, 2014 | 2 Comments

threat intelligencesecuritymonitoringincident responseanalytics

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:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Matthew Gardiner says:

    I posit that the reason that only organizations in the “upper stratosphere” produce their own TI is the classic problem of economies of scale and scope. Single organizations, sitting in their own application and Internet silos can’t afford to have their own intelligence gathering and investigative functions. This is exactly analogous to the physical world; we can’t all afford to have our own central intelligence agency or police detectives sitting in our own homes and businesses, protecting each of us individually. What we do is to join together (in the physical world largely through government) to provide these services in a shared fashion. This is exactly what needs to be done in the online world….but with some mix of vendors, non-profits, governments, and organizations collectively “sharing” TI and the rest of the organizations consuming this TI in near real-time. Requires a lot to make this happen, like an economic, technical, and legal framework that works for all participants…..but I see no alternative in a world where prevention is clearly no longer sufficient.

  • Matt, thanks for the comment. Indeed, it is a question of scale and scope – but also risk and [related] the degree of unusualness of their needs. Some companies DO hire private guard and private investigators and have their own ex-intel personnel on staff.

    And, of course, I fully support any/all useful TI sharing efforts, as you know well. Winning as the community is the way to go, and obviously those that produce their own intel share and receive shared info as well.