Application security redux: It’s All about the Apps (Part 5)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In this article series, we got started in Part 1 with a broad overview of application security, some of the different types of application security issues, and coding defects, as well as types of app vulnerabilities. In Part 2, we started with a look at how to protect applications from tampering or access and also take a closer look at the special case of mobile applications. In Part 3, we discussed how you can block undesirable applications and restrict what users are able to do with the apps that you do allow them to use.

In Part 4, we started to explore Microsoft’s AppLocker, which was introduced in Windows 7 and Server 2008 R2 and grew out of the previous Software Restrictions Policies feature. This time, in Part 5, we’ll delve into the use of PowerShell to configure and manage AppLocker and then wrap up the discussion in Part 6 as we move on to the new ability to control apps in Windows 10 mobile devices via the CSP that was added to AppLocker in Windows 10.

PowerShell Cmdlets for AppLocker

IT pros today seem to be divided on the subject of Microsoft’s PowerShell. It’s one of those things that, in most cases, people either despise with a passion or think is the best thing since sliced bread – although there are also those who have proclaimed a love/hate relationship with it, as evidenced by this thread.

The command line interface has been with most of us since the beginning of our computing lives. It provides a text-based means of interacting with our computers and telling them what we want them to do. Scripting is something that many of us have found useful for automating various tasks. The defining characteristic of PowerShell is that it attempts to combine the best of both worlds and provide both a command line environment and a scripting language in one package. This is a source of great delight for its many fans and a source of frustration and confusion for its detractors.

But whatever you think about it, the fact is that Microsoft is pushing PowerShell more and more for configuration, management and automation of Windows’ components and server applications. If you’re not a CLI (command line interface) lover, it behooves you to develop a taste for working in the “dark space” because increasingly, the GUI (graphic user interface) is becoming more limited in functions as the advanced tasks require going to PowerShell.

This applies more to some features than others. AppLocker is not one of those that has gone “all in” with PowerShell – at least not yet. The AppLocker PowerShell cmdlets are intended to supplement rather than supplant the AppLocker interface that you access in the Microsoft Management Console Snap-in. Nonetheless, the command line can sometimes offer a faster way to get things done, and the available PowerShell cmdlets for AppLocker can be useful for quickly accomplishing various aspects of AppLocker configuration and administration.

Getting and Using the AppLocker Cmdlets

If you’re familiar with PowerShell, you know that not all cmdlets come “in the box” with PowerShell. PowerShell Modules were introduced in PowerShell v2 to extend its repertoire of cmdlets (Prior to v2, this was accomplished by means of snap-ins, which are still supported, but modules make extensibility easier). Depending on your version of Windows Server, it will come with a number of built-in modules. Those that aren’t included can be imported. In many cases the relevant module will be included with the applications that it’s used for and will be installed along with the application itself.

Note:
If you’re still using Windows Server 2008 R2/Windows 7, you can import the AppLocker cmdlets by typing the following at the PowerShell prompt:

C:\PS>Import-Module AppLocker

There are five AppLocker cmdlets (currently). New cmdlets can be added in the future. Here are the cmdlets and what you can do with each of them:

  • Get-AppLockerFileInformation – The purpose of this cmdlet is pretty self-evident from the name. You use it to obtain information such as the publisher info (for files that are digitally signed), hash info, and path info for AppLocker files. This may come from event logs or from a list of files. Parameters you can use include –Path, -FileType, -Recurse, -EventLog, -LogPath, -EventType and –Statistics. Using these cmdlets you can retrieve file info for all executables in a specified directory, or for a specific file by path, or for all audited events in the AppLocker event log, or get statistics for events in the logs. For syntax and examples, see this link.
  • Set-AppLockerPolicy – AppLocker policies, as we discussed in the previous installment in this series, consist of rules and rule collections and can be applied to a new or existing GPO. You can use this cmdlet to set a specific Group Policy Object to contain a specified AppLocker policy. Note that this will overwrite the current policy that GPO unless you use the Merge parameter, which will cause the rules in the specified policy to be combined with the rules in the existing policy in the GPO. It’s very important to use Merge if you want your new policy to be an addition to, rather than a replacement for the existing policy. Other parameter for this cmdlet include –XMLPolicy, which designates the path where the AppLocker policy (in .XML format) is saved; -PolicyObject, which specifies the object that contains the policy; -LDAP, which specifies the LDAP path of a GPO; -Confirm, which prompts before executing the command; and –WhatIf, which describes what would happen if you executed the command (without actually doing so). For syntax and examples, see this link.
  • Get-AppLockerPolicy – This cmdlet is simple to understand: it retrieves the AppLocker policy for a local GPO or a domain or the policy that is currently in effect on the computer. Parameters include –Local, which gets the policy from the local GPO; -Domain, which gets the policy from the GPO in the LDAP parameter; -Effective, which shows you the policy that’s in effect on the computer, which is the merger of the local and domain policies; -LDAP, which specifies the LDAP path of a unique GPO; and –XML, which you use if you want the policy output in an XML string. For syntax and examples, see this link.
  • New-AppLockerPolicy – Again, this cmdlet does what its name implies: it’s used to create a new AppLocker policy, using a list of file info to automatically generate rules that will be applied to a specific user or group of users. These rules can be based on the publisher, hash or path information. The parameters include –FileInformation, which contains that information; -RuleType, which specifies the type of rule(s) to create and you can create multiple rule types if you wish. That way you have backup rules that can be used when one type of information isn’t available; -RuleNamePrefix, which you can use to designate a prefix for each of the rules that is created; -User, which specifies the user or group to which the rules apply and can be formatted as DNS user name, UPN, SAM user name or SID; -Optimize, which groups similar rules together; -IgnoreMissingFileInformation, which lets the cmdlet know it should still run even if there’s missing info that prevents a rule from being created; and –XML (same as above). For syntax and examples, see this link.
  • Test-AppLockerPolicy – This cmdlet provides you with an easy way to test whether specified files will be allowed to execute for a specific user. It’s always a good idea to test your policies to ensure that they will have the intended effect, since multiple policies can result in unexpected behaviors. Parameters include –PolicyObject, which specifies the policy object that contains the AppLocker policy that you want to test; -XMLPolicy, which lets you enter the XML path to the AppLocker policy; -Path, by which you can designate the list of file paths to test, using regular expressions; -User, for defining the user or group name for which you want to test the policy; and –Filter, which allows you to display only a particular policy option decision such as Allowed, Denied, Allowed by Default or Denied by Default, rather than display all policy decisions as is the default behavior. For syntax and examples see this link.

When you put it all together, then, you can quickly create and test a new AppLocker policy right from the PowerShell interface. You use Get-AppLockerFileInformation and send the output to New-AppLockerPolicy, then use Set-AppLockerPolicy to apply the new policy you’ve created and use Get-AppLockerPolicy to verify that your policy was imported. Finally, you can test the policy with Test-AppLockerPolicy. Once you’ve mastered these five cmdlets, it can greatly simplify and speed up the process of working with AppLocker to control the applications that your users can run on their work computers.

Summary

In this, Part 5 of our Application Security Redux series, we provided a summary of the PowerShell cmdlets that Microsoft has made available for AppLocker, and next time in Part 6, we’ll wrap up the discussion on restricting what users can do with allowed applications as we touch on a new feature that has been added in Windows 10: the ability to control apps in Windows 10 mobile devices via the CSP. See you then.

If you would like to read the other parts in this article series please go to:

About The Author

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top