Skip to content
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

Open
elhoim opened this issue Feb 5, 2019 · 3 comments
Open

Support multiple MISP Servers #10

elhoim opened this issue Feb 5, 2019 · 3 comments

Comments

@elhoim
Copy link
Member

elhoim commented Feb 5, 2019

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.

@cvandeplas
Copy link
Member

cvandeplas commented Mar 21, 2020

This is a challenging task.
Config wise we could allow misp_url, misp1_url, misp2_url, ... The code could multithread to do the background requests in parallel to speed up things.
We would also need to keep track from which MISP server the MISPEvent and MISPObject come from, otherwise we would not be able to pivot from there. Attributes don't need a reference, nor do Galaxy items (for now) as they use te public Galaxy repo.
Visually we'd also need to have a way to show where it comes from. Idea's on doing so are welcome.

When implemented feature request #18 From Maltego to MISP will also have a considerable impact.

@andurin
Copy link

andurin commented Jul 14, 2020

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.
While searching with pymisp against your mentionend misp_url I used to store the origniating misp url within the entity.

---------------------------------
| MISPEvent <entity>     |
---------------------------------
| misp_url: <source url> |
| EventID: 4711              |
| ....                                 |

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.
Yeah - challenging but I would like this feature too. If it would be interesting I could search my attic for the old (and maybe dirty) code.

Visually we'd also need to have a way to show where it comes from. Idea's on doing so are welcome.

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:

misp1_url: https:....
misp1_key: 12345asdf....
misp1_color: blue
...

After that it may be possible to use the misp_event_icon_{{color}}.png in the graph to have different colored Items?!

@cvandeplas
Copy link
Member

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 MISPEvent level, might also need to happen on MISPObject level.
On the other hand, the same event (uuid) could be on two distinct MISP Servers. So we might not need to store the URL at all. The MISPEvent display name should definitely change to something more human friendly and not instance specific.
It would still be interesting to be able to track where it came from, to support the analyst.

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 Search in MISP X and one Search in MISP Y)
But we could consider adding an optional parameter to the transforms to allow people to manually create their own transform configuration manually (in Maltego) and specify a specific MISP server in the transform settings.

Pull Requests are definitely welcome if you're able to work on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants