Trials and Tribulations of the Password Guy

I was just re-visiting a customer site to continue helping them with their Privileged Password Management deployment when I passed someone in the break room who called out “How’s it going, Password Guy?”

Password Guy? Well, I guess I have been talking about passwords for 10-plus years now, so I guess I can’t complain too much… but it did get me wondering… how is it that I’ve been talking about passwords for 10 years? Has this problem really been going on for 10-plus years? Actually, as you are about to learn, it’s been going on for much longer, and isn’t going anywhere any time soon.

When I first started dealing with the issue of passwords – back in the mid-1990s – that’s pretty much what we had-passwords. Sure, tokens were the rage and soon we all had a token (two-factor authenticator), but I was still dealing with passwords. In this case, they were root passwords. The root passwords didn’t use tokens, because tokens relied on a network, so you needed a password that would work at any time.

So, during my early security days, I had in the range of 300 different passwords that I owned (my account on various Unix/VMS/Tandem systems that weren’t yet using tokens) and a couple thousand root accounts that I didn’t own, but had to manage. Oh, and I had a token.

Users were authenticated with tokens, but they were relatively expensive and didn’t work on all platforms. Over the next 10 years, we saw LDAP, SSO, certificates, biometrics and others all be announced as the answer to passwords. And my number of personally owned accounts got smaller, but the number of shared system accounts (like root) that I had to manage never changed all that much.

So, over the past five years, Active Directory authentication seems to have emerged as the solution to our authentication woes. You can use your AD credential for email, system access, Web apps, and with AD bridging even us Unix bigots are logging in with AD credentials. As mobile devices get more integrated, they too are using this same AD credential. So is the end near for Password Guy?

Well, the short answer is no. What has happened is that this AD credential, which may not be privileged in AD, suddenly has become a very valuable target. Why? It works almost everywhere. How often does your organization force users to change their AD credential? I would say I most often see 30 days. So now, adversaries have an account that will work for up to 30 days if they compromise it. Where is this highly sensitive credential used? Everywhere. If you want to capture AD credentials, you don’t need elaborate hacking methods: Just stand up a bogus Web server and put up an authentication screen. If it is an internal Web app, most users expect that their AD credentials will be required.

This same AD credential, if the person is a system administrator, may map to privilege once the user authenticates to a local server, whether a Windows server or a Unix server. So now, you have privileged accounts (the AD account) being used all over the network and able to be attacked by APTs, regular phishing, social engineering, etc.

Whereas five to seven years ago, this account may have granted email or basic network access, now this same AD credential may be the equivalent of an enterprise administrator account based on the fact that the user’s AD account allows them to log in with privilege to many servers.

What I am starting to see is that many companies are becoming aware (sometimes painfully) of this exposure. Many companies have taken the approach that the “normal” AD credential can be used for non-privileged activities, and the “privileged” AD credential is managed.

Next Page: Manage or Eiminate

How is it managed? By controlling the password to this account, only giving it out when needed, and changing it after it is used. Does this sound familiar? This is what PPM has been doing for root accounts and other privileged accounts for years. So a new type of account is making its way into PPM systems: Individually owned privilege accounts.

The model of using a “privileged” AD account still has the inherent risk that it has a wide level of access. In a large organization, one AD account might be able to access hundreds or even thousands of servers. So some companies are taking the approach that even this access presents too much exposure in the world of APTs that may be able to move quickly to spread from machine to machine.

So another approach is to use PPM to manage the accounts with privilege, but have the accounts managed at the local server level instead of at the AD level: Completely eliminating the AD authentication as a method of gaining privilege at the server.

It provides a greater level of security (short lifetime of the credential, limited access, and only granted when needed), but guess what it does mean? A whole lot of passwords.

So, what does this mean at the credit union level? The reason these large companies could leverage their PPM solutions to solve this new risk (APTs), was because they had a PPM solution. What will be your response if guidance comes out stating that all privileged access to servers should be done without using AD authentication?

If you don’t have a PPM solution for the local administrator account today, how are you going to deal with the potential of many local accounts at each system which are now required for privileged access?

So, passwords are not going away. And as the Password Guy, I will say the same thing about them that I have always said. Passwords are bad. Eliminate them if you can, but more importantly, manage the ones that will not go away.