Have you been afraid to implement PowerShell in your environment because of security fears? Or, are you unable to use PowerShell due to security concerns expressed by others in your organization?
The reality of PowerShell security doesn’t always match the perception—which at times can be irrational. When compared to other scripting languages, PowerShell is actually more secure by default.
First generation: batch files
Let’s first examine the ancestor of all scripting in the current Windows IT world: batch files. Batch files have been around since the DOS era of the mid-1980s and many IT admins still use them today. They are treated as executable programs. You can double-click to run them. They can be executed from the current working directory with no path qualifier. And there is no built-in provision for digital signing.
As for the power of batch files, you can use them to run any command-line tool, executable or other batch files. All of these executable programs will run with the same privileges as the command prompt itself.
Second generation: VBscript
The second iteration of scripting in a Windows IT environment was VBscript. These scripts began in the late 1990s as more of a programmer-oriented tool for managing Windows and application automation. VBscript quickly grew into a powerful IT management tool in Windows. VBscripts are also treated as executable programs—they can be double-clicked to run them. They can be executed from the current folder without a path qualifier. And, they do not have an inherent digital signing option. Also, much like batch files, VBscripts will run with the same privileges as the command prompt that launched them or the user who double-clicked them.
Third generation: PowerShell
The third and newest generation of scripting for Windows is PowerShell. Introduced in 2008 with Windows Vista and Server 2008 R1, PowerShell opened the door to a whole new era in command-line tools and scripting for Windows administrators.
PowerShell doesn’t necessarily allow you to do many things that you could not do before using a combination of batch files and VBscripts. It just makes it far easier for you to do those same things. PowerShell designers went with a “secure-by-default” approach. PowerShell scripts are NOT considered executable programs. You CANNOT double-click to run them. You must ALWAYS specify a full or relative path to run them. There is a provision for digital signing.
Much like batch files and VBscripts, PowerShell scripts will run in the same context as the PowerShell prompt that they are run from. Finally, by default, PowerShell scripts are not allowed to run at all on a Windows Client Operating system and Windows Servers up to Server 2012 R1.
Four levels of Powershell’s execution policy
To run PowerShell scripts successfully, the PowerShell execution policy on a machine must be set to an appropriate level:
• Restricted
• AllSigned
• RemoteSigned
• Urestricted and Bypass
The default for Windows Server 2012 R2 and Server 2016 is RemoteSigned, while all other operating systems are set to Restricted, which means that scripts will not run. RemoteSigned prohibits running untrusted (unsigned) scripts that have been downloaded from an outside source. If a script has been written and saved from a machine in your domain, it will be trusted.
The AllSigned policy will prohibit any script that does not have a trusted signature from running. This is potentially the most secure level, but requires the most administrative overhead since every script will have to be signed any time a change is made to the script.
The Unrestricted and Bypass modes will not require signatures on scripts that you would like to run. This is a potentially dangerous mode and should be avoided in most production environments.
The execution policy level can be set either using the Set-ExecutionPolicy command or by using Group Policy settings to affect a large number of machines.
Other PowerShell security features
You can launch the PowerShell prompt as a lower-level user, then run individual commands or scripts as higher-privileged accounts. It’s essentially a built-in run-as capability.
For an even more granular administrative approach, you can take advantage of “Just in Time, Just Enough Administration” (JIT/JEA). This process allows administrators to limit what CommandLets, Functions and even Parameters are allowed to be used by a user or a group.
PowerShell also has auditing features available that can track what commands are run. By enabling Transcripts through Group Policy, all commands and results can be captured to a text-based log file. In addition, PowerShell will log severe errors and access violations to the standard Event Log.
Don’t let security concerns get in the way of your PowerShell implementation
You cannot avoid PowerShell any longer just because there are security concerns. PowerShell is becoming more deeply embedded and intertwined with the Windows operating system, Microsoft applications and services, and Microsoft Azure. The good news is that PowerShell is more secure by default than previous scripting environments due to the execution policy and signing requirements of PowerShell scripts.
There will certainly be vulnerabilities exposed and taken advantage of by the many ne’er-do-wells of the world in PowerShell’s lifetime. We as IT administrators must therefore embrace and understand the built-in security apparatus of PowerShell in order to keep ourselves protected, while at the same time leveraging one of the most important IT automation tools at our disposal in this new Windows scripting era.
Related courses
• Automating Administration with Windows PowerShell
• Advanced Automated Administration with Windows PowerShell
Subscribe
Never miss another article. Sign up for our newsletter.
The post How Secure is PowerShell? appeared first on Global Knowledge Blog.