7 Scripts and security

 

Let’s take a few minutes and talk about security. We covered this in the predecessor book (Learn PowerShell in a Month of Lunches, Fourth Edition, Manning, 2022), but we want to discuss this in depth. From our experiences in the field, the instant knee-jerk reaction is that PowerShell should be disabled on every desktop and server on the face of the planet because of how powerful and straightforward it is. Major corporations have a company-wide ban on using PowerShell for this very reason.

Viruses and malware are becoming increasingly sophisticated and harder and harder to detect. The security engineers for the top companies are good at identifying new attack vectors and helping fix the problems. Still, there are more bad guys out there with so much free time that they are finding vulnerabilities and attack vectors faster than they can be patched or fixed (this is why it’s essential to patch your systems!). The good news is that many bad actors use PowerShell as the attack vector. You’re probably wondering how in the world this is good news. Microsoft and a few trusted community members helped strengthen the security features built into PowerShell. Think of it as an in-depth defense program with multiple layers of security in place. PowerShell isn’t antimalware and isn’t intended to protect you should malware become present in your environment. Understanding PowerShell’s security goals is essential so that you don’t overestimate them.

7.1 Security is number one

7.2 Execution policy

7.2.1 Execution scope

7.2.2 Getting your policies

7.2.3 Setting an execution policy

7.3 PowerShell isn’t the default application

7.4 Running scripts

7.5 Recommendations

Summary