Powershell Studio 2019 - Audit Logging

Use this forum to ask questions after your subscription maintenance expires or before you buy. Need information on licensing or pricing? Questions about a trial version? This is the right place for you. No scripting questions, please.
Forum rules
DO NOT POST SUBSCRIPTION NUMBERS, LICENSE KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
User avatar
priara
Posts: 4
Joined: Wed May 11, 2016 10:18 am

Powershell Studio 2019 - Audit Logging

Post by priara » Mon Apr 08, 2019 4:00 pm

To help you better we need some information from you.

*** Please fill in the fields below if you are currently using a Trial Version of the Product. If you leave fields empty or specify 'latest' rather than the actual version your answer will be delayed as we will be forced to ask you for this information. ***

Product, version and build:
32 or 64 bit version of product: 64bit
Operating system: Windows 10
32 or 64 bit OS: 64 bit

*** Please add details and screenshots as needed below. ***

DO NOT POST SUBSCRIPTIONS, KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM

Hi does this tool provide audit logging? We have some teams who are bringing up some concerns and this was one of them.

For example, I write a PS script, turn it into an executable file and pass this off to our tier 1 support group. Is there audit logging that can be turned on to tell us who ran the .exe file? I’m not well versed with your product, so any assistance would be helpful.

Thank you

User avatar
Alexander Riedel
Posts: 7060
Joined: Tue May 29, 2007 4:43 pm

Re: Powershell Studio 2019 - Audit Logging

Post by Alexander Riedel » Mon Apr 08, 2019 5:11 pm

