Add Filebeat misp module #13805
Add Filebeat misp module #13805
Conversation
|
jenkins, test this |
|
I have yet to take a closer look, but in the pipeline, I think it would make sense to put the indicator in its separate field as well. E.g. put all IPs into a |
There was a problem hiding this comment.
This importer be good to have, and I'm happy to see this happening at the same time as ECS is working on the "threat" field set :-)
This is just a first cursory review. Noticed a few small things, see the comments.
One big no-no, however: please nest the fields under misp., as this hasn't been normalized vs other sources of IOCs, and will conflict (or at least confuse people) vs the upcoming support for "threat" in ECS.
| This defines the organizational level at which this Intrusion Set typically works. | ||
| Open Vocab - attack-resource-level-ov | ||
|
|
||
| - name: primary_motivation |
There was a problem hiding this comment.
What about using nesting, in order to keep all motivation levels grouped, within an event?
.motivation.primary.motivation.secondary.motivation.personal
There was a problem hiding this comment.
Not sure whether this is a good idea, since the existing fields are compliant to the STIX spec, hence potentially interoperable with other vendors.
x-pack/filebeat/module/misp/threat/test/misp-test.json.log-expected.json
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/misp/threat/test/misp-test.json.log-expected.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I have yet to take a closer look, but in the pipeline, I think it would make sense to put the indicator in its separate field as well. E.g. put all IPs into a
threat.threat_indicator.ipfield. That way, it would be very easy to get a list of all known bad IPs, search for specific IPs, or build visualizations/dashboards on top of the data. We could have a field per indicator type (value of thetypefield coming from MISP).
Sounds good to me. I can add a few additional fields. But it will not be threat.threat_indicator.ip, it will be source.ip or detination.ip.
Why? If the indicator is an IP ("this IP is known bad"), shouldn't all such IPs be in the same field? |
In most cases, both source and destination fields will be populated. But certain threat intel indicators might only have source populated, e.g., DOS attacks, etc. Using source.ip and destination.ip also makes query easier since they use the same fields as the normal events. |
Makes sense. If a threat IP is not source/destination specific, would you populate both? |
Yes. Whether it is src or dest or both is specified in the original intel record, and it determines how the fields are populated |
|
What kinds of IOC records are we seeing with a source and destination IP? Most of the time they are IPs, domains, file hashes, mutexes, or other names |
|
Pinging @elastic/siem (Team:SIEM) |
|
jenkins, test this |
|
jenkins, test this |
| This is a filebeat module for reading threat intel information from the MISP platform (https://www.circl.lu/doc/misp/). It uses the httpjson input to access the MISP REST API interface. | ||
|
|
||
| The configuration in the config.yml file uses the following format: | ||
| var.api_key: specifies the API key to access MISP. |
There was a problem hiding this comment.
I think there's a bit of a formatting issue with the config example.
There was a problem hiding this comment.
Do you mean the indent before var.api.key? It is done on purpose. Maybe not the best way to do it?
There was a problem hiding this comment.
Yeah, I mean the indentation. I don’t think this is what you we’re going for.
Add Filebeat misp module to take threat intel from the MISP platform.