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?
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
Network: Proxylogs, Firewall logs, IDS logs, DNS logs, etc.
- 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).
- 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.
- 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?
- 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
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.
- cess to the email header as well would be a great plus.
Third-party pDNS: always useful to get a broader view.
External feeds and sources
- Being able to search/collect information and artifacts from endpoints (i.e. memory, registry hives, running processes, etc.)
Centralized storage and correlation
- Free/Paid feeds of indicators
- Hopefully eachanalyst 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.
- 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 integratedwith other internal tools to allow automation
The following is a list of actions to take, which is mapped on the above requirements:
- Enumerate your environment (functional requirements: internal and external exposure)
- Evaluate your most critical assets the business wants you to protect (high level requirements: business top critical asset).
- Identify your Adversaries (high level requirements: what type of adversary may target our business)
- Prioritize the type of attacks/threats most dangerous for the business (functional requirements: what type of attacks/threats do you fear?)
- Identify the main countries and especially business industries of operation (high level requirements: countries and business industries of operation)
- 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 , 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.
References and Suggested Readings
 Scott J. Roberts, CTI SquadGoals - Setting Requirements, https://sroberts.github.io/2016/03/30/cti-squad-goals-intro-to-requirements/
 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
 Scott J. Roberts, Intelligence Collection Priorities, https://sroberts.github.io/2016/07/26/intelligence-collection-priorities
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.