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

chg: [threat-actor-naming] basic introduction and skeleton

pull/36/head
Alexandre Dulaunoy 2020-06-09 21:37:27 +02:00
parent ebb8814c09
commit 2eab004862
No known key found for this signature in database
GPG Key ID: 09E2CD4944E6CBCD
5 changed files with 957 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
threat-actor-naming/build.sh Normal file
View File

@ -0,0 +1,5 @@
/home/adulau/git/mmark2/mmark2 -2 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
cp threat-actor-naming.html /home/adulau/git/misp-standard.org/rfc

108
threat-actor-naming/raw.md Executable file
View File

@ -0,0 +1,108 @@
%%%
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 = 2020-06-09T00:00:00Z
[[author]]
initials="A."
surname="Dulaunoy"
fullname="Alexandre Dulaunoy"
abbrev="CIRCL"
organization = "Computer Incident Response Center Luxembourg"
[author.address]
email = "alexandre.dulaunoy@circl.lu"
phone = "+352 247 88444"
[author.address.postal]
street = "16, bd d'Avranches"
city = "Luxembourg"
code = "L-1160"
country = "Luxembourg"
[[author]]
initials="P."
surname="Bourmeau"
fullname="Pauline Bourmeau"
abbrev="CIRCL"
organization = "Corexalys"
[author.address]
email = "info@corexalys.com"
phone = ""
[author.address.postal]
street = "26 Rue de la Bienfaisance"
city = "Paris"
code = "75008"
country = "France"
%%%
.# 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]].
{mainmatter}
# Introduction
## 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].
# Reusing threat actor naming
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.
# Format
# Encoding
# Examples
# 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.
# Acknowledgements
The authors wish to thank all contributors who provided feedback via Twitter.
# References
<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>
<author initials='' surname='MISP' fullname='MISP Community'></author>
<date></date>
</front>
</reference>
<reference anchor='MISP-T' target='https://github.com/MISP/misp-taxonomies'>
<front>
<title>MISP Taxonomies - shared and common vocabularies of tags</title>
<author initials='' surname='MISP' fullname='MISP Community'></author>
<date></date>
</front>
</reference>
<reference anchor='MISP-G' target='https://github.com/MISP/misp-galaxy'>
<front>
<title>MISP Galaxy - Public repository </title>
<author initials='' surname='MISP' fullname='MISP Community'></author>
<date></date>
</front>
</reference>
{backmatter}

582
threat-actor-naming/threat-actor-naming.html Normal file
View File

@ -0,0 +1,582 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Recommendations on naming threat actors</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Conventions and Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Reusing threat actor naming">
<link href="#rfc.section.3" rel="Chapter" title="3 Format">
<link href="#rfc.section.4" rel="Chapter" title="4 Encoding">
<link href="#rfc.section.5" rel="Chapter" title="5 Examples">
<link href="#rfc.section.6" rel="Chapter" title="6 Security Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 Acknowledgements">
<link href="#rfc.section.8" rel="Chapter" title="8 References">
<link href="#rfc.references" rel="Chapter" title="9 References">
<link href="#rfc.references.1" rel="Chapter" title="9.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="9.2 Informative References">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.23.1 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Dulaunoy, A. and P. Bourmeau" />
<meta name="dct.identifier" content="urn:ietf:id:" />
<meta name="dct.issued" scheme="ISO8601" content="2020-06-09" />
<meta name="dct.abstract" content="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 ]." />
<meta name="description" content="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 ]." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">A. Dulaunoy</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">P. Bourmeau</td>
</tr>
<tr>
<td class="left">Expires: December 11, 2020</td>
<td class="right">CIRCL</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">June 9, 2020</td>
</tr>
</tbody>
</table>
<p class="title">Recommendations on naming threat actors<br />
<span class="filename"></span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>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 <a href="#MISP-P" class="xref">[MISP-P]</a>].</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on December 11, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>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.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Conventions and Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Reusing threat actor naming</a>
</li>
<li>3. <a href="#rfc.section.3">Format</a>
</li>
<li>4. <a href="#rfc.section.4">Encoding</a>
</li>
<li>5. <a href="#rfc.section.5">Examples</a>
</li>
<li>6. <a href="#rfc.section.6">Security Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">Acknowledgements</a>
</li>
<li>8. <a href="#rfc.section.8">References</a>
</li>
<li>9. <a href="#rfc.references">References</a>
</li>
<ul><li>9.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>9.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#conventions-and-terminology" id="conventions-and-terminology">Conventions and Terminology</a>
</h1>
<p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#reusing-threat-actor-naming" id="reusing-threat-actor-naming">Reusing threat actor naming</a>
</h1>
<p id="rfc.section.2.p.1">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 <a href="#MISP-G" class="xref">[MISP-G]</a>. 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.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#format" id="format">Format</a>
</h1>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#encoding" id="encoding">Encoding</a>
</h1>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#examples" id="examples">Examples</a>
</h1>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.6.p.1">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.</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.7.p.1">The authors wish to thank all contributors who provided feedback via Twitter.</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#references" id="references">References</a>
</h1>
<h1 id="rfc.references">
<a href="#rfc.references">9.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">9.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="MISP-G">[MISP-G]</b></td>
<td class="top">
<a>Community, M.</a>, "<a href="https://github.com/MISP/misp-galaxy">MISP Galaxy - Public repository</a>"</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">9.2.</a> Informative References</h1>
<table><tbody><tr>
<td class="reference"><b id="MISP-P">[MISP-P]</b></td>
<td class="top">
<a>Community, M.</a>, "<a href="https://github.com/MISP">MISP Project - Open Source Threat Intelligence Platform and Open Standards For Threat Information Sharing</a>"</td>
</tr></tbody></table>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Alexandre Dulaunoy</span>
<span class="n hidden">
<span class="family-name">Dulaunoy</span>
</span>
</span>
<span class="org vcardline">Computer Incident Response Center Luxembourg</span>
<span class="adr">
<span class="vcardline">16, bd d'Avranches</span>
<span class="vcardline">
<span class="locality">Luxembourg</span>,
<span class="region"></span>
<span class="code">L-1160</span>
</span>
<span class="country-name vcardline">Luxembourg</span>
</span>
<span class="vcardline">Phone: +352 247 88444</span>
<span class="vcardline">EMail: <a href="mailto:alexandre.dulaunoy@circl.lu">alexandre.dulaunoy@circl.lu</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Pauline Bourmeau</span>
<span class="n hidden">
<span class="family-name">Bourmeau</span>
</span>
</span>
<span class="org vcardline">Corexalys</span>
<span class="adr">
<span class="vcardline">26 Rue de la Bienfaisance</span>
<span class="vcardline">
<span class="locality">Paris</span>,
<span class="region"></span>
<span class="code">75008</span>
</span>
<span class="country-name vcardline">France</span>
</span>
<span class="vcardline">EMail: <a href="mailto:info@corexalys.com">info@corexalys.com</a></span>
</address>
</div>
</body>
</html>

