Time indicators in Microsoft Defender for Cloud assessments
Published May 11 2021 08:24 AM 3,226 Views
Microsoft

Microsoft Defender for Cloud uses assessments to determine if a resource is flagged as healthy or unhealthy or if a recommendation is not applicable to it. Azure Resource Graph and Defender for Cloud’s REST APIs are two great starting points for automations around these assessments. However, without knowing when an assessment has been evaluated for the first time or when a particular resource’s health state has recently changed, it is hard to determine how current the actual assessment result is. I am beyond excited to announce that the Defender for Cloud product group has you covered as of now!

 

We recently added two new time indicator fields to both Azure Resource Graph and Microsoft.security/assessments REST API provider to help you be even more successful in creating automations around Cloud Security Posture Management (CSPM). The statusChangeDate field will indicate when a resource’s status has recently changed, for example from healthy to unhealthy, whereas the firstEvaluationDate field explains when a resource has been evaluated for the first time.

 

Time indicators fields in a REST responseTime indicators fields in a REST response

Although it seems like only a little information to be added to an assessment result, these two new fields enable a variety of new automations that will help you keep track of improving your organization’s security posture. For example, you can use that data in a custom workbook to show the average time it needs for your resource owners to remediate a particular security control or recommendation. Or think of an automation that sends you a regular list with the latest resources that have been created with open recommendations. Another idea would be an automation that helps you “penalize” your resource owners by sending a notification that tells them they have had open recommendations on their resources for a particular number of days so they are supposed to focus on closing the gaps.

 

With this article, I want to give you some help to start with using time indicators in your new automations.

 

Time indicators in Azure Resource Graph

As you might know, Microsoft Defender for Cloud leverages Azure Resource Graph (ARG) to publish information about unhealthy resources in the securityResources ARG table. The following KQL (Kusto Query Language) query 

will show all assessments and their corresponding policy initiatives that have recently changed their assessment status to unhealthy:

 

 

securityresources
| where type =~ "microsoft.security/assessments"
| extend assessmentStatusCode = tostring(properties.status.code)
| where assessmentStatusCode =~ "unhealthy"
| extend firstEvaluationDate = todatetime(properties.status.firstEvaluationDate)
| extend statusChangeDate = todatetime(properties.status.statusChangeDate)
| where statusChangeDate > firstEvaluationDate

 

 

Time indicators within that context are stored in the properties.status.firstEvaluationDate and properties.status.statusChangeDate fields. The query above has also been published to our Microsoft Defender for Cloud Github repository where you can always find the latest version.

 

Time indicators in REST APIs

Besides using ARG, Microsoft.security/assessments API provider can be used to query the same information. The team recently published a new API version (2021-06-01), but you can also use the new fields with all legacy API versions (2020-01-01 and 2019-01-01-preview) by adding an additional parameter to the GET request. The request will then look like this:

 

 

GET https://management.azure.com/subscriptions/{{subscriptionId}}/providers/Microsoft.Security/assessments?api-version=2020-01-01&$expand=statusEvaluationDates

 

 

where expand=statusEvaluationDates is the new parameter to be added. As a result, the two new fields are shown within the properties.status section of the reply, as shown in the picture below.

 

Postman result when requesting information from the microsoft.security/assessments API providerPostman result when requesting information from the microsoft.security/assessments API provider

 As always when it comes to automation, it’s all about fantasy and the imagination of what might be possible with new features. To give you a head start, I’ve already created a Logic App that will send a weekly report to list resources that have recently changed to unhealthy.

 

The Logic App runs on a recurrence trigger and leverages the following KQL query within the context of a REST API POST command to pull all resource IDs that have become unhealthy within the last 7 days.

 

 

securityresources
| where type =~ 'microsoft.security/assessments'
| extend assessmentStatusCode = tostring(properties.status.code)
| where assessmentStatusCode =~ 'unhealthy'
| extend statusChangeDate = todatetime(properties.status.statusChangeDate)
| extend resourceId = tostring(properties.resourceDetails.Id)
| extend displayName = tostring(properties.displayName)
| where statusChangeDate > todatetime(now(-7d))
| distinct resourceId, displayName

 

 

 

After that, doing some internal magic, the playbook will leverage two other KQL queries to determine if the unhealthy resource in question is a resource or resource container (such as a subscription), and will then compose a new HTML email body and send it to the address(es) that you determine when deploying the automation to your environment. The automation has been published to the Defender for Cloud Github repository and can directly be deployed from there, using the provided ARM template.

 

Why using KQL in a Logic App?

Using a single HTTP post request against the Azure Resource Graph REST API provider lets you retrieve a list of resources and pre-filter the output instead of pulling information for every resource using a separate REST GET call. Leveraging the KQL query means that with a single API request you will get all the information pre-filtered in a very quick way, preventing throttling issues and enhancing automation speed.

 

Now it's your turn: go ahead, deploy the automation, play around with time indicators and let us know if the new fields are helpful for you and if you have other ideas of using these fields in other automation scenarios.

 

Happy testing and best regards,

Tom

1 Comment
Co-Authors
Version history
Last update:
‎Oct 21 2021 04:27 AM
Updated by: