Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
maxLevel2
typeflat

...

Note

You need the Admin level permissions on the Azure portal as the subscription setup will require admin consent API permissions, authentications, and audits.

Action

Steps

1

Register and configure the application

  1. Go to Azure portal and click on Azure Active Directory.

  2. Click on App registration on the left-menu side. Then click on + New registration.

  3. On the Register and Application page:

    1. Name the application.

    2. Select Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) in Supported Accounts type.

    3. In Redirect URI (optional) leave it as default (blank).

    4. Click Register.

  4. App registration page will open. Click on your app to configure it and give it permissions. You will see your app’s dashboard with information (docs, endpoints, etc.) when clicking it.

  5. Click Authentication on the left-menu side, then choose + Add a platform and select Mobile and desktop application.

  6. Select the three redirects URIs:

    • https://login.microsoftonline.com/common/oauth2/nativeclient

    • https://login.live.com/oauth20_desktop.srf

    • msale36f3a02-3eef-437b-874e-8a0aa29a2bf0://auth

  7. Click Configure.

2

Grant the required permissions

  1. Go to API permissions on the left-menu side.

  2. Click + Add permission in case you don’t have Microsoft Graph in the API/Permission list.

  3. Select Application permissions and check SecurityEvents.Read.All.

  4. Check the following permissions: AuditLog.Read.All,Directory.Read.All and User.Read.All. If you did everything correctly, permissions will display.

  5. Select Grant admin consent for the applications.

Info

You do not need to activate permissions if you are not going to use its corresponding resource. Check the Permissions reference per service section for a detailed breakdown on resource and their needed permissions.

3

Obtain the requires credentials for the collector

  1. Go to Certificates & Secrets, select + New client secret . Named it and copy the token value.

  2. Go to Overview to get your Tenant ID and Client ID and copy both values.

Note

The token will display only once. You will need to create another one if you didn’t copy it the first time.

...

In versions 1.X of the collector, some services had a config parameter tag_version with values v1or v2. The effect of this parameter is that the destination table for these services will be different. These are the destination tables according to the tag_version value:

v1

v2 (default)

cloud.msgraph.security.score

cloud.office365.security.score

cloud.msgraph.security.scorecontrol

cloud.office365.security.scorecontrol

In the new collector 2.0.0, the old config parameter tag_version has been removed. The same effect as v1can be made using override_tag, with these values:

Service

override_tag (to obtain the behaviour equivalent to tag_version: v1)

secure_scores

cloud.msgraph.security.scores.2

secure_score_control_profiles

cloud.msgraph.security.scorecontrol.2

For instance, if we have this in the old config:

...

However, as there are alerts of several types, in version 2.0.0 alerts are categorized according to their vendorInformation-provider field (their vendor) and sent to different tables:

Vendor

Old table

New table

IPC

cloud.msgraph.security.alerts

cloud.azure.ad.alerts

MCAS

cloud.office365.cloud_apps.alerts

Microsoft Defender ATP

cloud.office365.endpoint.alerts

Microsoft 365 Defender

cloud.office365.endpoint.alerts

Office 365 Security and Compliance

cloud.office365.security.alerts

Azure Sentinel

cloud.azure.sentinel.alerts

ASC

cloud.office365.identity.alerts

Azure Advanced Threat Protection

cloud.azure.securitycenter.alerts

Others

cloud.msgraph.security.alerts

It is possible to avoid this feature and send all alerts to the same table by editing the config file and changing the tag:

...