Privileged Process Automation Needs Privileged Access Management

In this post, we're going to look at some aspects of automating a privileged process. By "Privileged Process," I mean a series of operations that need to be executed to complete a given piece of work where each step needs access to some privileged (i.e. administrative) account to an IT system.  These operations start with pain + complexity + repetition, which drives the need for automation. We know that human error is also a key reason for automation, whether it is as simple as data entry issues or the thorny issue of giving people too much access to systems and they wander off the required path.

In summary, we are going to see that PAM is a much richer foundation for automation than simple password vaults because it provides verified information about the device and user.

This information can drive the process. A vault could give some device information as well as credentials, but this will not be maintained unless there is an external infrastructure to deliver it. A vault doesn't know about the permissions and policy that should be applied to the user. You could stop reading here, or continue to understand how PAM and PPA (the Osirium solution for privileged process automation) fit together.

Security in automation falls into two main areas: Who can access the automated tasks, and who are the internal or external attackers seeking to reveal the credentials and keys used by these tasks?

Who has access to privileged processes?

In our security community, it's clear that hard-coded credentials are breaches waiting to happen - especially if the code gets committed to GitHub and the like. The wider world of IT has many domain specialists, people who know about their environment, get valuable work done, but who do not have security as their first priority. For these people, using a vault might seem like the easiest way to separate credentials from code.

Here we'll show the benefits of taking a PAM approach rather than a Vault approach. And, specifically, we'll relate this back to the drivers of automation and how we can neatly abstract the security issues away for our domain specialists. We will also go over delegating those processes to achieve "shift-left" in a way that keeps everyone happy.

There are three main aspects to the security side of automation:

• Credentials and Secrets
• Assets and Inventory
• Permissions and Workflow

The first is obvious. Assets and Inventory are really important. We've all heard those stories where someone thought they were working on a test system when in fact they were working on the production version. As your domain specialists build their tasks, they'll be using test systems either hardcoded or parameterised. Once in production, hardcoded references are fragile to change, and parameters can be subject to accidents or abuse. Permissions and Workflow are key in operations.

But our domain specialists are unlikely to understand the nuances or even want to be burdened down by this in their code. Let's start with the useful aspects of vaults. You can use these as a simple Key-Value store, and therefore your program can have a simple read_secrets()call - but remember the code needs to authenticate with the vault, so it may be an issue of moving your security problems from one place to another - and making them worse as you go. It's the classic where do you store the key to the keys problem.

A program with keys to the vault is worse than one with a single set of credentials. It's possible to store more than just secrets in a vault. For example, for k,v in read_secrets('device_name') Where k could be IP address, port etc. This device-centric approach is useful. However, it relies on the stored data being correct.

The PAM approach is very similar in code but has the real benefit in that the connection details to the device have been verified as part of the provisioning process.

this_device = pam_read_device('device_id)
port = this_device.port
port = this_device['port']  # alternative version

The provisioning process also determines the device type and what authentication services it uses. In Automation, it is very helpful if the authentication service of the device and the user initiating the process are different (or in different operating realms). Otherwise, you've just granted access and privileges to a user that you wanted to keep away from the device in the first place.

With Opus, the task code never has the keys to the vault. These keys are held with the Opus environment that then provides a proxy instance of the vault. Providing the program behaves well, it can request the keys, secrets and credentials to the devices it needs.

Solving the Key to the Keys problem

The provisioned device is now an asset in an inventory. It can be searched for, and it can provide attributes and context. A PAM solution has policies; in our case, Osirium PAM uses 'Profile Membership' With PAM, an automated task can query for both the device and the user. Now we can provide a list of devices that are appropriate for "testers in UAT" or "Senior Help Desk operators in production". So this will reduce the chance of the wrong process on the wrong system. PAM helps with workflow as well, there are many useful examples here, but let's consider a task within a process.

Let's say that the task retrieves customer orders and displays them to the operator. A help desk operator can help customers with what they have ordered and what the deliveries will be. However, what if the customer needs a change or a more expensive alternative is available within and decent delivery time? We might want this task to raise a ticket or be passed to a more senior operator. So the same task can do different things based on the permissions of the user and where we are in the workflow.

Using a vault could be useful at the development phase; it will produce a task that is fit for function, but not a process that is fit for purpose. Using our PPA product will allow your domain specialists to do what they do best. But the outcome will be much better Processes that avoid unnecessary data entry and the classic human error of choosing the wrong system. The tasks and processes can be delegated to the right part of the business, and most usefully managed by the business. Workflow speeds everything up.

PPA can be used with a range of vaults and PAM systems; it's naturally at its best when used with Osirium PAM - if you'd like to know more - please get in touch.

‍