BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

The Law Of Unintended Consequences

Posted December 21, 2011    Peter McCalister

It’s been a long while since I’ve logged into a UNIX box at the console or via telnet. But back when I was first learning my way around UNIX in the late 80′s and early 90′s, I vividly remember the nearly universal greeting when logging in as root:

————————————–
login: root
password:

Don’t login as root, use su.
#
—————————————

That short bit of advice whenever I logged in as root stuck with me. I didn’t always obey it, and usually I ignored it at my own peril. I remember many times when I really wish I hadn’t been root when installing random software or just going about my business, and the law of unintended consequences reared its ugly head.

When I began using Windows NT in earnest, and then Windows 95, I noticed immediately that this simple principle simply seemed to be missing. It was always assumed that if it was your machine or server, that you would naturally have administrative rights at all times. Chaos ensued, and I often found myself rebuilding machines from scratch to recover from a relatively simple mistake committed with admin rights. I rapidly recalled those earlier admonishments to use ‘su’ rather than the root account, and always remembered to create standard user accounts for day to day use. This was really hard in the “old days” of Windows, and some might say it’s still a pain in the butt today, though it’s become much, much easier with the advent of things like User Account Control in Vista and Windows 7.

In those days (and, honestly, still today) I also suffered from a problem that many in the IT world will recognize: that I was the personal IT support department of my family, particularly my dad. Sure, I tried to get him to log in as a standard user early on, in the interest of saving myself some headaches, but of course it didn’t stick. I can remember on numerous occasions being summoned to deal with a virus or some other kind of malware that had embedded itself so deeply in the system that even specialized tools were unable to remove it. Oh, if he had only been a standard user it never would have required the multiple reformat and rebuilds that it did. Yeah, you remember.

And so we arrive at today.. Microsoft has finally caught up with the decades-old UNIX capability of ‘sudo’ that is essentially what UAC provides. So life is better, right? Now actions performed as administrator can be logged and patrolled to some degree, but of course some issues have remained. With ‘su’ you could grant very specific capabilities, such as the ability to run a single application or command as root, without handing over the keys to the castle. UAC still makes this tricky, since unlike ‘sudo’ it doesn’t ask for your user credentials to elevate an application or command, but instead asks for admin credentials. So now we’re almost back to square one–where ‘su’ allows you to empower regular users to do specific things, UAC is virtually an all-or-nothing proposition. This may work fairly well in the home market, but it certainly flops big time in a corporate setting.

The bottom line here should be obvious, we here at BeyondTrust make really cool software that allows you to control admin privileges via network policy at a very granular level, and we can solve a huge swath of these problems in a corporate setting. But being new here (this is my third week), I thought I’d kick off the blogging by talking a little bit about my personal history with avoiding root and admin privileges for my day to day work, and why it has always been important advice, both in how I’ve worked and in the advice I’ve given to others. Thanks for reading!

Leave a Reply

Additional articles

Restricted Area Sign

Implementing Least Privilege for Windows the Easy Way

Posted July 31, 2014    Morey Haber

The concept of least privilege states that asset users should have the lowest level of access privileges required to effectively conduct their jobs. Implementing least privilege can bring several benefits to your organization, including: Increased security by reducing the attack surface available to users and to potential attackers who compromise user systems via phishing, malware,…

Tags:
, , ,
gartner market guide image - aug 2014

Introducing the Gartner Market Guide for Privileged Account Management

Posted July 29, 2014    Chris Burd

Gartner recently released a new Market Guide for Privileged Account Management (PAM), and we’d like to share a complimentary copy with you. The report includes PAM market analysis and direction, vendor overviews, and recommendations for selecting PAM solutions for your environment. BeyondTrust is one of two representative vendors (out of 20) to address all solution…

Tags:
, , , , , , , ,
Integrating Least Privilege and Password Management to Solve Account Security Challenges

Integrating Least Privilege and Password Management to Solve Account Security Challenges

Posted July 24, 2014    Morey Haber

There is a reason all BeyondTrust Privileged Account Management (PAM) solutions share the PowerBroker name: They all inherently enable you to reduce user-based risk and can be integrated under a centralized IT risk management platform. Here’s one common use case that demonstrates how this integration changes the playing field. Consider the challenge of privileged access:…

Tags:
, , , , ,