Identity Security Cloud Advanced Policy Management Framework

Credits: This framework was designed with the input and help of @Bassem_Mohamed

Hi SOD-savvy Identity Security Cloud customers,

This tool is an example that combines the SaaS Connectivity Framework with the TypeScript SDK to implement dynamic search-based policies for Identity Security Cloud (ISC) and automate the administration tasks required to implement separation-of-duty (SOD) policies and certification campaigns at scale.

You can find the connector source code on this GitHub repository.

This blog will examine some of the ways you can use this tool to solve different business challenges.

Dynamic SOD policy definitions

A common approach many organizations take to define their SOD policies and matrices is to do so on the entitlement metadata level rather than on the technical entitlement level.

For example:

  • The organization business analysts define a list of toxic / conflicting business processes (e.g. Accounts Payable vs. Accounts Receivable).
  • The business analysts later identify which technical entitlements match each business process.

The ideal implementation of such SOD models would include the following:

  • A definition of Identity Security Cloud policies based on the conflicting business processes without manual specification of the technical entitlements in the policy definition.
  • A separate ability to “tag” the technical entitlements that match these business processes - the policies would automatically pick up these “tagged” technical entitlements.

As of July 2023, you can define SOD policies in Identity Security Cloud by manually selecting entitlement lists that match each conflicting side. This means that you currently need to maintain those lists of entitlements by changing your policy definition rather than creating a dynamic policy by using functionalities like Identity Security Cloud’s search and tagging capabilities.

Automating SOD policy certification campaign definitions

As of June 2023, you can create certification campaigns from your SOD policies as an additional configuration step in Identity Security Cloud. While it’s a simple additional configuration step, it can take some time if you need to do it at scale with many policies.

Also, in certain cases, you will have to reconfigure the created certification campaigns when certain changes are made to their respective policies, which adds an additional administration cost.

High-level Design

There are a three main components to the solution:

Policy Configuration CSV File

  • This is the master file that holds the required policy configurations.
  • Each line represents a separate policy that the framework will auto configure and maintain.
  • The policy configuration CSV file can be included in source control for versioning.
Field Name Required Description Expected Value
PolicyName :white_check_mark: Identity Security Cloud Policy name, acts as the main identifier text
PolicyType :white_check_mark: The type of Policy. For now only SOD is supported SOD
PolicyDescription :white_check_mark: Identity Security Cloud Policy description text
PolicyOwnerType :white_check_mark: Type of entity responsible for the policy configuration IDENTITY, GOVERNANCE_GROUP
PolicyOwner :white_check_mark: Name of the Identity or Governance Group responsible for the policy configuration text
PolicyEnabled :x: Whether the policy is enforced or not (Default is disabled) yes/no/true/false
ExternalReference :x: Standard Identity Security Cloud Policy attribute text
Tags :x: Standard Identity Security Cloud Policy attribute Comma-separated list (no spaces)
Query1Name :white_check_mark: Display Name for the SOD Policy Left-hand query text
Query1 :white_check_mark: The SOD Policy Left-hand query Valid Identity Security Cloud Entitlements Search Query
Query2Name :white_check_mark: Display Name for the SOD Policy Right-hand query text
Query2 :white_check_mark: The SOD Policy Right-hand query Valid Identity Security Cloud Entitlements Search Query
ViolationOwnerType :white_check_mark: Type of entity responsible for violation remediation IDENTITY, GOVERNANCE_GROUP, MANAGER
ViolationOwner :orange_circle: Not required with MANAGER type Name of the Identity or Governance Group responsible for violation remediation
MitigatingControls :x: Standard Identity Security Cloud Policy attribute text
CorrectionAdvice :x: Standard Identity Security Cloud Policy attribute text
Actions :x: Additional actions required aside from defining the policy. Empty action will only create a policy. REPORT, CERTIFY, DELETE_ALL, DELETE_CAMPAIGN
PolicySchedule :orange_circle: Only with the REPORT action DAILY, WEEKLY, MONTHLY
CertificationName :orange_circle: Only with the DELETE_CAMPAIGNS / CERTIFY actions text
CertificationDescription :orange_circle: Only with the CERTIFY action text
CertificationSchedule :x: Optional with the CERTIFY action to auto-schedule the campaign WEEKLY, MONTHLY

Delimited file source

The delimited file source serves as a way to store the earlier policy configurations in Identity Security Cloud.

  • This eliminates the need to externally store and read the policy configuration file.
  • This also means that you can recover the current configuration file at any time by downloading the accounts CSV file from this source.

SaaS connector and source

The solution uses the SaaS Connectivity Frameworkand leverages the TypeScript SDK to automate all the required administration tasks.

