Enhancement: Native Change Detection

Announcements Product News
,
1

This is available in all sandbox and production tenants.

Native Change Detection enables Admins to remediate out-of-band access changes.

  • Select the source, account operations, and attributes to monitor.
  • Consume Native Change Detected events in external systems.
  • Initiate workflows with Native Change Detected triggers.

This is available in your tenant if you see Native Change Detection triggers in the Event Triggers or Workflows UIs.

What are native changes / out-of-band changes?

Native changes, or out-of-band changes, occur when application admins provision access external to Identity Security Cloud. For example, a helpdesk user might use Active Directory Users and Computers to add groups to an account instead of instructing the account’s owner to submit an access request.

How do I configure Native Change Detection?

Administrators can enable Native Change Detection under Source > Edit Configuration > Aggregation and Provisioning > Native Change Detection.

image
image999Ă—525 46.6 KB

The default configuration is to monitor changes to all entitlement attributes for all account operations (Create, Update, and Delete).

Administrators can revise defaults using the Native Change Detection Config endpoint.

How are native changes detected?

Native Change events fire after Account Aggregations detects that accounts are created, updated or deleted external to Identity Security Cloud.

Native Change Account Created (Event Trigger Details) events fire after accounts are created on sources where:

  1. Native Change Detection is enabled; and
  2. Account Create operations are monitored; and
  3. At least one attribute that is selected for monitoring changed

Native Change Account Updated (Event Trigger Details) events fire after accounts are updated on sources where:

  1. Native Change Detection is enabled; and
  2. Account Update operations are monitored; and
  3. At least one attribute that is selected for monitoring changed

Native Change Account Deleted (Event Trigger Details) events fire after accounts are deleted on sources where:

  1. Native Change Detection is enabled; and
  2. Account Delete operations are monitored; and
  3. At least one attribute that is selected for monitoring changed

What’s Included in the Native Change Detected Events?

To understand what happened, we tell you the:

  • Account, source, and identity with the change.
  • Entitlements that were added or removed.
  • Non-entitlement attributes that changed.

To remediate the change, we include the identities to reference in a workflow:

  • The identity’s manager.
  • The source owner and governance group.
  • Relevant entitlement owners.

What’s Next on the Roadmap?

Admins will gain advanced configuration options in the Native Change Detection UI. Additionally, Admins will be able to get started fast using Workflow templates to:

  • Send a notification email when native changes occur.
  • Auto-revoke entitlements added through native change.
  • Micro-certify entitlements added through native change.

Workflow Starter Template for Auto-Revokes

Here’s how we recommend auto-revoking entitlements added through native change. You could upload this file under New Workflow > Start with a JSON File. Soon, you’ll see this added under New Workflow > Start with a Template.

native-change-detection-template.json (5.5 KB)

Submit Questions or Feedback

Submit questions or feedback to the product team, and we’ll be in touch.

4 Likes
2

Is it possible to include any approval as part of the workflow, for example, if the change is detected, then approval is sent to manager/application owner, if application owner approves, only the change should be reverted?.

3

I was just looking-for/thinking the same thing - that (an approval process would be created) would be great! …to finally have the capability in an implementation we had 10+ years ago :open_mouth: !
Is this possible or flagged as an idea ?

Or… (thinking aloud) I guess it’s possible (based on the attached sample native-change-detection-template.json workflow), to make the “Revocation” request process require approval, so by default you would have a “negative” approval/reject process:

  • Rejecting the Revocation - would allow the user to keep the detected NCD
  • Approving the Revocation - would remove the detected NCD

Hmm??

4

Hi @sunnyajmera and @akasper - We think you’re asking for a micro-certification. The Native Change Detection team is working with the Certifications team to support a certification that takes a single identity id for a list of entitlements, and then sends a certification to the identity’s manager. It’s possible the Entitlements team could add revoke approvals in the future as well.