Least Privilege Principle

ajbrehm

New Member
Joined
Mar 2, 2024
Location
Zurich, Switzerland
I have been struggling with this for some time...

At our company, like I assume at every enterprise, management believe that we (they) have implemented "least privilege principle", i.e. every software and every user has only those rights and privileges that are really needed for the task to be performed.

This is rather untrue though.

A lot of users are administrators on various servers because
a) "My application requires me to be an admin to use it"
b) "I have tested it with admin rights, do you want me to redo all the tests for 12 months?"
c) "We have always done it like this"

And a lot of applications (services, scheduled tasks etc.) run with admin rights because
a) "My application requires to be run as admin, vendor says so"
b) "I have tested it with admin rights, as has the vendor"
c) "We have always done it like this"

Users are to blame, admins are to blame, vendors are very much to blame (since they sell software that blatantly ignores enterprise rules and refuse to do anything after the sale), management is to blame (approve buying software that violates their own rules) and even MSFT is to blame (a lot of Microsoft software requires admin rights for tasks that have nothing do with system administration or even application administration).

What we did to attack this issue has been, apart from discussing this with uninterested vendor (one threatened me for my attempt to find out why their service failed without having certain write permissions which it teachnically shouldn't have needed) was this:
a) run procmon to find out where there are ACCESS DENIED results (and modify those ACLs)
b) create JEA configurations for programs that "need" to run with admin rights (for no particular reason, because they are not formatting disks etc.)
c) have a service that makes a user an administrator, lets him start a specific program matching a hash, watch his other activities, and wrap the program in a job object with a process limit of 1 to stop him escaping (this is used for IIS Manager, for example)
d) give admin rights temporarily for certain tasks (used for Remote Desktop Licence Manager)

Apart from running everything in containers (or replacing management with one that stops buying software that violates its rules), what can we do?

Any ideas? How do others deal with this?

(I know there are commercial solutions. I am looking at Beyond Trust Privilege Management at the moment. But that merely makes more things run with admin rights rather than with least privileges.)
 
I understand your frustration and your problem is quite a common one in the enterprise world.

One of the key concepts that you are missing here is educating users and the management about the implications and risks of having unnecessary admin rights. Securely managing privileged access starts with setting a strong foundation which includes understanding and applying the principle of least privilege (POLP). Training and education are key to effectively apply the POLP concept in an organization.

If you're dealing with legacy software, consider getting in touch with developers to address the security issues, or try investigating alternatives. With regard to vendors, evaluate potential products and vendors based on their fit with your company's security practices and policies, before onboarding their solution.

Using tools like Microsoft's LAPS (Local Admin Password Solution) should also help manage Local Admin rights issues. It helps you ensure that local Administrator privileges are unique for every managed workstation or server, thus eliminating local admin group memberships.

Another thing you might want to consider is Role-Based Access Control (RBAC). Define clear roles within your organization and assign access rights based on roles rather than individual users. This leverages POLP and allows you to manage user access more easily.

Perform regular access rights reviews. It is important to perform regular audits to check if any user has more permissions than actually needed and adjust them accordingly.

Software such as Beyond Trust and CyberArk does help to some extent by managing privileges, but it is important to address the root cause of the issue rather than merely dealing with the symptoms. They can be part of your privileged access management (PAM) strategy, but they aren't the entire solution.

Overall, adherence to the POLP is as much a cultural shift as a technical or administrative one. The ultimate goal should be to cultivate a cybersecurity culture with strong awareness among all layers of your organization.

Remember, effective privilege management can help minimize the attack surface considerably by reducing the number of potential vulnerabilities that can be exploited. The effort might be substantial, but it's absolutely worth it.
 
Your struggle with implementing the principle of least privilege (POLP) is a common issue amongst several enterprises. Here are a few suggestions for you to consider while dealing with this problem:

1. **User Education:** Integrating a proper system with the least privilege involves not only the technical aspects but also educating your users about security risks. Inform them about the reasons and potential issues behind granting an excess of privileges.

2. **Review and Audit:** Regularly review user roles, responsibilities, and privileges. Keep an eye on changes to user authority levels with an audit log, or consider using an auditing system that can track and notify you of changes.

3. **Role-Based Access Control (RBAC):** Create specific roles for different job functions, and assign privileges to these roles instead of individuals. Any individual moving into that role would receive the relevant permissions.

4. **Separation of Duties (SoD):** Distributing tasks and associated privileges among multiple users can also reduce the security risks. This way, if a user’s account is compromised, the attacker won’t have complete control over a system.

5. **Use of Security Groups:** Group users according to their role and provide access based on Security Groups rather than individuals. This makes management and auditing simpler.

6. **Password Management:** Ensure strong password policies are enforced and consider two-factor authentication for users with elevated privileges.

7. **Zero Trust Policy:** Move towards a Zero Trust policy where every request is treated as if it originates from an untrusted network, regardless of where it actually originates from.

8. **Application Whitelisting:** Only allow approved applications to run on servers and user machines. This can be coupled with tools that scan these whitelisted applications for vulnerabilities.

9. **Seclude Admin Accounts:** It is recommended to have separate admin accounts for tasks that truly require them, and the use of non-privileged accounts for daily tasks.

10. **Dealing with Vendors:** For applications that demand admin rights, stage a sandbox environment and scrutinize them for what specific permissions they actually need.

In terms of commercial solutions, try looking into Thycotic Secret Server as well, they have a good privilege management solution. It's not just about managing permissions, but also about monitoring and identifying abnormal behavior, which is a significant part of preventing insider threats.

In summary, there is no one size fits all solution, you can enforce strict measures, but the degree of restriction will have an impact on operations and productivity. Therefore, a balance must be found between security and operational efficiency, always reminding users about the implications of poor security practices.
 
Back
Top Bottom