Native Change Detection Using Workflows

Introduction

Read this blog to learn how to implement the Native Change Detection Workflows solution. This solution provides a way to automate out-of-band access that has been granted or revoked.

This solution is built based on the Native Change Detection Updates event trigger. This solution involves the following pieces:

  1. Dynamic Form: Native Change Detection Form
  2. Native Change Detection Workflow: Added Entitlements
  3. Native Change Detection Workflow: Removed Entitlements

One of these workflows will get triggered when sources admins provision/de-provision entitlements external to Identity Security Cloud. For example, a helpdesk user might use Active Directory ‘Users and Computers’ to add groups to or remove them from an account instead of instructing the account’s owner to submit an access request. In this situation, one of the two workflows will get triggered based on whether the entitlements were added or removed.

If an access was added the workflow creates micro-certification campaign for the correlated accounts assigning the campaign to the identity’s manager, for the uncorrelated accounts, the workflow will open a form assigning to the source owner to maintain or revoke each entitlement.

If access was removed, the workflow will open a form for each entitlement, assigning the form to the source owner, who must acknowledge the removed access or re-add the removed entitlement.

Read this blog to learn about native change detection workflows and how to implement them.

Workflow Purpose

We built this workflow to provide a way of automating the governance of out of band granted/revoked access.

In reality, some source admins can add/remove some access to accounts(correlated/uncorrelated), which might cause a risk to the organization’s assets as example:

  • Administrators can remove necessary access from a service account, which might stop a service or break an integration.
  • Administrators can grant privilege entitlements and access to an account’s resources by mistake, which might increase the attack surface or expose the account’s sensitive data.

These workflows give more visibility to source owners so they can certify the out of band granted/removed access. These workflows help to maintain the least privilege principle for correlated and uncorrelated accounts.

High-level Design

This section details the three pieces involved in the Native Change Detection Workflows solution.

Dynamic Form: Native Change Detection Form

The dynamic form will show variables and fields based on the triggering workflow and the form inputs as shown in this example:

  • Event Type
  • Entitlement Owner (if it exists)
  • Governance Action

Native Change Detection Workflow: Added Entitlements

The Native Change Detection Update event trigger starts the workflow process for added entitlements. Then the system checks whether the account in the NCD update trigger is a correlated or uncorrelated account.

Correlated Accounts

  • The workflow creates a micro-certification for the identity mapped to this account and assigns the certification campaign to the identity’s manager. The manager must certify only the out of band added entitlements.
  • The micro-certification campaign duration is 2 days. This a configurable value you can update in the ‘Define Variable’ step.
  • The system sends an email with a summary of the created micro-campaign
  • This is an example of the email template:

Uncorrelated Accounts

  • The workflow loops over the entitlements and send a form for each entitlement to the source owner.
  • The source owner must make a governance decision for this added entitlement and write a valid business justification.
  • The source owner can make these governance decisions:
    • Maintain: Acknowledges that the entitlement should be kept with the uncorrelated account.
    • Revoke: Asks Identity Security Cloud to create a revoke request to revoke the out of band added entitlement. If the entitlement is revoked, the revocation will follow the configured approval process.
  • Then the workflow sends an email with the decision that was made and shares it with the source owner and/or security team as an evidence.
  • This is an example of the email template:

Native Change Detection Workflow: Removed Entitlements

The Native Change Detection Update event trigger starts the workflow process. The system then checks whether the account in the NCD update trigger is a correlated or uncorrelated account.

  • The workflow loops over the entitlements and sends a form for each entitlement to the source owner.
  • The source owner must make a governance decision for this removed entitlement and write a valid business justification.
  • The source owner can make these governance decisions:
    • Acknowledge Entitlement Removal: Maintains the removal of this entitlement from this account.
    • Re-add Removed Entitlement: Asks Identity Security Cloud to create a access request to re-add the out of band removed entitlement. If the entitlement is re-added, the re-addition will follow the configured approval process.
  • Then the workflow send an email with the decision that was made and shares it with the source owner or with the security team as an evidence.
  • This is an example of the email template:

Considerations

Make sure that you properly test the workflows in your sandbox environments before introducing any changes to your production environments.

workflows and Forms Limitations

There are some limitations involved with using workflows and forms:

  • As of October ‘23, actions taken within the form are not audited, and no audit logs will be generated as exampled:
  • You can’t run a search query or report to get all access requests for revoked or re-added entitlements that are generated by the workflows or based on this form decision.
  • As of October '23, a workflow loop only supports 100-items. If you have more than 100 entitlements added, some won’t be processed when the workflow runs.
  • Visibility into the loop/executions is limited.

Deploying Instructions

Follow these instructions to deploy your solution:

Note: Deploy on your sandbox tenant first. Then perform all the testing and validate all the sandbox testing results before moving the workflow to the production.

Configure API Requests

First, change the HTTPRequest API URLs for the API calls to refer to your ISC tenant and your PAT client ID & client secret.

Import Form Definition and Workflows

