├── README.md
├── misp-core-format
├── Makefile
├── raw.md
├── raw.md.html
├── raw.md.txt
└── raw.md.xml
├── misp-galaxy-format
├── Makefile
├── draft-dulaunoy-misp-galaxy-format-02.xml
├── raw.md
└── raw.md.txt
├── misp-noticelist-format
└── raw.md
├── misp-object-template-format
├── Makefile
├── raw.md
├── raw.md.html
├── raw.md.txt
└── raw.md.xml
├── misp-query-format
├── Makefile
├── raw.md
├── raw.md.html
├── raw.md.txt
└── raw.md.xml
├── misp-taxonomy-format
├── Makefile
├── raw.md
└── raw.md.txt
├── misp-warninglist-format
└── raw.md
├── sightingdb-format
├── Makefile
├── raw.md
└── raw.md.txt
└── threat-actor-naming
├── build.sh
├── raw.md
├── threat-actor-naming.html
├── threat-actor-naming.txt
└── threat-actor-naming.xml
/README.md:
--------------------------------------------------------------------------------
1 | # MISP standards and RFCs
2 |
3 | This repository is the official source of the specification and formats used in the MISP project.
4 |
5 | The formats are described to support other implementations which reuse the format and ensuring an interoperability
6 | with existing MISP software, other Threat Intelligence Platforms and security tools at large.
7 |
8 | All the formats can be freely reused by everyone.
9 |
10 | ## MISP Formats in use and implemented in multiple software
11 |
12 | * [misp-core-format](misp-core-format/raw.md.txt) ([markdown source](misp-core-format/raw.md)) which describes the core JSON format of MISP. Current Internet-Draft: [16](https://tools.ietf.org/html/draft-dulaunoy-misp-core-format)
13 | * [misp-taxonomy-format](misp-taxonomy-format/raw.md.txt) ([markdown source](misp-taxonomy-format/raw.md)) which describes the taxonomy JSON format of MISP. Current Internet-Draft: [10](https://tools.ietf.org/html/draft-dulaunoy-misp-taxonomy-format)
14 | * [misp-galaxy-format](misp-galaxy-format/raw.md.txt) which describes the [galaxy](https://github.com/MISP/misp-galaxy) template format used to expand the threat actor modelling of MISP. Current Internet-Draft: [06](https://datatracker.ietf.org/doc/draft-dulaunoy-misp-galaxy-format/)
15 | * [misp-object-template-format](misp-object-template-format/raw.md.txt) which describes the [object](https://github.com/MISP/misp-objects) template format to add combined and composite object to the MISP core format. Current Internet-Draft: [03](https://datatracker.ietf.org/doc/draft-dulaunoy-misp-object-template-format/)
16 |
17 | ## MISP Format in design phase and implemented in at least one software prototype
18 |
19 | * misp-modules-protocol which describes the [misp-modules](https://github.com/MISP/misp-modules) protocol used between MISP and misp-modules.
20 |
21 | ## MISP Format in design phase
22 |
23 | * misp-collaborative-voting-format which describes the collaborative voting and scoring format for the feeds providers.
24 |
25 | ## Sample files
26 |
27 | If you want to see how a threat intelligence can be easily expressed in MISP standard, the following resources might give you some ideas:
28 |
29 | * [CIRCL OSINT MISP Feed](https://www.circl.lu/doc/misp/feed-osint/)
30 |
31 | [Installing MISP](https://www.misp-project.org/download/) is also another option to see the MISP standards in action. The MISP standards are actively used in the MISP threat intelligence platform to support the complete chain from intelligence creation, sharing, distribution and synchronisation.
32 |
33 | ## Building the RFCs
34 |
35 | These RFCs use [mmark](https://mmark.nl/) to generate - get a release [from the Github Repo](https://github.com/mmarkdown/mmark) and make sure it's in your PATH.
36 |
37 | You'll also need `xml2rfc` - install using `sudo pip3 isntall xml2rfc`
38 |
39 | ```bash
40 | for directory in $(find . -type d -iname "misp*"); do;
41 | echo "Building $directory...";
42 | cd $directory;
43 | make;
44 | cd ..;
45 | done;
46 | ```
47 |
48 | # Contribution
49 |
50 | If you want to contribute to the MISP specifications, feel free to [open an issue](https://github.com/MISP/misp-rfc/issues).
51 |
--------------------------------------------------------------------------------
/misp-core-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
--------------------------------------------------------------------------------
/misp-galaxy-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
10 |
--------------------------------------------------------------------------------
/misp-galaxy-format/draft-dulaunoy-misp-galaxy-format-02.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 | MISP galaxy format
14 |
15 |
16 | Computer Incident Response Center Luxembourg
17 |
18 |
19 | 16, bd d'Avranches
20 | Luxembourg
21 | L-1611
22 | Luxembourg
23 |
24 |
25 | +352 247 88444
26 | alexandre.dulaunoy@circl.lu
27 |
28 |
29 |
30 |
31 | Computer Incident Response Center Luxembourg
32 |
33 |
34 | 16, bd d'Avranches
35 | Luxembourg
36 | L-1611
37 | Luxembourg
38 |
39 |
40 | +352 247 88444
41 | andras.iklody@circl.lu
42 |
43 |
44 |
45 |
46 | Computer Incident Response Center Luxembourg
47 |
48 |
49 | 16, bd d'Avranches
50 | Luxembourg
51 | L-1611
52 | Luxembourg
53 |
54 |
55 | +352 247 88444
56 | deborah.servili@circl.lu
57 |
58 |
59 |
60 |
61 |
62 | Security
63 |
64 |
65 |
66 |
67 | This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
68 |
69 |
70 |
71 |
72 |
73 |
74 |
75 |
76 |
77 | Sharing threat information became a fundamental requirements on the Internet, security and intelligence community at large. Threat information can include indicators of compromise, malicious file indicators, financial fraud indicators or even detailed information about a threat actor. Some of these informations, such as malware or threat actors are common to several security events. MISP galaxy is a public repository of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
78 |
79 | In the MISP galaxy context, clusters help analysts to give more informations about their cybersecurity events, indicators or threats. MISP galaxies can be used for classification, filtering, triggering actions or visualisation depending on their use in threat intelligence platforms such as MISP .
80 |
81 |
82 |
83 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
85 | document are to be interpreted as described in RFC 2119 .
86 |
87 |
88 |
89 |
90 |
91 | A cluster is composed of a value (MUST), a description (OPTIONAL) and metadata (OPTIONAL).
92 |
93 | Clusters are represented as a JSON dictionary.
94 |
95 |
96 |
97 | The MISP galaxy format uses the JSON format. Each galaxy is represented as a JSON object with meta information including the following fields: name, uuid, description, version, type, authors, source, values.
98 |
99 | name defines the name of the galaxy. The name is represented as a string and MUST be present. The uuid represents the Universally Unique IDentifier (UUID) of the object reference. The uuid MUST be preserved. For any updates or transfer of the same object reference. UUID version 4 is RECOMMENDED when assigning it to a new object reference and MUST be present. The description is represented as a string and MUST be present. The uuid is represented as a string and MUST be present. The version is represented as a decimal and MUST be present. The source is represented as a string and MUST be present. Authors are represented as an array containing one or more authors and MUST be present.
100 |
101 | Values are represented as an array containing one or more values and MUST be present. Values defines all values available in the galaxy.
102 |
103 |
104 |
105 |
106 | The values array contains one or more JSON objects which represent all the possible values in the galaxy. The JSON object contains four fields: value, description, uuid and meta.
107 | The value is represented as a string and MUST be present. The description is represented as a string and SHOULD be present. The meta or metadata is represented as a JSON list and SHOULD be present.
108 | The uuid represents the Universally Unique IDentifier (UUID) of the value reference. The uuid SHOULD can be present and MUST be preserved.
109 |
110 |
111 |
112 |
113 | Meta contains a list of custom defined JSON key value pairs. Users SHOULD reuse commonly used keys such as 'properties, complexity, effectiveness, country, possible_issues, colour, motive, impact, refs, synonyms, derivated_from, status, date, encryption, extensions, ransomnotes' wherever applicable.
114 |
115 | properties is used to provide clusters with additional properties. Properties are represented as an array containing one or more strings ans MAY be present.
116 |
117 | derivated_from, refs, synonyms SHALL be used to give further informations. refs is represented as an array containing one or more strings and SHALL be present. synonyms is represented as an array containing one or more strings and SHALL be present. derivated_from is represented as an array containing one or more strings and SHALL be present.
118 |
119 | date, status MAY be used to give time information about an cluster. date is represented as a string describing a time or period and SHALL be present. status is represented as a string describing the current status of the clusters. It MAY also describe a time or period and SHALL be present.
120 |
121 | colour fields MAY be used at predicates or values level to set a specify colour that MAY be used by the implementation. The colour field is described as an RGB colour fill in hexadecimal representation.
122 |
123 | complexity, effectiveness, impact, possible_issues MAY be used to give further information in preventive-measure galaxy. complexity is represented by an enumerated value from a fixed vocabulary and SHALL be present. effectiveness is represented by an enumerated value from a fixed vocabulary and SHALL be present. impact is represented by an enumerated value from a fixed vocabulary and SHALL be present. possible_issues is represented as a string and SHOULD be present.
124 |
125 | Example use of the complexity, effectiveness, impact, possible_issues fields in the preventive-measure galaxy:
126 |
127 |
128 |
129 | {
130 | "meta": {
131 | "refs": [
132 | "http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/AdminTips/Customization/DisableWindowsScriptingHostWSH.html"
133 | ],
134 | "complexity": "Low",
135 | "effectiveness": "Medium",
136 | "impact": "Medium",
137 | "type": [
138 | "GPO"
139 | ],
140 | "possible_issues": "Administrative VBS scripts on Workstations"
141 | },
142 | "value": "Disable WSH",
143 | "description": "Disable Windows Script Host",
144 | "uuid": "e6df1619-f8b3-476c-b5cf-22b4c9e9dd7f"
145 | }
146 |
147 | country, motive MAY be used to give further information in threat-actor galaxy. country is represented as a string and SHOULD be present. motive is represented as a string and SHOULD be present.
148 |
149 | Example use of the country, motive fields in the threat-actor galaxy:
150 |
151 |
152 |
153 | {
154 | "meta": {
155 | "country": "CN",
156 | "synonyms": [
157 | "APT14",
158 | "APT 14",
159 | "QAZTeam",
160 | "ALUMINUM"
161 | ],
162 | "refs": [
163 | "http://www.crowdstrike.com/blog/whois-anchor-panda/"
164 | ],
165 | "motive": "Espionage"
166 | },
167 | "value": "Anchor Panda",
168 | "description": "PLA Navy",
169 | "uuid": "c82c904f-b3b4-40a2-bf0d-008912953104"
170 | }
171 |
172 | encryption, extensions, ransomnotes MAY be used to give further information in ransomware galaxy. encryption is represented as a string and SHALL be present. extensions is represented as an array containing one or more strings and SHALL be present. ransomnotes is represented as an array containing one or more strings ans SHALL be present.
173 |
174 | Example use of the encryption, extensions, ransomnotes fields in the ransomware galaxy:
175 |
176 |
177 |
178 | {
179 | "meta": {
180 | "refs": [
181 | "https://www.bleepingcomputer.com/news/security/revenge-ransomware-a-cryptomix-variant-being-distributed-by-rig-exploit-kit/",
182 | "https://id-ransomware.blogspot.co.il/2017/03/revenge-ransomware.html"
183 | ],
184 | "ransomnotes": [
185 | "https://2.bp.blogspot.com/-KkPVDxjy8tk/WM7LtYHmuAI/AAAAAAAAEUw/kDJghaq-j1AZuqjzqk2Fkxpp4yr9Yeb5wCLcB/s1600/revenge-note-2.jpg",
186 | "===ENGLISH=== All of your files were encrypted using REVENGE Ransomware. The action required to restore the files. Your files are not lost, they can be returned to their normal state by decoding them. The only way to do this is to get the software and your personal decryption key. Using any other software that claims to be able to recover your files will result in corrupted or destroyed files. You can purchase the software and the decryption key by sending us an email with your ID. And we send instructions for payment. After payment, you receive the software to return all files. For proof, we can decrypt one file for free. Attach it to an e-mail.",
187 | "# !!!HELP_FILE!!! #.txt"
188 | ],
189 | "encryption": "AES-256 + RSA-1024",
190 | "extensions": [
191 | ".REVENGE"
192 | ],
193 | "date": "March 2017"
194 | },
195 | "description": "This is most likely to affect English speaking users, since the note is written in English. English is understood worldwide, thus anyone can be harmed. The hacker spread the virus using email spam, fake updates, and harmful attachments. All your files are compromised including music, MS Office, Open Office, pictures, videos, shared online files etc.. CryptoMix / CryptFile2 Variant",
196 | "value": "Revenge Ransomware",
197 | "uuid": "987d36d5-6ba8-484d-9e0b-7324cc886b0e"
198 | }
199 |
200 | source-uuid, target-uuid SHALL be used to describe relationships. source-uuid and target-uuid represent the Universally Unique IDentifier (UUID) of the value reference. source-uuid and target-uuid MUST be preserved.
201 |
202 | Example use of the source-uuid, target-uuid fields in the mitre-enterprise-attack-relationship galaxy:
203 |
204 |
205 |
206 | {
207 | "meta": {
208 | "source-uuid": "222fbd21-fc4f-4b7e-9f85-0e6e3a76c33f",
209 | "target-uuid": "2f1a9fd0-3b7c-4d77-a358-78db13adbe78"
210 | },
211 | "uuid": "cfc7da70-d7c5-4508-8f50-1c3107269633",
212 | "value": "menuPass (G0045) uses EvilGrab (S0152)"
213 | }
214 |
215 |
216 |
217 |
218 |
219 | The authors wish to thank all the MISP community who are supporting the creation
220 | of open standards in threat intelligence sharing.
221 |
222 |
223 |
224 |
225 |
226 |
227 |
228 |
229 |
230 |
231 |
232 |
233 |
234 | MISP Galaxy -
235 |
236 |
237 |
238 |
239 |
240 |
241 | MISP Project - Malware Information Sharing Platform and Threat Sharing
242 |
243 |
244 |
245 |
246 |
247 |
248 |
249 |
250 |
--------------------------------------------------------------------------------
/misp-galaxy-format/raw.md:
--------------------------------------------------------------------------------
1 | %%%
2 | Title = "MISP galaxy format"
3 | abbrev = "MISP galaxy format"
4 | category = "info"
5 | docName = "draft-dulaunoy-misp-galaxy-format"
6 | ipr= "trust200902"
7 | area = "Security"
8 | submissiontype = "independent"
9 |
10 |
11 | [seriesInfo]
12 | name = "Internet-Draft"
13 | value = "draft-08"
14 | stream = "independent"
15 | status = "informational"
16 |
17 | [[author]]
18 | initials="A."
19 | surname="Dulaunoy"
20 | fullname="Alexandre Dulaunoy"
21 | abbrev="CIRCL"
22 | organization = "Computer Incident Response Center Luxembourg"
23 | [author.address]
24 | email = "alexandre.dulaunoy@circl.lu"
25 | phone = "+352 247 88444"
26 | [author.address.postal]
27 | street = "122, rue Adolphe Fischer"
28 | city = "Luxembourg"
29 | code = "L-1521"
30 | country = "Luxembourg"
31 | [[author]]
32 | initials="A."
33 | surname="Iklody"
34 | fullname="Andras Iklody"
35 | abbrev="CIRCL"
36 | organization = "Computer Incident Response Center Luxembourg"
37 | [author.address]
38 | email = "andras.iklody@circl.lu"
39 | phone = "+352 247 88444"
40 | [author.address.postal]
41 | street = "122, rue Adolphe Fischer"
42 | city = "Luxembourg"
43 | code = "L-1521"
44 | country = "Luxembourg"
45 | [[author]]
46 | initials="D."
47 | surname="Servili"
48 | fullname="Deborah Servili"
49 | abbrev="CIRCL"
50 | organization = "Computer Incident Response Center Luxembourg"
51 | [author.address]
52 | email = "deborah.servili@circl.lu"
53 | phone = "+352 247 88444"
54 | [author.address.postal]
55 | street = "122, rue Adolphe Fischer"
56 | city = "Luxembourg"
57 | code = "L-1521"
58 | country = "Luxembourg"
59 | %%%
60 |
61 |
62 | .# Abstract
63 |
64 | This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [@?MISP-G] [@?MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
65 |
66 | {mainmatter}
67 |
68 | # Introduction
69 |
70 | Sharing threat information became a fundamental requirements on the Internet, security and intelligence community at large. Threat information can include indicators of compromise, malicious file indicators, financial fraud indicators or even detailed information about a threat actor. Some of these informations, such as malware or threat actors are common to several security events. MISP galaxy is a public repository [@?MISP-G] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
71 |
72 | In the MISP galaxy context, clusters help analysts to give more informations about their cybersecurity events, indicators or threats. MISP galaxies can be used for classification, filtering, triggering actions or visualisation depending on their use in threat intelligence platforms such as MISP [@?MISP-P].
73 |
74 | ## Conventions and Terminology
75 |
76 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
77 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
78 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
79 |
80 | # Format
81 |
82 | A cluster is composed of a value (**MUST**), a uuid (**MUST**), a description (**MUST**) and metadata (**OPTIONAL**).
83 |
84 | Clusters are represented as a JSON [@!RFC8259] dictionary.
85 |
86 | ## Overview
87 |
88 | The MISP galaxy format uses the JSON [@!RFC8259] format. Each galaxy is represented as a JSON object with meta information including the following fields: name, uuid, description, version, type, authors, source, values, category.
89 |
90 | name defines the name of the galaxy. The name is represented as a string and **MUST** be present. The uuid represents the Universally Unique IDentifier (UUID) [@!RFC4122] of the object reference. The uuid **MUST** be preserved. For any updates or transfer of the same object reference. UUID version 4 is **RECOMMENDED** when assigning it to a new object reference and **MUST** be present. The description is represented as a string and **MUST** be present. The uuid is represented as a string and **MUST** be present. The version is represented as a decimal and **MUST** be present. The type is represented as a string and **MUST** be present and **MUST** match the name of the galaxy file. The source is represented as a string and **MUST** be present. Authors are represented as an array containing one or more authors and **MUST** be present. The category is represented as a string and **MUST** be present and describes the overall category of the galaxy such as tool or actor.
91 |
92 | Values are represented as an array containing one or more values and **MUST** be present. Values defines all values available in the galaxy.
93 |
94 | ## values
95 |
96 | The values array contains one or more JSON objects which represent all the possible values in the galaxy. The JSON object contains four fields: value, description, uuid and meta.
97 | The value is represented as a string and **MUST** be present. The description is represented as a string and **SHOULD** be present. The meta or metadata is represented as a JSON list and **SHOULD** be present.
98 | The uuid represents the Universally Unique IDentifier (UUID) [@!RFC4122] of the value reference. The uuid **MUST** be present and **MUST** be preserved.
99 |
100 | ## related
101 |
102 | Related contains a list of JSON key value pairs which describe the related values in this galaxy cluster or to other galaxy clusters. The JSON object contains three fields, dest-uuid, type and tags. The dest-uuid represents the target UUID which encompasses a relation of some type. The dest-uuid is represented as a string and **MUST** be present. The type is represented as a string and **MUST** be present and **SHOULD** be selected from the relationship types available in MISP objects [@?MISP-R]. The tags is a list of string which labels the related relationship such as the level of similarities, level of certainty, trust or confidence in the relationship, false-positive. A tag is represented in machine tag format which is a string an **SHOULD** be present.
103 |
104 | ~~~~
105 | "related": [ {
106 | "dest-uuid": "f873db71-3d53-41d5-b141-530675ade27a",
107 | "type": "similar",
108 | "tags": ["estimative-language:likelihood-probability=\"very-likely\""]
109 | } ]
110 | ~~~~
111 |
112 | ## meta
113 |
114 | Meta contains a list of custom defined JSON key value pairs. Users **SHOULD** reuse commonly used keys such as complexity, effectiveness, country, external_id, possible_issues, colour, motive, impact, refs, synonyms, status, date, encryption, extensions, ransomnotes, ransomnotes-filenames, ransomnotes-refs, suspected-victims, suspected-state-sponsor, type-of-incident, target-category, cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident, cfr-target-category, suspected-victims, suspected-state-sponsor, attribution-confidence, payment-method, price, spoken-language, official-refs wherever applicable. Additional meta field **MAY** be added without the need to be referenced or registered in advance.
115 |
116 | refs, synonyms, official-refs **SHALL** be used to give further informations. refs is represented as an array containing one or more strings and **SHALL** be present. synonyms is represented as an array containing one or more strings and **SHALL** be present. official-refs is represented as an array containing one or more strings and **MAY** be present.
117 |
118 | date, status **MAY** be used to give time information about an cluster. date is represented as a string describing a time or period and **SHALL** be present. status is represented as a string describing the current status of the clusters. It **MAY** also describe a time or period and **SHALL** be present.
119 |
120 | colour fields **MAY** be used at predicates or values level to set a specify colour that **MAY** be used by the implementation. The colour field is described as an RGB colour fill in hexadecimal representation.
121 |
122 | complexity, effectiveness, impact, possible_issues **MAY** be used to give further information in preventive-measure galaxy. complexity is represented by an enumerated value from a fixed vocabulary and **SHALL** be present. effectiveness is represented by an enumerated value from a fixed vocabulary and **SHALL** be present. impact is represented by an enumerated value from a fixed vocabulary and **SHALL** be present. possible_issues is represented as a string and **SHOULD** be present.
123 |
124 | Example use of the complexity, effectiveness, impact, possible_issues fields in the preventive-measure galaxy:
125 |
126 | ~~~~
127 | {
128 | "meta": {
129 | "refs": [
130 | "http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/AdminTips/Customization/DisableWindowsScriptingHostWSH.html"
131 | ],
132 | "complexity": "Low",
133 | "effectiveness": "Medium",
134 | "impact": "Medium",
135 | "type": [
136 | "GPO"
137 | ],
138 | "possible_issues": "Administrative VBS scripts on Workstations"
139 | },
140 | "value": "Disable WSH",
141 | "description": "Disable Windows Script Host",
142 | "uuid": "e6df1619-f8b3-476c-b5cf-22b4c9e9dd7f"
143 | }
144 | ~~~~
145 |
146 | country, motive, spoken-language **MAY** be used to give further information in threat-actor galaxy. country is represented as a string and **SHOULD** be present. motive is represented as a string and **SHOULD** be present. spoken-language is represented as an array containing one or more strings describing a language using ISO 639-2 code and **SHALL** be present.
147 |
148 | Example use of the country, motive fields in the threat-actor galaxy:
149 |
150 | ~~~~
151 | {
152 | "meta": {
153 | "country": "CN",
154 | "synonyms": [
155 | "APT14",
156 | "APT 14",
157 | "QAZTeam",
158 | "ALUMINUM"
159 | ],
160 | "refs": [
161 | "http://www.crowdstrike.com/blog/whois-anchor-panda/"
162 | ],
163 | "motive": "Espionage",
164 | "attribution-confidence": 50
165 | },
166 | "value": "Anchor Panda",
167 | "description": "PLA Navy",
168 | "uuid": "c82c904f-b3b4-40a2-bf0d-008912953104"
169 | }
170 | ~~~~
171 |
172 | encryption, extensions, ransomnotes, ransomnotes-filenames, ransomnotes-refs, payment-method, price **MAY** be used to give further information in ransomware galaxy. encryption is represented as a string and **SHALL** be present. extensions is represented as an array containing one or more strings and **SHALL** be present. ransomnotes is represented as an array containing one or more strings ans **SHALL** be present. ransomnotes-filenames is represented as an array containing one or more strings ans **SHALL** be present. ransomnotes-refs is represented as an array containing one or more strings ans **SHALL** be present. payment-method is represented as a string and **SHALL** be present. price is represented as a string and **SHALL** be present.
173 |
174 | Example use of the encryption, extensions, ransomnotes fields in the ransomware galaxy:
175 |
176 | ~~~~
177 | {
178 | "description": "Similar to Samas and BitPaymer, Ryuk is specifically used to target enterprise environments. Code comparison between versions of Ryuk and Hermes ransomware indicates that Ryuk was derived from the Hermes source code and has been under steady development since its release. Hermes is commodity ransomware that has been observed for sale on forums and used by multiple threat actors. However, Ryuk is only used by GRIM SPIDER and, unlike Hermes, Ryuk has only been used to target enterprise environments. Since Ryuk’s appearance in August, the threat actors operating it have netted over 705.80 BTC across 52 transactions for a total current value of $3,701,893.98 USD.",
179 | "meta": {
180 | "ransomnotes-filenames": [
181 | "RyukReadMe.txt"
182 | ],
183 | "ransomnotes-refs": [
184 | "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig3.png",
185 | "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig4.png"
186 | ],
187 | "refs": [
188 | "https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/"
189 | ]
190 | },
191 | "uuid": "f9464c80-b776-4f37-8682-ffde0cf8f718",
192 | "value": "Ryuk ransomware"
193 | }
194 | ~~~~
195 |
196 | Example use of the payment-method, price fields in the ransomware galaxy:
197 | ~~~~
198 | {
199 | "description": "This is most likely to affect English speaking users, since the note is written in English. English is understood worldwide, thus anyone can be harmed. The hacker spread the virus using email spam, fake updates, and harmful attachments. All your files are compromised including music, MS Office, Open Office, pictures, videos, shared online files etc..",
200 | "meta": {
201 | "date": "March 2017",
202 | "encryption": "AES-128",
203 | "extensions": [
204 | ".enc"
205 | ],
206 | "payment-method": "Bitcoin",
207 | "price": "0.1",
208 | "ransomnotes": [
209 | "Blocked Your computer has been blocked All your files are encrypted. To access your PC, you need to send to Bitcoin at the address below loading Step 1: Go to xxxxs : //wvw.coinbase.com/ siqnup Step 2: Create an account and follow the instructions Step 3: Go to the \"Buy Bitcoins\" section and then buy Bitcoin Step 4: Go to the \"Send\" section, enter the address above and the amount (0.1 Bitcoin) Step 5: Click on the button below to verify the payment, your files will be decrypted and the virus will disappear 'Check' If you try to bypass the lock, all files will be published on the Internet, as well as your login for all sites."
210 | ],
211 | "refs": [
212 | "https://id-ransomware.blogspot.co.il/2017/03/cryptomeister-ransomware.html"
213 | ]
214 | },
215 | "uuid": "4c76c845-c5eb-472c-93a1-4178f86c319b",
216 | "value": "CryptoMeister Ransomware"
217 | }
218 | ~~~~
219 |
220 |
221 | source-uuid, target-uuid **SHALL** be used to describe relationships. source-uuid and target-uuid represent the Universally Unique IDentifier (UUID) [@!RFC4122] of the value reference. source-uuid and target-uuid **MUST** be preserved.
222 |
223 | Example use of the source-uuid, target-uuid fields in the mitre-enterprise-attack-relationship galaxy:
224 | ~~~~
225 | {
226 | "meta": {
227 | "source-uuid": "222fbd21-fc4f-4b7e-9f85-0e6e3a76c33f",
228 | "target-uuid": "2f1a9fd0-3b7c-4d77-a358-78db13adbe78"
229 | },
230 | "uuid": "cfc7da70-d7c5-4508-8f50-1c3107269633",
231 | "value": "menuPass (G0045) uses EvilGrab (S0152)"
232 | }
233 | ~~~~
234 |
235 | cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident and cfr-target-category **MAY** be used to report information gathered from CFR's (Council on Foreign Relations) [@?CFR] Cyber Operations Tracker. cfr-suspected-victims is represented as an array containing one or more strings and **SHALL** be present. cfr-suspected-state-sponsor is represented as a string and **SHALL** be present. cfr-type-of-incident is represented as a string or an array and **SHALL** be present. **RECOMMENDED** but not exhaustive list of possible values for cfr-type-of-incident includes "Espionage", "Denial of service", "Sabotage". cfr-target-category is represented as an array containing one or more strings ans **SHALL** be present. **RECOMMENDED** but not exhaustive list of possible values for cfr-target-category includes "Private sector", "Government", "Civil society", "Military".
236 |
237 | Example use of the cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident, cfr-target-category fields in the threat-actor galaxy:
238 |
239 | ~~~~
240 | {
241 | "meta": {
242 | "country": "CN",
243 | "refs": [
244 | "https://www.fireeye.com/blog/threat-research/2015/12/the_eps_awakens.html",
245 | "https://www.cfr.org/interactive/cyber-operations/apt-16"
246 | ],
247 | "cfr-suspected-victims": [
248 | "Japan",
249 | "Taiwan"
250 | ],
251 | "cfr-suspected-state-sponsor": "China",
252 | "cfr-type-of-incident": "Espionage",
253 | "cfr-target-category": [
254 | "Private sector"
255 | ],
256 | "attribution-confidence": 50
257 | },
258 | "value": "APT 16",
259 | "uuid": "1f73e14f-b882-4032-a565-26dc653b0daf"
260 | },
261 | ~~~~
262 |
263 | attribution-confidence **MAY** be used to indicate the confidence about an attribution given by country or cfr-suspected-state-sponsor. attribution-confidence is represented on a scale from 0 to 100, where 50 means "no information", the values under 50 mean "probably not, almost certainly not to impossibility", the values above 50 means "from probable, almost certain to certainty" and **SHALL** be present if country or cfr-suspected-state-sponsor are present.
264 |
265 | ~~~~
266 | Impossibility no information Certainty
267 | +
268 | |
269 | +-------------------+------------------>
270 |
271 | 0 50 100
272 | ~~~~
273 |
274 | # JSON Schema
275 |
276 | The JSON Schema [@?JSON-SCHEMA] below defines the overall MISP galaxy formats. The main format is the MISP galaxy format used for the clusters.
277 |
278 | ## MISP galaxy format - galaxy
279 |
280 | ~~~~
281 | {
282 | "$schema": "http://json-schema.org/schema#",
283 | "title": "Validator for misp-galaxies - Galaxies",
284 | "id": "https://www.github.com/MISP/misp-galaxies/schema_galaxies.json",
285 | "type": "object",
286 | "additionalProperties": false,
287 | "properties": {
288 | "description": {
289 | "type": "string"
290 | },
291 | "type": {
292 | "type": "string"
293 | },
294 | "version": {
295 | "type": "integer"
296 | },
297 | "name": {
298 | "type": "string"
299 | },
300 | "icon": {
301 | "type": "string"
302 | },
303 | "uuid": {
304 | "type": "string"
305 | },
306 | "namespace": {
307 | "type": "string"
308 | },
309 | "kill_chain_order": {
310 | "type": "object"
311 | }
312 | },
313 | "required": [
314 | "description",
315 | "type",
316 | "version",
317 | "name",
318 | "uuid"
319 | ]
320 | }
321 | ~~~~
322 |
323 | ## MISP galaxy format - clusters
324 |
325 | ~~~~
326 | {
327 | "$schema": "http://json-schema.org/schema#",
328 | "title": "Validator for misp-galaxies - Clusters",
329 | "id": "https://www.github.com/MISP/misp-galaxies/schema_clusters.json",
330 | "type": "object",
331 | "additionalProperties": false,
332 | "properties": {
333 | "description": {
334 | "type": "string"
335 | },
336 | "type": {
337 | "type": "string"
338 | },
339 | "version": {
340 | "type": "integer"
341 | },
342 | "name": {
343 | "type": "string"
344 | },
345 | "uuid": {
346 | "type": "string"
347 | },
348 | "source": {
349 | "type": "string"
350 | },
351 | "category": {
352 | "type": "string
353 | },
354 | "values": {
355 | "type": "array",
356 | "uniqueItems": true,
357 | "items": {
358 | "type": "object",
359 | "additionalProperties": false,
360 | "properties": {
361 | "description": {
362 | "type": "string"
363 | },
364 | "value": {
365 | "type": "string"
366 | },
367 | "uuid": {
368 | "type": "string"
369 | },
370 | "related": {
371 | "type": "array",
372 | "additionalProperties": false,
373 | "items": {
374 | "type": "object"
375 | },
376 | "properties": {
377 | "dest-uuid": {
378 | "type": "string"
379 | },
380 | "type": {
381 | "type": "string"
382 | },
383 | "tags": {
384 | "type": "array",
385 | "uniqueItems": true,
386 | "items": {
387 | "type": "string"
388 | }
389 | }
390 | }
391 | },
392 | "meta": {
393 | "type": "object",
394 | "additionalProperties": true,
395 | "properties": {
396 | "type": {
397 | "type": "array",
398 | "uniqueItems": true,
399 | "items": {
400 | "type": "string"
401 | }
402 | },
403 | "complexity": {
404 | "type": "string"
405 | },
406 | "effectiveness": {
407 | "type": "string"
408 | },
409 | "country": {
410 | "type": "string"
411 | },
412 | "possible_issues": {
413 | "type": "string"
414 | },
415 | "colour": {
416 | "type": "string"
417 | },
418 | "motive": {
419 | "type": "string"
420 | },
421 | "impact": {
422 | "type": "string"
423 | },
424 | "refs": {
425 | "type": "array",
426 | "uniqueItems": true,
427 | "items": {
428 | "type": "string"
429 | }
430 | },
431 | "synonyms": {
432 | "type": "array",
433 | "uniqueItems": true,
434 | "items": {
435 | "type": "string"
436 | }
437 | },
438 | "status": {
439 | "type": "string"
440 | },
441 | "date": {
442 | "type": "string"
443 | },
444 | "encryption": {
445 | "type": "string"
446 | },
447 | "extensions": {
448 | "type": "array",
449 | "uniqueItems": true,
450 | "items": {
451 | "type": "string"
452 | }
453 | },
454 | "ransomnotes": {
455 | "type": "array",
456 | "uniqueItems": true,
457 | "items": {
458 | "type": "string"
459 | }
460 | }
461 | }
462 | }
463 | },
464 | "required": [
465 | "value"
466 | ]
467 | }
468 | },
469 | "authors": {
470 | "type": "array",
471 | "uniqueItems": true,
472 | "items": {
473 | "type": "string"
474 | }
475 | }
476 | },
477 | "required": [
478 | "description",
479 | "type",
480 | "version",
481 | "name",
482 | "uuid",
483 | "values",
484 | "authors",
485 | "source",
486 | "category
487 | ]
488 | }
489 | ~~~~
490 |
491 | # Acknowledgements
492 |
493 | The authors wish to thank all the MISP community who are supporting the creation
494 | of open standards in threat intelligence sharing.
495 |
496 |
497 |
498 | MISP Project - Malware Information Sharing Platform and Threat Sharing
499 |
500 |
501 |
502 |
503 |
504 |
505 |
506 | MISP Taxonomies - shared and common vocabularies of tags
507 |
508 |
509 |
510 |
511 |
512 |
513 |
514 | MISP Galaxy - Public Repository
515 |
516 |
517 |
518 |
519 |
520 |
521 |
522 | MISP Galaxy - Documentation of the Public Repository
523 |
524 |
525 |
526 |
527 |
528 |
529 |
530 |
531 | MISP Object Relationship Types - common vocabulary of relationships
532 |
533 |
534 |
535 |
536 |
537 |
538 |
539 | JSON Schema: A Media Type for Describing JSON Documents
540 |
541 |
542 |
543 |
544 |
545 |
546 |
547 | Cyber Operations Tracker - Council on Foreign Relations
548 |
549 |
550 |
551 |
552 |
553 | {backmatter}
554 |
--------------------------------------------------------------------------------
/misp-galaxy-format/raw.md.txt:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Network Working Group A. Dulaunoy
6 | Internet-Draft A. Iklody
7 | Intended status: Informational D. Servili
8 | Expires: 26 June 2024 CIRCL
9 | 24 December 2023
10 |
11 |
12 | MISP galaxy format
13 | draft-08
14 |
15 | Abstract
16 |
17 | This document describes the MISP galaxy format which describes a
18 | simple JSON format to represent galaxies and clusters that can be
19 | attached to MISP events or attributes. A public directory of MISP
20 | galaxies is available and relies on the MISP galaxy format. MISP
21 | galaxies are used to add further informations on a MISP event. MISP
22 | galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware,
23 | threats actors and various other collections of data that can be used
24 | to mark, classify or label data in threat information sharing.
25 |
26 | Status of This Memo
27 |
28 | This Internet-Draft is submitted in full conformance with the
29 | provisions of BCP 78 and BCP 79.
30 |
31 | Internet-Drafts are working documents of the Internet Engineering
32 | Task Force (IETF). Note that other groups may also distribute
33 | working documents as Internet-Drafts. The list of current Internet-
34 | Drafts is at https://datatracker.ietf.org/drafts/current/.
35 |
36 | Internet-Drafts are draft documents valid for a maximum of six months
37 | and may be updated, replaced, or obsoleted by other documents at any
38 | time. It is inappropriate to use Internet-Drafts as reference
39 | material or to cite them other than as "work in progress."
40 |
41 | This Internet-Draft will expire on 26 June 2024.
42 |
43 | Copyright Notice
44 |
45 | Copyright (c) 2023 IETF Trust and the persons identified as the
46 | document authors. All rights reserved.
47 |
48 | This document is subject to BCP 78 and the IETF Trust's Legal
49 | Provisions Relating to IETF Documents (https://trustee.ietf.org/
50 | license-info) in effect on the date of publication of this document.
51 | Please review these documents carefully, as they describe your rights
52 | and restrictions with respect to this document.
53 |
54 |
55 |
56 | Dulaunoy, et al. Expires 26 June 2024 [Page 1]
57 |
58 | Internet-Draft MISP galaxy format December 2023
59 |
60 |
61 | Table of Contents
62 |
63 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 | 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
65 | 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 | 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
67 | 2.2. values . . . . . . . . . . . . . . . . . . . . . . . . . 3
68 | 2.3. related . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 | 2.4. meta . . . . . . . . . . . . . . . . . . . . . . . . . . 4
70 | 3. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . . . 9
71 | 3.1. MISP galaxy format - galaxy . . . . . . . . . . . . . . . 9
72 | 3.2. MISP galaxy format - clusters . . . . . . . . . . . . . . 10
73 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
74 | 5. Normative References . . . . . . . . . . . . . . . . . . . . 14
75 | 6. Informative References . . . . . . . . . . . . . . . . . . . 14
76 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
77 |
78 | 1. Introduction
79 |
80 | Sharing threat information became a fundamental requirements on the
81 | Internet, security and intelligence community at large. Threat
82 | information can include indicators of compromise, malicious file
83 | indicators, financial fraud indicators or even detailed information
84 | about a threat actor. Some of these informations, such as malware or
85 | threat actors are common to several security events. MISP galaxy is
86 | a public repository [MISP-G] of known malware, threats actors and
87 | various other collections of data that can be used to mark, classify
88 | or label data in threat information sharing.
89 |
90 | In the MISP galaxy context, clusters help analysts to give more
91 | informations about their cybersecurity events, indicators or threats.
92 | MISP galaxies can be used for classification, filtering, triggering
93 | actions or visualisation depending on their use in threat
94 | intelligence platforms such as MISP [MISP-P].
95 |
96 | 1.1. Conventions and Terminology
97 |
98 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
99 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
100 | document are to be interpreted as described in RFC 2119 [RFC2119].
101 |
102 | 2. Format
103 |
104 | A cluster is composed of a value (MUST), a description (OPTIONAL) and
105 | metadata (OPTIONAL).
106 |
107 | Clusters are represented as a JSON [RFC8259] dictionary.
108 |
109 |
110 |
111 |
112 | Dulaunoy, et al. Expires 26 June 2024 [Page 2]
113 |
114 | Internet-Draft MISP galaxy format December 2023
115 |
116 |
117 | 2.1. Overview
118 |
119 | The MISP galaxy format uses the JSON [RFC8259] format. Each galaxy
120 | is represented as a JSON object with meta information including the
121 | following fields: name, uuid, description, version, type, authors,
122 | source, values, category.
123 |
124 | name defines the name of the galaxy. The name is represented as a
125 | string and MUST be present. The uuid represents the Universally
126 | Unique IDentifier (UUID) [RFC4122] of the object reference. The uuid
127 | MUST be preserved. For any updates or transfer of the same object
128 | reference. UUID version 4 is RECOMMENDED when assigning it to a new
129 | object reference and MUST be present. The description is represented
130 | as a string and MUST be present. The uuid is represented as a string
131 | and MUST be present. The version is represented as a decimal and
132 | MUST be present. The type is represented as a string and MUST be
133 | present and MUST match the name of the galaxy file. The source is
134 | represented as a string and MUST be present. Authors are represented
135 | as an array containing one or more authors and MUST be present. The
136 | category is represented as a string and MUST be present and describes
137 | the overall category of the galaxy such as tool or actor.
138 |
139 | Values are represented as an array containing one or more values and
140 | MUST be present. Values defines all values available in the galaxy.
141 |
142 | 2.2. values
143 |
144 | The values array contains one or more JSON objects which represent
145 | all the possible values in the galaxy. The JSON object contains four
146 | fields: value, description, uuid and meta. The value is represented
147 | as a string and MUST be present. The description is represented as a
148 | string and SHOULD be present. The meta or metadata is represented as
149 | a JSON list and SHOULD be present. The uuid represents the
150 | Universally Unique IDentifier (UUID) [RFC4122] of the value
151 | reference. The uuid SHOULD can be present and MUST be preserved.
152 |
153 | 2.3. related
154 |
155 | Related contains a list of JSON key value pairs which describe the
156 | related values in this galaxy cluster or to other galaxy clusters.
157 | The JSON object contains three fields, dest-uuid, type and tags. The
158 | dest-uuid represents the target UUID which encompasses a relation of
159 | some type. The dest-uuid is represented as a string and MUST be
160 | present. The type is represented as a string and MUST be present and
161 | SHOULD be selected from the relationship types available in MISP
162 | objects [MISP-R]. The tags is a list of string which labels the
163 | related relationship such as the level of similarities, level of
164 | certainty, trust or confidence in the relationship, false-positive.
165 |
166 |
167 |
168 | Dulaunoy, et al. Expires 26 June 2024 [Page 3]
169 |
170 | Internet-Draft MISP galaxy format December 2023
171 |
172 |
173 | A tag is represented in machine tag format which is a string an
174 | SHOULD be present.
175 |
176 | "related": [ {
177 | "dest-uuid": "f873db71-3d53-41d5-b141-530675ade27a",
178 | "type": "similar",
179 | "tags": ["estimative-language:likelihood-probability=\"very-likely\""]
180 | } ]
181 |
182 | 2.4. meta
183 |
184 | Meta contains a list of custom defined JSON key value pairs. Users
185 | SHOULD reuse commonly used keys such as complexity, effectiveness,
186 | country, external_id, possible_issues, colour, motive, impact, refs,
187 | synonyms, status, date, encryption, extensions, ransomnotes,
188 | ransomnotes-filenames, ransomnotes-refs, suspected-victims,
189 | suspected-state-sponsor, type-of-incident, target-category, cfr-
190 | suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-incident,
191 | cfr-target-category, suspected-victims, suspected-state-sponsor,
192 | attribution-confidence, payment-method, price, spoken-language,
193 | official-refs wherever applicable. Additional meta field MAY be
194 | added without the need to be referenced or registered in advance.
195 |
196 | refs, synonyms, official-refs SHALL be used to give further
197 | informations. refs is represented as an array containing one or more
198 | strings and SHALL be present. synonyms is represented as an array
199 | containing one or more strings and SHALL be present. official-refs is
200 | represented as an array containing one or more strings and SHALL be
201 | present.
202 |
203 | date, status MAY be used to give time information about an cluster.
204 | date is represented as a string describing a time or period and SHALL
205 | be present. status is represented as a string describing the current
206 | status of the clusters. It MAY also describe a time or period and
207 | SHALL be present.
208 |
209 | colour fields MAY be used at predicates or values level to set a
210 | specify colour that MAY be used by the implementation. The colour
211 | field is described as an RGB colour fill in hexadecimal
212 | representation.
213 |
214 | complexity, effectiveness, impact, possible_issues MAY be used to
215 | give further information in preventive-measure galaxy. complexity is
216 | represented by an enumerated value from a fixed vocabulary and SHALL
217 | be present. effectiveness is represented by an enumerated value from
218 | a fixed vocabulary and SHALL be present. impact is represented by an
219 | enumerated value from a fixed vocabulary and SHALL be present.
220 | possible_issues is represented as a string and SHOULD be present.
221 |
222 |
223 |
224 | Dulaunoy, et al. Expires 26 June 2024 [Page 4]
225 |
226 | Internet-Draft MISP galaxy format December 2023
227 |
228 |
229 | Example use of the complexity, effectiveness, impact, possible_issues
230 | fields in the preventive-measure galaxy:
231 |
232 | {
233 | "meta": {
234 | "refs": [
235 | "http://www.windowsnetworking.com/kbase/WindowsTips/WindowsXP/AdminTips/Customization/DisableWindowsScriptingHostWSH.html"
236 | ],
237 | "complexity": "Low",
238 | "effectiveness": "Medium",
239 | "impact": "Medium",
240 | "type": [
241 | "GPO"
242 | ],
243 | "possible_issues": "Administrative VBS scripts on Workstations"
244 | },
245 | "value": "Disable WSH",
246 | "description": "Disable Windows Script Host",
247 | "uuid": "e6df1619-f8b3-476c-b5cf-22b4c9e9dd7f"
248 | }
249 |
250 | country, motive, spoken-language MAY be used to give further
251 | information in threat-actor galaxy. country is represented as a
252 | string and SHOULD be present. motive is represented as a string and
253 | SHOULD be present. spoken-language is represented as an array
254 | containing one or more strings describing a language using ISO 639-2
255 | code and SHALL be present.
256 |
257 | Example use of the country, motive fields in the threat-actor galaxy:
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 | Dulaunoy, et al. Expires 26 June 2024 [Page 5]
281 |
282 | Internet-Draft MISP galaxy format December 2023
283 |
284 |
285 | {
286 | "meta": {
287 | "country": "CN",
288 | "synonyms": [
289 | "APT14",
290 | "APT 14",
291 | "QAZTeam",
292 | "ALUMINUM"
293 | ],
294 | "refs": [
295 | "http://www.crowdstrike.com/blog/whois-anchor-panda/"
296 | ],
297 | "motive": "Espionage",
298 | "attribution-confidence": 50
299 | },
300 | "value": "Anchor Panda",
301 | "description": "PLA Navy",
302 | "uuid": "c82c904f-b3b4-40a2-bf0d-008912953104"
303 | }
304 |
305 | encryption, extensions, ransomnotes, ransomnotes-filenames,
306 | ransomnotes-refs, payment-method, price MAY be used to give further
307 | information in ransomware galaxy. encryption is represented as a
308 | string and SHALL be present. extensions is represented as an array
309 | containing one or more strings and SHALL be present. ransomnotes is
310 | represented as an array containing one or more strings ans SHALL be
311 | present. ransomnotes-filenames is represented as an array containing
312 | one or more strings ans SHALL be present. ransomnotes-refs is
313 | represented as an array containing one or more strings ans SHALL be
314 | present. payment-method is represented as a string and SHALL be
315 | present. price is represented as a string and SHALL be present.
316 |
317 | Example use of the encryption, extensions, ransomnotes fields in the
318 | ransomware galaxy:
319 |
320 |
321 |
322 |
323 |
324 |
325 |
326 |
327 |
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 | Dulaunoy, et al. Expires 26 June 2024 [Page 6]
337 |
338 | Internet-Draft MISP galaxy format December 2023
339 |
340 |
341 | {
342 | "description": "Similar to Samas and BitPaymer, Ryuk is specifically used to target enterprise environments. Code comparison between versions of Ryuk and Hermes ransomware indicates that Ryuk was derived from the Hermes source code and has been under steady development since its release. Hermes is commodity ransomware that has been observed for sale on forums and used by multiple threat actors. However, Ryuk is only used by GRIM SPIDER and, unlike Hermes, Ryuk has only been used to target enterprise environments. Since Ryuk’s appearance in August, the threat actors operating it have netted over 705.80 BTC across 52 transactions for a total current value of $3,701,893.98 USD.",
343 | "meta": {
344 | "ransomnotes-filenames": [
345 | "RyukReadMe.txt"
346 | ],
347 | "ransomnotes-refs": [
348 | "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig3.png",
349 | "https://www.crowdstrike.com/blog/wp-content/uploads/2019/01/RansomeNote-fig4.png"
350 | ],
351 | "refs": [
352 | "https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/"
353 | ]
354 | },
355 | "uuid": "f9464c80-b776-4f37-8682-ffde0cf8f718",
356 | "value": "Ryuk ransomware"
357 | }
358 |
359 | Example use of the payment-method, price fields in the ransomware
360 | galaxy:
361 |
362 | {
363 | "description": "This is most likely to affect English speaking users, since the note is written in English. English is understood worldwide, thus anyone can be harmed. The hacker spread the virus using email spam, fake updates, and harmful attachments. All your files are compromised including music, MS Office, Open Office, pictures, videos, shared online files etc..",
364 | "meta": {
365 | "date": "March 2017",
366 | "encryption": "AES-128",
367 | "extensions": [
368 | ".enc"
369 | ],
370 | "payment-method": "Bitcoin",
371 | "price": "0.1",
372 | "ransomnotes": [
373 | "Blocked Your computer has been blocked All your files are encrypted. To access your PC, you need to send to Bitcoin at the address below loading Step 1: Go to xxxxs : //wvw.coinbase.com/ siqnup Step 2: Create an account and follow the instructions Step 3: Go to the \"Buy Bitcoins\" section and then buy Bitcoin Step 4: Go to the \"Send\" section, enter the address above and the amount (0.1 Bitcoin) Step 5: Click on the button below to verify the payment, your files will be decrypted and the virus will disappear 'Check' If you try to bypass the lock, all files will be published on the Internet, as well as your login for all sites."
374 | ],
375 | "refs": [
376 | "https://id-ransomware.blogspot.co.il/2017/03/cryptomeister-ransomware.html"
377 | ]
378 | },
379 | "uuid": "4c76c845-c5eb-472c-93a1-4178f86c319b",
380 | "value": "CryptoMeister Ransomware"
381 | }
382 |
383 | source-uuid, target-uuid SHALL be used to describe relationships.
384 | source-uuid and target-uuid represent the Universally Unique
385 | IDentifier (UUID) [RFC4122] of the value reference. source-uuid and
386 | target-uuid MUST be preserved.
387 |
388 |
389 |
390 |
391 |
392 | Dulaunoy, et al. Expires 26 June 2024 [Page 7]
393 |
394 | Internet-Draft MISP galaxy format December 2023
395 |
396 |
397 | Example use of the source-uuid, target-uuid fields in the mitre-
398 | enterprise-attack-relationship galaxy:
399 |
400 | {
401 | "meta": {
402 | "source-uuid": "222fbd21-fc4f-4b7e-9f85-0e6e3a76c33f",
403 | "target-uuid": "2f1a9fd0-3b7c-4d77-a358-78db13adbe78"
404 | },
405 | "uuid": "cfc7da70-d7c5-4508-8f50-1c3107269633",
406 | "value": "menuPass (G0045) uses EvilGrab (S0152)"
407 | }
408 |
409 | cfr-suspected-victims, cfr-suspected-state-sponsor, cfr-type-of-
410 | incident and cfr-target-category MAY be used to report information
411 | gathered from CFR's (Council on Foreign Relations) [CFR] Cyber
412 | Operations Tracker. cfr-suspected-victims is represented as an array
413 | containing one or more strings and SHALL be present. cfr-suspected-
414 | state-sponsor is represented as a string and SHALL be present. cfr-
415 | type-of-incident is represented as a string or an array and SHALL be
416 | present. RECOMMENDED but not exhaustive list of possible values for
417 | cfr-type-of-incident includes "Espionage", "Denial of service",
418 | "Sabotage". cfr-target-category is represented as an array containing
419 | one or more strings ans SHALL be present. RECOMMENDED but not
420 | exhaustive list of possible values for cfr-target-category includes
421 | "Private sector", "Government", "Civil society", "Military".
422 |
423 | Example use of the cfr-suspected-victims, cfr-suspected-state-
424 | sponsor, cfr-type-of-incident, cfr-target-category fields in the
425 | threat-actor galaxy:
426 |
427 |
428 |
429 |
430 |
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 | Dulaunoy, et al. Expires 26 June 2024 [Page 8]
449 |
450 | Internet-Draft MISP galaxy format December 2023
451 |
452 |
453 | {
454 | "meta": {
455 | "country": "CN",
456 | "refs": [
457 | "https://www.fireeye.com/blog/threat-research/2015/12/the_eps_awakens.html",
458 | "https://www.cfr.org/interactive/cyber-operations/apt-16"
459 | ],
460 | "cfr-suspected-victims": [
461 | "Japan",
462 | "Taiwan"
463 | ],
464 | "cfr-suspected-state-sponsor": "China",
465 | "cfr-type-of-incident": "Espionage",
466 | "cfr-target-category": [
467 | "Private sector"
468 | ],
469 | "attribution-confidence": 50
470 | },
471 | "value": "APT 16",
472 | "uuid": "1f73e14f-b882-4032-a565-26dc653b0daf"
473 | },
474 |
475 | attribution-confidence MAY be used to indicate the confidence about
476 | an attribution given by country or cfr-suspected-state-sponsor.
477 | attribution-confidence is represented on a scale from 0 to 100, where
478 | 50 means "no information", the values under 50 mean "probably not,
479 | almost certainly not to impossibility", the values above 50 means
480 | "from probable, almost certain to certainty" and SHALL be present if
481 | country or cfr-suspected-state-sponsor are present.
482 |
483 | Impossibility no information Certainty
484 | +
485 | |
486 | +-------------------+------------------>
487 |
488 | 0 50 100
489 |
490 | 3. JSON Schema
491 |
492 | The JSON Schema [JSON-SCHEMA] below defines the overall MISP galaxy
493 | formats. The main format is the MISP galaxy format used for the
494 | clusters.
495 |
496 | 3.1. MISP galaxy format - galaxy
497 |
498 |
499 |
500 |
501 |
502 |
503 |
504 | Dulaunoy, et al. Expires 26 June 2024 [Page 9]
505 |
506 | Internet-Draft MISP galaxy format December 2023
507 |
508 |
509 | {
510 | "$schema": "http://json-schema.org/schema#",
511 | "title": "Validator for misp-galaxies - Galaxies",
512 | "id": "https://www.github.com/MISP/misp-galaxies/schema_galaxies.json",
513 | "type": "object",
514 | "additionalProperties": false,
515 | "properties": {
516 | "description": {
517 | "type": "string"
518 | },
519 | "type": {
520 | "type": "string"
521 | },
522 | "version": {
523 | "type": "integer"
524 | },
525 | "name": {
526 | "type": "string"
527 | },
528 | "icon": {
529 | "type": "string"
530 | },
531 | "uuid": {
532 | "type": "string"
533 | },
534 | "namespace": {
535 | "type": "string"
536 | },
537 | "kill_chain_order": {
538 | "type": "object"
539 | }
540 | },
541 | "required": [
542 | "description",
543 | "type",
544 | "version",
545 | "name",
546 | "uuid"
547 | ]
548 | }
549 |
550 | 3.2. MISP galaxy format - clusters
551 |
552 |
553 |
554 |
555 |
556 |
557 |
558 |
559 |
560 | Dulaunoy, et al. Expires 26 June 2024 [Page 10]
561 |
562 | Internet-Draft MISP galaxy format December 2023
563 |
564 |
565 | {
566 | "$schema": "http://json-schema.org/schema#",
567 | "title": "Validator for misp-galaxies - Clusters",
568 | "id": "https://www.github.com/MISP/misp-galaxies/schema_clusters.json",
569 | "type": "object",
570 | "additionalProperties": false,
571 | "properties": {
572 | "description": {
573 | "type": "string"
574 | },
575 | "type": {
576 | "type": "string"
577 | },
578 | "version": {
579 | "type": "integer"
580 | },
581 | "name": {
582 | "type": "string"
583 | },
584 | "uuid": {
585 | "type": "string"
586 | },
587 | "source": {
588 | "type": "string"
589 | },
590 | "category": {
591 | "type": "string
592 | },
593 | "values": {
594 | "type": "array",
595 | "uniqueItems": true,
596 | "items": {
597 | "type": "object",
598 | "additionalProperties": false,
599 | "properties": {
600 | "description": {
601 | "type": "string"
602 | },
603 | "value": {
604 | "type": "string"
605 | },
606 | "uuid": {
607 | "type": "string"
608 | },
609 | "related": {
610 | "type": "array",
611 | "additionalProperties": false,
612 | "items": {
613 |
614 |
615 |
616 | Dulaunoy, et al. Expires 26 June 2024 [Page 11]
617 |
618 | Internet-Draft MISP galaxy format December 2023
619 |
620 |
621 | "type": "object"
622 | },
623 | "properties": {
624 | "dest-uuid": {
625 | "type": "string"
626 | },
627 | "type": {
628 | "type": "string"
629 | },
630 | "tags": {
631 | "type": "array",
632 | "uniqueItems": true,
633 | "items": {
634 | "type": "string"
635 | }
636 | }
637 | }
638 | },
639 | "meta": {
640 | "type": "object",
641 | "additionalProperties": true,
642 | "properties": {
643 | "type": {
644 | "type": "array",
645 | "uniqueItems": true,
646 | "items": {
647 | "type": "string"
648 | }
649 | },
650 | "complexity": {
651 | "type": "string"
652 | },
653 | "effectiveness": {
654 | "type": "string"
655 | },
656 | "country": {
657 | "type": "string"
658 | },
659 | "possible_issues": {
660 | "type": "string"
661 | },
662 | "colour": {
663 | "type": "string"
664 | },
665 | "motive": {
666 | "type": "string"
667 | },
668 | "impact": {
669 |
670 |
671 |
672 | Dulaunoy, et al. Expires 26 June 2024 [Page 12]
673 |
674 | Internet-Draft MISP galaxy format December 2023
675 |
676 |
677 | "type": "string"
678 | },
679 | "refs": {
680 | "type": "array",
681 | "uniqueItems": true,
682 | "items": {
683 | "type": "string"
684 | }
685 | },
686 | "synonyms": {
687 | "type": "array",
688 | "uniqueItems": true,
689 | "items": {
690 | "type": "string"
691 | }
692 | },
693 | "status": {
694 | "type": "string"
695 | },
696 | "date": {
697 | "type": "string"
698 | },
699 | "encryption": {
700 | "type": "string"
701 | },
702 | "extensions": {
703 | "type": "array",
704 | "uniqueItems": true,
705 | "items": {
706 | "type": "string"
707 | }
708 | },
709 | "ransomnotes": {
710 | "type": "array",
711 | "uniqueItems": true,
712 | "items": {
713 | "type": "string"
714 | }
715 | }
716 | }
717 | }
718 | },
719 | "required": [
720 | "value"
721 | ]
722 | }
723 | },
724 | "authors": {
725 |
726 |
727 |
728 | Dulaunoy, et al. Expires 26 June 2024 [Page 13]
729 |
730 | Internet-Draft MISP galaxy format December 2023
731 |
732 |
733 | "type": "array",
734 | "uniqueItems": true,
735 | "items": {
736 | "type": "string"
737 | }
738 | }
739 | },
740 | "required": [
741 | "description",
742 | "type",
743 | "version",
744 | "name",
745 | "uuid",
746 | "values",
747 | "authors",
748 | "source",
749 | "category
750 | ]
751 | }
752 |
753 | 4. Acknowledgements
754 |
755 | The authors wish to thank all the MISP community who are supporting
756 | the creation of open standards in threat intelligence sharing.
757 |
758 | 5. Normative References
759 |
760 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
761 | Requirement Levels", BCP 14, RFC 2119,
762 | DOI 10.17487/RFC2119, March 1997,
763 | .
764 |
765 | [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
766 | Unique IDentifier (UUID) URN Namespace", RFC 4122,
767 | DOI 10.17487/RFC4122, July 2005,
768 | .
769 |
770 | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
771 | Interchange Format", STD 90, RFC 8259,
772 | DOI 10.17487/RFC8259, December 2017,
773 | .
774 |
775 | 6. Informative References
776 |
777 | [CFR] Relations, C. O. F., "Cyber Operations Tracker - Council
778 | on Foreign Relations", 2018,
779 | .
780 |
781 |
782 |
783 |
784 | Dulaunoy, et al. Expires 26 June 2024 [Page 14]
785 |
786 | Internet-Draft MISP galaxy format December 2023
787 |
788 |
789 | [JSON-SCHEMA]
790 | Wright, A., "JSON Schema: A Media Type for Describing JSON
791 | Documents", 2016,
792 | .
793 |
794 | [MISP-G] Community, M., "MISP Galaxy - Public Repository",
795 | .
796 |
797 | [MISP-G-DOC]
798 | Community, M., "MISP Galaxy - Documentation of the Public
799 | Repository", .
800 |
801 | [MISP-P] Community, M., "MISP Project - Malware Information Sharing
802 | Platform and Threat Sharing", .
803 |
804 | [MISP-R] Community, M., "MISP Object Relationship Types - common
805 | vocabulary of relationships", .
807 |
808 | Authors' Addresses
809 |
810 | Alexandre Dulaunoy
811 | Computer Incident Response Center Luxembourg
812 | 122, rue Adolphe Fischer
813 | L-L-1521 Luxembourg
814 | Luxembourg
815 |
816 | Phone: +352 247 88444
817 | Email: alexandre.dulaunoy@circl.lu
818 |
819 |
820 | Andras Iklody
821 | Computer Incident Response Center Luxembourg
822 | 122, rue Adolphe Fischer
823 | L-L-1521 Luxembourg
824 | Luxembourg
825 |
826 | Phone: +352 247 88444
827 | Email: andras.iklody@circl.lu
828 |
829 |
830 | Deborah Servili
831 | Computer Incident Response Center Luxembourg
832 | 122, rue Adolphe Fischer
833 | L-L-1521 Luxembourg
834 | Luxembourg
835 |
836 | Phone: +352 247 88444
837 |
838 |
839 |
840 | Dulaunoy, et al. Expires 26 June 2024 [Page 15]
841 |
842 | Internet-Draft MISP galaxy format December 2023
843 |
844 |
845 | Email: deborah.servili@circl.lu
846 |
847 |
848 |
849 |
850 |
851 |
852 |
853 |
854 |
855 |
856 |
857 |
858 |
859 |
860 |
861 |
862 |
863 |
864 |
865 |
866 |
867 |
868 |
869 |
870 |
871 |
872 |
873 |
874 |
875 |
876 |
877 |
878 |
879 |
880 |
881 |
882 |
883 |
884 |
885 |
886 |
887 |
888 |
889 |
890 |
891 |
892 |
893 |
894 |
895 |
896 | Dulaunoy, et al. Expires 26 June 2024 [Page 16]
897 |
--------------------------------------------------------------------------------
/misp-noticelist-format/raw.md:
--------------------------------------------------------------------------------
1 | % Title = "MISP noticelist format"
2 | % abbrev = "MISP noticelist format"
3 | % category = "info"
4 | % docName = "draft-dulaunoy-misp-noticelist-format"
5 | % ipr= "trust200902"
6 | % area = "Security"
7 | %
8 | % date = 2018-04-01T00:00:00Z
9 | %
10 | % [[author]]
11 | % initials="A."
12 | % surname="Dulaunoy"
13 | % fullname="Alexandre Dulaunoy"
14 | % abbrev="CIRCL"
15 | % organization = "Computer Incident Response Center Luxembourg"
16 | % [author.address]
17 | % email = "alexandre.dulaunoy@circl.lu"
18 | % phone = "+352 247 88444"
19 | % [author.address.postal]
20 | % street = "16, bd d'Avranches"
21 | % city = "Luxembourg"
22 | % code = "L-1611"
23 | % country = "Luxembourg"
24 | % [[author]]
25 | % initials="A."
26 | % surname="Iklody"
27 | % fullname="Andras Iklody"
28 | % abbrev="CIRCL"
29 | % organization = "Computer Incident Response Center Luxembourg"
30 | % [author.address]
31 | % email = "andras.iklody@circl.lu"
32 | % phone = "+352 247 88444"
33 | % [author.address.postal]
34 | % street = " 16, bd d'Avranches"
35 | % city = "Luxembourg"
36 | % code = "L-1611"
37 | % country = "Luxembourg"
38 | % [[author]]
39 | % initials="D."
40 | % surname="Servili"
41 | % fullname="Deborah Servili"
42 | % abbrev="CIRCL"
43 | % organization = "Computer Incident Response Center Luxembourg"
44 | % [author.address]
45 | % email = "deborah.servili@circl.lu"
46 | % phone = "+352 247 88444"
47 | % [author.address.postal]
48 | % street = " 16, bd d'Avranches"
49 | % city = "Luxembourg"
50 | % code = "L-1611"
51 | % country = "Luxembourg"
52 |
53 | .# Abstract
54 |
55 | This document describes the MISP noticelist format which describes a simple JSON format to represent list of notices used to inform MISP users of the legal, privacy, policy or even technical implications of using, storing and sharing specific attributes, categories or objects. MISP noticelist can be used in threat intelligence or information sharing platform. A reference implementation and public repository is maintained within the open source MISP project.
56 |
57 | {mainmatter}
58 |
59 | # Introduction
60 |
61 | As the user navigates through the MISP interface, he can sometimes be lost about what to do or not to do on the platform. Noticelist have been created in order to help and guide the user during his use of MISP, by showing several information to him, or giving him easy reminders.
62 | For instance, due to GDRP, users are expected to be more careful about the information they share, and the GDPR noticelist can be used to help them with this new regulation.
63 |
64 | MISP noticelist is a public repository of list of notices to show to the user about the information he uses or share.
65 |
66 | ## Conventions and Terminology
67 |
68 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
69 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
70 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
71 |
72 | # Format
73 |
74 | Noticelist are represented as a JSON [@!RFC4627] dictionary.
75 |
76 | ## Overview
77 |
78 | The MISP noticelist format uses the JSON [@!RFC4627] format. Each noticelist is represented as a JSON object with meta information including the following fields: name, expended_name, ref, geographical_area and notice.
79 |
80 | name defines the name of the noticelist. It **MUST** match the name of the folder containing the list. The name is represented as a string and **MUST** be present. expanded_name defines the full name of the noticelist. The expanded_name is represented by a string and **MUST** be present. ref defines the references used to create the notice list. ref is represented as an array containing one or more references and **MUST** pe present. Each reference is a string and **MUST** be present. geographical_area defines the geographical area affected by this noticelist. geographical_area is represented as an array containing one or more descriptions of geographical area ans **SHOULD** be present. Each geographical area is a string and **SHOULD** be present.
81 |
82 | notice is represented as an array containing one or more values and **MUST** be present. notice defines all values available in the noticelist.
83 |
84 | The MISP noticelist directory is publicly available [@?MISP-N] in a git repository and can be freely reused in other tools such threat intelligence or information sharing platform.
85 |
86 | ## notice
87 |
88 | The notice array contains one or more JSON objects which represent all the possible values in the noticelist. The JSON object contains five fields: scope,
89 | field, value, tags and message.
90 |
91 | scope is represented as an array containing one or more scopes to apply the notice ans **MUST** be present. Each scope is a string and **MUST** be present. field is represented as an array containing one or more fields to apply the notice ans **MUST** be present. Each field is a string and **MUST** be present. value is represented as an array containing one or more values and **MUST** be present. Each value is a string and **MUST** be present. tags is represented as an array containing one or more values and **MUST** be present. Each tag is a string and **SHALL** be present. message is represented as a JSON dictionary containing one or more messages translated in different languages and **MUST** be present. Each element in the message dictionary is a couple name/value where the name designate a language and the value contains a string representing a message to display to the user. These elements **MUST** be present.
92 |
93 | Example of an element of the notice array
94 |
95 | ~~~~
96 | {
97 | "scope": ["attribute"],
98 | "field": ["category", "meta-category"],
99 | "value": [
100 | "Targeting data",
101 | "Attribution",
102 | "Financial fraud",
103 | "Social network",
104 | "Person"
105 | ],
106 | "tags": ["fpf:degrees-of-identifiability='explicitly-personal'"],
107 | "message": {
108 | "en": "This attribute is likely to contain personal data and the data subject is likely to be directly identifiable. Please verify that the processing of personal data is necessary and proportionate to the purposes (e.g. ensuring network and information security) and that you have a legal ground to share those personal data. Where applicable, please ensure that you have taken the necessary steps to ensure transparency towards the data subject in relation to the processing of their personal data."
109 | }
110 | }
111 | ~~~~
112 |
113 | # Acknowledgements
114 |
115 | The authors wish to thank all the MISP community who are supporting the creation
116 | of open standards in threat intelligence sharing.
117 |
118 |
119 |
120 | Notice lists public repository to inform users of MISP about legal or technical implication for some attributes, categories and objects.
121 |
122 |
123 |
124 |
125 |
126 | {backmatter}
127 |
--------------------------------------------------------------------------------
/misp-object-template-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
10 |
--------------------------------------------------------------------------------
/misp-query-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark -xml2 -page
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
10 |
--------------------------------------------------------------------------------
/misp-query-format/raw.md:
--------------------------------------------------------------------------------
1 | % Title = "MISP query format"
2 | % abbrev = "MISP query format"
3 | % category = "info"
4 | % docName = "draft-dulaunoy-misp-core-format"
5 | % ipr= "trust200902"
6 | % area = "Security"
7 | %
8 | % date = 2018-10-08T00:00:00Z
9 | %
10 | % [[author]]
11 | % initials="A."
12 | % surname="Dulaunoy"
13 | % fullname="Alexandre Dulaunoy"
14 | % abbrev="CIRCL"
15 | % organization = "Computer Incident Response Center Luxembourg"
16 | % [author.address]
17 | % email = "alexandre.dulaunoy@circl.lu"
18 | % phone = "+352 247 88444"
19 | % [author.address.postal]
20 | % street = "16, bd d'Avranches"
21 | % city = "Luxembourg"
22 | % code = "L-1160"
23 | % country = "Luxembourg"
24 | % [[author]]
25 | % initials="A."
26 | % surname="Iklody"
27 | % fullname="Andras Iklody"
28 | % abbrev="CIRCL"
29 | % organization = "Computer Incident Response Center Luxembourg"
30 | % [author.address]
31 | % email = "andras.iklody@circl.lu"
32 | % phone = "+352 247 88444"
33 | % [author.address.postal]
34 | % street = "16, bd d'Avranches"
35 | % city = "Luxembourg"
36 | % code = "L-1160"
37 | % country = "Luxembourg"
38 |
39 | .# Abstract
40 |
41 | This document describes the MISP query format used to search MISP (Malware Information and threat Sharing Platform) [@?MISP-P] threat intelligence instances.
42 | MISP query format is a simple format used to query MISP instances over a REST (Representational State Transfer ) interface.
43 | The query format includes the JSON format to describe the query and the minimal API access to perform the query. The JSON format includes the overall structure along with the semantic associated for each respective key. The goal of the format is to query MISP threat intelligence instances can feed and integrate with network security devices (such as firewall, network intrusion detection system, routers, SIEMs), endpoint security devices or monitoring devices.
44 |
45 | {mainmatter}
46 |
47 | # Introduction
48 |
49 | Sharing threat information became a fundamental requirements in the Internet, security and intelligence community at large. Threat
50 | information can include indicators of compromise, malicious file indicators, financial fraud indicators
51 | or even detailed information about a threat actor. MISP [@?MISP-P] started as an open source project in late 2011 and
52 | the MISP format started to be widely used as an exchange format within the community in the past years. The core format
53 | is described in an Internet-Draft as misp-core-format [@?MISP-C] and contain the standard MISP JSON format used for threat
54 | intelligence.
55 |
56 | The aim of this document is to describe the specification of the MISP query format and how the query can be perform against a REST interface.
57 |
58 | ## Conventions and Terminology
59 |
60 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
61 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
62 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
63 |
64 | # Format
65 |
66 | ## Overview
67 |
68 | The MISP query format is in the JSON [@!RFC8259] format.
69 |
70 |
71 | ## query format criteria
72 |
73 | ### returnFormat
74 |
75 | returnFormat **MUST** be present. returnFormat sets the type of output format. MISP allows multiple format (depending of the configuration):
76 |
77 | | value | Description |
78 | |---------------|:-------------------------------------------------------------------------:|
79 | | json | MISP JSON core format as described in [@?MISP-C] |
80 | | xml | MISP XML format |
81 | | openioc | OpenIOC format |
82 | | suricata | Suricata NIDS format |
83 | | snort | Snort NIDS format |
84 | | csv | CSV format |
85 | | rpz | Response policy zone format |
86 | | text | Raw value list format |
87 | | cache | MISP cache format (hashed values of attributes) |
88 |
89 | ### limit
90 |
91 | limit **MAY** be present. If present, the page parameter **MUST** also be supplied. limit sets the number of returned elements when paginating, depending on the scope of the request (x number of attributes or x number of events) as converted into the output format.
92 |
93 | ### page
94 |
95 | page **MAY** be present. If present, the page parameter **MUST** also be supplied. page generates the offset for the pagination and will return a result set consisting of a slice of the query results starting with offset (limit * page) + 1 and ending with (limit * (page+1)).
96 |
97 | ### value
98 |
99 | value **MAY** be present. If set, the returned data set will be filtered on the attribute value field. value **MUST** be a string or a sub-string, the latter of which starts with, ends with or is encapsulated in wildcard (\%) characters.
100 |
101 | ### type
102 |
103 | type **MAY** be present. If set, the returned data set will be filtered on the attribute type field. type **MUST** be a string or a sub-string, the latter of which starts with, ends with or is encapsulated in wildcard (\%) characters. The list of valid attribute types is described in the MISP core format [@?MISP-C] in the attribute type section.
104 |
105 | ### category
106 |
107 | category **MAY** be present. If set, the returned data set will be filtered on the attribute category field. category **MUST** be a string or a sub-string, the latter of which starts with, ends with or is encapsulated in wildcard (\%) characters. The list of valid categories is described in the MISP core format [@?MISP-C] in the attribute type section.
108 |
109 | A sample query to lookup for the last 30 days of indicators in the `Financial fraud` category and output in CSV format:
110 |
111 | ~~~~
112 | {
113 | "returnFormat": "csv",
114 | "last": "30d",
115 | "category": "Financial fraud"
116 | }
117 | ~~~~
118 |
119 | ### org
120 |
121 | org **MAY** be present. If set, the returned data set will be filtered by the organisation identifier (local ID of the instance). org **MUST** be the identifier of the organisation in a string format.
122 |
123 | ### tags
124 |
125 | tags **MAY** be present. If set, the returned data set will be filtered by tags. tags **MUST** be a string or a sub-string, the latter of which starts with, ends with or is encapsulated in wildcard (\%) characters.
126 |
127 | ~~~~
128 | {
129 | "returnFormat": "cache",
130 | "limit": "100",
131 | "tags": ["tlp:red", "%private%"]
132 | }
133 | ~~~~
134 |
135 | ### quickfilter
136 |
137 | ### from
138 |
139 | from **MAY** be present. If set, the returned data set will be filtered from a starting date. from **MUST** be a string represented in the format year-month-date.
140 |
141 | ~~~~
142 | {
143 | "returnFormat": "json",
144 | "limit": "100",
145 | "tags": ["tlp:amber"],
146 | "from": "2018-09-02",
147 | "to": "2018-10-01"
148 | }
149 | ~~~~
150 |
151 | ### to
152 |
153 | to **MAY** be present. If set, the returned data set will be filtered until the specified date. from **MUST** be a string represented in the format year-month-date.
154 |
155 | ### last
156 |
157 | last **MAY** be present. If set, the returned data set will be filtered in the number of days, hours or minutes defined (such as 5d, 12h or 30m). last **MUST** be a string represented in the format expressing days, hours or minutes.
158 |
159 | ### eventid
160 |
161 | eventid **MAY** be present. If set, the returned data set will be filtered to a specific event. eventid **MUST** be a string representing the event id as an integer.
162 |
163 | ~~~~
164 | {
165 | "returnFormat": "json",
166 | "eventid": 1
167 | }
168 | ~~~~
169 |
170 | ### withAttachments
171 |
172 | withAttachments **MAY** be present. If set to True (1), the returned data set will include the attachment(s) matching the query. withAttachments **MUST** be an integer set as 1 (True) to include the attachment(s). If not, the attachment(s) won't be included in the results.
173 |
174 | ### uuid
175 |
176 | ### publish_timestamp
177 |
178 | ### timestamp
179 |
180 | ### published
181 |
182 | ### enforceWarninglist
183 |
184 | ### to_ids
185 |
186 | ### deleted
187 |
188 | ### includeEventUuid
189 |
190 | ### event_timestamp
191 |
192 | ### sgReferenceOnly
193 |
194 | ### eventinfo
195 |
196 | ### searchall
197 |
198 | ### requested_attributes
199 |
200 | ### includeContext
201 |
202 |
203 | # Security Considerations
204 |
205 | MISP threat intelligence instances might contain sensitive or confidential information. Adequate access control and encryption measures shall be implemented to ensure the confidentiality of the threat intelligence.
206 |
207 | Adversaries might include malicious content in MISP queries. Implementation **MUST** consider the input of malicious inputs beside the
208 | standard threat information that might already include malicious intended inputs.
209 |
210 | # Acknowledgements
211 |
212 | The authors wish to thank all the MISP community who are supporting the creation
213 | of open standards in threat intelligence sharing. A special thank to all the committees which
214 | triggered us to come with better and flexible format.
215 |
216 |
217 |
218 |
219 | MISP Project - Malware Information Sharing Platform and Threat Sharing
220 |
221 |
222 |
223 |
224 |
225 |
226 |
227 | MISP core format
228 |
229 |
230 |
231 |
232 |
233 |
234 |
235 | MISP Taxonomies - shared and common vocabularies of tags
236 |
237 |
238 |
239 |
240 |
241 |
242 |
243 | MISP Object Relationship Types - common vocabulary of relationships
244 |
245 |
246 |
247 |
248 |
249 |
250 |
251 | JSON Schema: A Media Type for Describing JSON Documents
252 |
253 |
254 |
255 |
256 |
257 |
258 | {backmatter}
259 |
--------------------------------------------------------------------------------
/misp-query-format/raw.md.html:
--------------------------------------------------------------------------------
1 |
3 |
4 |
5 |
6 |
7 |
8 | MISP query format
9 |
10 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 |
Network Working Group
414 |
A. Dulaunoy
415 |
416 |
417 |
Internet-Draft
418 |
A. Iklody
419 |
420 |
421 |
Intended status: Informational
422 |
CIRCL
423 |
424 |
425 |
Expires: April 11, 2019
426 |
October 8, 2018
427 |
428 |
429 |
430 |
431 |
432 |
433 |
MISP query format
434 | draft-dulaunoy-misp-core-format
This document describes the MISP query format used to search MISP (Malware Information and threat Sharing Platform) [MISP-P] threat intelligence instances. MISP query format is a simple format used to query MISP instances over a REST (Representational State Transfer ) interface. The query format includes the JSON format to describe the query and the minimal API access to perform the query. The JSON format includes the overall structure along with the semantic associated for each respective key. The goal of the format is to query MISP threat intelligence instances can feed and integrate with network security devices (such as firewall, network intrusion detection system, routers, SIEMs), endpoint security devices or monitoring devices.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
440 |
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/.
441 |
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."
442 |
This Internet-Draft will expire on April 11, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
445 |
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.
Sharing threat information became a fundamental requirements in the Internet, security and intelligence community at large. Threat information can include indicators of compromise, malicious file indicators, financial fraud indicators or even detailed information about a threat actor. MISP [MISP-P] started as an open source project in late 2011 and the MISP format started to be widely used as an exchange format within the community in the past years. The core format is described in an Internet-Draft as misp-core-format [MISP-C] and contain the standard MISP JSON format used for threat intelligence.
494 |
The aim of this document is to describe the specification of the MISP query format and how the query can be perform against a REST interface.
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].
limit MAY be present. If present, the page parameter MUST also be supplied. limit sets the number of returned elements when paginating, depending on the scope of the request (x number of attributes or x number of events) as converted into the output format.
page MAY be present. If present, the page parameter MUST also be supplied. page generates the offset for the pagination and will return a result set consisting of a slice of the query results starting with offset (limit * page) + 1 and ending with (limit * (page+1)).
value MAY be present. If set, the returned data set will be filtered on the attribute value field. value MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters.
type MAY be present. If set, the returned data set will be filtered on the attribute type field. type MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters. The list of valid attribute types is described in the MISP core format [MISP-C] in the attribute type section.
category MAY be present. If set, the returned data set will be filtered on the attribute category field. category MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters. The list of valid categories is described in the MISP core format [MISP-C] in the attribute type section.
574 |
A sample query to lookup for the last 30 days of indicators in the Financial fraud category and output in CSV format:
MISP threat intelligence instances might contain sensitive or confidential information. Adequate access control and encryption measures shall be implemented to ensure the confidentiality of the threat intelligence.
586 |
Adversaries might include malicious content in MISP queries. Implementation MUST consider the input of malicious inputs beside the standard threat information that might already include malicious intended inputs.
The authors wish to thank all the MISP community who are supporting the creation of open standards in threat intelligence sharing. A special thank to all the committees which triggered us to come with better and flexible format.
671 |
672 |
673 |
674 |
--------------------------------------------------------------------------------
/misp-query-format/raw.md.txt:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Network Working Group A. Dulaunoy
6 | Internet-Draft A. Iklody
7 | Intended status: Informational CIRCL
8 | Expires: April 11, 2019 October 8, 2018
9 |
10 |
11 | MISP query format
12 | draft-dulaunoy-misp-core-format
13 |
14 | Abstract
15 |
16 | This document describes the MISP query format used to search MISP
17 | (Malware Information and threat Sharing Platform) [MISP-P] threat
18 | intelligence instances. MISP query format is a simple format used to
19 | query MISP instances over a REST (Representational State Transfer )
20 | interface. The query format includes the JSON format to describe the
21 | query and the minimal API access to perform the query. The JSON
22 | format includes the overall structure along with the semantic
23 | associated for each respective key. The goal of the format is to
24 | query MISP threat intelligence instances can feed and integrate with
25 | network security devices (such as firewall, network intrusion
26 | detection system, routers, SIEMs), endpoint security devices or
27 | monitoring devices.
28 |
29 | Status of This Memo
30 |
31 | This Internet-Draft is submitted in full conformance with the
32 | provisions of BCP 78 and BCP 79.
33 |
34 | Internet-Drafts are working documents of the Internet Engineering
35 | Task Force (IETF). Note that other groups may also distribute
36 | working documents as Internet-Drafts. The list of current Internet-
37 | Drafts is at https://datatracker.ietf.org/drafts/current/.
38 |
39 | Internet-Drafts are draft documents valid for a maximum of six months
40 | and may be updated, replaced, or obsoleted by other documents at any
41 | time. It is inappropriate to use Internet-Drafts as reference
42 | material or to cite them other than as "work in progress."
43 |
44 | This Internet-Draft will expire on April 11, 2019.
45 |
46 | Copyright Notice
47 |
48 | Copyright (c) 2018 IETF Trust and the persons identified as the
49 | document authors. All rights reserved.
50 |
51 | This document is subject to BCP 78 and the IETF Trust's Legal
52 | Provisions Relating to IETF Documents
53 |
54 |
55 |
56 | Dulaunoy & Iklody Expires April 11, 2019 [Page 1]
57 |
58 | Internet-Draft MISP query format October 2018
59 |
60 |
61 | (https://trustee.ietf.org/license-info) in effect on the date of
62 | publication of this document. Please review these documents
63 | carefully, as they describe your rights and restrictions with respect
64 | to this document. Code Components extracted from this document must
65 | include Simplified BSD License text as described in Section 4.e of
66 | the Trust Legal Provisions and are provided without warranty as
67 | described in the Simplified BSD License.
68 |
69 | Table of Contents
70 |
71 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
72 | 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
73 | 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
74 | 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
75 | 2.2. query format criteria . . . . . . . . . . . . . . . . . . 3
76 | 2.2.1. returnFormat . . . . . . . . . . . . . . . . . . . . 3
77 | 2.2.2. limit . . . . . . . . . . . . . . . . . . . . . . . . 4
78 | 2.2.3. page . . . . . . . . . . . . . . . . . . . . . . . . 4
79 | 2.2.4. value . . . . . . . . . . . . . . . . . . . . . . . . 4
80 | 2.2.5. type . . . . . . . . . . . . . . . . . . . . . . . . 4
81 | 2.2.6. category . . . . . . . . . . . . . . . . . . . . . . 5
82 | 2.2.7. org . . . . . . . . . . . . . . . . . . . . . . . . . 5
83 | 2.2.8. tags . . . . . . . . . . . . . . . . . . . . . . . . 5
84 | 2.2.9. quickfilter . . . . . . . . . . . . . . . . . . . . . 5
85 | 2.2.10. from . . . . . . . . . . . . . . . . . . . . . . . . 5
86 | 2.2.11. to . . . . . . . . . . . . . . . . . . . . . . . . . 6
87 | 2.2.12. last . . . . . . . . . . . . . . . . . . . . . . . . 6
88 | 2.2.13. eventid . . . . . . . . . . . . . . . . . . . . . . . 6
89 | 2.2.14. withAttachments . . . . . . . . . . . . . . . . . . . 6
90 | 2.2.15. uuid . . . . . . . . . . . . . . . . . . . . . . . . 6
91 | 2.2.16. publish_timestamp . . . . . . . . . . . . . . . . . . 6
92 | 2.2.17. timestamp . . . . . . . . . . . . . . . . . . . . . . 7
93 | 2.2.18. published . . . . . . . . . . . . . . . . . . . . . . 7
94 | 2.2.19. enforceWarninglist . . . . . . . . . . . . . . . . . 7
95 | 2.2.20. to_ids . . . . . . . . . . . . . . . . . . . . . . . 7
96 | 2.2.21. deleted . . . . . . . . . . . . . . . . . . . . . . . 7
97 | 2.2.22. includeEventUuid . . . . . . . . . . . . . . . . . . 7
98 | 2.2.23. event_timestamp . . . . . . . . . . . . . . . . . . . 7
99 | 2.2.24. sgReferenceOnly . . . . . . . . . . . . . . . . . . . 7
100 | 2.2.25. eventinfo . . . . . . . . . . . . . . . . . . . . . . 7
101 | 2.2.26. searchall . . . . . . . . . . . . . . . . . . . . . . 7
102 | 2.2.27. requested_attributes . . . . . . . . . . . . . . . . 7
103 | 2.2.28. includeContext . . . . . . . . . . . . . . . . . . . 7
104 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
105 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
106 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
107 | 5.1. Normative References . . . . . . . . . . . . . . . . . . 8
108 | 5.2. Informative References . . . . . . . . . . . . . . . . . 8
109 |
110 |
111 |
112 | Dulaunoy & Iklody Expires April 11, 2019 [Page 2]
113 |
114 | Internet-Draft MISP query format October 2018
115 |
116 |
117 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
118 |
119 | 1. Introduction
120 |
121 | Sharing threat information became a fundamental requirements in the
122 | Internet, security and intelligence community at large. Threat
123 | information can include indicators of compromise, malicious file
124 | indicators, financial fraud indicators or even detailed information
125 | about a threat actor. MISP [MISP-P] started as an open source
126 | project in late 2011 and the MISP format started to be widely used as
127 | an exchange format within the community in the past years. The core
128 | format is described in an Internet-Draft as misp-core-format [MISP-C]
129 | and contain the standard MISP JSON format used for threat
130 | intelligence.
131 |
132 | The aim of this document is to describe the specification of the MISP
133 | query format and how the query can be perform against a REST
134 | interface.
135 |
136 | 1.1. Conventions and Terminology
137 |
138 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 | document are to be interpreted as described in RFC 2119 [RFC2119].
141 |
142 | 2. Format
143 |
144 | 2.1. Overview
145 |
146 | The MISP query format is in the JSON [RFC8259] format.
147 |
148 | 2.2. query format criteria
149 |
150 | 2.2.1. returnFormat
151 |
152 | returnFormat MUST be present. returnFormat sets the type of output
153 | format. MISP allows multiple format (depending of the
154 | configuration):
155 |
156 |
157 |
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 | Dulaunoy & Iklody Expires April 11, 2019 [Page 3]
169 |
170 | Internet-Draft MISP query format October 2018
171 |
172 |
173 | +----------+-------------------------------------------------+
174 | | value | Description |
175 | +----------+-------------------------------------------------+
176 | | json | MISP JSON core format as described in [MISP-C] |
177 | | xml | MISP XML format |
178 | | openioc | OpenIOC format |
179 | | suricata | Suricata NIDS format |
180 | | snort | Snort NIDS format |
181 | | csv | CSV format |
182 | | rpz | Response policy zone format |
183 | | text | Raw value list format |
184 | | cache | MISP cache format (hashed values of attributes) |
185 | +----------+-------------------------------------------------+
186 |
187 | 2.2.2. limit
188 |
189 | limit MAY be present. If present, the page parameter MUST also be
190 | supplied. limit sets the number of returned elements when paginating,
191 | depending on the scope of the request (x number of attributes or x
192 | number of events) as converted into the output format.
193 |
194 | 2.2.3. page
195 |
196 | page MAY be present. If present, the page parameter MUST also be
197 | supplied. page generates the offset for the pagination and will
198 | return a result set consisting of a slice of the query results
199 | starting with offset (limit * page) + 1 and ending with (limit *
200 | (page+1)).
201 |
202 | 2.2.4. value
203 |
204 | value MAY be present. If set, the returned data set will be filtered
205 | on the attribute value field. value MUST be a string or a sub-string,
206 | the latter of which starts with, ends with or is encapsulated in
207 | wildcard (\%) characters.
208 |
209 | 2.2.5. type
210 |
211 | type MAY be present. If set, the returned data set will be filtered
212 | on the attribute type field. type MUST be a string or a sub-string,
213 | the latter of which starts with, ends with or is encapsulated in
214 | wildcard (\%) characters. The list of valid attribute types is
215 | described in the MISP core format [MISP-C] in the attribute type
216 | section.
217 |
218 |
219 |
220 |
221 |
222 |
223 |
224 | Dulaunoy & Iklody Expires April 11, 2019 [Page 4]
225 |
226 | Internet-Draft MISP query format October 2018
227 |
228 |
229 | 2.2.6. category
230 |
231 | category MAY be present. If set, the returned data set will be
232 | filtered on the attribute category field. category MUST be a string
233 | or a sub-string, the latter of which starts with, ends with or is
234 | encapsulated in wildcard (\%) characters. The list of valid
235 | categories is described in the MISP core format [MISP-C] in the
236 | attribute type section.
237 |
238 | A sample query to lookup for the last 30 days of indicators in the
239 | "Financial fraud" category and output in CSV format:
240 |
241 | {
242 | "returnFormat": "csv",
243 | "last": "30d",
244 | "category": "Financial fraud"
245 | }
246 |
247 | 2.2.7. org
248 |
249 | org MAY be present. If set, the returned data set will be filtered
250 | by the organisation identifier (local ID of the instance). org MUST
251 | be the identifier of the organisation in a string format.
252 |
253 | 2.2.8. tags
254 |
255 | tags MAY be present. If set, the returned data set will be filtered
256 | by tags. tags MUST be a string or a sub-string, the latter of which
257 | starts with, ends with or is encapsulated in wildcard (\%)
258 | characters.
259 |
260 | {
261 | "returnFormat": "cache",
262 | "limit": "100",
263 | "tags": ["tlp:red", "%private%"]
264 | }
265 |
266 | 2.2.9. quickfilter
267 |
268 | 2.2.10. from
269 |
270 | from MAY be present. If set, the returned data set will be filtered
271 | from a starting date. from MUST be a string represented in the format
272 | year-month-date.
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 | Dulaunoy & Iklody Expires April 11, 2019 [Page 5]
281 |
282 | Internet-Draft MISP query format October 2018
283 |
284 |
285 | {
286 | "returnFormat": "json",
287 | "limit": "100",
288 | "tags": ["tlp:amber"],
289 | "from": "2018-09-02",
290 | "to": "2018-10-01"
291 | }
292 |
293 | 2.2.11. to
294 |
295 | to MAY be present. If set, the returned data set will be filtered
296 | until the specified date. from MUST be a string represented in the
297 | format year-month-date.
298 |
299 | 2.2.12. last
300 |
301 | last MAY be present. If set, the returned data set will be filtered
302 | in the number of days, hours or minutes defined (such as 5d, 12h or
303 | 30m). last MUST be a string represented in the format expressing
304 | days, hours or minutes.
305 |
306 | 2.2.13. eventid
307 |
308 | eventid MAY be present. If set, the returned data set will be
309 | filtered to a specific event. eventid MUST be a string representing
310 | the event id as an integer.
311 |
312 | {
313 | "returnFormat": "json",
314 | "eventid": 1
315 | }
316 |
317 | 2.2.14. withAttachments
318 |
319 | withAttachments MAY be present. If set to True (1), the returned
320 | data set will include the attachment(s) matching the query.
321 | withAttachments MUST be an integer set as 1 (True) to include the
322 | attachment(s). If not, the attachment(s) won't be included in the
323 | results.
324 |
325 | 2.2.15. uuid
326 |
327 | 2.2.16. publish_timestamp
328 |
329 |
330 |
331 |
332 |
333 |
334 |
335 |
336 | Dulaunoy & Iklody Expires April 11, 2019 [Page 6]
337 |
338 | Internet-Draft MISP query format October 2018
339 |
340 |
341 | 2.2.17. timestamp
342 |
343 | 2.2.18. published
344 |
345 | 2.2.19. enforceWarninglist
346 |
347 | 2.2.20. to_ids
348 |
349 | 2.2.21. deleted
350 |
351 | 2.2.22. includeEventUuid
352 |
353 | 2.2.23. event_timestamp
354 |
355 | 2.2.24. sgReferenceOnly
356 |
357 | 2.2.25. eventinfo
358 |
359 | 2.2.26. searchall
360 |
361 | 2.2.27. requested_attributes
362 |
363 | 2.2.28. includeContext
364 |
365 | 3. Security Considerations
366 |
367 | MISP threat intelligence instances might contain sensitive or
368 | confidential information. Adequate access control and encryption
369 | measures shall be implemented to ensure the confidentiality of the
370 | threat intelligence.
371 |
372 | Adversaries might include malicious content in MISP queries.
373 | Implementation MUST consider the input of malicious inputs beside the
374 | standard threat information that might already include malicious
375 | intended inputs.
376 |
377 | 4. Acknowledgements
378 |
379 | The authors wish to thank all the MISP community who are supporting
380 | the creation of open standards in threat intelligence sharing. A
381 | special thank to all the committees which triggered us to come with
382 | better and flexible format.
383 |
384 | 5. References
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 | Dulaunoy & Iklody Expires April 11, 2019 [Page 7]
393 |
394 | Internet-Draft MISP query format October 2018
395 |
396 |
397 | 5.1. Normative References
398 |
399 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
400 | Requirement Levels", BCP 14, RFC 2119,
401 | DOI 10.17487/RFC2119, March 1997,
402 | .
403 |
404 | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
405 | Interchange Format", STD 90, RFC 8259,
406 | DOI 10.17487/RFC8259, December 2017,
407 | .
408 |
409 | 5.2. Informative References
410 |
411 | [MISP-C] MISP, "MISP core format", .
413 |
414 | [MISP-P] MISP, "MISP Project - Malware Information Sharing Platform
415 | and Threat Sharing", .
416 |
417 | Authors' Addresses
418 |
419 | Alexandre Dulaunoy
420 | Computer Incident Response Center Luxembourg
421 | 16, bd d'Avranches
422 | Luxembourg L-1160
423 | Luxembourg
424 |
425 | Phone: +352 247 88444
426 | Email: alexandre.dulaunoy@circl.lu
427 |
428 |
429 | Andras Iklody
430 | Computer Incident Response Center Luxembourg
431 | 16, bd d'Avranches
432 | Luxembourg L-1160
433 | Luxembourg
434 |
435 | Phone: +352 247 88444
436 | Email: andras.iklody@circl.lu
437 |
438 |
439 |
440 |
441 |
442 |
443 |
444 |
445 |
446 |
447 |
448 | Dulaunoy & Iklody Expires April 11, 2019 [Page 8]
449 |
--------------------------------------------------------------------------------
/misp-query-format/raw.md.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 | MISP query format
14 |
15 |
16 | Computer Incident Response Center Luxembourg
17 |
18 |
19 | 16, bd d'Avranches
20 | Luxembourg
21 | L-1160
22 | Luxembourg
23 |
24 |
25 | +352 247 88444
26 | alexandre.dulaunoy@circl.lu
27 |
28 |
29 |
30 |
31 | Computer Incident Response Center Luxembourg
32 |
33 |
34 | 16, bd d'Avranches
35 | Luxembourg
36 | L-1160
37 | Luxembourg
38 |
39 |
40 | +352 247 88444
41 | andras.iklody@circl.lu
42 |
43 |
44 |
45 |
46 |
47 | Security
48 |
49 |
50 |
51 |
52 | This document describes the MISP query format used to search MISP (Malware Information and threat Sharing Platform) threat intelligence instances.
53 | MISP query format is a simple format used to query MISP instances over a REST (Representational State Transfer ) interface.
54 | The query format includes the JSON format to describe the query and the minimal API access to perform the query. The JSON format includes the overall structure along with the semantic associated for each respective key. The goal of the format is to query MISP threat intelligence instances can feed and integrate with network security devices (such as firewall, network intrusion detection system, routers, SIEMs), endpoint security devices or monitoring devices.
55 |
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 | Sharing threat information became a fundamental requirements in the Internet, security and intelligence community at large. Threat
65 | information can include indicators of compromise, malicious file indicators, financial fraud indicators
66 | or even detailed information about a threat actor. MISP started as an open source project in late 2011 and
67 | the MISP format started to be widely used as an exchange format within the community in the past years. The core format
68 | is described in an Internet-Draft as misp-core-format and contain the standard MISP JSON format used for threat
69 | intelligence.
70 |
71 | The aim of this document is to describe the specification of the MISP query format and how the query can be perform against a REST interface.
72 |
73 |
74 |
75 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
76 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
77 | document are to be interpreted as described in RFC 2119 .
78 |
79 |
80 |
81 |
82 |
83 |
84 |
85 | The MISP query format is in the JSON format.
86 |
87 |
88 |
89 |
90 |
91 |
92 | returnFormat MUST be present. returnFormat sets the type of output format. MISP allows multiple format (depending of the configuration):
93 |
94 |
95 | value
96 | Description
97 |
98 | jsonMISP JSON core format as described in
99 | xmlMISP XML format
100 | openiocOpenIOC format
101 | suricataSuricata NIDS format
102 | snortSnort NIDS format
103 | csvCSV format
104 | rpzResponse policy zone format
105 | textRaw value list format
106 |
107 |
108 |
109 |
110 | limit MAY be present. If present, the page parameter MUST also be supplied. limit sets the number of returned elements when paginating, depending on the scope of the request (x number of attributes or x number of events) as converted into the output format.
111 |
112 |
113 |
114 |
115 | page MAY be present. If present, the page parameter MUST also be supplied. page generates the offset for the pagination and will return a result set consisting of a slice of the query results starting with offset (limit * page) + 1 and ending with (limit * (page+1)).
116 |
117 |
118 |
119 |
120 | value MAY be present. If set, the returned data set will be filtered on the attribute value field. value MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters.
121 |
122 |
123 |
124 |
125 | type MAY be present. If set, the returned data set will be filtered on the attribute type field. type MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters. The list of valid attribute types is described in the MISP core format in the attribute type section.
126 |
127 |
128 |
129 |
130 | category MAY be present. If set, the returned data set will be filtered on the attribute category field. category MAY be a string or a sub-string, the latter of which start with, ends with or is encapsulated in wildcard (\%) characters. The list of valid categories is described in the MISP core format in the attribute type section.
131 |
132 | A sample query to lookup for the last 30 days of indicators in the Financial fraud category and output in CSV format:
133 |
134 |
135 |
136 | {
137 | "returnFormat": "csv",
138 | "last": "30d",
139 | "category": "Financial fraud"
140 | }
141 |
142 |
143 |
144 |
145 |
146 |
147 | MISP threat intelligence instances might contain sensitive or confidential information. Adequate access control and encryption measures shall be implemented to ensure the confidentiality of the threat intelligence.
148 |
149 | Adversaries might include malicious content in MISP queries. Implementation MUST consider the input of malicious inputs beside the
150 | standard threat information that might already include malicious intended inputs.
151 |
152 |
153 |
154 |
155 | The authors wish to thank all the MISP community who are supporting the creation
156 | of open standards in threat intelligence sharing. A special thank to all the committees which
157 | triggered us to come with better and flexible format.
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 |
169 |
170 | MISP core format
171 |
172 |
173 |
174 |
175 |
176 |
177 | MISP Project - Malware Information Sharing Platform and Threat Sharing
178 |
179 |
180 |
181 |
182 |
183 |
184 |
185 |
186 |
--------------------------------------------------------------------------------
/misp-taxonomy-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
10 |
--------------------------------------------------------------------------------
/misp-warninglist-format/raw.md:
--------------------------------------------------------------------------------
1 | % Title = "MISP warning lists format"
2 | % abbrev = "MISP warning lists format"
3 | % category = "info"
4 | % docName = "draft-dulaunoy-misp-warninglists-format"
5 | % ipr= "trust200902"
6 | % area = "Security"
7 | %
8 | % date = 2018-04-01T00:00:00Z
9 | %
10 | % [[author]]
11 | % initials="A."
12 | % surname="Dulaunoy"
13 | % fullname="Alexandre Dulaunoy"
14 | % abbrev="CIRCL"
15 | % organization = "Computer Incident Response Center Luxembourg"
16 | % [author.address]
17 | % email = "alexandre.dulaunoy@circl.lu"
18 | % phone = "+352 247 88444"
19 | % [author.address.postal]
20 | % street = "16, bd d'Avranches"
21 | % city = "Luxembourg"
22 | % code = "L-1611"
23 | % country = "Luxembourg"
24 | % [[author]]
25 | % initials="A."
26 | % surname="Iklody"
27 | % fullname="Andras Iklody"
28 | % abbrev="CIRCL"
29 | % organization = "Computer Incident Response Center Luxembourg"
30 | % [author.address]
31 | % email = "andras.iklody@circl.lu"
32 | % phone = "+352 247 88444"
33 | % [author.address.postal]
34 | % street = " 16, bd d'Avranches"
35 | % city = "Luxembourg"
36 | % code = "L-1611"
37 | % country = "Luxembourg"
38 | % [[author]]
39 | % initials="D."
40 | % surname="Servili"
41 | % fullname="Deborah Servili"
42 | % abbrev="CIRCL"
43 | % organization = "Computer Incident Response Center Luxembourg"
44 | % [author.address]
45 | % email = "deborah.servili@circl.lu"
46 | % phone = "+352 247 88444"
47 | % [author.address.postal]
48 | % street = " 16, bd d'Avranches"
49 | % city = "Luxembourg"
50 | % code = "L-1611"
51 | % country = "Luxembourg"
52 |
53 |
54 |
55 | .# Abstract
56 |
57 | This document describes the MISP warninglist format which describes a simple JSON format to represent warninglists that can be used in MISP. A public directory of MISP warninglists is available and relies on the MISP warninglist format. MISP warninglists are used to detect false positives inside the attributes of a MISP event. MISP warninglists is a public repository composed of list of hostnames, ip addresses and various other collections of data that can be used to detect false positives.
58 |
59 | {mainmatter}
60 |
61 | # Introduction
62 |
63 | Sharing threat information became a fundamental requirements on the Internet, security and intelligence community at large. Threat information n include indicators of compromise, malicious file indicators, financial fraud indicators or even detailed information about a threat actor. However, it sometimes happens that analysts make mistakes and start to share informations that can be considered as false positive, leading to some errors in analysis. MISP warninglists have been created in order to detect such mistakes more easily.
64 |
65 | MISP warninglists is a public repository of known false positives collections, such as hash values of empty files, known domains and hostnames from Google or even security providers or vendors blog domains.
66 |
67 | ## Conventions and Terminology
68 |
69 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
70 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
71 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
72 |
73 | # Format
74 |
75 | Warninglists are represented as a JSON [@!RFC8259] dictionary.
76 |
77 | ## Overview
78 |
79 | The MISP warninglist format uses the JSON [@!RFC8259] format. Each warninglist is represented as a JSON object with meta information including the following fields: name, description, version, type, matching_attributes, list.
80 |
81 | name defines the name of the warninglist. The name is represented as a string and **MUST** be present. The description is represented as a string and **MUST** be present. The version is represented as a decimal and **MUST** be present. matching_attributes is represented as an array containing one or more values and is **RECOMMENDED**. type is represented as a string from an non exaustive list and **MUST** be present.
82 |
83 | list is represented as an array containing one or more values and **MUST** be present. list defines all values defined in the warninglist.
84 |
85 | #list
86 |
87 | The list array contains one or more strings which represents all the values referenced in the warninglist.
88 |
89 | Example of the empty-hashes warninglist:
90 | ~~~~
91 | {
92 | "name": "List of known hashes for empty files",
93 | "version": 2,
94 | "description": "Event contains one or more entries of empty files based on known hashed",
95 | "matching_attributes": [
96 | "md5",
97 | "sha1",
98 | "sha224",
99 | "sha256",
100 | "sha512",
101 | "filename|md5",
102 | "filename|sha1",
103 | "filename|sha224",
104 | "filename|sha256",
105 | "filename|sha512"
106 | ],
107 | "type": "string",
108 | "list": [
109 | "d41d8cd98f00b204e9800998ecf8427e",
110 | "da39a3ee5e6b4b0d3255bfef95601890afd80709",
111 | "d14a028c2a3a2bc9476102bb288234c415a2b01f828ea62ac5b3e42f",
112 | "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
113 | "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e"
114 | ]
115 | }
116 | ~~~~
117 |
118 | # Acknowledgements
119 |
120 | The authors wish to thank all the MISP community who are supporting the creation
121 | of open standards in threat intelligence sharing.
122 |
123 | {backmatter}
124 |
--------------------------------------------------------------------------------
/sightingdb-format/Makefile:
--------------------------------------------------------------------------------
1 | MMARK:=mmark -xml2 -page
2 |
3 | docs = $(wildcard *.md)
4 |
5 | all: $(docs)
6 | $(MMARK) $< > $<.xml
7 | xml2rfc --text $<.xml
8 | xml2rfc --html $<.xml
9 |
--------------------------------------------------------------------------------
/sightingdb-format/raw.md:
--------------------------------------------------------------------------------
1 | %%%
2 | Title = "SightingDB query format"
3 | abbrev = "SightingDB query format"
4 | category = "info"
5 | docName = "draft-tricaud-sightingdb-format"
6 | ipr= "trust200902"
7 | area = "Security"
8 |
9 | date = 2020-04-13T00:00:00Z
10 |
11 | [[author]]
12 | initials="S."
13 | surname="Tricaud"
14 | fullname="Sebastien Tricaud"
15 | abbrev="Devo Inc."
16 | organization = "Devo Inc."
17 | [author.address]
18 | email = "sebastien.tricaud@devo.com"
19 | phone = "+1 866-221-2254"
20 | [author.address.postal]
21 | street = "150 Cambridgepark Drive"
22 | city = "Cambridge, MA"
23 | code = "02140"
24 | country = "USA"
25 | %%%
26 |
27 | .# Abstract
28 |
29 | This document describes the format used by SightingDB to give automated context to a given Attribute
30 | by counting occurrences and tracking times of observability.
31 | SightingDB was designed to provide to MISP a Scalable and Fast way to store and retrieve Attributes.
32 |
33 | {mainmatter}
34 |
35 | # Introduction
36 |
37 | Adding context to any Attribute is the key that makes it useful. While there exist numerous ways of doing it,
38 | SightingDB does it by just counting.
39 | Whenever somebody retrieves an Attribute, this counting is provided, allowing anyone to understand whenever something
40 | was observed few or many times.
41 |
42 | ## Conventions and Terminology
43 |
44 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
45 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
46 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
47 |
48 | # Format
49 |
50 | ## Overview
51 |
52 | The SightingDB format is in JSON [@!RFC8259] format and used to query a SightingDB compatible connector. In SightingDB, a Sighting Object is composed of a single JSON object. This object contains the following fields: value, first_seen, last_seen, count, tags, ttl and consensus.
53 |
54 | ### Attribute Storage
55 |
56 | The fields described previously describe an Attribute and all the required characteristics. However they are stored in a Namespace. A Namespace is similar to a path in a file-system where the same file can be stored in multiple places.
57 |
58 | ### Namespace
59 |
60 | A Namespace with multiple levels **MUST** be separated with the slash '/' character. There is no specification on how they are structured, since it depends on the use cases.
61 |
62 | A Namespace starting with the underscore '_' character means it is private and internal to SightingDB. There are all reserved for the engine and **MUST** NOT be used.
63 |
64 | Reserved namespaces are:
65 |
66 | _expired/: Which contains all the attributes that expired, preserving the origin namespace
67 |
68 | _shadow/: When a value is searched and does not exists, it is stored there
69 |
70 | _config: Configuration
71 |
72 | _all: All the Attributes in one place, used to retrieve the 'consensus' property.
73 |
74 | The Attribute Key MUST always be the last part of the Namespace.
75 |
76 | #### Sample Namespaces
77 |
78 | /Organization1/service/ipv4: Store values for ipv4 keys in /Organization1/service
79 |
80 | /everything/domain: Store domains in /everything
81 |
82 | ### Attribute fields
83 |
84 | #### value
85 |
86 | The attribute value, used to store and retrieve information about an attribute. Note that value is not returned back in the JSON object, since it is queried, it is known. The Value is described in a section below, as it is very specific and can be either "as is", a hash, encoded in base64 or any other convenient mechanism.
87 |
88 | The value implementation **MUST** offer at least: 1) Raw value 2) Base64 URL Encoded 3) SHA256 Hash
89 |
90 | #### first_seen
91 |
92 | Time in UTC of the first time this value was captured
93 |
94 | #### last_seen
95 |
96 | Time in UTC of the last time this value was captured
97 |
98 | #### count
99 |
100 | How many time this value was written
101 |
102 | #### tags
103 |
104 | Tags follow how they are defined in MISP using the MISP Taxonomy. Each Tag is separated with the ';' character.
105 |
106 | #### ttl
107 |
108 | Time To Live, represents the expiration in seconds since the time the Attribute was created. Once it has expired, it moves in the private Namespace _expired.
109 |
110 | When an Attribute has this field set to 0, it means it is not set to expired. This is the default behavior.
111 |
112 | When an Attribute has this field set to a number greater than 0, the expiration status is computed only at retrieval time.
113 |
114 | #### consensus
115 |
116 | When a given Attribute Value is stored in different namespaces, the consensus field keeps track of them so it returns in how many different places this attributes exists. This is a simple counter.
117 |
118 | ## SightingDB Format - One Attribute
119 |
120 | ~~~~
121 | {
122 | "value":"127.0.0.1",
123 | "first_seen":1530394819,
124 | "last_seen":1572933618,
125 | "count":578391,
126 | "tags":"",
127 | "ttl":0,
128 | "consensus": 17
129 | }
130 | ~~~~
131 |
132 | ## Value
133 |
134 | The value submitted can be in multiple format according to the use-case. Any implementation **MUST** offer three alternatives:
135 |
136 | 1) Raw value: where nothing is encoded and the value is stored AS IS, such as show in the example above with the One Attribute in JSON.
137 |
138 | 2) SHA256: which prevents from seeing content (see Security Considerations), has a fixed size and is convenient for most requirements
139 |
140 | 3) Base64 URL: Where the specification of Base64 is followed, except the characters conflicting with an URL argument are replaced
141 |
142 | The value is configured as part of the Namespace. The private "_config" Namespace prefix stores this value storage mechanism.
143 |
144 | ### Configuring the value format for a Namespace
145 |
146 | If one has the Namespace "/Organization1/BU1/ip" and want to store those IP addresses in SHA256, it will be configured like this:
147 | The Namespace is kept but prefixed by "_config" and has a json object about value format set.
148 | "/_config/Organization1/BU1/ip"
149 |
150 | ~~~~
151 | {
152 | "value_format":"SHA256"
153 | }
154 | ~~~~
155 |
156 | Where "value_format" is either: "SHA256", "RAW" or "BASE64URL".
157 |
158 | ## Bulk
159 |
160 | When data must be sent and received in large amounts, it is preferable to embed in JSON all the objects at once. As such, for reading and writing, the format is the following:
161 |
162 | ~~~~
163 | {
164 | "items": [
165 | { "": "" },
166 | { "": "", "timestamp": }
167 | ]
168 | }
169 | ~~~~
170 |
171 | Where:
172 |
173 | namespace: is the wanted namespace where to store the value
174 |
175 | value: the value one want to track
176 |
177 | timestamp: **OPTIONAL** epoch timestamp to set the value at.
178 |
179 | The timestamp is how one can use SightingDB and use old datasets where the first seen and last seen is not relative to "right now".
180 |
181 | ### Request
182 |
183 | A Proper request with two items is made like this:
184 |
185 | ~~~~
186 | {
187 | "items": [
188 | { "/your/namespace": "127.0.0.1" },
189 | { "/your/other/namespace": "110812f67fa1e1f0117f6f3d70241c1a42a7b07711a93c2477cc516d9042f9db", "timestamp": 1586825229 }
190 | ]
191 | }
192 | ~~~~
193 |
194 | Which will either store or retrieve the wanted data.
195 |
196 | ### Response
197 |
198 | The response when retrieving sightings also has the list of items, in order, one per line of the results:
199 | ~~~~
200 | {
201 | "items": [
202 | {"value": "Octave_Hergebel", "first_seen":1530337182, "last_seen":1573110615, "count":93021, "tags":"", "ttl":0, "consensus": 1},
203 | {"value": "127.0.0.1", "first_seen":1562930418, "last_seen":1573110404, "count":1020492, "tags":"", "ttl":8912, "consensus": 3}
204 | ]
205 | }
206 | ~~~~
207 |
208 | # Security Considerations
209 |
210 | While this document solely focuses on the format, the reference implementation is SightingDB. The authentication, the data access is not handled by SightingDB.
211 | It is possible a value can leak if the access is too permissive.
212 |
213 | Even a Hashed value can be discovered, as re-hashing known values would match.
214 |
215 | # Acknowledgements
216 |
217 | The author wish to thank all the MISP community who are supporting the creation
218 | of open standards in threat intelligence sharing. As well as amazing feedback gathered
219 | during the MISP Summit 2019 in Luxembourg, in particular with Alexandre Dulaunoy and
220 | Andras Iklody.
221 |
222 | {backmatter}
223 |
--------------------------------------------------------------------------------
/sightingdb-format/raw.md.txt:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Network Working Group S. Tricaud
6 | Internet-Draft Devo Inc.
7 | Intended status: Informational April 13, 2020
8 | Expires: October 15, 2020
9 |
10 |
11 | SightingDB query format
12 | draft-tricaud-sightingdb-format
13 |
14 | Abstract
15 |
16 | This document describes the format used by SightingDB to give
17 | automated context to a given Attribute by counting occurrences and
18 | tracking times of observability. SightingDB was designed to provide
19 | to MISP a Scalable and Fast way to store and retrieve Attributes.
20 |
21 | Status of This Memo
22 |
23 | This Internet-Draft is submitted in full conformance with the
24 | provisions of BCP 78 and BCP 79.
25 |
26 | Internet-Drafts are working documents of the Internet Engineering
27 | Task Force (IETF). Note that other groups may also distribute
28 | working documents as Internet-Drafts. The list of current Internet-
29 | Drafts is at https://datatracker.ietf.org/drafts/current/.
30 |
31 | Internet-Drafts are draft documents valid for a maximum of six months
32 | and may be updated, replaced, or obsoleted by other documents at any
33 | time. It is inappropriate to use Internet-Drafts as reference
34 | material or to cite them other than as "work in progress."
35 |
36 | This Internet-Draft will expire on October 15, 2020.
37 |
38 | Copyright Notice
39 |
40 | Copyright (c) 2020 IETF Trust and the persons identified as the
41 | document authors. All rights reserved.
42 |
43 | This document is subject to BCP 78 and the IETF Trust's Legal
44 | Provisions Relating to IETF Documents
45 | (https://trustee.ietf.org/license-info) in effect on the date of
46 | publication of this document. Please review these documents
47 | carefully, as they describe your rights and restrictions with respect
48 | to this document. Code Components extracted from this document must
49 | include Simplified BSD License text as described in Section 4.e of
50 | the Trust Legal Provisions and are provided without warranty as
51 | described in the Simplified BSD License.
52 |
53 |
54 |
55 |
56 | Tricaud Expires October 15, 2020 [Page 1]
57 |
58 | Internet-Draft SightingDB query format April 2020
59 |
60 |
61 | Table of Contents
62 |
63 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 | 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
65 | 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 | 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
67 | 2.1.1. Attribute Storage . . . . . . . . . . . . . . . . . . 2
68 | 2.1.2. Namespace . . . . . . . . . . . . . . . . . . . . . . 3
69 | 2.1.3. Attribute fields . . . . . . . . . . . . . . . . . . 3
70 | 2.2. SightingDB Format - One Attribute . . . . . . . . . . . . 4
71 | 2.3. Value . . . . . . . . . . . . . . . . . . . . . . . . . . 5
72 | 2.3.1. Configuring the value format for a Namespace . . . . 5
73 | 2.4. Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . 5
74 | 2.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 6
75 | 2.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 6
76 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
77 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
78 | 5. Normative References . . . . . . . . . . . . . . . . . . . . 7
79 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
80 |
81 | 1. Introduction
82 |
83 | Adding context to any Attribute is the key that makes it useful.
84 | While there exist numerous ways of doing it, SightingDB does it by
85 | just counting. Whenever somebody retrieves an Attribute, this
86 | counting is provided, allowing anyone to understand whenever
87 | something was observed few or many times.
88 |
89 | 1.1. Conventions and Terminology
90 |
91 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
92 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
93 | document are to be interpreted as described in RFC 2119 [RFC2119].
94 |
95 | 2. Format
96 |
97 | 2.1. Overview
98 |
99 | The SightingDB format is in JSON [RFC8259] format and used to query a
100 | SightingDB compatible connector. In SightingDB, a Sighting Object is
101 | composed of a single JSON object. This object contains the following
102 | fields: value, first_seen, last_seen, count, tags, ttl and consensus.
103 |
104 | 2.1.1. Attribute Storage
105 |
106 | The fields described previously describe an Attribute and all the
107 | required characteristics. However they are stored in a Namespace. A
108 |
109 |
110 |
111 |
112 | Tricaud Expires October 15, 2020 [Page 2]
113 |
114 | Internet-Draft SightingDB query format April 2020
115 |
116 |
117 | Namespace is similar to a path in a file-system where the same file
118 | can be stored in multiple places.
119 |
120 | 2.1.2. Namespace
121 |
122 | A Namespace with multiple levels MUST be separated with the slash '/'
123 | character. There is no specification on how they are structured,
124 | since it depends on the use cases.
125 |
126 | A Namespace starting with the underscore '_' character means it is
127 | private and internal to SightingDB. There are all reserved for the
128 | engine and MUST NOT be used.
129 |
130 | Reserved namespaces are:
131 |
132 | _expired/: Which contains all the attributes that expired, preserving
133 | the origin namespace
134 |
135 | _shadow/: When a value is searched and does not exists, it is stored
136 | there
137 |
138 | _config: Configuration
139 |
140 | _all: All the Attributes in one place, used to retrieve the
141 | 'consensus' property.
142 |
143 | The Attribute Key MUST always be the last part of the Namespace.
144 |
145 | 2.1.2.1. Sample Namespaces
146 |
147 | /Organization1/service/ipv4: Store values for ipv4 keys in
148 | /Organization1/service
149 |
150 | /everything/domain: Store domains in /everything
151 |
152 | 2.1.3. Attribute fields
153 |
154 | 2.1.3.1. value
155 |
156 | The attribute value, used to store and retrieve information about an
157 | attribute. Note that value is not returned back in the JSON object,
158 | since it is queried, it is known. The Value is described in a
159 | section below, as it is very specific and can be either "as is", a
160 | hash, encoded in base64 or any other convenient mechanism.
161 |
162 | The value implementation MUST offer at least: 1) Raw value 2) Base64
163 | URL Encoded 3) SHA256 Hash
164 |
165 |
166 |
167 |
168 | Tricaud Expires October 15, 2020 [Page 3]
169 |
170 | Internet-Draft SightingDB query format April 2020
171 |
172 |
173 | 2.1.3.2. first_seen
174 |
175 | Time in UTC of the first time this value was captured
176 |
177 | 2.1.3.3. last_seen
178 |
179 | Time in UTC of the last time this value was captured
180 |
181 | 2.1.3.4. count
182 |
183 | How many time this value was written
184 |
185 | 2.1.3.5. tags
186 |
187 | Tags follow how they are defined in MISP using the MISP Taxonomy.
188 | Each Tag is separated with the ';' character.
189 |
190 | 2.1.3.6. ttl
191 |
192 | Time To Live, represents the expiration in seconds since the time the
193 | Attribute was created. Once it has expired, it moves in the private
194 | Namespace _expired.
195 |
196 | When an Attribute has this field set to 0, it means it is not set to
197 | expired. This is the default behavior.
198 |
199 | When an Attribute has this field set to a number greater than 0, the
200 | expiration status is computed only at retrieval time.
201 |
202 | 2.1.3.7. consensus
203 |
204 | When a given Attribute Value is stored in different namespaces, the
205 | consensus field keeps track of them so it returns in how many
206 | different places this attributes exists. This is a simple counter.
207 |
208 | 2.2. SightingDB Format - One Attribute
209 |
210 | {
211 | "value":"127.0.0.1",
212 | "first_seen":1530394819,
213 | "last_seen":1572933618,
214 | "count":578391,
215 | "tags":"",
216 | "ttl":0,
217 | "consensus": 17
218 | }
219 |
220 |
221 |
222 |
223 |
224 | Tricaud Expires October 15, 2020 [Page 4]
225 |
226 | Internet-Draft SightingDB query format April 2020
227 |
228 |
229 | 2.3. Value
230 |
231 | The value submitted can be in multiple format according to the use-
232 | case. Any implementation MUST offer three alternatives:
233 |
234 | 1. Raw value: where nothing is encoded and the value is stored AS
235 | IS, such as show in the example above with the One Attribute in
236 | JSON.
237 |
238 | 2. SHA256: which prevents from seeing content (see Security
239 | Considerations), has a fixed size and is convenient for most
240 | requirements
241 |
242 | 3. Base64 URL: Where the specification of Base64 is followed, except
243 | the characters conflicting with an URL argument are replaced
244 |
245 | The value is configured as part of the Namespace. The private
246 | "_config" Namespace prefix stores this value storage mechanism.
247 |
248 | 2.3.1. Configuring the value format for a Namespace
249 |
250 | If one has the Namespace "/Organization1/BU1/ip" and want to store
251 | those IP addresses in SHA256, it will be configured like this: The
252 | Namespace is kept but prefixed by "_config" and has a json object
253 | about value format set. "/_config/Organization1/BU1/ip"
254 |
255 | {
256 | "value_format":"SHA256"
257 | }
258 |
259 | Where "value_format" is either: "SHA256", "RAW" or "BASE64URL".
260 |
261 | 2.4. Bulk
262 |
263 | When data must be sent and received in large amounts, it is
264 | preferable to embed in JSON all the objects at once. As such, for
265 | reading and writing, the format is the following:
266 |
267 | {
268 | "items": [
269 | { "": "" },
270 | { "": "", "timestamp": }
271 | ]
272 | }
273 |
274 | Where:
275 |
276 | namespace: is the wanted namespace where to store the value
277 |
278 |
279 |
280 | Tricaud Expires October 15, 2020 [Page 5]
281 |
282 | Internet-Draft SightingDB query format April 2020
283 |
284 |
285 | value: the value one want to track
286 |
287 | timestamp: OPTIONAL epoch timestamp to set the value at.
288 |
289 | The timestamp is how one can use SightingDB and use old datasets
290 | where the first seen and last seen is not relative to "right now".
291 |
292 | 2.4.1. Request
293 |
294 | A Proper request with two items is made like this:
295 |
296 | {
297 | "items": [
298 | { "/your/namespace": "127.0.0.1" },
299 | { "/your/other/namespace": "110812f67fa1e1f0117f6f3d70241c1a42a7b07711a93c2477cc516d9042f9db", "timestamp": 1586825229 }
300 | ]
301 | }
302 |
303 | Which will either store or retrieve the wanted data.
304 |
305 | 2.4.2. Response
306 |
307 | The response when retrieving sightings also has the list of items, in
308 | order, one per line of the results:
309 |
310 | {
311 | "items": [
312 | {"value": "Octave_Hergebel", "first_seen":1530337182, "last_seen":1573110615, "count":93021, "tags":"", "ttl":0, "consensus": 1},
313 | {"value": "127.0.0.1", "first_seen":1562930418, "last_seen":1573110404, "count":1020492, "tags":"", "ttl":8912, "consensus": 3}
314 | ]
315 | }
316 |
317 | 3. Security Considerations
318 |
319 | While this document solely focuses on the format, the reference
320 | implementation is SightingDB. The authentication, the data access is
321 | not handled by SightingDB. It is possible a value can leak if the
322 | access is too permissive.
323 |
324 | Even a Hashed value can be discovered, as re-hashing known values
325 | would match.
326 |
327 | 4. Acknowledgements
328 |
329 | The author wish to thank all the MISP community who are supporting
330 | the creation of open standards in threat intelligence sharing. As
331 | well as amazing feedback gathered during the MISP Summit 2019 in
332 | Luxembourg, in particular with Alexandre Dulaunoy and Andras Iklody.
333 |
334 |
335 |
336 | Tricaud Expires October 15, 2020 [Page 6]
337 |
338 | Internet-Draft SightingDB query format April 2020
339 |
340 |
341 | 5. Normative References
342 |
343 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
344 | Requirement Levels", BCP 14, RFC 2119,
345 | DOI 10.17487/RFC2119, March 1997,
346 | .
347 |
348 | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
349 | Interchange Format", STD 90, RFC 8259,
350 | DOI 10.17487/RFC8259, December 2017,
351 | .
352 |
353 | Author's Address
354 |
355 | Sebastien Tricaud
356 | Devo Inc.
357 | 150 Cambridgepark Drive
358 | Cambridge, MA 02140
359 | USA
360 |
361 | Phone: +1 866-221-2254
362 | Email: sebastien.tricaud@devo.com
363 |
364 |
365 |
366 |
367 |
368 |
369 |
370 |
371 |
372 |
373 |
374 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 | Tricaud Expires October 15, 2020 [Page 7]
393 |
--------------------------------------------------------------------------------
/threat-actor-naming/build.sh:
--------------------------------------------------------------------------------
1 | /home/adulau/git/mmark/mmark raw.md >threat-actor-naming.xml
2 | xml2rfc --html threat-actor-naming.xml
3 | xml2rfc threat-actor-naming.xml
4 | cp threat-actor-naming.txt /home/adulau/git/misp-standard.org/rfc
5 | cp threat-actor-naming.html /home/adulau/git/misp-standard.org/rfc
6 |
--------------------------------------------------------------------------------
/threat-actor-naming/raw.md:
--------------------------------------------------------------------------------
1 | %%%
2 | Title = "Recommendations on Naming Threat Actors"
3 | abbrev = "Recommendations on Naming Threat Actors"
4 | category = "info"
5 | docName = "draft-dulaunoy-threat-actor-naming"
6 | ipr= "trust200902"
7 | area = "Security"
8 | date = 2024-12-21T00:00:00Z
9 | submissiontype = "independent"
10 |
11 | [seriesInfo]
12 | name = "Internet-Draft"
13 | value = "draft-00"
14 | stream = "independent"
15 | status = "informational"
16 |
17 | [[author]]
18 | initials="A."
19 | surname="Dulaunoy"
20 | fullname="Alexandre Dulaunoy"
21 | abbrev="CIRCL"
22 | organization = "Computer Incident Response Center Luxembourg"
23 | [author.address]
24 | email = "alexandre.dulaunoy@circl.lu"
25 | phone = "+352 247 88444"
26 | [author.address.postal]
27 | street = "122, rue Adolphe Fischer"
28 | city = "Luxembourg"
29 | code = "L-1521"
30 | country = "Luxembourg"
31 | [[author]]
32 | initials="P."
33 | surname="Bourmeau"
34 | fullname="Pauline Bourmeau"
35 | abbrev="Cubessa"
36 | organization = "Cubessa"
37 | [author.address]
38 | email = "Pauline@cubessa.io"
39 | phone = ""
40 | %%%
41 |
42 | .# Abstract
43 |
44 | This document provides advice on the naming of threat actors (also known as malicious actors).
45 | The objective is to provide practical advice for organizations such as security vendors or organizations attributing
46 | incidents to a group of threat actors. It also discusses the implications of naming a threat actor for intelligence analysts
47 | and threat intelligence platforms such as MISP [@?MISP-P].
48 |
49 | {mainmatter}
50 |
51 | # Introduction
52 |
53 | In threat intelligence, a name can be assigned to a threat actor without specific guidelines. This leads to issues such
54 | as:
55 |
56 | - 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).
57 | - Ambiguity in the words used to name the threat actor in different contexts (e.g., using common words).
58 | - 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?).
59 | - Confusion between techniques/tools used by a threat actor versus its name (e.g., naming a threat actor after a specific malware used).
60 | - 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?).
61 | - Lack of time-based information about the threat actor name, such as date of naming or a UUID.
62 | - 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.
63 |
64 | This document proposes a set of guidelines for naming threat actors. The goal is to reduce the issues mentioned above.
65 |
66 |
67 | ## Conventions and Terminology
68 |
69 | The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**",
70 | "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this
71 | document are to be interpreted as described in RFC 2119 [@!RFC2119].
72 |
73 | # Recommendations
74 |
75 | The recommendations listed below provide a minimal set of guidelines when assigning a new name to a threat actor.
76 |
77 | ## Reusing Threat Actor Names
78 |
79 | 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.
80 |
81 | ## Uniqueness
82 |
83 | 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.
84 |
85 | ## Format
86 |
87 | 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.
88 |
89 | ## Encoding
90 |
91 | 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.
92 |
93 | ## Avoid Confusing Actor Names with Malware Names
94 |
95 | 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.
96 |
97 | ## Directory
98 |
99 | A reference registry of threat actors is **RECOMMENDED** to ensure consistency of names across different parties such as the threat actor MISP galaxy [@!MISP-G].
100 |
101 | # Examples
102 |
103 | 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:
104 |
105 | - APT-1
106 | - TA-505
107 |
108 | The following threat actor names are considered examples to avoid:
109 |
110 | - GIF89a (Word also used for the GIF header)
111 | - ShadyRAT (Confusion between the name and the tool)
112 | - Group 3 (Common name used for other use-cases)
113 | - ZooPark (Name is used to describe something else)
114 |
115 | # Security Considerations
116 |
117 | 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.
118 |
119 | # Acknowledgements
120 |
121 | The authors wish to thank all contributors who provided feedback through the now-defunct Twitter and other new social networks.
122 |
123 | # References
124 |
125 |
126 |
127 |
128 | MISP Project - Open Source Threat Intelligence Platform and Open Standards For Threat Information Sharing
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 | MISP Taxonomies - shared and common vocabularies of tags
137 |
138 |
139 |
140 |
141 |
142 |
143 |
144 | MISP Galaxy - Public repository
145 |
146 |
147 |
148 |
149 |
150 |
151 | {backmatter}
152 |
--------------------------------------------------------------------------------
/threat-actor-naming/threat-actor-naming.txt:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | Network Working Group A. Dulaunoy
6 | Internet-Draft CIRCL
7 | Intended status: Informational P. Bourmeau
8 | Expires: 24 June 2025 Cubessa
9 | 21 December 2024
10 |
11 |
12 | Recommendations on Naming Threat Actors
13 | draft-00
14 |
15 | Abstract
16 |
17 | This document provides advice on the naming of threat actors (also
18 | known as malicious actors). The objective is to provide practical
19 | advice for organizations such as security vendors or organizations
20 | attributing incidents to a group of threat actors. It also discusses
21 | the implications of naming a threat actor for intelligence analysts
22 | and threat intelligence platforms such as MISP [MISP-P].
23 |
24 | Status of This Memo
25 |
26 | This Internet-Draft is submitted in full conformance with the
27 | provisions of BCP 78 and BCP 79.
28 |
29 | Internet-Drafts are working documents of the Internet Engineering
30 | Task Force (IETF). Note that other groups may also distribute
31 | working documents as Internet-Drafts. The list of current Internet-
32 | Drafts is at https://datatracker.ietf.org/drafts/current/.
33 |
34 | Internet-Drafts are draft documents valid for a maximum of six months
35 | and may be updated, replaced, or obsoleted by other documents at any
36 | time. It is inappropriate to use Internet-Drafts as reference
37 | material or to cite them other than as "work in progress."
38 |
39 | This Internet-Draft will expire on 24 June 2025.
40 |
41 | Copyright Notice
42 |
43 | Copyright (c) 2024 IETF Trust and the persons identified as the
44 | document authors. All rights reserved.
45 |
46 | This document is subject to BCP 78 and the IETF Trust's Legal
47 | Provisions Relating to IETF Documents (https://trustee.ietf.org/
48 | license-info) in effect on the date of publication of this document.
49 | Please review these documents carefully, as they describe your rights
50 | and restrictions with respect to this document.
51 |
52 |
53 |
54 |
55 |
56 | Dulaunoy & Bourmeau Expires 24 June 2025 [Page 1]
57 |
58 | Internet-Draft Recommendations on Naming Threat Actors December 2024
59 |
60 |
61 | Table of Contents
62 |
63 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 | 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
65 | 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
66 | 2.1. Reusing Threat Actor Names . . . . . . . . . . . . . . . 3
67 | 2.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 3
68 | 2.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 | 2.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3
70 | 2.5. Avoid Confusing Actor Names with Malware Names . . . . . 4
71 | 2.6. Directory . . . . . . . . . . . . . . . . . . . . . . . . 4
72 | 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
73 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
74 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
75 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
76 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
77 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
78 | 7.2. Informative References . . . . . . . . . . . . . . . . . 5
79 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
80 |
81 | 1. Introduction
82 |
83 | In threat intelligence, a name can be assigned to a threat actor
84 | without specific guidelines. This leads to issues such as:
85 |
86 | * A proliferation of threat actor names generating overlaps or
87 | different names for similar threat actors (e.g., some threat
88 | actors have more than 10 synonyms).
89 | * Ambiguity in the words used to name the threat actor in different
90 | contexts (e.g., using common words).
91 | * Lack of a clearly defined text format to describe the same threat
92 | actor (e.g., Is the threat actor name case-sensitive? Is there a
93 | dash or a space between the words?).
94 | * Confusion between techniques/tools used by a threat actor versus
95 | its name (e.g., naming a threat actor after a specific malware
96 | used).
97 | * Lack of source and reasoning from vendors when they describe their
98 | threat actor names (e.g., did they name the threat actor after a
99 | specific set of campaigns or a specific set of targets?).
100 | * Lack of time-based information about the threat actor name, such
101 | as date of naming or a UUID.
102 | * Lack of an open, mirrored "registry" of reference, accessible to
103 | all, where a new threat actor name can be registered, or where all
104 | already named threat actors can be accessed. The "registry" can
105 | contain the time-based information mentioned above; it is a tool.
106 |
107 | This document proposes a set of guidelines for naming threat actors.
108 | The goal is to reduce the issues mentioned above.
109 |
110 |
111 |
112 | Dulaunoy & Bourmeau Expires 24 June 2025 [Page 2]
113 |
114 | Internet-Draft Recommendations on Naming Threat Actors December 2024
115 |
116 |
117 | 1.1. Conventions and Terminology
118 |
119 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
121 | document are to be interpreted as described in RFC 2119 [RFC2119].
122 |
123 | 2. Recommendations
124 |
125 | The recommendations listed below provide a minimal set of guidelines
126 | when assigning a new name to a threat actor.
127 |
128 | 2.1. Reusing Threat Actor Names
129 |
130 | Before creating a new threat actor name, you MUST consider a review
131 | of existing threat actor names from databases such as the threat
132 | actor MISP galaxy [MISP-G]. Proliferation of threat actor names is a
133 | significant challenge for day-to-day analyst work. If your defined
134 | threat actor matches an existing threat actor, you MUST reuse an
135 | existing threat actor name. If there is no matching threat actor
136 | name, you SHALL create a new threat actor name, following the best
137 | practices defined in this document.
138 |
139 | 2.2. Uniqueness
140 |
141 | When choosing a threat actor name, uniqueness is a critical property.
142 | The threat actor name MUST be unique and not already in use in
143 | different contexts. The name MUST NOT be a word from a dictionary,
144 | which could be used in other contexts.
145 |
146 | 2.3. Format
147 |
148 | The name of the threat actor SHALL be composed of a single word. If
149 | there are multiple parts, such as a decimal value or a counter, the
150 | values MUST be separated with a dash. Single words are preferred to
151 | ease keyword searches by analysts in public sources.
152 |
153 | 2.4. Encoding
154 |
155 | The name of the threat actor MUST be expressed in 7-bit ASCII.
156 | Assigning a localized name to a threat actor MAY create ambiguity due
157 | to different localized versions of the same threat actor.
158 |
159 |
160 |
161 |
162 |
163 |
164 |
165 |
166 |
167 |
168 | Dulaunoy & Bourmeau Expires 24 June 2025 [Page 3]
169 |
170 | Internet-Draft Recommendations on Naming Threat Actors December 2024
171 |
172 |
173 | 2.5. Avoid Confusing Actor Names with Malware Names
174 |
175 | The name of the threat actor MUST NOT be based on the tools,
176 | techniques, or patterns used by the threat actor. A notorious
177 | example in the threat intelligence community is Turla, which can
178 | refer to a threat actor but also to a malware used by this group or
179 | other groups.
180 |
181 | 2.6. Directory
182 |
183 | A reference registry of threat actors is RECOMMENDED to ensure
184 | consistency of names across different parties such as the threat
185 | actor MISP galaxy [MISP-G].
186 |
187 | 3. Examples
188 |
189 | Some known examples are included below and serve as references for
190 | good and bad practices in naming threat actors. The following threat
191 | actor names are considered good examples:
192 |
193 | * APT-1
194 | * TA-505
195 |
196 | The following threat actor names are considered examples to avoid:
197 |
198 | * GIF89a (Word also used for the GIF header)
199 | * ShadyRAT (Confusion between the name and the tool)
200 | * Group 3 (Common name used for other use-cases)
201 | * ZooPark (Name is used to describe something else)
202 |
203 | 4. Security Considerations
204 |
205 | Naming a threat actor could include sensitive references to a case or
206 | an incident. Before releasing a name, the creator MUST review the
207 | name to ensure no sensitive information is included in the threat
208 | actor name.
209 |
210 | 5. Acknowledgements
211 |
212 | The authors wish to thank all contributors who provided feedback
213 | through the now-defunct Twitter and other new social networks.
214 |
215 | 6. References
216 |
217 | 7. References
218 |
219 | 7.1. Normative References
220 |
221 |
222 |
223 |
224 | Dulaunoy & Bourmeau Expires 24 June 2025 [Page 4]
225 |
226 | Internet-Draft Recommendations on Naming Threat Actors December 2024
227 |
228 |
229 | [MISP-G] Community, M., "MISP Galaxy - Public repository",
230 | .
231 |
232 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
233 | Requirement Levels", BCP 14, RFC 2119,
234 | DOI 10.17487/RFC2119, March 1997,
235 | .
236 |
237 | 7.2. Informative References
238 |
239 | [MISP-P] Community, M., "MISP Project - Open Source Threat
240 | Intelligence Platform and Open Standards For Threat
241 | Information Sharing", .
242 |
243 | Authors' Addresses
244 |
245 | Alexandre Dulaunoy
246 | Computer Incident Response Center Luxembourg
247 | 122, rue Adolphe Fischer
248 | L-L-1521 Luxembourg
249 | Luxembourg
250 | Phone: +352 247 88444
251 | Email: alexandre.dulaunoy@circl.lu
252 |
253 |
254 | Pauline Bourmeau
255 | Cubessa
256 | Email: Pauline@cubessa.io
257 |
258 |
259 |
260 |
261 |
262 |
263 |
264 |
265 |
266 |
267 |
268 |
269 |
270 |
271 |
272 |
273 |
274 |
275 |
276 |
277 |
278 |
279 |
280 | Dulaunoy & Bourmeau Expires 24 June 2025 [Page 5]
281 |
--------------------------------------------------------------------------------
/threat-actor-naming/threat-actor-naming.xml:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 | Recommendations on Naming Threat Actors
7 | Computer Incident Response Center Luxembourg122, rue Adolphe Fischer
8 | Luxembourg
9 | L-1521
10 | Luxembourg
11 | +352 247 88444
12 | alexandre.dulaunoy@circl.lu
13 | Cubessa
14 | Pauline@cubessa.io
15 |
16 | Security
17 |
18 |
19 |
20 | This document provides advice on the naming of threat actors (also known as malicious actors).
21 | The objective is to provide practical advice for organizations such as security vendors or organizations attributing
22 | incidents to a group of threat actors. It also discusses the implications of naming a threat actor for intelligence analysts
23 | and threat intelligence platforms such as MISP .
24 |
25 |
26 |
27 |
28 |
29 |
30 | Introduction
31 | In threat intelligence, a name can be assigned to a threat actor without specific guidelines. This leads to issues such
32 | as:
33 |
34 |
35 |
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).
36 |
Ambiguity in the words used to name the threat actor in different contexts (e.g., using common words).
37 |
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?).
38 |
Confusion between techniques/tools used by a threat actor versus its name (e.g., naming a threat actor after a specific malware used).
39 |
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?).
40 |
Lack of time-based information about the threat actor name, such as date of naming or a UUID.
41 |
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.
42 |
43 | This document proposes a set of guidelines for naming threat actors. The goal is to reduce the issues mentioned above.
44 |
45 | Conventions and Terminology
46 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
47 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
48 | document are to be interpreted as described in RFC 2119 .
49 |
50 |
51 |
52 | Recommendations
53 | The recommendations listed below provide a minimal set of guidelines when assigning a new name to a threat actor.
54 |
55 | Reusing Threat Actor Names
56 | 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 . 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.
57 |
58 |
59 | Uniqueness
60 | 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.
61 |
62 |
63 | Format
64 | 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.
65 |
66 |
67 | Encoding
68 | 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.
69 |
70 |
71 | Avoid Confusing Actor Names with Malware Names
72 | 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.
73 |
74 |
75 | Directory
76 | A reference registry of threat actors is RECOMMENDED to ensure consistency of names across different parties such as the threat actor MISP galaxy .
77 |
78 |
79 |
80 | Examples
81 | 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:
82 |
83 |
84 |
APT-1
85 |
TA-505
86 |
87 | The following threat actor names are considered examples to avoid:
88 |
89 |
90 |
GIF89a (Word also used for the GIF header)
91 |
ShadyRAT (Confusion between the name and the tool)
92 |
Group 3 (Common name used for other use-cases)
93 |
ZooPark (Name is used to describe something else)
94 |
95 |
96 |
97 | Security Considerations
98 | 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.
99 |
100 |
101 | Acknowledgements
102 | The authors wish to thank all contributors who provided feedback through the now-defunct Twitter and other new social networks.
103 |
104 |
105 | References
106 |
107 |
108 |
109 |
110 |
111 | References
112 | Normative References
113 |
114 |
115 | MISP Galaxy - Public repository
116 |
117 |
118 |
119 |
120 |
121 |
122 | Informative References
123 |
124 |
125 | MISP Project - Open Source Threat Intelligence Platform and Open Standards For Threat Information Sharing
126 |
127 |
128 |
129 |
130 |
131 |
132 |
133 |
134 |
135 |
136 |
--------------------------------------------------------------------------------