Product Configuration

This section is added to highlight the product security configuration practices in context of EdgeVerve AI Next deployment.

Identity and Access 

  1. Provide role privileges and access to profiles for intended users only and make sure to revoke the access for a particular user when it is no longer needed.
    1. Digital Worker / Engage. Roles in Digital Worker will not give access to Other EdgeVerve AI Next platform.
    2. Profiles depicts a sub-Department, work area, or business function in an enterprise for which Automation Software is being implemented. Assigning a profile to a user authorizes the user to perform the tasks, as defined for  the assigned role, for the Sub-Department. 
    3. Additionally, set profile filtering to TRUE in Admin portal to prevent studio users to access automation process design from unassigned profiles.
  2. Encryption Key Management: By default, the encryption key is placed in database and a default value is shipped with the product. It is recommended to change encryption keys post deployment as per customer’s requirements. This can be achieved by using “key management” feature accessible to administrator users through the PolarisEdge Administration Console. If needed,  customers can also use extensibility provided in the product to enable users to store/fetch key & salt values from any external software/ media like Credential vaults, Web APIs exposed by Key Management tools, etc.
  3. Update encryption key at regular intervals based on customer policies.
  4. Don’t share user/system credentials with each other. Especially, sharing robot credentials and business critical application credentials with other users can lead to security breaches. 
  5. API keys related to Google, Microsoft or any other services are shared by the customer with Agents for invoking respective APIs. These keys are critical in nature with potential to get access to sensitive resources hence it is recommended to procedurally ensure that Keys are safely shared, audited, and their usage is monitored by the customer. Customers should note that:
    1. Key generation, sharing, auditing, and monitoring the usage is outside of product boundary, and it must be handled by customer.
    2. Product doesn’t control transfer of API key by Agent over mail or chat or any other communication mediums. It is out of product boundary.
    3. Product provides all required controls to safeguard the API key once entered by Agent in the Engage Sign In manager. Product doesn’t allow the key to be accessed by any other user in the system. Keys are encrypted and stored securely. 
    4. By default, product supports CyberArk and BeyondTrust vaults. It is good practice to store the sensitive keys in these vaults and used it for the automation.

Environment

  1. All machines where automation software is installed should be in Prod mode. Access to higher environment like UAT and production environments should be given to limited authorized users. If possible, access should be given for a specified duration only. Additionally, activities performed during that duration should be monitored.
  2. Product binaries undergo thorough security checks ranging from code review to pen testing. In case it is desired to extend product behavior (such as addition of a webpage, extension of functionalities, and so on), it is expected that the extended implementation undergoes thorough similar rigor. This ensures that the extended implementation doesn’t introduce new security threats.
  3. Ensure that all product patches are applied to the given environment before releasing them to Customer teams for validation purposes. Ensure that product communication on patch availability is reviewed on a regular frequency and all relevant patches are applied to a given installation.
  4. Don’t enable debug log mode in production. It can expose sensitive information to untrusted parties. If needed, debug mode should be enabled only for troubleshooting purposes and should be switched off immediately after issue assessment/resolution.
  5. Custom DLLs uploaded into Automation system must be thoroughly checked for security issues before being used in the Automation echo system. Security scan of Custom DLLs is out of scope of the product. If possible, sign custom implemented DLL before using it.
  6. It is assumed that adequate security measures are deployed for physical protection of the IT assets and product installation (binaries and configuration files). This ensures that security breaches such as DLL hijacking and so on do not lower the security posture of the automation product.
  7. It is recommended to adhere to the following best practices for setting up SAML and OIDC based authentication support in the Automation platform:
    1. Only duly authorized users should have access to setup or modify SAML and OIDC configurations on the product.
    2. IDP should enforce certificate-based signing of the assertions and SAML response and restrict access to certificate for authorized user only.
    3. Keep the clock in synch between SP and IDP and NotOnOrAfter (message expiry) value. In case of SAML, it should be set to min value of 1min.
    4. In the IDP OIDC config, it is recommended to perform regex validation of redirect URI for the customer URLs.
    5. It is assumed that appropriate IDP security controls would be implemented by IDP owner.