• Home
  • Blog
  • RPA Identity Governance

Identity Governance of RPA Software Robots

RPA has great potential to speed up processes and make businesses more profitable. The technology also has a downside, unfortunately. Without proper controls, RPA could be a vector of fraud.

Before jumping into software robot (bot) credentials, it might be useful to discuss a few terms and processes associated with a typical industry-standard Identity Governance and Administration (IGA) system / enterprise function. In an IGA framework, there are two major types of identities – User identities and Service Accounts/Identities. In terms of User Identity, every user has a role e.g. Manager, Analyst, Accounts Payable clerk, etc. These roles are many times separated into two tiers – Business role and Technical role. Differences between these two tiers is out of the scope of this paper. Roles organize people by their business function and user-based attributes to solve questions of what users should have access to because of who they are or what they need or might have an option to request without additional approval. Each role may have one or more entitlements inside applications. Entitlements encapsulate the set of privileges/authorizations needed to perform a specific action inside an application. For example, an accounts payable clerk will have the entitlement to create refund checks in the financial application, view invoices and approve them for validity if they match the Purchase Order in the procure to pay module or the entitlement to view invoices in the invoicing system. In Role Based Access Control (RBAC), when a user joins an agency, he or she is assigned a role. Based on the role (and potentially other attributes such as location), he or she is automatically given entitlements/access to certain functions inside various applications within the agency. These are typically managed within an IGA system (previously called Identity and Access Management -IDAM o system) which then interfaces with the target applications directly or through Microsoft Active Directory to store and manage these entitlements. Where integration between an IGA system and the end systems does not exist, administrators manually enter the entitlements into the end systems after the completion of the approval workflow. Service Accounts are Privileged Accounts that are treated differently from User Accounts. Service Accounts are created for system level functions such as database access or Active Directory access by applications in the backend when they are executed. Service accounts have access to underlying OS level or database level functions only and don’t have any application entitlements. As an industry best practice, each service account should be assigned to a custodian who is typically the owner, manager, or administrator of the application that is using the service account.

While the easiest path to a bot implementation is to run them in an attended mode using the User ID of the person running the bot, this option does allow for scaling and running the application in an unattended mode. Some enterprises have a user provide their identity credentials to run bots in an unattended mode as a work around. This option is dangerous, is fraught with security vulnerabilities, and will not stand up to a security or a SOX/financial audit. In order to run bots in an unattended mode, the industry is moving towards providing bots with their own identities that are in between a User Identity and a Service Account/Identity. These bot IDs are treated as privileged accounts and are given application entitlements for the applications that they use/invoke. Similar to a Service ID since a Bot ID is not associated with a person, each Bot ID is assigned to a custodian who is responsible for verifying the entitlements of the Bot ID and responding to the periodic compliance reviews that are a part of the Identity Governance process.

The main RPA vendors store the Bot ID credentials in their databases using 256 bit encryption. While this is good, it does not address many of the issues related to secure credentials. For example, this mechanism of storing passwords does not support Two Factor/Multifactor authentication. In addition, like any service account credential that is stored in a database/config file, changing the passwords becomes very laborious. As a result, these IDs end up being setup with non-expiring passwords which introduces its own vulnerabilities. Bot IDs should be treated as privileged accounts since the risk of a security compromise is high where a bad actor can take control of a Bot ID/password if not protected correctly. With a hijacked Bot ID, a bad actor can play havoc in the enterprise. It is important to remember that a hijacked Bot ID is authenticated into the network and a hacker will likely be able to invoke the Command Line Interface (CLI) and use it as an entry point/springboard to traverse across the network and take control of important servers. Like Service Accounts, if a Bot ID is not treated as a privileged account and not monitored proactively, any misuse can go unnoticed for a long time. A relatively easy way of securing the bot credentials is through the use of Privileged Access Management (PAM) tools which are being implemented across the government as a part of the DHS CDM program. As a part of this program, DHS has procured licenses for various tools including IGA and PAM tools and is providing it to various agencies for their use. PAM tools (e.g. CyberArk, BeyondTrust, CA PAM, Thycotic, etc.) offer a host of features to manage privileged accounts including a secure vault to store the passwords, multifactor authentication with factors including Mutual TLS certificate – client side certificate, Whitelisting of host name and ip address where the credential is be released to, OS user running the process / making the request, Directory of the source of the executable, etc. PAM tools also perform session management by continually monitoring the session that the bot is running with the ability to pause or kill a session if the bot runs a command that is outside its authorized use. This will immediately catch any bad actors if they succeed in hijacking a privileged session. In addition, the PAM tool can rotate the password after each use greatly reducing the risk of a compromised ID.

