Identity Governance and Intelligence to Govern Bots

Identity Governance and Intelligence (IGI) allows enterprises to provision, audit and report user access and his activities through life cycle, compliance and analytics capabilities. While IGI revolves around typical entities like Users, Entitlements, Accounts, Groups, Roles etc., we are now introducing the notion of a Bot as an entity to manage. There has been a lot of discussion off-late around the use of Bots in enterprises and the need for Identity and Access Management (IAM) products to do something around the same. For instance, I am putting down a few excerpts from Gartner Identity and Access Management Summit 2018, in this context:

• Robotic Process Automation (RPA) will have a profound impact on IAM.
• Technical professionals should extend Identity Governance and Administration (IGA) to include software robots as a new identity type.
• RPA introduces robotic software whose identities and access must be managed and controlled.

It is pretty evident that IAM products would need to do their bit to integrate with RPA offerings. As a step towards this integration, we’ve made an attempt, to document how we could leverage the existing capabilities of IGI 5.2.4 to achieve governance of Bots. More precisely, here are the main aspects that show up in this blog:

• Provision a native Bot in IGI.
• Wrap a governance tier around Bots.
• Use Bots to serve a provisioning request on a target system.

Bot Governance

Before we go deep into the article, introducing a few concepts. To start off with, let’s see what a Bot is.

What is a Bot?

Bot / roBot is essentially an entity viz. a script / batch file / a piece of program that could perform a set of prescribed steps when told to do so. Take for an example, an end-point which is accessible only via the User Interface. For such an application, a good Bot would be a set of steps which help in:

• Login to the UI.
• Reach to the concerned panel.
• Fill in the requisite parameters.
• Complete the request.

What is the need for a Bot?

Enterprises ideally love to automate all the operations in the organization. They just don’t want to rely on manual intervention for any process. While this goal looks reasonable, it is accompanied with a set of technical challenges. The main challenge being, integration of desperate systems. There are just tons of ways in which two systems are reachable. For example, some systems could expose REST Services while some could just be exposing Java APIs, some would be exposing a CLI to interact, whereas for some systems UI might be the sole way to interact. Consequently, enterprises resort to human intervention to make the whole system work.

Talking an example more context of IGI, let’s talk of an access provisioning scenario. Many of the end-points / target systems are reachable using the Brokerage Tier of IGI. However, there are still a lot of end-points for which there are technical limitations of even writing a custom adapter. In such cases, administrators typically configure the workflow for Manual Provisioning. As far as the workflow execution is considered, the Operator manually provisions requests based off a Form handed out to him.

Enterprises want to dig out such pockets to the extent possible, introduce Bots to mimic human behavior and then improve the automation percentage of their enterprise and consequently operational efficiency of their enterprise.

Taking the same example forth, an administrator can introduce a a Bot that mimics the same set of steps that an Operator would do and hook this Bot in the Workflow. That way, the manual intervention of the Operator is completely avoided.

Why do we need to govern Bots?

From the description of the Bot, it is evident that Bots can be handy for automation. However, Bots can be risky, if there is no tab on what they are doing. At the end of the day, Bot is a script, a bunch of commands and who knows what side-effects can be caused by the execution. Unknowingly, Bots become identities of their own, who have got a power to execute any step on the end-points, without revealing their identity. That’s the biggest threat of having Bots in the organization, i.e. Accountability. It should be pretty clear on who owns all the actions being performed by the Bot.

Alternatively, there should be a clear indication of the entitlements and activities of the Bot and an assurance from the system that corporate policies are not being violated by the Bot. Likewise, there has to be governance around the Bot Owners, since the risk level of a Bot Owner might escalate owing to combined entitlements of the Bot Owner and the Bot.

Bot Provisioning in IGI

Now that we understand the concept of Bots, the need for it and the need for governance, lets see how we could setup a mechanism to provision Bots in IGI and thereafter elaborate the Governance aspects around a given Bot.

Two personas are involved in getting a Bot provisioned into IGI:

1. Appliance Administrator – One who provisions the Bot into the IGI Appliance.
2. Bot Owner – One who is accountable for all the Bot actions.

Let’s see the set of steps needed to get the Bot into the appliance.

Import Bot

1. Import the Bot into IGI via the Custom File Management module of IGI Appliance Interface. For the purpose of this document, the Bot is a shell script which would login to a remote box and create accounts based on specific criteria. Here are the steps for the same:
   • Log on to the LMI panel of the IGI Virtual Appliance.
   • Navigate to Configure > Custom file management.
   • Select the properties folder, and under that create a new folder say “rpa”.
   • Upload your Bot under the rpa folder.
   • Once uploaded, make a note of the path, where the Bot was uploaded.

Create the BotFarm Application

