PowerShell Does Not
Have To Be Installed Everywhere
A common mistake many organizations make is to leave PowerShell running on all workstations in the network. That’s unnecessary and increases an organization’s security risk. PowerShell is a powerful tool that can be used to manage configuration tasks across the network, but it needs to be installed only on the machines launching the PowerShell script—not on the machines being managed.
Some administrators do write scripts that call PowerShell on each individual box. But if PowerShell doesn’t have to be on a system, why increase the security risk? Even if it means rewriting PowerShell scripts, the security tradeoffs make it worthwhile.
There are three approaches many organizations take to limiting PowerShell usage. All of them can be accomplished using Group Policy Objects (GPOs):
1. Removing PowerShell from all machines except those needing it
2. Limiting PowerShell usage to administrators only
3. Hardening PowerShell security settings and restrictions via GPOs
The problem with the first option is that the machines that need to run PowerShell may change frequently. The problem with the second option is that ransomware groups strive to gain administrative access, allowing them to bypass the protection.
This is one of those “why not both” situations. To provide the most protection, an organization should remove PowerShell from machines where it isn’t necessary and limit execution of PowerShell to administrators. The security team should work with the Windows team to remove PowerShell in a way that doesn’t disrupt workflow and to create a painless way to enable PowerShell on new machines as needs change.
No. 3 should be done in all cases, no matter which approach of the first two that you take. Look at your current settings and see if they specifically address the ransomware concerns raised here—if they don't, take immediate action to correct the situation.