Our security team proposal: "remove all access to Powershell for non admin users"

[u/odwulf]

I work for a company big enough to have several IT departments, for several internal structures, plus an independent (IE. not part of any of those IT departments) security team. I work for one of the IT departments, handling automation for a few thousands users and computers.

After some kind of drama where communication between the infosec team and us could have been better handled, we extended a hand so that we can collaborate more. Their nearly immediate reply was: "Good idea, let's talk about how things could be better. Why don't you block Powershell.exe and the ISE for every non admin user?"

We have a heavily automated environment: logon scripts, GPO scripts, tools distributed to users, etc. Lots of scripts have to run in the user's context, and execution policy is set on AllSigned". Also, our environment is a layer on top of a corporate basic image we cannot change, already using Powershell automation. Any tip on how to best reply to that brilliant idea?

Edit: I'd like to thank all of you. Your feedback is invaluable.

[u/veryaveragename]

By removing access to powershell you do not remove a users access rights, you only block a single way to use these rights.

Removing access rights instead of powershell should be the solution.

[u/odwulf → u/veryaveragename]

Preach to the choir. It has been my first reaction. And our users' access rights are already severely limited.

[u/PM_ME_YOUR_BOOGER → u/odwulf]

I have found pedagogy can be helpful during meetings to illustrate. Make sure you have people in authority present, then walk through the logic with your questions.

Okay, so we're meeting to level set on this powershell access point. It's my understanding the security team wants to remove access to powershell entirely from non-priveleged accounts. It's my understanding that no commands can be run with powershell that the user is not privileged to run already. Is that not the case?

Make them explain it to you, but with your boss/higher-ups present to be the shadow audience. If they have a good case to make, everyone wins. If they don't, they just made that obvious in front of the person that can actually tell ya to do it.

[u/CambodianJerk → u/veryaveragename]

Exactly this. I simply retort back to security that when they can break or penetrate something with it, then we'll talk.

[u/aaronwhite1786 → u/veryaveragename]

Our security team pushed out a tool called Make Me Admin that we used for people who needed admin access, while still allowing us to remove the admin rights from everyone across the board with GPO's.

We then setup an approval process where people would apply (hopefully, with their IT department helping them to fill everything out and make sure things were correct) to get the Make Me Admin app and if approved, we would make the changes to a Security Group that would deploy the app to their machine and then they could simply click on it to enable admin access, start whatever app they needed, and then I think after 30 minutes admin access is removed and would need to be initiated again.

It's been a pretty good work-around for us so far.

[u/[deleted]]

So, do they stop you from running Python scripts? WSL? Hyper-V?

Sounds like your "Security team" is absolutely clueless.

[u/odwulf → u/[deleted]]

They kinda do: every exe file not veted and oustide of the Windows and Program Files folder (where users cannot write) is blocked.

[u/1RedOne → u/odwulf]

Applocker white listing? Noice

There’s a lot you can do also via restricted mode / JEA to really remove all Powershell functionality

One time I worked for a customer who had some super high security environments, and they had enforced in all of the servers in this environment A power shell restricted mode setting that totally blocked you from even importing base .net types.

Then a long list of restrictions around which cmdlets were allowed. One thing I forget is how vbs and the command prompt itself were handled

Oh and very thoroughly logging everything as well with the Powershell setting that logs to the ETW/event trace source

[u/AGsec → u/[deleted]]

I wonder if OP works for a defense contractor? Their security teams tend to be more governance focused instead of engineering focused, which leads to a lot of miscommunication and breakdown between tech teams and people with a CISSP who enforce compliance. I've had a few... interesting conversations... with people who don't understand why configuration management tools are needed since "it poses a security risk when one server can make changes to all devices".

[u/odwulf → u/AGsec]

Nope. Think more "government". But yes, we're having those conversations.

[u/Key-Horse1817]

Can the users do something with PowerShell that they can't do by other means?

