Robotic Process Automation – Attended

Continuing with this series of articles, it’s time to look at the first OWASP LCNC risk (Account impersonation) with respect to Robotic Process Automation, and specifically when running Attended Automations. 

But prior to that I want to describe the two main ways RPA processes can be executed for those who may not be familiar.  Those are Attended and Unattended.  

With Attended, the RPA processes act as a digital assistant to an active user.   The user will choose to execute a RPA task based upon the work they are doing.   As such, they act as an extension of the current user.

Unattended RPA processes run without a user’s interaction.  Instead, they get triggered by one of a variety of events such as: a file appearing on a server, an email coming in, a specific time, or anther trigger. 

Both attended and unattended have very different ways of presenting Account Impersonation, so these need to be discussed separately.  In this part of the series, I will only be discussing Attended.   No surprise, the next article will be focused on Unattended.

Ok, enough background, let’s begin.

Account Impersonation within Attended RPA

As with all domains, account impersonation occurs when you do not know the user acting within your systems. 

With Attended automation, the account impersonation occurs when the automation does not accurately record the user who launched them as the ‘actor’ who performed the task.   Since Attended automations are always launched by a user, all actions by those bots should be recorded as if the user performed them themselves.   This usually occurs when the developer uses their own credentials, or some other admin credentials to record transactions.

Presentation scenario / Attack scenario

Before we discuss how to remediate account impersonation issues within attended RPA, let’s discuss why it matters. To do this, I will present a few scenarios that can occur with attended RPA.

First, a sales team has an Attended RPA process created to complete the sales process.  When a sale has completed, the salesperson runs the attended bot to record the sale details and terms across several systems.  At the end of the quarter the sales commission report is run and all sales are attributed to the developer.   Upon investigation, the developer used their credentials to record all transactions, inaccurately attributing all sales to themselves. 

Second, a user has decided they no longer want to work at their current job. Rather than quit, they decide to perform the minimum work possible until they are let go.  A key part of their job is reviewing documentation and then properly classifying that document.  Once the classification is determined, the user launches an attended RPA process to route the document to the correct department and performs additional administrative tasks

The employee decides to choose the first classification option in the list without even opening the document.  They are able to complete their assigned work within 30 minutes daily.  

 As with the prior scenario, the RPA process uses a generic ID to record its transactions, making it hard to break down what each user is doing.   This employee’s actions are only discovered following an investigation when the receiving department realized they were getting many misclassified documents.      

This second scenario may sound oddly specific, the reason is it’s based upon a real scenario I encountered.   To make it worse, the receiving department had a 4-5 month backlog, so this occurred for months before being discovered.   The last problem was that since these documents were not being attributed to that user, there was no easy way to determine which they worked upon and needed to be fixed.  All documents during that time period with that type needed to be reclassified. 

Wow what a headache!

There are many more, but I hope these two are enough to understand the importance of knowing who is acting within your systems.

Remediation

1. Policy: Attended RPA use launching users’ credentials

As always, let’s start with the basics.   If you don’t already have one, put a policy in place that all Attended RPA processes should use the current user’s credentials for all actions taken. 

Since attended RPA processes act on the user’s behalf, all attended RPA processes should record their actions as if they were the user launching the process.  

2. Reusable code for accurate account usage

Once the policy is in place, a great way to gain adoption is to create reusable code to standardize user credential handling.   This helps ensure that only the launching users’ credentials are used to record actions.  This can cover accessing the most common applications, database transactions, log entries and more.  

Reusable code is also a great way to help with other LCNC risks, such as LCNC Risk 10: Security logging, but we will discuss that more when we discuss that risk.  

3. Code Audit

With the policy and reusable code in place, a quick audit of any attended processes in production or going to production can be done.   Was the reusable code used?  If so, you may be 80% of the way there to ensure the correct user is being recorded.

A deeper review may be needed to make sure the developer didn’t add other login processes that may violate the policy. The frequency of these deeper reviews will be up to each company based upon their staffing and risk appetite.

This type of audit should become part of a periodic check.   If you have a Center of Excellence, this should be added to their responsibility, with clear expectations of frequency and reporting of results.

4. Monitoring

Your IT security team likely already has tools in place to check for various types of ‘suspicious’ activities, like concurrent logins or logins to the same account across multiple physical locations. Make sure the IT team knows about what processes are running (LCNC risk 9: Asset Management) and there is a process for these tools to include the monitoring of automations being executed.

5. Developer training

Lastly, all developers (pro-code and citizen developers) should be trained to understand this and all security risks, as well as methods to mitigate.   As always, the developers are the first line of defense.   To make good decisions, they need to be informed as to the risks and best practices.  

Wrap-up

In the start of this series, I pitched the idea that the next steps for the LCNC top 10 should be to further refine each risk by discussing it specific to each LCNC domain (BI/RPA/App dev/others), and then discuss specific remediation steps.   Although this only covers the first risk and two domains, already the ways this risk presents itself and is remediated are quite different.

As we look at other of the top 10 risks and other domains this will continue to be the case.   To better and more deeply understand this, I again ask for your help.   Are you using RPA?  Have you experienced other scenarios where Account Impersonation is an issue?   Do you have other tools/methods to identify and remediate Account Impersonation?

Please let us know so as we continue to build out the OWASP LCNC top 10, we can add more value to the LCNC and security community.