Proposal for #741
Summary
Adding a new top level field in which IOC information can be stored. The goal of this issue is to get an understanding and agreement on what the structure could be before creating a RFC.
Motivation:
With the upcoming changes to detections making it possible to match against Threat Intelligence indices it becomes
usefull to have a place in the ECS where IOC's (Threat intelligence) can be stored in a common format.
This proposal focuses on IOC's specifically without taking into account other types of Threat Intel and attempts to capture the required information whilest staying simple to not overly complicate the schema.
Detailed Design:
{
"ioc": {
"reference": [
"https://example.com/"
],
"value": "",
"type": "",
"provider": {
"name": "",
"creator": "",
"reference": ""
},
"original": ""
},
"threat": {},
"rule": {},
"vulnerability": {}
}
| field |
type |
description |
rationale |
| ioc.reference |
array |
List of links which provide context on an IOC |
Gathering information quickly about an unknown IOC is beneficial. |
| ioc.value |
keyword |
The IOC value, the "what" on which can be monitored. E.g a hash, domain, ip, etc |
A single field in which the IOC value is stored makes searching, correlation and matching a lot easier then having to think Now in what field would this type of IOC be stored |
| ioc.type |
keyword |
A given type of IOC hash, domain, ip, string, unknown |
A categorization field for IOC's, this should be one of the listed values |
| ioc.provider.name |
keyword |
Name of the provider; e.g abuse.ch, emergingthreats |
An identifier for where the IOC came from. |
| ioc.provider.creator |
keyword |
Name of who created the IOC |
An identifier for who created the IOC originally, some TIP's allow for community contributions and this field can hold the original creator |
| ioc.provider.reference |
keyword |
Link to the source of the IOC |
This makes it possible to quickly find the source of an IOC |
| ioc.original |
text |
Full text value of the IOC |
It can be beneficial to store the full IOC with the original "format" for later |
| threat |
object |
Optional addition of threat fields |
IOC can be directly related to specific threats making them mappable to MITRE ATT&CK. Where possible these fields should be populated so triggered IOC's can be correlated properly by analysts |
| rule |
object |
Optional addition of rule fields |
This would allow for relating an IOC to any monitoring rule's |
| vulnerability |
object |
Optional addition of vulnerability fields |
This makes it possible to relate an IOC to a vulnerabitly if wanted |
The threat, vulnerability and rule fields are explicitly mentioned to provide context on how information can be combined
Proposal for #741
Summary
Adding a new top level field in which IOC information can be stored. The goal of this issue is to get an understanding and agreement on what the structure could be before creating a RFC.
Motivation:
With the upcoming changes to detections making it possible to match against Threat Intelligence indices it becomes
usefull to have a place in the ECS where IOC's (Threat intelligence) can be stored in a common format.
This proposal focuses on IOC's specifically without taking into account other types of Threat Intel and attempts to capture the required information whilest staying simple to not overly complicate the schema.
Detailed Design:
{ "ioc": { "reference": [ "https://example.com/" ], "value": "", "type": "", "provider": { "name": "", "creator": "", "reference": "" }, "original": "" }, "threat": {}, "rule": {}, "vulnerability": {} }Now in what field would this type of IOC be storedhash,domain,ip,string,unknownabuse.ch,emergingthreatsThe
threat,vulnerabilityandrulefields are explicitly mentioned to provide context on how information can be combined