IBM Security Resilient

Mod Con: Restrict Actions by Group Membership

  • 1.  Mod Con: Restrict Actions by Group Membership

    Posted Sat February 22, 2020 06:59 PM
    Edited by Brenden Glynn Sun February 23, 2020 01:24 PM

    Below is a Resilient Mod Con that will allow you to Restrict Actions by Group Membership.

     

    Background: By default, Actions in Resilient are not User aware. Role Based Access Control (RBAC) is only enforced at the Incident Level. A User either has the ability to View and or Edit an Incident, or they don't. Currently there is no granular RBAC on the Actions/Objects within an Incident.

     

    Actions can be simply defined as the modification of a Resilient Object. Performed either directly on that Object through User interaction, or through an Automatic or Menu Item Rule.

     

    These Objects in Resilient are:

    • Field (Incident)
    • Task
    • Note
    • Milestone
    • Artifact
    • Attachment
    • Data Table
    • Email Message

     

    Since Rule Conditions are set to determine when it's Activities will automatically trigger (Automatic Rules) or when an Action will be made visible/available for User selection (Menu Item Rules). A big caveat to this, is that any User who is a Member/Owner or has explicit permissions, has access to the Incident and in turn, can trigger the Actions provided the Conditions are correct.

     

    In certain use cases this is not desirable, and we want to Allow/Deny a user from triggering certain Actions. For example, in my previous Mod Cons, we created two actions. One that would Enforce Completion of Mandatory Tasks before Incident Closure, the other Mark Mandatory Tasks as Optional/Not Applicable. We may only want to allow certain Groups to mark those Mandatory Tasks as Optional. Not all of the Users on the Incident.

    Equally if not more important would be restricting the ability to trigger any invasive/impactful remediation Actions configured through Menu Item Rules. Such as restricting the blocking and or the isolation of an IP Address or System, to a select set of Groups and the Users within.

     

    Why: In these examples above, it is common (and is best practice) that only certain senior Groups within a SOC such as the Level 3, CERT and or Leadership Groups to have the access and the ability to trigger Remediation Actions.

     

    How: By adding a Script as a Rule Activity, we can Allow/Deny a User's ability to trigger any Action based on their Group Membership. What Rules to add this Script to:

     

    1. The Menu Item Rule that Triggers the Action.
    2. An Automatic Rule where the Condition is the Change/Modification of the Object of interest.

     

    Method: For this Mod Con example, we will be using an Automatic Task Rule, and a Task Script. If you've already implemented my first Mod Con: Mark Mandatory Tasks as Optional, you can use the Rule created in there. Otherwise you will be using one of your existing Rules/Actions or created a New Rule.

     

    Menu Item Task RuleAction - Mark as Optional/Not Necessary (From my previous Mod Con)

    Incident Script – Action - Groups Allowed to Perform Actions - Level 3 & CERT (NEW!)

     

    Note 1: When pairing Rules and Scripts, make sure that the Script is either an Incident Object or the same Object Type as the Rule you will be using it with. All Objects can use Incident Scripts, as the Incident is the parent/base Object.

     

    In the Task Script, we will be using a helper.fail message to block the Action before it is performed, and then convey a message to the User. You can choose to use this Script to Allow or Deny the ability to perform the Action. That is up to you.

     

    For the purposes of the Mod Con I will be choosing to Allow only the Groups listed in the Script to perform the Action. Those Groups allowed to Mark Tasks as Optional/Not Necessary are the Level 3 and or CERT.

     

    This Script can then be added as an Activity to any Action (Rule - Automatic or Menu Item) you wish only the Members of the Level 3 or CERT Groups to perform.

     

    Note 2: Be sure to make this Script the first Activity within the Rule. You'll see in my screenshot below, that I have two Scripts in my Rule. I want to make sure this Script is evaluated first.

     

    Script:

    Permitted_Groups = ["Level 3, CERT"]
    
    Permitted = False
    
    for group in Permitted_Groups:
      if groups.findByName(group):
        Permitted = True
    
    if not Permitted:
      log.info(principal.display_name + " attempted to perform this Action")
      helper.fail("You must be a Member of the Group: {}".format(group) + " to perform this Action")

    Screenshots:


    Menu Item Task Rule:


    Incident Script:


    Automatic Rule Use Case:
    We can restrict the modification of Incident Files, to only those in the Groups specific. Using the same Script created above as, an Activity within an Automatic Incident Rule. Where it's Conditions (ANY) are the Fields which we want to restrict the modification of. When a User attempts to modify any of the listed Fields, the Script will evaluate if they are in the Authorized Groups, if not, it will block the Action.

    Automatic Incident Rule

    Extending this Mod Con:
    Using Automatic Rules and this Script, you can Restrict the modification of any Resilient Object. Be it the creation, deletion, or change of those Object.

    ------------------------------
    Brenden Glynn
    CISSP, GCIH
    Incident Response Business Consultant
    IBM Resilient
    ------------------------------