Does PAM have to be scary and make our lives difficult?

A few months ago I came across funny memes about identity on LinkedIn, some of which went viral. Gave my thumbs up, as you would do, but never did I suspect that the Author’s and my paths would cross only few weeks later. Thanks Michael Finley for making me laugh and the inspiration for this article. This one is my favourite to date.

Beware, PAM is coming!

If you’ve never worked with PAM, you may be in for a little system shock when the business puts it in place. One day I use my regular account to access AWS resources and my servers on prem, just to learn the following morning I need to start using new, different account, which is not part of any SSO. I am thinking, yet another password to remember, when I am hit by a 32 character random string which looks like an encoded jwt token and surprise, surprise… it’s rotated every 8 hours. My initial reaction is shock, doubt, maybe frustration and a feeling of impeding doom. I then realise that I actually have to go through a lengthy process to have another account created, which will enable me logging into the domain controller as admin. Others tell me it takes a few weeks.

Privileged IT user aka the crying baby under the table

I cannot remember my random, long password and if I could I am probably in the wrong place. The PAM interface will log me out in 5 minutes and I really do not want have to log back in, with the username, password, hard token, oh I forgot – I am working from home, so I need to VPN in first… username, password and a swipe on my mobile authenticator app. What am I going to do? Of course! I am going to open a notepad and paste the password there. It’s ok, after all it only is valid for 8 hours. Unfortunately the sessions are much shorter too, so I will need to enter those credentials multiple times. I will then go and log into an SSH console, RDP session, every time copying and pasting the password into the login prompts, while sharing my screen with the incident recovery team, which is recorded by the way, oh wait a minute, did I actually drag the notepad to the screen I was sharing? Oops…

PAM project team aka The Enforcer

Security is important, but it’s a business function which first and foremost should be aligned with the organisational goals. Pretty sure we don’t deliberately make our lives difficult, but at the same time, even though I am a non-revenue generating workforce, my customer experience has to matter. I we’re making this difficult for workforce the organisation suffers and potentially doesn’t deliver on time.

The Enforcer’s complexity

Sometimes the latest and greatest is not the best thing for the business. I quite often come across policies that govern MFA, based on the strength of the factors in relation to data criticality. For example, to access an application as admin, you can use soft token, but to access domain controller as admin, you need a hard token. The argument is about the strengths, but it’s all relative. The enforcer says, I want to use a Yubikey, because it’s a hard token and it’s stronger than a soft token. A mobile authenticator app is classed as a soft token. Well, hang on. Yubikey as an OTP is still a single factor MFA device (you don’t need anything to use it, you just need to have in your possession) and when it comes to resistance to verifier impersonation, it’s lacking. A mobile push notification based authenticator on the other hand is resistant to MiTM attack.

NIST SP 800-63B says:

Authenticators that involve the manual entry of an authenticator output, such as out-of-band and OTP authenticators, SHALL NOT be considered verifier impersonation-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. In a MitM attack, an impostor verifier could replay the OTP authenticator output to the verifier and successfully authenticate.

Instead, you could select a few MFA factors that meet or exceed your baseline. It doesn’t matter if it exceeds it by a fraction or by a power of magnitude. Empower your users by allowing them to choose the method they like across all applications (including PAM), because they are all good enough. I call this concept ‘Everyone can drive a Ferrari’.

Everyone will take the secure path, if it’s the shortest one.

Nature follows the path of least resistance. Rivers flow around obstacles and thanks to gravity, always downhill. Human nature tells us to take the easy path. It’s perfectly normal. In fact I would be concerned if we tried to complicate things for the sake of making them complex.

If the secure path is driven by the ‘gravity’ and is genuinely easy, users will follow it. We can elaborate on what it means for days, but it really revolves around one aspect – customer experience. Make it great and suddenly there’s no point in finding workarounds.

Privileged session proxy and the third A

Shared accounts do not provide the ability to audit (AAA), as there’s no identity centric approach. Unfortunately that can be a technical limitation. One way of tackling this issue is session proxy. Privileged user logs into the PAM platform and receives the console to the server via PAM proxy. It means that the authentication process is handled by the platform and the connection is broken down in two, just like in the MiTM (Man in The Middle) attack. User connects to PAM proxy, PAM proxy adds credentials and takes care of the last mile of the RDP or SSH connection.

What the eye does not see, the heart does not grieve over.

If the user doesn’t see the password there’s no need to copy or remember it. There’s also no way it can be stolen because of mishandling. Not quite passwordless, but the aftermath is pretty similar. At the same time, proxy can record keystrokes or video of the session and store that as a valuable audit tool. But proxy should not only be considered for shared accounts. It actually helps with CX (customer experience) as the user now goes to one place to reach all privileged resources without moving between applications or jumpboxes.

Privileged IT user – The PAM ninja!

A PAM Ninja is a user who understands the need for security and the lengths we go to in order to provide it. It’s a user who is educated by the organisation, fully aware of the threats and willing to follow the model. That user is empowered by the business through excellent customer experience. The PAM processes are simple, adaptive and fast. I encourage the organisations I work with to carry out maturity assessments in order to improve the PAM culture that is supporting their businesses.