To begin with, to clarify:

This article deals with how to de-clutter your security profile and win back more time for useful business work. We’re going to look at this as an iterative process or journey, where the gain of each stage builds benefits into the next steps.

The Privileged Access Management Steps

The first step of the journey is a PAM baseline. As soon as you have all your shared accounts under control, worries about uncontrolled access melt away. You’ll separate people from credentials, and it will therefore be clear who can have access, who uses access, and how you grant and revoke access.

Naturally your security will be better, and you’ll spend less time worrying about unauthorised access. Your staff will be spending zero effort on password refreshes, as the PAM platform addresses this automatically.

At the end of this step, your most useful credentials are safely held and refreshed in the PAM Platform vault.

Further PAM Steps

Here are some extra steps for a fuller PAM journey:

  • Add a Configuration Management Database (CMDB) integration such as ServiceNow. This adds an extra degree of audit, such as why someone worked on a system. It also adds security in that a valid ticket is needed.
  • Create profiles for third party access. There is no need to share credentials with third parties and this will reduce the worries about outsourcers outsourcing. See here for more about third party access.
  • Sort out your dual account model, either by using PAM to control access and passwords of Privileged Accounts or by moving to a role-account model. For further information, see here.
  • Set up Multifactor Authentication to enhance inbound security. Here’s more on Multifactor Authentication.
  • Use Time Windows to limit access to appropriate times.
  • Remember Service Accounts.

The Privileged Task Management Steps

To get to this step, you will already have used some PTM. Enterprise-Class Credential Lifecycle management uses tasks to check and refresh keys and credentials.

The step goal here is to “delegate the task, not the privilege”. This means people run tasks rather than having login sessions. It’s more secure, less prone to human error, and considerably faster. The more PTM you do, the more you can go back to the PAM stage and remove more people from the shared credentials list.

This step works because Osirium PAM has the correct credentials available to use on behalf of the user. Tasks are defined in the Template Library and can be delegated to users through profile membership.

Privileged Task Management is well-suited to operations that are directed to one system device or application type. For example, operations like stopping and starting services, checking hotfixes and network ARP flushes.

Tasks become shortcuts for SysAdmins and can be delegated to the Help Desk. Indeed, tasks are a major contributor in the fight to stop the Help Desk becoming over-privileged.

Robotic Task Automation

For Osirium, this is the logical evolution of Privileged Task Management. In Osirium Automation, we deliver process automation where tasks can be run over multiple devices, systems and applications, and tasks themselves can make decisions on where to go next.

A Process is a collection of tasks, and Processes deliver value when they encapsulate business logic. At Osirium we go one step further: we’ve built-in escalation and workflow functions so that robotic processes can ask human operators what to do.

In the real world, not all tasks and therefore not all processes will complete successfully. There are edge cases and exceptions, such resources not being available or not in the expected state. There are other occasions when human input is required, such as where there is a choice of multiple resources.

We’ve realised that credentials and keys in task code and scripts represent a significant risk. Furthermore, we know that a bad-acting programmer with keys to a vault could request any keys or credentials. For this reason, in Opus, we have a vault proxy scheme which limits requests to only the credentials needed for the specific task in the process.

The vault proxy has multiple integration layers. This means that it will interoperate with Osirium PAM and many other vaults including Hashicorp. The RPA step builds on the PAM step, and since tasks make up processes it builds on the PTM Step.

There are other innovations too. We allow for tasks that make up processes to be written in multiple programming languages. We use secure containers to wrap up dependencies. This means that once a task is written it always operates the same way, and the underlying dependencies cannot be changed or removed underneath it. This leads to reliability and process that run every time.

Opus has data abstraction which allows it to present a consistent user interface no matter what systems it is interacting with. This means that the users do not have or even need access to the specific system environments needed to run tasks within processes.

Privileged Robotic Process Automation offers further advantages. The processes can execute privileged operations as part of business logic. If PTM could delegate to the Help Desk then RPA can delegate almost anywhere within the organisation.

Summing Up

At each stage in the journey, you can see that security has been a cornerstone delivery. At each stage, your cybersecurity profile has been de-cluttered because access to systems has been reduced, quantified and controlled. As we’ve taken more steps in the journey the focus has moved to ‘what do we need to do’ because we have the luxury of knowing that it is secure.

In the later steps, business efficiency has ramped up, and we’ve remembered that robots need people to deal with the exceptions and edge cases. At the same time, people are also beneficiaries, as they now have more uncluttered time to think more about what really matters to the business.

Related Topics