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.

Figure 1: Security controls related to vulnerabilities and security configurations

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:

Original:

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

New:

KeyPath="HKLM:Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers"
ValueName="AuthenticodeEnabled"
Value="1"

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.

SecurityBaseline

| 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*