misp-rfc/threat-actor-naming/threat-actor-naming.html

647 lines
21 KiB
HTML

<!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 Recommendations">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Reusing threat actor naming">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Uniqueness">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Format">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Encoding">
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 Don't confuse actor naming with malware naming">
<link href="#rfc.section.2.6" rel="Chapter" title="2.6 Directory">
<link href="#rfc.section.3" rel="Chapter" title="3 Examples">
<link href="#rfc.section.4" rel="Chapter" title="4 Security Considerations">
<link href="#rfc.section.5" rel="Chapter" title="5 Acknowledgements">
<link href="#rfc.section.6" rel="Chapter" title="6 References">
<link href="#rfc.references" rel="Chapter" title="7 References">
<link href="#rfc.references.1" rel="Chapter" title="7.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="7.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">Recommendations</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Reusing threat actor naming</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Uniqueness</a>
</li>
<li>2.3. <a href="#rfc.section.2.3">Format</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Encoding</a>
</li>
<li>2.5. <a href="#rfc.section.2.5">Don't confuse actor naming with malware naming</a>
</li>
<li>2.6. <a href="#rfc.section.2.6">Directory</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Examples</a>
</li>
<li>4. <a href="#rfc.section.4">Security Considerations</a>
</li>
<li>5. <a href="#rfc.section.5">Acknowledgements</a>
</li>
<li>6. <a href="#rfc.section.6">References</a>
</li>
<li>7. <a href="#rfc.references">References</a>
</li>
<ul><li>7.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>7.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>
<p id="rfc.section.1.p.1">In threat intelligence, a name can be assigned to a threat actor without specific guidelines. This leads to issues such as a:</p>
<p></p>
<ul>
<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>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?)</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 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?)</li>
<li>Lack of time-based information about the threat actor name, such as date of naming or and UUID.</li>
<li>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.</li>
</ul>
<p> </p>
<p id="rfc.section.1.p.3">This document proposes a set of guidelines to name threat actors. The goal is to reduce the above mentioned issues.</p>
<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="#recommendations" id="recommendations">Recommendations</a>
</h1>
<p id="rfc.section.2.p.1">The recommendations listed below provide a minimal set of guidelines while assigning a new name to a threat actor.</p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#reusing-threat-actor-naming" id="reusing-threat-actor-naming">Reusing threat actor naming</a>
</h1>
<p id="rfc.section.2.1.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.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#uniqueness" id="uniqueness">Uniqueness</a>
</h1>
<p id="rfc.section.2.2.p.1">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.</p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#format" id="format">Format</a>
</h1>
<p id="rfc.section.2.3.p.1">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.</p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#encoding" id="encoding">Encoding</a>
</h1>
<p id="rfc.section.2.4.p.1">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.</p>
<h1 id="rfc.section.2.5">
<a href="#rfc.section.2.5">2.5.</a> <a href="#don-t-confuse-actor-naming-with-malware-naming" id="don-t-confuse-actor-naming-with-malware-naming">Don't confuse actor naming with malware naming</a>
</h1>
<p id="rfc.section.2.5.p.1">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.</p>
<h1 id="rfc.section.2.6">
<a href="#rfc.section.2.6">2.6.</a> <a href="#directory" id="directory">Directory</a>
</h1>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#examples" id="examples">Examples</a>
</h1>
<p id="rfc.section.3.p.1">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:</p>
<p></p>
<ul>
<li>APT-1</li>
<li>TA-505</li>
</ul>
<p> </p>
<p id="rfc.section.3.p.3">The below threat actor names can be considered as example to not follow:</p>
<p></p>
<ul>
<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>
<p> </p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<p id="rfc.section.4.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.5">
<a href="#rfc.section.5">5.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
<p id="rfc.section.5.p.1">The authors wish to thank all contributors who provided feedback via Twitter.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#references" id="references">References</a>
</h1>
<h1 id="rfc.references">
<a href="#rfc.references">7.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">7.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">7.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>