Microsoft Defender Vulnerability Management (MDVM) is an often overlooked service that can be licensed standalone or is included in other Microsoft Defender licenses. In my experience, I’ve never seen it licensed standalone, but customers with Defender for Endpoint (MDE) P2, Defender for Servers  (MDS) P1, and Defender for Business (MDB) benefit from it’s core capabilities.  In addition to the core capabilities, add-on capabilities are available in the standalone license, Defender for Servers P2, or as an upgrade to the P1 licenses.

If you successfully integrate MDVM with your operations, it can provide huge value to reducing your attack surface, staying on top of weaknesses, managing inventory, and preventing threats before they actualise. So, to help you achieve that, in this blog, I’ll cover five mistakes I see folks who are licensed to MDVM make.

This blog is part of a series on common Microsoft 365 security mistakes. View the previous blogs here:

Table of Contents

Device values not leveraged

Device values are important for well managed MDVM operations, but also benefit and are core to MDE response. But that benefit only comes if you use them!

Device values can be low, normal, or high and set using the Microsoft Defender XDR portal at security.microsoft.com/machines (one at a time or select multiple) or using the MDE API.

You may want to roughly translate low, normal, and high to the tiered access model or enterprise access model.

From an MDVM perspective, some benefits of managing device values include:

  • Filtering your advanced hunting queries so you can customise detection rules.
    • This is the AssetValue in the DeviceInfo table
  • Filtering the device assets list.
    • I don’t see it as option for asset rules management to create a dynamic tag based on value, but hopefully soon.
  • Weighting the exposure score (software and firmware updates, upgrades, EOLs).
    • If a normal device weights 1, low devices weigh 0.75, so your score doesn’t increase as much.
    • High value devices have a dynamic weight based on 10% of your total devices. As an example, a tenant with 1200 devices will have a high value weight of 120. That would increase to 130 if the number of devices grew to 1300.  So you can see how significantly high value devices affect exposure score!
  • Ultimately, more easily prioritising your remediation activities.

Not assessing the real risk of a recommendation

The following point is true for any kind of vulnerability scanning service.

When you first start onboarding devices into MDVM, the Security recommendations page will light up like a Christmas tree. Security recommendations are plain-language advisories based on OS and software configuration changes; software/firm updates, upgrades, or EOLs; or other endpoint weaknesses that may require investigation.

For most environments, this creates necessary work because those weaknesses should be addressed. In some cases, it may produce unnecessary or at least low-priority work.

Recommendations are weighted with an impact score, lack a business context that you as the environment administrator will need to ascertain.   I often see is folks with too much of a “gotta catch ’em all” approach and spend time on items that aren’t worth the squeeze.  As an example, in the real world, Enable ‘Block third party cookies’ may just be a waste of your time; so don’t get obsessive about ticking every box.

Also consider the real-world requirements for CVEs to be exploited. Generally, multiple failures must align for adversaries to be successful. This is particularly the case for out of date software MDVM warns you about. You should absolutely keep software as up to date as possible, but practically, you’ll need to prioritise packaging, testing, and deploying things unless using a service like the awesome Patch My PC.

Take the example of this recommendation to update KeePass.

We’re busy, so want to know the real risk before we spend more time. Heading into the Associated CVEs tab, you can view the vulnerability description. In our Keepass example, CVE-2023-24055 actually requires the endpoint itself to be compromised with the adversary having access to the app’s configuration files, followed by the victim opening their database after the configuration file tampering (a cool POC can be found here).

In the real world, usually a serious chain of events must line up, often with mitigating factors preventing it (endpoint protection software, identity defences, etc).  So ask yourself: how likely is this, and should I prioritise other concerns?

For the avoidance of mischaracterising this mistake: you absolutely should be updating apps as widely and quickly as possible.  Having worked in and with all sorts of overwhelmed IT teams, I just want to encourage you to think, assess, prioritise based on real likelihood of damage, and take it easy on yourself if you can’t get everything done at lightning pace.

Not reviewing the software evidence

This follows on from the last mistake and recommendation as it will help you identify the reality of risks. The existence of an executable associated with a vulnerable app can be enough to trigger a vulnerable component warning, even if it’s not properly installed.

Heading to the Evidence tab of software and vulnerable components against a device, you can see the paths (file, registry) that allowed the MDVM detection. For example, in the screenshot below you can see patcher.jar associated with Log4j listed as a vulnerable component.

While the detection is accurate, investigation adds more context: it’s saved to a user’s OneDrive, in a folder with installation files, rather than actually being installed. If I’m prioritising vulnerability management, I would rather it wasn’t there, but I can probably find more important things to spend time on.

Moral of this mistake: the software evidence tab is there to help you understand how MDVM picked up on something and potentially explain confusing situations or help you get to the bottom of real-risk assessment.

Not leveraging Microsoft Defender for Servers P2

MDVM’s add-on license includes extra goodies that you don’t get as standard with MDE P2. I help a lot of customers review their environments and figure out what they’re paying for but not leveraging, and many don’t realise the add-on for MDVM is included in their Defender for Servers P2 license.

The add-on license provides a lot of useful capabilities, but two stick out for servers: baseline assessments and certificate inventories.

The security baseline assessments allow you to check an endpoint’s adherence to benchmarks such as CIS, Microsoft’s Security Baselines, or STIG. In environments that try to stick to these frameworks, it provides validation.

Certificate inventories provide insight into all certificates on the endpoint. At a minimum, you can leverage it to keep on top of infrastructure management by seeing expired or soon-to-expire certificates. Better still, you can identify those which may have suspicious (due to rarity) private CAs, or other qualities such as short key lengths and weak algorithms.

You’re paying for the add-on as part of MDS P2, why not use it?

Focusing only on exposure score recommendations and not Microsoft Secure Score

There are too many scores in the Microsoft ecosystem. Defender for Cloud has a secure score in portal.azure.com. Entra ID has the Identity Secure Score in entra.microsoft.com. Over in security.microsoft.com, there’s the Secure Score, Secure Score for Devices, and the exposure score. I think there’s a Microsoft Adoption/Productivity Score too, but I just can’t take it anymore.

The mistake this point refers to is focusing only on endpoint vulnerabilities, as surfaced primarily in MDVM’s dashboard by the exposure score.

I know it’s confusing having so many ‘scores’ in one Defender portal, so let me make it clear: work with the Microsoft Secure Score, found at security.microsoft.com/securescore. The benefit to this is its centralisation: in addition to the endpoint weaknesses MDVM discovers, the Microsoft Secure Score incorporates other service recommendations. It pulls in SaaS security from Defender for Cloud Apps, identity security from Entra ID and Defender for Cloud Apps, and more

Conclusion

Deploying MDVM is the easy part. Other than the dedicated scanner, you’re good to go as long as MDE is properly deployed. The hard part is operations: taking that new tool and translating it into something you manage as part of business as usual. Hopefully, avoiding the mistakes in this article will help you.

Tags:
Last updated on February 3, 2024