Selecting a cyber threat intelligence provider — building out your requirements
I recently struggled to find reference resources to create a requirements list for the selection of a cyber-threat intelligence (CTI) provider (I might have been looking in the wrong places). To help others, I thought I would share what I developed. It is by no means exhaustive or perfect, but I hope it can serve as a starting point.
Disclaimer: This article reflects my personal opinion.
Context is always helpful in articles like this one, so let me tell you why I developed these requirements in the first place.
1. Industry ISACs and public sector-driven sharing platforms bring a lot of benefit to organisations, but they typically have limited resources and data compared to private threat intelligence providers.
2. Opinions differ on the role of a CTI capability at private companies. Some choose to build an in-house capability that collects and analyses information, while others turn to a partner to help with this partially or entirely. Looking at the OODA loop, I think having a private CTI provider take on a significant role in the “Observe” and “Orient” phases makes your capability a lot more efficient and effective, provided you have the right use cases and procedures.
The scope of these requirements is limited to “external intelligence.
How did I start?
- Looked at different use cases ranging from technical to strategic, based on experience and input of stakeholder functions in a threat intelligence program (SOC, CIRT, Threat hunting, security awareness, security strategy, third-party risk management, vulnerability management …)
- Looked at the overall intelligence process
What did I end up with?
A list of requirements that I put into three buckets:
- Collection (What does the provider collect & where is it collected?)
- Analysis (What does the provider do with the collected data & how?)
- Delivery (At what interval and in what format does the provider deliver intelligence?)
Note: An alternative or complementary approach could be to map the requirements to your stakeholder use cases or regulatory/oversight requirements.
- The provider collects open-source information (from forums, paste-sites, news sites, blog sites, LinkedIn, security vendors, security researchers, Twitter, vulndb, cve mitre, … )
- The provider collects data from the dark and deep web (ask for detail on the number of analysts who are actively collecting data and engaged)
- The provider collects data from malware marketplaces (ask for detail on the number of analysts who are actively collecting data and engaged on dark & deep web forums)
- The provider collects data from sensors that are distributed globally (anti-virus, endpoint detection and response, malware sandboxing, proxies, bots …)
- The provider collects data from voice and chat tools (discord, ventrilo, teamspeak …)
- The provider actively engages with “malware as a service” providers/platforms to collect data
- The provider actively engages with “botnet services” to collect data
- The provider collects vulnerability information from common databases (e.g. vulndb)
- The provider collects domain information (creation, deletion, update, hosting)
- The provider collects certificate transparency logs (correlation with domain creation and reputation is a plus)
- The provider ensures that multiple geographical locations are accounted for in collection
- Upon request of customer, the provider will add additional sources to its collection (open-source, dark and deep web, voice and chat tools and marketplaces)
- The provider analyses data it collects and provides vendor agnostic recommendations to prevent and/or detect observed TTPs and infrastructure used (hash, ip, domains, urls, email addresses …)
- The provider analyses malware families (variants) and toolkits that it gathers through its collection, identifying linked exploits and exploit kits, rating how popular the vulnerability is and whether it’s been observed in attacks
- The provider completes an in-depth analysis of malware it gathers with the objective of identifying means to detect the malware
- The provider fullfils a customer’s priority intelligence requirements within an agreed timeframe
- The provider continuously analyses the threat landscape based on collected data and creates strategic, operational and tactical recommendations
- Upon request of the customer, the provider will try to engage with potential threat actors to gather additional context (the provider to specify in which scenarios this is possible)
- The intelligence provider performs analysis of tactics, techniques and procedures (TTPs) of real-life attackers, their modus operandi and information on geopolitical developments that may trigger cyber attacks
- The provider maps TTPs and recommended mitigations to the MITRE ATT&CK framework
- The provider analyses data it collects and assigns reliability and credibility scoring, which it will consistently share with its customer in the products delivered downstream
- The provider has processes in place to reduce bias and analyse the reliability and credibility of information collected (provider to provide an overview of the processes)
- The provider has a global coverage of intelligence analysts and ensures different cultural viewpoints are accounted for in the analysis of collected data
- The provider analyses the motives, intentions and capabilities of threat actors and includes these in reports and threat actor profiles
- The provider analyses collected data and looks for indications that its customer’s infrastructure might be impacted
- The provider analyses domain data to identify any potential typo-squatting/unicode domains or domain names that are similar to domains owned by its customer that could be used in phishing or malware campaigns
- The provider analyses certificate transparency logs to identify certificates created that might be leveraged in an attack of its customer
- The provider analyses the threat landscape and identifies the most relevant threat actors to its customer at a regular interval (Provider to specify the interval)
- The provider distributes tactical intelligence (indicators of compromise) in a structured format (json, stix,…) by means of api/taxii/… feed. This includes the option to restrict sharing of IOCs based on groups, labels, etc (detail for which SIEM & TIP solutions built-in integration exists)
- The provider provides tactical means that allow the customer to mitigate the risk of recent threat actor behaviour (Yara rules, SIGMA rules, IDS signatures)
- Tactical intelligence shared contains context (What incident or malware are the technical indicators linked to; what threat actor was involved; what was the targeted industry; what is the corresponding MITRE technique…)
- At a regular interval the provider publishes a vulnerability report highlighting the patch status, interest level and exploit status and whether it’s being actively used in campaigns
- At a regular interval the provider publishes threat intelligence reports on nation-state threat actors (provider to specify the interval)
- At a regular interval the provider publishes threat intelligence reports on Cybercriminal threat actors (provider to specify the interval)
- At a regular interval the provider publishes threat intelligence reports on Financial crime focused threat actors. (provider to specify the interval)
- At a regular interval the provider publishes malware intelligence reports, highlighting the commonly used malware, what MITRE ATT&CK techniques it applies to, what technology and sector it targets and how it bypasses security controls.
- Every 6 months, the provider publishes an overall threat intelligence report containing the latest trends in the threat landscape and predictions.
- The provider provides a list of most relevant threat actors to its customer at a regular interval (provider to specify the interval)
- The provider allows the customer to create alerts based on keyword and logic (open source, dark web and deep web)
- Based on pre-defined intelligence criteria agreed with customer, the threat intelligence provider will call the customer
A few examples:
Indication that your company has been compromised or is at a high risk
A 0-day vulnerability has been identified for a software in use at your company
- The provider creates a dashboard that provides an overview of risks linked to your vendors and suppliers
- The provider creates a dashboard that provides an overview of mentions of your company brand/name (social media sentiment) in the provider’s collected data, which can be used to identify potential brand damage.
- The provider provides the means to extract threat actor profiles:
Description, Incidents observed, Target industry, Tactics used (MITRE ATT&CK), Techniques used (MITRE ATT&CK), Procedures used, Tools/software used, Vulnerabilities targeted, Applications targeted
Use responses to these requirements to do the initial filtering of providers that do not meet your expectations. Before making a final selection, test the tools during at least a 3–4 week period. During that timeframe run through a set of predefined use cases and also look at how easy it is to consume the intelligence — especially for the parts that are not automated.
Whichever provider you select, accept that others might have data that you happen to need, at the time that you need it because they use different sources than your selected provider.
I look forward to hearing your thoughts and suggestions to enhance this list.