A Topic Is Not a Problem
"IoT security" is a topic. "Why do so many consumer IoT devices ship with unchangeable factory-default credentials, and what share of internet-facing devices in a given sample are still using them" is a research problem. The difference matters: a topic tells you a general area of interest; a research problem tells you exactly what you're going to try to find out.
A well-defined research problem needs four things:
- Specificity: it names the exact phenomenon, population, or dataset under study.
- Answerability: it can be resolved with data and methods the researcher can actually obtain.
- Non-triviality: the answer isn't already settled, or not settled with the rigour the field now expects.
- A stated boundary: it says plainly what counts as inside the study and what counts as outside it.
Reframing a Question: the Mirai Botnet, 2016
In October 2016, a botnet called Mirai, built almost entirely out of compromised IP cameras and home routers, launched some of the largest distributed denial-of-service attacks recorded up to that point. One of them knocked a major DNS provider offline and briefly took down Twitter, Netflix, and several other large sites for users across the United States.
The first question most reporters asked was "who is attacking us," which pointed at three university students who'd written the code to extort Minecraft server operators. That framing made for a dramatic headline, but it told a researcher very little that was useful.
A more productive research problem, and the one the security community actually pursued afterwards, was narrower: how many internet-facing IoT devices still ship with a small, fixed set of hardcoded factory username-password pairs that can't be changed by the owner, and how quickly can a scanner find and infect such a device once it's online? Mirai's own source code, once leaked, answered part of this directly: it listed barely more than sixty such credential pairs, covering products from a long list of manufacturers.
Reframing the question from "who did this" to "what structural weakness made this possible at this scale" is what turned a news story into a research problem with an answer that generalised far beyond the three people who happened to write Mirai.
Breaking a Problem into Sub-Problems
A well-defined research problem is usually still too large to attack in one move. The standard next step is to divide it into sub-problems, smaller questions that can each be answered on their own, and whose combined answers resolve the main problem. A good sub-problem meets three conditions:
- It's a genuine piece of the whole. Every sub-problem should cover part of the main problem, and the sub-problems together should cover all of it: no important part left out, no overlap doing the same work twice.
- It can be researched on its own. Each sub-problem should be answerable with its own data and its own method, rather than depending on another sub-problem's answer first.
- It stays small in number. Two to four sub-problems is typical for a course project. A list of ten or more usually means the main problem wasn't narrowed enough before the split was attempted.
Applied to Mirai, the main question, "why did Mirai spread so effectively across IoT devices?", splits cleanly into three:
- SP1: What share of internet-facing IoT devices use unchangeable default credentials?
- SP2: How quickly can a scanner find and infect such a device once it's online?
- SP3: What manufacturer or regulatory change would shrink this vulnerable pool?
SP1 is descriptive, SP2 is closer to experimental, and SP3 is the control-oriented question that the first two exist to inform. Notice that SP1 and SP2 together are what actually answer the main question. SP3 is a natural next step but isn't required to resolve the main problem itself. Keeping it as a clearly separate sub-problem, rather than quietly folding it into SP1 or SP2, is what stops a project's scope from creeping outward while data collection is already under way.
WannaCry and Mirai, Side by Side
Both incidents are still cited in security research today, because each traces a global-scale event back to one preventable, well-understood cause.
| WannaCry (2017) | Mirai (2016) | |
|---|---|---|
| Attack type | Self-spreading ransomware worm | IoT botnet used for DDoS |
| Root weakness | An unpatched Windows SMB flaw | Unchangeable default device passwords |
| Scale | 200,000+ systems, 150+ countries | Peaked near 600,000 infected devices |
| What stopped it | A hardcoded kill-switch domain | Arrest of its authors; the flaw itself remains unfixed in most devices |
| The research lesson | Patch discipline matters more than exploit sophistication | Structural design flaws scale further than any single attacker's skill |
Check Your Understanding
A classmate proposes "studying ransomware" as a project topic. Rewrite it as a specific, bounded, answerable research problem, applying all four criteria above. Then try the reverse: split the following problem into two or three sub-problems of your own: "Why do employees in some departments of an organisation click phishing links far more often than employees in other departments?"