Seach
  • Home
  • Blog
  • Defender TVM: Configuration Benchmark Management

Defender TVM: Configuration Benchmark Management

By Caleb Freitas

Vulnerability and Benchmark configuration management programs provide significant corrective and preventative controls that reduce exposure against real-world threats. While most organizations use third-party solutions such as Tenable Nessus or Qualys for vulnerability management, those solutions come with additional agent installations, licensing, and management overhead. With Microsoft Defender, licensing for vulnerability management is already included, and there are no other agent installs or different platforms to maintain.

In this multi-part blog post, we’ll review some of the use cases for threat and vulnerability management (TVM) data in Microsoft Defender for Endpoint and how to operationalize that data using Kusto Query Language (KQL). It is worth noting that Microsoft does have some excellent built-in dashboards for threat and vulnerability management (Dashboard insights – threat and vulnerability management | Microsoft Docs). But in this blog post, we’ll dive deeper to show more in-depth and customizable insights that can be tailored for your organization.

What is KQL? If you’re unfamiliar with KQL, we’d highly recommend visiting this Microsoft blog post for an overview (Learning Kusto Query Language).

Configuration Benchmark Overview

Hardware, operating systems, and applications all have default configurations that help with ease of deployment and ease of use. However, this usability comes at the price of reduced security. Attackers often exploit numerous default configuration settings, many of which don’t have a business need to be enabled. Examples include default accounts, unnecessary services, open network ports, and legacy protocols.

A standardized practice is to have a documented security configuration benchmark and only deploy devices with that benchmark. But organizations often struggle with the ongoing management and monitoring of documented benchmarks because device configurations may and will “drift” from the organizational standard, or the configuration that once was thought of as “secure” is now a vulnerability.

Additionally, many regulatory obligations such as CMMC (CM.2.061) require baseline configuration management (AKA Benchmarks) to be actively enforced, monitored, and maintained. Just applying a benchmark with a Group Policy or device management solution won’t cut it in an assessment, the auditor is going to want to see proof that the organization is actively monitoring and maintaining security configurations.

Benchmark Standards supported by Defender for Endpoint

Today, organizations can adopt several different well-documented configuration benchmark standards for guidance on secure configuration and Microsoft Defender reports on the following:

  • DISA STIG
  • CIS Benchmarks
  • Microsoft Security
    Baselines

Understanding the Data

In the Microsoft Defender Advanced Hunting portal, there are two different tables that we’ll want to understand:

  • DeviceTvmSecurityConfigurationAssessment – Assessment of the security configuration of devices.
  • DeviceTvmSecurityConfigurationAssessmentKB – A global knowledge base of various security configuration settings, including mapping to different benchmarks (STIG, CIS, MS).

For our queries, we’ll need to join the two tables to give us a complete picture of the devices in the environment and the configuration recommendations that we’re interested in.

A simple join statement using the column “ConfigurationID” as the join key will get us the complete picture:

Query

DeviceTvmSecureConfigurationAssessmentKB
| join (DeviceTvmSecureConfigurationAssessment) on ConfigurationId
| project DeviceName, ConfigurationId, ConfigurationName, ConfigurationImpact,
        ConfigurationCategory, ConfigurationSubcategory, ConfigurationBenchmarks,
        ConfigurationDescrip-tion, RiskDescription, RemediationOptions, IsCompliant

There are a few columns that are important to note for our next queries:

  • ConfigurationID: Unique Identifier to the configuration that is assessed
  • ConfigurationBenchmark: Displays if the configuration aligns with a known documented standard
  • o Center for Internet Security (CIS) Benchmark
    o DISA Security Technical Implantation Guide (STIG)
    o Microsoft Security (MS) Baseline

  • Configuration Impact: Rated security impact from 1-10, 10 being the highest impact items to reduce risk on a device.
  • IsCompliant: Indicates whether the configuration is implemented properly:
  • o 1 = yes,
    o 0 = No,
    o Null = Not Assessed

Use Case: View the Top Security Configuration Recommendations

If you ran the query in the last section, you probably returned thousands of results which isn’t very actionable or measurable.
Fortunately, Microsoft Defender has a “Configuration Impact” score, which is a great way to prioritize what configuration recommendations have the highest impact in reducing device exposure that the organization should implement first.

With the following query, we’ll summarize each non-compliant configuration recommendation with an overall impact score across all non-compliant devices, as well as a list of the non-compliant devices.

DeviceTvmSecureConfigurationAssessmentKB
| join (DeviceTvmSecureConfigurationAssessment
| where IsCompliant == 0) on ConfigurationId
| summarize Devices = make_list(DeviceName), DeviceCount = dcount(DeviceName) by ConfigurationId,
        ConfigurationName, ConfigurationImpact, ConfigurationCategory, ConfigurationSubcategory,
        tostring(ConfigurationBenchmarks), RemediationOptions
