Network Working Group A. Dulaunoy Internet-Draft CIRCL Intended status: Informational P. Bourmeau Expires: 7 February 2027 Cubessa A. Iklody. Iklody CIRCL 6 August 2026 Recommendations on Naming Threat Actors draft-00 Abstract This document provides advice on the naming of threat actors (also known as malicious actors). The objective is to provide practical advice for organizations such as security vendors or organizations attributing incidents to a group of threat actors. It also discusses the implications of naming a threat actor for intelligence analysts and threat intelligence platforms such as MISP [MISP-P]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Dulaunoy, et al. Expires 7 February 2027 [Page 1] Internet-Draft Recommendations on Naming Threat Actors August 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Reusing Threat Actor Names . . . . . . . . . . . . . . . 3 2.2. Threat Actor Types . . . . . . . . . . . . . . . . . . . 3 2.3. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Additional unique identifier . . . . . . . . . . . . . . 4 2.5. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 2.7. Avoid Confusing Actor Names with Malware Names . . . . . 4 2.8. Directory . . . . . . . . . . . . . . . . . . . . . . . . 5 3. MISP Galaxy Threat Actor Naming . . . . . . . . . . . . . . . 5 3.1. Recording Vendor Name Attribution . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In threat intelligence, threat actor names are often assigned without specific or consistent guidelines. This leads to several issues, such as: * A proliferation of threat actor names, generating overlaps or multiple names for the same or very similar threat actors (e.g., some threat actors have more than 10 known synonyms). * Ambiguity in the words used to name threat actors across different contexts (e.g., the use of common or generic words). * A lack of clearly defined naming conventions to describe the same threat actor (e.g., is the threat actor name case-sensitive? Should words be separated by a dash or a space?). * Confusion between the techniques or tools used by a threat actor and the threat actor’s name itself (e.g., naming a threat actor after a specific malware family). * A lack of transparency regarding the source and rationale used by vendors when assigning threat actor names (e.g., was the name derived from a specific campaign, a codename for a country, or a particular set of targets?). Dulaunoy, et al. Expires 7 February 2027 [Page 2] Internet-Draft Recommendations on Naming Threat Actors August 2026 * The absence of an open, mirrored reference “registry” accessible to all, where new threat actor names can be registered and existing ones can be consulted. Such a registry could also include time-based information and serve as a practical reference tool. This document proposes a set of recommendations and guidelines for naming threat actors. The objective is not to provide a silver bullet that solves all of the issues mentioned above, but rather to suggest approaches that reduce the burden on analysts when searching for and cross-correlating threat intelligence. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Recommendations The recommendations below specify a minimal set of guidelines to be applied when assigning a new name to a threat actor. 2.1. Reusing Threat Actor Names Before creating a new threat actor name, you SHOULD review existing threat actor names in reference databases, such as the Threat Actor MISP Galaxy [MISP-G]. The proliferation of threat actor names is a significant challenge in day-to-day analyst work. If the threat actor you have identified matches an existing entry, you SHOULD reuse the existing threat actor name. If no matching threat actor name exists, you SHALL create a new one, following the best practices defined in this document. Due to the volatile nature of threat correlation, threat actor profiles may be merged or split over time based on new information or further analysis. Analysts defining threat actors SHOULD use their best judgment to consolidate threat actor profiles whenever possible and retain previously defined names as aliases within the merged object, along with any previously established relationships. 2.2. Threat Actor Types The boundaries between threat actors, campaigns, and intrusion sets are frequently blurred, which can lead to the reclassification of the underlying concept. Such reclassification SHOULD NOT affect the existing naming convention. The previously assigned name SHOULD be retained in order to avoid losing correlations with historical data. Dulaunoy, et al. Expires 7 February 2027 [Page 3] Internet-Draft Recommendations on Naming Threat Actors August 2026 2.3. Uniqueness When choosing a threat actor name, uniqueness is a critical requirement. The threat actor name MUST be unique and not already in use in other contexts. The name SHOULD be selected with rarity in mind; common words are best avoided to facilitate searching and automated processing of information. If the use of common words is unavoidable, the threat actor name SHOULD consist of a combination of multiple words to increase uniqueness. 2.4. Additional unique identifier Threat actor definitions SHOULD include a unique identifier expressed as a UUID. When creating threat actor information, a prior check for an existing matching threat actor definition SHOULD be performed, and the UUID of the matching threat actor SHOULD be reused when a match is inferred. The inclusion of a UUID does not restrict the ability to retain vendor-specific threat actor naming conventions and SHOULD be treated as a separately expressed attribute of the threat actor. 2.5. Format The threat actor name SHOULD ideally consist of a single word. If the name is composed of multiple words or includes additional identifiers such as decimal values or counters, these elements SHOULD be combined into a single word without whitespace to facilitate searching. Single-word names are preferred to improve the efficiency of keyword searches by analysts in public sources. 2.6. Encoding The threat actor name MUST be expressed using 7-bit ASCII characters. Assigning localized or non-ASCII names to threat actors MAY introduce ambiguity due to the existence of multiple localized versions of the same name. 2.7. Avoid Confusing Actor Names with Malware Names The threat actor name MUST NOT be derived from the tools, techniques, or patterns used by the threat actor. A well-known example in the threat intelligence community is _Turla_, which can refer both to a threat actor and to malware used by that group or by other groups, leading to ambiguity. Dulaunoy, et al. Expires 7 February 2027 [Page 4] Internet-Draft Recommendations on Naming Threat Actors August 2026 2.8. Directory A reference registry of threat actors is RECOMMENDED to ensure consistency of naming across different parties, such as the Threat Actor MISP Galaxy [MISP-G]. 3. MISP Galaxy Threat Actor Naming The MISP Galaxy threat-actor cluster acts as an open directory rather than as a new naming authority. It consolidates threat actor definitions and the names published by security vendors while preserving the origin of each name. Before adding a cluster, contributors SHOULD search the threat-actor galaxy and its referenced producer clusters for an existing definition. A matching definition SHOULD reuse the existing UUID. If the available information supports a merge or split, contributors SHOULD preserve the earlier UUIDs, names, aliases, references, and relationships so that existing correlations remain usable. The canonical value of a threat-actor cluster SHOULD follow the naming recommendations in this document: it ought to be unique, searchable, composed of 7-bit ASCII characters, and distinct from malware, tools, techniques, and campaigns. Other names for the actor SHOULD be retained as synonyms rather than being silently replaced. References supporting the definition and its names SHOULD be included, and uncertain equivalences SHOULD NOT be represented as established aliases merely because two actors share tooling, infrastructure, targets, or techniques. 3.1. Recording Vendor Name Attribution A name assigned by a security vendor carries meaning only in the context of that producer's tracking methodology. The threat-actor galaxy therefore links each vendor name to its producer instead of storing an unqualified synonym. The cluster's meta object uses the name-attribution array for this purpose. Each entry has the form name:producer-cluster-uuid, where name is the exact threat actor name allocated by the vendor and producer-cluster-uuid is the UUID of that vendor's MISP Galaxy cluster producer entry. For example: "meta": { "name-attribution": [ "TA511:cae79680-67a6-4411-903c-f824dbcc813f" ] } Dulaunoy, et al. Expires 7 February 2027 [Page 5] Internet-Draft Recommendations on Naming Threat Actors August 2026 In this example, TA511 is the vendor-allocated threat actor name and cae79680-67a6-4411-903c-f824dbcc813f identifies the producer in MISP Galaxy. Consumers can consequently resolve who allocated the name without relying on the name's spelling or on an implicit vendor convention. The producer UUID SHOULD be used instead of a free-form producer name because the UUID is the stable reference when an organization changes its name or display value. Contributors adding a vendor-allocated name SHOULD: 1. preserve the spelling and capitalization used by the producer; 2. add or reuse the producer's MISP Galaxy cluster and reference its UUID in name-attribution; 3. include a public vendor reference supporting the allocation when one is available; 4. avoid assigning one vendor's name to a different producer, even when another vendor treats the actors as equivalent; and 5. keep distinct entries when the equivalence is uncertain, expressing the assessed relationship and confidence separately. This representation separates the stable identity of the consolidated MISP Galaxy threat actor, expressed by the threat-actor cluster UUID, from the vendor-specific name and the producer responsible for allocating it. It also supports the best practices above by retaining provenance, limiting ambiguous aliases, and allowing names and actor definitions to evolve without discarding historical correlations. 4. Examples Some known examples are included below and serve as references for good and bad practices in naming threat actors. The following threat actor names are considered good examples: * APT-1 * TA-505 The following threat actor names are considered examples to avoid: * GIF89a (Word also used for the GIF header) * ShadyRAT (Confusion between the name and the tool) * Group 3 (Common name used for other use-cases) * ZooPark (Name is used to describe something else) Dulaunoy, et al. Expires 7 February 2027 [Page 6] Internet-Draft Recommendations on Naming Threat Actors August 2026 5. Security Considerations Naming a threat actor could include sensitive references to a case or an incident. Before releasing a name, the creator MUST review the name to ensure no sensitive information is included in the threat actor name. 6. Acknowledgements The authors wish to thank all contributors who provided feedback through the now-defunct Twitter, other social networks such as Mastodon, Linkedin or via GitHub Issues. 7. References 8. References 8.1. Normative References [MISP-G] Community, M., "MISP Galaxy - Public repository", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [MISP-P] Community, M., "MISP Project - Open Source Threat Intelligence Platform and Open Standards For Threat Information Sharing", . Authors' Addresses Alexandre Dulaunoy Computer Incident Response Center Luxembourg 122, rue Adolphe Fischer L-L-1521 Luxembourg Luxembourg Phone: +352 247 88444 Email: alexandre.dulaunoy@circl.lu Pauline Bourmeau Cubessa Email: Pauline@cubessa.io Dulaunoy, et al. Expires 7 February 2027 [Page 7] Internet-Draft Recommendations on Naming Threat Actors August 2026 Andras Iklody Computer Incident Response Center Luxembourg Phone: +352 247 88444 Email: andras.iklody@circl.lu Dulaunoy, et al. Expires 7 February 2027 [Page 8]