New Microsoft Sentinel Workbook: Windows Firewall via AMA

I have authored a workbook for Microsoft Sentinel that has been accepted into the official Microsoft Sentinel Content Hub and GitHub repository. This is an update to an existing community-sourced workbook for Windows Firewall logs that worked for MMA-based (Microsoft Monitoring Agent) Log Analytics agents but does not work for Azure Monitor Agent (AMA) log collection.

What changed and why a workbook was needed

Since the MMA official deprecation last month (August 2024), organizations must migrate from MMA to AMA-based log collection to preserve security functionality. While Microsoft has released an AMA-based Windows Firewall connector, they did not also release a companion workbook.

Fundamentally, with the MMA, Windows Firewall data was saved to the Microsoft Sentinel-connected Log Analytics workspace in the WindowsFirewall table. However, with the AMA, Windows Firewall data is saved to the ASimNetworkSessionLogs table with the EventProduct value “Windows Firewall”. Analytic and hunting rules as well as workbooks that worked under the MMA don’t work with the AMA because the underlying table name and format changed.

The Windows Firewall via AMA workbook allows organizations to continue to have a decision and display visualization of Windows Firewall data after migration to the AMA. This article explains why the ASIM model is a good idea, shows ASIM in action with Windows Firewall via AMA logs, and walks you though installing and using the Windows Firewall via AMA connector and the new Windows Firewall via AMA workbook.

It’s all about the ASIM

Microsoft Sentinel data connectors underwent a major transformation in the last 18 months since the introduction of the Advanced Security Information Model (ASIM). This includes Windows Firewall logs which, with the advent of the AMA, are dramatically changed from the MMA-era and now conform to the ASIM model.

Put simply, ASIM is a standardized way of collecting and storing security-relevant log data from diverse types of hardware, software, and security services. Logging data that conforms to ASIM schema is also known as normalized, as seen on the lower left side of Figure 1.

A diagram of a software company

Description automatically generated with medium confidence

Figure 1 – Normalized data (lower left) does not require any source-specific parsers. (Source: Microsoft)

Inside the Azure Log Analytics database where security data processed by Microsoft Sentinel is stored, records are divided up into tables according to where the data came from. Prior to ASIM, logs from devices and computers were either written to their own application-specific log tables, to the default ‘syslog’ table, to the common event format (CEF) table, or to custom log (CL) tables. All of these pre-ASIM connectors required their own, unique parsers to sift out the relevant data (the center and lower right portions of Figure 1).

ASIM in action

Imagine that a column in one table might be named “Computer” and a similar column in other tables might be named “Hostname”, “DeviceName” or “ComputerName”—and they all represent the same entity. Easily performing effective and high-value entity searches across tables required either ingestion-time or query-time parsing. With more and more data source types coming online in the Sentinel community, this approach became unwieldy.

ASIM provides a seamless experience for handling various sources in uniform, normalized views, by providing the benefits of (1) Cross source detection across systems, including Okta, AWS, Azure and many more; and (2) Source agnostic content, that is, the coverage of both built-in and custom content using ASIM automatically expands to any source that supports ASIM, even if the source was added after the content was created.

Network Session Essentials solution includes Windows Firewall via AMA

Microsoft’s Network Session Essentials solution provides a set of content, specific to network security scenarios, that supports over 15 network products and services including Windows Firewall via AMA, Zscaler, AWS, Cisco Meraki, Fortinet FortiGate and more. This means the same content from the Network Session Essentials solution can work with multiple network products deployed in your organization hence delivering more value to protect your network with less. What do all these solutions have in common? They track network sessions!

Consider the screenshot in Figure 2 of the Network Session Essentials solution in the Microsoft Sentinel Content Hub. All the listed solutions on the left side share the same Content types on the right side. For example, the seven (7) analytic rules listed in the center section (Content name) work with all the hardware and software solutions sending their network session logs to Microsoft Sentinel. Before ASIM, many dozens of analytic rules would be required for similar coverage.