168
threat-actor-naming/threat-actor-naming.txt Normal file
View File

@ -0,0 +1,168 @@
Network Working Group A. Dulaunoy
Internet-Draft P. Bourmeau
Expires: December 11, 2020 CIRCL
June 9, 2020
Recommendations on naming threat actors
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]].
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 December 11, 2020.
Copyright Notice
Copyright (c) 2020 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.
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 1]
Internet-Draft Recommendations on naming threat actors June 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. Reusing threat actor naming . . . . . . . . . . . . . . . . . 2
3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 2
6. Security Considerations . . . . . . . . . . . . . . . . . . . 2
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 3
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 3
9.1. Normative References . . . . . . . . . . . . . . . . . . 3
9.2. Informative References . . . . . . . . . . . . . . . . . 3
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction
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. Reusing threat actor naming
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.
3. Format
4. Encoding
5. Examples
6. 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.
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 2]
Internet-Draft Recommendations on naming threat actors June 2020
7. Acknowledgements
The authors wish to thank all contributors who provided feedback via
Twitter.
8. References
9. References
9.1. Normative References
[MISP-G] Community, M., "MISP Galaxy - Public repository",
<https://github.com/MISP/misp-galaxy>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[MISP-P] Community, M., "MISP Project - Open Source Threat
Intelligence Platform and Open Standards For Threat
Information Sharing", <https://github.com/MISP>.
Authors' Addresses
Alexandre Dulaunoy
Computer Incident Response Center Luxembourg
16, bd d'Avranches
Luxembourg L-1160
Luxembourg
Phone: +352 247 88444
Email: alexandre.dulaunoy@circl.lu
Pauline Bourmeau
Corexalys
26 Rue de la Bienfaisance
Paris 75008
France
Email: info@corexalys.com
Dulaunoy & Bourmeau Expires December 11, 2020 [Page 3]

94
threat-actor-naming/threat-actor-naming.xml Normal file
View File

@ -0,0 +1,94 @@
<?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"?>
<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>
<city>Luxembourg</city>
<code>L-1160</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>
<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>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<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
document are to be interpreted as described in RFC 2119 <xref target="RFC2119"></xref>.</t>
</section>
</section>
<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>
<section anchor="format" title="Format">
</section>
<section anchor="encoding" title="Encoding">
</section>
<section anchor="examples" title="Examples">
</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>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors wish to thank all contributors who provided feedback via Twitter.</t>
</section>
<section anchor="references" title="References">
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<reference anchor="MISP-G" target="https://github.com/MISP/misp-galaxy">
<front>
<title>MISP Galaxy - Public repository </title>
<author fullname="MISP Community" surname="MISP"></author>
<date></date>
</front>
</reference>
</references>
<references title="Informative References">
<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>
<author fullname="MISP Community" surname="MISP"></author>
<date></date>
</front>
</reference>
</references>
</back>
</rfc>