What is a BOT/Digital Worker?
In the last decade, one of the revolutionary themes to improve business efficiency is automation. Automation of various time-consuming, repetitive, labor-oriented processes is not only improving efficiency but also saving millions of dollars in operating costs, the reduced human error is a bonus.
The dictionary defines automation as “the technique of making an apparatus, a process, or a system operate automatically.”
As per the International Society of Automation, automation is "the creation and application of technology to monitor and control the production and delivery of products and services.”
Automation is a term for technology applications where human input is minimized. This includes business process automation (BPA), IT automation, personal applications such as home automation, and more.
In the enterprise, popular approaches to automation include business process automation (BPA) and robotic process automation (RPA). In general, the term BPA is used when talking about how to apply the concept of automation to business processes, while RPA is used when discussing how to automate a specific, repetitive task
In IT automation “Robotic process automation” is a technology solution to reduce or remove human input and automate the process.
Robotic process automation is commonly known as RPA where "Robotic" describes the program that you can set up to do work—the same way you would—with computer systems and applications. “Process” refers to the work that you want to get done. And “Automation” is what it sounds like—making work happen on its own.
RPA bots, or just "bots", are software programs that you set up to do digital work. They’re not just simple chatbots - they're a Digital Workforce. RPA bots can interact with any system or application the same way a human worker would. It’s as simple as showing your bots what to do, then letting them do the work.
The RPA bots are also known as digital workers, from IT applications and system perspective they mimic human workers.
How is a BOT Created?
Let’s consider a typical repetitive IT scenario of user account creation in a web application. If John wants access to a web application “KnowledgeNet”, he will log in to a ticketing system and raise a ticket to get access to the web application. Once John’s manager Robert approves it the ticket will move into the fulfillment queue.
Once the ticket moves into the fulfillment queue, Smith from the fulfillment team will get notified that he needs to create an account of John in the Web Application “KnowledgeNet”. Now Smith will log in to the ticketing system and validate that John’s Manager Robert has approved the ticket. He will get John’s profile information from the ticket. Next Smith will log in to the administrative portal of “KnowledgeNet” and navigate to account creation screens. He will fill in John’s profile information and click on submit/create profile button. After creating John’s account in “KnowledgeNet”, Smith will change the ticket status to “Resolved” in the ticketing system and notify John that he has access to “KnowledgeNet”.
In RPA the human worker Smith can be replaced with a digital worker “KnowledgeNet Account Creation BOT”. This bot will do the same steps as Smith. It will open the ticketing application, validate the ticket, log in to the “KnowledgeNet” administrative portal and create an account for the requesting user, notify the user and finally resolve the ticket in the ticketing system.
So where is the problem?
Since a digital worker has replaced a human worker, he will need the same credential and privileges as a human. But how we can enforce the same policies on a digital worker? Who will be accountable for BOT’s action? For example, Smith needs to change his password every 45 days, or he is not supposed to store his password anywhere, how we can enforce the same policies on a digital worker?
Security Concerns Associated with ‘Digital Workers
Typically, the BOT accounts or digital workers’ accounts have elevated access to data or services like privileged accounts. However, the BOT accounts cannot be treated as privileged accounts as at any point they are not associated with any human worker/application.
The privileged accounts have three categories:
- Root/Administrator Accounts: These accounts possess full authority over systems and have no restriction for accessing services or data residing on a server. They are considered the most valuable targets for threat actors.
- System Accounts: These accounts are used for running operating system services and can modify the relevant files and configurations. They are typically provisioned with the operating system.
- Service/Application Accounts: These accounts are used for running processes and applications through automated, often unattended tasks. They frequently own or have access to data, resources, or configurations not available to non-privileged users.
The BOT accounts are distinct from privileged accounts, they are more normal human accounts with elevated rights. This causes several security concerns.
- RPA offers a broader spectrum of internal and external application integration and may lead to enhanced cyber threats. A BOT may use multiple credentials to log on to multiple (internal and external) applications.
- Automation of process through RPA without embedding/aligning control design may lead to manual override or unauthorized changes which often go undetected.
- Generic BOT ID often poses a risk of non-compliance to software licenses due to potential indirect usage.
- BOTs stores credentials of multiple applications, which are often empowered with extensive Unauthorized access and use of BOT credentials may lead to data, security, privacy, and fraud risks.
- Due to the high processing capability of BOTs, a delayed response to cyber incidents may lead to inappropriate processing of high-volume/ value transactions.
- BOTs are often not built for intent identification; hence detection of a security breach may be a challenge.
Impact of BOT Identity in Enterprise IAM
Since a digital worker or BOT mimics a human, the identities and accounts of digital workers possess the same threat level as human workers hence digital worker identities and accounts must be treated similarly to human identities and accounts.
Following are the impacted domain due to the introduction of BOT Identity.
- Identity Lifecycle
- How BOT identities should be managed in Identity Governance and Administration?
- How access governance can be implemented for BOTs?
- What should happen after decommissioning of BOT? What process should be followed for access revocation and deactivation of all accounts, and entitlements?
- How the BOT Identity and accounts should be named? What naming conventions should be followed to distinguish them from human and privileged accounts?
- Access request and approval process: Who owns BOTs? Who should raise access requests for BOTs and who will approve them?
- Ownership transfer of BOT’s identities when an owner leaves or moves.
- Accountability: Who will certify the access associated with BOT?
- Credential store: Can BOT utilize Credential vaults to store the passwords?
- Credential thefts: What if BOTs’ credentials are compromised? How to prevent, detect and rectify it?
- BOT activity and session monitoring: Can we monitor BOT activity and session? Can we terminate the BOT session on policy violation?
- SoD Conflicts: What if BOT entitlements have SoD conflicts?
- Gartner and Forrester predict the RPA market will grow 41% percent each year until 2020 and reach $2.9 billion in 2021.
- In a survey done by Forrester Consulting 69% of the respondents said they face difficulty in managing rules that guide bot behavior and 61% responded that the control & operations of RPA bots are immature.
- According to this Deloitte Report, the market for robotic process automation (RPA) is estimated to touch $16.9 billion in 2024.
The organization implementing automation using BOTs must have documented BOT Governance, it can be a slide deck or a detailed manual, or simply a one-pager. The documentation must be reviewed and approved by key stakeholders including the cybersecurity group, internal control staff, application owners, data owners, and business owners apart from the RPA BOT implementation team.
From digital workers’, identity management and governance perspective following are the key components for BOT Identity and Access Governance.
BOT Governing Bodies
The responsibility of governing body is to provide oversight of the RPA program. Oversight includes reviewing risks, ensuring adequate risk mitigation, and confirming which processes can be automated (through process assessments, including reviews of prioritization criteria, process type, and organizational area).
The major stakeholder in this body should be:
- Cybersecurity team who should cover Identity and Access Management, Data Security, Data Privacy, and Risk & Compliance.
- Application Owner/Owners
- Data Owner/Owners
- Business Owner
- RPA Architect
Implementation organization construct includes the people accountable for operational delivery. It should be composed of a hybrid of IT, Cyber Security, and business professionals. Even if your IT group leads all development, individuals in business units will need to support the documentation of existing processes which must include existing identity and access management processes, help define requirements for the automation solution, and participate in user-acceptance testing.
Implementation organizations must have clearly defined roles and responsibilities for each person who owns a component of operational delivery, regardless of whether that person is a direct report to the leader of the program or a staff member sitting in another team who provides part-time support. It must define the support model post-deployment, including the training and development plans for the individuals fulfilling the various program roles.
The IAM Team lead will help the application owner, data owner, and business owner to define the ownership of BOT Applications, BOT Identities, and BOT Accounts.
Operational Life Cycle
This governance component’s primary responsibility is to define the stages through which automation ideas must progress, from ideation to deployment and benefits realization. Answer the following questions: How will automation ideas be generated and captured? What criteria will be used to assess opportunities and determine if they should be developed? Will processes be reviewed before their being promoted into production? Who needs to review or approve an automated process before it’s used by the business? What software development life cycle will be employed? What change management processes need to be executed before a human turns a process over to a bot? What documentation is needed? How will process maintenance or support for processes that break post-deployment be managed? What business continuity plans are needed to ensure any potential interruptions to critical processes don’t negatively impact the business?
The cybersecurity team including the IAM team will review each process by the standard and process defined. He will be responsible to define the process of following:
- BOT Application Management
- BOT Identity Management which includes the Identity Lifecycle Management
- BOT Access Governance and Certification
- Naming Conventions
- BOT Access management
- BOT Ownership transfer process.
- BOT Credential Management and Integration with Credential Vault
- BOT Activity and Session Monitoring
- BOT Birthrights and SoD Policies if feasible.
The internal control team will review existing internal control policies, and consolidate risks that have been identified by key stakeholders at the program level and the individual automation opportunity level. They will
create a risk register those details on how each risk is mitigated and review it at regular intervals.
The risk mitigation measures in the register should translate into controls that are embedded within the operational life cycle. This section should cover these controls and how implementation will maintain adherence to existing internal control procedures, including documentation requirements for audits. Bear in mind that some existing procedures may not apply to bots. The internal control team needs to agree to these exceptions, and a standard treatment for digital workers needs to be established. Specifically, the approaches to bot-naming conventions, the storage of account credentials, internal control reviews for BOT processes before deployment, and internal audits of critical processes performed by bots should all be agreed on and documented.
Most organizations should already have existing documentation related to technology governance. The existing technology governance documents will require updating to incorporate RPA risk. When engaging stakeholders, particularly in the IT and cybersecurity groups along with representatives from the selected RPA software vendor, the following topics will be important to discuss and document
- Application management,
- Credential management including connectors
- User/Account/Role management
- Licensing structure
- Version management for code packages
- Technology continuity in the event of outages
- Business process continuity
- Cybersecurity risks
- Approach to data storage and data privacy
- Coding standards, and
- Best practices.
Also, implementation of general IT controls, including network security, audit logs, the applicability of segregation of duties, user access provisioning, encryption, and use of privileged user accounts must be considered.
BOT Governance Use Cases in IAM
Since BOTs mimic the human operator behavior all use cases applicable to human identity will apply to digital worker/BOT Identity. Following is a high-level list of applicable use cases for BOT Governance
- Identity Management
- BOT Application Registration: Registration of RPA Application which uses RPA BOTs in Identity Manager distinguished from other business applications/systems.
- BOT Identity Management: In identity lifecycle management for BOT Identities, the naming conventions should be implemented to distinguish it from human identity. The manager/supervisor must be a human identity who will be the owner of the BOT Identity.
- BOT Accounts Management: Management of BOT Account with appropriate role, entitlements, and permission to execute the BOT operation.
- Access Management (Authentication/Authorization)
- BOT Access Management: Implementation of access controls for BOTs which includes authentication and authorization policies. This use case may require exception approval for certain security controls such as captcha, and multi-factor authentication.
- Privileged Access Management
- BOT Privileged Access Management: Since BOTs have elevated privileges so the BOT Operations must be performed under privileged sessions. The BOT must check out credentials before operation and check in credentials after the operation. The BOTs can use PAM API for the operation.
- BOT Privileged Activity Monitoring: The BOTs must execute the operation as per defined policies if any operation violates any policy the session must get terminated and an alert/audit event must be raised from an audit and compliance perspective.
- Access Governance
- BOT Access Certification: This certification is identical to access certification for other business applications. The frequency and trigger for the access certification can be defined as per compliance and data classification requirements of the business application on which the BOT operates.
- BOT Risk Modelling
- BOT execution policies: These policies include at what period of the day BOT should, from which data center/network segment they should operate as well as the specification of machines which BOT should use to operate.
- BOT Provisioning Workflows & Entitlement Management: This use case will detail out what are the roles, entitlements, and access permission BOT accounts should be provided as a birthright as well as on approval of access request. It will also define the type of access approval workflow as per organization policy for the business application which is used by BOT.
- BOT Entitlements & Segregation of Duty (SoD) conflicts
- BOT Analytics
- BOT Performance
- BOT ROI
BOT Governance in NetIQ
The NetIQ Suite has capabilities to provide BOT Governance. All the use cases that we have discussed in the previous section can be realized by NetIQ Suite products.
The NetIQ platform already manages applications, identities, accounts, and privileges. To support BOT Governance and distinguish them from the human identity they need additional attributes to identity and application.
This additional attribute can be an identity attribute, a group, or a separate OU/nested OU.
The NetIQ Suite can offer a complete BOT Governance framework to govern BOTs (RPA/Non-RPA) including BOT ID Management, BOT Access Management & Certification, and BOTs Credential Management. The solution can have an analytical dashboard that will help customer to find the BOT ROI analysis.
The CyberRes Advantage
With decades of experience in corporate security, Micro Focus has deep knowledge of every aspect of zero trust. We can shine a new light on your people and data, showing you the best ways to protect them while working with your existing solutions to make them a part of a coherent, up-to-date, well-functioning whole. Learn more at CyberRes.com.
NetIQ provides security solutions that help organizations with workforce and consumer identity and access management at an enterprise scale. By providing secure access, effective governance, scalable automation, and actionable insight, NetIQ customers can achieve greater confidence in their IT security posture across cloud, mobile, and data platforms. Watch video demos on our NetIQ Unplugged YouTube channel. NetIQ is part of CyberRes, a Micro Focus line of business.