Least Privileged Model – It’s accepted knowledge that a least privileged model are good for security. They limit what a person, system or code base can do. The goal is ‘Just enough privilege’ to get the job done and nothing more.

We often see the least privilege model applied to endpoints. If there are no available privileges on the endpoint then it can’t be compromised. Meltdown and Spectre showed otherwise, and we should remember that the human operators are often fooled and phished.

The least privileged model is more important at the server

The servers hold all the critical data. Compromise of an endpoint is just a stepping stone to getting at the server. This is why a proliferation of Domain Administrator Accounts is a very bad thing.

People are more fallible than systems, people chose stupid passwords and given the wrong account, you are only one stupid password away from a breach. Osirium products follow a different architecture from other Privileged Access Management solutions, the last thing our solutions do is give a human access to a password.

Our best preference is to separate the user from the system, application or device altogether,

by using Privileged Task Automation. This essentially gives the user-controlled access to the task to be performed without a login to the remote system.

Next up is Single Sign-On (SSO). We would prefer that you have Osirium set up the connection and login well away from any endpoints. Once the session is set up, only the connection pipe is routed to the endpoint (and even then it’s in an SSL channel with a randomised port number).

In both cases, the user is separated from the privileged account credentials on the remote device. In security terms, this is what matters:

The identity of the user initiating the task or SSO – identity is a much better measure of security than the account used.

The roles and privileges of the account Osirium uses for the task or SSO – since these control the scope of the least privileged model.

This means that Osirium needs to keep track of a series of privileged accounts and allowable mappings to identities (identity in – Role out). Keeping track of these along with time windows and other gating items such as change tickets is Privileged Account Security Management.

Just to emphasise, Osirium takes a ‘vault last’ solution. Of course, we have break-glass and reveal password along with all the password updating scheme. It’s just that we never want your users seeing these in normal operation – there’s no need. Doing it right preserves the least privilege model all through the chain. It keeps you protected when the endpoints aren’t yours to control and people fail.