The threat actor construct needs some ability to represent pieces of information (breadcrumbs) left behind that indicate attribute to that particular threat actor. For example, an e-mail address, text snippet often found in source code, etc.
Some of this can be captured in a structured fashion now but:
a) it would be good to know which info is just info we happen to know and which info has been noticed to be good for attribution
b) it changes rapidly so tools may not be able to keep up with the structured fields
c) it isn't specific to any particular adversary TTP but more to how the adversary behaves in general, so the Indicator => TTP => Threat Actor relationship would be forced.
The threat actor construct needs some ability to represent pieces of information (breadcrumbs) left behind that indicate attribute to that particular threat actor. For example, an e-mail address, text snippet often found in source code, etc.
Some of this can be captured in a structured fashion now but: a) it would be good to know which info is just info we happen to know and which info has been noticed to be good for attribution b) it changes rapidly so tools may not be able to keep up with the structured fields c) it isn't specific to any particular adversary TTP but more to how the adversary behaves in general, so the Indicator => TTP => Threat Actor relationship would be forced.
This was suggested by a developer.