Microsoft Defender for Cloud provides recommendations on various items related to Azure resources (and on-prem resources via ARC). For example, one of the recommendation types focused on vulnerabilities that may exist on virtual machines (VMs). Microsoft provides two built-in vulnerability assessment solutions for VMs.
One is “Microsoft Defender vulnerability management,” and the other is the “integrated vulnerability scanner powered by Qualys” (referred to from here forward as “Qualys”). Microsoft includes both solutions as part of Microsoft Defender for Servers. In addition, Microsoft has made “Microsoft Defender vulnerability management” (referred to from here forward as “Default”) the default vulnerability scanner. These two options are shown below in Figure 1.
Figure 1 : Vulnerability assessment solutions currently available
My recommendation?
I recommend using the Qualys scanner instead of the Default vulnerability scanner. This is because the Qualys scanner looks for more vulnerabilities, resulting in a more complete result.
If you want to go further into the weeds from what I found, feel free to continue reading through the functional comparison, FAQ, and Reference Links sections below.
Functional comparison:
- When comparing a similar system in both scanners, the Qualys scanner identified significantly more vulnerabilities than the Default scanner.
- The Default scanner currently focuses only on software updates. At the same time, the Qualys scanner also identifies items such as null sessions, built-in guest accounts, Windows Explorer autoplay, and cached login credentials.
- In my example, the Qualys scanner found 8x as many vulnerabilities for a similar domain controller compared to the Default scanner.
- Both solutions are included in Microsoft Defender for Servers, so they currently have no cost difference.
FAQ’s:
- Do these scanners identify the same vulnerabilities? While there is some level of overlap in the vulnerabilities identified, they appear to be scanned using a different database for vulnerabilities.
- Can you use both vulnerability scanners on a single system? Unfortunately, only one vulnerability scanner can be installed at a time on a system. However, one vulnerability scanner can be used and then removed and replaced with the other vulnerability scanner. An example of these scanners and what they look like after deployment is shown in Figure 2.
Figure 2 : Two machines with one onboarded to each vulnerability scanner.
- Do the scanners use the same vulnerability identifier? Each scanner uses a different naming convention Default uses letters such as “QXCJCS,” versus Qualys, which uses numbers such as “90044”.
- Does using one scanner versus the other impact the secure score? Having either vulnerability scanner is considered acceptable to meet the “Machines should have a vulnerability assessment solution” requirement. However, the various vulnerabilities found by each scanner also need to be resolved to increase the secure score. So the more comprehensive scanner (Qualys) will require more work to remediate the issues identified and improve the secure score.
- Is there a way to see a complete list of what each scanner assesses? Unfortunately, I could not find a way to get a complete list of what each scanner checks. I attempted to find this data through searching with Kusto but was unsuccessful. (hint, search for securityresources | where type =~ “microsoft.security/assessments/subassessments”) .
- When was this assessment performed? I performed this evaluation on the week of 1/23/23.
Reference links:
Qualys usage is included per this article: Defender for Cloud’s integrated vulnerability assessment solution for Azure, hybrid, and multicloud machines | Microsoft Learn
So, what is your experience with these options? Do you have any insights that you can provide? Please feel free to reach out to me with them on LinkedIn or Twitter!
While investigating ways to automate adding, modifying, or removing Microsoft Defender for Cloud Apps (MDCA) policies, I could not locate any good Microsoft references. While researching the topic, I discovered a blog post discussing how to automate some MDCA rules within some policy types. This served as a starting point to investigate further automation of the MDCA policies. In addition, I discovered some of the REST API calls used to add, view, or modify MDCA policies through trial and error, which I used to create automated PowerShell functions to implement a consistent set of MDCA policies across our clients. This blog post will serve as a starting point for using the MDCA REST API.
Activate the API
First, make sure to activate the API in MDCA’s security extensions setting. Then, in the MDCA portal, click on the Gear icon, and select Security Extensions.
Under API tokens, select the Add token button. Type in a name for the token and select the Generate button. Copy the URL and API token now, as you will not have access to the token again. Select the Close button when you are finished. This token will appear in the API tokens list and can be revoked at any time. If using the Invoke-RestMethod command in PowerShell, include the token in your header as follows:
$headers = @{
"Authorization" = "Token abcdefghijklmnopqrstuvwxyz1234567890="
"Content-Type" = "application/json"
}Microsoft does include other methods of authentication which can be used in your automation, so I will link the article here.
Depending on the region, the URL copied might have the letters “us2” or “eu2” added to the address. Remove these letters when using the URL in your Invoke-RestMethod PowerShell command, or you will receive errors when executing the script, i.e., for the URL https://example.us2.portal.cloudappsecurity.com, use https://example.portal.cloudappsecurity.com instead.
Basic REST API Calls
Let us review the REST API calls:
GET https://<URL>/cas/api/v1/policies/ – This API lists all active policies on the tenant, and their ID, which will be required to get the policy information later. The JSON output will also show the number of active policies.
GET https://<URL>/cas/api/v1/policy/activity/ – This API is the activity log of the tenant’s MDCA. You can test this by adding a policy from a template, then review the API output. At the bottom of the JSON output should be your new policy. You can also review the settings of an edited policy or see if a policy has been deleted by checking the “deleted” attribute.
JSON Policy Breakdown
Here is an example of one of the policies in the output:
{
"_id": "627b9de8a0039f63881ce801",
"ref_policy_id": 308,
"actions": {
"0": [],
"11161": [],
"11114": [],
"11770": [],
"10489": []
},
"alertEmailRecipients": [],
"alertSeverity": "MEDIUM",
"alertSmsRecipients": [],
"anomalyDetection": {
"riskFactors": []
},
"bip_created": 1545748144000,
"consoleFilters": "{}",
"created": 1652268519991.5312,
"createdBy": "Builtin Policy",
"deletable": true,
"deleted": false,
"description": "This policy profiles your environment and triggers alerts when users perform multiple file sharing activities in a single session with respect to the baseline learned, which could indicate an attempted breach.",
"descriptionTemplate": "CONSOLE_POLICIES_BUILT_IN_POLICY_ANUBIS_UNUSUAL_ACTIVITY_SHARE_DESCRIPTION",
"detectionEngine": 1,
"editable": true,
"enableAlerts": true,
"enabled": true,
"isHidden": false,
"lastModified": 1652814616971.3586,
"lastModifiedBy": "Builtin Policy",
"name": "Unusual file share activity (by user)",
"nameTemplate": "CONSOLE_POLICIES_BUILT_IN_POLICY_ANUBIS_UNUSUAL_ACTIVITY_SHARE_NAME",
"policyId": 3,
"policyType": "ANOMALY_DETECTION",
"stories": [
0
],
"version": {
"full": "0.227.1",
"major": "0.227",
"minor": "1"
},
"ref_policy_created": 1545748144000,
"lastUserModified": 1652814616971.3586,
"matchesCount": 0,
"msFlowCheckboxChecked": false,
"msFlowId": null,
"perApp": true,
"readOnly": false,
"selectedRate": "all",
"templateId": "default",
"threshold": 5,
"windowSizeInMinutes": 30,
"editMode": true,
"story": 0
}This will be the template for adding, editing, or removing the policy “Unusual file share activity (by user).”
All policies are grouped into different Policy Types in the portal and are identified in the JSON output as the policyType attribute:
- ANOMALY_DETECTION – Anomaly detection policy
- ANOMALY_DISCOVERY – Cloud discovery anomaly detection policy
- APP_PERMISSION – OAuth app policy, OAuth app anomaly detection policy
- AUDIT – Activity policy
- FILE – File policy, Malware detection policy
- INLINE – Session Policy
- NEW_SERVICE – App discovery policy
API Call Samples (get policy data)
If we need to retrieve a single Activity policy, use the API call:
GET https://<URL>/cas/api/v1/policy/activity/<ID>/To retrieve an Anomaly detection policy:
GET https://<URL>/cas/api/v1/policy/anomaly/<ID>/To retrieve an App discovery policy:
GET https://<URL>/cas/api/v1/policy/discovery/<ID>/To retrieve a Cloud discovery anomaly detection policy:
GET https://<URL>/cas/api/v1/policy/discovery_anomaly/<ID>/To retrieve a File or Malware detection policy:
GET https://<URL>/cas/api/v1/policy/file/<ID>/To retrieve an OAuth app or OAuth app anomaly detection policy:
GET https://<URL>/cas/api/v1/policy/app_permissions/<ID>/And to retrieve a Session policy:
GET https://<URL>/cas/api/v1/policy/session/<ID>/Edit/Delete Policies
To edit individual policies, use the output from the activity log for the body of the API call and modify the required attributes. Then, use PUT instead of GET in your API call. I recommend configuring a test policy, gathering the output, and applying it to your automation. This is a more straightforward method than modifying the attributes manually.
Using our previous JSON output example, we would change the enabled attribute to false to disable the policy, copy the JSON with the changed attribute into the API body, and submit using PUT https://<URL>/cas/api/v1/policy/anomaly/627b9de8a0039f63881ce801/.
"editable": true,
"enableAlerts": true,
"enabled": false,
"isHidden": false,
"lastModified": 1652814616971.3586,When we inspect the web portal, the policy is disabled after refreshing the browser.
To delete a policy, edit, or verify, the attributes deletable and deleted are set to true. Not all policies may be deleted. The Malicious OAuth app consent policy is one policy during my testing that may only be set to disabled, even if the deletable attribute is set to true.
Construct the JSON Body to Add a Policy
We will use the JSON output as a template again to add a policy. This time, we will remove the _id attribute and modify the templateId attribute with “default” vice the numeric value. Change the name attribute to the new name of the policy. This will be the body of the API call.
WARNING! If you do not remove the _id attribute when creating the policy, it will create a second policy and show both policies in the portal. If you try to delete one of the two, it will delete, but the duplicate policy will remain in the portal. While the policy is not active, you will not be able to delete the duplicate since the _id is already marked as deleted. You will need to contact Microsoft to delete the duplicate.
{
"ref_policy_id": 308,
"actions": {
"0": [],
"11161": [],
"11114": [],
"11770": [],
"10489": []
},
"alertEmailRecipients": [],
"alertSeverity": "MEDIUM",
"alertSmsRecipients": [],
"anomalyDetection": {
"riskFactors": []
},
"bip_created": 1545748144000,
"consoleFilters": "{}",
"created": 1652268519991.5312,
"createdBy": "Builtin Policy",
"deletable": true,
"deleted": false,
"description": "This policy profiles your environment and triggers alerts when users perform multiple file sharing activities in a single session with respect to the baseline learned, which could indicate an attempted breach.",
"descriptionTemplate": "CONSOLE_POLICIES_BUILT_IN_POLICY_ANUBIS_UNUSUAL_ACTIVITY_SHARE_DESCRIPTION",
"detectionEngine": 1,
"editable": true,
"enableAlerts": true,
"enabled": true,
"isHidden": false,
"lastModified": 1652814616971.3586,
"lastModifiedBy": "Builtin Policy",
"name": "Test - Unusual file share activity (by user)",
"nameTemplate": "CONSOLE_POLICIES_BUILT_IN_POLICY_ANUBIS_UNUSUAL_ACTIVITY_SHARE_NAME",
"policyId": 3,
"policyType": "ANOMALY_DETECTION",
"stories": [
0
],
"version": {
"full": "0.227.1",
"major": "0.227",
"minor": "1"
},
"ref_policy_created": 1545748144000,
"lastUserModified": 1652814616971.3586,
"matchesCount": 0,
"msFlowCheckboxChecked": false,
"msFlowId": null,
"perApp": true,
"readOnly": false,
"selectedRate": "all",
"templateId": "default",
"threshold": 5,
"windowSizeInMinutes": 30,
"editMode": true,
"story": 0
}API Call Samples (Add a policy)
To add an Activity policy, use the API call:
POST https://<URL>/cas/api/v1/policy/activity/To add an Anomaly detection policy:
POST https://<URL>/cas/api/v1/policy/anomaly/To add an App discovery policy:
POST https://<URL>/cas/api/v1/policy/discovery/To add a Cloud discovery anomaly detection policy:
POST https://<URL>/cas/api/v1/policy/discovery_anomaly/To add a File or Malware detection policy:
POST https://<URL>/cas/api/v1/policy/file/To add an OAuth app or OAuth app anomaly detection policy:
POST https://<URL>/cas/api/v1/policy/app_permissions/And to add a Session policy:
POST https://<URL>/cas/api/v1/policy/session/To add the policy in our example, we would copy the modified JSON output into the API body and submit it using POST https://<URL>/cas/api/v1/policy/anomaly/.
Summary:
Microsoft should create official documentation to help automate MDCA policy tasks. However, these notes should help the community “fill in the blanks” by creating awesome automations!
Reference links:
Automating the MCAS deployment
;)
In this case study:
Client: Builders FirstSource, Inc.
Industry: Retail
Products and Services: Microsoft 365 Exchange, OneDrive, Azure and Microsoft Defender Antivirus
Country: USA
Quisitive constructs a strategic relationship with Builders FirstSource Inc.
Builders FirstSource, Inc. (BFS) is the largest supplier of structural building products, value-added components, and services to the professional market for new residential construction, repair, and remodeling in the United States.
In 2019, after a change in management, the company took a close look at its technology environment and realized it was not making adequate use of the Microsoft products it had already purchased licenses for.
“We knew our Microsoft maturity was not where we wanted it to be, and at the same time we knew that we had not leveraged our Microsoft contract properly, so we reached out to Microsoft and they recommended a few vendors to us,” said Ben Richard, VP, IT Operations, Builders FirstSource. “We selected Quisitive to help us implement and roll out the Microsoft products we were already paying for.”
These solutions included migrating to Microsoft 365 Exchange and OneDrive, Azure and Microsoft Defender Antivirus.
“Quisitive came in and in a matter of three months, we gained two years of Microsoft maturity,” Ben said, but pointed out that it was not just the outcomes that impressed him about Quisitive. It was also a combination of their strategy and their ability to work so well with his internal team.
“In my 20-year IT career, I have seen a lot of vendors who treat senior leadership in a much different way than they treat the IT staff working in the weeds. In Quisitive’s case, they are the real deal. They truly practice what they preach and respect the whole team,” he said. “I would put dollars to donuts that if asked, anyone on my team would have identical positive things to say about working with Quisitive.”
A True Strategic Partnership
According to Ben, one of the biggest benefits of working with Quisitive was the collaborative process it brought to the table.
“We wanted to be taught to fish. We did not want them to come in, do the heavy lifting, and leave — we wanted to learn ourselves how to keep the lights on and provide maintenance moving forward,” Ben said. “Quisitive was great in terms of providing us real-world learning on how to do everything, and they ended up becoming a real extension of our team.”
In fact, Ben said the Quisitive team and the Builders FirstSource team are in constant contact through Microsoft Teams chats.
“We consider Quisitive to be a significant part of our long-term Microsoft strategy, not a third-party consultant. They are an absolute key value partner in all of our decision making,” he said, adding that Quisitive has helped to educate the leadership team at Builders FirstSource on Microsoft maturity and advances over the last several years.
“We look to satisfy our clients’ needs not only in terms of what is contained in a statement of work, but also in other areas where we can provide partnership and leadership to help clients reach their full digital transformation goals, productivity goals, and cost goals.” said Dave Hickman, VP of Global Delivery, Quisitive. “With a client like Builders FirstSource, we’re able to have those discussions at a greater level, addressing the technical needs while ensuring the engineering tracks to business strategy.”
Building A Bigger Company
This strong partnership became even more critical to Ben and his team at Builders FirstSource when, in 2020, the company merged with BMC Stock Holdings Inc. (BMC). BMC is one of the country’s leading providers of diversified building materials and solutions to new construction builders and remodelers.
The result of the merger meant that overnight the combined organization ballooned to 26,000 team members, with a presence in 40 states, and a network of 550 distribution and manufacturing locations. This meant the company’s technology stack was suddenly also twice the size.
“We had such a great relationship with Quisitive that we started talking to them right away about a tenant-to-tenant migration,” Ben said. To date, Quisitive has completed an analysis of the environments, with the actual merging of tenants to be tackled once other integration activities are completed.
“If I were speaking to a peer at another company, I would tell them that I would strongly recommend working with Quisitive as a strategic partner if they want to leapfrog their Microsoft maturity. Quisitive is a great long-term partner, and really stepped up to the challenge,” Ben said.
“To sum it up, I would say that Quisitive routinely exceeded my expectations despite my expectations being significant. You cannot beat that.”
