connectors triggered on a specific job result configuration(specified by user as of now)

[abheektripathy]

hey @mlodic,

so here’s the idea, imagine you have an observable which for some reason needs to be analysed every x amount of time, you’ll have to rerun the job everytime. if we can have a new plugin which basically schedules jobs on a certain observable and then write up a connector as well which sends up the results via email.

even while using the cli, instead of setting up a cron job in the user’s codebase to leverage intelowl’s apis to get constant threat intelligence for a specific observable, the user can achieve this just through a single api request.

another thought, since the whole point of of threat intelligence is, alerting if something's breaking.
So the user sets up a scheduled job on a specific analyzer/playbook which runs every x time, and provides a config of supposed right results, henceforth if the results differ, it would send up an alert to the user via email.

though i would like some insights on how should i implement the latter and is this something which will be useful in the first place.

[0x0elliot]

sick idea. mostly what i am wondering is if there is a particular use-case analyzer that would require a cron job to begin with to "monitor" it's changes in results.

[mlodic]

I appreciate the effort in giving a birth to this idea.

I agree with @0x0elliot: we would need to have at least a real use case to justify such developments.

Right now I don't see a reason why a person would need to set up a cron. Most of the times, the IntelOwl analysis is triggered based on an external event, which could be an integration with a SIEM, an observation from a security analyst, etc. It is very difficult that you need to enrich any observable periodically without a "real" reason.
The idea is overall cool by itself but yeah, right now, I find very difficult to find a real use case which supports it.

Then, the are other interesting points that you mentioned:

• it makes sense to have a connector which send results via email when properly configured. We already have the configuration to enable email sending (thanks to the recent addition of the registration page) so this could be an option that we could add anyway
• I like the idea of having IntelOwl sending "alerts" by leveraging the "connectors". This could be extended even further

[0x0elliot]

personally, i think an "email connector" is a good idea here.

we can in general maybe elaborate over connectors for it to be easier for people to add custom logic to it. but honestly, that's a little too much work when they can just rewrite a connector by themselves.

the other thing is, intelowl as it is right now isn't exactly a monitoring tool. there are better ways to monitor as well in security. looping over an analyzer might be the least of our priorities.

[abheektripathy]

@mlodic @0x0elliot i understand the point, we can think of a way of intelowl sending out alerts(via the email connector) on a specified result configuration for a specific playbook.

Though, should that be implemented in the first place?

[mlodic]

First, I would implement the email connector and have it support the normal IntelOwl flow.

Then, the idea of activating connectors based on specific analyzers results makes completely sense to me. The point is that, right now, this is only supported by adding more logic to the connector itself and this is not ideal. It could be cool to add a way to configure those triggers to happen based on certain output results and make it configurable by the users that could choose when to trigger the connector. It could sorta become something similar to a SOAR (see Shuffler) where actions are triggered and configurable.

That would also be used later for the Investigation framework which would basically work very similarly but, instead of at the analyzer-connector level, it would work at job-job level. (for that issue the idea is to create some sort of flow of jobs triggering based on previous jobs results).

[mlodic]

Something very similar has been implemented with the "Pivot" framework that is already available in the backend.

Right now there is neither frontend nor documentation but I'll close this issue in favor of more modern ones regarding next steps of this new feature