IBM Robotic Process Automation security

The IBM Robotic Process Automation product was born on the cloud and is now available in on-premises deployments. Being cloud-native, IBM RPA is designed with strict security design principles that use built-in cloud security features. IBM RPA features IBM's world-class security practices and requirements.

Understanding IBM RPA's security posture requires a basic understanding of IBM RPA's component design and how those components work together to provide enterprise-ready features clients can depend on.

  • IBM RPA Control Center
    The IBM RPA Control Center is the user interface collection of robot management features that enables administrators, developers, and business leaders to manage the client's robot assets. These features include the robot repository, publishing robot's for business users to easily run in an attended fashion, building and viewing business dashboards, and scheduling robots for unattended execution. The IBM RPA Control Center is hosted on the server-side service management of the IBM RPA topology. UI access paths are secured with HTTPS, and the management console adapts its features based on your configured role.

  • IBM RPA's API server
    This component provides the business logic for the IBM RPA Control Center, hosted on the server-side service management of the IBM RPA topology. Endpoints are secured with HTTPS over TLS 1.2.

  • IBM RPA Studio
    You can use the IBM RPA Studio to develop and test the robotic automation scripts, which are then published through the API server to the IBM RPA script repository. The repository is hosted in a service-side IBM RPA relational database. The IBM RPA Studio is a rich Windows client, and is hosted on the developers' Windows workstation or laptop.

  • Bot Agent
    The Bot Agent is a local client-side component of IBM RPA installed as a Windows service. Its primary responsibility is to manage the activities and settings of the host computer by communicating with the IBM RPA server.

  • IBM RPA Launcher
    The IBM RPA Launcher provides a simple interface for business users to start configured attended bots whenever necessary in their daily business. Users are required to authenticate with the security provider configured for IBM RPA.

  • Bot Runtime
    The Bot Runtime provides the container for a robot in operation. IBM RPA bots run on the configured Window's host. The client manages the robot computer resource for operation.

    The IBM RPA consumer is in full control of the client guests, the client guest security policies, maintenance schedules and policy, operating system's firewalls, and other security controls. You can ensure that sensitive data and access to sensitive internal systems stay in-house. The Bot Runtime runs under a configured system user, which can have less permission than the Windows administrator.

  • IBM RPA Vault
    The IBM RPA Vault is hosted on the client's Windows host, and credentials for specific robotic access to system services are stored there. While IBM RPA allows credentials to be configured in the management server, it also provides facilities to use asymmetric keys. IBM RPA gives the public key to the management server for encrypting credentials and retaining the private key on-premises for decrypting credentials. The management service has no access to the private key.

  • SDLC
    IBM RPA enforces Secure software development lifecycle (SDLC) by following IBM's Security and Privacy by Design practices, an agile set of focused security and privacy practices.

IBM RPA security principles

Security cannot be bolted onto products, and IBM has a disciplined Security by Design approach to ensure that a methodical approach is used to design a strong security posture.

IBM has strict processes in place to consider alerting the customer to critical security considerations, including the IBM Product Security Incident Response Team (PSIRT) security remediations, periodic software as a service (SaaS) and on-premises third-party and internal penetration testing, and on-going security monitoring to identify threats. For more information, see Secure software development lifecycle.

IBM RPA networking

The following list defines the main security measures of IBM RPA networking:

    Secure HTTPS traffic ensures that no man-in-the-middle attacks are possible between components and ensures that the request body is encrypted from the IBM RPA client's environment to the IBM RPA server's environment.

  • Updates
    For the SaaS offering, the IBM RPA product team regularly reviews and updates the minimal TLS algorithms, which can be used to transfer data on the wire. Staying current is paramount for secure networking.

  • Client outbound port design
    Client's communicate with the IBM RPA management components through SignalR two-way protocols, such as web-sockets. While the IBM RPA management components do send data to the client's over these protocols, the client components must first log in to the IBM RPA management components and establish a communication channel: client outbound port to IBM RPA management inbound port. Only then can the management server send the client data. For more information about ports, see the requirements topic of the Installation section for the offering you want.

  • SaaS networking
    IBM RPA SaaS offering uses Azure Web Application Firewall (WAF) on Azure Application Gateway to provide enterprise protection against security attacks on public websites, such as SQL Injection, cross-site scripting, among others. IBM RPA site reliability engineering (SRE) manages the policy in the Azure Security Center and is alert to key vulnerabilities, such as the configuration of the TLS policy. For more information about WAF, read Microsoft's Azure Application Gateway features External link documentation.

