MISP
/
misp-rfc
mirror of https://github.com/MISP/misp-rfc
2
0
Fork 0
Code Issues Releases Wiki Activity

chg: [threat-actor-naming] draft updated, grammar corrected and small updates

pull/50/head
Alexandre Dulaunoy 2024-12-21 11:34:20 +01:00
parent a940150a8f
commit 2a9ea5fdf6
No known key found for this signature in database
GPG Key ID: 09E2CD4944E6CBCD
5 changed files with 1799 additions and 858 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
threat-actor-naming/build.sh
View File

@ -1,4 +1,4 @@
/home/adulau/git/mmark2/mmark2 -2 raw.md >threat-actor-naming.xml
/home/adulau/git/mmark/mmark raw.md >threat-actor-naming.xml
xml2rfc --html threat-actor-naming.xml
xml2rfc threat-actor-naming.xml
cp threat-actor-naming.txt /home/adulau/git/misp-standard.org/rfc

67
threat-actor-naming/raw.md Executable file → Normal file
View File

@ -1,12 +1,18 @@
%%%
Title = "Recommendations on naming threat actors"
abbrev = "Recommendations on naming threat actors"
Title = "Recommendations on Naming Threat Actors"
abbrev = "Recommendations on Naming Threat Actors"
category = "info"
docName = "draft-dulaunoy-threat-actor-naming"
ipr= "trust200902"
area = "Security"
date = 2024-12-21T00:00:00Z
submissiontype = "independent"
date = 2020-06-09T00:00:00Z
[seriesInfo]
name = "Internet-Draft"
value = "draft-00"
stream = "independent"
status = "informational"
[[author]]
initials="A."
@ -18,9 +24,9 @@ organization = "Computer Incident Response Center Luxembourg"
email = "alexandre.dulaunoy@circl.lu"
phone = "+352 247 88444"
[author.address.postal]
street = "16, bd d'Avranches"
street = "122, rue Adolphe Fischer"
city = "Luxembourg"
code = "L-1160"
code = "L-1521"
country = "Luxembourg"
[[author]]
initials="P."
@ -41,26 +47,26 @@ organization = "Corexalys"
.# Abstract
This document provides advice on the naming of threat actors (also known as malicious actors).
The objective is to provide practical advices for organisations such as security vendors or organisations attributing
incidents to a group of threat actor. It also discusses the implication of naming a threat actor towards intelligence analysts
and threat intelligence platforms such as MISP [@?MISP-P]].
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].
{mainmatter}
# Introduction
In threat intelligence, a name can be assigned to a threat actor without specific guidelines. This leads to issues such
as a:
as:
- A proliferation of threat actor names generating overlaps or different names for similar threat actors (e.g. some threat actors have more than 10 synonyms)
- Ambiguity in the words used to name the threat actor in different contexts (e.g. using common words)
- No clearly defined text format to describe the same threat actor (e.g. Is the threat actor name case sensitive? Is there a dash or a space between the two words?)
- Confusion between techniques/tools used by a threat actor versus its name (e.g. naming a threat actor after a specific malware used)
- Lack of source and list from vendors to describe their threat actor names and the reasoning behind the naming (e.g. did they name the threat actor after a specific set of campaigns? or specific set of targets?)
- Lack of time-based information about the threat actor name, such as date of naming or and UUID.
- Lack of open mirrored "registry" of reference, accessible to all, where to register a new threat actor name, or to access all already named threat actors. The "registry" can contain the time-based information mentionned above, it is a tool.
- A proliferation of threat actor names generating overlaps or different names for similar threat actors (e.g., some threat actors have more than 10 synonyms).
- Ambiguity in the words used to name the threat actor in different contexts (e.g., using common words).
- Lack of a clearly defined text format to describe the same threat actor (e.g., Is the threat actor name case-sensitive? Is there a dash or a space between the words?).
- Confusion between techniques/tools used by a threat actor versus its name (e.g., naming a threat actor after a specific malware used).
- Lack of source and reasoning from vendors when they describe their threat actor names (e.g., did they name the threat actor after a specific set of campaigns or a specific set of targets?).
- Lack of time-based information about the threat actor name, such as date of naming or a UUID.
- Lack of an open, mirrored "registry" of reference, accessible to all, where a new threat actor name can be registered, or where all already named threat actors can be accessed. The "registry" can contain the time-based information mentioned above; it is a tool.
This document proposes a set of guidelines to name threat actors. The goal is to reduce the above mentioned issues.
This document proposes a set of guidelines for naming threat actors. The goal is to reduce the issues mentioned above.
## Conventions and Terminology
@ -71,40 +77,40 @@ document are to be interpreted as described in RFC 2119 [@!RFC2119].
# Recommendations
The recommendations listed below provide a minimal set of guidelines while assigning a new name to a threat actor.
The recommendations listed below provide a minimal set of guidelines when assigning a new name to a threat actor.
## Reusing threat actor naming
## Reusing Threat Actor Names
Before creating a new threat actor name, you **MUST** consider a review of existing threat actor names from databases such as the threat actor
MISP galaxy [@!MISP-G]. Proliferation of threat actor names is a significant challenge for the day-to-day analyst work. If your threat actor defined an existing threat actor, you **MUST**
reuse an existing threat actor name. If there is no specific threat actor name, you **SHALL** create a new threat actor following the best practices defined in this document.
Before creating a new threat actor name, you **MUST** consider a review of existing threat actor names from databases such as the threat actor MISP galaxy [@!MISP-G]. Proliferation of threat actor names is a significant challenge for day-to-day analyst work. If your defined threat actor matches an existing threat actor, you **MUST** reuse an existing threat actor name. If there is no matching threat actor name, you **SHALL** create a new threat actor name, following the best practices defined in this document.
## Uniqueness
When choosing a threat actor name, uniqueness is a critical property. The threat actor name **MUST** be unique and not existing in different contexts. The name **MUST** not be a word from a dictionary which can be used in other contexts.
When choosing a threat actor name, uniqueness is a critical property. The threat actor name **MUST** be unique and not already in use in different contexts. The name **MUST NOT** be a word from a dictionary, which could be used in other contexts.
## Format
The name of the threat actor **SHALL** be composed of a single word. If there is multiple part like a decimal value such as a counter, the values **MUST** be separated with a dash. Single words are preferred to ease the search of keywords by analysts in public sources.
The name of the threat actor **SHALL** be composed of a single word. If there are multiple parts, such as a decimal value or a counter, the values **MUST** be separated with a dash. Single words are preferred to ease keyword searches by analysts in public sources.
## Encoding
The name of the threat actor **MUST** be expressed in ASCII 7-bit. Assigning a localized name to a threat actor **MAY** create a set of ambiguity about different localized version of the same threat actor.
The name of the threat actor **MUST** be expressed in 7-bit ASCII. Assigning a localized name to a threat actor **MAY** create ambiguity due to different localized versions of the same threat actor.
## Don't confuse actor naming with malware naming
## Avoid Confusing Actor Names with Malware Names
The name of the threat actor **MUST NOT** be assigned based on the tools, techniques or patterns used by the threat actor. A notorious example in the threat intelligence community is Turla which can name a threat actor but also a malware used by this group or other groups.
The name of the threat actor **MUST NOT** be based on the tools, techniques, or patterns used by the threat actor. A notorious example in the threat intelligence community is Turla, which can refer to a threat actor but also to a malware used by this group or other groups.
## Directory
A reference registry of threat actors is **RECOMMENDED** to ensure consistency of names accross different parties.
# Examples
Some known examples are included below and serve as reference for good practices in naming threat actors. The below threat actor names can be considered good example:
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 below threat actor names can be considered as example to not follow:
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)
@ -113,8 +119,7 @@ The below threat actor names can be considered as example to not follow:
# Security Considerations
Naming a threat actor could include specific sensitive reference to a case or an incident. Before releasing the naming, the creator
**MUST** review the name to ensure no sensitive information is included in the threat actor name.
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.
# Acknowledgements

