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

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:

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*

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?

Let’s get everyone in a conference room and fix this: My previous attempt to tackle the increase of my secure score for a specific environment through sitting down with the team that was responsible for the environment for an hour or two every month to look at the secure score and see what items we could tackle. Unfortunately, the result had little to no impact because the timeframe was insufficient to get things changed due to change control and waiting up to a day to see when changes had been successful.
Hoping it would get better on its own: I will admit part of me just hoped that the issue would go away over time without my having to focus efforts to improve it. But, as it’s been said, hope isn’t a strategy.

What is working?

Fifteen minutes a day on weekdays: I scheduled a 15-minute appointment every weekday from 8:00 – 8:15 in the morning. This timeframe let me focus on our secure score and see any results (or lack thereof) from changes made the day prior. Additionally, this blocked my calendar each morning so I could focus on this initiative.
Teams communication: Communication via Microsoft Teams was truly a key to this approach. We established a group chat for the various SME’s who have resources in the subscription. This group chat led to discussions on specific, actionable items and opened up communication so that there were no surprises as changes occurred in the environment.
Removing dead / non-required resources: Unlike in the walking dead, aggressively hunt dead items in your subscription. Don’t let them hang around any longer. If they aren’t required (IE: dead), put a bullet in their head and get them gone. In all seriousness, why work on securing resources that are not even required any longer. Removing them decreases your costs and simplifies the securing of your environment. In my example (see Figure 2), this resulted in almost a 20 point increase in my environment (from 56 to 74).
Fix the easy stuff first: Get a win. Then, after removing the dead stuff, go cherry-picking. Find the easy ones to fix—those with quick fixes – especially the scripted ones. Get those knocked out. It’s very motivating to see your secure score increase over time from 26 to 88 (been there, done that, need to make the t-shirt – see Figure 1).
Development then production: Hopefully, you have a development environment and a production environment. If so, start with an item in the development environment first and then make the change in production after it’s successful.
Track metrics: I track the date, secure score, points secure, points not secure, unhealthy, healthy, and not applicable numbers as part of my 15 minutes a day. I also keep any notes for that date to remember what may have impacted my secure score (see Figure 2).
Track specifics: I also track each required change, including any unique indicators and specifics of remediations taken for that item. This is to promote re-use of the remediations for other environments. Additionally, I track what is negatively impacting our secure score in production environments to map back initiatives to work through in the development environments.
Schedule changes: Many required changes will need a change control process. These need to be scheduled in advance and approved. I built in any time for these processes as part of the 15 minutes a day. The result is that many days may not involve fixing anything in the environment, but instead, that time is focused on getting paperwork in place to make the change happen.
Automate, Automate, Automate: Any change made somewhere for your secure score is extremely likely to be needed again. Develop automated remediations through Azure Automation (PowerShell) and/or LogicApps for reuse.

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?

Azure Sentinel is priced based on the amount of data that is gathered and how long it is retained. Pricing is available on a pay-as-you-go ($2.46 per GB), or with capacity reservations.
See Microsoft’s pricing calculator for details: Azure Sentinel Pricing | Microsoft Azure

Additional Reference material:

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

Figure 1: Security controls related to vulnerabilities and security configurations