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

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

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

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

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

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 emails 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, email addresses, and file interactions to ensure that all credentials, recipient groups, and paths are authorized and parameterized

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

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

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.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

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

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

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

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

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

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

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

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

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

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

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