2204
threat-actor-naming/threat-actor-naming.html
View File

File diff suppressed because it is too large Load Diff

244
threat-actor-naming/threat-actor-naming.txt
View File

@ -4,20 +4,21 @@
Network Working Group A. Dulaunoy
Internet-Draft P. Bourmeau
Expires: December 11, 2020 CIRCL
June 9, 2020
Intended status: Informational CIRCL
Expires: 24 June 2025 21 December 2024
Recommendations on naming threat actors
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
advices for organisations such as security vendors or organisations
attributing incidents to a group of threat actor. It also discusses
the implication of naming a threat actor towards intelligence
analysts and threat intelligence platforms such as MISP [MISP-P]].
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
@ -34,28 +35,27 @@ Status of This Memo
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 December 11, 2020.
This Internet-Draft will expire on 24 June 2025.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
Copyright (c) 2024 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 & Bourmeau Expires December 11, 2020 [Page 1]
Dulaunoy & Bourmeau Expires 24 June 2025 [Page 1]
Internet-Draft Recommendations on naming threat actors June 2020
Internet-Draft Recommendations on Naming Threat Actors December 2024
Table of Contents
@ -63,65 +63,57 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Reusing threat actor naming . . . . . . . . . . . . . . . 3
2.1. Reusing Threat Actor Names . . . . . . . . . . . . . . . 3
2.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Don't confuse actor naming with malware naming . . . . . 4
2.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5. Avoid Confusing Actor Names with Malware Names . . . . . 4
2.6. Directory . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
In threat intelligence, a name can be assigned to a threat actor
without specific guidelines. This leads to issues such as a:
without specific guidelines. This leads to issues such as:
o A proliferation of threat actor names generating overlaps or
different names for similar threat actors (e.g. some threat actors
have more than 10 synonyms)
* A proliferation of threat actor names generating overlaps or
different names for similar threat actors (e.g., some threat
actors have more than 10 synonyms).
* Ambiguity in the words used to name the threat actor in different
contexts (e.g., using common words).
* Lack of a clearly defined text format to describe the same threat
actor (e.g., Is the threat actor name case-sensitive? Is there a
dash or a space between the words?).
* Confusion between techniques/tools used by a threat actor versus
its name (e.g., naming a threat actor after a specific malware
used).
* Lack of source and reasoning from vendors when they describe their
threat actor names (e.g., did they name the threat actor after a
specific set of campaigns or a specific set of targets?).
* Lack of time-based information about the threat actor name, such
as date of naming or a UUID.
* Lack of an open, mirrored "registry" of reference, accessible to
all, where a new threat actor name can be registered, or where all
already named threat actors can be accessed. The "registry" can
contain the time-based information mentioned above; it is a tool.
o Ambiguity in the words used to name the threat actor in different
contexts (e.g. using common words)
o No clearly defined text format to describe the same threat actor
(e.g. Is the threat actor name case sensitive? Is there a dash
or a space between the two words?)
o Confusion between techniques/tools used by a threat actor versus
its name (e.g. naming a threat actor after a specific malware
used)
o Lack of source and list from vendors to describe their threat
actor names and the reasoning behind the naming (e.g. did they
name the threat actor after a specific set of campaigns? or
specific set of targets?)
o Lack of time-based information about the threat actor name, such
as date of naming or and UUID.
This document proposes a set of guidelines for naming threat actors.
The goal is to reduce the issues mentioned above.
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 2]
Dulaunoy & Bourmeau Expires 24 June 2025 [Page 2]
Internet-Draft Recommendations on naming threat actors June 2020
Internet-Draft Recommendations on Naming Threat Actors December 2024
o Lack of open mirrored "registry" of reference, accessible to all,
where to register a new threat actor name, or to access all
already named threat actors. The "registry" can contain the time-
based information mentionned above, it is a tool.
This document proposes a set of guidelines to name threat actors.
The goal is to reduce the above mentioned issues.
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@ -131,107 +123,109 @@ Internet-Draft Recommendations on naming threat actors June 2020
2. Recommendations
The recommendations listed below provide a minimal set of guidelines
while assigning a new name to a threat actor.
when assigning a new name to a threat actor.
2.1. Reusing threat actor naming
2.1. Reusing Threat Actor Names
Before creating a new threat actor name, you MUST consider a review
of existing threat actor names from databases such as the threat
actor MISP galaxy [MISP-G]. Proliferation of threat actor names is a
significant challenge for the day-to-day analyst work. If your
threat actor defined an existing threat actor, you MUST reuse an
existing threat actor name. If there is no specific threat actor
name, you SHALL create a new threat actor following the best
significant challenge for day-to-day analyst work. If your defined
threat actor matches an existing threat actor, you MUST reuse an
existing threat actor name. If there is no matching threat actor
name, you SHALL create a new threat actor name, following the best
practices defined in this document.
2.2. Uniqueness
When choosing a threat actor name, uniqueness is a critical property.
The threat actor name MUST be unique and not existing in different
contexts. The name MUST not be a word from a dictionary which can be
used in other contexts.
The threat actor name MUST be unique and not already in use in
different contexts. The name MUST NOT be a word from a dictionary,
which could be used in other contexts.
2.3. Format
The name of the threat actor SHALL be composed of a single word. If
there is multiple part like a decimal value such as a counter, the
there are multiple parts, such as a decimal value or a counter, the
values MUST be separated with a dash. Single words are preferred to
ease the search of keywords by analysts in public sources.
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 3]
Internet-Draft Recommendations on naming threat actors June 2020
ease keyword searches by analysts in public sources.
2.4. Encoding
The name of the threat actor MUST be expressed in ASCII 7-bit.
Assigning a localized name to a threat actor MAY create a set of
ambiguity about different localized version of the same threat actor.
The name of the threat actor MUST be expressed in 7-bit ASCII.
Assigning a localized name to a threat actor MAY create ambiguity due
to different localized versions of the same threat actor.
2.5. Don't confuse actor naming with malware naming
The name of the threat actor MUST NOT be assigned based on the tools,
techniques or patterns used by the threat actor. A notorious example
in the threat intelligence community is Turla which can name a threat
actor but also a malware used by this group or other groups.
Dulaunoy & Bourmeau Expires 24 June 2025 [Page 3]
Internet-Draft Recommendations on Naming Threat Actors December 2024
2.5. Avoid Confusing Actor Names with Malware Names
The name of the threat actor MUST NOT be based on the tools,
techniques, or patterns used by the threat actor. A notorious
example in the threat intelligence community is Turla, which can
refer to a threat actor but also to a malware used by this group or
other groups.
2.6. Directory
A reference registry of threat actors is RECOMMENDED to ensure
consistency of names accross different parties.
3. Examples
Some known examples are included below and serve as reference for
good practices in naming threat actors. The below threat actor names
can be considered good example:
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:
o APT-1
* APT-1
* TA-505
o TA-505
The following threat actor names are considered examples to avoid:
The below threat actor names can be considered as example to not
follow:
o GIF89a (Word also used for the GIF header)
o ShadyRAT (Confusion between the name and the tool)
o Group 3 (Common name used for other use-cases)
o ZooPark (Name is used to describe something else)
* 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)
4. Security Considerations
Naming a threat actor could include specific sensitive reference to a
case or an incident. Before releasing the naming, the creator MUST
review the name to ensure no sensitive information is included in the
threat actor name.
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.
5. Acknowledgements
The authors wish to thank all contributors who provided feedback via
Twitter.
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 4]
Internet-Draft Recommendations on naming threat actors June 2020
6. References
7. References
7.1. Normative References
Dulaunoy & Bourmeau Expires 24 June 2025 [Page 4]
Internet-Draft Recommendations on Naming Threat Actors December 2024
[MISP-G] Community, M., "MISP Galaxy - Public repository",
<https://github.com/MISP/misp-galaxy>.
@ -250,10 +244,9 @@ Authors' Addresses
Alexandre Dulaunoy
Computer Incident Response Center Luxembourg
16, bd d'Avranches
Luxembourg L-1160
122, rue Adolphe Fischer
L-L-1521 Luxembourg
Luxembourg
Phone: +352 247 88444
Email: alexandre.dulaunoy@circl.lu
@ -261,9 +254,8 @@ Authors' Addresses
Pauline Bourmeau
Corexalys
26 Rue de la Bienfaisance
Paris 75008
75008 Paris
France
Email: info@corexalys.com
@ -277,4 +269,12 @@ Authors' Addresses
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 5]
Dulaunoy & Bourmeau Expires 24 June 2025 [Page 5]

