chrisr3d
commented
2 years ago Hey,
I played a bit with ZMQ and implemented a parse_misp_attribute function to handle single attributes
I also made sure we can use the parsing functions multiple times once the parser is declared, so it can easily be handled with a loop for instance.
We were however wondering what would make the more sense to parse since there are multiple types of requests which are visible for the ZMQ channel.
I mean in your case, you want to convert single attributes, which is possible a use case among others, but our interrogation was more about the kind of request we should consider or not. If you're looking at the ZMQ channel, you can see the action can be add, edit, and so on. And in the end you can see a single attribute multiple times in your ZMQ feed since it can be for example edited of deleted after creation.
So if somehow you have a script running and getting JSON from the ZMQ feed, passing the data like:
from misp_stix_converter import MISPtoSTIX21Parser
parser21 = MISPtoSTIX21Parser()
for attribute in whatever_process:
parser.parse_misp_attribute(attribute)it should work but there is no control over duplicates.
Also I looked at what is passed to ZMQ when you add or edit a MISP object, just out of curiosity to add more examples to this explanation, and this is even trickier: you can get each individual object attribute separately when the object is created, but if you modify it, only the modified object attributes are displayed in the ZMQ feed.
Our guess then was perhaps to only consider the publish event actions that are passed to ZMQ since publishing is the only action where you are sure the data is supposed to be shared and synchronised (MISP synchronises published data only for instance).
So I don't know what is the best option depending on the kind of data you want to handle. If you want to pass attributes on the go, the function is available (but there is no deduplication process since the purpose of the MISP -> STIX export feature is to handle the convertion), if the question is more about what would make the more sense we can still discuss it and see the options.
As a side note here I can also mention that if you want to export MISP attributes, there is a restSearch endpoint to export attributes collections which uses the parse_misp_attributes function that was already there in the library (it is not the ZMQ feed but still interesting to mention)
PS: by the way I tested the parse_misp_attribute function with some data I got from a ZMQ feed on my test machine, which looks like this, and it works for me but let me know if it fails at any point for you so I can fix it
mavam
Is your feature request related to a problem? Please describe.
I'm receiving a feed of MISP attributes via ZMQ and would like to parse them according to the mapping described in the documentation. I understand that I can parse events as follows:
I was looking for the analogous
parse_misp_attribute()function, which unfortunately doesn't exist. How should I proceed?Describe the solution you'd like
It would be great to hear whether a
parse_misp_attribute()function makes sense. Maybe it could parse attributes incrementally and the parser could accumulate state?Or is subscribing to the attribute stream alone futile? I would like to emit a feed of STIX objects/bundles from the 0mq feed of attributes, with exactly the implementation of this library.
Describe alternatives you've considered
n/t
Additional context
n/t
Code of Conduct