ajbrehm

New Member
Joined
Mar 2, 2024
Messages
1
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.)
 


Solution
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...
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.
 


Solution
Back
Top