Migrating from ATT&CK Data Sources to Data Components

The taxonomy changed because source names were too coarse

Older ATT&CK material often described detection through broad Data Sources such as Process, Network Traffic, or User Account. Those labels pointed toward useful systems, but they could hide the exact information an analytic needed. A process source might expose creation, metadata, access, or termination. Possessing some process logs did not mean possessing all of those observations.

A Data Component describes a security-relevant type of information about an object or activity. The emphasis moves from “which product or source exists?” toward “which fact about the behavior must be observable?” This makes the evidential requirement more precise without making it local.

In the ATT&CK v19 defensive model, Detection Strategies and Analytics use Data Components to express the kinds of evidence relevant to adversary behavior. Your environment still has to decide which producers can supply that evidence, how their fields mean it, and whether the path works.

Translate by meaning rather than by label

Suppose an older mapping says Process monitoring. Do not replace it with the first component whose name contains process. Read the analytic claim. If it depends on a parent creating a child, the required information concerns process creation and ancestry. If it depends on code loaded into an existing process, process creation alone is insufficient.

Write the observation in plain language before selecting the component: “the operating system or sensor records which authenticated process created another process, with stable identifiers and event time.” Then compare that statement with the Data Component definition. This prevents a familiar name from carrying assumptions the component never promised.

One old source can map to several components, and several sources can contribute to one component. Migration is therefore semantic review, not search and replace. Preserve the old mapping and the reason for the new one so reviewers can see whether the detection requirement changed or only its ATT&CK representation.

Connect the component to an observation contract

After the ATT&CK mapping, identify the local producer and observation point. State which operation creates the record, which actors and targets it distinguishes, which timestamps it carries, and which configurations control availability. A component about account modification may be supported differently by an identity provider, an operating system, and a SaaS application.

Then identify transformation. A parser may map several provider operations into one normalized action. That can help shared analytics while erasing whether a role assignment was eligible, active, permanent, or delegated. Retain source meaning and mapping versions wherever the distinction affects the claim.

Finally, describe health. Which tenant, host population, or service can disappear without the aggregate event count looking unusual? Which required fields can become empty? A local telemetry contract turns the taxonomic information need into an operable dependency. The Data Component remains the organizing concept; the contract explains whether you can currently rely on it.

Validate observation separately from analytic logic

A stored event can show that the analytic handles a component-shaped record. It does not show that current systems emit that record for the intended behavior. Conversely, observing a record does not show that entity joins, windows, or alert delivery work.

Test the layers separately. Confirm that representative behavior produces the expected source record. Confirm that collection and normalization preserve the fields and meaning. Confirm that the analytic evaluates intended and ordinary alternatives correctly. Confirm that the consumer receives enough source context to investigate. Record the platform, version, population, and variation exercised.

If one layer cannot be tested safely, state that limitation. The mapping can remain relevant while local confidence is partial or unknown. This is more accurate than treating a component association as proof that the behavior is covered.

Use migration to expose assumptions, not merely update metadata

A good migration produces more than current ATT&CK labels. It reveals detections whose titles promise evidence the sensor never supplied, identifies shared telemetry dependencies, and shows where normalization has collapsed important distinctions. These findings may change requirements, tests, or coverage states.

Keep three statements separate. “ATT&CK associates this information with the behavior” is a framework fact. “This producer and mapping appear capable of supplying it” is a local assessment. “Representative tests reached the consumer under recorded conditions” is validation evidence. Combining them into one covered flag discards the value of the review.

When ATT&CK evolves again, the preserved observation statement remains useful. You can compare its meaning with the new model rather than reconstructing intent from an old label. That is the real benefit of migration: a clearer chain from adversary behavior to information need to local evidence and decision.