AAI Automation 360
AAI Automation 360
March 1, 2023
Legal Notices
© 2023 Automation Anywhere, Inc. All Rights Reserved.
See the list of Automation Anywhere trademarks at https://www.automationanywhere.com/trademark.
All other customer or partner trademarks or registered trademarks are owned by those companies.
The information contained in this documentation is proprietary and confidential. Your use of this information
and Automation Anywhere Software products is subject to the terms and conditions of the applicable
End-User License Agreement and/or Nondisclosure Agreement and the proprietary and restricted rights
notices included therein.
You may print, copy, and use the information contained in this documentation for the internal needs of
your user base only. Unless otherwise agreed to by Automation Anywhere and you in writing, you may
not otherwise distribute this documentation or the information contained here outside of your organization
without obtaining Automation Anywhere’s prior written consent for each such distribution.
Examples and graphics are provided only as reference information and might not match your site.
Content
Automation 360
About Automation 360
The Automation Anywhere Digital Workforce platform is the foundation to deliver the automation of
complex business work securely and at scale. Automation 360 is an industry-leading RPA and digital
workforce platform that combines an easy-to-use user interface with enterprise-class reliability and the
security to enable real-time self-automation.
Overview
Automation 360 is an industry-leading RPA and digital workforce platform that combines an easy-to-use user
interface with enterprise-class reliability and the security to enable real-time self-automation. It delivers a
browser-based, intuitive experience for business users to quickly automate tasks and tools for developers to
build process automation. Automation 360 provides both On-Premises and Cloud deployment options and
is the first platform that provides RPA-as-a-Service as an automation solution. It enables users to automate
applications across different infrastructures and industries such as banking, telecommunications, and
business process outsourcing (BPO) organizations.
• An intuitive interface to create a bot and design business process automation workflows.
• Support for multiple operating systems including Windows, Linux, and MacOS.
• Different views of bot to facilitate collaboration: flow view for business users, list view for developers,
and dual view for collaboration.
• Recorder that works across various platforms such as Microsoft Windows, Citrix, Web, and SAP.
• Advanced variables capabilities and support for JavaScript, Python, and VBScript.
• A flexible architecture that enables you to add new command packages.
RPA Workspace
A web-based workspace that provides the tools and capabilities to create, upload, and deploy bots to
automate repetitive tasks and processes. It includes the following:
• Control Room
• Bot Runner
• Bot editor
• Bot Creator
• Credential Vault
Process Discovery
An intelligent business solution that delivers a real-time, data-driven map of your business to help you
uncover transformational process insights across all applications, through each department, and for
every single task. Process Discovery follows the human instead of process logs by using advanced
computer vision, machine learning, and artificial intelligence to capture every step in every process
across every system. It requires zero integration, is universally compatible, and provides the privacy and
security of an on-premises solution.
Privacy Enhanced Gateway
Using Privacy Enhanced Gateway (PEG), enterprises can confidently execute on their strategic business
initiatives by filtering their sensitive data in a secure and scalable manner. PEG works by redacting
sensitive data that has been obtained on customer's machines within their own network before
forwarding the data to the Process Discovery cloud for analysis. As all traffic from the agents goes
through PEG before leaving the customer's perimeter, PEG removes personally identifiable information
(PII) and sensitive data.
Discovery Bot
An intelligent business solution for enterprise businesses that provides capabilities for end users to
discover opportunities for automation using process discovery. Discovery Bot focuses on process
automation by capturing document processes, identifying opportunities from business centric
processes, and prioritizing opportunities based on ROI, and create bots automatically. Discovery Bot
aligns business workers to uncover automation opportunities that can optimize the return on your RPA
investment.
IQ Bot
An intelligent document processing solution that can read and process various complex documents
and emails. IQ Bot combines RPA with multiple AI techniques to intelligently capture, classify, and
extract semi-structured and unstructured data, allowing document-centric business processes to be
automated end-to-end.
Bot Insight
The analytics platform that provides real-time, interactive, and smart insights about business processes
and operational intelligence. Bot Insight uses the large amount of content-level and productivity data
that the deployed bots generate and translates the data into insights through automatically generated
and customizable dashboards.
Bot Store
Online marketplace for pre-built bots and Digital Workers that run on the Automation 360 platform.
Access Bot Store directly from the Control Room to download or submit bots and packages.
Bot Store
Benefits
• Instant web-based deployment that enables you to start developing bots quickly
• An intuitive interface that enables users with varying skill levels to easily use the product and
speed up the learning process
• Easy collaboration between business, process, and IT
Business agility
Deployment models
Cloud
Automation 360 Cloud is hosted by Automation Anywhere, providing an easy consumption model of
the Automation 360 platform built on a cloud-native architecture. With the Automation 360 Cloud
service, the Automation 360 platform, which includes the Automation 360 Control Room and
applications (RPA Workspace, IQ Bot, Bot Insight, AARI, and Discovery Bot), is hosted by Automation
Anywhere and accessed by users through a web browser. The Bot Agent devices where the bots run
and execute the automations remain on the customer's infrastructure and securely connect to the
Automation 360 Cloud service through HTTPS.
Cloud-enabled
In this deployment model, data is hosted On-Premises. This model is suitable for customers who have
to adhere to strict regulatory norms where data sovereignty is mandatory.
On-Premises with packages updates through Cloud
With Automation Anywhere On-Premises with packages updates through Cloud service, all business,
personal, and operational data is kept on and deployed from the server on-premises on the customer
network.
The following image shows the deployment models for Automation 360:
In-product guide
Automation Anywhere uses a digital adoption platform to provide in-product user assistance (guides and
walkthroughs) and anonymously analyze product usage such as page views and feature clicks. This data is
used to inform user research and improve the overall experience of Automation Anywhere solutions.
Services performed
Data processed
Note: The digital adoption platform does not receive the user's IP address or bot
information such as which bot was run and what the bot does.
• Event data
Includes click and focus events providing usage metrics. This enables us to understand the
adoption of features and usage patterns to inform future improvements to the experience of our
products.
For example:
Includes data captured as users navigate to various parts of the web application, such as root
paths of links and page titles
Note: The platform does not collect any input parameters sent through a link.
• Metadata
Includes metadata that is associated with clicks and page loads when a user logs in to
Automation Anywhere products.
Metadata that is sent to the digital adoption platform includes the following types of information:
• Pseudonymized user ID
• Pseudonymized account ID
• Selected language
• Build number
• Browser version
RPA overview
Related information
Components
The Control Room is a centralized management point for all bots. A reverse proxy is responsible for listening
for remote connection requests and forwarding those requests to the correct specialized service. The
following figure shows the Control Room components and general data center interaction. Control Room
components are shown in orange and data center components provided by your organization are shown in
blue. Components that are centrally hosted on cloud and managed by Automation Anywhere such as
license server are shown in white.
In the data center, Control Room is installed on a server and configured to interact with the other data
center components.
• Elasticsearch
• Licensing
• Control Room acts as the single point of access and control for bot execution.
• Control Room provides bot upload and download features to facilitate seamless collaboration for end
to end business process automation by multiple users.
• All scheduling is managed by the Control Room. Bots are deployed on the Bot Runners either ad hoc
or on pre-defined schedules. Once the schedules are created, Control Room automatically and
intelligently picks up the subsequent updates to bots, without any need to alter automation schedules.
• Least Privilege and Access controls user access. They are implemented in the Control Room through
Role Based Access Control (RBAC).
• All Users and Roles are created and managed from the Control Room.
• Control Room dashboards provide a single view of the entire automation infrastructure.
• Control Room receives real time heartbeat and telemetry from automations with events, exceptions
and alerts.
• Unauthorized users cannot pause, resume or stop any of the ongoing automations on any Bot Runner.
• All historical automation data is logged in and available through Control Room Audit Logs.
Related information
Control Room overview
Distributed architecture
Automation Anywhere platform is deployed using a distributed architecture.
Centralized management is accomplished via a web-based server, called the Control Room, to manage all
development and execution of the digital workforce. The Control Room is connected to Bot Creators and
Bot Runners. Bot Creators are development systems used for authoring and tailoring of automations. Bot
Runners execute the automations; they are run-time systems installed on machines. Bot Runners can be
deployed on desktops, on virtual machines in data centers or cloud.
Automation Anywhere supports distributed architecture to deliver the optimal performance and security.
Following are the main distributable components of Control Room which can be clustered to achieve High
Availability (HA). In the image below, Automation Anywhere components are shown in orange and
components provided by your organization are shown in blue. Components that are centrally hosted on
cloud and managed by Automation Anywhere such as license server are shown in white.
Distributed Cache
Control Room architecture uses distributed cache to update all other nodes as soon as any information is
updated in one of the nodes. This ensures fastest data synchronization across all the nodes and delivers
seamless user experience. Automation 360 platform uses clustering mechanism to implement distributed
cache, to synchronize all data operations. For example, when the Credential Vault is opened from one node,
it is automatically opened for all other nodes too.
For information on HA/DR architecture for Automation 360 Cloud, see Automation 360 Cloud Security and
Data Privacy.
Related concepts
HA and DR deployment models
Security architecture
Many of the largest financial organizations in the world rely on the Automation 360 secure digital workforce
platform to automate security-sensitive operations.
The platform's security architecture is founded on Least Privilege principles and a strict Separation of Duty
model with 41 technical controls implemented across seven NIST 800-53r4 Control Families. Controls are
applied across three components: the Control Room, Bot Creators (development systems), and Bot Runners
(bot execution run times) through the bot life cycle from creation through decommissioning. This security
architecture and the underlying controls are mapped to industry best practices as defined by NIST and can
be readily mapped to other frameworks, for example, CoBIT (SOX) and ISO 27002.
Access controls
Automation 360 limits and controls human and bot access to logical resources across components.
• Two independent control planes enforce least privilege. Only developers are enabled to read or write,
only authorized Control Room users to execute automations, (Control Room authorizes and executes)
subject to fine-grained Role Based Access Controls (RBAC) down to individual automations (bot), Bot
Runners and domains.
• Bot- level Separation of Duty is enforced. Each bot is obfuscated and executed by its corresponding
authorized Bot Runners.
• Bot execution is controlled via RBAC. Domain privileges are defined across groups of bot and Bot
Runners.
• Security at-rest and in-transit: All access credentials are secured at-rest via a central Credential Vault
with support for third-party credential stores. All communications are secured in-transit via SSL and TLS.
Configuration management
• The Control Room authorizes, enforces, and logs changes to all Bot Creators and Bot Runners.
• Bots are controlled via a robust version control system, for rollback and full event logging.
• Bot change control on execution is enforced through encryption and authentication.
Risk assessment
Risk assessment is undertaken on Static, Dynamic, and Network-based Vulnerability Assessments. Audit and
accountability are established through event capture, logging and auditing on all three components with
granular event capture at the bot level and nonrepudiation. Bot Insight embedded analytics provides near-
real-time Incident Response and integration with Security Event and Information Management systems.
Related information
RPA Security
The NIST framework was selected as a foundation for best practices as a way to enumerate the controls
implemented throughout. Translations from NIST to other control frameworks are widely available,
resources are provided at the end of this topic.
The product security architecture is maintained by the Automation Anywhere Product Management team
and forms part of a formal policy model as an integral part of the Automation Anywhere Development
Roadmap. The following table lists the Control families and the corresponding features and security impacts.
Details on each Control family and how the security architecture is implemented in Automation Anywhere
products are in the corresponding topics.
(1) Resources: ISACA provides guides that map NIST SP800-53 to other security frameworks such as CoBIT
(SOX), SANS Top20.
Learn about secure deployment models, data element locations, and operational responsibilities.
Automation Anywhere Cloud is deployed to only allow access to Automation Anywhere Cloud Operations
personnel and Security Team resources. Network and cloud control plane access is restricted using VPN
with multi-factor authentication for AAI operational and security personnel. All AAI users must first
authenticate using MFA tokens to retrieve short-term credentials to access cloud resources. User credentials
are continuously monitored for compliance. All other operational users, cloud resources, and applications
are restricted from access to the Control Room. Regular AAI user access certification is conducted to ensure
only necessary access is provided to cloud operations personnel.
The cloud service is multi-tenanted and each customer control room environment uses a unique tenant
identifier to ensure data separation between the Control Rooms. Automation Anywhere members cannot
access a customer environment unless specific permission is provided by the customer, typically under
support troubleshooting procedures and controls.
Cloud
With the Automation AnywhereCloud offering, all business, personal, and operational data is stored on
Automation Anywhere administered cloud. Automation Anywhere is the cloud data controller and is
responsible for customer data privacy as published in accordance with Automation Anywhere cloud
security and compliance with data privacy.
Cloud-enabled
With the Automation Anywhere Cloud-enabled solution, business, personal, and operational data is
stored and managed on the customer-controlled infrastructure, while specific operational data related
to RPA is shared between the Automation Anywhere Cloud and the customer infrastructure. All data
privacy and compliance rests with the customer.
On-Premises with updates through Cloud
With Automation Anywhere On-Premises with updates through Cloud service, all business, personal,
and operational data is kept on and deployed from the server on-premises on the customer network.
All data privacy and compliance rests with the customer.
The following table lists the securing data and operations responsibilities:
On-Premises
with updates
Data requirement Cloud Cloud-enabled
through
Cloud
Automation
Data localization Customer Customer
Anywhere Cloud
Automation
Data privacy Customer Customer
Anywhere Cloud
On-Premises with
Cloud-
Data type Cloud updates through
enabled
Cloud
Cloud. For
Customer business data
more Customer
Customer network
information network
• Customer personal data
on Cloud
On-Premises with
Cloud-
Data type Cloud updates through
enabled
Cloud
storage
information,
• Business data used in
see
automation
Automation
360 Cloud
FAQ.
Operational data
Personal data
RPA platform
This topic details the best practices for securing the RPA platform with external security controls. Network-
based firewalls, Intrusion Detection Systems, anti-malware, and external log servers are all standard security
controls that are relevant to RPA deployment and the other infrastructure in your environment. The following
figure shows logically where these components are deployed in the RPA deployment:
In the image, Control Room components are shown in orange and data center components provided by
your organization are shown in blue.
Each external security control is discussed in detail in the following sections, in terms of placement and
configuration. Supporting network services such as Active Directory, SMB File Share, Microsoft SQL Server,
and production applications, and are accessed through network firewalls or directly, depending on their
placement relative to the RPA components.
Network-based firewalls and local server-based firewall are used to protect the Control Room or all nodes in
a Control Room cluster. By default, required protocols on the Control Room are permitted from the
corporate network. Additionally, all clustering protocols are permitted only between the nodes in the Control
Room cluster. Network-based firewalls are used to isolate Development, Test, and Production RPA
environments from the corporate network and from each other.
For unattended automation environments, the Bot Runners are placed in a specific isolated network and
protected by a network-based firewall. Attended automations run from corporate workstations with the Bot
Runner Bot Agent installed and are protected via the corporate perimeter firewalls or internal firewalls
protecting the corporate desktop infrastructure, like any desktop.
The Automation Anywhere Bot Agent runs on desktop class infrastructure and is considered a corporate
desktop. Anti-malware or anti-virus software is used to protect the registered device environment from
malicious software in the form of viruses and malware.
Intrusion Detection and Prevention Systems (IPS) protect the corporate network by detecting network-based
attack through network traffic analysis. Like any other critical section of the data center, an IPS protects the
RPA platform at the egress point, behind the network-based firewall.
Bot Creators exist on a separate Microsoft Windows system with its own credentialing system to create,
update, and unit test the bots on the Bot Creator. Bot Creators only upload and download bots to and from
the Control Room. Users on the Control Room users have privileges to execute bots on Bot Runners but
have no access to the Bot Creators. This separation of duty constitutes a dual authorization by requiring both
the developer and the business user to create and execute the bot in conformance with NIST AC-3 best
practices.
All Control Room users are assigned one or more roles. Access are available based on the usage conditions
assigned to each role when users are a member. Authorized users can temporarily or permanently suspend
other users when needed. RBAC enforces session handling to prevent unauthorized access. If an
unauthorized user attempts to view session details or gain access, the Control Room cluster will prevent this
progress and immediately terminates the unauthorized session. The unauthorized user will be prompted to
log in with valid credentials. Inactive accounts can be disabled.
The administrator controls are responsible for all security functions, consistent with best practices in NIST
SC-3: Security Function Isolation.
The Control Room includes segmented administrator roles by default. Many permissions are supported for
creating new roles.
Controls are implemented at the Control Room, Bot Creators, and Bot Runners layers, for NIST Access
Controls (AC) and Change Management (CM) guidelines. The following technical controls are implemented
to ensure access is governed through NIST Least Privileges.
• RBAC on bots
• RBAC on Bot Runners
RBAC on Bot Runners facilitates complete isolation of one department Bot Runner seamlessly from the
remaining departments' Bot Runners.
• RBAC for Credential Vault credentials management
Credentials created in the Control Room are used across Bot Creators and Bot Runners.
• Role-based processing domains
The Control Room RBAC applies the least privilege principles to domains by implementing Processing
Domains, specifying role-based privileges and permissions at the bots and Bot Runners level.
• RBAC on Audit Log
Audit is automated for all privileged and nonprivileged roles to conform to best practices, as defined in
NIST AC-6.
• RBAC on viewing bot activity
The Control Room Activity menu provides options shows the status of the Automation Anywhere
Enterprise automations. These options are: In Progress, Scheduled, and Historical.
• RBAC on User Management
Access is deny all and allow by exception based on roles, domains as defined in RBAC. Only those
users with access to User Management can manage other users in system.
• RBAC on roles and permissions management
Access is deny all and allow by exception based on roles, domains as defined in RBAC.
RBAC on bots
Access is deny all and allow by exception based on roles, except for admin roles. Addressing NIST AC-17
(access control), NIST configuration managments for NIST CM-2 (base line configurations), access
restrictions for NIST CM-5, NIST CM-6, and NIST CM-7 (least functionality), and monitoring NIST CM-9 for
bot activity across the development, test, and production environment.
RBAC on Bot Runners facilitates complete isolation of one department Bot Runner seamlessly from the
remaining departments' Bot Runners.
Bots are executed from the Control Room cluster. Local bot executions are protected through multiple
layered security, and are designed to prevent fraud as a result from escalation of privileges on Microsoft
Windows. The Bot Runner are executed by Windows, addressing access control enforcement in accordance
with NIST AC-3 Access Enforcement and AC-6 Least Privilege for Code Execution.
If user roles does not have access to sets of Bot Runners, as a result, these users are unable to view the Bot
Runners' executions or remote scheduling automation. See (Role-based processing domains).
Credentials created in the Control Room are used across Bot Creators and Bot Runners.
These credentials are securely stored in the centralized Credential Vault to facilitate access control, and to
divide in logical groups called lockers. These lockers enable complete separation between the credentials of
one department from another.
Role-based permissions
Locker permissions
Locker permissions are set when a locker is created or edited. A user can have the following permissions in a
locker:
Add Remove
View Edit Delete View Assign Rem
participant/ participant/
locker locker locker credential credential cred
owner owner
Consume ✓
Participate ✓ ✓
Manage ✓ ✓ ✓ ✓ ✓ ✓
Own ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Admin ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Related tasks
Create credential
Create locker
Related reference
Credentials and lockers in the Credential Vault
The Control Room RBAC applies the least privilege principles to domains by implementing Processing
Domains, specifying role-based privileges and permissions at the bots and Bot Runners level.
RBAC is applied at a folder level to completely and seamlessly isolate one department bot from the
remaining department bots. If the user role does not have access to a set of bots, those bots do not exist,
thereby enabling the separation of duties across different domains. For example, finance and accounting
roles can access only the bots that automate their respective functions, and specific Bot Runners can
execute these bots. This is consistent to best practices as defined by NIST AC-4 Processing Domains.
Audit is automated for all privileged and nonprivileged roles to conform to best practices, as defined in NIST
AC-6.
Access is view-only based on a deny all and allow by exception based on roles and domains as defined in
the Audit section 7 addressing Audit and Accountability (NIST AU 1 through 15) and as required by NIST AC-2
Automated System Account Management. If a role does not have permission to view Audit Logs, then the
Audit Trail tab is not visible to all members of that role. Audit automatically captures all events related to
creation, modification, enablement, disablement, and removal of users, bots, Bot Creators, and Bot Runners.
The Control Room Activity menu provides options shows the status of the Automation Anywhere Enterprise
automations. These options are: In Progress, Scheduled, and Historical.
Access to bot Activity status is deny all and allow by exception based on roles and domains as defined in
RBAC. Two levels of checks are applied to access the bot Activity data. The user is required to be a member
of a role that has access to view the Control Room. Users with Control Room access that can view only the
bots belonging to their departments, as applied through RBAC on bots.
Access is deny all and allow by exception based on roles, domains as defined in RBAC. Only those users with
access to User Management can manage other users in system.
Create Users
Only those users that create new users from the Control Room.
Edit Users
Only those users that edit existing users from the Control Room.
Delete Users
Only those users that delete existing users from the Control Room.
Authorized users assign various combinations of these access permissions to different sets of users and roles
based on the business requirements.
Access is deny all and allow by exception based on roles, domains as defined in RBAC.
Users with access to roles and permissions management can create, edit, and delete roles in the system.
This permission is typically assigned to administrators and power users from across enterprises.
Access is deny all and allow by exception based on roles and domains as defined in RBAC.
Administrators assign various permutation and combinations of these accesses to different sets of users and
roles based on the business requirements.
Access to license management is deny all and allow by exception based on roles and domains as defined in
RBAC.
Only those users with access to license management permission are able to update the license from the
Control Room. A common license exists for all the users across Automation 360 for a specific Control
Room. The updated license is effective for all the Bot Creators and Bot Runners registered with the
corresponding Control Room.
The Control Room issues new client access tokens or identifiers through hashing, signed by the Control
Room and sent to Bot Creators and Bot Runners over HTTPS. Every subsequent communication between
Control Room and Bot Creator or Bot Runner is serviced by the Control Room after validation of the
signature of the latest access token sent by the Bot Creator or Bot Runner. Each access token is unique to
every Bot Creator or Bot Runner. This ensures that even if an unauthorized user could bypass enterprise
security and access the system, the Control Room security restricts any damage.
Use the Credential Vault to store other information deemed confidential or sensitive. The credential store
implements NIST controls IA-2 to uniquely identify and authenticate organizational users (or processes
acting on behalf of organizational users).
Sensitive information does not have to be stored in bots or on Bot Runner systems, the Credential Vault
facilitates a logical separation of credentials from the bots.
Credential Vault variables (credentials) are created in the Control Room. They are available to the Bot
Creators and Bot Runners who are assigned roles that provide them access to the lockers that contain the
credentials.
The Credential Vault adds flexibility and dynamic character to bots because only the credential references
are present in the bots, and not the credentials. When bots are moved from one environment to another
environment, absolutely no change is required in the bots. Bots can seamlessly pick up the credentials values
applicable for the new environment from the Credential Vault of that environment. Additionally, the Control
Room automatically stores configuration-related sensitive data into the Credential Vault by default.
The Automation 360 platform offers the embedded Credential Vault and provides an extensive set of
safeguards to protect data at rest and in transit, but also while it is in use on individual systems.
During the Automation 360 installation process, the system generates an RSA 2048 bit public/private key pair
and an AES 256 bit key. The private key of the RSA 2048 pair is referred to as the Master Key, while the AES
256 key is referred to as the Data Key. The Master Key is presented to the installing administrator for
safekeeping in a physically secure location off system. The public key is used to encrypt the Data Key. Both
the public key and the encrypted Data Key are then stored in the database. When in use, all keys and
encrypted data are placed in encrypted secure memory using the Microsoft Data Protection API (DPAPI).
During Automation Anywhere Control Room startup or reboot, the administrator is prompted to supply the
Master Key. The encrypted Data Key is retrieved from the database and decrypted using the Master Key. The
Data Key is now ready for use. As the system stores and retrieves data from the Credential Vault, the Data
Key is used to encrypt and decrypt that data.
vault is used to store all system managed credentials and critical system configuration data. It can also be
used to store any other sensitive data used in an organization's automations. As a result, bot builders can
avoid the insecure practice of hard-coding credentials and other sensitive data/ arguments directly within
their automations.
Multi-layer authentication and fine-grained access control are essential for a tightly controlled environment.
So is end-to-end data protection, which is also necessary to maintain the confidentiality and integrity of
business-critical processes, sensitive data, and related credentials.
Master key
This RSA-2048 bit key is managed by an administrator outside of the system. This key unlocks the
Credential Vault. The administrator types the Master key each time the Control Room is started. When
the vault is open, the master key is immediately erased from memory and it is not stored anywhere in
the Automation Anywhere product.
Data encryption key
This AES-256 bit key is stored in the Control Room database and is used to encrypt and decrypt the
credentials at the time of storage or provisioning. This key is encrypted using the Master key. The Data
encryption key does not leave the Credential Vault at any time. Credential encryption and decryption
are done at the Credential Vault.
In addition to encrypting local credentials and selecting runtime data used by bots, the Credential Vault
provides secure storage for sensitive configuration parameters and details pertaining to the integral version
control and email services.
Credential storage
All sensitive data is stored in the Credential Vault using AES-256 encryption.
These credentials are encrypted by the Credential Vault service to conform to NIST SC-28 and to prevent
unauthorized access or disclosure of credentials. Only encrypted credentials travel from the Control Room
to the Database server and are stored in the database in an encrypted form. The data encryption key
encrypts all credentials using an AES 256-bit key generated by a FIPS 140-2 Level 1 validated module to meet
the NIST IA-7, SC-12, and 13 requirements for implementation of mechanisms for authentication to a
cryptographic module that meets the requirements of applicable federal laws.
The data for Active Directory user credentials for autologin to Bot Runners is also encrypted and securely
stored in the Credential Vault with the bot credentials.
Bot Runners or bots do not store credentials locally. Credentials are provisioned only during the execution of
the automation. When the credentials are requested by Bot Runners, encoded (64 bit) credentials travel from
the Control Room to Bot Runner over HTTPS protocol. When the bots finish execution, credentials are
erased from the memory.
Cryptographic providers
Control Room
Cryptographic
Supported Version
Provider
AES-256
RSA-2048
All Bouncy Castle FIPS versions mentioned in the Automation
HMAC-SHA256 Anywhere Open Source Software (OSS) Notice
PBKDF2-HMAC-
SHA512
Secure recording
You can enable or disable image captures of business applications by setting up secure recording in the
Control Room.
Overview
When secure recording is enabled, Bot Creators or Bot Runners cannot capture the application images,
values, or texts. As a result, no sensitive data is (intentionally or unintentionally) stored in the bots in the form
of images. The remaining automation data, for example, UI object details are captured, and they continue to
be captured so that the automation can work seamlessly.
As an administrator, you can apply this setting from the Control Room for all Bot Creators and Bot Runners
(for all users or for specific user roles).
5. In the Recorder preview image tab, select one of the following options:
• Enabled: A preview of the image is shown in the Bot editor when the object is captured but
discarded after you refresh the Bot editor. The image is stored in the Control Room and deleted
after 60 minutes.
• Disabled: Image is not captured and not stored in the Control Room.
Option Action
Select this option to enable secure recording for all users who have
All users
access to the product.
This extra layer of message level encryption provides protection against network stack issues (such as
Heartbleed where OpenSSL was leaking sensitive data from memory) and also adds protection to the last
hop of the connection when TLS is terminated at the load balancer. These credentials are decrypted by
Control Room and authenticated against the hashed (PBKDF2 and HMAC SHA512 algorithm) user passwords
or against Active Directory via Lightweight Directory Access Protocol (LDAP).
Easier adoption
Integrates with an existing authentication solution, compliant with the standards.
Maintenance
All passwords and password policies are centrally administered.
Better user experience
Fewer passwords to remember.
Local authentication manages user passwords through the Credential Vault. Passwords are hashed using the
HMACSHA512 algorithm, which is keyed by the output of the Password-Based Key Derivation Function
(PBKDF2). User passwords are encrypted in transit through TLS 1.2.
All authentication and session management is handled through the well-tested Spring Security framework.
Kerberos integration is provided through the well-tested Waffle framework. SAML integration is provided
through the well-tested OneLogin framework.
Automation Anywhere offers seamless integration with Microsoft Windows Active Directory for access to the
Control Room, Bot Creators, and Bot Runners. When Control Room is integrated with the Active Directory,
all the Active Directory users with basic details are directly available in the Control Room without any extra
configuration. For Active Directory integration, user passwords stay in only Active Directory and are not
saved in the platform.
In addition to Active Directory authentication, the Control Room has its own controls to prevent
unauthorized access to anDynamic access token authentication of Bot Runnersy automation data.
Bot Runner users can also configure their Active Directory credentials for Bot Runners machine autologin.
These credentials are saved in the centralized Credential Vault.
Automation Anywhere platform architecture supports multi-forest multi-domain Active Directory integration.
Multi-forest multi-domain integration requires trust relationships between the forests and the domains. Refer
to Configure Control Room for Active Directory: auto mode for details. Automation 360 On-Premises can be
configured with Active Directory global catalog server in a way that the Control Room, Bot Creators and Bot
Runners can all be in the same or different Active Directory forests and domains. This gives the added
flexibility and control for large-scale complex deployment where users are spread across geographies.
Multi-domain support is provided out of the box and no additional configuration is required. The Automation
360 On-Premises user provisioning from different Active Directory domains is also seamless. It enables the
Automation 360 On-Premises admin to centrally orchestrate the digital workforce running across the globe.
• Deployment of bots from the Control Room to remote Bot Runners is done over secure
communication.
• Upload and download of bots from the Bot Creator to the Control Room is done over HTTPS.
• Transfer of any information from the Control Room to the database and vice versa is done over secure
communication.
• Transfer of encoded credentials from the Control Room to Bot Runners is done over HTTPS.
• WebSocket communication with the real-time data service in the Control Room is done over HTTPS.
Bot deployment to remote bot runners, provisioning of credentials, automation scheduling, and event
capture are done exclusively through the Control Room. Use only HTTPS in the production environment.
• The REST APIs use Distributed Cache Service to get shared cached data required for specific
functionality.
• The Scheduler Service makes REST API calls to run a task on a specific client machine at a specific
time.
• Real-time Data Service makes REST API calls to authenticate incoming connection requests. It receives
task execution progress updates by Bot Runners and sends that information to all connected browser
clients using WebSocket Secure (WSS) protocol.
• The Control Room makes REST calls for user authentication and repository operations, for example,
upload a task, download a task, or compare two tasks.
• The Control Room makes REST calls to the validate user session at regular intervals. The Control Room
deploys and runs a task on a specific device using Bot Agent. It uses a TCP/IP channel.
• The Scheduler Service makes REST calls for autologin credentials. It also communicates to the Control
Room to get a license and user session-related information.
• The Control Room makes REST calls to get autologin credentials for a logged-in device. It also
communicates to the Control Room to get the license and user session-related information.
Change management
Access restrictions for configuration management.
Baseline inventory controls for Bot Creators, Bot Runners and bots
The Control Room provides a single-pane-of-glass on all automation operations and infrastructure, providing
a way to baseline the configuration of the environment. Inventory controls are maintained through the
application of RBAC and the use of the Bot Repository, Operations Room, and License Management to
establish a single point of control for Base Line Configurations (NIST CM 2) access restrictions for
configuration management (NI5T CM 5 and 6). Configure automated baseline reporting using the auditing
and reporting systems in the Control Room.
The Control Room RBAC provides a point of access control and management for all changes to the Control
Room, Credential Vault, Bot Creators, bots, and Bot Runners with an automated mechanism to prohibit
changes and report on any attempts to make unauthorized changes. The logging and auditing system on the
Control Room provides the reporting mechanism for change management to conform to best practices as
described in NIST CM-3 through 5.
The Control Room provides an automated mechanism for tracking and controlling the use of licensed
software across Bot Creators and Bot Runners, addressing NIST Change Management CM 10.
Separation of duties is implemented at multiple levels. Dual authorization is achieved through separation of
control planes for the Bot Creators and Bot Runners. Only bots created by an authorized Bot Creator can be
executed by a separately authorized Bot Runner and only by a user who has been given the privileges to do
so by an administrator.
After authentication is successful, the platform applies a second mandatory level of access control
enforcement in the form of fine-grained Role-Based Access Control (RBAC).
The Control Room has its own controls to prevent unauthorized access to any automation data.
• Password hashing
Password hashing does a one-way, permanent transformation of the passwords of the Control Room
users, inline with standard password management practices.
• Authentication failure messages
If an authentication attempt fails, the Automation 360 platform does not specifically state if the
username or password is incorrect. It only states that the supplied credentials are incorrect.
• Authentication for Bot Runners
Two layers of authentication are present for deploying the bots on remote Bot Runners.
• Dynamic access token authentication of Bot Runners
The Control Room implements and enforces a Trusted Path for registration and authentication of Bot
Creators and Bot Runners in accordance with NIST SC-11.
Password hashing
Password hashing does a one-way, permanent transformation of the passwords of the Control Room users,
inline with standard password management practices.
Control Room passwords are concatenated with a salt and then hashed using the PBKDF2WithHmacSHA512
algorithm before being stored in the database.
• The salt is 256 bits in size and is randomly generated by a cryptographically secure PRNG.
• The HMAC SHA512 algorithm is used for hashing and provides additional security over traditional
approaches.
• A keyed hash provides protection against hash length extension attacks.
• SHA 512 bit key is larger than the commonly used SHA 256 bit key.
• The key used for the HMAC is from the secure Password-Based Key Derivation Function (PBKDF2).
• Hashing is done for 100,000 rounds (based on NIST recommendations).
Every time a Bot Creator or Bot Runner authenticates against Control Room, its credentials are authenticated
against the hashed credentials.
If an authentication attempt fails, the Automation 360 platform does not specifically state if the username or
password is incorrect. It only states that the supplied credentials are incorrect.
This is one critical information security requirement for Automation Anywhere customers and defends the
system against a brute force attack.
All failed authentication attempts are logged. See Audit log. Audit Log access is provided as per RBAC and
audit logs are made available on a read-only basis for all users.
Two layers of authentication are present for deploying the bots on remote Bot Runners.
The Bot Runner is logged on/connected/unlocked using the configured credentials. These credentials are
fetched from the centralized Credential Vault over HTTPS. This first level of authentication is done against
the Active Directory domain automatically, on behalf of the user and is called Bot Runner autologin.
After being authenticated, Bot Runners can be authorized to execute bots independently and
asynchronously.
The following table shows what happens to the user session on the Bot Runner after bot deployment.
Session remains
Unlocked Deploy the bot
unlocked
The Control Room implements and enforces a Trusted Path for registration and authentication of Bot
Creators and Bot Runners in accordance with NIST SC-11.
The Automation 360 platform protects the automation data against any attempt to subvert the path. The
Control Room issues new client access tokens, or identifiers, after a predefined time period. These tokens
are protected to conform to NIST IA-5 by being signed by theControl Room and sent to Bot Creators and
Bot Runners over HTTPS. Every subsequent communication between the Control Room and Bot Creator/
Bot Runner is serviced by the Control Room only after validation of the signature of the latest access token
sent by the Bot Creator/Runner.
The access token is unique to every Bot Creator/Bot Runner. This protects the system from an unauthorized
attempt to bypass security and execute an unauthorized bot, and is consistent with the best practices to
conform to NIST IA-9 Service Identification and Authorization. These controls implement IA-3 for
cryptographically based bidirectional authentication and attestation of Bot Runners and Bot Creators before
establishing connections. This also addresses requirements around unique, automated, identifier
management IA-4 for multiple forms of authorization and identification. Identifiers are dynamically managed
for audit and control purposes. Identifiers are used as authenticators and managed for verification on initial
deployment, revoke, and prevent reuse. There are no static, unencrypted, identifiers in use by Bot Creators
or Bot Runners and cached tokens are cleared periodically.
The list below contains several examples of these attacks and the security controls in place to prevent them.
SQL injection is a high-risk vulnerability that can seriously impact the confidentiality, integrity, and availability
of a database. It enables an attacker to execute any SQL of his or her choosing inside the DB, thus allowing
them to read sensitive data, modify/insert data, and execute various operations.
The Control Room prevents SQL injection using query provided by the Hibernate framework.
Cross-site scripting is a high-risk vulnerability that can seriously impact the confidentiality, integrity, and
availability of any user web session. It enables an attacker to execute any JavaScript inside the victim's
browser, allowing them to spy on the user's input/output or take unauthorized actions on behalf of the user.
They could also redirect the user offsite to a malicious malware download or a credential phishing page.
The Control Room prevents cross-site scripting using automatic output encoding provided by the ReactJS
framework.
OWASP Top 10
Automation Anywhere provides the following controls to protect against the OWASP Top 10:
Risk Control
A2: Broken authentication and session See the identification and authentication
management section.
A4: Insecure direct object references Centralized authorization via Spring Security.
Automation Anywhere has implemented a development security plan and protocol that defines a specific
depth of testing and evaluation to be done by the Engineering team on each release, conforming with best
practices as defined by NIST SA-11 Developer Security Testing and Evaluation and NIST SA-15, Development
Process, Standards, and Tools. This plan has been documented and shared with the Automation Anywhere
Engineering teams.
In each weekly build, during the development process and before every release, all Automation Anywhere
software is scanned for flaws using the Veracode tool. Automation Anywhere Enterprise meets the
requirements for the strictest security policy available in the tool, Veracode Level 5, which is defined as no
Very High, High, or Medium severity vulnerabilities. Analysis reports are available with each release.
Dependency analysis
In each weekly build, during the development process and before every release, all of the third-party libraries
and dependencies in Automation Anywhere software are scanned for known vulnerabilities using the Black
Duck tool. Automation Anywhere upgrades vulnerable libraries when new versions become available.
Analysis reports are available with each release.
All Critical/High vulnerabilities are fixed for each release. Medium vulnerabilities will be considered for fixes in
future releases depending on the scope of the Automation Anywhere releases. The list of OSS used by the
application is published for each release.
Penetration testing
Automation Anywhere does a penetration test through a third-party vendor before each major release.
Additionally, Automation Anywhere incorporates the feedback from penetration tests conducted by
customers, which includes some of the largest financial institutions in the world. Analysis reports are
available with each release.
All the database level transactions are done with a nonsystem administrator account. The Control Room
installer passes the SQL Server 2012 certification test.
When Automation Anywhere bots are deployed from the Control Room to remote Bot Runners, they revert
the Bot Runner system to its original state. For example, if the Bot Runner machine was logged off and our
bot logged into the machine, it logs it off after the automation execution finishes. This ensures that system
level security is not compromised.
Automation Anywhere software does authentication and authorization level checks at the API level. API calls
are serviced only for those users who have permission on the automation data. Unauthorized users cannot
bypass system security through rogue API calls.
Clean uninstall
When Automation Anywhere Enterprise Client software is uninstalled, it leaves no trailing files or folders
behind. This clean uninstall of the Enterprise Client software complies with InfoSec policies.
Automation Anywhere software allows storing of automation data in the Program Data folder, for the files
which must be edited by end users. Permissions are also set on the directory during the installation so that
the user can edit the content of the folder. This complies with the InfoSec requirements of Automation
Anywhere customers.
Automation Anywhere Enterprise Client software uses MSVCxxx.dll files for automation purposes, but it does
not install these files by itself. Client software directly uses the DLL files installed by only the Microsoft
operating system. This ensures that client software does not overwrite the DLL files installed by Microsoft
and our customers do not have to worry about doing one more cycle of checking for any introduced
vulnerabilities.
Assembly manifest
All the executables (.exe file) of the Automation Anywhere Control Room and Enterprise Client software
contain the manifest files which describe assembly metadata, for example, filename, version number, and
culture. This makes our platform comply with organizational InfoSec policies.
Automation Anywhere supports configuration of reading and writing automation data to a location on a
network drive. This enables users to keep all automation data at one place.
When Automation Anywhere bots are deployed from the Control Room to remote Bot Runners, our
customers do not need to change security settings, for example, disable login page, disable legal disclaimer,
or disable screensaver. Automation deployment works seamlessly without disabling these settings.
The Automation Anywhere platform can securely automate even those difficult-to-automate business
applications which download the Java runtime environment (jre) during automation execution. Whenever
these applications are started, an Automation Anywhere agent gets associated with Java executable
noninvasive and automates the business application. After the automation finishes, the Automation
Anywhere agent is automatically terminated.
Users can securely use German, French, Italian, and Spanish language keyboard characters through the
embedded automation commands in Bot Creators. This enables users to write data into these languages.
Automation Anywhere customers do not need to depend on less secure third-party libraries for this
automation.
For the most current description of Automation Anywhere GDPR compliance statement, see Cloud
Automation Agreement and Privacy Policy for Automation Anywhere.
Centralized management is done through a web-based server, called the Control Room, to manage all
development and execution of the digital workforce. The Bot Agent executes automation and are run time
systems installed on the devices.
The following image shows the architecture and relation between Control Room and Bot Agent:
• *indicates that the Control Room creates a unique user name and device ID to persist in the public key
in the database.
• **indicates that device public key is validated by the Control Room and a new token is created.
The following table describes the flow and the actions that occur between the Control Room, Bot Agent and
the back end services (as numbered in the previous image):
Actions Description
1 The browser sends the device token to the Bot Agent for registration.
The Bot Agent then registers the device request to create a public key and a
2
token.
Actions Description
The back end services of the Control Room sends a response to the Bot Agent
3
that the device has been registered with a unique user name and device ID.
The Bot Agent sends a message to the browser that the device has been
4
registered successfully.
The Bot Agent sends a message to the back end services of the Control Room
5
to indicate that the JSON web token has been authenticated successfully.
The back end services of the Control Room then validates the device public key
6
and establishes a Web Socket connection with the new token.
The following table provides you the behavior and resiliency differences between Automation 360 and
Enterprise 11.
However, in Enterprise
11, the Control Room
reconnection does not
happen after a restart.
Priority of bots is
verified at
deployment.
When a low-priority
When bots are
bot is running and
queued for a Bot
a high-priority bot
Runner user,
is deployed, the Advantage in
higher-priority bots
system pauses the Automation 360 is that
are deployed
low-priority bot lower priority bots are
before lower-
Bot and runs the high- not paused and
priority bots.
deployment priority bot. complete their
deployment before the
However, if a
After the high- high-priority bots are
lower-priority bot is
priority bot is run, deployed.
already running,
the low-priority bot
higher-priority bots
resumes.
are deployed only
after the lower-
priority bot
completes running.
Error handler
Error Handling
package contains
command helps in
actions to easily
debugging when
Error Handling handle exceptions
the TaskBot and
a bot encounters
MetaBot Logic are
and transfers
run.
control to other
Bot Agent
continues to check
for connection
even if the Control
Room is down by
using the public
and private key.
Remote Desktop
Protocol is
supported on both
Remote Desktop single and multi-
Protocol is user devices.
supported only on
multi-user devices. In Enterprise 11,
Remote
Remote Desktop
connection
The Control Room Protocol
does not maintain connection is
the RDP. established from
the Control Room
and maintained by
the Control Room.
No standalone
Updates are configuration
Configuration
pushed through updates, but you
updates
Cloud can change it
manually.
Enhancements to
the configurations
are released as
patches.
Configure device
settings to
automatically set a
user's current
Global cache Not available
device as default
device after the
user logs in to the
Control Room.
Scheduling resiliency
Device pools provide built-in high availability (HA) for the Bot Runner devices if your unattended license is
free to use. You are not tied to a single Bot Runner device, so if your device is unavailable for any reason and
your unattended license is free for deployment, your automation is not affected. The scheduled automation
will automatically run on the next available Bot Runner device, thereby providing high availability.