PowerShell Security is a topic on everybody’s mind. Most of all – ours.
As PowerShell has become more popular with Administrators, it has also become more popular for unauthorized administrators – also known as “Attackers”. In any operating system or platform, the power and efficiency you provide to authorized administrators is also available to unauthorized administrators. For example, Unix, Linux, and Mac all have dozens of powerful built in compilers, scripting languages, and debuggers. It’s a power user’s dream, but also a liability.
The PowerShell team has recognized this double-edged sword since the introduction of PowerShell in 2006. In the last 10 years, we’ve invested greatly in both securing and hardening PowerShell. In PowerShell version 5, we really cranked up the dials on making PowerShell security transparent – the results of which we describe in our post, “PowerShell ♥ the Blue Team“.
As part of this effort, we’ve also done a deep comparative analysis on security between available shells and scripting languages. Where are we weak? What security features do other shells or scripting languages offer that PowerShell could perhaps learn from?
We broke this evaluation into seven major categories:
- Event Logging – The engine logs audit events of important operational events.
- Transcription – The engine logs application inputs and outputs.
- Dynamic Evaluation Logging – The engine logs the content of all content evaluation, including those generated or composed at runtime.
- Code Integrity Policies – The engine allows enforcement of code integrity / application whitelisting policies, including user-authored documents / scripts.
- Antimalware Integration – The engine actively integrates with antimalware software to evaluate the safety of code generated at runtime.
- Local Sandboxing – The engine allows sandboxing of behavior for local and interactive use.
- Remote Sandboxing – The engine allows sandboxing of behavior when accessed remotely.
This is the result of our analysis. We would love any feedback you have – especially if you are aware of a feature or protection we missed. Misrepresenting any of this data does nobody any good.
Lee Holmes [MSFT]
Azure Management Security