Can ATT&CK technique T1550.001 be closed out by patching, and if not, why not?
answer
- behaviour class, not a defect
- no product, no version, no fix field
- the grant is working as designed
- control class, not a patch
- techniques never go to zero
basics
~20 sNo. An ATT&CK T-number names a class of adversary behaviour, not a defect in a product. T1550.001 - using an application's access token - involves nothing broken, so only a control over grants and scopes changes exposure.
solid answer
~50 sA technique identifier and a flaw identifier are different kinds of object. A CVE identifier names one defect in one product and has a fixed version; an ATT&CK technique names something an adversary *does*, and carries no affected product, no version range, no fix and no vendor. `T1550.001` Use Alternate Authentication Material: Application Access Token describes using an application's issued token instead of a user's credential - for example an app in a SaaS tenant whose consent grant carries a mail-read scope, reading mailboxes exactly as the grant permits. Nothing there is broken, so nothing can be patched. What reduces exposure is a control class that removes what the behaviour depends on: who is allowed to consent to applications, how broadly scopes may be granted, how long a grant lives, and whether an existing grant can be withdrawn quickly. "We are fully patched" answers a question about flaws, not about behaviour, and no patch level ever retires a T-number.
go deeper
Be able to say that an ATT&CK T-number describes something an adversary does, while a CVE identifier names a defect in a specific product, and that only the second one has a fix.
Explain why T1550.001 in particular cannot be patched: every component in the path is behaving as designed, so exposure changes only when a control removes the broadly-scoped, long-lived grant it depends on.
Show the near-miss and why it still holds - T1190 names exploitation as a behaviour, so patching one product removes an opportunity but never retires the technique or identifies the flaw.
Refuse the workflow transplant. Techniques given owners, due dates and fix versions look like progress and produce a number that can never legitimately reach zero; frame exposure as cost imposed on the adversary instead.
## Two catalogues, two kinds of claim The single most common category error in this vocabulary is treating an ATT&CK technique identifier as though it were a vulnerability identifier. They answer different questions. A flaw identifier answers: *what is defective, in which product, in which versions, and what fixes it?* It is anchored to a piece of software, and it has a life cycle that ends - the fix ships, you install it, and the identifier stops being about you. An ATT&CK technique answers: *what is the adversary doing, and to what end?* The object holds a name, a description, the tactics it can serve, the platforms it applies to, and a set of documented ways it has been carried out. It holds **no product, no version range, no fixed-in field and no vendor**, because there is nothing for those fields to refer to. A technique has no life cycle that ends with a patch, and no patch level makes it inapplicable. ## Why T1550.001 is the sharpest illustration `T1550.001` is using an application access token as the authentication material - presenting a token that was legitimately issued to an application, rather than a user's password or ticket. Picture the concrete case: a SaaS tenant where an application holds a consent grant carrying a mail-read scope, and it reads mailboxes with it. That grant was created by an administrator through a supported flow. The identity provider issues tokens for it exactly as specified. The scope is honoured exactly as documented. **Every component in the path is working correctly.** There is no memory-safety error, no missing bounds check, no unauthenticated endpoint. There is nothing to fix, because nothing is broken. So asking "are we patched against T1550.001?" is not a hard question with an unpleasant answer; it is a question that does not parse. The behaviour depends on the *existence* of a long-lived, broadly-scoped grant and on who is permitted to create one. Those are the things a control class can take away: | What the behaviour depends on | The control class that removes it | | --- | --- | | Anyone may consent an app into the tenant | Restrict who may grant consent; require review for privileged scopes | | Scopes are granted broadly, once, forever | Least-scope grants; bounded lifetime; periodic re-approval | | A granted app keeps working after a user's password changes | Ability to withdraw a grant independently of user credentials | | Nobody knows which apps hold which scopes | An inventory of grants and their scopes as a first-class asset | Notice that none of those is a patch, and that the last row is not a technical fix at all. ## The near-miss that proves the rule The closest ATT&CK comes to naming a flaw is a technique like `T1190` Exploit Public-Facing Application: exploitation *as a behaviour*. Even there the identifier names no product, no defect and no fixed version - it names the act of exploiting whatever internet-facing thing you have. Patching a specific product removes one opportunity to perform `T1190`; it does not retire the technique, and the technique remains an accurate description of what an adversary would be doing the next time. The mapping runs one way and it is lossy: you can say which behaviour exploiting a given flaw would constitute, but you can never recover the flaw from the T-number, because thousands of unrelated flaws share it. ## Where the error shows up in practice - A list of technique identifiers treated as things to be "remediated" and eventually driven to zero. Techniques do not go to zero; adversary options are not a backlog. - A patch level offered as evidence that a technique does not apply. It is evidence about defects, and the two sets barely intersect. - A technique identifier given an owner, a due date and a fix version, borrowing a workflow built for flaws and applying it to a vocabulary that has no fix field. ## The answer that lands Say plainly that a T-number names behaviour and never a flaw; that `T1550.001` in particular describes a mechanism working as designed, so patching is not merely insufficient but irrelevant; and that what changes your exposure is a control that removes the precondition the behaviour cannot substitute - here, the broadly-scoped, long-lived application grant. Then note the asymmetry that keeps the two catalogues straight: a flaw can be fixed and its identifier retired from your estate, while a technique can only be made more expensive.
- If a patch does not close a technique, what does?Nothing closes it - the technique stays in the catalogue whatever you do. You remove or price up what it depends on. For T1550.001 that means constraining who may consent an application into the tenant, keeping scopes narrow and grants short-lived, and being able to withdraw a grant without touching user credentials.
- Can you map a CVE to an ATT&CK technique at all?You can state which behaviour exploiting that flaw would constitute - typically T1190 for an internet-facing service. The mapping is one-way and lossy: the technique names no product, no version and no fix, and the same T-number covers thousands of unrelated flaws, so you can never run it backwards.
- A managed provider's own app reads mailboxes under the same T1550.001. Does that make the mapping wrong?No. A technique names behaviour, not intent or authorisation, so an engineer's entirely ordinary delegated grant and an adversary's use of one are the same technique. That is exactly why a T-number is vocabulary for describing an action and never a verdict on it.
saying these in an interview costs you the question
- Treats an ATT&CK technique like a vulnerability to remediate
- Offers patch level as evidence a technique does not apply
- Assigns a fix version and due date to a T-number
- Believes techniques can be driven to zero
- Thinks a T-number can be resolved back to a specific flaw