Find your Microsoft Sentinel data connector

Rakendub:: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure portal

This article lists all supported, out-of-the-box data connectors and links to each connector's deployment steps.

Important

Note that Microsoft Sentinel data connectors are currently in Preview. The Azure Preview Supplemental Terms include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal. All customers using Microsoft Sentinel in the Azure portal will be redirected to the Defender portal and will use Microsoft Sentinel in the Defender portal only. Starting in July 2025, many new customers are automatically onboarded and redirected to the Defender portal.If you're still using Microsoft Sentinel in the Azure portal, we recommend that you start planning your transition to the Defender portal to ensure a smooth transition and take full advantage of the unified security operations experience offered by Microsoft Defender. For more information, see It’s Time to Move: Retiring Microsoft Sentinel’s Azure portal for greater security.

Data connectors are available as part of the following offerings:

Solutions: Many data connectors are deployed as part of Microsoft Sentinel solution together with related content like analytics rules, workbooks, and playbooks. For more information, see the Microsoft Sentinel solutions catalog.
Community connectors: More data connectors are provided by the Microsoft Sentinel community and can be found in the Azure Marketplace. Documentation for community data connectors is the responsibility of the organization that created the connector.
Custom connectors: If you have a data source that isn't listed or currently supported, you can also create your own, custom connector. For more information, see Resources for creating Microsoft Sentinel custom connectors.

Note

For information about feature availability in US Government clouds, see the Microsoft Sentinel tables in Cloud feature availability for US Government customers.

Data connector prerequisites

Each data connector has its own set of prerequisites. Prerequisites might include having specific permissions on your Azure workspace, subscription, or policy. You might also need to meet other requirements for the partner data source you're connecting to.

Prerequisites for each data connector are listed in this article and on the relevant data connector page in Microsoft Sentinel.

Azure Monitor agent (AMA) based data connectors require an internet connection from the system where the agent is installed. Enable port 443 outbound to allow a connection between the system where the agent is installed and Microsoft Sentinel.

Syslog and Common Event Format (CEF) connectors

Log collection from many security appliances and devices are supported by the data connectors Syslog via AMA or Common Event Format (CEF) via AMA in Microsoft Sentinel. To forward data to your Log Analytics workspace for Microsoft Sentinel, complete the steps in Ingest syslog and CEF messages to Microsoft Sentinel with the Azure Monitor Agent. These steps include installing the Microsoft Sentinel solution for a security appliance or device from the Content hub in Microsoft Sentinel. Then, configure the Syslog via AMA or Common Event Format (CEF) via AMA data connector that's appropriate for the Microsoft Sentinel solution you installed. Complete the setup by configuring the security device or appliance. Find instructions to configure your security device or appliance in one of the following articles:

Contact the solution provider for more information or where information is unavailable for the appliance or device.

Custom Logs via AMA connector

Filter and ingest logs in text-file format from network or security applications installed on Windows or Linux machines by using the Custom Logs via AMA connector in Microsoft Sentinel. For more information, see the following articles:

Sentinel data connectors

Note

The following table lists the data connectors that are available in the Microsoft Sentinel Content hub. The connectors are supported by the product vendor. For support, see the Supported by link.

Tip

For a list of tables ingested into Microsoft Sentinel and the connectors that ingest them, see Microsoft Sentinel tables and associated connectors.

1Password (Serverless)

Supported by: 1Password

The 1Password CCF connector allows the user to ingest 1Password Audit, Signin & ItemUsage events into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`OnePasswordEventLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

1Password API token: A 1Password API Token is required. See the 1Password documentation on how to create an API token.

Setup Instructions:

STEP 1 - Create a 1Password API token:

Follow the 1Password documentation for guidance on this step.

STEP 2 - Choose the correct base URL:

There are multiple 1Password servers which might host your events. The correct server depends on your license and region. Follow the 1Password documentation to choose the correct server. Input the base URL as displayed by the documentation (including 'https://' and without a trailing '/').

STEP 3 - Enter your 1Password Details:

Enter the 1Password base URL & API Token below:

Base Url: (Enter your Base Url)
API Token: (Enter your API Token)
Enable/Disable Connection

1Password (using Azure Functions)

Supported by: 1Password

The 1Password solution for Microsoft Sentinel enables you to ingest sign-in attempts, item usage, and audit events from your 1Password Business account using the 1Password Events Reporting API. This allows you to monitor and investigate events in 1Password in Microsoft Sentinel along with the other applications and services your organization uses.

Underlying Microsoft Technologies used:

This solution depends on the following technologies, and some of which may be in Preview state or may incur additional ingestion or operational costs:

Azure Functions

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`OnePasswordEventLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
1Password Events API Token: A 1Password Events API Token is required. For more information, see the 1Password API.

Note: A 1Password Business account is required

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to 1Password to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs from Azure. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the 1Password Events Reporting API

Follow these instructions provided by 1Password to obtain an Events Reporting API Token. Note: A 1Password Business account is required

STEP 2 - Deploy the functionApp using DeployToAzure button to create the table, dcr and the associated Azure Function

IMPORTANT: Before deploying the 1Password connector, a custom table needs to be created.

Option 1 - Azure Resource Manager (ARM) Template

This method provides an automated deployment of the 1Password connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace Name, Workspace Name, 1Password Events API Key, and URI.

The default Time Interval is set to five (5) minutes. If you'd like to modify the interval, you can adjust the Function App Timer Trigger accordingly (in the function.json file, post deployment) to prevent overlapping data ingestion.
Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

AbnormalSecurity (using Azure Function)

Supported by: Abnormal Security

The Abnormal Security data connector provides the capability to ingest threat and case logs into Microsoft Sentinel using the Abnormal Security Rest API.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ABNORMAL_THREAT_MESSAGES_CL`	No	No
`ABNORMAL_CASES_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Abnormal Security API Token: An Abnormal Security API Token is required. For more information, see Abnormal Security API. Note: An Abnormal Security account is required

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to Abnormal Security's REST API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1 - Configuration steps for the Abnormal Security API

Follow these instructions provided by Abnormal Security to configure the REST API integration. Note: An Abnormal Security account is required

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Abnormal Security data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Abnormal Security API Authorization Token, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

This method provides an automated deployment of the Abnormal Security connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Microsoft Sentinel Workspace ID, Microsoft Sentinel Shared Key and Abnormal Security REST API Key.

The default Time Interval is set to pull the last five (5) minutes of data. If the time interval needs to be modified, it is recommended to change the Function App Timer Trigger accordingly (in the function.json file, post deployment) to prevent overlapping data ingestion.

Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Abnormal Security data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. AbnormalSecurityXX).

e. Select a runtime: Choose Python 3.8.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): SENTINEL_WORKSPACE_ID SENTINEL_SHARED_KEY ABNORMAL_SECURITY_REST_API_TOKEN logAnalyticsUri (optional) (add any other settings required by the Function App) Set the uri value to: <add uri value>

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Azure Key Vault references documentation for further details.

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Agent 365

Supported by: Microsoft Corporation

Agent 365 data connector gives richer insights into AI agent activity by bringing AI agent telemetry from Agent 365, AI Foundry, and Copilot in the Microsoft Sentinel data lake to investigate agent behavior, tool usage, and execution with hunting, graph, and MCP workflows. Data from this connector is used to investigate AI agent behavior, tool usage, and execution in Microsoft Sentinel. If you have enabled these workflows, deactivating this connector will prevent those investigations from being performed.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion

Data collection rule support: Not currently supported

Setup Instructions:

AIShield

Supported by: AIShield

AIShield connector allows users to connect with AIShield custom defense mechanism logs with Microsoft Sentinel, allowing the creation of dynamic Dashboards, Workbooks, Notebooks and tailored Alerts to improve investigation and thwart attacks on AI systems. It gives users more insight into their organization's AI assets security posturing and improves their AI systems security operation capabilities.AIShield.GuArdIan analyzes the LLM generated content to identify and mitigate harmful content, safeguarding against legal, policy, role based, and usage based violations

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AIShield_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Note: Users should have utilized AIShield SaaS offering to conduct vulnerability analysis and deployed custom defense mechanisms generated along with their AI asset. Click here to know more or get in touch.

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected AIShield which is deployed with the Microsoft Sentinel Solution.

IMPORTANT: Before deploying the AIShield Connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Alibaba Cloud ActionTrail (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Alibaba Cloud ActionTrail data connector provides the capability to retrieve actiontrail events stored into Alibaba Cloud Simple Log Service and store them into Microsoft Sentinel through the SLS REST API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AliCloudActionTrailLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

SLS REST API Credentials/permissions: AliCloudAccessKeyId and AliCloudAccessKeySecret are required for making API calls. RAM policy statement with action of atleast log:GetLogStoreLogs over resource acs:log:{#regionId}:{#accountId}:project/{#ProjectName}/logstore/{#LogstoreName} is needed to grant a RAM user the permissions to call this operation.

Setup Instructions:

Configure access to AliCloud SLS API

Before using the API, you need to prepare your identity account and access key pair to effectively access the API.

We recommend that you use a Resource Access Management (RAM) user to call API operations. For more information, see create a RAM user and authorize the RAM user to access Simple Log Service.
Obtain the access key pair for the RAM user. For details see get Access Key pair.

Note the access key pair details for the next step.

Add ActionTrail Logstore

To enable the Alibaba Cloud ActionTrail connector for Microsoft Sentinel, click upon add ActionTrail Logstore, fill the form with the Alibaba Cloud environment configuration and click Connect.

Data Connectors Grid (configure in portal)

Alibaba Cloud Networking Data Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Alibaba Cloud Networking data connector provides the capability to ingest Alibaba Cloud networking data into Microsoft Sentinel through the Simple Log Service (SLS) REST API. Refer to API documentation for more information. The connector provides the ability to get VPC Flow Logs, WAF Logs, and API Gateway Logs from Alibaba Cloud.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AlibabaCloudVPCFlowLogs`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Alibaba Cloud SLS API access: Alibaba Cloud Simple Log Service access is required for the SLS API.

Setup Instructions:

Configure access to AliCloud SLS API

Before using the API, you need to prepare your identity account and access key pair to effectively access the API.

We recommend that you use a Resource Access Management (RAM) user to call API operations. For more information, see create a RAM user and authorize the RAM user to access Simple Log Service.
Obtain the access key pair for the RAM user. For details see get Access Key pair.

Note the access key pair details for the next step.

Data Connectors Grid (configure in portal)

AliCloud (using Azure Functions)

Supported by: Microsoft Corporation

The AliCloud data connector provides the capability to retrieve logs from cloud applications using the Cloud API and store events into Microsoft Sentinel through the REST API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AliCloud_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: AliCloudAccessKeyId and AliCloudAccessKey are required for making API calls.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Azure Blob Storage API to pull logs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected AliCloud which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the AliCloud API

Follow the instructions to obtain the credentials.

Obtain the AliCloudAccessKeyId and AliCloudAccessKey: log in the account, click on AccessKey Management then click View Secret.
Save credentials for using in the data connector.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the AliCloud data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the AliCloud data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the WorkspaceID, WorkspaceKey, AliCloudAccessKeyId, AliCloudAccessKey, AliCloudProjects and AppInsightsWorkspaceResourceID and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the AliCloud data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. AliCloudXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): WorkspaceID WorkspaceKey AliCloudAccessKeyId AliCloudAccessKey AliCloudProjects AppInsightsWorkspaceResourceID

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Amazon Web Services

Supported by: Microsoft Corporation

Instructions to connect to AWS and stream your CloudTrail logs into Microsoft Sentinel are shown during the installation process. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSCloudTrail`	Yes	Yes

Data collection rule support: Workspace transform DCR

Amazon Web Services CloudFront (via Codeless Connector Framework) (Preview)

Supported by: Microsoft Corporation

This data connector enables the integration of AWS CloudFront logs with Microsoft Sentinel to support advanced threat detection, investigation, and security monitoring. By utilizing Amazon S3 for log storage and Amazon SQS for message queuing, the connector reliably ingests CloudFront access logs into Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSCloudFront_AccessLog_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Ingesting AWS CloudFront logs in Microsoft Sentinel

List of Resources Required:

Open ID Connect (OIDC) web identity provider
IAM Role
Amazon S3 Bucket
Amazon SQS
AWS CloudFront configuration

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from an S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks.
Choose the ‘Specify template’ option, then ‘Upload a template file’ by clicking on ‘Choose file’ and selecting the appropriate CloudFormation template file provided below. click ‘Choose file’ and select the downloaded template.
Click 'Next' and 'Create stack'.

Template 1: OpenID connect authentication deployment: <variable value provided at install time>
Template 2: AWSCloudFront resources deployment: <variable value provided at install time>

Connect new collectors To enable AWS S3 for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

Amazon Web Services Elastic Load Balancing (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The AWS Elastic Load Balancing (ELB) connector for Microsoft Sentinel allows you to ingest access logs and flow logs from AWS Application Load Balancers (ALB), Network Load Balancers (NLB), and Gateway Load Balancers (GLB) into Microsoft Sentinel. These logs provide detailed information about requests processed by your load balancers and VPC traffic flows, enabling security monitoring, threat detection, and traffic analysis.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSALBAccessLogsData`	No	No

Data collection rule support: Not currently supported

Prerequisites:

AWS IAM Role ARN and SQS Queue: An AWS IAM Role ARN with cross-account access and an SQS Queue URL configured for S3 event notifications are required. See AWS ELB connector documentation for setup instructions.

Setup Instructions:

AWS CloudFormation Deployment To configure access on AWS, use CloudFormation templates to set up the environment to send logs from ALB, NLB and GLB to your Log Analytics Workspace.

Deployment steps:

Go to the Cloud Formation Templates, download the JSON template files.
Go to AWS CloudFormation Stacks.
First deploy the OIDCWebIdProvider.json template (skip if you already have an OIDC provider for Microsoft Sentinel).
Then deploy the AWSS3ELB.json template with your parameters.
Note down the following values from the stack outputs:
- IAMRoleArn
- ALBSQSQueueURL
- NLBSQSQueueURL
- NLBFlowLogsSQSQueueURL
- GLBFlowLogsSQSQueueURL

Post-deployment Configuration:

Once the CloudFormation stack is successfully deployed:

Go to the Resources tab in the stack.
Locate the created S3 bucket name.
In the S3 bucket, manually create the following folders:
- ALBLogs
- NLBAccessLogs
- NLBFlowLogs
- GLBFlowLogs

Sending Logs:

After folder creation, configure your AWS services to send logs to the appropriate folders:

ALB access logs -> ALBLogs/
NLB access logs -> NLBAccessLogs/
NLB flow logs -> NLBFlowLogs/
GLB flow logs -> GLBFlowLogs/

These logs will be ingested into the corresponding tables in your Log Analytics Workspace.

Table Mapping:

ALB access logs -> AWSALBAccessLogsData
NLB access logs -> AWSNLBAccessLogsData
NLB and GLB flow logs -> AWSELBFlowLogsData

Note: In the AWSELBFlowLogsData table, a column named LogType will indicate whether a row is from NLB flow logs or GLB flow logs.

Connect new collectors To enable the connector, click Add new collector, enter the required details, and click Connect.

Data Connectors Grid (configure in portal)

Amazon Web Services NetworkFirewall (via Codeless Connector Framework)

Supported by: Microsoft Corporation

This data connector allows you to ingest AWS Network Firewall logs into Microsoft Sentinel for advanced threat detection and security monitoring. By leveraging Amazon S3 and Amazon SQS, the connector forwards network traffic logs, intrusion detection alerts, and firewall events to Microsoft Sentinel, enabling real-time analysis and correlation with other security data

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSNetworkFirewallFlow`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Ingesting AWS NetworkFirewall logs in Microsoft Sentinel

List of Resources Required:

Open ID Connect (OIDC) web identity provider
IAM Role
Amazon S3 Bucket
Amazon SQS
AWSNetworkFirewall configuration
Follow this instructions for AWS NetworkFirewall Data connector configuration

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from an S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks.
Choose the ‘Specify template’ option, then ‘Upload a template file’ by clicking on ‘Choose file’ and selecting the appropriate CloudFormation template file provided below. click ‘Choose file’ and select the downloaded template.
Click 'Next' and 'Create stack'.

Template 1: OpenID connect authentication deployment: <variable value provided at install time>
Template 2: AWSNetworkFirewall resources deployment: <variable value provided at install time>

Connect new collectors To enable AWS S3 for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

Amazon Web Services S3

Supported by: Microsoft Corporation

This connector allows you to ingest AWS service logs, collected in AWS S3 buckets, to Microsoft Sentinel. The currently supported data types are:

AWS CloudTrail
VPC Flow Logs
AWS GuardDuty
AWSCloudWatch

For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSGuardDuty`	Yes	Yes
`AWSVPCFlow`	Yes	Yes
`AWSCloudTrail`	Yes	Yes
`AWSCloudWatch`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Environment: You must have the following AWS resources defined and configured: S3, Simple Queue Service (SQS), IAM roles and permissions policies, and the AWS services whose logs you want to collect.

Setup Instructions:

1. Set up your AWS environment

There are two options for setting up your AWS environment to send logs from an S3 bucket to your Log Analytics Workspace:

Setup with PowerShell script (recommended)

Run script to set up the environment: <variable value provided at install time>
External ID (Workspace ID): <variable value provided at install time>

Manual Setup

Follow the instruction in the following link to set up the environment: Connect AWS S3 to Microsoft Sentinel

2. Add connection

Amazon Web Services S3 DNS Route53 (via Codeless Connector Framework)

Supported by: Microsoft Corporation

This connector enables ingestion of AWS Route 53 DNS logs into Microsoft Sentinel for enhanced visibility and threat detection. It supports DNS Resolver query logs ingested directly from AWS S3 buckets, while Public DNS query logs and Route 53 audit logs can be ingested using Microsoft Sentinel's AWS CloudWatch and CloudTrail connectors. Comprehensive instructions are provided to guide you through the setup of each log type. Leverage this connector to monitor DNS activity, detect potential threats, and improve your security posture in cloud environments.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSRoute53Resolver`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

AWS Route53

This connector enables the ingestion of AWS Route 53 DNS logs into Microsoft Sentinel, providing enhanced visibility into DNS activity and strengthening threat detection capabilities. It supports direct ingestion of DNS Resolver query logs from AWS S3 buckets, while Public DNS query logs and Route 53 audit logs can be ingested via Microsoft Sentinel’s AWS CloudWatch and CloudTrail connectors. Detailed setup instructions are provided for each log type. Use this connector to monitor DNS traffic, identify potential threats, and enhance your cloud security posture.

You can ingest the following type of logs from AWS Route 53 to Microsoft Sentinel:

Route 53 Resolver query logs
Route 53 Public Hosted zones query logs (via Microsoft Sentinel CloudWatch connector)
Route 53 audit logs (via Microsoft Sentinel CloudTrail connector)

Ingesting Route53 Resolver query logs in Microsoft Sentinel

List of Resources Required:

Open ID Connect (OIDC) web identity provider
IAM Role
Amazon S3 Bucket
Amazon SQS
Route 53 Resolver query logging configuration
VPC to associate with Route53 Resolver query log config

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from an S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks.
Choose the ‘Specify template’ option, then ‘Upload a template file’ by clicking on ‘Choose file’ and selecting the appropriate CloudFormation template file provided below. click ‘Choose file’ and select the downloaded template.
Click 'Next' and 'Create stack'.

Template 1: OpenID connect authentication deployment: <variable value provided at install time>
Template 2: AWS Route53 resources deployment: <variable value provided at install time>

Connect new collectors To enable Amazon Web Services S3 DNS Route53 for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

Ingesting Route 53 Public Hosted zones query logs (via Microsoft Sentinel CloudWatch connector)

Public Hosted zone query logs are exported to CloudWatch service in AWS. We can use 'Amazon Web Services S3' connector to ingest CloudWatch logs from AWS to Microsoft Sentinel.

Step 1: Configure logging for Public DNS queries

Sign in to the AWS Management Console and open the Route 53 console at AWS Route 53.
Navigate to Route 53 > Hosted zones.
Choose the Public hosted zone that you want to configure query logging for.
In the Hosted zone details pane, click "Configure query logging".
Choose an existing log group or create a new log group.
Choose Create.

Step 2: Configure Amazon Web Services S3 data connector for AWS CloudWatch

AWS CloudWatch logs can be exported to an S3 bucket using lambda function. To ingest Public DNS queries from AWS CloudWatch to S3 bucket and then to Microsoft Sentinel, follow the instructions provided in the Amazon Web Services S3 connector.

Ingesting Route 53 audit logs (via Microsoft Sentinel CloudTrail connector)

Route 53 audit logs i.e. the logs related to actions taken by user, role or AWS service in Route 53 can be exported to an S3 bucket via AWS CloudTrail service. We can use 'Amazon Web Services S3' connector to ingest CloudTrail logs from AWS to Microsoft Sentinel.

Step 1: Configure logging for AWS Route 53 Audit logs

Sign in to the AWS Management Console and open the CloudTrail console at AWS CloudTrail
If you do not have an existing trail, click on 'Create trail'
Enter a name for your trail in the Trail name field.
Select Create new S3 bucket (you may also choose to use an existing S3 bucket).
Leave the other settings as default, and click Next.
Select Event type, make sure Management events is selected.
Select API activity, 'Read' and 'Write'
Click Next.
Review the settings and click 'Create trail'.

Step 2: Configure Amazon Web Services S3 data connector for AWS CloudTrail

To ingest audit and management logs from AWS CloudTrail to Microsoft Sentinel, follow the instructions provided in the Amazon Web Services S3 connector

Amazon Web Services S3 WAF

Supported by: Microsoft Corporation

This connector allows you to ingest AWS WAF logs, collected in AWS S3 buckets, to Microsoft Sentinel. AWS WAF logs are detailed records of traffic that web access control lists (ACLs) analyze, which are essential for maintaining the security and performance of web applications. These logs contain information such as the time AWS WAF received the request, the specifics of the request, and the action taken by the rule that the request matched.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSWAF`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from an S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks.
Choose the ‘Specify template’ option, then ‘Upload a template file’ by clicking on ‘Choose file’ and selecting the appropriate CloudFormation template file provided below. click ‘Choose file’ and select the downloaded template.
Click 'Next' and 'Create stack'.

Template 1: OpenID connect authentication deployment: <variable value provided at install time>
Template 2: AWS WAF resources deployment: <variable value provided at install time>

Connect new collectors To enable AWS S3 for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

Anvilogic

Supported by: Anvilogic

The Anvilogic data connector allows you to pull events of interest generated in the Anvilogic ADX cluster into your Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Anvilogic_Alerts_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Anvilogic Application Registration Client ID and Client Secret: To access the Anvilogic ADX we require the client id and client secret from the Anvilogic app registration

Setup Instructions:

Connect to Anvilogic to start collecting events of interest in Microsoft Sentinel

Complete the form to ingest Anvilogic Alerts into your Microsoft Sentinel

Token Endpoint: (https://login[.]microsoftonline[.]com/<tenant_id>/oauth2/v2.0/token)
Anvilogic ADX Scope: (<avl_adx_uri>/.default)
Anvilogic ADX Request URI: (<avl_adx_uri>/v2/rest/query)

ARGOS Cloud Security

Supported by: ARGOS Cloud Security

The ARGOS Cloud Security integration for Microsoft Sentinel allows you to have all your important cloud security events in one place. This enables you to easily create dashboards, alerts, and correlate events across multiple systems. Overall this will improve your organization's security posture and security incident response.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ARGOS_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

1. Subscribe to ARGOS

Ensure you already own an ARGOS Subscription. If not, browse to ARGOS Cloud Security and sign up to ARGOS.

Alternatively, you can also purchase ARGOS via the Azure Marketplace.

2. Configure Sentinel integration from ARGOS

Configure ARGOS to forward any new detections to your Sentinel workspace by providing ARGOS with your Workspace ID and Primary Key.

There is no need to deploy any custom infrastructure.

Enter the information into the ARGOS Sentinel configuration page.

New detections will automatically be forwarded.

Learn more about the integration

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Armis Alerts Activities (using Azure Functions)

Supported by: Armis Corporation

The Armis Alerts Activities connector gives the capability to ingest Armis Alerts and Activities into Microsoft Sentinel through the Armis REST API. Refer to the API documentation: https://<YourArmisInstance>.armis.com/api/v1/docs for more information. The connector provides the ability to get alert and activity information from the Armis platform and to identify and prioritize threats in your environment. Armis uses your existing infrastructure to discover and identify devices without having to deploy any agents.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Armis_Alerts_CL`	No	No
`Armis_Activities_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: Armis Secret Key is required. See the documentation to learn more about API on the https://<YourArmisInstance>.armis.com/api/v1/doc

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Armis API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias ArmisActivities/ArmisAlerts and load the function code. The function usually takes 10-15 minutes to activate after solution installation/update.

STEP 1 - Configuration steps for the Armis API

Follow these instructions to create an Armis API secret key.

Log into your Armis instance
Navigate to Settings -> API Management
If the secret key has not already been created, press the Create button to create the secret key
To access the secret key, press the Show button
The secret key can now be copied and used during the Armis Alerts Activities connector configuration

STEP 2 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.
Search for and select Microsoft Entra ID.
Under Manage, select App registrations > New registration.
Enter a display Name for your application.
Select Register to complete the initial app registration.
When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of Armis Alerts Activities Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 3 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of Armis Alerts Activities Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.
Select Certificates & secrets > Client secrets > New client secret.
Add a description for your client secret.
Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.
Select Add.
Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of Armis Alerts Activities Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 4 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.
Go to Access control (IAM) from left panel.
Click on Add, and then select Add role assignment.
Select Contributor as role and click on next.
In Assign access to, select User, group, or service principal.
Click on add members and type your app name that you have created and select it.
Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 5 - Create a Keyvault

Follow these instructions to create a new Keyvault.

In the Azure portal, Go to Key vaults. Click create.
Select Subsciption, Resource Group and provide unique name of keyvault.

NOTE: Create a separate key vault for each API key within one workspace.

STEP 6 - Create Access Policy in Keyvault

Follow these instructions to create access policy in Keyvault.

Go to keyvaults, select your keyvault, go to Access policies on left side panel. Click create.
Select all keys & secrets permissions. Click next.
In the principal section, search by application name which was generated in STEP - 2. Click next.

NOTE: Ensure the Permission model in the Access Configuration of Key Vault is set to 'Vault access policy'

STEP 7 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Armis Alerts Activities data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.., as well as the Armis API Authorization Key(s)

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Armis connector.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the below information : Function Name Workspace ID Workspace Key Armis Secret Key Armis URL (https://<armis-instance>.armis.com/api/v1/) Armis Alert Table Name
Armis Activity Table Name Severity (Default: Low) Armis Schedule KeyVault Name Azure Client Id Azure Client Secret Tenant Id
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Armis Alerts Activities data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. ARMISXXXXX).

e. Select a runtime: Choose Python 3.11

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective values (case-sensitive): Workspace ID Workspace Key Armis Secret Key Armis URL (https://<armis-instance>.armis.com/api/v1/) Armis Alert Table Name Armis Activity Table Name Severity (Default: Low) Armis Schedule KeyVault Name Azure Client Id Azure Client Secret Tenant Id logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Armis Devices (using Azure Functions)

Supported by: Armis Corporation

The Armis Device connector gives the capability to ingest Armis Devices into Microsoft Sentinel through the Armis REST API. Refer to the API documentation: https://<YourArmisInstance>.armis.com/api/v1/docs for more information. The connector provides the ability to get device information from the Armis platform. Armis uses your existing infrastructure to discover and identify devices without having to deploy any agents. Armis can also integrate with your existing IT & security management tools to identify and classify each and every device, managed or unmanaged in your environment.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Armis_Devices_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: Armis Secret Key is required. See the documentation to learn more about API on the https://<YourArmisInstance>.armis.com/api/v1/doc

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Armis API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Follow these steps to create the Kusto functions alias, ArmisDevice

STEP 1 - Configuration steps for the Armis API

Follow these instructions to create an Armis API secret key.

Log into your Armis instance
Navigate to Settings -> API Management
If the secret key has not already been created, press the Create button to create the secret key
To access the secret key, press the Show button
The secret key can now be copied and used during the Armis Device connector configuration

STEP 2 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.
Search for and select Microsoft Entra ID.
Under Manage, select App registrations > New registration.
Enter a display Name for your application.
Select Register to complete the initial app registration.
When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of Armis Device Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 3 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of Armis Device Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.
Select Certificates & secrets > Client secrets > New client secret.
Add a description for your client secret.
Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.
Select Add.
Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of Armis Device Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 4 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.
Go to Access control (IAM) from left panel.
Click on Add, and then select Add role assignment.
Select Contributor as role and click on next.
In Assign access to, select User, group, or service principal.
Click on add members and type your app name that you have created and select it.
Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 5 - Create a Keyvault

Follow these instructions to create a new Keyvault.

In the Azure portal, Go to Key vaults. Click create.
Select Subsciption, Resource Group and provide unique name of keyvault.

NOTE: Create a separate key vault for each API key within one workspace.

STEP 6 - Create Access Policy in Keyvault

Follow these instructions to create access policy in Keyvault.

Go to keyvaults, select your keyvault, go to Access policies on left side panel. Click create.
Select all keys & secrets permissions. Click next.
In the principal section, search by application name which was generated in STEP - 2. Click next.

NOTE: Ensure the Permission model in the Access Configuration of Key Vault is set to 'Vault access policy'

STEP 7 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Armis Device data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.., as well as the Armis API Authorization Key(s)

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Armis connector.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the below information : Function Name Workspace ID Workspace Key Armis Secret Key Armis URL (https://<armis-instance>.armis.com/api/v1/) Armis Device Table Name Armis Schedule KeyVault Name Azure Client Id Azure Client Secret Tenant Id
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Armis Device data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. ARMISXXXXX).

e. Select a runtime: Choose Python 3.11

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective values (case-sensitive): Workspace ID Workspace Key Armis Secret Key Armis URL (https://<armis-instance>.armis.com/api/v1/) Armis Device Table Name Armis Schedule KeyVault Name Azure Client Id Azure Client Secret Tenant Id logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Atlassian Beacon Alerts

Supported by: DEFEND Ltd.

Atlassian Beacon is a cloud product that is built for Intelligent threat detection across the Atlassian platforms (Jira, Confluence, and Atlassian Admin). This can help users detect, investigate and respond to risky user activity for the Atlassian suite of products. The solution is a custom data connector from DEFEND Ltd. that is used to visualize the alerts ingested from Atlassian Beacon to Microsoft Sentinel via a Logic App.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`atlassian_beacon_alerts_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

1. Microsoft Sentinel

Navigate to the newly installed Logic App 'Atlassian Beacon Integration'
Navigate to 'Logic app designer'
Expand the 'When a HTTP request is received'
Copy the 'HTTP POST URL'

2. Atlassian Beacon

Login to Atlassian Beacon using an admin account
Navigate to 'SIEM forwarding' under SETTINGS
Paste the copied URL from Logic App in the text box
Click the 'Save' button

3. Testing and Validation

Login to Atlassian Beacon using an admin account
Navigate to 'SIEM forwarding' under SETTINGS
Click the 'Test' button right next to the newly configured webhook
Navigate to Microsoft Sentinel
Navigate to the newly installed Logic App
Check for the Logic App Run under 'Runs history'
Check for logs under the table name 'atlassian_beacon_alerts_CL' in 'Logs'
If the analytic rule has been enabled, the above Test alert should have created an incident in Microsoft Sentinel

Atlassian Confluence Audit (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Atlassian Confluence Audit data connector provides the capability to ingest Confluence Audit Records events into Microsoft Sentinel through the REST API. Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ConfluenceAuditLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Atlassian Confluence API access: Permission of Administer Confluence is required to get access to the Confluence Audit logs API. See Confluence API documentation to learn more about the audit API.

Setup Instructions:

Connect to Atlassian Confluence API to start collecting audit logs in Microsoft Sentinel

To enable the Atlassian Confluence connector for Microsoft Sentinel, click to add an organization, fill the form with the Confluence environment credentials and click to Connect. Follow these steps to create an API token.

Data Connectors Grid (configure in portal)

Atlassian Jira Audit (using Azure Functions)

Supported by: Microsoft Corporation

The Atlassian Jira Audit data connector provides the capability to ingest Jira Audit Records events into Microsoft Sentinel through the REST API. Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Jira_Audit_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: JiraAccessToken, JiraUsername is required for REST API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Jira REST API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Follow these steps to create the Kusto functions alias, JiraAudit

STEP 1 - Configuration steps for the Jira API

Follow the instructions to obtain the credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Workspace data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Jira Audit data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the JiraAccessToken, JiraUsername, JiraHomeSiteName (short site name part, as example HOMESITENAME from https://community.atlassian.com) and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Jira Audit data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. JiraAuditXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): JiraUsername JiraAccessToken JiraHomeSiteName WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Atlassian Jira Audit (via Codeless Connector Framework)

Supported by: Microsoft Corporation

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Jira_Audit_v2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Atlassian Jira API access: Permission of Administer Jira is required to get access to the Jira Audit logs API. See Jira API documentation to learn more about the audit API.

Setup Instructions:

To enable the Atlassian Jira connector for Microsoft Sentinel, click to add an organization, fill the form with the Jira environment credentials and click to Connect. Follow these steps to create an API token.

Data Connectors Grid (configure in portal)

Auth0 Logs (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Auth0 data connector allows ingesting logs from Auth0 API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework. It uses Auth0 API to fetch logs and it supports DCR-based ingestion time transformations that parses the received security data into a custom table so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Auth0Logs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

STEP 1 - Configuration steps for the Auth0 Management API

Follow the instructions to obtain the credentials.

In Auth0 Dashboard, go to [Applications > Applications]
Select your Application. This should be a [Machine-to-Machine] Application configured with at least [read:logs] and [read:logs_users] permissions.
Copy [Domain, ClientID, Client Secret]

Base API URL: (https://example.auth0.com)
Client ID: (Client ID)
Client Secret: (API Token)
Enable/Disable Connection

Automated Logic WebCTRL

Supported by: Microsoft Corporation

You can stream the audit logs from the WebCTRL SQL server hosted on Windows machines connected to your Microsoft Sentinel. This connection enables you to view dashboards, create custom alerts and improve investigation. This gives insights into your Industrial Control Systems that are monitored or controlled by the WebCTRL BAS application.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Event`	Yes	No

Data collection rule support: Workspace transform DCR

Setup Instructions:

1. Install and onboard the Microsoft agent for Windows.

Learn about agent setup and windows events onboarding.

You can skip this step if you have already installed the Microsoft agent for Windows

2. Configure Windows task to read the audit data and write it to windows events

Install and configure the Windows Scheduled Task to read the audit logs in SQL and write them as Windows Events. These Windows Events will be collected by the agent and forward to Microsoft Sentinel.

Notice that the data from all machines will be stored in the selected workspace

2.1 Copy the setup files to a location on the server.

2.2 Update the ALC-WebCTRL-AuditPull.ps1 (copied in above step) script parameters like the target database name and windows event id's. Refer comments in the script for more details.

2.3 Update the windows task settings in the ALC-WebCTRL-AuditPullTaskConfig.xml file that was copied in above step as per requirement. Refer comments in the file for more details.

2.4 Install windows tasks using the updated configs copied in the above steps

Run the following command in powershell from the directory where the setup files are copied in step 2.1: <variable value provided at install time>

3. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the Event schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, validate below steps for any run time issues:

Make sure that the scheduled task is created and is in running state in the Windows Task Scheduler.
Check for task execution errors in the history tab in Windows Task Scheduler for the newly created task in step 2.4
Make sure that the SQL Audit table consists new records while the scheduled windows task runs.

AWS EKS Data Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The AWS EKS data connector provides the capability to ingest audit logs from Amazon Elastic Kubernetes Service into Microsoft Sentinel. This connector focuses on EKS audit logs (JSON format) which contain detailed information about API server requests, authentication decisions, and cluster activities. The connector uses AWS SQS to receive notifications when new audit log files are exported to S3, ensuring real-time security monitoring and compliance tracking for your Kubernetes clusters.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSEKSLogs_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

1. AWS CloudFormation Deployment

Use the provided CloudFormation templates to configure the AWS environment for sending logs from AWS EKS to your Log Analytics Workspace.

Deploy CloudFormation Templates in AWS:

Navigate to the AWS CloudFormation Stacks.
Click Create stack and select With new resources.
Choose Upload a template file, then click Choose file to upload the appropriate CloudFormation template(Template 1 and 2 below) provided.
Follow the prompts and click Next to complete the stack creation.
After the stacks are created, navigation to the Outputs section. Run the scripts in step 1 and 2 from the output section, it stream log from eks to sqs.
In the same outputs section, Note down the Role ARN and SQS Queue URL which are going to be used in connect connector.

Template 1: OpenID Connect authentication provider deployment: <variable value provided at install time>
Template 2: AWS EKS Resources Deployment: <variable value provided at install time>

2. Connect new collectors

To enable AWS Security Hub Connector for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

SentinelRoleArn: (The AWS IAM Role ARN for cross-account access (e.g., arn:aws:iam::123456789012:role/SentinelRole))
SentinelSQSQueueURL: (The full AWS EKS queue URL (e.g., https://sqs.region.amazonaws.com/account-id/queue-name))

3. Connect

Enable the AWS EKS connector.

Enable/Disable Connection

AWS S3 Server Access Logs (via Codeless Connector Framework)

Supported by: Microsoft Corporation

This connector allows you to ingest AWS S3 Server Access Logs into Microsoft Sentinel. These logs contain detailed records for requests made to S3 buckets, including the type of request, resource accessed, requester information, and response details. These logs are useful for analyzing access patterns, debugging issues, and ensuring security compliance.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSS3ServerAccess`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Environment: You must have the following AWS resources defined and configured: S3 Bucket, Simple Queue Service (SQS), IAM roles and permissions policies.

Setup Instructions:

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from an AWS S3 Server Access logs to your Log Analytics Workspace.

Deploy CloudFormation Templates in AWS:

Navigate to the AWS CloudFormation Stacks.
Click Create stack and select With new resources.
Choose Upload a template file, then click Choose file to upload the appropriate CloudFormation template provided.
Follow the prompts and click Next to complete the stack creation.
After the stacks are created, note down the Role ARN and SQS Queue URL.

Template 1: OpenID Connect authentication provider deployment: <variable value provided at install time>
Template 2: AWS Server Access resources deployment: <variable value provided at install time>

Connect new collectors To enable AWS S3 Server Access Logs Connector for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

AWS Security Hub Findings (via Codeless Connector Framework)

Supported by: Microsoft Corporation

This connector enables the ingestion of AWS Security Hub Findings, which are collected in AWS S3 buckets, into Microsoft Sentinel. It helps streamline the process of monitoring and managing security alerts by integrating AWS Security Hub Findings with Microsoft Sentinel's advanced threat detection and response capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AWSSecurityHubFindings`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Environment: You must have the following AWS resources defined and configured: AWS Security Hub, Amazon Data Firehose, Amazon EventBridge, S3 Bucket, Simple Queue Service (SQS), IAM roles and permissions policies.

Setup Instructions:

AWS CloudFormation Deployment Use the provided CloudFormation templates to configure the AWS environment for sending logs from AWS Security Hub to your Log Analytics Workspace.

Deploy CloudFormation Templates in AWS:

Navigate to the AWS CloudFormation Stacks.
Click Create stack and select With new resources.
Choose Upload a template file, then click Choose file to upload the appropriate CloudFormation template provided.
Follow the prompts and click Next to complete the stack creation.
After the stacks are created, note down the Role ARN and SQS Queue URL.

Template 1: OpenID Connect authentication provider deployment: <variable value provided at install time>
Template 2: AWS Security Hub resources deployment: <variable value provided at install time>

Connect new collectors To enable AWS Security Hub Connector for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

Azure Activity

Supported by: Microsoft Corporation

Azure Activity Log is a subscription log that provides insight into subscription-level events that occur in Azure, including events from Azure Resource Manager operational data, service health events, write operations taken on the resources in your subscription, and the status of activities performed in Azure. For more information, see the Microsoft Sentinel documentation .

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureActivity`	No	No

Data collection rule support: Not currently supported

Azure Batch Account

Supported by: Microsoft Corporation

Azure Batch Account is a uniquely identified entity within the Batch service. Most Batch solutions use Azure Storage for storing resource files and output files, so each Batch account is usually associated with a corresponding storage account. This connector lets you stream your Azure Batch account diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Batch Account diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Batch Account log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Batch Account at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure CloudNGFW By Palo Alto Networks

Supported by: Palo Alto Networks

Cloud Next-Generation Firewall by Palo Alto Networks - an Azure Native ISV Service - is Palo Alto Networks Next-Generation Firewall (NGFW) delivered as a cloud-native service on Azure. You can discover Cloud NGFW in the Azure Marketplace and consume it in your Azure Virtual Networks (VNet). With Cloud NGFW, you can access the core NGFW capabilities such as App-ID, URL filtering based technologies. It provides threat prevention and detection through cloud-delivered security services and threat prevention signatures. The connector allows you to easily connect your Cloud NGFW logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization's network and improves your security operation capabilities. For more information, see the Cloud NGFW for Azure documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`fluentbit_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Cloud NGFW by Palo Alto Networks to Microsoft Sentinel

Enable Log Settings on All Cloud NGFWs by Palo Alto Networks.

Inside your Cloud NGFW resource:

Navigate to the Log Settings from the homepage.
Ensure the Enable Log Settings checkbox is checked.
From the Log Settings drop-down, choose the desired Log Analytics Workspace.
Confirm your selections and configurations.
Click Save to apply the settings.

Azure Cognitive Search

Supported by: Microsoft Corporation

Azure Cognitive Search is a cloud search service that gives developers infrastructure, APIs, and tools for building a rich search experience over private, heterogeneous content in web, mobile, and enterprise applications. This connector lets you stream your Azure Cognitive Search diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Cognitive Search diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Cognitive Search log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Cognitive Search at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure DDoS Protection

Supported by: Microsoft Corporation

Connect to Azure DDoS Protection Standard logs via Public IP Address Diagnostic Logs. In addition to the core DDoS protection in the platform, Azure DDoS Protection Standard provides advanced DDoS mitigation capabilities against network attacks. It's automatically tuned to protect your specific Azure resources. Protection is simple to enable during the creation of new virtual networks. It can also be done after creation and requires no application or resource changes. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Azure DevOps Audit Logs (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Azure DevOps Audit Logs data connector allows you to ingest audit events from Azure DevOps into Microsoft Sentinel. This data connector is built using the Microsoft Sentinel Codeless Connector Framework, ensuring seamless integration. It leverages the Azure DevOps Audit Logs API to fetch detailed audit events and supports DCR-based ingestion time transformations. These transformations enable parsing of the received audit data into a custom table during ingestion, improving query performance by eliminating the need for additional parsing. By using this connector, you can gain enhanced visibility into your Azure DevOps environment and streamline your security operations.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ADOAuditLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure DevOps Prerequisite: Please ensure the following:
1. Register an Entra App in Microsoft Entra Admin Center under App Registrations.
2. In 'API permissions' - add Permissions to 'Azure DevOps - vso.auditlog'.
3. In 'Certificates & secrets' - generate 'Client secret'.
4. In 'Authentication' - add the Redirect URI found below in the corresponding field.
5. In the Azure DevOps settings - enable audit log and set View audit log for the user. Azure DevOps Auditing.
6. Ensure the user assigned to connect the data connector has the View audit logs permission explicitly set to Allow at all times. This permission is essential for successful log ingestion. If the permission is revoked or not granted, data ingestion will fail or be interrupted.

Setup Instructions:

**Connect to Azure DevOps to start collecting Audit logs in Microsoft Sentinel. **

Enter the App you have registered.
In the 'Overview' section, copy the Application (client) ID.
Select the 'Endpoints' button, and copy the 'OAuth 2.0 authorization endpoint (v2)' value and the 'OAuth 2.0 token endpoint (v2)' value.
In the 'Certificates & secrets' section, copy the 'Client Secret value', and store it securely.
Provide the required information below and click 'Connect'.

Token Endpoint: ([concat(variables('_loginUrl'), '/{TenantId}/oauth2/v2.0/token')])
Authorization Endpoint: ([concat(variables('_loginUrl'), '/{TenantId}/oauth2/v2.0/authorize')])
API Endpoint: (https://auditservice.dev.azure.com/{organizationName}/_apis/audit/auditlog?api-version=7.2-preview)

Azure Event Hub

Supported by: Microsoft Corporation

Azure Event Hubs is a big data streaming platform and event ingestion service. It can receive and process millions of events per second. This connector lets you stream your Azure Event Hub diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Event Hub diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Event Hub log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Event Hub at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure Firewall

Supported by: Microsoft Corporation

Connect to Azure Firewall. Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No
`AZFWApplicationRule`	Yes	Yes
`AZFWFlowTrace`	Yes	Yes
`AZFWFatFlow`	Yes	Yes
`AZFWNatRule`	Yes	Yes
`AZFWDnsQuery`	Yes	Yes
`AZFWIdpsSignature`	Yes	Yes
`AZFWInternalFqdnResolutionFailure`	Yes	Yes
`AZFWNetworkRule`	Yes	Yes
`AZFWThreatIntel`	Yes	Yes

Data collection rule support: Workspace transform DCR

Azure Key Vault

Supported by: Microsoft Corporation

Azure Key Vault is a cloud service for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, or cryptographic keys. This connector lets you stream your Azure Key Vault diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity in all your instances. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Azure Kubernetes Service (AKS)

Supported by: Microsoft Corporation

Azure Kubernetes Service (AKS) is an open-source, fully-managed container orchestration service that allows you to deploy, scale, and manage Docker containers and container-based applications in a cluster environment. This connector lets you stream your Azure Kubernetes Service (AKS) diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity in all your instances. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Azure Logic Apps

Supported by: Microsoft Corporation

Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate your apps, data, services, and systems. This connector lets you stream your Azure Logic Apps diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Logic Apps diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Logic Apps log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Logic Apps at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure Resource Graph

Supported by: Microsoft Corporation

Azure Resource Graph connector gives richer insights into Azure events by supplementing details about Azure subscriptions and Azure resources.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role permission on Azure subscriptions

Setup Instructions:

Connect Azure Resource Graph to Microsoft Sentinel

Azure Service Bus

Supported by: Microsoft Corporation

Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace). This connector lets you stream your Azure Service Bus diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Service Bus diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Service Bus log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Service Bus at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure SQL Databases

Supported by: Microsoft Corporation

Azure SQL is a fully managed, Platform-as-a-Service (PaaS) database engine that handles most database management functions, such as upgrading, patching, backups, and monitoring, without necessitating user involvement. This connector lets you stream your Azure SQL databases audit and diagnostic logs into Microsoft Sentinel, allowing you to continuously monitor activity in all your instances.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Azure Storage Account

Supported by: Microsoft Corporation

Azure Storage account is a cloud solution for modern data storage scenarios. It contains all your data objects: blobs, files, queues, tables, and disks. This connector lets you stream Azure Storage accounts diagnostics logs into your Microsoft Sentinel workspace, allowing you to continuously monitor activity in all your instances, and detect malicious activity in your organization. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureMetrics`	No	No
`StorageBlobLogs`	Yes	Yes
`StorageQueueLogs`	Yes	Yes
`StorageTableLogs`	Yes	Yes
`StorageFileLogs`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Storage Account diagnostics logs into Sentinel.

This connector uses a set of Azure Policies to apply a log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply policies to all current and future instances. To get most out of the Storage Account Diagnostic logging from the Azure Storage Account, we recommend that you enable Diagnostic logging from all services within the Azure Storage Account - Blob, Queue, Table and File. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Storage Account at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Stream diagnostics logs from your Azure Storage Blob service at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Stream diagnostics logs from your Azure Storage Queue service at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Stream diagnostics logs from your Azure Storage Table service at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Stream diagnostics logs from your Azure Storage File service at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure Stream Analytics

Supported by: Microsoft Corporation

Azure Stream Analytics is a real-time analytics and complex event-processing engine that is designed to analyze and process high volumes of fast streaming data from multiple sources simultaneously. This connector lets you stream your Azure Stream Analytics hub diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Policy: Owner role assigned for each policy assignment scope

Setup Instructions:

Connect your Azure Stream Analytics diagnostics logs into Sentinel.

This connector uses Azure Policy to apply a single Azure Stream Analytics log-streaming configuration to a collection of instances, defined as a scope. Follow the instructions below to create and apply a policy to all current and future instances. Note, you may already have an active policy for this resource type.

Stream diagnostics logs from your Azure Stream Analytics at scale

**Launch the Azure Policy Assignment wizard and follow the steps. **

In the Basics tab, click the button with the three dots under Scope to select your subscription.
In the Parameters tab, choose your Microsoft Sentinel workspace from the Log Analytics workspace drop-down list, and leave marked as "True" all the log categories you want to ingest.
To apply the policy on your existing resources, mark the Create a remediation task check box in the Remediation tab.

Azure Web Application Firewall (WAF)

Supported by: Microsoft Corporation

Connect to the Azure Web Application Firewall (WAF) for Application Gateway, Front Door, or CDN. This WAF protects your applications from common web vulnerabilities such as SQL injection and cross-site scripting, and lets you customize rules to reduce false positives. Instructions to stream your Microsoft Web application firewall logs into Microsoft Sentinel are shown during the installation process. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AzureDiagnostics`	No	No

Data collection rule support: Not currently supported

BETTER Mobile Threat Defense (MTD)

Supported by: Better Mobile Security Inc.

The BETTER MTD Connector allows Enterprises to connect their Better MTD instances with Microsoft Sentinel, to view their data in Dashboards, create custom alerts, use it to trigger playbooks and expands threat hunting capabilities. This gives users more insight into their organization's mobile devices and ability to quickly analyze current mobile security posture which improves their overall SecOps capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BetterMTDIncidentLog_CL`	No	No
`BetterMTDDeviceLog_CL`	No	No
`BetterMTDNetflowLog_CL`	No	No
`BetterMTDAppLog_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

In Better MTD Console, click on Integration on the side bar.
Select Others tab.
Click the ADD ACCOUNT button and Select Microsoft Sentinel from the available integrations.
Create the Integration:

set ACCOUNT NAME to a descriptive name that identifies the integration then click Next
Enter your WORKSPACE ID and PRIMARY KEY from the fields below, click Save
Click Done

Threat Policy setup (Which Incidents should be reported to Microsoft Sentinel):

In Better MTD Console, click on Policies on the side bar
Click on the Edit button of the Policy that you are using.
For each Incident types that you want to be logged go to Send to Integrations field and select Sentinel

For additional information, please refer to our Documentation.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

BeyondTrust PM Cloud

Supported by: BeyondTrust

The BeyondTrust Privilege Management Cloud data connector provides the capability to ingest activity audit logs and client event logs from BeyondTrust PM Cloud into Microsoft Sentinel.

This connector uses Azure Functions to pull data from the BeyondTrust PM Cloud API and ingest it into custom Log Analytics tables.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BeyondTrustPM_ActivityAudits_CL`	Yes	Yes
`BeyondTrustPM_ClientEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
BeyondTrust PM Cloud API credentials: BeyondTrust PM Cloud OAuth Client ID and Client Secret are required. The API account requires the following permissions: Audit - Read Only and Reporting - Read Only

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the BeyondTrust PM Cloud API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector uses the OAuth 2.0 client credentials flow to authenticate with the BeyondTrust PM Cloud API.

STEP 1 - Obtain BeyondTrust PM Cloud API credentials

Create an API Account in your BeyondTrust PM Cloud instance with OAuth API credentials (Client ID and Client Secret). The API account requires the following permissions:

Audit - Read Only
Reporting - Read Only

STEP 2 - Deploy the connector and the associated Azure Function

Use this method for automated deployment of the BeyondTrust PM Cloud data connector using an ARM Template.

Click the Deploy to Azure button below.

portal.azure.com
Select the preferred Subscription, Resource Group (must contain your Log Analytics workspace), and Location.
Enter the required parameters:
- Workspace Name: Name of your Log Analytics workspace (e.g., beyondtrust-pmcloud)
- BeyondTrust PM Cloud Base URL: Your tenant URL (e.g., https://yourcompany.beyondtrustcloud.com)
- BeyondTrust Client ID: OAuth Client ID from Step 1
- BeyondTrust Client Secret: OAuth Client Secret from Step 1
- Activity Audits Polling Interval: How often to collect Activity Audits (default: 15 minutes)
- Client Events Polling Interval: How often to collect Client Events (default: 5 minutes)
- Log Level: Logging level for troubleshooting (default: Information)
- Historical Data Timeframe: How far back to collect data on first run (default: 1 day)
Review advanced settings (Hosting Plan SKU, Storage Account Type) and adjust if needed.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.
The deployment creates all required resources: Function App, Storage Account, Data Collection Endpoint, Data Collection Rules, and custom Log Analytics tables.
Data should begin flowing within 15-30 minutes of deployment.

BigID DSPM connector

Supported by: BigID

The BigID DSPM data connector provides the capability to ingest BigID DSPM cases with affected objects and datasource information into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BigIDDSPMCatalog_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

BigID DSPM API access: Access to the BigID DSPM API through a BigID Token is required.

Setup Instructions:

Connect to BigID DSPM API to start collecting BigID DSPM cases and affected Objects in Microsoft Sentinel

Provide your BigID domain name like 'customer.bigid.cloud' and your BigID token. Generate a token in the BigID console via Settings -> Access Management -> Users -> Select User and generate a token.

BigID FQDN: (BigID FQDN)
BigID Token: (BigID Token)
Enable/Disable Connection

Bitglass (using Azure Functions)

Supported by: Microsoft Corporation

The Bitglass data connector provides the capability to retrieve security event logs of the Bitglass services and more events into Microsoft Sentinel through the REST API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BitglassLogs_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: BitglassToken and BitglassServiceURL are required for making API calls.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Azure Blob Storage API to pull logs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected Bitglass which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the Bitglass Log Retrieval API

Follow the instructions to obtain the credentials.

Please contact Bitglass support and obtain the BitglassToken and BitglassServiceURL ntation].
Save credentials for using in the data connector.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Bitglass data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Bitglass data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the BitglassToken, BitglassServiceURL and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Bitglass data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. BitglassXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): BitglassToken BitglassServiceURL WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Bitwarden Event Logs

Supported by: Bitwarden Inc

This connector provides insight into activity of your Bitwarden organization such as user's activity (logged in, changed password, 2fa, etc.), cipher activity (created, updated, deleted, shared, etc.), collection activity, organization activity, and more.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BitwardenEventLogs`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Bitwarden Client Id and Client Secret: Your API key can be found in the Bitwarden organization admin console. Please see Bitwarden documentation for more information.

Setup Instructions:

Connect Bitwarden Event Logs to Microsoft Sentinel

Your API key can be found in the Bitwarden organization admin console. Please see Bitwarden documentation for more information. Self-hosted Bitwarden servers may need to reconfigure their installation's URL.

Bitwarden Identity Url: (https://identity.bitwarden.com)
Bitwarden Api Url: (https://api.bitwarden.com)

blacklens.io

Supported by: blacklens.io Support

The blacklens.io data connector allows you to ingest Attack Surface Management alerts from blacklens.io into Microsoft Sentinel using a webhook-based Logic App and the Azure Monitor Logs Ingestion API.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`blacklens_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Contributor or Owner permissions on the resource group are required to deploy the data ingestion infrastructure (Data Collection Endpoint, Data Collection Rule, custom table, and Logic App).
blacklens.io Account: A blacklens.io account with webhook integration capabilities is required.

Setup Instructions:

Step 1 - Deploy the data ingestion infrastructure

This step deploys the required Azure resources: a Data Collection Endpoint, Data Collection Rule, custom Log Analytics table (blacklens_CL), and a webhook-triggered Logic App.

Click the Deploy to Azure button below.

portal.azure.com
Select the Subscription, Resource Group, and Location where your Microsoft Sentinel workspace resides.
Enter the Workspace Name of your Log Analytics workspace.
Click Review + create and then Create.

Step 2 - Copy the webhook URL

After the deployment succeeds, click the Outputs tab on the deployment page.
Copy the webhookUrl value.

Alternatively, navigate to Logic Apps > la-blacklens-alert-log-ingestion > Overview and copy the Workflow URL.

Step 3 - Configure blacklens.io

Log in to the blacklens.io portal.
Navigate to the webhook integration settings.
Paste the webhook URL copied in Step 2.
Save the configuration.
Link the webhook integration to at least one notification policy so that alerts are sent to the webhook.

After a few minutes, a test incident should appear in Microsoft Sentinel.

Box (using Azure Functions)

Supported by: Microsoft Corporation

The Box data connector provides the capability to ingest Box enterprise's events into Microsoft Sentinel using the Box REST API. Refer to Box documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BoxEvents_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Box API Credentials: Box config JSON file is required for Box REST API JWT authentication. For more information, see JWT authentication.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Box REST API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector depends on a parser based on Kusto Function to work as expected BoxEvents which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration of the Box events collection

See documentation to setup JWT authentication and obtain JSON file with credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Box data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Box JSON configuration file, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Box data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the AzureSentinelWorkspaceId, AzureSentinelSharedKey, BoxConfigJSON
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Box data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): AzureSentinelWorkspaceId AzureSentinelSharedKey BOX_CONFIG_JSON logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Box Events (CCF)

Supported by: Microsoft Corporation

The Box data connector provides the capability to ingest Box enterprise's events into Microsoft Sentinel using the Box REST API. Refer to Box documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`BoxEventsV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Box API credentials: Box API requires a Box App client ID and client secret to authenticate. For more information, see Client Credentials grant
Box Enterprise ID: Box Enterprise ID is required to make the connection. See documentation to find Enterprise ID

Setup Instructions:

NOTE: This connector uses Codeless Connecor Platform (CCF) to connect to the Box REST API to pull logs into Microsoft Sentinel.

NOTE: This connector depends on a parser based on Kusto Function to work as expected BoxEvents which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Create Box Custom Application

See documentation to setup client credentials authentication

STEP 2 - Grab Client ID and Client Secret values

You might need to setup 2FA to fetch the secret.

STEP 3 - Grab Box Enterprise ID from Box Admin Console

See documentation to find Enterprise ID

Connect to Box to start collecting event logs to Microsoft Sentinel

Provide the required values below:

Box Enterprise ID: (123456)

Check Point CloudGuard CNAPP Connector for Microsoft Sentinel

Supported by: Check Point

The CloudGuard data connector enables the ingestion of security events from the CloudGuard API into Microsoft Sentinel™, using Microsoft Sentinel’s Codeless Connector Framework. The connector supports DCR-based ingestion time transformations which parses incoming security event data into custom columns. This pre-parsing process eliminates the need for query-time parsing, resulting in improved performance for data queries.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CloudGuard_SecurityEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

CloudGuard API Key: Refer to the instructions provided here to generate an API key.

Setup Instructions:

Connect CloudGuard Security Events to Microsoft Sentinel

To enable the CloudGuard connector for Microsoft Sentinel, enter the required information below and select Connect.

API Key ID: (api_key)
API Key Secret: (api_secret)
CloudGuard Endpoint URL: (e.g. https://api.dome9.com)
Filter: (Paste filter from CloudGuard)
Enable/Disable Connection

Check Point Cyberint Alerts Connector (via Codeless Connector Framework)

Supported by: Cyberint

Cyberint, a Check Point company, provides a Microsoft Sentinel integration to streamline critical Alerts and bring enriched threat intelligence from the Infinity External Risk Management solution into Microsoft Sentinel. This simplifies the process of tracking the status of tickets with automatic sync updates across systems. Using this new integration for Microsoft Sentinel, existing Cyberint and Microsoft Sentinel customers can easily pull logs based on Cyberint's findings into Microsoft Sentinel platform.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`argsentdc_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Check Point Cyberint API Key, Argos URL, and Customer Name: The connector API key, Argos URL, and Customer Name are required

Setup Instructions:

Connect Checkpoint Cyberint Alerts to Microsoft Sentinel

To enable the connector provide the required information below and click on Connect.

Argos URL — Cyberint API URL for your tenant (e.g. https://your_tenant.cyberint.io) API Token — Cyberint API access token Customer Name — Company (client) name associated with your Cyberint instance Environments — Comma-separated list of environments to fetch. If empty, all environments are fetched.\n\nSeverity — Comma-separated list of severities to fetch (low, medium, high, very_high). If empty, all severities are fetched.\n\nPolling Interval — How often to poll for new alerts, in minutes (default: 5)\n\nInclude CSV Attachments as JSON — Whether to include CSV attachments as JSON content in alerts (default: false)

Argos URL: (https://your_tenant.cyberint.io)
API Token: (Cyberint API access token)
Customer Name: (Company (client) name associated with your Cyberint instance)
Environments: (Comma-separated list (e.g. Production,Staging))
Severity: (Comma-separated list (e.g. low,medium,high,very_high))
Polling Interval (Minutes): (Polling frequency in minutes)
Include CSV Attachments as JSON: (true or false)
Enable/Disable Connection

Check Point Cyberint IOC Connector

Supported by: Cyberint

Cyberint, a Check Point company, provides a Microsoft Sentinel integration to ingest Indicators of Compromise (IOCs) from the Infinity External Risk Management solution into Microsoft Sentinel. This connector automatically pulls the daily IOC feed — including malicious IPs, domains, URLs, and file hashes — enriched with threat context such as severity, confidence, and detected activity.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`iocsent_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Check Point Cyberint API Key, Argos URL, and Customer Name: The connector API key, Argos URL, and Customer Name are required

Setup Instructions:

Connect Check Point Cyberint IOC Feed to Microsoft Sentinel

To enable the connector provide the required information below and click on Connect.

Argos URL — Cyberint API URL for your tenant (e.g. https://your_tenant.cyberint.io) API Token — Cyberint API access token Customer Name — Company (client) name associated with your Cyberint instance

Argos URL: (https://your-company.cyberint.io)
API Token: (API Token)
Customer Name: (Company (client) name associated with your Cyberint instance)
Enable/Disable Connection

Cisco ASA/FTD via AMA

Supported by: Microsoft Corporation

The Cisco ASA firewall connector allows you to easily connect your Cisco ASA logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization's network and improves your security operation capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CommonSecurityLog`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

To collect data from non-Azure VMs, they must have Azure Arc installed and enabled. Learn more

Setup Instructions:

Enable data collection rule

Cisco ASA/FTD event logs are collected only from Linux agents.

Install Agent: <variable value provided at install time>

Run the following command to install and apply the Cisco ASA/FTD collector:

Value: <variable value provided at install time>

Cisco Cloud Security (using Azure Functions)

Supported by: Microsoft Corporation

The Cisco Cloud Security solution for Microsoft Sentinel enables you to ingest Cisco Secure Access and Cisco Umbrella logs stored in Amazon S3 into Microsoft Sentinel using the Amazon S3 REST API. Refer to Cisco Cloud Security log management documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Cisco_Umbrella_dns_CL`	Yes	Yes
`Cisco_Umbrella_proxy_CL`	Yes	Yes
`Cisco_Umbrella_ip_CL`	Yes	Yes
`Cisco_Umbrella_cloudfirewall_CL`	Yes	Yes
`Cisco_Umbrella_firewall_CL`	Yes	Yes
`Cisco_Umbrella_dlp_CL`	No	No
`Cisco_Umbrella_ravpnlogs_CL`	No	No
`Cisco_Umbrella_audit_CL`	No	No
`Cisco_Umbrella_ztna_CL`	No	No
`Cisco_Umbrella_intrusion_CL`	No	No
`Cisco_Umbrella_ztaflow_CL`	No	No
`Cisco_Umbrella_fileevent_CL`	No	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Amazon S3 REST API Credentials/permissions: AWS Access Key Id, AWS Secret Access Key, AWS S3 Bucket Name are required for Amazon S3 REST API.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Amazon S3 REST API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector has been updated to support Cisco Cloud Security log schema version 14.

NOTE: This connector uses a parser based on a Kusto Function to normalize fields. Follow these steps to create the Kusto function alias Cisco_Umbrella.

STEP 1 - Configuration of the Cisco Cloud Security logs collection

See documentation and follow the instructions for set up logging and obtain credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Functions

IMPORTANT: Before deploying the Cisco Cloud Security data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Amazon S3 REST API Authorization credentials, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cisco Cloud Security data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, S3Bucket, AWSAccessKeyId, AWSSecretAccessKey Note: For the S3Bucket use the value that Cisco referrs to as the S3 Bucket Data Path and add a / (forward slash) to the end of the value
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Cisco Cloud Security data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

NOTE: You will need to prepare VS code for Azure Functions development.

Download the Azure Functions App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): WorkspaceID WorkspaceKey S3Bucket AWSAccessKeyId AWSSecretAccessKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Cisco Cloud Security (using elastic premium plan) (using Azure Functions)

Supported by: Microsoft Corporation

The Cisco Umbrella data connector provides the capability to ingest Cisco Umbrella events stored in Amazon S3 into Microsoft Sentinel using the Amazon S3 REST API. Refer to Cisco Umbrella log management documentation for more information.

NOTE: This data connector uses the Azure Functions Premium Plan to enable secure ingestion capabilities and will incur additional costs. More pricing details are here.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Cisco_Umbrella_dns_CL`	Yes	Yes
`Cisco_Umbrella_proxy_CL`	Yes	Yes
`Cisco_Umbrella_ip_CL`	Yes	Yes
`Cisco_Umbrella_cloudfirewall_CL`	Yes	Yes
`Cisco_Umbrella_firewall_CL`	Yes	Yes
`Cisco_Umbrella_dlp_CL`	No	No
`Cisco_Umbrella_ravpnlogs_CL`	No	No
`Cisco_Umbrella_audit_CL`	No	No
`Cisco_Umbrella_ztna_CL`	No	No
`Cisco_Umbrella_intrusion_CL`	No	No
`Cisco_Umbrella_ztaflow_CL`	No	No
`Cisco_Umbrella_fileevent_CL`	No	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Amazon S3 REST API Credentials/permissions: AWS Access Key Id, AWS Secret Access Key, AWS S3 Bucket Name are required for Amazon S3 REST API.
Virtual Network permissions (for private access): For private storage account access, Network Contributor permissions are required on the Virtual Network and subnet. The subnet must be delegated to Microsoft.Web/serverFarms for Function App VNet integration.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Amazon S3 REST API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector has been updated to support cisco umbrella log schema version 14.

NOTE: This connector uses a parser based on a Kusto Function to normalize fields. Follow these steps to create the Kusto function alias Cisco_Umbrella.

STEP 1 - Network Prerequisites for Private Access

IMPORTANT: When deploying with private storage account access, ensure the following network prerequisites are met:

Virtual Network: An existing Virtual Network (VNet) must be available
Subnet: A dedicated subnet within the VNet must be delegated to Microsoft.Web/serverFarms for Function App VNet integration
Subnet Delegation: Configure the subnet delegation using Azure Portal, ARM template, or Azure CLI:
- Azure Portal: Go to Virtual networks → Select your VNet → Subnets → Select subnet → Delegate subnet to service → Choose Microsoft.Web/serverFarms
- Azure CLI: az network vnet subnet update --resource-group <rg-name> --vnet-name <vnet-name> --name <subnet-name> --delegations Microsoft.Web/serverFarms
Private Endpoints: The deployment will create private endpoints for storage account services (blob, file, queue, table) within the same subnet

STEP 2 - Configuration of the Cisco Umbrella logs collection

See documentation and follow the instructions for set up logging and obtain credentials.

STEP 3 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Functions

IMPORTANT: Before deploying the Cisco Umbrella data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Amazon S3 REST API Authorization credentials, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cisco Umbrella data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, S3Bucket, AWSAccessKeyId, AWSSecretAccessKey
For Private Access Deployment: Also enter existingVnetName, existingVnetResourceGroupName, and existingSubnetName (ensure subnet is delegated to Microsoft.Web/serverFarms) Note: For the S3Bucket use the value that Cisco referrs to as the S3 Bucket Data Path and add a / (forward slash) to the end of the value
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Cisco Umbrella data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

NOTE: You will need to prepare VS code for Azure Functions development.

Download the Azure Functions App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): WorkspaceID WorkspaceKey S3Bucket AWSAccessKeyId AWSSecretAccessKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Cisco Duo Security (using Azure Functions)

Supported by: Cisco Systems

The Cisco Duo Security data connector provides the capability to ingest authentication logs, administrator logs, telephony logs, offline enrollment logs and Trust Monitor events into Microsoft Sentinel using the Cisco Duo Admin API. Refer to API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CiscoDuo_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Cisco Duo API credentials: Cisco Duo API credentials with permission Grant read log is required for Cisco Duo API. See the documentation to learn more about creating Cisco Duo API credentials.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Cisco Duo API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected CiscoDuo which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Obtaining Cisco Duo Admin API credentials

Follow the instructions to obtain integration key, secret key, and API hostname. Use Grant read log permission in the 4th step of the instructions.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as Azure Blob Storage connection string and container name, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Cisco Duo Integration Key, Cisco Duo Secret Key, Cisco Duo API Hostname, Cisco Duo Log Types, Microsoft Sentinel Workspace Id, Microsoft Sentinel Shared Key
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): CISCO_DUO_INTEGRATION_KEY CISCO_DUO_SECRET_KEY CISCO_DUO_API_HOSTNAME CISCO_DUO_LOG_TYPES WORKSPACE_ID SHARED_KEY logAnalyticsUri (Optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://WORKSPACE_ID.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Cisco ETD (using Azure Functions)

Supported by: N/A

The connector fetches data from ETD API for threat analysis

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CiscoETD_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Email Threat Defense API, API key, Client ID and Secret: Ensure you have the API key, Client ID and Secret key.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the ETD API to pull its logs into Microsoft Sentinel.

Follow the deployment steps to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the ETD data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cisco ETD data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Region.
Enter the WorkspaceID, SharedKey, ClientID, ClientSecret, ApiKey, Verdicts, ETD Region
Click Create to deploy.

Cisco Meraki (using REST API)

Supported by: Microsoft Corporation

The Cisco Meraki connector allows you to easily connect your Cisco Meraki organization events (Security events, Configuration Changes and API Requests) to Microsoft Sentinel. The data connector uses the Cisco Meraki REST API to fetch logs and supports DCR-based ingestion time transformations that parses the received data and ingests into ASIM and custom tables in your Log Analytics workspace. This data connector benefits from capabilities such as DCR based ingestion-time filtering, data normalization.

Supported ASIM schema:

Network Session
Web Session
Audit Event

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ASimNetworkSessionLogs`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Cisco Meraki REST API Key: Enable API access in Cisco Meraki and generate API Key. Please refer to Cisco Meraki official documentation for more information.
Cisco Meraki Organization Id: Obtain your Cisco Meraki organization id to fetch security events. Follow the steps in the documentation to obtain the Organization Id using the Meraki API Key obtained in previous step.

Setup Instructions:

Connect Cisco Meraki events to Microsoft Sentinel

Currently, this connector allows to ingest events from the following Cisco Meraki REST API endpoint:

Get Organization Appliance Security Events This connector parses IDS Alert events into ASimNetworkSessionLogs Table and File Scanned events into ASimWebSessionLogs Table.
Get Organization Api Requests This connector parses events into ASimWebSessionLogs Table.
Get Organization Configuration Changes This connector parses events into ASimAuditEventLogs Table.

Organization Id: (OrganizationId)
API Key: (ApiKey)
Enable/Disable Connection

Cisco Secure Endpoint (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Cisco Secure Endpoint (formerly AMP for Endpoints) data connector provides the capability to ingest Cisco Secure Endpoint audit logs and events into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CiscoSecureEndpointAuditLogsV2_CL`	Yes	Yes
`CiscoSecureEndpointEventsV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Cisco Secure Endpoint API Credentials/Regions: To create API Credentials and to understand the regions, follow the document link provided here. Click here.

Setup Instructions:

Connect Cisco Secure Endpoint to Microsoft Sentinel

To ingest data from Cisco Secure Endpoint to Microsoft Sentinel, you have to click on Add Account button below, then you get a pop up to fill the details like Email, Organization, Client ID, API Key and Region, provide the required information and click on Connect. You can see the connected organizations/emails in the below grid.

Data Connectors Grid (configure in portal)

Cisco Software Defined WAN

Supported by: Cisco Systems

The Cisco Software Defined WAN(SD-WAN) data connector provides the capability to ingest Cisco SD-WAN Syslog and Netflow data into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Syslog`	Yes	Yes
`CiscoSDWANNetflow_CL`	No	No

Data collection rule support: Workspace transform DCR

Setup Instructions:

To ingest Cisco SD-WAN Syslog and Netflow data into Microsoft Sentinel follow the steps below.

1. Steps to ingest Syslog data to Microsoft sentinel

Azure Monitor Agent will be used to collect the syslog data into Microsoft sentinel. For that first need to create an azure arc server for the VM from which syslog data will be sent.

1.1 Steps to Add Azure Arc Server

In Azure portal, go to Servers - Azure Arc and click on Add.
Select Generate Script under Add a single server section. A User can also generate scripts for Multiple Servers as well.
Review the information on the Prerequisites page, then select Next.
On the Resource details page, provide the subscription and resource group of the Microsoft Sentinel, Region, Operating system and Connectivity method. Then select Next.
On the Tags page, review the default Physical location tags suggested and enter a value, or specify one or more Custom tags to support your standards. Then select Next
Select Download to save the script file.
Now that you have generated the script, the next step is to run it on the server that you want to onboard to Azure Arc.
If you have Azure VM follow the steps mentioned in the link before running the script.
Run the script by the following command: ./<ScriptName>.sh
After you install the agent and configure it to connect to Azure Arc-enabled servers, go to the Azure portal to verify that the server has successfully connected. View your machine in the Azure portal. Reference link: /azure/azure-arc/servers/learn/quick-enable-hybrid-vm

1.2 Steps to Create Data Collection Rule (DCR)

In Azure Portal search for Monitor. Under Settings, select Data Collection Rules and Select Create.
On the Basics panel, enter the Rule Name, Subscription, Resource group, Region and Platform Type.
Select Next: Resources.
Select Add resources.Use the filters to find the virtual machine that you'll use to collect logs.
Select the virtual machine. Select Apply.
Select Next: Collect and deliver.
Select Add data source. For Data source type, select Linux syslog.
For Minimum log level, leave the default values LOG_DEBUG.
Select Next: Destination.
Select Add destination and add Destination type, Subscription and Account or namespace.
Select Add data source. Select Next: Review + create.
Select Create. Wait for 20 minutes. In Microsoft Sentinel or Azure Monitor, verify that the Azure Monitor agent is running on your VM. Reference link: /azure/sentinel/forward-syslog-monitor-agent

2. Steps to ingest Netflow data to Microsoft sentinel

To Ingest Netflow data into Microsoft sentinel, Filebeat and Logstash needs to be installed and configured on the VM. After the configuration, vm will be able to receive netflow data on the configured port and that data will be ingested into the workspace of Microsoft sentinel.

2.1 Install filebeat and logstash

For the installation of filebeat and logstash using apt refer to this doc:
Filebeat: https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html.
Logstash: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html.
For the installation of filebeat and logstash for RedHat based Linux (yum) steps are as follows:
Filebeat: https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html#_yum.
Logstash: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html#_yum

2.2 Configure Filebeat to send events to Logstash

Edit filebeat.yml file: vi /etc/filebeat/filebeat.yml
Comment out the Elasticsearch Output section.
Uncomment Logstash Output section (Uncomment out only these two lines)- output.logstash hosts: ["localhost:5044"]
In the Logstash Output section, if you want to send the data other than the default port i.e. 5044 port, then replace the port number in the hosts field. (Note: This port should be added in the conf file, while configuring logstash.)
In the 'filebeat.inputs' section comment out existing configuration and add the following configuration: - type: netflow max_message_size: 10KiB host: "0.0.0.0:2055" protocols: [ v5, v9, ipfix ] expiration_timeout: 30m queue_size: 8192 custom_definitions:

/etc/filebeat/custom.yml detect_sequence_reset: true enabled: true

In the Filebeat inputs section, if you want to receive the data other than the default port i.e. 2055 port, then replace the port number in the host field.
Add the provided custom.yml file inside the /etc/filebeat/ directory.
Open the filebeat input and output port in the firewall.
Run command: firewall-cmd --zone=public --permanent --add-port=2055/udp
Run command: firewall-cmd --zone=public --permanent --add-port=5044/udp

Note: if a custom port is added for filebeat input/output, then open that port in the firewall.

2.3 Configure Logstash to send events to Microsoft Sentinel

Install the Azure Log Analytics plugin:
Run Command: sudo /usr/share/logstash/bin/logstash-plugin install microsoft-logstash-output-azure-loganalytics
Store the Log Analytics workspace key in the Logstash key store. The workspace key can be found in Azure Portal under Log analytic workspace > Select workspace > Under Settings select Agent > Log Analytics agent instructions.
Copy the Primary key and run the following commands:
sudo /usr/share/logstash/bin/logstash-keystore --path.settings /etc/logstash create LogAnalyticsKey
sudo /usr/share/logstash/bin/logstash-keystore --path.settings /etc/logstash add LogAnalyticsKey
Create the configuration file /etc/logstash/cisco-netflow-to-sentinel.conf: input { beats { port => <port_number> #(Enter output port number which has been configured during filebeat configuration i.e. filebeat.yml file .) } } output { microsoft-logstash-output-azure-loganalytics { workspace_id => "<workspace_id>" workspace_key => "${LogAnalyticsKey}" custom_log_table_name => "CiscoSDWANNetflow" } }

Note: If table is not present in Microsoft sentinel, then it will create a new table in sentinel.

2.4 Run Filebeat:

Open a terminal and run the command: systemctl start filebeat
This command will start running filebeat in the background. To see the logs stop the filebeat (systemctl stop filebeat) then run the following command: filebeat run -e

2.5 Run Logstash:

In another terminal run the command: /usr/share/logstash/bin/logstash --path.settings /etc/logstash -f /etc/logstash/cisco-netflow-to-sentinel.conf &
This command will start running the logstash in the background. To see the logs of logstash kill the above process and run the following command : /usr/share/logstash/bin/logstash --path.settings /etc/logstash -f /etc/logstash/cisco-netflow-to-sentinel.conf

Claroty xDome

Supported by: xDome Customer Support

Claroty xDome delivers comprehensive security and alert management capabilities for healthcare and industrial network environments. It is designed to map multiple source types, identify the collected data, and integrate it into Microsoft Sentinel data models. This results in the ability to monitor all potential threats in your healthcare and industrial environments in one location, leading to more effective security monitoring and a stronger security posture.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CommonSecurityLog`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

1. Linux Syslog agent configuration

Install and configure the Linux agent to collect your Common Event Format (CEF) Syslog messages and forward them to Microsoft Sentinel.

Notice that the data from all regions will be stored in the selected workspace

1.1 Select or create a Linux machine

Select or create a Linux machine that Microsoft Sentinel will use as the proxy between your security solution and Microsoft Sentinel this machine can be on your on-prem environment, Azure or other clouds.

1.2 Install the CEF collector on the Linux machine

Install the Microsoft Monitoring Agent on your Linux machine and configure the machine to listen on the necessary port and forward messages to your Microsoft Sentinel workspace. The CEF collector collects CEF messages on port 514 TCP.

Make sure that you have Python on your machine using the following command: python --version.
You must have elevated permissions (sudo) on your machine.

Run the following command to install and apply the CEF collector:: <variable value provided at install time>

2. Forward Common Event Format (CEF) logs to Syslog agent

Configure the Claroty xDome - Microsoft Sentinel integration to collect your Common Event Format (CEF) Syslog messages and forward them to Microsoft Sentinel.

3. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python --version
You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**4. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

Cloudflare (Preview) (using Azure Functions)

Supported by: Cloudflare

The Cloudflare data connector provides the capability to ingest Cloudflare logs into Microsoft Sentinel using the Cloudflare Logpush and Azure Blob Storage. Refer to Cloudflare documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Cloudflare_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Azure Blob Storage connection string and container name: Azure Blob Storage connection string and container name where the logs are pushed to by Cloudflare Logpush. For more information, see creating Azure Blob Storage container.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Azure Blob Storage API to pull logs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected Cloudflare which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration of the Cloudflare Logpush

See documentation to setup Cloudflare Logpush to Microsoft Azure

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Cloudflare data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as Azure Blob Storage connection string and container name, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cloudflare data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Azure Blob Storage Container Name, Azure Blob Storage Connection String, Microsoft Sentinel Workspace Id, Microsoft Sentinel Shared Key
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Cloudflare data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CloudflareXX).

e. Select a runtime: Choose Python 3.8.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): CONTAINER_NAME AZURE_STORAGE_CONNECTION_STRING WORKSPACE_ID SHARED_KEY logAnalyticsUri (Optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://WORKSPACE_ID.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Cloudflare (Using Blob Container) (via Codeless Connector Framework)

Supported by: Cloudflare

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CloudflareV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Create a storage account and a container: Before setting up logpush in Cloudflare, first create a storage account and a container in Microsoft Azure. Use this guide to know more about Container and Blob. Follow the steps in the documentation to create an Azure Storage account.
Generate a Blob SAS URL: Create and Write permissions are required. Refer the documentation to know more about Blob SAS token and url.
Collecting logs from Cloudflare to your Blob container: Follow the steps in the documentation for collecting logs from Cloudflare to your Blob container.

Setup Instructions:

Connect Cloudflare Logs to Microsoft Sentinel

To enable Cloudflare logs for Microsoft Sentinel, provide the required information below and click on Connect.

The Blob container's URL you want to collect data from:
The Blob container's storage account resource group name:
The Blob container's storage account location:
The Blob container's storage account subscription id:
The event grid topic name of the blob container's storage account if exist. else keep empty.:
Enable/Disable Connection

Cognni

Supported by: Cognni

The Cognni connector offers a quick and simple integration with Microsoft Sentinel. You can use Cognni to autonomously map your previously unclassified important information and detect related incidents. This allows you to recognize risks to your important information, understand the severity of the incidents, and investigate the details you need to remediate, fast enough to make a difference.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CognniIncidents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect to Cognni

Go to Cognni integrations page
Click 'Connect' on the 'Microsoft Sentinel' box
Copy and paste 'workspaceId' and 'sharedKey' (from below) to the related fields on Cognni's integrations screen
Click the 'Connect' botton to complete the configuration.
Soon, all your Cognni-detected incidents will be forwarded here (into Microsoft Sentinel)

Not a Cognni user? Join us

Workspace ID: <variable value provided at install time>
Shared Key: <variable value provided at install time>

Cohesity (using Azure Functions)

Supported by: Cohesity

The Cohesity function apps provide the ability to ingest Cohesity Datahawk ransomware alerts into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Cohesity_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Azure Blob Storage connection string and container name: Azure Blob Storage connection string and container name

Setup Instructions:

NOTE: This connector uses Azure Functions that connect to the Azure Blob Storage and KeyVault. This might result in additional costs. Check the Azure Functions pricing page, Azure Blob Storage pricing page and Azure KeyVault pricing page for details.

STEP 1 - Get a Cohesity DataHawk API key (see troubleshooting instruction 1)

STEP 2 - Register Azure app (link) and save Application (client) ID, Directory (tenant) ID, and Secret Value (instructions). Grant it Azure Storage (user_impersonation) permission. Also, assign the 'Microsoft Sentinel Contributor' role to the application in the appropriate subscription.

STEP 3 - Deploy the connector and the associated Azure Functions.

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cohesity data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the parameters that you created at the previous steps
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

CommvaultSecurityIQ

Supported by: Commvault

This Azure Function enables Commvault users to ingest alerts/events into their Microsoft Sentinel instance. With Analytic Rules,Microsoft Sentinel can automatically create Microsoft Sentinel incidents from incoming events and logs.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CommvaultAlerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Commvault Environment Endpoint URL: Make sure to follow the documentation and set the secret value in KeyVault
Commvault QSDK Token: Make sure to follow the documentation and set the secret value in KeyVault

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Commvault Instance to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Commvalut QSDK Token

Follow these instructions to create an API Token.

STEP 2 - Deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the CommvaultSecurityIQ data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Commvault Endpoint URL and QSDK Token, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Commvault Security IQ data connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Region.
Enter the Workspace ID, Workspace Key 'and/or Other required fields' and click Next.
Click Create to deploy.

Contrast ADR Push Connector

Supported by: Contrast Security

The Contrast Security connector provides the capability to ingest attack events and incidents from Contrast Application Detection and Response (ADR) into Microsoft Sentinel. This connector receives data via webhook push mechanism using OAuth authentication.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ContrastADRAttackEvents_CL`	No	No
`ContrastADRIncidents_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID (if using auto-created app). Typically requires Application Developer role or higher.
Microsoft Azure: Permission to create and configure Azure resources (DCE, DCR, Tables) and assign RBAC roles. Typically requires Contributor and User Access Administrator roles.
Contrast ADR Webhook Access: Access to Contrast ADR platform to configure webhook with OAuth authentication settings.

Setup Instructions:

1. Deploy Connector Resources

Deploy the required Azure resources for Contrast ADR data ingestion.

Choose Your Deployment Option

Select one of the following deployment options based on requirements:

Option A: Auto-Create Microsoft Entra Application (Recommended)

Clicking Deploy Contrast ADR CCF Connector will automatically create:

Data Collection Endpoint (DCE)
Data Collection Rule (DCR) with streams for attack events and incidents
Log Analytics tables (ContrastADRAttackEvents_CL and ContrastADRIncidents_CL)
Microsoft Entra Application with OAuth credentials
Role assignment (Monitoring Metrics Publisher) on the DCR

After deployment: All configuration values (Tenant ID, Client ID, Client Secret, DCE URI, DCR Immutable ID) will be auto-populated below for easy copy-paste into Contrast platform.

Option B: Use Pre-Existing Microsoft Entra Application (BYOA)

Clicking Deploy Contrast ADR CCF Connector will create:

Data Collection Endpoint (DCE)
Data Collection Rule (DCR) with streams for attack events and incidents
Log Analytics tables (ContrastADRAttackEvents_CL and ContrastADRIncidents_CL)
Microsoft Entra Application (you can ignore this)

When to use: If you have an existing Entra App that you want to reuse for security or compliance reasons. Additional steps required:

After deployment, manually assign your pre-existing Entra App's Service Principal the Monitoring Metrics Publisher role on the created DCR
Use your own Entra App's Client ID and Client Secret (ignore the auto-generated ones below)
Use the DCE URI and DCR Immutable ID from below in your Contrast webhook configuration

Click Deploy to begin:

2. Configure Contrast ADR Webhook

Copy the following values to configure the Microsoft Sentinel integration in Contrast ADR platform.

For Option A (Auto-Created Entra App): Use all the auto-populated values below. For Option B (Pre-Existing Entra App): Use the DCE URI, DCR Immutable ID, and Stream Names from below, but use your own Entra App's Tenant ID, Client ID, and Client Secret.

Azure Configuration Values:

Tenant ID: <variable value provided at install time>
Application (Client) ID: <variable value provided at install time>
Client Secret: <variable value provided at install time>
Data Collection Endpoint (DCE) URI: <variable value provided at install time>
Data Collection Rule (DCR) Immutable ID: <variable value provided at install time>
Attack Events Stream Name: <variable value provided at install time>
Incidents Stream Name: <variable value provided at install time>

Configure in Contrast ADR Platform

Log in to your Contrast ADR platform
Navigate to Administration > Integrations > Microsoft Sentinel
Copy and paste all the configuration values from above:
- Tenant ID
- Application (Client) ID
- Client Secret
- Data Collection Endpoint (DCE) URI
- Data Collection Rule (DCR) Immutable ID
- Attack Events Stream Name
- Incidents Stream Name
Click Save to complete the integration

The Contrast platform will automatically configure the OAuth authentication and data endpoints using these values.

3. Verify Data Ingestion

Verify that data is flowing from Contrast ADR to Microsoft Sentinel.

Verification Steps

Trigger a test attack event in Contrast ADR
Wait 5-10 minutes for data to appear in Microsoft Sentinel
Run the following query to verify attack events:

ContrastADRAttackEvents_CL
| take 10

Verify incidents data:

ContrastADRIncidents_CL
| take 10

Check for connectivity:

ContrastADRAttackEvents_CL
| summarize LastLogReceived = max(TimeGenerated)
| project IsConnected = LastLogReceived > ago(7d)

If data appears and IsConnected returns true, your connector is configured correctly!

Corelight Connector Exporter

Supported by: Corelight

The Corelight data connector enables incident responders and threat hunters who use Microsoft Sentinel to work faster and more effectively. The data connector enables ingestion of events from Zeek and Suricata via Corelight Sensors into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Corelight`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected Corelight which is deployed with the Microsoft Sentinel Solution.

1. Get the files

Contact your TAM, SE, or info@corelight.com to get the files needed for the Microsoft Sentinel integration.

2. Replay sample data.

Replay sample data to create the needed tables in your Log Analytics workspace.

Send sample data (only needed once per Log Analytics workspace): <variable value provided at install time>

3. Install custom exporter.

Install the custom exporter or the logstash container.

4. Configure the Corelight Sensor to send logs to the Azure Log Analytics Agent.

Using the following values, configure your Corelight Sensor to use the Microsoft Sentinel exporter. Alternatively, you can configure the logstash container with these values and configure your sensor to send JSON over TCP to that container on the appropriate port.

Workspace ID: <variable value provided at install time>
Primary Workspace Key: <variable value provided at install time>

Cortex XDR - Incidents

Supported by: DEFEND Ltd.

Custom Data connector from DEFEND to utilise the Cortex API to ingest incidents from Cortex XDR platform into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CortexXDR_Incidents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Cortex API credentials: Cortex API Token is required for REST API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials.

Setup Instructions:

Enable Cortex XDR API

Connect Cortex XDR to Microsoft Sentinel via Cortex API to process Cortex Incidents.

Cribl

Supported by: Cribl

The Cribl connector allows you to easily connect your Cribl (Cribl Enterprise Edition - Standalone) logs with Microsoft Sentinel. This gives you more security insight into your organization's data pipelines.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CriblInternal_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Installation and setup instructions for Cribl Stream for Microsoft Sentinel

Use the documentation from this Github repository and configure Cribl Stream using

https://docs.cribl.io/stream/usecase-azure-workspace/

CrowdStrike API Data Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The CrowdStrike Data Connector allows ingesting logs from the CrowdStrike API into Microsoft Sentinel. This connector provides the capability to ingest CrowdStrike Alerts, Detections, Hosts, Cases, and Vulnerabilities into Microsoft Sentinel. This connector is built on the Microsoft Sentinel Codeless Connector Framework and uses the CrowdStrike API to fetch logs. It supports DCR-based ingestion time transformations so that queries can run more efficiently. Refer to CrowdStrike API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CrowdStrikeAlerts`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Crowdstrike OAuth2 API Client and Scopes: Alerts, API Integrations, App Logs, Cases, Correlation Rules, Detections, Hosts, Assets, Incidents, Quarantined Files, Vulnerabilities are required for REST API. For more information, see API.

Setup Instructions:

Connect CrowdStrike to Microsoft Sentinel

Note: Important Notice: The Incidents API is fully decommissioned. Use the new Cases data type instead.

To gather data from CrowdStrike, you need to provide the following resources

1. Base API URL - To gather data from CrowdStrike, you'll need the Base API URL.

2. Client ID - To gather data from CrowdStrike, you'll need the Client ID.

3. Client Secret - To gather data from CrowdStrike, you'll need the Client Secret.

For detailed instructions on retrieving the Base API URL, Client ID, and Client Secret, please refer to the Connector Tutorial.

Data Connectors Grid (configure in portal)

Querying Detections (after successful connection)

Once logs are ingesting, the CrowdStrikeDetections table contains individual alert records grouped by aggregate_id. To view true detection-level behavior, use the following KQL query to aggregate alerts by their detection group:

CrowdStrikeDetections
| summarize
  AlertCount = count(),
  FirstSeen = min(CreatedTimestamp),
  LastSeen = max(CreatedTimestamp),
  MaxSeverity = max(Severity)
by AggregateId

CrowdStrike Falcon Adversary Intelligence (using Azure Functions)

Supported by: Microsoft Corporation

The CrowdStrike Falcon Indicators of Compromise connector retrieves the Indicators of Compromise from the Falcon Intel API and uploads them Microsoft Sentinel Threat Intel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ThreatIntelIndicators`	Yes	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
CrowdStrike API Client ID and Client Secret: CROWDSTRIKE_CLIENT_ID, CROWDSTRIKE_CLIENT_SECRET, CROWDSTRIKE_BASE_URL. CrowdStrike credentials must have Indicators (Falcon Intelligence) read scope.

Setup Instructions:

STEP 1 - Generate CrowdStrike API credentials.

Make sure 'Indicators (Falcon Intelligence)' scope has 'read' selected

STEP 2 - Register an Entra App with client secret.

Provide the Entra App principal with 'Microsoft Sentinel Contributor' role assignment on the respective log analytics workspace. How to assign roles on Azure.

STEP 3 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the CrowdStrike Falcon Indicator of Compromise connector, have the Workspace ID (can be copied from the following).

Workspace ID: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the CrowdStrike Falcon Adversary Intelligence connector connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Provide the following parameters: CrowdStrikeClientId, CrowdStrikeClientSecret, CrowdStrikeBaseUrl, WorkspaceId, TenantId, Indicators, AadClientId, AadClientSecret, LookBackDays

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the CrowdStrike Falcon Adversary Intelligence connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CrowdStrikeFalconIOCXXXXX).

e. Select a runtime: Choose Python 3.12.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): CROWDSTRIKE_CLIENT_ID CROWDSTRIKE_CLIENT_SECRET CROWDSTRIKE_BASE_URL TENANT_ID INDICATORS WorkspaceKey AAD_CLIENT_ID AAD_CLIENT_SECRET LOOK_BACK_DAYS WORKSPACE_ID
Once all application settings have been entered, click Save.

CrowdStrike Falcon Data Replicator (AWS S3) (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Crowdstrike Falcon Data Replicator (S3) connector provides the capability to ingest FDR event datainto Microsoft Sentinel from the AWS S3 bucket where the FDR logs have been streamed. The connector provides ability to get events from Falcon Agents which helps to examine potential security risks, analyze your team's use of collaboration, diagnose configuration problems and more.

NOTE:

1. CrowdStrike FDR license must be available & enabled.

2. The connector requires an IAM role to be configured on AWS to allow access to the AWS S3 bucket and may not be suitable for environments that leverage CrowdStrike - managed buckets.

3. For environments that leverage CrowdStrike-managed buckets, please configure the CrowdStrike Falcon Data Replicator (CrowdStrike-Managed AWS S3) connector.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CrowdStrike_Additional_Events_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Requirements: In order to use the Falcon Data Replicator feature the following are required:

Subscription: 1.1. Falcon Data Replicator. 1.2. Falcon Insight XDR.
Roles: 2.1. Falcon Administrator.
Setup your CrowdStrike & AWS environments To configure access on AWS, use the following two templates provided to set up the AWS environment. This will enable sending logs from an S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks.
Choose the ‘Specify template’ option, then ‘Upload a template file’ by clicking on ‘Choose file’ and selecting the appropriate CloudFormation template file provided below. click ‘Choose file’ and select the downloaded template.
Click 'Next' and 'Create stack'.

Make sure that your bucket will be created in the same AWS region as your Falcon CID where the FDR feed is provisioned. | CrowdStrike region | AWS region | |-----------------|-----------| | US-1 | us-west-1 | | US-2 | us-west-2 | | EU-1 | eu-central-1

Template 1: OpenID connect authentication deployment: <variable value provided at install time>
Template 2: AWS CrowdStrike resources deployment: <variable value provided at install time> Using your own S3 Bucket In order to use your own S3 bucket you can refernace the following guide Use your own S3 bucket or follow this steps:

Create support case with the following Name: Using Self S3 bucket for FDR
Add the following information: 2.1. The Falcon CID where your FDR feed is provisioned 2.2. Indicate which types of events you wish to have provided in this new FDR feed. 2.3. Indicate which types of events you wish to have provided in this new FDR feed. 2.4. Do not use any partitions.

Event type	S3 prefix
Primary Events	data/
Secondary Events	fdrv2/

Connect new collectors To enable AWS S3 for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Data Connectors Grid (configure in portal)

CrowdStrike Falcon Data Replicator (CrowdStrike Managed AWS-S3) (using Azure Function) (using Azure Functions)

Supported by: Microsoft Corporation

This connector enables the ingestion of FDR data into Microsoft Sentinel using Azure Functions to support the assessment of potential security risks, analysis of collaboration activities, identification of configuration issues, and other operational insights.

NOTE:

1. CrowdStrike FDR license must be available & enabled.

2. The connector uses a Key & Secret based authentication and is suitable for CrowdStrike Managed buckets.

3. For environments that use a fully owned AWS S3 bucket, Microsoft recommends using the CrowdStrike Falcon Data Replicator (AWS S3) connector.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CrowdStrikeReplicatorV2`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
SQS and AWS S3 account credentials/permissions: AWS_SECRET, AWS_REGION_NAME, AWS_KEY, QUEUE_URL is required. For more information, see data pulling. To start, contact CrowdStrike support. At your request they will create a CrowdStrike managed Amazon Web Services (AWS) S3 bucket for short term storage purposes as well as a SQS (simple queue service) account for monitoring changes to the S3 bucket.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the AWS SQS / S3 to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Prerequisites

Configure FDR in CrowdStrike - You must contact the CrowdStrike support team to enable CrowdStrike FDR.
- Once CrowdStrike FDR is enabled, from the CrowdStrike console, navigate to Support --> API Clients and Keys.
- You need to Create new credentials to copy the AWS Access Key ID, AWS Secret Access Key, SQS Queue URL and AWS Region.
Register AAD application - For DCR to authentiate to ingest data into log analytics, you must use AAD application.
- Follow the instructions here (steps 1-5) to get AAD Tenant Id, AAD Client Id and AAD Client Secret.
- For AAD Principal Id of this application, access the AAD App through AAD Portal and capture Object Id from the application overview page.

Deployment Options

Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Crowdstrike Falcon Data Replicator connector V2 using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms
Provide the required details such as Microsoft Sentinel Workspace, CrowdStrike AWS credentials, Azure AD Application details and ingestion configurations

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. It is recommended to create a new Resource Group for deployment of function app and associated resources. 3. Mark the checkbox labeled I agree to the terms and conditions stated above. 4. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Crowdstrike Falcon Data Replicator connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy DCE, DCR and Custom Tables for data ingestion
Deploy the required DCE, DCR(s) and the Custom Tables by using the Data Collection Resource ARM template
After successful deployment of DCE and DCR(s), get the below information and keep it handy (required during Azure Functions app deployment).
- DCE log ingestion - Follow the instructions available at Create data collection endpoint (Step 3).
- Immutable Ids of one or more DCRs (as applicable) - Follow the instructions available at Collect information from the DCR (Stpe 2).
Deploy a Function App
Download the Azure Function App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.
Configure the Function App
Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): AWS_KEY AWS_SECRET AWS_REGION_NAME QUEUE_URL USER_SELECTION_REQUIRE_RAW //True if raw data is required USER_SELECTION_REQUIRE_SECONDARY //True if secondary data is required MAX_QUEUE_MESSAGES_MAIN_QUEUE // 100 for consumption and 150 for Premium MAX_SCRIPT_EXEC_TIME_MINUTES // add the value of 10 here AZURE_TENANT_ID AZURE_CLIENT_ID AZURE_CLIENT_SECRET DCE_INGESTION_ENDPOINT NORMALIZED_DCR_ID RAW_DATA_DCR_ID EVENT_TO_TABLE_MAPPING_LINK // File is present on github. Add if the file can be accessed using internet REQUIRED_FIELDS_SCHEMA_LINK //File is present on github. Add if the file can be accessed using internet Schedule //Add value as '0 */1 * * * *' to ensure the function runs every minute.
Once all application settings have been entered, click Save.

CTERA Syslog

Supported by: CTERA

The CTERA Data Connector for Microsoft Sentinel offers monitoring and threat detection capabilities for your CTERA solution. It includes a workbook visualizing the sum of all operations per type, deletions, and denied access operations. It also provides analytic rules which detects ransomware incidents and alert you when a user is blocked due to suspicious ransomware activity. Additionally, it helps you identify critical patterns such as mass access denied events, mass deletions, and mass permission changes, enabling proactive threat management and response.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Syslog`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Step 1: Connect CTERA Platform to Syslog

Set up your CTERA portal syslog connection and Edge-Filer Syslog connector

Step 2: Install Azure Monitor Agent (AMA) on Syslog Server

Install the Azure Monitor Agent (AMA) on your syslog server to enable data collection.

CTM360 CyberBlindSpot (Serverless)

Supported by: Cyber Threat Management 360

The CTM360 Cyber Blind Spot (CBS) connector provides integration with CTM360's CBS platform to ingest security data across 6 module types: incidents, malware logs, breached credentials, compromised cards, domain infringement, and subdomain infringement. This connector uses the Codeless Connector Framework (CCF) for serverless data collection.

Data Types:

CBSLog_AzureV2_CL
CBS_MalwareLogs_AzureV2_CL
CBS_BreachedCredentials_AzureV2_CL
CBS_CompromisedCards_AzureV2_CL
CBS_DomainInfringement_AzureV2_CL
CBS_SubdomainInfringement_AzureV2_CL

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CBSLog_AzureV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

CTM360 CBS API Key: A valid CTM360 Cyber Blind Spot API key is required to connect to the CBS API endpoint.

Setup Instructions:

Connect CTM360 Cyber Blind Spot to Microsoft Sentinel

This connector uses the Codeless Connector Framework (CCF) to ingest data from CTM360 CBS into Microsoft Sentinel. Data is collected every 5 minutes across 6 different module types.

Note: This connector creates 6 separate tables for different CBS module types: Incidents, Malware Logs, Breached Credentials, Compromised Cards, Domain Infringement, and Subdomain Infringement.

Step 1: Obtain CTM360 API Keys

To setup this integration, you will need CBS API Key. You can get these keys using the following links:

CBS API Key found from this link: https://platform.ctm360.com/start/integrations after logging with you account

Step 2: Configure Connection

Enter your CTM360 CBS API key and connect to start data ingestion.

CTM360 CBS API Key: (Enter your CTM360 CBS API Key)
Enable/Disable Connection

Step 3: Verify Data Ingestion

After connecting, data should start flowing within 5-10 minutes. Use the sample queries above to verify data ingestion for each module type.

Note: Note: Initial data ingestion may take up to 30 minutes. The connector polls every 5 minutes with a 5-minute rolling window.

CTM360 HackerView (Serverless)

Supported by: Cyber Threat Management 360

The CTM360 HackerView connector enables you to ingest security issues and vulnerabilities from your HackerView External Attack Surface Management platform into Microsoft Sentinel. This serverless connector uses the REST API to automatically pull issue data for analysis and correlation with other security events.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`HackerViewLog_AzureV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

HackerView API Key: A valid HackerView API key with permissions to access issues data is required.

Setup Instructions:

Connect CTM360 HackerView to Microsoft Sentinel

This connector uses the HackerView REST API to automatically ingest security issues into Microsoft Sentinel.

Note: This is a serverless connector that uses Azure's Codeless Connector Framework (CCF). No Azure Function deployment is required.

Step 1: Obtain CTM360 API Keys

To setup this integration, you will need HackerView API Key. You can get these keys using the following links:

HackerView API Key found from this link: https://platform.ctm360.com/start/integrations after logging with you account

Step 2: Configure the Connector

Enter your HackerView API key and click Connect to begin data ingestion.

API Key: (Enter your HackerView API Key)
Enable/Disable Connection

Step 3: Verify Data Ingestion

After connecting, data should start flowing within 5-10 minutes. Run the following query to verify:

Note: HackerViewLog_AzureV2_CL | take 10

Custom logs via AMA

Supported by: Microsoft Corporation

Many applications log information to text or JSON files instead of standard logging services, such as Windows Event logs, Syslog or CEF. The Custom Logs data connector allows you to collect events from files on both Windows and Linux computers and stream them to custom logs tables you created. While streaming the data you can parse and transform the contents using the DCR. After collecting the data, you can apply analytic rules, hunting, searching, threat intelligence, enrichments and more.

NOTE: Use this connector for the following devices: Cisco Meraki, Zscaler Private Access (ZPA), VMware vCenter, Apache HTTP server, Apache Tomcat, Jboss Enterprise application platform, Juniper IDP, MarkLogic Audit, MongoDB Audit, Nginx HTTP server, Oracle Weblogic server, PostgreSQL Events, Squid Proxy, Ubiquiti UniFi, SecurityBridge Threat detection SAP and AI vectra stream.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`JBossEvent_CL`	No	No
`JuniperIDP_CL`	Yes	Yes
`ApacheHTTPServer_CL`	Yes	Yes
`Tomcat_CL`	Yes	Yes
`meraki_CL`	Yes	Yes
`VectraStream_CL`	No	No
`MarkLogicAudit_CL`	No	No
`MongoDBAudit_CL`	Yes	Yes
`NGINX_CL`	Yes	Yes
`OracleWebLogicServer_CL`	Yes	Yes
`PostgreSQL_CL`	Yes	Yes
`SquidProxy_CL`	Yes	Yes
`Ubiquiti_CL`	Yes	Yes
`vcenter_CL`	Yes	Yes
`ZPA_CL`	Yes	Yes
`SecurityBridgeLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Permissions: To collect data from non-Azure VMs, they must have Azure Arc installed and enabled. Learn more

Setup Instructions:

Enable data collection rule

Custom logs are collected from both Windows and Linux agents.

Install Agent: <variable value provided at install time>

CyberArk Audit

Supported by: CyberArk Support

The CyberArk Audit data connector enables Microsoft Sentinel to ingest security event logs and other events from the CyberArk Audit service via REST API. This integration helps you detect potential security risks, monitor user activity, analyze collaboration patterns, troubleshoot configuration issues, and gain deeper insights into your environment.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyberArk_AuditEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

CyberArk Audit Service Platform: Access to perform required configurations in CyberArk Audit platform

Setup Instructions:

Connect to CyberArk Audit API to start collecting event logs in Microsoft Sentinel

Follow the steps below to integrate Microsoft Sentinel with CyberArk Audit and enable centralized monitoring of system and user activities within Microsoft Sentinel. You can also refer to the CyberArk Audit documentation and follow till Step 5.

Step1: Create new SIEM integration

On CyberArk portal, go to Administration.
Select My environment > Integrations > Export to SIEM.
In the SIEM integrations page, select Create > Create SIEM integration
In the Create a SIEM integration page, select the Identity Administration link to create an OAuth server web in Identity Administration. Step 2: Create an OAuth2 server web app in Identity Administration
On Identity Administration page, from the left menu select Apps & Widgets > Web Apps
Select Add Web Apps and create an OAuth2 server type web app from the Custom tab.
Enter CyberArkAuditforMicrosoftSentinel in the ApplicationID and Name fields.
In the Tokens tab, ensure that the value in the Token Type field is jwtR256 and only the Client Creds authorization method is selected.
Click Add in the Scope tab and enter isp.audit.events:read.
In the Advanced tab, copy and paste the following script and then click Save.

		setClaim('tenant_id', TenantData.Get("CybrTenantID"));
		setClaim('aud', 'cyberark.isp.audit');

Click Save. Step 3: Create a service user in Identity Administration
Go to the Core Services > Users, select Add User.
In the Account section, enter the Login name and Display name as MicrosoftSentinel. Add a new password or generate the password automatically.
Select OAuth confidential client.
In the Application Settings tab, click Add.
Select the CyberArkAuditforMicrosoftSentinel application. This is the name you created in the web service. Step 4: Grant web app permissions to the service user
Go to the CyberArkAuditforMicrosoftSentinel web app you created.
In the Permissions tab, click Add to find your user MicrosoftSentinel and then click Add.
Set the following permissions for the user:
- Grant
- View
- Run
- Automatically deploy Step 5: Define the integration description
Go to Administration.
Select My environment > Integrations > Export to SIEM.
Select Create > Create SIEM integration.
Enter the name as Microsoft Sentinel Integration and optionally add a description.
Click Apply. Step 6: Connect CyberArk Audit Service with Microsoft Sentinel Data Connector

Note: Copy all the details you captured in the previous steps and connect with the CyberArk Audit service.

OAuth2 Server App Name: (e.g. AuditforMicrosoftSentinel)
Audit API Key: (The API Key can be retrieved from the Audit service)
Identity Endpoint: (e.g. kln9281.id.cyberark.cloud)
Audit API Base URL: (e.g. org-test.audit.cyberark.cloud)
Audit Query Filter Action (Optional): (e.g. {"op":"include","params":["cloud.core.login","cloud.core.mfasummary"]})
Audit Query Filter Application Code (Optional): (e.g. {"op":"include","params":["IDP","CMS"]})
Audit Query Filter Audit Type (Optional): (e.g. {"op":"include","params":["Failure"]})

CyberArkAudit (using Azure Functions)

Supported by: CyberArk Support

The CyberArk Audit data connector provides the capability to retrieve security event logs of the CyberArk Audit service and more events into Microsoft Sentinel through the REST API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyberArk_AuditEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Audit REST API Connections details and Credentials: OauthUsername, OauthPassword, WebAppID, AuditApiKey, IdentityEndpoint and AuditApiBaseUrl are required for making API calls.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Azure Blob Storage API to pull logs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

NOTE: API authorization key(s) or token(s) are securely stored in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values.

STEP 1 - Configuration steps for the CyberArk Audit SIEM Integration

Follow the instructions to obtain connection details and credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the CyberArk Audit data connector, have the Workspace Name and Workspace Location (can be copied from the following).

Workspace Name: <variable value provided at install time>
Workspace Location: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the CyberArk Audit data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the CyberArkAuditUsername, CyberArkAuditPassword, CyberArkAuditServerURL and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the CyberArk Audit data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CyberArkXXXXX).

e. Select a runtime: Choose Python 3.10.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): CyberArkAuditUsername CyberArkAuditPassword CyberArkAuditServerURL WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Cybersixgill Actionable Alerts (using Azure Functions)

Supported by: Cybersixgill

Actionable alerts provide customized alerts based on configured assets

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyberSixgill_Alerts_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: Client_ID and Client_Secret are required for making API calls.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Cybersixgill API to pull Alerts into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Cybersixgill Actionable Alerts data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, Client ID, Client Secret, TimeInterval and deploy.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Cybersixgill Actionable Alerts data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE:You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CybersixgillAlertsXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): ClientID ClientSecret Polling WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us

Once all application settings have been entered, click Save.

Cyble Vision Alerts

Supported by: Cyble Support

The Cyble Vision Alerts CCF Data Connector enables Ingestion of Threat Alerts from Cyble Vision into Microsoft Sentinel using the Codeless Connector Framework Connector. It collects alert data via API, normalizes it, and stores it in a custom table for advanced detection, correlation, and response.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CybleVisionAlerts_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Cyble Vision API token: An API Token from Cyble Vision Platform is required.

Setup Instructions:

Step 1 - Generating API Token from Cyble Platform

Navigate to Cyble Platform and log in using your Cyble Vision credentials.

Once logged in, go to the left-hand panel and scroll down to Utilities. Click on Access APIs. On the top-right corner of the page, click the + (Add) icon to generate a new API key. Provide an alias (a friendly name for your key) and click Generate. Copy the generated API token and store it securely.

STEP 2 - Configure the Data Connector

Return to Microsoft Sentinel and open the Cyble Vision Alerts data connector configuration page. Paste your Cyble API Token into the API Token field under 'API Details'.

API Token: (Enter your API Token)
Query Interval (in minutes): (Enter Time in Minutes (e.g., 10))
Enable/Disable Connection

Cyborg Security HUNTER Hunt Packages

Supported by: Cyborg Security

Cyborg Security is a leading provider of advanced threat hunting solutions, with a mission to empower organizations with cutting-edge technology and collaborative tools to proactively detect and respond to cyber threats. Cyborg Security's flagship offering, the HUNTER Platform, combines powerful analytics, curated threat hunting content, and comprehensive hunt management capabilities to create a dynamic ecosystem for effective threat hunting operations.

Follow the steps to gain access to Cyborg Security's Community and setup the 'Open in Tool' capabilities in the HUNTER Platform.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`SecurityEvent`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Note: Use the following link to find your Azure Tentant ID How to find your Azure Active Directory tenant ID

ResourceGroupName & WorkspaceName: <variable value provided at install time>
WorkspaceID: <variable value provided at install time>

1. Sign up for Cyborg Security's HUNTER Community Account

Cyborg Security offers Community Memebers access to a subset of the Emerging Threat Collections and hunt packages.

Create a Free Commuinity Account to get access to Cyborg Security's Hunt Packages: Sign Up Now!

2. Configure the Open in Tool Feature

Navigate to the Environment section of the HUNTER Platform.
Fill in te Root URI of your environment in the section labeled Microsoft Sentinel. Replace the <bolded items> with the IDs and Names of your Subscription, Resource Groups and Workspaces.

https[]()://portal.azure.com#@**AzureTenantID**/blade/Microsoft_OperationsManagementSuite_Workspace/Logs.ReactView/resourceId/%2Fsubscriptions%2F**AzureSubscriptionID**%2Fresourcegroups%2F**ResourceGroupName**%2Fproviders%2Fmicrosoft.operationalinsights%2Fworkspaces%2F<**WorkspaceName**>/
Click Save.

3. Execute a HUNTER hunt pacakge in Microsoft Sentinel

Identify a Cyborg Security HUNTER hunt package to deploy and use the Open In Tool button to quickly open Microsoft Sentinel and stage the hunting content.

Cyera DSPM Microsoft Sentinel Data Connector

Supported by: Cyera Inc

The Cyera DSPM data connector allows you to connect to your Cyera's DSPM tenant and ingesting Classifications, Assets, Issues, and Identity Resources/Definitions into Microsoft Sentinel. The data connector is built on Microsoft Sentinel's Codeless Connector Framework and uses the Cyera's API to fetch Cyera's DSPM Telemetry once received can be correlated with security events creating custom columns so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyeraClassifications_CL`	No	No
`CyeraAssets_CL`	No	No
`CyeraAssets_MS_CL`	No	No
`CyeraIssues_CL`	No	No
`CyeraIdentities_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Cyera DSPM Authentication

Connect to your Cyera DSPM tenenant via Personal Access Tokens

Cyera Personal Access Token Client ID: (client_id)
Cyera Personal Access Token Secret Key: (secret_key)
Enable/Disable Connection

CYFIRMA Attack Surface

Supported by: CYFIRMA

N/A

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaASCertificatesAlerts_CL`	Yes	Yes
`CyfirmaASConfigurationAlerts_CL`	Yes	Yes
`CyfirmaASDomainIPReputationAlerts_CL`	Yes	Yes
`CyfirmaASOpenPortsAlerts_CL`	Yes	Yes
`CyfirmaASCloudWeaknessAlerts_CL`	Yes	Yes
`CyfirmaASDomainIPVulnerabilityAlerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Attack Surface

Connect to CYFIRMA Attack Surface to ingest alerts into Microsoft Sentinel. This connector uses the DeCYFIR/DeTCT API to retrieve logs and supports DCR-based ingestion time transformations, parsing security data into custom tables during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
API Delta: (API Delta)
Enable/Disable Connection

CYFIRMA Brand Intelligence

Supported by: CYFIRMA

N/A

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaBIDomainITAssetAlerts_CL`	Yes	Yes
`CyfirmaBIExecutivePeopleAlerts_CL`	Yes	Yes
`CyfirmaBIProductSolutionAlerts_CL`	Yes	Yes
`CyfirmaBISocialHandlersAlerts_CL`	Yes	Yes
`CyfirmaBIMaliciousMobileAppsAlerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Brand Intelligence

Connect to CYFIRMA Brand Intelligence to ingest alerts data into Microsoft Sentinel. This connector uses the DeCYFIR/DeTCT Alerts API to retrieve logs and supports DCR-based ingestion time transformations, parsing security data into custom tables during ingestion. This enhances performance and efficiency by eliminating the need for query-time parsing.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
API Delta: (API Delta)
Enable/Disable Connection

CYFIRMA Compromised Accounts

Supported by: CYFIRMA

The CYFIRMA Compromised Accounts data connector enables seamless log ingestion from the DeCYFIR/DeTCT API into Microsoft Sentinel. Built on the Microsoft Sentinel Codeless Connector Framework, it leverages the DeCYFIR/DeTCT API to retrieve logs. Additionally, it supports DCR-based ingestion time transformations, which parse security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaCompromisedAccounts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Compromised Accounts

The CYFIRMA Compromised Accounts Data Connector enables seamless log ingestion from the DeCYFIR/DeTCT API into Microsoft Sentinel. Built on the Microsoft Sentinel Codeless Connector Framework, it leverages the DeCYFIR/DeTCT API to retrieve logs. Additionally, it supports DCR-based ingestion time transformations, which parse security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
API Delta: (API Delta)
Enable/Disable Connection

CYFIRMA Cyber Intelligence

Supported by: CYFIRMA

The CYFIRMA Cyber Intelligence data connector enables seamless log ingestion from the DeCYFIR API into Microsoft Sentinel. Built on the Microsoft Sentinel Codeless Connector Framework, it leverages the DeCYFIR Alerts API to retrieve logs. Additionally, it supports DCR-based ingestion time transformations, which parse security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaIndicators_CL`	Yes	Yes
`CyfirmaThreatActors_CL`	Yes	Yes
`CyfirmaCampaigns_CL`	Yes	Yes
`CyfirmaMalware_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Cyber Intelligence

This connector provides the Indicators, Threat actors, Malware and Campaigns logs from CYFIRMA Cyber Intelligence. The connector uses the DeCYFIR API to retrieve logs and supports DCR-based ingestion time transformations, parsing security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
Pull all IoC's Or Tailored IoC's: (All IoC's or Tailored IoC's)
API Delta: (API Delta)
Recommended Actions: (Recommended Action can be any one of:All/Monitor/Block)
Threat Actor Associated: (Is any Threat Actor Associated with the IoC's)
Enable/Disable Connection

CYFIRMA Digital Risk

Supported by: CYFIRMA

The CYFIRMA Digital Risk Alerts data connector enables seamless log ingestion from the DeCYFIR/DeTCT API into Microsoft Sentinel. Built on the Microsoft Sentinel Codeless Connector Framework, it leverages the DeCYFIR Alerts API to retrieve logs. Additionally, it supports DCR-based ingestion time transformations, which parse security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaDBWMPhishingAlerts_CL`	Yes	Yes
`CyfirmaDBWMRansomwareAlerts_CL`	Yes	Yes
`CyfirmaDBWMDarkWebAlerts_CL`	Yes	Yes
`CyfirmaSPESourceCodeAlerts_CL`	Yes	Yes
`CyfirmaSPEConfidentialFilesAlerts_CL`	Yes	Yes
`CyfirmaSPEPIIAndCIIAlerts_CL`	Yes	Yes
`CyfirmaSPESocialThreatAlerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Digital Risk

Connect to CYFIRMA Digital Risk Alerts to ingest logs into Microsoft Sentinel. This connector uses the DeCYFIR/DeTCT API to retrieve alerts and supports DCR-based ingestion time transformations for efficient log parsing.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
API Delta: (API Delta)
Enable/Disable Connection

CYFIRMA Vulnerabilities Intelligence

Supported by: CYFIRMA

The CYFIRMA Vulnerabilities Intelligence data connector enables seamless log ingestion from the DeCYFIR API into Microsoft Sentinel. Built on the Microsoft Sentinel Codeless Connector Framework, it leverages the CYFIRMA API's to retrieve logs. Additionally, it supports DCR-based ingestion time transformations, which parse security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyfirmaVulnerabilities_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

CYFIRMA Vulnerabilities Intelligence

This connector provides the Vulnerabilities logs from CYFIRMA Vulnerabilities Intelligence. The connector uses the DeCYFIR API to retrieve logs and supports DCR-based ingestion time transformations, parsing security data into a custom table during ingestion. This eliminates the need for query-time parsing, enhancing performance and efficiency.

CYFIRMA API URL: (https://decyfir.cyfirma.com)
CYFIRMA API Key: (CYFIRMA API Key)
API Delta: (API Delta)
Vendor-Associated Vulnerabilities:
Product-Associated Vulnerabilities:
Product with Version-Associated Vulnerabilities:
Enable/Disable Connection

Cynerio Security Events

Supported by: Cynerio

The Cynerio connector allows you to easily connect your Cynerio Security Events with Microsoft Sentinel, to view IDS Events. This gives you more insight into your organization network security posture and improves your security operation capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CynerioEvent_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Configure and connect Cynerio

Cynerio can integrate with and export events directly to Microsoft Sentinel via Azure Server. Follow these steps to establish integration:

In the Cynerio console, go to Settings > Integrations tab (default), and click on the +Add Integration button at the top right.
Scroll down to the SIEM section.
On the Microsoft Sentinel card, click the Connect button.
The Integration Details window opens. Use the parameters below to fill out the form and set up the connection.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Cyren Threat Intelligence

Supported by: Data443 Risk Mitigation, Inc.

Ingest IP reputation and malware URL indicators from Cyren using the Common Connector Framework (CCF).

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Cyren_Indicators_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Cyren JWT Tokens: JWT tokens stored in Azure Key Vault or provided at deployment time.

Setup Instructions:

Connect Cyren Threat Intelligence

To enable the Cyren Threat Intelligence connector, provide your JWT tokens below and click Connect.

Note: You can use either feed or both depending on your subscription. Leave the token field empty for any feed you have not purchased — only the connectors for provided tokens will be deployed.

For enhanced security, you can enable Key Vault integration to store and retrieve the JWT tokens.

IP Reputation JWT Token (Optional): (Leave empty if not purchased)
Malware URL JWT Token (Optional): (Leave empty if not purchased)
Enable/Disable Connection

D3 Smart SOAR Incidents

Supported by: D3 Security

The D3 Smart SOAR data connector pulls incidents from D3 Smart SOAR into Microsoft Sentinel using the D3 codeless REST API command endpoint.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`D3SOARIncidents_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Connect D3 Smart SOAR to Microsoft Sentinel

Prerequisite: In D3 Smart SOAR, navigate to Organization Management → Sites, select the site you are connecting, and set its Time Zone to (UTC+00:00) Coordinated Universal Time. This ensures incident timestamps are correctly aligned with Microsoft Sentinel.

Enter your D3 Smart SOAR connection details below. Incidents will be polled every 5 minutes and written to the D3SOARIncidents_CL table. Server URL — The base URL of your D3 Smart SOAR deployment, up to and including the site path. Do not include the API path. Username — Your D3 Smart SOAR account username (same as your portal login). Site — The D3 Smart SOAR site name your account belongs to (e.g. Security Operations). D3 JWT — A JSON Web Token issued by D3 Smart SOAR for API authentication.

Server URL: (https://poc.bemimo.com/ce_site/VSOC)
Username: (admin)
Site: (Security Operations)
D3 JWT: (ey...)
Enable/Disable Connection

Darktrace Connector for Microsoft Sentinel REST API

Supported by: Darktrace

The Darktrace REST API connector pushes real-time events from Darktrace to Microsoft Sentinel and is designed to be used with the Darktrace Solution for Sentinel. The connector writes logs to a custom log table titled "darktrace_model_alerts_CL"; Model Breaches, AI Analyst Incidents, System Alerts and Email Alerts can be ingested - additional filters can be set up on the Darktrace System Configuration page. Data is pushed to Sentinel from Darktrace masters.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`darktrace_model_alerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Darktrace Prerequisites: To use this Data Connector a Darktrace master running v5.2+ is required. Data is sent to the Azure Monitor HTTP Data Collector API over HTTPs from Darktrace masters, therefore outbound connectivity from the Darktrace master to Microsoft Sentinel REST API is required.
Filter Darktrace Data: During configuration it is possible to set up additional filtering on the Darktrace System Configuration page to constrain the amount or types of data sent.
Try the Darktrace Sentinel Solution: You can get the most out of this connector by installing the Darktrace Solution for Microsoft Sentinel. This will provide workbooks to visualise alert data and analytics rules to automatically create alerts and incidents from Darktrace Model Breaches and AI Analyst incidents.

Setup Instructions:

Detailed setup instructions can be found on the Darktrace Customer Portal: https://customerportal.darktrace.com/product-guides/main/microsoft-sentinel-introduction
Take note of the Workspace ID and the Primary key. You will need to enter these details on your Darktrace System Configuration page.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Darktrace Configuration

Perform the following steps on the Darktrace System Configuration page:
Navigate to the System Configuration Page (Main Menu > Admin > System Config)
Go into Modules configuration and click on the "Microsoft Sentinel" configuration card
Select "HTTPS (JSON)" and hit "New"
Fill in the required details and select appropriate filters
Click "Verify Alert Settings" to attempt authentication and send out a test alert
Run a "Look for Test Alerts" sample query to validate that the test alert has been received

DataBahn

Supported by: Databahn

The DataBahn connector provides the capability to push real-time platform telemetry from your DataBahn environment directly into Microsoft Sentinel using the Codeless Connector Framework (CCF) Push pattern. This connector ingests audit logs, operational alerts, and device inventory into custom Log Analytics tables for analysis, alerting, and visualization.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`databahn_audit_logs_CL`	No	No
`databahn_alerts_CL`	No	No
`databahn_device_inventory_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.
Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector enables your DataBahn platform to push audit logs, alerts, and device inventory directly to Microsoft Sentinel via the Azure Monitor Ingestion API.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will trigger the creation of Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Configure Your DataBahn Platform

Use the following parameters to configure your DataBahn Highway destination to push data to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>
Entra App Registration Application ID: <variable value provided at install time>
Entra App Registration Secret: <variable value provided at install time>
Data Collection Endpoint Uri: <variable value provided at install time>
Data Collection Rule Immutable ID: <variable value provided at install time>
Audit Logs Stream Name: <variable value provided at install time>
Alerts Stream Name: <variable value provided at install time>
Device Inventory Stream Name: <variable value provided at install time>

Datalake2Sentinel

Supported by: Orange Cyberdefense

This solution installs the Datalake2Sentinel connector which is built using the Codeless Connector Framework and allows you to automatically ingest threat intelligence indicators from Datalake Orange Cyberdefense's CTI platform into Microsoft Sentinel via the Upload Indicators REST API. After installing the solution, configure and enable this data connector by following guidance in Manage solution view.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ThreatIntelligenceIndicator`	Yes	No

Data collection rule support: Workspace transform DCR

Setup Instructions:

Installation and setup instructions

Use the documentation from this Github repository to install and configure the Datalake to Microsoft Sentinel connector.

https://github.com/cert-orangecyberdefense/datalake2sentinel

Dataminr Pulse Alerts Data Connector (using Azure Functions)

Supported by: Dataminr Support

Dataminr Pulse Alerts Data Connector brings our AI-powered real-time intelligence into Microsoft Sentinel for faster threat detection and response.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DataminrPulse_Alerts_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.
Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Required Dataminr Credentials/permissions:

a. Users must have a valid Dataminr Pulse API client ID and secret to use this data connector.

b. One or more Dataminr Pulse Watchlists must be configured in the Dataminr Pulse website.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the DataminrPulse in which logs are pushed via Dataminr RTAP and it will ingest logs into Microsoft Sentinel. Furthermore, the connector will fetch the ingested data from the custom logs table and create Threat Intelligence Indicators into Microsoft Sentinel Threat Intelligence. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1- Credentials for the Dataminr Pulse Client ID and Client Secret

Obtain Dataminr Pulse user ID/password and API client ID/secret from your Dataminr Customer Success Manager (CSM).

STEP 2- Configure Watchlists in Dataminr Pulse portal.

Follow the steps in this section to configure watchlists in portal:

Login to the Dataminr Pulse website.
Click on the settings gear icon, and select Manage Lists.
Select the type of Watchlist you want to create (Cyber, Topic, Company, etc.) and click the New List button.
Provide a name for your new Watchlist, and select a highlight color for it, or keep the default color.
When you are done configuring the Watchlist, click Save to save it.

STEP 3 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.
Search for and select Microsoft Entra ID.
Under Manage, select App registrations > New registration.
Enter a display Name for your application.
Select Register to complete the initial app registration.
When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of DataminrPulse Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 4 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of DataminrPulse Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.
Select Certificates & secrets > Client secrets > New client secret.
Add a description for your client secret.
Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.
Select Add.
Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of DataminrPulse Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 5 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.
Go to Access control (IAM) from left panel.
Click on Add, and then select Add role assignment.
Select Contributor as role and click on next.
In Assign access to, select User, group, or service principal.
Click on add members and type your app name that you have created and select it.
Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 6 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Dataminr Pulse Microsoft Sentinel data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DataminrPulse connector.

Click the Deploy to Azure button below.

aka.ms aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the below information : Function Name Workspace ID Workspace Key AlertsTableName BaseURL ClientId ClientSecret AzureClientId AzureClientSecret AzureTenantId AzureResourceGroupName AzureWorkspaceName AzureSubscriptionId Schedule LogLevel
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Dataminr Pulse Microsoft Sentinel data connector manually with Azure Functions (Deployment via Visual Studio Code).

1) Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. DmPulseXXXXX).

e. Select a runtime: Choose Python 3.8 or above.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.

2) Configure the Function App

In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective values (case-sensitive): Function Name Workspace ID Workspace Key AlertsTableName BaseURL ClientId ClientSecret AzureClientId AzureClientSecret AzureTenantId AzureResourceGroupName AzureWorkspaceName AzureSubscriptionId Schedule LogLevel logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

STEP 7 - Post Deployment steps

1) Get the Function app endpoint

Go to Azure function Overview page and Click on "Functions" in the left blade.
Click on the function called "DataminrPulseAlertsHttpStarter".
Go to "GetFunctionurl" and copy the function url.
Replace {functionname} with "DataminrPulseAlertsSentinelOrchestrator" in copied function url.

2) To add integration settings in Dataminr RTAP using the function URL

Open any API request tool like Postman.
Click on '+' to create a new request.
Select HTTP request method as 'POST'.
Enter the url prepapred in point 1), in the request URL part.
In Body, select raw JSON and provide request body as below(case-sensitive): { "integration-settings": "ADD", "url": "(URL part from copied Function-url)", "token": "(value of code parameter from copied Function-url)" }
After providing all required details, click Send.
You will receive an integration setting ID in the HTTP response with a status code of 200.
Save Integration ID for future reference.

Now we are done with the adding integration settings for Dataminr RTAP. Once the Dataminr RTAP send an alert data, Function app is triggered and you should be able to see the Alerts data from the Dataminr Pulse into LogAnalytics workspace table called "DataminrPulse_Alerts_CL".

Datawiza DAP

Supported by: Datawiza Technology Inc.

Connects the Datawiza DAP logs to Azure Log Analytics via the REST API interface

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`datawizaserveraccess_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Step 1 : Read the detailed documentation

The installation process is documented in great detail in the documentation site Microsoft Sentinel integration. The user should consult our support (support@datawiza.com) further to understand installation and debug of the integration.

Step 2: Install the Datawiza Sentinel Connector

The next step is to install the Datawiza log forwarder to send logs to Microsoft Sentinel. The exact installation will depend on your environment, consult the Microsoft Sentinel integration for full details.

Step 3: Test the data ingestion

After approximately 20 minutes access the Log Analytics workspace on your Microsoft Sentinel installation, and locate the Custom Logs section verify that a datawizaserveraccess_CL table exists. Use the sample queries to examine the data.

Derdack SIGNL4

Supported by: Derdack

When critical systems fail or security incidents happen, SIGNL4 bridges the ‘last mile’ to your staff, engineers, IT admins and workers in the field. It adds real-time mobile alerting to your services, systems, and processes in no time. SIGNL4 notifies through persistent mobile push, SMS text and voice calls with acknowledgement, tracking and escalation. Integrated duty and shift scheduling ensure the right people are alerted at the right time.

Learn more >

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`SecurityIncident`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

NOTE: This data connector is mainly configured on the SIGNL4 side. You can find a description video here: Integrate SIGNL4 with Microsoft Sentinel.

SIGNL4 Connector: The SIGNL4 connector for Microsoft Sentinel, Azure Security Center and other Azure Graph Security API providers provides seamless 2-way integration with your Azure Security solutions. Once added to your SIGNL4 team, the connector will read security alerts from Azure Graph Security API and fully automatically and trigger alert notifications to your team members on duty. It will also synchronize the alert status from SIGNL4 to Graph Security API, so that if alerts are acknowledged or closed, this status is also updated on the according Azure Graph Security API alert or the corresponding security provider. As mentioned, the connector mainly uses Azure Graph Security API, but for some security providers, such as Microsoft Sentinel, it also uses dedicated REST APIs from according Azure solutions.

Microsoft Sentinel Features

Microsoft Sentinel is a cloud native SIEM solution from Microsoft and a security alert provider in Azure Graph Security API. However, the level of alert details available with the Graph Security API is limited for Microsoft Sentinel. The connector can therefore augment alerts with further details (insights rule search results), from the underlying Microsoft Sentinel Log Analytics workspace. To be able to do that, the connector communicates with Azure Log Analytics REST API and needs according permissions (see below). Furthermore, the app can also update the status of Microsoft Sentinel incidents, when all related security alerts are e.g. in progress or resolved. In order to be able to do that, the connector needs to be a member of the 'Microsoft Sentinel Contributors' group in your Azure Subscription. Automated deployment in Azure The credentials required to access the beforementioned APIs, are generated by a small PowerShell script that you can download below. The script performs the following tasks for you:

Logs you on to your Azure Subscription (please login with an administrator account)
Creates a new enterprise application for this connector in your Azure AD, also referred to as service principal
Creates a new role in your Azure IAM that grants read/query permission to only Azure Log Analytics workspaces.
Joins the enterprise application to that user role
Joins the enterprise application to the 'Microsoft Sentinel Contributors' role
Outputs some data that you need to configure app (see below)

Deployment procedure

Download the PowerShell deployment script from here.
Review the script and the roles and permission scopes it deploys for the new app registration. If you don't want to use the connector with Microsoft Sentinel, you could remove all role creation and role assignment code and only use it to create the app registration (SPN) in your Azure Active Directory.
Run the script. At the end it outputs information that you need to enter in the connector app configuration.
In Azure AD, click on 'App Registrations'. Find the app with the name 'SIGNL4AzureSecurity' and open its details
On the left menu blade click 'API Permissions'. Then click 'Add a permission'.
On the blade that loads, under 'Microsoft APIs' click on the 'Microsoft Graph' tile, then click 'App permission'.
In the table that is displayed expand 'SecurityEvents' and check 'SecurityEvents.Read.All' and 'SecurityEvents.ReadWrite.All'.
Click 'Add permissions'.

Configuring the SIGNL4 connector app

Finally, enter the IDs, that the script has outputted in the connector configuration:

Azure Tenant ID
Azure Subscription ID
Client ID (of the enterprise application)
Client Secret (of the enterprise application) Once the app is enabled, it will start reading your Azure Graph Security API alerts.

NOTE: It will initially only read the alerts that have occurred within the last 24 hours.

Workspace ID: <variable value provided at install time>

Digital Shadows Searchlight (using Azure Functions)

Supported by: Digital Shadows

The Digital Shadows data connector provides ingestion of the incidents and alerts from Digital Shadows Searchlight into the Microsoft Sentinel using the REST API. The connector will provide the incidents and alerts information such that it helps to examine, diagnose and analyse the potential security risks and threats.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DigitalShadows_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: Digital Shadows account ID, secret and key is required. See the documentation to learn more about API on the https://portal-digitalshadows.com/learn/searchlight-api/overview/description.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a 'Digital Shadows Searchlight' to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1 - Configuration steps for the 'Digital Shadows Searchlight' API

The provider should provide or link to detailed steps to configure the 'Digital Shadows Searchlight' API endpoint so that the Azure Function can authenticate to it successfully, get its authorization key or token, and pull the appliance's logs into Microsoft Sentinel.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the 'Digital Shadows Searchlight' connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the 'Digital Shadows Searchlight' API authorization key(s) or Token, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the 'Digital Shadows Searchlight' connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, API Username, API Password, 'and/or Other required fields'.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the 'Digital Shadows Searchlight' connector manually with Azure Functions.

1. Create a Function App

From the Azure Portal, navigate to Function App.
Click + Create at the top.
In the Basics tab, ensure Runtime stack is set to python 3.8.
In the Hosting tab, ensure Plan type is set to 'Consumption (Serverless)'. 5.select Storage account
'Add other required configurations'.
'Make other preferable configuration changes', if needed, then click Create.

2. Import Function App Code(Zip deployment)

Install Azure CLI
From terminal type az functionapp deployment source config-zip -g <ResourceGroup> -n <FunctionApp> --src <Zip File> and hit enter. Set the ResourceGroup value to: your resource group name. Set the FunctionApp value to: your newly created function app name. Set the Zip File value to: digitalshadowsConnector.zip(path to your zip file). Note:- Download the zip file from the link - Function App Code

3. Configure the Function App

In the Function App screen, click the Function App name and select Configuration.
In the Application settings tab, select + New application setting.
Add each of the following 'x (number of)' application settings individually, under Name, with their respective string values (case-sensitive) under Value: DigitalShadowsAccountID WorkspaceID WorkspaceKey DigitalShadowsKey DigitalShadowsSecret HistoricalDays DigitalShadowsURL ClassificationFilterOperation HighVariabilityClassifications FUNCTION_NAME logAnalyticsUri (optional) (add any other settings required by the Function App) Set the DigitalShadowsURL value to: https://api.searchlight.app/v1 Set the HighVariabilityClassifications value to: exposed-credential,marked-document Set the ClassificationFilterOperation value to: exclude for exclude function app or include for include function app

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Azure Key Vault references documentation for further details.

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

DNS

Supported by: Microsoft Corporation

The DNS log connector allows you to easily connect your DNS analytic and audit logs with Microsoft Sentinel, and other related data, to improve investigation.

When you enable DNS log collection you can:

Identify clients that try to resolve malicious domain names.
Identify stale resource records.
Identify frequently queried domain names and talkative DNS clients.
View request load on DNS servers.
View dynamic DNS registration failures.

For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DnsEvents`	Yes	Yes
`DnsInventory`	Yes	Yes

Data collection rule support: Workspace transform DCR

Doppel Data Connector

Supported by: Doppel

The data connector is built on Microsoft Sentinel for Doppel events and alerts and supports DCR-based ingestion time transformations that parses the received security event data into a custom columns so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DoppelTable_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra Tenant ID, Client ID and Client Secret: Microsoft Entra ID requires a Client ID and Client Secret to authenticate your application. Additionally, Global Admin/Owner level access is required to assign the Entra-registered application a Resource Group Monitoring Metrics Publisher role.
Requires Workspace ID, DCE-URI, DCR-ID: You will need to get the Log Analytics Workspace ID, DCE Logs Ingestion URI and DCR Immutable ID for the configuration.

Setup Instructions:

Configure Doppel Webhook

Configure the Webhook in Doppel and Endpoint with permissions in Microsoft Sentinel to send data.

Register the Application in Microsoft Entra ID

Open the Microsoft Entra ID page:
- Click the provided link to open the Microsoft Entra ID registration page in a new tab.
- Ensure you are logged in with an account that has Admin level permissions.
Create a New Application:
- In the Microsoft Entra ID portal, select App registrations mentioned on the left-hand side tab.
- Click on + New registration.
- Fill out the following fields:

Name: Enter a name for the app (e.g., “Doppel App”).
Supported account types: Choose Accounts in this organizational directory only (Default Directory only - Single tenant).
Redirect URI: Leave this blank unless required otherwise.
- Click Register to create the application.

Copy Application and Tenant IDs:
- Once the app is registered, note the Application (client) ID and Directory (tenant) ID from the Overview page. You’ll need these for the integration.
Create a Client Secret:
- In the Certificates & secrets section, click + New client secret.
- Add a description (e.g., 'Doppel Secret') and set an expiration (e.g., 1 year).
- Click Add.
- Copy the client secret value immediately, as it will not be shown again.

Assign the "Monitoring Metrics Publisher" Role to the App

Open the Resource Group in Azure Portal:
- Navigate to the Resource Group that contains the Log Analytics Workspace and Data Collection Rules (DCRs) where you want the app to push data.
Assign the Role:
- In the Resource Group menu, click on Access control (IAM) mentioned on the left-hand side tab ..
- Click on + Add and select Add role assignment.
- In the Role dropdown, search for and select the Monitoring Metrics Publisher role.
- Under Assign access to, choose Azure AD user, group, or service principal.
- In the Select field, search for your registered app by name or client ID.
- Click Save to assign the role to the application.

Deploy the ARM Template

Retrieve the Workspace ID:
- After assigning the role, you will need the Workspace ID.
- Navigate to the Log Analytics Workspace within the Resource Group.
- In the Overview section, locate the Workspace ID field under Workspace details.
- Copy the Workspace ID and keep it handy for the next steps.
Click the Deploy to Azure Button:
- portal.azure.com.
- This will take you directly to the Azure portal to start the deployment.
Review and Customize Parameters:
- On the custom deployment page, ensure you’re deploying to the correct subscription and resource group.
- Fill in the parameters like workspace name, workspace ID, and workspace location.
Click Review + Create and then Create to deploy the resources.

Verify DCE, DCR, and Log Analytics Table Setup

Check the Data Collection Endpoint (DCE):
- After deploying, go to Azure Portal > Data Collection Endpoints.
- Verify that the DoppelDCE endpoint has been created successfully.
- Copy the DCE Logs Ingestion URI, as you’ll need this for generating the webhook URL.
Confirm Data Collection Rule (DCR) Setup:
- Go to Azure Portal > Data Collection Rules.
- Ensure the DoppelDCR rule is present.
- Copy the Immutable ID of the DCR from the Overview page, as you’ll need it for the webhook URL.
Validate Log Analytics Table:
- Navigate to your Log Analytics Workspace (linked to Microsoft Sentinel).
- Under the Tables section, verify that the DoppelTable_CL table has been created successfully and is ready to receive data.

Integrate Doppel Alerts with Microsoft Sentinel

Gather Necessary Information:
- Collect the following details required for integration:

Data Collection Endpoint ID (DCE-ID)
Data Collection Rule ID (DCR-ID)
Microsoft Entra Credentials: Tenant ID, Client ID, and Client Secret.

Coordinate with Doppel Support:
- Share the collected DCE-ID, DCR-ID, and Microsoft Entra credentials with Doppel support.
- Request assistance to configure these details in the Doppel tenant to enable webhook setup.
Webhook Setup by Doppel:
- Doppel will use the provided Resource IDs and credentials to configure a webhook.
- This webhook will facilitate the forwarding of alerts from Doppel to Microsoft Sentinel.
Verify Alert Delivery in Microsoft Sentinel:
- Check that alerts from Doppel are successfully forwarded to Microsoft Sentinel.
- Validate that the Workbook in Microsoft Sentinel is updated with the alert statistics, ensuring seamless data integration.

Dragos Notifications via Cloud Sitestore

Supported by: Dragos Inc

The Dragos Platform is the leading Industrial Cyber Security platform it offers a comprehensive Operational Technology (OT) cyber threat detection built by unrivaled industrial cybersecurity expertise. This solution enables Dragos Platform notification data to be viewed in Microsoft Sentinel so that security analysts are able to triage potential cyber security events occurring in their industrial environments.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DragosAlerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Dragos Sitestore API access: A Sitestore user account that has the notification:read permission. This account also needs to have an API key that can be provided to Sentinel.

Setup Instructions:

Please provide the following information to allow Microsoft Sentinel to connect to your Dragos Sitestore.

Dragos Sitestore Hostname: (dragossitestore.example.com)
Dragos Sitestore API Key ID: (Enter the API key ID.)
Dragos Sitestore API Key Secret: (Enter the API key secret)
Minimum Notification Severity. Valid values are 0-5 inclusive. Ensure less than or equal to maximum severity.: (Enter the min severity (recommend 0 for all notifications))
Maximum Notification Severity. Valid values are 0-5 inclusive. Ensure greater than or equal to minimum severity.: (Enter the max severity (recommend 5 for all notifications))
Enable/Disable Connection

Druva Events Connector

Supported by: Druva Inc

Provides capability to ingest the Druva events from Druva APIs

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DruvaSecurityEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Druva API Access: Druva API requires a client id and client secret to authenticate

Setup Instructions:

Note: Configurations to connect to Druva Rest API

Step 1: Create credentials from Druva console. Refer this doc for steps:- https://help.druva.com/en/articles/8580838-create-and-manage-api-credentials

Step 2: Enter the hostname. For public cloud its apis.druva.com

Step 3: Enter client id and client secret key

Connect to Druva API to start collecting logs in Microsoft Sentinel

Provide required values:

Hostname: (Example: apis.druva.com)

Dynamics 365 Finance and Operations

Supported by: Microsoft Corporation

Dynamics 365 for Finance and Operations is a comprehensive Enterprise Resource Planning (ERP) solution that combines financial and operational capabilities to help businesses manage their day-to-day operations. It offers a range of features that enable businesses to streamline workflows, automate tasks, and gain insights into operational performance.

The Dynamics 365 Finance and Operations data connector ingests Dynamics 365 Finance and Operations admin activities and audit logs as well as user business process and application activities logs into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`FinanceOperationsActivity_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra app registration: Application client ID and secret used to access Dynamics 365 Finance and Operations.

Setup Instructions:

Connectivity to Finance and Operations requires a Microsoft Entra app registration (client ID and secret). You'll also need the Microsoft Entra tenant ID and the Finance Operations Organization URL.

To enable data collection, create a role in Dynamics 365 Finance and Operations with permissions to view the Database Log entity. Assign this role to a dedicated Finance and Operations user, mapped to the client ID of a Microsoft Entra app registration. Follow these steps to complete the process:

Step 1 - Microsoft Entra app registration

Navigate to the Microsoft Entra portal.
Under Applications, click on App Registrations and create a new app registration (leave all defaults).
Open the new app registration and create a new secret.
Retain the Tenant ID, Application (client) ID, and Client secret for later use.

Step 2 - Create a role for data collection in Finance and Operations

In the Finance and Operations portal, navigate to Workspaces > System administration and click Security Configuration
Under Roles click Create new and give the new role a name e.g. Database Log Viewer.
Select the new role in the list of roles and click Privileges and than Add references.
Select Database log Entity View from the list of privileges.
Click on Unpublished objects and then Publish all to publish the role.

Step 3 - Create a user for data collection in Finance and Operations

In the Finance and Operations portal, navigate to Modules > System administration and click Users
Create a new user and assign the role created in the previous step to the user.

Step 4 - Register the Microsoft Entra app in Finance and Operations

In the F&O portal, navigate to System administration > Setup > Microsoft Entra applications (Azure Active Directory applications)
Create a new entry in the table. In the Client Id field, enter the application ID of the app registered in Step 1.
In the Name field, enter a name for the application.
In the User ID field, select the user ID created in the previous step.

Connect events from Dyanmics 365 Finance and Operations to Microsoft Sentinel

Connect using client credentials

Organizations

Each row represents an Finance and Operations connection

Data Connectors Grid (configure in portal)

Dynamics365

Supported by: Microsoft Corporation

The Dynamics 365 Common Data Service (CDS) activities connector provides insight into admin, user, and support activities, as well as Microsoft Social Engagement logging events. By connecting Dynamics 365 CRM logs into Microsoft Sentinel, you can view this data in workbooks, use it to create custom alerts, and improve your investigation process.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Dynamics365Activity`	Yes	No

Data collection rule support: Workspace transform DCR

Dynatrace Attacks V1

Supported by: Dynatrace

This connector uses the Dynatrace Attacks REST API to ingest detected attacks into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceAttacks_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace tenant with Application Security enabled, learn more about the Dynatrace platform.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read attacks (attacks.read) scope.

Setup Instructions:

Dynatrace Attack Events to Microsoft Sentinel

Configure and Enable Dynatrace Application Security. Follow these instructions to generate an access token.

Dynatrace Attacks V2

Supported by: Dynatrace

This connector uses the Dynatrace Attacks REST API to ingest detected attacks into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceAttacksV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace tenant with Application Security enabled, learn more about the Dynatrace platform.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read attacks (attacks.read) scope.

Setup Instructions:

Dynatrace Attack Events to Microsoft Sentinel

Configure and Enable Dynatrace Application Security. Follow these instructions to generate an access token.

Dynatrace tenant (ex. xyz.dynatrace.com): ({{dynatraceEnvironmentUrl}})
Dynatrace Access Token: ({{dynatraceAccessToken}})
Enable/Disable Connection

Dynatrace Audit Logs V1

Supported by: Dynatrace

This connector uses the Dynatrace Audit Logs REST API to ingest tenant audit logs into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceAuditLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace Tenant, to learn more about the Dynatrace platform Start your free trial.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read audit logs (auditLogs.read) scope.

Setup Instructions:

Dynatrace Audit Log Events to Microsoft Sentinel

Enable Dynatrace Audit Logging. Follow these instructions to generate an access token.

Dynatrace Audit Logs V2

Supported by: Dynatrace

This connector uses the Dynatrace Audit Logs REST API to ingest tenant audit logs into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceAuditLogsV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace Tenant, to learn more about the Dynatrace platform Start your free trial.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read audit logs (auditLogs.read) scope.

Setup Instructions:

Dynatrace Audit Log Events to Microsoft Sentinel

Enable Dynatrace Audit Logging. Follow these instructions to generate an access token.

Dynatrace tenant (ex. xyz.dynatrace.com): ({{dynatraceEnvironmentUrl}})
Dynatrace Access Token: ({{dynatraceAccessToken}})
Enable/Disable Connection

Dynatrace Problems V1

Supported by: Dynatrace

This connector uses the Dynatrace Problem REST API to ingest problem events into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceProblems_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace Tenant, to learn more about the Dynatrace platform Start your free trial.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read problems (problems.read) scope.

Setup Instructions:

Dynatrace Problem Events to Microsoft Sentinel

Follow these instructions to generate an access token.

Dynatrace Problems V2

Supported by: Dynatrace

This connector uses the Dynatrace Problem REST API to ingest problem events into Microsoft Sentinel Log Analytics

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceProblemsV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace Tenant, to learn more about the Dynatrace platform Start your free trial.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read problems (problems.read) scope.

Setup Instructions:

Dynatrace Problem Events to Microsoft Sentinel

Follow these instructions to generate an access token.

Dynatrace tenant (ex. xyz.dynatrace.com): ({{dynatraceEnvironmentUrl}})
Dynatrace Access Token: ({{dynatraceAccessToken}})
Enable/Disable Connection

Dynatrace Runtime Vulnerabilities V1

Supported by: Dynatrace

This connector uses the Dynatrace Security Problem REST API to ingest detected runtime vulnerabilities into Microsoft Sentinel Log Analytics.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceSecurityProblems_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace tenant with Application Security enabled, learn more about the Dynatrace platform.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read security problems (securityProblems.read) scope.

Setup Instructions:

Dynatrace Vulnerabilities Events to Microsoft Sentinel

Configure and Enable Dynatrace Application Security. Follow these instructions to generate an access token.

Dynatrace Runtime Vulnerabilities V2

Supported by: Dynatrace

This connector uses the Dynatrace Security Problem REST API to ingest detected runtime vulnerabilities into Microsoft Sentinel Log Analytics.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`DynatraceSecurityProblemsV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Dynatrace tenant (ex. xyz.dynatrace.com): You need a valid Dynatrace tenant with Application Security enabled, learn more about the Dynatrace platform.
Dynatrace Access Token: You need a Dynatrace Access Token, the token should have Read security problems (securityProblems.read) scope.

Setup Instructions:

Dynatrace Vulnerabilities Events to Microsoft Sentinel

Configure and Enable Dynatrace Application Security. Follow these instructions to generate an access token.

Dynatrace tenant (ex. xyz.dynatrace.com): ({{dynatraceEnvironmentUrl}})
Dynatrace Access Token: ({{dynatraceAccessToken}})
Enable/Disable Connection

Elastic Agent

Supported by: Microsoft Corporation

The Elastic Agent data connector provides the capability to ingest Elastic Agent logs, metrics, and security data into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ElasticAgentEvent`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Include custom pre-requisites if the connectivity requires - else delete customs: Description for any custom pre-requisite

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected ElasticAgentEvent which is deployed with the Microsoft Sentinel Solution.

NOTE: This data connector has been developed using Elastic Agent 7.14.

1. Install and onboard the agent for Linux or Windows

Install the agent on the Server where the Elastic Agent logs are forwarded.

Logs from Elastic Agents deployed on Linux or Windows servers are collected by Linux or Windows agents.

Choose where to install the Linux agent:

Install agent on Azure Linux Virtual Machine

Select the machine to install the agent on and then click Connect.

Install Agent: <variable value provided at install time>

Install agent on a non-Azure Linux Machine

Download the agent on the relevant machine and follow the instructions.

Install Agent: <variable value provided at install time>

Choose where to install the Windows agent:

Install agent on Azure Windows Virtual Machine

Select the machine to install the agent on and then click Connect.

Install Agent: <variable value provided at install time>

Install agent on a non-Azure Windows Machine

Download the agent on the relevant machine and follow the instructions.

Install Agent: <variable value provided at install time>

2. Configure Elastic Agent (Standalone)

Follow the instructions to configure Elastic Agent to output to Logstash

3. Configure Logstash to use Microsoft Logstash Output Plugin

Follow the steps to configure Logstash to use microsoft-logstash-output-azure-loganalytics plugin:

3.1) Check if the plugin is already installed: ./logstash-plugin list | grep 'azure-loganalytics' (if the plugin is installed go to step 3.3)

3.2) Install plugin: ./logstash-plugin install microsoft-logstash-output-azure-loganalytics

3.3) Configure Logstash to use the plugin

4. Validate log ingestion

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using custom table specified in step 3.3 (e.g. ElasticAgentLogs_CL).

It may take about 30 minutes until the connection streams data to your workspace.

Elastic Agent (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Elastic Agent data connector enables you to ingest system metrics, logs, and telemetry data collected by Elastic Agent from Elasticsearch into Microsoft Sentinel. This connector uses the Elasticsearch Search API with API key authentication to query multiple data streams (CPU, memory, process, filesystem, network, load, uptime, agent metrics, and logs). It supports DCR-based ingestion time transformations for efficient query execution. For more information, see the API documentation: https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ElasticAgentLogsV2_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

1. Prerequisites

Ensure you have the required access and configuration.

Prerequisites

An Elasticsearch deployment (self-managed or Elastic Cloud)
Elastic Agent deployed with System integration enabled
Agent monitoring enabled for logs and metrics
Elasticsearch API key with read permissions on all indices
Network connectivity from Microsoft Sentinel to your Elasticsearch endpoint

Required Indices

The connector queries the following Elasticsearch indices:

Metrics:

metrics-system.cpu-* - CPU metrics
metrics-system.memory-* - Memory metrics
metrics-system.process-* - Process metrics
metrics-system.filesystem-* - Filesystem metrics
metrics-system.network-* - Network metrics
metrics-system.load-* - System load (Linux only)
metrics-system.uptime-* - System uptime
metrics-elastic_agent.* - Agent telemetry

Logs:

logs-elastic_agent-* - Agent logs

2. Configure Elasticsearch Connections

Add one or more Elasticsearch connections to collect data from.

Elasticsearch Connections

You can add multiple connections to collect data from different Elasticsearch deployments. Each connection requires its own Elasticsearch URL and API key.

Creating an API Key

In Kibana, go to Stack Management > API Keys
Click Create API key
Set a name and configure permissions:
- Read access to metrics-system.*
- Read access to metrics-elastic_agent.*
- Read access to logs-elastic_agent-*
Copy the Base64-encoded API key value

Data Connectors Grid (configure in portal)

Ermes Browser Security Events

Supported by: Ermes Cyber Security S.p.A.

Ermes Browser Security Events

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ErmesBrowserSecurityEvents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Ermes Client Id and Client Secret: Enable API access in Ermes. Please contact Ermes Cyber Security support for more information.

Setup Instructions:

Connect Ermes Browser Security Events to Microsoft Sentinel

Connect using OAuth2 credentials

API URL (optional): (https://api.shield.ermessecurity.com)

ESET Protect Platform (using Azure Functions)

Supported by: ESET Enterprise Integrations

The ESET Protect Platform data connector enables users to inject detections data from ESET Protect Platform using the provided Integration REST API. Integration REST API runs as scheduled Azure Function App.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`IntegrationTable_CL`	Yes	Yes
`IntegrationTableIncidents_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Permission to register an application in Microsoft Entra ID: Sufficient permissions to register an application with your Microsoft Entra tenant are required.
Permission to assign a role to the registered application: Permission to assign the Monitoring Metrics Publisher role to the registered application in Microsoft Entra ID is required.

Setup Instructions:

NOTE: The ESET Protect Platform data connector uses Azure Functions to connect to the ESET Protect Platform via Eset Connect API to pull detections logs into Microsoft Sentinel. This process might result in additional data ingestion costs. See details on the Azure Functions pricing page.

NOTE: The newest version of the ESET PROTECT Platform and Microsoft Sentinel integration pulls not only detections logs but also newly created incidents. If your integration was set up before 20.06.2025, please follow these steps to update it.

Step 1 - Create an API user

Use this instruction to create an ESET Connect API User account with Login and Password.

Step 2 - Create a registered application

Create a Microsoft Entra ID registered application by following the steps in the Register a new application instruction.

Step 3 - Deploy the ESET Protect Platform data connector using the Azure Resource Manager (ARM) template

Click the Deploy to Azure button below.

aka.ms
Select the name of the Log Analytics workspace associated with your Microsoft Sentinel. Select the same Resource Group as the Resource Group of the Log Analytics workspace.
Type the parameters of the registered application in Microsoft Entra ID: Azure Client ID, Azure Client Secret, Azure Tenant ID, Object ID. You can find the Object ID on Azure Portal by following this path Microsoft Entra ID -> Manage (on the left-side menu) -> Enterprise applications -> Object ID column (the value next to your registered application name).
Provide the ESET Connect API user account Login and Password obtained in Step 1.
Select one or more ESET products (ESET PROTECT, ESET Inspect, ESET Cloud Office Security) from which detections are retrieved.

Exchange Security Insights On-Premises Collector

Supported by: Community

Connector used to push Exchange On-Premises Security configuration for Microsoft Sentinel Analysis

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ESIExchangeConfig_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Service Account with Organization Management role: The service Account that launch the script as scheduled task needs to be Organization Management to be able to retrieve all the needed security Information.
Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

1. Install the ESI Collector Script on a server with Exchange Admin PowerShell console

This is the script that will collect Exchange Information to push content in Microsoft Sentinel.

Script Deployment

Download the latest version of ESI Collector

The latest version can be found here : https://aka.ms/ESI-ExchangeCollector-Script. The file to download is CollectExchSecIns.zip

Copy the script folder

Unzip the content and copy the script folder on a server where Exchange PowerShell Cmdlets are present.

Unblock the PS1 Scripts

Click right on each PS1 Script and go to Properties tab. If the script is marked as blocked, unblock it. You can also use the Cmdlet 'Unblock-File . in the unzipped folder using PowerShell.

**Configure Network Access **

Ensure that the script can contact Azure Analytics (*.ods.opinsights.azure.com).

2. Configure the ESI Collector Script

Be sure to be local administrator of the server. In 'Run as Administrator' mode, launch the 'setup.ps1' script to configure the collector. Fill the Log Analytics (Microsoft Sentinel) Workspace information. Fill the Environment name or leave empty. By default, choose 'Def' as Default analysis. The other choices are for specific usage.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

3. Schedule the ESI Collector Script (If not done by the Install Script due to lack of permission or ignored during installation)

The script needs to be scheduled to send Exchange configuration to Microsoft Sentinel. We recommend to schedule the script once a day. The account used to launch the Script needs to be member of the group Organization Management

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Parsers are automatically deployed with the solution. Follow the steps to create the Kusto Functions alias : ExchangeAdminAuditLogs

Parsers are automatically deployed during Solution deployment. If you want to deploy manually, follow the steps below

Manual Parser Deployment

1. Download the Parser file

The latest version of the file ExchangeAdminAuditLogs

2. Create Parser ExchangeAdminAuditLogs function

In 'Logs' explorer of your Microsoft Sentinel's log analytics, copy the content of the file to Log explorer

3. Save Parser ExchangeAdminAuditLogs function

Click on save button. No parameter is needed for this parser. Click save again.

Exchange Security Insights Online Collector (using Azure Functions)

Supported by: Community

Connector used to push Exchange Online Security configuration for Microsoft Sentinel Analysis

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ESIExchangeOnlineConfig_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
microsoft.automation/automationaccounts permissions: Read and write permissions to create an Azure Automation with a Runbook is required. For more information, see Automation Account.
Microsoft.Graph permissions: Groups.Read, Users.Read and Auditing.Read permissions are required to retrieve user/group information linked to Exchange Online assignments. See the documentation to learn more.
Exchange Online permissions: Exchange.ManageAsApp permission and Global Reader or Security Reader Role are needed to retrieve the Exchange Online Security Configuration.See the documentation to learn more.
(Optional) Log Storage permissions: Storage Blob Data Contributor to a storage account linked to the Automation Account Managed identity or an Application ID is mandatory to store logs.See the documentation to learn more.

Setup Instructions:

NOTE - UPDATE

Note:
NOTE - UPDATE:
We recommend to Update the Collector to Version 7.6.0.0 or highier. The Collector Script Update procedure could be found here : ESI Online Collector Update

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Follow the steps for each Parser to create the Kusto Functions alias : ExchangeConfiguration and **ExchangeEnvironmentList STEP 1 - Parsers deployment**

Parser deployment (When using Microsoft Exchange Security Solution, Parsers are automatically deployed)

1. Download the Parser files

The latest version of the 2 files ExchangeConfiguration.yaml and ExchangeEnvironmentList.yaml

2. Create Parser ExchangeConfiguration function

In 'Logs' explorer of your Microsoft Sentinel's log analytics, copy the content of the file to Log explorer

3. Save Parser ExchangeConfiguration function

Click on save button. Define the parameters as asked on the header of the parser file. Click save again.

4. Reproduce the same steps for Parser ExchangeEnvironmentList

Reproduce the step 2 and 3 with the content of 'ExchangeEnvironmentList.yaml' file

NOTE: This connector uses Azure Automation to connect to 'Exchange Online' to pull its Security analysis into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Automation pricing page for details.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Automation

IMPORTANT: Before deploying the 'ESI Exchange Online Security Configuration' connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Exchange Online tenant name (contoso.onmicrosoft.com), readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the 'ESI Exchange Online Security Configuration' connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, Tenant Name, 'and/or Other required fields'.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy the 'ESI Exchange Online Security Configuration' connector manually with Azure Automation.

A. Create the Azure Automation Account

From the Azure Portal, navigate to Azure Automation Account.
Click + Add at the top.
In the Basics tab, fill the required fields and give a name to the Azure Automation.
In the Advanced and Networking and Tags Tabs, leave fields as default if you don't need to customize them.
'Make other preferable configuration changes', if needed, then click Create.

B. Add Exchange Online Management Module, Microsoft Graph (Authentication, User and Group) Modules

On the Automation Account page, select Modules.
Click on Browse gallery and search the ExchangeOnlineManagement module.
Select it and click on Select.
Choose Version 5.1 on Runtime version field and click on Import button. Repeat the step for the following modules : 'Microsoft.Graph.Authentication', 'Microsoft.Graph.Users' and 'Microsoft.Graph.Groups. Attention, you need to wait for Microsoft.Graph.Authentication installation before processing next modules

C. Download the Runbook Content

Download the latest version of ESI Collector. The latest version can be found here : https://aka.ms/ESI-ExchangeCollector-Script
Unzip the file to find the JSON file and the PS1 file for next step.

D. Create Runbook

On the Automation Account page, select the Runbooks button.
Click on Create a runbook and name it like 'ESI-Collector' with a runbook type PowerShell, Runtime Version 5.1 and click 'Create'.
Import the content of the previous step's PS1 file in the Runbook window.
Click on Publish

E. Create GlobalConfiguration Variable

On the Automation Account page, select the Variables button.
Click on Add a Variable and name it exaclty 'GlobalConfiguration' with a type String.
On 'Value' field, copy the content of the previous step's JSON file.
Inside the content, replace the values of WorkspaceID and WorkspaceKey.
Click on 'Create' button.

F. Create TenantName Variable

On the Automation Account page, select the Variables button.
Click on Add a Variable and name it exaclty 'TenantName' with a type String.
On 'Value' field, write the tenant name of your Exchange Online.
Click on 'Create' button.

G. Create LastDateTracking Variable

On the Automation Account page, select the Variables button.
Click on Add a Variable and name it exaclty 'LastDateTracking' with a type String.
On 'Value' field, write 'Never'.
Click on 'Create' button.

H. Create a Runbook Schedule

On the Automation Account page, select the Runbook button and click on your created runbook.
Click on Schedules and Add a schedule button.
Click on Schedule, Add a Schedule and name it. Select Recurring value with a reccurence of every 1 day, click 'Create'.
Click on 'Configure parameters and run settings'. Leave all empty and click on OK and OK again.

STEP 3 - Assign Microsoft Graph Permission and Exchange Online Permission to Managed Identity Account

To be able to collect Exchange Online information and to be able to retrieve User information and memberlist of admin groups, the automation account need multiple permission.

Assign Permissions by Script

A. Download Permission Script

Permission Update script

B. Retrieve the Azure Automation Managed Identity GUID and insert it in the downloaded script

Go to your Automation Account, in the Identity Section. You can find the Guid of your Managed Identity.
Replace the GUID in $MI_ID = "XXXXXXXXXXX" with the GUID of your Managed Identity.

C. Launch the script with a Global-Administrator account

Attention this script requires MSGraph Modules and Admin Consent to access to your tenant with Microsoft Graph. The script will add 3 permissions to the Managed identity: 1. Exchange Online ManageAsApp permission 2. User.Read.All on Microsoft Graph API 3. Group.Read.All on Microsoft Graph API

D. Exchange Online Role Assignment

As a Global Administrator, go to Roles and Administrators.
Select Global Reader role or Security Reader and click to 'Add assignments'.
Click on 'No member selected' and search your Managed Identity account Name beginning by the name of your automation account like 'ESI-Collector'. Select it and click on 'Select'.
Click Next and validate the assignment by clicking Assign.

ExtraHop Detections Data Connector

Supported by: ExtraHop Support

The ExtraHop Detections Data Connector enables you to import detection data from ExtraHop RevealX to Microsoft Sentinel through webhook payloads. Data is ingested using the Azure Monitor Log Ingestion API via a Data Collection Rule (DCR).

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ExtraHop_Detections_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID, create a Data Collection Endpoint, Data Collection Rule, and assign the required roles.
Microsoft Entra App Registration: A Microsoft Entra ID App Registration (Service Principal) with a Client Secret is required. The app's Object ID must be provided so the deployment can assign it the necessary role to publish logs via the Log Ingestion API.
Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
ExtraHop RevealX permissions: The following is required on your ExtraHop RevealX system:

Your RevealX system must be running firmware version 9.9.2 or later.
Your RevealX system must be connected to ExtraHop Cloud Services.
Your user account must have System Administration privileges on RevealX 360 or Full Write privileges on RevealX Enterprise.

Setup Instructions:

NOTE: This connector uses Azure Functions to receive ExtraHop webhook payloads and ingest them into Microsoft Sentinel using the Azure Monitor Log Ingestion API (DCR-based ingestion). This replaces the legacy Log Analytics HTTP Data Collector API. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store API credentials in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias ExtraHopDetections and load the function code or click here. The function usually takes 10-15 minutes to activate after solution installation/update.

Configuration:

STEP 1 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.
Search for and select Microsoft Entra ID.
Under Manage, select App registrations > New registration.
Enter a display Name for your application (e.g., ExtraHopSentinelConnector).
Select Register to complete the initial app registration.
When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of ExtraHop Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 2 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of ExtraHop Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.
Select Certificates & secrets > Client secrets > New client secret.
Add a description for your client secret.
Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.
Select Add.
Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of ExtraHop Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 3 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.
Select Enterprise applications from the left menu.
Find your newly created application in the list (you can search by the name you provided).
Click on the application.
On the overview page, copy the Object ID. This is the AzureEntraObjectID needed for your ARM template role assignment.

STEP 4 - Deploy ExtraHop Data Connector

IMPORTANT: Before deploying the ExtraHop Data connector, have the Microsoft Entra ID App Registration details (Client ID, Client Secret, Tenant ID, and Object ID) readily available.

Deploy the ExtraHop Detections Data Connector:

Use this method for automated deployment of the ExtraHop Detections Data connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Region.
Enter the below information :

a. FunctionName - Enter the Function App name (used to name all related resources). Must be 1-11 characters. Default: ExtraHop

b. Location - The location in which the data collection rules and data collection endpoints should be deployed

c. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

d. AzureClientId - Enter Azure Client ID that you have created during app registration

e. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. TenantId - Enter Tenant ID of your Microsoft Entra ID

h. DetectionsTableName - Enter name of the table used to store ExtraHop Detections logs. Default is 'ExtraHop_Detections'

i. LogLevel - Select log level or log severity value from Debug, Info, Error, Warning. By default it is set to Info

j. AppInsightsWorkspaceResourceID - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

STEP 5 - Post Deployment

After successful deployment, configure the webhook connection from ExtraHop RevealX to Microsoft Sentinel.

1) Get the Function App endpoint

Go to the Azure function overview page and click the Functions tab.
Click on the function called ExtraHopHttpStarter.
Go to Get Function URL and copy the function URL available under default (Function key).
Replace {functionname} with ExtraHopDetectionsOrchestrator in the copied function URL.

2) Configure a connection to Microsoft Sentinel and specify webhook payload criteria from RevealX

From your ExtraHop system, configure the Microsoft Sentinel integration to establish a connection between Microsoft Sentinel and ExtraHop RevealX and to create detection notification rules that will send webhook data to Microsoft Sentinel. For detailed instructions, refer to Integrate ExtraHop RevealX with Microsoft Sentinel SIEM.

After notification rules have been configured and Microsoft Sentinel is receiving webhook data, the Function App is triggered and you can view ExtraHop detections from the Log Analytics workspace custom table. Use the ExtraHopDetections parser function for a normalized view of the data.

F5 BIG-IP

Supported by: F5 Networks

The F5 firewall connector allows you to easily connect your F5 logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization's network and improves your security operation capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`F5Telemetry_LTM_CL`	No	No
`F5Telemetry_system_CL`	Yes	Yes
`F5Telemetry_ASM_CL`	No	No

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configure and connect F5 BIGIP

To connect your F5 BIGIP, you have to post a JSON declaration to the system’s API endpoint. For instructions on how to do this, see Integrating the F5 BGIP with Microsoft Sentinel.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Feedly IoC

Supported by: Feedly Inc

The Feedly IoC data connector provides the capability to ingest Indicators of Compromise (IoCs) from Feedly API into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`feedly_indicators_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Feedly API access: Access to the Feedly API is required. You need a Feedly API token with access to the IoC streams you want to ingest. Generate your API token at https://feedly.com/i/team/api

Setup Instructions:

Connect to Feedly to start collecting IoCs in Microsoft Sentinel

Go to https://feedly.com/i/team/api and generate a new API token for the connector.
In Sentinel, in the connector page - provide your Feedly API Key and Stream IDs. Then click "Connect".

Feedly API Key: (Enter your Feedly API token)
Feedly Stream IDs: (streamId1,streamId2,streamId3)
Enable/Disable Connection

Flare Push Connector

Supported by: Flare

The Flare connector provides the capability to ingest threat intelligence and exposure data from Flare into Microsoft Sentinel. Flare identifies your company's digital assets made publicly available due to human error or malicious attacks, including leaked credentials, exposed cloud buckets, darkweb mentions, and more.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`FireworkV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID.
Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR).
Flare: Permission to configure Microsoft Sentinel integration in Flare.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector enables Flare to send threat exposure data to Microsoft Sentinel. When data forwarding is enabled in Flare, raw event data is sent securely to the Microsoft Sentinel Ingestion API.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will create Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Configure Flare to Send Logs to Microsoft Sentinel

Use the following parameters to configure Flare to send logs to your workspace.

Entra Application (Client) ID: <variable value provided at install time>
Entra Directory (Tenant) ID: <variable value provided at install time>
Entra App Registration Secret: <variable value provided at install time>
Log Ingestion URL: <variable value provided at install time>

3. Configure Alert Channel in Flare

As an organization administrator, you can configure an Alert Channel in Flare to send data to Sentinel.

Authenticate on Flare
Access the alerts page to create a new alert channel.
Select 'Microsoft Sentinel' and copy the above fields in the form.

For more details, refer to the Flare documentation.

Forcepoint DLP

Supported by: Community

The Forcepoint DLP (Data Loss Prevention) connector allows you to automatically export DLP incident data from Forcepoint DLP into Microsoft Sentinel in real-time. This enriches visibility into user activities and data loss incidents, enables further correlation with data from Azure workloads and other feeds, and improves monitoring capability with Workbooks inside Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ForcepointDLPEvents_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Follow step by step instructions in the Forcepoint DLP documentation for Microsoft Sentinel to configure this connector.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Forescout

Supported by: Microsoft Corporation

The Forescout data connector provides the capability to ingest Forescout events into Microsoft Sentinel. Refer to Forescout documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ForescoutEvent`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected ForescoutEvent which is deployed with the Microsoft Sentinel Solution.

NOTE: This data connector has been developed using Forescout Syslog Plugin version: v3.6

1. Install and onboard the agent for Linux or Windows

Install the agent on the Server where the Forescout logs are forwarded.

Logs from Forescout Server deployed on Linux or Windows servers are collected by Linux or Windows agents.

Choose where to install the Linux agent:

Install agent on Azure Linux Virtual Machine

Select the machine to install the agent on and then click Connect.

Install Agent: <variable value provided at install time>

Install agent on a non-Azure Linux Machine

Download the agent on the relevant machine and follow the instructions.

Install Agent: <variable value provided at install time>

Choose where to install the Windows agent:

Install agent on Azure Windows Virtual Machine

Select the machine to install the agent on and then click Connect.

Install Agent: <variable value provided at install time>

Install agent on a non-Azure Windows Machine

Download the agent on the relevant machine and follow the instructions.

Install Agent: <variable value provided at install time>

2. Configure the logs to be collected

Configure the facilities you want to collect and their severities.

Under workspace advanced settings Configuration, select Data and then Syslog.
Select Apply below configuration to my machines and select the facilities and severities.
Click Save.

Install Agent: <variable value provided at install time>

3. Configure Forescout event forwarding

Follow the configuration steps below to get Forescout logs into Microsoft Sentinel.

Select an Appliance to Configure.
Follow these instructions to forward alerts from the Forescout platform to a syslog server.
Configure the settings in the Syslog Triggers tab.

Forescout Host Property Monitor

Supported by: Microsoft Corporation

The Forescout Host Property Monitor connector allows you to connect host properties from Forescout platform with Microsoft Sentinel, to view, create custom incidents, and improve investigation. This gives you more insight into your organization network and improves your security operation capabilities.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ForescoutHostProperties_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Forescout Plugin requirement: Please make sure Forescout Microsoft Sentinel plugin is running on Forescout platform

Setup Instructions:

Instructions on how to configure Forescout Microsoft Sentinel plugin are provided at Forescout Documentation Portal (https://docs.forescout.com/bundle/sentinel-1-0-h)

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Fortinet FortiNDR Cloud

Supported by: Fortinet

The Fortinet FortiNDR Cloud data connector provides the capability to ingest Fortinet FortiNDR Cloud data into Microsoft Sentinel using the FortiNDR Cloud API

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`FncEventsSuricata_CL`	No	No
`FncEventsObservation_CL`	No	No
`FncEventsDetections_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
MetaStream Credentials: AWS Access Key Id, AWS Secret Access Key, FortiNDR Cloud Account Code are required to retrieve event data.
API Credentials: FortiNDR Cloud API Token, FortiNDR Cloud Account UUID are required to retrieve detection data.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the FortiNDR Cloud API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector uses a parser based on a Kusto Function to normalize fields. Follow these steps to create the Kusto function alias Fortinet_FortiNDR_Cloud.

STEP 1 - Configuration steps for the Fortinet FortiNDR Cloud Logs Collection

The provider should provide or link to detailed steps to configure the 'PROVIDER NAME APPLICATION NAME' API endpoint so that the Azure Function can authenticate to it successfully, get its authorization key or token, and pull the appliance's logs into Microsoft Sentinel.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Fortinet FortiNDR Cloud connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the as well as the FortiNDR Cloud API credentials (available in FortiNDR Cloud account management), readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Fortinet FortiNDR Cloud connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location(Make sure using the same location as your Resource Group, and got the location supports Flex Consumption.
Enter the Workspace ID, Workspace Key, AwsAccessKeyId, AwsSecretAccessKey, and/or Other required fields.
Click Create to deploy.

Fortra Agari Data Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Fortra Agari Data Connector allows ingesting logs from Fortra Agari APIs into Microsoft Sentinel. This connector integrates with Agari Brand Protection (BP), Phishing Defense (APD), and Phishing Response (APR) products. It supports DCR-based ingestion time transformations for efficient query execution. Refer to Agari API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`AgariBPAlertsLog_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Configuration steps for the Agari API

Follow the instructions below to obtain your Agari API credentials.

Retrieve API URL Log in to your Agari Console and navigate to the API section. The default API URL is https://api.agari.com
Retrieve Client Credentials Obtain your Client ID and Client Secret from the API credentials section in your Agari account. Note that different Agari products (Brand Protection, Phishing Defense, Phishing Response) may require separate API credentials.
Select Data Streams Choose which Agari data streams you want to collect. You can select one or more streams based on your subscription and requirements.

Base API URL: (https://api.agari.com)
Client ID: (Your Client ID)
Client Secret: (Your Client Secret)
Enable/Disable Connection

Garrison ULTRA Remote Logs (using Azure Functions)

Supported by: Garrison

The Garrison ULTRA Remote Logs connector allows you to ingest Garrison ULTRA Remote Logs into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Garrison_ULTRARemoteLogs_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Garrison ULTRA: To use this data connector you must have an active Garrison ULTRA license.

Setup Instructions:

Deployment - Azure Resource Manager (ARM) Template

These steps outline the automated deployment of the Garrison ULTRA Remote Logs data connector using an ARM Tempate.

Click the Deploy to Azure button below.

portal.azure.com
Provide the required details such as Resource Group, Microsoft Sentinel Workspace and ingestion configurations

NOTE: It is recommended to create a new Resource Group for deployment of these resources. 3. Mark the checkbox labeled I agree to the terms and conditions stated above. 4. Click Purchase to deploy.

GCP Cloud Run (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The GCP Cloud Run data connector provides the capability to ingest Cloud Run request logs into Microsoft Sentinel using Pub/Sub. Refer the Cloud Run Overview for more details.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPCloudRun`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP Cloud Run to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable Cloud Run logs In the Google Cloud Console, enable cloud logging if not enabled previously, and save the changes.Deploy or update your Cloud Run services with logging enabled.

Reference Link: Link to documentation

Connect new collectors To enable GCP Cloud Run Request Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

GCP Cloud SQL (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The GCP Cloud SQL data connector provides the capability to ingest Audit logs into Microsoft Sentinel using the GCP Cloud SQL API. Refer to GCP cloud SQL Audit Logs documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPCloudSQL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect GCP Cloud SQL to Microsoft Sentinel

Tenant ID: A unique identifier that is used as an input in the terraform configuration within a GCP environment.: <variable value provided at install time>

In the Google Cloud Console, enable Cloud SQL API, if not enabled previously, and save the changes.
Connect new collectors To enable GCP Cloud SQL Logs for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

GCP Pub/Sub Audit Logs

Supported by: Microsoft Corporation

The Google Cloud Platform (GCP) audit logs, ingested from Microsoft Sentinel's connector, enables you to capture three types of audit logs: admin activity logs, data access logs, and access transparency logs. Google cloud audit logs record a trail that practitioners can use to monitor access and detect potential threats across Google Cloud Platform (GCP) resources.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPAuditLogs`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Connect new collectors To enable GCP Audit Logs for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

GCP Pub/Sub Load Balancer Logs (via Codeless Connector Framework).

Supported by: Microsoft Corporation

Google Cloud Platform (GCP) Load Balancer logs provide detailed insights into network traffic, capturing both inbound and outbound activities. These logs are used for monitoring access patterns and identifying potential security threats across GCP resources. Additionally, these logs also include GCP Web Application Firewall (WAF) logs, enhancing the ability to detect and mitigate risks effectively.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPLoadBalancerLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable Load Balancer logs In your GCP account, navigate to the Load Balancer section. In here you can nevigate to [Backend Service] -> [Edit], once you are in the [Backend Service] on the [Logging] section enable the checkbox of [Enable Logs]. Once you open the rule, switch the toggle button under the Logs section to On, and save the changes.

For more information: Link to documentation

Connect new collectors To enable GCP Load Balancer Logs for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

GCP Pub/Sub VPC Flow Logs (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform (GCP) VPC Flow Logs enable you to capture network traffic activity at the VPC level, allowing you to monitor access patterns, analyze network performance, and detect potential threats across GCP resources.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPVPCFlow`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable VPC Flow Logs In your GCP account, navigate to the VPC network section. Select the subnet you want to monitor and enable Flow Logs under the Logging section.

For more information: Google Cloud Documentation

Connect new collectors To enable GCP VPC Flow Logs for Microsoft Sentinel, click the Add new collector button, fill in the required information in the context pane, and click Connect.

Gigamon AMX Connector

Supported by: Gigamon

The Gigamon connector provides the capability to read raw event data from Gigamon in Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GigamonV2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.
Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector reads data from the tables that Gigamon CCF uses in a Microsoft Analytics Workspace, if the data forwarding option is enabled in Gigamon CCF then raw event data is sent to the Microsoft Sentinel Ingestion API.

2. Push your logs into the workspace

Use the following parameters to configure the your machine to send the logs to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>
Entra App Registration Application ID: <variable value provided at install time>
Entra App Registration Secret: <variable value provided at install time>
Data Collection Endpoint Uri: <variable value provided at install time>
Data Collection Rule Immutable ID: <variable value provided at install time>
Activity Stream Name: <variable value provided at install time>
Threat Stream Name: <variable value provided at install time>

GitHub (using Webhooks)

Supported by: Microsoft Corporation

The GitHub webhook data connector provides the capability to ingest GitHub subscribed events into Microsoft Sentinel using GitHub webhook events. The connector provides ability to get events into Microsoft Sentinel which helps to examine potential security risks, analyze your team's use of collaboration, diagnose configuration problems and more.

Note: If you are intended to ingest Github Audit logs, Please refer to GitHub Enterprise Audit Log Connector from "Data Connectors" gallery.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`githubscanaudit_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Setup Instructions:

NOTE: This connector has been built on http trigger based Azure Function. And it provides an endpoint to which github will be connected through it's webhook capability and posts the subscribed events into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Github Webhook connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the GitHub data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region and deploy. 3. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the GitHub webhook data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): WorkspaceID WorkspaceKey logAnalyticsUri (optional) - Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.
Once all application settings have been entered, click Save.

Post Deployment steps

STEP 1 - To get the Azure Function url

Go to Azure function Overview page and Click on "Functions" in the left blade.
Click on the function called "GithubwebhookConnector".
Go to "GetFunctionurl" and copy the function url.

STEP 2 - Configure Webhook to Github Organization

Go to GitHub and open your account and click on "Your Organizations."
Click on Settings.
Click on "Webhooks" and enter the function app url which was copied from above STEP 1 under payload URL textbox.
Choose content type as "application/json".
Subscribe for events and Click on "Add Webhook"

Now we are done with the github Webhook configuration. Once the github events triggered and after the delay of 20 to 30 mins (As there will be a dealy for LogAnalytics to spin up the resources for the first time), you should be able to see all the transactional events from the Github into LogAnalytics workspace table called "githubscanaudit_CL".

For more details, Click here

GitHub Enterprise Audit Log (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The GitHub audit log connector provides the capability to ingest GitHub logs into Microsoft Sentinel. By connecting GitHub audit logs into Microsoft Sentinel, you can view this data in workbooks, use it to create custom alerts, and improve your investigation process.

Note: If you intended to ingest GitHub subscribed events into Microsoft Sentinel, please refer to GitHub (using Webhooks) Connector from "Data Connectors" gallery.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GitHubAuditLogsV2_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

GitHub API personal access token: To enable polling for the Enterprise audit log, ensure the authenticated user is an Enterprise admin and has a GitHub personal access token (classic) with the read:audit_log scope.
GitHub Enterprise type: This connector will only function with GitHub Enterprise Cloud; it will not support GitHub Enterprise Server.

Setup Instructions:

Connect the GitHub Enterprise-level Audit Log to Microsoft Sentinel

Enable GitHub audit logs. Follow this guide to create or find your personal access token.

Data Connectors Grid (configure in portal)

Google ApigeeX (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google ApigeeX data connector provides the capability to ingest Audit logs into Microsoft Sentinel using the Google Apigee API. Refer to Google Apigee API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPApigee`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect Google ApigeeX to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable ApigeeX logs In the Google Cloud Console, enable Apigee API, if not enabled previously, and save the changes.
Connect new collectors To enable ApigeeX Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform CDN (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform CDN data connector provides the capability to ingest Cloud CDN Audit logs and Cloud CDN Traffic logs into Microsoft Sentinel using the Compute Engine API. Refer the Product overview document for more details.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPCDN`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP CDN to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable CDN logs In the Google Cloud Console, enable cloud logging if not enabled previously, and save the changes. Navigate to Cloud CDN section and click on Add origin to create backends as per link provided below.

Reference Link: Link to documentation

Connect new collectors To enable GCP Cloud CDN Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform Cloud IDS (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform IDS data connector provides the capability to ingest Cloud IDS Traffic logs, Threat logs and Audit logs into Microsoft Sentinel using the Google Cloud IDS API. Refer to Cloud IDS API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPIDS`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP Cloud IDS to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable IDS logs In the Google Cloud Console, enable Cloud IDS API, if not enabled previously. Create an IDS Endpoint and save the changes.

For more information on how to create and configure an IDS endpoint: Link to documentation

Connect new collectors To enable GCP IDS Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform Cloud Monitoring (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform Cloud Monitoring data connector ingests Monitoring logs from Google Cloud into Microsoft Sentinel using the Google Cloud Monitoring API. Refer to Cloud Monitoring API documentation for more details.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPMonitoring`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Google Cloud Platform Cloud Monitoring to Microsoft Sentinel

Setup GCP Monitoring Integration To fetch logs from GCP Cloud Monitoring to Sentinel Project ID of Google cloud is required.
Chose the Metric Type To collect logs from Google Cloud Monitoring provide the required Metric type.

For more details, refer to Google Cloud Metrics.

OAuth Credentials To Fetch Oauth client id and client secret refer to this documentation.
Connect to Sentinel Click on Connect to start pulling monitoring logs from Google Cloud into Microsoft Sentinel.

GCP Project ID:
Metric Type:
Data Connectors Grid (configure in portal)

Google Cloud Platform Compute Engine (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform Compute Engine data connector provides the capability to ingest Compute Engine Audit logs into Microsoft Sentinel using the Google Cloud Compute Engine API. Refer to Cloud Compute Engine API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPComputeEngine`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP Compute Engine to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable Compute Engine logs In the Google Cloud Console, enable Compute Engine API, if not enabled previously, and save the changes.
Connect new collectors To enable Compute Engine Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform DNS (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform DNS data connector provides the capability to ingest Cloud DNS Query logs and Cloud DNS Audit logs into Microsoft Sentinel using the Google Cloud DNS API. Refer to Cloud DNS API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPDNS`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP DNS to Microsoft Sentinel **

NOTE: If both Azure Function and CCF connector are running simultaneously, duplicate data is populated in the tables.

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable DNS logs In the Google Cloud Console, navigate to Cloud DNS Section. Enable cloud logging if not enabled previously, and save the changes. Here, you can manage the existing zones, or create a new zone and create policies for the zone which you want to monitor.

For more information: Link to documentation

Connect new collectors To enable GCP DNS Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform IAM (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform IAM data connector provides the capability to ingest the Audit logs relating to Identity and Access Management (IAM) activities within Google Cloud into Microsoft Sentinel using the Google IAM API. Refer to GCP IAM API documentation for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPIAM`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect GCP IAM to Microsoft Sentinel

NOTE: If both Azure Function and CCF connector are running parallelly, duplicate data is populated in the tables.

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

To enable IAM logs In your GCP account, navigate to the IAM section. From there, you can either create a new user or modify an existing user's role that you want to monitor. Be sure to save your changes..

For more information: Link to documentation

Connect new collectors To enable GCPIAM Logs for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Google Cloud Platform NAT (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform NAT data connector provides the capability to ingest Cloud NAT Audit logs and Cloud NAT Traffic logs into Microsoft Sentinel using the Compute Engine API. Refer the Product overview document for more details.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPNATAudit`	Yes	Yes
`GCPNAT`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP NAT to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable NAT logs In the Google Cloud Console, enable cloud logging if not enabled previously, and save the changes. Navigate to Cloud NAT section and click on Add origin to create backends as per link provided below.

Reference Link: Link to documentation

Connect new collectors To enable GCP Cloud NAT Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Cloud Platform Resource Manager (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Cloud Platform Resource Manager data connector provides the capability to ingest Resource Manager Admin Activity and Data Access Audit logs into Microsoft Sentinel using the Cloud Resource Manager API. Refer the Product overview document for more details.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GCPResourceManager`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

**Connect GCP Resource Manager to Microsoft Sentinel **

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable Resource Manager logs In the Google Cloud Console, enable cloud resource manager API if not enabled previously, and save the changes. Make sure to have organization level IAM permissions for your account to see all logs in the resource hierarchy. You can refer the document links for different IAM permissions for access control with IAM at each level provided in this link
Connect new collectors To enable GCP Resource Manager Logs for Microsoft Sentinel, click on Add new collector button, provide the required information in the pop up and click on Connect.

Google Kubernetes Engine (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Kubernetes Engine (GKE) Logs enable you to capture cluster activity, workload behavior, and security events, allowing you to monitor Kubernetes workloads, analyze performance, and detect potential threats across GKE clusters.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GKEAudit`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Enable Kubernetes Engine Logging In your GCP account, navigate to the Kubernetes Engine section. Enable Cloud Logging for your clusters. Within Cloud Logging, ensure that the specific logs you want to ingest—such as API server, scheduler, controller manager, HPA decision, and application logs—are enabled for effective monitoring and security analysis.
Connect new collectors To enable GKE Logs for Microsoft Sentinel, click the Add new collector button, fill in the required information in the context pane, and click Connect.

Google Security Command Center

Supported by: Microsoft Corporation

The Google Cloud Platform (GCP) Security Command Center is a comprehensive security and risk management platform for Google Cloud, ingested from Sentinel's connector. It offers features such as asset inventory and discovery, vulnerability and threat detection, and risk mitigation and remediation to help you gain insight into your organization's security and data attack surface. This integration enables you to perform tasks related to findings and assets more effectively.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GoogleCloudSCC`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Set up your GCP environment You must have the following GCP resources defined and configured: topic, subscription for the topic, workload identity pool, workload identity provider and service account with permissions to get and consume from subscription. Terraform provides API for the IAM that creates the resources. Link to Terraform scripts.

Tenant ID: A unique identifier that is used as an input in the Terraform configuration within a GCP environment.: <variable value provided at install time>

Connect new collectors To enable GCP SCC for Microsoft Sentinel, click the Add new collector button, fill the required information in the context pane and click on Connect.

Google Workspace Activities (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Google Workspace Activities data connector provides the capability to ingest Activity Events from Google Workspace API into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GoogleWorkspaceReports`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Google Workspace API access: Access to the Google Workspace activities API through Oauth are required.

Setup Instructions:

Connect to Google Workspace to start collecting user activity logs into Microsoft Sentinel

Configuration steps for the Google Reports API

Login to Google cloud console with your Workspace Admin credentials https://console.cloud.google.com.
Using the search option (available at the top middle), Search for APIs & Services
From APIs & Services -> Enabled APIs & Services, enable Admin SDK API for this project.
Go to APIs & Services -> OAuth Consent Screen. If not already configured, create a OAuth Consent Screen with the following steps:
1. Provide App Name and other mandatory information.
2. Pick External as User Type for the Audience.
Go to APIs & Services -> Credentials and create OAuth 2.0 Client ID
1. Click on Create Credentials on the top and select Oauth client Id.
2. Select Web Application from the Application Type drop down.
3. Provide a suitable name to the Web App and add the Redirect URI in the form below as the Authorized redirect URIs.
4. Once you click Create, you will be provided with the Client ID and Client Secret. Copy these values and use them in the configuration steps below.
Go to Google Auth Platform -> Data Access: Add Admin SDK API scope

Configure steps for the Google Reports API oauth access. Then, provide the required information below and click on Connect.

Data Connectors Grid (configure in portal)

GravityZone Data Connector

Supported by: Bitdefender SRL

This connector enables integration between Bitdefender GravityZone and Microsoft Sentinel through the Event Push Service API. Once configured, it streams all GravityZone event types directly into your Microsoft Sentinel workspace, where they are stored as logs in the GzSecurityEvents_CL table.

Key event categories such as EDR, XDR, ransomware mitigation, network sandboxing, and Exchange malware events can be automatically correlated and generate incidents through the NRT GravityZone Incident Alerts analytics rule.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`GzSecurityEvents_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Azure App Registration: Microsoft Entra App Registration with the following details retained Directory (Tenant) ID, Application (Client) ID, Managed Service Principal Object ID (from the Enterprise Applications entry of the app), Client Secret (generated under Certificates & secrets).
GravityZone Cloud Account: A GravityZone Cloud account with a generated API key for the Event Push Service endpoint.
Read our guide: Follow this step-by-step article to set up the integration. Customers | Partners

Setup Instructions:

Click the Deploy to Azure button below and fill in the required parameters.

aka.ms

Collect the Logs Ingestion URL from gz-sentinel-dce Data Collection Endpoint
Collect the Immutable ID from gz-sentinel-dcr Data Collection Rule
Go to your GravityZone Cloud account and navigate to My Account. Create an API key with Event Push Service permissions.
Configure your Event Push Service settings using this article. Customers | Partners. Please note that after the successful deployment of the Data Connector & successful setup of GravityZone's Event Push Service, the system will receive Activity Log data in near-real-time. A short delay may occur between data transmission and its appearance in the Microsoft Sentinel Logs section.

GreyNoise Threat Intelligence

Supported by: GreyNoise

This Data Connector installs an Azure Function app to download GreyNoise indicators once per day and inserts them into the ThreatIntelIndicators table in Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ThreatIntelIndicators`	Yes	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
GreyNoise API Key: Retrieve your GreyNoise API Key here.

Setup Instructions:

**You can connect GreyNoise Threat Intelligence to Microsoft Sentinel by following the below steps: **

The following steps create an Azure AAD application, retrieves a GreyNoise API key, and saves the values in an Azure Function App Configuration.

1. Retrieve your API Key from GreyNoise Visualizer.

Generate an API key from GreyNoise Visualizer https://docs.greynoise.io/docs/using-the-greynoise-api

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID and Client ID. Also, get the Log Analytics Workspace ID associated with your Microsoft Sentinel instance (it should display below).

Follow the instructions here to create your Azure AAD app and save your Client ID and Tenant ID: /azure/sentinel/connect-threat-intelligence-upload-api#instructions NOTE: Wait until step 5 to generate your client secret.

Workspace ID: <variable value provided at install time>

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

Follow the instructions here to add the Microsoft Sentinel Contributor Role: /azure/sentinel/connect-threat-intelligence-upload-api#assign-a-role-to-the-application

4. Specify the AAD permissions to enable MS Graph API access to the upload-indicators API.

Follow this section here to add 'ThreatIndicators.ReadWrite.OwnedBy' permission to the AAD App: /azure/sentinel/connect-threat-intelligence-tip#specify-the-permissions-required-by-the-application. Back in your AAD App, ensure you grant admin consent for the permissions you just added. Finally, in the 'Tokens and APIs' section, generate a client secret and save it. You will need it in Step 6.

5. Deploy the Threat Intelligence (New) Solution, (v3.0.14 or later) which includes the Threat Intelligence Upload Indicators API (Preview)

See Microsoft Sentinel Content Hub for this Solution, and install it in the Microsoft Sentinel instance. Note that you do not need to do any configuration in this step.

6. Deploy the Azure Function

Click the Deploy to Azure button.

aka.ms

Fill in the appropriate values for each parameter. Be aware that the only valid values for the GREYNOISE_CLASSIFICATIONS parameter are benign, malicious and/or unknown, which must be comma-separated.

7. Send indicators to Sentinel

The function app installed in Step 6 queries the GreyNoise GNQL API once per day, and submits each indicator found in STIX 2.1 format to the Microsoft Upload Threat Intelligence Indicators API. Each indicator expires in ~24 hours from creation unless found on the next day's query. In this case the TI Indicator's Valid Until time is extended for another 24 hours, which keeps it active in Microsoft Sentinel.

For more information on the GreyNoise API and the GreyNoise Query Language (GNQL), click here.

Halcyon Connector

Supported by: Halcyon

The Halcyon connector provides the capability to send data from Halcyon to Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`HalcyonEvents_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra Create Permissions: Permissions to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.
Role Assignment Permissions: Write permissions required to assign Monitoring Metrics Publisher role to the data collection rule (DCR). Typically requires Owner or User Access Administrator role at the resource group level.

Setup Instructions:

1. Create ARM Resources and Provision Required Permissions

This connector reads data from the tables that Halcyon uses in a Microsoft Analytics Workspace, if the data is being forwarded

2. Configure your integration in the Halcyon Platform

Use the following parameters to configure your integration in the Halcyon Platform.

Directory ID (Tenant ID): <variable value provided at install time>
Entra App Registration Application ID (Client ID): <variable value provided at install time>
Entra App Registration Secret (Credential Secret) (THIS SECRET WILL NOT BE VISIBLE AFTER LEAVING THIS PAGE): <variable value provided at install time>
Data Collection Endpoint (URL): <variable value provided at install time>
Data Collection Rule ID (Rule ID): <variable value provided at install time>

Holm Security Asset Data (using Azure Functions)

Supported by: Holm Security

The connector provides the capability to poll data from Holm Security Center into Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`net_assets_CL`	No	No
`web_assets_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
Holm Security API Token: Holm Security API Token is required. Holm Security API Token

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Holm Security Assets to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1 - Configuration steps for the Holm Security API

Follow these instructions to create an API authentication token.

STEP 2 - Use the below deployment option to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Holm Security connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Holm Security API authorization Token, readily available.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template Deployment

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Holm Security connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID, Workspace Key, API Username, API Password, 'and/or Other required fields'.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

IIS Logs of Microsoft Exchange Servers

Supported by: Community

[Option 5] - Using Azure Monitor Agent - You can stream all IIS Logs from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to create custom alerts, and improve investigation.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`W3CIISLog`	Yes	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more
Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 5 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

[Option 5] IIS logs of Exchange Servers

Select how to stream IIS logs of Exchange Servers

Enable data collection rule

IIS logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template (Preferred Method)

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
You can change the proposed name of the DCE.
Click Create to deploy.

B. Deploy Data Connection Rule

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Workspace ID 'and/or Other required fields'.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.
Click + Create at the top.
In the Basics tab, fill the required fields and give a name to the DCE.
'Make other preferable configuration changes', if needed, then click Create.

B. Create DCR, Type IIS log

From the Azure Portal, navigate to Azure Data collection rules.
Click + Create at the top.
In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR. Select the created DCE.
In the Resources tab, enter you Exchange Servers.
In 'Collect and deliver', add a Data Source type 'IIS logs' (Do not enter a path if IIS Logs path is configured by default). Click on 'Add data source'
'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Illumio Insights

Supported by: Illumio

The Illumio Insights data connector allows ingesting logs from the Illumio API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework. It uses the Illumio API to fetch logs and it supports DCR-based ingestion time transformations that parses the received security data into a custom table so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`IlumioInsights`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configuration steps for the Illumio Insights API

Prerequisites

Register and Login to Illumio Console with valid credentials
Client Credentials need to be stored in Microsoft Sentinel account for the tenant

Step 1: Register the Service Account

Go to Illumio Console → Access → Service Accounts
Create a service account for the tenant
Once you create a service account, you will receive the client credentials
Copy the Username (API Key) and the Secret Step 2: Add Client Credentials to Sentinel Account

Add the API key and secret to Sentinel Account for tenant authentication
These credentials will be used to authenticate calls to the Illumio SaaS API

Step 3: API Usage The connector will use these credentials to call the Illumio SaaS API:

Endpoint: GET https://gw.console.illum.io/api/v1/resource-insights
Required Headers:
- x-illumio-tenant-id: Your Illumio tenant ID
- x-auth-key: The API key obtained from step 1
- x-auth-X-api-secret: The secret key obtained from step 1

Authentication Validation Illumio validates the request against:

Signature against Entra ID's public keys
Audience (aud) matches your API's App ID URI
Issuer validation

Please fill in the required fields below with the credentials obtained from the Illumio Console:

Illumio Insights Api Key: (api_XXXXXX)
Api Secret: (API Secret)
Illumio Tenant Id: ({illumioTenantId})
Enable/Disable Connection

Illumio Insights Summary

Supported by: Illumio

The Illumio Insights Summary data connector provides the capability to ingest Illumio security insights and threat analysis reports into Microsoft Sentinel through the REST API. Refer to Illumio API documentation for more information. The connector provides the ability to get daily and weekly summary reports from Illumio and visualize them in Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`IllumioInsightsSummary_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Illumio API access: Illumio API access is required for the Illumio Insights Summary API.

Setup Instructions:

1. Configuration

Configure the Illumio Insights Summary connector.

[!NOTE] This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution.

Illumio Insights Api Key: (api_XXXXXX)
Api Secret: (API Secret)
Illumio Tenant ID: ({illumioTenantId})

2. Connect

Enable the Illumio Insights Summary connector.

Enable/Disable Connection

Illumio SaaS (using Azure Functions)

Supported by: Illumio

Illumio connector provides the capability to ingest events into Microsoft Sentinel. The connector provides ability to ingest auditable and flow events from AWS S3 bucket.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Illumio_Auditable_Events_CL`	Yes	Yes
`Illumio_Flow_Events_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
SQS and AWS S3 account credentials/permissions: AWS_SECRET, AWS_REGION_NAME, AWS_KEY, QUEUE_URL is required. If you are using s3 bucket provided by Illumio, contact Illumio support. At your request they will provide you with the AWS S3 bucket name, AWS SQS url and AWS credentials to access them.
Illumio API key and secret: ILLUMIO_API_KEY, ILLUMIO_API_SECRET is required for a workbook to make connection to SaaS PCE and fetch API responses.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the AWS SQS / S3 to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

Prerequisites

Ensure AWS SQS is configured for the s3 bucket from which flow and auditable event logs are going to be pulled. In case, Illumio provides bucket, please contact Illumio support for sqs url, s3 bucket name and aws credentials.
Register AAD application - For DCR (Data collection rule) to authentiate to ingest data into log analytics, you must use Entra application. 1. Follow the instructions here (steps 1-5) to get AAD Tenant Id, AAD Client Id and AAD Client Secret.
Ensure you have created a log analytics workspace. Please keep note of the name and region where it has been deployed.

Deployment

Choose one of the approaches from below options. Either use the below ARM template to deploy azure resources or deploy function app manually.

1. Azure Resource Manager (ARM) Template

Use this method for automated deployment of Azure resources using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Provide the required details such as Microsoft Sentinel Workspace, AWS credentials, Azure AD Application details and ingestion configurations

NOTE: It is recommended to create a new Resource Group for deployment of function app and associated resources. 3. Mark the checkbox labeled I agree to the terms and conditions stated above. 4. Click Purchase to deploy.

2. Deploy additional function apps to handle scale

Use this method for automated deployment of additional function apps using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms

3. Manual Deployment of Azure Functions

Deployment via Visual Studio Code.

Deploy a Function App
Download the Azure Function App file. Extract archive to your local development computer.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow next steps for configuring it.
Configure the Function App
Follow documentation <insert link> to set up all required environment variables and click Save. Ensure you restart the function app once settings are saved.

Imperva Cloud WAF (using Azure Functions)

Supported by: Microsoft Corporation

The Imperva Cloud WAF data connector provides the capability to integrate and ingest Web Application Firewall events into Microsoft Sentinel through the REST API. Refer to Log integration documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ImpervaWAFCloud_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: ImpervaAPIID, ImpervaAPIKey, ImpervaLogServerURI are required for the API. For more information, see Setup Log Integration process. Check all requirements and follow the instructions for obtaining credentials. Please note that this connector uses CEF log event format. More information about log format.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Imperva Cloud API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

**NOTE:**This data connector depends on a parser based on a Kusto Function to work as expected ImpervaWAFCloud which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the Log Integration

Follow the instructions to obtain the credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Functions

IMPORTANT: Before deploying the Workspace data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Imperva Cloud WAF data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the ImpervaAPIID, ImpervaAPIKey, ImpervaLogServerURI and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Imperva Cloud WAF data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure functions development.

Download the Azure Functions App file. Extract archive to your local development computer.
Start VS Code. Choose File in the main menu and select Open Folder.
Select the top level folder from extracted files.
Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.
Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. ImpervaCloudXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.
Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.
Go to Azure Portal for the Function App configuration.
Configure the Function App
In the Function App, select the Function App Name and select Configuration.
In the Application settings tab, select New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): ImpervaAPIID ImpervaAPIKey ImpervaLogServerURI WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Imperva Cloud WAF (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Imperva WAF Cloud data connector provides the capability to ingest logs into Microsoft Sentinel using the Imperva Log Integration via AWS S3 with SQS notifications. The connector parses CEF-formatted WAF events including access logs and security alerts for threat detection and investigation.Refer to Imperva WAF Cloud Log Integration for more information.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ImpervaWAFCloud`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

**Connect Imperva WAF Cloud to Microsoft Sentinel

NOTE: This connector fetches the Imperva Cloud WAF logs from AWS S3 bucket

To gather data from Imperva, you need to configure the following resources

AWS Role ARN To gather data from Imperva, you'll need AWS Role ARN.
AWS SQS Queue URL To gather data from Imperva, you'll need AWS SQS Queue URL.

For detailed steps to retrieve the AWS Role ARN, SQS Queue URL, and configure Imperva log forwarding to the Amazon S3 bucket, refer to the Connector Setup Guide.

Data Connectors Grid (configure in portal)

Infoblox Cloud Data Connector via AMA

Supported by: Infoblox

The Infoblox Cloud Data Connector allows you to easily connect your Infoblox data with Microsoft Sentinel. By connecting your logs to Microsoft Sentinel, you can take advantage of search & correlation, alerting, and threat intelligence enrichment for each log.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CommonSecurityLog`	Yes	Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

IMPORTANT: This Microsoft Sentinel data connector assumes an Infoblox Data Connector host has already been created and configured in the Infoblox Cloud Services Portal (CSP). As the Infoblox Data Connector is a feature of Threat Defense, access to an appropriate Threat Defense subscription is required. See this quick-start guide for more information and licensing requirements.

1. Linux Syslog agent configuration

Install and configure the Linux agent to collect your Common Event Format (CEF) Syslog messages and forward them to Microsoft Sentinel.

Notice that the data from all regions will be stored in the selected workspace

1.1 Select or create a Linux machine

1.2 Install the CEF collector on the Linux machine

Make sure that you have Python on your machine using the following command: python -version.
You must have elevated permissions (sudo) on your machine.

Run the following command to install and apply the CEF collector:: <variable value provided at install time>

2. Configure Infoblox to send Syslog data to the Infoblox Cloud Data Connector to forward to the Syslog agent

Follow the steps below to configure the Infoblox CDC to send data to Microsoft Sentinel via the Linux Syslog agent.

Navigate to Manage > Data Connector.
Click the Destination Configuration tab at the top.
Click Create > Syslog.

Name: Give the new Destination a meaningful name, such as Microsoft-Sentinel-Destination.
Description: Optionally give it a meaningful description.
State: Set the state to Enabled.
Format: Set the format to CEF.
FQDN/IP: Enter the IP address of the Linux device on which the Linux agent is installed.
Port: Leave the port number at 514.
Protocol: Select desired protocol and CA certificate if applicable.
Click Save & Close.

Click the Traffic Flow Configuration tab at the top.
Click Create.

Name: Give the new Traffic Flow a meaningful name, such as Microsoft-Sentinel-Flow.
Description: Optionally give it a meaningful description.
State: Set the state to Enabled.
Expand the Service Instance section.
Service Instance: Select your desired Service Instance for which the Data Connector service is enabled.
Expand the Source Configuration section.
Source: Select BloxOne Cloud Source.
Select all desired log types you wish to collect. Currently supported log types are:
Threat Defense Query/Response Log
Threat Defense Threat Feeds Hits Log
DDI Query/Response Log
DDI DHCP Lease Log
Expand the Destination Configuration section.
Select the Destination you just created.
Click Save & Close.

Allow the configuration some time to activate.

3. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python -version
You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**4. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

Infoblox Data Connector via REST API

Supported by: Infoblox

The Infoblox Data Connector allows you to easily connect your Infoblox TIDE data and Dossier data with Microsoft Sentinel. By connecting your data to Microsoft Sentinel, you can take advantage of search & correlation, alerting, and threat intelligence enrichment for each log.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Failed_Range_To_Ingest_CL`	No	No
`Infoblox_Failed_Indicators_CL`	No	No
`dossier_whois_CL`	No	No
`dossier_whitelist_CL`	No	No
`dossier_tld_risk_CL`	No	No
`dossier_threat_actor_CL`	No	No
`dossier_rpz_feeds_records_CL`	No	No
`dossier_rpz_feeds_CL`	No	No
`dossier_nameserver_matches_CL`	No	No
`dossier_nameserver_CL`	No	No
`dossier_malware_analysis_v3_CL`	No	No
`dossier_inforank_CL`	No	No
`dossier_infoblox_web_cat_CL`	No	No
`dossier_geo_CL`	No	No
`dossier_dns_CL`	No	No
`dossier_atp_threat_CL`	No	No
`dossier_atp_CL`	No	No
`dossier_ptr_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.
Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: Infoblox API Key is required. See the documentation to learn more about API on the Rest API reference

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Infoblox API to create Threat Indicators for TIDE and pull Dossier data into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.
Search for and select Microsoft Entra ID.
Under Manage, select App registrations > New registration.
Enter a display Name for your application.
Select Register to complete the initial app registration.
When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of the TriggersSync playbook.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 2 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TriggersSync playbook. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.
Select Certificates & secrets > Client secrets > New client secret.
Add a description for your client secret.
Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.
Select Add.
Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TriggersSync playbook.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 3 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.
Go to Access control (IAM) from left panel.
Click on Add, and then select Add role assignment.
Select Contributor as role and click on next.
In Assign access to, select User, group, or service principal.
Click on add members and type your app name that you have created and select it.
Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 4 - Steps to generate the Infoblox API Credentials

Follow these instructions to generate Infoblox API Key. In the Infoblox Cloud Services Portal, generate an API Key and copy it somewhere safe to use in the next step. You can find instructions on how to create API keys here.

STEP 5 - Steps to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Infoblox data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.., as well as the Infoblox API Authorization Credentials

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Infoblox Data connector.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the below information : Azure Tenant Id Azure Client Id Azure Client Secret Infoblox API Token Infoblox Base URL Workspace ID Workspace Key Log Level (Default: INFO) Confidence Threat Level App Insights Workspace Resource ID
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Infoblox SOC Insight Data Connector via AMA

Supported by: Infoblox

The Infoblox SOC Insight Data Connector allows you to easily connect your Infoblox BloxOne SOC Insight data with Microsoft Sentinel. By connecting your logs to Microsoft Sentinel, you can take advantage of search & correlation, alerting, and threat intelligence enrichment for each log.

This data connector ingests Infoblox SOC Insight CDC logs into your Log Analytics Workspace using the new Azure Monitor Agent. Learn more about ingesting using the new Azure Monitor Agent here. Microsoft recommends using this Data Connector.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CommonSecurityLog`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

To collect data from non-Azure VMs, they must have Azure Arc installed and enabled. Learn more
Common Event Format (CEF) via AMA and Syslog via AMA data connectors must be installed. Learn more

Setup Instructions:

Workspace Keys

In order to use the playbooks as part of this solution, find your Workspace ID and Workspace Primary Key below for your convenience.

Workspace ID: <variable value provided at install time>
Workspace Key: <variable value provided at install time>

Parsers

This data connector depends on a parser based on a Kusto Function to work as expected called InfobloxCDC_SOCInsights which is deployed with the Microsoft Sentinel Solution.

SOC Insights

This data connector assumes you have access to Infoblox BloxOne Threat Defense SOC Insights. You can find more information about SOC Insights here.

Infoblox Cloud Data Connector

This data connector assumes an Infoblox Data Connector host has already been created and configured in the Infoblox Cloud Services Portal (CSP). As the Infoblox Data Connector is a feature of BloxOne Threat Defense, access to an appropriate BloxOne Threat Defense subscription is required. See this quick-start guide for more information and licensing requirements.

Follow the steps below to configure this data connector

A. Configure the Common Event Format (CEF) via AMA data connector

Note: CEF logs are collected only from Linux Agents

Navigate to your Microsoft Sentinel workspace > Data connectors blade.
Search for the Common Event Format (CEF) via AMA data connector and open it.
Ensure there is no existing DCR configured to collect required facility of logs as it may cause log duplication. Create a new DCR (Data Collection Rule).

Note: It is recommended to install the AMA agent v1.27 at minimum. Learn more and ensure there is no duplicate DCR as it can cause log duplication.
Run the command provided in the Common Event Format (CEF) via AMA data connector page to configure the CEF collector on the machine.

B. Within the Infoblox Cloud Services Portal, configure Infoblox BloxOne to send CEF Syslog data to the Infoblox Cloud Data Connector to forward to the Syslog agent

Follow the steps below to configure the Infoblox CDC to send BloxOne data to Microsoft Sentinel via the Linux Syslog agent.

Navigate to Manage > Data Connector.
Click the Destination Configuration tab at the top.
Click Create > Syslog.

Name: Give the new Destination a meaningful name, such as Microsoft-Sentinel-Destination.
Description: Optionally give it a meaningful description.
State: Set the state to Enabled.
Format: Set the format to CEF.
FQDN/IP: Enter the IP address of the Linux device on which the Linux agent is installed.
Port: Leave the port number at 514.
Protocol: Select desired protocol and CA certificate if applicable.
Click Save & Close.

Click the Traffic Flow Configuration tab at the top.
Click Create.

Name: Give the new Traffic Flow a meaningful name, such as Microsoft-Sentinel-Flow.
Description: Optionally give it a meaningful description.
State: Set the state to Enabled.
Expand the Service Instance section.
Service Instance: Select your desired Service Instance for which the Data Connector service is enabled.
Expand the Source Configuration section.
Source: Select BloxOne Cloud Source.
Select the Internal Notifications Log Type.
Expand the Destination Configuration section.
Select the Destination you just created.
Click Save & Close.

Allow the configuration some time to activate.

C. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python -version
You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**2. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

Infoblox SOC Insight Data Connector via REST API

Supported by: Infoblox

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`InfobloxInsight_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

Workspace Keys

In order to use the playbooks as part of this solution, find your Workspace ID and Workspace Primary Key below for your convenience.

Workspace ID: <variable value provided at install time>
Workspace Key: <variable value provided at install time>

Parsers

This data connector depends on a parser based on a Kusto Function to work as expected called InfobloxInsight which is deployed with the Microsoft Sentinel Solution.

SOC Insights

This data connector assumes you have access to Infoblox BloxOne Threat Defense SOC Insights. You can find more information about SOC Insights here.

Follow the steps below to configure this data connector

1. Generate an Infoblox API Key and copy it somewhere safe

In the Infoblox Cloud Services Portal, generate an API Key and copy it somewhere safe to use in the next step. You can find instructions on how to create API keys here.

2. Configure the Infoblox-SOC-Get-Open-Insights-API playbook

Create and configure the Infoblox-SOC-Get-Open-Insights-API playbook which is deployed with this solution. Enter your Infoblox API key in the appropriate parameter when prompted.

InfoSecGlobal Data Connector

Supported by: InfoSecGlobal

Use this data connector to integrate with InfoSec Crypto Analytics and get data sent directly to Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`InfoSecAnalytics_CL`	No	No

Data collection rule support: Not currently supported

Setup Instructions:

InfoSecGlobal Crypto Analytics Data Connector

Data is sent to Microsoft Sentinel through Logstash
Required Logstash configuration is included with Crypto Analytics installation
Documentation provided with the Crypto Analytics installation explains how to enable sending data to Microsoft Sentinel

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

IONIX Security Logs (via Codeless Connector Framework)

Supported by: IONIX

The IONIX connector allows you to ingest action items from your IONIX Attack Surface Management platform into Microsoft Sentinel using the Codeless Connector Framework (CCF). Action items represent security findings and vulnerabilities that require remediation.

This connector automatically polls the IONIX API and writes data to the CyberpionActionItems_CL table.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`CyberpionActionItems_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

IONIX API Token: An API token from IONIX Portal is required. Create one in Settings > API in your IONIX Portal.

Setup Instructions:

Connect IONIX to Microsoft Sentinel

This connector uses the IONIX API to automatically poll for action items and ingest them into Microsoft Sentinel. You need an API token from your IONIX Portal.

IONIX API Token: (Enter your JWT API token from IONIX Settings > API)
IONIX Account Name: (cyberpion)
Enable/Disable Connection

IPinfo Abuse Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_abuse datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Abuse_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

Assign the AAD application you just created to the Contributor(Privileged administrator roles) and Monitoring Metrics Publisher(Job function roles) in the same “Resource Group” you use for “Log Analytic Workspace” on which “Microsoft Sentinel” is added: Use this Link.

4. Get Workspace Resource ID

Use the Log Analytic Workspace -> Properties blade having the 'Resource ID' property value. This is a fully qualified resourceId which is in the format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo ASN Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_ASN datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_ASN_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Carrier Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_carrier datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Carrier_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Company Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_company datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Company_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Core Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download Core datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_CORE_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Country ASN Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download country_asn datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Country_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Domain Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_domain datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Domain_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Iplocation Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_location datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Location_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Iplocation Extended Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_location_extended datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Location_extended_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Plus Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download Plus datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_PLUS_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Privacy Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_privacy datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Privacy_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo Privacy Extended Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download standard_privacy datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_Privacy_extended_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo ResProxy Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download ResProxy datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_RESIDENTIAL_PROXY_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo RIRWHOIS Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download RIRWHOIS datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_RIRWHOIS_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo RWHOIS Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download RWHOIS datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_RWHOIS_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo WHOIS ASN Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download WHOIS_ASN datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_WHOIS_ASN_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo WHOIS MNT Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download WHOIS_MNT datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_WHOIS_MNT_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo WHOIS NET Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download WHOIS_NET datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_WHOIS_NET_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo WHOIS ORG Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download WHOIS_ORG datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_WHOIS_ORG_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

IPinfo WHOIS POC Data Connector

Supported by: IPinfo

This IPinfo data connector installs an Azure Function app to download WHOIS_POC datasets and insert it into custom log table in Microsoft Sentinel

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Ipinfo_WHOIS_POC_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
IPinfo API Token: Retrieve your IPinfo API Token here.

Setup Instructions:

1. Retrieve API Token

Retrieve your IPinfo API Token here.

2. In your Azure AD tenant, create an Azure Active Directory (AAD) application

In your Azure AD tenant, create an Azure Active Directory (AAD) application and acquire Tenant ID, Client ID, and Client Secret: Use this Link.

3. Assign the AAD application the Microsoft Sentinel Contributor Role.

4. Get Workspace Resource ID

5. Deploy the Azure Function

Use this for automated deployment of the IPinfo data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the RESOURCE_ID, IPINFO_TOKEN, TENANT_ID, CLIENT_ID, CLIENT_SECRET.

Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the IPinfo data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract the archive to your local development computer Azure Function App.
Create Function App using Hosting Functions Premium or App service plan using advanced option using VSCode.
Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.
After successful deployment of the function app, follow the next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.
In the Function App, select the Function App Name and select Settings -> Configuration or Environment variables.
In the Application settings tab, select + New application setting.
Add each of the following application settings individually, with their respective string values (case-sensitive): RESOURCE_ID IPINFO_TOKEN TENANT_ID CLIENT_ID CLIENT_SECRET RETENTION_IN_DAYS TOTAL_RETENTION_IN_DAYS SCHEDULE LOCATION
Once all application settings have been entered, click Save.

Island Enterprise Browser V2

Supported by: Island

The Island Enterprise Browser V2 Data Connector allows you to ingest user events, admin events, and system events, all within a single connector.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`Island_UserEvents_V2_CL`	No	No

Data collection rule support: Not currently supported

Prerequisites:

Island API Key: An Island API key is required. Generate the API Key via Island Management Console. For further instructions, refer to the official Island documentation.

Setup Instructions:

Connect Island to Microsoft Sentinel

API URL and API Key are available via Island Management Console. For further instructions, refer to the official Island documentation.

API URL: (API URL)
API Key: (Key)
Enable/Disable Connection

Jamf Protect Push Connector

Supported by: Jamf Software, LLC

The Jamf Protect connector provides the capability to read raw event data from Jamf Protect in Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`jamfprotecttelemetryv2_CL`	Yes	Yes
`jamfprotectunifiedlogs_CL`	Yes	Yes
`jamfprotectalerts_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.
Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector reads data from the tables that Jamf Protect uses in a Microsoft Analytics Workspace, if the data forwarding option is enabled in Jamf Protect then raw event data is sent to the Microsoft Sentinel Ingestion API.

2. Push your logs into the workspace

Use the following parameters to configure the your machine to send the logs to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>
Entra App Registration Application ID: <variable value provided at install time>
Entra App Registration Secret: <variable value provided at install time>
Data Collection Endpoint Uri: <variable value provided at install time>
Data Collection Rule Immutable ID: <variable value provided at install time>
Unified Logs Stream Name: <variable value provided at install time>
Telemetry Stream Name: <variable value provided at install time>
Alerts Stream Name: <variable value provided at install time>

JoeSandboxThreatIntelligence (using Azure Functions)

Supported by: Stefan Bühlmann

JoeSandboxThreatIntelligence connector automatically generates and feeds threat intelligence for all submissions to JoeSandbox, improving threat detection and incident response in Sentinel. This seamless integration empowers teams to proactively address emerging threats.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`ThreatIntelligenceIndicator`	Yes	No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in azure active directory() and assign role of contributor to app in resource group.
Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.
REST API Credentials/permissions: JoeSandbox API Key is required.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the JoeSandbox API to pull JoeSandbox Threat IOCs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

Workspace ID: <variable value provided at install time>
Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template for Flex Consumption Plan

Use this method for automated deployment of the data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Application ID, Tenant ID,Client Secret, JoeSandbox API Key, JoeSandbox Initial Fetch Date, TimeInterval and deploy.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Option 2 - Azure Resource Manager (ARM) Template for Premium Plan

Use this method for automated deployment of the data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms
Select the preferred Subscription, Resource Group and Location.
Enter the Application ID, Tenant ID,Client Secret, JoeSandbox API Key, JoeSandbox Initial Fetch Date, TimeInterval and deploy.
Mark the checkbox labeled I agree to the terms and conditions stated above.
Click Purchase to deploy.

Keeper Security Push Connector

Supported by: Keeper Security

The Keeper Security connector provides the capability to read raw event data from Keeper Security in Microsoft Sentinel.

Log Analytics table(s):

Table	DCR support	Lake-only ingestion
`KeeperSecurityEventNewLogs_CL`	Yes	Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.
Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector reads data from the tables that Keeper Security uses in a Microsoft Analytics Workspace, if the data forwarding option is enabled in Keeper Security then raw event data is sent to the Microsoft Sentinel Ingestion API.

2. Push your logs into the workspace

Use the following parameters to configure the your machine to send the logs to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>
Entra App Registration Application ID: <variable value provided at install time>
Entra App Registration Secret: <variable value provided at install time>
Data Collection Endpoint Uri: <variable value provided at install time>
Data Collection Rule Immutable ID: <variable value provided at install time>
Events Logs Stream Name: <variable value provided at install time>

3. Update Keeper Admin Console

Configure the Keeper Admin Console with the Azure connection details to enable data forwarding to Microsoft Sentinel.

Configure Azure Monitor Logs in Keeper Admin Console

In the Keeper Admin Console, login as the Keeper Administrator. Then go to Reporting & Alerts and select Azure Monitor Logs.

Provide the following information from Step 2 above into the Admin Console:

Azure Tenant ID: You can find this from Azure's "Subscriptions" area.
Application (client) ID: This is located in the App registration (KeeperLogging) overview screen
Client Secret Value: This is the Client Secret Value from the app registration secrets.
Endpoint URL: This is a URL that is created in the following specific format: https://<collection_url>/dataCollectionRules/<dcr_id>/streams/<table>?api-version=2023-01-01

To assemble the Endpoint URL:

<Collection URL> This comes from Step 2 above
<DCR_ID> From the Data Collector Rule, copy the "Immutable Id" value, e.g. dcr-xxxxxxx
This is the table name created by Azure, e.g. Custom-KeeperSecurityEventNewLogs
Example: https://<Collection_URL>/dataCollectionRules/<DCR_ID>/streams/Custom-KeeperSecurityEventNewLogs?api-version=2023-01-01

LastPass Enterprise - Reporting (Polling CCF)

Supported by: The Collective Consulting

The LastPass Enterprise connector provides the capability to LastPass reporting (audit) logs into Microsoft Sentinel. The connector provides visibility into logins and activity within LastPass (such as reading and removing passwords).

Log Analytics table(s):

Table DCR support Lake-only ingestion

LastPassNativePoller_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

LastPass API Key and CID: A LastPass API key and CID are required. For more information, see LastPass API.

Setup Instructions:

Connect LastPass Enterprise to Microsoft Sentinel

Provide the LastPass Provisioning API Key.

Lookout Mobile Threat Detection Connector (via Codeless Connector Framework) (Preview)

Supported by: Lookout

The Lookout Mobile Threat Detection data connector provides the capability to ingest events related to mobile security risks into Microsoft Sentinel through the Mobile Risk API. Refer to API documentation for more information. This connector helps you examine potential security risks detected in mobile devices.

Log Analytics table(s):

Table DCR support Lake-only ingestion

LookoutMtdV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Lookout Mobile Threat Defence connector to Microsoft Sentinel

Before connecting to Lookout, ensure the following prerequisites are completed.

ApiKey is required for Mobile Threat Detection API. See the documentation to learn more about API. Check all requirements and follow the instructions for obtaining credentials.

API key: (Enter your API key )

Enable/Disable Connection

Luminar IOCs and Leaked Credentials (using Azure Functions)

Supported by: Cognyte Luminar

Luminar IOCs and Leaked Credentials connector allows integration of intelligence-based IOC data and customer-related leaked records identified by Luminar.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in azure active directory() and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: Luminar Client ID, Luminar Client Secret and Luminar Account ID are required.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Cognyte Luminar API to pull Luminar IOCs and Leaked Credentials into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Application ID, Tenant ID,Client Secret, Luminar API Client ID, Luminar API Account ID, Luminar API Client Secret, Limit, TimeInterval and deploy.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Cognyte Luminar data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE:You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CognyteLuminarXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): Application ID Tenant ID Client Secret Luminar API Client ID Luminar API Account ID Luminar API Client Secret Limit TimeInterval - Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us

Once all application settings have been entered, click Save.

MailGuard 365

Supported by: MailGuard 365

MailGuard 365 Enhanced Email Security for Microsoft 365. Exclusive to the Microsoft marketplace, MailGuard 365 is integrated with Microsoft 365 security (incl. Defender) for enhanced protection against advanced email threats like phishing, ransomware and sophisticated BEC attacks.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MailGuard365_Threats_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configure and connect MailGuard 365

In the MailGuard 365 Console, click Settings on the navigation bar.

Click the Integrations tab.

Click the Enable Microsoft Sentinel.

Enter your workspace id and primary key from the fields below, click Finish.

For additional instructions, please contact MailGuard 365 support.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

MailRisk by Secure Practice

Supported by: Secure Practice

The MailRisk by Secure Practice connector allows you to ingest email threat intelligence data from the MailRisk API into Microsoft Sentinel. This connector provides visibility into reported emails, risk assessments, and security events related to email threats.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MailRiskEventEmails_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

API credentials: Your Secure Practice API key pair is also needed, which are created in the settings in the admin portal. Generate a new key pair with description Microsoft Sentinel.

Setup Instructions:

1. Obtain Secure Practice API Credentials

Log in to your Secure Practice account and generate an API Key and API Secret if you haven't already.

2. Connect to MailRisk API

Enter your Secure Practice API credentials below. The credentials will be securely stored and used to authenticate API requests.

API Key: (Enter your Secure Practice API Key)

API Secret: (Enter your Secure Practice API Secret)

Enable/Disable Connection

meshStack Event Logs

Supported by: meshcloud GmbH

The meshStack Event Logs connector provides the capability to ingest meshStack platform events into Microsoft Sentinel. By connecting meshStack event logs into Microsoft Sentinel, you can view this data in workbooks, use it to create custom alerts, and improve your investigation process for cloud platform governance, audit, and compliance monitoring.

Log Analytics table(s):

Table DCR support Lake-only ingestion

meshStackEventLogs_CL No No

Data collection rule support: Not currently supported

Prerequisites:

meshStack OAuth2 API Key: A valid meshStack API Key with the 'Admin: List Event Logs in any Workspace' permission is required. Create the API Key in the meshStack Admin Panel under Access Control > API Keys. The API Key provides OAuth2 credentials (Key ID as client_id and Key Secret as client_secret) for authentication. Note: The API Key is bound to a workspace but can access events from all workspaces.

meshStack Instance: Access to a meshStack instance with the Events API enabled.

Setup Instructions:

Connect meshStack Event Logs to Microsoft Sentinel

Enter your meshStack instance API URL and OAuth2 credentials from the API Key. The API URL format should be: https://your-meshstack-instance.io. Create an API Key in meshStack (Admin Panel > Access Control > API Keys) with the 'Admin: List Event Logs in any Workspace' permission. The API Key provides a Key ID (client_id) and Key Secret (client_secret) for OAuth2 authentication.

meshStack API URL: (https://your-meshstack-instance.io)

Client ID (Key ID): (Enter Key ID from API Key)

Client Secret (Key Secret): (Enter Key Secret from API Key)

Enable/Disable Connection

Microsoft 365 (formerly, Office 365)

Supported by: Microsoft Corporation

The Microsoft 365 (formerly, Office 365) activity log connector provides insight into ongoing user activities. You will get details of operations such as file downloads, access requests sent, changes to group events, set-mailbox and details of the user who performed the actions. By connecting Microsoft 365 logs into Microsoft Sentinel you can use this data to view dashboards, create custom alerts, and improve your investigation process. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OfficeActivity Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft 365 Insider Risk Management

Supported by: Microsoft Corporation

Microsoft 365 Insider Risk Management is a compliance solution in Microsoft 365 that helps minimize internal risks by enabling you to detect, investigate, and act on malicious and inadvertent activities in your organization. Risk analysts in your organization can quickly take appropriate actions to make sure users are compliant with your organization's compliance standards.

Insider risk policies allow you to:

define the types of risks you want to identify and detect in your organization.

decide on what actions to take in response, including escalating cases to Microsoft Advanced eDiscovery if needed.

This solution produces alerts that can be seen by Office customers in the Insider Risk Management solution in Microsoft 365 Compliance Center. Learn More about Insider Risk Management.

These alerts can be imported into Microsoft Sentinel with this connector, allowing you to see, investigate, and respond to them in a broader organizational threat context. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Active-Directory Domain Controllers Security Event Logs

Supported by: Community

[Option 3 & 4] - Using Azure Monitor Agent -You can stream a part or all Domain Controllers Security Event logs from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to create custom alerts, and improve investigation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityEvent Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 3 and 4 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

Security logs of Domain Controllers

Select how to stream Security logs of Domain Controllers. If you want to implement Option 3, you just need to select DC on same site as Exchange Servers. If you want to implement Option 4, you can select all DCs of your forest.

[Option 3] List only Domain Controllers on the same site as Exchange Servers for next step

This limits the quantity of data injested but some incident can't be detected.

[Option 4] List all Domain Controllers of your Active-Directory Forest for next step

This allows collecting all security events

Security Event log collection

Data Collection Rules - Security Event logs

Enable data collection rule for Security Logs Security Events logs are collected only from Windows agents.

Add chosen DCs on Resources tab.

Select Security log level

Common level is the minimum required. Please select 'Common' or 'All Security Events' on DCR definition.

Install Agent: <variable value provided at install time>

Microsoft Copilot

Supported by: Microsoft

The Microsoft Copilot logs connector in Microsoft Sentinel enables seamless ingestion of Copilot-generated activity logs from M365 Copilot and Security Copilot into Microsoft Sentinel for advanced threat detection, investigation and response. It collects telemetry from Microsoft Copilot services such as usage data and system responses and ingests into Microsoft Sentinel, allowing security teams to monitor for misuse, detect anomalies, and maintain compliance with organizational policies.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CopilotActivity No Yes

Data collection rule support: Not currently supported

Prerequisites:

Tenant Permissions: 'Security Administrator' or 'Global Administrator' on the workspace's tenant.

Setup Instructions:

Connect Microsoft Copilot audit logs to Microsoft Sentinel

This connector uses the Office Management API to get your Microsoft Copilot audit logs. The logs will be stored and processed in your existing Microsoft Sentinel workspace. You can find the data in the CopilotActivity table.

Enable/Disable Connection

Microsoft Dataverse

Supported by: Microsoft Corporation

Microsoft Dataverse is a scalable and secure data platform that enables organizations to store and manage data used by business applications. The Microsoft Dataverse data connector provides the capability to ingest Dataverse and Dynamics 365 CRM activity logs from the Microsoft Purview Audit log into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

DataverseActivity Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Tenant Permissions: 'Security Administrator' or 'Global Administrator' on the workspace's tenant.

Micorosft Purview Audit: Microsoft Purview Audit (Standard or Premium) must be activated.

Production Dataverse: Activity logging is available only for Production environments. Other types, such as sandbox, do not support activity logging.

Dataverse Audit Settings: Audit settings must be configured both globally and at the entity/table level. For more information, see Dataverse audit settings.

Setup Instructions:

Connect Microsoft Dataverse audit logs to Microsoft Sentinel

This connector uses the Office Management API to get your Dataverse audit logs. The logs will be stored and processed in your existing Microsoft Sentinel workspace. You can find the data in the DataverseActivity table.

Enable/Disable Connection

Microsoft Defender for Cloud Apps

Supported by: Microsoft Corporation

By connecting with Microsoft Defender for Cloud Apps you will gain visibility into your cloud apps, get sophisticated analytics to identify and combat cyberthreats, and control how your data travels.

Identify shadow IT cloud apps on your network.

Control and limit access based on conditions and session context.

Use built-in or custom policies for data sharing and data loss prevention.

Identify high-risk use and get alerts for unusual user activities with Microsoft behavioral analytics and anomaly detection capabilities, including ransomware activity, impossible travel, suspicious email forwarding rules, and mass download of files.

Mass download of files

Deploy now >

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert No No

McasShadowItReporting No No

Data collection rule support: Not currently supported

Microsoft Defender for Endpoint

Supported by: Microsoft Corporation

Microsoft Defender for Endpoint is a security platform designed to prevent, detect, investigate, and respond to advanced threats. The platform creates alerts when suspicious security events are seen in an organization. Fetch alerts generated in Microsoft Defender for Endpoint to Microsoft Sentinel so that you can effectively analyze security events. You can create rules, build dashboards and author playbooks for immediate response. For more information, see the Microsoft Sentinel documentation >.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Defender for Identity

Supported by: Microsoft Corporation

Connect Microsoft Defender for Identity to gain visibility into the events and user analytics. Microsoft Defender for Identity identifies, detects, and helps you investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. Microsoft Defender for Identity enables SecOp analysts and security professionals struggling to detect advanced attacks in hybrid environments to:

Monitor users, entity behavior, and activities with learning-based analytics

Protect user identities and credentials stored in Active Directory

Identify and investigate suspicious user activities and advanced attacks throughout the kill chain

Provide clear incident information on a simple timeline for fast triage

Try now >

Deploy now >

For more information, see the Microsoft Sentinel documentation >.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Defender for IoT

Supported by: Microsoft Corporation

Gain insights into your IoT security by connecting Microsoft Defender for IoT alerts to Microsoft Sentinel. You can get out-of-the-box alert metrics and data, including alert trends, top alerts, and alert breakdown by severity. You can also get information about the recommendations provided for your IoT hubs including top recommendations and recommendations by severity. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Defender for Office 365 (Preview)

Supported by: Microsoft Corporation

Microsoft Defender for Office 365 safeguards your organization against malicious threats posed by email messages, links (URLs) and collaboration tools. By ingesting Microsoft Defender for Office 365 alerts into Microsoft Sentinel, you can incorporate information about email- and URL-based threats into your broader risk analysis and build response scenarios accordingly.

The following types of alerts will be imported:

A potentially malicious URL click was detected

Email messages containing malware removed after delivery

Email messages containing phish URLs removed after delivery

Email reported by user as malware or phish

Suspicious email sending patterns detected

User restricted from sending email

These alerts can be seen by Office customers in the ** Office Security and Compliance Center**.

For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Defender Threat Intelligence

Supported by: Microsoft Corporation

Microsoft Sentinel provides you the capability to import threat intelligence generated by Microsoft to enable monitoring, alerting and hunting. Use this data connector to import Indicators of Compromise (IOCs) from Microsoft Defender Threat Intelligence (MDTI) into Microsoft Sentinel. Threat indicators can include IP addresses, domains, URLs, and file hashes, etc.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Microsoft Defender XDR

Supported by: Microsoft Corporation

Microsoft Defender XDR is a unified, natively integrated, pre- and post-breach enterprise defense suite that protects endpoint, identity, email, and applications and helps you detect, prevent, investigate, and automatically respond to sophisticated threats.

Microsoft Defender XDR suite includes:

Microsoft Defender for Endpoint

Microsoft Defender for Identity

Microsoft Defender for Office 365

Threat & Vulnerability Management

Microsoft Defender for Cloud Apps

For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityIncident Yes Yes

SecurityAlert Yes Yes

DeviceEvents Yes Yes

EmailEvents Yes Yes

IdentityLogonEvents Yes Yes

CloudAppEvents Yes Yes

AlertEvidence Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Entra ID

Supported by: Microsoft Corporation

Gain insights into Microsoft Entra ID by connecting Audit and Sign-in logs to Microsoft Sentinel to gather insights around Microsoft Entra ID scenarios. You can learn about app usage, conditional access policies, legacy auth relate details using our Sign-in logs. You can get information on your Self Service Password Reset (SSPR) usage, Microsoft Entra ID Management activities like user, group, role, app management using our Audit logs table. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SigninLogs Yes Yes

AuditLogs Yes Yes

AADNonInteractiveUserSignInLogs Yes Yes

AADServicePrincipalSignInLogs Yes Yes

AADManagedIdentitySignInLogs Yes Yes

AADProvisioningLogs Yes Yes

ADFSSignInLogs Yes Yes

AADUserRiskEvents Yes Yes

AADRiskyUsers Yes Yes

NetworkAccessTraffic Yes Yes

AADRiskyServicePrincipals Yes Yes

AADServicePrincipalRiskEvents Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Entra ID Assets

Supported by: Microsoft Corporation

Entra ID assets data connector gives richer insights into activity data by supplementing details with asset information. Data from this connector is used to build data risk graphs in Purview. If you have enabled those graphs, deactivating this Connector will prevent the graphs from being built. Learn about the data risk graph.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Data collection rule support: Not currently supported

Setup Instructions:

Microsoft Entra ID Protection

Supported by: Microsoft Corporation

Microsoft Entra ID Protection provides a consolidated view at risk users, risk events and vulnerabilities, with the ability to remediate risk immediately, and set policies to auto-remediate future events. The service is built on Microsoft’s experience protecting consumer identities and gains tremendous accuracy from the signal from over 13 billion logins a day. Integrate Microsoft Microsoft Entra ID Protection alerts with Microsoft Sentinel to view dashboards, create custom alerts, and improve investigation. For more information, see the Microsoft Sentinel documentation .

Get Microsoft Entra ID Premium P1/P2

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Exchange Admin Audit Logs by Event Logs

Supported by: Community

[Option 1] - Using Azure Monitor Agent - You can stream all Exchange Audit events from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to view dashboards, create custom alerts, and improve investigation. This is used by Microsoft Exchange Security Workbooks to provide security insights of your On-Premises Exchange environment

Log Analytics table(s):

Table DCR support Lake-only ingestion

Event Yes No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 1 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

2. [Option 1] MS Exchange Management Log collection - MS Exchange Admin Audit event logs by Data Collection Rules

The MS Exchange Admin Audit event logs are collected using Data Collection Rules (DCR) and allow to store all Administrative Cmdlets executed in an Exchange environment.

DCR

Data Collection Rules Deployment

Enable data collection rule Microsoft Exchange Admin Audit Events logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template (Prefered)

Use this method for automated deployment of the DCR.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace Name 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCR, Type Event log

From the Azure Portal, navigate to Azure Data collection rules.

Click + Create at the top.

In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR.

In the Resources tab, enter you Exchange Servers.

In 'Collect and deliver', add a Data Source type 'Windows Event logs' and select 'Custom' option, enter 'MSExchange Management' as expression and Add it.

'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Parsers are automatically deployed with the solution. Follow the steps to create the Kusto Functions alias : ExchangeAdminAuditLogs

Parsers are automatically deployed during Solution deployment. If you want to deploy manually, follow the steps below

Manual Parser Deployment

1. Download the Parser file

The latest version of the file ExchangeAdminAuditLogs

2. Create Parser ExchangeAdminAuditLogs function

In 'Logs' explorer of your Microsoft Sentinel's log analytics, copy the content of the file to Log explorer

3. Save Parser ExchangeAdminAuditLogs function

Click on save button. No parameter is needed for this parser. Click save again.

Microsoft Exchange HTTP Proxy Logs

Supported by: Community

[Option 7] - Using Azure Monitor Agent - You can stream HTTP Proxy logs and Security Event logs from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you create custom alerts, and improve investigation. Learn more

Log Analytics table(s):

Table DCR support Lake-only ingestion

ExchangeHttpProxy_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated: Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 7 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

2. [Option 7] HTTP Proxy of Exchange Servers

Select how to stream HTTP Proxy of Exchange Servers

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Message Tracking are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template (Prefered Method)

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

You can change the proposed name of the DCE.

Click Create to deploy.

B. Deploy Data Connection Rule

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

Create Custom Table - Explanation

The Custom Table can't be created using the Azure Portal. You need to use an ARM template, a PowerShell Script or another method described here.

Create Custom Table using an ARM Template

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group, Location and Analytic Workspace Name.

Click Create to deploy.

Create Custom Table using PowerShell in Cloud Shell

From the Azure Portal, open a Cloud Shell.

Copy and paste and Execute the following script in the Cloud Shell to create the table. $tableParams = @' { "properties": { "schema": { "name": "ExchangeHttpProxy_CL", "columns": [ { "name": "AccountForestLatencyBreakup", "type": "string" }, { "name": "ActivityContextLifeTime", "type": "string" }, { "name": "ADLatency", "type": "string" }, { "name": "AnchorMailbox", "type": "string" }, { "name": "AuthenticatedUser", "type": "string" }, { "name": "AuthenticationType", "type": "string" }, { "name": "AuthModulePerfContext", "type": "string" }, { "name": "BackEndCookie", "type": "string" }, { "name": "BackEndGenericInfo", "type": "string" }, { "name": "BackendProcessingLatency", "type": "string" }, { "name": "BackendReqInitLatency", "type": "string" }, { "name": "BackendReqStreamLatency", "type": "string" }, { "name": "BackendRespInitLatency", "type": "string" }, { "name": "BackendRespStreamLatency", "type": "string" }, { "name": "BackEndStatus", "type": "string" }, { "name": "BuildVersion", "type": "string" }, { "name": "CalculateTargetBackEndLatency", "type": "string" }, { "name": "ClientIpAddress", "type": "string" }, { "name": "ClientReqStreamLatency", "type": "string" }, { "name": "ClientRequestId", "type": "string" }, { "name": "ClientRespStreamLatency", "type": "string" }, { "name": "CoreLatency", "type": "string" }, { "name": "DatabaseGuid", "type": "string" }, { "name": "EdgeTraceId", "type": "string" }, { "name": "ErrorCode", "type": "string" }, { "name": "GenericErrors", "type": "string" }, { "name": "GenericInfo", "type": "string" }, { "name": "GlsLatencyBreakup", "type": "string" }, { "name": "HandlerCompletionLatency", "type": "string" }, { "name": "HandlerToModuleSwitchingLatency", "type": "string" }, { "name": "HttpPipelineLatency", "type": "string" }, { "name": "HttpProxyOverhead", "type": "string" }, { "name": "HttpStatus", "type": "string" }, { "name": "IsAuthenticated", "type": "string" }, { "name": "KerberosAuthHeaderLatency", "type": "string" }, { "name": "MajorVersion", "type": "string" }, { "name": "Method", "type": "string" }, { "name": "MinorVersion", "type": "string" }, { "name": "ModuleToHandlerSwitchingLatency", "type": "string" }, { "name": "Organization", "type": "string" }, { "name": "PartitionEndpointLookupLatency", "type": "string" }, { "name": "Protocol", "type": "string" }, { "name": "ProtocolAction", "type": "string" }, { "name": "ProxyAction", "type": "string" }, { "name": "ProxyTime", "type": "string" }, { "name": "RequestBytes", "type": "string" }, { "name": "RequestHandlerLatency", "type": "string" }, { "name": "RequestId", "type": "string" }, { "name": "ResourceForestLatencyBreakup", "type": "string" }, { "name": "ResponseBytes", "type": "string" }, { "name": "RevisionVersion", "type": "string" }, { "name": "RouteRefresherLatency", "type": "string" }, { "name": "RoutingHint", "type": "string" }, { "name": "RoutingLatency", "type": "string" }, { "name": "RoutingStatus", "type": "string" }, { "name": "RoutingType", "type": "string" }, { "name": "ServerHostName", "type": "string" }, { "name": "ServerLocatorHost", "type": "string" }, { "name": "ServerLocatorLatency", "type": "string" }, { "name": "SharedCacheLatencyBreakup", "type": "string" }, { "name": "TargetOutstandingRequests", "type": "string" }, { "name": "TargetServer", "type": "string" }, { "name": "TargetServerVersion", "type": "string" }, { "name": "TotalAccountForestLatency", "type": "string" }, { "name": "TotalGlsLatency", "type": "string" }, { "name": "TotalRequestTime", "type": "string" }, { "name": "TotalResourceForestLatency", "type": "string" }, { "name": "TotalSharedCacheLatency", "type": "string" }, { "name": "UrlHost", "type": "string" }, { "name": "UrlQuery", "type": "string" }, { "name": "UrlStem", "type": "string" }, { "name": "UserADObjectGuid", "type": "string" }, { "name": "UserAgent", "type": "string" }, { "name": "TimeGenerated", "type": "datetime" }, { "name": "FilePath", "type": "string" } ] } } } '@

Copy, Replace, Paste and execute the following parameters with your own values: $SubscriptionID = 'YourGUID' $ResourceGroupName = 'YourResourceGroupName' $WorkspaceName = 'YourWorkspaceName'

Execute the Following Cmdlet to create the table: Invoke-AzRestMethod -Path "/subscriptions/$SubscriptionID/resourcegroups/$ResourceGroupName/providers/microsoft.operationalinsights/workspaces/$WorkspaceName/tables/ExchangeHttpProxy_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.

Click + Create at the top.

In the Basics tab, fill the required fields and give a name to the DCE.

'Make other preferable configuration changes', if needed, then click Create.

B. Create a DCR, Type Custom log

From the Azure Portal, navigate to Azure Data collection rules.

Click on 'Create' button.

On 'Basics' tab, fill the Rule name like DCR-Option7-HTTPProxyLogs, select the 'Data Collection Endpoint' with the previously created endpoint and fill other parameters.

In the Resources tab, add your Exchange Servers.

In Collect and Deliver, add a Data Source type 'Custom Text logs' and enter the following file pattern : 'C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Eas*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ecp*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Oab*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\OwaCalendar*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\PowerShell*.log','C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp*.log'

Put 'ExchangeHttpProxy_CL' in Table Name.

in Transform field, enter the following KQL request : source | extend d = split(RawData,',') | extend DateTime=todatetime(d[0]),RequestId=tostring(d[1]) ,MajorVersion=tostring(d[2]) ,MinorVersion=tostring(d[3]) ,BuildVersion=tostring(d[4]) ,RevisionVersion=tostring(d[5]) ,ClientRequestId=tostring(d[6]) ,Protocol=tostring(d[7]) ,UrlHost=tostring(d[8]) ,UrlStem=tostring(d[9]) ,ProtocolAction=tostring(d[10]) ,AuthenticationType=tostring(d[11]) ,IsAuthenticated=tostring(d[12]) ,AuthenticatedUser=tostring(d[13]) ,Organization=tostring(d[14]) ,AnchorMailbox=tostring(d[15]) ,UserAgent=tostring(d[16]) ,ClientIpAddress=tostring(d[17]) ,ServerHostName=tostring(d[18]) ,HttpStatus=tostring(d[19]) ,BackEndStatus=tostring(d[20]) ,ErrorCode=tostring(d[21]) ,Method=tostring(d[22]) ,ProxyAction=tostring(d[23]) ,TargetServer=tostring(d[24]) ,TargetServerVersion=tostring(d[25]) ,RoutingType=tostring(d[26]) ,RoutingHint=tostring(d[27]) ,BackEndCookie=tostring(d[28]) ,ServerLocatorHost=tostring(d[29]) ,ServerLocatorLatency=tostring(d[30]) ,RequestBytes=tostring(d[31]) ,ResponseBytes=tostring(d[32]) ,TargetOutstandingRequests=tostring(d[33]) ,AuthModulePerfContext=tostring(d[34]) ,HttpPipelineLatency=tostring(d[35]) ,CalculateTargetBackEndLatency=tostring(d[36]) ,GlsLatencyBreakup=tostring(d[37]) ,TotalGlsLatency=tostring(d[38]) ,AccountForestLatencyBreakup=tostring(d[39]) ,TotalAccountForestLatency=tostring(d[40]) ,ResourceForestLatencyBreakup=tostring(d[41]) ,TotalResourceForestLatency=tostring(d[42]) ,ADLatency=tostring(d[43]) ,SharedCacheLatencyBreakup=tostring(d[44]) ,TotalSharedCacheLatency=tostring(d[45]) ,ActivityContextLifeTime=tostring(d[46]) ,ModuleToHandlerSwitchingLatency=tostring(d[47]) ,ClientReqStreamLatency=tostring(d[48]) ,BackendReqInitLatency=tostring(d[49]) ,BackendReqStreamLatency=tostring(d[50]) ,BackendProcessingLatency=tostring(d[51]) ,BackendRespInitLatency=tostring(d[52]) ,BackendRespStreamLatency=tostring(d[53]) ,ClientRespStreamLatency=tostring(d[54]) ,KerberosAuthHeaderLatency=tostring(d[55]) ,HandlerCompletionLatency=tostring(d[56]) ,RequestHandlerLatency=tostring(d[57]) ,HandlerToModuleSwitchingLatency=tostring(d[58]) ,ProxyTime=tostring(d[59]) ,CoreLatency=tostring(d[60]) ,RoutingLatency=tostring(d[61]) ,HttpProxyOverhead=tostring(d[62]) ,TotalRequestTime=tostring(d[63]) ,RouteRefresherLatency=tostring(d[64]) ,UrlQuery=tostring(d[65]) ,BackEndGenericInfo=tostring(d[66]) ,GenericInfo=tostring(d[67]) ,GenericErrors=tostring(d[68]) ,EdgeTraceId=tostring(d[69]) ,DatabaseGuid=tostring(d[70]) ,UserADObjectGuid=tostring(d[71]) ,PartitionEndpointLookupLatency=tostring(d[72]) ,RoutingStatus=tostring(d[73]) | extend TimeGenerated = DateTime | project-away d,RawData,DateTime | project-away d,RawData,DateTime and click on 'Destination'.

In 'Destination', add a destination and select the Workspace where you have previously created the Custom Table

Click on 'Add data source'.

Fill other required parameters and tags and create the DCR

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Microsoft Exchange Logs and Events

Supported by: Community

[Option 2] - Using Azure Monitor Agent - You can stream all Exchange Security & Application Event logs from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to create custom alerts, and improve investigation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Event Yes No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated: Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 2 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

2. [Option 2] Security/Application/System logs of Exchange Servers

The Security/Application/System logs of Exchange Servers are collected using Data Collection Rules (DCR).

Security Event log collection

Data Collection Rules - Security Event logs

Enable data collection rule for Security Logs Security Events logs are collected only from Windows agents.

Add Exchange Servers on Resources tab.

Select Security log level

Common level is the minimum required. Please select 'Common' or 'All Security Events' on DCR definition.

Install Agent: <variable value provided at install time>

Application and System Event log collection

Enable data collection rule

Application and System Events logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template (Prefered method)

Use this method for automated deployment of the DCR.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace Name 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCR, Type Event log

From the Azure Portal, navigate to Azure Data collection rules.

Click + Create at the top.

In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR.

In the Resources tab, enter you Exchange Servers.

In 'Collect and deliver', add a Data Source type 'Windows Event logs' and select 'Basic' option.

For Application, select 'Critical', 'Error' and 'Warning'. For System, select Critical/Error/Warning/Information.

'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Microsoft Exchange Message Tracking Logs

Supported by: Community

[Option 6] - Using Azure Monitor Agent - You can stream all Exchange Message Tracking from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. Those logs can be used to track the flow of messages in your Exchange environment. This data connector is based on the option 6 of the Microsoft Exchange Security wiki.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MessageTrackingLog_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated: Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

This Data Connector is the option 6 of the wiki.

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers Deploy the Azure Arc Agent Learn more

2. Message Tracking of Exchange Servers

Select how to stream Message Tracking of Exchange Servers

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Message Tracking are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

You can change the proposed name of the DCE.

Click Create to deploy.

B. Deploy Data Connection Rule and Custom Table

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

Create Custom Table - Explanation

The Custom Table can't be created using the Azure Portal. You need to use an ARM template, a PowerShell Script or another method described here.

Create Custom Table using an ARM Template

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group, Location and Analytic Workspace Name.

Click Create to deploy.

Create Custom Table using PowerShell in Cloud Shell

From the Azure Portal, open a Cloud Shell.

Copy and paste and Execute the following script in the Cloud Shell to create the table. $tableParams = @' { "properties": { "schema": { "name": "MessageTrackingLog_CL", "columns": [ { "name": "directionality", "type": "string" }, { "name": "reference", "type": "string" }, { "name": "source", "type": "string" }, { "name": "TimeGenerated", "type": "datetime" }, { "name": "clientHostname", "type": "string" }, { "name": "clientIP", "type": "string" }, { "name": "connectorId", "type": "string" }, { "name": "customData", "type": "string" }, { "name": "eventId", "type": "string" }, { "name": "internalMessageId", "type": "string" }, { "name": "logId", "type": "string" }, { "name": "messageId", "type": "string" }, { "name": "messageInfo", "type": "string" }, { "name": "messageSubject", "type": "string" }, { "name": "networkMessageId", "type": "string" }, { "name": "originalClientIp", "type": "string" }, { "name": "originalServerIp", "type": "string" }, { "name": "recipientAddress", "type": "string" }, { "name": "recipientCount", "type": "string" }, { "name": "recipientStatus", "type": "string" }, { "name": "relatedRecipientAddress", "type": "string" }, { "name": "returnPath", "type": "string" }, { "name": "senderAddress", "type": "string" }, { "name": "senderHostname", "type": "string" }, { "name": "serverIp", "type": "string" }, { "name": "sourceContext", "type": "string" }, { "name": "schemaVersion", "type": "string" }, { "name": "messageTrackingTenantId", "type": "string" }, { "name": "totalBytes", "type": "string" }, { "name": "transportTrafficType", "type": "string" }, { "name": "FilePath", "type": "string" } ] } } } '@

Copy, Replace, Paste and execute the following parameters with your own values: $SubscriptionID = 'YourGUID' $ResourceGroupName = 'YourResourceGroupName' $WorkspaceName = 'YourWorkspaceName'

Execute the Following Cmdlet to create the table: Invoke-AzRestMethod -Path "/subscriptions/$SubscriptionID/resourcegroups/$ResourceGroupName/providers/microsoft.operationalinsights/workspaces/$WorkspaceName/tables/MessageTrackingLog_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.

Click + Create at the top.

In the Basics tab, fill the required fields and give a name to the DCE, like ESI-ExchangeServers.

'Make other preferable configuration changes', if needed, then click Create.

B. Create a DCR, Type Custom log

From the Azure Portal, navigate to Azure Data collection rules.

Click on 'Create' button.

On 'Basics' tab, fill the Rule name like DCR-Option6-MessageTrackingLogs, select the 'Data Collection Endpoint' with the previously created endpoint and fill other parameters.

In the Resources tab, add your Exchange Servers.

In Collect and Deliver, add a Data Source type 'Custom Text logs' and enter 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking*.log' in file pattern, 'MessageTrackingLog_CL' in Table Name. 6.in Transform field, enter the following KQL request : source | extend d = split(RawData,',') | extend TimeGenerated =todatetime(d[0]) ,clientIP =tostring(d[1]) ,clientHostname =tostring(d[2]) ,serverIp=tostring(d[3]) ,senderHostname=tostring(d[4]) ,sourceContext=tostring(d[5]) ,connectorId =tostring(d[6]) ,source=tostring(d[7]) ,eventId =tostring(d[8]) ,internalMessageId =tostring(d[9]) ,messageId =tostring(d[10]) ,networkMessageId =tostring(d[11]) ,recipientAddress=tostring(d[12]) ,recipientStatus=tostring(d[13]) ,totalBytes=tostring(d[14]) ,recipientCount=tostring(d[15]) ,relatedRecipientAddress=tostring(d[16]) ,reference=tostring(d[17]) ,messageSubject =tostring(d[18]) ,senderAddress=tostring(d[19]) ,returnPath=tostring(d[20]) ,messageInfo =tostring(d[21]) ,directionality=tostring(d[22]) ,messageTrackingTenantId =tostring(d[23]) ,originalClientIp =tostring(d[24]) ,originalServerIp =tostring(d[25]) ,customData=tostring(d[26]) ,transportTrafficType =tostring(d[27]) ,logId =tostring(d[28]) ,schemaVersion=tostring(d[29]) | project-away d,RawData and click on 'Destination'.

In 'Destination', add a destination and select the Workspace where you have previously created the Custom Table

Click on 'Add data source'.

Fill other required parameters and tags and create the DCR

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Microsoft Power Automate

Supported by: Microsoft Corporation

Power Automate is a Microsoft service that helps users create automated workflows between apps and services to synchronize files, get notifications, collect data, and more. It simplifies task automation, increasing efficiency by reducing manual, repetitive tasks, and enhancing productivity. The Power Automate data connector provides the capability to ingest Power Automate activity logs from the Microsoft Purview Audit log into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PowerAutomateActivity Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Tenant Permissions: 'Security Administrator' or 'Global Administrator' on the workspace's tenant.

Micorosft Purview Audit: Microsoft Purview Audit (Standard or Premium) must be activated.

Setup Instructions:

Connect Microsoft Power Automate audit logs to Microsoft Sentinel

This connector uses the Office Management API to get your Power Automate audit logs. The logs will be stored and processed in your existing Microsoft Sentinel workspace. You can find the data in the PowerAutomateActivity table.

Enable/Disable Connection

Microsoft Power Platform Admin Activity

Supported by: Microsoft Corporation

Microsoft Power Platform is a low-code/no-code suite empowering both citizen and pro developers to streamline business processes by enabling the creation of custom apps, automation of workflows, and data analysis with minimal coding. The Power Platform Admin data connector provides the capability to ingest Power Platform administrator activity logs from the Microsoft Purview Audit log into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PowerPlatformAdminActivity Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Tenant Permissions: 'Security Administrator' or 'Global Administrator' on the workspace's tenant.

Micorosft Purview Audit: Microsoft Purview Audit (Standard or Premium) must be activated.

Setup Instructions:

Connect Microsoft Power Platform Admin Activity audit logs to Microsoft Sentinel

This connector uses the Office Management API to get your Power Platform administrator audit logs. The logs will be stored and processed in your existing Microsoft Sentinel workspace. You can find the data in the PowerPlatformAdminActivity table.

Enable/Disable Connection

Microsoft PowerBI

Supported by: Microsoft Corporation

Microsoft PowerBI is a collection of software services, apps, and connectors that work together to turn your unrelated sources of data into coherent, visually immersive, and interactive insights. Your data may be an Excel spreadsheet, a collection of cloud-based and on-premises hybrid data warehouses, or a data store of some other type. This connector lets you stream PowerBI audit logs into Microsoft Sentinel, allowing you to track user activities in your PowerBI environment. You can filter the audit data by date range, user, dashboard, report, dataset, and activity type.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PowerBIActivity Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Project

Supported by: Microsoft

Microsoft Project (MSP) is a project management software solution. Depending on your plan, Microsoft Project lets you plan projects, assign tasks, manage resources, create reports and more. This connector allows you to stream your Azure Project audit logs into Microsoft Sentinel in order to track your project activities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ProjectActivity Yes Yes

Data collection rule support: Workspace transform DCR

Microsoft Purview

Supported by: Microsoft Corporation

Connect to Microsoft Purview to enable data sensitivity enrichment of Microsoft Sentinel. Data classification and sensitivity label logs from Microsoft Purview scans can be ingested and visualized through workbooks, analytical rules, and more. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PurviewDataSensitivityLogs Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Microsoft Purview to Microsoft Sentinel

Within the Azure Portal, navigate to your Purview resource:

In the search bar, search for Purview accounts.

Select the specific account that you would like to be set up with Sentinel.

Inside your Microsoft Purview resource: 3. Select Diagnostic Settings. 4. Select + Add diagnostic setting. 5. In the Diagnostic setting blade:

Select the Log Category as DataSensitivityLogEvent.

Select Send to Log Analytics.

Chose the log destination workspace. This should be the same workspace that is used by Microsoft Sentinel.

Click Save.

Microsoft Purview Information Protection

Supported by: Microsoft Corporation

Microsoft Purview Information Protection helps you discover, classify, protect, and govern sensitive information wherever it lives or travels. Using these capabilities enable you to know your data, identify items that are sensitive and gain visibility into how they are being used to better protect your data. Sensitivity labels are the foundational capability that provide protection actions, applying encryption, access restrictions and visual markings. Integrate Microsoft Purview Information Protection logs with Microsoft Sentinel to view dashboards, create custom alerts and improve investigation. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MicrosoftPurviewInformationProtection Yes Yes

Data collection rule support: Workspace transform DCR

Mimecast Audit

Supported by: Mimecast

The data connector for Mimecast Audit provides customers with the visibility into security events related to audit and authentication events within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into user activity, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.
The Mimecast products included within the connector are: Audit

Log Analytics table(s):

Table DCR support Lake-only ingestion

Audit_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: See the documentation to learn more about API on the Rest API reference

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Mimecast API authorization key(s) or Token, readily available.

STEP 3 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 4 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TenableVM Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 5 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

Deploy the Mimecast Audit Data Connector:

Use this method for automated deployment of the Mimecast Audit Data connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Region.

Enter the below information :

a. Location - The location in which the data collection rules and data collection endpoints should be deployed

b. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

c. AzureClientID - Enter Azure Client ID that you have created during app registration

d. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

e. AzureTenantID - Enter Azure Tenant ID of your Azure Active Directory

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. MimecastBaseURL - Enter Base URL of Mimecast API 2.0 (e.g. https://api.services.mimecast.com)

h. MimecastClientID - Enter Mimecast Client ID for authentication

i. MimecastClientSecret - Enter Mimecast Client Secret for authentication

j. MimecastAuditTableName - Enter name of the table used to store Audit data. Default is 'Audit'

k. StartDate - Enter the start date in the 'yyyy-mm-dd' format. If you do not provide a date, data from the last 60 days will be fetched automatically. Ensure that the date is in the past and properly formatted

l. Schedule - Please enter a valid Quartz cron-expression. (Example: 0 0 */1 * * *) Do not keep the value empty, minimum value is 10 minutes

m. LogLevel - Please add log level or log severity value. By default it is set to INFO

n. AppInsightsWorkspaceResourceId - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Mimecast Audit & Authentication (using Azure Functions)

Supported by: Mimecast

The data connector for Mimecast Audit & Authentication provides customers with the visibility into security events related to audit and authentication events within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into user activity, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.
The Mimecast products included within the connector are: Audit & Authentication

Log Analytics table(s):

Table DCR support Lake-only ingestion

MimecastAudit_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Mimecast API credentials: You need to have the following pieces of information to configure the integration:

mimecastEmail: Email address of a dedicated Mimecast admin user

mimecastPassword: Password for the dedicated Mimecast admin user

mimecastAppId: API Application Id of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAppKey: API Application Key of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast admin user

mimecastSecretKey: Secret Key for the dedicated Mimecast admin user

mimecastBaseURL: Mimecast Regional API Base URL

The Mimecast Application Id, Application Key, along with the Access Key and Secret keys for the dedicated Mimecast admin user are obtainable via the Mimecast Administration Console: Administration | Services | API and Platform Integrations.

The Mimecast API Base URL for each region is documented here: https://integrations.mimecast.com/documentation/api-overview/global-base-urls/

Resource group: You need to have a resource group created with a subscription you are going to use.

Functions app: You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Mimecast API authorization key(s) or Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Deploy the Mimecast Audit & Authentication Data Connector:

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the following fields:

appName: Unique string that will be used as id for the app in Azure platform

objectId: Azure portal ---> Azure Active Directory ---> more info ---> Profile -----> Object ID

appInsightsLocation(default): westeurope

mimecastEmail: Email address of dedicated user for this integraion

mimecastPassword: Password for dedicated user

mimecastAppId: Application Id from the Microsoft Sentinel app registered with Mimecast

mimecastAppKey: Application Key from the Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast user

mimecastSecretKey: Secret Key for dedicated Mimecast user

mimecastBaseURL: Regional Mimecast API Base URL

activeDirectoryAppId: Azure portal ---> App registrations ---> [your_app] ---> Application ID

activeDirectoryAppSecret: Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> [your_app_secret]

workspaceId: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Workspace ID (or you can copy workspaceId from above)

workspaceKey: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Primary Key (or you can copy workspaceKey from above)

AppInsightsWorkspaceResourceID : Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Properties ---> Resource ID

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Go to Azure portal ---> Resource groups ---> [your_resource_group] ---> [appName](type: Storage account) ---> Storage Explorer ---> BLOB CONTAINERS ---> Audit checkpoints ---> Upload and create empty file on your machine named checkpoint.txt and select it for upload (this is done so that date_range for SIEM logs is stored in consistent state)

Mimecast Awareness Training

Supported by: Mimecast

The data connector for Mimecast Awareness Training provides customers with the visibility into security events related to the Targeted Threat Protection inspection technologies within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.
The Mimecast products included within the connector are:

Performance Details

Safe Score Details

User Data

Watchlist Details

Log Analytics table(s):

Table DCR support Lake-only ingestion

Awareness_Performance_Details_CL Yes Yes

Awareness_SafeScore_Details_CL Yes Yes

Awareness_User_Data_CL Yes Yes

Awareness_Watchlist_Details_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: See the documentation to learn more about API on the Rest API reference

Setup Instructions:

Resource group

You need to have a resource group created with a subscription you are going to use.

Functions app

You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

Entra Object ID

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of Mimecast Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 2 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of Mimecast Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of Mimecast Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 3 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

STEP 4 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Mimecast API authorization key(s) or Token, readily available.

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Mimecast Awareness Training Data connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Region.

Enter the below information :

a. Location - The location in which the data collection rules and data collection endpoints should be deployed

b. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

c. AzureClientID - Enter Azure Client ID that you have created during app registration

d. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

e. AzureTenantID - Enter Azure Tenant ID of your Azure Active Directory

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. MimecastBaseURL - Enter Base URL of Mimecast API 2.0 (e.g. https://api.services.mimecast.com)

h. MimecastClientID - Enter Mimecast Client ID for authentication

i. MimecastClientSecret - Enter Mimecast Client Secret for authentication

j. MimecastAwarenessPerformanceDetailsTableName - Enter name of the table used to store Awareness Performance Details data. Default is 'Awareness_Performance_Details'

k. MimecastAwarenessUserDataTableName - Enter name of the table used to store Awareness User Data data. Default is 'Awareness_User_Data'

l. MimecastAwarenessWatchlistDetailsTableName - Enter name of the table used to store Awareness Watchlist Details data. Default is 'Awareness_Watchlist_Details'

m. MimecastAwarenessSafeScoreDetailsTableName - Enter name of the table used to store Awareness SafeScore Details data. Default is 'Awareness_SafeScore_Details'

n. StartDate - Enter the start date in the 'yyyy-mm-dd' format. If you do not provide a date, data from the last 60 days will be fetched automatically. Ensure that the date is in the past and properly formatted

o. Schedule - Please enter a valid Quartz cron-expression. (Example: 0 0 */1 * * *) Do not keep the value empty, minimum value is 10 minutes

p. LogLevel - Please add log level or log severity value. By default it is set to INFO

q. AppInsightsWorkspaceResourceId - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Mimecast Cloud Integrated

Supported by: Mimecast

The data connector for Mimecast Cloud Integrated provides customers with the visibility into security events related to the Cloud Integrated inspection technologies within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Cloud_Integrated_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: See the documentation to learn more about API on the Rest API reference

Setup Instructions:

Resource group

You need to have a resource group created with a subscription you are going to use.

Functions app

You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Mimecast API authorization key(s) or Token, readily available.

STEP 3 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 4 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TenableVM Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 5 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Mimecast Cloud Integrated Data connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Region.

Enter the below information :

a. Location - The location in which the data collection rules and data collection endpoints should be deployed

b. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

c. AzureClientID - Enter Azure Client ID that you have created during app registration

d. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

e. AzureTenantID - Enter Azure Tenant ID of your Azure Active Directory

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. MimecastBaseURL - Enter Base URL of Mimecast API 2.0 (e.g. https://api.services.mimecast.com)

h. MimecastClientID - Enter Mimecast Client ID for authentication

i. MimecastClientSecret - Enter Mimecast Client Secret for authentication

j. MimecastCITableName - Enter name of the table used to store Cloud Integrated data. Default is 'Cloud_Integrated'

k. StartDate - Enter the start date in the 'yyyy-mm-dd' format. If you do not provide a date, data from the last 60 days will be fetched automatically. Ensure that the date is in the past and properly formatted

l. Schedule - Please enter a valid Quartz cron-expression. (Example: 0 0 */1 * * *) Do not keep the value empty, minimum value is 10 minutes

m. LogLevel - Please add log level or log severity value. By default it is set to INFO

n. AppInsightsWorkspaceResourceId - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Mimecast Intelligence for Microsoft - Microsoft Sentinel (using Azure Functions)

Supported by: Mimecast

The data connector for Mimecast Intelligence for Microsoft provides regional threat intelligence curated from Mimecast’s email inspection technologies with pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times.
Mimecast products and features required:

Mimecast Secure Email Gateway

Mimecast Threat Intelligence

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Mimecast API credentials: You need to have the following pieces of information to configure the integration:

mimecastEmail: Email address of a dedicated Mimecast admin user

mimecastPassword: Password for the dedicated Mimecast admin user

mimecastAppId: API Application Id of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAppKey: API Application Key of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast admin user

mimecastSecretKey: Secret Key for the dedicated Mimecast admin user

mimecastBaseURL: Mimecast Regional API Base URL

The Mimecast Application Id, Application Key, along with the Access Key and Secret keys for the dedicated Mimecast admin user are obtainable via the Mimecast Administration Console: Administration | Services | API and Platform Integrations.

The Mimecast API Base URL for each region is documented here: https://integrations.mimecast.com/documentation/api-overview/global-base-urls/

Resource group: You need to have a resource group created with a subscription you are going to use.

Functions app: You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Mimecast API authorization key(s) or Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Enable Mimecast Intelligence for Microsoft - Microsoft Sentinel Connector:

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the following fields:

appName: Unique string that will be used as id for the app in Azure platform

objectId: Azure portal ---> Azure Active Directory ---> more info ---> Profile -----> Object ID

appInsightsLocation(default): westeurope

mimecastEmail: Email address of dedicated user for this integraion

mimecastPassword: Password for dedicated user

mimecastAppId: Application Id from the Microsoft Sentinel app registered with Mimecast

mimecastAppKey: Application Key from the Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast user

mimecastSecretKey: Secret Key for dedicated Mimecast user

mimecastBaseURL: Regional Mimecast API Base URL

activeDirectoryAppId: Azure portal ---> App registrations ---> [your_app] ---> Application ID

activeDirectoryAppSecret: Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> [your_app_secret]

workspaceId: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Workspace ID (or you can copy workspaceId from above)

workspaceKey: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Primary Key (or you can copy workspaceKey from above)

AppInsightsWorkspaceResourceID : Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Properties ---> Resource ID

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Go to Azure portal ---> Resource groups ---> [your_resource_group] ---> [appName](type: Storage account) ---> Storage Explorer ---> BLOB CONTAINERS ---> TIR checkpoints ---> Upload and create empty file on your machine named checkpoint.txt and select it for upload (this is done so that date_range for TIR logs is stored in consistent state)

Additional configuration:

Connect to a Threat Intelligence Platforms Data Connector. Follow instructions on the connector page and then click connect button.

Mimecast Secure Email Gateway

Supported by: Mimecast

The data connector for Mimecast Secure Email Gateway allows easy log collection from the Secure Email Gateway to surface email insight and user activity within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities. Mimecast products and features required:

Mimecast Cloud Gateway

Mimecast Data Leak Prevention

Log Analytics table(s):

Table DCR support Lake-only ingestion

Seg_Cg_CL Yes Yes

Seg_Dlp_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: See the documentation to learn more about API on the Rest API reference

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

**STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Mimecast API authorization key(s) or Token, readily available.

STEP 3 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 4 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TenableVM Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 5 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

Deploy the Mimecast Secure Email Gateway Data Connector:

Use this method for automated deployment of the Mimecast Secure Email Gateway Data connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

SSelect the preferred Subscription, Resource Group and Region.

Enter the below information :

a. Location - The location in which the data collection rules and data collection endpoints should be deployed

b. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

c. AzureClientID - Enter Azure Client ID that you have created during app registration

d. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

e. AzureTenantID - Enter Azure Tenant ID of your Azure Active Directory

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. MimecastBaseURL - Enter Base URL of Mimecast API 2.0 (e.g. https://api.services.mimecast.com)

h. MimecastClientID - Enter Mimecast Client ID for authentication

i. MimecastClientSecret - Enter Mimecast Client Secret for authentication

j. MimecastCGTableName - Enter name of the table used to store CG data. Default is 'Seg_Cg'

k. MimecastDLPTableName - Enter name of the table used to store DLP data. Default is 'Seg_Dlp'

l. StartDate - Enter the start date in the 'yyyy-mm-dd' format. If you do not provide a date, data from the last 60 days will be fetched automatically. Ensure that the date is in the past and properly formatted

m. Schedule - Please enter a valid Quartz cron-expression. (Example: 0 0 */1 * * *) Do not keep the value empty, minimum value is 10 minutes

n. LogLevel - Please add log level or log severity value. By default it is set to INFO

o. AppInsightsWorkspaceResourceId - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Mimecast Secure Email Gateway (using Azure Functions)

Supported by: Mimecast

The data connector for Mimecast Secure Email Gateway allows easy log collection from the Secure Email Gateway to surface email insight and user activity within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities. Mimecast products and features required:

Mimecast Secure Email Gateway

Mimecast Data Leak Prevention

Log Analytics table(s):

Table DCR support Lake-only ingestion

MimecastSIEM_CL No No

MimecastDLP_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Mimecast API credentials: You need to have the following pieces of information to configure the integration:

mimecastEmail: Email address of a dedicated Mimecast admin user

mimecastPassword: Password for the dedicated Mimecast admin user

mimecastAppId: API Application Id of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAppKey: API Application Key of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast admin user

mimecastSecretKey: Secret Key for the dedicated Mimecast admin user

mimecastBaseURL: Mimecast Regional API Base URL

The Mimecast Application Id, Application Key, along with the Access Key and Secret keys for the dedicated Mimecast admin user are obtainable via the Mimecast Administration Console: Administration | Services | API and Platform Integrations.

The Mimecast API Base URL for each region is documented here: https://integrations.mimecast.com/documentation/api-overview/global-base-urls/

Resource group: You need to have a resource group created with a subscription you are going to use.

Functions app: You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Mimecast API authorization key(s) or Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Deploy the Mimecast Secure Email Gateway Data Connector:

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the following fields:

appName: Unique string that will be used as id for the app in Azure platform

objectId: Azure portal ---> Azure Active Directory ---> more info ---> Profile -----> Object ID

appInsightsLocation(default): westeurope

mimecastEmail: Email address of dedicated user for this integraion

mimecastPassword: Password for dedicated user

mimecastAppId: Application Id from the Microsoft Sentinel app registered with Mimecast

mimecastAppKey: Application Key from the Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast user

mimecastSecretKey: Secret Key for dedicated Mimecast user

mimecastBaseURL: Regional Mimecast API Base URL

activeDirectoryAppId: Azure portal ---> App registrations ---> [your_app] ---> Application ID

activeDirectoryAppSecret: Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> [your_app_secret]

workspaceId: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Workspace ID (or you can copy workspaceId from above)

workspaceKey: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Primary Key (or you can copy workspaceKey from above)

AppInsightsWorkspaceResourceID : Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Properties ---> Resource ID

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Go to Azure portal ---> Resource groups ---> [your_resource_group] ---> [appName](type: Storage account) ---> Storage Explorer ---> BLOB CONTAINERS ---> SIEM checkpoints ---> Upload and create empty file on your machine named checkpoint.txt, dlp-checkpoint.txt and select it for upload (this is done so that date_range for SIEM logs is stored in consistent state)

Mimecast Targeted Threat Protection

Supported by: Mimecast

The data connector for Mimecast Targeted Threat Protection provides customers with the visibility into security events related to the Targeted Threat Protection inspection technologies within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.
The Mimecast products included within the connector are:

URL Protect

Impersonation Protect

Attachment Protect

Log Analytics table(s):

Table DCR support Lake-only ingestion

Ttp_Url_CL Yes Yes

Ttp_Attachment_CL Yes Yes

Ttp_Impersonation_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: See the documentation to learn more about API on the Rest API reference

Setup Instructions:

Resource group

You need to have a resource group created with a subscription you are going to use.

Functions app

You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of Mimecast Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 2 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of Mimecast Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of Mimecast Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 3 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

STEP 4 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Mimecast API authorization key(s) or Token, readily available.

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Mimecast Targeted Threat Protection Data connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Region.

Enter the below information :

a. Location - The location in which the data collection rules and data collection endpoints should be deployed

b. WorkspaceName - Enter Microsoft Sentinel Workspace Name of Log Analytics workspace

c. AzureClientID - Enter Azure Client ID that you have created during app registration

d. AzureClientSecret - Enter Azure Client Secret that you have created during creating the client secret

e. AzureTenantID - Enter Azure Tenant ID of your Azure Active Directory

f. AzureEntraObjectID - Enter Object id of your Microsoft Entra App

g. MimecastBaseURL - Enter Base URL of Mimecast API 2.0 (e.g. https://api.services.mimecast.com)

h. MimecastClientID - Enter Mimecast Client ID for authentication

i. MimecastClientSecret - Enter Mimecast Client Secret for authentication

j. StartDate - Enter the start date in the 'yyyy-mm-dd' format. If you do not provide a date, data from the last 60 days will be fetched automatically. Ensure that the date is in the past and properly formatted

k. MimecastTTPAttachmentTableName - Enter name of the table used to store TTP Attachment data. Default is 'Ttp_Attachment'

l. MimecastTTPImpersonationTableName - Enter name of the table used to store TTP Impersonation data. Default is 'Ttp_Impersonation'

m. MimecastTTPUrlTableName - Enter name of the table used to store TTP Attachment data. Default is 'Ttp_Url'

n. Schedule - Please enter a valid Quartz cron-expression. (Example: 0 0 */1 * * *) Do not keep the value empty, minimum value is 10 minutes

l. LogLevel - Please add log level or log severity value. By default it is set to INFO

o. AppInsightsWorkspaceResourceId - Migrate Classic Application Insights to Log Analytic Workspace which is retiring by 29 Febraury 2024. Use 'Log Analytic Workspace-->Properties' blade having 'Resource ID' property value. This is a fully qualified resourceId which is in format '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}'

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Mimecast Targeted Threat Protection (using Azure Functions)

Supported by: Mimecast

The data connector for Mimecast Targeted Threat Protection provides customers with the visibility into security events related to the Targeted Threat Protection inspection technologies within Microsoft Sentinel. The data connector provides pre-created dashboards to allow analysts to view insight into email based threats, aid in incident correlation and reduce investigation response times coupled with custom alert capabilities.
The Mimecast products included within the connector are:

URL Protect

Impersonation Protect

Attachment Protect

Log Analytics table(s):

Table DCR support Lake-only ingestion

MimecastTTPUrl_CL No No

MimecastTTPAttachment_CL No No

MimecastTTPImpersonation_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: You need to have the following pieces of information to configure the integration:

mimecastEmail: Email address of a dedicated Mimecast admin user

mimecastPassword: Password for the dedicated Mimecast admin user

mimecastAppId: API Application Id of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAppKey: API Application Key of the Mimecast Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast admin user

mimecastSecretKey: Secret Key for the dedicated Mimecast admin user

mimecastBaseURL: Mimecast Regional API Base URL

The Mimecast Application Id, Application Key, along with the Access Key and Secret keys for the dedicated Mimecast admin user are obtainable via the Mimecast Administration Console: Administration | Services | API and Platform Integrations.

The Mimecast API Base URL for each region is documented here: https://integrations.mimecast.com/documentation/api-overview/global-base-urls/

Setup Instructions:

Resource group

You need to have a resource group created with a subscription you are going to use.

Functions app

You need to have an Azure App registered for this connector to use

Application Id

Tenant Id

Client Id

Client Secret

NOTE: This connector uses Azure Functions to connect to a Mimecast API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Configuration:

STEP 1 - Configuration steps for the Mimecast API

Go to Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> New client secret and create a new secret (save the Value somewhere safe right away because you will not be able to preview it later)

STEP 2 - Deploy Mimecast API Connector

IMPORTANT: Before deploying the Mimecast API connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Mimecast API authorization key(s) or Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Deploy the Mimecast Targeted Threat Protection Data Connector:

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the following fields:

appName: Unique string that will be used as id for the app in Azure platform

objectId: Azure portal ---> Azure Active Directory ---> more info ---> Profile -----> Object ID

appInsightsLocation(default): westeurope

mimecastEmail: Email address of dedicated user for this integraion

mimecastPassword: Password for dedicated user

mimecastAppId: Application Id from the Microsoft Sentinel app registered with Mimecast

mimecastAppKey: Application Key from the Microsoft Sentinel app registered with Mimecast

mimecastAccessKey: Access Key for the dedicated Mimecast user

mimecastSecretKey: Secret Key for dedicated Mimecast user

mimecastBaseURL: Regional Mimecast API Base URL

activeDirectoryAppId: Azure portal ---> App registrations ---> [your_app] ---> Application ID

activeDirectoryAppSecret: Azure portal ---> App registrations ---> [your_app] ---> Certificates & secrets ---> [your_app_secret]

workspaceId: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Workspace ID (or you can copy workspaceId from above)

workspaceKey: Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Agents ---> Primary Key (or you can copy workspaceKey from above)

AppInsightsWorkspaceResourceID : Azure portal ---> Log Analytics Workspaces ---> [Your workspace] ---> Properties ---> Resource ID

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Go to Azure portal ---> Resource groups ---> [your_resource_group] ---> [appName](type: Storage account) ---> Storage Explorer ---> BLOB CONTAINERS ---> TTP checkpoints ---> Upload and create empty files on your machine named attachment-checkpoint.txt, impersonation-checkpoint.txt, url-checkpoint.txt and select them for upload (this is done so that date_range for TTP logs are stored in consistent state)

MISP2Sentinel

Supported by: Community

This solution installs the MISP2Sentinel connector that allows you to automatically push threat indicators from MISP to Microsoft Sentinel via the Upload Indicators REST API. After installing the solution, configure and enable this data connector by following guidance in Manage solution view.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Setup Instructions:

Installation and setup instructions

Use the documentation from this GitHub repository to install and configure the MISP to Microsoft Sentinel connector:

https://github.com/cudeso/misp2sentinel

MongoDB Atlas Logs

Supported by: MongoDB

The MongoDBAtlas Logs connector gives the capability to upload MongoDB Atlas database logs into Microsoft Sentinel through the MongoDB Atlas Administration API. Refer to the API documentation for more information. The connector provides the ability to get a range of database log messages for the specified hosts and specified project.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MDBALogTable_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: MongoDB Atlas service account Client ID and Client Secret are required. For more information, see creating a service account

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to 'MongoDB Atlas' to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Ensure the workspace is added to Microsoft Sentinel before deploying the connector.

STEP 1 - Configuration steps for the 'MongoDB Atlas Administration API'

Follow these instructions to create a MongoDB Atlas service account.

Copy the Client ID and Client Secret you created, also the Group ID (Project) and each Cluster ID (Hostname) required for later steps.

Refer MongoDB Atlas API documentation for more details.

The client secret can be passed into the connector via an Azure key vault or directly into the connector.

If you want to use the key vault option create a key vault, using a Vault Access Policy, with a secret named mongodb-client-secret and your client secret saved as the secret value.

STEP 2 - Deploy the 'MongoDB Atlas Logs' connector and the associated Azure Function

Click the Deploy to Azure button below.

portal.azure.com

STEP 3 - Set the connector parameters

Select the preferred Subscription and an existing Resource Group.

Enter an existing Log Analytics Workspace Resource ID belonging to the resource group.

Click Next

Enter the MongoDB Group ID, a list of up to 10 MongoDB Cluster IDs, each on a separate line, and MongoDB Client ID.

Choose for Authentication Method either Client Secret and copy in your client secret value or Key Vault and copy in the name of your key vault. Click Next

Review the MongoDB filters. Select logs from at least one category. Click Next

Review the schedule. Click Next

Review the settings then click Create.

MuleSoft Cloudhub (using Azure Functions)

Supported by: Microsoft Corporation

The MuleSoft Cloudhub data connector provides the capability to retrieve logs from Cloudhub applications using the Cloudhub API and more events into Microsoft Sentinel through the REST API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

MuleSoft_Cloudhub_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: MuleSoftEnvId, MuleSoftAppName, MuleSoftUsername and MuleSoftPassword are required for making API calls.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Azure Blob Storage API to pull logs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected MuleSoftCloudhub which is deployed with the Microsoft Sentinel Solution.

Note: This data connector fetch only the logs of the CloudHub application using Platform API and not of CloudHub 2.0 application

STEP 1 - Configuration steps for the MuleSoft Cloudhub API

Follow the instructions to obtain the credentials.

Obtain the MuleSoftEnvId, MuleSoftAppName, MuleSoftUsername and MuleSoftPassword using the documentation.

Save credentials for using in the data connector.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the MuleSoft Cloudhub data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the MuleSoft Cloudhub data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the MuleSoftEnvId, MuleSoftAppName, MuleSoftUsername and MuleSoftPassword and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the MuleSoft Cloudhub data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. MuleSoftXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): MuleSoftEnvId MuleSoftAppName MuleSoftUsername MuleSoftPassword WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

NC Protect

Supported by: archTIS

NC Protect Data Connector (archtis.com) provides the capability to ingest user activity logs and events into Microsoft Sentinel. The connector provides visibility into NC Protect user activity logs and events in Microsoft Sentinel to improve monitoring and investigation capabilities

Log Analytics table(s):

Table DCR support Lake-only ingestion

NCProtectUAL_CL No No

Data collection rule support: Not currently supported

Prerequisites:

NC Protect: You must have a running instance of NC Protect for O365. Please contact us.

Setup Instructions:

Install NC Protect into your Azure Tenancy

Log into the NC Protect Administration site

From the left hand navigation menu, select General -> User Activity Monitoring

Tick the checkbox to Enable SIEM and click the Configure button

Select Microsoft Sentinel as the Application and complete the configuration using the information below

Click Save to activate the connection

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Netskope Alerts and Events

Supported by: Netskope

Netskope Security Alerts and Events

Log Analytics table(s):

Table DCR support Lake-only ingestion

NetskopeAlerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Netskope organisation url: The Netskope data connector requires you to provide your organisation url. You can find your organisation url by signing into the Netskope portal.

Netskope API key: The Netskope data connector requires you to provide a valid API key. You can create one by following the Netskope documentation.

Setup Instructions:

STEP 1 - Create a Netskope API key.

Follow the Netskope documentation for guidance on this step.

STEP 2 - Enter your Netskope product Details

Enter your Netskope organisation url & API Token below:

Organisation Url: (Enter your organisation url)

API Key: (Enter your API Key) OPTIONAL: Specify the Index the API uses.

Configuring the index is optional and only required in advanced scenario's. Netskope uses an index to retrieve events. In some advanced cases (consuming the event in multiple Microsoft Sentinel workspaces, or pre-fatiguing the index to only retrieve recent data), a customer might want to have direct control over the index.

Index: (NetskopeCCF)

STEP 3 - Click Connect

Verify all fields above were filled in correctly. Press the Connect to connect Netskope to Microsoft Sentinel.

Enable/Disable Connection

Netskope Data Connector

Supported by: Netskope

The Netskope data connector provides the following capabilities:

NetskopeToAzureStorage :

Get the Netskope Alerts and Events data from Netskope and ingest to Azure storage. 2. StorageToSentinel :

Get the Netskope Alerts and Events data from Azure storage and ingest to custom log table in log analytics workspace. 3. WebTxMetrics :

Get the WebTxMetrics data from Netskope and ingest to custom log table in log analytics workspace.

For more details of REST APIs refer to the below documentations:

Netskope API documentation:

https://docs.netskope.com/en/netskope-help/admin-console/rest-api/rest-api-v2-overview-312207/ 2. Azure storage documentation: /azure/storage/common/storage-introduction 3. Microsoft log analytic documentation: /azure/azure-monitor/logs/log-analytics-overview

Log Analytics table(s):

Table DCR support Lake-only ingestion

alertscompromisedcredentialdata_CL No No

alertsctepdata_CL No No

alertsdlpdata_CL No No

alertsmalsitedata_CL No No

alertsmalwaredata_CL No No

alertspolicydata_CL No No

alertsquarantinedata_CL No No

alertsremediationdata_CL No No

alertssecurityassessmentdata_CL No No

alertsubadata_CL No No

eventsapplicationdata_CL No No

eventsauditdata_CL No No

eventsconnectiondata_CL No No

eventsincidentdata_CL No No

eventsnetworkdata_CL No No

eventspagedata_CL No No

Netskope_WebTx_metrics_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in azure active directory() and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: Netskope Tenant and Netskope API Token is required. See the documentation to learn more about API on the Rest API reference

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Netskope APIs to pull its Alerts and Events data into custom log table. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of the TriggersSync playbook.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 2 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TriggersSync playbook. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TriggersSync playbook.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 3 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.

Go to Access control (IAM) from left panel.

Click on Add, and then select Add role assignment.

Select Contributor as role and click on next.

In Assign access to, select User, group, or service principal.

Click on add members and type your app name that you have created and select it.

Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 4 - Steps to create/get Credentials for the Netskope account

Follow the steps in this section to create/get Netskope Hostname and Netskope API Token:

Login to your Netskope Tenant and go to the Settings menu on the left navigation bar.

Click on Tools and then REST API v2

Now, click on the new token button. Then it will ask for token name, expiration duration and the endpoints that you want to fetch data from.

Once that is done click the save button, the token will be generated. Copy the token and save at a secure place for further usage.

STEP 5 - Steps to create the azure functions for Netskope Alerts and Events Data Collection

IMPORTANT: Before deploying Netskope data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.., as well as the Netskope API Authorization Key(s).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Using the ARM template deploy the function apps for ingestion of Netskope events and alerts data to Sentinel.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the below information : Netskope HostName Netskope API Token Select Yes in Alerts and Events types dropdown for that endpoint you want to fetch Alerts and Events Log Level Workspace ID Workspace Key

Click on Review+Create.

Then after validation click on Create to deploy.

Netskope Web Transaction Connector (via Blob Storage)

Supported by: Netskope

The Netskope Web Transaction connector ingests web transaction logs from Netskope Log Streaming into Microsoft Sentinel via Azure Blob Storage using the Codeless Connector Framework (CCF).

Log Analytics table(s):

Table DCR support Lake-only ingestion

NetskopeWebTransactions_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Subscription permissions: You need permissions to create the data flow resources:

storage queues (notification queue and dead-letter queue)

event grid topic and subscription (to send 'blob created event' notifications to the notification queue)

role assignments (to grant access for Microsoft Sentinel app to the blob container and the storage queues.)

Storage Account Network Configuration: Network restrictions (firewall/IP rules) on the Azure Blob Storage account are not supported for this connector due to Azure Storage firewall restrictions and limitations:

IP network rules haveno effecton requests originating from the same Azure region as the storage account.

IP network rulescannot restrictaccess to Azure services deployed in the same region, as these services use private Azure IP addresses for communication.

Virtual network service endpoint rules do not apply to clients in a paired region.

Ensure the storage account's Networking blade is set to Enabled from all networks.

Storage Account Role Assignments: The following Azure RBAC roles must be assigned to the Microsoft Sentinel enterprise application service principal (displayed below) on the Storage Account that contains your blob container:

Storage Blob Data Contributor — required for reading blob data from the container.

Storage Queue Data Contributor — required for managing notification and dead-letter queue messages.

To assign these roles: navigate to the Storage Account → Access Control (IAM) → Add role assignment, search for the service principal ID shown below, and assign both roles.

Collecting data from Netskope to your blob container: Follow the steps in the Netskope Log Streaming documentation to configure Netskope to stream Web Transaction logs to your Azure Blob Storage container.

Setup Instructions:

Connect Netskope WebTx Logs to Microsoft Sentinel

To enable the Netskope WebTx Logs for Microsoft Sentinel, provide the required information below and click on Connect.

The blob container URL you want to collect data from:

The blobs folder name in the container. Optional.:

The blob container's storage account location:

The blob container's storage account resource group name:

The blob container's storage account subscription id:

The event grid topic name of the blob container's storage account if exist. else keep empty.:

Enable/Disable Connection

Netskope Web Transactions Data Connector

Supported by: Netskope

The Netskope Web Transactions data connector provides the functionality of a docker image to pull the Netskope Web Transactions data from google pubsublite, process the data and ingest the processed data to Log Analytics. As part of this data connector two tables will be formed in Log Analytics, one for Web Transactions data and other for errors encountered during execution.

For more details related to Web Transactions refer to the below documentation:

Netskope Web Transactions documentation:

https://docs.netskope.com/en/netskope-help/data-security/transaction-events/netskope-transaction-events/

Log Analytics table(s):

Table DCR support Lake-only ingestion

NetskopeWebtxData_CL No No

NetskopeWebtxErrors_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in Microsoft Entra ID and assign role of contributor to app in resource group.

Microsoft.Compute permissions: Read and write permissions to Azure VMs is required. For more information, see Azure VMs.

TransactionEvents Credentials and Permissions: Netskope Tenant and Netskope API Token is required. For more information, see Transaction Events.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Setup Instructions:

NOTE: This connector provides the functionality of ingesting Netskope Web Transactions data using a docker image to be deployed on a virtual machine (Either Azure VM/On Premise VM). Check the Azure VM pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Steps to create/get Credentials for the Netskope account

Follow the steps in this section to create/get Netskope Hostname and Netskope API Token:

Login to your Netskope Tenant and go to the Settings menu on the left navigation bar.

Click on Tools and then REST API v2

Now, click on the new token button. Then it will ask for token name, expiration duration and the endpoints that you want to fetch data from.

Once that is done click the save button, the token will be generated. Copy the token and save at a secure place for further usage.

STEP 2 - Choose one from the following two deployment options to deploy the docker based data connector to ingest Netskope Web Transactions data

IMPORTANT: Before deploying Netskope data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available, as well as the Netskope API Authorization Key(s) [Make sure the token has permissions for transaction events].

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Using Azure Resource Manager (ARM) Template to deploy VM [Recommended]

Using the ARM template deploy an Azure VM, install the prerequisites and start execution.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the below information : Docker Image Name (mgulledge/netskope-microsoft-sentinel-plugin:netskopewebtransactions) Netskope HostName Netskope API Token Seek Timestamp (The epoch timestamp that you want to seek the pubsublite pointer, can be left empty) Workspace ID Workspace Key Backoff Retry Count (The retry count for token related errors before restarting the execution.)
Backoff Sleep Time (Number of seconds to sleep before retrying) Idle Timeout (Number of seconds to wait for Web Transactions Data before restarting execution) VM Name Authentication Type Admin Password or Key DNS Label Prefix Ubuntu OS Version Location VM Size Subnet Name Network Security Group Name Security Type

Click on Review+Create.

Then after validation click on Create to deploy.

Option 2 - Manual Deployment on previously created virtual machine

Use the following step-by-step instructions to deploy the docker based data connector manually on a previously created virtual machine.

Install docker and pull docker Image

NOTE: Make sure that the VM is linux based (preferably Ubuntu).

Firstly you will need to SSH into the virtual machine.

Now install docker engine.

Now pull the docker image from docker hub using the command: 'sudo docker pull mgulledge/netskope-microsoft-sentinel-plugin:netskopewebtransactions'.

Now to run the docker image use the command: 'sudo docker run -it -v $(pwd)/docker_persistent_volume:/app mgulledge/netskope-microsoft-sentinel-plugin:netskopewebtransactions'. You can replace mgulledge/netskope-microsoft-sentinel-plugin:netskopewebtransactions with the image id. Here docker_persistent_volume is the name of the folder that would be created on the vm in which the files will get stored.

Configure the Parameters

Once the docker image is running it will ask for the required parameters.

Add each of the following application settings individually, with their respective values (case-sensitive): Netskope HostName Netskope API Token Seek Timestamp (The epoch timestamp that you want to seek the pubsublite pointer, can be left empty) Workspace ID Workspace Key Backoff Retry Count (The retry count for token related errors before restarting the execution.)
Backoff Sleep Time (Number of seconds to sleep before retrying) Idle Timeout (Number of seconds to wait for Web Transactions Data before restarting execution)

Now the execution has started but is in interactive mode, so that shell cannot be stopped. To run it as a background process, stop the current execution by pressing Ctrl+C and then use the command: 'sudo docker run -d -v $(pwd)/docker_persistent_volume:/app mgulledge/netskope-microsoft-sentinel-plugin:netskopewebtransactions'.

Stop the docker container

Use the command 'sudo docker container ps' to list the running docker containers. Note down your container id.

Now stop the container using the command: 'sudo docker stop <container-id>'.

Network Security Groups

Supported by: Microsoft Corporation

Azure network security groups (NSG) allow you to filter network traffic to and from Azure resources in an Azure virtual network. A network security group includes rules that allow or deny traffic to a virtual network subnet, network interface, or both.

When you enable logging for an NSG, you can gather the following types of resource log information:

Event: Entries are logged for which NSG rules are applied to VMs, based on MAC address.

Rule counter: Contains entries for how many times each NSG rule is applied to deny or allow traffic. The status for these rules is collected every 300 seconds.

This connector lets you stream your NSG diagnostics logs into Microsoft Sentinel, allowing you to continuously monitor activity in all your instances. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

AzureDiagnostics No No

Data collection rule support: Not currently supported

NordPass

Supported by: NordPass

Integrating NordPass with Microsoft Sentinel SIEM via the API will allow you to automatically transfer Activity Log data from NordPass to Microsoft Sentinel and get real-time insights, such as item activity, all login attempts, and security notifications.

Log Analytics table(s):

Table DCR support Lake-only ingestion

NordPassEventLogs_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Ensure that the resource group and the Log Analytics workspace are created and located in the same region so you can deploy the Azure Functions.

Add Microsoft Sentinel to the created Log Analytics workspace.

Generate a Microsoft Sentinel API URL and token in the NordPass Admin Panel to finish the Azure Functions integration. Please note that you’ll need the NordPass Enterprise account for that.

Important: This connector uses Azure Functions to retrieve Activity Logs from NordPass into Microsoft Sentinel. This may result in additional data ingestion costs. For more information, refer to the Azure Functions pricing page.

Setup Instructions:

To proceed with the Microsoft Sentinel setup

Click the Deploy to Azure button below.

aka.ms

Please note that after the successful deployment, the system pulls Activity Log data every 1 minute by default.

Obsidian Datasharing Connector

Supported by: Obsidian Security

The Obsidian Datasharing connector provides the capability to read raw event data from Obsidian Datasharing in Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ObsidianActivity_CL No No

ObsidianThreat_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector reads data from the tables that Obsidian Datasharing uses in a Microsoft Analytics Workspace, if the data forwarding option is enabled in Obsidian Datasharing then raw event data is sent to the Microsoft Sentinel Ingestion API.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will trigger the creation of Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Push your logs into the workspace

Use the following parameters to configure the your machine to send the logs to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>

Entra App Registration Application ID: <variable value provided at install time>

Entra App Registration Secret: <variable value provided at install time>

Data Collection Endpoint Uri: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

Activity Stream Name: <variable value provided at install time>

Threat Stream Name: <variable value provided at install time>

Okta Single Sign-On (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Okta Single Sign-On (SSO) data connector provides the capability to ingest audit and event logs from the Okta Sysem Log API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework and uses the Okta System Log API to fetch the events. The connector supports DCR-based ingestion time transformations that parses the received security event data into a custom columns so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OktaSSO No No

Data collection rule support: Not currently supported

Prerequisites:

Okta API Token: An Okta API token. Follow the following instructions to create an See the documentation to learn more about Okta System Log API.

Setup Instructions:

To enable the Okta Single Sign-On for Microsoft Sentinel, provide the required information below and click on Connect.

Data Connectors Grid (configure in portal)

Onapsis Defend: Integrate Unmatched SAP Threat Detection & Intel with Microsoft Sentinel

Supported by: Onapsis

Empower security teams with deep visibility into unique exploit, zero-day, and threat actor activity; suspicious user or insider behavior; sensitive data downloads; security control violations; and more - all enriched by the SAP experts at Onapsis.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Onapsis_Defend_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rules. Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

We will create data collection rule (DCR) and data collection endpoint (DCE) resources. We will also create a Microsoft Entra app registration and assign the required permissions to it.

Automated deployment of Azure resources Clicking on "Deploy push connector resources" will trigger the creation of DCR and DCE resources. It will then create a Microsoft Entra app registration with client secret and grant permissions on the DCR. This setup enables data to be sent securely to the DCR using a OAuth v2 client credentials.

2. Maintain the data collection endpoint details and authentication info in Onapsis Defend Integration

Share the data collection endpoint URL and authentication info with the Onapsis Defend Integration administrator to configure the Onapsis Defend Integration to send data to the data collection endpoint.

Tenant ID | Use this value to configure as Tenant ID: <variable value provided at install time>

Entra Application ID | Use this value for the Client ID: <variable value provided at install time>

Entra Application Secret | Use this value for the Token: <variable value provided at install time>

LogIngestionURL | Use this value for the URL parameter: <variable value provided at install time>

DCR Immutable ID | Use this value for the DCR_ID parameter: <variable value provided at install time>

OneLogin IAM Platform (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The OneLogin data connector provides the capability to ingest common OneLogin IAM Platform events into Microsoft Sentinel through REST API by using OneLogin Events API and OneLogin Users API. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OneLoginEventsV2_CL Yes Yes

OneLoginUsersV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

OneLogin IAM API Credentials: To create API Credentials follow the document link provided here, Click Here. Make sure to have an account type of either account owner or administrator to create the API credentials. Once you create the API Credentials you get your Client ID and Client Secret.

Setup Instructions:

Connect OneLogin IAM Platform to Microsoft Sentinel

To ingest data from OneLogin IAM to Microsoft Sentinel, you have to click on Add Domain button below then you get a pop up to fill the details, provide the required information and click on Connect. You can see the domain endpoints connected in the grid.

Data Connectors Grid (configure in portal)

OneTrust

Supported by: OneTrust, LLC

The OneTrust connector for Microsoft Sentinel provides the capability to have near real time visibility into where sensitive data has been located or remediated across across Google Cloud and other OneTrust supported data sources.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OneTrustMetadataV3_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector reads data from the tables that OneTrust uses in a Microsoft Analytics Workspace. If OneTrust's data forwarding option is enabled then raw event data can be sent to the Microsoft Sentinel Ingestion API.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will trigger the creation of Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Push your logs into the workspace

Use the following parameters to configure the your machine to send the logs to the workspace.

Tenant ID (Directory ID): <variable value provided at install time>

Entra App Registration Application ID: <variable value provided at install time>

Entra App Registration Secret: <variable value provided at install time>

Data Collection Endpoint Uri: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

OneTrust Metadata Stream Name: <variable value provided at install time>

Open Systems Data Connector

Supported by: Open Systems

The Open Systems Logs API Microsoft Sentinel Connector provides the capability to ingest Open Systems logs into Microsoft Sentinel using Open Systems Logs API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OpenSystemsZtnaLogs_CL Yes Yes

OpenSystemsFirewallLogs_CL No No

OpenSystemsAuthenticationLogs_CL No No

OpenSystemsProxyLogs_CL No No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Container Apps, DCRs, and DCEs: Permissions to deploy Azure Container Apps, Managed Environments, Data Collection Rules (DCRs), and Data Collection Endpoints (DCEs) are required. This is typically covered by having the 'Contributor' role on the subscription or resource group.

Role Assignment Permissions: Permissions to create role assignments (specifically 'Monitoring Metrics Publisher' on DCRs) are required for the deploying user or service principal.

Required Credentials for ARM Template: During deployment, you will need to provide: Open Systems Logs API endpoint and connection string, and Service Principal credentials (Client ID, Client Secret, Object/Principal ID).

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Custom prerequisites if necessary, otherwise delete this customs tag: Description for any custom pre-requisites

Setup Instructions:

STEP 1: Prerequisites

Ensure you have the following information and permissions before proceeding:

Open Systems Logs API endpoint and connection String.

Service Principal credentials (Client ID, Client Secret, Object/Principal ID).

Permissions to deploy Azure Container Apps, Managed Environments, Data Collection Rules (DCRs), Data Collection Endpoints (DCEs), and create Role Assignments (typically 'Contributor' role on the subscription or resource group).

STEP 2: Deploy the Connector

Deploy the ARM template to set up the data processing resources, including the data collection rule and associated components.

Click the Deploy to Azure button below. This will take you to the Azure portal.

aka.ms

In the Azure portal, select your desired Subscription, Resource Group, and Region.

Provide the required parameters, including those gathered in the prerequisites step (Open Systems Logs API details, Service Principal credentials, etc.), when prompted by the deployment wizard.

Review the terms and click Review + create, then Create to start the deployment.

STEP 3: Post-Deployment Verification

After successful deployment:

Verify that the Azure Container App running the processor is in a 'Running' state.

Check the OpenSystemsZtnaLogs_CL, OpenSystemsFirewallLogs_CL, OpenSystemsAuthenticationLogs_CL, and OpenSystemsProxyLogs_CL tables in your Log Analytics workspace for incoming data. It may take some time for logs to appear after initial setup.

Use the sample queries provided in the 'Next Steps' tab of this data connector page to view and analyze your logs.

OpenAI (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The OpenAI data connector enables you to ingest audit logs, chat completion data, or both from your OpenAI organization into Microsoft Sentinel through the OpenAI API. Each data type uses a separate REST API poller and requires a different API key type: audit logs (user actions, API key management, organization changes, security events) require an organization-level admin API key, while chat completions (model usage, token consumption, performance metrics) require a project-level API key. You may configure one or both data types independently. Audit logs are collected into the custom OpenAIAuditLogs_CL table (aliased by the OpenAIAuditLogs parser). Chat completions are normalized into the ASimAgentEventLogs standard ASIM table (aliased by the OpenAIChatCompletions parser) for security monitoring, compliance analysis, and usage monitoring. Refer to OpenAI API documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OpenAIAuditLogs No No

Data collection rule support: Not currently supported

Prerequisites:

OpenAI API access: Each data type requires a different API key type. An organization-level admin API key is required for audit logs - these can be created in your OpenAI organization settings. A project-level API key is required for chat completions - these can be created under a specific project in the OpenAI dashboard. You may configure audit logs, chat completions, or both independently.

Setup Instructions:

Connection Information

Details on the connections used to collect data from OpenAI's API.

Audit Logs (OpenAIAuditLogs):

Use organization-level admin API keys.

Audit logging must be enabled in your OpenAI organization settings. Organization owners can go to OpenAI's Organization settings -> Data controls -> Data retention to enable audit logging.

Once OpenAI audit logging is enabled, it cannot be disabled without contacting OpenAI support.

Chat Completions (ASimAgentEventLogs):

Use project-level API keys.

Only chat completions created with the store parameter set to true will be collected.

Chat completions are normalized into the ASimAgentEventLogs ASIM standard table.

Deleting stored chat completions while this connector is active may require you to disconnect and reconnect to reset the data collection state.

Add OpenAI Audit Logs Connection

Enter your OpenAI API credentials to collect audit logs data from OpenAI API.

Add OpenAI Chat Completions Connection

Enter your OpenAI API credentials to collect chat completions data from OpenAI API.

Data Connectors Grid (configure in portal)

Oracle Cloud Infrastructure (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Oracle Cloud Infrastructure (OCI) data connector provides the capability to ingest OCI Logs from OCI Stream into Microsoft Sentinel using the OCI Streaming REST API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OCI_LogsV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

OCI Streaming API access: Access to the OCI Streaming API through a API Signing Keys is required.

Setup Instructions:

Connect to OCI Streaming API to start collecting Event logs in Microsoft Sentinel

Log in to the OCI console and access the navigation menu.

In the navigation menu, go to "Analytics & AI" -> "Streaming".

Click "Create Stream".

Select an existing "Stream Pool" or create a new one.

Enter the following details:

"Stream Name"

"Retention"

"Number of Partitions"

"Total Write Rate"

"Total Read Rate" (based on your data volume)

In the navigation menu, go to "Logging" -> "Service Connectors".

Click "Create Service Connector".

Enter the following details:

"Connector Name"

"Description"

"Resource Compartment"

Select the "Source": "Logging".

Select the "Target": "Streaming".

(Optional) Configure "Log Group", "Filters", or use a "custom search query" to stream only the required logs.

Configure the "Target" by selecting the previously created stream.

Click "Create".

Follow the documentation to create a Private Key and API Key Configuration File. Save the Pem File, pass phrase (Optional, it is not set when using the OCI console to generate the API signing key pair) and fingerprint in a secured place for use when connect.

Data Connectors Grid (configure in portal)

Orca Security Alerts

Supported by: Orca Security

The Orca Security Alerts connector allows you to easily export Alerts logs to Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

OrcaAlerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Follow guidance for integrating Orca Security Alerts logs with Microsoft Sentinel.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Palo Alto Cortex XDR

Supported by: Microsoft Corporation

The Palo Alto Cortex XDR data connector allows ingesting logs from the Palo Alto Cortex XDR API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework. It uses the Palo Alto Cortex XDR API to fetch logs and it supports DCR-based ingestion time transformations that parses the received security data into a custom table so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PaloAltoCortexXDR_Incidents_CL Yes Yes

PaloAltoCortexXDR_Endpoints_CL Yes Yes

PaloAltoCortexXDR_Audit_Management_CL Yes Yes

PaloAltoCortexXDR_Audit_Agent_CL Yes Yes

PaloAltoCortexXDR_Alerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configuration steps for the Palo Alto Cortex XDR API Follow the instructions to obtain the credentials. you can also follow this guide to generate API key.

Retrieve API URL 1.1. Log in to the Palo Alto Cortex XDR [Management Console] with Admin user credentials 1.2. In the [Management Console], click [Settings] -> [Configurations] 1.3. Under [Integrations] click on [API Keys]. 1.4. In the [Settings] Page click on [Copy API URL] in the top right corner.

Retrieve API Token 2.1. Log in to the Palo Alto Cortex XDR [Management Console] with Admin user credentials 2.2. In the [Management Console], click [Settings] -> [Configurations] 2.3. Under [Integrations] click on [API Keys]. 2.4. In the [Settings] Page click on [New Key] in the top right corner. 2.5. Choose security level, role, choose Standard and click on [Generate] 2.6. Copy the API Token, once it generated the [API Token ID] can be found under the ID column

Base API URL: (https://api-example.xdr.au.paloaltonetworks.com)

API Key ID: (API ID)

API Token: (API Token)

Enable/Disable Connection

Palo Alto Cortex Xpanse (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Palo Alto Cortex Xpanse data connector ingests alerts data into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CortexXpanseAlerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Palo Alto Xpanse to Microsoft Sentinel

To ingest data from Palo Alto Cortex Xpanse to Microsoft Sentinel, click on Add Domain. Fill in the required details in the pop-up and click Connect. You will see connected domain endpoints in the grid below. To get the Auth ID and API Key, go to Settings → Configuration → Integrations → API Keys in the Cortex Xpanse portal and generate new credentials.

Data Connectors Grid (configure in portal)

Palo Alto Prisma Cloud CSPM (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Palo Alto Prisma Cloud CSPM data connector allows you to connect to your Palo Alto Prisma Cloud CSPM instance and ingesting Alerts (https://pan.dev/prisma-cloud/api/cspm/alerts/) & Audit Logs(https://pan.dev/prisma-cloud/api/cspm/audit-logs/) into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PaloAltoPrismaCloudAlertV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Palo Alto Prisma Cloud CSPM Events to Microsoft Sentinel

To get more information on how to obtain the Prisma Cloud Access Key, Secret Key, and Base URL, please refer to theconnector tutorial, provide the required information below and click on Connect.

Prisma Cloud Access Key: (Enter Access Key)

Prisma Cloud Secret Key: (Enter Secret Key)

Prisma Cloud Base URL: (https://api2.eu.prismacloud.io)

Enable/Disable Connection

Data Connectors Grid (configure in portal)

Palo Alto Prisma Cloud CWPP (using REST API)

Supported by: Microsoft Corporation

The Palo Alto Prisma Cloud CWPP data connector allows you to connect to your Palo Alto Prisma Cloud CWPP instance and ingesting alerts into Microsoft Sentinel. The data connector is built on Microsoft Sentinel's Codeless Connector Framework and uses the Prisma Cloud API to fetch security events and supports DCR-based ingestion time transformations that parses the received security event data into a custom columns so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PrismaCloudCompute_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

PrismaCloudCompute API Key: A Palo Alto Prisma Cloud CWPP Monitor API username and password is required. For more information, see PrismaCloudCompute SIEM API.

Setup Instructions:

Connect Palo Alto Prisma Cloud CWPP Security Events to Microsoft Sentinel

To enable the Palo Alto Prisma Cloud CWPP Security Events for Microsoft Sentinel, provide the required information below and click on Connect.

Path to console: (europe-west3.cloud.twistlock.com/{sasid})

Prisma Access Key (API): (Prisma Access Key (API))

Secret: (Secret)

Enable/Disable Connection

Pathlock Inc.: Threat Detection and Response for SAP

Supported by: Pathlock Inc.

The Pathlock Threat Detection and Response (TD&R) integration with Microsoft Sentinel Solution for SAP delivers unified, real-time visibility into SAP security events, enabling organizations to detect and act on threats across all SAP landscapes. This out-of-the-box integration allows Security Operations Centers (SOCs) to correlate SAP-specific alerts with enterprise-wide telemetry, creating actionable intelligence that connects IT security with business processes.

Pathlock’s connector is purpose-built for SAP and forwards only security-relevant events by default, minimizing data volume and noise while maintaining the flexibility to forward all log sources when needed. Each event is enriched with business process context, allowing Microsoft Sentinel Solution for SAP analytics to distinguish operational patterns from real threats and to prioritize what truly matters.

This precision-driven approach helps security teams drastically reduce false positives, focus investigations, and accelerate mean time to detect (MTTD) and mean time to respond (MTTR). Pathlock’s library consists of more than 1,500 SAP-specific detection signatures across 70+ log sources, the solution uncovers complex attack behaviors, configuration weaknesses, and access anomalies.

By combining business-context intelligence with advanced analytics, Pathlock enables enterprises to strengthen detection accuracy, streamline response actions, and maintain continuous control across their SAP environments—without adding complexity or redundant monitoring layers.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ABAPAuditLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rules. Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

We will create data collection rule (DCR) and data collection endpoint (DCE) resources. We will also create a Microsoft Entra app registration and assign the required permissions to it.

Automated deployment of Azure resources Clicking on "Deploy push connector resources" will trigger the creation of DCR and DCE resources. It will then create a Microsoft Entra app registration with client secret and grant permissions on the DCR. This setup enables data to be sent securely to the DCR using a OAuth v2 client credentials.

2. Maintain the data collection endpoint details and authentication info in your central instance of Pathlock's Cybersecurity Application Controls: Threat Detection and Response

Share the data collection endpoint URL and authentication info with the Pathlock administrator to configure the plug and play forwarding in Threat Detection and Response to send data to the data collection endpoint. Please do not hesitate to contact Pathlock if support is needed.

Use this value to configure as Tenant ID in the LogIngestionAPI credential.: <variable value provided at install time>

Entra Application ID: <variable value provided at install time>

Entra Application Secret: <variable value provided at install time>

Use this value to configure the LogsIngestionURL parameter when deploying the IFlow.: <variable value provided at install time>

DCR Immutable ID: <variable value provided at install time>

Perimeter 81 Activity Logs

Supported by: Perimeter 81

The Perimeter 81 Activity Logs connector allows you to easily connect your Perimeter 81 activity logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Perimeter81_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Please note the values below and follow the instructions here to connect your Perimeter 81 activity logs with Microsoft Sentinel.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Phosphorus Devices

Supported by: Phosphorus Inc.

The Phosphorus Device Connector provides the capability to Phosphorus to ingest device data logs into Microsoft Sentinel through the Phosphorus REST API. The Connector provides visibility into the devices enrolled in Phosphorus. This Data Connector pulls devices information along with its corresponding alerts.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Phosphorus_CL No No

Data collection rule support: Not currently supported

Prerequisites:

REST API Credentials/permissions: Phosphorus API Key is required. Please make sure that the API Key associated with the User has the Manage Settings permissions enabled.

Follow these instructions to enable Manage Settings permissions.

Log in to the Phosphorus Application

Go to 'Settings' -> 'Groups'

Select the Group the Integration user is a part of

Navigate to 'Product Actions' -> toggle on the 'Manage Settings' permission.

Setup Instructions:

STEP 1 - Configuration steps for the Phosphorus API

Follow these instructions to create a Phosphorus API key.

Log into your Phosphorus instance

Navigate to Settings -> API

If the API key has not already been created, press the Add button to create the API key

The API key can now be copied and used during the Phosphorus Device connector configuration

Connect the Phosphorus Application with Microsoft Sentinel

STEP 2 - Fill in the details below

IMPORTANT: Before deploying the Phosphorus Device data connector, have the Phosphorus Instance Domain Name readily available as well as the Phosphorus API Key(s)

Ping One (via Codeless Connector Framework)

Supported by: Microsoft Corporation

This connector ingests audit activity logs from the PingOne Identity platform into Microsoft Sentinel using a Codeless Connector Framework.

Log Analytics table(s):

Table DCR support Lake-only ingestion

PingOne_AuditActivitiesV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Ping One connector to Microsoft Sentinel

Before connecting to PingOne, ensure the following prerequisites are completed. Refer to the document for detailed setup instructions, including how to obtain client credentials and the environment ID.

Client Credentials You'll need client credentials, including your client id and client secret.

Environment Id
To generate token and gather logs from audit activities endpoint

Data Connectors Grid (configure in portal)

Prancer Data Connector

Supported by: Prancer PenSuiteAI Integration

The Prancer Data Connector has provides the capability to ingest Prancer (CSPM)[https://docs.prancer.io/web/CSPM/] and PAC data to process through Microsoft Sentinel. Refer to Prancer Documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

prancer_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Include custom pre-requisites if the connectivity requires - else delete customs: Description for any custom pre-requisite

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Prancer REST API to pull logs into Microsoft sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

STEP 1: Follow the documentation on the Prancer Documentation Site in order to set up an scan with an azure cloud connector.

STEP 2: Once the scan is created go to the 'Third Part Integrations' menu for the scan and select Sentinel.

STEP 3: Create follow the configuration wizard to select where in Azure the results should be sent to.

STEP 4: Data should start to get fed into Microsoft Sentinel for processing.

Premium Microsoft Defender Threat Intelligence

Supported by: Microsoft Corporation

Microsoft Sentinel provides you the capability to import threat intelligence generated by Microsoft to enable monitoring, alerting and hunting. Use this data connector to import Indicators of Compromise (IOCs) from Premium Microsoft Defender Threat Intelligence (MDTI) into Microsoft Sentinel. Threat indicators can include IP addresses, domains, URLs, and file hashes, etc. Note: This is a paid connector. To use and ingest data from it, please purchase the "MDTI API Access" SKU from the Partner Center.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Proofpoint On Demand Email Security (via Codeless Connector Framework)

Supported by: Proofpoint, Inc.

Proofpoint On Demand Email Security data connector provides the capability to get Proofpoint on Demand Email Protection data, allows users to check message traceability, monitoring into email activity, threats,and data exfiltration by attackers and malicious insiders. The connector provides ability to review events in your org on an accelerated basis, get event log files in hourly increments for recent activity.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ProofpointPODMailLog_CL Yes Yes

ProofpointPODMessage_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Websocket API Credentials/permissions: ProofpointClusterID, and ProofpointToken are required. For more information, see API.

Setup Instructions:

Configuration steps for the Proofpoint POD Websocket API

The PoD Log API does not allow use of the same token for more than one session at the same time, so make sure your token isn't used anywhere.

Proofpoint Websocket API service requires Remote Syslog Forwarding license. Please refer the documentation on how to enable and check PoD Log API. You must provide your cluster id and security token.

Retrieve the cluster id 1.1. Log in to the proofpoint [Management Console] with Admin user credentials

1.2. In the Management Console, the cluster id is displayed in the upper-right corner.

Retrieve the API token 2.1. Log in to the proofpoint [Management Console] with Admin user credentials

2.2. In the Management Console, click Settings -> API Key Management

2.3. Under API Key Management click on the PoD Logging tab.

2.4. Get or create a new API key.

Cluster Id: (cluster_id)

API Key: (API Key)

Enable/Disable Connection

Proofpoint On Demand Email Security (via Codeless Connector Framework)

Supported by: Microsoft Corporation

Proofpoint On Demand Email Security data connector provides the capability to get Proofpoint on Demand Email Protection data, allows users to check message traceability, monitoring into email activity, threats,and data exfiltration by attackers and malicious insiders. The connector provides ability to review events in your org on an accelerated basis, get event log files in hourly increments for recent activity.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ProofpointPODMailLog_CL Yes Yes

ProofpointPODMessage_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Websocket API Credentials/permissions: ProofpointClusterID, and ProofpointToken are required. For more information, see API.

Setup Instructions:

Configuration steps for the Proofpoint POD Websocket API

The PoD Log API does not allow use of the same token for more than one session at the same time, so make sure your token isn't used anywhere.

Proofpoint Websocket API service requires Remote Syslog Forwarding license. Please refer the documentation on how to enable and check PoD Log API. You must provide your cluster id and security token.

Retrieve the cluster id 1.1. Log in to the proofpoint [Management Console] with Admin user credentials

1.2. In the Management Console, the cluster id is displayed in the upper-right corner.

Retrieve the API token 2.1. Log in to the proofpoint [Management Console] with Admin user credentials

2.2. In the Management Console, click Settings -> API Key Management

2.3. Under API Key Management click on the PoD Logging tab.

2.4. Get or create a new API key.

Cluster Id: (cluster_id)

API Key: (API Key)

Enable/Disable Connection

Proofpoint TAP (via Codeless Connector Framework)

Supported by: Proofpoint, Inc.

The Proofpoint Targeted Attack Protection (TAP) connector provides the capability to ingest Proofpoint TAP logs and events into Microsoft Sentinel. The connector provides visibility into Message and Click events in Microsoft Sentinel to view dashboards, create custom alerts, and to improve monitoring and investigation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ProofPointTAPMessagesDeliveredV2_CL Yes Yes

ProofPointTAPMessagesBlockedV2_CL Yes Yes

ProofPointTAPClicksPermittedV2_CL Yes Yes

ProofPointTAPClicksBlockedV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Proofpoint TAP API Key: A Proofpoint TAP API service principal and secret is required to access Proofpoint's SIEM API. For more information, see Proofpoint SIEM API.

Setup Instructions:

Configuration steps for the Proofpoint TAP API

Log into the Proofpoint TAP dashboard

Navigate to Settings and go to Connected Applications tab

Click on Create New Credential

Provide a name and click Generate

Copy Service Principal and Secret values

NOTE: This connector depends on a parser based on Kusto Function to work as expected ProofpointTAPEvent which is deployed with the Microsoft Sentinel Solution.

Service Principal: (123456)

Secret: (123456)

Enable/Disable Connection

Proofpoint TAP (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Proofpoint Targeted Attack Protection (TAP) connector provides the capability to ingest Proofpoint TAP logs and events into Microsoft Sentinel. The connector provides visibility into Message and Click events in Microsoft Sentinel to view dashboards, create custom alerts, and to improve monitoring and investigation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ProofPointTAPMessagesDeliveredV2_CL Yes Yes

ProofPointTAPMessagesBlockedV2_CL Yes Yes

ProofPointTAPClicksPermittedV2_CL Yes Yes

ProofPointTAPClicksBlockedV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Proofpoint TAP API Key: A Proofpoint TAP API service principal and secret is required to access Proofpoint's SIEM API. For more information, see Proofpoint SIEM API.

Setup Instructions:

Configuration steps for the Proofpoint TAP API

Log into the Proofpoint TAP dashboard

Navigate to Settings and go to Connected Applications tab

Click on Create New Credential

Provide a name and click Generate

Copy Service Principal and Secret values

NOTE: This connector depends on a parser based on Kusto Function to work as expected ProofpointTAPEvent which is deployed with the Microsoft Sentinel Solution.

Service Principal: (123456)

Secret: (123456)

Enable/Disable Connection

QscoutAppEventsConnector (via Codeless Connector Framework)

Supported by: Quokka

Ingest Qscout application events into Microsoft Sentinel

Log Analytics table(s):

Table DCR support Lake-only ingestion

QscoutAppEvents_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Qscout Organization ID: The API requires your organization ID in Qscout.

Qscout Organization API Key: The API requires your organization API key in Qscout.

Setup Instructions:

NOTE: This connector uses Codeless Connector Framework (CCF) to connect to the Qscout app events feed and ingest data into Microsoft Sentinel

Provide the required values below:

Qscout Organization ID: (123456)

Qscout Organization API Key: (abcdxyz)

Enable/Disable Connection

Qualys Knowledge Base (via Codeless Connector Framework)

Supported by: Microsoft Corporation

Ingest Qualys Knowledge Base Vulnerability Data into Microsoft Sentinel using version 4.0 of the Qualys API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

QualysKnowledgeBase Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Qualys API access: Requires a Qualys User Account with read access to the Knowledge Base endpoints.

Setup Instructions:

Step 1: Set Credentials Provide your Qualys API credentials to enable data ingestion from the Qualys Knowledge Base.

To gather data from Qualys VM, you need to provide the following resources:

API Credentials: username and password for an account with read access to the Knowledge Base API. You can find the exact permissions needed in the Qualys API documentation.

API Server URL: the Qualys API server URL specific to your region. You can find the exact API server URL for your region here

API Server URL: (Enter API Server URL)

Username: (Enter Qualys username)

Password: (Enter your Qualys password or token) Step 2: Set Any Optional Filters

Configure optional filters to customize which vulnerabilities are ingested. Learn more about available filters in the Qualys API documentation.

2a. Filter by Patch Status Choose to only show vulnerabilities that are patchable or not patchable.

2b. Filter by Discovery Method and Authentication Types Choose to only receive vulnerabilities assigned a certain discovery method or having specific authentication types.

Discovery Authentication Types: (e.g., Windows, Oracle, Unix, SNMP (comma-separated)) Step 3: Review and Enable Review your configuration settings and enable the connector to start ingesting Qualys Knowledge Base data into Microsoft Sentinel.

Enable/Disable Connection

Qualys VM KnowledgeBase (using Azure Functions)

Supported by: Microsoft Corporation

The Qualys Vulnerability Management (VM) KnowledgeBase (KB) connector provides the capability to ingest the latest vulnerability data from the Qualys KB into Microsoft Sentinel.

This data can used to correlate and enrich vulnerability detections found by the Qualys Vulnerability Management (VM) data connector.

Log Analytics table(s):

Table DCR support Lake-only ingestion

QualysKB_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Qualys API Key: A Qualys VM API username and password is required. For more information, see Qualys VM API.

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias QualysVM Knowledgebase and load the function code or click here, on the second line of the query, enter the hostname(s) of your QualysVM Knowledgebase device(s) and any other unique identifiers for the logstream. The function usually takes 10-15 minutes to activate after solution installation/update.

This data connector depends on a parser based on a Kusto Function to work as expected. Follow the steps to use the Kusto function alias, QualysKB

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Qualys API

Log into the Qualys Vulnerability Management console with an administrator account, select the Users tab and the Users subtab.

Click on the New drop-down menu and select Users.

Create a username and password for the API account.

In the User Roles tab, ensure the account role is set to Manager and access is allowed to GUI and API

Log out of the administrator account and log into the console with the new API credentials for validation, then log out of the API account.

Log back into the console using an administrator account and modify the API accounts User Roles, removing access to GUI.

Save all changes.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Qualys KB connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Qualys API username and password, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Qualys KB connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID, Workspace Key, API Username, API Password , update the URI, and any additional URI Filter Parameters (This value should include a "&" symbol between each parameter and should not include any spaces)

Enter the URI that corresponds to your region. The complete list of API Server URLs can be found here

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Note: If deployment failed due to the storage account name being taken, change the Function Name to a unique value and redeploy.

Option 2 - Manual Deployment of Azure Functions

This method provides the step-by-step instructions to deploy the Qualys KB connector manually with Azure Function.

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.

Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.

After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following seven (7) application settings individually, with their respective string values (case-sensitive): apiUsername apiPassword workspaceID workspaceKey uri filterParameters logAnalyticsUri (optional)

Enter the URI that corresponds to your region. The complete list of API Server URLs can be found here. The uri value must follow the following schema: https://<API Server>/api/2.0

Add any additional filter parameters, for the filterParameters variable, that need to be appended to the URI. The filterParameter value should include a "&" symbol between each parameter and should not include any spaces.

Note: If using Azure Key Vault, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Use logAnalyticsUri to override the log analytics API endpoint for delegated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Qualys Vulnerability Management (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Qualys Vulnerability Management (VM) data connector provides the capability to ingest vulnerability host detection data into Microsoft Sentinel through the Qualys API. The connector provides visibility into host detection data from vulerability scans.

Log Analytics table(s):

Table DCR support Lake-only ingestion

QualysHostDetectionV3_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

API access and roles: Ensure the Qualys VM user has a role of Reader or higher. If the role is Reader, ensure that API access is enabled for the account. Auditor role is not supported to access the API. For more details, refer to the Qualys VM Host Detection API and User role Comparison document.

Setup Instructions:

Connect Qualys Vulnerability Management to Microsoft Sentinel

NOTE: To gather data for Detections based on Host, expand the DetectionList column in the table.

To gather data from Qualys VM, you need to provide the following resources

API Credentials To gather data from Qualys VM, you'll need Qualys API credentials, including your Username and Password.

API Server URL To gather data from Qualys VM, you'll need the Qualys API server URL specific to your region. You can find the exact API server URL for your region here

Qualys API User Name: (Enter UserName)

Qualys API Password: (Enter password)

Qualys API Server URL: (Enter API Server URL)

Truncation Limit Configure the maximum number of host records to retrieve per API call (20-5000 range). Higher values may improve performance but could impact API response times.

Enable/Disable Connection

Radiflow iSID via AMA

Supported by: Radiflow

iSID enables non-disruptive monitoring of distributed ICS networks for changes in topology and behavior, using multiple security packages, each offering a unique capability pertaining to a specific type of network activity

Log Analytics table(s):

Table DCR support Lake-only ingestion

RadiflowEvent No No

Data collection rule support: Not currently supported

Setup Instructions:

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected [RadiflowEvent] which is deployed with the Microsoft Sentinel Solution.

1. Kindly follow the steps to configure the data connector

Step A. Configure the Common Event Format (CEF) via AMA data connector

Note:- CEF logs are collected only from Linux Agents

Navigate to Microsoft Sentinel workspace ---> configuration ---> Data connector blade.

Search for 'Common Event Format (CEF) via AMA' data connector and open it.

Check If there is no existing DCR configured to collect required facility of logs, Create a new DCR (Data Collection Rule).

Note:- It is recommended to install minimum 1.27 version of AMA agent Learn more and ensure there is no duplicate DCR as it can cause log duplicacy.

Run the command provided in the CEF via AMA data connector page to configure the CEF collector on the machine.

Step B. Configure iSID to send logs using CEF

Configure log forwarding using CEF:

Navigate to the System Notifications section of the Configuration menu.

Under Syslog, select +Add.

In the New Syslog Server dialog specify the name, remote server IP, Port, Transport and select Format - CEF.

Press Apply to exit the Add Syslog dialog.

Step C. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python --version

You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**2. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

Rapid7 Insight Platform Vulnerability Management Reports (using Azure Functions)

Supported by: Microsoft Corporation

The Rapid7 Insight VM Report data connector provides the capability to ingest Scan reports and vulnerability data into Microsoft Sentinel through the REST API from the Rapid7 Insight platform (Managed in the cloud). Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

NexposeInsightVMCloud_assets_CL No No

NexposeInsightVMCloud_vulnerabilities_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials: InsightVMAPIKey is required for REST API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Insight VM API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parsers based on a Kusto Function to work as expected InsightVMAssets and InsightVMVulnerabilities which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the Insight VM Cloud

Follow the instructions to obtain the credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Workspace data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Rapid7 Insight Vulnerability Management Report data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the InsightVMAPIKey, choose InsightVMCloudRegion and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Rapid7 Insight Vulnerability Management Report data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.

Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.

After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive):
InsightVMAPIKey InsightVMCloudRegion WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Rapid7 Insight Platform Vulnerability Management Reports (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Rapid7 Insight VM Report data connector provides the capability to ingest Scan reports and vulnerability data into Microsoft Sentinel through the REST API from the Rapid7 Insight platform (Managed in the cloud). Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Rapid7InsightVMCloudAssets Yes Yes

Rapid7InsightVMCloudVulnerabilities Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

REST API Credentials: InsightVMAPIKey is required for REST API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials

Setup Instructions:

Follow the instructions to configure the Rapid7 InsightVM connector.

Note: Note: This data connector depends on a parsers based on a Kusto Function to work as expected InsightVMAssets and InsightVMVulnerabilities which is deployed with the Microsoft Sentinel Solution.

1. Configuration steps for Rapid7 Insight VM cloud

Follow the instructions to obtain the credentials.

In Rapid7 InsightVM, generate an API Key.

Note your Region and API Key.

Region: (us, eu, etc.)

API Key: (API Key)

2. Connect

Enable the Rapid7 Insight VM connector.

Enable/Disable Connection

Red Sift Events (CCF Push)

Supported by: Red Sift

The Red Sift connector provides the capability to ingest Red Sift authentication and email forensics events into Microsoft Sentinel using the CCF push model with DCE + DCR.

Log Analytics table(s):

Table DCR support Lake-only ingestion

RedSiftAuth_CL No No

RedSiftEmailForensics_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

Deploy the DCE, DCR, custom table, and the Entra app registration used for OAuth client credentials.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will trigger the creation of Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Configure Red Sift webhook

Use the following parameters to configure Red Sift to send events to Microsoft Sentinel. Use the appropriate stream name for each event type.

Tenant ID (Directory ID): <variable value provided at install time>

Entra App Registration Application ID: <variable value provided at install time>

Entra App Registration Secret: <variable value provided at install time>

Data Collection Endpoint Uri: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

Auth Events Stream Name: <variable value provided at install time>

Email Forensics Events Stream Name: <variable value provided at install time>

RSA ID Plus Admin Logs Connector

Supported by: RSA Support Team

The RSA ID Plus AdminLogs Connector provides the capability to ingest Cloud Admin Console Audit Events into Microsoft Sentinel using Cloud Admin APIs.

Log Analytics table(s):

Table DCR support Lake-only ingestion

RSAIDPlus_AdminLogs_CL No No

Data collection rule support: Not currently supported

Prerequisites:

RSA ID Plus API Authentication: To access the Admin APIs, a valid Base64URL encoded JWT token, signed with the client's Legacy Administration API key is required.

Setup Instructions:

NOTE: This connector uses Codeless Connector Framework (CCF) to connect to the RSA ID Plus Cloud Admin APIs to pull logs into Microsoft Sentinel.

STEP 1 - Create Legacy Admin API Client in Cloud Admin Console.

Follow steps mentioned in this page.

STEP 2 - Generate the Base64URL encoded JWT Token.

Follow the steps mentioned in this page under the header 'Legacy Administration API'.

STEP 3 - Configure the Cloud Admin API to start ingesting Admin event logs into Microsoft Sentinel.

Provide the required values below:

Admin API URL: (https://<tenantName>.access.securid.com/AdminInterface/restapi/v1/adminlog/exportLogs)

JWT Token: (Enter your JWT Token)

STEP 4 - Click Connect

Verify all the fields above were filled in correctly. Press Connect to start the connector.

Enable/Disable Connection

Rubrik Security Cloud data connector (using Azure Functions)

Supported by: Rubrik

The Rubrik Security Cloud data connector enables security operations teams to integrate insights from Rubrik's Data Observability services into Microsoft Sentinel. The insights include identification of anomalous filesystem behavior associated with ransomware and mass deletion, assess the blast radius of a ransomware attack, and sensitive data operators to prioritize and more rapidly investigate potential incidents.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Rubrik_Anomaly_Data_CL Yes Yes

Rubrik_Ransomware_Data_CL Yes Yes

Rubrik_ThreatHunt_Data_CL Yes Yes

Rubrik_Events_Data_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Rubrik webhook which push its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Rubrik Microsoft Sentinel data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available..

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Rubrik connector.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the below information : Function Name Workspace ID Workspace Key AnomaliesTableName RansomwareAnalysisTableName ThreatHuntsTableName EventsTableName LogLevel

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Rubrik Microsoft Sentinel data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. RubrikXXXXX).

e. Select a runtime: Choose Python 3.8 or above.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following application settings individually, with their respective values (case-sensitive): WorkspaceID WorkspaceKey AnomaliesTableName RansomwareAnalysisTableName ThreatHuntsTableName EventsTableName LogLevel logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Post Deployment steps

1) Get the Function app endpoint

Go to Azure function Overview page and Click on "Functions" tab.

Click on the function called "RubrikHttpStarter".

Go to "GetFunctionurl" and copy the function url.

2) Add a webhook in RubrikSecurityCloud to send data to Microsoft Sentinel.

Follow the Rubrik User Guide instructions to Add a Webhook to begin receiving event information

Select the Microsoft Sentinel as the webhook Provider

Enter the desired Webhook name

Enter the URL part from copied Function-url as the webhook URL endpoint and replace {functionname} with "RubrikAnomalyOrchestrator", for the Rubrik Microsoft Sentinel Solution

Select the EventType as Anomaly

Select the following severity levels: Critical, Warning, Informational

Choose multiple log types, if desired, when running "RubrikEventsOrchestrator"

Repeat the same steps to add webhooks for Anomaly Detection Analysis, Threat Hunt and Other Events.

NOTE: while adding webhooks for Anomaly Detection Analysis, Threat Hunt and Other Events, replace {functionname} with "RubrikRansomwareOrchestrator", "RubrikThreatHuntOrchestrator" and "RubrikEventsOrchestrator" respectively in copied function-url.

Now we are done with the rubrik Webhook configuration. Once the webhook events triggered , you should be able to see the Anomaly, Anomaly Detection Analysis, Threat Hunt events and Other Events from the Rubrik into respective LogAnalytics workspace table called "Rubrik_Anomaly_Data_CL", "Rubrik_Ransomware_Data_CL", "Rubrik_ThreatHunt_Data_CL", and "Rubrik_Events_Data_CL".

SaaS Security

Supported by: Valence Security

Connects the Valence SaaS security platform Azure Log Analytics via the REST API interface

Log Analytics table(s):

Table DCR support Lake-only ingestion

ValenceAlert_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Step 1 : Read the detailed documentation

The installation process is documented in great detail in Valence Security's knowledge base. The user should consult this documentation further to understand installation and debug of the integration.

Step 2: Retrieve the workspace access credentials

The first installation step is to retrieve both your Workspace ID and Primary Key from the Microsoft Sentinel platform. Copy the values shown below and save them for configuration of the API log forwarder integration.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Step 3: Configure Sentinel integration on the Valence Security Platform

As a Valence Security Platform admin, go to the configuration screen, click Connect in the SIEM Integration card, and choose Microsoft Sentinel. Paste the values from the previous step and click Connect. Valence will test the connection so when success is reported, the connection worked.

Salesforce Audit Logs (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Salesforce Audit Logs data connector provides the capability to ingest administrative changes and configuration modifications from your Salesforce org into Microsoft Sentinel through the REST API. The connector provides the ability to ingest Setup Audit Trail and Login History events into Microsoft Sentinel which track changes made to your org's configuration, helping you maintain security and compliance visibility.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SalesforceAuditTrail Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Salesforce Service Cloud API access: Access to the Salesforce Service Cloud API through a Connected App is required.

Setup Instructions:

Connect Salesforce to Microsoft Sentinel

Follow Create a Connected App in Salesforce for OAuth and Configure a Connected App for the OAuth 2.0 Client Credentials Flow to create a Connected App with access to the Salesforce Service Cloud API. Through those instructions, you should get the Consumer Key and Consumer Secret. For Salesforce Domain name, Go to Setup, type My Domain in the Quick Find box, and select My Domain to view your domain details. Make sure to enter the domain name without a trailing slash (e.g., https://your-domain.my.salesforce.com). Fill the form below with that information.

Data Connectors Grid (configure in portal)

SalesForce Real-Time Event Monitoring Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Salesforce Real-Time Event Monitoring (RTEM) Connector provides the capability to ingest information about your Salesforce real time events using Object for Event Storage into Microsoft Sentinel through the REST API. The connector provides ability to review events in your org on an accelerated basis, get real-time event data for recent activity.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SalesForceRealTimeEventMonitoring_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Salesforce Event Monitoring API access: Access to the Salesforce Event Monitoring API through a Connected App is required.

Setup Instructions:

Connect to Salesforce Event Monitoring to start collecting real-time event monitoring logs in Microsoft Sentinel

Follow Create a Connected App in Salesforce for OAuth and Configure a Connected App for the OAuth 2.0 Client Credentials Flow to create a Connected App with access to the Salesforce Event Monitoring API. Through those instructions, you should get the Consumer Key and Consumer Secret. For Salesforce Domain name, Go to Setup, type My Domain in the Quick Find box, and select My Domain to view your domain details. Make sure to enter the domain name without a trailing slash (e.g., https://your-domain.my.salesforce.com). Fill the form below with that information.

Note: Required Add-on subscription: Your Salesforce account should include Salesforce Shield or Salesforce Event Monitoring add-on subscriptions for this connector to work.

Data Connectors Grid (configure in portal)

Salesforce Service Cloud (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Salesforce Service Cloud data connector provides the capability to ingest information about your Salesforce operational events into Microsoft Sentinel through the REST API. The connector provides ability to review events in your org on an accelerated basis, get event log files in hourly increments for recent activity.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SalesforceServiceCloudV3_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Salesforce Service Cloud API access: Access to the Salesforce Service Cloud API through a Connected App is required.

Setup Instructions:

Connect to Salesforce Service Cloud API to start collecting event logs in Microsoft Sentinel

Follow Create a Connected App in Salesforce for OAuth and Configure a Connected App for the OAuth 2.0 Client Credentials Flow to create a Connected App with access to the Salesforce Service Cloud API. Through those instructions, you should get the Consumer Key and Consumer Secret. For Salesforce Domain name, Go to Setup, type My Domain in the Quick Find box, and select My Domain to view your domain details. Make sure to enter the domain name without a trailing slash (e.g., https://your-domain.my.salesforce.com). Fill the form below with that information.

Note: Notice: Solution version 3.2.0 and later uses the SalesforceServiceCloudV3_CL table. The parser has been updated accordingly.

Data Connectors Grid (configure in portal)

Samsung Knox Asset Intelligence

Supported by: Samsung Electronics Co., Ltd.

Samsung Knox Asset Intelligence Data Connector lets you centralize your mobile security events and logs in order to view customized insights using the Workbook template, and identify incidents based on Analytics Rules templates.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Samsung_Knox_Audit_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Entra app: An Entra app needs to be registered and provisioned with ‘Microsoft Metrics Publisher’ role and configured with either Certificate or Client Secret as credentials for secure data transfer. See the Log ingestion tutorial to learn more about Entra App creation, registration and credential configuration.

Setup Instructions:

This Data Connector uses the Microsoft Log Ingestion API to push security events into Microsoft Sentinel from Samsung Knox Asset Intelligence (KAI) solution.

STEP 1 - Create and register an Entra Application

Note: This Data Connector can support either Certificate-based or Client Secret-based authentication. For Certificate-based authentication, you can download the Samsung CA-signed certificate (public key) from KAI documentation portal. For Client Secret-based authentication, you can create the secret during the Entra application registration. Ensure you copy the Client Secret value as soon as it is generated.

IMPORTANT: Save the values for Tenant (Directory) ID and Client (Application) ID. If Client Secret-based authentication is enabled, save Client Secret (Secret Value) associated with the Entra app.

STEP 2 - Automate deployment of this Data Connector using the below Azure Resource Manager (ARM) template

IMPORTANT: Before deploying the Data Connector, copy the below Workspace name associated with your Microsoft Sentinel (also your Log Analytics) instance.

Workspace Name: <variable value provided at install time>

Click the button below to install Samsung Knox Intelligence Solution.

aka.ms\n2. Provide the following required fields: Log Analytics Workspace Name, Log Analytics Workspace Location, Log Analytics Workspace Subscription (ID) and Log Analytics Workspace Resource Group.

STEP 3 - Obtain Microsoft Sentinel Data Collection details

Once the ARM template is deployed, navigate to Data Collection Rules https://portal.azure.com/#browse/microsoft.insights%2Fdatacollectionrules? and save values associated with the Immutable ID (DCR) and Data Collection Endpoint (DCE).

IMPORTANT: To enable end-to-end integration, information related to Microsoft Sentinel DCE and DCR are required for configuration in Samsung Knox Asset Intelligence portal (STEP 4).

Ensure the Entra Application created in STEP 1 has permissions to use the DCR created in order to send data to the DCE. Please refer to /azure/azure-monitor/logs/tutorial-logs-ingestion-portal#assign-permissions-to-the-dcr to assign permissions accordingly.

STEP 4 - Connect to Samsung Knox Asset Intelligence solution to configure Microsoft Sentinel to push select Knox Security Events as Alerts

Login to Knox Asset Intelligence administration portal and navigate to Dashboard Settings; this is available at the top-right corner of the Portal.

Note: Ensure the login user has access to 'Security' and 'Manage dashboard view and data collection' permissions.

Click on Security tab to view settings for Microsoft Sentinel Integration and Knox Security Logs.

In the Security Operations Integration page, toggle on 'Enable Microsoft Sentinel Integration' and enter appropriate values in the required fields.

a. Based on the authentication method used, refer to information saved from STEP 1 while registering the Entra application.

b. For Microsoft Sentinel DCE and DCR, refer to the information saved from STEP 3.

Click on 'Test Connection' and ensure the connection is successful.

Before you can Save, configure Knox Security Logs by selecting either Essential or Advanced configuration (default: Essential).

To complete the Microsoft Sentinel integration, click 'Save'.

SAP BTP

Supported by: Microsoft Corporation

SAP Business Technology Platform (SAP BTP) brings together data management, analytics, artificial intelligence, application development, automation, and integration in one, unified environment.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SAPBTPAuditLog_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Client Id and Client Secret for Audit Retrieval API: Enable API access in BTP.

Setup Instructions:

Step 1 - Configuration steps for the SAP BTP Audit Retrieval API

Follow the steps provided by SAP see Audit Log Retrieval API for Global Accounts in the Cloud Foundry Environment. Take a note of the url (Audit Retrieval API URL), uaa.url (User Account and Authentication Server url) and the associated uaa.clientid.

NOTE: You can mass onboard BTP subaccounts by using provided tools.

Connect events from SAP BTP to Microsoft Sentinel

Connect using OAuth client credentials

Subaccounts

Each row represents a connected subaccount

Data Connectors Grid (configure in portal)

SAP Enterprise Threat Detection, cloud edition

Supported by: SAP

The SAP Enterprise Threat Detection, cloud edition (ETD) data connector enables ingestion of security alerts from ETD into Microsoft Sentinel, supporting cross-correlation, alerting, and threat hunting.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SAPETDAlerts_CL Yes Yes

SAPETDInvestigations_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Client Id and Client Secret for ETD Retrieval API: Enable API access in ETD.

Setup Instructions:

Step 1 - Configuration steps for the SAP ETD Audit Retrieval API

Follow the steps provided by SAP see ETD docs. Take a note of the url (Audit Retrieval API URL), uaa.url (User Account and Authentication Server url) and the associated uaa.clientid.

NOTE: You can onboard one or more ETD subaccounts by following the steps provided by SAP see ETD docs. Add a connection for each subaccount.

TIP: Use the shared blog series for additional info.

Connect events from SAP ETD to Microsoft Sentinel

Connect using OAuth client credentials

ETD accounts

Each row represents a connected ETD account

Data Connectors Grid (configure in portal)

SAP LogServ (RISE), S/4HANA Cloud private edition

Supported by: SAP

SAP LogServ is an SAP Enterprise Cloud Services (ECS) service aimed at collection, storage, forwarding and access of logs. LogServ centralizes the logs from all systems, applications, and ECS services used by a registered customer.
Main Features include:
Near Realtime Log Collection: With ability to integrate into Microsoft Sentinel as SIEM solution.
LogServ complements the existing SAP application layer threat monitoring and detections in Microsoft Sentinel with the log types owned by SAP ECS as the system provider. This includes logs like: SAP Security Audit Log (AS ABAP), HANA database, AS JAVA, ICM, SAP Web Dispatcher, SAP Cloud Connector, OS, SAP Gateway, 3rd party Database, Network, DNS, Proxy, Firewall

Log Analytics table(s):

Table DCR support Lake-only ingestion

SAPLogServ_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rules. Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

We will create data collection rule (DCR) and data collection endpoint (DCE) resources. We will also create a Microsoft Entra app registration and assign the required permissions to it.

Automated deployment of Azure resources Clicking on "Deploy push connector resources" will trigger the creation of DCR and DCE resources. It will then create a Microsoft Entra app registration with client secret and grant permissions on the DCR. This setup enables data to be sent securely to the DCR using a OAuth v2 client credentials.

2. Maintain the data collection endpoint details and authentication info in SAP LogServ

Share the data collection endpoint URL and authentication info with the SAP LogServ administrator to configure the SAP LogServ to send data to the data collection endpoint.

Learn more from this blog series.

Use this value to configure as Tenant ID in the LogIngestionAPI credential.: <variable value provided at install time>

Entra Application ID: <variable value provided at install time>

Entra Application Secret: <variable value provided at install time>

Use this value to configure the LogsIngestionURL parameter when deploying the IFlow.: <variable value provided at install time>

DCR Immutable ID: <variable value provided at install time>

SAP S/4HANA Cloud Public Edition

Supported by: SAP

The SAP S/4HANA Cloud Public Edition (GROW with SAP) data connector enables ingestion of SAP's security audit log into the Microsoft Sentinel Solution for SAP, supporting cross-correlation, alerting, and threat hunting. Looking for alternative authentication mechanisms? See here.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ABAPAuditLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Client Id and Client Secret for Audit Retrieval API: Enable API access in BTP.

Microsoft Sentinel for SAP content package (60+ analytic rules, workbooks, parsers, and more): Deploy from Microsoft Sentinel content hub.

Setup Instructions:

Step 1 - Configuration steps for SAP S/4HANA Cloud Public Edition

To connect to SAP S/4HANA Cloud Public Edition, you will need:

Configure a communication arrangement for communication scenario SAP_COM_0750

SAP S/4HANA Cloud Public Edition tenant API URL

Valid communication user (username and password) for your SAP S/4HANA Cloud system

Appropriate authorizations to access audit log data via OData services

NOTE: This connector supports Basic authentication. Looking for alternative authentication mechanisms? See here

Connect events from SAP S/4HANA Cloud Public Edition to Microsoft Sentinel Solution for SAP

Connect using Basic authentication

S/4HANA Cloud Public Edition connections

Each row represents a connected S/4HANA Cloud Public Edition system

Data Connectors Grid (configure in portal)

SecurityBridge Solution for SAP

Supported by: SecurityBridge

SecurityBridge enhances SAP security by integrating seamlessly with Microsoft Sentinel, enabling real-time monitoring and threat detection across SAP environments. This integration allows Security Operations Centers (SOCs) to consolidate SAP security events with other organizational data, providing a unified view of the threat landscape . Leveraging AI-powered analytics and Microsoft’s Security Copilot, SecurityBridge identifies sophisticated attack patterns and vulnerabilities within SAP applications, including ABAP code scanning and configuration assessments . The solution supports scalable deployments across complex SAP landscapes, whether on-premises, in the cloud, or hybrid environments . By bridging the gap between IT and SAP security teams, SecurityBridge empowers organizations to proactively detect, investigate, and respond to threats, enhancing overall security posture.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ABAPAuditLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rules. Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

We will create data collection rule (DCR) and data collection endpoint (DCE) resources. We will also create a Microsoft Entra app registration and assign the required permissions to it.

Automated deployment of Azure resources Clicking on "Deploy push connector resources" will trigger the creation of DCR and DCE resources. It will then create a Microsoft Entra app registration with client secret and grant permissions on the DCR. This setup enables data to be sent securely to the DCR using a OAuth v2 client credentials.

2. Maintain the data collection endpoint details and authentication info in SecurityBridge

Share the data collection endpoint URL and authentication info with the SecurityBridge administrator to configure the Securitybridge to send data to the data collection endpoint.

Learn more from our KB Page https://abap-experts.atlassian.net/wiki/spaces/SB/pages/4099309579/REST+Push+Interface

Use this value to configure as Tenant ID in the LogIngestionAPI credential.: <variable value provided at install time>

Entra Application ID: <variable value provided at install time>

Entra Application Secret: <variable value provided at install time>

Use this value to configure the LogsIngestionURL parameter when deploying the IFlow.: <variable value provided at install time>

DCR Immutable ID: <variable value provided at install time>

Sentinel for SAP Stream ID: <variable value provided at install time>

SecurityBridge_CL Stream ID: <variable value provided at install time>

Semperis Lightning Logs

Supported by: Semperis

The Semperis Lightning connector uses Azure Functions to ingest Semperis Lightning identity security data into Microsoft Sentinel. The connector deploys an Azure Function and collects data into custom Log Analytics tables for investigation and threat hunting.

Log Analytics table(s):

Table DCR support Lake-only ingestion

LightningTier0Nodes_CL No No

LightningAttackPaths_CL No No

LightningIOEResults_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Semperis Lightning API credentials: A Semperis Lightning API Key and selected Zone (na or eu) are required to authenticate the connector to Semperis Lightning.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to Semperis Lightning and pull data into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Ensure the workspace is added to Microsoft Sentinel before deploying the connector.

STEP 1 - Configure access for Semperis Lightning

Sign in to your Semperis Lightning tenant.

Create or retrieve a valid Semperis API Key for connector access.

Confirm your Semperis Zone value (na for North America or eu for Europe) for use during deployment.

STEP 2 - Deploy the 'Semperis Lightning Logs' connector and the associated Azure Function

Click the Deploy to Azure button below.

aka.ms

STEP 3 - Set the connector parameters

Select the preferred Subscription and an existing Resource Group.

Enter an existing Log Analytics Workspace Resource ID belonging to the resource group.

Click Next.

Enter your Semperis API Key and select the Semperis Zone.

Optionally adjust the Connector Schedule (default: every 1 hour).

Review the settings and click Create.

SentinelOne (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The SentinelOne data connector allows ingesting logs from the SentinelOne API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework. It uses the SentinelOne API to fetch logs and it supports DCR-based ingestion time transformations that parses the received security data into a custom table so that queries don't need to parse it again, thus resulting in better performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SentinelOneActivities_CL Yes Yes

SentinelOneAgents_CL Yes Yes

SentinelOneGroups_CL Yes Yes

SentinelOneThreats_CL Yes Yes

SentinelOneAlerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configuration steps for the SentinelOne API Follow the instructions to obtain the credentials. You can also follow the guide to generate API key.

Retrieve SentinelOne Management URL 1.1. Log in to the SentinelOne [Management Console] with Admin user credentials 1.2. In the [Management Console] copy the URL link above without the URL path.

Retrieve API Token 2.1. Log in to the SentinelOne [Management Console] with Admin user credentials 2.2. In the [Management Console], click [Settings] 2.3. In [Settings] view click on [USERS]. 2.4. In the [USERS] Page click on [Service Users] -> [Actions] -> [Create new service user]. 2.5. Choose [Expiration date] and [scope] (by site) and click on [Create User]. 2.6. Once the [Service User] is created copy the [API Token] from page and press [Save]

SentinelOne Management URL: (https://example.sentinelone.net/)

API Token: (API Token)

Enable/Disable Connection

Seraphic Web Security

Supported by: Seraphic Security

The Seraphic Web Security data connector provides the capability to ingest Seraphic Web Security events and alerts into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SeraphicWebSecurity_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Seraphic API key: API key for Microsoft Sentinel connected to your Seraphic Web Security tenant. To get this API key for your tenant - visit the Integrations page in your Seraphic Console.

Setup Instructions:

Connect Seraphic Web Security

Please insert the integration name, the Seraphic integration URL and your workspace name for Microsoft Sentinel:

Silverfort Admin Console

Supported by: Silverfort

The Silverfort ITDR Admin Console connector solution allows ingestion of Silverfort events and logging into Microsoft Sentinel. Silverfort provides syslog based events and logging using Common Event Format (CEF). By forwarding your Silverfort ITDR Admin Console CEF data into Microsoft Sentinel, you can take advantage of Sentinels's search & correlation, alerting, and threat intelligence enrichment on Silverfort data. Please contact Silverfort or consult the Silverfort documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CommonSecurityLog Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

1. Linux Syslog agent configuration

Install and configure the Linux agent to collect your Common Event Format (CEF) Syslog messages and forward them to Microsoft Sentinel.

Notice that the data from all regions will be stored in the selected workspace

1.1 Select or create a Linux machine

Select or create a Linux machine that Microsoft Sentinel will use as the proxy between your security solution and Microsoft Sentinel this machine can be on your on-prem environment, Azure or other clouds.

1.2 Install the CEF collector on the Linux machine

Install the Microsoft Monitoring Agent on your Linux machine and configure the machine to listen on the necessary port and forward messages to your Microsoft Sentinel workspace. The CEF collector collects CEF messages on port 514 TCP.

Make sure that you have Python on your machine using the following command: python -version.

You must have elevated permissions (sudo) on your machine.

Run the following command to install and apply the CEF collector:: <variable value provided at install time>

2. Forward Common Event Format (CEF) logs to Syslog agent

Set your security solution to send Syslog messages in CEF format to the proxy machine. Make sure you to send the logs to port 514 TCP on the machine's IP address.

3. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python -version

You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**4. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

SlackAudit (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The SlackAudit data connector provides the capability to ingest Slack Audit logs into Microsoft Sentinel through the REST API. Refer to API documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SlackAuditV2_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

UserName, SlackAudit API Key & Action Type: To Generate the Access Token, create a new application in Slack, then add necessary scopes and configure the redirect URL. For detailed instructions on generating the access token, user name and action name limit, refer the link.

Setup Instructions:

**Connect SlackAudit to Microsoft Sentinel

**

To ingest data from SlackAudit to Microsoft Sentinel, you have to click on Add Domain button below then you get a pop up to fill the details, provide the required information and click on Connect. You can see the usernames, actions connected in the grid.

Data Connectors Grid (configure in portal)

Snowflake (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Snowflake data connector provides the capability to ingest Snowflake Login History Logs, Query History Logs, User-Grant Logs, Role-Grant Logs, Load History Logs, Materialized View Refresh History Logs, Roles Logs, Tables Logs, Table Storage Metrics Logs, Users Logs into Microsoft Sentinel using the Snowflake SQL API. Refer to Snowflake SQL API documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SnowflakeLogin_CL Yes Yes

SnowflakeQuery_CL Yes Yes

SnowflakeUserGrant_CL Yes Yes

SnowflakeRoleGrant_CL Yes Yes

SnowflakeLoad_CL Yes Yes

SnowflakeMaterializedView_CL Yes Yes

SnowflakeRoles_CL Yes Yes

SnowflakeTables_CL Yes Yes

SnowflakeTableStorageMetrics_CL Yes Yes

SnowflakeUsers_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Snowflake to Microsoft Sentinel

NOTE: To ensure data is presented in separate columns for each field, execute the parser using the Snowflake() function

To gather data from Snowflake, you need to provide the following resources

Account Identifier To gather data from Snowflake, you'll need Snowflake Account Identifier.

Programmatic Access Token To gather data from Snowflake, you'll need the Snowflake Programmatic Access Token

For detailed instructions on retrieving the Account Identifier and Programmatic Access Token, please refer to the Connector Tutorial.

Data Connectors Grid (configure in portal)

SOC Prime Platform Audit Logs Data Connector

Supported by: SOC Prime

The SOC Prime Audit Logs data connector allows ingesting logs from the SOC Prime Platform API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework. It uses the SOC Prime Platform API to fetch SOC Prime platform audit logs and it supports DCR-based ingestion time transformations that parses the received security data into a custom table, thus resulting in better performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SOCPrimeAuditLogs_CL Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Configuration steps for the SOC Prime Platform API Follow the instructions to obtain the credentials. you can also follow this guide to generate personal API key.

Retrieve API Key

Log in to the SOC Prime Platform

Click [Account] icon -> [Platform Settings] -> [API]

Click [Add New Key]

In the modal that appears give your key a meaningful name, set expiration date and product APIs the key provides access to

Click on [Generate]

Copy the key and save it in a safe place. You won't be able to view it again once you close this modal

SOC Prime API Key: (API Key)

Enable/Disable Connection

Sonrai Data Connector

Supported by: N/A

Use this data connector to integrate with Sonrai Security and get Sonrai tickets sent directly to Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Sonrai_Tickets_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Sonrai Security Data Connector

Navigate to Sonrai Security dashboard.

On the bottom left panel, click on integrations.

Select Microsoft Sentinel from the list of available Integrations.

Fill in the form using the information provided below.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Sophos Endpoint Protection (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Sophos Endpoint Protection data connector provides the capability to ingest Sophos events and Sophos alerts into Microsoft Sentinel. Refer to Sophos Central Admin documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SophosEPEvents_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Sophos Endpoint Protection API access: Access to the Sophos Endpoint Protection API through a service principal is required.

Setup Instructions:

Connect to Sophos Endpoint Protection API to start collecting event and alert logs in Microsoft Sentinel

Follow Sophos instructions to create a service principal with access to the Sophos API. It will need the Service Principal ReadOnly role. Through those instructions, you should get the Client ID, Client Secret, Tenant ID and data region. Fill the form bellow with that information.

Sophos Tenant ID: (Sophos Tenant ID)

Sophos Tenant Data Region: (eu01, eu02, us01, us02 or us03)

Data Connectors Grid (configure in portal)

Symantec Integrated Cyber Defense Exchange

Supported by: Microsoft Corporation

Symantec ICDx connector allows you to easily connect your Symantec security solutions logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization’s network and improves your security operation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SymantecICDx_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Configure and connect Symantec ICDx

On the ICDx navigation bar, click Configuration.

At the top of the Configuration screen, click Forwarders, and next to Microsoft Sentinel (Log Analytics), click Add.

In the Microsoft Sentinel (Log Analytics) window that opens, click Show Advanced. See the documentation to set advanced features.

Make sure that you set a name for the forwarder and under Azure Destination, set these required fields:

Workspace ID: Paste the Workspace ID from the Microsoft Sentinel portal connector page.

Primary Key: Paste the Primary Key from the Microsoft Sentinel portal connector page.

Custom Log Name: Type the custom log name in the Microsoft Azure portal Log Analytics workspace to which you are going to forward events. The default is SymantecICDx.

Click Save and to start the forwarder, go to Options > More and click Start.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Synqly Integration Connector

Supported by: Synqly

The Synqly connector provides the capability to push security events from Synqly integrations into Microsoft Sentinel using the Azure Logs Ingestion API. Events are automatically normalized to ASIM (Advanced Security Information Model) tables for use with Microsoft Sentinel analytics, workbooks, and hunting queries.

Log Analytics table(s):

Table DCR support Lake-only ingestion

union ASimAuditEventLogs, ASimAuthenticationEventLogs, ASimDhcpEventLogs, ASimDnsActivityLogs, ASimFileEventLogs, ASimNetworkSessionLogs, ASimProcessEventLogs, ASimRegistryEventLogs, ASimUserManagementActivityLogs, ASimWebSessionLogs No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra ID: Application Developer role (or higher) to create app registrations.

Microsoft Azure: Owner or User Access Administrator role on the resource group to deploy DCR and assign Monitoring Metrics Publisher role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

This connector enables push-based ingestion of security events from Synqly integrations into Microsoft Sentinel. Events are automatically normalized to ASIM (Advanced Security Information Model) tables.

Deploy Connector Resources Clicking "Deploy" creates a Data Collection Rule (DCR), Data Collection Endpoint (DCE), and Entra application with the necessary permissions to securely send data to Microsoft Sentinel.

2. Grant Additional Permissions (Based on Use Case)

Additional roles may be required depending on how you plan to use Synqly with Microsoft Sentinel.

Sink Connector (Write-Only): No additional permissions needed. SIEM Connector (Read/Write): Assign Microsoft Sentinel Contributor role to the Entra application via the Azure UI in your Log Analytics workspace.

See Synqly documentation for detailed setup guides.

3. Push your logs into the workspace

Provide these parameters to your Synqly integration. The Synqly service will automatically handle the technical details of data ingestion, including formatting events to one of the 10 supported ASIM schemas (Authentication, AuditEvent, Dhcp, Dns, FileEvent, NetworkSession, ProcessEvent, RegistryEvent, UserManagement, WebSession).

Important: Events with unsupported schema types are silently dropped by Azure. If expected data is not appearing, verify with your Synqly integration provider that events are being sent with one of the supported schema types listed above.

Tenant ID (Directory ID): <variable value provided at install time>

Entra App Registration Application ID: <variable value provided at install time>

Entra App Registration Secret: <variable value provided at install time>

Data Collection Endpoint Uri: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

Stream Name: <variable value provided at install time>

Syslog via AMA

Supported by: Microsoft Corporation

Syslog is an event logging protocol that is common to Linux. Applications will send messages that may be stored on the local machine or delivered to a Syslog collector. When the Agent for Linux is installed, it configures the local Syslog daemon to forward messages to the agent. The agent then sends the message to the workspace.

Learn more >

Log Analytics table(s):

Table DCR support Lake-only ingestion

Syslog Yes Yes

Data collection rule support: Workspace transform DCR

TacitRed Compromised Credentials

Supported by: Data443 Risk Mitigation, Inc.

Ingest compromised credential findings from TacitRed using the Common Connector Framework (CCF).

Log Analytics table(s):

Table DCR support Lake-only ingestion

TacitRed_Findings_CL No No

Data collection rule support: Not currently supported

Prerequisites:

TacitRed API Key: API key stored in Azure Key Vault or provided at deployment time.

Setup Instructions:

Connect TacitRed Compromised Credentials

To enable the TacitRed connector, provide your API key below and click Connect.

For enhanced security, you can enable Key Vault integration to store and retrieve the API key.

TacitRed API Key: (Enter your TacitRed API key)

Enable/Disable Connection

Talon Insights

Supported by: Talon Security

The Talon Security Logs connector allows you to easily connect your Talon events and audit logs with Microsoft Sentinel, to view dashboards, create custom alerts, and improve investigation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Talon_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Please note the values below and follow the instructions here to connect your Talon Security events and audit logs with Microsoft Sentinel.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Team Cymru Scout Data Connector (using Azure Functions)

Supported by: Team Cymru

The TeamCymruScout Data Connector allows users to bring Team Cymru Scout IP, domain and account usage data in Microsoft Sentinel for enrichment.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Cymru_Scout_Domain_Data_CL No No

Cymru_Scout_IP_Data_Foundation_CL No No

Cymru_Scout_IP_Data_Details_CL No No

Cymru_Scout_IP_Data_Communications_CL No No

Cymru_Scout_IP_Data_PDNS_CL No No

Cymru_Scout_IP_Data_Fingerprints_CL No No

Cymru_Scout_IP_Data_OpenPorts_CL No No

Cymru_Scout_IP_Data_x509_CL No No

Cymru_Scout_IP_Data_Summary_Details_CL No No

Cymru_Scout_IP_Data_Summary_PDNS_CL No No

Cymru_Scout_IP_Data_Summary_OpenPorts_CL No No

Cymru_Scout_IP_Data_Summary_Certs_CL No No

Cymru_Scout_IP_Data_Summary_Fingerprints_CL No No

Cymru_Scout_Account_Usage_Data_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Permission to assign a role to the registered application: Permission to assign a role to the registered application in Microsoft Entra ID is required.

Team Cymru Scout Credentials/permissions: Team Cymru Scout account credentials(Username, Password) is required.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Team Cymru Scout API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Steps to Create Team Cymru Scout API Key

Follow these instructions to create a Team Cymru Scout API Key.

Refer to the API Keys document to generate an API key to use as an alternate form of authorization.

STEP 2 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of TeamCymruScout Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 3 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TeamCymruScout Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TeamCymruScout Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 4 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

STEP 5 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.

Go to Access control (IAM) from left panel.

Click on Add, and then select Add role assignment.

Select Contributor as role and click on next.

In Assign access to, select User, group, or service principal.

Click on add members and type your app name that you have created and select it.

Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 6 - Upload csv with indictaors in Watchlist

Follow the steps in this section to upload csv containing indicators in watchlist:

In the Azure portal, Go to Microsoft Sentinel and select your workspace.

Go to Watchlist under Configuration section from left panel.

Click on TeamCymruScoutDomainData, and then select Bulk update from Update watchlist.

Upload your csv files with domain indicators in Upload file input and click on Next: Review+Create.

Once validation is successful, click on Update.

Follow the same steps to update TeamCymruScoutIPData watchlist for ip indicators.

Reference link: Bulk update a watchlist

STEP 7 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the TeamCymruScout data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following) readily available.., as well as the TeamCymruScout Credentials.

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the TeamCymruScout data connector.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the below information : Location WorkspaceName Function Name TeamCymruScoutBaseURL AuthenticationType Username Password APIKey IPValues DomainValues APIType AzureClientId AzureClientSecret TenantId AzureEntraObjectId IPTableName DomainTableName AccountUsageTableName Schedule AccountUsageSchedule LogLevel

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the TeamCymruScout data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. CymruScoutXXXXX).

e. Select a runtime: Choose Python 3.12 or above.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following application settings individually, with their respective values (case-sensitive): CymruScoutBaseURL AuthenticationType TeamCymruScoutUsername TeamCymruScoutPassword APIKey IPValues DomainValues APIType AZURE_CLIENT_ID AZURE_CLIENT_SECRET AZURE_TENANT_ID IPTableName DomainTableName AccountUsageTableName Schedule AccountUsageSchedule LogLevel AZURE_DATA_COLLECTION_ENDPOINT AZURE_DATA_COLLECTION_RULE_ID_MAIN_TABLES AZURE_DATA_COLLECTION_RULE_ID_SUB_TABLES

Once all application settings have been entered, click Save.

Tenable Identity Exposure

Supported by: Tenable

Tenable Identity Exposure connector allows Indicators of Exposure, Indicators of Attack and trailflow logs to be ingested into Microsoft Sentinel.The different work books and data parsers allow you to more easily manipulate logs and monitor your Active Directory environment. The analytic templates allow you to automate responses regarding different events, exposures and attacks.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Tenable_IE_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Access to TenableIE Configuration: Permissions to configure syslog alerting engine

Setup Instructions:

This data connector depends on afad_parser based on a Kusto Function to work as expected which is deployed with the Microsoft Sentinel Solution.

1. Configure the Syslog server

You will first need a linux Syslog server that TenableIE will send logs to. Typically you can run rsyslog on Ubuntu. You can then configure this server as you wish, but it is recommended to be able to output TenableIE logs in a separate file.

Configure rsyslog to accept logs from your TenableIE IP address. Choose one of the following options:

Option 1: Using AllowedSender directive

This configuration restricts which hosts can send logs to your syslog server at the network level. It's more secure as it rejects unauthorized connections before processing them.

Download the configuration file: 80-tenable-allowedsender.conf

Run in sudo mode: sudo -i

Set your TenableIE IP address: export TENABLE_IE_IP={Enter your IP address}

Execute the commands from the downloaded configuration file

Restart rsyslog: systemctl restart rsyslog

Option 2: Filter logs by source IP (For environments with multiple syslog sources)

This configuration accepts all incoming logs but only processes those from the specified TenableIE IP address. It's particularly useful when you have multiple syslog servers or applications sending logs to the same syslog server, and you want to selectively process only TenableIE logs.

Download the configuration file: 80-tenable-filter.conf

Run in sudo mode: sudo -i

Set your TenableIE IP address: export TENABLE_IE_IP={Enter your IP address}

Execute the commands from the downloaded configuration file

Restart rsyslog: systemctl restart rsyslog

2. Install and onboard the Microsoft agent for Linux

The OMS agent will receive the TenableIE syslog events and publish it in Microsoft Sentinel :

Choose where to install the agent:

Install agent on Azure Linux Virtual Machine

Select the machine to install the agent on and then click Connect.

Install Agent: <variable value provided at install time>

Install agent on a non-Azure Linux Machine

Download the agent on the relevant machine and follow the instructions.

Install Agent: <variable value provided at install time>

3. Check agent logs on the Syslog server

tail -f /var/opt/microsoft/omsagent/log/omsagent.log

4. Configure TenableIE to send logs to your Syslog server

On your TenableIE portal, go to System, Configuration and then Syslog. From there you can create a new Syslog alert toward your Syslog server.

Once this is done, check that the logs are correctly gathered on your server in a separate file (to do this, you can use the Test the configuration button in the Syslog alert configuration in TenableIE). If you used the Quickstart template, the Syslog server will by default listen on port 514 in UDP and 1514 in TCP, without TLS.

Note: Both configuration options from Step 1 configure the syslog server to listen on port 514 for both UDP and TCP connections.

5. Configure the custom logs

Configure the agent to collect the logs.

In Microsoft Sentinel, go to Configuration -> Settings -> Workspace settings -> Custom logs.

Click Add custom log.

Upload a sample TenableIE.log Syslog file from the Linux machine running the Syslog server and click Next

Set the record delimiter to New Line if not already the case and click Next.

Select Linux and enter the file path to the Syslog file, click + then Next. The default location of the file is /var/log/TenableIE.log if you have a Tenable version <3.1.0, you must also add this linux file location /var/log/AlsidForAD.log.

Set the Name to Tenable_IE_CL (Azure automatically adds _CL at the end of the name, there must be only one, make sure the name is not Tenable_IE_CL_CL).

Click Next, you will see a resume, then click Create

6. Enjoy !

You should now be able to receive logs in the Tenable_IE_CL table, logs data can be parse using the afad_parser() function, used by all query samples, workbooks and analytic templates.

Tenable Vulnerability Management (using Azure Functions)

Supported by: Tenable

The TVM data connector provides the ability to ingest Asset, Vulnerability, Compliance, WAS assets and WAS vulnerabilities data into Microsoft Sentinel using TVM REST APIs. Refer to API documentation for more information. The connector provides the ability to get data which helps to examine potential security risks, get insight into your computing assets, diagnose configuration problems and more

Log Analytics table(s):

Table DCR support Lake-only ingestion

Tenable_VM_Asset_CL Yes Yes

Tenable_VM_Vuln_CL Yes Yes

Tenable_VM_Compliance_CL Yes Yes

Tenable_WAS_Asset_CL Yes Yes

Tenable_WAS_Vuln_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: Both a TenableAccessKey and a TenableSecretKey is required to access the Tenable REST API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials.

Setup Instructions:

NOTE: This connector uses Azure Durable Functions to connect to the TenableVM API to pull assets, vulnerabilities and compliance(if selected) at a regular interval into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a TenableVM parser for vulnerabilities and a TenableVM parser for assets based on a Kusto Function to work as expected which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for TenableVM

Follow the instructions to obtain the required API credentials.

STEP 2 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 3 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of TenableVM Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of TenableVM Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 4 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

STEP 5 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function App

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the TenableVM Vulnerability Management Report data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group, FunctionApp Name and Location.

Enter the below information :

a. WorkspaceName - Enter the Workspace Name of the log analytics Workspace.

b. TenableAccessKey - Enter Access key for using the Tenable API.

c. TenableSecretKey - Enter Tenable Secret Key for Authentication.

d. AzureClientID - Enter Azure Client ID.

e. AzureClientSecret - Enter Azure Client Secret.

f. TenantID - Enter Tenant ID got from above steps.

g. AzureEntraObjectId - Enter Azure Object ID got from above steps.

h. LowestSeveritytoStore - Lowest vulnerability severity to store. Allowed Values: Info, Low, Medium, High, Critical. Default is Info.

i. ComplianceDataIngestion - Select true if you want to enable Compliance data ingestion from Tenable VM. Default is false.

j. WASAssetDataIngestion - Select true if you want to enable WAS Asset data ingestion from Tenable VM. Default is false.

k. WASVulnerabilityDataIngestion - Select true if you want to enable WAS Vulnerability data ingestion from Tenable VM. Default is false.

l. LowestSeveritytoStoreWAS - The Lowest Vulnerability severity to store for WAS. Allowed Values: Info, Low, Medium, High, Critical. Default is Info.

m. TenableExportScheduleInMinutes - Schedule in minutes to create new export job from Tenable VM. Default is 1440.

n. AssetTableName - Enter name of the table used to store Asset Data logs.

o. VulnTableName - Enter name of the table used to store Vulnerability Data logs.

p. ComplianceTableName - Enter name of the table used to store Compliance Data logs.

q. WASAssetTableName - Enter name of the table used to store WAS Asset Data logs.

r. WASVulnTableName - Enter name of the table used to store WAS Vulnerability Data logs.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the TenableVM Vulnerability Management Report data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. TenableVMXXXXX).

e. Select a runtime: Choose Python 3.12.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive):

a. WorkspaceName - Enter the Workspace Name of the log analytics Workspace.

b. TenableAccessKey - Enter Access key for using the Tenable API.

c. TenableSecretKey - Enter Tenable Secret Key for Authentication.

d. AzureClientID - Enter Azure Client ID.

e. AzureClientSecret - Enter Azure Client Secret.

f. TenantID - Enter Tenant ID got from above steps.

g. AzureEntraObjectId - Enter Azure Object ID got from above steps.

h. LowestSeveritytoStore - Lowest vulnerability severity to store. Allowed Values: Info, Low, Medium, High, Critical. Default is Info.

i. ComplianceDataIngestion - Select true if you want to enable Compliance data ingestion from Tenable VM. Default is false.

j. WASAssetDataIngestion - Select true if you want to enable WAS Asset data ingestion from Tenable VM. Default is false.

k. WASVulnerabilityDataIngestion - Select true if you want to enable WAS Vulnerability data ingestion from Tenable VM. Default is false.

l. LowestSeveritytoStoreWAS - The Lowest Vulnerability severity to store for WAS. Allowed Values: Info, Low, Medium, High, Critical. Default is Info.

m. TenableExportScheduleInMinutes - Schedule in minutes to create new export job from Tenable VM. Default is 1440.

n. AssetTableName - Enter name of the table used to store Asset Data logs.

o. VulnTableName - Enter name of the table used to store Vulnerability Data logs.

p. ComplianceTableName - Enter name of the table used to store Compliance Data logs.

q. WASAssetTableName - Enter name of the table used to store WAS Asset Data logs.

r. WASVulnTableName - Enter name of the table used to store WAS Vulnerability Data logs.

s. PyTenableUAVendor - Value must be set to Microsoft.

t. PyTenableUAProduct - Value must be set to Microsoft Sentinel.

u. PyTenableUABuild - Value must be set to 3.1.0.

Once all application settings have been entered, click Save.

Tenant-based Microsoft Defender for Cloud

Supported by: Microsoft Corporation

Microsoft Defender for Cloud is a security management tool that allows you to detect and quickly respond to threats across Azure, hybrid, and multi-cloud workloads. This connector allows you to stream your MDC security alerts from Microsoft 365 Defender into Microsoft Sentinel, so you can can leverage the advantages of XDR correlations connecting the dots across your cloud resources, devices and identities and view the data in workbooks, queries and investigate and respond to incidents. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Connect Tenant-based Microsoft Defender for Cloud to Microsoft Sentinel

After connecting this connector, all your Microsoft Defender for Cloud subscriptions' alerts will be sent to this Microsoft Sentinel workspace.

Your Microsoft Defender for Cloud alerts are connected to stream through the Microsoft 365 Defender. To benefit from automated grouping of the alerts into incidents, connect the Microsoft 365 Defender incidents connector. Incidents can be viewed in the incidents queue.

TheHive (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The TheHive data connector provides the capability to ingest TheHive security incident response platform data into Microsoft Sentinel through the REST API. Refer to API documentation for more information. The connector provides the ability to get cases, tasks, and alerts from TheHive and visualize them in Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

TheHiveData No No

Data collection rule support: Not currently supported

Prerequisites:

TheHive API access: TheHive API Version 4 and above access is required for the TheHive API.

Setup Instructions:

1. Configuration

Follow the instructions to configure the TheHive connector.

TheHive Base URL: (TheHive instance base URL (e.g., https://thehive.example.com)) Get the API Key from your TheHive user profile settings. (or a dedicated user created for this purpose)

Api Key: (API key for TheHive API)

2. Connect

Enable the TheHive connector.

Enable/Disable Connection

Theom

Supported by: Theom

Theom Data Connector enables organizations to connect their Theom environment to Microsoft Sentinel. This solution enables users to receive alerts on data security risks, create and enrich incidents, check statistics and trigger SOAR playbooks in Microsoft Sentinel

Log Analytics table(s):

Table DCR support Lake-only ingestion

TheomAlerts_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

In Theom UI Console click on Manage -> Alerts on the side bar.

Select Sentinel tab.

Click on Active button to enable the configuration.

Enter Primary key as Authorization Token

Enter Endpoint URL as https://<Workspace ID>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01

Click on SAVE SETTINGS

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Threat intelligence - TAXII

Supported by: Microsoft Corporation

Microsoft Sentinel integrates with TAXII 2.0 and 2.1 data sources to enable monitoring, alerting, and hunting using your threat intelligence. Use this connector to send the supported STIX object types from TAXII servers to Microsoft Sentinel. Threat indicators can include IP addresses, domains, URLs, and file hashes. For more information, see the Microsoft Sentinel documentation >.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Threat Intelligence Platforms

Supported by: Microsoft Corporation

Microsoft Sentinel integrates with Microsoft Graph Security API data sources to enable monitoring, alerting, and hunting using your threat intelligence. Use this connector to send threat indicators to Microsoft Sentinel from your Threat Intelligence Platform (TIP), such as Threat Connect, Palo Alto Networks MindMeld, MISP, or other integrated applications. Threat indicators can include IP addresses, domains, URLs, and file hashes. For more information, see the Microsoft Sentinel documentation >.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Threat Intelligence Upload API (Preview)

Supported by: Microsoft Corporation

Microsoft Sentinel offers a data plane API to bring in threat intelligence from your Threat Intelligence Platform (TIP), such as Threat Connect, Palo Alto Networks MineMeld, MISP, or other integrated applications. Threat indicators can include IP addresses, domains, URLs, file hashes and email addresses. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Setup Instructions:

**You can connect your threat intelligence data sources to Microsoft Sentinel by either: **

Using an integrated Threat Intelligence Platform (TIP), such as Threat Connect, Palo Alto Networks MineMeld, MISP, and others.

Calling the Microsoft Sentinel data plane API directly from another application.

Note: The 'Status' of the connector will not appear as 'Connected' here, because the data is ingested by making an API call.

**Follow These Steps to Connect to your Threat Intelligence: **

1. Get Microsoft Entra ID Access Token

To send request to the APIs, you need to acquire Microsoft Entra ID access token. You can follow instruction in this page: /azure/databricks/dev-tools/api/latest/aad/app-aad-token#get-an-azure-ad-access-token

Notice: Please request Microsoft Entra ID access token with scope value: [variables('managementUri')]

2. Send STIX objects to Sentinel

You can send the supported STIX object types by calling our Upload API. For more information about the API, click here.

HTTP method: POST

Endpoint: https://api.ti.sentinel.azure.com/workspaces/[WorkspaceID]/threatintelligence-stix-objects:upload?api-version=2024-02-01-preview

WorkspaceID: the workspace that the STIX objects are uploaded to.

Header Value 1: "Authorization" = "Bearer [Microsoft Entra ID Access Token from step 1]"

Header Value 2: "Content-Type" = "application/json"

Body: The body is a JSON object containing an array of STIX objects.

Transmit Security Connector (using Azure Functions)

Supported by: Transmit Security

The [Transmit Security] data connector provides the capability to ingest common Transmit Security API events into Microsoft Sentinel through the REST API. Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

TransmitSecurityActivity_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Client ID: TransmitSecurityClientID is required. See the documentation to learn more about API on the https://developer.transmitsecurity.com/.

REST API Client Secret: TransmitSecurityClientSecret is required. See the documentation to learn more about API on the https://developer.transmitsecurity.com/.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Transmit Security API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Transmit Security API

Follow the instructions to obtain the credentials.

Log in to the Transmit Security Portal.

Configure a management app. Give the app a suitable name, for example, MyAzureSentinelCollector.

Save credentials of the new user for using in the data connector.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Transmit Security data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Transmit Security data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group, and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select an existing resource group without Windows apps in it or create a new resource group.

Enter the TransmitSecurityClientID, TransmitSecurityClientSecret, TransmitSecurityPullEndpoint, TransmitSecurityTokenEndpoint, and deploy.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Transmit Security data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS Code for Azure function development.

Download the Azure Function App file. Extract the archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top-level folder from the extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button.

If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure.

If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option).

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions.

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs, choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to the Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

Select Environment variables.

Add each of the following application settings individually, with their respective string values (case-sensitive):

TransmitSecurityClientID

TransmitSecurityClientSecret

TransmitSecurityPullEndpoint

TransmitSecurityTokenEndpoint

WorkspaceID

WorkspaceKey

logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for a dedicated cloud. For example, for the public cloud, leave the value empty; for the Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Apply.

Trellix Endpoint Security (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Trellix Endpoint Security data connector enables you to ingest security events from Trellix ePO (ePolicy Orchestrator) into Microsoft Sentinel. This connector uses OAuth2 client credentials authentication and automatically handles pagination to collect comprehensive endpoint security data including threat detections, analyzer information, source and target system details, and threat response actions.

Log Analytics table(s):

Table DCR support Lake-only ingestion

TrellixEvents No No

Data collection rule support: Not currently supported

Setup Instructions:

1. API Configuration

Configure your Trellix ePO API connection.

API Base URL: (https://api.manage.trellix.com) Authentication

Provide your API key for authentication. This will be sent in the x-api-key header.

API Key: (Enter your API key)

Note: The API key will be securely stored and used for authentication with the Trellix ePO API.

2. Authentication Configuration

Configure OAuth2 authentication credentials.

Token endpoint: (https://iam.cloud.trellix.com/iam/v1.0/token) OAuth2 Configuration Configure OAuth2 client credentials for API access. Read about the Trellix API authorization model at https://developer.manage.trellix.com/public/mvision/docs/umam

Client ID: (Your client ID)

Client Secret: (Your client secret)

Note: OAuth2 authentication provides secure access to your API endpoints.

3. Enable Connector

Activate the Trellix Endpoint Security connector

Connector Activation

Review your configuration and enable the connector to start collecting security events.

Enable/Disable Connection Post-Connection

After connecting, monitor the connector status in the Data connectors page. Data should begin appearing within 5-10 minutes.

Trend Vision One (using Azure Functions)

Supported by: Trend Micro

The Trend Vision One connector allows you to easily connect your Workbench alert data with Microsoft Sentinel to view dashboards, create custom alerts, and to improve monitoring and investigation capabilities. This gives you more insight into your organization's networks/systems and improves your security operation capabilities.

The Trend Vision One connector is supported in Microsoft Sentinel in the following regions: Australia East, Australia Southeast, Brazil South, Canada Central, Canada East, Central India, Central US, East Asia, East US, East US 2, France Central, Japan East, Korea Central, North Central US, North Europe, Norway East, South Africa North, South Central US, Southeast Asia, Sweden Central, Switzerland North, UAE North, UK South, UK West, West Europe, West US, West US 2, West US 3.

Log Analytics table(s):

Table DCR support Lake-only ingestion

TrendMicro_XDR_WORKBENCH_CL No No

TrendMicro_XDR_RCA_Task_CL No No

TrendMicro_XDR_RCA_Result_CL No No

TrendMicro_XDR_OAT_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Trend Vision One API Token: A Trend Vision One API Token is required. See the documentation to learn more about the Trend Vision One API.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Trend Vision One API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Trend Vision One API

Follow these instructions to create an account and an API authentication token.

STEP 2 - Use the below deployment option to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Trend Vision One connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Trend Vision One API Authorization Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template Deployment

This method provides an automated deployment of the Trend Vision One connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter a unique Function Name, Workspace ID, Workspace Key, API Token and Region Code.

Note: Provide the appropriate region code based on where your Trend Vision One instance is deployed: us, eu, au, in, sg, jp

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Tropico Security - Alerts

Supported by: TROPICO Security

Ingest security alerts from Tropico Security Platform in OCSF Security Finding format.

Log Analytics table(s):

Table DCR support Lake-only ingestion

{{graphQueriesTableName}} No No

Data collection rule support: Not currently supported

Setup Instructions:

Connect Tropico Security Platform

Enter your read-only API key from Tropico Settings.

API Key: (trop_xxxx...)

Enable/Disable Connection

Tropico Security - Events

Supported by: TROPICO Security

Ingest security events from Tropico Security Platform in OCSF Security Finding format.

Log Analytics table(s):

Table DCR support Lake-only ingestion

{{graphQueriesTableName}} No No

Data collection rule support: Not currently supported

Setup Instructions:

Connect Tropico Security Platform

Enter your read-only API key from Tropico Settings.

API Key: (trop_xxxx...)

Enable/Disable Connection

Tropico Security - Incidents

Supported by: TROPICO Security

Ingest attacker session incidents from Tropico Security Platform.

Log Analytics table(s):

Table DCR support Lake-only ingestion

{{graphQueriesTableName}} No No

Data collection rule support: Not currently supported

Setup Instructions:

Connect Tropico Security Platform

Enter your read-only API key from Tropico Settings.

API Key: (trop_xxxx...)

Enable/Disable Connection

Upwind Logs Loader (Ingestion API)

Supported by: Upwind

The Upwind Logs Loader data connector ingests compute platform assets from the Upwind cloud security platform into a Microsoft Sentinel custom table using an Azure Function and the Azure Monitor Ingestion API (DCE/DCR).

Upwind provides runtime-powered cloud security, correlating cloud posture with live workload context. This connector surfaces your Upwind inventory — compute platform assets across AWS, GCP, and Azure — directly into Microsoft Sentinel for correlation, hunting, and incident enrichment.

Log Analytics table(s):

Table DCR support Lake-only ingestion

UpwindLogsAssets_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Upwind API Credentials: An Upwind API client ID and client secret are required. Obtain these from your Upwind platform under Settings → API Keys. The client credentials are used to authenticate against https://auth.upwind.io/oauth/token to obtain a bearer token.

Upwind Organization ID: Your Upwind Organization ID is required. Find it in the Upwind platform under Settings → Organization.

Setup Instructions:

NOTE: This connector uses Azure Functions and the Azure Monitor Ingestion API (DCE/DCR) to push Upwind logs into Microsoft Sentinel. The ARM template automatically creates the Data Collection Endpoint, custom log table (UpwindLogsAssets_CL), Data Collection Rule, and role assignment. This might result in additional data ingestion costs. Check the Azure Functions pricing page and Azure Monitor pricing page for details.

(Optional) During deployment, choose Key Vault as the authentication method to securely store your Upwind client secret. You can provide an existing Key Vault name or let the template create a new one. A user-assigned managed identity is automatically configured with the required Key Vault access policies.

STEP 1 – Obtain Upwind API credentials

Log in to the Upwind platform.

Navigate to Settings → API Keys.

Create a new API key and note the Client ID and Client Secret.

Navigate to Settings → Organization and note your Organization ID.

STEP 2 – Deploy the Azure Function App

Click Deploy to Azure and fill in the parameters. The template automatically creates the DCE, UpwindLogs_CL table, DCR, role assignment, and Function App.

aka.ms

Parameters to fill in:

Parameter Description

WorkspaceName Name of your Log Analytics / Microsoft Sentinel workspace

UpwindOrgId Upwind Organization ID from Step 1

UpwindClientId Upwind API Client ID from Step 1

UpwindClientSecret Upwind API Client Secret from Step 1

AppInsightsWorkspaceResourceID Full Resource ID of the Log Analytics workspace (from Log Analytics workspace → Properties)

Workspace ID: <variable value provided at install time>

Vaikora AI Agent Behavioral Signals

Supported by: Data443 Risk Mitigation, Inc.

Ingest AI agent behavioral signals from the Vaikora API into Microsoft Sentinel using the Codeless Connector Framework (CCF). Monitor agent actions, policy decisions, anomaly scores, and risk levels to detect suspicious AI activity in your environment.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Vaikora_AgentSignals_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Vaikora API Key: A Vaikora API key (vk_xxxxx) with read access to the actions endpoint. Obtain this from your Vaikora dashboard under Settings > API Keys.

Setup Instructions:

Connect Vaikora AI Agent Behavioral Signals

To enable the Vaikora connector, enter your Vaikora API key below and click Connect. The Agent ID is optional; use it to scope ingestion to a single agent, or leave it blank to ingest actions from all agents the key can see.

Your API key is available in the Vaikora dashboard under Settings > API Keys. The Agent ID is the UUID shown on each agent's detail page.

Vaikora API Key: (vk_xxxxxxxxxxxxxxxxxxxxxxxx)

Vaikora Agent ID (optional): (Leave blank to monitor all agents)

Enable/Disable Connection

Valimail Enforce Configuration Events

Supported by: Valimail

The Valimail Configuration Events data connector allows ingesting email domain's configuration events from the Valimail's Reporting API into Microsoft Sentinel. The data connector is built on Microsoft Sentinel Codeless Connector Framework.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ValimailEnforceEvents_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Configuration steps for the Valimail Events API Follow the instructions in the guide to generate a set of Reporting API credentials. Store the created Client ID and the App ID keys.

Client Account Slug: (Account slug)

API Client Id: (Client Id Credential)

API App Id: (App Id Credential)

Enable/Disable Connection

Varonis Purview Push Connector

Supported by: Varonis

The Varonis Purview connector provides the capability to sync resources from Varonis to Microsoft Purview.

Log Analytics table(s):

Table DCR support Lake-only ingestion

VaronisResources_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role

Setup Instructions:

1. Run this to setup ingestion for Varonis Resoources

This will create the necessary Log Analytics tables, Data Collection Rule (DCR), and an Entra application to securely send data to the DCR.

Automated Configuration and Secure Data Ingestion with Entra Application Clicking on "Deploy" will trigger the creation of Log Analytics tables and a Data Collection Rule (DCR). It will then create an Entra application, link the DCR to it, and set the entered secret in the application. This setup enables data to be sent securely to the DCR using an Entra token.

2. Push your logs into the workspace

Use the following parameters to configure the Varonis Purview Connector in your Varonis integrations dashboard.

Tenant ID (Directory ID): <variable value provided at install time>

Entra App Registration Application ID: <variable value provided at install time>

Entra App Registration Secret: <variable value provided at install time>

Data Collection Endpoint Uri: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

Resources Stream Name: <variable value provided at install time>

Varonis SaaS

Supported by: Varonis

Varonis SaaS provides the capability to ingest Varonis Alerts into Microsoft Sentinel.

Varonis prioritizes deep data visibility, classification capabilities, and automated remediation for data access. Varonis builds a single prioritized view of risk for your data, so you can proactively and systematically eliminate risk from insider threats and cyberattacks.

Log Analytics table(s):

Table DCR support Lake-only ingestion

VaronisAlerts_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to Varonis DatAlert service to pull alerts into Microsoft Sentinel. This might result in additional data ingestion costs. See the Azure Functions pricing page for details.

For Azure function and related services installation use:

portal.azure.com

STEP 1 - Obtain the Varonis DatAlert Endpoint API credentials.

To generate the Client ID and API key:

Launch the Varonis Web Interface.

Navigate to Configuration -> API Keys. The API Keys page is displayed.

Click Create API Key. The Add New API Key settings are displayed on the right.

Fill in the name and description.

Click the Generate Key button.

Copy the API key secret and save it in a handy location. You won't be able to copy it again.

For additional information, please check: Varonis Documentation

STEP 2 - Deploy the connector and the associated Azure Function.

Workspace Name: <variable value provided at install time>

Use this method for automated deployment of the data connector using an ARM Template.

Click the Deploy to Azure button.

portal.azure.com

Select the preferred Subscription, Resource Group, Region, Storage Account Type.

Enter Log Analytics Workspace Name, Varonis FQDN, Varonis SaaS API Key.

Click Review + Create, Create.

Vectra XDR (using Azure Functions)

Supported by: Vectra Support

The Vectra XDR connector gives the capability to ingest Vectra Detections, Audits, Entity Scoring, Lockdown, Health and Entities data into Microsoft Sentinel through the Vectra REST API. Refer to the API documentation: https://support.vectra.ai/s/article/KB-VS-1666 for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Detections_Data_CL Yes Yes

Audits_Data_CL Yes Yes

Entity_Scoring_Data_CL Yes Yes

Lockdown_Data_CL Yes Yes

Health_Data_CL Yes Yes

Entities_Data_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: Vectra Client ID and Client Secret is required for Health, Entity Scoring, Entities, Detections, Lockdown and Audit data collection. See the documentation to learn more about API on the https://support.vectra.ai/s/article/KB-VS-1666.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Vectra API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Follow these steps for Detections Parser, Audits Parser, Entity Scoring Parser, Lockdown Parser and Health Parser to create the Kusto functions alias, VectraDetections, VectraAudits, VectraEntityScoring, VectraLockdown and VectraHealth.

STEP 1 - Configuration steps for the Vectra API Credentials

Follow these instructions to create a Vectra Client ID and Client Secret.

Log into your Vectra portal

Navigate to Manage -> API Clients

From the API Clients page, select 'Add API Client' to create a new client.

Add Client Name, select Role and click on Generate Credentials to obtain your client credentials.

Be sure to record your Client ID and Secret Key for safekeeping. You will need these two pieces of information to obtain an access token from the Vectra API. An access token is required to make requests to all of the Vectra API endpoints.

STEP 2 - App Registration steps for the Application in Microsoft Entra ID

This integration requires an App registration in the Azure portal. Follow the steps in this section to create a new application in Microsoft Entra ID:

Sign in to the Azure portal.

Search for and select Microsoft Entra ID.

Under Manage, select App registrations > New registration.

Enter a display Name for your application.

Select Register to complete the initial app registration.

When registration finishes, the Azure portal displays the app registration's Overview pane. You see the Application (client) ID and Tenant ID. The client ID and Tenant ID is required as configuration parameters for the execution of Vectra Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app

STEP 3 - Add a client secret for application in Microsoft Entra ID

Sometimes called an application password, a client secret is a string value required for the execution of Vectra Data Connector. Follow the steps in this section to create a new Client Secret:

In the Azure portal, in App registrations, select your application.

Select Certificates & secrets > Client secrets > New client secret.

Add a description for your client secret.

Select an expiration for the secret or specify a custom lifetime. Limit is 24 months.

Select Add.

Record the secret's value for use in your client application code. This secret value is never displayed again after you leave this page. The secret value is required as configuration parameter for the execution of Vectra Data Connector.

Reference link: /azure/active-directory/develop/quickstart-register-app#add-a-client-secret

STEP 4 - Get Object ID of your application in Microsoft Entra ID

After creating your app registration, follow the steps in this section to get Object ID:

Go to Microsoft Entra ID.

Select Enterprise applications from the left menu.

Find your newly created application in the list (you can search by the name you provided).

Click on the application.

On the overview page, copy the Object ID. This is the AzureEntraObjectId needed for your ARM template role assignment.

STEP 5 - Assign role of Contributor to application in Microsoft Entra ID

Follow the steps in this section to assign the role:

In the Azure portal, Go to Resource Group and select your resource group.

Go to Access control (IAM) from left panel.

Click on Add, and then select Add role assignment.

Select Contributor as role and click on next.

In Assign access to, select User, group, or service principal.

Click on add members and type your app name that you have created and select it.

Now click on Review + assign and then again click on Review + assign.

Reference link: /azure/role-based-access-control/role-assignments-portal

STEP 6 - Create a Keyvault

Follow these instructions to create a new Keyvault.

In the Azure portal, Go to Key vaults and click on Create.

Select Subsciption, Resource Group and provide unique name of keyvault.

STEP 7 - Create Access Policy in Keyvault

Follow these instructions to create access policy in Keyvault.

Go to keyvaults, select your keyvault, go to Access policies on left side panel, click on create.

Select all keys & secrets permissions. Click next.

In the principal section, search by application name which was generated in STEP - 2. Click next.

Note: Ensure the Permission model in the Access Configuration of Key Vault is set to 'Vault access policy'

STEP 8 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Vectra data connector, have the Vectra API Authorization Credentials readily available..

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Vectra connector.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the below information : Function Name Workspace Name Vectra Base URL (https://<vectra-portal-url>) Vectra Client Id - Health Vectra Client Secret Key - Health Vectra Client Id - Entity Scoring Vectra Client Secret - Entity Scoring Vectra Client Id - Detections Vectra Client Secret - Detections Vectra Client Id - Audits Vectra Client Secret - Audits Vectra Client Id - Lockdown Vectra Client Secret - Lockdown Vectra Client Id - Host-Entity Vectra Client Secret - Host-Entity Vectra Client Id - Account-Entity Vectra Client Secret - Account-Entity Key Vault Name Azure Client Id Azure Client Secret Tenant Id Azure Entra ObjectID StartTime (in MM/DD/YYYY HH:MM:SS Format) Include Score Decrease Audits Table Name Detections Table Name Entity Scoring Table Name Lockdown Table Name Health Table Name Entities Table Name Exclude Group Details From Detections Log Level (Default: INFO) Lockdown Schedule Health Schedule Detections Schedule Audits Schedule Entity Scoring Schedule Entities Schedule

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Vectra data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. VECTRAXXXXX).

e. Select a runtime: Choose Python 3.8 or above.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following application settings individually, with their respective values (case-sensitive): Workspace ID Workspace Key Vectra Base URL (https://<vectra-portal-url>) Vectra Client Id - Health Vectra Client Secret Key - Health Vectra Client Id - Entity Scoring Vectra Client Secret - Entity Scoring Vectra Client Id - Detections Vectra Client Secret - Detections Vectra Client Id - Audits Vectra Client Secret - Audits Vectra Client Id - Lockdown Vectra Client Secret - Lockdown Vectra Client Id - Host-Entity Vectra Client Secret - Host-Entity Vectra Client Id - Account-Entity Vectra Client Secret - Account-Entity Key Vault Name Azure Client Id Azure Client Secret Tenant Id StartTime (in MM/DD/YYYY HH:MM:SS Format) Include Score Decrease Audits Table Name Detections Table Name Entity Scoring Table Name Lockdown Table Name Health Table Name Entities Table Name Log Level (Default: INFO) Lockdown Schedule Health Schedule Detections Schedule Audits Schedule Entity Scoring Schedule Entities Schedule logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Veeam Data Connector (using Azure Functions)

Supported by: Veeam Software

Veeam Data Connector allows you to ingest Veeam telemetry data from multiple custom tables into Microsoft Sentinel.

The connector supports integration with Veeam Backup & Replication, Veeam ONE and Coveware platforms to provide comprehensive monitoring and security analytics. The data is collected through Azure Functions and stored in custom Log Analytics tables with dedicated Data Collection Rules (DCR) and Data Collection Endpoints (DCE).

Custom Tables Included:

VeeamMalwareEvents_CL: Malware detection events from Veeam Backup & Replication

VeeamSecurityComplianceAnalyzer_CL: Security & Compliance Analyzer results collected from Veeam backup infrastructure components

VeeamAuthorizationEvents_CL: Authorization and authentication events

VeeamOneTriggeredAlarms_CL: Triggered alarms from Veeam ONE servers

VeeamCovewareFindings_CL: Security findings from Coveware solution

VeeamSessions_CL: Veeam sessions

Log Analytics table(s):

Table DCR support Lake-only ingestion

VeeamMalwareEvents_CL Yes Yes

VeeamSecurityComplianceAnalyzer_CL Yes Yes

VeeamOneTriggeredAlarms_CL Yes Yes

VeeamAuthorizationEvents_CL Yes Yes

VeeamCovewareFindings_CL Yes Yes

VeeamSessions_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Veeam Infrastructure Access: Access to Veeam Backup & Replication REST API and Veeam ONE monitoring platform is required. This includes proper authentication credentials and network connectivity.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to Veeam APIs and pull data into Microsoft Sentinel custom tables. This may result in additional data ingestion costs. See the Azure Functions pricing page for details.

STEP 1 - Select the deployment option for Veeam Data Connector and associated Azure Functions

IMPORTANT: Before you deploy Veeam Data Connector, prepare Workspace Name (can be copied from the following).

Workspace Name: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Veeam data connector using an ARM Template.

Click the Deploy to Azure button below.

portal.azure.com

Select the preferred Subscription, Resource Group and Location.

Enter the Microsoft Sentinel Workspace Name.

Click Review + Create, Create.

VersasecCms

Supported by: Versasec Support

The VersasecCms data connector allows ingesting logs into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

VersasecCmsSysLogs_CL No No

VersasecCmsErrorLogs_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Configuration

Enter credentials for VersasecCms.

Management URL:

API Base Path:

API Token:

Polling Interval (Minutes):

Enable/Disable Connection

VirtualMetric DataStream for Microsoft Sentinel

Supported by: VirtualMetric

VirtualMetric DataStream connector deploys Data Collection Rules to ingest security telemetry into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CommonSecurityLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

App Registration or Azure Managed Identity: VirtualMetric DataStream requires an Entra ID identity to authenticate and send logs to Microsoft Sentinel. You can choose between creating an App Registration with Client ID and Client Secret, or using Azure Managed Identity for enhanced security without credential management.

Resource Group Role Assignment: The chosen identity (App Registration or Managed Identity) must be assigned to the resource group containing the Data Collection Endpoint with the following roles: Monitoring Metrics Publisher (for log ingestion) and Monitoring Reader (for reading stream configuration).

Setup Instructions:

Configure VirtualMetric DataStream for Microsoft Sentinel

Configure the VirtualMetric DataStream for Microsoft Sentinel to send data.

Register Application in Microsoft Entra ID (Optional)

Choose your authentication method: Option A: Use Azure Managed Identity (Recommended)

Skip this step if you plan to use Azure Managed Identity for authentication.

Azure Managed Identity provides a more secure authentication method without managing credentials.

Option B: Register a Service Principal Application

Open the Microsoft Entra ID page:

Click the provided link to open the Microsoft Entra ID registration page in a new tab.

Ensure you are logged in with an account that has Application Administrator or Global Administrator permissions.

Create a New Application:

In the Microsoft Entra ID portal, select App registrations from the left-hand navigation.

Click on + New registration.

Fill out the following fields:

Name: Enter a descriptive name for the app (e.g., "VirtualMetric ASIM Connector").

Supported account types: Choose Accounts in this organizational directory only (Single tenant).

Redirect URI: Leave this blank.

Click Register to create the application.

Copy Application and Tenant IDs:

Once the app is registered, note the Application (client) ID and Directory (tenant) ID from the Overview page. You'll need these for VirtualMetric DataStream configuration.

Create a Client Secret:

In the Certificates & secrets section, click + New client secret.

Add a description (e.g., 'VirtualMetric ASIM Secret') and set an appropriate expiration period.

Click Add.

Copy the client secret value immediately, as it will not be shown again. Store this securely for VirtualMetric DataStream configuration.

Assign Required Permissions

Assign the required roles to your chosen authentication method (Service Principal or Managed Identity) in the resource group.

For Service Principal (if you completed Step 1):

Navigate to Your Resource Group:

Open the Azure Portal and navigate to the Resource Group that contains your Log Analytics Workspace and where Data Collection Rules (DCRs) will be deployed.

Assign the Monitoring Metrics Publisher Role:

In the Resource Group, click on Access control (IAM) from the left-hand menu.

Click + Add and select Add role assignment.

In the Role tab, search for and select Monitoring Metrics Publisher.

Click Next to go to the Members tab.

Under Assign access to, select User, group, or service principal.

Click + Select members and search for your registered application by name or client ID.

Select your application and click Select.

Click Review + assign twice to complete the assignment.

Assign the Monitoring Reader Role:

Repeat the same process to assign the Monitoring Reader role:

Click + Add and select Add role assignment.

In the Role tab, search for and select Monitoring Reader.

Follow the same member selection process as above.

Click Review + assign twice to complete the assignment. For Azure Managed Identity:

Create or Identify Your Managed Identity:

If using System-assigned Managed Identity: Enable it on your Azure resource (VM, App Service, etc.).

If using User-assigned Managed Identity: Create one in your resource group if it doesn't exist.

Assign the Monitoring Metrics Publisher Role:

Follow the same steps as above, but in the Members tab:

Under Assign access to, select Managed identity.

Click + Select members and choose the appropriate managed identity type and select your identity.

Click Select, then Review + assign twice to complete.

Assign the Monitoring Reader Role:

Repeat the process to assign the Monitoring Reader role to the same managed identity. Required Permission Summary: The assigned roles provide the following capabilities:

Monitoring Metrics Publisher: Write data to Data Collection Endpoints (DCE) and send telemetry through Data Collection Rules (DCR)

Monitoring Reader: Read stream configuration and access Log Analytics workspace for ASIM table ingestion

Deploy Azure Infrastructure

Deploy the required Data Collection Endpoint (DCE) and Data Collection Rules (DCR) for Microsoft Sentinel tables using our ARM template.

Deploy to Azure:

Click the Deploy to Azure button below to automatically deploy the required infrastructure:

portal.azure.com

This will take you directly to the Azure portal to start the deployment.

Configure Deployment Parameters:

On the custom deployment page, configure the following settings:

Project details:

Subscription: Select your Azure subscription from the dropdown

Resource group: Select an existing resource group or click Create new to create a new one Instance details:

Region: Select the Azure region where your Log Analytics workspace is located (e.g., West Europe)

Workspace: Enter your Log Analytics workspace name

DCE Name: Provide a name for the Data Collection Endpoint (e.g., "vmetric-dce")

DCR Name Prefix: Provide a prefix for the Data Collection Rules (e.g., "vmetric-dcr")

Complete the Deployment:

Click Review + create to validate the template.

Review the parameters and click Create to deploy the resources.

Wait for the deployment to complete (typically takes 2-5 minutes).

Verify Deployed Resources:

After deployment, verify the following resources were created:

Data Collection Endpoint (DCE): Check Azure Portal > Monitor > Data Collection Endpoints

Data Collection Rules (DCRs): Check Azure Portal > Monitor > Data Collection Rules

Copy the DCE Logs Ingestion URI from the DCE Overview page (format: https://<dce-name>.<region>.ingest.monitor.azure.com)

Copy the DCE Resource ID from the DCE Overview page (format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Insights/dataCollectionEndpoints/<dce-name>)

For each DCR, note the Immutable ID from the Overview page - you'll need these for VirtualMetric DataStream configuration.

Configure VirtualMetric DataStream Integration

Set up VirtualMetric DataStream to send security telemetry to Microsoft Sentinel tables.

Access VirtualMetric DataStream Configuration:

Log into your VirtualMetric DataStream management console.

Navigate to Fleet Management > Targets section.

Click Add new target button.

Select Microsoft Sentinel target.

Configure General Settings:

Name: Enter a name for your target (e.g., "cus01-ms-sentinel")

Description: Optionally provide a description for the target configuration

Configure Azure Authentication (choose based on Step 1): For Service Principal Authentication:

Managed Identity for Azure: Keep Disabled

Tenant ID: Enter the Directory (tenant) ID from Step 1

Client ID: Enter the Application (client) ID from Step 1

Client Secret: Enter the client secret value from Step 1 For Azure Managed Identity:

Managed Identity for Azure: Set to Enabled

Configure Stream Properties:

Endpoint: Choose your configuration method:

For manual stream configuration: Enter the DCE Logs Ingestion URI (format: https://<dce-name>.<region>.ingest.monitor.azure.com)

For auto stream detection: Enter the DCE Resource ID (format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Insights/dataCollectionEndpoints/<dce-name>)

Streams: Select Auto for automatic stream detection, or configure specific streams if needed

Verify Data Ingestion in Microsoft Sentinel:

Return to your Log Analytics Workspace

Run sample queries on the ASIM tables to confirm data is being received:
ASimNetworkSessionLogs | where TimeGenerated > ago(1h) | take 10

Check the Microsoft Sentinel Overview dashboard for new data sources and event counts.

VirtualMetric DataStream for Microsoft Sentinel data lake

Supported by: VirtualMetric

VirtualMetric DataStream connector deploys Data Collection Rules to ingest security telemetry into Microsoft Sentinel data lake.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CommonSecurityLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

App Registration or Azure Managed Identity: VirtualMetric DataStream requires an Entra ID identity to authenticate and send logs to Microsoft Sentinel data lake. You can choose between creating an App Registration with Client ID and Client Secret, or using Azure Managed Identity for enhanced security without credential management.

Resource Group Role Assignment: The chosen identity (App Registration or Managed Identity) must be assigned to the resource group containing the Data Collection Endpoint with the following roles: Monitoring Metrics Publisher (for log ingestion) and Monitoring Reader (for reading stream configuration).

Setup Instructions:

Configure VirtualMetric DataStream for Microsoft Sentinel data lake

Configure the VirtualMetric DataStream for Microsoft Sentinel data lake to send data.

Register Application in Microsoft Entra ID (Optional)

Choose your authentication method: Option A: Use Azure Managed Identity (Recommended)

Skip this step if you plan to use Azure Managed Identity for authentication.

Azure Managed Identity provides a more secure authentication method without managing credentials.

Option B: Register a Service Principal Application

Open the Microsoft Entra ID page:

Click the provided link to open the Microsoft Entra ID registration page in a new tab.

Ensure you are logged in with an account that has Application Administrator or Global Administrator permissions.

Create a New Application:

In the Microsoft Entra ID portal, select App registrations from the left-hand navigation.

Click on + New registration.

Fill out the following fields:

Name: Enter a descriptive name for the app (e.g., "VirtualMetric ASIM Connector").

Supported account types: Choose Accounts in this organizational directory only (Single tenant).

Redirect URI: Leave this blank.

Click Register to create the application.

Copy Application and Tenant IDs:

Once the app is registered, note the Application (client) ID and Directory (tenant) ID from the Overview page. You'll need these for VirtualMetric DataStream configuration.

Create a Client Secret:

In the Certificates & secrets section, click + New client secret.

Add a description (e.g., 'VirtualMetric ASIM Secret') and set an appropriate expiration period.

Click Add.

Copy the client secret value immediately, as it will not be shown again. Store this securely for VirtualMetric DataStream configuration.

Assign Required Permissions

Assign the required roles to your chosen authentication method (Service Principal or Managed Identity) in the resource group.

For Service Principal (if you completed Step 1):

Navigate to Your Resource Group:

Open the Azure Portal and navigate to the Resource Group that contains your Log Analytics Workspace and where Data Collection Rules (DCRs) will be deployed.

Assign the Monitoring Metrics Publisher Role:

In the Resource Group, click on Access control (IAM) from the left-hand menu.

Click + Add and select Add role assignment.

In the Role tab, search for and select Monitoring Metrics Publisher.

Click Next to go to the Members tab.

Under Assign access to, select User, group, or service principal.

Click + Select members and search for your registered application by name or client ID.

Select your application and click Select.

Click Review + assign twice to complete the assignment.

Assign the Monitoring Reader Role:

Repeat the same process to assign the Monitoring Reader role:

Click + Add and select Add role assignment.

In the Role tab, search for and select Monitoring Reader.

Follow the same member selection process as above.

Click Review + assign twice to complete the assignment. For Azure Managed Identity:

Create or Identify Your Managed Identity:

If using System-assigned Managed Identity: Enable it on your Azure resource (VM, App Service, etc.).

If using User-assigned Managed Identity: Create one in your resource group if it doesn't exist.

Assign the Monitoring Metrics Publisher Role:

Follow the same steps as above, but in the Members tab:

Under Assign access to, select Managed identity.

Click + Select members and choose the appropriate managed identity type and select your identity.

Click Select, then Review + assign twice to complete.

Assign the Monitoring Reader Role:

Repeat the process to assign the Monitoring Reader role to the same managed identity. Required Permission Summary: The assigned roles provide the following capabilities:

Monitoring Metrics Publisher: Write data to Data Collection Endpoints (DCE) and send telemetry through Data Collection Rules (DCR)

Monitoring Reader: Read stream configuration and access Log Analytics workspace for ASIM table ingestion

Deploy Azure Infrastructure

Deploy the required Data Collection Endpoint (DCE) and Data Collection Rules (DCR) for Microsoft Sentinel data lake tables using our ARM template.

Deploy to Azure:

Click the Deploy to Azure button below to automatically deploy the required infrastructure:

portal.azure.com

This will take you directly to the Azure portal to start the deployment.

Configure Deployment Parameters:

On the custom deployment page, configure the following settings:

Project details:

Subscription: Select your Azure subscription from the dropdown

Resource group: Select an existing resource group or click Create new to create a new one Instance details:

Region: Select the Azure region where your Log Analytics workspace is located (e.g., West Europe)

Workspace: Enter your Log Analytics workspace name

DCE Name: Provide a name for the Data Collection Endpoint (e.g., "vmetric-dce")

DCR Name Prefix: Provide a prefix for the Data Collection Rules (e.g., "vmetric-dcr")

Complete the Deployment:

Click Review + create to validate the template.

Review the parameters and click Create to deploy the resources.

Wait for the deployment to complete (typically takes 2-5 minutes).

Verify Deployed Resources:

After deployment, verify the following resources were created:

Data Collection Endpoint (DCE): Check Azure Portal > Monitor > Data Collection Endpoints

Data Collection Rules (DCRs): Check Azure Portal > Monitor > Data Collection Rules

Copy the DCE Logs Ingestion URI from the DCE Overview page (format: https://<dce-name>.<region>.ingest.monitor.azure.com)

Copy the DCE Resource ID from the DCE Overview page (format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Insights/dataCollectionEndpoints/<dce-name>)

For each DCR, note the Immutable ID from the Overview page - you'll need these for VirtualMetric DataStream configuration.

Configure VirtualMetric DataStream Integration

Set up VirtualMetric DataStream to send security telemetry to Microsoft Sentinel data lake tables.

Access VirtualMetric DataStream Configuration:

Log into your VirtualMetric DataStream management console.

Navigate to Fleet Management > Targets section.

Click Add new target button.

Select Microsoft Sentinel target.

Configure General Settings:

Name: Enter a name for your target (e.g., "cus01-ms-sentinel")

Description: Optionally provide a description for the target configuration

Configure Azure Authentication (choose based on Step 1): For Service Principal Authentication:

Managed Identity for Azure: Keep Disabled

Tenant ID: Enter the Directory (tenant) ID from Step 1

Client ID: Enter the Application (client) ID from Step 1

Client Secret: Enter the client secret value from Step 1 For Azure Managed Identity:

Managed Identity for Azure: Set to Enabled

Configure Stream Properties:

Endpoint: Choose your configuration method:

For manual stream configuration: Enter the DCE Logs Ingestion URI (format: https://<dce-name>.<region>.ingest.monitor.azure.com)

For auto stream detection: Enter the DCE Resource ID (format: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Insights/dataCollectionEndpoints/<dce-name>)

Streams: Select Auto for automatic stream detection, or configure specific streams if needed

Verify Data Ingestion in Microsoft Sentinel data lake:

Return to your Log Analytics Workspace

Run sample queries on the ASIM tables to confirm data is being received:
ASimNetworkSessionLogs | where TimeGenerated > ago(1h) | take 10

Check the Microsoft Sentinel Overview dashboard for new data sources and event counts.

VirtualMetric Director Proxy

Supported by: VirtualMetric

VirtualMetric Director Proxy deploys an Azure Function App to securely bridge VirtualMetric DataStream with Azure services including Microsoft Sentinel, Azure Data Explorer, and Azure Storage.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CommonSecurityLog Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Function App: An Azure Function App must be deployed to host the Director Proxy. Requires read, write, and delete permissions on Microsoft.Web/sites resources within your resource group to create and manage the Function App.

VirtualMetric DataStream Configuration: You need VirtualMetric DataStream configured with authentication credentials to connect to the Director Proxy. The Director Proxy acts as a secure bridge between VirtualMetric DataStream and Azure services.

Target Azure Services: Configure your target Azure services such as Microsoft Sentinel Data Collection Endpoints, Azure Data Explorer clusters, or Azure Storage accounts where the Director Proxy will forward data.

Setup Instructions:

Deploy VirtualMetric Director Proxy

Deploy the Azure Function App that serves as a secure proxy between VirtualMetric DataStream and Microsoft Sentinel.

Prerequisites and Deployment Order

Recommended Deployment Order:

For optimal configuration, consider deploying the target connectors first:

Deploy Microsoft Sentinel Connector: Deploy the VirtualMetric DataStream for Microsoft Sentinel connector first to create the required Data Collection Endpoints and Rules.

Deploy Microsoft Sentinel data lake Connector (optional): If using Microsoft Sentinel data lake tables, deploy the VirtualMetric DataStream for Microsoft Sentinel data lake connector.

Deploy Director Proxy (this step): The Director Proxy can then be configured with your Microsoft Sentinel targets. Note: This order is recommended but not required. You can deploy the Director Proxy independently and configure it with your targets later.

Deploy Azure Function App

Deploy the VirtualMetric Director Proxy Azure Function App using the Deploy to Azure button.

Deploy to Azure:

Click the Deploy to Azure button below to deploy the Function App:

portal.azure.com

Configure Deployment Parameters:

Subscription: Select your Azure subscription

Resource Group: Choose the same resource group as your Microsoft Sentinel workspace or create a new one

Region: Select the Azure region (should match your Microsoft Sentinel workspace region)

Function App Name: Provide a unique name for the Function App (e.g., "vmetric-director-proxy")

Complete Deployment:

Click Review + create to validate the parameters

Click Create to deploy the Function App

Wait for deployment to complete (typically 3-5 minutes)

Note the Function App URL: https://<function-app-name>.azurewebsites.net

Configure Function App Permissions

Assign the necessary permissions to the Function App's managed identity to access Microsoft Sentinel resources.

Enable System-Assigned Managed Identity:

Navigate to your deployed Function App in Azure Portal

Go to Identity under Settings

Toggle Status to On for System assigned identity

Click Save and confirm

Navigate to Resource Group:

Go to the resource group containing your Microsoft Sentinel workspace and Data Collection Endpoints

Assign Required Roles:

Open Access control (IAM)

Click + Add > Add role assignment

Assign the following roles to the Function App's system-assigned managed identity:

Monitoring Metrics Publisher: For sending data to Data Collection Endpoints

Monitoring Reader: For reading Data Collection Rules configuration

Select the Function App Identity:

In Members tab, select Managed identity

Choose Function App and select your deployed Director Proxy Function App

Complete the role assignment

Get Function App Access Token (Optional for Function Key authentication):

Navigate to your Function App

Go to App keys under Functions

Copy the default host key or create a new function key for authentication

Configure VirtualMetric DataStream Integration

Set up VirtualMetric DataStream to send security telemetry to Microsoft Sentinel through the Director Proxy.

Access VirtualMetric DataStream Configuration:

Log into your VirtualMetric DataStream management console

Navigate to Targets section

Click Microsoft Sentinel Targets

Click Add new target or edit an existing Microsoft Sentinel target

Configure General Settings:

Name: Enter a name for your target (e.g., "sentinel-with-proxy")

Description: Optionally provide a description for the target configuration

Configure Azure Authentication: For Service Principal Authentication:

Managed Identity for Azure: Keep Disabled

Tenant ID: Enter your Azure Active Directory tenant ID

Client ID: Enter your service principal application ID

Client Secret: Enter your service principal client secret For Azure Managed Identity:

Managed Identity for Azure: Set to Enabled

Configure Director Proxy (in Azure Properties tab):

Endpoint Address: Enter the Function App URL from Step 2 (format: https://<function-app-name>.azurewebsites.net)

Access Token: Enter the Function App host key from Step 3 (optional if using Managed Identity)

Configure Stream Properties:

Endpoint: Enter the DCE Logs Ingestion URI (format: https://<dce-name>.<region>.ingest.monitor.azure.com)

Streams: Select Auto for automatic stream detection, or configure specific streams if needed

Verify Data Ingestion in Microsoft Sentinel:

Return to your Log Analytics Workspace

Run sample queries to confirm data is being received:
CommonSecurityLog | where TimeGenerated > ago(1h) | take 10

Check the Microsoft Sentinel Overview dashboard for new data sources and event counts

VMRayThreatIntelligence (using Azure Functions)

Supported by: VMRay

VMRayThreatIntelligence connector automatically generates and feeds threat intelligence for all submissions to VMRay, improving threat detection and incident response in Sentinel. This seamless integration empowers teams to proactively address emerging threats.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ThreatIntelligenceIndicator Yes No

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Subscription: Azure Subscription with owner role is required to register an application in azure active directory() and assign role of contributor to app in resource group.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: VMRay API Key is required.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the VMRay API to pull VMRay Threat IOCs into Microsoft Sentinel. This might result in additional costs for data ingestion and for storing data in Azure Blob Storage costs. Check the Azure Functions pricing page and Azure Blob Storage pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Deploy VMRay Threat Intelligence Connector

Ensure you have all the required prerequisites: Client ID, Tenant ID, Client Secret, VMRay API Key, and VMRay Base URL.

To obtain the Client ID, Client Secret, and Tenant ID, follow these instructions

For the Flex Consumption Plan, click the Deploy to Azure button below:

aka.ms

For the Premium Plan, click the Deploy to Azure button below:

aka.ms.

VMware Carbon Black Cloud via AWS S3 (via Codeless Connector Framework)

Supported by: Microsoft

The VMware Carbon Black Cloud via AWS S3 data connector provides the capability to ingest watchlist, alerts, auth and endpoints events via AWS S3 and stream them to ASIM normalized tables. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CarbonBlack_Alerts_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Environment: You must have the following AWS resources defined and configured: S3, Simple Queue Service (SQS), IAM roles and permissions policies

Environment: You must have the a Carbon black account and required permissions to create a Data Forwarded to AWS S3 buckets. For more information, see Carbon Black Data Forwarder Docs

Setup Instructions:

AWS CloudFormation Deployment To configure access on AWS, two templates has been generated to set up the AWS environment to send logs from S3 bucket to your Log Analytics Workspace.

For each template, create Stack in AWS:

Go to AWS CloudFormation Stacks

In AWS, choose the 'Upload a template file' option and click on 'Choose file'. Select the downloaded template

Click 'Next' and 'Create stack'

Template 1: OpenID connect authentication deployment: <variable value provided at install time>

Template 2: AWS Carbon Black resources deployment: <variable value provided at install time> When deploying 'Template 2: AWS Carbon Black resources deployment' template you'll need supply a few parameters

Stack Name: A stack name of your choosing (will appear in the list of stacks in AWS)

Role Name: Must begin with 'OIDC_' prefix, has a default value.

Bucket Name: Bucket name of your choosing, if you already have an existing bucket paste the name here

CreateNewBucket: If you already have an existing bucket that you would like to use for this connector select 'false' for this option, otherwise a bucket with the name you entered in 'Bucket Name' will be created from this stack.

Region: This is the region of the AWS resources based on Carbon Black's mapping - for more information please see Carbon Black documentation.

SQSQueuePrefix: The stack create multiple queues, this prefix will be added to each one of them.

WorkspaceID: Use the Workspace ID provided below.

Workspace ID: <variable value provided at install time> Once the deployment is complete - head to the 'Outputs' tab, you will see: Role ARN, S3 bucket and 4 SQS resources created. You will need those resources in the next step when configuring Carbon Black's data forwarders and the data connector.

Carbon Black data forwarder configuration After all AWS resources has been created you'll need to configure Carbon Black to forward the events to the AWS buckets for Microsoft Sentinel to ingest them. Follow Carbon Black's documentation on how to create a 'Data Forwarders' Use the first recommended option. When asked to input a bucket name use the bucket created in the previous step. You will be required to add 'S3 prefix' for each forwarder, please use this mapping:

Event type S3 prefix

Alert carbon-black-cloud-forwarder/Alerts

Auth Events carbon-black-cloud-forwarder/Auth

Endpoint Events carbon-black-cloud-forwarder/Endpoint

Watchlist Hit carbon-black-cloud-forwarder/Watchlist

2.1. Test your data forwarder (Optional) To validate the data forwarder is configured as expected, in Carbon Black's portal search for the data forwarder that you just created and click on 'Test Forwarder' button under the 'Actions' column, this will generate a 'HealthCheck' file in the S3 Bucket, you should see it appear immediately.

Connect new collectors To enable AWS S3 for Microsoft Sentinel, click the 'Add new collector' button, fill the required information, the ARN role and the SQS URL are created in step 1, note that you will need to enter the correct SQS URL and select the appropriate event type from the dropdown, for example if you want to ingest Alert events you will need to copy the Alerts SQS URL and select the 'Alerts' event type in the dropdown

Data Connectors Grid (configure in portal)

Windows DNS Events via AMA

Supported by: Microsoft Corporation

The Windows DNS log connector allows you to easily filter and stream all analytics logs from your Windows DNS servers to your Microsoft Sentinel workspace using the Azure Monitoring agent (AMA). Having this data in Microsoft Sentinel helps you identify issues and security threats such as:

Trying to resolve malicious domain names.

Stale resource records.

Frequently queried domain names and talkative DNS clients.

Attacks performed on DNS server.

You can get the following insights into your Windows DNS servers from Microsoft Sentinel:

All logs centralized in a single place.

Request load on DNS servers.

Dynamic DNS registration failures.

Windows DNS events are supported by Advanced SIEM Information Model (ASIM) and stream data into the ASimDnsActivityLogs table. Learn more.

For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ASimDnsActivityLogs Yes Yes

Data collection rule support: Workspace transform DCR

Windows Firewall

Supported by: Microsoft Corporation

Windows Firewall is a Microsoft Windows application that filters information coming to your system from the Internet and blocking potentially harmful programs. The software blocks most programs from communicating through the firewall. Users simply add a program to the list of allowed programs to allow it to communicate through the firewall. When using a public network, Windows Firewall can also secure the system by blocking all unsolicited attempts to connect to your computer. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Data collection rule support: Not currently supported

Windows Firewall Events via AMA

Supported by: Microsoft Corporation

Windows Firewall is a Microsoft Windows application that filters information coming to your system from the internet and blocking potentially harmful programs. The firewall software blocks most programs from communicating through the firewall. To stream your Windows Firewall application logs collected from your machines, use the Azure Monitor agent (AMA) to stream those logs to the Microsoft Sentinel workspace.

A configured data collection endpoint (DCE) is required to be linked with the data collection rule (DCR) created for the AMA to collect logs. For this connector, a DCE is automatically created in the same region as the workspace. If you already use a DCE stored in the same region, it's possible to change the default created DCE and use your existing one through the API. DCEs can be located in your resources with SentinelDCE prefix in the resource name.

For more information, see the following articles:

Data collection endpoints in Azure Monitor

Microsoft Sentinel documentation

Log Analytics table(s):

Table DCR support Lake-only ingestion

Data collection rule support: Not currently supported

Windows Forwarded Events

Supported by: Microsoft Corporation

You can stream all Windows Event Forwarding (WEF) logs from the Windows Servers connected to your Microsoft Sentinel workspace using Azure Monitor Agent (AMA). This connection enables you to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization’s network and improves your security operation capabilities. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

WindowsEvent Yes Yes

Data collection rule support: Workspace transform DCR

Windows Security Events via AMA

Supported by: Microsoft Corporation

You can stream all security events from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization’s network and improves your security operation capabilities. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityEvent Yes Yes

Data collection rule support: Workspace transform DCR

WithSecure Elements API (Azure Function)

Supported by: WithSecure

WithSecure Elements is the unified cloud-based cyber security platform designed to reduce risk, complexity, and inefficiency.

Elevate your security from your endpoints to your cloud applications. Arm yourself against every type of cyber threat, from targeted attacks to zero-day ransomware.

WithSecure Elements combines powerful predictive, preventive, and responsive security capabilities - all managed and monitored through a single security center. Our modular structure and flexible pricing models give you the freedom to evolve. With our expertise and insight, you'll always be empowered - and you'll never be alone.

With Microsoft Sentinel integration, you can correlate security events data from the WithSecure Elements solution with data from other sources, enabling a rich overview of your entire environment and faster reaction to threats.

With this solution Azure Function is deployed to your tenant, polling periodically for the WithSecure Elements security events.

For more information visit our website at: https://www.withsecure.com.

Log Analytics table(s):

Table DCR support Lake-only ingestion

WsSecurityEvents_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

WithSecure Elements API client credentials: Client credentials are required. See the documentation to learn more.

Setup Instructions:

1. Create WithSecure Elements API credentials

Follow the user guide to create Elements API credentials. Save credentials in a safe place.

2. Create Microsoft Entra application

Create new Microsoft Entra application and credentials. Follow the instructions and store values of Directory (tenant) ID, Object ID, Application (client) ID and Client Secret (from client credentials field). Remember to store Client Secret in a safe place.

3. Deploy Function App

NOTE: This connector uses Azure Functions to pull logs from WithSecure Elements. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store Microsoft Entra client credentials and WithSecure Elements API client credentials in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

IMPORTANT: Before deploying the WithSecure Elements connector, have the Workspace Name (can be copied from the following), data from Microsoft Entra (Directory (tenant) ID, Object ID, Application (client) ID and Client Secret), as well as the WithSecure Elements client credentials, readily available.

Workspace Name: <variable value provided at install time>

Deploy all the resources related to the connector

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID, Entra Client ID, Entra Client Secret, Entra Tenant ID, Elements API Client ID, Elements API Client Secret.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details. 4. You can also fill in optional fields: Elements API url, Engine, Engine Group. Use default value of Elements API url unless you have some special case. Engine and Engine Group map to security events request parameters, fill in those parameters if you are interested only in events from specific engine or engine group, in case you want to receive all security events leave the fields with default values. 5. Mark the checkbox labeled I agree to the terms and conditions stated above. 6. Click Purchase to deploy.

Wiz (using Azure Functions)

Supported by: Wiz

The Wiz connector allows you to easily send Wiz Issues, Vulnerability Findings, and Audit logs to Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

union isfuzzy=true (WizIssues_CL),(WizIssuesV2_CL) No No

union isfuzzy=true (WizVulnerabilities_CL),(WizVulnerabilitiesV2_CL) No No

union isfuzzy=true (WizAuditLogs_CL),(WizAuditLogsV2_CL) No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Wiz Service Account credentials: Ensure you have your Wiz service account client ID and client secret, API endpoint URL, and auth URL. Instructions can be found on Wiz documentation.

Setup Instructions:

NOTE: This connector: Uses Azure Functions to connect to Wiz API to pull Wiz Issues, Vulnerability Findings, and Audit Logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details. Creates an Azure Key Vault with all the required parameters stored as secrets.

STEP 1 - Get your Wiz credentials

Follow the instructions on Wiz documentation to get the erquired credentials.

STEP 2 - Deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Wiz Connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Wiz credentials from the previous step.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1: Deploy using the Azure Resource Manager (ARM) Template

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the following parameters:

Choose KeyVaultName and FunctionName for the new resources

Enter the following Wiz credentials from step 1: WizAuthUrl, WizEndpointUrl, WizClientId, and WizClientSecret

Enter the Workspace credentials AzureLogsAnalyticsWorkspaceId and AzureLogAnalyticsWorkspaceSharedKey

Choose the Wiz data types you want to send to Microsoft Sentinel, choose at least one from Wiz Issues, Vulnerability Findings, and Audit Logs.

(optional) follow Wiz documentation to add IssuesQueryFilter, VulnerbailitiesQueryFilter, and AuditLogsQueryFilter.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2: Manual Deployment of the Azure Function

Follow Wiz documentation to deploy the connector manually.

Workday User Activity

Supported by: Microsoft Corporation

The Workday User Activity data connector provides the capability to ingest User Activity Logs from Workday API into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ASimAuditEventLogs Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Workday User Activity API access: Access to the Workday user activity API through Oauth are required. The API Client needs to have the scope: System and it needs to be authorized by an account with System Auditing permissions.

Setup Instructions:

Connect to Workday to start collecting user activity logs in Microsoft Sentinel

In Workday, access the "Edit Tenant Setup - Security" task, verify "OAuth 2.0 Settings" section, make sure that the "OAuth 2.0 Clients Enabled" check box is ticked.

In Workday, access the "Edit Tenant Setup - System" task, verify "User Activity Logging" section, make sure that the "Enable User Activity Logging" check box is ticked.

In Workday, access the "Register API Client" task.

Define the Client Name, select the "Client Grant Type": "Authorization Code Grant" and then select "Access Token Type": "Bearer"

Enter the "Redirection URI" found in the form below

In section "Scope (Functional Areas)", select "System" and click OK at the bottom

Copy the Client ID and Client Secret before navigating away from the page, and store it securely.

In Sentinel, in the connector page - provide required Token, Authorization and User Activity Logs Endpoints, along with Client ID and Client Secret from previous step. Then click "Connect".

A Workday pop up will appear to complete the OAuth2 authentication and authorization of the API client. Here you need to provide credentials for Workday account with "System Auditing" permissions in Workday (can be either Workday account or Integration System User).

Once that's complete, the message will be displayed to authorize your API client

Token Endpoint: (https://wd2-impl-services1.workday.com/ccx/oauth2/{tenantName}/token)

Authorization Endpoint: (https://impl.workday.com/{tenantName}/authorize)

**User Activity Logs Endpoint, it ends with /activityLogging **: (https://wd2-impl-services1.workday.com/ccx/api/privacy/v1/{tenantName}/activityLogging)

Workplace from Facebook (using Azure Functions)

Supported by: Microsoft Corporation

The Workplace data connector provides the capability to ingest common Workplace events into Microsoft Sentinel through Webhooks. Webhooks enable custom integration apps to subscribe to events in Workplace and receive updates in real time. When a change occurs in Workplace, an HTTPS POST request with event information is sent to a callback data connector URL. Refer to Webhooks documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Workplace_Facebook_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Webhooks Credentials/permissions: WorkplaceAppSecret, WorkplaceVerifyToken, Callback URL are required for working Webhooks. See the documentation to learn more about configuring Webhooks, configuring permissions.

Setup Instructions:

NOTE: This data connector uses Azure Functions based on HTTP Trigger for waiting POST requests with logs to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Functions App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias WorkplaceFacebook and load the function code or click here on the second line of the query, enter the hostname(s) of your Workplace Facebook device(s) and any other unique identifiers for the logstream. The function usually takes 10-15 minutes to activate after solution installation/update.

STEP 1 - Configuration steps for the Workplace

Follow the instructions to configure Webhooks.

Log in to the Workplace with Admin user credentials.

In the Admin panel, click Integrations.

In the All integrations view, click Create custom integration

Enter the name and description and click Create.

In the Integration details panel show App secret and copy.

In the Integration permissions pannel set all read permissions. Refer to permission page for details.

Now proceed to STEP 2 to follow the steps (listed in Option 1 or 2) to Deploy the Azure Function.

Enter the requested parameters and also enter a Token of choice. Copy this Token / Note it for the upcoming step.

After the deployment of Azure Functions completes successfully, open Function App page, select your app, go to Functions, click Get Function URL and copy this / Note it for the upcoming step.

Go back to Workplace from Facebook. In the Configure webhooks panel on each Tab set Callback URL as the same value that you copied in point 9 above and Verify token as the same value you copied in point 8 above which was obtained during STEP 2 of Azure Functions deployment.

Click Save.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Functions

IMPORTANT: Before deploying the Workplace data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Workplace data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the WorkplaceVerifyToken (can be any expression, copy and save it for STEP 1), WorkplaceAppSecret and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy. 6. After deploying open Function App page, select your app, go to the Functions and click Get Function Url copy it and follow p.7 from STEP 1.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Sophos Endpoint Protection data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.

After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): WorkplaceAppSecret WorkplaceVerifyToken WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

XBOW Security Platform (via Azure Function)

Supported by: XBOW

The XBOW data connector ingests asset snapshots, vulnerability findings, and assessment activity from the XBOW Security Platform into Microsoft Sentinel. An Azure Function polls the XBOW API on a timer and pushes asset JSON snapshots into XbowAssets_CL, enriched findings (with evidence, PoC recipes, impact, and mitigations) into XbowFindings_CL, and assessment lifecycle events into XbowAssessments_CL, using the Azure Monitor Ingestion API (DCE/DCR).

Log Analytics table(s):

Table DCR support Lake-only ingestion

XbowAssets_CL No No

XbowFindings_CL No No

XbowAssessments_CL No No

Data collection rule support: Not currently supported

Prerequisites:

XBOW API Token: A XBOW Personal Access Token is required. Generate one in the XBOW console under Settings > Personal Access Tokens. Scope the token to the organization you want to monitor.

XBOW Organization ID: The Organization ID from your XBOW account. Find it in the XBOW console URL or via the API.

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Custom prerequisites if necessary, otherwise delete this customs tag: Description for any custom pre-requisites

Azure AD App Registration: An Azure AD App Registration (service principal) is required. You must manually assign the Monitoring Metrics Publisher role on the Data Collection Rule (DCR) to this App Registration after deployment.

Setup Instructions:

NOTE: This connector uses Azure Functions and the Azure Monitor Ingestion API (DCE/DCR) to ingest XBOW assets, findings, and assessments into Microsoft Sentinel. The ARM template automatically creates the Data Collection Endpoint, custom log tables (XbowAssets_CL, XbowFindings_CL, and XbowAssessments_CL), Data Collection Rule, and Function App. This might result in additional data ingestion costs. Check the Azure Functions pricing page and Azure Monitor pricing page for details.

(Optional Step) Securely store your XBOW API Token and App Registration credentials in Azure Key Vault. Follow these instructions to use Azure Key Vault references with an Azure Function App.

STEP 1 – Generate a XBOW API Token

Log into the XBOW console with administrator access.

Click your profile icon (top right) and select Settings.

In the left sidebar, click Personal Access Tokens.

Click Generate new token, provide a name, and select the organization scope.

Copy and securely store your token — it will not be shown again.

Note your Organization ID from the XBOW console or from the URL when viewing your organization.

STEP 2 – Create an Azure AD App Registration and Grant DCR Role

In the Azure Portal, navigate to Azure Active Directory > App registrations > New registration.

Provide a name (e.g. Xbow-Sentinel-Connector) and register.

Under Certificates & secrets, create a new client secret. Note the Tenant ID, Client ID, and Client Secret.

Deploy the connector using Step 3 below, then return here.

Open the deployed Data Collection Rule (from the deployment outputs or by searching in the resource group).

Go to Access control (IAM) > Add role assignment.

Select role Monitoring Metrics Publisher.

Assign access to the App Registration (service principal) created above.

Wait a few minutes for RBAC propagation before verifying ingestion.

STEP 3 – Deploy the Azure Function App

Click Deploy to Azure and fill in the parameters. The template will automatically create the Data Collection Endpoint, XbowAssets_CL, XbowFindings_CL, and XbowAssessments_CL tables, Data Collection Rule, and Function App.

aka.ms

Parameters to fill in:

Parameter Description

WorkspaceName Name of your Log Analytics / Microsoft Sentinel workspace

XbowApiToken XBOW Personal Access Token from Step 1

XbowOrgId XBOW Organization ID from Step 1

TenantId Azure AD Tenant ID from Step 2

ClientId App Registration Client ID from Step 2

ClientSecret App Registration Client Secret from Step 2

AppInsightsWorkspaceResourceID Full Resource ID of the Log Analytics workspace (from Log Analytics workspace > Properties)

FunctionAppLocation Optional Azure region for Function App resources (defaults to the Resource Group location)

Workspace ID: <variable value provided at install time>

Zero Networks Segment (Push)

Supported by: Zero Networks

The Zero Networks Segment push connector allows Zero Networks to send Audits, Network Activities, Identity Activities, and RPC Activities directly to Microsoft Sentinel in real time. Deploy the connector to create a Data Collection Rule (DCR) and Microsoft Entra app; then configure your Zero Networks application with the connection details to push events.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZNAudit_CL Yes Yes

ZNNetworkActivity_CL Yes Yes

ZNIdentityActivity_CL Yes Yes

ZNRPCActivity_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft Entra: Permission to create an app registration in Microsoft Entra ID. Typically requires Entra ID Application Developer role or higher.

Microsoft Azure: Permission to assign Monitoring Metrics Publisher role on data collection rule (DCR). Typically requires Azure RBAC Owner or User Access Administrator role.

Setup Instructions:

1. Create ARM Resources and Provide the Required Permissions

Deploy the push connector to create a Log Analytics table, Data Collection Rule (DCR), Data Collection Endpoint (DCE), and Microsoft Entra app. Then configure your Zero Networks application with the connection details.

Automated Configuration Clicking "Deploy" will create a DCR and DCE, then a Microsoft Entra app registration with client secret and grant permissions on the DCR. Your application can then send data securely using OAuth 2.0 client credentials.

2. Configure Your Zero Networks Application

Use the following values to configure your Zero Networks application to push Audits, Network Activities, Identity Activities, and RPC Activities to Microsoft Sentinel.

Tenant ID (Directory ID): <variable value provided at install time>

Entra Application ID: <variable value provided at install time>

Entra Application Secret: <variable value provided at install time>

Data Collection Endpoint URI: <variable value provided at install time>

Data Collection Rule Immutable ID: <variable value provided at install time>

Stream: Audits: <variable value provided at install time>

Stream: Network Activities: <variable value provided at install time>

Stream: Identity Activities: <variable value provided at install time>

Stream: RPC Activities: <variable value provided at install time>

Zero Networks Segment Audit

Supported by: Zero Networks

The Zero Networks Segment Audit data connector provides the capability to ingest Zero Networks Audit events into Microsoft Sentinel through the REST API. This data connector uses Microsoft Sentinel native polling capability.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZNSegmentAuditNativePoller_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Zero Networks API Token: ZeroNetworksAPIToken is required for REST API. See the API Guide and follow the instructions for obtaining credentials.

Setup Instructions:

Connect Zero Networks to Microsoft Sentinel

Enter the Zero Networks API URL (e.g. portal.zeronetworks.com). The connector adds https:// and /api/v1/audit automatically. Then provide your API key and click Connect.

Zero Networks API URL: (portal.zeronetworks.com)

ApiKey: (ApiKey)

Enable/Disable Connection

Data Connectors Grid (configure in portal)

ZeroFox CTI

Supported by: ZeroFox

The ZeroFox CTI data connectors provide the capability to ingest the different ZeroFox cyber threat intelligence alerts into Microsoft Sentinel.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZeroFox_CTI_advanced_dark_web_CL No No

ZeroFox_CTI_botnet_CL No No

ZeroFox_CTI_breaches_CL No No

ZeroFox_CTI_C2_CL No No

ZeroFox_CTI_compromised_credentials_CL No No

ZeroFox_CTI_credit_cards_CL No No

ZeroFox_CTI_dark_web_CL No No

ZeroFox_CTI_discord_CL No No

ZeroFox_CTI_disruption_CL No No

ZeroFox_CTI_email_addresses_CL No No

ZeroFox_CTI_exploits_CL No No

ZeroFox_CTI_irc_CL No No

ZeroFox_CTI_malware_CL No No

ZeroFox_CTI_national_ids_CL No No

ZeroFox_CTI_phishing_CL No No

ZeroFox_CTI_phone_numbers_CL No No

ZeroFox_CTI_ransomware_CL No No

ZeroFox_CTI_telegram_CL No No

ZeroFox_CTI_threat_actors_CL No No

ZeroFox_CTI_vulnerabilities_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

ZeroFox API Credentials/permissions: ZeroFox Username, ZeroFox Personal Access Token are required for ZeroFox CTI REST API.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the ZeroFox CTI REST API to pull logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Retrieval of ZeroFox credentials:

Follow these instructions for set up logging and obtain credentials.

Log into ZeroFox's website. using your username and password 2 - Click into the Settings button and go to the Data Connectors Section. 3 - Select the API DATA FEEDS tab and head to the bottom of the page, select <<Reset>> in the API Information box, to obtain a Personal Access Token to be used along with your username.

STEP 2 - Deploy the Azure Function data connectors using the Azure Resource Manager template:

IMPORTANT: Before deploying the ZeroFox CTI data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Preparing resources for deployment.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group, Log analytics Workspace and Location.

Enter the Workspace ID, Workspace Key, ZeroFox Username, ZeroFox Personal Access Token

Click Review + Create to deploy.

ZeroFox Enterprise - Alerts (Polling CCF)

Supported by: ZeroFox

Collects alerts from ZeroFox API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZeroFoxAlertPoller_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

ZeroFox Personal Access Token (PAT): A ZeroFox PAT is required. You can get it in Data Connectors > API Data Feeds.

Setup Instructions:

Connect ZeroFox to Microsoft Sentinel

Connect ZeroFox to Microsoft Sentinel

Provide your ZeroFox PAT: (Zerofox PAT)

Enable/Disable Connection

Zimperium Mobile Threat Defense

Supported by: Zimperium

Zimperium Mobile Threat Defense connector gives you the ability to connect the Zimperium threat log with Microsoft Sentinel to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization's mobile threat landscape and enhances your security operation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZimperiumThreatLog_CL No No

Data collection rule support: Not currently supported

Setup Instructions:

Configure and connect Zimperium MTD

In zConsole, click Manage on the navigation bar.

Click the Integrations tab.

Click the Threat Reporting button and then the Add Integrations button.

Create the Integration:

From the available integrations, select Microsoft Microsoft Sentinel.

Enter your workspace id and primary key from the fields below, click Next.

Fill in a name for your Microsoft Sentinel integration.

Select a Filter Level for the threat data you wish to push to Microsoft Sentinel.

Click Finish

For additional instructions, please refer to the Zimperium customer support portal.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Zoom Reports (using Azure Functions)

Supported by: Microsoft Corporation

The Zoom Reports data connector provides the capability to ingest Zoom Reports events into Microsoft Sentinel through the REST API. Refer to API documentation for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Zoom_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: AccountID, ClientID and ClientSecret are required for Zoom API. For more information, see Zoom API. Follow the instructions for Zoom API configurations.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Zoom API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias Zoom and load the function code or click here. The function usually takes 10-15 minutes to activate after solution installation/update.

STEP 1 - Configuration steps for the Zoom API

Follow the instructions to obtain the credentials.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Zoom Reports data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Zoom Audit data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Region.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the AccountID, ClientID, ClientSecret, WorkspaceID, WorkspaceKey, Function Name and click Review + create. 4. Finally click Create to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Zoom Reports data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. ZoomXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration

Step 2 - Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): AccountID ClientID ClientSecret WorkspaceID WorkspaceKey logAnalyticsUri (optional) Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

Zoom Reports Connector (via Codeless Connector Framework)

Supported by: Microsoft Corporation

The Zoom Reports data connector enables you to ingest Zoom Reports data into Microsoft Sentinel through the Zoom REST API v2, allowing you to monitor and audit Zoom usage across your organization. This connector uses server-to-server OAuth account credentials for authentication and supports ingestion of multiple report types including Daily Usage Reports for meeting statistics and usage metrics, User Reports for active/inactive user host information, Telephony Reports for telephony usage statistics, Cloud Recording Usage Reports for cloud storage and recording usage, Operation Logs for administrative operations and audit trail, and Activity Logs for user sign-in/sign-out activities. Each report type is collected in a separate polling configuration with automatic pagination support using NextPageToken. The data connector is built on Microsoft Sentinel Codeless Connector Framework and supports DCR-based ingestion time transformations for optimized query performance.

Log Analytics table(s):

Table DCR support Lake-only ingestion

ZoomV2_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Zoom API access: Access to Zoom REST API v2 with account credentials

Setup Instructions:

1. Zoom Configuration

Configure Server-to-Server OAuth App and gather credentials

Step 1: Set up Zoom Server-to-Server OAuth App, follow Create an app. Please make sure to add Reports related scopes to your app:

report:read:list_users:admin

report:read:cloud_recording:admin

report:read:daily_usage:admin

report:read:operation_logs:admin

report:read:telephone:admin

report:read:user_activities:admin

For more information, see Zoom Server-to-Server OAuth Documentation and Reports APIs.

Step 2: Get Your App Credentials

Find your app credentials (Account ID, Client ID and Client Secret) on your Personal app management page on the Zoom App Marketplace

Security Notes

Store Account ID, Client ID and Client Secret securely

Regularly rotate credentials for enhanced security

Client ID: (Zoom App Client ID)

Client Secret: (Zoom App Client Secret)

Account ID: (Your Zoom Account ID)

Token Base URL: (https://zoom.us/oauth/token)

API Base URL: (https://api.zoom.us/v2)

2. Connect

Enable the Zoom Reports connector

Activate the Connector

Review your Zoom App credentials found in Step 2, then enable the connector to begin collecting Zoom Reports data.

Monitoring

Check data arrival using these queries:

Check all report types:

ZoomV2_CL | where TimeGenerated > ago(30m) | summarize Records = count() by EventType

Check specific report type:

ZoomV2_CL | where EventType == 'dates' | where TimeGenerated > ago(1h) | limit 10

Monitor connector health:

ZoomV2_CL | where TimeGenerated > ago(24h) | summarize LastRecord = max(TimeGenerated), RecordCount = count() by EventType | order by LastRecord desc

Enable/Disable Connection

Deprecated Sentinel data connectors

Note

The following table lists the deprecated and legacy data connectors. Deprecated connectors are no longer supported.

[Deprecated] Auth0 Logs (using Azure Function) (using Azure Functions)

Supported by: Microsoft Corporation

The Auth0 Logs (using Azure Function) data connector provides the capability to ingest Auth0 log events into Microsoft Sentinel

Log Analytics table(s):

Table DCR support Lake-only ingestion

Auth0AM_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: API token is required. For more information, see API token

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Auth0 Management APIs to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Auth0 Management API

Follow the instructions to obtain the credentials.

In Auth0 Dashboard, go to Applications > Applications.

Select your Application. This should be a "Machine-to-Machine" Application configured with at least read:logs and read:logs_users permissions.

Copy Domain, ClientID, Client Secret

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Auth0 Access Management data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Auth0 Access Management data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the Domain, ClientID, Client Secret, AzureSentinelWorkspaceId, AzureSentinelSharedKey. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Auth0 Access Management data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. Auth0AMXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): DOMAIN CLIENT_ID CLIENT_SECRET WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

[Deprecated] GitHub Enterprise Audit Log

Supported by: Microsoft Corporation

The GitHub audit log connector provides the capability to ingest GitHub logs into Microsoft Sentinel. By connecting GitHub audit logs into Microsoft Sentinel, you can view this data in workbooks, use it to create custom alerts, and improve your investigation process.

Note: If you intended to ingest GitHub subscribed events into Microsoft Sentinel, please refer to GitHub (using Webhooks) Connector from "Data Connectors" gallery.

NOTE: This data connector has been deprecated, consider moving to the CCF data connector available in the solution which replaces ingestion via the deprecated HTTP Data Collector API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

GitHubAuditLogPolling_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

GitHub API personal access token: You need a GitHub personal access token to enable polling for the organization audit log. You may use either a classic token with 'read:org' scope OR a fine-grained token with 'Administration: Read-only' scope.

GitHub Enterprise type: This connector will only function with GitHub Enterprise Cloud; it will not support GitHub Enterprise Server.

Setup Instructions:

Connect the GitHub Enterprise Organization-level Audit Log to Microsoft Sentinel

Enable GitHub audit logs. Follow this guide to create or find your personal access token.

[Deprecated] Infoblox SOC Insight Data Connector via Legacy Agent

Supported by: Infoblox

The Infoblox SOC Insight Data Connector allows you to easily connect your Infoblox BloxOne SOC Insight data with Microsoft Sentinel. By connecting your logs to Microsoft Sentinel, you can take advantage of search & correlation, alerting, and threat intelligence enrichment for each log.

This data connector ingests Infoblox SOC Insight CDC logs into your Log Analytics Workspace using the legacy Log Analytics agent.

Microsoft recommends installation of Infoblox SOC Insight Data Connector via AMA Connector. The legacy connector uses the Log Analytics agent which is about to be deprecated by Aug 31, 2024, and should only be installed where AMA is not supported.

Using MMA and AMA on the same machine can cause log duplication and extra ingestion cost. More details.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CommonSecurityLog Yes Yes

Data collection rule support: Workspace transform DCR

Setup Instructions:

Workspace Keys

In order to use the playbooks as part of this solution, find your Workspace ID and Workspace Primary Key below for your convenience.

Workspace ID: <variable value provided at install time>

Workspace Key: <variable value provided at install time>

Parsers

This data connector depends on a parser based on a Kusto Function to work as expected called InfobloxCDC_SOCInsights which is deployed with the Microsoft Sentinel Solution.

SOC Insights

This data connector assumes you have access to Infoblox BloxOne Threat Defense SOC Insights. You can find more information about SOC Insights here.

Infoblox Cloud Data Connector

This data connector assumes an Infoblox Data Connector host has already been created and configured in the Infoblox Cloud Services Portal (CSP). As the Infoblox Data Connector is a feature of BloxOne Threat Defense, access to an appropriate BloxOne Threat Defense subscription is required. See this quick-start guide for more information and licensing requirements.

1. Linux Syslog agent configuration

Install and configure the Linux agent to collect your Common Event Format (CEF) Syslog messages and forward them to Microsoft Sentinel.

Notice that the data from all regions will be stored in the selected workspace

1.1 Select or create a Linux machine

Select or create a Linux machine that Microsoft Sentinel will use as the proxy between your security solution and Microsoft Sentinel this machine can be on your on-prem environment, Azure or other clouds.

1.2 Install the CEF collector on the Linux machine

Install the Microsoft Monitoring Agent on your Linux machine and configure the machine to listen on the necessary port and forward messages to your Microsoft Sentinel workspace. The CEF collector collects CEF messages on port 514 TCP.

Make sure that you have Python on your machine using the following command: python -version.

You must have elevated permissions (sudo) on your machine.

Run the following command to install and apply the CEF collector:: <variable value provided at install time>

2. Within the Infoblox Cloud Services Portal, configure Infoblox BloxOne to send CEF Syslog data to the Infoblox Cloud Data Connector to forward to the Syslog agent

Follow the steps below to configure the Infoblox CDC to send BloxOne data to Microsoft Sentinel via the Linux Syslog agent.

Navigate to Manage > Data Connector.

Click the Destination Configuration tab at the top.

Click Create > Syslog.

Name: Give the new Destination a meaningful name, such as Microsoft-Sentinel-Destination.

Description: Optionally give it a meaningful description.

State: Set the state to Enabled.

Format: Set the format to CEF.

FQDN/IP: Enter the IP address of the Linux device on which the Linux agent is installed.

Port: Leave the port number at 514.

Protocol: Select desired protocol and CA certificate if applicable.

Click Save & Close.

Click the Traffic Flow Configuration tab at the top.

Click Create.

Name: Give the new Traffic Flow a meaningful name, such as Microsoft-Sentinel-Flow.

Description: Optionally give it a meaningful description.

State: Set the state to Enabled.

Expand the Service Instance section.

Service Instance: Select your desired Service Instance for which the Data Connector service is enabled.

Expand the Source Configuration section.

Source: Select BloxOne Cloud Source.

Select the Internal Notifications Log Type.

Expand the Destination Configuration section.

Select the Destination you just created.

Click Save & Close.

Allow the configuration some time to activate.

3. Validate connection

Follow the instructions to validate your connectivity:

Open Log Analytics to check if the logs are received using the CommonSecurityLog schema.

It may take about 20 minutes until the connection streams data to your workspace.

If the logs are not received, run the following connectivity validation script:

Make sure that you have Python on your machine using the following command: python -version

You must have elevated permissions (sudo) on your machine

Run the following command to validate your connectivity:: <variable value provided at install time>

**4. Secure your machine **

Make sure to configure the machine's security according to your organization's security policy

Learn more >

[Deprecated] IONIX Security Logs (Push)

Supported by: IONIX

⚠️ This connector is deprecated and will be removed in June 2026. Please use the new 'IONIX Security Logs (via Codeless Connector Framework)' connector instead, which provides automatic daily polling without requiring manual configuration in the IONIX portal.

The IONIX Security Logs data connector ingests logs from the IONIX system directly into Sentinel. The connector allows users to visualize their data, create alerts and incidents and improve security investigations.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CyberpionActionItems_CL No No

Data collection rule support: Not currently supported

Prerequisites:

IONIX Subscription: A subscription and account is required for IONIX logs. One can be acquired here.

Setup Instructions:

Follow the instructions to integrate IONIX Security Alerts into Sentinel.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

[Deprecated] Lookout

Supported by: Lookout

The Lookout data connector provides the capability to ingest Lookout events into Microsoft Sentinel through the Mobile Risk API. Refer to API documentation for more information. The Lookout data connector provides ability to get events which helps to examine potential security risks and more.

NOTE: This data connector has been deprecated, consider moving to the CCF data connector available in the solution which replaces ingestion via the deprecated HTTP Data Collector API.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Lookout_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Mobile Risk API Credentials/permissions: EnterpriseName & ApiKey are required for Mobile Risk API. For more information, see API. Check all requirements and follow the instructions for obtaining credentials.

Setup Instructions:

NOTE: This Lookout data connector uses Azure Functions to connect to the Mobile Risk API to pull its events into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected LookoutEvents which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the Mobile Risk API

Follow the instructions to obtain the credentials.

STEP 2 - Follow below mentioned instructions to deploy the Lookout data connector and the associated Azure Function

IMPORTANT: Before starting the deployment of the Lookout data connector, make sure to have the Workspace ID and Workspace Key ready (can be copied from the following).

Workspace ID: <variable value provided at install time>

Workspace Key: <variable value provided at install time>

Azure Resource Manager (ARM) Template

Follow below steps for automated deployment of the Lookout data connector using an ARM Template.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Region.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the Function Name, Workspace ID,Workspace Key,Enterprise Name & Api Key and deploy. 4. Click Create to deploy.

[Deprecated] Microsoft Exchange Logs and Events

Supported by: Community

Deprecated, use the 'ESI-Opt' dataconnectors. You can stream all Exchange Audit events, IIS Logs, HTTP Proxy logs and Security Event logs from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to view dashboards, create custom alerts, and improve investigation. This is used by Microsoft Exchange Security Workbooks to provide security insights of your On-Premises Exchange environment

Log Analytics table(s):

Table DCR support Lake-only ingestion

Event Yes No

SecurityEvent Yes Yes

W3CIISLog Yes No

MessageTrackingLog_CL Yes Yes

ExchangeHttpProxy_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Azure Log Analytics will be deprecated, to collect data from non-Azure VMs, Azure Arc is recommended. Learn more

Detailed documentation: >NOTE: Detailed documentation on Installation procedure and usage can be found here

Setup Instructions:

NOTE: This solution is based on options. This allows you to choose which data will be ingest as some options can generate a very high volume of data. Depending on what you want to collect, track in your Workbooks, Analytics Rules, Hunting capabilities you will choose the option(s) you will deploy. Each options are independant for one from the other. To learn more about each option: 'Microsoft Exchange Security' wiki

1. Download and install the agents needed to collect logs for Microsoft Sentinel

Type of servers (Exchange Servers, Domain Controllers linked to Exchange Servers or all Domain Controllers) depends on the option you want to deploy.

Deploy Monitor Agents

This step is required only if it's the first time you onboard your Exchange Servers/Domain Controllers

Select which agent you want to install in your servers to collect logs:

[Prefered] Azure Monitor Agent via Azure Arc

Deploy the Azure Arc Agent Learn more

Install Azure Log Analytics Agent (Deprecated on 31/08/2024)

Download the Azure Log Analytics Agent and choose the deployment method in the below link.

Install Agent: <variable value provided at install time>

2. Deploy log injestion following choosed options

[Option 1] MS Exchange Management Log collection

Select how to stream MS Exchange Admin Audit event logs

MS Exchange Admin Audit event logs

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Microsoft Exchange Admin Audit Events logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCR.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace Name 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCR, Type Event log

From the Azure Portal, navigate to Azure Data collection rules.

Click + Create at the top.

In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR.

In the Resources tab, enter you Exchange Servers.

In 'Collect and deliver', add a Data Source type 'Windows Event logs' and select 'Custom' option, enter 'MSExchange Management' as expression and Add it.

'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Data Collection Rules - When the legacy Azure Log Analytics Agent is used

Configure the logs to be collected

Configure the Events you want to collect and their severities.

Under workspace Legacy agents management, select Windows Event logs.

Click Add Windows event log and enter MSExchange Management as log name.

Collect Error, Warning and Information types

Click Save.

Install Agent: <variable value provided at install time>

[Option 2] Security/Application/System logs of Exchange Servers

Select how to stream Security/Application/System logs of Exchange Servers

Security Event log collection

Data Collection Rules - Security Event logs

Enable data collection rule for Security Logs Security Events logs are collected only from Windows agents.

Add Exchange Servers on Resources tab.

Select Security log level

Common level is the minimum required. Please select 'Common' or 'All Security Events' on DCR definition.

Install Agent: <variable value provided at install time>

Application and System Event log collection

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Application and System Events logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCR.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace Name 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCR, Type Event log

From the Azure Portal, navigate to Azure Data collection rules.

Click + Create at the top.

In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR.

In the Resources tab, enter you Exchange Servers.

In 'Collect and deliver', add a Data Source type 'Windows Event logs' and select 'Basic' option.

For Application, select 'Critical', 'Error' and 'Warning'. For System, select Critical/Error/Warning/Information.

'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Data Collection Rules - When the legacy Azure Log Analytics Agent is used

Configure the logs to be collected

Configure the Events you want to collect and their severities.

Under workspace advanced settings Configuration, select Data and then Windows Event logs.

Click Add Windows event log and search Application as log name.

Click Add Windows event log and search System as log name.

Collect Error (for all), Warning (for all) and Information (for System) types

Click Save.

Install Agent: <variable value provided at install time>

[Option 3 and 4] Security logs of Domain Controllers

Select how to stream Security logs of Domain Controllers. If you want to implement Option 3, you just need to select DC on same site as Exchange Servers. If you want to implement Option 4, you can select all DCs of your forest.

[Option 3] List only Domain Controllers on the same site as Exchange Servers for next step

This limits the quantity of data injested but some incident can't be detected.

[Option 4] List all Domain Controllers of your Active-Directory Forest for next step

This allows collecting all security events

Security Event log collection

Data Collection Rules - Security Event logs

Enable data collection rule for Security Logs Security Events logs are collected only from Windows agents.

Add chosen DCs on Resources tab.

Select Security log level

Common level is the minimum required. Please select 'Common' or 'All Security Events' on DCR definition.

Install Agent: <variable value provided at install time>

[Option 5] IIS logs of Exchange Servers

Select how to stream IIS logs of Exchange Servers

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule IIS logs are collected only from Windows agents.

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

You can change the proposed name of the DCE.

Click Create to deploy.

B. Deploy Data Connection Rule

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.

Click + Create at the top.

In the Basics tab, fill the required fields and give a name to the DCE.

'Make other preferable configuration changes', if needed, then click Create.

B. Create DCR, Type IIS log

From the Azure Portal, navigate to Azure Data collection rules.

Click + Create at the top.

In the Basics tab, fill the required fields, Select Windows as platform type and give a name to the DCR. Select the created DCE.

In the Resources tab, enter you Exchange Servers.

In 'Collect and deliver', add a Data Source type 'IIS logs' (Do not enter a path if IIS Logs path is configured by default). Click on 'Add data source'

'Make other preferable configuration changes', if needed, then click Create.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Data Collection Rules - When the legacy Azure Log Analytics Agent is used

Configure the logs to be collected

Configure the Events you want to collect and their severities.

Under workspace advanced settings Configuration, select Data and then IIS Logs.

Check Collect W3C format IIS log files

Click Save.

Install Agent: <variable value provided at install time>

[Option 6] Message Tracking of Exchange Servers

Select how to stream Message Tracking of Exchange Servers

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Message Tracking are collected only from Windows agents.

Note: Attention, Custom logs in Monitor Agent is in Preview. The deployment doesn't work as expected for the moment (March 2023).

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

You can change the proposed name of the DCE.

Click Create to deploy.

B. Deploy Data Connection Rule and Custom Table

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.

Click + Create at the top.

In the Basics tab, fill the required fields and give a name to the DCE, like ESI-ExchangeServers.

'Make other preferable configuration changes', if needed, then click Create.

B. Create Custom DCR Table

Download the Example file from Microsoft Sentinel GitHub.

From the Azure Portal, navigate to Workspace Analytics and select your target Workspace.

Click in 'Tables', click + Create at the top and select New Custom log (DCR-Based).

In the Basics tab, enter MessageTrackingLog on the Table name, create a Data Collection rule with the name DCR-Option6-MessageTrackingLogs (for example) and select the previously created Data collection Endpoint.

In the Schema and Transformation tab, choose the downloaded sample file and click on Transformation Editor.

In the transformation field, enter the following KQL request : source | extend TimeGenerated = todatetime(['date-time']) | extend clientHostname = ['client-hostname'], clientIP = ['client-ip'], connectorId = ['connector-id'], customData = ['custom-data'], eventId = ['event-id'], internalMessageId = ['internal-message-id'], logId = ['log-id'], messageId = ['message-id'], messageInfo = ['message-info'], messageSubject = ['message-subject'], networkMessageId = ['network-message-id'], originalClientIp = ['original-client-ip'], originalServerIp = ['original-server-ip'], recipientAddress= ['recipient-address'], recipientCount= ['recipient-count'], recipientStatus= ['recipient-status'], relatedRecipientAddress= ['related-recipient-address'], returnPath= ['return-path'], senderAddress= ['sender-address'], senderHostname= ['server-hostname'], serverIp= ['server-ip'], sourceContext= ['source-context'], schemaVersion=['schema-version'], messageTrackingTenantId = ['tenant-id'], totalBytes = ['total-bytes'], transportTrafficType = ['transport-traffic-type'] | project-away ['client-ip'], ['client-hostname'], ['connector-id'], ['custom-data'], ['date-time'], ['event-id'], ['internal-message-id'], ['log-id'], ['message-id'], ['message-info'], ['message-subject'], ['network-message-id'], ['original-client-ip'], ['original-server-ip'], ['recipient-address'], ['recipient-count'], ['recipient-status'], ['related-recipient-address'], ['return-path'], ['sender-address'], ['server-hostname'], ['server-ip'], ['source-context'], ['schema-version'], ['tenant-id'], ['total-bytes'], ['transport-traffic-type']

Click 'Run' and after 'Apply'.

Click Next, then click Create.

C. Modify the created DCR, Type Custom log

From the Azure Portal, navigate to Azure Data collection rules.

Select the previously created DCR, like DCR-Option6-MessageTrackingLogs.

In the Resources tab, enter you Exchange Servers.

In Data Sources, add a Data Source type 'Custom Text logs' and enter 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking*.log' in file pattern, 'MessageTrackingLog_CL' in Table Name. 6.in Transform field, enter the following KQL request : source | extend TimeGenerated = todatetime(['date-time']) | extend clientHostname = ['client-hostname'], clientIP = ['client-ip'], connectorId = ['connector-id'], customData = ['custom-data'], eventId = ['event-id'], internalMessageId = ['internal-message-id'], logId = ['log-id'], messageId = ['message-id'], messageInfo = ['message-info'], messageSubject = ['message-subject'], networkMessageId = ['network-message-id'], originalClientIp = ['original-client-ip'], originalServerIp = ['original-server-ip'], recipientAddress= ['recipient-address'], recipientCount= ['recipient-count'], recipientStatus= ['recipient-status'], relatedRecipientAddress= ['related-recipient-address'], returnPath= ['return-path'], senderAddress= ['sender-address'], senderHostname= ['server-hostname'], serverIp= ['server-ip'], sourceContext= ['source-context'], schemaVersion=['schema-version'], messageTrackingTenantId = ['tenant-id'], totalBytes = ['total-bytes'], transportTrafficType = ['transport-traffic-type'] | project-away ['client-ip'], ['client-hostname'], ['connector-id'], ['custom-data'], ['date-time'], ['event-id'], ['internal-message-id'], ['log-id'], ['message-id'], ['message-info'], ['message-subject'], ['network-message-id'], ['original-client-ip'], ['original-server-ip'], ['recipient-address'], ['recipient-count'], ['recipient-status'], ['related-recipient-address'], ['return-path'], ['sender-address'], ['server-hostname'], ['server-ip'], ['source-context'], ['schema-version'], ['tenant-id'], ['total-bytes'], ['transport-traffic-type']

Click on 'Add data source'.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Data Collection Rules - When the legacy Azure Log Analytics Agent is used

Configure the logs to be collected

Under workspace Settings part, select Tables, click + Create and click on New custom log (MMA-Based).

Select Sample file MessageTracking Sample and click Next

Select type Windows and enter the path C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking*.log. Click Next.

Enter MessageTrackingLog as Table name and click Next.

Click Save.

Install Agent: <variable value provided at install time>

[Option 7] HTTP Proxy of Exchange Servers

Select how to stream HTTP Proxy of Exchange Servers

Data Collection Rules - When Azure Monitor Agent is used

Enable data collection rule Message Tracking are collected only from Windows agents.

Note: Attention, Custom logs in Monitor Agent is in Preview. The deployment doesn't work as expected for the moment (March 2023).

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the DCE and DCR.

A. Create DCE (If not already created for Exchange Servers)

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

You can change the proposed name of the DCE.

Click Create to deploy.

B. Deploy Data Connection Rule

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID 'and/or Other required fields'.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Automation

Use the following step-by-step instructions to deploy manually a Data Collection Rule.

A. Create DCE (If not already created for Exchange Servers)

From the Azure Portal, navigate to Azure Data collection Endpoint.

Click + Create at the top.

In the Basics tab, fill the required fields and give a name to the DCE.

'Make other preferable configuration changes', if needed, then click Create.

B. Create Custom DCR Table

Download the Example file from Microsoft Sentinel GitHub.

From the Azure Portal, navigate to Workspace Analytics and select your target Workspace.

Click in 'Tables', click + Create at the top and select New Custom log (DCR-Based).

In the Basics tab, enter ExchangeHttpProxy on the Table name, create a Data Collection rule with the name DCR-Option7-HTTPProxyLogs (for example) and select the previously created Data collection Endpoint.

In the Schema and Transformation tab, choose the downloaded sample file and click on Transformation Editor.

In the transformation field, enter the following KQL request : *source | extend TimeGenerated = todatetime(DateTime) | project-away DateTime

Click 'Run' and after 'Apply'.

Click Next, then click Create.

C. Modify the created DCR, Type Custom log

From the Azure Portal, navigate to Azure Data collection rules.

Select the previously created DCR, like DCR-Option7-HTTPProxyLogs.

In the Resources tab, enter you Exchange Servers.

In Data Sources, add a Data Source type 'Custom Text logs' and enter 'C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover*.log' in file pattern, 'ExchangeHttpProxy_CL' in Table Name. 6.in Transform field, enter the following KQL request : source | extend TimeGenerated = todatetime(DateTime) | project-away DateTime

Click on 'Add data source'.

Assign the DCR to all Exchange Servers

Add all your Exchange Servers to the DCR

Data Collection Rules - When the legacy Azure Log Analytics Agent is used

Configure the logs to be collected

Under workspace Settings part, select Tables, click + Create and click on New custom log (MMA-Based).

Select Sample file MessageTracking Sample and click Next

Select type Windows and enter all the following paths C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Eas*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ecp*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Oab*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\OwaCalendar*.log, C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\PowerShell*.log and C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttp*.log . Click Next.

Enter ExchangeHttpProxy as Table name and click Next.

Click Save.

Install Agent: <variable value provided at install time>

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected. Parsers are automatically deployed with the solution. Follow the steps to create the Kusto Functions alias : ExchangeAdminAuditLogs

Parsers are automatically deployed during Solution deployment. If you want to deploy manually, follow the steps below

Manual Parser Deployment

1. Download the Parser file

The latest version of the file ExchangeAdminAuditLogs

2. Create Parser ExchangeAdminAuditLogs function

In 'Logs' explorer of your Microsoft Sentinel's log analytics, copy the content of the file to Log explorer

3. Save Parser ExchangeAdminAuditLogs function

Click on save button. No parameter is needed for this parser. Click save again.

[Deprecated] Okta Single Sign-On (using Azure Function) (using Azure Functions)

Supported by: Microsoft Corporation

The Okta Single Sign-On (SSO) (using Azure Function) connector provides the capability to ingest audit and event logs from the Okta API into Microsoft Sentinel. The connector provides visibility into these log types in Microsoft Sentinel to view dashboards, create custom alerts, and to improve monitoring and investigation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Okta_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

Okta API Token: An Okta API Token is required. See the documentation to learn more about the Okta System Log API.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to Okta SSO to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

NOTE: This connector has been updated, if you have previously deployed an earlier version, and want to update, please delete the existing Okta Azure Function before redeploying this version.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the Okta SSO API

Follow these instructions to create an API Token.

Note - For more information on the rate limit restrictions enforced by Okta, please refer to the documentation.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Okta SSO connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the Okta SSO API Authorization Token, readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

This method provides an automated deployment of the Okta SSO connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID, Workspace Key, API Token and URI.

Use the following schema for the uri value: https://<OktaDomain>/api/v1/logs?since= Replace <OktaDomain> with your domain. Click here for further details on how to identify your Okta domain namespace. There is no need to add a time value to the URI, the Function App will dynamically append the inital start time of logs to UTC 0:00 for the current UTC date as time value to the URI in the proper format.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Okta SSO connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

Download the Azure Function App file. Extract archive to your local development computer.

Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.

After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following five (5) application settings individually, with their respective string values (case-sensitive): apiToken workspaceID workspaceKey uri logAnalyticsUri (optional)

Use the following schema for the uri value: https://<OktaDomain>/api/v1/logs?since= Replace <OktaDomain> with your domain. Click here for further details on how to identify your Okta domain namespace. There is no need to add a time value to the URI, the Function App will dynamically append the inital start time of logs to UTC 0:00 for the current UTC date as time value to the URI in the proper format.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

[Deprecated] SentinelOne (using Azure Function) (using Azure Functions)

Supported by: Microsoft Corporation

The SentinelOne data connector provides the capability to ingest common SentinelOne server objects such as Threats, Agents, Applications, Activities, Policies, Groups, and more events into Microsoft Sentinel through the REST API. Refer to API documentation: https://<SOneInstanceDomain>.sentinelone.net/api-doc/overview for more information. The connector enables event retrieval to assess potential security risks, monitor collaboration, and diagnose and troubleshoot configuration issues.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SentinelOne_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: SentinelOneAPIToken is required. See the documentation to learn more about API on the https://<SOneInstanceDomain>.sentinelone.net/api-doc/overview.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the SentinelOne API to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected which is deployed as part of the solution. To view the function code in Log Analytics, open Log Analytics/Microsoft Sentinel Logs blade, click Functions and search for the alias SentinelOne and load the function code or click here. The function usually takes 10-15 minutes to activate after solution installation/update.

STEP 1 - Configuration steps for the SentinelOne API

Follow the instructions to obtain the credentials.

Log in to the SentinelOne Management Console with Admin user credentials.

In the Management Console, click Settings.

In the SETTINGS view, click USERS

Click New User.

Enter the information for the new console user.

In Role, select Admin.

Click SAVE

Save credentials of the new user for using in the data connector.

NOTE :- Admin access can be delegated using custom roles. Please review SentinelOne documentation to learn more about custom RBAC.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the SentinelOne data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the SentinelOne Audit data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the SentinelOneAPIToken, SentinelOneUrl (https://<SOneInstanceDomain>.sentinelone.net) and deploy. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the SentinelOne Reports data connector manually with Azure Functions (Deployment via Visual Studio Code).

Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Start VS Code. Choose File in the main menu and select Open Folder.

Select the top level folder from extracted files.

Choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose the Deploy to function app button. If you aren't already signed in, choose the Azure icon in the Activity bar, then in the Azure: Functions area, choose Sign in to Azure If you're already signed in, go to the next step.

Provide the following information at the prompts:

a. Select folder: Choose a folder from your workspace or browse to one that contains your function app.

b. Select Subscription: Choose the subscription to use.

c. Select Create new Function App in Azure (Don't choose the Advanced option)

d. Enter a globally unique name for the function app: Type a name that is valid in a URL path. The name you type is validated to make sure that it's unique in Azure Functions. (e.g. SOneXXXXX).

e. Select a runtime: Choose Python 3.11.

f. Select a location for new resources. For better performance and lower costs choose the same region where Microsoft Sentinel is located.

Deployment will begin. A notification is displayed after your function app is created and the deployment package is applied.

Go to Azure Portal for the Function App configuration.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): SentinelOneAPIToken SentinelOneUrl WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

[Deprecated] Sophos Endpoint Protection (using Azure Function) (using Azure Functions)

Supported by: Microsoft Corporation

The Sophos Endpoint Protection data connector provides the capability to ingest Sophos events into Microsoft Sentinel. Refer to Sophos Central Admin documentation for more information.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SophosEP_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

REST API Credentials/permissions: API token is required. For more information, see API token

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to the Sophos Central APIs to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

NOTE: This data connector depends on a parser based on a Kusto Function to work as expected SophosEPEvent which is deployed with the Microsoft Sentinel Solution.

STEP 1 - Configuration steps for the Sophos Central API

Follow the instructions to obtain the credentials.

In Sophos Central Admin, go to Global Settings > API Token Management.

To create a new token, click Add token from the top-right corner of the screen.

Select a token name and click Save. The API Token Summary for this token is displayed.

Click Copy to copy your API Access URL + Headers from the API Token Summary section into your clipboard.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the Sophos Endpoint Protection data connector, have the Workspace ID and Workspace Primary Key (can be copied from the following).

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

Use this method for automated deployment of the Sophos Endpoint Protection data connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms

Select the preferred Subscription, Resource Group and Location.

NOTE: Within the same resource group, you can't mix Windows and Linux apps in the same region. Select existing resource group without Windows apps in it or create new resource group. 3. Enter the Sophos API Access URL and Headers, AzureSentinelWorkspaceId, AzureSentinelSharedKey. 4. Mark the checkbox labeled I agree to the terms and conditions stated above. 5. Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the Sophos Endpoint Protection data connector manually with Azure Functions (Deployment via Visual Studio Code).

Step 1 - Deploy a Function App

NOTE: You will need to prepare VS code for Azure function development.

Download the Azure Function App file. Extract archive to your local development computer.

Follow the function app manual deployment instructions to deploy the Azure Functions app using VSCode.

After successful deployment of the function app, follow next steps for configuring it.

Step 2 - Configure the Function App

Go to Azure Portal for the Function App configuration.

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select New application setting.

Add each of the following application settings individually, with their respective string values (case-sensitive): SOPHOS_TOKEN WorkspaceID WorkspaceKey logAnalyticsUri (optional)

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us.

Once all application settings have been entered, click Save.

[Deprecated] VMware Carbon Black Cloud (using Azure Function) (using Azure Functions)

Supported by: Microsoft

The VMware Carbon Black Cloud connector provides the capability to ingest Carbon Black data into Microsoft Sentinel. The connector provides visibility into Audit, Notification and Event logs in Microsoft Sentinel to view dashboards, create custom alerts, and to improve monitoring and investigation capabilities.

Log Analytics table(s):

Table DCR support Lake-only ingestion

CarbonBlackEvents_CL No No

CarbonBlackNotifications_CL No No

CarbonBlackAuditLogs_CL No No

Data collection rule support: Not currently supported

Prerequisites:

Microsoft.Web/sites permissions: Read and write permissions to Azure Functions to create a Function App is required. For more information, see Azure Functions.

VMware Carbon Black API Key(s): Carbon Black API and/or SIEM Level API Key(s) are required. See the documentation to learn more about the Carbon Black API.

A Carbon Black API access level API ID and Key is required for Audit and Event logs.

A Carbon Black SIEM access level API ID and Key is required for Notification alerts.

Amazon S3 REST API Credentials/permissions: AWS Access Key Id, AWS Secret Access Key, AWS S3 Bucket Name, Folder Name in AWS S3 Bucket are required for Amazon S3 REST API.

Setup Instructions:

NOTE: This connector uses Azure Functions to connect to VMware Carbon Black to pull its logs into Microsoft Sentinel. This might result in additional data ingestion costs. Check the Azure Functions pricing page for details.

(Optional Step) Securely store workspace and API authorization key(s) or token(s) in Azure Key Vault. Azure Key Vault provides a secure mechanism to store and retrieve key values. Follow these instructions to use Azure Key Vault with an Azure Function App.

STEP 1 - Configuration steps for the VMware Carbon Black API

Follow these instructions to create an API Key.

STEP 2 - Choose ONE from the following two deployment options to deploy the connector and the associated Azure Function

IMPORTANT: Before deploying the VMware Carbon Black connector, have the Workspace ID and Workspace Primary Key (can be copied from the following), as well as the VMware Carbon Black API Authorization Key(s), readily available.

Workspace ID: <variable value provided at install time>

Primary Key: <variable value provided at install time>

Option 1 - Azure Resource Manager (ARM) Template

This method provides an automated deployment of the VMware Carbon Black connector using an ARM Tempate.

Click the Deploy to Azure button below.

aka.ms aka.ms

Select the preferred Subscription, Resource Group and Location.

Enter the Workspace ID, Workspace Key, Log Types, API ID(s), API Key(s), Carbon Black Org Key, S3 Bucket Name, AWS Access Key Id, AWS Secret Access Key, EventPrefixFolderName,AlertPrefixFolderName, and validate the URI.

Enter the URI that corresponds to your region. The complete list of API URLs can be found here

The default Time Interval is set to pull the last five (5) minutes of data. If the time interval needs to be modified, it is recommended to change the Function App Timer Trigger accordingly (in the function.json file, post deployment) to prevent overlapping data ingestion.

Carbon Black requires a seperate set of API ID/Keys to ingest Notification alerts. Enter the SIEM API ID/Key values or leave blank, if not required.

Note: If using Azure Key Vault secrets for any of the values above, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Mark the checkbox labeled I agree to the terms and conditions stated above.

Click Purchase to deploy.

Option 2 - Manual Deployment of Azure Functions

Use the following step-by-step instructions to deploy the VMware Carbon Black connector manually with Azure Functions.

Create a Function App

From the Azure Portal, navigate to Function App, and select + Add.

In the Basics tab, ensure Runtime stack is set to Powershell Core.

In the Hosting tab, ensure the Consumption (Serverless) plan type is selected.

Make other preferrable configuration changes, if needed, then click Create.

Import Function App Code

In the newly created Function App, select Functions on the left pane and click + Add.

Select Timer Trigger.

Enter a unique Function Name and modify the cron schedule, if needed. The default value is set to run the Function App every 5 minutes. (Note: the Timer trigger should match the timeInterval value below to prevent overlapping data), click Create.

Click on Code + Test on the left pane.

Copy the Function App Code and paste into the Function App run.ps1 editor.

Click Save.

Configure the Function App

In the Function App, select the Function App Name and select Configuration.

In the Application settings tab, select + New application setting.

Add each of the following thirteen to sixteen (13-16) application settings individually, with their respective string values (case-sensitive): apiId apiKey workspaceID workspaceKey uri timeInterval CarbonBlackOrgKey CarbonBlackLogTypes s3BucketName EventPrefixFolderName AlertPrefixFolderName AWSAccessKeyId AWSSecretAccessKey SIEMapiId (Optional) SIEMapiKey (Optional) logAnalyticsUri (optional)

Enter the URI that corresponds to your region. The complete list of API URLs can be found here. The uri value must follow the following schema: https://<API URL>.conferdeploy.net - There is no need to add a time suffix to the URI, the Function App will dynamically append the Time Value to the URI in the proper format.

Set the timeInterval (in minutes) to the default value of 5 to correspond to the default Timer Trigger of every 5 minutes. If the time interval needs to be modified, it is recommended to change the Function App Timer Trigger accordingly to prevent overlapping data ingestion.

Carbon Black requires a seperate set of API ID/Keys to ingest Notification alerts. Enter the SIEMapiId and SIEMapiKey values, if needed, or omit, if not required.

Note: If using Azure Key Vault, use the@Microsoft.KeyVault(SecretUri={Security Identifier})schema in place of the string values. Refer to Key Vault references documentation for further details.

Use logAnalyticsUri to override the log analytics API endpoint for dedicated cloud. For example, for public cloud, leave the value empty; for Azure GovUS cloud environment, specify the value in the following format: https://<CustomerId>.ods.opinsights.azure.us

Once all application settings have been entered, click Save.

Island Enterprise Browser Admin Events (Legacy)

Supported by: Island

This is a legacy connector and is no longer recommended. Please use the Island Enterprise Browser V2 Data Connector instead, which supports user, admin and system events within a single connector.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Island_Admin_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Island API Key: An Island API key is required.

Setup Instructions:

Connect Island to Microsoft Sentinel

This is a legacy connector. For full setup instructions, refer to the official Island documentation (requires login to the Island Management Console).

Island Enterprise Browser User Events (Legacy)

Supported by: Island

This is a legacy connector and is no longer recommended. Please use the Island Enterprise Browser V2 Data Connector instead, which supports user, admin and system events within a single connector.

Log Analytics table(s):

Table DCR support Lake-only ingestion

Island_User_CL Yes Yes

Data collection rule support: Workspace transform DCR

Prerequisites:

Island API Key: An Island API key is required.

Setup Instructions:

Connect Island to Microsoft Sentinel

This is a legacy connector. For full setup instructions, refer to the official Island documentation (requires login to the Island Management Console).

Security Events via Legacy Agent

Supported by: Microsoft Corporation

You can stream all security events from the Windows machines connected to your Microsoft Sentinel workspace using the Windows agent. This connection enables you to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization’s network and improves your security operation capabilities. For more information, see the Microsoft Sentinel documentation.

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityEvent Yes Yes

Data collection rule support: Workspace transform DCR

Subscription-based Microsoft Defender for Cloud (Legacy)

Supported by: Microsoft Corporation

Microsoft Defender for Cloud is a security management tool that allows you to detect and quickly respond to threats across Azure, hybrid, and multi-cloud workloads. This connector allows you to stream your security alerts from Microsoft Defender for Cloud into Microsoft Sentinel, so you can view Defender data in workbooks, query it to produce alerts, and investigate and respond to incidents.

For more information>

Log Analytics table(s):

Table DCR support Lake-only ingestion

SecurityAlert Yes Yes

Data collection rule support: Workspace transform DCR

Syslog via Legacy Agent

Supported by: Microsoft Corporation

Syslog is an event logging protocol that is common to Linux. Applications will send messages that may be stored on the local machine or delivered to a Syslog collector. When the Agent for Linux is installed, it configures the local Syslog daemon to forward messages to the agent. The agent then sends the message to the workspace.

Learn more >

Log Analytics table(s):

Table DCR support Lake-only ingestion

Syslog Yes Yes

Data collection rule support: Workspace transform DCR

Next steps

For more information, see:

Microsoft Sentinel solutions catalog

Threat intelligence integration in Microsoft Sentinel

Tagasiside

Kas sellest lehest oli abi?

Last updated on 2026-05-14

Table	DCR support	Lake-only ingestion
`SecurityIncident`	Yes	Yes
`SecurityAlert`	Yes	Yes
`DeviceEvents`	Yes	Yes
`EmailEvents`	Yes	Yes
`IdentityLogonEvents`	Yes	Yes
`CloudAppEvents`	Yes	Yes
`AlertEvidence`	Yes	Yes

Table	DCR support	Lake-only ingestion
`SigninLogs`	Yes	Yes
`AuditLogs`	Yes	Yes
`AADNonInteractiveUserSignInLogs`	Yes	Yes
`AADServicePrincipalSignInLogs`	Yes	Yes
`AADManagedIdentitySignInLogs`	Yes	Yes
`AADProvisioningLogs`	Yes	Yes
`ADFSSignInLogs`	Yes	Yes
`AADUserRiskEvents`	Yes	Yes
`AADRiskyUsers`	Yes	Yes
`NetworkAccessTraffic`	Yes	Yes
`AADRiskyServicePrincipals`	Yes	Yes
`AADServicePrincipalRiskEvents`	Yes	Yes

Table	DCR support	Lake-only ingestion
`Awareness_Performance_Details_CL`	Yes	Yes
`Awareness_SafeScore_Details_CL`	Yes	Yes
`Awareness_User_Data_CL`	Yes	Yes
`Awareness_Watchlist_Details_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`Ttp_Url_CL`	Yes	Yes
`Ttp_Attachment_CL`	Yes	Yes
`Ttp_Impersonation_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`MimecastTTPUrl_CL`	No	No
`MimecastTTPAttachment_CL`	No	No
`MimecastTTPImpersonation_CL`	No	No

Table	DCR support	Lake-only ingestion
`alertscompromisedcredentialdata_CL`	No	No
`alertsctepdata_CL`	No	No
`alertsdlpdata_CL`	No	No
`alertsmalsitedata_CL`	No	No
`alertsmalwaredata_CL`	No	No
`alertspolicydata_CL`	No	No
`alertsquarantinedata_CL`	No	No
`alertsremediationdata_CL`	No	No
`alertssecurityassessmentdata_CL`	No	No
`alertsubadata_CL`	No	No
`eventsapplicationdata_CL`	No	No
`eventsauditdata_CL`	No	No
`eventsconnectiondata_CL`	No	No
`eventsincidentdata_CL`	No	No
`eventsnetworkdata_CL`	No	No
`eventspagedata_CL`	No	No
`Netskope_WebTx_metrics_CL`	No	No

Table	DCR support	Lake-only ingestion
`OpenSystemsZtnaLogs_CL`	Yes	Yes
`OpenSystemsFirewallLogs_CL`	No	No
`OpenSystemsAuthenticationLogs_CL`	No	No
`OpenSystemsProxyLogs_CL`	No	No

Table	DCR support	Lake-only ingestion
`PaloAltoCortexXDR_Incidents_CL`	Yes	Yes
`PaloAltoCortexXDR_Endpoints_CL`	Yes	Yes
`PaloAltoCortexXDR_Audit_Management_CL`	Yes	Yes
`PaloAltoCortexXDR_Audit_Agent_CL`	Yes	Yes
`PaloAltoCortexXDR_Alerts_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`ProofpointPODMailLog_CL`	Yes	Yes
`ProofpointPODMessage_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`ProofPointTAPMessagesDeliveredV2_CL`	Yes	Yes
`ProofPointTAPMessagesBlockedV2_CL`	Yes	Yes
`ProofPointTAPClicksPermittedV2_CL`	Yes	Yes
`ProofPointTAPClicksBlockedV2_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`NexposeInsightVMCloud_assets_CL`	No	No
`NexposeInsightVMCloud_vulnerabilities_CL`	No	No

Table	DCR support	Lake-only ingestion
`Rapid7InsightVMCloudAssets`	Yes	Yes
`Rapid7InsightVMCloudVulnerabilities`	Yes	Yes

Table	DCR support	Lake-only ingestion
`Rubrik_Anomaly_Data_CL`	Yes	Yes
`Rubrik_Ransomware_Data_CL`	Yes	Yes
`Rubrik_ThreatHunt_Data_CL`	Yes	Yes
`Rubrik_Events_Data_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`LightningTier0Nodes_CL`	No	No
`LightningAttackPaths_CL`	No	No
`LightningIOEResults_CL`	No	No

Table	DCR support	Lake-only ingestion
`SentinelOneActivities_CL`	Yes	Yes
`SentinelOneAgents_CL`	Yes	Yes
`SentinelOneGroups_CL`	Yes	Yes
`SentinelOneThreats_CL`	Yes	Yes
`SentinelOneAlerts_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`SnowflakeLogin_CL`	Yes	Yes
`SnowflakeQuery_CL`	Yes	Yes
`SnowflakeUserGrant_CL`	Yes	Yes
`SnowflakeRoleGrant_CL`	Yes	Yes
`SnowflakeLoad_CL`	Yes	Yes
`SnowflakeMaterializedView_CL`	Yes	Yes
`SnowflakeRoles_CL`	Yes	Yes
`SnowflakeTables_CL`	Yes	Yes
`SnowflakeTableStorageMetrics_CL`	Yes	Yes
`SnowflakeUsers_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`Cymru_Scout_Domain_Data_CL`	No	No
`Cymru_Scout_IP_Data_Foundation_CL`	No	No
`Cymru_Scout_IP_Data_Details_CL`	No	No
`Cymru_Scout_IP_Data_Communications_CL`	No	No
`Cymru_Scout_IP_Data_PDNS_CL`	No	No
`Cymru_Scout_IP_Data_Fingerprints_CL`	No	No
`Cymru_Scout_IP_Data_OpenPorts_CL`	No	No
`Cymru_Scout_IP_Data_x509_CL`	No	No
`Cymru_Scout_IP_Data_Summary_Details_CL`	No	No
`Cymru_Scout_IP_Data_Summary_PDNS_CL`	No	No
`Cymru_Scout_IP_Data_Summary_OpenPorts_CL`	No	No
`Cymru_Scout_IP_Data_Summary_Certs_CL`	No	No
`Cymru_Scout_IP_Data_Summary_Fingerprints_CL`	No	No
`Cymru_Scout_Account_Usage_Data_CL`	No	No

Table	DCR support	Lake-only ingestion
`Tenable_VM_Asset_CL`	Yes	Yes
`Tenable_VM_Vuln_CL`	Yes	Yes
`Tenable_VM_Compliance_CL`	Yes	Yes
`Tenable_WAS_Asset_CL`	Yes	Yes
`Tenable_WAS_Vuln_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`TrendMicro_XDR_WORKBENCH_CL`	No	No
`TrendMicro_XDR_RCA_Task_CL`	No	No
`TrendMicro_XDR_RCA_Result_CL`	No	No
`TrendMicro_XDR_OAT_CL`	No	No

Parameter	Description
`WorkspaceName`	Name of your Log Analytics / Microsoft Sentinel workspace
`UpwindOrgId`	Upwind Organization ID from Step 1
`UpwindClientId`	Upwind API Client ID from Step 1
`UpwindClientSecret`	Upwind API Client Secret from Step 1
`AppInsightsWorkspaceResourceID`	Full Resource ID of the Log Analytics workspace (from Log Analytics workspace → Properties)

Find your Microsoft Sentinel data connector

Data connector prerequisites

Syslog and Common Event Format (CEF) connectors

Custom Logs via AMA connector

Sentinel data connectors

For each template, create Stack in AWS:

Post-deployment Configuration:

Sending Logs:

Table Mapping:

For each template, create Stack in AWS:

For each template, create Stack in AWS:

For each template, create Stack in AWS:

Option A: Auto-Create Microsoft Entra Application (Recommended)

Option B: Use Pre-Existing Microsoft Entra Application (BYOA)

Azure Configuration Values:

Configure in Contrast ADR Platform

For each template, create Stack in AWS:

Required Indices

Creating an API Key

NOTE - UPDATE:

The PoD Log API does not allow use of the same token for more than one session at the same time, so make sure your token isn't used anywhere.

The PoD Log API does not allow use of the same token for more than one session at the same time, so make sure your token isn't used anywhere.

For each template, create Stack in AWS:

Step 2: Get Your App Credentials

Security Notes

Monitoring

Deprecated Sentinel data connectors

Next steps

Tagasiside

Lisaressursid

Table	DCR support	Lake-only ingestion
`Detections_Data_CL`	Yes	Yes
`Audits_Data_CL`	Yes	Yes
`Entity_Scoring_Data_CL`	Yes	Yes
`Lockdown_Data_CL`	Yes	Yes
`Health_Data_CL`	Yes	Yes
`Entities_Data_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`VeeamMalwareEvents_CL`	Yes	Yes
`VeeamSecurityComplianceAnalyzer_CL`	Yes	Yes
`VeeamOneTriggeredAlarms_CL`	Yes	Yes
`VeeamAuthorizationEvents_CL`	Yes	Yes
`VeeamCovewareFindings_CL`	Yes	Yes
`VeeamSessions_CL`	Yes	Yes

Event type	S3 prefix
Alert	carbon-black-cloud-forwarder/Alerts
Auth Events	carbon-black-cloud-forwarder/Auth
Endpoint Events	carbon-black-cloud-forwarder/Endpoint
Watchlist Hit	carbon-black-cloud-forwarder/Watchlist

Table	DCR support	Lake-only ingestion
`union isfuzzy=true (WizIssues_CL),(WizIssuesV2_CL)`	No	No
`union isfuzzy=true (WizVulnerabilities_CL),(WizVulnerabilitiesV2_CL)`	No	No
`union isfuzzy=true (WizAuditLogs_CL),(WizAuditLogsV2_CL)`	No	No

Table	DCR support	Lake-only ingestion
`XbowAssets_CL`	No	No
`XbowFindings_CL`	No	No
`XbowAssessments_CL`	No	No

Parameter	Description
`WorkspaceName`	Name of your Log Analytics / Microsoft Sentinel workspace
`XbowApiToken`	XBOW Personal Access Token from Step 1
`XbowOrgId`	XBOW Organization ID from Step 1
`TenantId`	Azure AD Tenant ID from Step 2
`ClientId`	App Registration Client ID from Step 2
`ClientSecret`	App Registration Client Secret from Step 2
`AppInsightsWorkspaceResourceID`	Full Resource ID of the Log Analytics workspace (from Log Analytics workspace > Properties)
`FunctionAppLocation`	Optional Azure region for Function App resources (defaults to the Resource Group location)

Table	DCR support	Lake-only ingestion
`ZNAudit_CL`	Yes	Yes
`ZNNetworkActivity_CL`	Yes	Yes
`ZNIdentityActivity_CL`	Yes	Yes
`ZNRPCActivity_CL`	Yes	Yes

Table	DCR support	Lake-only ingestion
`ZeroFox_CTI_advanced_dark_web_CL`	No	No
`ZeroFox_CTI_botnet_CL`	No	No
`ZeroFox_CTI_breaches_CL`	No	No
`ZeroFox_CTI_C2_CL`	No	No
`ZeroFox_CTI_compromised_credentials_CL`	No	No
`ZeroFox_CTI_credit_cards_CL`	No	No
`ZeroFox_CTI_dark_web_CL`	No	No
`ZeroFox_CTI_discord_CL`	No	No
`ZeroFox_CTI_disruption_CL`	No	No
`ZeroFox_CTI_email_addresses_CL`	No	No
`ZeroFox_CTI_exploits_CL`	No	No
`ZeroFox_CTI_irc_CL`	No	No
`ZeroFox_CTI_malware_CL`	No	No
`ZeroFox_CTI_national_ids_CL`	No	No
`ZeroFox_CTI_phishing_CL`	No	No
`ZeroFox_CTI_phone_numbers_CL`	No	No
`ZeroFox_CTI_ransomware_CL`	No	No
`ZeroFox_CTI_telegram_CL`	No	No
`ZeroFox_CTI_threat_actors_CL`	No	No
`ZeroFox_CTI_vulnerabilities_CL`	No	No

Table	DCR support	Lake-only ingestion
`CarbonBlackEvents_CL`	No	No
`CarbonBlackNotifications_CL`	No	No
`CarbonBlackAuditLogs_CL`	No	No