Once you have configured your API requests, start importing the form definition and workflows you will need to implement the solution:

  1. Import the “Native Change Detection Form“ definition (see the attachments at the end of this blog) using this beta endpoint.
  2. Download the JSON files for the workflows (see the attachments at the end of this blog).
  3. Log into ISC with Admin rights and create a personal access token (PAT). In the PAT, assign the scope sp-scopes-all. Store the client ID/secret somewhere secure. This client ID/secret pair will be needed for all API calls in the child workflow.
  4. Upload the JSON files for the workflows into your ISC tenant.

Edit Native Change Detection Workflow: Added Entitlements

Once you have imported ‘Native Change Detection Workflow: Added Entitlements’, use the Workflow Builder to edit it:

  1. Update the “Define Variable” with the campaign duration.
  1. Edit the ‘Send Email 2’ action to update the following values (if needed):
    • Recipient Email Address
    • From
    • Subject
    • Body
  1. Edit the ‘Form’ action to change the following values (if needed):
    • Form Recipient
    • Notification Subject
    • Submission Deadline
    • Reminder Body
      Example:
  1. Edit the ‘Send Email’ action to update the following values (if needed):
    • Recipient Email Address
    • From
    • Subject
    • Body
      Example:
  1. Enable the workflow.

Edit Native Change Detection Workflow: Removed Entitlements

Once you have edited the workflow for the added entitlements, you can start editing this workflow, ‘Native Change Detection Workflow: Removed Entitlements’:

  1. Edit the ‘Form’ action to change the following values (if needed):
    • Form Recipient
    • Notification Subject
    • Submission deadline
    • Reminder Body
    • Form Submission Reminder
      Example:
  1. Edit the ‘Send Email’ or ‘Send Email 1’ actions to update the following values (if needed):
    • Recipient Email Address
    • From
    • Subject
    • Body:
      Example:
  1. Enable the workflow.

Conclusion

Once you have completed these steps, you can start using this solution to start automating your governance of out-of-band access that has been granted or revoked. Refer to the attachments at the end of this blog for all the files you need to get started!

Attachments

Native Change Detection Form (24.9 KB)
NativeChangeDetectionforAccessRemoval.json (11.4 KB)
Native Change Detected for Added Entitlements.json (13.1 KB)

15 Likes

Hi @Bassem_Mohamed,

Thank you for sharing this workflow.
I am trying to use this workflow to detect changes on Active Directory source, however I only want to target changes on entitlements present within a specific OU.

Parent OU of entitlements that I want to target
OU=Access,OU=Groups,DC=demo,DC=local

Have you or anyone else configured and tested this.

Regards.

1 Like

Hi @rahulsinghrconsulting,
you can use this json filter in the trigger node:

$.entitlementChanges[*].added[*][?(@.value contains "OU=Access,OU=Groups,DC=demo,DC=local")]

Thanks,
Bassem

2 Likes

Hi @Bassem_Mohamed,
thank you very much for the explanation of Native Change Detection! But I do not really understand, how this feature works in detail… Could you please explain me, how this function works and how I can use it easily with multiple sources on which native change detection is enabled:

  1. Does this Native Change Detection function creates a snapshot of the current state of a source after enabling of this function? And then it fires events on every change of attributes, which should be monitored?
  2. If you have multiple sources with the Native Change Detection enabled and you need to react to only specific changes on each source, would you recommend to create different workflows for each source or is there any possibility to use an option “if source.name = xyz then”…?
  3. You have already answered the question about AD and filtering for some OUs and this is a great option. But from my experience, it would be great just to have an option to limit Native Change Detection only to entitlements being managed through Access Profiles or Roles. Is it possible to limit somehow this function?

I would much appreciate, if you could explain it to the community :slight_smile: Many thanks in advance!

Thank you @Bassem_Mohamed for this workflow .

Form is assigned to the source owner , How source owner know if item is pending to be actioned apart from the email ? Does UI will show any form pending ?

Also does approval form has any owner , anyone can get the link of the form and can take action ?

1 Like

Hi @vishal_kejriwal1, No the form link should be accessed only by the form recipient. You can configure a reminder mail to remind the recipient if he didn’t submit the form before the deadline.

Hey @tburt, Do you know when can the form recipient see the pending forms in the UI?
Thanks!

1 Like

Thank you @Bassem_Mohamed .

Hi @tburt ,
Can you please confirm below items , I think these 2 items would be really helpful in multiple different scenarios . I will also try to open a item in sailpoint idea for both of them if they don’t exists .

  1. when can the form recipient see the pending forms in the UI.
  2. when Form can be assigned to governance group or multiple recipients ?

Bassem,

This is not currently on the roadmap.

Vishal

  1. Not currently on the roadmap
  2. Also not on the roadmap.

Use the “Provide Feedback” Link in the Form UI page to schedule a 1:1 with myself and my lead UX designer if you want to discuss further.

1 Like

Thank you @tburt . I will schedule sometime.

Hi @Bassem_Mohamed.

Thank you for this insightful post.

1 Like