Although Robotics Process Automation(RPA) brings efficiency and productivity in business processes but it is also escorted by risks inherent to RPA and to business environment it automates. I’m personally leveraging and developing RPA use cases to automate multiple SAP access management and internal control requirements but placing effective controls against the RPA risks and ensuring continuous compliance is also the need of the hour.
Before I give my 2 cents for RPA related risks and respective controls, I would like to clarify that this is solely my personal opinion and do not necessarily express the view or opinion of my employer.
1. Increased Cyber Attack Surface
Risk: RPA offers broader spectrum of internal and external application integration, and may lead to enhanced cyber attack surface. For example, Apart from RPA infrastructure, RPA also requires GUI scripting to be enabled in SAP environment which is an easy threat vector for denial of service attack.
Control: RPA and SAP integration needs to be secured in order to make sure that environment is free from interference or tampering. Penetration testing can be performed to assess the vulnerability of RPA and SAP infrastructure. For securing GUI scripting access, limit it to bot users by leveraging system parameters like sapgui/user_scripting_per_user. Paramters like sapgui/user_scripting_set_readonly and sapgui/ user_scripting_disable_recording may also be leveraged for further hardening.
2. Critical Access, Segregation of Duties Conflicts(SoD) and Privacy Risks w.r.t bot user in SAP environment
Risk: As bot users/digital workers will act on behalf of human user in the system where bot user will perform the activities based on the information/data feeded by human user therefore access risks of bot users (Critical action, privacy and SoDs) need to be taken care similar to human users within SAP environment.
Control: Risks arising from access risks with bot user ID will need to be controlled, remediated, transferred or accepted in a similar way as for human users. Also, new access risk rules need to be created and monitored within GRC for the access which can be considered sensitive with digital workers due to scale of disruption it can cause.
3. SoD conflict between “human user feeding the data to the bot users” and “bot users”
Risk: Humans will eventually be responsible to feed the data to bot(via email, excel, word…..). Let’s call them “bot data feeder“. SoD conflict within the bot user can still be managed in a same way as managed for human users but it becomes more cumbersome to monitor and manage SoD risk if one part of the process is performed by bot data feeder and other part by bot user. A more complex case could be human bot data feeder performing one activity by one bot user and another conflicting activity by another bot user. For example, adversary opens closed period by leveraging bot user 1 and then performs fraudulent posting in the closed period by leveraging bot user 2 or his own user.
Control: Risks arising from access combination of bot data feeder access (human user access) and bot user access needs to be monitored. This is possible by leveraging standard access risk analysis tools. Solution is complex but easily achievable by zero custom development effort.
4. Unauthorized manipulation of scripts and deficient change management process in RPA tool
Risk: Broad access in RPA tool and lack of change management controls may also lead to unauthorized manipulation and deployment of scripts.
Control: SoD rules should be defined for RPA environment and controlled change management process need to be followed for developing the RPA algorithm so that person developing the script must not be able to deploy the changes to production or manipulate the script directly in productive environment. For production deployment, similar change control and validation process can be applied to RPA environment as that of business application.
5. Unauthorized access to bot credentials for VM/desktop and bot user credentials for business application
Risk: Unauthorized access and use of bot credentials may lead to data privacy breach and/or fraud.
Control: Credentials of bot VM/desktop account can be stored in encrypted vault and should follow the corporate password policy as for human users. For application login by bot users, single-sign on should be enforced if feasible. If single sign-on is not possible then, business application administrator should punch in the initial password in RPA tool preferably via screen sharing session with RPA administrator. RPA applications usually store password of business application bot user in encrypted form.
6. Processing of bigger volume of inappropriate data if RPA is breached or incorrect data is feeded by mistake/intentionally by bot data feeder
Risk: The impact of something going wrong with bot is much bigger than with a human user especially for un-intentional incorrect data feed.
Control: There is a need to put efficient and automated detective controls to monitor the activities performed by bot users.
I would like to emphasize that above list of risks and controls may not be exhaustive and it would be nice if you can share your thoughts around this topic.