The logic has been implemented in the account aggregation, which allows you to easily schedule these policy and campaign refresh tasks as required.

You can also configure a workflow to automatically trigger account aggregation on this source once an account aggregation finishes successfully on the delimited file source.

Processing logic

An administrator is expected to upload a policy configuration CSV file to the delimited file source in Identity Security Cloud. Once that’s done, the SaaS connector account aggregation performs these actions:

  1. Find the delimited file “Advanced Policy Configurations” source by using the source name provided in the SaaS connector source configuration using the List Sources API.

  2. List all the policy configurations in the delimited file using the Account List API.

  3. Process each policy configuration record as follows:

    • Use the Search API to find entitlements matching both provided queries.
    • Use the relevant APIs to resolve owners of type IDENTITY (Search API) and GOVERNANCE_GROUP (Beta GovernanceGroup API).
    • Use the relevant SOD policy APIs to find and patch and existing policy, or create a new one.
    • Schedule the policy using the Update policy schedule API if the REPORT action was set.
    • Use the search API to find all access profiles that contain the entitlements matching both provided queries.
    • Use the search API to find all roles that contain the access profiles from the previous step.
    • Use the relevant certification campaign template APIs to find and patch an existing campaign or create a new one if the CERTIFY action was set.
    • Schedule the campaign by using the update campaign template schedule API if the CERTIFY action and CertificationSchedule field were set.
  4. Prepare a policy implementation status object to be returned as an account in the SaaS connector source. The “status” account would show details like these:

    • Indication of whetherthe policy, policy schedule, campaign, campaign schedule have been configured
    • List of error messages faced during processing the policy configuration
    • Statistics on the number of access items relevant to each side of the policy queries
    • Lists of relevant entitlements, access profiles and roles on either side of the policy queries
  5. You can get a full processing status report by downloading the “Accounts” CSV file from the SaaS connector source.

Usage Instructions

:warning: Always make sure you properly test and validate any configurations in your sandbox environment(s) first before moving them to production

Configure your policy configuration CSV

This is a sample policy configuration CSV file with a few examples.

Things to consider:

  • Ensure you have unique names for the different policies and campaigns where it’s relevant.
  • The policy name is the unique identifier for policies. Changing a policy name will create a new policy rather than rename an existing policy.
  • The certification name is the unique identifier for certifications. Changing a campaign name will create a new campaign rather than rename an existing campaign.
  • Ensure that you use valid entitlement search queries.
    • It is recommended that you test the search queries in the Identity Security Cloud UI first to ensure their validity and that they return the required entitlements.
    • You can leverage the Identity Security Cloud tagging capabilities to tag entitlements and then use the tag-based search query (tags:YOUR_TAG) for the ultimate flexibility of which entitlements to target.
  • Ensure that you add the correct policy owner and violation manager references. Nothing will be configured if those references are broken.

Configure your delimited file source

  1. Create a new delimited file source within your tenant.
  2. Configure the account schema by uploading the attached sample CSV file. Ensure that the PolicyName attribute is set as both the account ID and account name.
  3. Import your policy configuration CSV under the Account Aggregations tab.

Configure your SaaS connector source

You can find the source code for the connector on this GitHub repository, Alternatively, you can use the pre-built connector file attached following this section. Note that the attached file here may not always be up to date with any later code changes in GitHub.

  1. Generate a personal access token (PAT) from your tenant. Ensure that you add the sp:scopes:all scope for full admin permissions.
  2. Follow these instructions to install the sailpoint-cli tool.
  3. Follow these instructions to optionally build and then deploy the SaaS connector.
  1. Create a new source in your tenant using the newly added SaaS connector.
  2. Fill in the required details under Connection Configurations.
  3. Add your tenant API URL and PAT details (ClientID/ClientSecret) to the source configuration.
  4. Populate the name of the delimited file source created in the previous step in the Policy Configuration Source Name field
  5. Optionally fill in the details under ‘Additional Settings’.
  6. Test the connection to ensure the required details are correct.
  7. Run an account aggregation on this SaaS connector source and witness the magic! :wink:
  8. In ideal situations, schedule the account aggregation so that it periodically refreshes the configured policies and campaigns with any new updates either to the policy configurations or the entitlement data.

Resources

advanced-policy-framework-0.8.0.zip (194.7 KB)
SamplePolicies.csv (2.3 KB)

10 Likes

The capable of dynamic updated SOD policies instead of a static list is awesome.
However, the doc says a maximum of 50 entitlements in each access list; while in SaaS connector, it is configurable with a default 400. And It threw an error when creating a policy has more than 50 entitlements.

Reference:
Managing Policies - SailPoint Identity Services

50 entitlements is the default limit. Customers should engage their Customer Success Manager to explore raising that limit.