It seems I’ve been preoccupied lately with telling all of you about the things you shouldn’t do anymore. Between blowing away firewall rules and killing security technologies, I guess I’ve become that guy. Now get off my lawn!
But why stop now – I’m on a roll. This week, let’s take on another common practice that ends up being an extraordinarily bad idea – running user devices with administrator access. Let’s slay that sacred cow.
Once again, most of you security folks with any kind of kung fu are already here. You’d certainly not let an unsophisticated user run with admin rights, right? They might do something like install software or even click on a bad link and get pwned. Yeah, it’s been known to happen.
Thus the time has come for the rest of the great unwashed to get with the program. Your standard build (you have a standard build, right? If not, we’ll talk about that next week in the Endpoint Fundamentals Series) should dictate user devices run as standard users. Take that and put it in your peace pipe.
Impact
Who cares? Why are we worried about whether a user runs as a standard or admin user? To state the obvious: admin rights on endpoint devices represent the keys to the kingdom. These rights allow users to install software, mess with the registry under Windows, change all sorts of config files, and generally do whatever they want on the device. Which wouldn’t be that bad if we only had to worry about legitimate users.
Today’s malware doesn’t require user interaction to do its damage, especially on devices running with local admin access. All the user needs to do is click the wrong link and it’s game over – malware installed and defenses rendered useless, all without the user’s knowledge. Except when they are offered a great deal on “security software,” get a zillion pop-ups, or notice their machine grinding to a halt.
To be clear, users can still get infected when running in standard mode, but the attack typically ends at logout. Without access to the registry (on Windows) and other key configuration files, malware generally expires when the user’s session ends.
Downside
As with most of the tips I’ve provided over the past few weeks, user grumpiness may result once they start running in standard mode. They won’t be able to install new software and some of their existing applications may break. So use this technique with care. That means you should actually test whether every application runs in standard user mode before you pull the trigger. Business critical applications probably need to be left alone, as offensive as that is.
Most applications should run fine, making this decision a non-issue, but use your judgement on allowing certain users to keep admin rights (especially folks who can vote you off the island) to run a specific application. Yet I recommend you stamp your feet hard and fast if an application doesn’t play nicely in standard mode. Yell at your vendors or internal developers to jump back into the time machine and catch up with the present day. It’s ridiculous that in 2010 an end-user facing application would require admin rights.
You also have the “no soup for you” card, which is basically the tough crap response when someone gripes about needing admin rights. Yes, you need to have a lot of internal mojo to pull that off, but that’s what we are all trying to build, right? Being able to do the right security thing and make it stick is the hallmark of an effective CISO.
Discuss
So there you have it. This is a FireStarter, so fire away, sports fans. Why won’t this work in your environment? What creative, I mean ‘legitimate’, excuses are you going to come up with now to avoid doing proper security hygiene on the endpoints? This isn’t that hard, and it’s time. So get it done, or tell me why you can’t…
Reader interactions
9 Replies to “FireStarter: Admin access, buh bye”
@Glen Daniel
Yes, I have done this, too. It usually works OK. You can even take it a step further and create an “application profile” by using AD and Group Policy. Then, when someone else has the same app you can assign them the policy and they will get the correct permissions.
I’ve found that most applications that require admin rights to run do so because they make changes to specific keys in the registry and/or they need to save files to the root drive (I’m talking WinXP here. Not sure if this applies to Vista or 7). When we find an app that won’t run without admin rights we use an app (I think Log Parser) to find the “Access Denied” entries in the logs. Then we elevate the privileges to those specific Registry keys or the specific folder on the root drive only. That works pretty good for us.
There’s one key element we’re missing here: company culture. I have seen companies who denied admin rights by default and were able to spend their spyware budget on something else. I have also seen companies where denying admin would result in a user revolt.
In the latter case, I know enough to provide an alternative. As a matter of professional responsibility I would still recommend not running as admin, *but* if you don’t want to do that, here is option B.
Option B is to run the most common internet applications as non-admin, using something like software restriction policies: namely, the browser, e-mail and IM client.
Certainly, this is not a fool-proof solution. However, we must consider the risk we’re trying to mitigate. If we can reduce the risk through the most common attack vectors, then we may have reduced it enough to be acceptable.
Is it a trade-off? Sure. But tell me when security isn’t a trade-off. We do what we can. To hell with the purists!
I wonder how this InfoSec / IT-Sec paradigm is going to be affected by App-V and things like the WinXP guest in Windows 7 (or other popular virtual machine Hosts).
Another question might be WHEN (if at all) the desktop is going away in Global 200 Enterprises (or the larger government agencies worldwide).
Is this a problem specific to Windows networking because of the concept of forests/domains?
I have heard about some businesses whitelisting applications as secure on platforms such as the iPhone or Android OS. Perhaps, like I mentioned before, it is better to spin cycles on app security than locking down the end-user platform?
Ahh, the admin rights dilemma!
Here are some things I’d throw into the fire. Disclaimer: I think a vast majority of users should run as a normal user, and certainly everyone who is not technically savvy. The approach *should* be to get everyone running as non-admin, and make exceptions the rare case.
I also far prefer not to even give most users an option to run as admins. They shouldn’t install crap anyway.
1) System admin. This is an arguable topic, but I know many sysadmins or your infrastructure admins who also run as admins on their workstations. We do tend to be far more comfortable with “run as,” but there are still those who just do a far better job when they can go day-to-day as admin. Then again, even if we couldn’t, we most certainly log into servers with elevated privs anyway and have options… We also probably do install more business-related things than most depts…
2) Developers, especially web developers. Tools like Visual Studio and a local IIS install just simply need admin rights. I’ve never seen a web developer who was fine with or hit no ceilings while running as a non-admin. I feel the nature of their work tends to cause them to be an exception as a group.
3) Laptops don’t help the argument, especially when someone is remote and either needs to change network settings for the Important Trade Show network, or install printer drivers at Important Client Location. Thankfully this trade-off is best met by 24/7 tech support and other fancy solutions (an account that can *only* make network setting changes), but there are still small nuances and things to think about with mobile devices that find their way into environments you can’t predict nor control. They should still run as non-admin, but it does come with some frustrations!
4a) Not only does running as non-admin typically result in having standard builds/images, but you increasingly need an engineer to deploy and control such things, especially if you’re getting past the 200-user count. This is a significant uptick in cost and manhours. This is more important if you have any players who do any r&d or evaluate new software (like developers!). They need deploys, installs, etc.
4b)Likewise with standard builds are the licensed softwares that are not globally distributed or covered by site licensing. You need to track them and have a way to deploy and remove them…
…and so on.
Anyway, just things to think about in a topic that should be simple (and usually is!) but does have pockets of challenges.
@dre – No arguments with server and application security as a priority. Yet, there are also things on the endpoint that we can/should do to add another layer of defense. Legacy applications are a sticky one, since typically those don’t warrant a lot of investment to bring them up to snuff. As always, it gets back to understanding the risk the issue presents to the org. If it’s a handful of users that need admin access, the risk is probably acceptable. If it’s everyone, then it may not be or other alternatives need to be considered. That’s the point.
@steve – There are options to do “run as…” but that gives the user (even sophisticated users) the ability to circumvent the control. You may want to look at something like privilege escalation (BeyondTrust does this), which provides a policy-based mechanism to escalate rights where needed. I’m going to go through the alternatives in much more detail in the Endpoint Security Fundamentals series over the next two weeks.
The only exceptions to our standard image with limited user rights is the small minority of users who work regularly with application software tools that require admin rights (not just to install, but for routine upkeep). The need to use some of these “heavy client” tools by some of our staff to support client work has led in the past to issuing laptops with admin right enabled, but this is a catch-22, since that sort of configuration violates FDCC. No argument with the premise here, but I’m curious how you feel about allowing “Run As” for end users as an alternative to enabling full admin rights on the device.
Mike,
It’s certainly possible to have attacks persist after normal users log out and back in, (thinking of Programs\Startup\ here), but a) it’s much more obvious & easier to clean since they don’t have access to all the obscure nooks & crannies admins can muck with, and b) apparently the virus authors haven’t put much effort into non-admin persistence, likely because there are so many admin accounts to compromise. Make ‘em work for it!
@ Mike,
You said, “It’s ridiculous that in 2010 an end-user facing application would require admin rights”. I guess the one objection here is that legacy applications have no knowledge of what year it is. Worse, some projects (especially ones supported by legacy hardware or software) have no expiration built into the product.
Check this list out – http://securityscoreboard.com/reviews/tag/productsoffered/privilegedaccessmanagement/
The above security products can get you on the right track. Becoming a CIS (Center for Internet Security) Member will give many additional resources for end-user, desktop, and server hardening (if you’re in the private sector—NIST FDCC otherwise).
Server and application security have preemptive importance in my world (compared to end-user hardening, which can usually become undone, and network which can be tricked/subverted).