IBM QRadar SOAR

Hi All,

We're looking for feedback on an enhancement we're currently exploring, namely providing the ability to control who can execute actions on incidents which are not currently controlled by permissions and which originated from this RFE. 

Control what "Actions" "Selected" "..." a Group has available to them

We already have some control for non incident members with existing view permissions, however for rules and playbooks, as well as specific built in product actions like generating incident reports, there are no such controls. Equally if you're a member of an incident you can do anything in that incident.

We'd like feedback on whether you would prefer a whitelisting approach, where users must be explicitly given permission to perform an action, or blacklisting, where users must be explicitly restricted from performing an action.

In the whitelisting approach, we'd need to consider each rule/playbook that's developed or installed via integrations (existing and future). They would have to be explicitly added to users (via groups or roles probably). The same would apply to any new product action.

In the blacklisting approach, you would only need to update users permissions for the actions they shouldn't have access to.

In both cases, permissions would be cumulative as they are today.

If an action was whitelisted in one group or role a user had, but not in another, they would always be able to accomplish that action.

If an action was blacklisted in one group or role a user had, but not in another, they would never be able to accomplish that action.

We would appreciate any feedback on this, the approach to take, issues or concerns you forsee, clarifiations or considerations we should take into account.

Feel free to contact me directly or else reply to this post.

------------------------------
Martin Feeney
Product Manager, IBM Security QRadar SOAR
martin.feeney@ie.ibm.com
------------------------------

Hi @Martin Feeney. Just providing my feedback on this RFE...

First, our organization probably wouldn't leverage this functionality at the moment because all of our members should have the ability to run every action by design and based on how our our team is structured. That being said, I can certainly see why some SOC teams would want this, especially large ones with several tiers of analysts.

In the cyber security RBAC space we always side with whitelisting as opposed to blacklisting, as this ensure access is granted on a need-to-have basis. Of course, at scale this could be cumbersome to configure, so in an ideal state I would envision being able to select checkboxes from a list of all actions; this would need to be inclusive of a 'Select All' checkboxes option to quickly select all actions (and perhaps then unselect a few sensitive ones) as well as a simple 'Grant All' actions option from the permissions view of each SOAR Role. Additionally, a view of permissions within each Rule would be useful.