Privileged access management - the network gatekeeper

Unfortunately, it’s not only external attackers that pose a risk to you and your network. According to research by The Ponemon Institute, so called “Insider Threat” incidents have risen by 44% in the last two years, with the estimated cost of credential theft rising from $2.79M in 2020, to $4.6M last year. The time to contain insider threats has also increased and unsurprisingly, the data shows that the longer it takes to neutralize a beach, the higher the cost to the business in terms of both cash, and reputation.

Of course, this is not a new problem. Administrators have been trying to secure their systems since the days of Teleprinters. Protocols such as TACACS and RADIUS have been around since the 1980s and 1990s, respectively; and they oversaw secure(ish) access to systems for decades. But they’re no longer sufficient to manage the bewildering array of platforms, devices and requirements that make up the modern “connect-all-the-things” world.

So, what’s the answer? Identity and Access Management (IAM or IdAM) is a fascinating (if you’re that way inclined) branch of the IT Security discipline. It seeks to define exactly what is meant by the term “identity”, and there’s a lot more to it than just a username and password! It’s too complex to describe in detail here, but this article gives a good overview.

As with any complex system, the correct set of tools go a long way to making the topic understandable and controllable. IAM has the limitation of only proving the identity of a person trying to connect to a device or system. To control what level of access they need, and to monitor what they are doing with that access, needs more than IAM can provide.

Privileged Access Management with Osirium

PAM from Osirium is a Privileged Access Management platform that makes it easy for organizations to administer, control and audit who is accessing which assets, and what they’re doing while connected.

The key concept behind PAM is the assumption that endpoints ARE already compromised and that users ARE phishable. To mitigate this, the system ensures that credentials never pass-through endpoints and are never revealed to users (except under carefully defined emergency conditions). This separation of people and passwords guarantees users can never copy their passwords to their clipboards, nor can traffic passing between their workstation and the target be intercepted. Think of the PAM server almost like a “credential-injecting proxy”.

There are other methods of handling secure access to systems, such as Identity & Access Management (IAM) tools, but these simply rely on the ability of a user to prove who they say they are. In contrast, Privileged Access Management systems control user access and permissions by assigning accounts “roles”. Osirium PAM implements privileged account management policies through “Profiles”, which map identities to roles on target systems. A user connecting to an endpoint only gets the access level defined by their Profile.

Osirium PAM includes over 200 predefined device “templates” that allow admins to quickly define the systems in use in their environment. This includes on-prem hardware and software endpoints, as well as cloud infrastructure. Additional custom templates can also be easily defined.

Once accounts, devices and roles are defined, users can connect to the systems they have been granted access to by logging into the Osirium web interface, where they are presented with a list of systems they can work with.

Selecting one of the defined access methods will launch it in the user’s browser and credentials are injected without ever being revealed. Additional authentication steps can be implemented, such as requiring the user to create a “Change Ticket” and specify the reason for the connection. These can also be configured so that a supervisor must authorize the connection before it is granted.

Some systems might require special tools or management utilities, for example SQL Management Studio. These can be installed on a system that is then defined as a Management Application Proxy (MAP) server. Selecting these from the Access List opens an RDP session to the MAP server and runs the defined tool.

As you would expect from a tool for controlling system access, Osirium PAM includes many audit and validation features. This includes automatically recording video screen captures or screenshots of active sessions, as well as comprehensive logging facilities, making this an ideal tool for monitoring regulatory compliance.

As mentioned in the introduction, not all attacks originate from outside the network and sysadmin and security teams also need to watch for insider threats. Osirium PAM’s Behavior Analytics module tracks all access activity across the monitored network and can recognize suspicious user activity, unauthorized use of credentials as well as “privilege creep”. All users are assigned risk scores based on their activity patterns, allowing the system to easily identify and alert on anomalous or suspicious behavior.

The system also includes a management dashboard that gives an overview of devices, users, and other summary information:

PRTG watches the watcher

The Osirium PAM server also features a REST API, which, of course, means we can access this management information through Paessler PRTG monitoring software.

The Osirium API’s primary purpose is to produce reports about system activity, so it responds to most API queries with an array of JSON objects. PRTG’s native REST sensors can’t parse these objects directly, so we’ll need to use the EXE / Script Advanced Sensor to process the API returns. This simple PowerShell script will count the JSON objects returned by the API and populate a sensor channel with the value returned. Just copy the script to the Custom Sensor folder (default - C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML). Here's the Gitlab link: https://gitlab.com/PRTG/Sensor-Scripts/Osirium-PAM

Next, we need to create a set of API credentials from the Osirium web console. These consist of a “Client ID” and a “Token”. Details of how to generate them can be found in the Osirium documentation. To avoid having to setup the API credentials multiple times, for each sensor we want to create, we can make use of PRTG’s inheritance feature.

Add your Osirium server into PRTG, in the usual way. Then scroll down the new device’s properties page until you find “Credentials for Script Sensors” and add two entries:

The API credentials will now be available to any script sensor we add to the device.

Next, add an EXE / Script Advanced Sensor to the new device, and give it a meaningful name – “Devices” for example. Choose the script to be run – “OsiriumPAM.ps1” and enter the script parameters:

These are:

Once created, you can add limits (thresholds) to the sensor channels to alert you should the returned values change.

Another neat trick is to add the address of the Osirium server into the “Service URL” field of the device details, so you can open the console directly from the Device Tools menu in PTRG:

Controlling who gets access to which resources, and when, is a vital part of the system administrator’s role. The prevalence of hybrid networks, cross-functional teams, and stringent compliance requirements, not to mention the huge upsurge in remote working in the last few years, have only made things more complex. Osirium’s PAM system is designed to simplify the task and reduce the burden on the admin team; helping them control and monitor their environments and identify suspicious or malicious activity, whether it originates from outside or in.