What are some security implications to be aware of before adopting RPA? What measures should businesses put in place to mitigate these security risks?
Even top RPA tools that have been used by our members aren't without some challenge if not mindfully implemented. There are a lot of benefits of RPA for your business, especially the ROI for RPA. In addition to security, there are some other drawbacks to RPA, although many of our reviewers boast about the advantages. Take careful consideration when implementing to mitigate any of the risks.
RPA software bots require access to certain systems and tools to carry out their tasks. They may be logging in to ERP or CRM tools, for example, or be integrated into a process using RPA and AI. To gain access, the bot will be coded so it can carry out it's tasks. This aspect makes them susceptible to hackers looking to retrieve credentials or passwords. Also, data that bots collect can also be compromised during the transaction process or storage. Follow best practices and standards so you're not opening yourself up for unnecessary risk.
Our members have shared their best practices when implementing RPA, and we're summarizing as a form of RPA standards and an introduction to a RPA security framework.
RPA solution needs to undergo testing (including penetration testing) to ensure compliance. We need to treat our Bots similar like our employees if our vision is to scale it at an enterprise level. So similar like human resources, bots need to be made aware of current company security standards, trainings etc. From a CISO perspective, we need to
1. Ensure that the access of the bot is controlled through enterprise user auth system.
2. Ensure that bot has its own set of credentials especially when it is connecting with external systems for traceability.
3. Ensure that bot is designed with Rule Based Access Control in mind.
4. Ensure that bot "vault" is encrypted and all sensitive information is stored in its vault.
In addition, there has to be clear separation of duties and delineation to ensure that each bot is self contained in its own security bubble and doesn't trespass into each other.
From business perspective, its imperative to quickly determine the deployment unit of the bot.
1. If the bot is running in a users system, then it should take the image of the user and work according to user compliance [e.g. password change in 90 days etc].
2. If the bot is running on a server then business should ask IT to get the penetration testing done to ensure that the bot will be able to sustain itself and thwart any security attaks especially if there is a user interface involved.
Must be especially aware of access to applications - when implementing bots it is important to include access rules and monitoring to ensure complete understanding of access rules. It is especially important in these situations to focus on a role based security access strategy that allows users to be assigned a role and then access to apps can be controlled by role rather than individual users. Some legacy apps do not use role based access management this could cause issues when combining new apps together in a bot
In my experience, these are some security recommendations for RPA:
- Robot identification: do not use another user's login. The Robot must have an specific login to distinguish what was done by a human and what was done by a robot.
- Access profile: some teams give “super powers” to robot execute everything. In our experience this is not a good practice. The ideal is to evaluate carefully what the robot can do and what it cannot.
- Password Valt: do not leave passwords used by robots in the source code. Ideally, passwords should be stored in a safe that few people have access to.
- Transaction logs: every good tool has a Log to show what was done by an RPA tool. This Log is essential for an eventual audit.
The RPA solution does not offer any inherent security issues. Our development and testing is all done within the client environment and when the bot is complete – Our organization maintains zero access points to the client’s bot or environment.
Should support be required, our development team will request access through a secured interface owned and regulated by the client’s security protocols.
Bottom-Line: Our strict governance model is designed to be 100% transparent to access requirements during bot deployment and there is no risk of client data being leaked, as all development work is done within the client’s environment.
Hope this helps. If you need anything else let me know.
Three points:
- Firstly all the RPA bots should have proper SOD on Bot ID's.
- Ensure all the control checks are implemented to each of the RPA steps Identified.
- Finally how the business Data is handled during the course of automation.