I85PREP
⌘ K
MITRE ATT&CK Fundamentals study materials
MITRE ATT&CK Fundamentals study resources

Layer Drift, Revoked Objects and a TAXII Feed That Overwrites Itself

MITRE ATT&CK Fundamentals · Put your knowledge to work in context.

All case studies

Layer Drift, Revoked Objects and a TAXII Feed That Overwrites Itself

Kestrel Financial's CTI team publishes six ATT&CK Navigator layers, one per intelligence source, all created against ATT&CK v13. In March the platform vendor upgraded the embedded ATT&CK data. Symptoms since: (1) 37 techniques in the oldest layer render greyed out, and the hover text names a different ID; (2) a script that merges the six layers by technique ID now produces 61 rows where 54 are expected, including pairs such as T1562 and T1562.001 counted separately; (3) the team's TAXII client, which polls the enterprise collection hourly and de-duplicates on the technique identifier, has begun replacing newer objects with older ones; (4) the analyst working the Android workstream tried to add mobile findings to the enterprise layer and Navigator refused the import. The team must ship a threat profile to the fraud-detection engineering group in ten days, and the engineering lead has already circulated a screenshot of the greyed-out layer asking whether coverage was lost.

1. Explain why the 37 techniques greyed out after the upgrade, and what the team should do about them before circulating the profile.

Read the worked answer

A Navigator layer is not self-contained. It stores technique IDs and a versions block naming the ATT&CK version the layer was built against, plus a domain (enterprise-attack, mobile-attack or ics-attack). When the embedded data changes, the layer is checked against the new technique list. An ID that no longer exists in that version - because it was deprecated, split into sub-techniques, or renamed - cannot be resolved, so the entry renders disabled or grey rather than scored.

So no, coverage was not lost; the layer is pointing at identifiers that have moved. The handling is:

  1. Read the STIX object for each greyed ID and check for revoked: true and any revoked-by relationship. That relationship names the replacement, and where a technique was split it may name several.
  2. Remap each entry by hand to the correct replacement, guided by the original comment text - a deprecated scripting technique may map to one interpreter sub-technique or the parent, depending on what the source actually described.
  3. Update the layer's versions.attack value to the version now in use, so the file and the platform agree.
  4. Re-export and diff before publishing, and tell the engineering lead plainly: 37 identifiers were remapped, not deleted.

Going forward, version-pin the layers deliberately and re-validate on every upgrade rather than letting the platform silently drift.

2. The TAXII client is overwriting newer objects with older ones. What is wrong with the de-duplication logic and what should it be?

Read the worked answer

De-duplicating on the ATT&CK technique identifier is the bug. That identifier is an external reference - it lives inside the object, it is not the object's identity, and it can be reused across versions or attached to several objects (a technique and its detection-related data, for example). Two different STIX objects can share a technique ID.

The stable identity is the STIX id (for example an attack-pattern UUID), which persists across modifications of the same object. Correct practice:

  • Key on id. Treat each object version as a revision of that identity.
  • Resolve conflicts with modified. When two versions of the same id arrive, keep the one with the later modified timestamp - that is what stops the hourly poll from resurrecting an older record.
  • Filter revoked: true. Do not surface revoked objects as live coverage; keep them for history and follow revoked-by to the replacement.
  • Do not assume one collection holds everything. TAXII collections are scoped per domain - the enterprise collection will never contain the mobile objects the Android analyst needs; that requires the mobile collection.

A ten-minute fix to the key field would have prevented the last three weeks of contradictions, and it should be regression-tested before the profile ships.

3. The merge script emits 61 rows where 54 are expected, and the mobile import failed. Address both, and say how the merged output should be scored.

Read the worked answer

The 61 versus 54 rows is a parent/child aggregation error. T1562 and T1562.001 are the same branch: the child is a refinement of the parent, so a row count that includes both counts one behaviour twice. Consolidate so that each branch appears once - roll children up into the parent for the dashboard, or keep the most specific level and drop the parent - and state the choice in the layer's legend text so nobody re-derives a different rule.

The mobile import failed because a Navigator layer belongs to exactly one matrix. The Enterprise and Mobile matrices have different technique sets, different tactic columns and different identifiers; there is no valid single layer spanning both. Options are separate layers with a shared legend, or a side-by-side presentation with an explicit mapping table for findings that exist on both sides.

Scoring also needs documenting, because the six source layers each carry scores for their own reasons:

  • Pick an aggregation rule - maximum score wins is the usual choice, because one source reporting high confidence should not be diluted by five reporting none - and write it down.
  • Do not sum scores across sources; the result is uninterpretable and inflates priority for techniques that appear in many weak reports.
  • Preserve the per-source comment so an analyst can see why a cell is hot.

Ship the merged profile with the aggregation rule stated in one sentence, and the engineering team can use it without guessing.