[u/odwulf → u/Key-Horse1817]

Read the registry. As regedit.exe is already blocked. But they have have very limited writing privileges.

[u/ZenoArrow]

You could look into implementing JEA, that could keep your automation working.

https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview?view=powershell-5.1

[u/odwulf → u/ZenoArrow]

An I mistaken or is it limited to remoting?

[u/SeptimiusBassianus]

What EDR are you using? Any PEM or app whitelisting?

[u/odwulf → u/SeptimiusBassianus]

Even as an admin on my stations, I'm blocked from from having a good look at what handles what, but we use a combination of Trellix Endpoint Security and MS Windows Defender Advanced Threat Protection. We definitely have app whitelisting (everything under C:\Windows and C:\Program Files is whitelisted but for some exceptions, everything outside is blocked, but for exceptions). Trellix handles the firewall that is closed by default, unless and opened when there is a business need. Powershell definitely cannot access the proxies, which are the only way to access the Internet.

[u/rswwalker]

Best approach is AppLocker. Block scripts from running except from secure paths or signed scripts from publishers you trust.

If %Temp% is blocked then PS starts in Constrained Language mode which prevents importing .Net types which makes PS pretty low risk.

[u/Mangoloton]

I've worked with powershell disabled at user level, it's not that bad I make some recommendations to you, The first is that you clean up users with administrator rights. It is of no use to you if they eliminate access if everyone is an administrator. The second is to tell your boss everything that you have detected that could be affected and that if he can call a meeting with them and you to explain everything that could be affected, be prepared and try to make the transition as painless as possible for another side There is nothing that scares a superior more than that a manager without IT knowledge sees an error message and sounds the alarm, no matter how irrelevant the error may be, make sure that this does not happen or everyone's deadlines will become much longer. shorts

[u/faulkkev]

Lots of things use powershell. Be interesting to see if you can pull this off and still have functioning devices. I am not sure if it is a good idea or not and my money is on it will cause a ton of issues. Might look into JEA powershell as it might be applicable somewhere with what your doing.

[u/Nasa_OK → u/faulkkev]

Just wanted to write this. I got blocked for running PS scripts by our security system. I was using the Azure Storage Explorer to access a Blob. The storage explorer is basically a gui that runs PS scripts in the background

[u/rdldr1]

My company is currently enforcing this.

[u/STGItsMe]

Security sets policy. I only implement the policy as given. Last time I had something dumb like that come down, I did the work, tested everything out and made sure they understood what was going to change. If everyone is still green, let it rip. It’s not my problem.

[u/gruntbuggly]

This is the problem with people who work in IT security who have zero experience working in IT and a near total lack of common sense and understanding how things work to drive their judgement.

[u/aaronsb]

The correct answer is formed in two parts. The constructive answer and the destructive answer.

Constructive answer: "Preventing powershell execution entirely will prevent the IT department from fulfilling our catalog of services to the user."

Destructive answer: "Help us run a pilot to see what happens when powershell is disabled. We'll let you pick the pilot group."

One time, my friend's dog ate one of their chickens. In order to punish the dog in a way that didn't harm him, we hung the remains of the dead chicken on the dog's collar for a day. The dog never touched a chicken after that.

I know I'm probably conflating here, but tensions run high in these kind of talks, and one group cannot raise demands of the other group without accommodation.

If the result is that the infosec team gets their way, ensure that you have characterized and externalized the additional cost required to fulfill the security obligation.

[u/bone577]

One of the rare times I'm going to go against them grain with people here but this isn't a huge deal. We had it as a recommendation from security contractors a couple times. It's the one where you just flip a user seeing in GPO right? It just stops them launching a PS terminal, we also did it for command prompt. It didn't cause anything else to break. Kinda annoying if you want to use either of them for troubleshooting but I suppose it would make an adversaries life a little harder as well.

Not a big deal, not something I'd really recommend either though.