Using the KQL query results to find the exact registry setting to remediate security configurations | Quisitive

If you have worked for a while on your secure score and you have virtual machines in your environment, I’m betting you may have run into this situation. Your secure score probably has a variety of items that need resolution under both “Remediate vulnerabilities” and “Remediate security configurations.” In a previous blog post, I provided my insights on how to raise your security score in general. There is a significant push towards addressing the two items shown below as they represent 11% of the remaining secure score increase in my environment. The secure score in the environment I am working on is currently 88%, so 11% of the 12% remaining (shown below in Figure 1).

In this blog post, I will focus on one specific set of security items and a process for resolving them more effectively. Specifically – how to fix items under “Remediate security configurations” within “Machines should be configured security” that require registry changes to systems (yeah, I know, this one is pretty darn specific). It’s critical to understand what specific registry key, path, and value are required to remediate this issue. A single mistake on any of those can have significant negative results, so those must be 100% correct before making any changes to the registry on a system.

If we expand either of the controls in Figure 1, we see various security items that require resolution. For example, if we expand “Remediate security configurations,” we see the information in Figure 2.

Figure 2: Remediate security configurations

In Figure 3, we see the various failed rules by their severity. In my environment, I have already completed some of the resolutions for these items, so for the three potentially impacted systems, we have a total of 16 failed rules currently.

Figure 3: Details for the security configurations that need to be remediated

For today’s example, we are going to work on resolving AZ-WIN-00155. If we dig into the details for this one, we see what’s required and the actual value. Figure 4 shows that the expected value is 1, but the current value is 0. The challenge here is this screen does not show what registry key it’s looking at for this information. To see this, we open the “View affected machines” link below.

Figure 4: Details for AZ-WIN-00155

This moves us into KQL/Kusto. From here, we can run the original query (Figure 5). That gives us the computer ID and the computer name. That’s helpful, but we also need to know what registry key it is checking.

Figure 5: Kusto query for AZ-WIN-00155

If we instead highlight the first three lines and then add a quick project for the fields we want (Computer, RuleSetting, ExpectedResult), we get a more direct representation of what we need (shown in Figure 6).

Figure 6: Updated query to show the Computer, RuleSetting, and ExpectedResult

From here, I can cut and paste the RuleSetting field. This gives me the actual registry setting that is being assessed. I can now run a script to reach out to the Computer(s) indicated to create the appropriate registry entry in my environment. In my case, I need to translate the RuleSetting also as follows:


RuleSetting=LocalMachine\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers : AuthenticodeEnabled



Summary: If you dig into the various items identified under “Remediate security configurations,” you can use the Kusto query generated by the system to determine the appropriate path, key, and value required to remediate the security configuration.

