-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multiple MISP Servers #10
Comments
This is a challenging task. When implemented feature request #18 From Maltego to MISP will also have a considerable impact. |
A few years ago as I've detected canari I started nearly the same work as this project but I never get that far. Once upon that time my code was able to work with different MISP URLs.
For further pivoting based on a entity I did a lookup if misp_url was set in the entity and used that url for the next pymisp requests (getting objects, attributes, etc). I have to admit that I've ended up somewhere around here and I guess the challenges starts here since I never minded about where I need references and where not. IIRC I also saved the source misp url in attributes and objects and this broke the maltego correlation since I wasn't able to query a misp url attribute against other misp instances to see of other knows more about it.
Is this that mandatory? As long as I may have different external links right to the relevant MISP Events/Attributes in form of their misp urls I may find the information source in my browser. But one may create different colored iconsets for misp event entites and do s.th. in the config like:
After that it may be possible to use the |
In regards to visual: yes, your idea is an option. I was also thinking about http://maltego.blogspot.com/2019/02/fun-with-flags.html?m=1 In regards to the URL: indeed, this is an option on The config file (and remote server) will indeed need to be changed to support such a list of multiple servers. Let's not forget those that use remote transforms. Requests to each MISP server (when searching for attributes, ...) should happen in parallel (multithreaded) to prevent unneeded slowdowns. I believe Maltego's limitations will prevent us to have separate transforms for a specific MISP instance. (so one Pull Requests are definitely welcome if you're able to work on this! |
A potentially easier way would be when generating the mtz file, to also have a parameter in the configuration file to have the name of the MISP instance (ex.: superSecretServer), and also use that name in the transform folder within Maltego from MISP_maltego to MISP_maltego (superSecretServert).
This would allow users to create access for as many MISP instances as they want, and they could also easily select from which MISP instances that they can query.
The text was updated successfully, but these errors were encountered: