REVIEW ONLY — Cato Networks CCF Push solution 3.0.0

[yoelk]

Internal review before submitting to Microsoft. Do not merge.

This PR targets master of this fork rather than Azure/Azure-Sentinel, purely so the diff is reviewable. When review is done the same branch is submitted upstream and this PR is closed. Merging here would make the fork diverge from upstream for no reason.

What this is

A second, self-service way for customers to get Cato events into Microsoft Sentinel. They install it from Microsoft's Content Hub, own the Entra application themselves, and grant Cato permission to write events to one Data Collection Rule and nothing else. It sits alongside the existing turnkey integration rather than replacing it.

15 files: 14 added, 1 modified.

---

1. The connector — what customers actually touch

connectorDefinition.json is the connector page rendered inside the customer's Azure portal. The most worthwhile file to review, because it is the product surface.

• Title Cato Networks Events (Push), publisher Cato Networks, id CatoNetworksEventsPush
• Three instruction steps: deploy the ARM resources, paste six values into the CMA, keep the schema current
• Step 2 renders six CopyableLabel fields that auto-fill after deployment: Tenant ID, Application ID, Secret, Data Collection Endpoint URI, Data Collection Rule Immutable ID, stream name
• Declares the permissions a customer needs before deploying

dataConnector.json is the runtime binding: kind: Push, stream Custom-CatoNetworksEvents. Short, but it is what makes the connector report Connected.

2. The schema — generated, not worth reading line by line

table.json (399 columns) and DCR.json (stream declaration plus transformKql).

• Generated from the live Cato event schema by services/events-log/cato-sentinel-solution in server-services. Fix the source there, never here.
• Two renames, because Log Analytics reserves the names: time → TimeGenerated, title → activity_title
• Guarded by an append-only check: a build that removes or retypes a column fails rather than publishing

3. No analytic rules in this release

The three rules that translate Cato predefined alert-policy rules are held back deliberately.
Microsoft confirmed a solution is approved with a data connector alone, and the rules are still with
Cato's security team, so shipping the connector first and the rules in a later version costs
nothing. They remain a MISA requirement, so they are deferred rather than dropped.

4. Packaging and identity — the irreversible parts

SolutionMetadata.json — publisherId: catonetworks, offerId: cato-networks-sentinel-ccf-push. The offer ID must match the Partner Center offer exactly and cannot be changed after the offer is created; correcting it means deleting the offer and submitting a new PR. Note catonetworksltd1641478570665 also exists and is a legacy account — not the one to publish under.

Package/ — mainTemplate.json, createUiDefinition.json, testParameters.json, 3.0.0.zip, all produced by Microsoft's createSolutionV3.ps1. A hand-built equivalent was tried and is measurably wrong: it omits the analytic rules and drops a category domain.

Version 3.0.0 is the V3 packaging convention for a first release, not a typo.

Names that cannot change after publishing: stream Custom-CatoNetworksEvents, table CatoNetworksEvents_CL, connector id CatoNetworksEventsPush. Renaming any of them later strands every customer's historical data.

5. Three files outside the solution folder

Easy to miss, because nothing in Solutions/CatoNetworks/ points at them, and each omission is a CI failure:

File	Why
Logos/catonetworks.svg	Solution_CatoNetworks.json's Logo field is a raw URL to this exact path
.script/tests/KqlvalidationsTests/CustomTables/CatoNetworksEvents_CL.json	Without it every rule query fails KS204: does not refer to any known table
.script/tests/detectionTemplateSchemaValidation/ValidConnectorIds.json	Validate_DetectionTemplates_HasValidConnectorIds asserts each rule's connector id is listed

ValidConnectorIds.json is the only modified file: 351 → 352 entries, CatoNetworksEventsPush appended, nothing removed.

---

Two things that look like mistakes but are not

"BasePath": "C:\\GitHub\\Azure-Sentinel\\Solutions\\CatoNetworks" — a Windows path in a repo nobody builds on Windows. It is upstream convention; merged solutions from other vendors commit exactly this. Our build rewrites it locally and restores the placeholder before committing.

The Logo field points at a raw.githubusercontent.com/Azure/Azure-Sentinel/master/... URL that 404s today. It resolves only after this merges upstream. Every solution does it this way.

Still needs sign-off

• The logo — the Cato ring, matching the icon on Cato's existing Azure Marketplace listing (catonetworks.cato_socket_vm). Redrawn as SVG because that listing serves a 216x216 PNG and Sentinel accepts SVG only, with embedded PNGs explicitly rejected; geometry and colour were measured from that PNG. Passes every rule in Microsoft's logo checklist. Worth confirming with brand that this is the mark they want, and ideally replacing it with the official square icon from brand kit 101 if one exists as SVG — no standalone square mark is checked in anywhere, only the wide lockup.
• offerId — must be agreed before the Partner Center offer is created, since it is permanent.
• Listing content — privacy policy URL and screenshots. Needed for Partner Center, not for this PR.

What happens next

1. Review here, then open the real PR from this same branch to Azure/Azure-Sentinel and close this one. No rebuild needed.
2. Microsoft reviews. Published SLA is up to 8 calendar days.
3. After merge, create the Azure Application offer in Partner Center and publish to a preview audience of named Azure subscription IDs.

Schema updates do not go through this path. Existing customers get new fields from catonetworks/cato-sentinel-ccf, published automatically, with no Microsoft round trip.

[yoelk]

Superseded by the upstream submission: Azure#15004

This PR did its job — internal review before anything reached Microsoft. The branch cato-networks-ccf-push-3.0.0 is unchanged and is the head of the upstream PR, so it stays; only this review PR closes.