Scaling AppLocker - Managing it AFTER Deployment!

When working on limiting outbound access to the internet by application with Windows Firewall with Advanced Security I kept running into a key shortcoming - introducing a new or previously unknown application to the system allowed bypasses to firewall rules when using a blocklist configuration. A pre-defined allow configuration of outbound traffic with WFwAS is difficult or nearly impossible to scale, so it wasn't going to solve the problem by itself. WFwAS can do a great job of limiting web access for pre-defined applications in common locations, but it is difficult to use it when there are new applications introduced into folders with different or random path names on thousands of machines. The lack of wildcards or user variables in the path of an application in a rule means that many applications that use the internet could not be managed in a practical manner for more than a small number of machines.

This is one area that an application control policy can help quite a bit. An application control policy can limit newly introduced applications to only those that are trusted (more or less) to behave or have limited abilities to interact with the web programmatically, helping mitigate some of the gaps left by WFwAS. The best bet for a strong security posture on Windows workstations is to use Windows 10 with all of the great mitigations that come with it. For example, Device Guard can be deployed as a very effective deterrent to malware, and many people who are much more knowledgeable than me have discussed it in depth. But what if Device Guard isn't available or isn't enough? There is still a strong case for using AppLocker in many environments, either alone (not as good as Device Guard but better than nothing) or as a more granular supplement to Device Guard.

There is quite a bit of documentation from Microsoft, as well as help on several blogs, with information on how to create an initial AppLocker policy. If you are looking for a place to start, here is a great reference resource; there are many others out there: https://docs.microsoft.com/en-us/windows/device-security/applocker/applocker-overview

A lot of the documentation and blogs discuss creation of an AppLocker policy using a gold image and then pushing it out in a manner that enforces this gold image. It is a good practice and definitely the way to get the most benefit from AppLocker...

...but what about deploying it to a large number of already existing machines that were built over a long period of time with different images of various metallurgic constitutions? What if AppLocker has to be deployed (maybe quickly) into an environment that already has accumulated years of bad habits and many applications that aren't even remotely accounted for by the gold image?

There are a few things that can help make this happen.

1. Have a clear plan on what to accomplish with AppLocker (see previous link to AppLocker Overview from Microsoft)
2. Have a method of centralizing and analyzing AppLocker audit logs, such as Windows Event Forwarding (WEF). https://social.technet.microsoft.com/wiki/contents/articles/33895.windows-event-forwarding.aspx
3. Create a candidate policy based off of a gold image and best practice recommendations.
4. Test the candidate policy against a representative group in audit mode.
5. Adjust the policy as necessary using audit logs to inform of blocked files or applications.
6. Apply the policy in an audit configuration to the whole organization.
7. Adjust the policy as necessary based off of the audit logs.
8. Train IT staff and end users on what to expect when the policy is enforced.
9. When auditing and training is at an acceptable level, enforce the policy.
10. Continue to adjust policy as needed when something is blocked that should be allowed using enforcement logs.
11. Continue training.

Sounds pretty straightforward, right? But when I tried this I kept having problems on the steps requiring that the policy be adjusted. When I initially rolled it out I knew of two ways to create an exception to adjust the policy.

1. Obtain a copy of the application installer and install it on a test machine. Collect all related installer, exe, script, and/or DLL files and use the GPO editor or PowerShell to create new rules.
2. Copy installer, exe, script, and/or DLL files from a production machine that already has the application installed and use the GPO editor or PowerShell to create new rules.

This worked well when going through the initial deployment, but as the deployment moved from a few machines to a few hundred to thousands these two methods of updating policies didn't scale. The biggest issue was with application installations or updates that executed files or scripts from a temporary location (which would be blocked) and then removed the files from that temporary location when the installation didn't complete. Many of these were triggered by automated update processes that were difficult or time consuming to manually trigger on a test machine. By the time a notification was generated and someone was able to investigate on a production machine the file was already deleted by the installer. Even without those problems, the sheer volume of blocks and time it took to retrieve the files or install them on a test machine to create rules made it difficult to deploy to the entire organization.

In all of the research I did I couldn't find anything that indicated how to solve this problem. All of the guides I had read talked about what to do once I had a local copy of a file, but all I had was a log entry indicating that something had been blocked. I didn't have access to the file, or it took too long to get it, or there were too many.

After a fair amount of researching and frustration I finally found this gem in the Get-AppLockerFileInformation cmdlet documentation:

"The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields."

 source: https://technet.microsoft.com/en-us/library/ee460961.aspx, emphasis added

The log entry turned out to be the key to solving the problem - and it was staring me in the face the whole time! If I could retrieve the file information from the event log, I could then pipe it into the New-AppLockerPolicy cmdlet and create rules based off of the logs that were already being centralized. This allowed policy modifications for files even if I no longer had access to the file - as long as I had the audit or prevention log event - which meant it could much more easily scale to a full deployment.

Here is a link to some example snippets of code: https://github.com/limpidweb/applocker/blob/master/applocker_ps_examples-1

These can be used as part of a much larger script to help automate some of the more tedious tasks in making AppLocker policy changes, such as version control, partial match searching, policy backups, change control, etc.

Hope this helps! Now to start planning a new post...

Until then, work hard and spend time with your family.
Branden
@limpidweb