Qualys BYOL or built-in Qualys agent for Azure Security Center – Microsoft Defender for Cloud MDfC

If you are deploying Microsoft Defender for Cloud (MDfC) on your servers (previously known as Microsoft Defender for Servers) you are probably using the built-in vulnerability assessment tool as described in the Integrated Qualys vulnerability scanner for virtual machines article. This Qualys tool is built-in into Defender for Cloud and doesn’t require any external licenses. However, if your company is already utilizing Qualys as your primary threat and vulnerability scanner, you should be able to leverage the BYOL solution, as this will provide Qualys Vulnerability Assessment in both your Qualys subscription and in the Azure Security Center. The Azure Security Center handles the deployment of Qualys Cloud Agent for this solution to work. Agents installed via other methods (extensions, baked into images, or deployed manually) will not report their findings into the associated ASC.

Some considerations to review before comparing the options.

  • Cost: The built-in scanner is included with MDfC has no added cost in Azure Defender for Cloud. BYOL option requires maintaining a Qualys license.
  • Coverage: The built-in scanner supports Azure ARC machines, while the Qualys BYOL option will not cover on-prem and multi cloud machines. The BYOL option only works with Azure Virtual Machines.
  • Deployment: The built-in scanner has more deployment options through API making it almost automatically deployment for Azure Virtual Machines (see official docs)
  • Vulnerability findings: The built-in scanner findings in Azure Security Center are richer with data, comparing to BYOL findings in ASC, whereas BYOL findings are also reflected in the Qualys platform. For instance, while you will find the same CVE and Security Recommendations, the metadata passed to ASC will not be as complete as using the build-in agent.

Best and Fastest way to implement Device-Based Conditional Access Policies in AzureAD. No compliance required !

Up to a few weeks ago, we needed to fully enroll the devices in Microsoft Endpoint Manager #MEM (a.k.a. Intune) to be able to use device-based conditional access policies. Similarly, we needed to evaluate the compliance of the device which was not the most reliable technology. However, this new feature allows to easily evaluate these conditions based on the type of registration of the device. Therefore, fully enrolling the devices in Intune is not required anymore. As long as the device has been integrated with AzureAD, we can create conditional access policies. The properties filter we can use are as the following:

  1. AzureAD Joined
  2. Hybrid Azure AD Joined
  3. Azure AD registered

What is a trustType attribute: It is a valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices)              

This is a great feature and adds a lot of value to the implementation. In my case, I currently have a customer on a highly secured industry that is evaluating Office365 and requires to limit access to only corporate-owned Win10 devices, but it is not implementing Endpoint Management nor is interested in enrolling the devices to evaluate compliancy. By synchronizing the devices using AzureAD Connect and automatically joining the devices as Hybrid AzureAD we can accomplish their specific requirement.

Please note that Device state and filters for devices cannot be used together in Conditional Access policy.

Hope you like this policy as much as I do.

Until next time !

Fastest way to capture and upload the hardware hashes into Intune AutoPilot (Microsoft Device Management #MEM)

We expect the vendors to provide the Windows Autopilot hardware hashes or onboard the devices directly into our tenant. However, that is not usually the case. While the process has improved over the years, there are situation where vendors may not be able to generate the hardware hashes on a timely manner, or not at all. That is why Windows Autopilot device registration can be done within your organization by manually collecting the hardware hashes and uploading this information in a comma-separated-value (CSV) file.

STOP THERE… that process has been updated and improved, making our life much easier. Thank to a newly available option as part of the Windows10 devices, you can manually generate the hashes and automatically upload the hashes to your tenant without the need exporting it into a .CSV file.

During the OOBE (Out of the Box Experience) you also can initiate the hardware hash upload by launching a command prompt (Shift+F10 at the sign in prompt), and using the following commands.

Prerequisite: Your device needs to be connected either a wired or wireless network with internet access.

Powershell.exe 
Install-Script -name Get-WindowsAutopilotInfo -Force
Set-ExecutionPolicy Unrestricted
Get-WindowsAutoPilotInfo -Online

At this point you will be prompted to sign in, an account with the Intune Administrator role is sufficient, and the device hash will then be uploaded automatically. If MFA is enabled, you will be required to use it. (Always make sure to have MFA enabled in all your accounts)

Upon confirmation of the uploaded device hash details, run a sync in the Microsoft Endpoint Manager Admin Center and wait for your new device to appear.

Once the device is shown in your device list, and an autopilot profile is assigned, restarting the device will result in OOBE running through Windows Autopilot provisioning process.