How Does Privileged Process Automation (PPA) Work?

A Peek Behind the Curtains of PPA

Getting started with PPA

If you haven’t already, I recommend you spend a bit of time taking a look at https://osirium.com/ppa. That tells the story of why secure automation, Privileged Process Automation (PPA), is a critical capability for service desks, IT operations teams, admins, DevOps and much more.

In this article, I’m going to focus on the concepts and technology behind PPA so you get a better idea of how it’s deployed, managed and integrates with your existing systems and processes. Along the way, we’ll see how to:

• Isolate users from Keys and credentials
• Isolate developers from Keys and Credentials
• Isolate developers from direct vault access
• Isolate users from environments and dependencies a process needs
• Abstracting input and output to a web interface
• Audit everything

This video sums it all up

Concepts and Terminology

To help us get started, here’s what we call the various elements of a privileged process:

• Command: An *action* that makes an individual change or call to a device, application or system. For example, “Get a list of free ports”
• Task: A *series of commands* that perform changes or updates on a single device, system or application. For example, “Find a free port, provision it to this VLAN”
• Process: A *series of tasks* that perform a *business function” across a number of devices, systems or applications. For example, “Add this new user into our infrastructure for this role”
• ‍

Three Modes of Operation

PPA processes can be started in three different modes:

1. Human-Guided: A user (who could be in IT or in a line-of-business team) that is presented with a list of processes that are entitled to use based on their role.
2. Via application: For example, integrated with another system such as ServiceNow
3. Scheduled: A process that needs to run on a regular schedule, for example checking on a server’s health.

All these modes are closely linked. If you wish, a single process could be written to be invoked in all three different modes. Equally, any task could switch during execution. For example, an automated process may be invoked from ServiceNow but, if necessary, it can switch to requiring human interaction to confirm/approve a choice or review results. (You can see this in action here)

PPA tasks are hosted within Docker Containers which we’ll get into later. These tasks can be written in different languages, for example, Active Directory tasks might be written in PowerShell while network switch operations are written in Python. You choose what works best for you depending on the system and your available skills. Importantly, these tasks never contain admin credentials or keys with isolation via a vault proxy.

Isolating Credentials with the Vault Proxy

PPA abstracts access to credentials via a proxy. That means the code never needs to know what vault it’s using, and the developer of the process never has access.

Besides the protection immediately gained, the proxy goes further and ensures that code can move from dev to test to production easily and securely with no risk that test credentials get into production or vice versa. The proxy also removes the need to worry about different vault providers. You may have multiple vaults in your business such as Osirium PAM or HashiCorp Vault but no code changes are needed to move between the providers.

Making Code Safe at Rest

So what does this isolation, or proxy, look like?

Clearly, embedded credentials in source code is an accident waiting to happen.

As an example, traditionally a script might have:

The PPA version is slightly longer but adds a huge amount of protection:

Note that the code is not vault-specific, so during development, a vault with test credentials can be used but when the code makes it to the production environment, a completely different vault will be used.

Also, this code can only be compiled and run within the PPA appliance which is also protected from unauthorised access.

Inside the Container

You can use any number of Docker base images, although we provide some neatly packaged pre-baked ones.

The base images will have the file systems, network, languages and library dependencies you need along with some PPA specifics:

• The Vault Proxy interface
• The UI abstraction interface for appropriate language
• An email API – which isolates the code/user/developer from the credentials/certificates/site-specifics of sending an email.
• A Syslog API – should you need specific syslog messages — PPA will create syslogs for process events automatically.

There are some optional libraries that can be included to simplify the development effort, by default, that includes libraries for Active Directory, InfoBlox, Cisco, ServiceNow, Checkpoint and others.

Abstracting the UI

This is an especially powerful capability of PPA. All input and output is handled via a web interface and provides a set of simple UI primitives that add very rich interaction options.

Take this example: In an existing script, you might have code such as this:

Which returns a very simple, but not very intuitive result to the console:

For a PPA version, this would be changed to:

The PPA version will give you a rich user experience.

You’ll even get rich functionality “for free” such as sorting results and even a CSV download option. It’s also ready for changes, as PPA adds more capability to the UI library, for example in the way the table is formatted, the process gets the benefit without any code changes.
What’s really cool here is that if the PPA team improve the way that they layout tables – then the process code does not change, a new version of the PPA appliance results in a new layout with no code changes.

If you’re interested, the UI documentation can be found here: PPA Documentation.

Human Interaction with PPA processes

There are three main “roles” for human interactions with processes:

• The Process Operator: They can start tasks from the automation gallery, make inputs and outputs, park and resume tasks etc. This could be an admin, a help desk agent, someone in a business function or even and external partner or – customer (an aspect that is great for Managed Service Providers)
• The Approvers: These people receive notifications from tasks, which may require choices, inputs and outputs. Typically the notifications contain webhooks which to a specific instance of a process. Approvers need to be authenticated to ensure the right person has provided the approval and the whole process has a full audit trail.
• The “Subjects”: These people are on the receiving end of changes made by PPA processes, for example, the member of staff that requested their password to be reset. Depending on how the process has been written, they’ll get a notification via email or even popular messaging platforms.

The Process Operator may also be an Approver for some processes. A simple example might be where ServiceNow has used business rules to initiate a PPA process. The Operator might be required to approve actions that the PPA Process will make, or perhaps to provide missing information so that a process can complete.

Deploying Processes from Dev to Production

As we’ve seen the process has been isolated from the admin credentials via the proxy vault and the UI is abstracted from the code. That prevents any accidental exposure of dev or test credentials to production systems or production credentials revealed to developers. Because PPA Processes are well contained and carry all their dependencies with them – they can move from UAT to Production without developer intervention. Now, this has to be a good thing!

Your existing DevOps pipeline can be used to deploy the PPA containers – and PPA can even help with that as you can see in this example using Ansible.

‍