In the Diamond Model, how do two filled vertices lead you to a third?
answer
- four core features, one event
- blank vertices are the normal state
- a known feature becomes a search key
- same key, second host, new victim
- what comes back is a hypothesis
basics
~20 sBy pivoting: a feature you already know is used as a search key to find features you do not. Knowing the capability and the infrastructure that served it, you can reach a victim nobody has looked at yet.
solid answer
~50 sThe Diamond Model's atomic unit is an event with four core features: adversary, capability, infrastructure, victim. In practice you almost never observe all four; you observe one or two and the rest are blank. Pivoting is the analytic move that fills a blank one: take a feature you do have, use it as a search key wherever that artefact appears, and see what else it touches. Concretely, a self-signed TLS certificate with a distinctive subject and public key served a loader from one staging host. That single artefact is a key: the same public key turns up presented by a second host, and that second host has spoken to a cloud control-plane endpoint belonging to an organisation nobody had considered. Two filled vertices reached a third. What you get back is a hypothesis attached to the graph, not a fact about it.
go deeper
Be ready to name the four core features and describe one concrete pivot end to end — this artefact, that search, this new vertex. Say out loud that most vertices start blank; interviewers listen for whether you know that is normal.
You are expected to explain why some artefacts pivot well and others do not: a public key implies a shared private key, a subject string implies nothing. Be able to walk a two-hop chain and state what each hop assumed.
Show that you know the reached vertex is a hypothesis with an owner, a date and a chance of being wrong. Talk about how leased cloud address space and shared tenancy break the assumption that an endpoint identifies an organisation.
Own the question of which artefacts are worth investing in as pivots at all. That is a bet on the adversary's economics: durable infrastructure is only durable while rebuilding it costs the operator more than it costs you to follow.
## The unit is an event, not an intrusion The Diamond Model of Intrusion Analysis describes one **event** as: an *adversary* deploys a *capability* over some *infrastructure* against a *victim*. Those four are the **core features**, drawn as the four points of a diamond. An intrusion is not one diamond — it is many events, each its own diamond, strung together in order. The first thing to internalise is that a real event almost never has all four features filled in. You see a payload but not who sent it. You see a host that served it but not what it hit. You see a machine that was hit but not what served it. Blank vertices are the normal state, and the model is built for that state rather than embarrassed by it. ## Pivoting is the move that fills a blank Pivoting is the technique of taking a feature you *do* know and using it as a search key to discover features you do not. It works because attacks leave shared artefacts: an operator who registers a domain, deploys a certificate, or reuses a key has created something that exists in more than one place and can be looked up. The edges of the diamond are where pivots happen: - **capability to infrastructure** — this payload resolves to, or was served from, that host - **infrastructure to victim** — that host has spoken to this endpoint - **victim to capability** — this organisation holds a sample nobody else had - **infrastructure to infrastructure** — two hosts share a certificate, a key, or a registration detail Chain two of those and you reach a vertex that was never observed at all. ## The worked case A loader is served over TLS from a staging host. The TLS certificate is self-signed, and it carries a distinctive subject string and a specific public key. That gives you two filled vertices: a **capability** (the loader) and an **infrastructure** (the host and, more usefully, the certificate's key). The key is the pivot. A public key is not a coincidence in the way a subject string is — anyone can copy the text `CN=updates.internal` into a certificate of their own, and researchers and unrelated operators do. The *same public key* means the same private key was deployed, so the two hosts were configured by the same hands or from the same build. So you search on that key and find a second staging host. That second host, at some recorded moment, exchanged traffic with a cloud control-plane endpoint owned by a different organisation entirely — one that has not been attacked, has no idea any of this exists, and appears nowhere else in the story. The **victim** vertex is now filled. You reached it from two vertices, without ever touching the third organisation. ## Why this matters for a nation-state operator The pivot only exists because the artefact survived. An operator with a revenue clock — one that has to monetise access before it gets burned — rotates infrastructure fast, and a certificate lives weeks. A crew with time and no revenue target reuses staging estate for months because rebuilding it costs operator hours it would rather spend elsewhere. Longevity is what makes an artefact a usable pivot at all, and it is a consequence of the adversary's economics rather than of your cleverness. ## What the pivot produced, and what it did not The reached vertex is a **hypothesis**. It says: this endpoint sits at the far end of an edge from infrastructure that the same operator built. It does not say the endpoint was compromised. It does not say the organisation was targeted. It does not say the endpoint even belongs to that organisation — cloud address space is leased and re-leased, tenancy is shared, and ownership records go stale. The common beginner error is to treat the diagram as a record of facts because it is drawn as a graph and graphs look authoritative. Every edge you drew by pivoting is a dated assertion someone can disprove, and the model has machinery for exactly that: each event carries meta-features — when it happened, which direction it ran, what result it produced, and how confident you are. ## Choosing a direction to pivot in The model does not tell you which way to go; it enumerates approaches. A **victim-centred** approach starts from the organisation you can see and works outward. A **capability-centred** approach starts from the payload. An **infrastructure-centred** approach starts from a host, a domain, or a key. Which one you use is decided by which vertex you can actually fill, not by preference. In the case above the infrastructure was the only durable thing on the board, so it was the infrastructure that got walked.
- The adversary vertex is usually blank. Why does that not stop you pivoting?Because pivots run along the technical edges — capability, infrastructure, victim — and none of them need the adversary filled. You can walk a certificate key to a second host and that host to an endpoint without ever forming a view on who is behind it. The model tolerates a permanently blank adversary vertex by design; treating it as a prerequisite is what stalls people.
- Why is a shared certificate subject string a much weaker pivot than a shared public key?A subject string is just text. Anyone can copy `CN=updates.internal` into a certificate they generate themselves, and unrelated operators reuse the same lazy defaults, so matching on it produces collisions with no common cause. A matching public key means the same private key was deployed on both hosts, which implies a shared build or shared hands. Same evidence class, very different strength.
- Does the Diamond Model say which vertex you should start from?No. It names the approaches — victim-centred, capability-centred, infrastructure-centred — and leaves the choice to you. In practice the starting vertex is whichever one you can actually fill, and the useful one is whichever artefact the operator reuses. If they burn infrastructure after every operation, an infrastructure-centred approach yields nothing and the capability is your only durable handle.
It is the way a phone number in one contact's record leads you to a second contact you never knew existed: the number is not the point, its reuse is.
saying these in an interview costs you the question
- Treats the diamond as a picture drawn after the fact, not an analytic tool
- Says a pivot proves the reached victim was compromised
- Believes all four vertices must be filled before the model is usable
- Matches on a self-signed certificate's subject string and calls it the same operator
- Confuses the diamond with an ordered sequence of attack stages