Privileged Account and Session Management (PASM) is a new PAM (Privileged Access Management) that focuses on privileged account monitoring and management for compliance, security, and data integrity purposes. Whereas PAM covers user account, on rights escalation demands, PASM and PEDM (Privilege Elevation and Delegation Management), its counterpart, covers those accounts that, by design, run on elevated privileges – administrative, system, and operational accounts. In this article, I’ll be covering PASM, the first step in building a functional privileged account monitoring & management infrastructure.

From PAM to PASM and PEDM

PASM is the answer to the life-long question: “who watches the watchers?”. Privileged accounts are vital cogs in a company’s digital ecosystem, ensuring e-business continuity, operational readiness, and, most importantly safeguarding assets and resources against insider threats and malicious actors. Undoubtedly, the term itself has caused some degree of confusion, often being mistaken with P.A.M (Privileged Access Management).

Indeed, PASM and PAM are two sides of the same coin (i.e. rights curation and access control), but not entirely the same. I have already mentioned the fact that PASM applies to privileged accounts, while PAM to ‘underprivileged’ accounts (non-administrative accounts). Now, in defining Privileged Accounts and Session Management, we first need to understand the fact that administrative accounts (i.e., admin) are not the only type of accounts running on higher privileges.

Besides admin accounts, we have system-type accounts (i.e. user-type accounts which are automatically generated by your OS during or after the installation process ends; they grant you system-wide access), service accounts, app accounts, emergency accounts, and the list goes on. Hierarchically speaking, user-type accounts are subordinated to privileged accounts which, through P.A.M and company-enforced policies can control, manage, and monitor the latter account types.

Here’s a quick example: say that user X, who works for company XYZ that runs a proprietary PAM solution, requests an elevated rights session to update the endpoint’s sound card drivers. The admin approves the request but decides to log the session in case the user tries to perform a task other than the one indicated in the request.

Let’s take it up a notch: instead of installing the sound drivers, the user downloads a music streaming software from a questionable source and deploys it on the machine.

Depending on the PAM solution’s level of granularity, the process can be automatically killed, before notifying the admin, or the event gets logged, later to be flagged as suspicious and be dealt with in accordance with the company’s policies. With this in mind, we will now turn our attention to PASM.

I already covered the core functionality of PASM, so let’s now talk about how privileged account and session management apply to the real world. Even the most basic PASM solution must be able to cover these areas:

  • Creating new privileged accounts (based on the company’s needs) or revoking existing ones.
  • ‘Policing’ privileged accounts (i.e., managing and overseeing privileged accounts activity).
  • Credentials ‘vaulting’. Setting up secure vaults to store passwords and private keys.
  • Credential hygiene. Policies that dictate when the passwords and private keys get regenerated.

Now, before we get to the part about PASM architecture, I should mention something about Privilege Elevation and Delegation Management (PEDM). Of course, this topic will be extensively covered in an upcoming article, but PASM without PEDM doesn’t make any sense. You’ll understand why in a second. Knowing that PASM is the ‘rule setter, PEDM can be regarded as the ‘control rod’. In essence, the solution adds granularity to PASM, allowing you to control privileged session parameters such as users, apps and services used, activities were undertaken during a privileged session, and more.

Privileged Account and Session Management – Architecture Basics.

Now that we’ve got that out of the way, let’s see the steps you need to take in order to plot a functional PASM architecture.

Step 1. Company policies and privileged account curation.

By now, your company must have lain down some ‘ground rules in regards to who gets access to what. I’m referring, of course, to IAM policies. Why are they necessary? Well, let’s just say you wouldn’t want someone from maintenance poking around payroll documents. Regardless of company size, role-based management is a must for the above-stated reason. Larger businesses would research ‘out-of-the-box solutions such as auto rights de-escalation tools that make use of POLP (Principle of Least Privilege). All the things discussed so far cover user accounts. What about your admin accounts, operational and system accounts?

Naturally, one cannot apply the same user-centric rules and policies to privileged accounts. That’s the first step to implementing PASM – defining privileged roles based on the company’s requirements, dimensioning each role by adding or subtracting attributes, and computing how many privileged accounts the environment needs for (optimal) business continuity. In privileged account creation, you must also consider the right-to-account ratio – not a good idea to create a single, God-type account (i.e., full permissions, full rights, no overseeing required) and several, lower-tier admin accounts; they do say that moderation is the key of life.

One last thing before we move on to the second step – compliance. Privileged account curation or, better said, overseeing, can help you obtain various compliance certificates. In some cases (e.g. HIPA and PCI-DDS), privileged account monitoring and management are mandatory. Keep these in mind when designing your privileged account curation schema.

Step 2. Define authentication rules.

Now that your first privileged accounts are up and running, it’s time to determine how your high privileged account holders will authenticate. MFA (multi-factor authentication) is a must, as in the case of lower-level accounts. Depending on the privileges associated with the account you can choose MFA via a web-hosted application like Google Auth or phone link.

Step 3. Overseeing privileged account activity.

Deploy the tools necessary to track, monitor, and enforce compliance across your privileged accounts. Compliance-facing tools will significantly the risk associated with insider threats. Privileged account overseeing also includes logging and recording. Scriptural logs and video records can greatly aid in your incident response endeavors.

Step 4. SSO and AAPM.

Security and app control must be precisely dimensioned to efficiently broker human interaction with apps and authentication mechanisms. AAPM (Application-to-Application Password Management) is one of the best approaches in app-to-app credential delivery, as it securely injects passwords into scrips or apps without the need to rely on human input.

AAPM-based PASMs are usually backed up by SSOs (Single Sign-On) to uphold confidentiality (i.e. not even the holder knows the credentials). Password vaulting is yet another good PASM practice – using secure, application-level, vault to high-level passwords. Do keep in mind that passwords vaults for privileged accounts should differ from those used to store passwords for ‘low-level’ accounts (e.g. Twitter, Facebook, Gmail, Dropbox, etc.).

Step 5. POLP and round-the-clock training.

The final step to Privileged Account and Session Management implementation is POLP. Allow me to rephrase that: company-wide adoption of the Principle of Last Privilege. As to what POLP is and how it can improve your overall account security, you should definitely give Andra Andrioaie’s article a thorough read. Anyhow, POLP should also be implemented in PASM as an extra failsafe against insider threat. Apart from POLP, consider adding more cybersecurity awareness training hours to your employees’ schedules. Consider bringing an outside security advisor to host these extracurricular sessions.


Privileged Account and Session Management is the best ‘gatekeeper’ one could have (and afford) to oversee everything related to privileged accounts activity. Although my recommendations would be to keep the number of accounts to a minimum, there are times (especially during a company’s ‘upswinging’ period) when more privileged users are necessary. As always, stay safe, implement the very best of practices, stay away from phishy websites, and subscribe to Heimdal™ Security’s newsletter.

Did you enjoy this article? Follow us on LinkedInTwitterFacebookYoutube, or Instagram to keep up to date with everything we post!

Leave a Reply

Your email address will not be published. Required fields are marked *