search

TheHive-Project / TheHive

TheHive: a Scalable, Open Source and Free Security Incident Response Platform
https://thehive-project.org
GNU Affero General Public License v3.0
3.44k stars 623 forks source link

Support Plugins in TheHive #631

Open billmurrin opened 6 years ago

billmurrin commented 6 years ago

Request Type

Feature Request

Work Environment

Question Answer
OS version (server) Linux / WSL...
OS version (client) Multiple
TheHive version / git hash Current and Develop
Package Type Multiple
Browser type & version Multiple

Problem Description

TheHive is reaching a point in its development where it should consider including Plugin support into various areas of the backend and the front-end. Each SOC has various tools, requirements, and unique organizational needs. Trying to fit all of these needs into the Core of TheHive is impossible. Supporting a robust plugin system will enable 3rd Party developers to expand features and support of TheHive while also saving the Core from bloat.

Steps to Reproduce

N/A

Possible Solutions

Scala based plugin management examples: https://vikashazrati.wordpress.com/2011/09/15/building-a-plugin-based-architecture-in-scala/ https://github.com/apache/incubator-toree/blob/master/plugins/src/main/scala/org/apache/toree/plugins/PluginManager.scala https://github.com/dacr/simple-plugin-architecture

Complementary information

UI related plugins could support new menu options, case options, configuration options, new tabs in the case, buttons, trending, reporting, etc. Backend options might include something like web hook plugins (send data directly to a solution from TheHive, ingestion of events/alerts from a given solution directly to TheHive alerts/cases), etc.

I am able and willing to assist and would like to discuss implementing this feature more with the development team.

neok0 commented 6 years ago

I like the Idea a lot. I'm not that familiar with Scala, if its possible to even add plugins in different languages e.g. python it would also increase the participation of users.

To-om commented 6 years ago

TheHive back-end already has a kind of plugins: connectors. They are loaded using Play modules and can:

Connectors can use core objects but the opposite is not possible. This is the main limitation I see.

Regarding TheHive front-end, it is more complicated. The current front-end includes support of all known connectors. I don't know how to manage plugins with Angular. Maybe @nadouani has ideas.

For plugins in different languages, we added the support of active response (#609): an user can execute an action on any TheHive element (case, task, ...). The action can be written in any language and is run by Cortex (like analyzers).

saadkadhi commented 6 years ago

@billmurrin as @To-om stated, we already have support for a rather modular 'plugin' system albeit not one that can easily used/leveraged without good knowledge of the back-end. Active Response should provide an easier way to integrate simple 'plugins' with different entities within TheHive's workflow.

billmurrin commented 6 years ago

Aloha @To-om and @saadkadhi, I appreciate your responses.

So, if an organization had a few connectors to extend the functionality of TheHive, how would they go about loading them into TheHive? It seems like you would have to load the modules into the project, modify the build.sbt of TheHive project, and then recompile TheHive to include the modules? In order for the Core and Connector to exchange information, the core would have to be modified and then likely maintained independently.

That seems a lot more low-level and complicated from a user/organization perspective than finding a plugin that does x,y,z and dropping a file into a plugin type of folder on the server. It also does not expose the core, or the UI, to the connector, nor does it allow the connector to register for events from the Core since the Core knows nothing about it.

I would like to work on a Plugin Manager, a Plugin Trait (Every plugin has to extend the Trait) and related supporting classes so that a few events can be exposed in the Core that a plugin can register for. If you guys have any particular areas in mind, we can start there as a prototype of the feature to build on. As I stated in the original post, my team and I are willing to develop/support this request, although we may have questions every now and then about how things are implemented on the back-end/front-end, etc.

Regarding the Angular piece, this link offers a little insight. https://www.mschweighauser.com/plugin-interface-for-your-angular-app/

crackytsi commented 6 years ago

I could imagine features like https://github.com/TheHive-Project/TheHive/issues/595 as a plugin...

veeral-patel commented 5 years ago

@billmurrin there's a lot of small feature requests in TheHive's issues, this idea could alleviate that problem by enabling people to write their own plugins.

If that's true, then this idea will improve TheHive far more than any other feature request out there. No joke!

I'm willing to hop on a 45 minute call with you, if you want to bounce some ideas off of me and discuss how we'd build this feature. Anyone else can join too!

My email is veeral.patel@berkeley.edu

billmurrin commented 5 years ago

Last year, in July or so, my team discussed this feature with the TheHive development team. One of the limiting factors at the time, and I'm not sure where this is currently (I haven't looked at the road-map in a bit), was the transition to a new database which would require significant recoding/refactoring by the dev team. We put the feature on hold waiting for this to transpire. I am still interesting in this. Perhaps the dev team can discuss where they are at on the db migration.

veeral-patel commented 5 years ago

@billmurrin Thanks! Not sure I understand, though. Plugins are an application-level concern, they should be agnostic to the underlying database, so why do we need to wait until we switch to a graph database to make this happen?

billmurrin commented 5 years ago

Bottom line is that I don't think the DB is properly abstracted so many of the controllers have reliance upon elastic4play which would pretty much need to be changed to a new lib when the db migration occurs. If it became a bit more abstracted than I think you are totally right. This is something along the lines of our discussion with the devs over a year ago (memory gets fuzzier with time). I remain interested in this. So, if @saadkadhi thinks things have settled (like is the project staying with ES) and we should be good to move forward than we should definitely do this.