Going beyond this particular example: All this data is currently available in a log analytics workspace to automate this resolution. For instance, we could establish an alert in Azure Monitor that looks for failed conditions for a missing registry value. Then a script or a LogicApp could be run to email for approval for the change (see note #1). If approved, the script can run to set the appropriate registry key. An example Kusto query for this is below.

| where AnalyzeResult == "Failed"
| where BaselineRuleType == "Registry Key"
| project Computer, RuleSetting, ExpectedResult
| distinct Computer, RuleSetting, ExpectedResult

Note #1: I would probably recommend LogicApps for this as there are existing ties to LogicApps within Microsoft Defender for Cloud*

I know that sounds like a bad infomercial for getting six-pack abs, but it’s not. This is a story about the lessons I have learned attempting to increase my Microsoft Defender for Cloud Secure Score and what works (and what did not). Let’s start with what did not work.

What did not work?

What is working?

Figure 1: Current secure score

Figure 2: Tracking metrics

Welcome to the “Introducing” series. In the previous blog post, we introduced Logic Apps. In this blog post, we will introduce a security solution that Microsoft has created called Azure Sentinel.

What is Azure Sentinel?

Security is a core requirement for IT organizations. Compute, network and storage-based devices each gather information about what is occurring for those devices and write that data into some form of a log. For Windows systems these are written to event logs, Linux systems write to log files, and network/storage devices write their data to Syslog servers. Azure Sentinel works to consume and correlate these logs to provide new capabilities.

SIEM: With security data being written to many different types of systems, it is difficult to impossible for system administrators to watch all the different log files to identify relevant information. Furthermore, it is both challenging and complicated to compare events within one log with another to detect any patterns that could indicate the need for attention, sometimes critical attention. As a result, it is common to generate alerts for specific conditions or to gather the information across the various systems into a single location where the data can more effectively be analyzed. This common repository is a Security Information and Event Management (SEIM) solution. A SIEM aggregates data and helps to correlate these data to provide actionable alerting and dashboards that assist with performing analysis of the security information that is collected. Think of it as a one-stop-shop for all security events across all of information technology’s compute, network, and storage devices whether on-prem or in the cloud.

SOAR: Security Orchestration Automation Response (SOAR) provides the automated actions that a company decides should occur when specific conditions are identified. An example of this is what is referred to as the “Impossible Travel” situation. This would occur if a user logged in to their work computer in Dallas at 8:00 am and then logs into another system in Europe two hours later. It is an impossible travel situation as even with the fastest air travel it would not be possible for the same person to have logged in at these times in both locations because it would take too long to travel from the first location to the second location. When a situation like this occurs, organizations may choose to perform automation that validates the situation for specific risks (such as, was it a different computer for the two logins, does the user have a VPN that may be communicating to Europe, etc.) and then performs some form of action. For the “Impossible Travel” situation, this might be disabling the user’s account and generating a notification to the user’s manager – after verifying that it was a different device on each login and that the user does not have a history of using VPNs.

So, what is Azure Sentinel? Azure Sentinel is a cloud-based SIEM and SOAR solution that can be used to gather security information from across an organization and help to identify and remediate security threats.

A did-you-know: Also, if you are familiar with internal and external IT audits, you may be familiar with some of the requirements that many regulations and laws require. One such common requirement is the retention and review of security event logs. Now, apply what we have just discussed, and you will quickly realize how Azure Sentinel can play a beneficial role in helping you meet this audit requirement even automatically. We will delve into this topic later in the series.

What are the components of Azure Sentinel?

Azure Sentinel is built upon existing Azure technologies including Log Analytics, Kusto, Logic Apps, Workbooks, and Azure Monitor. If you have been reading this series for a while now, the list below should seem very familiar as these were the recent blog posts in this series.

Log Analytics: The data that is gathered by Azure Sentinel’s connectors are stored in a Log Analytics workspace.

Kusto: As the data for Azure Sentinel is stored in a Log Analytics workspace, Kusto is the query language that is used to work with the data that is gathered by Azure Sentinel.

Logic Apps: Azure Sentinel uses Logic Apps to perform remediations for alert conditions to provide low-code or no-code automation. In Sentinel, these are referred to as “playbooks”.

Azure Monitor/Workbooks: Workbooks provide pre-built and customizable solutions to visualize the data stored in Sentinel. In Sentinel, these are referred to as “workbooks”.

Working with each of the solutions above provides a solid foundation to work from when learning Azure Sentinel.

Connectors: Data connectors are used in Sentinel to gather data from a variety of sources. An example of this is shown below where the connectors are filtered by the keyword “Azure”. Connectors that are already installed into Sentinel are shown with the vertical green bar on the left of the icon representing the Azure service.

What are common uses for Azure Sentinel?

Once data has been collected by Azure Sentinel it can be used to assist with investigating a potential incident or to hunt for threats in the environment.

Insights: Incidents are a gathering of alerts, entities, and additional evidence that is gathered when an alert is triggered based on the detection. The example below shows several incidents in Azure Sentinel.

Investigation: The details of an incident can be investigated an incident and see the relationships between the various entities as shown below.

Digging further into an investigation provides pre-built Kusto queries that can be used to further analyze the underlying data.

Hunting: Sentinel includes a variety of pre-built queries that assist with hunting for threats in an environment.

Tip: Azure Sentinel also has a community on GitHub that contains custom workbooks, hunting queries, notebooks, and playbooks. If you are looking for additional hunting queries (among other assets), it is a good place to start.

How is Azure Sentinel priced?

Additional Reference material:

Special thanks to Ed Higgins, Rod Trent, and Maarten Goet for their assistance with this blog post!