![]() ![]() The reason for this of course is that we have a target which is always available to a device with an internet connection, and secondly that we can then build workbooks in order to visualise the data. In order to modernise the log collection process, I turned to Log Analytics as a target. Data Collection – Log Analytics & Endpoint Analytics For instance, if a user is offsite for several days, and we use a centralised CSV to collect the information, when they connect we are only going to get the values from the log at that time, potentially missing an issue that impacted them. This report append process is vital in the success for your AppLocker rollout, as with so many applications being audited, the event log can rollover quicker than is required to export the details. This means catering for machines that are offsite for instance, in which case if we were using a centralised CSV and appending details to it, we need the machine to be connected to the VPN, and this isn’t always the case. The main issue with exporting all of this valuable detail to CSV files, either shared, or local, is the fact we need a schedule to run and a harvesting mechanism which is consistent. Running the above command results in something like the following on your client Get-AppLockerFileInformation -EventType Audited -EventLog -Statistics Through PowerShell we can query AppLocker events, using the following command More information on AppLocker can be found on an earlier blog post here – Managing Windows 10 with Microsoft Intune – Part 2 – MSEndpointMgr CSV Exports – The Collection IssueĬollecting these logs can pose a challenge, and historically I have relied on PowerShell scripts and CSV exports in order to demonstrate the results to clients. Here you can see a screenshot showing the EXE log where event 8003 indicates that a file would have been blocked These can be viewed in the following location Īpplication s and Service Logs\Microsoft\Windows\AppLocker This is where I typically recommend that you run AppLocker rules in “Audit” mode for a period of 30 days, defining the enforcement mode as “Audit only” in each of the four policies ĭuring the auditing phase time event logs are created with detailed information on the files being run and most important of all, whether they would have been blocked by enforcement of the policy. The major issue for a lot of companies which want to push out AppLocker, is how to I determine that all of my clients are not going to be impacted by enforcing policies? If you don’t do this correctly you could end up in large numbers of users being unable to launch applications, so you need to proceed with caution. With the policy assigned, when an end user attempts to launch a non-approved application, they receive a blocked file dialogue box similar to this Implementing AppLocker ![]() ![]() The purpose of this primarily is a security concern, where a primary focus is those applications which can be run / installed under normal user context.Īdministrators usually thus start with a policy which whitelists default applications or they capture rules from a client device which contains all of the common applications An example of both is pictured below What Is AppLocker?ĪppLocker is a feature of Windows which allows administrators to control which applications can be launched on a device. In my second post of a series of posts on how we can utilise Log Analytics for automation and reporting, focusing on managing AppLocker in a more holistic manner. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |