| Internet-Draft | Recommendations on Naming Threat Actors | August 2026 |
| Dulaunoy, et al. | Expires 7 February 2027 | [Page] |
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].¶
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 (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.¶
In threat intelligence, threat actor names are often assigned without specific or consistent guidelines. This leads to several issues, such as:¶
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.¶
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].¶
The recommendations below specify a minimal set of guidelines to be applied when assigning a new name to a threat actor.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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"
]
}
¶
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:¶
name-attribution;¶
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.¶
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:¶
The following threat actor names are considered examples to avoid:¶
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.¶
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.¶