According to the American Institute of CPAs, Segregation of Duties (SOD) is a basic building block of sustainable risk management and internal controls for a business. The principle of SOD is based on shared responsibilities of a key process that disperses the critical functions of that process to more than one person or department. Without this separation in key processes, fraud and error risks are far less manageable. SODs take two main forms – SODs between software environments where a user from a Non-production/Development system should not have access to a production system. Within the production environment, critical functions within a workflow should be distributed among more than one person. For example, a user who has the entitlement to create a refund should be different from the person who has the entitlement for approving the refund for payment. SOD rules for BOT IDs should be treated exactly as regular User IDs. Dissecting this further, when developing and testing a bot, an agency should use a different bot ID than the one that is used for production. Also, within production, when automating a process, use two different bots for different parts of the workflow that mimics a regular user SODs i.e. create different bot roles and different IDs associated with these roles. For example, create IDs where one Bot ID has the entitlement to create a refund and second one to approve it. This is automatically enforced if you provision the IDs with an IGA system. When provisioning Bot IDs in an IGA system, agencies will need to consider the following factors: 1) Employee ID / Bot ID – ID naming convention for Bot IDs should be different to allow easy differentiation 2) SSN – A dummy SSN range should be reserved for Bots. This range is dependent on the validation checks of the IGA system in use 3) Name – Bot naming convention 4) Supervisor/Manager – This should be the custodian of the Bot.

The three main tenets of audit are to demonstrate organizational integrity, demonstrate quality and continuous improvement, and provide risk-based assurance. It is also important to remember that an audit reviews the processes and the artifacts/data resulting from those processes. It is important to keep the three tenets of an audit in mind while designing bots. While it should not matter for an audit if a workflow process is carried out by a human or a bot as long as the process and the artifacts can be shown as repeatable and of high quality, it is important to involve audit organization within the agency and its Chief Audit Executive (CAE) as a part of the design and build of a bot to let them review and walk through the process being automated, the code/logic and associated parameters, and the audit evidence being produced (such as audit logs) to show them the integrity of the process, the segregation of duties built into the process as described above, the non-repudiation of Bot IDs where the risk of an ID hijack are mitigated, and the monitoring activities. The task of monitoring bots is made significantly easier through the use of Privileged Access Session Management (PASM) that is a part of a PAM solution where the entire session executed by the bot is recorded.

Software robots can impersonate people to access resources on their behalf or can use a shared account to access some resources. In both cases, software robots should have their own non-repudiated unique identity for getting access to IT resources. They should also employ commercial credential vaulting solutions to control software robots’ use of credentials. Implementation of a PAM solution is a very good method to the controlling and monitoring of Bot IDs. Some of the key controls for the Identity Governance of Bots include:

  • Authentication: Instead of storing the bot credentials in code or software, a credential vault or a PAM solution is the preferred choice.
  • Authorization and Segregation of Duties: Limit software robot credentials to specific tasks, processes, systems and environments. Clearly define the software robot development process, its role and entitlements held.
  • Life Cycle Management: Model a Bot Identity lifecycle management similar to a contingent worker in an organization. Each software robot needs to have a custodian and a sponsor. The sponsor creates and maintains the bot while the custodian runs and evaluates the results of the processes carried out by the bot.
  • Unique Identifier: Software robots need to have an unique identifier. This unique identifier enables effective monitoring, reporting, certification, and analytical functions.
  • Ownership Management: Software robots’ ownership should be identified to ensure accountability for software robot actions. Also, assignment and transfer of ownership should be tracked if, for example, custodians delegate their responsibility to another person or if a custodian retires.
  • Credential Management: Credentials of software robots should be protected in credential vaults. This can be combined with single sign-on to simplify the access.
  • Deregistration: Software robot identities should be deregistered when there is no need for the bot’s functionality. This is important to prevent orphan software robot accounts, which can result in potential access vulnerabilities in the environment. A mature IGA system in place in an organization will automatically take care of this as a part of the periodic attestation / recertification process where all IDs and their accesses are reviewed at least annually.