Our website uses cookies. To find out more information on the cookies we use, please head to our privacy policy.OK

Implementing a Least Privileged Model with Privileged Account Security Management (PASM)

Authorized Personnel Only - Least Privileged Model

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.

Related Articles

term->name is Third Party Access Protection

Recovery from O2 outage could have been accelerated using Osirium Privileged Task Automation

The system and process flaws that resulted in a loss of service for 23 million customers yesterday could have been resolved rapidly using Osirium… Read Post

The O2 outage, how task automation could help

Ericsson and O2 engineers would have been flat out either updating certificates or software. Once the fix recipe was determined it would be a case… Read Post

Sharing Privileged Accounts With Third Parties

In this article, we’ll look at customer, MSP and contractor sides of this issue. Outsourcing work to a third-party is a frequent occurrence.… Read Post