Does delivery mean the attacker succeeded?

No. It identifies one part of the modeled sequence, not the final outcome.

Must every stage be visible in logs?

No. Available evidence may cover only part of an intrusion.

Is observing four stages a measure of percentage completion?

No. Stage counts do not quantify progress, damage or defensive effectiveness in that way.

AI Glossary / Data governance and quality / Advanced

Cyber kill chain

Definition

The Cyber Kill Chain is a framework associated with Lockheed Martin for analyzing an intrusion as a sequence of stages and identifying opportunities to interrupt it. Its seven stages are reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. It gives defenders a structure for connecting evidence and controls. It is an analytical model, not proof that every incident will present seven separately observable events.

What it means

An isolated alert may reveal only part of what an adversary is attempting. A delivery event, for example, does not establish that exploitation or the intended objective succeeded. The framework encourages teams to ask what came before, what might follow and where intervention is possible. For an original AI publishing business, this can help explain an incident involving an editor's workstation without reducing it to a single suspicious message. The analysis must still distinguish observed facts from hypotheses and avoid filling missing stages with invented evidence.

How it works

The original paper by Hutchins, Cloppert and Amin maps intrusion phases to defensive action and relates individual attempts to broader campaigns. Reconnaissance concerns preparation and targeting; weaponization prepares the attack material; delivery brings it to the target; exploitation triggers the compromise; installation establishes the relevant presence; command and control supports remote interaction; actions on objectives pursue the intended outcome. Analysts use available evidence to reason about these phases and defensive opportunities. In an original review, a stage assignment should include the supporting observation and uncertainty. A model label does not make an unverified event a confirmed occurrence.

Three practical examples

A security team distinguishes delivery of a suspicious attachment from evidence that it actually executed on a workstation.
An AI publishing organization reviews whether its monitoring would reveal an unexpected outbound control connection, alongside controls intended to prevent an earlier compromise.
A training exercise maps a fictional intrusion narrative to stages and identifies which statements are observed, inferred or still unknown.

Think of it this way

Imagine reconstructing a failed burglary attempt from several clues: preparation outside, an attempted entry and an alarm inside. The clues help explain the sequence, but the absence of a camera image is not proof that nothing happened at that point. Likewise, one alarm does not establish that property was removed. The analogy illustrates reasoning about stages and evidence; the Cyber Kill Chain itself concerns cyber intrusions and their defensive analysis.

Worked example

Consider an original fictional incident review with four observations. At 09:00, a suspicious message reaches an editor's mailbox. At 09:04, endpoint records show execution associated with its attachment. At 09:06, a new unauthorized program is recorded on the workstation. At 09:08, monitoring identifies an outbound connection associated with that program. Analysts provisionally map these observations to delivery, exploitation, installation and command and control, subject to verification of the relationships. They have observations associated with four of the framework's seven stages. That is a coverage description, not a claim that the attack is 4/7 complete or that detection effectiveness is 57.1%. Reconnaissance and weaponization are not directly observed in the available records. There is also no established evidence of the adversary's final objective being achieved. The team investigates the connection and affected system rather than declaring either success or complete safety from the stage count alone. The example contains no real organization or incident.

Illustrative case study

In a fictional AI glossary company, an initial incident summary says an attack was stopped because a suspicious message was identified. A more careful timeline shows that identification happened after the workstation activity in the worked example. The team revises the report to separate the time of delivery, the time of observation and the time of response. It investigates the later events and records what remains unknown about the outcome. The scenario illustrates using the framework to improve questions and reporting. It does not imply that a particular alert proves data theft or that naming the stages resolves the incident.

Common misconceptions and mistakes

Seven stages do not create a seven-point security score. A blocked attempt at one stage also does not establish that every related attempt was blocked. Another mistake is confusing lack of visibility with absence of activity. Analysts should not force an event into a stage merely to complete a diagram, or assume that a proposed sequence is proven because it looks plausible. The framework also does not replace detailed technical investigation. Its value comes from organizing evidence and defensive decisions, while the actual incident may require additional descriptions and models.

Business use

For an AI website project, use the framework to connect technical observations with decisions managers can understand. In the fictional editor-workstation incident, distinguish what arrived, what ran, what was observed later and which outcomes remain unconfirmed. Ask which controls could prevent, reveal or interrupt the relevant activity, and what evidence demonstrates their behavior. Keep incident response ownership and unresolved questions visible. This supports clearer prioritization and reporting than counting alerts or filling seven boxes. It does not establish an organization's readiness without testing the controls and processes on which the analysis depends.

Check your understanding

How many observations appear in the toy timeline?

Answer: Four.

Which two preparation stages are not directly observed?

Answer: Reconnaissance and weaponization.

Is achievement of the final objective established?

Answer: No.

Why should the report distinguish event time from detection time?

Answer: Discovering evidence later does not mean the activity was prevented earlier.

What should accompany a proposed stage mapping?

Answer: The supporting evidence, its interpretation and any relevant uncertainty.

Related terms

Incident response
Defense in depth (computing)
Intrusion analysis
threat intelligence
indicators of compromise
command and control
defense in depth

Learn next

Create a fictional incident timeline with separate columns for event time, observation time, supporting evidence and uncertainty. Map relevant events to the framework, leaving unsupported stages explicitly unknown. Identify one defensive question for each observed event without treating the completed diagram as proof of the incident's outcome.

Sources

Eric M. Hutchins, Michael J. Cloppert and Rohan M. Amin, Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains, primary paper, mirrored copy: https://dl.icdst.org/pdfs/files3/c8dcc718c171cfa32b7410b3850c9ee9.pdf The four-event timeline, burglary analogy and AI glossary incident are original educational illustrations. The original Lockheed Martin website returned an access error; the authored paper was read through the cited mirror. The entry does not adopt promotional effectiveness claims as independent evidence.

Previous: Cuzick - Edwards test Next: Cybersecurity