1. Fast-Track UiPath Developer Module 10: Sensitive Data Handling
Machina Automation
Fast-Track UiPath Developer
Module 10: Sensitive Data Handling

2. 10 – Sensitive Data Handling
Overview: This module covers the risks associated with building and deploying automated workflows in UiPath, and how they are mitigated through proper handling of sensitive data and through features built into the UiPath architecture.
Organization: This module is organized into the following sections:
10.1: Potential Risks
10.2: Managing Credentials
10.3: Studio Security
10.4: Robot Security
10.5: Orchestrator Security

3. 10.1 – Potential Risks
Robots having access to credentials and systems normally used by human workers
Unauthorized modifications of automation workflows in the development or testing phases
Robots having access to privileged information such as personal data of employees, financial data, etc.
Unauthorized modifications of automation workflows or runtime parameters in the production environment

4. 10.2 – Managing Credentials
UiPath Studio has Packages that support credential management in Orchestrator or in Windows Credential Manager:
Orchestrator Activities Package – UiPath.Core.Activities:
Get Credential: get a credential from Orchestrator
Returns Username as String
Returns Password as SecureString
Set Credential: set a credential in Orchestrator (the Credential Asset must exist)
Windows Credential Manager Activities Package – UiPath.Credentials.Activities:
Add Credential: add a new credential to Windows Credential Manager
Delete Credential: remove a credential from Windows Credential Manager
Get Secure Credential: get a credential from Windows Credential Manager
Request Credential: prompt the user to enter credentials

5. 10.2 – Managing Credentials
If credentials are managed in Windows Credential Manager, then the credentials need to be added to each UiRobot machine that the automated process runs on (distributed control).
If credentials are managed in Orchestrator, then the credentials are available to each UiRobot that runs the automated process (centralized control)
Use the Type Secure Text activity to write SecureString passwords into password fields in the UI

6. 10.3 – Studio Security Code Reviews
Ensure that the process that will run on live production data is safe with no possibility of security breaches
Standards of review must be established, reviewed, and enforced
Some areas of particular concern include:
Handling of credentials
Data sharing: Focused on prevention of making data accessible outside of the trusted scope
Saving files
Sending s
Interactions with other systems and data sources
Hard-coded values: Malicious developers could hard-code certain details that could lead to fraudulent or subversive activities
Enforce the use of external configurable settings
Verify all account interaction, addresses, and file interactions to ensure that all credentials, recipient groups, and paths are authorized and parameterized

7. 10.3 – Studio Security Securing Automation Packages
Studio Direct Connection to Orchestrator:
Publish project from within Studio
NuGet package is created
NuGet package is sent directly to Orchestrator
Protect access to Packages in Orchestrator by permission (User Roles)
Studio Indirect Publishing (not connected directly to Orchestrator):
NuGet package is saved to a local folder
Access privileges to folder are required
Manually upload to Orchestrator

8. 10.3 – Studio Security Isolate Environments: Version Control:
Ensure that RPA Developers cannot adjust UiRobot settings
Ensure that development Studio is not connected to production Orchestrator
Ensure that RPA Developers cannot upload or publish packages to production Orchestrator
Ensure that RPA Developers do not have the rights to access production Orchestrator
Version Control:
It is common practice to keep source XAML files in a source control system, especially when multiple developers are working on the same project
Orchestrator versions NuGet packages but not XAML files
Useful when implementing changes and bug fixes
Useful in verifying that correct versions are implemented in production
The published package version from Orchestrator should be referenced in check-in notes when the corresponding XAML is checked into source control

9. 10.4 – Robot Security Provisioning Robots: Authentication:
A Robot must be provisioned in Orchestrator before it can connect
Orchestrator generates a unique key for each provisioned robot
Authentication:
Robots use the machine name and Robot Key provided by Orchestrator to authenticate in the first phase
Access to Settings:
Access to the Settings page on the Robot machine, where the Robot Key and the Orchestrator URL can be edited, requires elevated rights
User needs elevated rights to disconnect a Robot from Orchestrator

10. 10.4 – Robot Security Storing Credentials:
Orchestrator Credential Assets:
Centralized database
Credentials are encrypted using AES 256-bit and stored on the SQL Server database
Can be accessed by all connected robots
Should be configured with “value per robot” to prevent unauthorized access
Windows Credential Manager:
Works as a local machine storage
Should be used when Orchestrator is not available
Can be used as a fall-back if Orchestrator is unavailable and the robot only requires credentials from Orchestrator

