You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--Scope creep between threat actor name creation and adoption.
--Ambiguity in suggestions for vendors and non-vendors. (note: I believe you will be unlikely to garner traction amongst vendor names, but you can influence how non-vendor orgs adhere to threat actor names and conventions)
--For non-vendors there is ambiguity in storage standards for data tagged to actor names and how it should be used in written reports.
--This is overly prescriptive for a best practice/guideline document. Telling someone they will do things is a quick way to get them to ignore the guidance. Instead, I softened the language in several places from SHALL and MUST to SHOULD and MAY. I've written far too many policy docs for companies before, so I strongly suggest using the looser language.
--Specifying that threat actors names should be written in a certain way (using a dash) or use only one word (which I have no idea what you mean by a non-dictionary word), is objectively wrong. Instead, what you want is organizations to adopt a flexible naming convention that properly groups together like types of intrusion activity clusters and can evolve over time. I think you can point to how MISP uses a dash or single word as an example of how this can be applied, if you want to drive home the point. I do suggest looking at the documentation the Vertex Project Synapse has for their "tag trees" on this though.
--Lastly, lack of sources. With all do respect, MISP is far from the only player in this space, so to help gain industry traction it is important to include previous standards on how vendors name threat actor groups, cases where borrowing a name has become an issue (see history of mis-attribution citation), and other related resources. I have provided several for you to consider including.
It seems there is some confusion about the scope of the document, which your feedback has highlighted. The document focuses solely on the identification and reference of threat actor naming. Actual attribution of threat actors, among other related topics, is clearly out of scope.
The use of identifiers is a significant issue in many free-text documents, which is why we strongly recommend using names that are easily extractable and not commonly found in dictionaries. This avoids common challenges in natural language processing and automatic extraction. But indeed, we can make it easier by just recommending the reference to other names already chosen by the vendor(s).
The document provides prescriptive guidance for our tooling and development efforts within the MISP community. However, we do not mandate anyone to use or implement the standard. We will soften language, that's also a very good point.
I'll do a major update in the document to clearly describe the scope and I'll send a review request afterward.
General comments based on my read of the RFC and my attempts to rectify those with inline re-writes located here (https://docs.google.com/document/d/18l7TIOihRsxh2Y8yQWVfwIG38gEF5n2VWBD644E5tFQ/edit?usp=sharing) and attached:
--Scope creep between threat actor name creation and adoption.
--Ambiguity in suggestions for vendors and non-vendors. (note: I believe you will be unlikely to garner traction amongst vendor names, but you can influence how non-vendor orgs adhere to threat actor names and conventions)
--For non-vendors there is ambiguity in storage standards for data tagged to actor names and how it should be used in written reports.
--This is overly prescriptive for a best practice/guideline document. Telling someone they will do things is a quick way to get them to ignore the guidance. Instead, I softened the language in several places from SHALL and MUST to SHOULD and MAY. I've written far too many policy docs for companies before, so I strongly suggest using the looser language.
--Specifying that threat actors names should be written in a certain way (using a dash) or use only one word (which I have no idea what you mean by a non-dictionary word), is objectively wrong. Instead, what you want is organizations to adopt a flexible naming convention that properly groups together like types of intrusion activity clusters and can evolve over time. I think you can point to how MISP uses a dash or single word as an example of how this can be applied, if you want to drive home the point. I do suggest looking at the documentation the Vertex Project Synapse has for their "tag trees" on this though.
--Lastly, lack of sources. With all do respect, MISP is far from the only player in this space, so to help gain industry traction it is important to include previous standards on how vendors name threat actor groups, cases where borrowing a name has become an issue (see history of mis-attribution citation), and other related resources. I have provided several for you to consider including.
Feel free to reach out for additional clarification on any of the points noted above via DMs on LinkedIn (https://www.linkedin.com/in/john-doyle-a02bab10/)
Doyle_Threat_Actor_Naming_RFC_Suggestions.docx
The text was updated successfully, but these errors were encountered: