Conundrum methodology · 8 min read · Updated September 2026
The Big 5 are the five methods by which nearly all attacks arrive: phishing, malware, denial of service, hacking and insider threat. Organising intelligence around the vector, the how, rather than around the threat actor, the who, gives a team defences that hold against adversaries it has never heard of, and a structure that non-specialists can read.
Read first: The intelligence cycle (the process these vectors organise)
There is a long-running argument in this discipline about whether an intelligence function should organise itself around threat actors or around the methods those actors use. The position here is the second one, firmly. Effective threat management comes from understanding how an adversary operates rather than from establishing who they are.
This is not a rejection of actor tracking. It is a claim about sequence. Vector first, actor second.
An organisation that structures its intelligence around a list of known actors has a predictable blind spot: the group that is not on the list. New entrants targeting your peers do not announce themselves, and a function watching fifteen named adversaries will be looking the wrong way when the sixteenth arrives. A method-centric approach does not have that failure mode, because a new group using a familiar technique walks into defences that are already there.
The MITRE ATT&CK framework reinforces the same logic by cataloguing behaviour rather than identity. Phishing sits under initial access, at the start of a chain, and detecting or disrupting an early-stage technique cuts off a large share of everything that would otherwise have followed it. Effort spent at that end of the chain has leverage that effort spent on attribution does not.
Attribution is not worthless. It is slow, frequently uncertain, and secondary: useful context once the defensive work is done, and a poor foundation to build the defensive work on. The uncomfortable version of this, familiar to anyone who has briefed a board, is that naming the group often satisfies the room without changing anything. The better question is the one a sceptical board member asks next: so what, and what do we do about it?
Phishing is social engineering aimed at getting a person to hand over credentials, money or access, usually by impersonating something the recipient trusts. What has changed is the sophistication rather than the principle.
Business email compromise is the clearest evolution: attacks conducted by compromising or spoofing a legitimate account, often carrying no malware and no malicious link at all. There is nothing for a scanner to detect because the attack is entirely text and context. Elsewhere, attackers increasingly route through legitimate URLs on reputable platforms that redirect to credential harvesting, and attachments have moved from crude executables to obfuscation and macro-based loaders.
The intelligence message underneath all of it is simple enough to give to non-specialists: unsolicited messages deserve caution regardless of how they look, because phishing exploits trust, and trust can be manufactured.
Reporting on this vector should stay simple and consistent, and should answer a short list of questions every time: how many malicious messages arrived, how many were blocked automatically, how many were clicked, what they contained, whether malware was involved and of what kind, where the user was directed, which parts of the business were targeted, and whether the same pattern is being seen across the wider industry.
One warning that belongs in every phishing briefing: the absence of impact is not the absence of threat. A run of quiet quarters tends to persuade boards that the controls can be relaxed, and the gap between relaxing them and someone exploiting the gap is short.
Malware has stopped being the preserve of capable actors. Malware-as-a-service has commoditised it to the point where a semi-skilled criminal can select features from a menu, pay in cryptocurrency and deploy: a jukebox model, insert fee, choose payload, press play. The consequence for defenders is a proliferation of variants built on shared codebases with new evasion bolted on, which further undermines any strategy that depends on recognising a specific group's tooling.
The useful classification is by role in the intrusion rather than by family name:
Read that way, malware is a phase in a life cycle rather than a standalone event. The analytical questions become where in the chain it sits, what its presence says about the adversary's intent, and what its capability implies for this organisation specifically.
Ransomware is where this vector has evolved furthest, from a blunt weapon into an extortion industry with affiliates, revenue sharing, negotiation support and payment processing. A campaign typically runs initial access, persistence, credential harvesting, lateral movement, payload delivery, encryption with exfiltration beforehand, and then extortion.
Four things make it distinct from the rest of the malware vector. It is financially motivated and organised rather than disruptive or espionage-driven. It uses double and triple extortion, threatening to leak data or notify regulators on top of encryption. It is frequently human-operated, with people tailoring the attack in the environment and stepping around automated detection. And its dwell time is short while its consequences are long: the intrusion may be measured in days and the recovery in quarters.
That last property is why ransomware belongs on a risk register rather than only in a SOC queue. It is a business event with regulatory, legal, brand and continuity dimensions, and the intelligence function should be working with backup, disaster recovery, legal and communications teams before there is an incident to work with them about.
Denial of service uses distributed infrastructure, typically a botnet of compromised devices, to exhaust a target's capacity until legitimate users cannot reach it. The growth of poorly secured connected devices has raised the ceiling on what is achievable considerably.
The intelligence questions here are less about the technique, which is well understood, and more about dependency: which parts of the internet would have to be unavailable to stop you operating, which services would degrade, whether a contingency exists, and whether your provider is actually delivering the protection you assume they are. Those are answerable questions, and most organisations have not answered them.
Hacking, in this model, means direct unauthorised intrusion into a system or network: exploiting a vulnerability rather than persuading a person or deploying a tool.
The exposure has shifted toward third-party software and SaaS. Where an organisation depends on platforms it does not control, a vulnerability in one of them is a vulnerability in you, and capable actors now move from disclosure to working exploit fast enough that patching cadence becomes a genuine determinant of outcome. The intelligence contribution is knowing which vulnerabilities are being weaponised, in what you actually run, before the patch window closes.
Insider threat is risk originating inside the organisation, and the common mistake is to read it as a synonym for malice. A great deal of it is accidental: data shared with the wrong party by someone who did not understand the policy, documents misdelivered, corporate resources reached over insecure networks, passwords reused across services.
That distinction should shape the controls. A programme designed only to catch a hostile employee will miss most of what actually happens, and treating every error as a potential betrayal is corrosive to the culture you need in order to hear about mistakes at all. The objective is an environment as forgiving of human error as it is resilient to deliberate sabotage.
The five are a taxonomy, not a set of walls. A single real incident moves through several of them: a phishing email delivers malware, the malware harvests credentials, the credentials enable hands-on intrusion, and the confusion of the incident gives cover to insider activity, whether deliberate or not.
This is the argument against organising security functions as silos that mirror the taxonomy. The vectors are useful for structuring intelligence and communication; they are a poor model for how an attack behaves, and a defence built as five separate programmes will have five separate views of one event.
The Big 5's practical value is that it gives a shared vocabulary across people who do not share expertise. It structures requirements, guides vendor selection, frames threat assessments, and gives reporting a consistent shape that recipients learn to read.
The compact form is a single table with one row per vector, carrying what has been seen, the methods in use, the impact, the control that most matters, and where attention should go next. On one page it lets an analyst communicate trends, a security operations team align detection to known methods, and an executive see where risk sits and where investment is needed, without any of them having to read the others' material.
In a mature function it stops being a static chart and becomes a live view, linked to incidents, reporting and per-vector risk. That is the direction to build in.
Identifying a threat is not the same as understanding it. The analyst's contribution is impact: what this specific capability could do to this specific organisation, and what follows from that.
There is a useful image for this. An expert handling a venomous snake knows it is dangerous not from its label or its appearance but from studying its behaviour, its venom, its history and the available antidotes, and the practical question is not what the species is called but what you would have to amputate to survive a bite. Four things follow: understanding the adversary matters, impact matters as much as identification, threats evolve so yesterday's mitigation may not hold, and controls are not permanent.
Conundrum is organised by vector rather than by actor. Collection, scoring, reporting and dissemination all run per vector, each with its own requirements and its own reporting lane, which is a direct implementation of vector first, actor second.
There is a sixth lane alongside the five: geopolitics. It is not an attack vector and is not presented as one. It is carried separately because geopolitical events change which threats matter to whom, and folding that into one of the five would misrepresent it.
Threat actors and malware families are still resolved, named and tracked, cross-referenced against public registries. They are context attached to the vector view rather than the axis the platform is organised around.
MITRE ATT&CK, and why TTPs beat actor names
the technique-level view of the same behaviour
