In ATT&CK, how do you map one intrusion that crosses an Enterprise host action and an ICS-only plant action?
answer
- two mappings, not one chain
- no edge links T1### to T0###
- the timeline is yours to assert
- collapsing to Enterprise erases the plant step
- join on identifiers, never on names
basics
~20 sYou produce two mappings in two coordinate systems and join them yourself. ATT&CK has no edge linking a T1### technique to a T0### one, so the ordering, the causal link and the single narrative are yours to write, not the catalogue's.
solid answer
~50 sDo not pick a matrix. Map the host-side actions against Enterprise and the plant-side actions against ICS, then join them with your own timeline, because nothing in either catalogue records that one preceded or enabled the other. The wrong move is collapsing everything into Enterprise on the grounds that initial access was IT-side: Enterprise has no cell for sending a protocol-legal control command that a device simply obeys, so that step disappears from the write-up entirely and the episode reads as an ordinary host compromise. Two further traps: the counts do not add, because the denominators are different catalogues; and several technique names recur across both matrices as distinct objects, so a dedupe on names merges two different claims. The join being manual is the point — say so explicitly rather than implying ATT&CK supplied it.
code
text · 12 linesATT&CK Enterprise (T1###)
Initial Access T1190 Exploit Public-Facing Application
Execution T1059 Command and Scripting Interpreter
...
ATT&CK for ICS (T0###)
T0855 Unauthorized Command Message
...
# No parent/child or ordering relationship exists between T1059 and T0855.
# The catalogue names the nodes; the timeline joining them is yours.
# Do not sum across the two lists - different catalogues, no shared denominator.go deeper
Know that an intrusion touching both office hosts and plant devices produces two separate ATT&CK mappings, because ICS techniques are not part of the Enterprise matrix.
Explain that no relationship object links a T1### technique to a T0### one, so ordering and causation between the halves are asserted by you, not read off the catalogue.
Demonstrate the judgment: refuse the collapse into Enterprise, name what would be erased by it, and keep the two mappings joined by an explicit timeline with stated confidence.
Own why it matters beyond the write-up — the two halves point at different control classes with different owners and budgets, and a collapsed mapping quietly leaves one of them unassigned.
## The episode Take a concrete one. A flat office segment carries IP cameras, a print server and two building-automation controllers on the same broadcast domain. A commodity criminal — unauthenticated, no account anywhere, working entirely from reachability — fires one public exploit at every reachable instance of an internet-exposed service and sorts the results afterwards. One lands. From that host, the operator reaches the building-automation controllers on the shared segment and sends them a control command over a protocol whose specification contains no authentication at all. The controllers obey, because obeying is what they are specified to do. Now write that up in ATT&CK. ## Two mappings, one hand-built join The host-side half is ordinary Enterprise material: exploitation of the exposed service, then command execution on the host. The plant-side half is not Enterprise material at all. Sending a well-formed command that the device accepts is not execution of attacker code, not exploitation, not lateral movement to an account. It lives in the ICS matrix, in the `T0###` space, and it has no Enterprise parent. So the output is two mappings, and the join between them is yours: - ATT&CK has **no relationship object** that says "this Enterprise technique preceded that ICS technique", or enabled it, or is the IT stage of it. - The two matrices have **different tactic columns**, so you cannot lay them side by side as one row of stages. - The ordering and the causal claim come from **your timeline**, built from what you reconstructed, and they carry your confidence, not MITRE's. Stating that explicitly is the mark of a good answer. Plenty of write-ups present a cross-domain chain as though ATT&CK supplied the chain; it supplied the vocabulary for the nodes and none of the edges. ## The wrong answer, and why it is so tempting The wrong answer is: initial access was IT-side, the whole episode is therefore an Enterprise episode, map it all to Enterprise. It is tempting because it produces one clean chain in one matrix, and because the entry point genuinely was Enterprise. What it costs you is the only step that mattered. The Enterprise matrix has no cell for a physical process being driven to a state nobody chose, so the plant-side action is either dropped or filed under a generic Impact entry that says nothing about a controller obeying an unauthenticated command. The write-up then reads as a routine host compromise — which is exactly the reading that leaves the shared broadcast domain, and the controllers on it, unowned by anyone afterwards. ## Three traps in the join **Counts do not add.** "Eleven techniques observed" across two matrices has no denominator. Report the Enterprise mapping and the ICS mapping separately, each against its named matrix. **Names recur; objects do not.** Several technique names appear in both catalogues as distinct objects with distinct identifiers and distinct asset scopes. Joining or deduplicating on names silently merges two different claims about two different asset classes. Join on identifiers, and keep both. **Nothing nests.** There is no parent-child edge across matrices in either direction, so you cannot roll the ICS half up into an Enterprise summary or present the Enterprise half as the parent of the ICS half. ## What the mapping is for The reason to keep both halves is that they point at different control classes with different owners. The Enterprise half points at an exposed service and a patch cycle. The ICS half points at something a patch cannot reach: the control protocol has no authentication in its specification, so there is nothing to enable or configure, and the vendor is not going to ship it into a controller that is already installed. The only class of control left is one that removes reachability between the office segment and the controllers — which is a different budget, a different owner and, very often, a different contract. Collapse the episode into Enterprise and that second conclusion never gets written down. That is the practical reason the two coordinate systems are worth the extra work of joining them by hand.
- Why not just file the plant-side step under the Enterprise Impact column?Because Impact in Enterprise describes availability and integrity of data and services, not a physical process driven to a setpoint nobody chose. Filing it there keeps the episode in one matrix at the cost of naming the wrong thing: the entry would not say that a controller accepted a protocol-legal command from an unauthenticated peer, which is the fact that decides what control class applies and who pays for it.
- What confidence attaches to the ordering between the Enterprise and ICS halves?Yours alone. Neither matrix records sequence or causation between techniques, and there is no cross-matrix relationship object at all. The claim that the host action enabled the plant action comes from your reconstruction of the episode, and it should be stated with the same hedging as any other reconstruction rather than inheriting the catalogue's authority.
- A colleague deduplicates the two mappings and reports a single technique list. What breaks?Two things. Same-named techniques in Enterprise and ICS are distinct objects covering different asset classes, so merging them collapses two claims into one. And the resulting count has no denominator, because the techniques came from two catalogues of different sizes and different tactic columns. The list looks tidier and asserts less than the two separate ones did.
saying these in an interview costs you the question
- Maps the whole episode to Enterprise because entry was IT-side
- Presents the cross-domain chain as if ATT&CK supplied the links
- Reports one blended technique count across both matrices
- Treats an ICS technique as the OT variant of an Enterprise one
- Deduplicates the two mappings on technique names