Chapter 7. Scripts and security

 

If you’ve been in IT for a while, you may recall the days of rampant macro-based malware that took advantage of the scripting elements in Microsoft Office. When PowerShell was first mentioned, many people were concerned about the potential for abuse. Microsoft was cognizant of this fear and took steps to mitigate potential problems. After all, a malicious PowerShell script can do a lot of damage with a minimal amount of code. PowerShell scripting by itself isn’t a bad thing, so they didn’t want to make it completely unavailable. Instead, Microsoft tried to strike a balance.

But—and we can’t stress this strongly enough—PowerShell’s security features are intended to be part of a defense in depth program, where you have multiple layers of security in place. PowerShell isn’t anti-malware, and it isn’t intended to absolutely protect you, should malware become present in your environment. It’s important to understand what PowerShell’s security goals are, so that you don’t overestimate them.

7.1. PowerShell’s script security goal

7.2. Execution policy

7.3. PowerShell isn’t the default application

7.4. Running scripts

7.5. Recommendations

7.6. Summary