Why do intel teams track an intrusion as a numbered activity cluster instead of naming the actor?
answer
- start from what your telemetry supports
- a label over cases, not people
- overlap in evidence, nothing about who
- clusters split; a name resists it
basics
~20 sA cluster label records only that a set of intrusions share observed evidence such as infrastructure or tooling. An actor name asserts who is behind them, a claim defender telemetry rarely supports. Clusters split and merge; names resist that.
solid answer
~50 sAn activity cluster is a bookkeeping label over cases, not a claim about people. It says: these intrusions share evidence I can point at, so I will track them together and reuse what I learn from one on the next. That is a claim I can defend from my own telemetry and, crucially, retract - clusters get split when the shared evidence turns out to be commodity, and merged when new overlap appears. An actor name is a different and much larger claim: that a persistent set of operators, usually with an implied sponsor and intent, conducted all of it. Almost nothing in an enterprise's logs supports that; it normally rests on reporting, law-enforcement action or intelligence a defender does not have. So most teams stay at activity level deliberately, and only the rare cluster with sustained, exclusive tradecraft is ever promoted.
go deeper
Be ready to say in one sentence what a cluster label claims - shared observed evidence - and what it does not claim: who the operators are. Knowing that clusters get split and merged is most of the answer.
Explain why the cheap claim is the useful one: clustering exists so that knowledge transfers between cases, and that benefit needs no identity claim at all. Expect to distinguish activity, actor and sponsor attribution.
Show that you record the evidence behind every merge so it can be unwound, and that you state overlaps with other vendors' names rather than equivalences. Interviewers listen for whether you have had to retract a linkage.
Own the policy question: what your organisation is willing to publish as a linkage claim, who signs it off, and how you keep an internal tracking label from becoming an external assertion your customers act on.
## Two different claims When a security team writes `CLUSTER-14` on a set of related intrusions, it is making a narrow, evidence-shaped statement: *these cases overlap in things I observed, so I am going to file them together*. The overlap might be a domain reused across two victims, a backdoor with the same embedded configuration, an unusual sequence of commands typed by hand, or a certificate that appears on both sets of infrastructure. When someone instead writes the name of a known group, the claim is far larger. It asserts that a durable set of human operators - typically with an implied sponsor, budget and mission - conducted all of it. Almost none of that is visible in enterprise telemetry. Logs show artefacts and behaviours: a process was created, a certificate was presented, bytes left the network. They do not show who was at the keyboard or who paid them. ## Why the cheaper claim is the useful one The practical value of clustering is not naming. It is transfer: if two cases are in the same cluster, the hunt you wrote for the first one is worth running for the second, and the artefacts you burned in one are worth blocking before the next. That value comes entirely from the evidential overlap, and none of it requires knowing who the operators are. The cluster label also carries a property a name does not: it is revisable. Clusters split when the thing they were built on turns out to be shared - a hosting provider used by thousands of tenants, a default library fingerprint, a foothold bought from someone who sold it twice. They merge when a new case brings overlap in something exclusive. A team that tracks activity expects to do this; a team that has published a group name finds every revision expensive and embarrassing. ## The naming conventions you will meet Most vendors keep an explicitly *uncategorised* namespace for exactly this reason - Mandiant's `UNC####` prefix is the best-known example - and graduate a cluster to a fuller designation only when the evidence carries it. Others use themed names (weather systems, animals, other schemes) applied at the group level. The important point for an interview is not the scheme but its semantics: **a vendor's name is that vendor's cluster, drawn from that vendor's visibility.** Two vendors watching different slices of the internet will draw slightly different boundaries around the same activity, so their sets rarely coincide exactly. ## Mapping between naming schemes When a peer says "our vendor's report on SLATE HYENA looks like your cluster", the safe statement is an *overlap* statement, not an equality: "our cluster shares these three named observables with that report; we do not assert they describe the same operators." Publishing an equivalence between two vendors' names is the single most common way a clustering error propagates, because the person who reads it downstream has no way to see which evidence carried the claim. ## Attribution, and its several meanings "Attribution" gets used for at least three separate claims, and they are not equally hard: - **Activity attribution** - these intrusions belong together. This is clustering, and it is what a defender can usually support. - **Actor attribution** - a specific persistent group conducted them. Needs evidence about operators, not just artefacts. - **Sponsor attribution** - a state or organisation directed them. Almost always a government or a large vendor's claim, resting on sources a defender does not hold. A candidate who collapses these into one is signalling they have never had to defend a claim to someone senior. ## What this changes in practice - Write down, with each merge, *what evidence* justified it. That record is what lets you unwind it later. - Keep the internal tracking label and any published linkage claim separate; the first is cheap to change, the second is not. - Never let the label become the argument. "It is CLUSTER-14, so it is targeted" is circular: the cluster is a hypothesis about the cases, not a fact about the world. - Be comfortable saying "we track this as activity and we do not attribute it". Withholding a claim you cannot support is a correct and defensible outcome, not a gap in the analysis.
- A peer says their vendor's report on a group they call SLATE HYENA describes the same activity as your cluster. What do you tell them?State the overlap, not identity: name the specific observables our cluster shares with that report, and say we do not assert the two describe the same operators. Different vendors cluster from different visibility, so their boundaries rarely match exactly. If a mapping is worth publishing, publish the evidence behind it and mark it as an overlap relationship, so anyone downstream can see what carried the claim.
- What would make you promote a cluster from a tracking label to a named group?Sustained, exclusive tradecraft across many cases - a non-public capability, distinctive operator habits, a coherent targeting pattern over time - plus evidence about the operators themselves, which usually comes from outside your telemetry: partner reporting, indictments, law-enforcement action. Many teams never promote anything and stay at activity level permanently, which is a legitimate position rather than an admission of failure.
- What does giving a cluster a memorable brand name cost you?Reification. A catchy name makes readers treat the cluster as a coherent organisation with intent, and it travels into press coverage and executive conversations detached from the evidence that created it. It also raises the price of being right later: splitting a numbered cluster is bookkeeping, while splitting a branded group is a public correction.
A cluster label is a case file with a shared elastic band round it. An actor name is a nameplate on a door - much harder to peel off when the files turn out to belong to two people.
saying these in an interview costs you the question
- Says a shared malware family proves the same operators
- Treats a vendor's group name as an authoritative identity
- Assumes attribution means naming a country
- Talks about the cluster as a fact rather than a revisable hypothesis