PowerShell provides script block logging (https://docs.microsoft.com/en-us/powers ... dit_script) which still applies even if
the code is packaged as an executable file.
We do provide the option to not run if this is enabled or turn it off during code execution (admin privileges required) if you decide to do that.
This is determined at packaging time.
So there is no *extra* mechanism we provide, since PowerShell already provides you with plenty of logging ability if you need that.
It is however also pretty easy to write to the Windows event log from your own code if you decide that works better for you.
https://docs.microsoft.com/en-us/powers ... rshell-5.1
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
priara
Posts: 4
Joined: Wed May 11, 2016 10:18 am

Re: Powershell Studio 2019 - Audit Logging

Post by priara » Tue Apr 09, 2019 7:58 am

Thank you Alex. We are getting some push back from our Dev team. Do you have any responses to their concerns below? I'd like to be able to purchase this product, but my peers believe that they are bringing up valid concerns and unfortunately I'm not well versed with this product (since I've only been using the trial version and my ps coding is limited at best).

PowerShell can be written with Intellisense and debugging capabilities in VS Code (free) and converted to EXE using the PS2EXE-GUI tool from Microsoft (free)
As a matter of opinion, “executable-izing” powershell scripts seems like a profoundly bad idea, let alone marrying that idea to a tool that costs money. Doing this obfuscates the code-base behind a paid license…

PowerShell scripts should not be “packaged” into executables -in general- as it defeats some of the strengths of PowerShell. Namely; clarity of purpose, and maintainability.
Putting an executable wrapper on PS scripts means dealing with things like incompatible PS versions later on and serves only as an obfuscation tactic if one of the purposes behind the wrapper is to “hide” sensitive things that may be housed in the script. Security through obscurity is not security at all…

As an example: .NET applications can do things like call PowerShell scripts so, it would be possible for the systems team to still handle all of their own scripting and we would have a TSS/USST-facing internal-only web application which calls those scripts in an authenticated, loggable, fashion.


Any response to their concerns that would support purchasing of this product would be helpful.

Thank you again,
Priscilla

User avatar
Alexander Riedel
Posts: 7060
Joined: Tue May 29, 2007 4:43 pm

Re: Powershell Studio 2019 - Audit Logging

Post by Alexander Riedel » Tue Apr 09, 2019 9:05 am

Well, it is true that you can write PowerShell with Notepad and debug in the command line shell. It is a question of what works best for you.

As for packaging code as an executable being a bad idea, I don't know, that is of course defined by your internal policies. I humbly submit that because a variety of these tools exist, there obviously is a need for them.
As for PS2EXE-GUI, I had a quick peek: "Unfortunately Ingo seems to have stopped working on his script so I overworked his script with some error fixes, improvements and output support for non-console WinForms scripts (parameter -noConsole to ps2exe.ps1)." So you have to ask yourself, do you trust your business needs to 'a guy' (PS2EXE was not created by Microsoft) who simply may stop being interested in the tool that you use or a company that has been in this business for over twenty years. That is your decision of course.
I am also not sure how packaging PowerShell code with our packager would 'marry' your code to our tool? We charge no runtime fees and it is a means of publishing the product, not a means of storing your code. Of course we strongly encourage you to store your code safely, preferably in a version control system, so that you do *not* create any dependency. That is just standard procedure, one would assume.

Different entities have different reasons for packaging code, you must decide which one applies to you. I am not sure how packaging defeats any of PowerShell strengths, you are still in possession of the code, so the clarity and maintainability remains. That would mean any compiler, .NET or otherwise would do that too, which simply is not true. Some of our customers chose to package PowerShell code to keep unskilled users from attempting to fix things they should not touch. Having a signed and sealed exe erects an additional hurdle to end-users modifying code and possibly causing damage. That is just one reason though and brings us to the security question....

Of course packaging code into an executable does not mean you are now free to put sensitive information in your code. You should never do that. Nor does it provide absolute security against anyone reading your code.There is no such thing as absolute security. "Security through obscurity is not security at all…" That is a rehash of one of the Microsoft PowerShell Team members speaking at a conference.
What it should say is "Security through obscurity alone is insufficient security." Security is always like an onion. More than one layer is required and you decide how many you and your organization needs.
If security is your concern, you should probably hire a dedicated IT security expert or consult with one and not only listen to presentations at a conference. I hope you already do that. It is a complicated and multi-layered subject (pun intended) and having a professional assist in this matter would sure help.

My favorite analogy on this subject is as follows: Not leaving your valuable visible inside your car and locking your car doors is no measurable defense against a professional car thief and a tow truck.
Common sense though and all professional advice dictates it is a good idea though and everyone does it (mostly). Ask your "no security through obscurity" folks if they then leave their cars unlocked and their laptops in the passenger seat at Walmart, since it doesn't matter anyway.

It appears to me that your Dev team simply wants to use these tools as they are from Microsoft and it is what they already use. I would like to point out that there is absolutely no reason for this type of exclusivity seemingly portrayed by your team. Any developer, PowerShell or otherwise, should always be versed in multiple tools and languages and any attempt to create a 'pure', singular provider environment creates the dependency your dev team seems to advise against.
Sometimes Microsoft tools have a tendency of disappearing into the fog of time as the teams move on to newer and greener pastures. :D I recall having this very same conversation a few years ago about the ISE, since "that is all what one needs and it is free". It is now no longer developed or maintained by Microsoft as far as I know.

Ultimately, not knowing your position and who decides what in your company, I would advise all of you to sit together and discuss what is best for your company now and in the future, rather than arguing about solid and absolute positions. Things move and develop and having multiple tools and skills with the inherent flexibility it provides, seems to deliver a better outlook on adapting to future business needs.

As always, happy to help and I hope this provides you with some talking points.
Alexander Riedel
SAPIEN Technologies, Inc.

User avatar
priara
Posts: 4
Joined: Wed May 11, 2016 10:18 am

Re: Powershell Studio 2019 - Audit Logging

Post by priara » Tue Apr 09, 2019 10:30 am

Thank you Alexander for all your thoughts! Very much appreciated and will defintely open discussion for our team.

User avatar
priara
Posts: 4
Joined: Wed May 11, 2016 10:18 am

Re: Powershell Studio 2019 - Audit Logging

Post by priara » Tue Apr 09, 2019 1:20 pm

Hopefully one last question... is the software compiling powershell into a native executable or is it just wrapping powershell with an executable layer?

User avatar
Alexander Riedel
Posts: 7060
Joined: Tue May 29, 2007 4:43 pm

Re: Powershell Studio 2019 - Audit Logging

Post by Alexander Riedel » Tue Apr 09, 2019 2:19 pm

It is not a compiler. There is no PowerShell compiler.
Depending on host selection, the most common one is to package the script in a custom host which provides additional functionality, (Windows host, service, tray application, etc).
There are options that use temporary files, but that is not something we generally recommend.
Here are the options that we provide for that. Please keep in mind that this does not include the MSI builder options.
Packager 1.png
Packager 1.png (62.19 KiB) Viewed 12815 times
Packager 2.png
Packager 2.png (32.92 KiB) Viewed 12815 times
Packager 3.png
Packager 3.png (40.5 KiB) Viewed 12815 times
Packager 4.png
Packager 4.png (22.96 KiB) Viewed 12815 times
Packager 5.png
Packager 5.png (17.9 KiB) Viewed 12815 times
Alexander Riedel
SAPIEN Technologies, Inc.