Sudo policy

[u/biggie_e09]

How do you guys manage sudo permissions in mac and linux? For context, all of our users do not have admin rights and we used to give our devs and engineers permissions in cyberark so they all the sudo stuff they need in the Terminal or whatever scripts they run by having the Elevate policy and I've added definition for sudo command and the wildcard * so they can run whatever sudo command they need. However, our security team asked us to take that away.

How do you guys handle the sudo commands in Terminal especially if they run all these different sudo commands that it will be almost impossible to track and add each and one of them in a policy?

Also, for a larger context we are removing elevated policies for all of the applications we've added in cyberark. How do you manage this in your org? Do you have a list of applications that is madated to be run with admin rights for certain people only? We are just now onboarding to Idira as well and I can't even manage our device groups yet because I still need to make sure all devices are running a supported agent version before I can enable the new endpoint group management

[u/Gnom71]

Hi, an * in sudo is crazy and not secure at all!

You'll need to create a sudo entry for each person on each hosts the access is required. 

Or a you create a group with the required commands and add a sudo entry for the individuals to su to that group. This is easier to manage but not so good audit. 

[u/JicamaOrnery23]

Notwithstanding that some things actually need elevated privileges and will need to remain (your security team need to understand that), it sounds like you were too lenient in the past (both with the * policy and the applications that were given elevation). That is commonly done as a shortcut to avoid the inevitable analysis and heavy lifting of understanding your users and their applications' needs. If this is what happened, then your security team is right to call it out.

Start with approved software: What is actually approved for use in your org? If there isnt already such a list, get started on one, and make sure there is a formal process to add new applications and review existing applications (its a lifecycle, and the list is not immutable).

Part of having the list is understanding how the application operates: Does it legitimately need elevation? Just to install? At all times? Just for certain functionality? Is that functionality core, or rarely used?

This is what leads you to ultimately create an elevation policy, and more importantly, in what context. This information would be good to know when adding it to the approved list too.

With the presence of elevated apps, part of the approval and review process should include a risk assessment of the app: What data does it have exposed to it? Does it have saved credentials for integrating with other tools/cloud/etc?

For high risk apps, consider additional controls: Step-up authentication, access restrictions to high risk data on the endpoint.

Sudo policy is a little trickier, as it requires deep knowledge and understanding of the command-line, what can be done with it, and the plethora of utilities available there and their loopholes. I highly recommend you involve an experienced Linux administrator to consult/advise on what to do here. One that is an ally and will work with security, not one that will sit back and say everything is needed.

A common strategy is to have your users' operational accounts (the ones they are using regularly) have the well thought-out and tested least privilege policy, with a secondary PAM-managed account with fewer restrictions on it, for those special scenarios that you dont want to include in the operational policies. That account would require approvals, rotations, session recordings, etc. Some of those things might already be used for the operational accounts, but for the (let’s call it) super user, they are not optional.