BOT Security – Are Your BOTS Secured???

Understand key critical paths in the process to be automated and the need for secured access while automating them.

Example: Two Factor authentication, secured file access.

Risk management with respect to inputs for the process, application access controls and output is saved as compared to AS IS Process and Automated Process.

Example: Data generated via the DB as compared to data exported via GUI in the AS IS Process.

BOT Support and Monitoring Team should be trained to decipher the BOT Performance Dashboards for abnormal anomalies with a BOT Run

Tip: Compare a failure with the AUDIT LOGS generated via the Orchestrator or the Control Room. Train the team specifically to read EVENT VIEWER logs to be a step ahead in the identification of a failure

Access privileges of a super user while creating BOT are often exercised. No harm in doing so, if they are revoked on a production run with the required access levels. Enforce a 30-day access monitoring and control on BOT used credentials, build notification in the BOT code itself to notify on the change of login credentials on 28th or 27th day of the review period in a month.

Run through CISO review when the BOT codes are developed and run on production during the initial days. Vulnerability checks can be identified by the IT security team and can be fixed before an intrusion is already in the house avoiding impacts to the organization and existing processes.

COE teams should build a Robotic Framework which includes adhering of security requirements when the PDD and SDD are created. Build a security adherence checklist.

Example – Access credentials, Infra DB access, Storage of files, encryption of sensitive data, login credentials encrypted in a vault to ensure the BOT developers follow the same whilst deploying BOT in production.

Change management should include security compliance sign off from the process owner and the security team as part of the checklist to deploy the change in production.