Integrating Cato Events with Microsoft Sentinel Using the Turnkey Integration

Overview

Use this Microsoft Sentinel integration to include Cato event data in your existing monitoring, correlation, and investigation workflows.

This article covers the native turnkey integration: Cato creates and manages an Entra application in your tenant, sends events directly to Sentinel, and maps them automatically to Sentinel's data model. It is the recommended method for most accounts because it needs the least ongoing attention after setup.

Cato also offers a Content Hub integration, which is installed from the Microsoft Sentinel Content Hub. With that method, you own the Entra application, and Cato receives permission to write events and nothing else. For a full comparison, review the guidance in Integrating Cato Events with Microsoft Sentinel.

Process and Owners

Prerequisites

• A Microsoft tenant integration already configured in the CMA, under Resources > Integrations > Configured Integrations. This is the parent connector for Microsoft applications. Configure it once and reuse it across all Microsoft integrations.

• Editor permission for Integrations (in the Resources section). For more information, see Managing Admin Roles Using RBAC.

• An existing Log Analytics workspace in Sentinel to receive Cato events.

• An Azure account with permission to deploy ARM templates and grant role assignments in the target subscription and resource group.

• Review the prerequisites for all Cato event integrations in Getting Started with Event Integrations.

Understanding the Integration's Architecture

Understanding the underlying model helps explain why certain steps exist, and what to check if events aren't flowing as expected.

This is a high-level architecture diagram:

Step 1: Entra ID admin consent (before the tenant connector)

Approving the tenant connector triggers an OAuth consent prompt against your Microsoft Entra tenant. Before your Entra ID admin approves this, they should know exactly what is being granted:

• The only Microsoft Graph permission requested is Application.ReadWrite.OwnedBy. It grants Cato's multi-tenant application two capabilities, and only for applications the tenant connector itself creates:

  • The ability to create new app registrations in your tenant.

  • Read/write access, at any time, to the applications it created, not to any other application in your tenant.

• It does not grant blanket tenant access. Newly created applications start with zero permissions: no Graph API scopes and no Azure RBAC roles. They cannot do anything until you consent to specific permissions for that connector (for example, through the Sentinel ARM template below, or an OAuth consent screen for other connector types).

• Each application created this way is dedicated to your tenant alone. It is never shared with, or joint across, any other Cato customer.

Tenant-wide admin consent in Microsoft Entra requires one of the following roles:

• Privileged Role Administrator, which can consent to any permission for any API

• Cloud Application Administrator or Application Administrator, which can consent to most permissions but with some exceptions for Microsoft Graph application permissions

• Global Administrator, which can also grant consent

To grant admin consent:

1. Go to the Entra admin center and navigate to Identity > Applications > Enterprise applications.

2. Locate the application.

3. Go to Security > Permissions and select Grant admin consent.

For the full prerequisites and step-by-step instructions, see the Microsoft Entra documentation.

Step 2: Tenant connector (one-time, prerequisite)

Before any Sentinel-specific setup, you approve Cato's tenant connector, shown in the CMA as "Microsoft 365 (New Tenant)". This is backed by Cato's own multi-tenant application, which resides in Cato's tenant, not yours. You can revoke this approval at any time.

Approving it grants Cato only one capability: the permission to create new app registrations inside your tenant. It does not grant those apps any access on its own. Every permission a created app receives still requires your explicit approval, either via OAuth consent or via the ARM template deployment below.

This connector is shared across all Microsoft-family integrations, not just Sentinel. The tenant connector is used by every Cato connector that integrates with a Microsoft product: Sentinel, Intune, CASB/DLP, Defender, and others. You approve the tenant connector once; after that, each time you create a new Microsoft-family connector in the CMA, a separate, dedicated app registration is created in your tenant for that connector specifically. Creating a Sentinel connector does not grant any access related to Intune or other Microsoft products. Each connector gets its own app with its own permissions.

Apps created by the tenant connector authenticate using a certificate (not a client secret). Cato manages certificate rotation and lifecycle automatically. When you delete a connector in the CMA, Cato deletes the corresponding app registration it created for that connector; app registrations don't outlive the connector that created them.

Benefits of the tenant connector model:

• One-time approval for app creation. You approve the tenant connector once, and every future Microsoft-family connector (Sentinel, Intune, CASB/DLP, Defender, and so on) gets its own app registration automatically under that approval, without a separate approval for the registration itself. Each connector still has its own consent step for the permissions it needs, as described below.

