What is Privileged Robotic Process Automation?

RPA (Robotic Process Automation) operates on user applications, whereas PRPA (Privileged Robotic Process Automation) or Privileged Process Automation (PPA) generally operates on administrative interfaces and secured data – it’s about delegating processes not privileges.

There is already an established market for RPA. Here, we are going to outline the differences between Robotic Process Automation (RPA) and the Privileged version (PRPA).

Privileged Accounts and API Key Security

An obvious difference is that PRPA will need keys and credentials to execute privileged operations. At Osirium, we believe that the code that makes up a process should be ‘inert at rest’. By this we mean that should an attacker obtain a copy of your process and its task code they will not be able to extract any API keys or credentials. We’ll go further, in that they shouldn’t be able to extract data such as addresses meta data either.

Furthermore, in PRPA or PPA, there is a need to protect task code from malicious insider modifications that seek to copy or use keys/credentials, or even send them to devices as part of a man in the middle (MITM) attack.

This means that a PPA platform must deliver keys and credentials to the process, only when it needs them and only if they are running in the correct context.

Within our PPA Opus (now known as PPA) product, we use a vault proxy system. Our PPA platform spins up a secure container for each process and provides it with a one-time key and suitable context meta-data. For example, the user identity, and devices involved. Code within the secure container can only ask for appropriate keys/credentials from the vault proxy.

Therefore the vault proxy can verify the one-time key and context meta-data before requesting the actual keys/credentials from the active vault.

Thus, the process code must be in the right container, with the right key and meta-data before it can get indirect access to keys/credentials.

Device, Application and System Interactions

APIs and command lines implement a fixed contract between caller and device. This is a more accurate and secure approach than OCR driven UI(User Interface). APIs are the correct approach for high-value mission critical operations.

Privileged Process Automation executes high-value processes, therefore accuracy and security is paramount. This means that PPA is more likely to use APIs and command lines than RPA, which is often executed by driving the UI (User Interface)

Automate the Expected, Interact with the Unexpected

Each individual part of a system is simple in isolation. However a chain of simple components quickly becomes complex – and then adding humans to the mix can make things chaotic.

Therefore, processes deal best with what they expect to happen. Expect also includes error handling on a task by task basis. Designing error handling for an entire process is near impossible and will make code bloated and hard to read.

This is where our intelligent, high value human operators come in. A human operator can be told that a process cannot continue because a part of a system has run out of resource. There could be many solutions to this problem, like say, deleting log files (and thus losing some audit trail). The human can make the value decision between canceling the process or freeing up the resources for it to continue.

Tasks in Flight

Opus from Osirium handles issues raised by tasks and processes ‘in-flight’. Its design means that it has a continuous open channel waiting for any type of output to be emitted. If the output is expected – it feeds into the next task in the process. But, if it is unexpected, or is raising a question, it gets directed to the human operator.

Would you like data with that?

Often, the desired outcome of a process is data, for example privileged operations across a range of systems to yield performance data. Our Opus product has layers of data abstraction. These take data in whatever format is emitted by the devices and organises this into useful, intelligent representations, either for human consumption via applications or for the next step in the process.

At any stage, multiple data formats are available – for example, a list of ports could be available as a table with check-boxes and a CSV file simultaneously. If the choice is obvious, the human operator can check the required ports. If the list needs further work, then it can be imported into a spreadsheet or emailed to another team member.

Workflow – if ‘X’ happens, it needs Escalation or Approval

Consider a database operation that unexpectedly runs out of disk space. This ‘in-flight’ issue may get raised to an operator who hasn’t got the authority to deal with the problem. This requires a work-flow for escalation. In this case, the task could be escalated to a senior team member, or a link to the task emailed to a manager.

The senior member could solve the resource issue and hand back the task to the original operator, or, the manager could issue an approval to a task/process that deals with the problem.

It is important that these escalations are tracked and audited. If issues happen enough times Opus provides good data to justify process or system improvements.

A Consistent Interface – all your Processes in one place

Privileged processes, by their nature, are executed on a wide range of devices, applications and systems. Furthermore, they will often need specific prerequisites to run. As infrastructure evolves, these become more complex with the need to accommodate legacy versions.

Opus provides Secure containers which, along with the abstraction layer, deliver an environment where all dependencies are safely isolated. The data flows in and out of the process, is abstracted into machine and human readable form, which then drives the operator dashboard.

The dashboard is the team’s view of their tasks. Tasks can be passed between operators and with workflow escalated to other teams and/or passed through for manager approval. The operator that starts the task may not be the one that sees it complete.

‍