PowerShell: No More Dangerous Than Anything Else

Whenever I'm speaking to a group of PowerShell newcomers, two questions ALWAYS come up:

1. Isn't PowerShell dangerous? 

2. Is there a way to log everything an admin does in PowerShell?

The answer to both questions is "no," and that isn't a problem. Here's why.

First, PowerShell neither adds nor subtracts anything to your environment's security. It's just a tool. Can a Domain Admin use PowerShell to delete every object int he directory? Yes, but he or she could also do that with several other tools, including Active Directory Users & Computers. "Ah," you say, "but in ADUC, with newer versions of Windows, OUs are protected against accidental deletion!" And PowerShell will respect that, because it's a security attribute in the directory itself - so PowerShell is just as protected against accidental deletion. 

"But PowerShell doesn't ask 'are you sure?' for everything!" Not always. With some major operations that have a high "impact level," PowerShell will confirm the operation - try running Set-ExecutionPolicy or Enable-PSRemoting and you'll see that happen. But in most cases, no - PowerShell assumes that you KNOW WHAT YOU ARE DOING, and lets you do it. If you have admins who can't be trusted to work without "are you sure?" prompts, you should seriously evaluate why you've given them so much power. If the difference between "safe" and "dangerous" is the "Yes" button on a confirmation dialog, then I'd hate to work in your environment. And I'd make backups every ten minutes. Seriously.

Could a USER use PowerShell to delete everything on their C: drive? Probably not, because normal users don't have sufficient permissions to key folders like C:Windows. Could a user delete all of their documents in PowerShell? Sure. But they could do so more easily in Explorer.

That's the thing: Doing dangerous stuff in a GUI is almost ALWAYS easier in a GUI! Right-click, delete. Ctrl+A, delete, "Y" to confirm. In PowerShell you have to type a whole command. I've deleted files accidentally in Explorer before, because it's just a button click. It's hard to "accidentally" type a really massive command in PowerShell.

So, bottom line: Anything you can do with PowerShell, you can do in at least 2 other ways, including GUIs. Therefore, PowerShell is no more dangerous than the rest of Windows. 

Next up is auditing. No, PowerShell doesn't provide an enforced way of logging everything an admin does. Yes, you could run Start-Transcript, but there's no way to ensure that will always run. Even in a profile script. Not every PowerShell host supports profiles (most script editors make loading profiles optional), and when you remote into a machine, profiles don't run. 

But you know what? The GUI tools you've used for years don't log everything, either. "Ah, wait," a student will say, "the GUI does audit things like user creation or file deletion, if we've set up auditing." No, the GUI does not. That auditing is conducted by the underlying operating system - and that auditing will still happen if you perform those same actions in PowerShell. Once again, PowerShell gives you the exact same level of security as the GUI, because the security is actually implemented "underneath" both the GUI and PowerShell.

PowerShell - or, I should say, some PowerShell extensions - can sometimes let you make mistakes that a GUI would protect you from. For example, when I start showing classes the Microsoft ActiveDirectory module, I'll ask if it's possible to create a user account that has a blank samAccountName attribute. Invariably, the class says you can't do that, because they're used to the ADUC console not allowing it. In fact, you CAN create an account with a blank samAccountName. Once. That's because the samAccountName must be unique in the domain, and the first blank one is unique. Try it again and it'll fail. This is the difference between logic that's applied by the technology (Active Directory) and the console (ADUC). It's actually a sign of a poor design: The user interface, whether it's PowerShell or a GUI, shouldn't implement that kind of "business logic." Instead, it should be implemented by the back-end technology, so that the logic is consistent regardless of the interface. This samAccountName example points to a poor design in Active Directory, not in PowerShell or the GUI. 

By and large, though, PowerShell is no different, no more or less dangerous, and no more or less audible than its GUI counterparts.