1. Login to IGI Admin Console and create a new Application, called BotFarm. Any given account on this application would be a Bot Wrapper, holding critical metadata of a Bot, imported above. For e.g. actual physical location of the Bot.
2. Tweak the Account Configuration corresponding to the BotFarm application to add Target Attributes, especially BotLocation.

Note: This attribute shows up, along with the Account Form, in the Account Selection Step of the Access Request Flow. That would be a critical attribute to gather at the time of provisioning a Bot.

Associate Workflow around BotFarm Application

Ensure that any request to provision a Bot on the BotFarm Application is complemented by an approval cycle:

1. Create a new workflow of Context “User Access Change”, titled “Bot Creation”, which has an activity “Bot Provisioning”.
2. Tie an Approval around this request. That way, Bots are provisioned only after legitimate Review and Approvals.

Risk Modeling

Ensure that the right business activities mapping with entitlements is in place. This will go a long way in bubbling up the Risk Posture of a given Bot, and consequently of the Bot Owner as well:

1. Risk Modeling in IGI revolves around the notion of Business Activities.
2. Business Activities are typically created and associated with different Entitlements.
3. Entitlements are assigned to a User / Account / Bot.
4. Define new risks and in the course of it, associate risk with different activities. You could create and associate risks with different combinations of activities, which could help in flagging potential Segregation of Duty (SoD) conflicts.
5. Once we get the risks, activities, entitlements in place, the workflow “Bot Creation” can be made online.

Note: The risk level of a Bot Owner is influenced by two aspects:

1. The current set of entitlements of the Bot Owner.
2. The current set of entitlements of the Bot itself.

Bot Provisioning

Once the requisite artifacts are in place, here are the steps for a Bot Owner to provision a new Bot into IGI:

• Provision this Bot into BotFarm Application:
  • Login to the Service Center as the BotOwner (rjgorthi).
  • Launch the Request Center module from the Top Left Hamburger Menu.
  • Launch the Bot Provisioning Activity and notice the Risk Status of the user:

• Go to the “Application Roles” Tab and select the “BotFarm” Application in the Application Picker that pops out. You would see the following entitlements listed there:

Figure 3. Entitlements to be selected for Bot being provisioned

• Select the Bot Functions that you would like to perform, i.e. the Entitlements you would like for your Bot. In case, it’s administrative functions that you would like your Bot to do, click Add against the AdminBot entitlement.
• Say, your Bot has a requirement of performing the Performance Bot function as well. Go ahead and select the PerformanceBot entitlement.
• Once you do that:
  • The system detects that the two entitlements conflict with each other.
  • The Risk Status shows up as a Flashing Red Flag for the BotOwner rjgorthi.

• That essentially is where the current Risk Assessment strengths of IGI can be leveraged for a given Bot.
• Remove the PerformanceBot entitlement and proceed to the next step.
• Click the Add New button to the Middle Right of the screen. In the form that shows up:
  • Specify the account Name as adminBOT.
  • Specify the location of the physical Bot imported earlier by the Appliance Administrator, against the attribute BotLocation:

• Hit Save and Proceed to the next step.
• Hit Submit on the Shopping Cart and thereafter it will be queued up for approvals.
• Once approved:
  • rjgorthi would start serving as the Bot Owner for adminBOT.
  • adminBOT has got the path of the physical Bot assigned to the BotLocation Target Attribute.

Leverage Bot for Access Requests

The intent of this section would be to see how the adminBOT gets into action, in place of the Manual Operator. To illustrate this fact, we have a created a new Access Request workflow and we are hooking in the BOT execution step therein. Here’s the flow:

• Create an Admin Role BotAdminRole and add our Bot Owner rjgorthi as a member of this role.
• Create a new Access Request Workflow, say “Bot Based Access Request”.
• In this workflow, assign the Admin Roles to the different stages of the request. For the Operator Step, specify BotAdminRole as the one to execute the request:

• Define a BotBasedProvisioningRule for:
  • Reading the BotLocation attribute of a given BOT.
  • Triggering the Bot hosted at the path stored against BotLocation.
• Hook-in the Rule as a post-action Step in the Authorization Node of “Bot Based Access Request”. This will ensure that the system executes the Bot as soon as the relevant stakeholder approves the request.
• Make the workflow Bot Based Access Request online.
• From an end-user perspective:
  • The end-user places an access request via the Bot Based Access RTriggering the Bot hosted at the path stored against BotLocation.equest activity.
  • The approver of the request approves it.
  • Once the approver approves it, the engine triggers the Post-Process Action which is the Rule defined above.
  • As part of the rule execution, system would gather the request parameters.
  • The rule feeds these parameters to adminBot.
  • The rule triggers adminBot, which facilitates creation of an artifact on the end-point, since adminBOT would be triggered.