Security Bytes: What is Least Privilege and why you should care about it - History

This post is the first in a series of posts on the challenges of balancing privileged access with a robust security posture and a challenging delivery pipeline.

It is also the first of my Security Bytes posts, where I dig into areas of interest in Information Security/Cyber Security, and offer my opinion.

If you’ve known me for a while you’ll know I’ve only worked in an InfoSec/CyberSec role for just over two years. So what do I know about security?

Well, I’ve also worked in IT for a total of just under 25 years now.

So I’ve been around, I’ve seen things…

IT History

First of all, a little history is needed.

I’ll keep this short, lest I bore you to tears!

When many generations of computer were invented, they weren’t always accessible to all:

1. They were huge.
2. They were frighteningly expensive.
3. They were not user friendly in any sense you’d use that description today.
4. They were not connected to other computers or if they were, they were closed private networks.

In the late 60s and early 70s, the precursor to the Internet was born, ARPANET.

This led to computers being far more connected than they were before.

Fast forward to the late 80s and early 90s and the invention of the World Wide Web made computers far more accessible and user friendly. Fast forward from there to now and we continued to reduce the barriers to entry of computing:

1. Increased affordability.
2. Reduced complexity - if you wanted to you could use a computer to play games, to watch video, to find information.
3. Reduced size.

Why am I going over all this? What relevance does it have today?

Simply put, the more ubiquitous computers have become, the more we rely on them, the more we wish to make them easy to use and abstract away the complexity from those who don’t know how to write programs or scripts, the more dependent upon them we become, the bigger a target they have become to those who wish to cause havoc, to deceive, to steal.

The only truly secure computer isn’t powered on right?

Users vs Admins

There are and have always been several types of users of computers, ranging from novices to those who design and build computers and the software that runs on them.

Traditionally, the people with the most privileged access to computer systems have been those most skilled and most trusted to administer those systems at a low level: System Administrators or SysAdmins, Operators, perhaps software developers on less sensitive non-production systems.

You would always have more ordinary users than privileged users in the past. An ordinary user of a software application doesn’t need administrative access to run an application, in most cases they don’t want it either (Personal Computers in a home/hobby setting notwithstanding).

Keep that last point in mind as we go on…

OSI Model

From the late 70’s onwards a model called the Open Systems Interconnect or OSI model started to be developed to quantify the different layers in a system architecture:

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

The higher up the stack (layer 5-7), the closer to the ordinary user, the lower down the stack (layer 2/3) the greater the requirement for specialist knowledge and the need for privileged access rather than just “using” the system.

I’m deliberately over simplifying to make a point here as admin users operate at the application layer when using a computer system, but they also need to understand and perhaps physically work with the lower layers.

So what changed?

Segregation of Duties/Role Based Access Control

Somewhere along the line as systems became smaller, cheaper, more connected, you no longer had to be physically at a system to use it and that also applied to privileged users - they don’t want to have to go to a noisy datacentre just to perform admin tasks right?

So you then have admin users and normal users using the same interface - and that means you need a way of segregating access - a normal user should not be able to reconfigure or shutdown the system or applications.

So you need Role Based Access Control (RBAC).

Privilege Elevation and Security Contexts

So we have established that we need to segregate admin access from non admin access. This can and has been done in a number of ways over the years in various different operating systems.

I’m going to pick on two examples here.

Unix-like systems - superuser

Unix and Linux systems have a number of different security controls. One of the core concepts though is multi-user support and run levels.

With the idea that depending upon the mode of the system and the user you are logged in as, what you can do can vary quite wildly.

In the beginning there was one user: root. This is known also as the superuser and has access to every file and command on the system.

You can (and should) create less privileged users for using the system without needing to administer it.

This helps protect the data, the service underpinned by the system, a whole host of good reasons why.

There was always a way to switch from one user to another: the substitute user (su) command (quick note - I’d always thought this mean “switch user”, not “substitute user” - every day is a school day!).

However, rather than su to a more privileged user (be that root or another privileged account), then drop back to the lesser privileged account, admins may be tempted to just stay logged in as the privileged user.

Why would that be bad?

1. If you guess or compromise the password of root or a root equivalent account you can do what you like - change data, steal data, corrupt the system, shut it down, you name it.
2. If you always run as root, there are very few safety nets in a Unix-like system - there is an assumption of a certain level of skill and knowledge to be able to use those systems - once upon a time there wasn’t a nice graphical user interface/desktop on Linux/Unix.
3. Human beings are flawed, we make mistakes. If you make a mistake as a non privileged user, the impact is fairly trivial because your access doesn’t afford you much ability to cause significant damage. Make a mistake as root though…

Enter SUDO

In the early 80s, SUDO was invented. In its initial guise it allowed you, as a standard user, to have certain commands run as the superuser. So your security context didn’t change, you were not root, but you could get root to run things for you. SUperuser, DO.

You also don’t need to know the root password, you’re not logging in as root. You’re logging in as you and asking for a command to be run as root - impersonating root in effect.

Initially all SUDO really did was switch you to be root without logging in as root or knowing roots’ password.

Over time it has grown to allow very fine grained control over what a user can do. A user has a sudoers file that dictates what they can and can’t do, and what they can or can’t have run as a superuser.

Windows

Windows has a somewhat different approach. Whilst there is some commonality and standards compliance on things like filesystem permissions, where windows is lacking is in real granular privilege solutions that are easy to configure, administer and use.

There has been some good work by Microsoft over the years here (and some bad decisions too).

Microsoft though had a challenge with Windows that Unix-like systems did not have for many years: Windows is GUI driven, user friendly. As a result far more standard everyday users had access to a Windows PC/Server than a Unix or Linux machine.

This in turn presented a few other challenges:

1. Abstracting complexity away from the user.
2. Maintaining backwards compatibility in future OS Versions.

As soon as you try to hide complexity from the user, you just move it down the stack, you increase complexity in the lower layers. This increases the likelihood of bugs/security holes, intentional or otherwise.

The popularity of the friendly user experience means you become a victim of your own success - more users = more people who maybe find those bugs - including those with malicious intent.

And with that popularity comes pressure to maintain backwards compatibility.

People don’t want to keep upgrading - that takes time, effort, money.

So Microsoft get left to live with those choices over decades.

Summary

I’m going to stop here before diving into Least Privilege. I’ll dive into that in my next post.

As ever, thanks for reading and feel free to leave comments down below!

If you like what I do and appreciate the time and effort and expense that goes into my content you can always