| extend OverallImpact = ConfigurationImpact * DeviceCount
| project-reorder ConfigurationId, ConfigurationName, ConfigurationImpact, DeviceCount,
        OverallImpact, ConfigurationCategory, ConfigurationSubcategory, ConfigurationBenchmarks, Devices,
        RemediationOptions
| sort by OverallImpact desc

 

Use Case: Filter by Device Groups

In larger environments, various teams may be responsible for managing devices by type or function. In Microsoft Defender, we can use Device Groups for filtering in our queries. In our demo environment, we have a device group called “Full Auto” that we will be filtering for, but in most standard environments, there are typically device groups configured to separate servers and workstations.

// Select the Device Group you want to report on
let devicefilter = DeviceInfo
| where MachineGroup == ‘Full Auto’
| distinct DeviceName;
// Analyze open configuration items and score impact
DeviceTvmSecureConfigurationAssessmentKB
| join (DeviceTvmSecureConfigurationAssessment
| where IsCompliant == 0
| where DeviceName in (devicefilter)) on ConfigurationId
| summarize Devices = make_list(DeviceName), DeviceCount = dcount(DeviceName) by
        ConfigurationId, ConfigurationName, ConfigurationImpact, ConfigurationCategory,
        ConfigurationSubcategory, tostring(ConfigurationBenchmarks), RemediationOptions
| extend OverallImpact = ConfigurationImpact * DeviceCount
| project-reorder ConfigurationId, ConfigurationName, ConfigurationImpact, DeviceCount,
        OverallImpact, ConfigurationCategory, ConfigurationSubcategory, ConfigurationBenchmarks,
        Devices, RemediationOptions
| sort by OverallImpact desc

Use Case: Utilize a Custom Configuration Baseline

While organizations should adopt an existing security benchmark standard such as CIS or DISA STIGs, it is uncommon and typically impractical to implement all the recommended settings within a benchmark without negatively impacting the environment. Therefore, the standard process is to thoroughly test benchmark configuration items and document the settings deployed to all devices and which settings items may be excluded from deployment for business reasons.

If your organization does have a documented benchmark configuration (CMMC Requirement CM.2.061) by using an external data lookup, we can filter for organizationally defined configuration settings. Also, as a bonus, we can use a custom impact score to better represent what may be most important to your organization to reduce address risk.

In this example, we exported a list of all Microsoft Defender configuration items to a CSV file and added columns called “CustomBenchmark” and “CustomImpact”:

Our CSV was then uploaded to Azure Blob storage so that we can use an external data lookup to bring in the data as a custom table.

To learn more about External Data lookups, we had previously published an article for performing this in Azure Sentinel, Microsoft Defender supports the same capabilities. Using KQL to Ingest External Data In Azure Sentinel | Managed Sentinel.

// Select the Device Group you want to report on
let devicefilter = DeviceInfo
| where MachineGroup == ‘Full Auto’
| distinct DeviceName;
// Bring in Custom Benchmark as external data
externaldata (ConfigurationId: string, ConfigurationImpact: int, CustomImpact: int,
        Custombenchmark: string,
        ConfigurationName: string, ConfigurationDescription: string, RiskDescription: string,
        ConfigurationCategory: string, ConfigerationSubcategory: string, ConfigurationBenchMarks: dynamic,
        Tags: dynamic, RemediationOptions: string)
        [h’.csv’]
with (IgnoreFirstRecord = true)
| where Custombenchmark == ‘Yes’
// Join with device configuration data
| join (DeviceTvmSecureConfigurationAssessment
| where IsCompliant == 0
| where DeviceName in (devicefilter)) on ConfigurationId
| summarize Devices = make_list(DeviceName), DeviceCount = dcount(DeviceName) by
        ConfigurationId, ConfigurationName, CustomImpact, ConfigurationCategory,
        ConfigurationSubcategory, Custombenchmark, RemediationOptions
| extend OverallImpact = CustomImpact * DeviceCount
| project-reorder ConfigurationId, ConfigurationName, CustomImpact, DeviceCount,
        OverallImpact, ConfigurationCategory, ConfigurationSubcategory, Custombenchmark,
        Devices, RemediationOptions
| sort by OverallImpact desc

 

Conclusion

Using Advanced Hunting Queries in Microsoft Defender for Endpoint, we can easily pull data on, enrich, and prioritize configuration recommendations. In this blog post, we only ran the queries manually. Though, with the cloud-native integrations and the capabilities of the M365 suite, we can easily take this further and use the same KQL queries for scheduling reports with Microsoft Azure LogicApps or creating custom interactive dashboards with PowerBI and enable the compliance teams with actionable reporting.

Caleb Freitas is a Managed Sentinel security architect.

Related reading