More control over responders execution

[siisar]

Request Type

Feature Request

Problem Description

Currently, any analyst with write permission is able to execute the responders. This can be dangerous, because it can perform actions with huge impact on an organization. For example, any analyst could block a domain or ip using the umbrella responder.

Steps to Reproduce

1.- Umbrella blacklister responder must be working in cortex 2.- Go to a case with domain or ip observables 3.- Go to the observables tab. 4.- If the current user has write permission, it can execute the umbrella responder and block that ip or domain for the whole organization

Possible Solutions

The simplyest way would be to allow to execute this kind of responders (or even all of them) just for administrators. Analysts need the write permission to create cases, update them, etc, but not all of them should be allowed to execute such dangerous responders.

Other approach could be to create an intermediate role, between write and admin, to allow execute this kind of responders, or even a check as the one that currently exists to create alerts (in the add user screen). This may require that responders should have a kind of categorization, to mark them as only executable by the ones with this special role/check

This feature is extremely important in our organization

[veeral-patel]

@siisar Hey - so essentially you'd like an additional permission that determines if an user can execute any responder on a case?

What do you think of having certain responders require a second person to approve?

[siisar]

Hi veeral, well it sounds good, in the end the approach is quite similar... Do you think is easier to implement?? How is your proposal for that approval circuit?

[veeral-patel]

@siisar It's another form of authorization, in addition to what you're suggesting.

This seems like a really fun feature request to work on! I'd be willing to chat with you for ~30 minutes to exchange ideas (I have some ideas on how we can make this even better) and figure out how I can implement this.

You can shoot me an email at veeral.patel@berkeley.edu.

[siisar]

Well, if you are thinking of adding this new kind of authorization as a general feature, then it is ok, but if it is just for this specific one I think that it implies a lot of complexity, beause I guess that you would need to implement a kind of workflow with the auth proccess...

The best approach would be to have a full segmentation of the permissions, and that you could create roles and link them to the permissions... but that´s not the way it currently works... So with the current roles&user profiling I think the best and easiest way to implement this feature would be:

1.- On the Cortex side: When you define the responder with the json file, add a new property, for instance "authorized_responder: boolean" (false by default, so everyone can execute them by default, as happens right now). 2.- On the Hive side. In the new/update user screen, add a new check "Execute authorized responders", beside the "Alert creation" check. This is better than creating a new role, it just adds a new permission to the current existing roles.

Having this, only users with this new check active can execute the responders with the property "authorized_responder=true"

[veeral-patel]

@siisar yeah the two phase approval process is probably fun to think about, but not too relevant in real life :(

Actually, I don't think we need to do anything on the Cortex aside. What if we just created a permissions table like this:

user_id | responder_id | case_id 3 | 5 | 1 3 | 2 | 3 ..

and TheHive's REST API only allows you to run a responder if there's a row in this table?

The web console uses the REST API, so no need to enforce anything there.

[siisar]

Yeah, but, at least in my use case, it is not necessary to segmentate by case, just need the relationship between user_id & responder_id, having the case adds more complexity...

But in your approach, who is going to fill that table? I think that it should be the admin user when creating/updating the new user.

Your approach could be good, but consider the following drawbacks: 1.- The admin user, when creating the new user, has to select the allowed responders. The problem is that if new responders are added in the future, every single user has to be updated if we want to add the new responder, it is a very hard administrative work. The same could happen if one responder is removed... If we also consider the segmentation by case, things get even worse, because for every case added we have to update the users permissions (for each user)...

2.- The default value should be all responders allowed, so all of them must be selected by default.

In my approach I suggest just a single check when creating a new user, "Execute authorized responders", and in the cortex side we delegate the selection of which responders are considered as authorized, and we do not have these drawback commented above.

In the end, I think that both approachs are the same in a fundamental way, the only difference is that as you suggest the relationship with the responders is given when creating the new user, and in my approach the relationship is dinamic, based on responder config.

[tr1cky6uy]

Hi, I'm +1 for this problem. It would be awesome to have proper permission handling on the responders/analyzers, as I can see for the analyzers there is something in 4.14 if I'm correct but I haven't tried it yet. In my opinion the best way would be a new setting entry where you can specify which user can run which analyzers/responders.