• Automatic cleanup (no orphaned app registrations). Deleting a connector in the CMA removes the app registration Cato created for it in the same action. There's nothing left behind in your tenant to track down and clean up manually.

• Certificate-based auth with automatic rotation. Because Cato creates and manages these app registrations, it also owns certificate rotation for their lifetime. Registering the app yourself would mean taking on that rotation as an ongoing operational task.

• Zero permissions by default. Every app the tenant connector creates starts with no API scopes and no Azure RBAC roles. Access is only added in a later, explicit step (an ARM deployment or OAuth consent screen).

• Per-connector isolation. Each Microsoft-family connector gets its own dedicated app registration. A Sentinel connector's app has no bearing on an Intune or CASB connector's access, and vice versa.

If your organization requires that applications in your tenant are registered and owned by you rather than by Cato, use the Content Hub integration instead. It does not use the tenant connector.

Step 3: Sentinel Connector Setup

App Creation

When you start a new Sentinel connector in the CMA, the parent connector uses its capability to create a new per-customer app registration in your tenant. This is what the progress loader (0-100%) in the CMA represents. At this point, the app exists but has no permissions and no resources yet.

ARM Template Deployment ("Deploy to Azure")

Clicking through takes you to a pre-populated ARM template that you deploy in your own Azure portal, under your own credentials. This is the step where:

• You approve the app's scoped permissions

• Sentinel resources are actually provisioned

• Cato's Service Principal receives its role assignments

Cato never deploys directly into your tenant. Deployment is always customer-initiated and customer-executed. The template provisions:

The template does not create a Data Collection Endpoint. Azure Data Collection Rules now expose their own ingestion endpoint directly, which is what keeps the template's resource count and permission scope minimal.

Step 4: Ongoing Schema Management

As Cato's event schema evolves, the DCR and table schema need updating so that new fields are ingested. Cato adds event fields frequently, and until a field exists in your DCR and table, its values are not stored.

Cato can apply these updates for you, using the roles granted during ARM deployment. This behavior is controlled by the Auto Update Schema setting on the integration, and depends on Cato's Service Principal retaining those roles.

For how to enable it, see Keeping the Event Schema Up to Date.

The three role assignments serve two distinct purposes, and removing them has different consequences:

• Removing Monitoring Metrics Publisher (on the DCR) stops data ingestion entirely. This is a full outage, not a degraded mode. No new events reach Sentinel.

• Removing either custom role (DCR Manager / Table Manager) does not stop existing ingestion; it only prevents Cato from applying future schema updates, so new event fields won't appear in your table until the roles are restored.

Recommendation: If your organization runs periodic access reviews, flag Cato's Service Principal for renewal rather than removal.

Setting Up the Integration

Creating the Microsoft Tenant Integration (one-time)

The MS tenant connector is a parent connector for other Microsoft apps, as explained in the prerequisites. If you have already created it for a different Microsoft integration, you don't need to repeat this procedure for your Sentinel integration.

To create the MS Tenant integration:

1. From the CMA's navigation menu, select Resources > Integrations, and then click the Configured Integrations tab.

2. Click New. The New Connector panel opens.

3. In the New Connector panel, select the MS Tenant (Configure a new MS Tenant) app.

4. Enter the Connector Name.

5. Click Authorize and Save.

   A new browser tab opens to the Microsoft 365 app.

6. In the new browser tab, authenticate to the Microsoft 365 app:

   1. Select the Microsoft account for the Microsoft 365 app.

      Otherwise, there may be a Microsoft authentication error.

   2. Enter the password for the Microsoft account and approve it.

   3. Accept the permissions to let Cato access the Microsoft 365 app.

      A success page shows that the permissions were applied.

   4. You can close the browser tab and return to the CMA.

7. The Microsoft 365 app now appears under the Integrated Apps tab.

Creating the Sentinel Integration

To create the Sentinel integration:

1. From the navigation menu, select Resources > Integrations.

2. On the Configured Integrations tab, click New. The New Integration panel opens.

3. Select Microsoft Sentinel, and in the Auth field, select Consent ARM template authentication for Microsoft Sentinel.

