Cato Networks solution: CCF Push data connector for Cato Cloud events

[yoelk]

Change(s):

• New solution: Cato Networks (Solutions/CatoNetworks), a CCF Push data connector for Cato Cloud security and networking events.
• Creates the custom table CatoNetworksEvents_CL and declares the stream Custom-CatoNetworksEvents; transformKql maps the Cato event schema onto the table, deriving TimeGenerated from Cato's epoch-millisecond time field and renaming title to activity_title.
• Adds Logos/catonetworks.svg.
• Registers the custom table in .script/tests/KqlvalidationsTests/CustomTables/CatoNetworksEvents_CL.json.
• Adds CatoNetworksEventsPush to .script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json (append only; 351 -> 352 entries, nothing removed).

Reason for Change(s):

• Cato Networks is publishing a Sentinel solution so customers can receive Cato events through the Codeless Connector Framework. Cato pushes batched events server to server with OAuth2 client credentials to the data collection rule provisioned by the connector page's Deploy action, so the customer owns the Entra application and grants Cato the Monitoring Metrics Publisher role on that rule and nothing else.
• This is a first submission; there is no existing Cato solution in the repo to update.

Version Updated:

• Not applicable. No Detections or Analytic Rule templates are included in this release. Analytic rules and ASIM parsers are planned for a later version.

Testing Completed:

• Yes. Package/mainTemplate.json was deployed into a Microsoft Sentinel workspace with no custom parsers, functions or tables. The connector page renders, Deploy provisions the Entra application, data collection endpoint, data collection rule, custom table and the role assignment, a batch of events is accepted, rows land in CatoNetworksEvents_CL, and the connector reports Connected.
• Package/ was produced by Tools/Create-Azure-Sentinel-Solution/V3/createSolutionV3.ps1 in catalog version mode, not hand written.

Checked that the validations are passing and have addressed any issues that are present:

• Yes, with one caveat. node .script/local-validation/validate.js --path "Solutions/CatoNetworks" reports 47 passed, 3 failed, 40 skipped. The Solution checks (9 passed) and ARM-TTK (2 passed) pass.
• The three failures are environment, not content: the KQL Validation, Detection Template Schema and Non-ASCII suites could not execute on the submitting machine. Two target netcoreapp3.1, which requires an x64 .NET host and this is arm64, and the third needs the .NET 8 runtime, which is not installed. Each aborts with Could not find 'dotnet' host for the 'X64' architecture or You must install or update .NET to run this application before running a single test.
• Happy to act on anything CI surfaces from those three suites.

[yoelk]

@microsoft-github-policy-service agree company="Cato Networks"

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a new Microsoft Sentinel solution for Cato Networks implementing a CCF Push data connector that ingests Cato Cloud events into a custom Log Analytics table.

Changes:

• Introduces the new solution scaffold (Solutions/CatoNetworks) including metadata, release notes, and ARM UI/parameters.
• Adds the Push connector definition/resources (DCR, custom table schema, connector definition + instance).
• Registers the connector ID and custom table schema in repo validation lists.

Reviewed changes

Copilot reviewed 11 out of 14 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
Solutions/CatoNetworks/SolutionMetadata.json	Adds solution marketplace metadata (publisher/offer/support/categories/dates).
Solutions/CatoNetworks/ReleaseNotes.md	Adds initial release notes entry for the solution.
Solutions/CatoNetworks/Package/testParameters.json	Adds ARM test parameters used for validation/deployment.
Solutions/CatoNetworks/Package/createUiDefinition.json	Adds the Sentinel solution install UI (workspace selector + copyable setup values).
Solutions/CatoNetworks/Data/Solution_CatoNetworks.json	Adds solution packaging descriptor pointing to connector definition and metadata.
Solutions/CatoNetworks/Data Connectors/CatoNetworks_PUSH_CCP/table.json	Defines the custom table CatoNetworksEvents_CL schema.
Solutions/CatoNetworks/Data Connectors/CatoNetworks_PUSH_CCP/dataConnector.json	Defines the Push data connector instance wiring to DCR/DCE + auth outputs.
Solutions/CatoNetworks/Data Connectors/CatoNetworks_PUSH_CCP/connectorDefinition.json	Defines connector UI, instructions, queries, and permissions.
Solutions/CatoNetworks/Data Connectors/CatoNetworks_PUSH_CCP/DCR.json	Defines stream + transformKql mapping from Cato payload to custom table.
.script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json	Registers the connector ID for schema validation.
.script/tests/KqlvalidationsTests/CustomTables/CatoNetworksEvents_CL.json	Registers the custom table schema for KQL validation tests.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[yoelk]

Thanks for the review. I rebased onto current master to clear the conflict — the PR is mergeable again at 14 files.

