Something you might know about me is that I think Powershell is just about the best thing to ever happen to Windows Server. And even if you don't agree... well, you don't really have a choice because there are already tasks that must be done in Powershell and there is no GUI alternative, and that trend will only continue.
Powershell will become part of your life if you plan on continuing to work with Windows Server. PS is very powerful, and it makes many tasks much faster and more automatable. But with that power, comes the side-effect that PS also makes many nefarious activities faster and easier as well. An attacker has many more tools and methods (no pun intended) available to him or her if they have unrestricted access to Powershell on your server. You could restrict all Powershell usage on your servers, but that means losing an extremely valuable tool for administrators. There must be a compromise...
One effective way to mitigate this risk is to digitally sign your Powershell scripts with a certificate. By setting the execution policy of PS scripts on your servers to AllSigned, Powershell will not run scripts unless it can successfully validate the signature that is in the script. That also means that the script cannot be modified after being signed, as the signature will no longer match the modified script. This is much better than the RemoteSigned execution policy, which only mandates that scripts downloaded through an Attachment Execution Service-compliant application need to be signed, which is extremely easy to bypass. (e.g. just clear the alternate NTFS data stream.)
Good news is that code signing, especially in Powershell, is actually pretty easy to do.
First, as an administrator of an Active Directory domain with an Enterprise Certificate Authority, you need to make a code signing certificate for your users to use. On your CA, open the Certificate Templates MMC snap-in. You can also get there in the CA snap-in by right-clicking on Certificate Templates and choosing Manage.
Duplicate the Code Signing template, so that you don't modify the original template. Configure all the properties of this template as desired, including allowing Authenticated Users (or whichever users you desire) the ability to enroll in your new certificate template.
I very creatively named my template "Code Signing Template v1." Now go back to your Certificate Authority snap-in, and choose New -> Certificate Template to Issue. Choose your new code signing cert.
Keep in mind that this information is being uploaded to Active Directory, so make sure AD replication has taken effect before wondering why the certificate isn't already available at your location as soon as you issue it.
Now, on your workstation, where you are logged in as a regular user, you want to enroll for one of those new code signing certs. You could do this in the Certificates MMC snap-in:
But, since we like to save time, let's go ahead and instead submit the certificate request via Powershell:
You have to take the spaces out of the certificate template name. But you'll know the certificate request was successful if the status is Issued. You'll also notice that the public key of your new code signing cert is now published publicly in your Active Directory user account. This is so everyone else in the domain can access your public key so that they can validate that you did, in fact, sign that exact Powershell script, so we can figure that it's safe to run.
Signing a Powershell script with your new code signing certificate is simple:
Just Set-AuthenticodeSignature $script $certificate, and it's signed. The signature is actually a block of cipher-text that appears at the bottom of your newly signed script.
Your identity is also encoded in those comments, but is not encrypted. So Powershell can tell who signed the script right off the bat. Then, Powershell retrieves the public key of that identity (from AD for example.) The script was signed using your private key, which you do not share, and can only be decrypted with your public key, which you do share. So if Powersell is able to decode the signature with your public key, it can be reasonably assured that it was signed by you. If the script changes by even a single character, then that hashed with your private key would result in an entirely different signature, therefore modification of the script means Powershell will not run it unless it is re-signed by another authorized user, and we would be able to tell who that was.
Alright, that's enough out of me. Hopefully I've been able to at least pique your interest in the potential security benefits of code signing!
(And sorry for all the cheesy pixellation.)