Connect Azure Assets to Azure Defender

 

Explore & Manage Your Resources With Asset Inventory

A single page is provided by the asset inventory page of Azure Security Center for viewing the security posture of the resources you've connected to Security Center and whenever any of the resources has outstanding recommendations, they'll automatically appear into the inventory. You can use this view and its filters to address such questions as:

• Which of my subscriptions with Azure Defender enabled have outstanding recommendations?
• Which of my machines with the tag 'Production' are missing the Log Analytics agent?
• How many of my machines tagged with a specific tag have outstanding recommendations?
• How many resources in a specific resource group have security findings from a vulnerability assessment service?

The asset management possibilities for this tool are substantial and continue to grow.

How does asset inventory work?

An Azure service known as the Azure Resources Graph (ARG) is utilized by the asset inventory that provides the ability to query the Security Center's security posture data across multiple subscriptions and is designed to offer efficient resource exploration with the ability to query at scale. Using the Kusto Query Language (KQL), asset inventory is capable of producing  deep insights quickly by cross-referencing ASC data with the other resource properties.

How to use asset inventory?

• From Security Center's sidebar, select Inventory.
• Use the filter by name box to display a specific resource, or use the filters as described below.
• Select the relevant options in the filters to create the specific theory you want to perform.
• To use the security findings contain filter, enter free text from the ID, security check, or CVE name of a vulnerability finding to filter to the affected resources.   

Configure Auto Provisioning

Data collection is required to provide visibility into the missing updates, misconfigured OS security settings, endpoint protection status, and health as well as threat protection and it is only needed for compute resources (VMs, virtual machine scale sets, IaaS containers, and non-Azure computers). You can easily gain from the Azure Security Center even if you don't provision agents; but, you will have limited security, and the capabilities listed above are not supported. Data is collected using:

• The Log Analytics agent, which reads various security-related configurations and event logs from the machine as well as copies the data to your workspace for analysis. Examples of such data are operating system type version, operating system logs (Windows event logs), running processes, ,machine name, IP addresses, and logged in user.

• Security extensions, such as the Azure policy Add-on for Kubernetes, which can also provide data to the Security Center regarding specialized resource types.

 Why use auto provisioning?

An Auto provisioning page is capable of installing any of the agents and extensions described on it  manually. However, it also reduces the management caapbility by installing all the required agents and extensions on existing- and new- machines to ensure faster security coverage for all the supported resources.

How does auto provisioning work?

Security Center's auto provisioning settings have a toggle for each type of supported extension and whenever you enable auto provisioning of an extension, the appropriate Deploy can be assigned to ensure that the extension is provisioned on all the existing and future resources of that type.

Information for Azure Sentinel Users

The security events collection within the context of a single workspace can be configured from either Azure Security Center or Azure Sentinel, but not both, but if you want to add Azure Sentinel to a workspace that is already getting alerts from the Azure Security Center and is set to collect the Security Events, you can have following two options:

• Leave the Security Events collection in the Azure Security Center as it is. You will be able to query and analyse these events in Azure Sentinel as well as Azure Defender. However, you will not be able to monitor the connector's connectivity status or change its configuration in Azure Sentinel. If this is important to you, then consider the second option. 

• Disable the Security Events collection in Azure Security Center. Then add the Security Events connector in the Azure Sentinel. As with the first option, you will be able to query and analyze events in both the Azure Sentinel as well as Azure Defender/ASC, but you will now be able to monitor the connector's connectivity status or change its configuration in- and only in- Azure Sentinel. 

What event type are stored in "Common" and "Minimal"?

To determine the events for the Common and Minimal options, we should work with the customers and industry standards to learn about the unfiltered frequency of each event as well as their usage. The following guidelines can be used in this process:

• Minimal- Make sure that this set covers only events that might indicate a successful breach and important events that have a low volume. For example, this set contains user successful and failed login (event IDs 4624, 4625), but it doesn't contain sign out, which is important for auditing but not meaningful for detection and has relatively high volume. Most of the data volume of this set is the login events and process creation events (event ID 4688). 

• Common- Provide a full user audit trail in this set. For example, this set contains both the user logins and user sign outs (event ID 4634). We include the auditing actions like the security group changes, key domain controller Kerberos operations, and other events that are recommended by the industry organizations. 

Events with very low volume were included in the Common set as the main motivation to choose it over all the events is to reduce the volume and filter out specific events.