So I ask OSINT students to solve a modest research assignment any way they see fit. They all listen carefully to me, then turn around to the computer screens and frantically start typing.
After a few minutes I call them back to the central table to ask them what exactly they are doing, what is the research plan, the approach, the strategy?
No one answers.
The research assignment is full of vague terms, ambiguous terms, omissions, contradictions such as: the latest, recent, some, “a list of”, references, most important, “to what extent”. But no one asks me what I mean with that. No one asked me what the information is going to be used for, what the purpose is, the goals, what the problem is I am trying to solve with that information. No one asks who the customer actually is.
Yet they are all typing.
I wonder what.
Once I show them that the assignment is so vague that it cannot be solved, the penny drops. Once I demonstrate that it is impossible to start any OSINT assignment without knowing the customers’ intent, another penny drops. Then it is time to teach the concept of An Answerable Question. A research question that is so precise, detailed, complete and accurate that there can be no misunderstanding to what information exactly is required.
An Answerable Question is part of the OSINT process Requirement Analysis and Problem Deconstruction. Following Kettering’s law*, I share with the students OSINT Standard Operating Procedure (SOP) #4 : a full implementation of describing and solving the assignment problem Arno’s way: concept analysis, assumptions analysis, customer analysis, and Answerable Questions.
It takes time. And effort. But the benefits are clear.
- Searching and finding the public open source domain is much easier once you know what you are looking for.
- A well and clearly designed requirement analysis and intelligence collection plan explain when to stop.
- Continuation at a later date or by some one else in the team is now possible.
- Since we know exactly what to do we can now make a time planning and even a budget.
- Collecting the requirement analyses over time allows for analysis of customers’ requirements so we can look ahead.
- Finally, team work is now possible. An assignment can be shared amongst multiple team members.
Remember Law #4: ”no OSINT research makes any sense without detailed requirement analysis and problem deconstruction”
I have been using this technique for 25 years now, gradually changing and improving, using tables and flow charts for assistance. But believe me, everything you think you are doing wrong I did wrong too. And I still make those mistakes. I still remember that particular customer coming to my office asking me to do the same research I did two months earlier, again. But back then, I simply started typing until I found what I needed, I compiled, edited, analysed, collated and produced. So I had no clue what he was talking about.
Making mistakes is good. Mostly, you can learn so much from mistakes, but on the condition that: 1. the person concerned acknowledges the mistake, and 2. that the person is willing to learn from it.
* A problem well stated is a problem half-solved” Charles Kettering (1876-1958)
