Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback on Threat Actor Naming Standard #54

Open
Johnnyd4251 opened this issue Jan 4, 2025 · 1 comment
Open

Feedback on Threat Actor Naming Standard #54

Johnnyd4251 opened this issue Jan 4, 2025 · 1 comment

Comments

@Johnnyd4251
Copy link

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

@adulau
Copy link
Member

adulau commented Jan 6, 2025

Thank you very much for the feedback.

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.

Thank you again for your feedback and proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants