Best Practices: Intelligence Requirements

What Is An Intelligence Requirement?

An Intelligence Requirement (IR) is a collection of topics or a research question reflecting an organization’s cyber threat–related priorities that guides a security or threat intelligence team’s research and analysis efforts.

Examples

• What ransomware variants are being leveraged against financial institutions based in the United States?
• What threat actor groups target energy companies operating in the United States and Saudi Arabia?
• What vulnerabilities exist in Microsoft Office 365?
• Threats targeting finance in the United Kingdom
• Vulnerabilities in industrial control systems leveraged by energy companies

Types of Intelligence Requirements

• Incident Related: Derived from incidents and alerts worked on by an organization’s SecOps, SOC monitoring, or incident response team
• Geographical: Informed by the geographical location(s) in which an organization operates
• Industry: Informed by an organization’s industry
• Technology: Focused on technology leveraged by the organization
• Ad-hoc: Requests that come from leadership or are related to recent or current events

Subtypes of Intelligence Requirements in ThreatConnect

• Intelligence Requirement (IR): Threats of overall concern to an organization (e.g., cyber threats, fraud, geopolitical/physical threats)
• Priority Intelligence Requirement (PIR): Threat actor motives; tactics, techniques, and procedures (TTPs); targets; impacts; or attributions in association with IRs
• Specific Intelligence Requirement (SIR): Facts associated with threat activity, such as indicators of compromise (IOCs)
• Request for Information (RFI): One-off requests for information related to topics of interest to particular stakeholders
• Research Requirement (RR): A topic or area of investigation that is of interest to an individual or group and does not merit a full intelligence requirement, but does require tracking of relevant information

In ThreatConnect^®, most requirements will likely be either the IR or PIR subtypes. The SIR subtype should only be used to investigate specific items related to the larger requirement subtypes. The RFI subtype should be used  for one-off questions and requests from stakeholders, while the RR subtype should be used  to capture in-depth investigations focused on specific areas that may not be covered by the IR or PIR subtypes.

Creating Intelligence Requirements for Your Organization

Step 1: Collect information on areas of interest from stakeholders

IRs supply the security organization with the information they need to make decisions. The first step in creating these requirements is to identify what matters most to your stakeholders. These stakeholders may be representatives from each business unit in the organization, leadership from different security teams, the Chief Information Security Officer (CISO), or the Chief Information Officer (CIO).

One of the biggest challenges around creating IRs is getting information from stakeholders. These struggles often arise when looking for input about what the requirements should include and feedback on how well the information provided via reporting and briefings addresses them.

There are a few ways to collect information on areas of interest from stakeholders. Some organizations use a survey and ask a series of questions designed to narrow the topics that may be of interest or useful to the organization. These questions can include multiple-choice questions like “Which of the following topics do you find most important to the security of our organization?”, with choices such as cybercrime, ransomware, advanced persistent threat groups, phishing, and so forth. Alternatively, some organizations schedule a recurring meeting with stakeholders to gather their thoughts and feedback. Often, it is easier to start with a set of preliminary topics and narrow the focus, as some stakeholders may not know what they want or what would be most valuable at first.

The key point is to avoid creating requirements without context. The threat intelligence team is there to support the rest of the security organization, and that starts by focusing on the things that are most impactful to the organization's stakeholders.

Step 2: Identify the type(s) of requirement(s) that will work best for you

Many teams find it best to start with what they know. For some, that means starting with geographical- and industry-focused requirements; for others, that means beginning with requirements derived from incidents and alerts worked on by other teams within the security organization.

One of the most effective approaches is to start with something relatively straightforward for you and your team. This approach helps build confidence in the requirement-defining process and allows the team to overcome hurdles when starting with a large project they must complete before they can define requirements. For example, if the organization has not identified and cataloged all the technologies its employees use, then starting with a technology-focused requirement would necessitate a project to catalog all of those technologies. This cataloging project would push the requirement-defining effort back until it is complete. To avoid this situation, start with something that is known when identifying requirements for your organization.

Step 3: Draft a preliminary set of requirements

Using the information gathered from stakeholders and an understanding of the type(s) of requirement(s) that best fit your team and organization, draft a preliminary set of requirements. These may take the form of research questions, lists of topics, or statements. The important thing is that the requirements are in a format that makes sense to your team and organization. The most effective requirements are specific and focused on a particular time frame (e.g., “Cybercrime activity targeting energy companies sponsoring the 2024 Super Bowl”), but some teams will have more open-ended requirements (e.g.,  “What state-sponsored threat actors are known to target financial organizations with operations in the United States and Singapore?”).

This can be a daunting task in the requirement-creation process, but the key is to get started. It is much easier to refine a set of requirements than it is to start from scratch. Do not worry about getting it “right” the first time; the important thing is to have a set of requirements to start with that you can refine them over time as you figure out what works best for you and your organization.

Step 4: Review the draft of requirements with stakeholders

This step is the most important when creating requirements because it helps teams ensure their requirements align with the rest of the business. It is also one of the most commonly skipped steps because it can be difficult to get stakeholders to provide feedback due to scheduling conflicts and competing priorities.

An effective way to review a draft of requirements with stakeholders is to schedule a  recurring meeting with them to collect additional information about their areas of interest, review existing requirements, and obtain their sign-offs. Another option is a survey-style email that allows stakeholders to read the requirements on their own time and provide feedback, either via a freeform text field or by selecting one or more options from a set of answers (e.g.,  “Yes, this will be helpful” or “No, this will not be useful to me”).

Step 5: Update the draft of requirements and finalize them based on stakeholder feedback

After reviewing the draft of requirements with stakeholders, update it based on their feedback, and then finalize the requirements. Some teams complete this step by capturing the finalized requirements in a tracking spreadsheet or another similar tool. In ThreatConnect, users can leverage the new Intelligence Requirement feature to capture their finalized requirements and track information in their local ThreatConnect instance and the ThreatConnect Global Intelligence Dataset that is related to those requirements.

Next Steps

Identify a Timeline for Reviewing and Updating IRs

As mentioned in Step 4, one way teams can ensure they review and update requirements with their stakeholders regularly is to schedule a recurring meeting. It is recommended to review and update requirements quarterly, biannually, or annually, depending on your team and business needs. Cyber threats are evolving constantly, and your organization’s priorities may change over time. Because of this, scheduling regular intervals for this review process can ensure your team is investigating the things that are most impactful to the organization.

Create Collection Requirements From Your IRs

Once you finalize the IRs, create collection requirements to focus the team’s resources around getting the information needed to answer their IRs. A good place to start with collection requirements is by looking at the sources and tools that might help address the requirements. Are there particular OSINT or premium feeds focused on areas that relate to your requirements? Do you need to invest in a bespoke solution to capture relevant information? Answers to these questions can ensure that the team’s resources are spent on the tools and feeds that will be most helpful.

Use IRs to Focus Your Team’s Work

One benefit of having defined IRs is that they can shift a team's focus to the things that matter most to the organization. IRs identify exactly what the team should be investigating and researching. Most of the analysts’ time should be spent on things related to the requirements themselves. This can be accomplished in several ways, but one option, if feasible, is to assign individual IRs to particular analysts or sets of analysts so that each team member knows their areas of responsibility.

ThreatConnect^® is a registered trademark of ThreatConnect, Inc.

20159-02 v.01.A