A screenshot of a computer

Description automatically generated

Figure 2 – ASIM consolidates Analytics rules, Hunting rules, Playbooks, and Workbooks for cross-platform network session data.

Install the Network Session Essentials solution playbook

Notice in Figure 2 there is a playbook, SummarizeData_NSE, which is specially crafted to support the workbook in the solution: Network Session Essentials, seen in Figure 3. This workbook view displays the power of the ASIM model merging network session data from four different data sources in the same ‘pane of glass’ (VMInsights, Fortinet, Windows Firewall via AMA, and Defender for Endpoint).

A screenshot of a computer

Description automatically generated

Figure 3 – The Network Session Essentials workbook consolidates dissimilar data sources.

The Network Session Essentials solution can handle data of very high events per second (EPS), and when there is content that is using such high EPS, there can be some performance impact that can cause slow loading of workbooks or query results. To overcome this, Microsoft created the SummarizeData_NSE playbook that summarizes the source logs and stores the data in the NetworkCustomAnalytics_sourceInfo_CL table. That custom table is where the visualizations of the Network Session Essentials workbook come from.

Tip: Install the Network Session Essentials playbook and workbook in addition to installing the Windows Firewall via AMA connector and workbook. Use the workbook to have awareness of network session activity across all devices and services that include network session data.

Windows Firewall logs security value

The built-in Windows Firewall is a great security feature for the Windows client and server operating systems. And while not every organization actively uses Window Firewall (they may have a third-party security solution deployed instead), the Windows Firewall application itself has a powerful logging component that is of high value for connection to Microsoft Sentinel.

Turning on Windows Firewall Logging

Figure 4 is an actual Windows firewall log—this is the raw data we are collecting for security use. The columns include source and destination IP and port, size of the packet in bytes, TCP control flags, and the direction of the communication.

A screenshot of a computer screen

Description automatically generated

Figure 4 – The Windows Firewall log contains valuable network session data for security analysis.

As a best practice, enable Windows Firewall logging on all your servers connected to Microsoft Sentinel. Firewall logging can be enabled at scale with Active Directory Group Policy (GPO).

Figure 5 shows the necessary configuration of each profile (Domain, Private, and Public), specifically that all dropped and successful connections are logged, and that the log size limit is 1,024-KB.

A screenshot of a computer

Description automatically generated

Figure 5 – Desired Windows Firewall logging settings for use with Microsoft Sentinel data connector.

Enable Windows Firewall log collection via AMA

The most common scenario for collecting Windows Firewall logs at scale is for the purpose of informing the SIEM: Microsoft Sentinel. While you can collect Windows Firewall events via AMA using an ad-hoc Azure Monitor Data Collection Rule (DCR) alone, if you are using Microsoft Sentinel, the DCR should be created within the Microsoft Sentinel application.

Install the Windows Firewall via AMA data connector

After enabling Windows Firewall logging on your Windows servers as previously described in this article, navigate to the Content hub in Microsoft Sentinel and locate the Windows Firewall solution as seen in Figure 6. Select the solution and push the Install button.

Figure 6 – Installing the Windows Firewall solution from the Microsoft Sentinel Content hub.

Once the Windows Firewall solution is successfully installed, the view seen in Figure 6 will change slightly—The Windows Firewall solution will show “Installed” and the “Install” button will change to a “Manage” button.

Click the Manage button and then, from the Windows Firewall solution page, select Windows Firewall Events via AMA and push the Open connector page button. From the Windows Firewall Events via AMA connector page, seen in Figure 7, push the Create data collection rule button.

A screenshot of a computer

Description automatically generated

Figure 7 – The Windows Firewall Events via AMA data connector page when configured and operational.

