Too many admins spoil your security

We’ve all known for a long time that unnecessary use of elevated privileges is a bad thing. You shouldn’t be logged in as an administrator while surfing the Internet or checking your email; in particular, you shouldn’t do that stuff while logged onto a server as an admin. Your organization shouldn’t have too many enterprise admins, domain admins, or server admins. We all have that.

But recently I came across a large shipping container client on the Asia-Pacific rim that literally had thousands of application administrators. They have thousands of applications, many of which have hundreds of administrators; in fact, for some of those applications, every user was an administrator. In most of those cases, I’m referring to normal user accounts (not an OS or network admin account) that had the highest-level application privileges.

The most popular applications at this shipping company have many thousands of users, so at first having roughly 10 percent of your users operating as administrators may not seem like that big a deal. But users should always be lowest privilege level, and having an excessive number of application administrators is as bad as having too many OS administrators. Perhaps it’s even worse.

Every additional administrator causes linear-to-exponential growth in risk. Every additional admin doesn’t just increase his or her own risk; if they’re compromised, they add to the takedown risk of all the others. Each admin may belong to groups others do not. If a hacker compromises A and gets to B, B may more easily lead to C, and so on.

One big problem with too many application administrators is that application administrators rarely take the precautions that OS and network administrators do. Regular admins are now accustomed to using quarantined “jump” computers from more secure areas to do their admin work. They know not to surf on the Web or answer email using their elevated alternate credentials. They know to investigate and report possibly compromised computers. Application administrators tend to be much less clued in.

At this particular client, we found a significant minority of application administrators had been infected with malware over the last year. The number wasn’t any different than that for the general population — and that was exactly the problem. The company had significantly cut the number of OS and network administrators over the last year and had minimized the number of members in elevated groups. But no one had thought to do the same analysis on the application administrators (at least not until I came along — that’s why they pay me the big bucks).

Most bad guys are after systems and data. Even when they compromise the passwords of the entire domain and all the network administrators, what they are really after lies on application servers, which is why application administrators can do you in.

How to reduce risk First, do an audit of each application and find out the number of total elevated user (and service) accounts within the application. If the number seems extraordinarily high, do some research to confirm. Following the least-privilege principle, find out (or let the application team find out) how many elevated users are absolutely needed within the application. Get rid of those you don’t need and improve control over the rest. I’ve done a few of these audits; it’s usually easy to find the problem children, and you can eliminate a lot of them.

If the application requires a whole bunch of admins — and yes, such crappy applications exist — it’s time to start contacting the developers or vendors. Any decent application should require only a few administrators. Everyone else should be a reader or maybe a content-specific editor.

My favorite applications are the RBAC (role-based access control) ones where almost no one is an admin, and even the admins are limited in what they can do. In a great RBAC program, what each user can do is determined by his or her role — usually just a few functions or tasks. They can do only that task (say, update a record in a table) while within the application and performing a particular function.

Let me explain: In most of today’s traditional applications, application admins have complete control of the application. They can do anything: change any setting, install or uninstall bits, add and remove users, and copy the entire database off the network to removable media. An application admin is like an app god.

But in an RBAC application, no one is god. No one can copy the entire database or delete it or whatever. The person who adds and removes users and grants elevated privileges is not the same person manipulating the data within the application. In another instance, an RBAC admin may be able to access and change data, but only while within an application module. Once the application is closed, the RBAC admin has zero rights to the underlying database or application.

The bad guys are after system access and databases. That’s why I’m as worried about how a company controls and audits application administrators as I used to be about OS and network administrators. D’oh! It’s never too late for old security guys to learn new risk tricks.