Least-Privilege Security – Why and How

- Greg Gray, BOHH Labs Senior Software Engineer

Your users only need access to the resources they need to do their jobs. It’s a pretty simple concept that’s been a best-practice for many years. Simple in concept, not so simple in execution.

To make this concept work, I believe there are three areas where least-privilege security must be implemented: users, applications, and processes. Below we will take a deeper diver into each one.

Users
Users are given access to machines (e.g., their workstations) from which they perform their jobs. In many corporate environments, users are not given the privilege to install software. The applications they are allowed to run might also be controlled. Even access to some areas of the local file system might be necessarily restricted to maintain the integrity of the running machine.

Software developers typically need access to their own workstations and remote databases and servers. Since many of these needs are project-based, the privileges should be given to get the project done, then revoked when the privileges are no longer needed. This revoking of privileges is often missed, giving some users, who have worked on many projects, access to many more resources than they need to do their jobs at any one point in time and the opportunity to misuse data they have access to but should not.

System administrators need access to systems at a high-level of privilege, but does each administrator need access to all systems at that level?  In the smaller environments, probably yes, but for large environments, with a larger number of administrators, some narrowing of the privilege scope is probably warranted and ultimately a best practice when it comes to security.

The disgruntled employee with privileges to many systems is a danger to the company’s assets should this person be fired. A protocol needs to be established for quickly removing the privileges of this employee if needed.

Applications and Processes
Applications need privileges to access file systems, local databases, and remote databases and systems. Sometimes privileges are given to an application early in the development life-cycle that might not be needed later in the development life-cycle.

These privileges should be pared as needed so the application doesn’t go into production with unnecessarily liberal access to certain database resources or other company resources. If the application doesn’t create or drop tables, then the application shouldn’t have that privilege. There may also be different roles for users of an application. A role that only does reporting probably doesn’t need data modification privileges.

User Privileges
Implement Centralized Login:
The first thing that needs to be done to get control of user accounts and privileges is to establish a centralized login system. In a Microsoft Windows environment, this usually begins with the Active Directory Domain Services. In a Linux/Unix environment, an LDAP server can provide for central management of logins and permissions. An Active Directory service can also act as an LDAP server for Linux/Unix environments.

Active Directory Domain Services actually encompass multiple services that can be used for privilege management and maintenance:

• Domain Services – Provides authentication and centralized storage for users and data. Also provides search functions.
• Lightweight Directory Services – Provides for directory-enabled applications using the LDAP  protocol.
• Directory Federation Services – Provides single-sign-on (SSO) to authenticate users to multiple applications and devices.
• Certificate Services – Provides for the creation, distribution and management of secure certificates.

Kerberos is an authentication protocol that uses the concept of tickets to allow machines communicating over an insecure network to provide proof of identity. Kerberos is commonly used for SSO in Linux/Unix environments, but Microsoft also has a Kerberos system available.

Centralized login systems aren’t just for users. Applications and Databases can use them, too. As an example, MySQL Enterprise can be setup to use Pluggable Authentication Modules (PAM) to authenticate using an LDAP, Kerberos, or other authentication source. Other systems can use Kerberos without PAM.

Establish Policies
Once a central login system is established, policies need to be established that outline what is permissible for each user, application, and process. Users will probably have a blanket policy that covers all users for access to their workstations, email servers, etc. System administrators will have their own policy that extends their permissions for their unique role in the security realm.

Applications and Processes will have their own unique policies that will likely vary from application to application. Database permissions for software developers will have phases where the beginning of the projects will allow more permissive access while the permissions might disappear altogether after the application is in production. The application must also have a documented policy for appropriate permissions for it to perform its functions. These varying permissions can be grouped into roles and assigned to each user as needed. The centralized login system can store and manage these roles.

Audit
Perhaps the most important actions to take for least-privilege policies is auditing the systems to ensure that the policies are being enforced. Audits should be scheduled on a regular basis in addition to having a few surprise audits. Auditing not only ensures that the policies are being enforced but also reminds the user community what the policies are and that the policies are important to the company.

Automation
Least-Privilege Security management is not an easy task. In small organizations it could probably be managed by a small number of people (at least two) but in larger organizations, the task becomes onerous. Luckily, there are a number of third party products that can provide automated services to bolster your privilege management efforts. These services run the full gamut, from automated probing of systems looking for vulnerabilities, to performing the necessary audits to ensure policy compliance.