140
threat-actor-naming/threat-actor-naming.xml
View File

@ -1,122 +1,118 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" xml:lang="en" consensus="yes">
<?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><?rfc comments="no"?>
<rfc version="3" ipr="trust200902" docName="draft-00" submissionType="independent" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true">
<front>
<title abbrev="Recommendations on naming threat actors">Recommendations on naming threat actors</title><author initials="A." surname="Dulaunoy" fullname="Alexandre Dulaunoy"><organization abbrev="CIRCL">Computer Incident Response Center Luxembourg</organization><address><postal><street>16, bd d'Avranches</street>
<title abbrev="Recommendations on Naming Threat Actors">Recommendations on Naming Threat Actors</title><seriesInfo value="draft-00" stream="independent" status="informational" name="Internet-Draft"></seriesInfo>
<author initials="A." surname="Dulaunoy" fullname="Alexandre Dulaunoy"><organization abbrev="CIRCL">Computer Incident Response Center Luxembourg</organization><address><postal><street>122, rue Adolphe Fischer</street>
<city>Luxembourg</city>
<code>L-1160</code>
<code>L-1521</code>
<country>Luxembourg</country>
</postal><phone>+352 247 88444</phone>
<email>alexandre.dulaunoy@circl.lu</email>
</address></author>
<author initials="P." surname="Bourmeau" fullname="Pauline Bourmeau"><organization abbrev="CIRCL">Corexalys</organization><address><postal><street>26 Rue de la Bienfaisance</street>
</address></author><author initials="P." surname="Bourmeau" fullname="Pauline Bourmeau"><organization abbrev="CIRCL">Corexalys</organization><address><postal><street>26 Rue de la Bienfaisance</street>
<city>Paris</city>
<code>75008</code>
<country>France</country>
</postal><email>info@corexalys.com</email>
</address></author>
<date year="2020" month="June" day="9"></date>
<area>Security</area><workgroup></workgroup>
<abstract><t>This document provides advice on the naming of threat actors (also known as malicious actors).
The objective is to provide practical advices for organisations such as security vendors or organisations attributing
incidents to a group of threat actor. It also discusses the implication of naming a threat actor towards intelligence analysts
and threat intelligence platforms such as MISP <xref target="MISP-P"></xref>].</t>
</address></author><date year="2024" month="December" day="21"></date>
<area>Security</area>
<workgroup></workgroup>
<abstract>
<t>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 <xref target="MISP-P"></xref>.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<section anchor="introduction"><name>Introduction</name>
<t>In threat intelligence, a name can be assigned to a threat actor without specific guidelines. This leads to issues such
as a:</t>
<t>
<list style="symbols">
<t>A proliferation of threat actor names generating overlaps or different names for similar threat actors (e.g. some threat actors have more than 10 synonyms)</t>
<t>Ambiguity in the words used to name the threat actor in different contexts (e.g. using common words)</t>
<t>No clearly defined text format to describe the same threat actor (e.g. Is the threat actor name case sensitive? Is there a dash or a space between the two words?)</t>
<t>Confusion between techniques/tools used by a threat actor versus its name (e.g. naming a threat actor after a specific malware used)</t>
<t>Lack of source and list from vendors to describe their threat actor names and the reasoning behind the naming (e.g. did they name the threat actor after a specific set of campaigns? or specific set of targets?)</t>
<t>Lack of time-based information about the threat actor name, such as date of naming or and UUID.</t>
<t>Lack of open mirrored &quot;registry&quot; of reference, accessible to all, where to register a new threat actor name, or to access all already named threat actors. The &quot;registry&quot; can contain the time-based information mentionned above, it is a tool.</t>
</list>
</t>
<t>This document proposes a set of guidelines to name threat actors. The goal is to reduce the above mentioned issues.</t>
as:</t>
<section anchor="conventions-and-terminology" title="Conventions and Terminology">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
<ul spacing="compact">
<li>A proliferation of threat actor names generating overlaps or different names for similar threat actors (e.g., some threat actors have more than 10 synonyms).</li>
<li>Ambiguity in the words used to name the threat actor in different contexts (e.g., using common words).</li>
<li>Lack of a clearly defined text format to describe the same threat actor (e.g., Is the threat actor name case-sensitive? Is there a dash or a space between the words?).</li>
<li>Confusion between techniques/tools used by a threat actor versus its name (e.g., naming a threat actor after a specific malware used).</li>
<li>Lack of source and reasoning from vendors when they describe their threat actor names (e.g., did they name the threat actor after a specific set of campaigns or a specific set of targets?).</li>
<li>Lack of time-based information about the threat actor name, such as date of naming or a UUID.</li>
<li>Lack of an open, mirrored &quot;registry&quot; of reference, accessible to all, where a new threat actor name can be registered, or where all already named threat actors can be accessed. The &quot;registry&quot; can contain the time-based information mentioned above; it is a tool.</li>
</ul>
<t>This document proposes a set of guidelines for naming threat actors. The goal is to reduce the issues mentioned above.</t>
<section anchor="conventions-and-terminology"><name>Conventions and Terminology</name>
<t>The key words &quot;<bcp14>MUST</bcp14>&quot;, &quot;<bcp14>MUST NOT</bcp14>&quot;, &quot;<bcp14>REQUIRED</bcp14>&quot;, &quot;<bcp14>SHALL</bcp14>&quot;, &quot;<bcp14>SHALL NOT</bcp14>&quot;,
&quot;<bcp14>SHOULD</bcp14>&quot;, &quot;<bcp14>SHOULD NOT</bcp14>&quot;, &quot;<bcp14>RECOMMENDED</bcp14>&quot;, &quot;<bcp14>MAY</bcp14>&quot;, and &quot;<bcp14>OPTIONAL</bcp14>&quot; in this
document are to be interpreted as described in RFC 2119 <xref target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="recommendations" title="Recommendations">
<t>The recommendations listed below provide a minimal set of guidelines while assigning a new name to a threat actor.</t>
<section anchor="recommendations"><name>Recommendations</name>
<t>The recommendations listed below provide a minimal set of guidelines when assigning a new name to a threat actor.</t>
<section anchor="reusing-threat-actor-naming" title="Reusing threat actor naming">
<t>Before creating a new threat actor name, you MUST consider a review of existing threat actor names from databases such as the threat actor
MISP galaxy <xref target="MISP-G"></xref>. Proliferation of threat actor names is a significant challenge for the day-to-day analyst work. If your threat actor defined an existing threat actor, you MUST
reuse an existing threat actor name. If there is no specific threat actor name, you SHALL create a new threat actor following the best practices defined in this document.</t>
<section anchor="reusing-threat-actor-names"><name>Reusing Threat Actor Names</name>
<t>Before creating a new threat actor name, you <bcp14>MUST</bcp14> consider a review of existing threat actor names from databases such as the threat actor MISP galaxy <xref target="MISP-G"></xref>. Proliferation of threat actor names is a significant challenge for day-to-day analyst work. If your defined threat actor matches an existing threat actor, you <bcp14>MUST</bcp14> reuse an existing threat actor name. If there is no matching threat actor name, you <bcp14>SHALL</bcp14> create a new threat actor name, following the best practices defined in this document.</t>
</section>
<section anchor="uniqueness" title="Uniqueness">
<t>When choosing a threat actor name, uniqueness is a critical property. The threat actor name MUST be unique and not existing in different contexts. The name MUST not be a word from a dictionary which can be used in other contexts.</t>
<section anchor="uniqueness"><name>Uniqueness</name>
<t>When choosing a threat actor name, uniqueness is a critical property. The threat actor name <bcp14>MUST</bcp14> be unique and not already in use in different contexts. The name <bcp14>MUST NOT</bcp14> be a word from a dictionary, which could be used in other contexts.</t>
</section>
<section anchor="format" title="Format">
<t>The name of the threat actor SHALL be composed of a single word. If there is multiple part like a decimal value such as a counter, the values MUST be separated with a dash. Single words are preferred to ease the search of keywords by analysts in public sources.</t>
<section anchor="format"><name>Format</name>
<t>The name of the threat actor <bcp14>SHALL</bcp14> be composed of a single word. If there are multiple parts, such as a decimal value or a counter, the values <bcp14>MUST</bcp14> be separated with a dash. Single words are preferred to ease keyword searches by analysts in public sources.</t>
</section>
<section anchor="encoding" title="Encoding">
<t>The name of the threat actor MUST be expressed in ASCII 7-bit. Assigning a localized name to a threat actor MAY create a set of ambiguity about different localized version of the same threat actor.</t>
<section anchor="encoding"><name>Encoding</name>
<t>The name of the threat actor <bcp14>MUST</bcp14> be expressed in 7-bit ASCII. Assigning a localized name to a threat actor <bcp14>MAY</bcp14> create ambiguity due to different localized versions of the same threat actor.</t>
</section>
<section anchor="don-t-confuse-actor-naming-with-malware-naming" title="Don't confuse actor naming with malware naming">
<t>The name of the threat actor MUST NOT be assigned based on the tools, techniques or patterns used by the threat actor. A notorious example in the threat intelligence community is Turla which can name a threat actor but also a malware used by this group or other groups.</t>
<section anchor="avoid-confusing-actor-names-with-malware-names"><name>Avoid Confusing Actor Names with Malware Names</name>
<t>The name of the threat actor <bcp14>MUST NOT</bcp14> be based on the tools, techniques, or patterns used by the threat actor. A notorious example in the threat intelligence community is Turla, which can refer to a threat actor but also to a malware used by this group or other groups.</t>
</section>
<section anchor="directory" title="Directory">
<section anchor="directory"><name>Directory</name>
<t>A reference registry of threat actors is <bcp14>RECOMMENDED</bcp14> to ensure consistency of names accross different parties.</t>
</section>
</section>
<section anchor="examples" title="Examples">
<t>Some known examples are included below and serve as reference for good practices in naming threat actors. The below threat actor names can be considered good example:</t>
<t>
<list style="symbols">
<t>APT-1</t>
<t>TA-505</t>
</list>
</t>
<t>The below threat actor names can be considered as example to not follow:</t>
<t>
<list style="symbols">
<t>GIF89a (Word also used for the GIF header)</t>
<t>ShadyRAT (Confusion between the name and the tool)</t>
<t>Group 3 (Common name used for other use-cases)</t>
<t>ZooPark (Name is used to describe something else)</t>
</list>
</t>
<section anchor="examples"><name>Examples</name>
<t>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:</t>
<ul spacing="compact">
<li>APT-1</li>
<li>TA-505</li>
</ul>
<t>The following threat actor names are considered examples to avoid:</t>
<ul spacing="compact">
<li>GIF89a (Word also used for the GIF header)</li>
<li>ShadyRAT (Confusion between the name and the tool)</li>
<li>Group 3 (Common name used for other use-cases)</li>
<li>ZooPark (Name is used to describe something else)</li>
</ul>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>Naming a threat actor could include specific sensitive reference to a case or an incident. Before releasing the naming, the creator
MUST review the name to ensure no sensitive information is included in the threat actor name.</t>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>Naming a threat actor could include sensitive references to a case or an incident. Before releasing a name, the creator <bcp14>MUST</bcp14> review the name to ensure no sensitive information is included in the threat actor name.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors wish to thank all contributors who provided feedback via Twitter.</t>
</section>
<section anchor="references" title="References">
<section anchor="references"><name>References</name>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<references><name>References</name>
<references><name>Normative References</name>
<reference anchor="MISP-G" target="https://github.com/MISP/misp-galaxy">
<front>
<title>MISP Galaxy - Public repository </title>
@ -124,8 +120,9 @@ MUST review the name to ensure no sensitive information is included in the threa
<date></date>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
</references>
<references title="Informative References">
<references><name>Informative References</name>
<reference anchor="MISP-P" target="https://github.com/MISP">
<front>
<title>MISP Project - Open Source Threat Intelligence Platform and Open Standards For Threat Information Sharing</title>
@ -134,6 +131,7 @@ MUST review the name to ensure no sensitive information is included in the threa
</front>
</reference>
</references>
</references>
</back>