4. Configure the following fields:

   • Enter a Name for this integration

   • Select the name of the MS tenant integration in the Parent ID field

   • Enter your existing Workspace Name that receives the data in Microsoft Log Analytics

   • Enter a new Table Name to hold the data in the Log Analytics Workspace with this name (Cato appends _CL)

   • Define how many days you want Microsoft to retain Cato data in the Table Retention Days field

   • Under Data Sources, enable Auto Update Schema. See Keeping the Event Schema Up to Date

   • Optional: Add filters to control which Cato events are sent to Microsoft Sentinel, as described below

5. Click Save to deploy the integration to Microsoft.

   Note: You now have 10 minutes to complete the setup in Microsoft.

6. A browser tab opens and directs you to authorize the creation of the integration in Microsoft.

   Note: You must authorize the integration with the same tenant used to create the MS tenant integration. The signed-in user must have permission to create resources in that tenant.

7. In the Microsoft portal, select the resource group and region that contain the target Log Analytics workspace, and click Review + Create.

8. Click Create to start the deployment.

9. When the deployment is complete, you can close the Microsoft tab.

10. In the CMA, refresh the Integrations page. The integration status appears in the Integrated Apps tab.

Keeping the Event Schema Up to Date

Cato adds new fields to its event schema regularly. For a new field to reach Sentinel, it has to be added to both the Data Collection Rule and the custom table in your workspace.

Note: This is an Early Availability (EA) feature that is only available for limited release. For more information, contact your Cato Networks representative or send an email to ea@catonetworks.com.

The Auto Update Schema setting controls whether Cato does this for you:

• Enabled - when Cato adds an event field, it adds the corresponding column to your Data Collection Rule and table automatically. There is no downtime and no data loss while an update is applied, and no action is needed from you.

• Disabled - your Data Collection Rule and table keep their current columns. Events continue to be ingested, but any field Cato has added since the integration was deployed is not stored.

Auto Update Schema is off by default, on both new and existing integrations.

Turning it on means that Cato modifies the Data Collection Rule and the custom table in your Log Analytics workspace whenever the event schema changes. Whether that is acceptable is a decision for your organization. Many do not allow a vendor to make changes in their workspace, and for them the setting should stay off.

Leaving it off has a cost: event fields that Cato adds after your integration is deployed are not stored, and Cato does not provide a self-service way to apply them on this method. If you need both control over your workspace and a way to keep the schema current, use the Content Hub integration instead.

The roles that let Cato make these changes are granted when you deploy the ARM template, whether or not the setting is on. The setting controls only whether Cato uses them. See Step 4: Ongoing Schema Management for what happens if you remove them.

To enable automatic schema updates on an existing integration:

1. From the navigation menu, select Resources > Integrations, and then click the Configured Integrations tab.

2. Expand the Microsoft Sentinel row and click the name of the integration. The Edit Integration panel opens.

3. Under Data Sources, turn on Auto Update Schema.

4. Click Save.

Note:

Automatic schema updates depend on Cato's Service Principal keeping the two custom roles granted during the ARM deployment. If those roles are removed, ingestion continues, but new fields stop appearing in your table. See Step 4: Ongoing Schema Management.

Verifying the integration is working

After setup, confirm:

• The new table (with the _CL suffix) appears in your Log Analytics workspace under Tables.

• The connector status in the CMA's Integrated Apps tab shows as connected / healthy.

• Sample events appear in the table within a few minutes of traffic. Query with <YourTableName>_CL | take 10 in Log Analytics.

• In Azure, Cato's Service Principal still holds its granted roles on the DCR and table resources.

Configure Filters

Use filters to control which Cato events are exported to Microsoft Sentinel. This helps reduce ingestion costs, minimize noise, and focus investigations on the events that are most relevant to specific sites, users, or regions. You can also use filters to route different subsets of events to different SIEM environments.

Use filter groups to define filters based on any Event Field or combination of fields. Conditions within each group use AND logic. OR logic is applied between groups. The filters in the screenshot configure the integration to export:

• Events that originate from Paris or Madrid, are of sub-type Internet Firewall, and resulted in actions other than Monitor or Prompt

• Username contains Test

Known Limitations

• Large event limitation: Some XOps events can include extensive story information in the raw_data field, which may cause the event to exceed Microsoft Sentinel ingestion size limits (approximately 1 MB). When this occurs, Cato still forwards the event to Sentinel, but omits the raw_data field to maintain compatibility with Sentinel ingestion requirements.

• Schema update dependency: ongoing schema updates depend on Cato's Service Principal retaining its granted roles. If your organization runs periodic access reviews, flag this Service Principal to avoid unintentional role removal breaking future ingestion.