Americas

  • United States

Asia

Oceania

roger_grimes
Columnist

Too many admins spoil your security

Analysis
May 07, 20135 mins
Access ControlData and Information SecuritySecurity

Never give users more access rights than needed. If you hand out admin privileges like candy, it'll come back to haunt you

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.

roger_grimes
Columnist

Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author