By Mark Arena, CEO of Intel 471.
There are many definitions of what is an intelligence requirement but the definition to me that is most accurate is:
“Any subject, general or specific, upon which there is a need for the collection of information, or the production of intelligence.”
Ref:http://www.thefreedictionary.com/intelligence+requirement
With the above definition I want to highlight that an intelligence requirement could be one of two things: something where there is a need for the collection of information or the production of intelligence. Based on this, breaking out these two differing types of intelligence requirements into separate lists is the best approach.
Let’s take an example:
The CISO/CSO (Chief Information Security Officer) of your organization wants to know of any vulnerabilities that are being exploited in the wild that your organization can’t defend against or detect.
As you can see in the above example, breaking out what is needed for the production of intelligence and renaming it production requirements makes it clear that this is what is required for the production of intelligence therefore:
-> Intelligence requirements (what questions do we need our intelligence collection to answer to meet our production requirements)
Now we have two separate tables of what our intelligence consumers need versus what we need to collect. Next we need to identify what observables or data inputs we would need to answer our intelligence requirements, which we’ll call our collection requirements. Lets take another example:
In the above example what we have is:
-> Collection requirements (what observables/data inputs do we need to answer our intelligence requirements)
By breaking out your organization’s collection requirements this way, it will allow you to better assign the responsibility to collect for a specific collection requirement to a team, capability or external provider which can be regularly assessed to see how it fits into helping meet your organization’s intelligence requirements. When it comes to external providers of intelligence, there’s a number that sit in the intelligence cycle between collection and dissemination. Intel 471 sits primarily in the collection part of the intelligence cycle and works with organizations to more effectively collect against their externally focused collection requirements. When we refer to “externally focused” collection requirements, what we mean is that collection requirements can either be internally focused or externally focused where internally focused collection requirements require visibility on the subject organization’s attack surface. Externally focused collection requirements involves requirements that are adversary/cyber threat actor focused.
The holy grail of cyber threat intelligence prioritization?
The holy grail of cyber threat intelligence prioritization is to have a single long-term prioritized list of production requirements that is updated twice a year. The production requirements should be broad enough to encompass short-term requirements that immediately head to the top of the priority list but are very narrowly focused and only last at maximum 30 days, for example a requirement to assist with incident response to a security breach. In the absence of a single prioritized list, breaking down intelligence priorities by high, medium and low priorities is acceptable and is common practice with most resources going into satisfying high priority items.
Intelligence requirements: Attack surface or adversary focused?
A common question cyber threat intelligence professionals encounter is whether their organization’s intelligence requirements should be attack surface or adversary focused. A single intelligence requirement could be either but not both. An intelligence requirement in the context described above needs to relate to a specific observable that is eventually tasked to a team, capability or external provider so will need to be attack surface or adversary focused.
[Image: https://d39ec1uo9ktrut.cloudfront.net/c2c3d-0ur_vavkoadwhezk2-300x127.png]
As you can see in the above example, breaking out what is needed for the production of intelligence and renaming it production requirements makes it clear that this is what is required for the production of intelligence therefore:
-> Intelligence requirements (what questions do we need our intelligence collection to answer to meet our production requirements)
Now we have two separate tables of what our intelligence consumers need versus what we need to collect. Next we need to identify what observables or data inputs we would need to answer our intelligence requirements, which we’ll call our collection requirements. Lets take another example:
[Image: https://d39ec1uo9ktrut.cloudfront.net/5484b-0blbgssfmxhnzohub-300x138.png]
In the above example what we have is:
-> Collection requirements (what observables/data inputs do we need to answer our intelligence requirements)
By breaking out your organization’s collection requirements this way, it will allow you to better assign the responsibility to collect for a specific collection requirement to a team, capability or external provider which can be regularly assessed to see how it fits into helping meet your organization’s intelligence requirements. When it comes to external providers of intelligence, there’s a number that sit in the intelligence cycle between collection and dissemination. Intel 471 sits primarily in the collection part of the intelligence cycle and works with organizations to more effectively collect against their externally focused collection requirements. When we refer to “externally focused” collection requirements, what we mean is that collection requirements can either be internally focused or externally focused where internally focused collection requirements require visibility on the subject organization’s attack surface. Externally focused collection requirements involves requirements that are adversary/cyber threat actor focused.
[Image: https://d39ec1uo9ktrut.cloudfront.net/f8a86-0zrmpkjhzc1puljuj-239x300.jpg]
The holy grail of cyber threat intelligence prioritization?
The holy grail of cyber threat intelligence prioritization is to have a single long-term prioritized list of production requirements that is updated twice a year. The production requirements should be broad enough to encompass short-term requirements that immediately head to the top of the priority list but are very narrowly focused and only last at maximum 30 days, for example a requirement to assist with incident response to a security breach. In the absence of a single prioritized list, breaking down intelligence priorities by high, medium and low priorities is acceptable and is common practice with most resources going into satisfying high priority items.
Intelligence requirements: Attack surface or adversary focused?
A common question cyber threat intelligence professionals encounter is whether their organization’s intelligence requirements should be attack surface or adversary focused. A single intelligence requirement could be either but not both. An intelligence requirement in the context described above needs to relate to a specific observable that is eventually tasked to a team, capability or external provider so will need to be attack surface or adversary focused.
Initial access brokers (IABs) sell access to compromised organizations on underground forums. Here's an analysis looking at whether these offers can be correlated to ransomware attacks.
The disruption of the XSS cybercrime forum and arrest of its administrator in Ukraine in July 2025 has shook Russian-speaking cybercriminal communities to their core and raised questions if the forum can recover.
The Lumma infostealer malware collects highly sensitive data including logins and session tokens. Here's how to conduct a threat hunt leveraging up-to-date tactics, techniques and procedures used by Lumma.
Stay informed with our weekly executive update, sending you the latest news and timely data on the threats, risks, and regulations affecting your organization.