Defining Threat Intelligence Requirements

Published: 2016-09-25
Last Updated: 2016-11-10 21:31:59 UTC
by Pasquale Stirparo (Version: 1)
0 comment(s)


Setting up the requirements is the first task to be completed before investing time in researching and collecting any type of intelligence. However, in many conversations on the topic I have been into, requirements are too often confused with "which tool do we need?" and "how many people do we need?” While these parameters are part of the equation, the main goal of setting the requirements is to understand which type of information is of interest for a given organization. This because there are mainly two issues:
The overall amount of information received from different sources (e.g. sharing groups, feeds, etc.) is huge and a big part of it not relevant to your organization;
Even if you would focus only on the amount of information that interests your organization, most of the times such amount of data would still be well over what is the analyst(s) capacity.

Therefore a proper model has to define the requirements and also their priority, in order to be sure that the most relevant and most critical information is processed and not lost in the noise. 
I like to split the types of requirements in three different groups:

  • High Level Requirements
    • As the name suggests, these are general requirements like defining what type of threat actor is of interest, understanding which are the business industries of operation, etc.
  • Functional Requirements
    • These are more practical and technical requirements, based on what type of infrastructure your organization has.
  • Capability/Visibility Requirements
    • This is literally what information the analyst needs to have access to, in order to get the proper internal visibility needed to meet the requirements defined in the previous two categories.

Defining Threat Intelligence Requirements

Following are the three types of requirements explained in (slightly) more details, to give an example of what each one means. This list does not want to be exhaustive, but rather to set up an initial direction that will have to be tailored to your specific organization.

High Level Requirements

  • Countries of Operation
    • This is a very high level one. The granularity of this has to be defined. It could be referring just to the macro regions of operation (quite high level though for big organizations), to each country were major operational branches are, or to each county were the organization has a presence (even with small branches).
      • E.g. if your organization has no presence/business in Asia or country X, you may not be interested in activities targeting specifically that region/country.
      • E.g. actions led by this could be blocking traffic towards countries your organization has no business with (and/or generating an alert).
  • Business Industries of Operation
    • The core business of the company (e.g. insurance, bank/finance, manufacturing, energy, etc.) is obviously known and the first to start with.
    • This point also refers to understanding all other secondary (but relevant) industries your company is involved in and/or possesses sensitive information about;
      • E.g. your organization (e.g. core business finance) is also involved in oil plants, with access to blueprints for business reasons. Are there groups after these specific IP/info? Which ones?
  • Business Top Critical Assets
    • Assets refers to both type of critical data for the organization (Credit Card and Financial account data, Personal Identifiable Information, Intellectual Property, Confidential business information, Credentials and IT System Information), and Operational Systems for which their availability is business critical.
  • What type of Adversary may be targeting your business?
    • E.g. Hacktivist, Organized Crime, Corporate Espionage, Nation-State, etc.
  • Who will consume the Intelligence you collect/produce?
    • SOC analysts, CISO, etc., to understand whether you need to collect/produce technical, tactical and/or strategic intelligence.

Functional Requirements

  • Physical external/perimetral exposure
    • Servers facing external network: 
      • What services are publicly exposed? What OS version do they run? What DB + version? Etc. (selecting those of major importance first)
    • Which devices are reachable from the outside?
      • E.g. printers with remote maintenance access.
  • Physical internal exposure
    • What systems do you use internally (i.e. that have access to the internal network)?
      • Windows / OSX / *nix ? Which version?
      • Mobile?
    • What software/version do you use internally? (IE, Outlook, Flash, etc.). Are there unpatched vulnerabilities to be monitored? Are any of those being exploited in the wild?
    • What type of attachments do you allow? What types of file are allowed to be downloaded from the internal network?
    • Network infrastructure (yes, that famous diagram no one ever has)
  • What type of attacks/threats does your organization fear most?
    • DDoS attacks
    • Banking Trojan
    • Drive-by / EK
    • Credentials' Phishing
    • Intellectual Property (IP) exfiltration
    • Etc.

Capability/Visibility Requirements

Given that the best intelligence is the one you can gather from your own environment, and higher visibility into your environment will lead you to use information and tools in a more efficient way. Following there are the resources needed to have visibility on the data needed to fulfill those requirements. 

  • Email logs
    • As basic requirements, it is of paramount importance being able to access all email logs containing timestamp, sender, recipient, subject, attachment(s) name, attachment(s) hash value.
    • Being able to access the quarantined attachments, or having an address were to forward malicious emails for automatic processing in a safe environment;
    • Having access to the email header as well would be a great plus.
  • Network: Proxylogs, Firewall logs, IDS logs, DNS logs, etc.
  • Passive DNS
    • Another must have is a passive DNS: collect all DNS resolutions ever made by any machine within your network;
    • Third-party pDNS: always useful to get a broader view.
  • Endpoint visibility
    • Being able to search/collect information and artifacts from endpoints (i.e. memory, registry hives, running processes, etc.)
  • External feeds and sources
    • Free/Paid feeds of indicators
    • Hopefully each analyst belongs to one or more trusted sharing communities, which are usually not public. If not, create your network of trusted peers, this is a must have for an analyst.
  • Centralized storage and correlation
    • This may be full-fledged Threat Intelligence Platform (TIP) or an Excel spreadsheet
    • Useful as central collection point of the collected intel. 
    • Ideally can be integrated with other internal tools to allow automation

Action Plan

The following is a list of actions to take, which is mapped on the above requirements:

  1. Enumerate your environment (functional requirements: internal and external exposure)
  2. Evaluate your most critical assets the business wants you to protect (high level requirements: business top critical asset).
  3. Identify your Adversaries (high level requirements: what type of adversary may target our business)
  4. Prioritize the type of attacks/threats most dangerous for the business (functional requirements: what type of attacks/threats do you fear?)
  5. Identify the main countries and especially business industries of operation (high level requirements: countries and business industries of operation)
  6. Identify who will be the TI consumers (high level requirements: who will consume the TI?)

Once it is clear what you need to protect and what type of information needs to be collected, it is time to move to the "capability/visibility requirements”, keeping in mind what information you need in order to cover all the requirements defined above.

We have already mentioned that the first and best intelligence feeds you can get are from your own internal environment. Specifically, as also mentioned by Scott J. Roberts in his blog [1], starting from the analysis of your past incident can give you immediately a good indication about your requirements. Do those incidents fit into the requirements you have set? If not, refine them. From the past incidents, it will be possible also to check how mature are the capability/visibility requirements. If that incident will happen again, would you be able to either prevent or detect it? The requirements will tell you.
Last but not least, remember that this is an iterative process and all those requirements need to be reviewed and refined periodically, because the threat landscape will change, as well as the organization infrastructure and/or secondary business industries may change as well. How often? This is really tailored to the organization (e.g. 6 or 12 months). 

Did you define your TI requirements? What approach did you use? Please share your experience.

Happy Hunting,



References and Suggested Readings
[1] – Scott J. Roberts, "CTI SquadGoals - Setting Requirements",
[2] – CIA, "A Fresh Look at Collection Requirements",
[3] – Scott J. Roberts, "Intelligence Collection Priorities",


0 comment(s)


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives