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.

...

Release

Released on

Release type

Details

Recommendations

v2.0.0

Status
colourGreen
titleIMPROVEMENT

Improvements

  • Complete reimplementation of the collector, refactoring all the services

Recommended version

v1.7.1

Status
colourPurple
titleNEW FEATURE

Status
colourGreen
titleIMPROVEMENT

Status
colourRed
titleBUG FIX

New features

  • time_delta_in_days can now be overwritten in the user configuration by override_time_delta_in_days in all the service that are “time-based”. This new parameter cannot be combined with reset_persistence_auth and/or start_time.

Improvements

  • The state is now persisted more frequently for most of the services. This means that, in case of a collector restart, the chances of duplicating data have been reduced considerably, as the collector will continue pulling data from the same point where it was when the collector was stopped.

Bug Fixing

  • The collector will get the most recent token available before performing any new request, reducing the possibilities to get a 401 code as a response.

  • The 504 code responses were returned many time; some of them for having asked for too old data. This used to cause a locking state in the collector, as it was not able to continue. Some mechanisms has been added to avoid requiring that old data to the API. Anyway, if a 504 appears now for any other reason, the improvement related to persisting the state frequently makes the collector continue collecting correctly after the service restart.

Upgrade

v1.7.0

 

Status
colourPurple
titleNEW FEATURE

Status
colourGreen
titleIMPROVEMENT

Status
colourRed
titleBUG FIX

New features:

  • alerts_v2 service included, keeping old alerts service for compatibility.

  • Compliance for MS 365 GCC High US environments added.

Improvements:

  • Update DCSDK from 1.8.0 to 1.9.2

Bug Fixing:

  • The collector now keeps retrieving events when it is up-to-date.

  • Added extra protection to refresh token and avoid 401 status errors.

  • When a 401 status code is received from a response, the collector tries the request again using the access_token available in the collector_variables, instead of raising en Error. This definitely fixes the bug that used to make the collector restart due to 401 errors.

  • A vendor thread termination event has been set, including three different check points in the thread's run method, as a protection against non-terminated vendor threads, causing the alerts service to stop. Some extra logging has also been added to identify the root cause in case this keeps happening.

Recommended versionUpgrade

v1.6.2

Status
colourRed
titleBUG FIX

Status
colourGreen
titleIMPROVEMENT

Improvements:

  • Update DCSDK from 1.6.0 to 1.8.0

Bug Fixing:

  • Fix in the service urls: they were not being formatted correctly with the start_time variable, which allows the user to select the date from which they want to collect events.

  • Updated the limits of the API: The limits have been modified with the official values. This fixes throttling issues.

  • Updated the default value of star_time from 61 days in the past to 30, as this is the maximum limit the API allows.

Upgrade

v1.6.0

Status
colourPurple
titleNEW FEATURE

New features:

  • The pulling mechanism now uses a sliding window to avoid event loss and duplication.

Improvements:

  • DevoCollectorSDK upgraded to v1.6.0:

    • Added:

      • More log traces related to execution environment details.

      • Global rate limiters functionality.

      • Extra checks for supporting MacOS as development environment.

      • Obfuscation functionality.

    • Changed:

      • Some log traces now are shown less frequently.

      • The default value for the logging frequency for "main" processes has been changed (to 120 seconds).

      • Updated some Python Packages.

      • Controlled stopping functionality more stable when using the "template".

      • Improved some log messages related to Devo certificates (when using the Devo sender).

      • Validate json objects before saving them to persistence (using filesystem).

Upgrade

v1.4.2

Status
colourRed
titleBUG FIX

Fixed bugs:

  • Fixes bug with non-time-based puller state.

Upgrade

v1.4.1

Status
colourRed
titleBUG FIX

Fixed bugs:

  • Fix error with vendor state when checking the reset_persistence_auth parameter.

  • Allow using v2 tags for secure_scores and secure_scores_control_profile tags.

  • Add missing Devo metadata into events.

Upgrade

v1.4.0

Status
colourGreen
titleIMPROVEMENT

Improvements:

  • Automatic outdated start_time correction for audit-based services.

    • New “reset persistence” functionality.

Upgrade

v1.3.0

Status
colourGreen
titleIMPROVEMENT

Status
colourRed
titleBUG FIX

Improvements:

  • start_time configuration parameter normalization for audit and provisioning services.

  • Upgraded devocollectorsdk from 1.4.0 to 1.4.4b:

    • Added:

      • New "templates" functionality.

      • New controlled stopping condition when any input thread fatally fails.

      • Log traces for knowing the execution environment status (debug mode).

    • Changed:

      • Improved log trace details when runtime exceptions happen

      • Refactored source code structure

      • Fixes in the current puller template version

      • The Docker container exits with the proper error code

Bug fixing:

  • Correct token validation when a Partial Content response is received.

  • Use appropriate destination tag for provisioning events.

Upgrade

v1.2.0

Status
colourPurple
titleNEW FEATURE

Status
colourGreen
titleIMPROVEMENT

New features:

  • New supported sources

    • Sign In (signIn service)

    • Audit (audit service)

    • Provisioning (provisioning service)

  • Previous services modification

    • The new tagging introduced in the previous v1.1.3 release is now customizable through the tag_version service parameter. The default tagging has been reverted to the original one.

    • The alerts source, when setting the tag_version to v2, will try to categorize the events by applying different tags based on the event’s provider.

Improvements:

  • Token validation is now performed against the corresponding endpoint.

Upgrade