Comparing Azure vulnerability scanning solutions | Quisitive

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:

FAQ’s:

Figure 2 : Two machines with one onboarded to each vulnerability scanner.

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.

Image of selecting security extensions in MDCA

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:

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!

Automating the MCAS deployment

Managing API tokens

Builders FirstSource Study Feature Image - House construction with the Builders Firstsource logo overlaid
Quisitive Constructs Strategic Relationship with Builders FirstSource
Learn how Quisitive helped Builders FirstSource build their Microsoft maturity to support their growing company in this case study.
Builders_FirstSource_Logo

In this case study:

Client: Builders FirstSource, Inc.

Industry: Retail

Products and Services:  Microsoft 365 Exchange, OneDrive, Azure and Microsoft Defender Antivirus

Country: USA

“We wanted to be taught to fish. We did not want them to come in, do the heavy lifting, and leave… 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.”
Ben Richard
Vice President, IT Operations, Builders FirstSource

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.”

“With the plethora of Microsoft products and skews available both in pilot mode and general availability, it becomes tricky to know which products to implement and how best to implement them. With a partner like Quisitive, who maintains a close connection with Microsoft as well as understands and utilizes these tools themselves, it becomes possible to fully optimize these products for strategic use. With their improved Microsoft stack, Builders FirstSource is set up to support the needs of their growing business.”
Dave Hickman
VP, Global Delivery, Quisitive

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.”