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.

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.

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

The default Native Change Detection configuration on a source.
The default Native Change Detection configuration on a source.3454Ă—1752 362 KB

Toggle Enable Native Change Detection to use the feature on your desired sources.

Use this toggle to enable Native Change Detection on a source.
Use this toggle to enable Native Change Detection on a source.3454Ă—1752 362 KB

How are native changes detected?

Native Change events fire after Account Aggregation 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.

Workflow Template for Auto-Revokes

Here’s how we recommend auto-revoking entitlements added through native change.

Audit Events for Native Change Detection

Here’s how we recommend reporting native changes.

Submit Questions or Feedback

Submit questions or feedback by commenting on this topic!

7 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?.

1 Like
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.

1 Like
5

Hi @kirby_fitch I am testing built in SailPoint NCD feature in our sandbox environment. We have many Delimited file sources. We use ServiceNow for Role requests and to create manual fulfilment tickets. For Valid Role requests when I aggregate CSV file to Delimited file source, the NCD feature flags NCD detection.
I tried also to aggregate using load account API but I got the same result.

Do you have any suggestion how the NCD feature should be used in Delimited file source?

6

Hi @KidusKebede,

All changes on DelimitedFile sources are discovered via aggregation, which means we regard them as native changes. We could make this more selective in the future. I’d recommend submitting an idea if you’d like us to pursue that!

1 Like
7

Thanks @kirby_fitch for your reply. What about direct sources (e.g JDBC connector) which doesn’t have auto provisioning (Direct sources generate ServiceNow ticket for fulfillment through SailPoint ServiceNow catalog plugin)? Is it considered as native change on aggregation.

Is it the right statement to say, the current NCD features works for Direct sources with auto provisioning on?

8

Yes, that’s correct. If we learn about a change in an aggregation, it’s considered a native change. That would include manual changes that were made because a task instructed the person to do it.

9

Thank you Kirby for your reply. I have submitted new idea to request Native Change Detection enhancement to support Delimited File sources and Direct connectors without auto provisioning. For anyone who needs this enhancement, feel free to vote on this link https://ideas.sailpoint.com/ideas/GOV-I-3698

1 Like