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.