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:
- Dynamic Form: Native Change Detection Form
- Native Change Detection Workflow: Added Entitlements
- 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:
- Import the “Native Change Detection Form“ definition (see the attachments at the end of this blog) using this beta endpoint.
- Download the JSON files for the workflows (see the attachments at the end of this blog).
- 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. - 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:
- Update the “Define Variable” with the campaign duration.
- Edit the ‘Send Email 2’ action to update the following values (if needed):
- Recipient Email Address
- From
- Subject
- Body
- Edit the ‘Form’ action to change the following values (if needed):
- Form Recipient
- Notification Subject
- Submission Deadline
- Reminder Body
Example:
- Edit the ‘Send Email’ action to update the following values (if needed):
- Recipient Email Address
- From
- Subject
- Body
Example:
- 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’:
- Edit the ‘Form’ action to change the following values (if needed):
- Form Recipient
- Notification Subject
- Submission deadline
- Reminder Body
- Form Submission Reminder
Example:
- Edit the ‘Send Email’ or ‘Send Email 1’ actions to update the following values (if needed):
- Recipient Email Address
- From
- Subject
- Body:
Example:
- 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)