It will have been hard to miss the rise in prominence of Robotic Process Automation (RPA) – the use of software ‘robots’ to automate business processes, reducing manual administration for repetitive, predictable tasks.

For example, RPA is used for website chatbots that answer visitors’ frequently asked questions without the default need for human interaction. The robot could then escalate the issue to its human worker counterpart if it cannot meet all of the visitor’s requirements, consolidating the visitor’s information to make the job simpler for the human support agent.

Note here the distinction between RPA and Artificial Intelligence (AI). RPA is deterministic logic, so the robot will do whatever the script dictates. In the above example, the same question will always produce the same answer from the robot. AI, on the other hand, is non-deterministic logic, and has the potential to evolve over time. So although the base training data might be the same for a number of instances of AI, the end systems will diverge over time and could produce different outputs for the same inputs.

While the time and cost saving benefits of RPA are clear, organisations that implement RPA must make sure to tightly control the identities and the access of these ‘digital workers’ to data and areas of their systems, in much the same way as their human counterparts. Inadequate identity and access management (IAM) of the software robots will put the security of these systems at risk.

 

Current operation – impersonation

Looking at IAM implementations for RPA solutions today and considering the principle of least privilege, we recognise that the robot should have no more access permissions than the user they are operating for (their human worker counterpart), and ideally less. And yet the majority of RPA implementations talk about impersonation of this user.

Impersonation provides a very simple solution to allow the robot to access any details that the user can, in order to execute the process in question, effectively impersonating the user that they are acting on behalf of.

It is possible to limit the access of the robot, but without specialised implementations it is difficult to technically reduce the rights of the robot to a subset of the user rights, whilst at the same time performing tasks on behalf of the user. Without this implementation, there is an increased risk of unauthorised access from hackers where the robot has access beyond what is necessary. Further, if there is a hacking incident then it will be impossible to tell whether the robot script or the human user credentials were compromised and therefore determine the cause of the breach.

 

The case for representation

Representation is fundamentally different to impersonation. With impersonation, identity B can pretend to be identity A and access A’s protected resources. With representation, identity A allows identity B to operate on their behalf, still identified as B, but (temporarily) holding (a subset of) rights to access A’s resources. When B accesses those resources, it is clear that it is B performing the access on behalf of A.

 

This diagram may help you visualise this:

Comparing 'impersonation' and 'representation'

 

And if you’re technically minded, this more detailed diagram may help:

Comparing 'impersonation' and 'representation' - detailed

By way of a brief explanation, C(B + lim(A)), P(B + lim(A)) is effectively saying: The context is that of B with a partial sub context for A; The privileges are that of B with a subset of privileges from A.

 

In the RPA scenario, representation would mean that the robot would always be executing with its assigned identity, but will receive delegated rights from a given user identity to access a limited set of information, enabling it to execute the appropriate process in the context of its identity.

This delegation creates a cleaner, clearer boundary between the robot process and the identity that is the subject of the process execution, and adheres to the principle of least privilege.

 

Increasing applicability

Delegating representation rather than impersonation also gives other advantages.

Firstly, the delegation can be multi-level. The RPA can be triggered by someone who is already operating on behalf of the primary user identity, assuming onward delegation rights have been granted.

Secondly, the techniques required for representation would allow the RPA to operate over differing identity classes (individuals, organisations and things), enabling automations to be more widely deployed for increased efficiency and cost savings.

To find out how Ubisecure’s IAM and representation governance solutions can help you secure RPA processes and more, get in touch.