IDPro Editorial Committee
It is likely that IDPro members are grappling with providing identity and access management services to a newer type of identity in the enterprise that is not a human, is not purely functional and not always privileged, and may have traits that apply to all – bots. Bots can duplicate human interaction with applications or automate tasks or end-to-end business processes traditionally done by humans. Bot identities need to be available for use by robotic process automation (RPA) software, where the intelligence about the functions the bot’s accounts are performing typically lives. Thus, the bot’s core identity must exist in identity management systems so that bot access is created, reviewed and controlled much like any other worker’s access.
For this article’s purpose, a bot is simply an identity with linked accounts used by software. A bot’s Active Directory account may look a lot like a human’s Active Directory account. Some bots may be deployed with ramped-up functional accounts performing the same maintenance type tasks repetitively on many like-systems – they have a confined scope. Other bots may perform end to end business processes and require the same authentication and authorization services as a human worker to function. Service management platforms need to be able to find bot identity data so that resources can be requested and approved for the bots. Termination, deletion, transfer, certification, separation of duties checks, adequate audit trails, privileged access management, monitoring and a host of other services within the enterprise apply. Each of these services may already exist in an organization for human identities and only need tweaks to make them work well for bot identities. As an example, an inaccurately timed access disablement for a human worker may cause far less organizational stress than an unwarranted access disablement for a bot. A bot owner may have many bots that collectively pose a separation of duties problem for the owner that is more difficult to detect. Identity Governance and Administration (IGA) architectures must evolve quickly to encompass bot identity so that organizations can more safely take full advantage of the new capabilities at their disposal.
The following is a brief list of suggestions for developing basic bot identity capabilities:
- Engage the appropriate teams in discussions about governance and to review access control procedures, audit and compliance requirements, privileged access management requirements, password vaulting, etc. Update cyber policies and standards to include bot identities.
- Recognize bots as a new identity type because it is important to differentiate bots from the rest of the worker population. Being able to identify different populations of nonhuman identities and accounts in the identity data allows the use of those population indicators to determine where the account data should exist and which controls to apply.
- The new worker type should be used to ensure that bots do not automatically pop up in systems, applications, org charts and reports that apply only to people, with unfortunate side effects; bots do not need compliance training, to enter timesheets, get paid or have access to benefit plans. Therefore:
- Have data consumers opt-in to bot data that may be available in data warehouses or other systems that provide data to the organization. Data consumers must make a conscious decision to subscribe to bot identity data if they require it.
- Develop a system or leverage an existing system from which to source bot identities using the new identity type; define a baseline bot identity profile that works for your organization. Use your identity management systems to manage bot account access. (Using bots to manage identity management systems and functions is a fascinating but different topic.)
- Map the bot profile to the user account schema on your major systems and applications. Decide what those account profiles will look like.
- Apply a unique identifier to each bot in enterprises that use a unique identifier for each human identity, to simplify the application of existing identity management and other business processes to bots.
- Create a bot request process in the service management system and enforce consistency in the bot request and onboarding process.
- Tie each bot identity to an approved RPA program as prerequisite to the bot identity creation request. Just as governance and accountability should apply to an RPA program, governance and accountability must apply to the bots that serve them. Wrapping the bot creation process within an already approved bot program adds a layer of oversight and a place to go when follow up on a bot account is needed.
- Tie each bot identity to an owner \ manager during the bot identity creation process; the frontline person accountable for the bot’s existence and access. Have the manager, and a representative of the RPA program the bot is working for, each approve the bot identity’s creation as an added measure of bot population control.
- Add automation to manager changes so that if the manager transfers or leaves the organization a new manager is automatically assigned to the bot.
- Maintain the audit trail including the multiple approvals for bot creation and access. Any additional access provided to the bot also needs inclusion in the audit trail. Going forward, the activity of the bot should be monitored, especially where privileged access is concerned.
- Additional privileged access controls that are applied to people performing privileged access tasks should also apply to bots performing the same privileged functions.
- Certification of bot access and functionality on a schedule appropriate to the functions it performs should be included in the lifecycle.
- Develop an offboarding housekeeping plan to disable and eliminate bot accounts that are no longer needed.