11. 10.4 – Robot Security Manipulating Sensitive Data:
Robot + Machine = Trusted Environment
Sensitive data can be protected by:
Configuring a trusted channel:
VPN connections
Secure FTP (SFTP) sessions
HTTPS web sites
Encrypting data when using untrusted channels
Use limited access environments:
Restricted shared folders
Restricted SharePoint domains

12. 10.4 – Robot Security Isolating Environments: Securing Packages:
Development Environment
RPA Developers and their Robots only interact with systems in a “sandbox” environment
Development Robots should not be able to connect to the UAT and Production Orchestrators
Securing Packages:
NuGet package is published to Orchestrator
NuGet package is ready to be downloaded by Robot when needed
NuGet package is stored on Robot in a folder with restricted access
The package is verified for any tampering before execution

13. 10.5 – Orchestrator Security
Orchestrator is built on three layers:
Presentation Layer:
Accessed via browser
Communication between clients (browser, robot) and Orchestrator is encrypted using the secure HTTPS channel
User session is saved in a session cookie (with configurable expiration time)
Password complexity is configurable
Account automatic locking after a configurable number of failed attempts
Protection against XSRF/CSRF (Cross-site Request Forgery or One-click Attack) and clickjacking (malicious links hidden beneath legitimate clickable content) implemented in the code

14. 10.5 – Orchestrator Security
Service Layer:
Contains the business logic
Installation of Orchestrator website only with SSL certificate
Role-based access control
No data sent outside organization’s network
Logging – default events and user actions are logged for auditing
Encryption key in the configuration file can itself be encrypted
Persistence Layer:
Contains the database
Orchestrator supports encrypted communication with SQL Server
Each password is encrypted with a different encryption key
Login attempts are logged: result, IP address, timestamp, browser information
Permissions to data stored in SQL Server can be granted to user roles in order to prevent unauthorized use

15. 10.5 – Orchestrator Security
Retrieving Credentials:
Robot received the instruction from Orchestrator to start a process
Robot requests credentials required to create an interactive Windows session from Orchestrator
Orchestrator verifies that the credentials requested are available on the SQL Server Database or CyberArk
Orchestrator decrypts and sends the username as plain text and the password as SecureString

16. 10.5 – Orchestrator Security
User Roles:
There are two pre-defined roles in Orchestrator:
Administrator
Robot
Other roles, such as Developer, Support, and Business can be created by administrators
Developer User Role:
Default role for developers when logging on Orchestrator
Rights can vary from one environment to another:
almost full access on the development environment
view-only on the test environment – allow enough privileges so that monitoring and bug-fixing is efficient
limited or non-existent on the production environment

17. 10.5 – Orchestrator Security
User Roles:
Support User Role:
Production-only role given to the support team that will have to monitor the processes running on the production environment
should not allow package uploading or robot editing
should allow starting and stopping jobs, viewing robots, viewing schedules, and viewing logs
Business Role:
Limited view rights in production (for training purposes)
Target audience:
Business department
May be triggering jobs and reviewing queue items that were processed

18. 10.5 – Orchestrator Security
Multitenancy:
One Orchestrator can contain multiple Tenants
Separate Elements:
Robots
Processes
Assets
Queues
Data
Configuration
Users
Roles
Audit Trail:
Tracks actions performed by all users in Orchestrator
Allows filtering by components and actions

19. 10.5 – Orchestrator Security
Robot Logging:
Developers add Log Message activities to their workflows
Messages are generated when the process runs
Logged messages are stored in SQL Server or Elasticsearch (or other platform)
Authentication Security:
Options:
Local username and password
Active Directory usernames using Windows Authentication
Google Accounts open with OpenAuthentication 2.0
Azure Active Directory authentication
Pre-requisites:
HTTPS configured at IIS level
SSL certificate from a trusted provider
HTTP binding should be set to redirect to HTTPS

20. 10.5 – Orchestrator Security
Account Security:
Account Lockout:
Helps to protect users from Brute Force attacks
Additional login attempts can be prevented for a period of time after a number of failed attempts
Settings are configurable per Tenant
Expiring Passwords:
Passwords can be set to expire after a number of days
User must change password on first login
Password History:
Allows administrators to prevent the users from reusing old passwords, unless it is beyond the password history length
Multiple Login Control:
Multiple logins with the same user are disabled
When an additional attempt to login in is made on a new machine, the existing connection is closed on the previous machine

21. 10.5 – Orchestrator Security
Encryption:
Transport Level Security 1.2 Protocol
Advanced Encryption Standard on 256-bit cipher
Secure Hash Algorithm 2