IBM RPA encryption

In the IBM RPA SaaS offering, all the server-side disks are encrypted, which means data at rest is encrypted at the disk level. The encryption keys are platform-managed by Microsoft. For more information, see Microsoft's Azure Data Encryption at rest External link security documentation.

Federal Information Processing Standards (FIPS) are standards that describe document processing, encryption algorithms, and other information technology standards. The National Institute of Standards and Technology (NIST) developed FIPS to use in computer systems by non-military American government agencies and government contractors.

Being FIPS compliant means that a Cryptographic Module meets the requirements for each level and can be validated, if necessary. Starting from version 21.0.1, IBM RPA is FIPS 140-2 compliant if FIPS mode is enabled. See details in FIPS control center interface.

Note:Some of IBM RPA dependencies on Red Hat® OpenShift® Container Platform are not FIPS compliant, like IBM Automation Foundation and IBM MQ.

To learn more about IBM RPA's data encryption, see the Data encryption topic for each IBM RPA component in this documentation.

  • Bot Agent data encryption
    All the data traffic between the Bot Agent and the IBM RPA server is encrypted with the HTTPS protocol over TLS 1.2.

  • Bot Runtime data encryption
    Data traffic between the Bot Runtime and the IBM RPA server is encrypted with HTTPS over TLS 1.2.

  • IBM RPA Control Center data encryption
    The communication between IBM RPA Control Center and IBM RPA's API uses secure HTTPS over TLS 1.2 protocol. The communication between a user and IBM RPA Control Center uses the same protocol.

  • IBM RPA Launcher data encryption
    Data that is exchanged between the IBM RPA Launcher and the IBM RPA's API uses a secure HTTPS connection.

  • IBM RPA Studio data encryption
    Data traffic between IBM RPA Studio and the IBM RPA server, like scripts and machine learning models, are encrypted by using HTTPS. Sensitive information is secured by using the Windows Data Protection resource.

  • IBM RPA Vault data encryption
    IBM RPA Vault has two methods: the system and the local vault. Both of them use asymmetric encryption, and they both are responsible for the configuration and encryption of credentials.

IBM RPA authentication

The following list defines the authentication methods available in IBM RPA:

  • Custom User Registry
    IBM RPA product was introduced with a custom-user registry to support SaaS accounts and provide the portals that are required to manage user accounts. Passwords are stored by using a salted hash algorithm and are unknown to the IBM RPA SRE team. Self-service resets are enabled through configured email account to ensure that only the registered email can request a password reset. A configurable login-token timeout value can be configured to ensure that logins expire at the frequency that is dictated by the organization.

  • Single-Sign On
    An alternative for IBM RPA on premises, SSO is supported by using the IAF ODIC provider, which allows integration with various enterprise directories. The specific enterprise directories and SSO providers can optionally be configured for Multi-Factor Authentication.

IBM RPA authorization

IBM RPA has five pre-defined roles to isolate critical administration features from users of the IBM RPA system: platform administrator, tenant administrator, bot developer, business operator user, and normal user roles. For the IBM RPA SaaS offering, only administrators and normal users are represented.

These roles provide permission sets to allow for the administrators to be segregated from permissions for general robot users. The IBM RPA Control Center adapts the interface to the specific role of the logged-in user. For more information about roles, see Role-based access

IBM logging and monitoring

You can view logs and monitor resources in the IBM RPA Control Center. For more information, see Data visualization in IBM RPA Control Center.