It is not our aim to promote any third-party products so, using your favorite search engine, search for “least privilege security” for a list of such products.

Least-Privilege Security has a vital role in protecting your company’s systems and resources, in other words: your company’s bottom line. Users need clear policies to outline what is expected of them. Application developers need clear policies to ensure a secure environment in which to run their applications and access their databases. These policies need to be enforced to ensure there are no holes in the systems or in the policies themselves. Finally, verifying the policies are being used as intended via audit is the final necessary step to securing and protecting your company’s resources.

Why All Applications Should be Created as if They Were Security Applications

Before I go in to detail on this subject, let me make some statements clear:

1. I do not believe that organizations should stop purchasing specific security applications, CASB's, Firewalls, VPN's etc.
2. I believe that security is multi-faceted and that organizations must take different and layered approaches to protect their data and systems. 
3. I am not the devil in carnet. (Although this has yet to be proven outright!)

This has to be said up front, as I just spoke at a conference and addressed this subject and inevitably people told me how wrong I was and that an application's job should be to do what it says on the tin. This then leads on to them accusing me of not taking security seriously. (Not the case).

But while we are on it, let me also add in here that I am not a great lover of the current rush to use external libraries - API's into other applications yes, but not external libraries that we as developers have no insight into and no definitive way to make sure that they are programmed correctly and in a secure manner. Oh yes, there is Open Source. This does have a place, but the licensing can be restrictive on organizations, and also it not immune to massive security errors.

So here go my thoughts on it:

Systems are inundated with bad actors every hour of the day - all 24 of them and every single day of our seven-day week. We have had the current security practices for over a decade now, and while they have definitely worked in some cases, there are other well documented ones where they have blatantly not. This alone tells me that we need to re-evaluate how we are protecting our systems and data. One of these places must be within the applications that are used. If I create an application that connects and retrieves data from a database in a data center far far away, is it not incumbent on me to make sure that:

1. I check for SQL Injection Attacks
2. I make sure that there are ZERO login credentials held in plain text that my application uses.
• This means, no scripts
• No uncompiled code
• No ini files
• No conf files and
• No txt file

Or, to put it another way, there is no mechanism for a bad actor to read a file that held on the system and take from it details that will compromise the data.

I do not see this as being controversial or special, just good practice!

In addition to the basic points above, I also believe that the software developers job is to:
Create an application that does what it says on the tin, making it as simple to use as possible, while maintaining security to a degree that makes it incredibly hard for any non-authorized actor to access anything that the application has been designed for, without, compromising the usability.

And then this last point is vital. As soon as usability is compromised, the users will find a work around and then security is forgotten about, as a user’s primary role is to complete the task at hand, and they will just assume security.

This leads me nicely on to my next rant. Security of data is down to us as technologists. We are the ones who should know how to secure up a database. A bank's role is to secure my money and make it available for me. My role is to make all the transactions in between secure. I have more knowledge than they do on that, and I hope they have more knowledge than I on the markets, so they and in turn I do not go broke!

These are all great words and statements, but in practice how does a developer create an application that does what it is designed to and separately keeps the data secure?

This is where I lose the few friends I have within the industry, but here it goes:

When programming, STOP relying on external libraries that you have zero insight into. Programming is an art form. We create an application from a blank screen, it appears before us. I have never heard anyone say, "Wow Simon that painting by numbers book you have completed has really made a difference and it is truly unique." I am not saying that all libraries are bad, of course they are not, but let us not rely on them. Start looking within and creating your own. This allows you to know they are written as securely as they can be, and that you have full control of the source code. Otherwise, how do you know that your application is secure? The library may have security flaws in It, or worse, it may be calling out sending usage and other data to the publisher. Security starts from the basis of 'I do not trust you.'

Then there is the programming itself. I am not the world's best. I create an application, a library for our applications or a routine to go in to one of our applications, and that then goes to the engineering department who scrutinize, scream, fix and generally work on my code. Once they are complete, it comes back to me for review where I invariantly will have a lot of changes and once more send it to engineering. This process goes on until we are happy. Then a code review happens with myself, my CTO and our chief developer. We look at the code and check for security holes. Once this is done we go to Beta. During the whole process, we are continuously testing and pushing the code to its limits and in some cases sending it out for review and testing.

To sum up. I see my job as a technologist to help with security and make sure that the applications I have control of can be a part of an organizations security defenses, no matter what the application is designed to do.