Introduction

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,

Pasquale

References and Suggested Readings
[1] – Scott J. Roberts, "CTI SquadGoals - Setting Requirements", https://sroberts.github.io/2016/03/30/cti-squad-goals-intro-to-requirements/
[2] – CIA, "A Fresh Look at Collection Requirements", https://www.cia.gov/library/center-for-the-study-of-intelligence/kent-csi/vol4no4/html/v04i4a03p_0001.htm
[3] – Scott J. Roberts, "Intelligence Collection Priorities", https://sroberts.github.io/2016/07/26/intelligence-collection-priorities