Requirements. The first part of the intelligence cycle and the most neglected. According to the appendix of Joint Publication 2–0: Joint Intelligence
intelligence requirement. 1. Any subject, general or specific, upon which there is a need for the collection of information, or the production of intelligence. 2. A requirement for intelligence to fill a gap in the command’s knowledge or understanding of the operational environment or threat forces.
Intelligence requirements (or just requirements) are key questions (as @cyint_dude calls them) that stakeholders (the CERT, leadership, etc) want the intelligence team to answer. Requirements set the entire priority of your intelligence cycle, what sources you collect from, what types of processing you need to do, and what methods of dissemination will meet the need. Where your team is focusing, aka Squad Goals. Lets get started…
Past Incident Based Requirements
Effective leadership is putting first things first. ~ Stephen Covey
I’ve said it a thousands times, but place #1 to start is your own incident management system. Build requirements based on incidents you’ve already investigated, every IP address, every piece of malware, every domain. Why do you think firms with consultants who do incident response always have good intelligence? It’s no coincidence, they set intelligence requirements based on the incidents they respond to and so should you. This isn’t ground breaking, so we’ll move on.
Business Plan Based Requirements
If there are two men, Rod and Rob, and you can only steal from one, which one would you choose? The answer is: Whichever one is a banker. ~ Jarod Kintz
The next place to gather requirement is by digging into your organizations business plan. Certain actors target resources in a way that you can rule them in or out of scope:
- Are you a bank or financial institution? Financially motivated attackers probably want to attack you.
- Are you doing energy exploration? A handful of attackers specialize in that.
- Do you invent pharmaceuticals? Look for actors that try to steal intellectual property.
CrowdStrike illustrated this in their Uncover the Adversary map:
So using this as an example (and CrowdStrike vernacular):
- What about that bank? They’ll want to focus on Deep Panda, Impersonating Panda, and Singing Spider.
- If you’re an oil company you should be on the look out for Cutting Kitten, Energetic Bear, and Ghost Jackal.
- The firm with the new heart attack treatment? I’d be on the look out for Deep Panda, Union Spider, and Corsair Jackal.
These distinctions won’t always be perfect but they provide a solid basis to develop requirements. Your industry heavily defines your threat model and thus is a rich starting point to begin defining your intelligence requirements.
Geographic Based Requirements
I get to go to overseas places, like Canada. ~ Britney Spears
Geography is a tricky thing. The Internet lets us access information across the world yet at the same time it’s often an extension of real life. Attackers take advantage of geographic distribution to remain semi-anonymous, but in others they use computer network attack to project a different kind of power within a region.
The Naikon Group is a good example. Public reports say they’re focused on operations within South East Asia. Don’t live in South East Asia? Naikon is probably not interested to you. Living in Singapore? You should probably be paying attention. Even though an actor could strike across the world (and may do so) it would be sloppy to not consider location in defining intelligence requirements.
Aside: Before you say it I agree, VPNs are easy and hotpoints can be anywhere. Avoid assuming too much when it comes to the Internet and physical location._
Technology Based Requirements
Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. ~ Unknown
It’s a common mistake to think of attackers as omnipotent. They have limits, budgets, time, etc. As a result most attackers focus on attacking certain kinds of networks. A Windows network running Active Directory is often harder to attack than a Linux network on LDAP (don’t knock MSFT, they’ve invested a lot in security over the last 15 years) but the fact is most attackers are probably more familiar and invested in attacking Windows and AD.
When developing intelligence requirements take the time to look around your infrastructure, what makes you special? Do you run lots of Industrial Control Systems? You should probably be paying attention to different attackers than a law firm running all Macs. Part of this is vulnerability management as well, understanding the flaws that are out there for the systems you protect, but it’s also understanding what attacks can exploit those vulnerabilities.
Vertical Based Requirements
I would rather walk with a friend in the dark, than alone in the light. ~ Helen Keller
One of the least appreciated approaches to forming intelligence requirements is asking others. Backs work with banks on similar criminal groups. A university could collaborate with similar universities by sharing information about incidents. Industry has been embracing this for years with the formation of Information Sharing and Analysis Centers such as FS-ISAC, the Retail Cyber Intelligence Sharing Center, and others. Whether formal or informal these groups provide the chance to learn from others and avoid making the same mistakes twice.
One Off Requirements
Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. ~ Donald Rumsfeld
Then there are the odd bits. They may come in when a higher up is watching CNN in the airport or they may come from a spooky government source. No matter what they will show up at some point and become part of your intelligence requirements, maybe as a one time addition, maybe on an ongoing basis. Don’t discount them.
Writing Strong Requirements
The best intelligence requirements are specific enough to direct answering the question. Here are some characteristics that lead to good intelligence requirements:
| Characteristic | Description |
|---|---|
| Singular | A strong requirement focuses on one question and only one question. |
| Atomic | The requirement should be specific to a particular fact or event. |
| Decision Centric | The requirement should lead to making a decision. |
| Timeliness | A requirement should capture the timeframe for usable intelligence. |
It takes time and practice to develop good requirements.
Weak Requirements
- What actors might attack our company?
- What indicators should we be using in our IDS?
- Are there actors targeting the location we’re in?
- What malware should we look for on our network?
- Will our organization get DDoS’d?
Strong Requirements
- Is X Actor active?
- What are current file system indicators of Actor X?
- Is an actor specifically targeting Region Y?
- Are attackers using Locky against my vertical? Are there indicators of DDoS attack in the next 30 days?
Practice makes perfect, but working with others to sharpen your requirements writing is even better.
Just the Start
Even though they’re commonly missed the fact is developing good requirements sets the solid foundation for a good intelligence cycle. If you want to read more the CIAs Center for Intelligence Studies has a great article A Fresh Look at Collection Requirements and Army Field Manual 34–2 Collection Management to Support Commanders includes the appendix Developing Priority Intelligence Requirements. Read those and you’ll be on the right track.