I checked each of the five findings against what is already merged in this repo rather than answer from first principles. Four of them describe the repo's own conventions or the packager's own output, so I have not changed them; the fifth is a deliberate design choice I would rather explain than quietly alter. Happy to be overruled on any of these.

BasePath is machine-specific — this is the convention here. Of 400 merged Data/Solution_*.json files sampled, 363 commit a Windows absolute path, 20 relative, 11 unix absolute, 6 absent. Examples include Microsoft Defender XDR and CrowdStrike Falcon Endpoint Protection, both C:\GitHub\Azure-Sentinel\Solutions\.... Our build rewrites the value inside the checkout it packages in and restores the placeholder before committing, so it is never read from the committed file. Removing it would make us the outlier.

RetryCount should be camelCase — it is PascalCase in the schema. All 35 merged Push connectors in this repo spell it RetryCount; there are no camelCase instances. Renaming it would break the connector.

docs.microsoft.com in createUiDefinition.json — that file is generated by Tools/Create-Azure-Sentinel-Solution/V3/createSolutionV3.ps1, and the URL is written by the packager itself: Tools/Create-Azure-Sentinel-Solution/common/commonFunctions.ps1 lines 696, 1075 and 2237. 186 of 200 merged createUiDefinition.json files contain it. Editing it would mean hand-modifying the packager's output, which the contribution guidance asks contributors not to do. If the link should move to learn.microsoft.com, the fix belongs in commonFunctions.ps1 and would benefit every solution at once — happy to raise that separately.

The ReleaseNotes table has an extra leading pipe — I do not think it does. The row is | **Version** | **Date Modified (DD-MM-YYYY)** | **Change History** |, a single leading pipe with three cells and a matching separator row. The only difference from most merged files is that our headers are bold. If it renders wrongly for you, please point at the rendered output and I will fix it.

The update template is linked from an external repo on a mutable branch — this one is a real design decision, so it deserves a real answer.

Cato's event schema grows more often than a solution version is published. Under CCF Push we hold Monitoring Metrics Publisher on the customer's data collection rule and nothing else, so we cannot add a column to their table; only the customer can. That template is how they do it, and it has to be reachable between solution releases.

Pinning it to a commit SHA would freeze customers on whichever schema existed at release and defeat the purpose. The template is desired-state and strictly append-only — columns are added, never removed or retyped, enforced by a checked-in baseline on our side — so "latest" is always the correct thing to apply, and applying an older one could only ever remove columns a customer already has.

I did originally ship this template inside Package/, and removed it before submitting: across 559 merged solutions Package/ contains only <version>.zip, mainTemplate.json, createUiDefinition.json and testParameters.json, and adding a fifth file to the packager's output directory seemed worse than linking out.

If there is a supported pattern for shipping a customer-applied schema update inside a solution, I would much rather use it — that question is open with the App Assure team and I have no strong attachment to the current approach.

[yoelk]

Adding here a screenshot, showing the connector on my tenant as connected

[v-maheshbh (v-maheshbh)]

Hi yoelk

Kindly ensure all CCF files follow the naming convention:
SolutionName_ConnectorDefinition, SolutionName_dataConnector, SolutionName_DCR and that the file name prefix matches the solution name consistently.

Thanks!

[yoelk]

Thanks v-maheshbh (@v-maheshbh) — done, pushed in b2cbc04.

All four CCF files under Solutions/CatoNetworks/Data Connectors/CatoNetworks_PUSH_CCP/ now carry the solution-name prefix:

Before	After
connectorDefinition.json	CatoNetworks_ConnectorDefinition.json
dataConnector.json	CatoNetworks_dataConnector.json
DCR.json	CatoNetworks_DCR.json
table.json	CatoNetworks_table.json

I prefixed table.json as well, so the whole directory is consistent rather than just the three named.

The only other change is the corresponding path in Data/Solution_CatoNetworks.json. The Package/ output is unchanged, since the packager derives it from the file contents rather than their names — re-running createSolutionV3.ps1 after the rename produced an identical mainTemplate.json, createUiDefinition.json and 3.0.0.zip.

Let me know if anything else needs adjusting.

[yoelk]

Small correction to my previous comment: I said the packager was re-run after the rename and produced identical output. That was imprecise — the packager was not re-run; Package/ is untouched since the 3.0.0 build on 30 Aug.

The conclusion still holds, and here is the actual basis for it rather than an inference:

• Package/mainTemplate.json and Package/createUiDefinition.json contain zero references to any source filename (connectorDefinition.json, dataConnector.json, DCR.json, table.json, or their prefixed forms) — the packager inlines the file contents, so the rename cannot affect them.
• Package/3.0.0.zip contains exactly two entries, mainTemplate.json and createUiDefinition.json, both matching the committed copies.

So the committed Package/ output is already correct for the renamed sources. Happy to re-run createSolutionV3.ps1 and push the regenerated artifacts anyway if you would rather see them rebuilt on top of the rename.