1. SAP user accounts

Create separate SAP user accounts for the bot operator and the bot identities. In this case you will have a clear insight when the bot has conducted operations versus when a human operator did. Only separation of these two accounts will make it possible to allocate actions, mistakes, attacks or fraudulent actions. Each RPA bot must be assigned to a unique SAP account (do note that this will impact your SAP license fees).

Implement system security and include password rotation for RPA bots. The passwords should never be stored in the scripts. The credentials must be secured, for example by storing the credentials in the encrypted RPA vault.

2. RPA and Segregation of Duties

The RPA accounts should be granted authorizations to be able to perform their tasks. The assignment of these authorizations should be done according to the least privilege. But remember, even the most careful implementation of RPA can lead to an increase in account privileges, increasing the risks of fraud. If the bot processes a number of steps in a process, there will most probably be a conflict in the duties. This can be solved by splitting the bot into multiple bots, but this will not solve the issue if both bots are operated by the same human being. Putting in place two human operators that oversee each other will solve this, but this takes away the advantage of automation.

And whether or not RPA is implemented, there is always the risks of fraud, even when no SoD conflicts exist. If a fake account is created (either by a human or a bot) and the process is handled (either by a different bot or human), the operation is conducted, and the fraud can go undetected.

To mitigate these risks and SoD conflicts, we recommend to:

• Segregate the duties of the developers of the RPA scripts and the human operators of these bots. So human bot supervisors should not be able to define and maintain RPA scripts and the script developers may not run the bots.
• Implement Privilege Access Management and include the RPA accounts. With a compliant PAM solution, usage of the privilege accounts will be monitored, alerts of dangerous or suspicious activity will be tracked and recorded and forensic investigations can be conducted (for more information, read our blog about Privilege Access Management.)
• Four eyes principle can be implemented using bots, for example one bot does the operation and a second bot verifies the correctness and approves.
• Reviewing the assigned authorizations and executed tasks using the transaction monitoring capabilities in CSI Authorization Auditor is also recommended.
• Restrict the authorizations that are assigned to the bots. Restrict each bot strictly confirm the assigned task(s). Never assign authorizations with write access to the database directly, this increases the risks of data tempering and data corruption.
   

3. Logging of RPA activity

The security team needs to review the log of all RPA activities. If there is no log available, it is not possible to investigate, which is a major security issue. If the RPA tool does not provide the log, Privilege Access Management (PAM), must be implemented. CSI Emergency Request can be used to support this.

The RPA logging needs to be in a separate system where the logs are stored securely, the logging will not be overwritten, and forensic investigation can take place. The logs that are being generated should be system generated, complete and immutable. Logging of the script changes and account changes must be included.
 

4. RPA lifecycle

RPA is based on executing automated scripts. Implement a lifecycle for continuous RPA support; Monitor the bots to detect usage, alert and act on incidents and audit.

Reviewing and testing the RPA scripts is an important step. The correct assignment of authorizations to the bots must also be part of the testing, so do not assign the SAP_ALL profile to the bot for testing purposes.

Changes in the scripts must be reviewed, tested and approved before scripts become operational.