mirror of https://github.com/MISP/misp-rfc
141 lines
7.6 KiB
XML
141 lines
7.6 KiB
XML
<?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">
|
|
<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</t>
|
|
<t>Lack of open "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.</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>
|
|
|
|
<section anchor="conventions-and-terminology" title="Conventions and Terminology">
|
|
<t>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 <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="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="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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<section anchor="directory" title="Directory">
|
|
</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>
|
|
|
|
<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>
|