Establishing an Intelligence Requirements Process

Whether you are starting out a threat intelligence program or have an existing program already in place, one of the key pieces to define is the requirements for producing your intelligence. In this blog, we’ll cover why you should have an intelligence requirements process, what that looks like in practice, and how to best use requirements to drive your threat intelligence program.

Why intelligence requirements?

Without a structure in place to produce your intelligence, you are just assuming the work you are doing matches whatever needs your organization may have, which is rarely the case. How do you know you are producing work that benefits your customers? How do you make sure you are answering the right questions? How do you measure the success of your threat intel program? All these questions can be answered by intelligence requirements.

Without requirements, you don’t know what to prioritize, and how to best support your customers, which are two major value propositions of intelligence requirements. With well-defined requirements, you have a document that clearly defines the asks, the deliverables, the customers, and priority for the different questions your stakeholders need answers to. 

How do you use intelligence requirements?

The first thing you should be doing is meeting with your customers to draft the intelligence requirements. Customers can range from actual clients of your company, to your internal SOC or Incident Response team, to executives and leadership. Whoever your team is built to support would be a potential customer here. You’ll first need to set up some face-to-face time with these customers to identify the requirements, and in those meetings, you’ll want to understand what questions they need to be answered from you and your team.

The questions they ask should be specific enough that you can give them a clear, confident answer. If they are asking general questions like “What threat actors would target our company?," you may wish to be more precise. While it’s a valid question, it is potentially more hypothetical and may lead to speculative and not strictly evidence-based answers. Something better could be “What current threat actors are seen utilizing BlueKeep exploits to compromise a company?," since this is more specific, and your team can provide evidence-based answers to this question. You should strive to work with your customers on defining clear requirements and guiding them through that process to ensure you have good requirements going into things.

Depending on your intel team’s function, you may have some internal requirements that drive your work but are not necessarily asked for by your direct customers. This could take the shape of producing threat intel reports that are released openly and shared with the world to educate people on a certain attack or active campaign that may be impacting them. These can still be valuable, even though they weren’t direct asks from customers since this could improve the overall security of people globally.

What does this look like in practice?

There isn’t a standard for drafting intelligence requirements and therefore they can take various forms, but we’ll tell you what’s worked so far based on collective experience for us here at ZeroFox. Depending on your company, you may have an internal wiki, use Confluence or Google Drive for your documentation, and we’d recommend you utilize what your team standardizes on to store and document your requirements.

Once you have your notes from your customer meetings, you’ll sit down and start drafting these with your documentation tool of choice. We recommend capturing the following sections:

• Summary
• Gaps
• Customers
• Deliverables

These sections will get you started, but there may be specific topics you want to include in addition to these sections. In the Summary area, you’ll want to capture the overall goal of this requirement and a brief write-up of what it’s asking for. Identifying gaps is the area you’ll want to include the most detail in since this is what you’ll actually plan your workaround. The Gaps section includes all the customer-specific questions that require intelligence, which should be prioritized based on customer needs.

The Customers section should include all the stakeholders that this will benefit and should include the Point-of-Contact information for who will be receiving this intelligence. In some cases, this requirement can benefit multiple customers, so you’ll want to identify everyone this requirement is for and how to deliver it to them.

Lastly, the Deliverables section should be the outcome of this intelligence requirements work. Do the customers just want a presentation at the end of it? Do they want more tactical intelligence to include in their SIEM for alerting on new threats? Whatever format they need this in, you should document it here. One area we didn’t mention is the time requirements, which could go here next to each deliverable or in the Summary section perhaps. 

Now what?

After implementing the intelligence requirements process above, you should be on your way to having sit-downs with your customers to go over their needs and questions, along with having a centralized place to store your prioritized list of requirements that includes their specific questions to be answered. Having these will allow you to make more informed decisions as to how your team works and what they work on, helping you to meet your customer needs and ensure you are answering the right questions. You shouldn’t mark this process as being done just yet since requirements don’t end here. Customer’s needs can change all the time, so you’ll want to have a good cadence for following-up with them to make sure the work you are doing still aligns with their needs.