At Digital Shadows we get excited about intelligence. In fact, we’ve talked about it more than once before. One of the problems with any specialized job function is that it often has its own lexicon.As intelligence analysts at heart, we don’t mean to, but sometimes it’s us pushing a book of complicated words, terms, concepts, and jargon in everyone’s face without stopping to consider that:
- We may have never defined them and/or
- We might’ve expected you to understand them immediately.
The problem is sometimes people are new to the conversation and so it’s good to go back and refresh on the important things. This article aims to dispel some rumors around intelligence terminology, especially when talking about intelligence requirements and how they’re built at a tactical, user level. In addition to some of the terms, hopefully, this explains a few key concepts that are important to understand for any intelligence user, including producers and consumers.
What is an intelligence requirement?
A few weeks back, my colleague Kim wrote a brilliant blog about the intelligence cycle. One of the key points that she raised, especially in the planning & direction phase, was to develop intelligence requirements. Unless you’ve received formal training at the likes of Fort Huachuca, Chicksands, or Quantico, the concept of an “intelligence requirement” may still be new to you. Developing intelligence requirements is the first—and arguably one of the most important— steps in making the intelligence cycle go ’round.
- Requirements provide direction for an intelligence analyst to gather and collect information.
- Requirements define the required resources and also gaps in capabilities for collection management purposes.
- Requirements determine the end product that will be produced and whether the end-user will be satisfied with the results.
The process of forming intelligence requirements starts as a conversation between the analyst and the end-user. If this conversation doesn’t take place, then information is being collected without purpose, there’s a chance the end-user will not be satisfied with the results. Not to mention time and other resources will have gone to waste.
What does a requirements conversation look like?
A conversation about requirements might look a lot like asking an aspiring intelligence consumer about what their daily work is like, what information needs they might have, what problems they’ve encountered previously, and what types of information they already know or have access to so that work is not duplicated.
It might also be asking about their absolute dream list of information needs, and it may also be setting expectations about intelligence capabilities. Unfortunately, we’re not all-knowing savants all the time: sometimes the collection doesn’t work out, and sometimes we get it wrong.
Developing a requirement often starts with answering the 5 W’s: Who, What, When, Where, Why—and sometimes most importantly, “How”.
Talking about these questions can determine the Essential Elements of Information (EEI) to produce intelligence that matters to the end-user. Everyone wants to know who’s attacking or why, but maybe knowing how or when they’re attacking is the more important part to focus on as a tactical goal. To be answerable, they should be simple. Even in a dusty US Army intelligence field manual published in the mid-1990s, the guidelines for developing intelligence requirements still ring true today:
- Requirements should only ask one question.
- Requirements should focus on a specific fact, event, or activity.
- Requirements provide the intelligence required to support a single decision.
To put it another way, a European retailer asking the question “Which cybercriminal groups are currently active?” may be too broad and will result in way too many answers. Instead, we can ask:
- Does current mean existing today, or within the last 30 to 180 days?
- Is there a specific application vulnerability or exploit that keeps the end-user up at night?
- Is there a particular industry or other profile that’s more applicable and interesting to the end-user?
We need to refine the question in order to provide a useful answer.
In this case, asking the above questions leads to a better approach which asks, “What criminal groups in the last six months have been actively targeting Magento in the European Union?” There are now some defined paths to explore, which results in more focused intelligence collection and production. This can reduce the threat intel noise, as our CISO has spoken about previously.
What would a completed product look like in answer to this question? This is just an example of what a profile on the actors behind the Magecart campaigns might contain:
- Standard indicators of compromise (IOC) for the security tools
- System behaviors or other indicators of attack (IOA) for the threat hunters
- An overall assessment based on the recent activity we’ve observed based on our data or what we’ve seen others in the community reporting
We may also look at other groups that are targeting rewards programs or gift cards, or actors who may be just trolling for targets of opportunity. For a European company using Magento in the e-commerce space, all of these inform the overall threat assessment based on the given intelligence requirement.
How should you measure success?
The next step is to produce a collection plan which helps coordinate efforts among various teams. There should be an agreed-upon timeline among all parties to deliver updates or the final product. It should also be very clear to both intelligence producers and end-users what determines a success.
If everything was executed correctly, but nothing came out of the collection, all parties should also understand why. There is a difference between looking and not finding anything versus didn’t or couldn’t look for something. The former illustrates how sometimes life can be beyond our control, versus the latter, which may indicate an unrealistic timetable or a gap in capabilities.
A lot has probably happened behind the scenes to make the magic happen on the analysis and production side of things. There may have been technical research needed for specific hardware or software vulnerabilities, language and targeting expertise to seek out where a cybercriminal group may be chatting online or selling their goods.
Several layers of checks and balances are also required to ensure quality assurance of the collection itself, as well as the final product. Essentially, what started as a conversation between a client and a senior analyst turns into a team effort that may last hours or days. This is precisely why requirements need to be so well-defined from the start, especially since various collection and analysis efforts are often happening simultaneously.
Some Closing Thoughts on intelligence requirements
Keep in mind that we’re not talking about big-picture, strategic requirements, which operate at higher levels than the tactical ones we’re discussing today. Tactical intelligence requirements are generally more short-term in nature and more applicable at lower levels. However, the methods to derive tactical versus strategic requirements can be very similar, however. A recent podcast guest, Anomali’s A.J. Nash, made some excellent points about having an overarching intelligence program that includes executive responsibility to help guide different types of intelligence requirements at all levels. There’s also a lot of great academic material on the subject if this is an area of interest for you, wherever your role is in the intelligence cycle.
Hopefully this article helped clear up the unknowns about how to build them and how they come into play. The practice behind developing them can help inform other types of intelligence requirements. Multiple teams within the same organization each may have their own specific needs and intelligence requirements: What works for one team as an intelligence requirement may not work for another. Efforts should be made to understand where requirements differ and what’s necessary to fulfill them with the right intelligence.
Here at Digital Shadows, we often sit down with clients to understand their specific intelligence needs during an incident, for instance, or based on a formal request-for-information (RFI). A discussion about intelligence requirements might happen during Zoom chats or phone calls, over email chains, or a combination of these. Our goal is to ensure we understand a client’s requirements and highlight any possible limitations. If you have concerns about your exposure or would love to get more intelligence in your life, we have a way for you to test drive Searchlight for a week, or you can request a demo.