Robotic process automation involves the use of bots, machine learning and AI to interact with business processes, taking people (mostly) out of the equation. While RPA can automate many time-consuming manual processes and thereby optimize enterprise workflows, RPA-enabled organizations must now combat security concerns related to both traditional real-user issues — they will be the ones overseeing the software, after all — as well as issues specific to bots. Without effective RPA security controls, deployments can end up being more of a liability than an asset.
Users managing bots, bots acting as users
Though RPA replaces humans with bots, people still need to work with bots to schedule, run, view and edit their processes. To successfully and securely do this, security admins must to be able to specify who does what — access control for humans and bots alike is critical.
Not unlike other corporate systems, be concerned about who can do what — or in the case of RPA, what can do what — and also consider more granular concerns, such as what time of day or days of the week an individual or bot has access. Some vendors refer to this as role-based access control. No matter what it’s called, every RPA system needs to provide it in some form. Look for how granular permissions can be set — the more granular, the more control security will have over what a given user can do.
To applications, a bot is just another user that needs to authenticate — i.e., log in — to use most systems. Be sure to know where those credentials are stored when not in use by the bot and how they are protected — is the credential vault encrypted? Who holds the key? Similarly, when the bot is running, know where the credentials are stored. If, for example, credentials are being stored in the bot computer’s memory in clear text, they could be compromised by a third party.
The bot, which effectively is an application program itself, is part of a business process and, thus an intellectual property asset of the enterprise using it. It is important that the bot code be protected from unauthorized copying. Ask potential RPA vendors if they provide runtime code obfuscation for bots — this protects code from being captured from the memory of the system where it is running.
Because bots mimic users, they interact with apps using keyboard and mouse peripheral inputs. An unauthorized person having physical access to the computer running a bot might be able to change data or otherwise change the bot processing by intervening through the peripherals. Be sure to consider whether potential RPA vendors provide an option for disabling the physical keyboard and mouse from being used while a bot is running.
Some vendors go a step further, offering an RPA stealth mode. In this mode, the fact that a bot is running is hidden from anyone viewing the PC screen. While this is not a desired option when debugging a bot, it could serve as a good security measure for production bots.
Enterprise RPA security integration
Because bot security is part of the overall enterprise security structure, it’s important that RPA software provide data for and integration into enterprise security systems.
For starters, enterprises must make sure their chosen RPA systems provide detailed audit logs of all activity. Find out specifically what level of granularity and control can be obtained over what data is logged.
If organizations use single sign-on or SAML-based systems for credential and user management, make sure the RPA system can interface into said SSO or SAML system.
Finally, companies using a SIEM system will want to confirm RPA software provides an interface into that so security teams can have a complete picture of its enterprise environment.
There are many aspects to RPA security. Some may be more important to a given organization than others, but be sure to consider each area and make sure that potential RPA providers meet the requirements of your enterprise and its security team.