SailPoint IdentityIQ Applications Credential Cycling Using PAM Solution

A large number of applications on SailPoint IdentityIQ rely on using service accounts to communicate with the application targets. These accounts have the authorizations to perform identity management tasks and should be treated as privileged accounts. When a privileged account management solution like CyberArk or BeyondTrust is used in the organisation, the credentials of the privileged account would be stored on the PAM solution and retrieved by IdentityIQ whenever required. The feature of credential cycling introduced in IdentityIQ 7.3 allows this to be configured with ease.

 

The following presentation discusses the need for credential cycling and how it works:

The following demonstration illustrates a use case where credential cycling is configured with the CyberArk PAM solution:

The next video demonstrates credential cycling when configured with the Thycotic Secret Server PAM solution:

CyberArk Privileged Account Security Architecture

Privileged accounts on a system possess higher authorizations and control. These accounts pose a higher risk if they are compromised. Privileged Identity Management solutions aim to address this by providing security and control over these accounts. CyberArk is a major provider that offers privileged account security and is backed by a patented vaulting technology. CyberArk enables organizations to secure, provision, manage, control and monitor activities associated with privileged accounts.

The following presentation describes privileged account security and the architecture of a CyberArk implementation. The various components of the CyberArk architecture and their functionalities are also discussed.

 

Split Brain Scenario in CyberArk

In high availability clustering, split-brain is a problem scenario that can occur when one of the nodes fails. Within a CyberArk implementation with disaster recovery enabled, a split-brain condition might arise if high availability is not configured as per the recommendations.

The following presentation discusses split-brain scenario in a CyberArk implementation and how it can be resolved:

Sailpoint IIQ Activity Data Sources

Monitoring and analysis of events that occur on a system is crucial to identify threats and generate timely alerts. It is also significant to identify by whom such events were caused if it was triggered by a user. Sailpoint IdentityIQ allows us to keep track of identity activity on various targets using Activity Data Sources. When configured, this allows us to track activity like logon times, security events, or application activity among other actions.

The following presentation discusses how Activity Data Sources can be configured on IdentityIQ for basic Security Information and Event Management (SIEM) with an example use-case:

The following demonstration presents the use case for identifying activity based policy violations by setting up Activity Data Sources:

Securing IIQ SPAdmin Account Using CyberArk PAM

In an enterprise, a large number of privileged accounts are spread over various applications and systems. These accounts have higher authorizations and hence need to be handled with higher security. CyberArk‘s Privileged Account Management solution is targeted at achieving this.

In SailPoint IdentityIQ, accounts can have the highest privilege in form of the ‘System Administrator’ capability. The ‘spadmin’ account that comes out-of-the-box is configured to have this privileged access. This account, if managed by the CyberArk PAM solution, improves safety of the IdentityIQ environment.

 

The following presentation discusses this use case and how it can be implemented using CyberArk PAM:

The following video demonstrates the use-case in action for verifying and changing spadmin password from CyberArk and initiating privileged sessions:

Reassignment of Employee mailbox to manager via Sailpoint’s Identity IQ

Email is the most powerful tool for enterprise level communication as it provides accountability and reliability in communication. To an organization, the emails that are received by the employees are a valuable resource. When an employee resigns or is terminated from the company, the organization might still need access to his/her mailbox. This is especially significant in sales, support and administration activities as it can impact the organization either directly or indirectly. This scenario can be addressed by allowing an authority within the organization to access the de-provisioned mailbox and is an important challenge within identity and access management. The risks and compliance guidelines associated with this approach are also factors that need to be considered.

Sailpoint’s IdentityIQ is shipped with a connector for Active Directory. This connector supports management of users, groups and mailboxes on Exchange server. However, for modifying the mailbox permissions, native rules need to be configured in order to execute the corresponding PowerShell scripts.

The following presentation introduces a scenario where handling mailbox permissions would be required. After an overview of native rules, the implementation of this use case is also discussed.

The following demo focuses on granting Exchange mailbox permissions via IdentityIQ and verifying that the changes are reflected on the mail server.

XML Tags in Sailpoint

XML Objects:

Every object in Sailpoint is stored as an XML file. The existing XML objects can be explored from the “Debug Pages”. XML files are useful while adding new objects. This can be done using “Import from XML” under Global Settings. Any object like rules, certifications, system configurations, email templates, etc. can be created using XML.

XML Object Tags:

Each of the objects is represented by its respective XML tag and has its own structure. For example, rules are referred with the <Rule> tag, tasks with <TaskDefinition> tag, email templates with <EmailTemplate> tag.

An XML file with only one object begins and ends with a tag corresponding to that object type. However, it is a better practice to always wrap the objects with the <sailpoint> tags as this offers more flexibility. This approach also enables to import multiple objects defined in the same XML file.

For example, two XML files can be combined into a single file:

 

Usage of combined XML objects:

Taking the approach of using a single XML file is extremely useful for deploy-ready and stable objects. Doing this in general will reduce the modularity which raises few concerns:

  1. If an issue arises with importing one of the objects, it will halt the process of import and rest of the features would be left out
  2. As part of the development process, it would be inconvenient to import all the objects repeatedly while only one or few of them are updated.

Due to these reasons, it is better to combine tested and stable XML objects instead of objects that are still in development.

The usage of this approach can be observed in the “init.xml” file that comes with Sailpoint. This file contains all of the objects required for the basic features of the product, packaged into a single XML file.