The Create Data Collection Rule pane will appear on the right side of the screen. Create the DCR with these steps:

  1. Assign a rule name like “MSSentinel-ama-windowsfirewall-<MyOrg>-dcr”, confirm the subscription and resource group (usually the same as where Microsoft Sentinel is installed) and push the Next: Resources button.
  2. If you will be associating the DCR with just one or a few computers, locate and select them, but if you will be using Azure Policy to associate computers with the DCR at scale (recommended), you can leave this step blank. Push the Next: Collect button.
  3. Unless you have a reason not to, accept the “Domain”, “Private”, and “Public” profiles selection and push the Next: Review + create button.
  4. Push the Create button to create the DCR.

Figure 8 shows what the Windows Firewall via AMA DCR looks like, including the Resource JSON that exposes the destination table: ASimNetworkSessionLogs.

A screenshot of a computer

Description automatically generated

Figure 8 – The DCR for Windows Firewall via AMA streams data to the AsimNetworkSessionLogs table.

Tip: Use Azure Policy to affect the Data Collection Rule Association (DCRA) automatically rather than specify computers manually on the DCR Resources tab. See the Azure Policy section of my previous blog article for step-by-step instructions.

You can validate success at creating the Windows Firewall via AMA DCR and associating the DCR with one or more Windows computers by observing Windows Firewall entries in the ASimNetworkSessionLogs table as seen in Figure 9 (from Log Viewer inside the Microsoft Sentinel console).

A screenshot of a computer

Description automatically generated

Figure 9 – A Windows Firewall via AMA log entry showing outbound connection to the Microsoft East US datacenter in Boydton, Virginia on port 443.

Install the Windows Firewall via AMA workbook

The new workbook that is the subject of this article is the ‘last piece of the puzzle’, because the workbook won’t yield data until all the previous steps described are complete.

Don’t install the Windows Firewall workbook that is seen in the Windows Firewall solution at the Content hub—that workbook is only for the MMA-era Windows Firewall logs.

  1. Locate and select the Windows Firewall via AMA Standalone Content source in the Microsoft Sentinel Content hub.
  2. Push the Install button.
  3. After the workbook installs, push the Configuration button.
  4. Then push the Save button as seen in Figure 10.
  5. Select the location (Azure region) where you want to save the workbook, usually the same location where Microsoft Sentinel is installed.
  6. Push the View saved workbook button.

Figure 10 – Saving the Windows Firewall via AMA workbook to your Microsoft Sentinel workspace.

Use the Windows Firewall via AMA workbook

Here are some tips for getting value from the Windows Firewall via AMA workbook.

  • Change the TimeRange from the default 7 days and/or the Computers filter from the default of “All” to whatever works for you. If you want the workbook to always open with those settings, push the Save button at the top of the workbook (looks like a floppy disk).
  • To the right of the time range selector are tiles representing the ten (10) most recent computers to upload their Windows Firewall logs during the time range. Computers upload their logs when the maximum log file size (see Figure 5) is reached. (1,024-KB is specified as the desired log size to effect timely uploads to Microsoft Sentinel.)
  • To the right of the connected computer tiles is a chart showing the total number of unique connected computers during the selected period.
  • Below these widgets are a sortable list of Firewall events and a pie chart of Allowed Connections by port (See Figure 11).

Figure 11 – The top portion of the Windows Firewall via AMA workbook.

Next the workbook has two Piechart/Timechart visualizations displaying protocols encountered by the Windows Firewall and what actions were taken by Windows Firewall during the selected period (see Figure 12).

Figure 12 – The center portion of the Windows Firewall via AMA workbook.

Below the Piechart/Timechart visualizations, the workbook has a sortable chart of Windows Security Events by Account. The “Distinct IP Count” and “Event Count” columns can help you identify the most-seen Active Directory accounts in your environment

The final section of the Workbook, “Correlation” gives a representation of the Windows firewall, security log and Azure sign-in events. Results could mean a targeted attack to an organization’s private and public cloud. This can also be used to monitor the organization’s most used IP’s.

For more information

#MVPBuzz #MicrosoftSentinel #SIEM #AzureMonitor #CloudSecurity #AzureWorkbook #WindowsDefender #WindowsFirewall #WindowsDefenderFirewall

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.